This page is part of the Potential Drug-Drug Interaction (PDDI) Clinical Decision Support (CDS) (FHIR IG) (v0.2.0: STU 1 Ballot 2) based on FHIR R4. . For a full list of available versions, see the Directory of published versions
The primary intended audience includes individuals seeking guidance on how to implement drug-drug interaction clinical decision support using modern health information technology standards. This implementation guide is written with the intention of showing how potential drug-drug interaction (PDDI) alerts more specifically tailored to patient context could be presented through the electronic health record using modern standards. It is also written for a more general audience of individuals creating medication safety knowledge artifacts that they intend to disseminate to healthcare organizations.
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, University of Utah, RWTH Aachen University, Clemson University, the Open Source Electronic Health Alliance (OSEHRA), the University of Arizona, and Wolters Kluwer Health. It was funded in part by AHRQ grants: U18 HS027099, R01 LM011838, R21 HS023826 and R01 HS025984, and NLM grant T15 LM007124, R15 LM012941.
Clinical decision support has the potential to reduce adverse events 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 a high percentage (~90%) of PDDI alerts in computerized provider order entry (CPOE) systems are ignored.2,3 The reason for overriding PDDI alerts appears to be multi-factorial. The current widely-used approach of alerting based on simple pair-wise drug comparisons with no further consideration of patient context can lead to alerts with high recall but low precision. This implementation guide provides guidance on how to use information in the electronic health record to make alerts more specifically relevant to a given patient. Do we want to reword this sentence? Change prescibe to order-sign? Moreover, medication alerts are typically presented at 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 might help disperse the burden of optimizing alerts and maintaining drug knowledge.6
Patient-specific alerting is an overarching goal for 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. The unique combinations of risk factors possessed by each individual patient increases the complexity of decisions. Moreover, 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. 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 PDDI CDS by building on the Word Wide Web Consortium (W3C) Semantic Web in Health Care and Life Sciences Community Group project to make PDDI knowledge more comprehensive, standardized, and computable through a minimum information model.7 The W3C project provides non-ambiguous definitions for 10 core information items. It also provides 8 detailed best practice recommendations related to the 10 core information items. This implementation guide implements the W3C project’s recommendations using a service-based approach and the emerging health information technology standards FHIR, CDS Hooks, and CQL. PDDI CDS that follows the recommendations in this guide should be more specific, actionable, and sharable than current PDDI alerts. Also, the approach allows for an efficient system to document physician actions in conjunction with relevant patient-specific information. In this regard, CDS implementers 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 to make CDS artifacts computable and interoperable such as CDS Connect. This implementation guide uses CQL to represent executable PDDI CDS logic with the intention lowering the barrier for other implementers to use the codebase for their institution’s needs.
PDDIs are, to an extent, theoretical due to knowledge gaps in the literature. Thus, alert specificity and individualized information is limited by available knowledge. The goal of contextualizing or individualizing these alerts is not only to reduce the number of alerts by increasing specificity, but also to improve the clinical relevance of the information that is presented. In this respect, PDDI CDS may function as an educational tool to raise awareness of known factors that may mitigate or potentiate the risk associated with PDDIs. Gaps in the literature relating to contextual factors is a known issue of the domain and is a key limitation to this and other PDDI CDS systems. Moreover, with this limitation, unknown medication adherence, and data quality/availability – it is ultimately the clinician’s decision whether to proceed with potentially interacting drug orders.
An important requirement of CDS is that it provide clinically relevant information to the clinician at the right time. This implementation guide assumes that CDS is provided as a real-time remote service which the EHR (client) subscribes to at various points in the workflow of clinicians. The service requests clinical decision support based on the current patient context. The EHR client sends relevant contextual information as part of the request and receives clinically relevant suggestions describing potential actions to be taken. The CDS service must run efficiently to meet clinician expectations and not interrupt from the clinical workflow. Delays in presenting CDS information may lead to unsuccessful CDS adoption and clinician frustration.
To address workflow considerations, this implementation guide describes two complementary PDDI CDS scenarios: 1) CDS at the time that an ordering clinician selects a drug to add to an order (“order-select”), and 2) CDS at the time an ordering clinician signs a drug order (“order-sign”). It is possible for a stakeholder to implement both scenarios. In such case, the CDS service might trigger highly similar alerts at both order-select and order-sign. For example, if a clinician decides to ignore/over-ride a CDS suggestion presented at order-select, the CDS service might detect the same PDDI issue upon order-sign. This implementation guide defines a stateful approach where various resources returned from the order-select service are used to determine if an alert has been seen before while simultaneously allowing client EHRs to choose how to handle apparently repeat CDS suggestions.
In this guide, we assume that the service implementation complies with the CDS Hooks Specification. CDS-Hooks is a standard that has gained considerable interest among EHR vendors. It is a “hook” based pattern designed to provide a simple way to initiate requests for CDS, from any point in a clinical workflow. It specifies the basic actions of registering for CDS services, calling those services, and then receiving the CDS service response in form of simple structured messages called “cards” that provide appropriate information and suggested actions within the context of the EHR. In CDS Hooks, “Prefetch” queries are a key component that supports the CDS system performance. These queries assemble relevant data from the EHR prior to submitting a request to the CDS service. Depending on the patient and service, prefetch data may encompass a variety resources captured during various time periods, so it is crucial that implementors and clinicians refine prefetch template parameters to obtain only data that is clinically relevant. See this implementation guide’s discussion of the CDS Service specification applied to PDDI CDS for more information.
The Use Case section of this implementation guide describes a representative clinical PDDI example that is used for illustration throughout this implementation guide. PDDI CDS artifacts were created from the use case at a narrative, semi-structured, and fully executable level. The artifacts comply with the a minimum information model for potential drug-drug interaction knowledge and evidence described in a W3C Community Interest Group Note.7
The example CDS services shown in this implementation guide were written without the use of a specific authoring tool. The Clinical Decision Support Authoring Tool is a component of the CDS Connect project funded by the Agency for Healthcare Research and Quality (AHRQ). It is possible to use the authoring tool to develop PDDI CDS logic using CQL. Interested persons can access a test version of the tool with these features on GitHub. However, the authoring tool was not used to assist with PDDI CDS that uses CDS Hooks as specified in this implementation guide.
This implementation guide:
Describes a potential PDDI CDS use case (Warfarin + NSAIDs):
Provides implementation guidance for actionable PDDI alerts using sharable CDS artifacts that adhere to a minimum information model for representing clinically actionable knowedge about PDDIs
Provides knowledge artifacts and related resources using the following HIT specifications:
© HL7.org (HL7 Clinical Decision Support Workgroup). hl7.fhir.uv.pddi#0.2.0 based on FHIR v4.0.1. Generated 2020-08-10.
Links: Home
| QA Report | Search
| Version History
| 
| Propose a change