CDS Hooks - A Technology That Complements SMART Apps

A clinical scenario to understand CDS Hooks 

CDS Hooks is an attempt to help clinicians with clinical decision support by running checks automatically for them ahead of time, and then providing information within the context of the EHR. 

When a triggering activity occurs, the CDS Client (EHR) notifies each CDS service registered for the activity, which then provide near-real-time feedback about the triggering event with basic details about the clinical workflow context (via the context parameter of the hook) plus whatever service-specific data are required (via the pre-fetch-template parameter).

A great example by which to visualize the way this technology works is in the context of prescription writing.  The event of writing the prescription triggers a CDS Hook which learns that the physician is in the process of writing a prescription, and it can return some information in the form of a “card” that will be displayed inside the EHR. There can be three categories of data that CDS hooks can return: 

• Information card: Providing the financials of the drug being prescribed 
• Suggestion card: Proposing an alternate drug in accordance with the age of the patient with a button to switch over. 
• App link card: Providing link to an external app. Example, while in the medication prescription workflow, if it makes sense to run an app that can provide guidelines on managing hypertension, the CDS service might return a link to that app. Therefore, CDS hooks is a technology that complements SMART Apps as it enables to launch the right app at the right time. 

Hook context 

Any user workflow or action within an EHR (CDS Client) will include contextual information such as the current user, patient and so on. CDS Hooks refers to this information as context. For each hook, a set of context parameters get defined each of which can be either optional or required (depending on the capabilities of individual CDS Clients) and each has a data type associated with it. However, the context information is intended to be relevant to most CDS Services subscribing to the hook. 

Each hook includes: 

• Data specific to a hook 
• Data that all CDS services using that hook would use 
• Can be FHIR data or references to FHIR data 
• Every hook defines its own context 

Hook prefetch 

For understanding the concept of Hook Prefetch, let us consider the example of a Patient view hook. CDS services that may require the full patient details, can request it to be prefetched or fetch it as needed from the FHIR server using a prefetch template in their discovery response. Another example is the ePrescription workflow. While placing medication order, allergies do not form part of the official set of contexts that the hook defines. However, one can register with the CDS service a “Prefetch request”. Once registered with the service every time the EHR calls the service, the allergies information must be fetched from the EHR and included while calling the service.  This however is an optional requirement as not all EHR can support this. Every CDS service may have different requirements, and the services can register a set of their requirements when they get configured to work inside an EHR. 

Prefetch data is always FHIR data, specific to a given CDS Service and expressed as FHIR read/search queries. 

Prefetch data is defined by each CDS Service because it is specific to the information that service needs in order to process. 

 “Standard Hooks” available for use 

Patient View: This is invoked when a patient record gets opened. 

Order Select: This is fired when a clinician selects one or more orders to place 

Order Sign: This is invoked when a clinician is ready to sign one or more orders for a patient 

Appointment Book: This is invoked when the user is scheduling encounters/visits for the patient 

Encounter Start: This is invoked when the user is initiating a new encounter. In Inpatient setting this would be at the time of admission and in Outpatient setting this would be the time of patient-check-in for a face-to-face or equivalent for a virtual/telephone encounter 

Encounter Discharge: This is invoked while performing discharge formalities relevant for an inpatient encounter 

Security of CDS Hooks 

When an EHR needs to configure a new set of CDS service, the CDS service provider hosts a Discovery endpoint which includes a list of services provided. So, Discovery provides the end-to-end way to configure all the details required for one or more services that needs to be connected to. 

Before the CDS service and the EHR get connected, the EHR needs to adequately protect the clinical data it supplies. This is done by registering the service with the EHR’s Authorization server and generate access tokens by the Auth service for the EHR to pass to the service. When the EHR calls the service, it uses transport layer security (TLS) as the communications channel and uses certificates to establish the identity of the service to the EHR. 

Likewise, the CDS service also needs to be able to trust that the call is from a known EHR and needs to authenticate the EHR that’s invoking it. Each call from the EHR to the service is accompanied by a JSON web token signed by the EHRs private key which allows the CDS service to verify that the call is legitimate. 

Clinical decision making is complex involving myriad data points, inputs, changing guidelines and protocols and need to be patient and event specific and standard EHR systems often fail to support clinical decision making. CDS hooks is fast emerging as a probable answer to the challenges of providing patient/context specific decision support by enabling information displayed within the EHR to be specific to both the patient and stage of treatment. In addition, CDS hooks can also be actionable to the clinician within the context of the EHR workflow.

CDS hooks can be tailored to integrate seamlessly with the diverse EHR vendors systems. A well-designed implementation of CDS Hooks will enable software to remember when providers accept or reject cards so that information flows to the provider in a way that’s useful and usable. With careful design to limit the possibility of alert fatigue often associated with CDS, EHRs will be able to offer customers the advantages of a new clinical quality-enhancing functionality with limited development effort, making this technology a win-win-win-win for providers, patients, EHR vendors and third-party software developers.

In the current healthcare scenario, CDS hooks can be considered best fit since every vendor will be supporting the same FHIR based APIs with standardized hooks which means that CDS developers need not build unique interfaces with every clinical application it seeks to integrate, rather build a single standardized API that works with all. 

A common set of CDS Hooks is already drafted for established use cases, however it is by no means a closed list and digital health communities such as the FHIR Implementations working group are encouraged to develop and implement new ‘Hooks’ for new use cases in the days to come.