Digital-health

After explaining the ideal architecture and data model, let’s see which are the models FHIR foresees for the interoperability among the health information systems.

In a previous article we examined how the clinical documentation can be made through a collection of Resources.

Think of Resources as paper “forms” reflecting different types of clinical and administrative information that can be captured and shared. The FHIR specification defines a generic “form template” for each type of clinical information – so one for allergies, one for prescriptions, one for referrals, etc.

Some resources are infrastructure components used to support the technical exchange of information by describing what systems are able to do, defining allowed sets of codes, etc. Some systems, such as clinical decision support engines, may expose FHIR interfaces even though they don’t actually store any patient or administrative information themselves.

The paper forms (Resources) in FHIR are somewhat generic. They have to be usable in different countries and by different types of clinicians in different contexts. Recognizing that a one size fits all approach is not appropriate in the healthcare space, FHIR provides the ability to adjust the forms (Resources) by defining “extensions” as well as enforcing constraints. For example, a “prescription” form might have extension elements added to support tracking of restricted medications while also constraining the codes that can be used to communicate types of drugs to a particular national standard.

To keep the number of resources reasonable, some of them are fairly broad. For example, the Observation resource is used for vital signs, lab results, psychological assessments and a variety of other things. To support setting rules for more narrow areas (e.g. “What should I send if I want to share a blood pressure?“), FHIR allows the creation of Profiles.

Interfaces

In addition to defining the “forms” for data exchange (Resources), FHIR also defines a set of interfaces by which systems actually share that information. There are four primary mechanisms or “paradigms” of exchange supported by FHIR: via a REST interface, by exchanging Documents, by sending and receiving Messages and by exposing and invoking Services.

REST

REST is the simplest exchange mechanism. Continuing with the “form” metaphor, a RESTful server can be thought of as a room full of filing cabinets. Within the room is a cabinet for each “type” of form (or Resource) it supports. The cabinet contains folders where each folder has a unique number and represents one particular real-world thing: one Patient, one Encounter, one Medication, etc. Each folder (which represents a single Resource instance) contains multiple pieces of paper, with each piece of paper representing a specific “version” of that instance. Every time someone updates a record, a new piece of paper is added to the top of the file folder. To see the history of a resource, you simply have to flip through the pieces of paper in the folder.

Note that a typical medical record is generally a big “folder-of-folders” with many different types of ‘forms’ or ‘reports’ gathered together.

FHIR foresees an API with which you can do the following:

• search: search through the folders for one(s) that meet a set of search criteria and give you a copy of the top piece of paper in each relevant folder
• read: get a copy of the top piece of paper (which is the most current version) from a specific folder
• create: add a new folder to the appropriate cabinet (with a new number)
• update: add a new page (version) to the contents of a specific folder
• delete: virtually remove a folder from the cabinet
• transaction: place multiple pieces of paper in distinct folders at the same time
• operation: perform an action or procedure on papers from one or more of the folders – for example, averaging numbers across patients, producing a summary record, or perform a complex search.

Starting from these procedures more sophisticated interfaces can be created answering specific needs.

Documents

Documents are a familiar mechanism for sharing information in the healthcare space. They are useful whenever there’s a desire to guide how a consumer of information will navigate it and there’s a need to have a “frozen” view of information that can be reliably retrieved even years in the future. Examples of document-like things in healthcare include discharge summaries and lab reports.

In FHIR, there’s a special resource called Composition that acts as the “cover page” for a document. It identifies the title, author date, relevant patient and the table of contents. A FHIR document can be thought of as a set of sheets (Resource instances) stacked together with a title page on top that’s stapled together. That stapled collection can then be stored or passed around, conveying a complete set of information at once.

Messaging

Much healthcare information exchange happens using a messaging paradigm. In messaging, a set of information is sent from one system to another, typically triggered by an event in the sender system. For example, a patient being admitted, a lab test being ordered, a drug being administered. The message serves to notify the receiver that the event occurred as well as provide details about any existing data that was modified or new data that was created. Typically receiving a message means there’s an expectation that the receiving system will “do something” in response.

A message might request that a lab order be fulfilled or notify a system that two patient records have been merged or that a patient has been transferred from one bed to another. A message is similar to a document in that it collects resources together, however for a message, the “cover page” is a MessageHeader that acts as a requisition.

Services

Services can be thought of as a light-weight way of doing messaging. Rather than a full cover page, a small sticky note is attached to the front of a resource. And sometimes rather than sending a full piece of paper, the relevant pieces are cut out and sent as fragments. The response to a requisition is a similarly paper-clipped bundle of resource instances. Services are likely to be used for things like decision support. E.g. “Is there a problem with prescribing medication X for patient Y?” or “What’s the recommended care plan for a patient with conditions A, B and C?”

Coming back to EHR, the exchange of information with health systems can be done through REST or documents, while messages and services can be used to add smart functions to HER, like an advanced clinic dashboard or a decision support system.

In next articles we’ll examine both cases.

To be continued.