Data Standards like FHIR Matter in Healthcare. Here’s How to Get the Most Out of Them.

Picture this: A patient with a heart condition collapses while traveling. Emergency responders rush to help, but they can't access her medical history - her diagnosis, current medications, or critical allergy information. The data exists, but it's trapped in a different hospital system using incompatible formats. Treatment gets delayed. Risk increases.

This scenario plays out daily in healthcare systems worldwide.

The solution? FHIR (Fast Healthcare Interoperability Resources). The leading modern standard for healthcare data exchange. It defines structures called 'resources' for common healthcare concepts - Patient, Observation, Medication, Encounter - and specifies exactly how data should be formatted when shared between systems. But here's the thing: agreeing on a standard is one thing. Actually adopting it to integrate systems is another.

What FHIR Really Does

Healthcare systems face a fundamental problem: every software vendor structures data differently. That’s necessary and desirable to meet their own respective needs. Think of FHIR as a common language for the exchange of healthcare data.

Without it, one hospital might store a patient's name as "firstName" and "lastName" while another uses "given_name" and "family_name". When these systems try to exchange information, they can't automatically understand each other and recognize they're talking about the same person. Deterministic software does not understand nuance.

FHIR specifies that patient names should use 'given' and 'family' fields within a 'name' array. When both systems follow this standard specification, they can reliably exchange patient information without ambiguity. When different systems all follow the same standard, they can communicate reliably without custom translation work for every connection.

FHIR solves this by defining how healthcare data should be shared.Think of FHIR like a universal translator: it doesn't change how each health provider stores data internally, but ensures that when they share information, both sides understand exactly what they're receiving. This concept, called semantic interoperability, is critical to effective, modern healthcare delivery, which relies on connected systems and secure data exchange.

Having an agreed and shared representation of patient data, independent from the original data source facilitates integration across different systems, and transforms patient care. Remember the traveler with the heart condition? With integrated records, emergency responders could access her cardiac history, medication list, and allergy alerts using her national patient ID. Harmful medications get avoided. Lives get saved.

The Reality: Standardised Systems Need Integration Tools

Here's where it gets interesting. FHIR provides the technical framework for interoperability and establishes a “common language” for healthcare data, but successful implementation requires significant organizational commitment, technical expertise, and often substantial system upgrades.

FHIR provides the base framework, but each country or region typically publishes an 'Implementation Guide' - detailed specifications for how FHIR should be applied in their specific context, including required fields, terminology bindings, and validation rules.

Then, most healthcare organizations aren't starting from scratch with FHIR-compliant systems - they're working with existing platforms that don't speak FHIR natively.

We saw this firsthand when working with a clinic in Indonesia. The government mandated that all health facilities send patient records to their Shared Health Record system, Satusehat, which accepts data that is structured according to the FHIR standard. The clinic was using CommCare as their EMR - excellent for offline, mobile case management in rural areas, but not a FHIR-native system. Therefore, data from CommCare requires transformation before it can be sent to the Satusehat FHIR app according to the government’s specific Satusehat Implementation Guide. This represents a common challenge: bridging established systems with new FHIR-based national infrastructure.

Making FHIR Work in Practice

This is where OpenFn comes in. As a Digital Public Good recognized by the United Nations and listed as a Mature Global Good for Health by Digital Square, OpenFn is used in over 40 countries to power healthcare data exchange. OpenFn provides both a secure orchestration layer (see “interoperability layer” from the OpenHIE specification) and a workflow engine all in one platform.

For the Indonesian clinic, we built automated workflows using our FHIR-4 adaptor that:

• Converted non-FHIR data into FHIR-compliant formats, enabling fast and secure integration of Patient, Visit, & Treatment data with the national health system
• Handled authentication and validation automatically with our Satusehat adaptor
• Included robust error handling to keep data flowing smoothly even when issues arose

OpenFn adaptors, including the FHIR-4 adaptor, accelerate integration with data systems by providing helper functions and shortcuts that fast-track data transformation and mapping logic, making it easier to convert non-FHIR data into FHIR resources.

The result? Patient records can now flow automatically from CommCare to the national registry without manual intervention, complex reporting processes, or refactoring of the non-FHIR application’s core data structure. With OpenFn, the Indonesian clinic doesn’t have to rebuild their EMR, and it was able to choose the EMR that worked best for their use case, even if that wasn’t a FHIR-native app. Using OpenFn as a FHIR-translation layer or “FHIR facade” enables the clinic to efficiently and cost effectively connect their EMR to the government’s FHIR-native national health information system for live reporting.

If your app is not FHIR-native, then leaning on FHIR facades and data integration layers like OpenFn to handle the FHIR-translation for your app is a great, cost-effective way to ensure compliance. Remember that FHIR is a standard designed for interoperability and data exchange, not for data capture. Therefore, rebuilding your app to use a FHIR-native data model is rarely the best way to achieve compliance.

Moving Data Between FHIR Systems

Even if you have two systems that are already FHIR-native or FHIR-compliant, an orchestration layer is still pivotal to automatically move the data between the systems, while securely handling authentication and errors. Therefore, even in FHIR-to-FHIR integrations, automation platforms like OpenFn are critical for operationalizing data exchange. They are responsible for automatically extracting, routing, and loading data between systems.

In non-technical language, if someone in Japan speaks English, and someone in France speaks English, that doesn't mean they are actually speaking to each other. Sure, some important legwork has been done to make communication between them easier, but we still need to fly them to the same place so they can speak face to face, or provide them the mobile telephony infrastructure so they can speak to each other on the phone.

The same is true of software. HTTP requests between systems’ APIs (or methods of executing data integration) are pivotal to realising the promise of actual integration (not just ‘interopability’). Even when all systems are "speaking FHIR", OpenFn makes it much easier to build and maintain the actual integrations between them - the actual end goal of an integrated ecosystem.

What We've Learned About FHIR Implementation

Through projects like this, several patterns have emerged:

• Start with clear data mapping early. The biggest challenge isn't the technology, it's figuring out how your existing data elements map to FHIR resources (e.g., Patient, Encounter, Observation, Medication). You’ll need to leverage FHIR implementation guides (or work with FHIR experts to develop these) in order to determine how exactly a system has implemented FHIR and adapted it for its use cases. Data element mapping also typically requires medical experts to review terminology and coding of diagnoses, medications, and other data to ensure clinic accuracy. Good documentation and sample data make this process infinitely easier. Using AI can speed up this process (see here for our guide on using LLMs to support data mapping), but the human in the loop is vital for accuracy and accountability.
• Expect to adapt. Sometimes you'll need to update your source application to capture all the data your FHIR system requires. This might mean modifying forms or data models to facilitate automated data exchange.
• FHIR is not a silver bullet. Even when two systems both implement according to the FHIR standard, software developers are only human! Each one may interpret the Implementation Guide slightly differently or implement different guides entirely. We’ve even encountered scenarios where systems implement different versions of FHIR (imagine someone speaking American English vs. Pidgin English), meaning that some translation work is still required to facilitate data exchange–even between two FHIR systems. In such cases, the OpenFn integration platform helps translate between those different systems, simplifies the data mapping, and scales the routing logic needed to bridge these differences.
• You’ll need an orchestration layer to move the FHIR data between systems. To actually automate data exchange and operationalize interoperability, an orchestration layer or “interoperability layer” is critical for routing and moving data securely between connected systems. OpenFn is a trusted, open source option used widely by NGOs, health ministries and as part of the world’s Digital Public Infrastructure, which can support this functionality.

The Bigger Picture

FHIR doesn't just help individual patients. When healthcare systems successfully adopt common data standards, we enable collective insights. Public health officials can track vaccination coverage in real-time. Researchers can analyze treatment outcomes across populations. Health system leaders can make data-driven decisions about resource allocation.

But FHIR alone isn't the answer to everyone’s integration challenges. It's incredibly technical to implement and maintain. The key is pairing standards with practical integration tools that make implementation achievable, repeatable and scalable for organizations at any technical maturity level.

Ready to connect your health systems with FHIR-based infrastructure? OpenFn's platform includes pre-built FHIR workflow templates and our specialized FHIR-4 adaptor designed to help bridge non-FHIR and FHIR systems. Our services team can guide you through the integration process - from data element mapping to automating data exchange.

Book a consultation to discuss your use case with our team, post questions on community.openfn.org, or sign up for free to explore our FHIR templates on the platform.

Watch the Digital Square FHIR webinars.