SATUSEHAT: joining up the health records of thousands of facilities (public case analysis)
Solution case studies are scenarios based on common industry problem patterns. They do not refer to any client and are not MarkasDev project portfolio items. Our client portfolio is published separately.
Industry context
Disclosure: this is an analysis of a public case. SATUSEHAT is a programme of Indonesia's Ministry of Health. MarkasDev is not the implementer, not a client, and had no part in this project. This page is not our portfolio. We read the public documents to show what happens when technology has to connect thousands of different organisations.
According to its official documentation, SATUSEHAT is a health information exchange that connects healthcare facilities, regulators, payers and digital service providers. It uses the HL7 FHIR standard for its data model and APIs. According to an opinion piece on kumparan, the Ministry launched the platform on 26 July 2022.
The obligation rests on Ministry of Health Regulation No. 24 of 2022 on Medical Records. SATUSEHAT's monitoring guide states that every healthcare facility must send electronic medical record (EMR) data. The same kumparan piece gives 31 December 2023 as the integration deadline.
The case matters to hospital leaders, health offices, regional state enterprises and other public-service operators. The challenge is not buying an application. It is getting many different systems to exchange data in the same way, and keeping that exchange running after launch.
Problem
Without a shared data channel, patient data stays inside each facility. The Ministry itself says the aim is that patients no longer fill in new forms every time they move between facilities (Ministry release, 4 September 2023).
For staff, the problem is repeated data entry. The kumparan opinion author (Dr I Dewa Gede Dony Lesmana, 21 August 2026) describes one patient with suspected tuberculosis: staff must enter the same data into the Free Health Check (CKG) application, the tuberculosis information system (SITB), the community health centre system (SIMPUS) and the JKN insurance system. In his account this consumes time, adds administrative load and raises the risk of input errors.
The root cause is fragmentation. The same author says the Ministry once mapped more than 400 government health applications not integrated at facility level, run by different directorates with their own data standards and report formats. We cite this as that author's claim. We did not find the mapping document in a primary source.
Claims governance is a second problem. The Joint Circular of 30 July 2026 positions integrated EMR as the electronic document supporting JKN claims management. It refers to the need for a traceable data trail for transparency and oversight.
Constraints
- Thousands of facilities with different EMR systems: some use a vendor (partner system), some a self-built EMR, and both must be registered and verified on the SATUSEHAT Platform
- Fragmented government applications: according to the kumparan author, more than 400, each with its own data standards and report formats
- Uneven integration quality: the same author says many vendors still do only minimal bridging without sending diagnoses and prescriptions
- Limited IT staff and uneven infrastructure; BMI (quoted by youngster.id) points to infrastructure gaps outside Java and legacy systems in the regions
- Patient data is highly sensitive: security and access rights must be protected, and the national cyber agency (BSSN) co-signed the 2026 Joint Circular
- Compliance is set by regulation: Regulation 24/2022 and Health Minister Circular HK.02.01/MENKES/1030/2023, which vendor eHealth.co.id says carries sanctions for facilities with low data-submission coverage
Approach
Diagnose
This section is analysis: how a Diagnose phase would show up in a case like this. It is not a claim that MarkasDev worked on SATUSEHAT.
A paid Diagnose is useful before any code is written. For a hospital or health office the questions are concrete. Which EMR system is in use, and is its vendor verified on the SATUSEHAT Platform? Which data is already structured (visits, diagnoses) and which is still on paper or in spreadsheets? Who holds the production API access code, and what is the risk if that person changes roles? SATUSEHAT's own documentation lists the prerequisites: update the EMR system data in the DFO, Regfasyankes or RS Online application, then fill in the SATUSEHAT contact form to create an account. The production API access code is said to appear within 3 working days after that. Diagnose maps all these prerequisites and their owners, so deadlines and responsibilities are clear from the start.
Deliver
This is analysis too. The Deliver phase splits the work into milestones with acceptance criteria that can be checked. The dashboard-coverage guide written by vendor eHealth.co.id separates basic resources (visits and diagnoses) from supporting resources (for example observations, procedures and prescriptions). That order suits milestones: first visits and diagnoses are sent, then the supporting modules one by one.
Acceptance criteria must be measurable, for example successful FHIR transactions (HTTP 200 or 201) for the agreed resources, and no data typed twice at the registration desk. We wrote these criteria as an example. They are not official programme targets. A minimal integration that only turns a dashboard green would not pass. The case shows why: the kumparan author describes vendors that bridge minimally without diagnoses and prescriptions.
Operate
Also analysis. A working integration can still break: expired credentials, an EMR version change, or a community health centre losing its connection. SATUSEHAT's documentation provides operational tools: a FHIR Transaction Summary, a FHIR Transaction Log per resource with success or failure status and response codes (for example 200, 201, 400, 500), a default view of the last 90 days, and log downloads going back up to 6 months.
Under the Operate framework, these logs feed a monthly retainer: who monitors, which threshold triggers action, what response time applies (the SLA), and what report reaches leadership. In our view this is the difference between an integration finished on paper and one that is actually used.
High-level architecture
This diagram is our simplification of SATUSEHAT's public documentation and is not an official architecture diagram. Facilities obtain a production API access code through DFO, Regfasyankes or RS Online after updating their EMR system data. The FHIR Transaction Summary counts only transactions with HTTP status 200 or 201. The transaction log shows resource, method, status and response code so failures can be traced and audited. The SATUSEHAT RME Viewer is being integrated in stages and was first used at several Ministry vertical hospitals.
Typical outcomes
Every figure below comes from a source we opened, and their scopes differ, so they must not be compared directly. What is available is adoption data, not impact data.
On 4 September 2023 the Ministry said 792 hospitals through to community health centres had joined the SATUSEHAT Platform and the number was still growing (Ministry release).
In early 2026 a BMI report quoted by youngster.id (9 April 2026) said 95% of hospitals nationwide were connected at system level. This is a media report of a third-party report.
A Ministry deck titled Capaian Implementasi SatuSehat Maret 2026, which we read through a Scribd summary, gives 3,292 hospitals with 96.7% connected as of 2 March 2026. For primary clinics it gives 4,308 facilities with 73% connected. Caution: the summary uses different terms (registered, connected, integrated) and its percentages do not fully match a recalculation from the facility counts. Treat these as indicative. The gap between hospitals and primary clinics suggests primary care is lagging.
On 30 July 2026 the Ministry of Health, the Corruption Eradication Commission (KPK), the Ministry of Home Affairs, BPJS Kesehatan and the national cyber agency (BSSN) signed a Joint Circular on accelerating integrated EMR in SATUSEHAT for JKN claims management.
According to kumparan (21 August 2026), the monitoring dashboard updated in August 2026 shows all puskesmas and hospitals targeted by the dashboard as integrated and sending data regularly. We could not open the dashboard itself, so this is second-hand. The same author warns that repeated data entry at facilities still happens.
What we did not find: verified public figures on staff time saved, fewer rejected claims, or faster JKN claims. We did not invent them. Benefit statements in press releases, such as faster and more efficient claims, are stated goals rather than measured results.
Typical or expected outcomes, not claims about MarkasDev project results.About this analysis
This is an analysis of a public case, not a MarkasDev client project. We read Ministry of Health documents, the SATUSEHAT Platform documentation and some third-party articles. Every figure on this page comes from a source we opened, and we state its scope and limits. Media and opinion quotes are marked as second-hand.
Why this case matters to your organisation
Health is where late data affects people directly. The Minister's remark at the launch of the SATUSEHAT RME Viewer sums it up: data follows the patient, not the patient following the data. For hospital leaders, health offices and regional state enterprises, the same question applies elsewhere: local finance, logistics, public services. How much of your data is typed twice, and how quickly would you notice a failed data transfer?
Reading the case through Diagnose, Deliver, Operate
The pattern is three questions in order. What is the state of the systems and who owns each part? That is the job of Diagnose, most useful before anything is built. How do you connect different systems with clear acceptance criteria? See our system integration and API service. Who keeps that connection healthy after launch, and under what SLA? That is the ground of Operate.
If you are weighing when an up-front mapping deserves its own fee, we discuss it in When an organisation needs a paid Diagnose before building a system.
Limits of this analysis
We did not interview the Ministry or any facility. We did not open the national dashboard directly. Some figures come from third-party summaries and are marked that way. The launch date of the SATUSEHAT RME Viewer is inconsistent on the Directorate General's site (the release text says 1 September 2025, the page date says 1 September 2026), so we do not use its year. Treat this page as material for discussion, not as an audit report.
Sources
Accessed 30 September 2026.
- Ministry of Health, Kemenkes Perkuat Tata Kelola Klaim JKN melalui Integrasi Rekam Medis Elektronik dengan SATUSEHAT, 30 July 2026 (Indonesian).
- Ministry of Health, Begini Cara Terintegrasi ke SATUSEHAT bagi Fasyankes dan Penyedia Rekam Medis Elektronik, 4 September 2023 (Indonesian).
- SATUSEHAT Platform, Fasyankes (registration guide) (Indonesian).
- SATUSEHAT Platform, Dashboard Monitoring Integrasi SATUSEHAT (Indonesian).
- SATUSEHAT Platform, Log Transaksi FHIR (Indonesian).
- SATUSEHAT Platform, FHIR (Indonesian).
- Directorate General of Advanced Health Services, Launching Viewer SATUSEHAT RME (Indonesian).
- Dr I Dewa Gede Dony Lesmana (opinion), Bukan Menambah Aplikasi, Saatnya Menyatukan Data Kesehatan, kumparan, 21 August 2026 (Indonesian).
- youngster.id, Menuju Satu Data: Indonesia Pacu Transformasi Digital Kesehatan lewat SATUSEHAT, 9 April 2026 (quoting BMI; Indonesian).
- Ministry of Health (presentation, summary on Scribd), Capaian Implementasi SatuSehat Maret 2026 (Indonesian).
- eHealth.co.id, Panduan Cara Melihat Capaian Pengiriman Data SATUSEHAT, 5 August 2024 (vendor blog; Indonesian).