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

Subject:	Health IT
Pages:	4
Words:	1036
Reading time:	5 min
Study level:	Master

Problem Statement
Information Needed for the Database
Entity Description
Database Concept Map
Conclusion
References

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.

Conclusion

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.

References

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.