By: Amos (kippi) Bordowitz

FHIR® (Fast Healthcare Interoperability Resources) is HL7’s modern standard for the electronic exchange of information in the healthcare ecosystem. The main goal, as is suggested in the very name of the standard, is to promote interoperability between different healthcare systems, making it easier to exchange and use healthcare data. FHIR is meant to ultimately replace older standards, such as the widely used HL7v2.

That’s the gist on FHIR as a standard, but what is a FIHR Resource? How are FHIR Resources built? Here, we will break it down – from what Resources are used for, their structure and how they are used in real world scenarios.

 

Resources- what are they even?

FHIR Resources are the basic building blocks of FHIR. Each Resource is a modular component that represents a specific, atomic concept or entity in healthcare, such as a patient, medication, observation, or diagnostic report. These Resources can be combined and extended to model complex healthcare workflows and data exchanges.

 

Atomicity

Each Resource is a discrete, self-contained, standalone unit that encapsulates information about a distinct entity, concept or event in the healthcare domain. This atomic nature is crucial for ensuring that resources can be individually managed, transmitted, and processed without requiring additional context or dependencies.
Although FHIR resources are atomic, they can reference other resources to provide context and allow representation of more complex healthcare data structures. These references do not compromise the atomic nature of the resources; instead, they allow for modular composition. For example, a MedicationRequest resource may reference a Medication resource to specify the medication being prescribed. Each resource remains atomic, but together they form a comprehensive representation of a clinical scenario. That being said, each of the resources mentioned can be created, read, updated, and deleted independently of each other or any other Resource.

 

Structure

Each FHIR Resource is a structured data model that contains a set of predefined elements. These elements are defined by HL7, which is important, as it ensures that all resources are – at least in their core – standard, no matter who creates, reads or receives them. As FHIR employs an inheritance system (reminiscent of object-oriented programming), all Resources inherit a set of elements (which themselves inherit a standard structure named Element and defined using an ElementDefinition). These can be both metadata and data points, as well as identifiers.

Resource instances are represented in JSON or XML formats, which are both human and computer-readable and easy to follow.

 

Base Resources and Domain Resources

In actuality, the Base Resource, from which all Resources are derived, is a very simple entity, which has only four basic elements. Each Resource has its own logical id, unique to the system on which it is stored. This id serves as an identification of the Resource itself (but not the entity it represents), as well as the address in which it can be accessed.

Moving on, in this article, when we speak of “Resources”, what we are really talking about is “Domain Resources”, which are a 2^nd level of inheritance, and from which all the business-resources (Patient, Practitioner, Encounter etc.) are derived. DomainResouces allow for extensions, contained Resources and a human readable text narrative that contains a summary of the resource and may be used to represent the content of the resource to a human.

Elements

All Resources have a defined set of elements, each one holding a discrete piece of data. For example, a patient will have a name, Identifier (national ID, passport etc.), address and means of communication. Each of these are stored in their own elements. Some elements are of primitive data types (i.e., simple, single datum): string, date, number, boolean etc. Others are complex data structures that can hold anywhere from 2 to 15 pieces of data that are used together to make business sense. Some notable examples are Identifier, CodeableConcept (the most prevalently used complex data type) and Address.

Here is a JSON snippet showing the structure of the CodeableConcept, to give you a sense of what a complex data type looks like:

Note that there are several sub-elements that only actually “make sense” when coupled together. The code must also have a “system” – a unique URI that identifies the “dictionary”, or “namespace”, in which the code is unique and identifies a well-defined concept or “meaning”, and as a
best-practice, the human-readable display of the code. Taken together, they make sense on a business level.

 

Cardinality

defines the minimum and maximum number of times an element can appear in an instance. It’s expressed as a range, such as 0..1 or 1..*. When looking at the cardinality, the left number signals the minimum and the right number – the maximum. Thus, a 0..1 cardinality denotes that the element has a maximum of 1 occurrence, but that it is not mandatory, as the minimum is 0.

An asterisk (*), as in a cardinality of 1..* denotes the fact that the element is an array, able to hold as many occurrences as necessary. For example, in the Patient Resource, the identifier element has a cardinality of 0..*, meaning it is not mandatory, but may have several instances, as people often have several forms of identification.

 

Flags

Flags are a set of information about the element that impacts how implementers handle them. Flags are extremely important and can have major implications on implementation, so they should never be ignored.

Major flags include “Must Support”. “Modifier Element” and “Summary”, but there are others. We have previously written a whole post on the subject, so we will not go into any more depth here.

 

Constraints (Invariants)

All Resources and elements may have constraints attached to them that affect how they can or should be populated, such that harmful conditions can be avoided. Constraints come with a severity level (The following is taken from the FHIR specs):

·      Error: A rule that all resources must conform to. Validators should report it as an error if
the rule is violated, and applications processing the content can reject it as an invalid resource.

·      Warning: Report
this as a warning that there may be a problem with the resource, but it is
considered valid and can be processed normally

 A third level, “Guideline”, also exists, but it is more specialized. Read more about it here.

  

Extensions

While FHIR could ideally be viewed as “out of the box”
interoperability, no two healthcare systems are exactly alike.  While systems that are based on (or at least
support) FHIR resources should be able to function safely with the basic Resources only, there are times in which there is a requirement for data that wasn’t described in the base HL7 Resource definition. For this reason, all Resources and elements in FHIR can be extended – meaning that there is a built-in option to add more elements or sub elements to a resource. There is, of course, a proper way to do so, via Extensions, which are FHIR structures with a canonical URL and a value. These can be added specifically to the “extension” array of the Resource (or element). For more information on Extensions, see here.

 

Profiling

As we’ve just established, not all organizations, and certainly not all countries, have the same data setup or requirements. According to the FHIR specs, “there is wide variability between jurisdictions and across the healthcare ecosystem around practices, requirements, regulations, education and what actions are feasible and/or beneficial.” For this reason, FHIR allows implementors to create profiles, which allow for a variety of customizations on the base Resource. Profiles allow an organization to set expected parameters, set constraints and flags, change cardinality, bind elements to specific ValueSets, declare specific extensions that must be used, slice arrays (set specific rules for certain sub-arrays) and define exact implantation rules and
recommendations, as well as best practices. This allows organizations to set a conformance expectancy on incoming and outgoing Resources and even to reject incoming Resources that do not conform to a profile.

On a national level, profiling allows a national Core team to define national profiles that support the ability to allow (or even force) organizations to comply with the specific requirements of the national healthcare system. Once such national profiles are set, it is usually expected that organizational profiles will inherit from the national profiles, thus the new profiles automatically conform to the national profiles. This is considered more of a guideline, unless there is regulation to enforce this as a rule. We’ve written more on profiling here, as well as a deep dive on slicing here.

 

Messages vs. FHIR Resources: A Paradigm Shift in
Healthcare Data Exchange

The transition from HL7v2 messages to FHIR resources represents a significant shift in healthcare data exchange, with profound implications for how information is structured, managed, and shared. Now that you understand what Resources are, we can discuss the differences between the two paradigms.

 

HL7v2 Messages: Snapshot-Based Data Exchange

HL7v2 has long been a cornerstone of healthcare interoperability, enabling the exchange of clinical and administrative data through structured messages. Each HL7v2 message is essentially a snapshot, containing all relevant data at a specific moment. For instance, a lab result message might include patient details, test results, and associated observations.

However, this approach has several limitations:

1. Redundancy: Data is often repeated across messages. For example, patient information is duplicated in every lab result message, leading to inefficiencies.
2. Limited Reusability: HL7v2 messages are purpose-specific and not
   easily reused across different contexts, often requiring multiple
   variations of similar messages for different workflows.
3. Tightly Coupled Data: Data in HL7v2 is tightly bound within messages, making it difficult to reuse individual data elements without processing the entire message.
   
   

FHIR Resources: Modular and Reusable Components

FHIR introduces a modular approach, breaking down healthcare data – as already mentioned – into discrete, reusable components: Resources. Each Resource represents a specific concept, such as a patient, observation, or medication, and can be managed independently.

Key advantages of this approach include:

1. Reusability and References: FHIR resources can be referenced by multiple other resources without duplicating information, similar to object-oriented programming. For example, a single Patient resource can be linked to multiple Observations and MedicationRequests.
2. Modularity: Resources are self-contained, allowing systems to interact with only the data they need. This flexibility supports efficient and scalable integration across healthcare systems.
3. Decoupling of Data: Unlike HL7v2’s tightly coupled messages, FHIR resources are loosely coupled. Resources can exist independently but are linked through references, allowing for more dynamic and flexible data management.

From Message-Centric to Resource-Centric

The shift from HL7v2 to FHIR is more than just a technical upgrade; it represents a move from a message-centric to a resource-centric approach in healthcare data exchange. While HL7v2 messages bundle all necessary information into single transmissions, FHIR focuses on modularity, reusability, and flexibility. This aligns with modern API-driven integration, where systems
interact with specific resources via RESTful APIs, querying or updating only the required data.

FHIR’s resource-centric model leads to more efficient data exchanges, reduced redundancy, and better scalability, making it well-suited to meet the demands of today’s interconnected healthcare environment.

 
Summary

FHIR Resources provide the foundation for interoperable healthcare data exchange. By encapsulating specific healthcare concepts in a standardized, atomic structure, they enable the construction of complex healthcare models. Through precise definitions, cardinality, and constraints, FHIR Resources ensure data consistency and quality. While the core structure is
standardized, the flexibility offered by extensions and profiling allows for adaptation to diverse healthcare environments, fostering a robust and adaptable healthcare ecosystem. Resources are the cornerstone of a paradigm shift.

 ——

Transforming legacy HL7v2 messages or JSON to FHIR Resources can be hard work and error prone. If this sounds familiar, or if your organization is making the shift to FHIR, then FUME – our FHIR-converter might be the tool for you! Feel free to contact us with any questions you might have.