FHIR puts actionable clinical decision support into hands of physicians

FHIRworks Series: The barriers for sharing documentation and data in healthcare are breaking down, helped by standardization, digital technologies and collaborationIn this blog series we will focus on the use of HL7 FHIR in the real-world, and how it can be used to drive further adoption and innovation in Healthcare. This is the second blog in the series.

In a highly interoperable world where Fast Healthcare Interoperability Resources (FHIR) are ubiquitous, it is important to think of decision support not tightly coupled within a single electronic medical record (EMR), but shared across an entire healthcare ecosystem.

Decision support can be observed through a number of lenses. One way is to consider drug-to-drug allergy interactions; another is to base decision support on results from individual laboratory tests; while a third involves combining patient observations with demographic data, such as age and sex. All these attributes form a view of the patient and the likely decision support that is required.

Decision support today

In the past, these decision-support rules were recorded within EMRs, or other clinical systems, and then triggered when certain conditions were met. For example, if a patient is allergic to penicillin, the doctor is alerted to this if he or she writes a prescription for a penicillin-based drug. As new evidence was found — from clinical research, real-world observations and medical outcomes — it would be implemented within these systems. In the future, this evidence will be found much faster, and greater sources of this information will be identified, aided by digital technologies and patient tools such as wearables. There needs to be a way to allow for this decision support to be delivered through trusted clinical sources and available when the evidence is found.

Considerations for implementing clinical decision support

  • Trust is needed — in the source of the decision support, and backed by clinical evidence. Without trust, these decision support rules may be ignored.
  • Decision support needs to be within the clinician workflow, since there is little benefit in providing decision support after the fact, or in making clinicians go outside their normal workflow to enable these rules
  • A balance of rules is needed as well. If there are too many annoying pop-ups, clinicians will want them disabled, since they lessen their clinical time with the patient.

This is great for a single EMR system where every piece of information known about a patient is in a centralised repository and all rules are managed centrally, but this is not going to be the case in the future. Even today, most organisations have an EMR supported by pharmacy dispensing, laboratory information systems and a variety of other bedside systems.

What does a future clinical decision support capability look like?

In the future, the sources and expanse of information will explode with internet of things-based devices, which will be located in intensive care units (ICUs) at patients’ bedsides, capturing real-time patient observations, or found beyond the hospital setting in the form of consumer monitoring devices such as blood glucometers, insulin pumps, and even personal fitness bands and watches. These data sources offer a great deal of information about consumers and their health attributes.

Not only are the data sources increasing, but so is the way that clinicians interact with this data, through increasing mobility, artificial intelligence, chatbots and other user experiences yet to be realised.

All of this leads us to a need to decouple the clinical decision support from the underlying systems of record and provide access to this in a standardised and distributed fashion. And this is where the latest in the FHIR stack steps in: CDS hooks.

Explaining CDS hooks

CDS hooks is a standard for defining how decision-support information can be communicated to a clinical user. It is being looked at around the world for its application within clinical systems, and has been tested within HL7 connectathons around the globe to show how decision support can be enhanced through this standard.

CDS hooks return a set of cards which define an information flow. There are three types of cards:

  • Information Cards. This is information that can be provided to the user about the decision support itself; in other words, why the rule has been triggered, for example that the patient has hypotension and the clinician is trying to prescribe an angiotensin-converting-enzyme (ACE) inhibitor, as an ACE inhibitor lowers blood pressure.
  • Suggestion Cards. This is an option to provide alternatives to the user, such as a different medication or a different diagnostic test. In the above hypotension example, it may suggest fludrocortisone for the clinician.
  • App Link Cards: This is a link to another application or web page that can offer additional information to the user. This might link to a web page showing information on fludrocortisone and specific brands that might be available for prescribing within the dispensary.

These cards can be used in combinations to guide the user through the process of decision support based upon the rules that have been triggered.

There are currently three defined hooks, or places where a clinical decision support rule can be triggered (as provided by the standard), which are: 1) Medication-prescribe, where a new medication is prescribed to a patient; 2) Order-review, the process of reviewing diagnostic tests within an EMR or electronic health record (EHR); and 3) Patient-view, when the user opens a patient’s record.

These are the hooks provided by the standard, but as with HL7 FHIR, generally the options can be extended.

CDS hooks in action

Let’s consider the following scenario:

Peter Kelly, a 68-year-old male patient with hypertension and left ventricular hypertrophy, is being treated with Amlodipine 5mg, 1 tablet orally once daily, and Telmisartan 80mg + Hydrochlorothiazide 25mg, 1 tablet orally once daily.

After a fall at home, his right knee becomes swollen and acutely inflamed, and he goes to his local doctor for treatment. The doctor prescribes pain relief and attempts to also prescribe the anti-inflammatory medication naproxen as “Naproxen 500 mg tablet, 1 tablet orally twice daily with food.”

As the medication is selected, the clinical decision support system alerts the doctor that the combination of the non-steroidal anti-inflammatory drug (NSAID) medication with the other medication the patient is already taking has an increased incidence of serious renal impairment and strongly advises against this combination. The decision-support system recommends alternative management and shows references to the doctor about this risk, all within the practice’s system in the context of prescribing the medication.

By putting actionable decision-support capabilities into the hands of healthcare professionals, FHIR standards such as CDS hooks will provide a clear view of the patient, reduce risk and improve health outcomes.



  1. Nice post Chris! Hope that you’ll be able to demonstrate the DXC Open Health Connect Platform at the HL7NZ FHIR & SNOMED CT Implementation Showcase in Auckland on June 18th.


  1. […] data and metadata to ensure that the data is properly mapped. This is the purpose underlying Fast Healthcare Interoperability Resources (FHIR): to make it easier to exchange specific pieces of […]

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.