Learn about the latest FHIR version and new features of the FHIR R5, such as topic-based subscriptions, revised medication definition resources, new health-related information structures, and operations for managing large resources. HL7 and FHIR initiatives, has been in use for nearly five years since its release. Hence, there is anticipation among the community that the HL7 organization, in charge of developing and enhancing the FHIR standard, will utilize its vast expertise in healthcare standardization with the new FHIR R5 version, thereby further enabling global healthcare interoperability.
However, despite the bright possibilities of improved data exchange, new versions of healthcare data standards always worry stakeholders because of the possible challenges when switching versions and the changes in workflows that the process may require. In today’s article, we will discuss the new features of the FHIR R5, that is, the FHIR latest version, and strategies for handling shifts between versions.
FHIR R5: What’s New?
The functionality of the FHIR R5 aims to enhance interoperability and data management in healthcare. A significant aspect of this enhancement is the improved handling of FHIR bundle, which facilitates efficient grouping and exchange of healthcare data. Let’s explore some of the new features and additions included in FHIR R5:
- Topic-Based Subscriptions: One of the most notable enhancements is the addition of capabilities for topic-based subscriptions. This feature enables proactive event FHIR notifications based on data changes in the source system, which can improve patient care and outcomes.
- Revised Medication Definition Resources: The updated Medication Definition resources better support the needs of manufacturers and regulators, as well as their use in drug catalogs and pharmacopeias. These revisions can lead to improved medication management and patient safety.
- New Health-Related Information Structures: FHIR V5 introduces several new resources that define structures for different types of health-related information. With 157 resource types, FHIR offers an extensive range of options for data management.
- Operations for Managing Large Resources: FHIR V5 includes new operations for efficiently managing large resources such as Groups and Lists. These changes enable faster and more efficient information exchange, allowing clinicians to focus more on patient care and less on administrative tasks.
While these updates and additions represent only a small sample of the thousands of incremental improvements in FHIR V5, they can significantly benefit the healthcare community. However, implementing and adopting the new standard may pose some challenges.
One of the primary challenges is the need for healthcare organizations to upgrade their systems to support FHIR V5, which may require significant time and resources, including training staff on the new standard. Additionally, there may be compatibility issues with existing systems, which could necessitate further updates.
It is essential to consider all the strategies available to ensure a successful shift between FHIR versions.
Strategies for Handling Shifts Between FHIR Versions
By using the fhirVersion Mime type parameter
In the context of FHIR resources, using the Mime type to provide version information is one of the most effective ways to determine the version of FHIR. Mime type refers to the data content type of a specific request (e.g., image, text, video, or an FHIR Resource). The Mime type may also include additional information, such as the format or version of a Resource.
By specifying the fhirVersion Mime type parameter, a server can support multiple versions on the same end-point if the client indicates which version it supports.
Example of a complex Data Type:
GET [base]/metadata
Accept: application/fhir+json; fhirVersion=3.0
The fhirVersion parameter plays a critical role in versioning FHIR, as it allows for seamless interoperability between systems that operate on different FHIR versions. For instance, if a system uses FHIR version 4.0 and receives a resource with a MIME-type of “application/fhir+json; fhirVersion=3.0,” it can automatically convert it to ensure compatibility with its version.
Defining the FHIR version in a URL
Defining the FHIR version in a URL can be helpful when a system needs to support both version 4 and version 5 of FHIR simultaneously. However, this method means there must be two versions of all endpoints for each resource, one for version 4 and one for version 5. This approach burdens developers, as they have to create and maintain two versions of each endpoint.
Defining FHIR version in URL:
https://example.com/fhir/R4/Patient
By including the version in the URL, we will know beforehand which version we are working with. This means we don’t have to parse the resource twice or perform additional steps to determine which version to validate against. It simplifies the validation process and reduces the time it takes to validate the resource.
Using a URL to define the FHIR version can have certain benefits in specific scenarios, but it is not the method of choice. Therefore, before implementing this approach in their system, developers should thoroughly evaluate its advantages and disadvantages.
By including the version in the URL, we will know beforehand which version we are working with. This means we don’t have to parse the resource twice or perform additional steps to determine which version to validate against. It simplifies the validation process and reduces the time it takes to validate the resource.
Using a URL to define the FHIR version can have certain benefits in specific scenarios, but it is not the method of choice. Therefore, before implementing this approach in their system, developers should thoroughly evaluate its advantages and disadvantages.
Specifying a version-specific profile on the resource itself
In one of our previous articles, we discussed FHIR profiles and how to publish/where to find ready-to-use profiles. A profile enables the definition of additional data elements beyond the base resource by providing a set of constraints or extensions. It can also specify the version of FHIR that the resource conforms to.
Version-specific profile example:
{
"resourceType": "Patient",
"meta": {
"profile": ["http://hl7.org/fhir/3.0/StructureDefinition/Patient"]
}
}The main drawback of specifying a version in the resource is that double data parsing is required before parsing the resource. This means that before parsing the resource, it is not known which validator to apply to parse it. The profile is contained in the body of the request. To understand which version to validate the resource with, it is first necessary to read the profile from the server and then start validating the resource. This extra step can slow down the validation process and complicate it.
In some cases, versioning in a profile can be helpful, mainly when there is a need to specify the FHIR version at the resource level. A profile can be utilized to offer additional information about the resource, including its version. However, using a profile to specify the FHIR version can be quite time-consuming.
The fhirVersion element in the applicable CapabilityStatement
The element in the applicable CapabilityStatement provides information about the server’s capabilities, including the FHIR specification it covers and the operations it can perform with different resources. Including the supported FHIR version in this element is essential, primarily when the server supports multiple versions.
When the server uses only one version of FHIR, the fhirVersion element makes it easy for clients to determine which version is being used. However, when the server supports multiple versions, it is important to specify all the versions supported in the element.
Defining the FHIR version in CapabilityStatement allows clients to determine whether they can exchange data with the server without compatibility issues. For instance, if the client uses FHIR version 5 and the server supports only FHIR version 4, data exchange may fail, or the data may be incomplete or invalid. By specifying the FHIR version in CapabilityStatement, clients can avoid such problems and ensure smooth FHIR bulk data export and data exchange.
Switching FHIR Versions? Make Sure You Adhere to Industry Regulations First
Doubt the need to upgrade to FHIR R5 the latest FHIR version? Take your time since there are more important aspects to consider when leveraging data standards for interoperability. For example, regulatory compliance in healthcare allows for the secure exchange of sensitive patient information, minimizes risks of data breaches, and saves stakeholders from severe penalties.
The ONC-compliant Kodjin FHIR Server is a lightning-fast solution built with cutting-edge technology for maximum scalability. Edenlab’s team is well-versed in the latest FHIR changes and can help healthcare organizations navigate the complexities of FHIR implementation. By using the Kodjin FHIR Server, you ensure compliance with such regulations as HIPAA and the 170.315(g)(10) Standardized API for Patient and Population Services criterion. Contact us to pass the ONC Health IT Certification Program without a hitch. Also, don’t forget to check our FHIR Server Terminology Services.
