Preface FHIR stands for Fast Healthcare Interoperability Resources. FHIR is a way to make sharing healthcare data easier and safer. This post will focus on introducing FHIR concepts specifically for developers. FHIR have a really good documentation here. I personally like to work with JSON, so all the examples and explanations on this blog will be based on JSON structure since that feels to me like an easier structure to grasp. Thank you for reading, and enjoy exploring FHIR from a developer’s perspective! What is FHIR? Like I already said, FHIR stands for Fast Healthcare Interoperability Resources. But what does that mean? It’s a standard developed by HL7 (Health Level Seven International). It is designed to facilitate the exchange of healthcare information between different systems. FHIR defines a set of “resources” (data structures) that represent various healthcare concepts, such as patients, medications, and observations. A crude example would be JSON. It’s also a common data format defined by Douglas Crockford that basically every developer uses now which improved data sharing between systems. Similarly, FHIR aims to standardize healthcare data exchange. However, FHIR operates at a higher level of structure and detail to address complex healthcare data. Why FHIR? So, this is not a first. There’s plenty of similar standards defined and used everywhere. Examples would be HL7 V2 and CDA, also developed by HL7. The key difference why we would prefer FHIR over other would be Flexibility FHIR have a flexible format data compared to database fixed format data. Easy development FHIR adopt open web technologies like HTTPS, REST and JSON/XML formats. This makes it so that developers, outside of healthcare, can learn the standard faster and enables faster and simpler application development. Interoperability FHIR offers multiple options for exchanging data among systems. For example, it supports messaging (similar to HL7 V2), documents (like CDA), etc. So a better standard altogether. There’s also versions of FHIR like DSTU2, R3, R4, R4B and R5. R5 is the latest but Google Cloud Healthcare API only supports up to R4 and AWS HealthLake API only supports R4, at the time of writing this blog post. What is a Resource? Here’s a list of resource available in FHIR R4 – https://hl7.org/fhir/R4/resourcelist.html There is a total of 145 resources, that’s a lot. But the thing is you don’t need to know all of them. For your implementation maybe you need to know like around 10 – 15 resources. Find and list them before you start. A resource in FHIR is equivalent to a Model or an Entity in a program. A single class can represent one resource. So for a Patient resource in FHIR, we can have a PatientResource class. Just like in OOPS concept these resources are also derived classes. They extends 2 other basic resource structures called Resource and a DomainResource. They basically introduces fields that should be in every resource. They also handle concepts like contained resources and extensibility but we can dive in deeper on those later. Just like in an RDBMS (Relational Database Management System), resources can be linked. A sample relation representation would be as follows It’s a little chaotic but this is how it goes. There are fields in a resource that you use to link to another resource. These fields will be of a Reference type. You can read more about it here. Integrating FHIR FHIR is designed to facilitate the exchange of healthcare information, and it aligns with several key healthcare standards and regulations, including HIPAA and GDPR. It can also seamlessly integrate with any of the existing standards like the older standards from HL7 itself or standards like DICOM. In most cases, you won’t rely solely on FHIR for your implementations. However, you can choose to use it extensively where it makes sense. When to Use FHIR Interoperability Needs: Use FHIR when there is a need to exchange data between different healthcare systems. Its standardized format ensures that data can be shared and understood across various platforms. Modern Web Technologies: FHIR is ideal for applications that leverage modern web technologies like RESTful APIs, JSON, and XML. It simplifies the development process and enhances the performance of web-based healthcare applications. Regulatory Compliance: When compliance with regulations like HIPAA and GDPR is required, FHIR provides built-in support for security and privacy measures, ensuring that data exchange meets legal standards. Integration with Existing Standards: FHIR can be used alongside other standards such as HL7 V2, CDA, and DICOM. This makes it a versatile choice for projects that need to integrate with legacy systems or specialized standards like medical imaging. How to Use FHIR Define Use Cases: Start by identifying the specific use cases where FHIR will be applied. This could include patient data exchange, clinical decision support, or mobile health applications. Choose the Right Resources: FHIR provides a wide range of resources to represent different healthcare concepts. Select the appropriate resources that match your use cases, such as Patient, Observation and Encounter. Leverage FHIR APIs: Utilize FHIR’s RESTful APIs to enable seamless data exchange. These APIs allow for easy integration with other systems and support CRUD (Create, Read, Update, Delete) operations on FHIR resources. Test and Validate: Thoroughly test your FHIR implementation to ensure it meets the required standards and performs as expected. Use available FHIR validation tools to check for compliance with the FHIR specification. If you’re using available APIs, they will handle many security and validation tasks. However, it’s still important to add extra measures to ensure everything is fully protected and compliant. Effective Use You will see that most of the fields specified in resources are optional. You don’t need to populate them in order to create a resource. But having those details is what using the FHIR makes sense. We will later learn about Coding and CodeableConcept. These fields are important for collecting consistent clinical data, which helps different systems work together and makes data analysis easier. Using these fields well means healthcare apps can give more useful information, improving care quality and decision-making. The values for these fields come from a predefined set, similar to an ENUM. Ideally, you should use a value from this set. However, sometimes you might not find a suitable value. In such cases, you can create your own value set (as defined in FHIR as a system) and use it. The problem with this approach is that other systems won’t recognize your custom value set, which undermines the goal of interoperability. You can request HL7 to add the values you need to the existing value sets. This way, you can use them without creating custom sets, ensuring better compatibility with other systems. However, this process might take some time and approval. Summary In this introduction to FHIR, we’ve covered the basics of what FHIR is, why it’s important, and how it works with resources. We’ve explored the flexibility, ease of development, and interoperability that FHIR offers. Understanding these fundamental concepts is crucial for developers working with healthcare data systems. Stay tuned for Part 2, where we’ll explore FHIR resources in greater detail, including their resource structure, data types, and how to effectively use them in your healthcare applications. We’ll also provide practical examples to help you better understand how to implement FHIR in real-world scenarios. References https://hl7.org/fhir/ – Official FHIR Documentation
