HIT Perspectives: CDS Hooks Can Use FHIR APIs to Trigger Robust Decision Support in EHRs

Clinicians need a variety of timely information about individual patients, their condition and potential treatment options to develop cost-effective, high-quality care plans. To be sure, electronic health records (EHRs) already contain a lot of relevant information in the form of clinical decision support (CDS) to help guide decision making. However, EHRs designed primarily as documentation tools are challenged to offer sophisticated, precision decision support tools, especially in the face of constant advances in diagnoses and treatments. This challenge is being addressed by a new standards-based technology called CDS Hooks.

CDS Hooks are rapidly coming onstream as vendors build application programming interfaces (APIs) based on HL7’s Fast Healthcare Interoperability Resources (FHIR) standard. FHIR has taken the industry by storm (a FHIR-storm!), fueled by mandated use by the federal government.

How does CDS Hooks work? The technical capability offered by CDS Hooks enables the creation of standard places within the EHR workflow where the EHR can issue a notification that an event is happening. This notification can be received by an external application, which in turn can return pertinent information to the EHR, for display to the EHR user. In FHIR-speak, the information returned is a “card.” Cards can be of three types:

• Information card: Conveys text that may be useful for the user
• Suggestion card: Provides suggestions
• App link card: Links to reference materials or apps

Development of CDS Hooks is just getting off the ground. Today there are eight ”hooks,” which have been defined as part of Version 1 of the standard:

• Patient View: When a patient is selected and his or her record opened
• Medication Prescribe: When a medication is being prescribed
• Order Review: When order(s) have been selected and are being reviewed
• Order Select: When order(s) are selected
• Order Sign: When order(s) are being signed
• Appointment Book: When an appointment is being scheduled
• Encounters Start: When a new-patient encounter begins
• Encounter Discharge: When a patient encounter is completed

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. The hook can be received by a patient engagement API. The API returns a suggestion card recommending that the patient be provided educational materials, enrollment into a support program and given an offer for copay assistance.

Because FHIR is an open-source standard, new hooks can be created by any interested party. So, while the list of hooks is rather short today, we expect it will grow dramatically as CDS Hooks becomes more widely adopted by EHR vendors.

Similar functionality has been part of health information technology for quite some time. In the mid-1980s, UNIX-based The Medical Manager software (a practice management solution) featured “Triggers,” which functioned in the same manner as CDS Hooks do today. The key difference between the Triggers of yesteryear and CDS Hooks is that in the past, each EHR vendor decided what specific hooks would be applied and developed unique APIs around them. Today, there’s a common solution with a common platform.

Looking to the future. The beauty of CDS Hooks is that every vendor supports the same FHIR API and offers the same set of standardized hooks. In this manner, developers of decision support tools don’t need to write unique interfaces for each EHR, but rather can build to a single API that works with all.

As with any new technology, there are pros and cons. Providers are not generally receptive to decision support reminders because sometimes the information may not be pertinent or actionable. Too many interruptions lead to “alert fatigue,” a well-documented phenomenon in which providers simply click through the reminders without reading them or taking action.

Use of CDS Hooks partly addresses these concerns by enabling returned information to be specific to both the patient and stage of treatment. Better yet, it can be actionable to the clinician within the context of the EHR workflow. 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.

Widespread adoption by EHR vendors of CDS Hooks creates an opportunity for innovative, complementary applications that supplement the core functionality of the EHR. With careful design to limit the possibility of alert fatigue, EHRs will be able to offer customers the advantages of a new clinical quality-enhancing functionality with limited development effort. Without a doubt, this is a win-win-win-win for providers, patients, EHR vendors and third-party software developers.

Point-of-Care Partners offers a wide range of consulting services specific to FHIR and CDS Hooks. Please contact me at michael.burger@pocp.com if your organization needs assistance in these areas.