Hello Community!
Working on non-FHIR to FHIR integration? We’ve got some cool new tools that might help you out! We just released new FHIR templates and adaptors to help jumpstart your FHIR projects. You can check them out here: fhir-r4 adaptor, Satusehat adaptor, and don’t forget to register for OpenFn Cloud if you haven’t already.
We’ve also built a bunch of pre-made FHIR workflow templates on OpenFn Cloud to make your life easier. Just hit “Create Workflow” in your dashboard and search for “FHIR” - you’ll find templates like “Non-FHIR to FHIR” and “Syncing CommCare Cases to HAPI FHIR.” Pretty handy, right?
So, what got us into FHIR in the first place?
First off, if you’re new to FHIR - it stands for Fast Healthcare Interoperability Resources. Think of it as the universal translator for healthcare data. It’s a global standard that uses modern web APIs to help different healthcare systems actually talk to each other (finally!).
Back in December at the Open Digital Health Summit in Nairobi, we shared our experience integrating a non-FHIR EMR with a FHIR-based shared health record system for a clinic in Indonesia. It was quite the journey and led us to build our fhir-r4 adaptor!
The challenge we faced
Here’s what happened: The Indonesian government said “Hey, all health facilities need to send patient records to our Shared Health Record system called Satusehat” (which runs on FHIR). Our partner clinic was using CommCare as their EMR - great for offline, mobile case management in rural areas, but it doesn’t speak FHIR natively. So we had a classic integration puzzle on our hands.
How we solved it
We built an automated solution using OpenFn with these key pieces:
Automated workflows - We set up workflows to handle data mapping, transformation, and smart routing so data flows seamlessly between systems.
Smart error handling - Nobody likes broken data, so we built robust error-handling and retry mechanisms to keep everything running smoothly.
The right adaptors - We used OpenFn’s CommCare adaptor to pull data and our Satusehat adaptor to handle authentication, FHIR validation, and data imports.
Our approach (the nitty-gritty)
Workflow design - We mapped out exactly what needed to happen, in what order, and figured out which record IDs to sync back to keep everything connected.
Data mapping - This was the big one! We created detailed specs showing how to transform data from the source system into proper FHIR resources.
Data dictionaries - We used CommCare’s existing lookup tables to build a comprehensive dictionary that mapped things like lab results to standard terminologies (SNOMED, LOINC, ICD-10, KFA codes).
Storage decisions - We had to decide where to keep all our mapping logic. Options included OpenFn workflow code, OpenFn collections, external services like Open Concept Lab, or even in the source/target apps themselves. It really depends on who’s managing changes and their technical comfort level.
What we learned (the good stuff!)
Start mapping early - Seriously, get some sample data and start figuring out your mappings ASAP. Good documentation from target systems is worth its weight in gold.
Plan for things to break - They will! Having a solid plan for handling errors saves you from a lot of 3 AM debugging sessions.
Keep your data dictionaries clean - Clear, comprehensive data dictionaries are your best friend for consistent mapping.
Be ready to adapt - Sometimes you’ll need to tweak your source application to capture all the data your FHIR system needs. That might mean updating forms, data models, or metadata schemas.
The bottom line
FHIR integration might seem scary at first, but with the right tools (like OpenFn 
) and approach, it’s totally doable. Our experience showed us that automated workflows, good mapping, and proactive error handling are the secret sauce.
If you’re tackling similar challenges, definitely consider these strategies! And hey, don’t be shy - drop a comment if you’re exploring FHIR integration use cases. The community is here to help!