From Silos to Synergy: FHIR in focus

At D-tree, we believe that FHIR, Fast Healthcare Interoperability Resources, has great potential to contribute to helping people receive more coordinated and uninterrupted healthcare. In this first blog in a series about FHIR, Khumbo Lihonga, our Engineering Manager in Malawi, shares what he sees as the potential and challenges with FHIR.

There has been a growth in the number of technologies developed to support digital health interventions worldwide – from OpenSRP and Medic Mobile to DHIS2, CommCare, and others. They all share the same goal – to equip health workers with tools, usually an app, that optimize their work and ultimately health outcomes for people. We know that many of these technologies work when applied correctly, and they are being used by health workers across the globe, making their work easier and enabling standardized and quality care. 

However, as much as these technologies share the same goal, they have gone about it in different ways. For example, how the data recorded by health workers is stored. One app can store an individual’s name as two data points under the headings ‘first name’ and ‘last name’ and at the same time, another app can store the same data under the headings ‘first name’ and ‘surname’. Finally, a third app can store this same data under a single heading, ‘full name’. While this example can seem trivial, it highlights a significant challenge regarding interoperability.

A more practical example begins with a health worker who visits a pregnant woman, Jane, at her home. Through using a job-aid tool, an app, the health worker may recognize that she is exhibiting danger signs and needs to be referred to a facility. In the app, these danger signs could be stored as data under the heading ‘danger signs’. Assuming the data can be sent to the facility, the receiving facility system might not be able to make sense of it as it may store danger sign data under the heading of ‘symptoms’. As a result, the danger signs and any other conflicting headings will result in the facility system not understanding the details of the referral.

On arrival at the facility, Jane would need to be re-reviewed to determine what her problem is. This might include registering her demographic details, entering her clinical history, and examining her to determine why it is she was referred. This is not only tedious for Jane as she has already done this with the health worker while at home, but more significantly, this creates a duplicate record of her as well – one with the health worker and one with the facility. Eventually, when the health worker follows up with her, their app will similarly not be able to understand her visit details from the facility system and the health worker will need to rely on Jane’s recollection of events to guide any additional service provision. 

This lack of understanding between the two systems introduces the potential for several points of failure in Jane’s continuum of care. This means that at each point of service provision, there is a possibility of human error due to a lack of sufficient information. To begin with, they wouldn’t even be expecting Jane at the facility which could lead to a long waiting time while she is in distress. Furthermore, without a complete picture of her condition she might be misdiagnosed, prescribed medication she is allergic to, prescribed medication that she shouldn’t be taking with any other medication she may be currently taking, and so on. As you can imagine, this is a critical problem as the list of detrimental possibilities for her and her baby is endless.

One solution to this problem is to enforce the use of the same technology across the different levels of the healthcare system. In Jane’s scenario, this means that the app being used by the health worker and the facility system would use the same technology. This would mean that the data would be stored the same way and each tool would be able to understand Jane’s clinical information. However, different providers have different needs and wants, and what works well for the health worker might not work for the facility. For example, the health worker might not need a supply chain feature in their app while this might be a key feature for a facility. As a result, enforcing one technology on all stakeholders is not an ideal solution.

Another solution that has been proposed is the use of an interoperability layer. This is a technology that facilitates the exchange of information between two or more disparate systems. In Jane’s example, this would mean that when the app wants to send data to the facility system, it must first send that data to the interoperability layer. Consequently, the interoperability layer will receive the request, modify the data to suit the receiving system, and then send it to the facility accordingly. This solution has one major challenge – maintainability. As old systems are depreciated, new systems are introduced, and existing systems grow, there is an ever-changing set of requirements that need to be maintained on the interoperability layer as well as with the different technologies to ensure a consistent flow of information. Depending on the individual objectives of the different entities doing the maintenance, this can be a significant challenge in the long run and may not be an ideal solution.

Finally, one solution that is gaining traction is a standard known as Fast Healthcare Interoperability Resource, FHIR. This is not a technology, but rather a standard that provides guidance to different technologies on how healthcare data should be represented. It does this by providing pre-defined templates of common healthcare data such as that of patients, practitioners, visits, and more. Furthermore, the FHIR standard also provides guidance on how to exchange the data that is generated using these pre-defined templates. It does this by incorporating modern web protocols and data formats as a means to share data across systems. Referring to Jane’s example, this would mean that the health worker’s FHIR-compliant app would store and transmit each danger sign as an ‘observation’. Subsequently, when Jane visits the facility, the FHIR-compliant facility system will be able to retrieve these observations and comprehend her reason for the referral among other details.

FHIR is an ideal solution as it addresses the challenges of the previously mentioned solutions. With regards to enforcing the same technology, FHIR allows different technologies to become FHIR-compliant by storing and sharing their data in the prescribed manner. In addition, while FHIR can be used as part of an interoperability layer, if systems sharing data are all FHIR compliant then the need for the interoperability layer becomes obsolete. But this is not to say that FHIR does not have its limitations. Establishing pre-defined templates and protocols for healthcare systems worldwide is a significant challenge as it is impossible to cover all use cases. For example, when storing a patient’s address, FHIR includes pre-defined headings for the name of the city, district, country and so on. However, it does not include catchment areas which is a key piece of information regarding service provision at the community level.

In conclusion, the FHIR standard is a solution with great potential. It provides a comprehensive set of pre-defined templates covering different aspects of healthcare. Ideally, it also provides a means to exchange this data using web protocols that are widely used in today’s technologies. Consequently, different digital health technologies can implement this standard and exchange their data with other FHIR-compliant systems accordingly. It does have its shortcomings but it is under constant revision and the benefits significantly outweigh the costs. Using FHIR would allow patients like Jane to receive the comprehensive care they deserve across different service providers, among all levels of the healthcare system, and throughout their lifetime. 

In our next article, we will highlight the state of interoperability in Malawi, the adoption of FHIR in the country, and share D-tree’s experience developing an FHIR-compliant app.