Potential Drug-Drug Interaction (PDDI) CDS IG : STU Ballot 1
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 
The words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, AND OPTIONAL are used as defined “Key words for use in RFCs to Indicate Requirement Levels”. S. Bradner. IETF. March 1997. Best Current Practice.
PDDI CDS knowledge artifacts. It is RECOMMENDED that the knowledge artifacts adhere to the Minimum Representation of Potential Drug-Drug Interaction Knowledge and Evidence proposed by the W3C Semantic Web in Health Care and Life Sciences Community Group
A CDS rule execution engine. It is RECOMMENDED that it 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.
A web service that processes CDS requests using a CDS rule execution engine. The service MUST be able to process CDS Hooks requests and return CDS Hooks Card responses.
FHIR server(s) for terminology and patient data
Local (preferred)
The Clinical Decision Support Authoring Tool is a component of the CDS Connect project funded by the Agency for Healthcare Research and Quality (AHRQ). The Documentation section of this implementation guide describes the PDDI CDS artifact knowledge at a narrative and semi-structured level. Although currently not tested, it should be possible to use the authoring tool to develop CQL from similar semi-structured knowledge representations.
To invoke the PDDI CDS service, the EHR needs to send a CDS Hooks request at a pre-specified step the workflow process. The CDS service then parses and processes the request to determine if the prescribed medication conflicts with a medication the patient is presumably taking. If this condition is satisfied, the CDS service provides individualized information based on the PDDI knowledge base.
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 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 interacting orders.
The goal of CDS is to bring clinically relevant information to the clinician at the right time; therefore, CDS performance is required to meet clinician expectations. Delays in presenting information may lead to unsuccessful CDS adoption and clinician frustration. While the implementor remains in control of fulfilling prefetch queries, this is a key component of the CDS Hooks standard and supports the CDS system performance. 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. The EHR may combine several methods to satisfy prefetch templates. For more information see the Documentation section, Prefetch Role.
Each implementation MAY employ a slightly different approach to ensure successful integration of the CDS system. Here are several general aspects to assess:
A technical framework for the EHR to interact with the CDS service by
creating and sending CDS Hooks requests
capturing and presenting CDS Hooks responses
capturing, processing, modifying, and storing a DetectedIssue resource
Terminology mapping (e.g., RxNorm, LOINC)
Building FHIR resources
SMART authentication and FHIR server requests
Two exemplar PDDI CDS artifacts are available in this implementation guide (i.e., Warfarin + NSAIDs and Digoxin + Cyclosporine). The status of the exemplar PDDI knowledge artifacts for Level 1 Implementation is structured, and semi-structured for the Level 2 Implementation.
Note: The PDDIs were chosen for level of complexity, decision points, and contextual factors. These examples serve as reference for the methodology and procedures that may be adopted when developing and implementing PDDI CDS using CQL, FHIR, and CDS Hooks.
The primary difference between Level 1 and Level 2 Implementations is the addition of a second hook during the order entry task. From a clinical and technical perspective, this sets the Level 2 Implementation apart from most conventional CDS systems that trigger PDDI CDS at the time of order signing. In Level 2, PDDI CDS is moved up to earlier in the order entry workflow, providing clinicians with actionable information in the middle of their decision making process. We think that providing information at this stage presents less of a cognitive burden on the clinician and will lead to more effective PDDI CDS. In order for PDDI CDS to be both sensitive and specific, different contextual factors are sent to the CDS service depending order entry workflow step the clinician is engaged in. At the time of medication selection, a medication-select CDS Hook sends medication resources to the CDS service. Later, at the time of order signing, a medication-prescribe CDS Hook sends other contextual resources specific to a PDDI identified from processing medication-select. This might include retrospective patient conditions, lab measurements, and other information. One potential advantage of this approach is a reduction the amount of information needed to provide actionable PDDI information to the clinician. The approach might also limit the amount of information the EHR has to provide for an order entry task. For example, if a clinician starts an NSAID order for a patient that was taking warfarin and decides to discontinue the order based on the presented cards, the clinician only needs to read and process medication factors, and the EHR would not display additional patient resources such as age and history of upper gastrointestinal bleed. In Level 2, the DetectedIssue resource stores crucial information on clinician action that facilitates monitoring PDDIs and improving actionable suggestions. Moreover, by creating a DetectedIssue resource that contains clinician responses. This gives control to the clinician on what, if any, additional patient-specific information is presented. For example, if a clinician decides to continue with the NSAID prescription but adds a proton pump inhibitor (risk mitigating action), the CDS Service for medication-prescribe would adjust the indicator from “hard-stop” (interruptive) to “warning” (passive). Table 1 provides a summary of the specification and feature differences between the levels of implementation.
| Base Specifications | Level-1 | Level-2 | |
|---|---|---|---|
| Specifications | |||
medication-prescribe 1.0 |
X | X | |
medication-prescribe 1.1 |
X | ||
medication-select 1.0 |
X | ||
DetectedIssue resource |
X | X | X |
| Features | |||
DetectedIssue potentiation element |
X | X | |
Card response extension for DetectedIssue |
X | X | |
| Clinician action documentation | X | X | |
| Sequential clinician action documentation | X | ||
| Clinician response alert filtering | X | ||
| Minimized alert presentation | X | ||
| Minimized data query | X | ||
| Scalable framework for contextual factors | X |
This section provides an overview of the processes and components of the PDDI CDS. It is delineated by Level 1 and Level 2 Implementation sections. The Level 1 Implementation describes the technology specifications, and what structured code is available in this implementation guide. The Level 2 Implementation is a target for future iterations to optimize the CDS artifacts. Details regarding the knowledge artifacts and decision points for the individual artifacts can be found in the Documentation section.
Prior to a hook trigger and subsequent processes, the EHR MUST initiate a CDS Discovery (Figure 1). CDS Discovery is to identify CDS services and obtain associated prefetch templates. A prefetch template is a dictionary of read and search requests for needed resources of a particular service. The PDDI CDS service MAY provide a prefetch template for each service, and the EHR SHOULD populate prefetch templates with relevant patient data for the anticipated CDS Hook request.
Example 1: EHR request for CDS Discovery
GET http://FHIR.org/PDDI-CDS
Example 2: CDS Discovery response
{
"services": [
{
"hook": "medication-prescribe",
"title": "PDDI CDS Service",
"description": "CDS Service for drug-drug interactions",
"id": "PDDI-CDS",
"prefetch": {
"medications_stated": "MedicationStatement?patient//query parameters"
"medications_dispensed" : "MedicationDispense?patient//query parameters"
"medications_administered" : "MedicationAdminister?patient//query parameters"
"medications_prescribed" : "MedicationRequest?patient//query parameters"
"age" : "Request?patient//query parameters"
"UGIB" : "Condition?patient//query parameters"
}
The Level 1 Implementation uses the medication-prescribe 1.0 specification but does not declare the triggering event. Since EHR platforms may have different discrete steps in the order entry process, the implementor decides what action (e.g., selecting a medication product, accepting order completion) triggers the CDS Hooks request.
Specific CDS Hooks and FHIR standards modifications REQUIRED for Level 1 Implementation:
A CDS Hooks Card extension so that a DetectedIssue resource can be included in a Card response
A DetectedIssue resource extension to add the potentiation element
The process for a unique instance of PDDI CDS begins with the user triggering a CDS Hooks request (i.e., medication-prescribe) and ends with the user’s action in response to the Card response suggestion(s) (Figure 2). The parse and pre-process subprocess is to determine if a FHIR server query needed. The Clinical Reasoning module evaluates the complete request and creates information to send back the the EHR. The event subprocesses may occur in response to a specific instance (i.e., SMART authorization and FHIR access) or asynchronous of the specific instance (i.e., CDS Discovery).
The PDDI CDS artifacts use the HL7 CDS Hooks specification 1.0. The CDS Hooks standard defines the data structure to facilitate communication between the EHR and the CDS service through a RESTful API request and response. This allows patient data to be sent and received by the EHR at intervals that better align with clinical workflows – further leveraging FHIR and SMART applications at the point of care. CDS Hooks instances include CDS Discovery, EHR requests and CDS service response. The context and prefetch are two key elements of the CDS Hook request that contain patient information. The context element contains data that is task and hook-specific. The prefetch element contains patient-specific information that is relevant to the context data and the invoked CDS service. The CDS Hooks response is a set of Cards. The Cards contain general information, suggested actions, and display indicators in a structured format for the EHR to process and display. The CDS Discovery of the CDS Hooks specification delineates information that the CDS service is to provide to the EHR.
Note: The HL7 specification for decision support does not require that the CDS service process CDS Hooks. This implementation guide requires their use because CDS Hooks should provide simplicity and specific orientation for CPOE workflow integration.
The EHR MUST call the PDDI CDS service by sending an HTTP POST containing JSON to the service endpoint (e.g.,http://FHIR.org/PDDI-CDS/warfarin-nsaids-cds). The JSON (CDS Hooks request) MUST contain specified information for the hook that was triggered, FHIR server, user, context, and prefetch.
The context element of a CDS Hooks request contains contextual data for the current task and is specified below. For example, the medication-prescribe hook specifies the context MUST include the medication product (i.e., medication element of the MedicationRequest resource) of the order in process.
medication-prescribe 1.0.
| Field | Optionality | Prefetch Token | Type | Description |
|---|---|---|---|---|
patientId |
REQUIRED | Yes | string | Describe the context value |
encounterId |
OPTIONAL | Yes | string | Describe the context value |
medication |
REQUIRED | No | object | STU3 - FHIR MedicationRequest resource |
The prefetch element contains patient data that is provided by the EHR upon submission of the CDS Hook to the CDS service. The CDS service MUST provide the EHR with a prefetch template at the time of service discovery. The prefetch element MAY specify patient data other than medications for the purpose of individualizing the CDS logic and response. The prefetch query MUST be designed to obtain data for the patient indicated by the context patientID. The CDS service SHOULD then compare the context medication to the patient’s current medications in the prefetch element.
Note: For simplicity, this implementation guide uses the term “prefetch” regardless of whether the EHR supplies the data prior to a hook request or if it is queried by the CDS service as a post-hoc FHIR server request.
A Bundle is a FHIR resource that groups resources into a single instance, which is ideal for messaging with CDS Hooks, storing a collection of resources obtained on CDS Discovery, and providing flexibility in using the collections as a persistent instance. PDDI CDS implementors MUST use the bundle resource for certain context elements and all prefetch resources. For each prefetch template query, a Bundle MUST be created to group the resources. A prefetch element MAY contain several Bundle resources with several other resources grouped within.
This section describes the components and processes of the Clinical Reasoning module used for the PDDI CDS artifacts. The Clinical Reasoning module provides resources and operations to enable sharing and evaluation of clinical knowledge artifacts. For the PDDI CDS artifacts this encompasses the PlanDefinition, CarePlan, RequestGroup, DetectedIssue, and CQL libraries.
Note: While resources and CQL libraries are specified for this implementation guide, these are not required for PDDI CDS functionality. The
PlanDefinition, however, is RECOMMENDED to create sharable PDDI knowledge artifacts.
In the FHIR resource workflow, the PlanDefinition resource is categorized as a definition. Resources in this category define an action that can occur with a patient. There are three main elements of the PlanDefinition that are used for the PDDI CDS instances. These elements include TriggerDefinition, Condition, DynamicValue, and Action.
The TriggerDefinition uses the Name Event, which allows triggering of an event opposed to a scheduled or fixed event. The TriggerDefinition for a PlanDefinition written for PDDI CDS MUST be based on one of the CDS Hooks requests medication-prescribe and medication-select.
"triggerDefinition": {
"type": "named-event",
"eventName": "medication-prescribe"
"triggerDefinition": {
"type": "named-event",
"eventName": "medication-select"
The condition element is used to determine whether or not the CDS logic is to be applied and the language that the logic is written in. If the condition is satisfied (i.e., true or false), an action(s) is initiated.
"condition": [
{
"kind": "applicability",
"language": "text/cql",
"expression": "Inclusion Criteria"
The Action element provides the specific action(s) and associated information. Only one action can be taken for each group, which is reflected by the Card actions where the user can only select one action per suggestion.
"condition": [
{
"kind": "applicability",
"language": "text/cql",
"expression": "Inclusion Criteria"
}
],
"action": [
{
"title": "Increased risk of bleeding",
"description": "Potential Drug-Drug Interaction between warfarin (product) and NSAID (product)",
"dynamicValue": [
{
"path": "action.title",
"expression": "Get Base Summary"
},
{
"path": "action.description",
"expression": "Get Base Detail"
},
{
"path": "activity.extension",
"expression": "Get Base Indicator"
}
],
"action": [
snipped for brevity
The DynamicValue enables customization of the statically defined resources. Since each decision block for PDDIs have one or more individualized information components, integrating patient-specific and product-specific data into Card elements is facilitated by the DynamicValue element.
"action": [
{
"label": "Assess risk and take action if necessary.",
"dynamicValue": [
{
"path": "action.label",
"expression": "Get Card 2 Label"
The FHIR resource workflow categorizes the CarePlan and RequestGroup resources as requests, thereby expressing the intention for something to occur. The CDS service creates a CarePlan that references a RequestGroup for each CDS Hook response Card, and a single DetectedIssue resource for the identified PDDI. As an example, in this implementation guide, the Warfarin + NSAID artifact creates four response cards, each containing minimum information model elements and associated actions. The CarePlan references four RequestGroup resources under the the activity element. The RequestGroup action element provides the suggestions and actions in the response card. The CarePlan and RequestGroup resources are subsequently transformed into a CDS Hooks Card response and sent to the EHR along with the DetectedIssue resource.
The DetectedIssue resource is needed to document clinician actions associated with identified PDDIs and increase the specificity of alerts; thus, it is created by all PDDI CDS services. Level 1 and Level 2 Implementations MUST have EHR functionality to receive, process, modify, and store a DetectedIssue resource created by a PDDI CDS service(s). Use of the DetectedIssue resource with PDDI CDS requires an extension for the potentiating element. The potentiating element is analogous but antagonistic to the mitigating element that currently exists. These elements refer to relevant actions that have occurred (e.g., initiating another medication, substituting a medication order, or discontinuing the current order). For example, substituting naproxen for acetaminophen when a Warfarin-NSAID interaction is detected would be documented as a mitigating action. Conversely, if the same patient was currently taking prednisone, it would be documented as a potentiating action.
Example 3: DetectedIssue Elements
{
"resourceType" : "DetectedIssue",
"status" : "preliminary"
"implicated" : [{ Reference(Any) }], e.g., Interacting drugs
"mitigation" : [{ e.g., Step taken to address and patient risk mitigating factors
"action" : { CodeableConcept }, e.g., Discontinued interacting drug
}]
"potentiating" : [{ e.g., overriden suggested actions and patient risk potentiating factors
"action" : { CodeableConcept}, e.g., Overrode discontinuing interacting drug
snipped for brevity
It is RECOMMENDED that a CDS rule execution engine for PDDI CDS be able to execute CDS rules written in CQL. CQL was developed by HL7 for clinical experts to express knowledge in an author-friendly and human-readable but computable language.
All artifact logic using CQL are wrapped in a container called a library. There is a set of declarations documented in the CQL Specification that need to be defined to provide information about the library. Those declarations are Library, Data Models, Libraries, Terminology, Parameters, Context and Statements.
The library declaration defines the library name used as an identifier for other CQL libraries to reference. The version is an optional declaration.
library Warfarin_NSAIDs_CDS version '1.0'
Data models define the structures that can be used within retrieve expressions in the library.
using FHIR version '3.0.0'
For the PDDI CDS artifacts, FHIR model, version 3.0.0 is used as the primary data model within the library. The data model supports all FHIR STU3 resources including MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense, Observation, and Condition.
Statements defined in specific libraries can be reused in other libraries as a reference by a locally assigned name.
include PDDICDS_Common version '1.0' called Common
As an example below, statements defined in the PDDICDS_Common library, version 1.0, can now be referenced using the assigned name of Common.
define "NSAID Prescription":
ContextPrescriptions P
where Common.ToCode(P.medication.coding[0]) in "NSAIDs"
A value set declaration specifies a local identifier that represents a value set and can be used anywhere within the library.
valueset "Warfarins": 'http://hl7.org/fhir/uv/pddi/ValueSet/valueset-warfarin'
This definition establishes the local identifier Warfarins as a reference to the external identifier for the value set, an uniform resource identifier (URI) in this case is http://hl7.org/fhir/uv/pddi/ValueSet/valueset-warfarin. The external identifier should be an ID or a uniform resource identifier (URI).
This valueset definition can then be used within the library wherever a valueset can be used:
define "Warfarin Rx":
[MedicationRequest: "Warfarins"] MR
where MR.authoredOn.value in Interval[Today() - 100 days, null]
The above statement collects all MedicationRequest resources with a code in the Warfarins value set and the authored date within 100-day look-back period.
For the PDDI CDS value sets, refer to Terminology page for the list of value sets used by this implementation.
The parameters defined in a library MAY be referenced by name in any expression within the library.
parameter ContextPrescriptions List<MedicationRequest>
The context element of CDS Hook request contains the MedicationRequest resources specified in medications element as described in the example below. The data is parsed and assigned to the ContextPrescriptions parameter defined in the library.
"context": {
...
"medications": {
"resourceType": "Bundle",
"entry": [
{
"resource": {
... // FHIR MedicationRequest
}
}
]
}
}
}
This parameter definition can now be referenced anywhere within the CQL library:
define "NSAID Prescription":
ContextPrescriptions P
where Common.ToCode(P.medication.coding[0]) in "NSAIDs"
The context declaration defines the overall context for statements within the library.
context Patient
The context Patient declaration to restrict the information that will be returned from a retrieve of a single patient.
Define statements describing named expressions that can be referenced either from other expressions within the same library or by containing decision support artifacts.
define "GI Bleeds Condition":
Last(
[Condition: "History of GI Bleeds"] C
sort by assertedDate.value
)
This example defines the GI Bleeds Condition statement, which retrieves the most recent condition with a code in the History of GI Bleeds value set.
The Library resource contains the CQL library in base64 format. As an example below, the CQL library is encoded to base64 format and stored by using the Library FHIR resource.
In Library resource, the relatedArtifact element defines the dependent relationship between libraries. For example, warfarin-nsaids-cds library references the PDDICDS_Common library and that relationship is described in the relatedArtifact element.
{
"resource": {
"resourceType": "Library",
"id": "warfarin-nsaids-cds",
...
"relatedArtifact": [
{
"type": "depends-on",
"resource": {
"reference": "Library/PDDICDSCommon"
}
}
],
"content": [
{
"contentType": "application/elm+xml",
"data": "..." // CQL base64 logic content
}
]
}
}
When the Clinical Reasoning module processes the data, the library resource is loaded from local FHIR server and then the logic content in base64 format is decoded. If the content is in CQL format, it is tranlated into ELM XML format which is a machine-readable canonical representation.
For the best performance, the CQL logic should be translated into ELM XML format before being stored in the Library resource. This will enable the Clinical Reasoning module to execute the CQL logic without performing the translation.
In PlanDefinition resource, the library element defines the reference to the logic used by the PlanDefinition. An example for warfarin-nsaids-cds PlanDefinition resource is the reference to Library/warfarin-nsaids-cds Library resource.
"library": [
{
"reference": "Library/warfarin-nsaids-cds"
}
],
This library contains the logic used by the PlanDefinition to establish the condition, and to dynamically construct the guidance so that it reflects the data for the current patient.
As described in the condition element of the PlanDefinition section, the Clinical Reasoning module will load the statement in the condition element defined in the CQL library. Then the statement will be evaluated by the CQL engine. For example, the Inclusion Criteria statement in the library below will be loaded and evaluated to determine whether or not the condition is satisfied.
define "Inclusion Criteria":
if "Is context medication topical diclofenac"
then "Is warfarin in prefetch"
else (
"Is context medication systemic NSAID"
and "Is warfarin in prefetch"
)
define "Is context medication topical diclofenac":
exists ("Topical Diclofenac Prescription")
define "Topical Diclofenac Prescription":
ContextPrescriptions P
where Common.ToCode(P.medication.coding[0]) in "Topical Diclofenac"
define "Is warfarin in prefetch":
exists ("Warfarin Rx")
define "Warfarin Rx":
[MedicationRequest: "Warfarins"] MR
where MR.authoredOn.value in Interval[Today() - 100 days, null]
define "Is context medication systemic NSAID":
exists ("NSAID Prescription")
define "NSAID Prescription":
ContextPrescriptions P
where Common.ToCode(P.medication.coding[0]) in "NSAIDs"
Similar to condition element, dynamicValue element within the action element allows to customize the card content depending on the logic defined in the library. As an example, the Get Base Summary statement below specified in dynamicValue element will be evaluated, and the dynamic content containing medication names will be returned.
define "Get Base Summary":
'Potential Drug-Drug Interaction between warfarin ('
+ Common.GetMedicationNames("Warfarin Rx")
+ ') and NSAID ('
+ Common.GetMedicationNames("NSAID Prescription")
+ ').'
define "Get Base Detail":
'Increased risk of bleeding.'
define "Get Base Indicator":
if "Is context medication topical diclofenac"
then 'info'
else 'warning'
A FHIR server request by the CDS service is necessary in the event the request prefetch element is empty. While the prefetch element is OPTIONAL, it MUST NOT be partially fulfilled. The post-hoc FHIR server query is performed at the parse and pre-process phase shown in Figure 3. To accomplish a FHIR server request, the server URL and the OAuth authorization token (i.e. fhirServer, fhirAuthorization) MUST be provided in the CDS Hooks request.
The CDS service response is a Card array. Each Card has specified attributes that map to the core elements of the minimum information model (e.g.,summary = Drugs Involved). Each Card has a suggestions array and each suggestion has an action array. The Card indicator element dictates how the EHR presents the alert (e.g., indicator = “hard-stop” could be a modal alert).
Example 4: CDS Hooks Response
{
"cards": [
{
"summary": "Potential drug-drug interaction between naproxen 500mg tablet and warfarin 5mg tablet",
"indicator": "hard-stop",
"detail": "Non-steroidal anti-inflammatory drugs (NSAIDs) have antiplatelet effects which increase the bleeding risk when combined with oral anticoagulants such as warfarin.",
"source": {
"label": "Potential Drug-Drug Interaction CDS",
"suggestions": [
{
"label": "Assess risk and take action if necessary",
"actions": [
{
"type": "create",
"description": "If the NSAID is being used as an analgesic or antipyretic, it would be prudent to use an alternative such as acetaminophen.",
"resource": {
"APAP-order": "MedicationRequest"
}
}
]
}
]
}
},
{
"summary": "Patient is taking omeprazole 20mg daily",
"indicator": "info",
"detail": "Proton pump inhibitors and misoprostol may reduce the risk of UGIB in patients receiving NSAIDs and warfarin.",
"source": {
"label": "Potential Drug-Drug Interaction CDS"
}
snipped for brevity
Card Display Example
The Level 2 Implementation is a proposed target to optimize PDDI CDS artifacts. It builds on the Level 1 Implementation; however, implementors MUST select either Level 1 or 2 Implementation and not both. This section does not provide a comprehensive overview of the implementation but highlights deviations from the Level 1 Implementation above.
Differences between the Level 1 and Level 2 Implementations include:
Defining two CDS Hooks triggers in CPOE workflow (i.e., medication-select and medication-prescribe)
Creating a medication-select specification
Modify medication-prescribe specification
Creating separate but coordinated Medication Select and Medication Prescribe Services
Note: The Level 2 Implementation requires two separate, but coordinated, services for standards’ precision, logic flexibility, and to avoid the need for CDS service state.
Different contextual factors are available and needed at different times during the medication order process (Figure 4). To align clinicians’ information needs with PDDI information, the Level 2 Implementation defines two separate hook trigger events in the medication order workflow:
Selecting a drug product to include in medication order (medication-select)
Accepting or signing a single medication order (medication-prescribe)
Coordinating the Medication Select Service with the Medication Prescribe Service is a key aspect of the Level 2 Implementation. Whether the Medication Prescribe Service is called depends on aspects of the DetectedIssue resource (i.e., status element). The DetectedIssue resource is created by the Medication Select Service and populated by clinician actions in response to the displayed Cards. Figure 5 depicts the summary of operations that coordinates the Medication Select and Medication Prescribe Services.
{
"services": [
{
"hook": "medication-select",
"title": "PDDI CDS Service",
"description": "CDS Service for drug-drug interactions",
"id": "PDDI-CDS-medication-select",
"prefetch": {
"medications_stated": "MedicationStatement?patient//query parameters"
"medications_dispensed" : "MedicationDispense?patient//query parameters"
"medications_administered" : "MedicationAdminister?patient//query parameters"
"medications_prescribed" : "MedicationRequest?patient//query parameters"
}
},
{
"hook": "medication-prescribe",
"title": "PDDI CDS Service",
"description": "CDS Service for drug-drug interactions",
"id": "PDDI-CDS-medication-prescribe",
"prefetch": {
"drug_drug_interaction": "DetectedIssue//query parameters"
"observations": "Observation?detectedissue//query parameters"
"conditions": "Condition?detectedissue//query parameters"
}
}
]
}
The Level 2 Implementation specifies the use of both the medication-select and medication-prescribe CDS Hooks during a single medication order task. In addition to creating a medication-select hook, the mediction-prescribe context is modified to include the DetectedIssue resource.
The context element of the medication-select CDS Hooks request is identical to the medication-prescribe specification used in the Level 1 Implementation. The context element in the Level 2 Implementation medication-prescribe element has a minor modification to include the DetectedIssue resource. The DetectedIssue.id indicates the PDDI that was identified by the Medication Select Service (e.g., id : "warfarin-NSAID1234"). For details on the specifications are below.
medication-select 1.0 (new CDS Hook)| Field | Optionality | Prefetch Token | Type | Description |
|---|---|---|---|---|
patientId |
REQUIRED | Yes | string | The FHIR Patient.id of the current patient |
encounterId |
OPTIONAL | Yes | string | The FHIR Encounter.id of the current encounter |
medication |
REQUIRED | No | object | STU3 - FHIR Bundle of draft MedicationRequest resource for the current order entry task |
medication-prescribe 1.1 (modification of a current CDS Hook)The base version for the medication-prescribe hook is 1.0. The Level 2 Implementation requires an additional context field. This modification is considered Minor but will change the version to 1.1.
| Field | Optionality | Prefetch Token | Type | Description |
|---|---|---|---|---|
patientId |
REQUIRED | Yes | string | The FHIR Patient.id of the current patient in context |
encounterId |
OPTIONAL | Yes | string | The FHIR Encounter.id of the current encounter in context |
detectedissue |
REQUIRED | Yes | object | STU3 - FHIR Bundle of DetectedIssue resource for current order entry task |
medication |
REQUIRED | No | object | STU3 - FHIR Bundle of draft MedicationRequest resource for the current order entry task |
Since the order entry task is split into two separate CDS Hooks events (i.e., services), the prefetch template for the Medication Select Service includes only medication resources. The prefetch template for the Medication Prescribe Service includes any additional resources needed for a specific PDDI after accounting for clinician action(s).
As previously discussed, a DetectedIssue resource is created in both implementations. The Level 2 Implementation, however, uses the DetectedIssue to carry clinician-action state through order entry process. The the context element of the medication-prescribe request contains the DetectedIssue resource. During the parse and pre-process phase, the service determines if the ordered medication is the same as the DetectedIssue medication, and if prefetch data is needed for additional processing. The ordered medication is compared to the DetectedIssue medication either by the DetectedIssue.id, which is a Persistent Uniform Resource Locator (PURL) or through the DetectedIssue.implicated reference to conflicting medications. This is to ensure the clinician action did not eliminate the PDDI (e.g., change naproxen to acetaminophen). The DetectedIssue status element is instantiated by the Medication Select Service and indicates to the EHR if prefetch data are available or needed. If the status value is “final”, the EHR and the CDS service MUST NOT retrieve prefetch data. If the status is “preliminary”, the EHR MAY fulfill the prefetch queries or the CDS service MUST retrieve prefetch data from the FHIR server.
The parse and pre-process event for a medication-select request in the Level 2 Implementation is identical to what occurs with medication-prescribe for the Level 1 Implementation. Processing of medication-prescribe for the Level 2 Implementation service is slightly different. During the parse and pre-process phase the CDS service checks the medication that was finally ordered against the DetectedIssue resource (Figure 6). This is to confirm that the prescriber continued with the conflicting order after having the option to change the medication in response to the CDS Hooks Cards. In addition, the DetectedIssue status field indicates to the CDS service if additional prefetch data is needed for the specific PDDI.
Example: Level 2 – CDS Hooks Response
{
"cards": [
{
"summary": "Potential drug-drug interaction between naproxen 500mg tablet and warfarin 5mg tablet",
"indicator": "hard-stop",
"detail": "Non-steroidal anti-inflammatory drugs (NSAIDs) have antiplatelet effects which increase the bleeding risk when combined with oral anticoagulants such as warfarin.",
"detectedIssue" : {
"resourceType": "DetectedIssue",
"id": "Warfarin-NSAID-1234",
"status": "preliminary",
"category": {
"coding": [
{
"system": "http://hl7.org/fhir/v3/ActCode",
"code": "DRG",
"display": "Drug Interaction Alert"
}
]
},
snipped for brevity
Card Display Example
PDDI Version: 0.1.0 ®© FHIR Version: 3.5.0 generated on Tue, Aug 21, 2018 16:14+1000.
| History
| Propose a change
