Ashley Teraishi

Jordan Guzman
January 25, 2021
Healthcare Database Design and Schema
The goals of this project were to design an Entity Relationship Diagram that captures a
visual representation of the database schema that we wrote in MySQL. Records of doctors,
patients, prescriptions, pharmacies, pharmaceutical companies, contracts between the pharmacies
and pharmaceutical companies, patient and pharmacy addresses, drugs, and varying drug prices
among the pharmacies are stored within the healthcare database. It was understood that a doctor
treats a patient, and a patient sees a doctor. This implies that a relationship exists between a
doctor and a patient. However, there are two ways in which this relationship exists. 1) A doctor
treats a patient and a patient is treated by a doctor; and 2) a doctor prescribes drugs to a patient
and a patient receives prescriptions from a doctor.
The relationship of treatment was handled with a table “treats” that stores references to
both the doctor and the patient in order to avoid redundant data. The prescription relationship is
both a relationship connecting entities, but it is also an entity itself that holds specific data
regarding a prescription. Prescription joins doctors, patients, drugs, and pharmacies. A drug
needs to be prescribed from a doctor to a patient; a patient needs to have a prescription to legally
buy a pharmaceutical drug; and a pharmacy must fill the prescription.
Both a pharmacy and a patient must have an address on file. This is handled by the
creation of a separate table address which stores the city, state, and zip code. It stores addresses.
The patient and pharmacy relations have foreign keys referencing the address relation. The
purpose of having created a designated address relation was to avoid data redundancy and update
anomalies. A pharmacy has a relationship with the drug relation because a pharmacy sells drugs
and pharmaceutical drugs are sold by pharmacies.
Things that needed to be considered were doctors having more than one patient, and
patients having more than one doctor. Both patient and doctor can be identified by their
respective SSN. Prescriptions also needed to record the prescribing doctor, the patient receiving
the prescription, the drug being prescribed, the quantity of the drug, the pharmacy at which the
prescription was filled, the prescription date, and the fill date. Care was taken to only record the
most recent prescription of a recurring drug being prescribed to a patient as to avoid redundant
clutter within a query that returns prescription data.

Records of drugs sold by specific pharmaceutical companies will be disposed of when the
record of the pharmaceutical company that makes the drug(s) is deleted. Contracts between
pharmacies and pharmaceutical companies, along with the supervisors handling the contracts and
other details, are recorded in the database. Among the details of the contracts are start and end
dates of the contract and the text within the contract.
The Entity Relationship Diagram consists of six entities with their given attributes,
eleven relationships, and three associative entities. A patient and a doctor have a relationship
that shows treatment. Treats is the associative entity that joins the patient and the doctor and
allows for each patient to see multiple doctors, or for each doctor to have multiple patients. The
creation of this associative entity allows for the schema to be normalized as “treats” eliminates
redundant data and update anomalies. A patient must have a primary care physician, but a
patient may also have specialists. Thus, we made the assumption that a patient can have many
doctors. A doctor must have at least one patient, but they will likely have many patients.

Prescription refers to four entities that are related through a prescription: the doctor, the
patient, the drug, and the pharmacy at which the prescription is filled. A doctor can prescribe
drugs for patients. According to treatment, the doctor may prescribe, one, many, or no drugs.
This is at the discretion of the doctor. Our assumption was that it is optional for a doctor to write
any prescription, but they can write many if they choose. However, a prescription must be
written by a doctor. A patient must receive a prescription if the patient is to legally receive a
pharmaceutical drug. For this reason, we made the assumption that it is mandatory for a patient
to have one or more prescriptions if they are to receive a pharmaceutical drug. A patient can
receive more than one prescription and can also receive prescriptions from more than one doctor.
One or many drugs can be prescribed. We assumed this to be necessary because a prescription
must prescribe at least one drug in order to be a prescription. Also, a drug must be prescribed if
it is to legally be distributed. There can be more than one prescription for a drug. Lastly, we
assumed the relationship between the pharmacy and the prescription to be a mandatory one due
to the definition of a prescription being filled. A prescription must be filled at a pharmacy. One
prescription cannot be filled at many pharmacies, but a pharmacy can fill many prescriptions.
The assumption was that a pharmacy must fill prescriptions by the definition of being labeled a
pharmacy.
A pharmacy must sell drugs in order to be considered a pharmacy. It must sell at least
one drug. A pharmaceutical drug does not necessarily need to be sold to pharmacies directly.
The drug can be sold to wholesalers, which then distribute the drug to pharmacies. Additionally,
each pharmacy sells drugs at different prices. To keep track of the various drug prices, we have a
table called sells. Sells includes foreign keys of pharmacy_id and trade_name, and also keeps
track of the price for each. The price attribute includes a check so that a price can never be
negative.
Pharmaceutical companies can have contracts with pharmacies to sell their drugs. They
do not need to have a contract with a pharmacy. They can instead sell the drugs to wholesalers
rather than to pharmacies. In this same regard, a pharmacy does not need to have a contract with
a pharmaceutical company. They can purchase the drugs from wholesalers. A pharmaceutical
company, if it chooses, can have contracts with several pharmacies, and pharmacies can have
contracts with various pharmaceutical companies. The “Contract” associative entity joins the
pharmacy and the pharmaceutical company in a relationship as they enter into a contract with
one another. “Contracts” is the relationship connecting “Pharmacy” and “PharmaCo” through
“Contract.” Another relationship between the pharmacy and the entity that is the contract is
supervises relationship. Supervises allows for this part of the schema to exist in the third normal
form. It eliminates update anomalies that are possible in the occurrence of a supervisor leaving
and creating the need for a replacement supervisor to take over the contract. The update just
needs to be made once rather than on every occurrence of the contract that contained the former
supervisor.
The contract contains records of a start and end date as well as the text that outlines
details of the contract between the pharmacy and pharmaceutical company. The contract can be
retrieved by a contract id. This measure was taken as it would be more efficient to retrieve a
contract from the id assigned to it rather than having to query the database for the supervisor
assigned to the contract. It was assumed that a supervisor can be assigned to numerous contracts
simultaneously. So, rather than sifting through the contracts assigned to a supervisor, the user
can just enter the contract_id to retrieve the details concerning the contract.

As a final note, to calculate the patient’s age and the doctor’s years_experience we added
two update statements towards the end of the schema. Upon insertion, age and years_experience
are both set to null, but are later calculated and updated. To calculate the patient’s age, we use
the dob attribute and find the difference between the system date and the patient’s date of birth.
Very similarly, to calculate the doctor’s years_experience we use the start_date attribute to
calculate the difference from the system date.
Entity Relationship Diagram:

SQL Queries

Question one asks how many times each drug has been prescribed in total. This is a pretty
simple query because we wanted to start off small and get more complex with each question. To
answer this question, we simply need to select the drug trade name and the number of times it
appears in a prescription. To complete the query, we left join the tables drug and prescription to
ensure that every drug in the database is accounted for. Finally, we group by trade name, the
drug primary key, to be able to see the count for each drug.

Question two pertains to a very real world scenario of checking prices before purchasing
an item. In this scenario, we want to find the pharmacy that sells Advil for the lowest price. To
answer this question, we need to join the tables pharmacy, drug, and sells. The sells table keeps
track of the prices for each drug at each pharmacy, so it takes the drug trade name and the
pharmacy id as foreign keys. Next, we need to group by the pharmacy id so that we can see the
prices for each pharmacy. Finally, we set a having constraint so that only the minimum price for
Advil is shown.

Question three pertains to the contracts between pharmacies and pharmaceutical

companies. We would like to show the supervisor, the start date, and the end date for contracts
between CVS and Pfizer. It is important to note that there is more than one CVS pharmacy, so
we need to account for all of them, not just one. To do so, we join the tables pharmacy,
pharma_co, contract, and supervises. We also ensure that only the contracts between CVS
pharmacies and Pfizer are shown by using where and having constraints.

Question four asks about the relationship between pharmaceutical companies, drugs, and
pharmacies. We would like to show the drugs that Pfizer sells and at which pharmacies these
drugs are sold. For this, we join the tables pharma_co, drug, pharmacy, and sells. Lastly, we need
to ensure that only drugs sold by the pharmaceutical company, Pfizer, are displayed.

Question five is our most comprehensive question of this assignment and shows the
relationships between many of the tables. The question asks to find the patient “Tom Smith” and
to display all of his doctors by name, all of his prescriptions with the drugs prescribed, the
quantity, and where the prescription was filled. In order to answer this question we need to join
the tables patient, doctor, treats, pharmacy, drug, and prescription. We also wanted to search for
the patient by his full name which is a concatenation of his first and last name attributes. To
finish up the query, we group by prescription_id and the doctor’s SSN so that each prescription
and doctor name is displayed for Tom Smith.

Conclusion
We explained how we interpreted the instructions and included the assumptions made to
help with the design and implementation of the database. The Entity Relationship diagram
visually captures our understanding and interpretation of what was explained to us for the
creation of the database. It also helped to guide the writing of the schema. The process of
designing the diagram illuminated any possible update anomalies that were lurking about. This
led to the creation of the associative entities that were used in response to the discovery of those
anomalies. Thus, the design helped to normalize the database in 3NF.