When we talk about digital healthcare in Indonesia, one of the biggest challenges is data fragmentation.
Each district or hospital often runs its own system — making it difficult to share clinical data securely and consistently across regions.
In this post, I’ll share:
- 🧩 The background and goals of the project
- 🏗️ The architecture and technology choices we made
- ⚙️ The challenges we faced around scale, cost, and security
- 🌐 Our future direction toward a hybrid on-premise model
I. Introduction
In 2024, the Oxford University Clinical Research Unit (OUCRU) and the Indonesian Ministry of Health launched a national initiative to improve healthcare data interoperability using FHIR (Fast Healthcare Interoperability Resources) standards.
I joined this project as a DevOps Engineer, responsible for designing and maintaining the entire infrastructure.
My main mission: to build a federated ecosystem where each district could manage its own FHIR data — while still communicating seamlessly with others across the national network.
💡 To enable healthcare data to move where it’s needed, when it’s needed — safely, efficiently, and transparently.
| Goal | Description |
|---|---|
| Interoperability | Systems across districts must exchange health data seamlessly using FHIR standards. |
| Scalability | The architecture should handle new districts as the network grows. |
| Security | Protect patient data under Indonesia’s health data regulations. |
| Cost Efficiency | Optimize Google Cloud resources for a non-profit budget. |
| Automation | Everything must be reproducible, version-controlled, and automated (IaC, CI/CD). |
II. System Overview
At a high level, the ecosystem consists of multiple district FHIR servers, each managed independently by their respective local governments.
These servers are connected through a peer-to-peer FHIR federation, where every district’s FHIR Gateway can securely request and exchange data with other districts when needed.
🧭 Architecture at a Glance
Each district deploys a FHIR Gateway that serves as both a secure API proxy and an access control layer for its internal FHIR server.
Requests between districts occur directly over HTTPS, with each gateway responsible for authentication, authorization, and audit logging of all inbound and outbound data exchanges.
- FHIR Gateway: The communication core — validates all requests, enforces access control, and ensures compliance with inter-district data policies.
- Peer-to-Peer Federation: Gateways communicate directly across clouds or environments (e.g., Google Cloud, AWS, on-premise), enabling interoperability without centralized dependency.
- Data Sovereignty: Each district maintains full control of its infrastructure, credentials, and FHIR data — ensuring local ownership and compliance with national regulations.
We began our rollout on Google Cloud Platform (GCP) for its scalability, tooling, and healthcare compliance readiness.
The availability of a Jakarta region ensures that all workloads and patient data remain within Indonesia’s borders, fully aligned with national health data protection requirements.
This foundation allowed us to prototype rapidly while staying compliant with data residency and sovereignty laws.
☁️ Cloud-Native Stack
- Cloud Run and GKE — containerized microservices for FHIR Gateway and supporting APIs
- Cloud SQL & BigQuery — structured storage and analytics
- Cloud Storage — object and unstructured data
- IAM + VPC Service Controls — fine-grained security and network isolation
- Compute Engine — for legacy or specialized workloads
We follow 12-factor app principles to keep services modular, portable, and cloud-agnostic, making it easy to deploy on AWS or on-prem Kubernetes as other districts join the federation.
🧩 In the next part of this series, I’ll share how our open-source tools and public services power this peer-to-peer FHIR federation layer.
III. Challenges Along the Way
Building a federated FHIR ecosystem from the ground up was both thrilling and overwhelming.
We were effectively laying down the first foundation of its kind — connecting healthcare districts that had never interoperated at this scale before.
Some key challenges we faced
- 🧩 Data governance: Each district had its own compliance rules and data sovereignty policies that had to be respected
- 🧠 Tool maturity: There was no ready-made “federated FHIR” blueprint — we had to design our own gateway patterns, auth flows, and governance models
- 🔐 System complexity: Every networking and security configuration had long-reaching effects across environments
- ⏱️ Time pressure: Balancing design exploration with production deadlines, while keeping uptime and patient data integrity intact
- 💰 Cost awareness: Cloud resources, network egress, and FHIR store usage can scale quickly — we had to constantly review and right-size deployments to stay within budget
To manage all of this, we adopted a lightweight agile workflow:
- Used GitHub Projects to organize sprints, issues, and milestones — giving full visibility across developers, DevOps, and domain experts
- Practiced continuous iteration — shipping small, testable increments instead of massive releases
- Embedded infra-as-code and CI/CD from day one, so every change was reproducible and easy to roll back
- Regularly reviewed cloud spend and utilization dashboards to catch early cost spikes before they became problems
It wasn’t always smooth — there were plenty of late-night debugging sessions and architecture pivots — but the result was a production-ready, scalable federation that could truly transform how districts share health data securely and efficiently.
IV. How Federation Works
At the core of the federated ecosystem is peer-to-peer interoperability between districts — allowing each region to exchange patient data securely, without relying on a central hub.
When a healthcare worker in District A initiates a completeness check (for example, to retrieve a patient’s vaccination history stored in District B), the FHIR Search & Sync service interacts with the local FHIR Gateway.
If data is missing, the gateway issues a federated HTTPS request directly to the FHIR Gateway of District B.
District B’s gateway validates the incoming request, fetches the relevant records from its internal services or FHIR API, and returns the data securely to District A.
Finally, District A’s system updates its FHIR Store through the Healthcare API to complete the record.
Key design principles
- 🧩 Federated & autonomous: Each district operates independently — managing its own FHIR Gateway, credentials, and data policies under local government control
- 🔁 Gateway-to-Gateway communication: Districts exchange data directly using FHIR REST APIs over HTTPS, ensuring interoperability without central dependency
- 🔒 Controlled trust model: Authentication and authorization are managed through gateway-specific credentials (e.g., JWT tokens or mutual TLS) issued and rotated by each local authority
- 📜 Traceable & auditable: Every completeness request and response is logged for audit, compliance, and monitoring
- 🌐 Future-ready evolution: The architecture is designed to later integrate Pub/Sub or Kafka for event-driven federation, providing asynchronous messaging, queuing, and resilience at scale
This peer-to-peer FHIR federation enables secure collaboration between semi-autonomous regions — balancing local data sovereignty with national interoperability.
V. Automation and DevOps Practices
Automation was a non-negotiable from day one.
As the sole infrastructure engineer, I needed to ensure that our growing number of IT developers — working on various services, APIs, and data flows — could confidently build and deploy without creating operational bottlenecks.
That meant building a system where every environment could be rebuilt, tested, and deployed automatically.
We standardized on:
- Terraform for provisioning and managing infrastructure on GCP
- GitHub for centralized collaboration and version control
- GitHub Actions for CI/CD pipelines handling builds, tests, and infrastructure updates
Almost all our deployment services are containerized and follow Twelve-Factor App principles, ensuring consistency across environments — whether deployed on Cloud Run, Compute Engine, or our future on-premise Kubernetes clusters.
⚙️ Our Automation Highlights
- Infrastructure as Code: Modular Terraform stacks for networking, monitoring, and FHIR environments
- CI/CD Pipelines: Automated image builds, vulnerability scans (via Trivy), and Terraform plan/apply workflows
- Containerization: Each microservice packaged in Docker for portable and reproducible deployments
- Version Control & Review: All changes flow through GitHub PRs with automated linting and review checks
- Secrets Management: Managed via Google Secret Manager with short-lived tokens and auto-rotation
- Health Checks & Verification: Every deployment validated before promotion to production
These practices made our ecosystem repeatable, auditable, and resilient — essential for healthcare-grade infrastructure where reliability and traceability matter as much as speed.
VI. Cost Optimization & Observability
Operating on a non-profit budget meant we had to be creative and efficient.
- ⚙️ Right-sized compute: Cloud Run autoscaling & preemptible VMs for batch jobs
- 💾 BigQuery cost controls: Partitioned tables, caching, and dry-run queries
- 🧹 Storage lifecycle: Automatically moving data to Nearline after 30 days
- 💰 Budget alerts: Email notifications for spending thresholds
This allowed us to maintain great performance while keeping costs sustainable.
VII. Future Direction: Hybrid & On-Premise
As more districts join the federation, regulatory and cost considerations push us toward a hybrid model.
Our next milestones:
- Move sensitive FHIR data on-premise, while keeping analytics and orchestration in the cloud
- Use Kubernetes (GKE / K3s) and Docker for consistent deployment
- Implement secure tunnels (Cloud VPN / Interconnect) for remote district connections
- Add local caching and sync mechanisms for regions with unstable internet
The goal: a flexible, federated system that can operate anywhere — from Jakarta to the most rural clinics.
VIII. Closing Thoughts
This project is still evolving, but it already marks a major step forward in Indonesia’s healthcare digital transformation.
We’re proving that federated, standards-based interoperability isn’t just a theory — it’s achievable, even under real-world constraints. Kudos to IT Team for collaborating and going hard on this one! You could check out more about @budiwidhiyanto as the fullstack engineer in this work.
If you’re working on healthcare interoperability, FHIR, or cloud-native DevOps in complex environments,
I’d love to connect and exchange ideas 👋
📎 Connect with me: LinkedIn @chiqors
🧠 Thanks for reading!
If this story resonates or you’re interested in FHIR, DevOps, or cloud architecture,
don’t forget to leave a ❤️ or follow — I’ll be posting part 2 soon!
Top comments (0)