Understanding FHIR Structure Components and Resources

FHIR Components

Standards are the agreed-upon rules on which systems and processes are built. For example, web standards were developed and formalized to bring consistency to our online experiences and to make the Internet more accessible for everyone. They don’t impact how a website appears to the end user. However, they dictate how the back end of a website is structured.

Like web standards, health interoperability standards guide the development of new ways to share healthcare information. Last year, Health Level Seven (HL7) debuted the fourth iteration of their Fast Healthcare Interoperability Resources standard (FHIR 4). This particular standard builds on previous standards to give health IT vendors a common way to build the tools that help physicians, payers and providers gain point-of-care access to patient information.

Understanding FHIR structure components and resources is the first step to using FHIR for applications that work on mobile phones, iPads and other “connected” devices.

RESTful APIs

FHIR 4 brings flexibility and functionality to the game. FHIR is bi-directional (read or write); it is flexible to different levels of granularity (individual data elements or whole documents); and it supports common pluggable apps straight from App Store or Google Play. At its core, FHIR is simply a data API standards framework for the same kind of RESTful APIs that drive online commerce.

With FHIR 4, building out a healthcare interoperability interface using off-the-shelf programming APIs takes hours—not days or weeks (as was the case with previous HL7 development standards).

The base FHIR specification is a “platform specification” describing a set of base resources, frameworks and APIs. It creates a common platform or foundation on which to implement different solutions. Therefore, FHIR usually requires adaptation to particular contexts of use in a healthcare setting.

FHIR Profiles and Resources

Profiles and Resources are both considered “components.” Let’s look at each in turn.

FHIR defines a set of modular data components called “resources.” These are the most important aspects of the FHIR specification. Resources are any content that is exchangeable; they are the building blocks of independent, discrete data. Any information that can be named can be a resource, including:

• a document
• an image
• a temporal service
• a collection of other resources
• a non-virtual object (such as a person)

Resources are used to store and/or exchange data between different health record systems. FHIR Resource Types can be:

• Administrative
  • Patient, Practitioner, Organization, Location, Coverage, Invoice
• Clinical
  • Allergy Intolerance, Condition, Family History, Care Plan
• Infrastructure/Conformance
  • “CapabilityStatement” or “StructureDefinition”

A list of available resources can be found here:

• DSTU2 Resource List
• STU3 Resource List

What about FHIR profiles? A FHIR “profile” is a set of rules allowing a FHIR resource to be constrained or to include extensions so it can add additional attributes. The profile splits the component list into two sub-lists of one element each.

A FHIR profile allows you to author and publish a customized, more specific resource definition by specifying a set of constraints and/or extensions on the base resource. A FHIR resource can express conformance to a specific profile, which allows a FHIR server to programmatically validate a given resource against the associated profile definition.

Resource Data Formats

As we’ve seen, FHIR solutions are built from a set of modular components (resources), which represent healthcare data and can easily be assembled into working systems to solve real-world clinical and administrative problems.

Resources are used to build an “instance-level” picture of the data. Resources may aid in exchanging the data or provide a means to store the data. Resources must include the following things:

• A URL (to identify the resource)
• Metadata (to aid in searches and cataloging)
• An XHTML summary (so people can read it)
• Definitions (for data elements)
• An extensibility framework specific to healthcare

FHIR supports 145 resource types, typically in XML, JSON, or RDF/Turtle. formats These are the logical, common contents of the resource mapped to formal definitions; e.g. RIM & other formats.

Attributes

Resources also include a set of common and resource-specific metadata (attributes). FHIR resources can store or exchange clinical and administrative data. The aim is to create a framework that can be interpreted by any system, in a variety of applications (including mobile apps, cloud communications, EHRs, and more). Resources are based on the following structures:

• XML
• JSON
• HTTP
• Atom
• OAuth

Conclusion

So how do these elements come together to create the revolutionary healthcare operability standard that is FHIR? How does FHIR address the challenge with current medical terminology standards to effectively capture, use and exchange health data?

According to Evelyn Gallego, founder of EMI Advisors, who serves as the program manager of the The Gravity Project:

“FHIR resources incorporate coded data elements to define the information exchange between two disparate technology systems. The medically coded data elements provide the semantics for the content made available for use within a FHIR resource.

“FHIR, by design, supports structured data exchange and thereby needs to reference unambiguous and well defined terms so that the information is both human and machine readable.”