01 · Problem statement
The problem
Indonesia has built the rail. SATUSEHAT is the national health information exchange: a single platform through which patient records move between facilities in the FHIR standard (Fast Healthcare Interoperability Resources, the international format for health data exchange), so that a person's medical history follows them wherever they seek care. The mandate is complete. The Health Law (UU 17/2023) establishes the ministry's authority over integrated medical record data, and Ministerial Regulation 24/2022 requires every facility to connect its electronic medical records to the platform. Enforcement has begun: in March 2026 the Ministry of Health sanctioned 1,306 hospitals, roughly four in ten nationwide, for incomplete data submission, with consequences running from accreditation downgrades to operational shutdown.
Yet the rail runs far below capacity. The ministry's own monitoring counts integration by facilities actively and routinely transmitting data, and a large share of Indonesia's healthcare facilities still transmit little or none. The bottleneck is not willingness; sanctions have settled that question. It is translation. Getting a record onto the rail means converting a doctor's free-text clinical notes into ICD-10, SNOMED CT, and LOINC codes (the international vocabularies for diagnoses, clinical terms, and laboratory observations) packaged as FHIR resources: a translation from the language clinicians write to the language the rail speaks. That demands terminology expertise and integration engineering that a rural Puskesmas (community health centre), and most small facilities, simply do not have. Every facility is being asked to build its own translation capacity for a shared road, and most cannot. The result is a mandate that punishes the facilities least equipped to comply, a ministry making national decisions on partial data, and patients whose records stop at the facility door. And the stakes run past compliance: SATUSEHAT is a read-write rail, built so that a clinician can one day retrieve a patient's history from any facility, and every record that never gets written is a record no one can ever read back.
02 · How it works
How it works
When every facility faces the same translation problem, translation should be built once and shared, the way infrastructure is. The missing layer is a shared on-ramp: a translation service that any facility can use, so that connecting to SATUSEHAT stops being a bespoke engineering project.
Three cooperating software agents do the work, and translation is the reason AI fits it. A terminology mapper reads unstructured clinical notes and proposes the corresponding ICD-10, SNOMED CT, and LOINC codes, the task modern language models handle best because it is, literally, translation between languages. A validator checks every proposed code against the ministry's own terminology libraries and flags low-confidence results for human review; a clinician confirms, the machine learns, and nothing enters the national record unverified. A synchronisation agent then packages validated records as FHIR resources and submits them through SATUSEHAT's standard interfaces, keeping the connection current as systems change. The facility keeps its existing records system; the layer meets it where it is.
Two public rails come out of this, and naming them is the point. The first is stress-tested existing infrastructure: every silent facility the on-ramp connects strengthens the write path on which the read path depends, because continuity of care means retrieving records through the platform, and only written records can be retrieved. The second is new, and it is what makes the title literal: the accumulated, clinician-validated corpus of translations from Indonesian clinical language to the standard vocabularies. That corpus does not exist today, every integrator rebuilds fragments of it privately, and once built and published as a public asset it is inherited by every EMR vendor, every facility, and every future integration, which is what makes it infrastructure rather than a product. The condition is governance: the corpus and the translation service must be owned publicly and openly specified, or the pilot produces one more proprietary connector and the infrastructure claim fails. The pilot is designed to settle that governance question, in the pattern the Centre for Digital Public Infrastructure describes for shared building blocks generally: government-anchored standards, minimal data movement, reusable by all.
This use case is the prerequisite half of a pair: our health interoperability use case addresses the read path, the exchange layer through which coded records serve care across facilities.
03 · Who we need
Who we need
We are inviting partners to scope a bounded first pilot: one cohort of currently silent facilities, one clinical module set, one shared translation service, with the corpus published as a public good from day one and scope limited to the record types the mandate already requires.
Three roles need filling. Problem owners, the health authorities that carry the cost of the integration gap and own the terminology standards the service must honour, to anchor governance of the corpus and the sandbox under which the pilot runs. Adopters, the facilities that would connect through the on-ramp and, critically, the EMR and SIMRS vendors whose systems would consume the published translations, since a shared corpus is only infrastructure if the market builds on it. And partners able to mobilise resources for a time-bound pilot, distinct from the platform itself, which remains government-owned. The Alliance's role is to convene, matchmake, and carry lessons across sectors. If your institution fits one of these roles, we want to hear from you.
04 · Get involved
Help move this from problem to proof.
Bring operational evidence, contribute technical expertise, help validate a regulatory assumption, join a pilot, or help fund the research this use case still needs.
