Project Scenario
You are a small database consulting company specializing in developing databases for the medical industry. You have just been awarded the contract to develop a data model for a database application system for a mid-size health insurance company to keep track of health claims including patient information, provider(doctor) information, information about patient visits to their doctor as well as prescription drugs prescribed to patients.
Information such as patient name, address, phone, email etc. are needed as well as who each patient’s primary care doctor is, their insurance ID number and insurance company name. We also want information on each doctor such as their specialty and what hospitals they are affiliated with as well as their phone, address etc. Regarding the hospitals themselves we will need to know where they are located and how to contact them.
The prescriptions given to each patient by a health-care provider also need to be tracked in this particular database at this time to determine claim eligibility including some basic information on the drug being prescribed to make sure there are no conflicts with a patient’s other prescriptions. We need to know each drug’s name, purpose/use, and possible side effects.
Eventually, the database will be used to track trends and for some extrapolative modeling based on the accumulated data. The database will be accessible in English only right now, although plans include making it available in multiple languages eventually.
Part A: Determining entities, attributes, UIDs
Based on the business scenario stated above you will identify the database needs, and then create a conceptual data model to support these needs.
Review the types of information a medical database may contain. Read articles and check the internet to understand the challenges of tracking this information.
Research medical information to better understand your topic. Look for the type of information you will need to track.
Build a list of business needs, rules and assumptions based on your scenario, research, and objectives.
Develop a list of potential entities including their attributes, the attribute’s optionality as well as a possible UID for each entity. HINT: A maximum of 4 are required. Choose carefully!
Create a preliminary Entity Relationship Diagram (ERD) that meets these needs and objectives. (Note: Create entities only, relationships will be added in Part C)
What to submit: All relevant documentation for parts 1 to 4 plus preliminary ERD
PART B: Supertypes and subtypes
As stated in the scenario we need to track the visits a patient makes to their doctor. Some patient visits are related to a new issue/illness, some are follow up visits to an existing diagnosis and some visits are routine “well patient” visits or checkups. We would like to be able to track which type of visit each instance is so we can keep specific information regarding the visit. For example:
For a new issue/illness visit we will store an initial diagnosis
For follow-up visits we need to keep track of the patient’s status regarding the diagnosis
For routine checkups we need to track patient vital information such as current blood pressure, height, and weight and if any condition is discovered a diagnosis will be noted.
Finally, modify the ERD using a supertype/subtype structure within the Office Visit entity.
What to submit: Modified ERD
PART C: Relationships
While creating your entities you should have been thinking about what relationships the entities would have with each other. Create the relationships between your entities including the relationship’s optionality and cardinality.
Write out the ERDish for each of the relationships. HINT For example: Each PATIENT must have one and only one DOCTOR (their primary doctor) and/or Each PRESCRIPTION must be prescribed by one and only one DOCTOR.
Some relationships will be transferrable and some non-transferrable – be sure to illustrate this point on the ERD. For example, once a prescription is written for a patient it cannot be transferred to another patient.
The possible relationship types are: 1-to-1, 1-to-many and many-to-many.
Any many-to-many relationships will need to be resolved. For example, each doctor may be affiliated with many hospitals and each hospital may have many doctors affiliated with it. We need to make sure the many-to-many relationships are resolved.
Modify the ERD from parts A and B to include the relationships.
What to submit: All ERDish rules and ERD diagram with relationships
