This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR Medical Informatics, is properly cited. The complete bibliographic information, a link to the original publication on http://medinform.jmir.org/, as well as this copyright and license information must be included.
A computerized physician order entry (CPOE) system combined with a clinical decision support system can reduce duplication of medications and thus adverse drug reactions. However, without infrastructure that supports patients’ integrated medication history across health care facilities nationwide, duplication of medication can still occur. In Taiwan, the National Health Insurance Administration has implemented a national medication repository and Web-based query system known as the PharmaCloud, which allows physicians to access their patients’ medication records prescribed by different health care facilities across Taiwan.
This study aimed to develop a scalable, flexible, and thematic design-based clinical decision support (CDS) engine, which integrates a national medication repository to support CPOE systems in the detection of potential duplication of medication across health care facilities, as well as to analyze its impact on clinical encounters.
A CDS engine was developed that can download patients’ up-to-date medication history from the PharmaCloud and support a CPOE system in the detection of potential duplicate medications. When prescribing a medication order using the CPOE system, a physician receives an alert if there is a potential duplicate medication. To investigate the impact of the CDS engine on clinical encounters in outpatient services, a clinical encounter log was created to collect information about time, prescribed drugs, and physicians’ responses to handling the alerts for each encounter.
The CDS engine was installed in a teaching affiliate hospital, and the clinical encounter log collected information for 3 months, during which a total of 178,300 prescriptions were prescribed in the outpatient departments. In all, 43,844/178,300 (24.59%) patients signed the PharmaCloud consent form allowing their physicians to access their medication history in the PharmaCloud. The rate of duplicate medication was 5.83% (1843/31,614) of prescriptions. When prescribing using the CDS engine, the median encounter time was 4.3 (IQR 2.3-7.3) min, longer than that without using the CDS engine (median 3.6, IQR 2.0-6.3 min). From the physicians’ responses, we found that 42.06% (1908/4536) of the potential duplicate medications were recognized by the physicians and the medication orders were canceled.
The CDS engine could easily extend functions for detection of adverse drug reactions when more and more electronic health record systems are adopted. Moreover, the CDS engine can retrieve more updated and completed medication histories in the PharmaCloud, so it can have better performance for detection of duplicate medications. Although our CDS engine approach could enhance medication safety, it would make for a longer encounter time. This problem can be mitigated by careful evaluation of adopted solutions for implementation of the CDS engine. The successful key component of a CDS engine is the completeness of the patient’s medication history, thus further research to assess the factors in increasing the PharmaCloud consent rate is required.
Duplication of medication can be defined as a patient being prescribed more than two medications of the same therapeutic class (including different doses, forms, frequencies, or routes) within an overlapping period, with one of the prescriptions being clinically redundant [
In addition, duplication of medications increases overall medical expenditures [
More and more information and communication technologies, such as clinical decision support systems (CDSSs), have been proposed as a solution for improving medication safety. Many studies have suggested that a computerized physician order entry (CPOE) system combined with a CDSS could help in preventing ADRs [
In Taiwan, the National Health Insurance Administration (NHIA) has implemented approaches for sharing patients’ medical care information nationwide, including health smart cards [
Currently, the PharmaCloud stores the latest 3 months of each patient’s prescribed medication records. It supports two access modes for authorized clinical professionals. One is an online query through a Web browser interface; the other is a batch download. By using the online query mode, an authorized physician can access patients’ medication histories in the PharmaCloud through a Web browser. When the physician wants to prescribe medication orders for a patient, he or she can use the Web browser to submit queries about the patient’s medication history prior to ordering a prescription. A physician can check that information on the browser manually and then use that information to make independent decisions about the prescription to avoid prescribing duplicate medications. Most health care facilities encourage their physicians to use the online query mode to access the PharmaCloud. However, physicians are usually very busy and so this approach may not be feasible.
In the batch download mode, a patient’s medication history can be downloaded from the PharmaCloud provided the patient has signed an informed consent form allowing the authorized physicians access and has made an appointment at least one day in advance. We will refer to the informed consent form as the PharmaCloud consent form. In this approach, the downloaded patients’ medication histories have to be integrated into a CPOE system so that the CPOE can verify the prescription to see if there is any potential duplicate medication and other ADRs. However, CPOE systems are complex because they must access data from various systems within a hospital. Furthermore, electronic health record (EHR) systems are usually adopted incrementally [
In this study, we developed a modularized clinical decision support (CDS) engine that can support duplicate medication checks based on the PharmaCloud. We also analyzed the impact of the CDS engine on patient encounter time and physicians’ responses to handling potential duplicate medication alerts. These results could provide insights to adopt the CDS engine and recommendations to improve the efficiency in medication safety checks.
For this study, the CDS engine was developed and installed at Taipei Medical University Hospital, a teaching hospital with nearly 800 beds. The hospital has a highly informative infrastructure and is a certified Healthcare Information and Management Systems Society EHR Adoption Model stage 6 hospital [
The framework of the CDS engine and interactions with the PharmaCloud and a CPOE system are presented in
The PharmaCloud adapter is used to access a patient’s visit appointment information registered in the patient appointment system and to verify whether the patient signed the PharmaCloud consent form for PharmaCloud access. If so, the PharmaCloud adapter retrieves the patient’s last 3 months of medication records from the PharmaCloud via batch download over the National Health Insurance (NHI) virtual private network (VPN).
The CDS engine local repository was implemented using the PostgreSQL relational database system [
The decision support module is a decoupled, thematic design approach that allows health care facilities to add, update, and delete customized medication verification modules (eg, duplicate medication, drug-drug interaction, and maximum dosage). The duplicate medication checker was one of the verification modules used in this study. It consists of a set of logic and rules for detecting duplicate medications. Duplicate medication is primarily identified using the ATC system [
The CDS engine adapter is an interface between the CDS engine and a CPOE system that allows the CPOE system to initiate the duplicate medication checker. It performs mapping functions between the hospital’s drug codes, NHI drug codes, and ATC codes. When a physician wants to prescribe a drug for a patient, the CPOE system sends the drug details, including the patient’s identification, drug code, start date, and stop date, to the duplicate medication checker via the CDS engine adapter, which then converts the drug details into a form that can be interpreted by the duplicate medication checker. After checking for duplicate medication, the duplicate medication checker returns the result to the CPOE system via the CDS engine adopter.
The integrated computerized physician order entry (CPOE) system and clinical decision support (CDS) engine for detecting potential duplicate medications. NHI: National Health Insurance; VPN: virtual private network.
The CDS engine is different from the traditional CDSS coupled with CPOE. The CDS engine has a decoupled decision support module from the hard-coded rules in CPOE. The module provides a thematic decision rules design approach. Health care facilities are able to maintain several independent thematic CDS modules for different CDS applications. These independent configurable knowledge rule modules allow CPOE to invoke few configurations and decrease the code change of the original CPOE. The scalable and flexible nature of the framework facilitates health care facilities to integrate the CDS function into their existing CPOE system. The steps involved in the extension of the CDS engine rule module are as follows:
Defining the theme of the decision support module. In this study, we defined a duplicate medication checker to distinguish duplicate medications. The theme of the decision support module can be extended using a drool file [
Defining the input and output parameters and the decision support logics in the decision support module. Health care facilities must select the input parameters from the CPOE and local repository for the decision support logics, and those that are to be returned to the CPOE. The design of the decision support logics may be based on relevant clinical guidelines, regulations, protocols, or medication knowledge.
Retrieving the EHRs from the local repository. In our study, the EHRs were retrieved from PharmaCloud through the PharmaCloud adapter. In other scenarios, health care facilities could add other EHR adapters to retrieve different EHR sources.
Adding a Web service path to the CDS engine adapter. A health care facility can add a Web service URL for CPOE to invoke the added decision support module.
CPOE has an AJAX [
To ensure a certain level of safety in storing medical information, we adopted some information security assumptions for both the EHR repositories and CPOE, such as secure tunnel, access control, and privacy control protection. In the secure tunnel, as PharmaCloud is deployed in the NHI VPN environment, the CDS engine must access the PharmaCloud through the NHI VPN. In the access control, we must have both the physician’s Healthcare Certification Authority card and the patient’s health smart card simultaneously inserted into the card reader to verify that the physician has the authority to access the patient’s medication history. Finally, the patient must sign the PharmaCloud consent form before the CDS engine batch downloads their medication history; if not, the CDS engine would not retrieve the patient’s medication history.
Patients who wish to allow their physicians at a health care facility to access their medication history in the PharmaCloud must complete the PharmaCloud consent form and submit it to the health care facility. When a patient wants to visit a doctor, he or she makes an appointment and registers in advance by using the patient appointment system of the health facility. If the patient’s consent is in effect at the time of the visit, the CDS engine retrieves the patient’s medication history for the past 3 months from the PharmaCloud and stores it into the CDS engine local repository. To evaluate the impact of the CDS engine on an outpatient clinical encounter, a clinical encounter log iss created to collect information about the patient and physician, the start and end time of the clinical encounter, the drugs prescribed by the physician, and the physician’s responses to potential duplicate medication alerts, if any.
If the duplicate medication checker detects a potential duplicate medication (ie, the prescribed drug’s ATC level 4 code is the same as the one stored in the CDS engine local repository), it sends an alert to the CPOE system. The alert information, including drug name, ATC code, and start and stop dates, is then displayed on a pop-up screen (
The prescription workflow using the clinical decision support (CDS) engine for detection of potential duplicate medication.
A screenshot of a pop-up screen showing an alert message that appears when a potential duplicate medication is detected. The screen presents the information about the duplicate drug (upper panel), response options for reasons for prescribing the medication (middle), and action to take (lower panel).
The CDS engine has been integrated into a CPOE system of the hospital to support order entry processes, and this combined system has operated in four outpatient departments: medicine, surgery, gynecology-pediatrics, and “other” departments. The clinical encounter log was initiated to collect information about clinical encounters from April 1 to June 30, 2016. During this period, for each patient’s clinical encounter, the log collected the starting and ending time of the encounter, prescribed medication, and the physician’s response(s) to a potential duplicate medication alert, if any. The log could be used to analyze how the CDS engine affected the encounter time and to determine physicians’ responses to potential duplicate medication alerts in different outpatient departments.
To investigate clinical encounter time, we divided clinical encounters into two groups based on the clinical encounter log: “with CDS engine” and “without CDS engine.” Patients in the without CDS engine group were those who did not sign a PharmaCloud consent form; patients in the with CDS engine group were those who signed the PharmaCloud consent form. We also analyzed the characteristics of the consent rate, potential duplicate medication rate, and physicians’ response(s) to any potential duplicate medication alerts. We used the statistical software R version 3.3.1 [
Overall, there were 178,300 patient visits to the four outpatient departments during the 3-month period, as shown in
Analysis of clinical encounters information during the 3-month data collection period.
Clinical encounters | With CDSa engine (n=43,844) | ||
No medicine prescribed, n (%) | 12,230 (27.89) | 37,742 (28.07) | 49,972 (28.03) |
Medicine prescribed, n (%) | 31,614 (72.11) | 96,714 (71.93) | 128,328 (71.97) |
Potential duplicate medication, n | 4227 | — | |
No potential duplicate medication, n | 27,387 | — |
aCDS: clinical decision support.
Differences in clinical encounter time between with clinical decision support (CDS) engine and without CDS engine groups.
Departments | Without CDS engine | With CDS engine | |||||
n | Median time in minutes, (IQR) | n | Median time in minutes, (IQR) | ||||
Medicine | 49,310 | 3.7 (2.2-6.2) | 17,189 | 4.5 (2.6-7.4) | <.01 | ||
Surgery | 26,885 | 3.1 (1.5-5.8) | 9031 | 3.7 (1.8-7.0) | <.01 | ||
Gynecology-Pediatrics | 9129 | 4.5 (2.5-7.7) | 2209 | 4.6 (2.3-8.0) | .92 | ||
Other | 11,390 | 3.8 (2.2-6.4) | 3185 | 4.3 (2.4-7.2) | <.01 | ||
Total | 96,714 | 3.6 (2.0-6.3) | 31,614 | 4.3 (2.3-7.3) | <.01 |
Physicians’ responses to potential duplicate medications.
Department | Physician response, n (%) | ||||||
Cancela | Lost prescriptionb | Physician on leavec | Condition changed | Othere | Self-payf | Total | |
Medicine | 1049 (36.32) | 87 (3.01) | 91 (3.15) | 905 (31.34) | 528 (18.28) | 228 (7.89) | 2888 (100) |
Surgery | 603 (55.89) | 38 (3.52) | 9 (0.83) | 226 (20.95) | 155 (14.37) | 48 (4.45) | 1079 (100) |
Gynecology-Pediatrics | 88 (40.18) | 11 (5.02) | 0 (0) | 88 (40.18) | 16 (7.31) | 16 (7.31) | 219 (100) |
Other | 168 (48.00) | 5 (1.43) | 5 (1.43) | 82 (23.43) | 21 (6.00) | 69 (19.71) | 350 (100) |
Total | 1908 (42.06) | 141 (3.11) | 105 (2.31) | 1301 (28.68) | 720 (15.87) | 361 (7.96) | 4536 (100) |
aCancel: confirmed as a duplicate drug—cancel this drug.
2Lost prescription: the patient lost the prescription.
cPhysician on leave: the physician is going on leave, plan earlier patient follow-up.
dCondition change: the patient’s condition has changed—arrange an early follow-up.
eOther: none of the above reasons—arrange an early follow-up.
fSelf-pay: duplicate prescribing, but the patient wishes to pay at his or her own expense.
An alert was trigged by a drug in a prescription if it was detected as a potential duplicate medication. Among the 4227 potential duplicate medication prescriptions (
In
Prescriptions confirmed as duplicate medication prescriptions.
Canceled druga, n | CDSb engine prescriptionc, n | |||
Medicine | 2685 (63.52) | 1025 | 17,189 | 5.96 |
Surgery | 1019 (24.11) | 576 | 9031 | 6.38 |
Gynecology-Pediatrics | 215 (5.09) | 86 | 2209 | 3.89 |
Others | 308 (7.29) | 156 | 3185 | 4.90 |
Total | 4227 (100) | 1843 | 31,614 | 5.83 |
aThe prescription had at least one drug confirmed as a duplicate drug and the doctor canceled this drug.
bCDS: clinical decision support.
cThe prescription checked with the CDS engine.
In our study, we developed a CDS engine to access the PharmaCloud (a national medication repository) to retrieve the medication records of patients from the previous 3 months. As per Taiwan NHI policies, health care facilities are required to upload their patients’ prescriptions within 24 hours after a visit. Thus, the CDS engine can access a fairly complete and up-to-date medication history. A previous study [
Nowadays, medication safety is a top priority for both patients and health care providers. However, it requires additional cost. Under our CDS engine framework, clinical encounter time was slightly (0.7 min) longer than when a CPOE system was used alone (from 3.6 min to 4.3 min) despite the ability to enhance medication safety. However, as we adopt more advanced and faster communication and computer technology to build CDS engines, the increased time can be mitigated. Thus, while implementing the CDS engine, to guarantee the desired level of medication safety, we should carefully evaluate the adopted solutions to meet the time requirements in clinical practice. Although the CDS engine takes an additional time of 0.7 min, it is still more efficient than the previous methods used in Taiwan [
Knowledge-based CDS generally offers two categories: “stand-alone CDS” and “CDS coupled with CPOE” [
Moreover, as described in the Methods section (“Extension of Decision Support Function”), we can add EHR adapters to retrieve other EHR repositories not restricted in PharmaCloud. As increasing numbers of EHRs gradually become available, our CDS engine approach can rapidly meet the changing requirements of CDSS to provide more complete medical histories and ensure added safety. Other studies also indicated that the future adoption of CDS would ideally be modularized [
Electronic health records are generally recognized as key components of CDSSs [
Our study showed that 24.59% of patients signed the PharmaCloud consent form to allow their physicians to access their medication records. In our context, direct CDS engine users include authorized physicians, not patients. However, only after the patients sign the PharmaCloud consent form can the physicians access the patients’ medication histories in the PharmaCloud from their CPOE system. The lack of patient participation in the PharmaCloud system would increase the difficulty associated with the efficient implementation of protections against duplicate medication prescription across health care facilities. In Australia, My Health Record was originally adopted with opt-in consent; however, because the uptake rate remained low, two trial areas adopted opt-out consent until 2016 to increase the uptake rate. As a result, the uptake rates were obviously higher in these areas than in the non-trial areas [
The system proposed in this study has certain limitations. Firstly, the PharmaCloud batch mode requires patient consent to access his or her medication history prior to their hospital visit. In our approach, the PharmaCloud system provided only a batch download mode for the CDS engine to retrieve patient medication history, and the CDS engine local repository was updated once daily, usually at midnight. Therefore, it was not possible to use the CDS engine for checking prescriptions of walk-in patients. A previous study indicated that walk-in patients represent approximately 44% of total patients [
In this study, we developed a modularized CDS engine to access a national medication repository, the PharmaCloud, for detection of duplicate medication across health care facilities in Taiwan. Because of the modularized design, the CDS engine could easily extend functions for detection of ADR events when more and more EHR systems are adopted. Moreover, the CDS engine can retrieve more updated and completed patients’ medication histories in the PharmaCloud, so it can have better performance for detection of duplicate medication.
Although our CDS engine approach could enhance medication safety, it would make encounter time longer. Fortunately, this problem can be mitigated by careful evaluation of adopted solutions for implementation of the CDS engine.
Because the PharmaCloud system provided batch download mode only for the CDS engine to retrieve patients’ medication history, the CDS engine local repository could not be updated in a timely manner. Thus, the CDS engine might not be able to provide walk-in patients with protection from duplicate medication. To tackle this problem, we suggest PharmaCloud should consider the opt-out consent policy to increase the usability of the CDS engine to provide more comprehensive CDS support in health care facilities.
adverse drug reaction
Anatomical Therapeutic Chemical
clinical decision support
clinical decision support system
computerized physician order entry
electronic health record
National Health Insurance
National Health Insurance Administration
service-oriented architecture
virtual private network
This work was partially supported by the Industrial Technology Research Institute of Taiwan (ITRI) with Project Grant No F301AR9A10. The authors would like to express our appreciation to Alina, Kent Chen, and the colleagues of Information Management Department, Taipei Medical University Hospital, for their technical support.
None declared.