In the world of healthcare, access to accurate and timely information can mean the difference between life and death. It is a complex and dynamic field that relies heavily on the exchange of information between various stakeholders. That's where FHIR, or Fast Healthcare Interoperability Resources, comes in, a standardized framework designed to enable the efficient sharing of healthcare-related information. FHIR has gained immense popularity due to its ability to handle clinical data, healthcare-related administrative information, public health data, and research data, making it a game-changer for the healthcare industry. It is intended for use in diverse healthcare settings, from in-patient and ambulatory care to long-term and community care.
FHIR-based APIs have allowed EHR vendors to develop compatible products, enabling a wider range of healthcare applications to work together effectively. FHIR supports four interoperability paradigms - REST, Documents, Messages, and Services - making it a versatile tool that can be customized to fit the specific needs of different healthcare workflows. In this blog post, we'll explore how these different paradigms are being implemented around the world to achieve greater interoperability in healthcare systems.
The RESTful interface is the most high profile way to exchange data. It is a client-server architecture where clients send requests to servers, and servers respond with data. In the context of FHIR, REST means that FHIR resources (e.g., Patient, Observation, Medication, etc.) are identified by unique URLs and can be retrieved, created, updated, or deleted using standard HTTP methods (GET, POST, PUT, DELETE).
One of the benefits of using a RESTful architecture is that FHIR can be easily integrated into existing web-based systems and can be accessed using standard web technologies, such as web browsers, mobile apps, or web services. Additionally, FHIR's RESTful architecture makes it easy to scale, secure, and maintain FHIR-based applications.
Here are some example API requests that use these HTTP methods and resource types:
Note that these requests are just examples, and the actual URLs and parameters used in a FHIR API will depend on the specific implementation and requirements of the application.
Example: Here's an example of a FHIR RESTful API request and response for retrieving patient information:
Request:
GET https://example.com/fhir/Patient/123
Response:
HTTP/1.1 200 OK
Content-Type: application/fhir+json
{
"resourceType": "Patient",
"id": "123",
"name": [
{
"family": "Smith",
"given": [
"John",
"Doe"
]
}
],
"gender": "male",
"birthDate": "1980-01-01",
"address": [
{
"line": [
"123 Main St"
],
"city": "Anytown",
"state": "CA",
"postalCode": "12345",
"country": "US"
}
],
"telecom": [
{
"system": "phone",
"value": "555-123-4567"
}
]
}
In this example, the client sends a GET request to retrieve the patient resource with the ID "123". The server responds with a JSON-encoded representation of the resource, including the patient's name, gender, date of birth, address, and phone number. The response includes a status code of 200 OK, indicating that the request was successful. The Content-Type header indicates that the response is in FHIR JSON format.
In the United States, the RESTful FHIR paradigm is being used to promote interoperability in healthcare by enabling the exchange of electronic health information between different systems and providers. This is being accomplished through the use of FHIR-based standards such as the US CORE FHIR Profiles. These profiles define a set of FHIR resources and data elements that are required to support specific healthcare workflows, such as patient identification, clinical data exchange, and medication management. By adopting these standards, healthcare organizations can ensure that their systems are able to communicate with each other using a common language and format, which can improve patient care and outcomes. Additionally, the US government has implemented policies such as the 21st Century Cures Act and the ONC (Office of the National Coordinator for Health Information Technology) Interoperability Rule, which require the use of FHIR-based APIs for electronic health information exchange.
To know more: US Core Implementation Guide
The document paradigm in FHIR defines a structured and standardized way of exchanging clinical documents between different healthcare systems. It is based on the FHIR DocumentReference resource, which represents a reference to a document and its metadata. The DocumentReference resource can be used to represent different types of clinical documents, including:
- Discharge summaries
- Referral letters
- Progress notes
- Imaging reports
- Lab reports
The DocumentReference resource contains metadata about the document, such as the document type, author, date, and title. It also includes a reference to the actual document content, which can be stored as a binary attachment or as a URL pointing to the document location.
Let's see how India is using Document FHIR paradigm to it's full potential:
The Ayushman Bharat Digital Mission in India is using the document paradigm of FHIR (Fast Healthcare Interoperability Resources) to achieve interoperability in the following ways:
- FHIR Documents: Ayushman Bharat Digital Mission is using FHIR Documents to standardize the exchange of clinical documents, such as discharge summaries, lab reports, and radiology reports. This helps in reducing the variability in the structure and content of these documents, making it easier to exchange information between different healthcare providers.
- FHIR Bundles: FHIR Bundles are used to group related resources together, such as a patient's health record. Ayushman Bharat Digital Mission uses FHIR Bundles to facilitate the exchange of patient health records between healthcare providers, enabling a more comprehensive view of a patient's medical history.
In summary, Ayushman Bharat Digital Mission is using the document paradigm of FHIR to standardize the exchange of clinical documents, patient health records, and patient data, enabling interoperability between different healthcare providers.
To know more: FHIR Implementation Guide for ABDM
The messaging paradigm in FHIR (Fast Healthcare Interoperability Resources) is a way of exchanging healthcare information between different healthcare systems using messages. This paradigm has several features that make it useful in healthcare interoperability, including:
- Messages: FHIR messaging is based on messages, which are similar to those used in HL7 V2 and V3 messaging. Messages are used to transport data between different healthcare systems, such as electronic health record (EHR) systems or medical devices.
- Bundle of resources: FHIR messages are made up of a bundle of resources, which are the individual pieces of healthcare data being exchanged. These resources can be structured data elements, such as patient demographics or clinical observations, or unstructured data such as images or text documents.
- Request/response behavior: FHIR messaging allows for request/response behavior, where a sender sends a message requesting specific data from a receiver, and the receiver responds with a message containing the requested data. This allows for targeted exchange of data and can help to minimize unnecessary data exchange.
- Event-driven: FHIR messaging is event-driven, meaning that it is triggered by specific events or actions, such as sending a lab order or receiving a lab result. This can help to automate workflows and improve the efficiency of healthcare processes.
- Asynchronous: FHIR messaging can be used in an asynchronous mode, meaning that messages can be sent and received at different times without requiring immediate response. This can be useful in situations where real-time exchange of data is not necessary, such as exchanging data between healthcare systems that are not in the same location.
Example: The National Platform for Health and Insurance Exchange Services (NPHIES) is a healthcare interoperability standard in Saudi Arabia that is based on the messaging paradigm in FHIR.
In the messaging paradigm of NPHIES, healthcare information is exchanged between different healthcare systems using messages.
One example of how NPHIES uses the messaging paradigm is in the exchange of claims and payments between healthcare providers and insurers. When a healthcare provider submits a claim to an insurer, they can do so using a message that contains all the necessary information about the claim, such as the patient's information, the services provided, and the cost of the services. The insurer can then respond with a message containing the payment information.
The service paradigm in FHIR (Fast Healthcare Interoperability Resources) is a way of exchanging healthcare information between different healthcare systems using web services. This paradigm enables ultra-complex or ultra-simple workflows and can use HTTP or other protocols to exchange data. In the service paradigm of FHIR, healthcare systems expose their functionality as a set of services, which can be accessed by other healthcare systems to exchange healthcare information. These services can be customized to package and process FHIR resources in specific ways, such as individual resources or bundles of resources.
The service paradigm enables healthcare systems to create custom workflows that are tailored to their specific needs. For example, a healthcare system might use a service to process patient data and generate a report, or to validate a medication order and send it to a pharmacy.
NOTE: A "service" refers to the orchestration of the exchange of FHIR resources, which is achieved through a combination of RESTful interfaces, messages, and documents, among other transfer methods. So calling the 4th ‘other’ category “services” is… misleading. The 4th FHIR Paradigm is Storage Paradigm.
The storage paradigm refers to the storage of FHIR resources directly in databases, leveraging new database technologies and features to perform analysis directly on the resources. This approach offers several benefits, including faster and more efficient access to data, improved scalability, and increased flexibility in data modeling.
While the HL7 (Health Level Seven International) organization has traditionally focused on interfaces and avoided vendor design, the FHIR community has now begun to embrace the storage paradigm. There is significant interest and energy in leveraging new database technologies to build robust storage solutions for FHIR resources.