The problem: care moves, but information may not follow
When a patient moves from one hospital to another, the receiving team may need recent observations, medication information, documented allergies and the referral note. If that information arrives late or in an unusable format, staff may ask the patient to repeat their history, contact the previous hospital or re-enter data manually.
Electronic records help within an institution. Continuity across institutions also requires reliable patient matching, compatible data, authorised access and a clear clinical handover. The receiving team needs to understand where a record came from, when it was recorded and whether it is complete enough for the current purpose.
What already exists in Indonesia
The Ministry of Health describes SATUSEHAT as a health information exchange ecosystem. Its documentation specifies HL7 FHIR for data models and APIs, and describes terminology and request validation.13 Its Patient documentation also explains the use of the national Master Patient Index and the patient's SATUSEHAT identifier.4
These are existing foundations. The proposal adds an AI-assisted process for helping hospitals prepare consistent data mappings. It does not assume that every hospital can already retrieve every other hospital's records, or that an AI agent has access to SATUSEHAT. The exact exchange route, supported resources and read permissions must be confirmed for the participating institutions.
An illustrative patient journey
Rina, a fictional patient, receives care at Hospital A and is referred to Hospital B. The receiving clinician needs an accurate account of the referral and relevant recent records.
In the proposed workflow, Hospital A prepares an agreed referral dataset from its electronic medical record. Approved mappings translate the relevant local fields into the shared structure. Checks confirm the patient, required fields and source information before the authorised exchange takes place.
Hospital B receives the dataset through the agreed route and displays it within the receiving team's workflow. A clinician reviews its source and date, reconciles relevant information with Rina and records any unresolved gaps. Hospital B can send an acknowledgement or a correction request to the responsible team.
The intended outcome is that Rina's next care team starts with usable information, with less work left to her as the messenger between hospitals.
What needs to be shared
The participating clinical teams should define a limited referral dataset for one pathway.
| Information | Why it matters | Necessary checks |
|---|---|---|
| Patient identifiers and encounter context | Link the record to the correct person and episode of care. | Resolve ambiguous matches; do not merge records on an AI suggestion alone. |
| Referral reason and note | Explain the handover and relevant context. | Preserve the original author, source and date. |
| Relevant medication and allergy information | Give the receiving team information to review and reconcile. | Preserve documented status; distinguish missing information from a recorded negative finding. |
| Selected observations and test results | Make relevant existing results available. | Preserve units, dates, test meaning and original values. |
The table is a proposed dataset, not a statement that every item is universally available through a particular SATUSEHAT API. The participating hospitals must confirm what they can lawfully exchange and what the receiving service can use.
Where agentic AI could help
Hospitals can use different field names, local codes and software. An integration team must establish how those fields correspond to the agreed target structure. A bounded AI agent could assist with this preparation by choosing among approved tools: a data dictionary, terminology lookup, schema validator and mapping-test runner.
For example, the agent could inspect a hospital's schema and propose a mapping for a local laboratory field. It would identify supporting definitions, run tests and present uncertain cases to a data steward. It must not infer a test's meaning solely from a similar-looking label or invent a unit that the source does not contain.
The proposed agent produces mapping candidates and test results. A designated technical and clinical reviewer approves the mapping before deployment. Once approved, a controlled connector applies the versioned mapping consistently. The agent does not need unrestricted access to live records to prepare mappings.
This architecture is a MOSAIC design proposal. The reviewed sources establish the interoperability foundations and AI-risk context; they do not establish that agentic AI already improves Indonesian hospital interoperability.
Illustrative architecture
The upper loop prepares mappings; the lower path exchanges patient information. The exchange should use approved SATUSEHAT interfaces where their capabilities and permissions support the pathway. All connections shown are proposed, subject to institutional approval and technical verification.
Keep responsibilities clear
| Participant or component | Responsibility |
|---|---|
| Hospital A | Maintain source records, authorise sharing and resolve errors originating in its data. |
| Mapping agent | Suggest mappings and run approved checks within a limited task and tool scope. |
| Data steward and clinical reviewer | Decide whether a mapping preserves meaning and approve or reject it. |
| Connector and exchange operator | Enforce approved transformations, access rules, delivery checks and logging. |
| Hospital B and receiving clinician | Review received information and decide how to use it in care. |
AI-assisted harmonisation cannot resolve missing source information, create authority to access records or make a clinical decision. FHIR validation checks structure and relevant rules; clinical usability also requires review of the information's meaning and context.
Safeguards for the proposed pilot
Indonesia's Permenkes 24/2022 on medical records requires confidentiality, integrity and availability for electronic medical records.5 Law 27/2022 on Personal Data Protection provides relevant obligations for processing personal data, including health information.6 The institutions need a documented lawful basis and access arrangements for the specific pathway. Patient consent, where required, must be handled as part of those arrangements.
The proposed pilot should:
- Begin with schemas and synthetic samples. Use identifiable records only when necessary, appropriately authorised and protected. Do not place patient records in an unapproved public AI service.
- Constrain the agent's tools. Allow only approved dictionaries, validators and test environments. Record tool calls, limit retries and prevent patient-data content from becoming instructions that change permissions.
- Require human approval. Version mappings, preserve test evidence and provide rollback. Uncertain results enter a review queue; they are not silently accepted.
- Preserve source meaning. Keep provenance and timestamps. Do not overwrite original clinical records or convert missing values into reassuring statements.
- Protect identity and access. Separate mapping preparation from patient matching and sharing permissions. Log access and enforce each participant's authorised scope.
- Plan for failures. Provide a controlled manual handover when exchange is unavailable, and a correction process when a shared record changes.
NIST's Generative AI Profile addresses risks including confabulation and the need to evaluate AI systems in their intended context.7 For this proposal, correctness must be demonstrated through reviewed mappings and representative tests rather than the agent's stated confidence.
Test whether AI adds value
Start with two hospitals, one referral pathway and a limited dataset. First establish a standards-based connector and handover process. Compare conventional mapping work with AI-assisted preparation using the same tasks and review requirements.
| Measure | Purpose |
|---|---|
| Time to produce and approve a mapping | Test whether AI reduces preparation effort after accounting for human review. |
| Mapping errors and reviewer corrections | Check whether the approach preserves data meaning. |
| Validation failures and unresolved patient matches | Measure exchange reliability and identity risks. |
| Time until relevant information is available to Hospital B | Measure the practical handover delay. |
| Staff re-entry and follow-up contacts | Check whether the process reduces repeated work. |
| Clinician-assessed handover completeness | Establish whether received information is usable. |
| Incidents, access violations and recovery time | Test safe operation and service continuity. |
Review repeated tests individually: some are clinically necessary and should not be counted as avoidable duplication. Analyse technical improvements separately from patient waiting time, which also depends on staffing, appointments and clinical needs.
No time-saving or patient-outcome result is claimed for this concept. A pilot should report failures, exclusions and review effort alongside successful exchanges.
Sources and further reading
This is an original MOSAIC proposal. The references support the existing Indonesian foundations and the safeguards discussion; they do not endorse or validate the proposed AI architecture. Sources were reviewed on 2 October 2026.
- Ministry of Health — What is SATUSEHAT? Defines the health information exchange ecosystem and the interoperability problem it addresses.
- SATUSEHAT — FHIR Explains the shared data-model and API foundations.
- SATUSEHAT — Interoperability validation Describes terminology checks, request validation and errors. These checks do not establish full clinical correctness.
- SATUSEHAT — Patient Explains the national patient identifier and Master Patient Index context.
- Ministry of Health — Permenkes 24/2022 Provides the regulatory context for medical records; Article 29 addresses electronic-record security principles.
- JDIH Komdigi — Law 27/2022 on Personal Data Protection Provides the personal-data processing context.
- NIST — Generative Artificial Intelligence Profile (2024) Provides a risk-management reference for evaluating and governing generative AI.