#FHIR Important Concepts, Terms and Definitions by Manish Sharma, @msharmas

FHIR is the latest interoperability standard based on a RESTful API architecture published by HL7. HL7 has been working for over 25 years in publishing standards for Healthcare data interoperability. The move from the earlier HL7’s 2.x standards evolved to the Development of the RIM v3 and then to FHIR, has now allowed a paradigm shift to leverage web standards. The purpose of this article is to get the reader to understand the difference between the earlier versions of HL7 interoperability standards and then present the important concepts that will help you to understand FHIR concepts, terms and definitions.

How is data exchange different using web APIs and FHIR compared to traditional HL7 interfaces? (Ref1)

Dave Shaver, “The interoperability standards we have today are focused on exchanging transactions at certain points of the care lifecycle. In HL7 version 2 that’s focused on patient care, including myriad activities such as administrative tasks, admission, discharge, orders, or results availability. Clinical administrative data is being moved at a certain point in time during the lifecycle of the data. This means it’s difficult to ask questions about that data, except when it has reached that exact point in its life cycle.

FHIR, on the other hand, For the first time is going to be a standard that will allow applications to query the source of truth for data when they need it, not just when it reaches a specific point in its lifecycle. HL7 v2 and CDA documents rely on a push-model of data exchange. FHIR, on the other hand, is more of a pull-model.”

Before we get into the details of FHIR, we need to understand what is RESTful API Architecture.

REST full form is REpresentational State Transfer and API stands for Application Program Interface. The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation (ref2). REST is a software architectural style that defines the set of rules and constraints to be used for creating web services between applications, to allow requesting systems to access and manipulate web resources by using a uniform and predefined set of rules. Interaction in REST based systems happen through Internet’s Hypertext Transfer Protocol (HTTP). Web services which follow the REST architectural style are known as RESTful web services.

FHIR stands for, Fast Healthcare Interoperability Resources. In the early days of the development of the FHIR standard,

  • it was called Resources for Health in 2011 by Grahame Grieve. A Reading of the FHIR Genesis blog by Grahame Grieve, is a must to understand the how the transition from HL7 2.x to FHIR happened and most importantly, why. He also highlights the move from RIM v3 to Resources for Health (RfH as it was called then).
  • In Feb 2014 FHIR was released by HL7 as a “Draft Standard for Trial Use” (DSTU), Release 1, version DSTU 1 (v0.0.82).
  • In December 2014, a broad cross-section of stakeholders committed to the Argonaut Project, in the US.
  • FHIR Release 3 was published in March 2017, as the first STU (Standards for Trial Use) release.
  • FHIR Release 4.0.1 was published on October 30, 2019 (Wiki)

In a change from the earlier event driven model of Interoperability, which relied on exchange of messages during patient registration, admission, ordering, and other similar events, FHIR solutions are built primarily from a set of two modular components called “Resources” & “APIs“. (ref3)

Resources: A resource is an entity that: (source: ref3)

  • has a known identity (a URL) by which it can be addressed
  • identifies itself as one of the types of resource defined in this specification
  • contains a set of structured data items as described by the definition of the resource type
  • has an identified version that changes if the contents of the resource change
  • Resource instances are represented as either XMLJSON or RDF and there are currently 145 different resource types defined in the FHIR specification.

APIs – a collection of well-defined interfaces (ref3) for interoperating between two applications. Although not required, the FHIR specification targets RESTful interfaces for API implementation

If one were to view the healthcare data in its entirety, we will be able to understand that there’s a need to share healthcare data by the way of a more manageable sub-domain or smaller chunks of data, at the same time ensuring we are able to maintain the integrity and consistency in the way the resources interact with each other and while maintaining the context between these pieces of information.

And based on this concept, there are projects live today that are DOMAIN driven, argonaut for clinical data, CARIN for consumer directed approach, DaVinci for payors, BlueButton for observational reports, etc, look up more projects here (ref3.1)

Think of Resources as paper “forms” reflecting different types of clinical and administrative information that can be captured and shared. [10]

Therefore, each form has a category, like administrative, clinical, financial, etc. For each patient, one or many of these categories of information can be recorded. For instance, one form template for the clinical category would be recorded for allergies, another one for prescriptions, or in the administrative category, about the physician for the encounter, or the encounter information itself that is stored in various FHIR repositories.

FHIR repositories can be an EHR , a pharmacy systems, a hospital information systems (HIS), etc. Some systems, such as a patient health record (e.g., Apple’s Health App), may expose FHIR interfaces even though they don’t actually store any patient or administrative information themselves. Each Resource defines a small amount of highly-focused data. [10]

A single resource doesn’t say very much, but a collection of Resources taken together creates a useful clinical record. Information systems map the actions that a user takes (look up patient records, make a note in their history, etc.) to operations on the relevant resources.” Source: (Ref4). The Resources in FHIR are categorised as the FHIR Composition Framework

Source: FHIR Overview – Architects, HL7, Link

Descriptions of the layers in the FHIR Composition framework: (source: Architects Overview)

  1. Foundation Resources: Foundation resources are the most rudimentary, foundational resources. They are often used for infrastructural tasks. Although not prohibited, they are not always referenced by other resources.
  2. Base Resources: Layer two consists of base resources. These are often the leaf nodes of a resource graph. In other words, they are often referenced by other resources, but don’t typically reference other resources themselves. These resources are typically the most commonly used, and therefore require the highest degree of consistency and architectural rigor. Governance is greatest for resources in layers one and two.
  3. Clinical Resources: Layer 3 includes the resources that are clinical in nature but are also very common across many use cases. This includes resources for clinical observations, clinical treatment, care provision, and medications. These resources can be used by themselves, but typically build on the resources in layer two. For example, an observation resource will reference the patient resource from layer two. These resources are also frequently contextualized when they are referenced by resources in layers three, four and five.
  4. Financial Resources: Layer four is dedicated to financial resources. Logically, financial resources build on clinical and base resources. For example, a billing resource will reference clinical events and activities as well as base resources like a patient.
  5. Specialized Resources: In layer five, we find more specialized resources for less common use cases. These resources almost always reference resources in lower layers. Given that FHIR places priority on satisfying the most common use cases, there are fewer resources in this layer.
  6. Resource Contextualization: Layer 6 does not contain resources. However, it does extend the composition framework made up by the first five layers of resources. Layer 6 includes profiles and graphs. Profiles are used to extend, constrain, or otherwise contextualize resources for a given purpose. Graphs are compositions of resources, or webs of resource, that contain attributes of their own.

Let’s take for discussion the Patient Resource and review the definition provided in the standard. Each Resource has the following details:

  1. Scope & Usage
  2. References to other Resources
  3. Resource Content defines the structure
    1. Name of the Data Element (Patient Name, Active, Patient Telecom, Gender, etc)
    2. Flags: A set of information about the element that impacts how implementers handle them.
    3. Cardinality Rule: Cardinality: the lower and upper bounds on how many times this element is allowed to appear in the resource
    4. Type
    5. Description and Constraints defined for each Resource Content
  4. Examples with narratives
  5. Detailed Descriptions of the Elements in a Resource
  6. Mappings to other standards
  7. Profiles and Extentions (definitions below)
  8. More Information about Resource Formats can be viewed here
a Resource UML diagram that summarizes the content graphically

Extensibility: as explained earlier about there being a domain driven effort in defining the FHIR resources, FHIR takes into consideration such a need by defining “Extentions” as well as enforcing constraints. For example, a “prescription” resource 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. Another example of extensibility is the Patient Consent for Record sharing, (ref5). The Patient Resource doesn’t in itself contain the information about patient consent to sharing information. But a PHR vendor could extend the Patient Resource, to maintain a record of this agreement/ consent. (ref: extensibility examples)

Source: https://www.hl7.org/fhir/overview-clinical.html

Profiles: To keep the number of base 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 to allow for different types of detailed clinical information to be captured and shared in particular setting (country, state, organisation etc). A Profile is, therefore, a set of constraints on a resource represented as a structure definition with kind = constraint. For example, create a profile for how the patient phone number, a data element in the Patient Resource, should be captured and displayed, another example is the patient blood pressure (ref, Profiling Examples)

Narrative: FHIR resources support sharing not only discrete data for computation, but also a human-readable view so that the humans on each end of a healthcare information exchange can still get a full picture of what’s going on. Narrative is expected to exist for most resource instances, although it can be omitted in a few limited circumstances. In some cases, the narrative will be generated from discrete information. In other cases, the narrative might be free-form text commentary entered directly by a practitioner, such as referral letters, pathology reports, etc. Certain parts of the narrative content could also later be exposed as discrete data. [source: 10]

FHIR has a set of INTERFACES [10] using which the information is exchanged between different systems. There are four primary mechanisms of exchange supported by FHIR, via a

  • A. REST interface,
  • B. by exchanging Documents,
  • C. by sending and receiving Messages
  • D. and by exposing and invoking Services.

A. REST: For manipulation of resources, FHIR provides a REST API with a rich but simple set of interactions:(Ref6)

Example of FHIR REST interface

Some examples of REST Interfaces for manipulation of Resources, along with the URLs

  1. create: Add a new patient, when a new patient registers at the hospital for a visit, with a new patient id. Create = POST https://example.com/path/{resourceType}
  2. read: Get a copy of the current medications list, for a particular patient. Read = GET https://example.com/path/{resourceType}/{id}
  3. update: a patient’s appointment information, due to the change in the appointment date and time, as requested by the patient. Update = PUT https://example.com/path/{resourceType}/{id}
  4. delete: Mark a Medication as inactive because its no longer part of the National Drug Formulary. Delete = DELETE https://example.com/path/{resourceType}/{id}
  5. search: Have the clerk search through the list of all the patients for one(s) that meet a set of search criteria, age range between 40 to 45 and Location =”Bangalore” and return the results of those patients that meet this criteria. Search = GET https://example.com/path/{resourceType}?search parameters
  6. history: is when the user wants to view the list of past encounters for a patient. History = GET https://example.com/path/{resourceType}/{id}/_history
  7. transaction: is equivalent to asking the doctor or the nurse to record a visit summary or a discharge note for a patient. Transaction = POST https://example.com/path/ (POST a transaction bundle to the system)
  8. operation: Ask the clerk to 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 just by ticking a box on a requisition saying “do that one”. Operation = GET https://example.com/path/{resourceType}/{id}/${opname}

B. Documents [10] are 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. Two systems or two FHIR servers could connect with each other to just exchange documents for a particular patient.

C. Message [10] is a set of information 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. 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.

D. Services [10] can be thought of as a small sticky note. 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?

FHIR from a System Architects perspective, (Source:Ref7) In the healthcare domain, we have a core set of common business objects including things like “a patient”, “a procedure”, “an observation”, “an order”, etc. (see a list of defined resources). The FHIR specification provides a framework for defining these healthcare business objects (“resources”), for relating them together, for implementing them in a computable form, and for sharing them across well-defined interfaces. The FHIR framework contains a verifiable and testable syntax, a set of rules and constraints, methods and interface signatures for “FHIR-aware” APIs, and specifications for the implementation of a server capable of requesting and delivering FHIR business objects

A FHIR REST server is any software that implements the FHIR APIs and uses FHIR resources to exchange data

Source: FHIR Overview – Architects, link

HL7 suggested list of documents to review when trying to understand the FHIR standards for the first time
See the executive summary, the developer’s introductionclinical introduction, or architect’s introduction, and then the FHIR overview / roadmap & Timelines

Why FHIR is better? (Source: Ref8)

  • A strong focus on implementation: fast and easy to implement (multiple developers have had simple interfaces working in a single day)
  • Multiple implementation libraries, many examples available to kick-start development
  • Specification is free for use with no restrictions
  • Interoperability out-of-the-box: base resources can be used as is, but can also be adapted as needed – which happens a lot – for local requirements using Profiles, Extensions, Terminologies and more
  • Evolutionary development path from HL7 Version 2 and CDA: standards can co-exist and leverage each other
  • Strong foundation in Web standards: XML, JSON, HTTP, OAuth, etc.
  • Support for RESTful architectures, seamless exchange of information using messages or documents, and service-based architectures
  • Concise and easily understood specifications
  • A human-readable serialization format for ease of use by developers
  • Ontology-based analysis with formal mapping for correctness (under development)
  • A central challenge for healthcare standards is how to handle the wide variability caused by diverse healthcare processes. FHIR solves this challenge by defining a simple framework for extending the existing resources and describing their use with Profiles. All systems can read all resources, but applications can add more control and meaning using profiles. Many healthcare contexts require extensive local agreements

Currrent Landscape

  1. There are many companies and big tech that have already adopted the FHIR Standards in a big way. For instance, Apple has integrated the FHIR standards into the iphone Health App in a way that the patient information from her multiple visits across multiple healthcare organisation are pulled into the users iphone and shown to her as and when required. Apple has even ensured that no health data is stored on the users phone/ device.
  2. Google has also published the CloudHealthcare APIs based on the FHIR R4 standard.
  3. Microsoft Azure has expanded the API for FHIR to fuel interoperability in Healthcare
  4. And here’s a HL7Wiki article, Companies interested in or using FHIR, link
  5. The MOHFW, India has recently published the National Digital Health Blueprint, which mentions the use of FHIR as an interoperability standard. It identifies 8 FHIR Resources as a starting point.
  6. In a book published by the NitiAayog, link, Building a 21st Century Health System for India, the Chapter 5 of the document highlights the evolving Healthcare Technology framework. FHIR is mentioned as the foundational standard for semantic interoperability between systems.
  7. eObjects framework and information can be found here, link
  8. Also read the Blog by Dr. Pankaj Gupta, on some new and interesting concepts around interoperability in India link
  9. Based on various updates from the Govt. Of India and across the Healthcare Industry in India, you can also join and follow the work being done at the National Collaborative Initiative For Interoperability
Source: The NDHB Document by MoHFW, India

Usecase Scenarios for FHIR

  1. Personal Health Records
  2. Document Exchange
  3. Decision Support Systems
  4. Federated Health Records (ref: NDHB, India)
  5. Usecases from Argonaut Project: [source: 16]
    1. Patient  uses  provider-approved  web  application  to  access  health  data
    2. Patient  uses  provider-­approved  mobile  app  to  access  health  data
    3. Clinician  uses  provider­-approved  web  application  to  access  health  data
    4. Clinician  uses  provider­-approved  mobile  app  to  access  health  data
    5. (future) Clinician  in  organization  A  uses  EHR  A  to  access  patient  data  in  EHR  B,  operated  by organization  B

Review the details of these usecases defined in the Ref: Usecases

Suggested Readings

  1. Rest API talk by Leonard Richardson: link
  2. Richardson Maturity Model, talks about the principle elements of a REST approach with a healthcare example thats worth reviewing, link
  3. Book: Rest in Practice, link
  4. RESTful API wiki, link
  5. Mastering REST Architecture — REST Architecture Details, link
  6. HBR, The untapped potential of Healthcare APIs link
  7. Will web APIs and HL7 FHIR change our views on data interoperability?, HealthStandards, David Shavers presentation Link
  8. HL7 FHIR, r4 Home page Link
  9. HL7, Getting Started with FHIR, link
  10. HL7, Clinical Overview, link
  11. HL7, Blogs on FHIR, link
  12. HL7, FHIR Product Brief, link
  13. HL7, FHIR for C-Suite, link
  14. HL7Wiki, Companies interested in or using FHIR, link
  15. HL7Wiki, National FHIR Projects, link
  16. HL7, Argonaut Project, link

This article is also quite similar to the concepts of FHIR, I have reviewed the literature on FHIR and tried to collate excerpts from various sources (mentioned next to the relevant excerpt as a source or reference(ref)) that will help the reader understand the fundamental definitions of FHIR. It’s a FHIR Reference Document of sorts, containing information pulled together from various sources of information.

Stay tuned for the HL7 India CONNECTATHON happening in june.

A big thanks to Kumar Satyam

Manish Sharma
Manish Sharma

Founder & Editor, The HCITExperts Blog

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top
👋 Hello
Hello!! 👋 Manish here, Thanks for visiting The Healthcare IT Experts Blog !! How can i help you?