The CDS Hooks application programming interface (API) is a specification that builds on the FHIR® core specification to describe how an electronic health record (EHR) can automatically invoke external Decision Support Services based on events that occur during normal application use. These events are termed “hooks” in the specification – hence the name. The output from the service is presented to the user in the form of cards which can give advice or can be actionable by the user.

Medication-prescribe CDS-Hook

One CDS-Hook that is commonly described is the ‘medication-prescribe’ hook, which is invoked when triggering a prescription. For example, when a pricing service has been configured to respond to this event, it takes in the code for the medication, checks the usual price the patient pays and can then suggest a more cost-effective alternative, which could be a generic medication. The sequence of events would be:

  1. The user enters a prescription.
  2. The CDS service is automatically invoked, passing across the code for the drug from a given formulary.
  3. The service looks for medications that have a similar action but have a lower price and returns alternatives which are displayed in information cards to the user (any number of cards can be returned).

Here’s a diagram of the flow – from the specification:

How can we improve this simple example?

There are a number of ways that we can improve this simple example:

  • Rather than simple information cards, the card could allow the user to change the prescription to the recommended one (note that this requires the user to agree to the change).
  • When the service is invoked, we could also pass across the patients’ medical insurance details. The service can then check with the insurance provider to better determine the co-payment by the patient based on their insurance plan. There would need to be co-operation with the payer community, and this is already starting to happen in the U.S., under the umbrella of the HL7® Da Vinci Project. There are obvious benefits to the insurer – and the community – in reducing the overall cost of medications.
  • The card could enable the user to invoke another application using the SMART app-launch specification. The example above shows that the service has detected that the medication Toprol XL is a beta-blocker used to treat chest pain (angina), heart failure and high blood pressure (hypertension) which works by lowering heart rate and blood pressure. The card could provide a link to a SMART application which provides physicians with the most up-to-date clinical research on managing patients with hypertension. Additionally, the app could retrieve the patients’ medical history from the EHR and display a chart showing the patients’ blood pressure over time with the medications that have been previously prescribed on the chart – or it could retrieve the patient’s current medications and check for interactions. 
Services need to be configured

Services need to be configured in advance before they can be invoked. There are a number of options to consider:

  • What is the hook that will initiate the service call? A single hook can invoke any number of services – it’s up to the EHR to manage how best to present the returned cards to the user. While the specification doesn’t define the hooks, it does provide a process for common hooks to be agreed upon, which are documented in GitHub.
  • What information (in the form of FHIR resources) is passed to the service when it is invoked? Called the “prefetch” in the specification, this increases the ability of the service to provide customised support.
  • Can the service make queries against the EHR for more information? For this to happen the, service must have an access token that accompanies the API call back to the EHR. As a user is waiting, the service call must be as fast as possible, so the token is created by the Authorisation server component in advance and passed to the service when the hook is invoked. The token along with a SMART scope parameter indicates what clinical data can be made available to the service, so the tokens must be scoped to the current user and the service.
Security is paramount

Security is paramount when exchanging clinical data, both for the service and the EHR and mechanisms are described in the specification concerning this. Key points include:

  • Before the service and the EHR are connected, it is expected that the organization using the EHR will perform due diligence on the service provider. In particular, the EHR needs to be satisfied that the clinical data it supplies is adequately protected. Part of this process is to register the service with the EHR’s Authorisation server so that Access tokens can be generated by the Auth service for the EHR to pass to the service. (This is part of the SMART OAuth2 protocol – in SMART terms, the CDS Service is an external app that can access the EHR data).
  • When the EHR calls the service, it uses transport layer security (TLS) as the communications channel. This configuration uses certificates to establish the identity of the service to the EHR.
  • From the perspective of the service, it also needs to be able to trust that the call is from a known EHR. Each call from the EHR to the service is accompanied by a JWT token signed by the EHRs private key. This allows the service to verify that the call is legitimately using the EHRs public key (supplied at registration).
Why is all this required?

What is the value of this specification? As with other parts of FHIR (think Terminology services) what CDS hooks does is to separate the provision of complex functionality like CDS services from their consumption. By standardising the interface between the two, it establishes a ‘marketplace’ of CDS services which allows an EHR to select the service that meets their needs, knowing that the interface has been carefully designed, commonly used and widely checked. The supplier of the services can also market themselves to any other EHR that supports CDS Hooks, which makes it simpler to provide services and reduces the need for bespoke interfaces. 

The FHIR based CDS Hooks API specification describes how an EHR can invoke external services to improve clinical workflow, using SMART to ensure security. CDS Hooks can automatically invoke external CDS services, with the output from the service being presented to the clinical user in the form of cards that can give advice, or be actionable by clinicians. CDS services support clinicians during their decision-making process, ensuring appropriate information is provided at the point of care. 

CDS Hooks, SMART on FHIR and the FHIR standard can underpin an ecosystem of healthcare data, supporting access to, and manipulation of, healthcare data and services by different applications. 

To learn more about FHIR, read my white paper Enabling the Ecosystem with FHIR which discusses how healthcare information can be made available where and when it is needed.

Go to White Paper