This page is part of the Potential Drug-Drug Interaction (PDDI) Clinical Decision Support (CDS) (FHIR IG) (v0.1.0: STU 1 Ballot 1) based on FHIR v3.5.0. . For a full list of available versions, see the Directory of published versions
This implementation guide is targeted at stakeholders who seek to increase the specificity and clinical relevance of potential drug-drug interaction (PDDI) alerts presented through the electronic health record. The approach is service-oriented and uses Web standards, a PDDI minimum information model, and emerging Health Information Technology (HIT) standards including CDS Hooks, Fast Health Interoperability Resources (FHIR), and Clinical Quality Language (CQL).
This implementation guide was developed by the Health Level 7 (HL7) Clinical Decision Support Work Group CDS WG in collaboration with the University of Pittsburgh Medical Center (UPMC), RWTH Aachen University, the Open Source Electronic Health Alliance (OSEHRA), the University of Arizona, and Wolters Kluwer Health. It was funded by AHRQ grants: R01 LM011838, R21 HS023826 and R01 HS025984, and NLM grant T15 LM007124.
This implementation guide:
Describes two exemplar potential PDDI CDS artifacts: Warfarin + NSAIDs and Digoxin + Cyclosporine.
Provides structured code for artifacts using the following HIT specifications:
Proposes and provides guidance to implement efficient PDDI CDS artifacts.
Note: This implementation guide describes two levels of PDDI CDS implementation. Level 1 Implementation enables stakeholders to start using PDDI CDS with benefits over conventional PDDI alerting systems. Level 2 Implementation extends and optimizes the PDDI CDS. The Getting Started tab specifies differences between the two levels of implementation.
Clinical decision support has the potential to reduce adverse outcomes associated with pharmacotherapy. Specifically, computerized PDDI checking at medication order entry is an efficient mechanism to bring conflicting therapies to clinicians’ attention. In the United States, Meaningful Use incentives have supported the widespread dissemination of PDDI checking;1 however, researchers have found that nearly all PDDI alerts in computerized provider order entry (CPOE) systems are ignored.2,3 The reason for overriding PDDI alerts appears to be multi-factorial. Simple pair-wise drug comparisons can lead to overly sensitive alerts and desensitized clinicians. Moreover, medication alerts are typically presented the end of the order entry task – after the decision has been made to prescribe a medication. A primary motivation for this implementation guide is to expand PDDI CDS to provide actionable information to clinicians earlier in the order entry process.
The burden of PDDI CDS governance falls to specific institutions, which may contribute to the broad discord of PDDI alerts among institutions.4,5 While the majority of health systems use third-party commercial knowledge bases that are integrated into the EHR alerting framework, each institution has the ability to customize the alert types and thresholds in relation to the knowledge base. A sharable service that coordinates drug knowledge and CDS alerts may reduce the variability and set a standard of care for PDDI CDS across institutions. Supporting this approach, both EHR vendors and drug knowledge vendors are beginning to adopt service-oriented data standards such as FHIR and CDS Hooks. In addition to standardizing care, a sharable service-based approach to PDDI CDS can help disperse the burden of optimizing alerts and maintaining drug knowledge.6
Personalized alerting is an overarching goal of PDDI CDS that has not been broadly achieved. The current state of high-sensitivity and low-specificity alerts is a known problem without a simple solution. The barriers are both theoretical and technological. Individual patients have unique risk factor combinations that increase the complexity of decisions, and alerts are often designed without due consideration for the clinician’s decision making process. Conventional PDDI CDS approaches alert on simple pair-wise drug combinations without considering other data that could be used to tailor CDS for the specific patient. In other words, the knowledge base and technical framework need further development to account for patient factors to reduce the number of alerts and improve alert specificity. This implementation guide advances toward improving alert specificity by building on the Word Wide Web Consortium (W3C) community group project to make PDDI knowledge more comprehensive, standardized, and computable through a minimum information model.7 The W3C project and resulting minimum information model support defining and presenting actionable PDDI information at the point of care. This implementation guide not only leverages knowledge and technologies to support presenting actionable PDDI recommendations, but also provides an efficient system to document these actions in conjunction with relevant patient-specific information. In this regard, implementors can track clinician responses for analyses that may lead to further refined PDDI CDS alerts.
Finally, clinical expertise is crucial to developing clinically relevant CDS. However, a barrier exists between expressing clinical knowledge and writing the actual code used by CDS systems. CQL is an HL7 standard that was developed as an authoring language that is both structured and human readable.8 Moreover, CQL is a foundational component of national efforts, such as CDS Connect in the United States, to make CDS artifacts computable and interoperable. This implementation guide applies CQL to PDDI CDS, which may lower the barrier for other implementors to use the codebase for their institution’s needs.
This implementation guide builds on the the W3C Community Group Note, “A Minimum Representation of Potential Drug-Drug Interaction Knowledge and Evidence - Technical and User-centered Foundation.” This Note provides a technical and user-centered foundation for a PDDI minimum information model. The overarching goal of this project was to support effective PDDI CDS. The principal contributions of the Note include:
definitions for the model’s core information items, examples of using these definitions to represent two PDDIs, and a set of additional PDDIs selected as case studies for future work using the information model;
clarification of model users, use cases, and specific information needs;
statement on the appropriate scope of knowledge representation for the information model;
potential applications of the minimum information model that could lead to improved patient safety.
This Community Group Note provides motivation and a detailed domain analysis for structuring PDDI knowledge with the minimum information model. The model elements include: