Insurance spread over four tables?

michael_barnett wrote on Wednesday, June 21, 2006:

can someone tell me why insurance information is split into

insurance_companies
insurance_data
insurance_numbers
phone_numbers

I was trying to provide the phone number for an insurance company.

when you fill out the insurance demographics there is no place to add the insurance companies phone number.

if you hit the add/search it does have a place to enter the phone number. But it places the phone number in the phone_number table not the insurance_numbers table.

am i missing something on how to add an insurance company or is there a way to fill out he table for insurance numbers i don’t know of.

sunsetsystems wrote on Wednesday, June 21, 2006:

insurance_companies: This table is somewhat misnamed  since the same companies appear in it multiple times… as they have multiple plans or billing locations.  Perhaps there should be a separate "insurance_plans" table.

insurance_data: This identifies, for each patient, which insurance plans they use.

insurance_numbers: These are the physician credentialing numbers assigned by the insurance companies.

phone_numbers (and similarly addresses): Someone decided that phone numbers and addresses should go into separate tables.  This is somehwhat reasonable, but not how I would have done it.

Rod
www.sunsetsystems.com

michael_barnett wrote on Wednesday, June 21, 2006:

i guess this type of thing happens when something is in a constant state of improvement or change.

markleeds wrote on Wednesday, June 21, 2006:

Where’s tekknogenius?  He’s the database expert.  He was talking about normalizing our tables.

michael_barnett wrote on Wednesday, June 21, 2006:

hehe i just sent the database to montana state college of technology. the database instructor there is brutal on database normalization man he hammered that stuff for two years. but i asked him if he could challege some of his students to normalize it.

I’m taking two database classes in sept one programming the other management maybe i can look at it further then.

sunsetsystems wrote on Wednesday, June 21, 2006:

The other problem with the database that should be fixed is there’s no referential integrity checking.  Postgres has supported this for years and makes it really easy.  MySQL finally supports it now but only with INNODB tables.

Rod
www.sunsetsystems.com

andres_paglayan wrote on Wednesday, June 21, 2006:

I have a work in progress database normalization
you can donwload the clay file @
paglayan.com/DataModel.clay
although you’ll need eclipse with the clay dbase modeling plugin to open it.
at paglayan.com/DataModel.sql
you’ll find the sql definition for the data model, so you could reverse it into your db design tool,
again,
is work in progress and is 50% done for a whole OEMR design,
the downside I’m finding is that with all the db normalized the code to be re-written is too extensive, and it justifies a whole re-write,

drbowen wrote on Wednesday, June 21, 2006:

—The other problem with the database that should be fixed is there’s no referential
integrity checking.  Postgres has supported this for years and makes it really
easy.  MySQL finally supports it now but only with INNODB tables.—

I’m already running one table with InnoDB.  MySAM is moving towards being deprecated with the new standard being InnoDB.

InnoDB improves referential integrity and I believe is now supporting triggers and stored procedures.

Sam Bowen