Database design and implementation for EasyMed (Online ...

1

Database design and implementation for EasyMed

(Online medical scheduling service)

IS613: Final Database Project – Team 4

Members

Gayathri Devi Annamalai ([email protected])

Ning Chen ([email protected])

Prajakta Degaonkar ([email protected])

Shweta Hirway ([email protected])

Sushama Shinde ([email protected])

Seidenberg School of Computer Science and Information Systems

Pace University, New York

Spring 2015

mailto:[email protected]





2

Table of Contents

1. Goal of the project 3

2. Organizational goals and objectives 3

3. Problem be solved 3

4. Database Solution 4

5. Business Rules 4

6. Flowchart 5

7. Preliminary Entity Relationship Model 6

8. Normalization Process 6

Denormalized Form 6

First Normal Form (1NF) 7

Second Normal Form (2NF) 8

Third Normal Form (3NF) 9

9. Entities after Normalization 11

10. Relationships between Entities after Normalization 12

11. Entity Relationship Diagram 13

12. Description of Tables (Create, Insert, Views) 14

13. Implementing the Database Solution in Microsoft Access 2013 16

14. Description of queries 19

Search_Doctor 19

UHC_Payer_ID_Query 20

Doctor_Review_Query 21

Doctor_Appointment_Query 23

Doctor_profile_address_query 24

15. Access forms 25

16. References 29

3

Goal of the project

The goal of our project is to create a database system for a patient to shortlist a doctor with the

help of doctor’s specialty, user submitted reviews and also manages online appointments as per

patient’s convenience.

Organizational Goals and Objectives

The Online Medical Booking System is easy to use, full-featured and flexible appointment

management portal. It allows patient to view list of doctors, available appointment time, and

book appointment, cancel appointment, and view his appointment history.

Problems to be solved

Healthcare is the biggest problem faced by every generation. Sometimes it is very difficult to

find suitable doctor in your locality and even if you find one, it is difficult to get convenient

appointment with the same. It enables users to make informed decisions by reading patient

reviews and by viewing the doctor’s calendar for vacant appointments. Many hospitals currently

uses a manual system for the scheduling and managing appointments which requires numerous

paper forms update, personal visits and phone follow-ups for appointment scheduling.

Even though it is sometimes easier to receive immediate appointment confirmation via telephone

booking, this facility is not feasible in the some emergency cases as its not available 24/7. When

a patient searches for specialized doctors in their area, they are provided with many doctors

under the same specialization and area. This can be overcome with the help of user submitted

reviews and ratings, to find the best doctor among them.

4

Sometimes a patient may face difficulties in finalizing a best suited doctor which falls under

patient’s insurance plan and coverage. This can cause inconvenience to patient as he/she might

need to pay from his pocket for the doctor’s fee and medicine.

Database Solutions

The objective of this database is to build a structured appointment scheduling system which will

go a long way toward improving revenue and increasing patient satisfaction in a medical

practice. The purpose of this database is create end-use searchable database where administrator

can manage doctor’s database and schedule from web based control panel. Doctors can view

their appointment list from this portal. Once the patients shortlists the doctors in their area

according to the required specialization, they can finalize the best doctor by comparing the user

submitted reviews and ratings.

Business Rules

Every user must have login Id and password.

A patient can search by doctor’s specialty, zip code and insurance.

Currently we are focusing on New York City’s five boroughs.

We have subdivided each boroughs in to two neighborhoods.

Further each neighborhood will have one zip code assigned to it.

Doctors are classified into four specialties.

While searching for doctor in database, patient can select from three insurance plans.

Each patient search will result into at least two doctors for comparison purpose.

Each patient can provide for doctors by submitting reviews and ratings.

Availability of reviews and ratings will help new patient to shortlist the doctor.

5

Each doctor will have available slots on particular days for online appointments.

The patient can view the doctor’s profile and schedule appointment as per his

convenience.

Patients with no insurance plan/coverage can also take advantage of this database.

Flowchart

6

Preliminary Entity Relationship Model

Normalization Process

Denormalized Form

Doctor-Doctor Review Relationship:

Doctor_License_No Doctor_Fname Doctor_Lname Doctor_Email_ID Doctor_Phone

Doctor_Specialty Doctor_Education Supported_Insurance

Patient_ID Review_Comment Review_Rating Review_Date

Doctor_Language_Spoken Doctor_Prof_Membership

7

Patient-Appointment-Record:

Patient_ID Patient_Fname Patient_Lname Patient_Email_ID Patient_Phone

Patient_Address_Line1 Patient_Address_Line1 Location_ID Location_Zip_Code

Appointment_ID Appointment_Date Appointment_Time Appointment_Status Visit_ID

Doctor_License_No

Insurance-Bill

Insurance_ID Insurance_Name Payer_ID Patient_ID

Bill_ID Doctor_License_No

Location-Location Mapping

Location_ID Location_Zip_Code Location_Borough Location_Neighborhood

Doctor_License_No Clinic_Address_Line1 Clinic_Address_Line2

First Normal Form (1NF)

Table format: No repeating groups and PK identified (Doctor_License_No, Review_Reference,

Patient_ID, Appointment_ID, Insurance_ID, Location_ID, Location_Zip_Code)





Doctor_Language_Spoken Doctor_Prof_Membership

Patient-Appointment-Record:



Appointment_ID Appointment_Date Appointment_Time Appointment_Status

Doctor_License_No

8

Insurance-Bill


Bill_ID Doctor_License_No




Second Normal Form (2NF)

The tables should be in 1NF and have no partial dependencies.


Doctor




Doctor Profile

Doctor_Prof_Membership_ID Doctor_License_No Doctor_Prof_Membership Doctor_Language_Spoken

Patient-Appointment:

Patient



Appointment


Doctor_License_No Patient_ID

9

Visit:

Visit_ID Visit_Purpose Record_ID

Medical Record:

Record_ID Patient_ID Appointment_ID

Insurance-Bill:

Insurance


Bill

Bill_ID Doctor_License_No Insurance_ID

Payment


Location



Third Normal Form (3NF) and Boyce-Codd Normal Form (BCNF)


Doctor



Payment_ID Bill_ID

10

Review

Review_Reference Patient_ID Review_Comment Review_Rating Review_Date

Doctor Profile

Doctor_Prof_Membership_ID Doctor_License_No Doctor_Prof_Membership Doctor_Language_Spoken

Patient-Appointment:

Patient



Appointment


Doctor_License_No

Visit:

Visit_ID Visit_Purpose Record_ID

Medical Record:

Record_ID Patient_ID Appointment_ID

Insurance-Bill:

Insurance


Bill

Bill_ID Doctor_License_No Insurance_ID

11

Payment

Location-Location Mapping:

Location


Location mapping

Location_ID Location_Zip_Code Doctor_License_No Clinic_Address_Line1 Clinic_Address_Line2

Entities after Normalization

Entity Entity Description

Doctor A person who is licensed to practice medicine

Doctor_Profile Object of doctor details for helping patient matching

Doctor_Review Visiting doctor experience from patient

Patient A person who is under medical care or treatment

Appointment Doctor for whom patient has been appointed

Visit Object of doctor office visit

Medical_Record Object of patient physical or mental problem history

Insurance Coverage that covers the cost of an insured individual's medical and surgical expenses.

Bill Fee generated after visiting doctor

Payment Payment for bill

Location Address which patient locates

Location_Mapping Doctor’s office where is convenience for patient choosing

Payment_ID Bill_ID

12

Relationships between Entities after Normalization

Entities

Relation

Cardinalities

Parent Child Min Max

Doctor Doctor_Profile Identify 1:1 1:1

Doctor Doctor_Review Non-

Identify

1:1 1:M

Doctor Location_Mapping Identify 1:1 1:1

Doctor Bill Non-

Identify

1:1 1:M

Doctor Appointment Non-

Identify

1:1 1:M

Patient Doctor_Review Identify 1:1 1:M

Patient Insurance Non-

Identify

1:1 1:1

Patient Appointment Non-

Identify

1:1 1:0

Patient Medical_Record Non-

Identify

1:0 1:0

Visit Appointment Non-

Identify

1:1 1:M

Appointment Medical_Record Non-

Identify

1:1 1:M

Insurance Bill Non-

Identify

1:1 1:M

Bill Payment Non-

Identify

1:1 1:M

Location Location_Mapping Identify 1:1 1:M

Medical_Record Visit Non-

Identify

1:0 1:0

13

Relationship between Doctor and different types of doctors identified as supertype (Doctor) and

subtype (Primary_Care, Pediatrician, Dentist, and Dermatologist). Relationship between

Location and different types of Locations, and relationship between Insurance and different types

of Insurances have same relationship as above. Supertype and its subtypes represent different

aspects of the same entity, which is viewing differently. We can use only Doctor entity but at

this point some of the attributes will not be applicable, and cells in the table will not have value

(for example, Primary_Care will not needed Doctor_Fname or Doctor_Phone). All entities in this

type of relationship should have the same identifier (Doctor_License_No) because they represent

different aspects of the same entity (Doctor).

Entity Relationship Diagram

The above mentioned entities, attributes, constraints and relationships are converted into below

ER model:

14

Description of Tables

Doctor

Doctor table contains the following attributes: a number for uniquely identifying the doctors, the

doctor’s first and last names, and the doctor’s Email address, Phone number, Specialty,

Education and Supported_Insurance are listed in table.

Doctor (Doctor_License_No, Doctor_Fname, Doctor_Lname, Doctor_Email_ID,

Doctor_Phone, Doctor_Speciality, Doctor_Education, Supported_Insurance )

Doctor_Profile

Doctor_Profile table contains the following attributes: Doctor_Prof_Membership_ID and

Doctor_License_No as uniquely identify doctor profile, and Doctor_Language_Spoken, and

Doctor_Prof_Membership are also listed.

Doctor_Profile (Doctor_Prof_Membership_ID, Doctor_License_No,

Doctor_Language_Spoken, Doctor_Prof_Membership)

Doctor_Review

Doctor_Review table contains the following attributes: Review_Reference and Patient_ID as

uniquely identify Doctor_Review, and Review_Comments, Review_Rating, Review_Date,

Doctor_License_No)

Doctor_Review (Review_Reference, Patient_ID, Doctor_Review, Review_Comments,

Review_Rating, Review_Date, Doctor_License_No)

Location

Location table contains the following attributes: Location_ID and Location_Zip_Code as

uniquely identify Location, and Location_Borough, Location_Neighborhood are also included)

Location (Location_ID, Location_Zip_Code, Location_Borough, Location_Neighborhood)

Location_Mapping

Location_Mapping table contains the following attributes: Location_ID, Location_Zip_Code and

Doctor_License_No as uniquely identify Location, and Clinic_Address_Line1,

Clinic_Address_Line2 are also contained.

15

Location_Mapping (Location_ID, Location_Zip_Code, Doctor_License_No ,

Clinic_Address_Line1, Clinic_Address_Line2)

Patient

Patient table contains the following attributes about patient information: Patient_ID as uniquely

identify Patient, and Patient_Fname, Patient_Lname, Patient_Email_ID, Patient_Phone,

Patient_Address_Line1, Patient_Address_Line1 describe patient information.

Patient (Patient_ID, Patient_Fname, Patient_Lname, Patient_Email_ID, Patient_Phone,

Patient_Address_Line1, Patient_Address_Line1)

Insurance

Insurance table contains the following attributes about Insurance information: Insurance_ID that

uniquely identifying Patient’s Insurance for doctor matching, Insurance_Name, Payer_ID,

Patient_ID are listed)

Insurance (Insurance_ID, Insurance_Name, Payer_ID, Patient_ID)

Medical_Record

Medical_Record contains the following attributes for patient’s medical record: Record_ID that

uniquely identifying Medical_Record, Patient_ID, Appointment_ID are also included.

Medical_Record (Record_ID, Patient_ID, Appointment_ID)

Visit

Visit table contains the following attributes: Visit_ID that uniquely identifying Visit,

Visit_Purpose, Record_ID are also listed.

Visit (Visit_ID, Visit_Purpose, Record_ID)

Appointment

Appointment table contains the following attributes: Appointment_ID as uniquely identify

Appointment situation, Appointment_Date, Appointment_Time, Appointment_Status,

Patient_ID, Visit_ID, Doctor_License_No are listed as well.

Appointment (Appointment_ID, Appointment_Date, Appointment_Time,

Appointment_Status, Patient_ID, Visit_ID, Doctor_License_No)

16

Bill

Bill table contains the following attributes: Bill_ID as uniquely identify Bill, Insurance_ID,

Doctor_License_No are included.

Bill (Bill_ID, Insurance_ID, Doctor_License_No)

Payment

Payment table contains the following attributes for patient’s payment after visiting doctors:

Payment _ID that uniquely identifying Payment, Bill_ID is contained.

Payment (Payment _ID, Bill_ID)

Implementing the Database Solution in Microsoft Access 2013

This is the layout of Access relationship model in Access 2013:

Examples of creating tables, adding constraints while creating tables itself, inserting values into

tables and views of tables in MS Access are as follows:

17

Table Doctor_Profile:

1. Create table

2. Insert values in table

3. Table-view of tuples from Doctor_Profile

Table Medical_Record:

1. Create table


18

3. Table-view of tuples from Medical_Record

Table Patient:

1. Create table


3. Table-view of tuples from Patient

19

Description of Queries

Query 1: Search_Doctor

Which dentists are available in New York borough Queens (Zip code – 11354 and 11365)

which supports insurance type ‘UHC’?

SELECT DOCTOR.DOCTOR_LICENSE_NO, DOCTOR.DOCTOR_FNAME, DOCTOR.DOCTOR_LNAME, DOCTOR.DOCTOR_PHONE, DOCTOR.DOCTOR_EMAIL_ID, PATIENT.LOCATION_ZIP_CODE FROM DOCTOR INNER JOIN (LOCATION_MAPPING INNER JOIN PATIENT ON (LOCATION_MAPPING.LOCATION_ZIP_CODE = PATIENT.LOCATION_ZIP_CODE) AND (LOCATION_MAPPING.LOCATION_ID = PATIENT.LOCATION_ID)) ON DOCTOR.DOCTOR_LICENSE_NO=LOCATION_MAPPING.DOCTOR_LICENSE_NO GROUP BY DOCTOR.DOCTOR_LICENSE_NO, DOCTOR.DOCTOR_FNAME, DOCTOR.DOCTOR_LNAME, DOCTOR.DOCTOR_PHONE, DOCTOR.DOCTOR_EMAIL_ID, PATIENT.LOCATION_ZIP_CODE, DOCTOR.DOCTOR_SPECIALITY, DOCTOR.SUPPORTED_INSURANCE HAVING (((PATIENT.LOCATION_ZIP_CODE) =11354 Or (PATIENT.LOCATION_ZIP_CODE) =11365) AND ((DOCTOR.DOCTOR_SPECIALITY) ="DENTIST") AND ((DOCTOR.SUPPORTED_INSURANCE) ='UHC'));

20

Output of Query 1:

Query 2: UHC_Payer_ID_Query

Doctor D_231 (with specialty Dermatologist) wants to count patients who visited him and

their Payer ID for insurance type UHC.

SELECT DOCTOR.DOCTOR_LICENSE_NO, Count (APPOINTMENT.APPOINTMENT_ID) AS COUNT_OF_APPOINTMENTS, APPOINTMENT.PATIENT_ID, PATIENT.PATIENT_FNAME, PATIENT.PATIENT_LNAME, INSURANCE.INSURANCE_ID, INSURANCE.PAYER_ID FROM DOCTOR INNER JOIN ((PATIENT INNER JOIN INSURANCE ON PATIENT.[PATIENT_ID] = INSURANCE.[PATIENT_ID]) INNER JOIN APPOINTMENT ON PATIENT.[PATIENT_ID] = APPOINTMENT.[PATIENT_ID]) ON DOCTOR.[DOCTOR_LICENSE_NO] = APPOINTMENT.[DOCTOR_LICENSE_NO] GROUP BY APPOINTMENT.PATIENT_ID, PATIENT.PATIENT_FNAME, PATIENT.PATIENT_LNAME, INSURANCE.INSURANCE_ID, INSURANCE.PAYER_ID, DOCTOR.DOCTOR_LICENSE_NO, INSURANCE.INSURANCE_NAME HAVING (((DOCTOR.DOCTOR_LICENSE_NO) ="D_231") AND ((INSURANCE.INSURANCE_NAME) ="UHC"));

21

Output of query 2:

Query 3: Doctor_Review_Query

Patients wants to look for doctor’s reviews and ratings with specialty as Primary_Physician

in Manhattan borough.

SELECT LOCATION.LOCATION_BOROUGH, LOCATION.LOCATION_ZIP_CODE, LOCATION_MAPPING.DOCTOR_LICENSE_NO, DOCTOR.DOCTOR_FNAME, DOCTOR.DOCTOR_LNAME, DOCTOR.DOCTOR_EDUCATION, DOCTOR_REVIEW.REVIEW_REFERENCE, DOCTOR_REVIEW.REVIEW_COMMENT, DOCTOR_REVIEW.PATIENT_ID, DOCTOR_REVIEW.REVIEW_DATE FROM (DOCTOR INNER JOIN (LOCATION INNER JOIN LOCATION_MAPPING ON (LOCATION.[LOCATION_ZIP_CODE] = LOCATION_MAPPING.[LOCATION_ZIP_CODE]) AND (LOCATION.[LOCATION_ID] = LOCATION_MAPPING.[LOCATION_ID])) ON DOCTOR.[DOCTOR_LICENSE_NO] = LOCATION_MAPPING.[DOCTOR_LICENSE_NO]) INNER JOIN DOCTOR_REVIEW ON DOCTOR.[DOCTOR_LICENSE_NO] = DOCTOR_REVIEW.[DOCTOR_LICENSE_NO] GROUP BY LOCATION.LOCATION_BOROUGH, LOCATION.LOCATION_ZIP_CODE, LOCATION_MAPPING.DOCTOR_LICENSE_NO, DOCTOR.DOCTOR_FNAME, DOCTOR.DOCTOR_LNAME, DOCTOR.DOCTOR_EDUCATION, DOCTOR_REVIEW.REVIEW_REFERENCE, DOCTOR_REVIEW.REVIEW_COMMENT, DOCTOR_REVIEW.PATIENT_ID, DOCTOR_REVIEW.REVIEW_DATE,

22

DOCTOR_REVIEW.REVIEW_RATING, DOCTOR.DOCTOR_SPECIALITY HAVING (((LOCATION.LOCATION_BOROUGH) ="Manhattan") AND ((DOCTOR.DOCTOR_SPECIALITY) ="Primary Physician")) ORDER BY LOCATION_MAPPING.DOCTOR_LICENSE_NO;

Output of query 3:

Query 4: Doctor_Appointment_Query

Doctor with license number D_213 and specialty as Pediatrician needs to know which all

patients has visited him on May 4th 2015 and their visit purposes.

SELECT DOCTOR.DOCTOR_LICENSE_NO, APPOINTMENT.APPOINTMENT_ID, APPOINTMENT.APPOINTMENT_DATE,

23

APPOINTMENT.APPOINTMENT_TIME, APPOINTMENT.PATIENT_ID, APPOINTMENT.VISIT_ID, PATIENT.PATIENT_FNAME, PATIENT.PATIENT_LNAME, VISIT.VISIT_PURPOSE FROM VISIT INNER JOIN (PATIENT INNER JOIN (DOCTOR INNER JOIN APPOINTMENT ON DOCTOR.[DOCTOR_LICENSE_NO] = APPOINTMENT.[DOCTOR_LICENSE_NO]) ON PATIENT.[PATIENT_ID] = APPOINTMENT.[PATIENT_ID]) ON VISIT.[VISIT_ID] = APPOINTMENT.[VISIT_ID] GROUP BY DOCTOR.DOCTOR_LICENSE_NO, APPOINTMENT.APPOINTMENT_ID, APPOINTMENT.APPOINTMENT_DATE, APPOINTMENT.APPOINTMENT_TIME, APPOINTMENT.PATIENT_ID, APPOINTMENT.VISIT_ID, PATIENT.PATIENT_FNAME, PATIENT.PATIENT_LNAME, VISIT.VISIT_PURPOSE HAVING (((DOCTOR.DOCTOR_LICENSE_NO) ="D_213") AND ((APPOINTMENT.APPOINTMENT_DATE) =#5/4/2015#));

Output of query 4:

24

Query 5: Doctor_profile_address_query

What is the doctor profile (doctor’s professional memberships and languages spoken) and

doctor’s clinic address for Dentist in Queens, Zip code 11354.

SELECT DOCTOR.DOCTOR_LICENSE_NO, DOCTOR_PROFILE.DOCTOR_PROF_MEMBERSHIP_ID, DOCTOR_PROFILE.DOCTOR_PROF_MEMBERSHIP, DOCTOR_PROFILE.DOCTOR_LANGUAGE_SPOKEN, LOCATION_MAPPING.CLINIC_ADDRESS_LINE1, LOCATION_MAPPING.CLINIC_ADDRESS_LINE2 FROM (DOCTOR INNER JOIN LOCATION_MAPPING ON DOCTOR.[DOCTOR_LICENSE_NO] = LOCATION_MAPPING.[DOCTOR_LICENSE_NO]) INNER JOIN DOCTOR_PROFILE ON DOCTOR.[DOCTOR_LICENSE_NO] = DOCTOR_PROFILE.[DOCTOR_LICENSE_NO] WHERE (((DOCTOR.DOCTOR_SPECIALITY) ="Dentist") AND ((LOCATION_MAPPING.LOCATION_ZIP_CODE) =11354));

Output of query 5:

25

Access forms

As a part of adhoc query and user interface, we have created Access forms which will take inputs

form user for search criteria and show records which satisfy that criteria as result.

1. Form1_ALL_DOCTOR Query:

This form execution, asks user for ‘What doctor specialty you are looking for?’ as input 1:

Consider, user / patient is looking for Dentist for this example. Once he enters that input as

Dentist following screen will ask user for ‘Which New York borough you are looking for?’ as

input 2:

26

Suppose, user/patient is looking for Dentist in Queens Borough. Once he enters that input as

Queens for this question, following screen will ask user for ‘Which insurance do you have?’ as

input 3:

As part of this query, consider user inputs as UHC and enter it. Follwing view of doctors record will

apeers on screen. This criteira is satisfied by 4 doctors in database so result will be as shown below in 4

output screens:

28

2. Form2_Appointment_status Query:

Once user/ patient has finalized the doctor as per form 1 execution, next step will be looking for

all available appointment slots for that doctor on particular day as per patient’s need.

This form 2 execution, asks user for ‘What is the doctor license number for your finalized

doctor?’ as input 1:

29

Consider, user / patient has finalized for D_201 as an example. Once he enters that input as

D_201 following screen will ask user for ‘Which date you are looking for?’ as input 2:

Suppose, user/patient is looking for appointment slots on May 8th 2015. Once he enters that input

as 5/8/2015 for this question. As an output of this query, following set of records will appear.

References:

https://www.health.ny.gov/statistics/cancer/registry/appendix/neighborhoods.htm

Coronel C., & Morris S. (2015). “Database Systems: Design, Implementation, and Management,” 11th

Edition, Cengage Learning.

https://www.health.ny.gov/statistics/cancer/registry/appendix/neighborhoods.htm

Database design and implementation for EasyMed (Online ...

Documents

Transcript of Database design and implementation for EasyMed (Online ...