FHIR and its acquaintances have become one of the most compelling and essential standards to regularize the process of accessing and sharing health data securely. 

But as changes happen, now experts of informatics working on FHIR are facing a more fundamental issue: how does a clinician know when and which app to use? The major challenge of the SMART on FHIR with the integration into clinician-facing EHRs is that for launching an app, the user has to first decide to do the launch. 

For this, the knowledge of the usefulness of apps should be known by them. This is where “CDS Hooks” comes in. It is an attempt to support clinicians to know what they want, ahead of time and to provide information regarding the context within the EHR.

Know The Basic Elements And Terms Of CDS Hook

1. Web service:

The communication of two different electronic devices offering services via the internet.

2. CDS service:

A decision support service that agrees to requests regarding patient information and provides responses accordingly.

3. EHR:

Electronic Health Record also called CDS client here, accepts decision support in services MAY format, provides authorization and FHIR resource server.

4. Card:

Help or guidance in the form of a card (pop-up) having discrete recommendations or suggestions from decision support services returned to the user within the CDS client. 

Cards can be of 3 types

• Information card: includes useful text for the user
• Suggestion card: provides suggestions
• App link card: interlinking cards- links to reference materials

5. Hook:

A described point with the client system’s workflow with familiar interpreted information provided in return for the request made.

6. CDS:

CDS stands for Clinical Decision Support. It is a health information tech that provides clinicians, patients, and other healthcare staff with data and person-specific information, to improve healthcare.

7. Prefetch template:

It is an FHIR read or search request that explains needed relevant data by the CDS service.

CDS Hooks: Introduction To The Hottest In Trending

CDS Hooks is an open-source specification and an HL7 published specification for user-facing CDS, that takes EHR encounters/events (like when a provider views a patient’s chart, when a visit starts or ends when a medication is ordered, etc) and notifies peremptory web services, that can be created by anyone.

These web services can provide “card” data right back to the EHR, to be viewed by the provider. 

CDS Hooks is at its fastest pace of adoption as many vendors are building APIs based on HL7’s FHIR standard. FHIR is now a storm that took down the industry into its firm hold for the greater good, with its mandated use fueled by the federal government.

Understand easily with the following examples:

• A provider selects a medication order for which you create a cost estimator card.
• When an encounter ends, you create a service that ends up with a follow-up text/bot (like a patient satisfaction survey).

In simple terms, when a clinician views a patient’s chart and if the patient has any medical conditions in the past that have got documented in the EHR, it will pop up like a notification card in the provider’s EHR.

The Most Important 2 Things That You Need To Get CDS Hooks To Work

1. A place for you to serve your code, and
2. An EHR to show these cards. Simple!

You just need to copy & paste the server URL that you created, onto your EHR. Add “cds-services/” at the end of the URL and save. Your created pop-up card will appear in your EHR. Done! You can also include interlinkings using codes in your server.

Benefit Of CDS Hook

• FHIR APIs can be used by CDS Hooks to set off robust clinical support in EHRs.
• It allows every vendor to support the same FHIR API and to offer the same set of standardized hooks.
• The developers of decision support tools do not require to write individual interfaces for each EHR. 
• Developers can build to a single API that goes with all.
• CDS Hooks partly addresses interruptions by allowing returned information to be clear and specific to both the stage of treatment and the patient.
• It stays actionable to the clinicians within the conditions of the EHR workflow.

CDS Hook: The Implementation

Implementation matters the most in any case. A perfectly designed implementation of the CDS Hook will allow the software to not forget when providers accept or reject cards. This ensures the smooth flow of information to the provider in a way that is usable and useful.

The support of SMART is referenced specifically in the 21st Century Cures Acts of 2016. The Act requires a universal API to make all elements of a patient’s health record accessible across the SMART API, easily. CDS Hooks are commonly implemented as SMART applications.

The Usage Of CDS Hooks

• It enables the creation of places that are standard inside the EHR workflow. In those places, the EHR can provide a notification of an event/encounter that is happening.
• This notification can be received by an external (SMART) application that returns relevant information to the EHR for displaying to the user. 

Creating New Hooks

New Hooks can be created by anyone interested because FHIR is an open-source standard. Here we explain to you the six “hooks” standard, which has been defined as a part of version 1:

1. Patient-view:

It is called only once at the start of a user’s interaction with a particular patient’s record.

2. Order-select:

It fires when a clinician chooses one or more orders to be placed for a single patient. If supported by the EHR, this hook will also be used whenever the clinician selects a detail associated with the order.

3. Order-sign:

It is fired when a clinician is ready to sign one or more orders (orders like medications, procedures, labs, and others) for a particular person.

4. Appointment book:

This is used when the user is scheduling one or more future encounters for the patient.

5. Encounter-start:

It is invoked when the user is ready for a new encounter. The time of in-patient admission is a good example of this. For the outpatient environment, it will be the time of patient check-in for a face-to-face/virtual encounter.

6. Encounter-discharge:

It is fired when the user is undergoing the discharge process for an encounter- an in-patient encounter.

Other than this, inside the clinician’s workflow, user activity triggers CDS Hooks in real-time. Examples are

Order-select: On authorizing a new prescription

Patient-view: While opening a new patient record

Order-sign: On viewing pending orders for approval

Conformation Language

RFC2119 describes the interpretation of the keywords, “MUST”, “MUST NOT”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”.

Description Of Each CDS Service

How To Provide FHIR Resources To A CDS service?

• Specific FHIR resources are needed for each CDS service to work out the recommendations requested by the CDS client.
• A CDS client, with no problem in real-world performance, could start a CDS service passing only the required data. 
• The CDS service then could request approval for FHIR resources as they were demanded, then recover the resources from the CDS client’s FHIR server.
• The CDS services SHOULD respond quickly. So these specifications help by defining the process which allows a CDS service to request and gather FHIR resources competently.

There are two optional methods for doing these:

1. FHIR resources may be acquired by passing “prefetched” data from the CDS client to the CDS service in the service call.
2. The second one allows the CDS service to recover FHIR resources by and for itself. But it needs more efficiency to do so.

CDS Hooks API Security & Safety Measures

• The risk that confidential information and privileged authorizations transferred between a CDS Client and a CDS Service could be furtively intercepted by an attacker
• The risk that an attacker impersonating as a legitimate CDS Service could receive confidential information or privileged authorizations from a CDS Client, or could provide to a CDS Client decision support recommendations/suggestions that could be dangerous to a patient
• The risk that an attacker impersonating as a legitimate service-subscribing CDS Client (i.e., a middle man) could interrupt and possibly change data exchanged between the two parties
• The risk that a CDS Service could insert dangerous suggestions or links to dangerous apps in Cards returned to a CDS Client
• The risk that a CDS Hooks browser-based deployment could be exploited by a Cross-Origin Resource Sharing (CORS) attack
• The risk that a CDS Service could return a decision based on outdated patient data, resulting in harm to the patient

A security model is exclusively defined by CDS Hooks to address the above-mentioned risks. It assures that the identities of both the CDS service and the client are validated by each other, by securing vital and private information and privileged authorizations shared between the CDS service and the client. 

This is done by recommending means of assuring data freshness, and by inducing business mechanisms through which trust is confirmed and maintained between a CDS client and a CDS service.

RELATED: FHIR Success Story: A Large Healthcare Company’s Experience With CapMinds HL7 FHIR Services

Final Thoughts

The integration of FHIR and CDS Hook can eradicate “alert fatigue” to a great extent. Alert fatigue is another big problem that has become common with the growing amount of patient health data. It becomes easier for medical records and providers to get engulfed if they are notified of every reading.

The clinical insights provided by FHIR and CDS Hook data can turn out to be significant and usable if only provided usefully and appropriately in the required conditions of the clinical workflow. Get the perfect HL7 FHIR services for you with all updated features from CapMinds Technologies. Because CapMindship never fails to amaze you!

We facilitate real-time data access and healthcare delivery. To effectively convey medical solutions, healthcare applications should be able to share, integrate, exchange, and retrieve data between themselves. With CapMinds HL7 FHIR your data will be available, discoverable, and understandable while maintaining structure and standardization.

Our service features include HL7 integration solutions, HL7 interface development, third-party HL7 implementations, and HL7 viewer programming

CapMinds HL7 interfaces ensure compliance with regulatory standards set by the U.S. Department of Health and Human Services (HHS), Office of the National Coordinator – Authorized Testing and Certification Body (ONC-ATCB), American National Standards Institute (ANSI), HITECH’s Meaningful Use Stage 1 and 2 (MU-1 & MU-2), Health Insurance Portability and Accountability Act (HIPAA), and International Organization for Standardization.

Choosing CapMinds is the best option! Why?

• We strive to improve healthcare organizations’ workplace productivity by simplifying their day-to-day operations.
• We combine the best features of HL7’s Version 2, Version 3, and CDA® while leveraging the latest web standards to maximize interoperability.
• We have the expertise to design, develop, and manage a comprehensive HL7 interface compliant with required standards, specifications, and formats.

Select Capminds FHIR HL7 integration solutions. Visit us for more information. 

“We ensure your data and interoperability will be safer and faster with us”