Вы находитесь на странице: 1из 7

Database Design and Knowledge Management Final Report

Submitted to:

Dr. Tinnakornsrisuphap

Prepared by:

Sarah Armenio

Health Care Informatics

HCIN 543 – 02B – Summer 2018

August 27, 2018


Executive Summary

A health care organization requires a method of storing data about its patients,

physicians, and the care provided by its physicians to its patients. Written notes about a patient’s

care or their visits is unstructured data that is difficult to search, requires time to read and

understand, and makes organizational level reporting almost impossible.

The solution is to create a database to store discrete, structured data points about patients

and their visits. Tables were created to store information about patients, visits, physicians, and

orders. Relationships between these tables were created to link the various data points (using

foreign keys) in meaningful and logical ways with careful consideration to create a database with

no redundant or repeating data. The database design also included the creation of forms to allow

users to enter data into the database, queries to retrieve common data entries, and reports to be

generated for the organization.

The result is a normalized database to store information about patients and key

information related to their care. Normalization means that any necessary updates to the entries

will be optimized since the data points are not repeated. Users of the system can make changes

to the data using a form, such as a name change, and have the update reflected in all related

tables automatically because of the relationships between the tables. A database administrator

will be responsible for control access to the database, its security, and maintenance of the

database including disaster planning and recovery.

Possible recommendations to the design of the database would be to alter the foreign keys

of the Visit and Order table to create clearer relationship between patients, visits, and orders.
1.0 Introduction

Health care organizations care for thousands of patients with each patient having one or more

visits and orders. Additionally, dozens or hundreds of physicians in the organization are

responsible for placing these orders and treating their patients during a visit. Understanding these

relationships, storing information about patients, and tracking visits or orders is difficult when it

is in written or unstructured format. Thus, a database can be created to store discrete, structured

data about patients and their care. Consideration is given to the attributes of each entity and the

relationships between table entities using primary keys, foreign keys, secondary keys, and

alternate keys. All primary keys of an entity should be unique and all relationships between the

tables should be one to many. Normalization of the database ensure that there is no redundant or

repeated data that would cause update anomalies.

2.0 Methodology

 Tables

Four tables were created in the database:

Patient (MedicalRecordNum, PatientFirstName, PatientLastName, PatientMiddleName,


PatientDOB, PatientGender)
AK None
SK PatientLastName, PatientFirstName, PatientDOB
FK None

Visit (VisitNum, VisitDate, DischargeDate, Facility, Department, PatientClass,


AdmitType)
AK None
SK VisitDate, DischargeDate, Facility, Department, PatientClass,
AdmitType
FK None

Order (OrderNum, OrderType, OrderStatus, Priority, RequestedDateTime, PhysNum,


MedicalRecordNum, VisitNum)
AK VisitNum
SK OrderType, OrderStatus, Priority, RequestedDateTime
FK PhysNum -> Physician, MedicalRecordNum -> Patient, VisitNum
-> Visit

Physician (PhysNum, PhysFirstName, PhysLastName, PhysSpecialty)


AK
SK PhysFirstName, PhysLastName, PhysSpecialty
FK None

One patient may have many visits. One visit may have many orders. One physician may

have many orders.

 Forms

o Patient: To create and update patients in the database

o Order: To create and update orders in the database

o Visit: To create and update visit in the database

o Physician: To create and add physicians in the database.

 Queries

o RetrievePatientAndOrder

 Retrieve all patients their corresponding orders.

 SELECT Patient.MedicalRecordNum, Patient.PatientFirstName,


Patient.PatientLastName, Order.OrderNum, Order.OrderType,
Order.OrderType, Order.OrderStatus, Order.Priority,
Order.RequestedDateTime, Order.PhysNum
FROM Patient INNER JOIN [Order] ON Patient.MedicalRecordNum =
Order.MedicalRecordNum;

RetrievePatientAndOrders
MedicalRecor PatientFirst PatientLast Order Expr100 OrderTy OrderSt Prior RequestedDa PhysN
dNum Name Name Num 4 pe atus ity teTime um
1000 Sarah Armenio 111 Urinean Urinean OPEN 8/26/2018 P100
lysis lysis
1000 Sarah Armenio 222 MRI MRI OPEN 8/25/2018 P200
2000 Roxeanne Tabaj 333 Blood Blood Closed STAT 8/15/2018 P100
3000 Leonard Honacki 444 X Ray X Ray Closed 8/23/2018 P200
4000 Timothy McCallan 555 MRI MRI Closed 8/20/2018 P100
RetrievePatientAndOrders
MedicalRecor PatientFirst PatientLast Order Expr100 OrderTy OrderSt Prior RequestedDa PhysN
dNum Name Name Num 4 pe atus ity teTime um
5000 Carlyn Smith 666 Gasto Gasto Open 8/25/2018 P200

o RetrievePatientByLastName

 Retrieve the patient with a last name of “Armenio”

 SELECT *
FROM Patient
WHERE PatientLastName = "Armenio";

RetrievePatientByLastName
MedicalRecordNu PatientFirstNa PatientLastNa PatientMiddleNa PatientDateOfBir PatientGend
m me me me th er
1000 Sarah Armenio Elizabeth 8/26/2018 Female
o RetrievePatientByMRN

 Retrieve the patient with a MedicalRecordNum of “1000”

 SELECT *
FROM Patient
WHERE MedicalRecordNum = '1000';

RetrievePatientByMRN
MedicalRecordNu PatientFirstNa PatientLastNa PatientMiddleNa PatientDateOfBir PatientGend
m me me me th er
1000 Sarah Armenio Elizabeth 8/26/2018 Female

o RetrievePhysicians

 Retrieve all physicians in the database

 SELECT *
FROM Physician;

RetrievePhysicians
PhysNum PhysFirstName PhysLastName PhysSpecialty
P100 Susan Smith Internal Medicine
P200 Christopher Adams Cardiology
o RetrieveVisitOn08252018

 Retrieve visits that occurred on “08/25/2018”


 SELECT Visit.[VisitDate], *
FROM Visit
WHERE (((Visit.[VisitDate])=#8/25/2018#));

RetrieveVisitOn08252018
VisitDate VisitNum DischargeDate Facility Department PatientClass AdmitType
8/25/2018 3405 Hospital B Gastro Outpatient OP
8/25/2018 5678 Hospital B Cardiology Outpatient OP

3.0 Results

 Reports

o Patients and Corresponding Orders

 Query Used: RetrievePatientAndOrder


 Information Shown: MRN, Patient First Name, Patient Last Name, Order
Number for the Patient, Order Type, Order Status, Order Priorty, Date
Requested for the orders, and the Physician that placed the order.

o All Physicians

 Query Used: RetrievePhysicians


 Information Shown: Physician Number, Physician First Name, Physician
Last Name, Physician Specialty

o RetrieveVisitOn08252018

 Query Used: RetrieveVisitOn08252018


 Information Shown: Visit Date, Visit Number, Discharge Date, Facility,
Department of visit, Patient Class for the visit, Admit Type for the visit.

4.0 Conclusions and Recommendations

After careful analysis of the environment a database was created to store patient, physician, visit,

and order information for the healthcare organization. Each table to hold this information was

given a unique primary key and designed so that the database was in normalized form with no
redundant or repeating data. One-to-many relationships between the entities were created

between patient and visit, patient and order, and order and physician. The Medical Record

Number was the primary key for Patient table and a secondary key for the Order table. This

meant that each order should have a Patient. This meant that every patient was directly linked to

an order.

One recommendation to the design would be to have Medical Record Number as a

secondary of the Visit entity, rather than the Order entity. A patient may have an order, but a

visit must exist for that order. With the current design, it is possible for an order to exist without

a visit, which is not reflective of the desired state. Rather a patient may have one or many visits,

and each visit may have one or many orders. Thus a better design would be as follows:

Patient (MedicalRecordNum, PatientFirstName, PatientLastName, PatientMiddleName,


PatientDOB, PatientGender)
AK None
SK PatientLastName, PatientFirstName, PatientDOB
FK None

Visit (VisitNum, VisitDate, DischargeDate, Facility, Department, PatientClass,


AdmitType, MedicalRecordNum)
AK None
SK VisitDate, DischargeDate, Facility, Department, PatientClass,
AdmitType
FK MedicalRecordNum -> Patient

Order (OrderNum, OrderType, OrderStatus, Priority, RequestedDateTime, PhysNum,


VisitNum)
AK VisitNum
SK OrderType, OrderStatus, Priority, RequestedDateTime
FK PhysNum -> Physician, VisitNum -> Visit

Похожие интересы