n8n Automation & Integration
Automation for Digital Health
Health systems generate the same handful of integration problems repeatedly: data sits in one system and is needed in another, a threshold is crossed and someone must be told, a report is due on a schedule, or a record is wrong and nobody notices until the reporting cycle closes.
The shape of a health automation workflow:
Data Source → n8n → Validation
→ Transformation → Integration
→ Notification → Reporting
Concrete examples of that shape:
DHIS2 → n8n → FHIR
FHIR → n8n → notification /
referral workflow
OCL → n8n → terminology update
→ review
Database → n8n → reporting
API → n8n → SMS / email
Scheduled workflow → validation
→ alert → human review
What this covers in practice:
- DHIS2 ↔ FHIR — moving aggregate or tracker data into FHIR resources, and the reverse, with mapping and conformance checks in between
- Healthcare data synchronisation — keeping two systems consistent without anyone exporting a spreadsheet
- Patient and referral workflow automation — triggering the next step when a record meets defined criteria
- SMS and email notifications — alerts to health workers, supervisors or programme staff, including Nepali-language message content
- Reporting and dashboards — assembling indicator data on a reporting cycle instead of by hand
- Data quality checks — rules that run against incoming data and raise what fails rather than accepting it
- Scheduled data exchange — nightly or reporting-period runs where real-time exchange is unnecessary
- API integration — connecting services that expose endpoints but share no data model
- Terminology and data workflows — pulling concept updates from a terminology source such as OCL and routing changes for review before they take effect
- AI-assisted workflows with human oversight — using a model for classification, drafting or summarisation inside a workflow, with a person approving anything that affects a record or reaches a patient
- Monitoring and alerts — watching the integrations themselves, so a workflow that stops running is noticed the same day
The mapping, identifier and terminology questions underneath these workflows are the ones set out in healthcare interoperability in Nepal; automation does not remove them, it just stops them being answered manually every month.
Beyond health
The same capability applies wherever systems need to talk to each other on a schedule or on an event:
- Government and public services — form intake, routing, status notifications and reporting
- NGOs and development organisations — partner reporting, data collection pipelines, grant and programme administration
- Education — enrolment, attendance and results workflows
- Finance and business operations — invoice routing, reconciliation support, approvals
- Customer service — ticket routing, acknowledgements, escalation
- Research and data management — collection, cleaning and export pipelines
- HR and administrative workflows — onboarding, leave, document handling
- Monitoring, evaluation and reporting — indicator collection and scheduled reporting packs
Architecture
The automation layer sits between the systems and the destinations, and neither side needs to know the other exists:
Applications / APIs / Databases
↓
n8n Automation Layer
↓
Validation + Transformation
+ Business Rules
↓
FHIR / DHIS2 / OCL / Email /
SMS / Dashboards / Other Systems
Everything meaningful happens in the third row. Transport is a solved problem; deciding what a valid record looks like, what to do with an invalid one, and which steps a human must approve is the actual engineering.
Where OpenFn fits
We also work with OpenFn, which is oriented toward development-sector and health-system interoperability. The two overlap on API and notification workflows and differ at the edges — n8n reaches further into general operational and business-process automation, OpenFn further into development-sector integration. Which one runs a given workflow depends on the systems involved, the deployment requirements and who will maintain it. Running both in one estate is normal.
n8n Automation Expertise in Nepal
What we bring to an automation project:
- Nepal-based implementation — a team in Nepal, in the same time zone as the systems and the people operating them
- Healthcare and public-sector experience — DHIS2 implementation and localisation, an HL7 FHIR platform, and the reporting workflows around them, described in the DHIS2 and FHIR case studies
- Open-source and API-first integration — no proprietary lock-in in the integration layer, and systems integrated through documented interfaces
- Self-hosted deployment where appropriate — n8n can run inside your own infrastructure, which is often the deciding factor for health and government data
- Data security and access control — credential handling, least-privilege access and audit, under an ISMS aligned with ISO/IEC 27001:2022
- Human review for sensitive workflows — clinical, terminology and financial steps pause for approval rather than committing automatically
- Integration with existing systems rather than replacing them — automation is added around what is already running
Our experience with health-system interoperability and reporting provides a practical foundation for building and operating n8n workflows. We do not claim n8n certifications or partnerships.
My take
The automation worth building is rarely the impressive one. It is the weekly export somebody does by hand, the notification that currently depends on a person remembering, the reconciliation nobody has time for.
Two rules keep these workflows trustworthy. First, a failure must be louder than a success — if a run drops records quietly, the reporting looks complete and the error compounds. Second, anything that changes a clinical record, a terminology concept or a payment gets a human in the loop. Automation should remove the typing, not the judgement.
Frequently asked questions
- What is n8n used for?
- n8n is an open-source workflow automation platform. It connects applications, APIs, databases and messaging services into workflows that run on a schedule or in response to an event, with transformation and conditional logic in between.
- Can n8n be used with health data in Nepal?
- Yes, with the usual conditions. n8n can be self-hosted inside your own infrastructure so health data does not leave the environment you control, and sensitive steps can require human approval before they commit. Authorisation, audit and access control still have to be designed for the specific deployment.
- Can n8n integrate DHIS2 and FHIR?
- Yes. Both expose HTTP APIs, so a workflow can read from one, map and validate the payload, and write to the other, with scheduling, retries and alerting around it.
- Should we use n8n or OpenFn?
- It depends on the workflow, the systems involved, deployment requirements and who will maintain it. n8n covers broad operational and business-process automation; OpenFn is oriented toward development-sector and health-system interoperability. Many organisations run both.
Sources
- n8n. Documentation. docs.n8n.io
- n8n. Hosting and self-hosting documentation. docs.n8n.io/hosting
- OpenFn. Documentation. docs.openfn.org
- DHIS2. Developer documentation. docs.dhis2.org
- HL7 International. FHIR specification. hl7.org/fhir
- Open Concept Lab. Documentation. docs.openconceptlab.org