Potential Drug-Drug Interaction (PDDI) CDS IG : STU1 Ballot 2
1.0.0-ballot - STU Ballot
Potential Drug-Drug Interaction (PDDI) CDS IG : STU1 Ballot 2
1.0.0-ballot - STU Ballot
This page is part of the Potential Drug-Drug Interaction (PDDI) Clinical Decision Support (CDS) (FHIR IG) (v1.0.0-ballot: STU 1 Ballot 3) based on FHIR R4. . For a full list of available versions, see the Directory of published versions 
| Official URL: http://hl7.org/fhir/uv/pddi/ImplementationGuide/hl7.fhir.uv.pddi | Version: 1.0.0-ballot | |||
| Draft as of 2022-06-23 | Computable Name: PDDI_CDS | |||
Where possible, new and updated content will be highlighted with green text and background.
The following resolutions have been voted on by the members of the sponsoring work group HL7 International Clinical Decision Support.
Comments and their resolutions
Listed below are the resolved trackers for this version:
Status: Summary:(Jira Issue)
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 during computerized provider order entry 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 is focused on drug therapy ordering conducted with an inpatient or outpatient electronic health record. If the system can send medication orders present in the National Council for Prescription Drug Programs (NCPDP) e-prescribing medication history for outpatient drugs as FHIR resources to the CDS service then, these resources could be included in CDS logic. This implementation guide solely focuses on drug to drug interactions. It is true that vitamins, herbals, and food also have interactions with therapeutic drugs and cause adverse events. However, the representation of these entities with EHR systems is not as standardized as therapeutic drugs. Future versions of the implementation guide might add additional use cases and clarification on how to handle these entities.
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, NLM grant T15 LM007124, R15 LM012941, NCCIH grant U54 AT008909.
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 PDDI alerts more specifically relevant to a given patient at various points in the clinical workflow. 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 approach this IG suggests could be effective at reducing the number of alerts and increasing their relevance. For example, a recent study developed, validated, and tested 8 contextualized drug-drug interaction alert algorithms that used data from electronic health records data to fine-tune the alerts to a given patient. The interactions were chosen based on monthly override rates from a single large care facility. Testing on retrospective real-world data showed the potential for the eight algorithms to reduce alerts that interrupt clinician workflow by more than 50% from baseline.4
The burden of PDDI CDS governance falls to specific institutions, which may contribute to the broad discord of PDDI alerts among institutions.5,6 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.7
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 to a successful PDDI CDS 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 World 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 minimal information model.8,9 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.10 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. Note that the remote service would not a component of the EHR, would use API and web standards for communication, and could be a servlet container hosted within the organization’s data architecture / firewall or hosted offsite. HIPAA privacy and data protection rules would apply to all aspects of the interaction between the EHR and the CDS service.
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. Note that it might not be possible to develop CDS Logic to evaluate a candidate order at the “order-select” stage.’ In these cases, appropriately, there would be no ability for the EHR to subscribe to a service specific to the drug-drug interaction that triggers at order-select.
A third option that this implementation guide discusses is CDS at the time a clinician opens a patient-record (“patient-view”). Note that. although this event happens outside of computerized provider order entry, we included it as a scenario because are potentially good reasons to do PDDI CDS at patient-view including 1) the patient-view hook has broad adoption it might be the most appropriate place in the clinical workflow for shared decision-making this is an ideal time to bring up current potential interactions and perform risk calculations.
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 minimal information model for potential drug-drug interaction knowledge and evidence described in a W3C Community Interest Group Note.8,9 The IG use cases (Warfarin + non-steroidal anti-inflamatory drugs (NSAIDs) and Digoxin + Cyclosporine) show that the potential interactions often need to consider route and formulation. The minimal information model specifies contextual Information/modifying factors which these would fall under.
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 minimal information model for representing clinically actionable knowledge about PDDIs
Provides knowledge artifacts and related resources using the following HIT specifications:
| IG | Package | FHIR | Comment |
|---|---|---|---|
  Potential Drug-Drug Interaction (PDDI) CDS IG : STU1 Ballot 2 | hl7.fhir.uv.pddi#1.0.0-ballot | R4 | |
 HL7 Terminology (THO) | hl7.terminology.r4#5.0.0 | R4 | Automatically added as a dependency - all IGs depend on HL7 Terminology |
This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (hl7.fhir.uv.pddi.r4) and R4B (hl7.fhir.uv.pddi.r4b) are available.
There are no Global profiles defined
This publication includes IP covered under the following statements.
http://www.nlm.nih.gov/research/umls/rxnorm
IG © 2021+ HL7 Clinical Decision Support Workgroup. Package hl7.fhir.uv.pddi#1.0.0-ballot based on FHIR 4.0.1. Generated 2022-12-07
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change