Digital-health

The creation of an Electronic Health Record based on FHIR architecture allows the implementation of services to support decisions in a simple and effective way. Let’s see how.
FHIR provides a set of resources for “clinical reasoning” to enable the representation, distribution and evaluation of clinical knowledge such as clinical decision support rules, quality measures, public health indicators, order sets and clinical protocols.

FHIR supports clinical reasoning in two main use cases:

• Sharing – the ability to represent artefacts of clinical knowledge by supporting physicians in decision making during the care management and delivery;
• Evaluation – the ability to assess clinical knowledge artefacts relevant to a specific patient or population, including the ability to request decision support and retrospectively assess clinical quality metrics.

A possible implementation of clinical reasoning can be achieved with CDS Hooks, an open source specification focused on clinical decision support. CDS Hooks can use FHIR to represent patient information and recommendations, but it is an architecturally independent specification.

The CDS Hooks specifications describe a model based on “hooks” to invoke decision support within a physician’s workflow. The specification defines an API which supports:

• Synchronous, workflow triggered CDS calls that return information and suggestions
• Launch of a user-oriented SMART application when the CDS requires additional interaction

SMART Health IT is an open, standards-based technology platform that allows you to create applications that can be used by any clinical system supporting this standard. The applications, free of charge or for a fee, are contained in a catalogue that you can consult here.

The CDS Hooks API is still under active development and therefore subject to change. The community, made by healthcare companies and clinical software manufacturers, is currently working on a version 1.0.

The basic components of CDS Hooks are:

• Service – a decision support service that accepts requests containing patient information and provides answers
• Hook – a defined point within the client system workflow with contextual information provided as part of the request
• EHR – a clinical information system that calls the decision support services (e.g. an electronic patient record)
• Cards – cards returned from decision support services containing recommendations or suggestions that are presented to the user within the EHR

How CDS Hooks Works

A CDS Hooks scenario involves two main actors: a CDS client and a CDS service, where the CDS client can be an electronic medical record, a prescription system or any clinical workflow system.

When the physician interacts with the CDS client it triggers hooks such as, for example:

• patient-view, when selecting a patient
• medication-prescription, when writing a new prescription
• order-review, when viewing an order (prescription) for its approval

When such an event occurs, the Client CDS notifies each registered CDS service. The notification includes:

• User ID
• Patient ID
• Patient context clinical data (hook context)
• Other specific data required by the service (pre-fetch-template)

Each CDS service can return one or more cards in response to the hook. Cards transmit a combination of text (fact sheet), alternative suggestions (suggestion sheet) and links to applications or reference materials (app link sheet).

CDS Hooks and FSE

In the case we are hypothesising, an EHR in hospital (in the figure below on the top left, yellow in colour) interrogates a CDS service transmitting, as context data, those contained in the system and eventually in the Clinical Data Repository. The CDS service can integrate these data by querying the FHIR Server of the Regional Electronic Health Record (in red on the right) so as to return, in the form of cards, more timely and relevant clinical knowledge.

The user can consult these cards – one or more of each type – within the CDS client. The cards allow different interaction modes:

• fact sheet: providing text that the user can read.
• suggestion card: providing a specific suggestion for which the CDS client shows a button that the user can click to accept. When this button is clicked, the suggested change is automatically inserted into the user interface of the CDS client.
• app link card: providing a link to an app (often a SMART app) where the user can provide details, scroll through a flowchart, or do anything else to take an informed decision.

The Regional Electronic Health Record therefore allows to complete the information that is considered by the CDS service and that may not be present in the CDS client (eg medication, diseases, etc …).

The end.