Forem: Choirunnisa Hapsari

Integrating Indonesian Hospitals with SATUSEHAT: A Developer's Guide to HL7 FHIR

Choirunnisa Hapsari — Sat, 04 Apr 2026 08:38:18 +0000

Indonesia is building a national health data exchange called SATUSEHAT, and every hospital in the country needs to integrate with it. If you're a developer tasked with this integration, this guide covers the architecture, FHIR resource types, common gotchas, and a realistic timeline for going live.

What is SATUSEHAT?

SATUSEHAT is Indonesia's national health data platform, managed by the Ministry of Health (Kemenkes). Think of it as Indonesia's answer to nationwide health interoperability — a centralized FHIR R4 server where hospitals push clinical encounter data.

The mandate is clear: hospitals that fail to integrate face sanctions from the Directorate General of Health Services (Dirjen Yankes). As of 2026, over 1,200 hospitals have been flagged for non-compliance, with a June 2026 deadline looming.

The platform runs on HL7 FHIR R4 and exposes RESTful APIs for data submission. The developer portal is at satusehat.kemkes.go.id.

FHIR Resources You Need to Implement

SATUSEHAT doesn't require every FHIR resource — just a specific subset relevant to Indonesian clinical workflows. Here's what you'll need:

Resource	Purpose	Required?
`Organization`	Your hospital entity	Yes
`Location`	Departments, rooms, beds	Yes
`Practitioner`	Doctors, nurses	Yes
`Patient`	Patient demographics (linked to NIK)	Yes
`Encounter`	Clinical visits/admissions	Yes
`Condition`	Diagnoses (ICD-10)	Yes
`MedicationRequest`	Prescriptions	Yes
`MedicationDispense`	Pharmacy dispensing	Yes
`Observation`	Vital signs, lab results	Conditional
`Specimen`	Lab specimens (SNOMED-CT)	Conditional
`ImagingStudy`	Radiology (DICOM + NIDR)	Conditional

The "conditional" resources depend on your hospital's service scope. A hospital with a radiology department needs ImagingStudy; a small hospital without a lab may skip Specimen initially.

Authentication Flow

SATUSEHAT uses OAuth 2.0 Client Credentials flow. You register your application in the developer portal to get a client_id and client_secret, then exchange them for an access token:

# Get access token
curl -X POST https://api-satusehat.kemkes.go.id/oauth2/v1/accesstoken?grant_type=client_credentials \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET"

{
  "access_token": "eyJ...",
  "token_type": "BearerToken",
  "expires_in": "3599",
  "scope": ""
}

Tokens expire in 1 hour. Build token refresh into your integration layer — don't fetch a new token per request.

The Integration Architecture

Here's the pattern we've found works well for Indonesian hospitals:

┌──────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   SIMRS /    │     │   Integration    │     │   SATUSEHAT     │
│   RME        │────▶│   Gateway        │────▶│   FHIR Server   │
│   Database   │     │                  │     │                 │
└──────────────┘     │  - FHIR mapper   │     └─────────────────┘
                     │  - Queue system  │
                     │  - Retry logic   │
                     │  - Audit log     │
                     └──────────────────┘

The Integration Gateway sits between your hospital's SIMRS and SATUSEHAT. It handles:

Data mapping: Transform SIMRS-specific data models to FHIR R4 resources
Queueing: Buffer submissions during network issues (hospital internet in Indonesia can be unreliable)
Retry with backoff: SATUSEHAT API has rate limits and occasional downtime
Audit logging: Track every submission for compliance reporting

Example: Mapping an Encounter

// Transform SIMRS visit data to FHIR Encounter
function mapToFHIREncounter(visit) {
  return {
    resourceType: "Encounter",
    status: mapVisitStatus(visit.status),
    class: {
      system: "http://terminology.hl7.org/CodeSystem/v3-ActCode",
      code: visit.type === "inpatient" ? "IMP" : "AMB",
      display:
        visit.type === "inpatient" ? "inpatient encounter" : "ambulatory",
    },
    subject: {
      reference: `Patient/${visit.patient_satusehat_id}`,
      display: visit.patient_name,
    },
    participant: [
      {
        individual: {
          reference: `Practitioner/${visit.doctor_satusehat_id}`,
          display: visit.doctor_name,
        },
      },
    ],
    period: {
      start: formatToFHIRDateTime(visit.admission_date),
      end: visit.discharge_date
        ? formatToFHIRDateTime(visit.discharge_date)
        : undefined,
    },
    location: [
      {
        location: {
          reference: `Location/${visit.department_satusehat_id}`,
          display: visit.department_name,
        },
      },
    ],
    serviceProvider: {
      reference: `Organization/${HOSPITAL_ORG_ID}`,
    },
  };
}

Common Gotchas

After integrating multiple hospitals, here are the pitfalls that catch most teams:

1. Patient NIK Matching

SATUSEHAT links patients via NIK (national ID number). The problem: many hospital databases have inconsistent NIK data — missing digits, typos, or placeholder values. You'll need a data cleanup step before integration.

def validate_nik(nik: str) -> bool:
    """Indonesian NIK is exactly 16 digits."""
    if not nik or not nik.isdigit():
        return False
    if len(nik) != 16:
        return False
    # First 6 digits = region code (validate against known codes)
    region = nik[:6]
    return region in VALID_REGION_CODES

2. SATUSEHAT ID Mapping

Every entity (patient, practitioner, location) needs a SATUSEHAT-assigned ID. You need to:

Search SATUSEHAT first to find existing records
Create only if not found
Store the mapping in your local database

Never hardcode SATUSEHAT IDs. They can change during data migrations.

3. Sandbox vs. Production Differences

The sandbox environment at api-satusehat-stg.kemkes.go.id doesn't perfectly mirror production. Some things we've seen:

Sandbox accepts malformed resources that production rejects
Rate limits are more generous in sandbox
Some code systems have different validation rules

Always do a pilot run in production with real (consented) data before declaring integration complete.

4. FHIR DateTime Formatting

SATUSEHAT is strict about datetime formats. Use ISO 8601 with timezone:

// Correct
"2026-04-04T10:30:00+07:00"

// Wrong (will be rejected)
"2026-04-04 10:30:00"
"04/04/2026"

5. ICD-10 Code Validation

SATUSEHAT validates ICD-10 codes against the ICD-10 WHO version, not ICD-10-CM. Some codes that exist in ICD-10-CM don't exist in the WHO version. Make sure your mapping uses the correct codeset.

Realistic Timeline

Based on our experience across multiple hospital integrations:

Phase	Duration	Activities
Registration	1-2 weeks	Portal registration, credential setup, team onboarding
Data Audit	2-3 weeks	NIK cleanup, master data mapping, gap analysis
Development	4-6 weeks	FHIR mapper, gateway, queue system, retry logic
Sandbox Testing	2-3 weeks	Submit test data, fix validation errors, load testing
Production Pilot	2-3 weeks	Limited department rollout, monitor success rates
Full Go-Live	1-2 weeks	All departments, monitoring, staff training

Total: 12-19 weeks for a typical hospital. Smaller hospitals with simpler SIMRS can be faster; large hospitals with complex legacy systems take longer.

Monitoring Post-Integration

Once live, track these metrics:

Submission success rate — aim for >98%. Below that, investigate validation errors.
Retry rate — high retries suggest network or rate limit issues.
Data completeness — are all departments submitting? Some may quietly drop off.
Latency — SATUSEHAT API response times can spike during peak hours (morning clinic times).

# Simple monitoring check
def check_submission_health(last_24h_stats):
    success_rate = stats.success / stats.total
    if success_rate < 0.98:
        alert(f"SATUSEHAT submission rate dropped to {success_rate:.1%}")
    if stats.avg_retry > 2:
        alert(f"High retry rate: {stats.avg_retry:.1f} per submission")

Resources

SATUSEHAT Developer Portal — official API docs, sandbox access, code system references
Cara Integrasi SATUSEHAT dengan SIMRS: Panduan Teknis — step-by-step guide in Indonesian
HL7 FHIR R4 Specification — the standard SATUSEHAT is built on
MedMinutes — health IT tools for Indonesian hospitals, including managed SATUSEHAT integration

MedMinutes provides managed SATUSEHAT integration for hospitals that want to comply without building the entire pipeline in-house. We handle the FHIR mapping, queue management, and ongoing API change monitoring. Currently serving 50+ hospitals across Indonesia.

Building an AI Clinical Decision Support System (CDSS) for Indonesian Hospitals

Choirunnisa Hapsari — Sat, 04 Apr 2026 08:37:57 +0000

Medication errors remain one of the leading causes of preventable patient harm worldwide. The WHO estimates that unsafe medication practices cost $42 billion annually and that CDSS implementations can reduce prescribing errors by up to 55%. In Indonesia, where over 2,800 hospitals serve 270+ million people, the challenge is amplified by fragmented health IT systems and varying levels of digital maturity.

This article walks through how we approached building a Clinical Decision Support System (CDSS) tailored to Indonesian hospital workflows — the architecture decisions, module design, and integration patterns that make it work in practice.

The Regulatory Push

Indonesia's Permenkes No. 24/2022 on Electronic Medical Records explicitly calls for clinical decision support capabilities in hospital information systems. This isn't just a nice-to-have — hospitals pursuing accreditation (SNARS) need to demonstrate medication safety protocols, and CDSS directly supports that requirement.

The regulation also aligns with the broader SATUSEHAT national health data platform initiative, which mandates HL7 FHIR-based interoperability. Any CDSS needs to work within this ecosystem.

Architecture: Why a Chrome Extension + API Gateway

Here's the reality in Indonesian hospitals: most already run some form of SIMRS (Hospital Information System) or RME (Electronic Medical Record). Ripping that out and replacing it is expensive, disruptive, and politically difficult.

Our approach: overlay, don't replace.

┌─────────────────────────────────────────────┐
│  Hospital Browser (any SIMRS/RME web app)   │
│  ┌───────────────────────────────────────┐  │
│  │  Chrome Extension (Content Script)     │  │
│  │  - Reads clinical context from DOM     │  │
│  │  - Injects CDSS overlay panels         │  │
│  │  - Sends anonymized queries to API     │  │
│  └──────────────┬────────────────────────┘  │
└─────────────────┼───────────────────────────┘
                  │ HTTPS
┌─────────────────▼───────────────────────────┐
│  API Gateway (Cloud Run — Jakarta region)    │
│  - Authentication & rate limiting            │
│  - Routes to appropriate CDSS module         │
│  - Tier-based access control                 │
├──────────────────────────────────────────────┤
│  ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│  │ ICD-10   │ │ Drug     │ │ AI Resume    │ │
│  │ Engine   │ │ Interact.│ │ Generator    │ │
│  └──────────┘ └──────────┘ └──────────────┘ │
└──────────────────────────────────────────────┘

The Chrome Extension reads the clinical context from whatever web-based SIMRS the hospital is using, then sends queries to our Cloud Run API Gateway deployed in the Jakarta (asia-southeast2) region for low latency. This means zero changes to the hospital's existing system.

The 4 CDSS Modules

1. SOAP Extraction

Extracts structured SOAP (Subjective, Objective, Assessment, Plan) data from free-text clinical notes in the RME. This feeds downstream modules.

# Simplified extraction flow
def extract_soap(clinical_note: str) -> SOAPResult:
    """Extract SOAP components using LLM with medical prompt."""
    response = model.generate(
        prompt=SOAP_EXTRACTION_PROMPT,
        input_text=clinical_note,
        output_schema=SOAPSchema
    )
    return validate_soap(response)

2. ICD-10 AI Recommendations

Takes the extracted SOAP data and suggests appropriate ICD-10 and ICD-9-CM codes. This is powered by a FastAPI backend with ChromaDB for vector similarity search against the full ICD codeset, combined with Gemini 2.0 Flash for contextual reasoning.

# ICD recommendation engine
@app.post("/api/icd/recommend")
async def recommend_icd(soap: SOAPInput):
    # Vector search for candidate codes
    candidates = chromadb_collection.query(
        query_texts=[soap.assessment],
        n_results=10
    )
    # LLM re-ranking with clinical context
    ranked = await rerank_with_context(
        candidates=candidates,
        soap=soap,
        coding_guidelines=ICD_10_RULES
    )
    return ranked[:5]  # Top 5 recommendations

Why this matters: accurate ICD coding directly affects BPJS (national insurance) claim approval rates. Miscoding means rejected claims, which means revenue loss for the hospital.

3. Drug Interaction Detection

Real-time detection of drug-drug interactions when a physician prescribes medication. The interaction database covers severity levels (minor, moderate, major, contraindicated) and includes Indonesian formulary (FORNAS) context.

// Example API response
{
  "interaction_found": true,
  "severity": "major",
  "drug_a": "Warfarin",
  "drug_b": "Aspirin",
  "mechanism": "Increased bleeding risk via additive anticoagulant effects",
  "recommendation": "Consider alternative or adjust dosing with INR monitoring",
  "references": ["DrugBank:DB00682", "MIMS Indonesia"]
}

4. AI Medical Resume Generator

Automatically generates structured medical resumes (discharge summaries) from the patient's encounter data. This saves physicians significant documentation time — in our observations, 15-30 minutes per patient discharge.

Integration Pattern: The Overlay Approach

The key insight is that hospital IT teams are cautious (rightfully so). A Chrome Extension gives us:

Zero infrastructure changes at the hospital
Gradual rollout — install on one workstation, test, then expand
Works with any web-based SIMRS — we read DOM elements, not database tables
Easy updates — push new extension versions without hospital IT involvement

The extension uses content scripts to detect which SIMRS is running, then applies the appropriate DOM selectors to extract clinical context:

// Detect SIMRS and load appropriate adapter
const adapters = {
  "simrs-khanza": KhanzaAdapter,
  "e-puskesmas": EPuskesmasAdapter,
  generic: GenericFormAdapter,
};

const detected = detectSIMRS(document);
const adapter = new adapters[detected]();
const clinicalContext = adapter.extractContext();

Deployment Considerations

Indonesian hospitals have diverse IT setups. Some have reliable internet; others are in remote areas with intermittent connectivity. We support both:

Cloud deployment: API Gateway on Cloud Run (Jakarta region), auto-scaling, pay-per-request
On-premise deployment: Docker containers for hospitals that require data to stay on-site (common for military and government hospitals)

Latency matters in clinical workflows. A drug interaction check that takes 5 seconds won't get used. Our p95 response time for the Drug Interaction module is under 200ms from Jakarta-region hospitals.

What We Learned

Clinician trust is earned, not assumed. We added confidence scores and literature references to every recommendation. Physicians won't act on a black-box suggestion.
Local formulary matters. International drug databases don't cover all medications available in Indonesia. We maintain an Indonesian drug mapping layer.
Start with one module. Hospitals that adopted Drug Interaction first, then expanded to ICD recommendations, had much higher sustained usage than those that tried to deploy everything at once.
Regulatory alignment opens doors. Framing CDSS as a Permenkes 24/2022 compliance tool made procurement conversations significantly easier.

Resources

What is CDSS? Complete Guide for Indonesian Hospitals — detailed overview of CDSS concepts and benefits (Indonesian)
MedMinutes CDSS Product Page — module details and integration options
WHO Medication Safety Report — global medication error statistics
Permenkes No. 24/2022 — Indonesian RME regulation

MedMinutes builds health IT tools for Indonesian hospitals, including AI-powered CDSS, claim audit systems, and SATUSEHAT integration. We're based in Indonesia and serve 50+ hospitals across 8+ provinces.

Building a Real-Time Clinical Decision Support System for Indonesian Hospitals

Choirunnisa Hapsari — Fri, 20 Mar 2026 10:23:58 +0000

Indonesian hospitals face a unique challenge: they need clinical decision support, but most CDSS solutions are designed for Western healthcare systems. At MedMinutes, we're building tools specifically for Indonesia's healthcare ecosystem — and CDSS is one of our newest products.

Here's why this matters and what we've learned so far.

Why Indonesian Hospitals Need Their Own CDSS

Indonesia's national health insurance (BPJS Kesehatan) covers over 200 million people. Hospitals submit thousands of claims daily, and mistakes — wrong drug combinations, incorrect ICD-10 codes, missed diagnoses — lead to rejected claims and patient safety issues.

Off-the-shelf CDSS tools from the US or Europe don't work well here because they don't account for:

Formularium Nasional (FORNAS) — Indonesia's national drug formulary that dictates what BPJS will reimburse
INA-CBG coding — Indonesia's own case-based grouping system, different from standard DRG
Local drug brands — Doctors prescribe by Indonesian brand names (Glucophage, Diafac, Eraphage), not just generic names
Infrastructure reality — Many hospitals outside Java have unreliable internet connections

Our Approach: Browser Extension

Rather than asking hospitals to replace their existing systems, we built CDSS as a browser extension. It works on top of whatever Hospital Information System (HIS/SIMRS) the hospital already uses.

This was a practical decision. Indonesian hospitals use dozens of different HIS vendors. Building native integrations for each one would take forever. A browser extension that reads the screen and provides real-time alerts is much more realistic.

What the CDSS Actually Does

When a doctor is working in their HIS, our extension:

Detects the diagnosis being entered and cross-checks it against clinical pathways
Flags drug interactions — checking prescribed medications against known interactions, with attention to Indonesian brand names
Validates ICD-10 codes — making sure the diagnosis codes match what BPJS expects for the treatment being given
Suggests missing steps — like reminding a doctor that an HbA1c test is overdue for a diabetes patient

The goal isn't to replace clinical judgment. It's to catch the routine stuff that's easy to miss when you're seeing 40+ patients a day.

The Hard Part: Localization

The engineering isn't the hardest part. The real challenge is building an accurate knowledge base for Indonesia's specific context.

For example, mapping drug interactions requires knowing that "Metformin" might appear as "Glucophage", "Diafac", "Eraphage", or a dozen other brand names in different hospitals. This mapping work requires close collaboration with clinical pharmacists — it's not something you can just scrape from a database.

Similarly, Indonesia's clinical pathways (Panduan Praktik Klinis) are published by specialist associations like PAPDI, IDAI, and POGI. These aren't always digitized, and they get updated regularly. Keeping our rule database current is an ongoing effort.

What We've Learned Building Healthcare Tools

We've been in the Indonesian healthtech space for a while now. Our first product, BPJScan, helps hospitals audit their BPJS claims to catch errors before submission. A few lessons that carry over:

Hospitals buy compliance, not technology. The feature that convinces a hospital director to adopt a new tool is almost always "this will reduce your claim rejections" — not "this uses cutting-edge AI." We learned this with BPJScan and it applies equally to CDSS.

Start narrow, then expand. We focus on one hospital, one HIS vendor, one clinical specialty first. Get it working reliably. Then generalize. Trying to build for everyone at once is a recipe for building something that works for no one.

Internet reliability matters more than you think. We design everything to work offline-first. Clinical tools that break when the WiFi drops are not acceptable when patient care is involved.

Where We Are Now

CDSS is still early. We're piloting it alongside our existing products (BPJScan for claim auditing, RME for electronic medical records) in hospitals that already use our platform. The advantage is that hospitals using our RME get deeper CDSS integration — but the browser extension approach means any hospital can benefit.

If you're working on healthtech in Southeast Asia, or if you're a developer interested in healthcare challenges in emerging markets, I'd love to hear from you. The problems here are genuinely different from what you see in US/EU healthtech, and there's a lot of room for creative solutions.

Check out what we're building at MedMinutes.

This is part of a series on building healthtech infrastructure for emerging markets. Previously: How AI is Transforming Hospital Claim Auditing in Indonesia.

How AI is Transforming Hospital Claim Auditing in Indonesia

Choirunnisa Hapsari — Thu, 19 Mar 2026 03:01:36 +0000

Indonesia's national health insurance (BPJS Kesehatan) covers 270+ million people across 2,600+ hospitals. Every hospital submits thousands of claims monthly through the INA-CBG system — Indonesia's adaptation of Diagnosis Related Groups (DRG).

The Problem: Revenue Leakage

Studies show that 70% of severity level codes are incorrect in Indonesian hospital claims, and 40% of pending claims are caused by coding errors. Most hospitals still audit claims manually — reviewing a small sample of cases with spreadsheets. This means most errors go undetected.

How AI Changes the Game

AI-powered claim audit tools can:

Analyze 100% of claims (not just samples) in minutes
Detect undercoding where severity levels don't match documentation
Find missed diagnosis codes that affect INA-CBG tariff calculations
Identify revenue recovery opportunities across thousands of cases
Monitor coding patterns per physician for targeted improvement

Global research shows AI can reduce medical coding errors by up to 38%, and hybrid AI+human approaches achieve 99% accuracy.

The Indonesian Context

With Indonesia transitioning from INA-CBG to iDRG (Indonesian DRG) in 2025-2027, the complexity of medical coding is increasing dramatically — from ~1,000 to ~22,000 diagnosis codes. Manual auditing is becoming impossible at scale.

Platforms like MedMinutes BPJScan are addressing this by analyzing claim TXT files automatically, detecting undercoding, and finding revenue optimization opportunities for 50+ hospitals across Indonesia.

Key Takeaways

Manual claim auditing can't keep up with modern healthcare volume
AI doesn't replace casemix teams — it augments them by handling data-heavy analysis
The ROI is clear: hospitals typically recover 15-30% more revenue with systematic AI auditing
The iDRG transition makes AI tools essential, not optional

Sources: BPJS Kesehatan Annual Report, WHO DRG Guidelines, Indonesian Journal of Health Economics, Permenkes No. 76/2016