Introduction

This article is part of my series of articles for programmers getting into the area of health informatics. I feel that this topic should be very useful from multiple perspectives including HL7 and DICOM-related programming. Therefore, you will find this article linked from both my HL7 and DICOM programming tutorials. As always, your feedback is much appreciated. Also, when you are done reading this article, don't forget to try out the HL7 interactive quiz which focuses on some of the material covered in this article.

FHIR (Fast Healthcare Interoperability Resources) is the newest of the HL7 message communication standards for exchanging healthcare information electronically. Developed by Health Level Seven International (HL7), FHIR aims to resolve the issue of healthcare data interoperability, enabling different healthcare systems to communicate and share data effectively, securely, and consistently. FHIR provides a comprehensive framework and related standards for the representation of electronic health data, facilitating the exchange of information between healthcare providers, organizations, and individuals. The goal is to support and enhance clinical care, data analytics, and other health-related processes. In this article, I will cover some background on this standard and in my future articles will cover practical applications using code based examples using Java and .NET

Building Blocks of FHIR

Before we dive into FHIR, we need to know a little bit about some standards that it is built on top of. These include REST, XML and JSON.

REST (stands for “Representational State Transfer”) is a popular web protocol and it uses a set of architectural principles that define how resources are addressed and accessed over the web. RESTful systems employ standard HTTP methods with a focus on using stateless operations, making web services scalable by minimizing the amount of stored session data. Resources, each identified by a unique Uniform Resource Identifier (URI), are core to REST, and actions upon them are performed using standard HTTP methods such as GET, POST, PUT, and DELETE. In a RESTful environment, communication is typically done using plain HTTP, but data can be transmitted in various formats like JSON or XML. The stateless and client-server architecture inherent in REST allows for reduced latency, enhanced visibility, and a generic interface that makes it highly favored for public APIs and web services, driving interoperability among diverse systems on the internet.

XML, developed by the W3C (World Wide Web Consortium), uses a set of user-defined tags to delimit data and is often utilized in a wide range of applications, such as web development, data interchange, configuration files, and much more. Its ability to effectively facilitate the exchange of data across different systems and platforms makes XML a crucial technology in various fields and industries.

JSON, an acronym for “JavaScript Object Notation”, is a lightweight data-interchange format that is easy for humans to read and write and easy for machines to parse and generate. Derived from JavaScript, JSON has become a widely adopted standard, used to transmit data between a server and web application, serving as an alternative to XML. It employs a map structure of key-value pairs, where the keys are strings and the values can be strings, numbers, arrays, or other JSON objects. Known for its simplicity and efficiency, JSON is often used in APIs and web services to provide public data and facilitate cross-platform data exchange, particularly in web and mobile applications, due to its seamless compatibility with JavaScript and other programming languages.

War does not determine who is right - only who is left. ~ Bertrand Russell

History of FHIR

The development of Fast Healthcare Interoperability Resources (FHIR) by the Health Level Seven International (HL7) group commenced in 2011. The project was primarily aimed at addressing the complexity and interoperability challenges presented by earlier HL7 versions, such as HL7 V2.x and HL7 V3 which I have covered in my earlier articles. FHIR was designed to be simple to implement, while also being able to accurately represent complex healthcare data and workflows. By leveraging contemporary web technologies and protocols, notably REST, JSON, and XML, FHIR quickly garnered attention and momentum in the healthcare IT community, becoming a pivotal standard for facilitating interoperability among diverse healthcare systems.

Some Key Terms used in FHIR

Navigating the vast and intricate landscape of the Fast Healthcare Interoperability Resources (FHIR) standard can be an arduous task. The extensive documentation contains a plethora of concepts, technical jargon, and nuanced terminologies intrinsic to the FHIR ecosystem. Having a curated list of key terms is absolutely essential as a navigational aid in such a complex environment. This list I provide below hopefully serves that purpose and should act as a robust reference point, enabling individuals to quickly grasp the essential meanings and interrelationships of various concepts, hence fostering a more profound and nuanced understanding. Furthermore, it assists in ensuring that communication regarding the FHIR standard remains precise and unambiguous, promoting a clear and consistent understanding among different stakeholders, such as healthcare professionals, developers, and data analysts. The structured organization of terminologies into a comprehensive list thus stands as a cornerstone for effective exploration and utilization of the FHIR documentation, making the learning curve more manageable and the application of knowledge more effective.

1. Bundle is a package that holds multiple healthcare resources (see definition for ‘resource’ below) together for easier sharing and transportation.

2. Code System is a list of codes that explain the meaning of different healthcare concepts, ensuring that everyone speaks the same language in medical terms.

3. Coding is a simple way of including code information, along with where the code comes from, within a healthcare resource.

4. Contained Resource is a related piece of information that’s included directly within another piece of healthcare data, instead of just being linked or referred to. See definition for ‘resource’ below.

5. Data Types can be thought of data structures used in healthcare data, like numbers, texts, boolean, or more complex structures.

6. Element is the smallest pieces of data in healthcare information, which make up the bigger structures known as resources.

7. Endpoint is a web address where healthcare information services can be accessed and shared between systems.

8. Extension is defined as a way to add more pieces of information to existing healthcare data to meet specific needs without changing the original structure.

9. Implementation Guide is defined as a manual that helps users understand how to work with healthcare data, often including special rules and structures to follow.

10. Interactions and Operations refer to actions you can perform on healthcare data (‘resources’ in FHIR and REST vocabulary), like creating, reading, updating, or more complex tasks.

11. Interoperability is defined as a the ability of different computer systems to work together, sharing and understanding each other’s healthcare data.

12. Identifier is defined as a unique mark given to a piece of healthcare data so it can be easily found and referred to.

13. Message is defined as a piece of healthcare data sent from one system to another, carrying various kinds of information together. Messaging is the process of transferring messages.

14. Narrative is defined as a readable summary included within healthcare data, helping users understand the content easily.

15. Observation is defined as a type of healthcare data representing information (a ‘resource’ in FHIR terminology) collected about a patient, like test results or vital signs.

16. Operation Outcome is defined as information that tells you the result of a particular action on the healthcare data, such as whether it was successful or if there were any issues.

17. Patient is defined as a type of healthcare data (also a ‘resource’ in FHIR terminology) that represents a person receiving medical services.

18. Practitioner is defined as a type of healthcare data (also a ‘resource’ in FHIR terminology) representing medical professionals, like doctors or nurses, involved in providing healthcare.

19. Profile is defined as a specialized version of healthcare data that’s been tailored to meet certain needs or purposes.

20. Reference is defined as a way to show the relationship between two pieces of healthcare data, where one points to the other.

21. RESTful APIs are a set of rules and tools that allow systems to communicate and manage healthcare data over the internet.

22. Resource is defined as a basic part of healthcare data representing different concepts like patients, doctors, or medications.

23. Resource Type is a specific format for organizing healthcare data, making sure it follows certain rules and structures.

24. Search Parameter is defined as specific criteria used to find and retrieve particular pieces of healthcare data.

25. Value Set is defined as a group of allowed values used to keep the content of healthcare data consistent and understandable.

Stengths

FHIR is built upon modern web technologies such as REST, JSON, and XML that I mentioned previously, which aligns better with current software development practices. It utilizes HTTP-based RESTful protocols, which are familiar to many developers and simplifies the integration with other web technologies.FHIR is designed with interoperability in mind and facilitates easier communication among various healthcare systems. It leverages modern web standards, thereby making data exchange between disparate systems more straightforward. FHIR allows for more flexibility with its resource-based model. Each resource is an independently manageable entity, and you can choose to work with as much or as little as needed for a particular use case.

FHIR’s modular architecture supports extensibility. Developers can create new resources or extend existing ones to accommodate emerging use cases or specific requirements without disrupting the existing system. FHIR offers a fine level of granularity by allowing access and manipulation of individual data elements, which wasn’t a strong suit of HL7 2.x. FHIR promotes the usage of standardized APIs, which can be utilized to facilitate data retrieval and interaction with electronic health records (EHRs) in a consistent manner. The FHIR standard is also optimized for use with mobile devices, enhancing the capabilities for mobile health applications, patient portals, and other modern health IT solutions. FHIR has been widely adopted and promoted by major EHR vendors and healthcare organizations, offering a robust and growing community that contributes to the continuous development and enhancement of the standard. FHIR is also equipped to handle clinical reasoning capabilities, which support decision-making activities, further enhancing the utility of healthcare applications. FHIR can handle both structured and unstructured data, providing a comprehensive view of patient data, including clinical notes, lab results, and imaging data.

The creation of a thousand forests is in one acorn. ~ Ralph Waldo Emerson

Challenges

Despite these advantages, it’s crucial to note that the transition from HL7 2.x to FHIR can be resource-intensive, and many organizations may operate in a hybrid environment for a considerable period, necessitating tools and strategies to work with both standards concurrently. Organizations often face challenges related to the transition from traditional HL7 standards to FHIR, which can involve significant changes to data models, interfaces, and workflows. Many healthcare organizations operate legacy systems that may not be readily compatible with FHIR. Retrofitting or upgrading these systems to work with FHIR can be complex and resource-intensive. Converting existing data formats and structures into FHIR resources may require extensive data mapping efforts, which can be complicated by the intricacies of healthcare data. FHIR demands a skillset that might be new to some developers who are familiar with HL7 2.x and other traditional data exchange standards in healthcare, necessitating training and adaptation. Though FHIR aims for standardization, variations in implementation and the use of extensions may still present challenges in achieving seamless interoperability. Certain aspects or resources of FHIR may still be maturing, potentially causing hesitancy or challenges for organizations looking to implement them.

In summary, FHIR is a pivotal standard in healthcare informatics, enabling systems to share health data in a secure, standardized, and interoperable manner, thereby facilitating improved patient care, research, and healthcare management.

Conclusion

I hope this article provided a good overview of FHIR and why it is being adopted radidly across the world. Orchestrating a harmonious interplay among various healthcare entities, the use of FHIR (along with other key standards such as SNOMED CT, LOINC, ICD, etc which I covered in a previous article) ensures data is not just shared, but also understood and utilized optimally across different platforms and applications, thereby fortifying the foundation for enhanced patient care, robust medical research, and streamlined healthcare operations. Its unprecedented flexibility, scalability, and ease of implementation catapult FHIR to be a paramount player in navigating the complexities of healthcare data interoperability, promising a future where data-driven decisions illuminate the path towards global health advancements. If you are interested in strengthening your knowledge on some of the material covered in this article, you may consider trying out an interactive quiz that I put together recently which covers a number of concepts in the various HL7 standards that have been published including V2, V3, CDA and FHIR. In my future HL7 and DICOM programming tutorials, I will try to illustrate use of FHIR using some code-based examples using both Java and .NET. See you then!