What concerns me here is that I see (from the consumer side) the
complexities of medical billing, with insurance submissions, partial
payments, etc. If your situation doesn't involve all those complexities --
and if you are sure you can handle whatever complexities you have -- then
you can go with an Access solution.

I did something similar just recently. Here's the general method.

1) As I think you already know, create separate tables for each item which
would otherwise have duplicates. In your case, this is at least Doctors,
Locations, and BillAreas. Each table should have an auto-number primary key
(PK) with a field size of long integer. I'll call these the item tables,
and the names stored in them "items".

2) Create whatever tables you need which use these items, with the items
represented by links (also called foreign keys, or FK). The FKs should be
numbers with field size long integer to match the PKs in the other tables.
I'll call these the transaction tables.

3) Set up database relationships to show the link between the FKs in the
transaction tables and the PKs in the item tables. Because the PKs are
"index no duplicates", Access knows that the relationships are one-to-many.
(You can set up the relationships later in queries, but by setting them up
at this time, they are automatically preset when you define the query.)

4) Create an input data table to store a copy of the input data, with the
same fields as your input data file. You will initially import your data
into this table, since it's much easier to deal with data already in the
database. (This will be one table for each different format of input file.
If you only have one input file format, then you only have one table.) The
important items (Location etc) should be indexed, but WITH duplicates,
because you haven't eliminated the duplicates at this point.

5) Set up an Update Query to edit and correct the input data. This is not
strictly necessary, but it's better to plan for it. In my case, some fields
imported as nulls when they needed to be zeroes.

6) Set up an Append Query for each item table, with the item table as the
destination. Each append query involves the input data table and the item
table Change the relationship to be a left join (option two in the join
properties) just for this query. In the first column, field = the input
data table field, table = the input data table, append to = the item table
field. In the second column, field = the item table field, table = the item
table, append to is blank, and criteria = "is null".

7) Set up an Append Query for the transaction table. This query will
include the transaction table and all the item tables. In the "field" line,
list all the fields in the input query you want to put in the transaction
table, and the corresponding transaction table names in the "append to"
line. But for the items, give the field name of the PK in the item table on
the "field" line, the item table on the "table" line, and the FK field name
in the transaction. Note that you do not directly reference the item names
from the input table; Access figures out from the relationships what PK
from the item table needs to go into the FK in the transaction table.

8) Set up a Select (the default) Query using the transaction table and the
item tables, selecting all the non-key fields in the transaction table and
the item fields from the item tables. This isn't strictly necessary but
makes building forms and reports a lot easier -- base the form/report on
this query rather than on all the tables.

9) To add new data:
  import into the input data table
  run the append query for the item tables
  run the append query for the transaction tables
  delete all the records from the input data table.
You can automate this, and will probably want to do so if this is a daily
process.

Edward