Potential Drug-Drug Interaction (PDDI) CDS IG : STU1 Ballot 2
1.0.0-ballot - STU Ballot International flag

Potential Drug-Drug Interaction (PDDI) CDS IG : STU1 Ballot 2, published by HL7 Clinical Decision Support Workgroup. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/PDDI-CDS/ and changes regularly. See the Directory of published versions

Implementation Guide for PDDI CDS (DRAFT)

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

Introduction

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)

  1. Applied: Typo: World (FHIR-29616)
  2. Applied: Grammar correction : The barriers to a successful PDDI CDS are both theoretical and technological (FHIR-29614)
  3. Applied: Incorrect use of dratOrders on order-sign (FHIR-29608)
  4. Applied: Typo: Digoxin (FHIR-29623)
  5. Applied: “Recommend not getting rid of ““prescribe.””” (FHIR-29613)
  6. Applied: “Throughout: correct ““decision making”” to ““decision-making””” (FHIR-29615)
  7. Applied: typo: knowledge - here and in 2.0.0 (FHIR-29618)
  8. Applied: Not convinced that a web service based decision support can do better than existing DDI solutions. (FHIR-29598)
  9. Applied: It is not clear what the additional context field is. (FHIR-29601)
  10. Applied: “Missing required ““cds-services”” path segment for CDS Hooks examples” (FHIR-29607)
  11. Applied: Remove and correct the referenced sentence. (FHIR-29627)
  12. Applied: The Homepage and most of the sections of the IG need proofreading. (FHIR-29611)
  13. Applied: Correct link to CDS Hooks feedfback service details (FHIR-29606)
  14. Applied: “Recommend that PDDI CDS IG address security and privacy concerns, that may arise due to a patient’s consent directive.” (FHIR-29626)
  15. Applied: CDS Discovery examples include wrong attribute (FHIR-29605)
  16. Applied: “Make the page structure consistent regarding ““Page Contents.””” (FHIR-29610)
  17. Applied: The discussion/presentation of Knowldege Artifacts is helpful (FHIR-29632)
  18. Applied: Fix CDS Hooks discovery url typo,dennispatterson (FHIR-29604)
  19. Applied: “Consider expanding the IG to include drug interactions with vitamins, herbs and food.” (FHIR-29596)
  20. Applied: Practicing clinicians using the EHR must be consulted re: any configuration decisions made related to the CDS service and what alerts to present. (FHIR-29622)
  21. Applied: The emission of the coded response would be useful for clinicians reviewing the specificaiton to see. (FHIR-29630)
  22. Applied: This section provides a good overview with the 2 use cases provided for implementers. (FHIR-29628)
  23. Applied: The basic implementation is a repetition of the CDS Hooks standard. (FHIR-29600)
  24. Applied: Clarify whether these have NCPDP SCRIPT functions in outpatient e-prescribing world? (FHIR-29617)
  25. Applied: “IG needs to include dosage, route are required for CDS hook.” (FHIR-29633)
  26. Applied: Suggest only one alert at the point of ordering the drug unless the orderer is different than the order signer. (FHIR-29597)
  27. Applied: Required coordiation extensions should be included within PDDI implementation guide (FHIR-29609)
  28. Applied: “When using acronyms, specify meaning on first use or in a glossary.” (FHIR-29629)
  29. Applied: Summary of the Terminology section and list of value sets is very helpful for implementers. (FHIR-29631)
  30. Applied: Disagree with configuration to not address certain drugs - this might be an added risk. (FHIR-29621)
  31. Applied: The scope of this document related to inpatient drug orders vs. outpatient (retail) prescription drugs should be clarified. (FHIR-29612)
  32. Applied: Please clarify: how does outpatient e-prescribing via NCPDP SCRIPT fit in here? (FHIR-29619)
  33. Applied: Is it possible to provide the CDS information at an intermediate step between product selection and signing the order? (FHIR-29620)
  34. Applied: “In Figure 10, note that an order selection dropdown list may or may not include the route; therefore, the node that evaluates whether or not the selected order is topical diclofenac may or may not be able to be evaluated.” (FHIR-28511)
  35. Applied: Please change MUST to SHOULD in the following sentence: “If the CDS rule execution engine does not receive prefetch data in the request it MUST query the FHIR server via network call.” (FHIR-28508)
  36. Applied: Not always possible to evaluate an order at order-select stage (FHIR-28514)
  37. Applied: Card Action Example seems backwards (FHIR-28428)
  38. Applied: Question about order-select prefetch content (FHIR-28429)
  39. Applied: Redundancy in Figures 10 and 11 (FHIR-28512)
  40. Applied: “The link to the description of “configuration-items” works, but no information about “configuration-items” is provided at the destination web page (the CDS Hooks specification).” (FHIR-28510)
  41. Applied: “Consider removing this sentence: “It is RECOMMENDED that the rule engine be able to execute CDS rules written in CQL and represented as a FHIR Library resource, either directly or compiled to HL7 Expression Logical Model.” ” (FHIR-28509)
  42. Applied: resources named without text formatting (FHIR-18074)
  43. Applied: Fix navigation,smrobertson (FHIR-18056)
  44. Applied: PDDI CarePlan - bad link - PDDI #9 (FHIR-18805)
  45. Applied: Fix references (FHIR-18057)
  46. Applied: Wording correction (FHIR-18073)
  47. Applied: All of the Resource links point to the Documentation page. - PDDI #10 (FHIR-18806)
  48. Applied: Making conformance criteria more visible (FHIR-18078)
  49. Applied: DetectedIssue in CDS service response - PDDI #1 (FHIR-18804)
  50. Applied: Editorial fix (FHIR-18072)
  51. Applied: Bad links - PDDI #11 (FHIR-18807)
  52. Applied: section 6 Documentation needs to be expanded (FHIR-18079)

Intended Audiences

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.

Collaborators and Funding

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.

Context

Rationale

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.

Assumptions

Clinical

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.

Technical

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.

Scope

This implementation guide:

  1. Describes a potential PDDI CDS use case (Warfarin + NSAIDs):

    • CDS at the time that an ordering clinician selects a drug to add to an order (“order-select”), and
    • CDS at the time an ordering clinician signs a drug order (“order-sign”)

  2. 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

  3. Provides knowledge artifacts and related resources using the following HIT specifications:

References

  1. Centers for Medicare and Medicated Services. Eligible Professional Meaningful Use Core Measures Measure 2 of 14. 2013 April (cited 2018 August). Available from: https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/2013DefinitionEP_2_Drug_Interaction_Checks.pdf.
  2. Bryant AD, Fletcher GS, Payne TH. Drug Interaction Alert Override Rates in the Meaningful Use Era: No Evidence of Progress. Applied Clinical Informatics. 2014;5(3):802-813. doi:10.4338/ACI-2013-12-RA-0103.
  3. Van der Sijs H, Aarts J, Vulto A, Berg M. Overriding of Drug Safety Alerts in Computerized Physician Order Entry. Journal of the American Medical Informatics Association : JAMIA. 2006;13(2):138-147. doi:10.1197/jamia.M1809.
  4. Chou, E., Boyce, RD., Balkan, B., Rosko, S., Subbian, V., Romero, A., Hansten, P., Horn, J., Gephart, S., Malone, DC. Designing and Evaluating Contextualized Drug-Drug Interaction Algorithms. Accepted to JAMIA Open 02/26/2021. JAMIO-2020-0010.R3. PubMed ID: in process. PubMedCentral ID: In process.
  5. McEvoy DS, Sittig DF, Hickman T-T, et al. Variation in high-priority drug-drug interaction alerts across institutions and electronic health records. Journal of the American Medical Informatics Association : JAMIA. 2017;24(2):331-338. doi:10.1093/jamia/ocw114.and 5.
  6. Fung KW, Kapusnik-Uner J, Cunningham J, Higby-Baker S, Bodenreider O. Comparison of three commercial knowledge bases for detection of drug-drug interactions in clinical decision support. Journal of the American Medical Informatics Association : JAMIA. 2017;24(4):806-812. doi:10.1093/jamia/ocx010.
  7. Tilson H, Hines LE, McEvoy G, et al. Recommendations for Selecting Drug-Drug Interactions for Clinical Decision Support. American journal of health-system pharmacy : AJHP : official journal of the American Society of Health-System Pharmacists. 2016;73(8):576-585. doi:10.2146/ajhp150565.
  8. World Wide Web Consortium (W3C) Semantic Web in Health Care and Life Sciences Community Group. A Minimum Representation of Potential Drug-Drug Interaction Knowledge and Evidence - Technical and User-centered Foundation. May 8, 2019. https://w3id.org/hclscg/pddi.
  9. Hochheiser, H., Jing, Xia., Garcia, E., Ayvaz, S., Sahay, R., Dumontier, M., Banda, JM., Beyan, O., Brochhausen, M., Draper, E., Habiel, S., Hassanzadeh, O., Herrero-Zazo, M., Hocum, B., Horn, J., Lebaron, B., Malone, DC., Nytrø, Ø., Reese, T., Romagnoli, K., Schneider, J., Zhang, LY, Boyce, RD. A minimal information model for potential drug-drug interactions. Frontiers in Pharmacology. Research Topic: Drug Interactions in the Real World. 2020. vol. 11. 10.3389/fphar.2020.608068. PubMed ID: in process. PubMedCentral ID: In process.
  10. Health Level Seven International. HL7 Cross-Paradigm Specification: Clinical Quality Language, Release 1. 2017 May (cited 2018 August). Available from: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=400.

Dependencies

IGPackageFHIRComment
.. Potential Drug-Drug Interaction (PDDI) CDS IG : STU1 Ballot 2hl7.fhir.uv.pddi#1.0.0-ballotR4
... HL7 Terminology (THO)hl7.terminology.r4#5.3.0R4Automatically added as a dependency - all IGs depend on HL7 Terminology
... FHIR Extensions Packhl7.fhir.uv.extensions.r4#1.0.0R4Automatically added as a dependency - all IGs depend on the HL7 Extension Pack

Package hl7.fhir.uv.extensions.r4#1.0.0

This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sun, Mar 26, 2023 08:46+1100+11:00)

Cross Version Analysis

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.

Global Profiles

There are no Global profiles defined

IP Statements

This publication includes IP covered under the following statements.

http://www.nlm.nih.gov/research/umls/rxnorm