OpenFn Integration & Interoperability
What an OpenFn integration does
OpenFn is an open-source workflow automation and data integration platform used widely in the global development and digital health sector. A workflow ("job") reads from a source, transforms the payload in JavaScript using an adaptor for the target system, and writes the result — with logging and retry behaviour around it.
The shape of every integration is the same:
Source System → OpenFn
→ Transform / Validate
→ Target System
The variants we most often need in Nepal's health and development context:
DHIS2 → OpenFn → FHIR
Database → OpenFn → DHIS2
API → OpenFn → DHIS2 / FHIR
Health Information System
→ OpenFn → Reporting System
What makes these projects succeed or fail is not the arrow in the middle. It is whether the identifiers on both sides resolve to the same person or facility, whether the codes mean the same thing, and what happens to a record that fails validation at three in the morning. Those questions are the same ones that decide any healthcare interoperability project.
Integration and interoperability use cases
Work that fits this pattern:
- DHIS2 integration — pushing aggregate or tracker data into DHIS2, or extracting from it for onward exchange
- FHIR-based interoperability — mapping source records onto FHIR resources and posting them to a FHIR server
- Health information exchange — moving structured clinical and programme data between systems that were never designed to talk to each other
- API-to-API integration — connecting two services that each expose HTTP endpoints but no shared model
- Database synchronisation — keeping a downstream store consistent with an operational system
- Data transformation and mapping — field mapping, code translation, unit and calendar conversion, record reshaping
- Scheduled data exchange — nightly, weekly or reporting-period runs where real-time exchange is unnecessary or unsafe
- Data validation — rejecting or quarantining records that fail conformance or business rules before they reach the target system
- Programme monitoring workflows — assembling indicator data from multiple sources for a monitoring dashboard or reporting cycle
- Referral and notification workflows — triggering a message or a task when a record meets defined criteria
- Government health-system integration — exchange with national platforms under their own conformance and authorisation requirements
- Development-partner reporting workflows — transforming programme data into the formats funders and partners require
OpenFn and n8n
Both are automation platforms, and the overlap is real. The difference is in what each was built around: OpenFn around development-sector and health system interoperability, n8n around general workflow and business-process automation across a very wide connector library. We use both.
| Capability | n8n | OpenFn |
|---|---|---|
| General workflow automation | ✓ | ✓ |
| API integration | ✓ | ✓ |
| Healthcare integration | ✓ | ✓ |
| DHIS2 integration | ✓ | ✓ |
| FHIR workflows | ✓ | ✓ |
| Development-sector interoperability | ✓ | |
| Business process automation | ✓ | |
| Notifications and operational workflows | ✓ | ✓ |
| Data transformation | ✓ | ✓ |
A blank cell means the capability is not what that platform is primarily built around — not that it is impossible there. Neither column is the better platform. A monthly DHIS2-to-FHIR reconciliation with strict conformance requirements and a Slack alert when a partner's CRM gets a new record are different problems, and the sensible answer is often to run both tools in the same estate.
A combined integration layer
In practice the two sit in one layer, and the systems on either side do not need to know which tool handled a given flow:
Systems
↓
OpenFn / n8n Integration Layer
↓
Validation + Transformation
+ Business Rules
↓
DHIS2 / FHIR / APIs / Databases
/ Notifications / Reporting
Which tool runs a given workflow depends on the workflow itself, the systems involved, the deployment requirements — self-hosted or managed, network restrictions, data residency — and the organisational context, including who will maintain the workflow after handover. That last one is decided more often than it is discussed.
This is the same reasoning behind routing integrations through a middleware layer at all rather than wiring systems point to point, which is set out in the FHIR and interoperability case study.
OpenFn & interoperability expertise in Nepal
Aamako Maya is a Nepal-based digital health technology company. The work we bring to OpenFn-based integration is the work we already do:
- Nepal health-system experience — building and operating digital health systems used by health workers and municipalities
- Government digital-health systems — working within national reporting and conformance requirements
- DHIS2 — implementation, localisation and reporting, described in the DHIS2 case study
- HL7 FHIR — running a FHIR platform and an upgrade path toward FHIR v6
- Health data interoperability — identifiers, terminology and conformance, not just transport
- Open standards — FHIR, HL7 v2, ICD, SNOMED CT, LOINC and the OpenHIE architecture pattern
- Development-sector workflows — programme monitoring and partner reporting
- API-first integration — systems designed to be integrated rather than scraped
- Secure data exchange — authorisation, audit and an ISMS aligned with ISO/IEC 27001:2022
- Local implementation and support — a team in Nepal, in the same time zone as the systems being integrated
Our experience with health-system interoperability provides a practical foundation for implementing OpenFn-based integration workflows. We do not claim OpenFn certifications or partnerships, and the projects described elsewhere on this site were delivered with the tooling named in each case study.
My take
The question clients ask is "which platform should we use?". The question worth answering first is "what does a failed record do?". An integration that moves data successfully on the happy path and silently drops malformed records is worse than no integration, because the reporting looks complete.
Once you have an answer for validation failures, retries, duplicate handling and who gets told, the platform choice becomes much smaller than it first appeared — and usually resolves on deployment and maintenance constraints rather than features.
Frequently asked questions
- What is OpenFn used for?
- OpenFn is an open-source integration and workflow automation platform used in the global development and digital health sector. It connects systems, transforms and validates records between them, and runs those exchanges on a schedule or in response to events.
- Can OpenFn integrate with DHIS2 and FHIR?
- Yes. OpenFn provides adaptors for DHIS2 and for FHIR, along with HTTP, database and other system adaptors, so a workflow can read from one and write to the other with transformation and validation in between.
- Should we use OpenFn or n8n?
- It depends on the workflow, the systems involved, deployment requirements and who will maintain it. OpenFn is oriented toward development-sector and health-system interoperability; n8n toward broad business-process and operational automation. Many organisations run both.
- Does Aamako Maya have existing OpenFn deployments?
- We do not claim previous OpenFn deployments. Our experience is with health-system interoperability — DHIS2, HL7 FHIR, terminology, APIs and integration middleware in Nepal — which provides a practical foundation for implementing OpenFn-based integration workflows.
Sources
- OpenFn. Documentation. docs.openfn.org
- OpenFn. Adaptors registry (includes DHIS2, FHIR, HTTP and database adaptors). docs.openfn.org/adaptors
- n8n. Documentation. docs.n8n.io
- HL7 International. FHIR specification. hl7.org/fhir
- DHIS2. Developer documentation. docs.dhis2.org