Key Takeaways
- FHIR includes resources, profiles, implementation guides, and data types, each playing a critical role in structuring, customizing, and securely exchanging healthcare data.
- Resources are the building blocks of the FHIR standard. They cover about 80% of healthcare data needs, with the remaining 20% customized through profiling.
- Profiling of FHIR resources allows the extension or constraint of base resources to meet specific use cases.
- FHIR Implementation guides provide rules and guidelines for resource usage, API features, and terminologies, ensuring compliance with national standards and enhancing interoperability
At the forefront of challenges healthcare organizations face now is data interoperability. Healthcare data has remained fragmented because of different data standards and systems used by individual healthcare organizations. But FHIR has revolutionized this by enhancing interoperability. If you want to understand FHIR components and resources, you are in the right place.
We will take a deep dive into what makes up the FHIR specification, provide examples of resources such as the patient FHIR resource, and demonstrate how Kodjin and our team’s expertise can help streamline your healthcare data integration efforts. With extensive experience in developing and implementing FHIR-based solutions, Kodjin is well-equipped to address your interoperability challenges and enhance your data exchange processes.
FHIR Resources
What are HL7 FHIR resources? Resources are the foundation of the FHIR standard. They are the main structural element of FHIR solutions and are also often referred to as the “building blocks” of FHIR. Each block (resource) is defined by its particular context and contains various healthcare information represented in a standardized way.
Read also: FHIR vs HL7: Which is the best
Below is a FHIR resource list structured by type for the latest version of the specification FHIR V5.
For example, the HL7 FHIR Patient resource must contain information such as the patient’s name, address, telephone number, allergies, condition etc. As such, when two FHIR-based systems are exchanging data, they will “know” what each field represents without additional tweaking or a need for data conversion. Data from a laboratory information system (LIS) can be easily integrated with and interpreted by a hospital’s electronic medical records (EMR) system.
The key requirements list for FHIR can be defined as:
- Identical definition and representation, including the names of attributes, types of data, and relations between data arrays
- Standardized FHIR resource types attributes (1+2 = Base FHIR resources, defined by the standard specifications, have a standard list of elements, types, and relations between data arrays.)
- Standard metadata, defining the technical context of each resource: ID, version, profile, text narrative, last updated
- Human-readable format.
The resources and resource elements, along with their naming, data types, and the relationships between them, are all defined by the FHIR standard. Each resource can be represented in different formats such as XML and JSON.
Below we will take a more detailed look at an example of an FHIR Resource – a FHIR Patient resource, and the kind of information about the patient it can provide.
(Disclaimer: all information in the given example is fictitious and does not represent a real person)
{
"resourceType": "Patient",
"id": "870bfc6c-654b-4b29-aac3-3315eed565d6",
"meta": {
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient|5.0.1"
]
},
"extension": [
{
"url": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-race",
"extension": [
{
"url": "ombCategory",
"valueCoding": {
"system": "urn:oid:2.16.840.1.113883.6.238",
"code": "2106-3",
"display": "White"
}
}
]
}
],
"identifier": [
{
"use": "usual",
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "MR",
"display": "Medical Record Number"
}
],
"text": "Medical Record Number"
},
"system": "http://hospital.smarthealthit.org",
"value": "1032702"
}
],
"active": true,
"name": [
{
"family": "Kovach",
"given": [
"Amy",
"V."
],
"suffix": [
"Ms."
],
"period": {
"start": "2020-07-22"
}
}
],
"telecom": [
{
"system": "phone",
"value": "378-354-1234",
"use": "home"
},
{
"system": "email",
"value": "[email protected]"
}
],
"gender": "female",
"birthDate": "1987-02-20",
"address": [
{
"line": [
"183 Mountain View St"
],
"city": "Mounds",
"state": "OK",
"postalCode": "74048",
"country": "US"
}
],
"maritalStatus": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-MaritalStatus",
"code": "M",
"display": "Married"
}
],
"text": "Married"
},
"communication": [
{
"language": {
"coding": [
{
"system": "urn:ietf:bcp:47",
"code": "en-US",
"display": "English"
}
],
"text": "English"
}
}
]
}FHIR Profiles
Among FHIR components this FHIR standard follows the 80/20 rule, meaning FHIR resources are intended to cover around 80 percent of data elements in the healthcare systems, while the other 20 need to be tweaked to cover specific use cases. This way, FHIR provides both the base and the means to expand that base to suit your needs.
In the FHIR standard, resources are described loosely to allow them to be adapted for a specific context. Extending or constraining elements in the base resource is called profiling. Hence, a modified FHIR resource is referred to as an FHIR profile. Profiling helps define the missing extensions that should be added and how API functions and terminologies should be used (terminologies in FHIR® are defined using value sets and code systems).
A typical FHIR profile will consist of:
- general requirements describing its goal, category, and the original resource configured by the profile
- a snapshot section with a full configuration of the profiled resource
- a differential section focused on the differences between the profile and the base resource (This section and the FHIR profiler tool help make profile configuration easier for data analysts)
- Slicing, binding, and FHIRPath rules for constraining or extending resources.
FHIR resources, while covering a lot of use cases, are not one-size-fits-all. Profiling is an essential part of the process of FHIR adoption and development. The most commonly used FHIR profiles vary depending on the healthcare organization and the specific use case. However, several FHIR profiles are widely adopted and have become industry standards.
One of the most widely used FHIR profiles is the US Core Profile, which is used for exchanging patient information between systems in the United States. It includes a set of common data elements that are required to support a variety of use cases, such as electronic health records (EHRs), patient portals, and public health reporting.
Another widely used profile is the Da Vinci profile, which is a set of FHIR resources and profiles that are designed to support the exchange of healthcare information between payers and providers in the US. It includes resources for claims, payments, and patient information.
Read Also: Mapping Healthcare Data to HL7 FHIR Resources
The Care Connect profile is widely used in the UK for the exchange of healthcare information between systems. It includes a set of FHIR resources and profiles that support the exchange of patient information and clinical documents.
The Argonaut profile is another widely adopted FHIR profile that is designed to support the exchange of healthcare information between systems. It is focused on the exchange of patient information and clinical documents and is used in the United States and Canada.
To help business analysts and developers create profiles for their specific context, there are various profile authoring tools. Our team has published a detailed comparison of such tools, where we compare the Kodjin Profile Editor, the Forge from Fire.ly, and Trifolia-on-FHIR.
Below, we’ll take a look at the Carin for Blue Button Patient profile snapshot. The base FHIR Patient resource contains an exhaustive set of data elements, but not all of them are relevant in this particular case. If you take a look at the snapshot provided below, you will notice some elements marked with a red S, those are fields that must be supported in the API to conform to the C4BB Patient resource. Some elements had their cardinality changed to one, meaning this element must appear at least one time.
FHIR Implementation Guide
Implementation guides (IGs) are a collection of FHIR resources (profiles, value sets, examples, documentation, etc.) and rules that are to be used for specific purposes.
IGs describe how FHIR resources are to be used in a particular clinical context and are key to providing a fast and seamless implementation of FHIR Profiles. For instance, IGs can describe which patient attributes should be filled in to comply with national standards or which terminologies should be used.
Typically, implementation guides are published online after being created with an FHIR IG publisher. You can find some examples of published IGs on the FHIR registry.
Implementation Guides specify:
- Rules about which resource elements are or are not used, and what additional elements are added that are not part of the base specification
- Rules about which of FHIR’s RESTful API, messaging, and document features are used, and how they are used
- Rules about which terminologies are used in particular elements
- Descriptions of how the Resource elements and API features map to local requirements and/or implementations.
FHIR Data Types
FHIR data types are used to define the resource elements and allow FHIR-based systems to understand what different elements of the FHIR resources represent. The FHIR data format ensures consistent representation and exchange of these data types across different systems.
In FHIR, data types are divided into primitive, general-purpose, metadata, and special-purpose data types.
The primitive types of data include string, integer, boolean, etc., each capable of holding a single value.
Below are illustrations that demonstrate the various data types used in the FHIR standard. For more information, you can refer to the FHIR specification page on data types.
Primitive Types
General-Purpose Datatypes
Metadata Types
Special Purpose Datatypes
FHIR REST API
A REST API (also referred to as RESTful API) is an application programming interface (API) that follows the requirements of the REST architectural style and allows for interaction with RESTful web services. The advantages of RESTful architectures include lightweight interfaces, allowing fast transmission and processing of data.
FHIR utilizes REST for data exchange in its API and provides different endpoints for different types of transactions with the resources. The FHIR REST API call consists of a request from a client and a response from a server.
For example, third-party applications, such as a Patient’s Portal app, can request data about the patient from an EHR system through an integrated FHIR API. The request specifies which type of data and how much of it needs to be pulled from the EHR server.
Security and Privacy in FHIR
FHIR as a standard does not inherently provide security features. Its primary focus is on defining the structure for healthcare data and how it can be exchanged. FHIR specification assumes that security will be provided by the underlying system or through other layers of the technology stack. In other words, while FHIR outlines how resources like patient records should be structured and how they can be accessed or modified via APIs, it does not dictate how these operations should be secured.
This approach offers flexibility in implementing security features, allowing organizations to layer their own protocols such as encryption, access control, and auditing on top of FHIR. Many systems use HTTPS for data encryption and OAuth 2.0 for authentication. FHIR often leverages existing security frameworks like SMART on FHIR, which standardizes integration with OAuth 2.0 and OpenID Connect for secure authorization and single sign-on.
Conclusion
FHIR has emerged as a secure data standard for achieving true healthcare interoperability for a reason. In this article, you learned how the main components of the FHIR standard are facilitating interoperability around the globe.
Our expertise in creating FHIR facade interfaces ensures streamlined integration of complex healthcare data systems, enhancing the user experience and efficiency.
Next, you can learn more in-depth about the FHIR Standard, FHIR structure components, and resources in our Ultimate Guide – What is FHIR.
Our FHIR development team is always open to cooperation and collaboration to help your healthcare organization achieve a fast and agile data exchange. Contact us to see how we can help with your project!
FAQ
What is the basic building block of FHIR?
FHIR Resources are the basic building blocks of the FHIR specification. They comprise an indivisible unit that contains various clinical data in a structured manner. Each resource is defined by the context of its use. For example, the patient resource contains the most important information about the patient, such as name, address, age, and so on, while Observation resource contains information about vital signs, test results, clinical findings, etc.
How many resources are in FHIR?
In the latest version of FHIR (v. 5), there are 153 resources. The specification remains in active development, and as such, new resources are added continuously.
What is the difference between FHIR and SMART on FHIR?
SMART on FHIR combines FHIR and the SMART platform. Essentially, it’s a set of open standards and specifications that work together to help healthcare developers create and integrate third-party healthcare apps. FHIR standardizes data, while SMART standardizes how this data can be accessed. You can read more about the differences between FHIR and SMART and the technical components for SMART on FHIR on our blog.
