Welcome to the eCQM FHIR Sparks!
This is the first installment in a series of video shorts that will introduce Fast Healthcare Interoperability Resources, or FHIR
an interoperability standard created by the standards development organization Health Level 7 (HL7®).
This series is presented by the Centers for Medicare & Medicaid Services (CMS).
It is intended to support healthcare quality leaders, health IT vendors, and measure developers begin to explore the use of FHIR
for quality measurement.
We hope this series “sparks” your interest and engagement in this emerging area of interoperability!
In this segment, we’ll define FHIR and describe work among the HL7 standards community to apply FHIR to quality measurement.
What is FHIR?
FHIR is an international standard that is intended to facilitate interoperability between disparate systems.
FHIR describes data formats for clinical and administrative healthcare data, known as “resources.”
FHIR also describes methods for exchanging electronic data through modern web-based application programming interfaces, or “APIs.”
FHIR builds on previous data format standards from HL7 that have been used for information exchange
like HL7 version 2, commonly used for transmitting ADT and other messages between providers.
A core goal of FHIR was to create a standard that could be adopted across multiple health IT platforms
to make real time interoperability easier.
By adopting existing standards and concepts already familiar to developers outside of healthcare
FHIR reduces the learning curve, makes interoperability easier
and enables faster and simpler application creation.
To understand this better, let’s take a closer look at resources and profiles.
In FHIR, healthcare data is broken down into categories, like patients, lab results, and encounters.
Each of these categories is further defined within a FHIR Resource, which includes the data elements
terminology, and other constraints that together make up an exchangeable element of a patient record.
FHIR resources are intended to be discrete enough to allow meaningful exchange, and universal enough to be widely accepted and
supported by multiple health IT applications.
FHIR resources are also designed to be easily understood by technical experts and non-technical people alike.
Let’s take a closer look at the Patient Resource.
To do so, we’ll visit the HL7 FHIR Release 4 website, and open the Patient Resource.
At the top of the page, you’ll see HL7 provides a narrative description of the scope and use of the Patient resource.
This resource is focused on describing the demographic information necessary to support administrative,
financial, and clinical procedures.
Under Resource Content, you see a detailed description of the elements included within the patient resource.
This may look technical, but with a little practice, it’s not too difficult to interpret.
Let’s briefly walk through how information is presented within a Resource.
Starting on the left, you see a tree structure. Each item in the tree is an “element” of the Patient Resource.
Each item in the tree is further defined by the columns to the right of the element name.
For example, the Patient resource includes an element of birthDate.
To the right of birthDate, the icon in the “flag” column presents a form of HL7 notation that provides direction to implementers on how to handle the element.
In this case it indicates that birthDate is included in summary data when the Patient resource is exchanged.
The Card, or Cardinality field, provides lower and upper bounds for how often the element is allowed to appear.
For birthDate, this field indicates that there can be 0 to 1, and no greater than 1, date of birth for a given patient.
Next, the “Type” field further clarifies the type of data contained in the element. BirthDate is noted to be a date.
Finally, a brief description explains the element in plain language.
You can see that there are multiple ‘elements,’ like the birthDate element, within the Patient Resource.
FHIR defines each element discretely to support retained meaning when data is exchanged.
By defining these elements, FHIR is not assuming they are all present in every record, or that they are all exchanged in each
exchange of patient information.
Rather, the definitions within the Resource enable organizations involved to align how they store and exchange patient information, so it
can easily be understood and used by those sending and receiving data from disparate systems without additional effort.
Next, let’s talk profiles.
Remember, resources provide the building blocks and common definitions for how clinical data should be structured and exchanged.
They are designed to be general, and as FHIR is an international standard, resources support a broad range of uses.
When data is to be exchanged for a specific use, such as quality measures, resources often need to be further defined, or extended, to
include the specific elements and definitions needed for that use case.
In these situations, HL7 stakeholders create what’s called a “profile.”
A profile is nothing more than a resource that has been changed in order to meet that specific use case.
Profiles enable us to clarify specific terminology to be used, or which elements are “required” for exchange in that use case.
Let’s think back to the “Patient” resource example.
Can you think of a constraint that might be necessary to use a birthDate in quality measurement? There is one…
A persons’ age often determines whether they are eligible for the clinical action indicated in a quality measure
such as breast cancer screening, or influenza immunization.
Because patient birthDate is used to calculate age, for the purpose of measurement, birthDate is a required element.
There may be other data exchange scenarios where age is nice to have, but not required.
birthDate is one example of an element on the Patient resource that must be profiled for the purpose of quality measurement.
The birthDate element is just one example of the unique constraints that apply to quality measurement that may not apply to other data
exchange scenarios.
When constraints exist, profiles are created. And when multiple profiles are created to support a use case
these profiles are published as an Implementation Guide.
For quality measurement, the QI-Core, or “Quality Improvement Core” implementation guide defines the profiles needed to create
interoperable, quality-focused applications.
QI-Core is just one of several implementation guides that support quality measurement.
Collectively, this set of guides is referred to as the “Clinical Reasoning” module.
Now you have a basic understanding of how FHIR is used to provide data definitions.
Resources provide the basic building blocks for data exchange.
Profiles layer in context for data exchange in specific uses.
Implementation guides are collections of profiles and other context-specific information that enable exchange.
And Clinical Reasoning is a set of FHIR implementation guides that support quality measurement and improvement.
In our next short, we’ll take a closer look at the additional guides in the Clinical Reasoning module
and specifically, how these FHIR implementation guides can support electronic clinical quality measurement.