Using FHIR to Improve Patient Engagement

This article is a summary of the GeekSpeak by Gaurav Porwal, Engineering Manager at GeekyAnts. Sections have been edited and restructured for clarity and ease of reading.

FHIR, or Fast Healthcare Interoperability Resources, is transforming healthcare delivery rapidly. With FHIR, all stakeholders in the healthcare industry — patients, healthcare professionals, and government institutions — can enjoy the perks of better information dispersal, easier coordination between departments, and uncomplicated service delivery.

For example, FHIR is bringing standardization and uniformity into patient data exchange between hospitals, clinics, and other institutions in the healthcare industry. This eliminates the need for patients to carry their physical prescriptions and medical reports across hospitals.

Even when a patient switches to a hospital, FHIR makes it easy to transfer patients' data from Hospital A to Hospital B through its standard operating procedure and flexible architecture. 

FHIR is a draft data standard. It proposes rules and parameters that govern the collection, management, and sharing of healthcare care. Designed to work alongside other standards like HL7 v2 and v3, DICOM, and SNOMED CT, the FHIR standard modernizes various healthcare workflows through a web-based approach using the principle of RESTful web services.

Since its launch in 2014, FHIR has steadily risen in adoption volume. It is gaining strong traction among most organizations in the health industry. Even product vendors developing new solutions are carving their projects to use FHIR.

For example, Google has announced support for FHIR in their Google Cloud Healthcare API. Any healthcare organization using Google Cloud and FHIR-based data will enjoy a simpler data integration process.

The creators of FHIR, Grahame Grieve and HL7 International, envisioned FHIR to simplify the implementation of health information systems and function in a connected ecosystem where data exchange and transfer is a one-click affair. The latest version of the standard is version 4.

To achieve this vision and goal, FHIR works in six pillars —

1. Use a Resource Oriented Architecture (ROA) to standardize data management
2. Increase interoperability to ensure standardization in data exchange
3. Keep the protocols modular to increase flexibility in data collection
4. Accommodate extensibility for better customization of data interaction and future-proofing
5. Focus on being patient-centric and human-readable to ensure personalized service-delivery
6. Keep the technology open-source to eliminate restrictions in tech stack implementation

Among these six pillars, Resource Oriented Architecture and Interoperability are the two main pillars. 

Resource Oriented Architecture

A resource can be thought of as the smallest data unit that can be grouped together into one category. For example, a person’s data set or a lab test. Each can be grouped into patient data and clinical documents respectively. Hence, these are resources.

It is important to note that FHIR does not restrict what data to capture. However, FHIR does instruct on how to organize the collected data in the organizational-level database layer. This ensures that the collected data, in whatever shape or form, when shared with other organizations in the ecosystem, will be easily accessible and readable.

For example, there are no restrictions if you want to store language with a patient. But the data cannot be embedded into the standard ones. The data source will need to be extended to accommodate the language parameter.

This resource-based approach helps streamline communication. Each resource can be identified using a unique URL. The URL structure includes the base endpoint, resource type, and identifier. Each resource will also have metadata, narratives, and extension. This will be part of the Jason schema or XML format.

Note that the resources can be retrieved using RESTful APIs or socket servers or anything that allows the process. But it has to be laid down in the standard format given by FHIR norms.

Interoperability

Today’s medical workflow has multiple devices that collect a lot of data. The interoperability concept acts as a bridge and ensures that every system and device works together seamlessly. Using interoperability all touchpoints can communicate and exchange information without friction.

For example, a person’s data can be collected via fitness bands or digital watches. It can also be collected through laboratory reports. Data also accumulates in healthcare applications on mobile phones or servers in hospitals. Using interoperability, all the data captured can be synched up according to the standards and norms of FHIR. This ensures that wherever the data is needed, it is available in a universal format understood by anyone who requires the information.

The entire process is a great leap to providing better healthcare to patients. For example, take two hospitals named A and B. Each hospital has its own data form. Hospital A uses XML, and Hospital B uses Jason.

If the two had to communicate in the traditional settings, then there has to be a data transformation layer. In this scenario, a new data transformation layer will be required for all data points — fitness plan, lab records, healthcare providers, and more. There will be countless connections, especially globally, making data management tedious.

But with the interoperability of FHIR, there is a standard data interaction that eliminates the requirement for a data transformation layer. Any information that is referred — name, gender, date of birth, etc. — all the stakeholders will receive supported fields according to the in-house format. Other properties will be contained in a field called extension.

In a nutshell, interoperability removes the reliance on RESTful inputs or data structures. One can directly call RESTful APIs and integrate them. Additionally, once the standardization for FHIR is updated, all the organizations will get the data in the updated format.

FHIR does not impose an architectural pattern. It is flexible and just lays down basic ground rules on how to structure data and communicate the information. An application can be built with a peer-to-peer or central service. The can also be an asynchronous architecture for microservices built with Java, Go, or Node.js.

The restrictions FHIR imposes are on the structuring of data and how the RESTful endpoint is created. It also lays down rules for the number of endpoints for each resource, how to get the data and the mode in which the data will get updated.

A typical flow will be — there are RESTful endpoints (either in Jason or XML), it will go to an FHIR Parser, which again goes to the FHIR Service and then to the storage. The storage database can be in SQL or NoSQL. So, it is not restricting where the data can be store, but it is telling the input provider what the endpoint should be.

FHIR works with the concept of composition framework. This ensures that the various forms of data collected — patient, clinical, lab, etc. — can be organized and standardized.

For example, consider there are six layers of data. Category one is the foundation layer. Then there is a base layer, a clinical layer, a financial layer, a specialization layer, and a contextual layer. FHIR divides the data across each layer efficiently. So, if there is a need for a clinical document, one can go to the clinical resources, make the API call and get the data. This clear separation of information ensures fast retrieval of data.

Another case is when there is data needed for healthcare premiums. In this case, one can go to the financial layer, and show it on the web portal. The EHR admin can get the information and perform necessary actions with the press of a button. 

FHIR removes numerous roadblocks faced by patients in receiving prompt care. Thanks to its ability to streamline data transmission, FHIR eliminates a lot of friction in data sharing. It has laid out rules and protocols on how to structure data, capture data, and manage the data. This means better access to information for the patient and no requirement to carry physical medical records during hospital consultations. For example, during an emergency, if a patient is being shifted from Apollo Hospital to Manipal Hospital, the medical history can be obtained easily using RESTful APIs.

FHIR also does not restrict the technology used. One can build an application using .net and another application in the ecosystem using React.js. However, the underlying standardization remains constant, i.e., there is no restriction on the communication level side, but not on the technology side. This ensures great flexibility in the delivery of healthcare and promotes customized service. It also reduces costs.

FHIR has the potential to bring standardization and better delivery of healthcare services to everyone. A great example close to home is the ABDM FHIR initiative under the Ayushman Bharat Digital Mission (ABDM). 

The ABDM FHIR process will create a set of repositories where the government can store data on a federated architecture. If a user is using a health locker A and another health locker B, they are still connected using an API gateway. Even the lab records are getting standardized in the repositories, meaning that their history will be recorded and can be accessed wherever required. In the long run, what the Aadhar card did for delivering essential household services, the ABDM card can be its analogous equivalent.

For now, we have just scratched the surface and are experimenting continuously with incorporating the concept. Digital solutions like the customizable Telehealth Solution by GeekyAnts also use these concepts. They are designed to simplify the FHIR-compliant application creation process for healthcare service providers.

Visit our YouTube Channel to watch the video. Subscribe now!