This fragment is available on index.html
This publication includes IP covered under the following statements.
| Type | Reference | Content |
|---|---|---|
| web | snomed.info | 12847006 |
| web | snomed.info | 86895006 |
| web | snomed.info | 89748001 |
| web | snomed.info | 48974009 |
| web | snomed.info | 63954007 |
| web | snomed.info | 81387001 |
| web | snomed.info | 2367005 |
| web | snomed.info | 12274003 |
| web | snomed.info | 47064007 |
| web | snomed.info | 235853006 |
| web | snomed.info | 84568007 |
| web | snomed.info | 81142005 |
| web | snomed.info | 62341002 |
| web | snomed.info | 74341002 |
| web | snomed.info | 76078009 |
| web | snomed.info | 62838000 |
| web | snomed.info | 46523000 |
| web | snomed.info | 55746001 |
| web | snomed.info | 81518000 |
| web | snomed.info | 109558001 |
| web | snomed.info | 61401005 |
| web | snomed.info | 196731005 |
| web | snomed.info | 74474003 |
| web | snomed.info | 95531001 |
| web | github.com | 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 |
| web | snomed.info | 12847006 |
| web | snomed.info | 86895006 |
| web | snomed.info | 89748001 |
| web | snomed.info | 48974009 |
| web | snomed.info | 63954007 |
| web | snomed.info | 81387001 |
| web | snomed.info | 2367005 |
| web | snomed.info | 12274003 |
| web | snomed.info | 47064007 |
| web | snomed.info | 235853006 |
| web | snomed.info | 84568007 |
| web | snomed.info | 81142005 |
| web | snomed.info | 62341002 |
| web | snomed.info | 74341002 |
| web | snomed.info | 76078009 |
| web | snomed.info | 62838000 |
| web | snomed.info | 46523000 |
| web | snomed.info | 55746001 |
| web | snomed.info | 81518000 |
| web | snomed.info | 109558001 |
| web | snomed.info | 61401005 |
| web | snomed.info | 196731005 |
| web | snomed.info | 74474003 |
| web | snomed.info | 95531001 |
| web | w3id.org | It is RECOMMENDED that knowledge artifacts for PDDI CDS are written so that clinician-focused response information adheres to the 8 detailed best practice recommendations discussed in the Community Group Note titled Minimum Representation of Potential Drug-Drug Interaction Knowledge and Evidence . |
| web | github.com | A rule engine MAY execute CDS rules written in CQL and represented as a FHIR Library , either directly or compiled to Expression Logical Model . While this method is described in the current IG, implementers MAY choose to use various programming languages, rule engines and/or machine learning models rather than CQL+FHIR. |
| web | cds-hooks.org |
Figure 1 depicts hook triggers for a medication prescribing example. The implementation follows the
CDS Hooks order-select
and
CDS Hooks order-sign
specifications that define trigger events when a clinician enters a medication and is ready to sign one or more medication orders for a patient. The order-select
hook defines the initial trigger at the start of the CPOE workflow. The order-sign
hook is among the last workflow events before an order is promoted out of a draft status. Having the option to trigger the CDS service at only one
of two different events in the workflow sets PDDI CDS apart from most conventional CDS systems that trigger CDS at the time of order signing. By moving CDS triggers earlier in the order entry workflow (i.e., order-select
), clinicians will have 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 CDS. 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.
|
| web | cds-hooks.org |
Figure 1 depicts hook triggers for a medication prescribing example. The implementation follows the
CDS Hooks order-select
and
CDS Hooks order-sign
specifications that define trigger events when a clinician enters a medication and is ready to sign one or more medication orders for a patient. The order-select
hook defines the initial trigger at the start of the CPOE workflow. The order-sign
hook is among the last workflow events before an order is promoted out of a draft status. Having the option to trigger the CDS service at only one
of two different events in the workflow sets PDDI CDS apart from most conventional CDS systems that trigger CDS at the time of order signing. By moving CDS triggers earlier in the order entry workflow (i.e., order-select
), clinicians will have 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 CDS. 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.
|
| web | github.com | 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 . |
| web | hapifhir.io | HAPI JPA Server |
| web | hapifhir.io | HAPI JAX-RS Server |
| web | github.com | .NET Server |
| web | cds-hooks.org |
Figure 1 depicts hook triggers for a medication prescribing example. The implementation follows the
CDS Hooks order-select
and
CDS Hooks order-sign
specifications that define trigger events when a clinician enters a medication and is ready to sign one or more medication orders for a patient. The order-select
hook defines the initial trigger at the start of the CPOE workflow. The order-sign
hook is among the last workflow events before an order is promoted out of a draft status. From a clinical and technical perspective, triggering the CDS service at two events in the workflow sets PDDI CDS apart from most conventional CDS systems that trigger CDS at the time of order signing. By moving CDS triggers earlier in the order entry workflow (i.e., order-select
), clinicians will have 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 CDS.
|
| web | cds-hooks.org |
Figure 1 depicts hook triggers for a medication prescribing example. The implementation follows the
CDS Hooks order-select
and
CDS Hooks order-sign
specifications that define trigger events when a clinician enters a medication and is ready to sign one or more medication orders for a patient. The order-select
hook defines the initial trigger at the start of the CPOE workflow. The order-sign
hook is among the last workflow events before an order is promoted out of a draft status. From a clinical and technical perspective, triggering the CDS service at two events in the workflow sets PDDI CDS apart from most conventional CDS systems that trigger CDS at the time of order signing. By moving CDS triggers earlier in the order entry workflow (i.e., order-select
), clinicians will have 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 CDS.
|
| web | hipaa.yale.edu | Implementers need to consider and address security and privacy concerns that might arise when from providing CDS as a service. One thing to consider is if the clinician ordering a drug is not authorized to have access to information masked due to a patient's consent directive that restricts sharing. For example, consider the Warfarin + non-steroidal anti-inflamatory drugs (NSAIDs) Use Case where the clinician selects warfarin for a patient currently prescribed a NSAID and a proton pump inhibitor. It is conceivable that the clinician would not be aware that the patient is also taking a selective serotonin reuptake inhibitor (SSRI) for a major depressive disorder because the patient did not consent to share this information with anyone besides the mental health provider who prescribed the SSRI. Assuming that the FHIR Authorization Server enforces the patient's consent directive not to disclose to the CDS that the patient is taking a SSRI then, the clinician will not be alerted about the PDDI with NSAID. However, the FHIR Authorization Server could also have an organizational policy that authorizes the CDS as a "super user" and permits it to access to information that is masked from an unauthorized clinician. If the CDS service identifies a PDDI that could result from the order selected by the clinician, it could return a CDS Hook card cautioning the clinician of a possible counter-indication, and recommending that the clinician ask the patient about any medications that the patient has not shared. This would fall under a "Break the Glass" (BTG) scenario and would require a special procedure. A similar CDS BTG scenario was demonstrated during the HIMSS 201902 Orlando Consumer Centered Care Planning Interoperability Showcase and is described here . It was sponsored by the HL7 Security and CBCP WGs, VA, Allscripts, Perspecta, MyPatientLink and others. For more information, see https://build.fhir.org/security-labels.html#break-the-glass and https://build.fhir.org/operationoutcome-example-break-the-glass.html. |
| web | github.com |
The CDS Hooks feedback service
provides a mechanism for the CDS Service to receive an update from the client on the acceptance or rejection of a suggestion. This is valuable information to enable a service to improve its behavior towards the goal of the end-user having a positive and meaningful experience with the CDS. There are four distinct, possible outcomes for an end user's single interaction with a CDS Hooks suggestion card: suggestion accepted, card ignored, card dismissed without reason, card dismissed with reason. While the feedback mechanism could potentially provide the CDS Service with greater context for coordination between order-select
and order-sign
card responses, the coordination mechanism described in this IG does not require its use. EHR clients that implement the hook coordination mechanism (see advanced implementation
) MAY integrate feedback to inform how the service filters cards. However, this is not a requirement.
|
| web | cds-hooks.org |
The PDDI CDS artifacts use the current HL7 CDS Hooks specification
. 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.
|
| web | cds-hooks.org |
order-sign 1.0
|
| web | cds-hooks.org | 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. |
| web | github.com | 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. |
| web | w3id.org | 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 |
| web | cds-hooks.org | CDS Hooks |
| web | ucum.org |
The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
Show Usage
|
| web | w3id.org | The Warfarin + non-steroidal anti-inflamatory drugs (NSAIDs) knowledge artifact represents a relatively complex contextualized PDDI CDS algorithm. The knowledge artifact contains logic that uses both drug and patient contextual factors. The original rule was developed by clinical experts as part of the W3C Community Group effort to develop a minimal information model for representing clinically actionable knowledge about PDDIs . Table 1 is the Warfarin + NSAIDs knowledge artifact at the narrative level using the minimal information model. The IG use case shows 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. |
| web | www.whocc.no | Comment: The drugs involved in a PDDI SHOULD be explicitly stated. To support a computable representation of the PDDI, the drugs involved SHOULD be listed as sets of terms from a terminology such as RxNorm or the Anatomical Therapeutic Chemical Classification System (ATC) . Such so called value sets MAY be referenced by a URI to a public repository such as the Value Set Authority Center that is maintained by the United States National Library of Medicine . |
| web | www.who.int | Comment: The clinical consequences associated with a PDDI SHOULD be reported if known. Clinical consequences SHOULD refer health outcomes as specifically as possible. To support a computable representation of the PDDI, clinical consequences SHOULD be represented as one or more sets of terms from a terminology such as ICD-10 or SNOMED-CT . Such so called value sets MAY be referenced by a URI to a public repository such as the Value Set Authority Center that is maintained by the United States National Library of Medicine . |
| web | purl.obolibrary.org | Comment: Any recommended actions that apply to all patient exposures SHOULD be stated using clear and concise language. The recommended action statement SHOULD also provide citations to evidence for a suspected drug-drug interaction (not provided in this example). Recommendations that depend on contextual information/modifying factors SHOULD be mentioned separately to support context-specific presentation of such information. |
| web | purl.obolibrary.org | Comment: Any recommended actions that apply to all patient exposures SHOULD be stated using clear and concise language. The recommended action statement SHOULD also provide citations to evidence for a suspected drug-drug interaction (not provided in this example). Recommendations that depend on contextual information/modifying factors SHOULD be mentioned separately to support context-specific presentation of such information. |
| web | purl.obolibrary.org | Comment: Contextual information/modifying factors are necessary for alerts that are both sensitive and specific. Like clinical consequences, each known factor SHOULD be stated as specifically as possible. The factors SHOULD be amenable to implementation as executable logic using value sets from clinical terminologies such as RxNorm , the Anatomical Therapeutic Chemical Classification System (ATC) , ICD-10 , and SNOMED-CT . As is used in this example, each factor SHOULD be related to a specific recommended action that is supported by the evidence for a suspected drug-drug interaction |
| web | www.whocc.no | Comment: Contextual information/modifying factors are necessary for alerts that are both sensitive and specific. Like clinical consequences, each known factor SHOULD be stated as specifically as possible. The factors SHOULD be amenable to implementation as executable logic using value sets from clinical terminologies such as RxNorm , the Anatomical Therapeutic Chemical Classification System (ATC) , ICD-10 , and SNOMED-CT . As is used in this example, each factor SHOULD be related to a specific recommended action that is supported by the evidence for a suspected drug-drug interaction |
| web | www.who.int | Comment: Contextual information/modifying factors are necessary for alerts that are both sensitive and specific. Like clinical consequences, each known factor SHOULD be stated as specifically as possible. The factors SHOULD be amenable to implementation as executable logic using value sets from clinical terminologies such as RxNorm , the Anatomical Therapeutic Chemical Classification System (ATC) , ICD-10 , and SNOMED-CT . As is used in this example, each factor SHOULD be related to a specific recommended action that is supported by the evidence for a suspected drug-drug interaction |
| web | purl.obolibrary.org | Comment: Contextual information/modifying factors are necessary for alerts that are both sensitive and specific. Like clinical consequences, each known factor SHOULD be stated as specifically as possible. The factors SHOULD be amenable to implementation as executable logic using value sets from clinical terminologies such as RxNorm , the Anatomical Therapeutic Chemical Classification System (ATC) , ICD-10 , and SNOMED-CT . As is used in this example, each factor SHOULD be related to a specific recommended action that is supported by the evidence for a suspected drug-drug interaction |
| web | purl.obolibrary.org | Comment: Contextual information/modifying factors are necessary for alerts that are both sensitive and specific. Like clinical consequences, each known factor SHOULD be stated as specifically as possible. The factors SHOULD be amenable to implementation as executable logic using value sets from clinical terminologies such as RxNorm , the Anatomical Therapeutic Chemical Classification System (ATC) , ICD-10 , and SNOMED-CT . As is used in this example, each factor SHOULD be related to a specific recommended action that is supported by the evidence for a suspected drug-drug interaction |
| web | www.whocc.no | Comment: The drugs involved in a NPDI SHOULD be explicitly stated. To support a computable representation of the NPDI, the drugs involved SHOULD be listed as sets of terms from a terminology such as RxNorm or the Anatomical Therapeutic Chemical Classification System (ATC) . Such so called value sets MAY be referenced by a URI to a public repository such as the Value Set Authority Center that is maintained by the United States National Library of Medicine . Due the novelty of natural products in terminology sets, use of RxMix may be helpful in finding a set of terms relating to the natural product in consideration. |
| web | www.who.int | Comment: The clinical consequences associated with a NPDI SHOULD be reported if known. Clinical consequences SHOULD refer health outcomes as specifically as possible. To support a computable representation of the NPDI, clinical consequences SHOULD be represented as one or more sets of terms from a terminology such as ICD-10 or SNOMED-CT . Such so called value sets MAY be referenced by a URI to a public repository such as the Value Set Authority Center that is maintained by the United States National Library of Medicine . |
|
Advanced_W_N_Cards.svg
|
|
Basic_Digoxin_Cyclosporine.svg
|
|
Basic_W_N_Cards.svg
|
|
Basic_Warfarin_NSAID.svg
|
|
CBD-Clopidogrel.png
|
|
CBD-DOAC.png
|
|
CPOE_workflow.svg
|
|
CPOE_workflow_2.svg
|
|
Digoxin_Cyclosporine_tree.png
|
|
Level_1_D_C_Cards.svg
|
|
Level_2_D_C_Cards.svg
|
|
Value_sets.svg
|
|
Warfarin-NSAID-TREE-opthalmic-addition.png
|
|
advanced-parse-pre-process.png
|
|
advanced-pddi-cds-service.png
|
|
basic-order-sign-service.png
|
|
basic-parse-pre-process.png
|
|
cds-service-discovery.png
|
|
digoxin-cylcosporine-sign.png
|
|
patient-view-parse-process.png
|
|
patient-view.png
|
|
warfarin-nsaid-select.png
|
|
warfarin-nsaid-sign.png
|