By: Amos (Kippi) Bordowitz

To read this in Hebrew, click here

HL7® FHIR® standard – Fast Healthcare Interoperability Resources – is a standard created for the successful and easy exchange of healthcare data of all types between medical and healthcare organizations. FHIR® is open source and enjoys a growing international community, under the auspices of HL7®.

HL7® FHIR® is meant to solve one the hardest problems in healthcare – almost zero interoperability. Each organization saves data in a certain manner, according to whatever decisions were made by the system and data engineers of each organization. This isn’t a problem until this data needs to be sent to a different organization.

Here are a few simple examples of interoperability issues in healthcare, just to get a feel for how big the problem is:

• Terminologies (which codes are used to represent concepts – clinical or other)
• Leading zeros in data points – keep them or ditch them?
• The way names are maintained – family name first or first name? What about prefixes?
• Units of measurements (especially problematic when administering medications)
• Date and time formats
• Consent forms

That was just the tip of the iceberg. Almost every datum that is compiled by an organization has the potential of being in a different format, not only to other organizations, but even in the same one. One hospital wing might have different rules than another. This creates a chaos of problems when a patient needs to be moved to a different care facility, for example. Precious time can be lost, resources wasted, and sub-optimal care given. Lives can be lost. Lives are lost.

FHIR® is a fairly rigid standard; it sets very clear rules for every type of resource while still allowing for a great deal of flexibility using extensions which are quite easy to create and set. It allows for rules to be imposed by the creator and has plenty of space for comments and definitions that will make everything clear for users on the “other end” of the data transfer.

FHIR® is built on several layers of resources, or “levels”, each built on the previous:

Level 1: Basic framework on which the specification is built. This includes the base documentation, JSON and XML representation, DataTypes and Extensions.

Level 2: Supporting implementation and binding to external specifications. This is where you learn about the most basic types of concepts and resources, Implementer support, security, conformance, terminology and the exchange module.

Level 3: Linking to real world concepts in the healthcare system. The Administrative module covers the base data that is then linked into the other modules for clinical content, finance/billing, workflow, etc. It is built on the FHIR technology platform modules.

Level 4: Record-keeping and Data Exchange for the healthcare process. The modules on this level are what you would call the “bread and butter” of healthcare. From clinical, medications and diagnostics; to financials and workflow.

Level 5: Clinical reasoning. Providing the ability to reason about the healthcare process.

Framework (Taken directly from the FHIR overview):

FHIR® is based on "Resources" which are the common building blocks for all exchanges. Resources are an instance-level representation of some kind of healthcare entity. All resources have the following features in common:

• A URL that identifies the resource
• Common metadata
• A human-readable XHTML summary
• A set of defined data elements - a different set for each type of resource
• An extensibility framework to support variation in healthcare

Resource instances are represented as either XML, JSON or RDF and there are currently 145 different resource types defined in the FHIR specification.

Each instance of a resource consists of:

• resourceType - Required: FHIR defines many different types of resources.
• id - The id of this resource. Always present when a resource is exchanged, except during the create operation.
• meta - Usually Present: Common use/context data to all resources and managed by the infrastructure. Missing if there is no metadata.
• text - Recommended: XHTML that provides a human readable representation for the resource.
• extension - Optional: Extensions defined by the extensibility framework.
• data - Optional: data elements - a different set, defined for each type of resource.

URLs:

An important way of identifying resources is by giving them a URL. It is not required, but is highly preferred. The URL identifies the resource and specifies where it was/can be accessed from. If the resource is accessed via the FHIR RESTful API (see immediately below) then the URL for the resource is [base]/[resourceType]/[id] where the resourceType and id come from the resource.

Interactions:

FHIR provides a REST API which allows for several types of resource manipulations. These include: Create, Read, Update, Delete, Search, History, Transaction and Operation. It is important to familiarize yourself with all of these. The FHIR specification has several other kinds of exchange, such as using Messages and Documents to transfer groups of resources.

Resource creation/deletion processes involve a HTTP POST transaction. All the rest are GET based.

Create example: POST https://example.com/path/{resourceType}

When creating or updating a resource, if all goes well, you will receive a 201 code with a location header containing details on the new/updated resource. Otherwise, the server will return a detailed error report. In all cases, the message will also include an OperationOutcome resource with additional information.

Reading a resource is done by sending HTTP GET requests to the desired Resource Type endpoint.

Read example: GET https://example.com/path/{resourceType}/{id}

In addition to getting single known resources it's possible to find a collection of resources by searching the resource type end-point with a set of criteria describing the set of resources that should be retrieved, and their order. The general pattern is:

GET https://example.com/path/{resourceType}?criteria

The criteria is a set of HTTP parameters that specify which resources to return. For example, the search operation

GET https://example.com/base/MedicationRequest?patient=347

returns all the prescriptions for the patient created above.
The response to a search request is a Bundle: a list of matching resources with some metadata (see FHIR® website for more info).

Update requests require a HTTP PUT request including the new version you wish to create in its entirety. This will also return a response with all the same information you would expect from a create request.

Managing variability:
Geopolitical differences and even different branches of the healthcare industry create variation. When you add the fact that there is no central body that dictates and enforces business practices you end up with immense possible variation. To address this, FHIR has an extension framework, allowing us to add properties that the base resources might not include.
For example: In Israel, all residents must belong to one of 4 national HMOs. This is not addressed by the base resource but is an absolutely crucial bit of information. An extension was therefore created for this purpose.

Tips:
In order to be a competent developer in a FHIR® ecosystem, it is worthwhile to grasp an important fact about the differences between local and global FHIR. FHIR is meant to be an international standard with flexibility and extensibility that allow every country and even every organization to set up their own system. That being said - unless you are implementing a very special solution for a very specific case/organization - the more generic your implementation, the better, as it can be used on a larger scale. This is especially true if you wish to create a FHIR-based application. Local developers usually base their work on pre-established national profiles, while generic developers use the base definitions, allowing the widest audience and variety of uses. The problem is that variations are basically infinite. What can you do about this?

Firstly, try your best to use the base definitions. Use clear text explanations throughout your implementation where the resources allow for it (there are several options for this) and wherever possible, use standard terminologies.
Examples for such terminology code systems: SNOMED, LOINC, UCUM, OMIM, HGVS.
Finally, we recommend learning FHIR Shorthand (FSH), a powerful way to write FHIR resources in a fraction of the time and far fewer keystrokes.
--------------------------

In conclusion, while HL7® FHIR® is powerful, it has a bit of a steep learning curve that must be overcome in order to become proficient. Here at Outburn we understand that getting started can be a little daunting. We will be happy to be of service, no matter what your FHIR needs are.