Electronic Health Records Database Design: Drug-to-Drug Interactions

Drug-to-drug interactions (DDIs) cause significant patient problems while treating comorbid conditions. Even though these problems are often predictable and preventable, a systematic approach is needed to avoid adverse drug events (ADEs). A clinical database can become an efficient solution for addressing the problem of DDIs. The present paper offers a database design that uses electronic health records (EHRs) to improve patient outcomes associated with ADEs by providing alerts of possible DDIs.

Problem Statement

Complex conditions are known to be treated with multiple drugs, which increases the risk of drug-related patient problems. According to Toivo, Mikkola, Laine, and Airaksinen (2016), DDIs become the reason for up to 2.6% of hospital admissions. DDIs are said to occur when several drugs interact in such a manner that efficiency or toxicity of one or several drugs is altered by others (Khandeparkar & Rataboli, 2017). Since all the drugs have annotations about the possible DDIs, ADEs are preventable most of the time. However, while prescribing, doctors may be unaware of the medications a patient is taking. Additionally, physicians might overlook possible DDIs, especially if they happen due to the interaction of more than two drugs. Therefore, a technological solution is needed to address the problem of ADEs.

A hospital database that includes the data about all the medications a patient is currently taking or has been taking can benefit healthcare providers and patients. Doctors can save time by reviewing electronic data about the history of a patient’s drug use instead of interviewing the patient. Additionally, such an approach can improve the accuracy of the information. While prescribing a medication, a doctor can enter the name of the drug he or she wants to recommend into a program interface. The software addresses the database and warns the user if the entered drug has possible DDIs with the medications the patients have been taking. Such a process has the potential to become an effective method for preventing ADEs.

Information Needed for the Database

The use of databases is known to be beneficial for studying DDIs. Patel, Borg, Haubrich, and McNicholl (2018) utilize a large database to extract information about patients and prescription data. The proposed database for avoiding ADEs will require similar data with several additions. The four major elements or entities are patients, drugs, DDIs, and prescriptions. The information needed to identify patients will be his or her first name, last name, middle initial, gender, date of birth (DOB). Patients’ full names are needed to identify them, while gender and DOB may be beneficial to determine the severity of possible ADEs. The information about drugs will include its generic name and brand name to identify them. The information about DDIs consists of the names of two drugs that may lead to ADEs and the description of the possible adverse effects. The information about prescriptions will include its patient information, data about the drug, and prescription date. The date is needed to understand if the patient can still experience the effects of DDIs even if he stopped using it. The information discussed above is the minimum for the effective work of the proposed database.

Entity Description

As mentioned above, the proposed database has four entities that have several attributes. The patient table has the columns for the first name, last name, middle initial, gender, and DOB. The first three attributes that state a full name of a patient are unstructured data since they can consist of various characters with the only restriction of the length. Gender is a structured attribute that will include only one letter: “F” for females and “M” for males. DOB is also a column that provides for structured data since users will have to enter data using a strict format. The patient table includes a unique ID that is also structured and automatically assigned by the system. All this information will be automatically gathered from hospital EHRs.

The drugs table has only three attributes, which are drug ID, its generic name, and brand name. While the ID is a numeric value that is structured and automatically assigned, the other two columns are unstructured with limited length. The DDI table will have three structured columns as the names for the drugs will be borrowed from the drugs table, and the IDs are always structured. However, the last column, description of ADEs, is unstructured. The prescription entity consists only of structures attributes and includes a prescription ID, patient ID, drug ID, and date. The design aims at containing as much structured data as possible to ensure data integrity and stability of database performance. Refer to Table 1 for the complete data dictionary for the proposed database design.

Table Name Attribute Name Contents Type Format Example Notes
PATIENT PAT_ID Automatically assigned ID of a patient integer ######### 1234567 Primary Key
PAT_FNAME Patient’s first name Varchar(30) Xxxxxxxxx John
PAT_LNAME Patient’s last name Varchar(30) Xxxxxxxxx Johnson
PAT_MIDINIT Patient’s middle initial Varchar(1) X J
PAT_DOB Patient’s date of birth date YYYY.MM.DD 2019.05.31
PAT_GEN Patient’s gender Varchar(30) X M
DRUG DRUG_ID Automatically assigned ID of a drug integer ######### 1234567 Primary Key
DRUG_GNAME Drug’s generic name Varchar(30) Xxxxxxxxx Metformin
DRUG_BNAME Drug’s brand name Varchar(30) Xxxxxxxxx Glucophage
DDI DDI_DRUG1ID ID of the first drug integer ######### 1234567 Primary Key, Foreign Key, references DRUG.DRUG_ID
DDI_DRUG2ID ID of the second drug integer ######### 1234567 Primary Key, Foreign Key, references DRUG.DRUG_ID
DDI_DESC Description of possible ADEs Varchar(225) Xxxxxxxxxxxx Headache
PRESCRIPTION PRES_ID Automatically assigned ID of a prescription integer ######### 1234567 Primary Key
DRUG_ID Automatically assigned ID of a drug integer ######### 1234567 Foreign Key, references DRUG.DRUG_ID
PAT_ID Automatically assigned ID of a patient integer ######### 1234567 Foreign Key, references PATIENT.PAT_ID
PRES_DATE Date of the prescription date YYYY.MM.DD 2019.05.31

Table 1. Data Dictionary.

Database Concept Map

The relationships between the entities are described in Figure 1.

Database Concept Map.
Figure 1. Database Concept Map.


The present paper offers an efficient database design to address the problem of DDIs. Instead of focusing on treating and managing the condition, the database aims at preventing AMEs. The design includes only essential entities and attributes and can be extended to address other issues or integrated into a larger hospital database. The primary characteristic of the database is data integrity and constancy since it focuses on structured data.


Khandeparkar, A., & Rataboli, P. (2017). A study of harmful drug–drug interactions due to polypharmacy in hospitalized patients in Goa Medical College. Perspectives in Clinical Research, 8(4), 180. Web.

Patel, N., Borg, P., Haubrich, R., & McNicholl, I. (2018). Analysis of drug–drug interactions among patients receiving antiretroviral regimens using data from a large open-source prescription database. American Journal of Health-System Pharmacy, 75(15), 1132-1139. Web.

Toivo, T., Mikkola, J., Laine, K., & Airaksinen, M. (2016). Identifying high risk medications causing potential drug–drug interactions in outpatients: A prescription database study based on an online surveillance system. Research in Social and Administrative Pharmacy, 12(4), 559-568. Web.