Lesson 0022 · FHIR · Modul SATUSEHAT · ±18 menit

SATUSEHAT: platform, token, prasyarat, NIK dan nomor IHS

Satu materi yang khas Indonesia: apa itu SATUSEHAT, cara service Node Anda mendapat token, langkah persiapan sebelum data klinis, dan bedanya NIK, nomor IHS, dan identifier lokal

Target lesson ini: Anda bisa menjawab "Pernah dengar SATUSEHAT? Bagaimana sistem kami terhubung ke sana?" dalam 60–90 detik (HIE berbasis FHIR R4, Sandbox vs Production, client credentials dari backend, prasyarat, NIK vs nomor IHS).

Modul ini membawa R4, REST, dan SMART dari lesson sebelumnya ke konteks Indonesia: SATUSEHAT.

Fakta SATUSEHAT diambil dari dokumentasi resmi Kemenkes, diakses 2026-10-26. Dokumentasi ini berubah cepat (halaman Standar Terminologi saja mencatat revisi v11.2 per 30 September 2026), jadi sebut "per dokumentasi terakhir yang saya baca" bila ditanya detail. ^[1] Klaim yang tidak bisa saya verifikasi dari halaman publik ditandai belum terverifikasi (diakses 2026-10-26).

1a. Apa itu SATUSEHAT, dan bagaimana sistem Anda masuk (±8 menit)

SATUSEHAT adalah "ekosistem pertukaran data kesehatan (HIE: Health Information Exchange)" yang menghubungkan sistem fasyankes, regulator, penjamin, dan penyedia layanan digital. Latar belakangnya: lebih dari 400 aplikasi kesehatan pemerintah yang belum terintegrasi dan tidak adanya standar format interoperabilitas. Tujuannya antara lain spesifikasi terstandar memakai HL7 FHIR dan HTTPS REST API, supaya developer bisa memakai bahasa apa pun, serta nomor SATUSEHAT sebagai single identifier pasien. ^[2]

Versi FHIR: halaman FHIR di dokumentasi hanya menyebut "HL7 FHIR" tanpa nomor versi ^[3], tetapi base URL-nya memakai path fhir-r4 ^[4] dan profile resminya diterbitkan sebagai SATUSEHAT FHIR R4 Implementation Guide di Simplifier, dengan canonical seperti https://fhir.kemkes.go.id/r4/StructureDefinition/Patient. ^[5] Jadi semua yang Anda pelajari di 0001–0020 tentang R4 berlaku di sini; inilah contoh nyata "IG nasional di atas R4" dari lesson 0003.

	Sandbox (Staging)	Production
OAuth base URL	`https://api-satusehat-stg.dto.kemkes.go.id/oauth2/v1`	`https://api-satusehat.kemkes.go.id/oauth2/v1`
FHIR base URL	`https://api-satusehat-stg.dto.kemkes.go.id/fhir-r4/v1`	`https://api-satusehat.kemkes.go.id/fhir-r4/v1`
Siapa bisa memakai	Fasyankes dan partner, termasuk yang belum terverifikasi; ada data pasien dummy khusus Sandbox	Setelah registrasi (Terdaftar) di SATUSEHAT Platform

Kutipan tabel: ^[4] ^[6] ^[7] Organization ID, Client ID, dan Client Secret dilihat setelah login ke portal SATUSEHAT Platform. Pembatasan resource per "Tipe Kode Akses API" (jenis institusi) ada di dokumen unduhan yang tidak saya baca: belum terverifikasi (diakses 2026-10-26). ^[6]

Autentikasi: OAuth2 client credentials dengan secret. Ini server-to-server, tanpa user dan tanpa redirect: ^[8]

// Hanya untuk dibaca: service Node (bukan React!) mengambil token SATUSEHAT
const OAUTH = "https://api-satusehat-stg.dto.kemkes.go.id/oauth2/v1";   // sandbox

const res = await fetch(`${OAUTH}/accesstoken?grant_type=client_credentials`, {   // grant_type di query string
  method: "POST",
  headers: { "Content-Type": "application/x-www-form-urlencoded" },
  body: new URLSearchParams({ client_id: process.env.SS_CLIENT_ID!, client_secret: process.env.SS_CLIENT_SECRET! }),
});
const { access_token, expires_in } = await res.json();   // contoh di docs: "token_type": "BearerToken", "expires_in": "3599"
// setiap request FHIR berikutnya: Authorization: Bearer ${access_token}

client_id dan client_secret diperlakukan seperti username dan password aplikasi; keduanya didapat dari Kemenkes. Respons gagal berupa OperationOutcome. ^[8]
Ada rate limit: "1 request per minute after a failed attempt", dan dokumentasi juga memperingatkan generate token baru yang terlalu sering. Konsekuensi desain: cache token di service Node sampai mendekati expires_in, jangan minta token per request. ^[8]
Bandingkan dengan SMART Backend Services (lesson 0019): sama-sama client_credentials tanpa user, tetapi SMART memakai JWT assertion bertanda tangan private key, sedangkan SATUSEHAT memakai client_secret. Karena secret, token tidak boleh diminta dari browser: React app memanggil backend Node Anda, backend yang memanggil SATUSEHAT.

Latihan 1 — Platform dan token

Jawab tanpa scroll ke atas.

Sekarang Anda tahu ke mana service Node mengirim data dan bagaimana mendapat token. Sebelum data klinis pertama bisa dikirim, ada urutan persiapan dan beberapa identifier yang harus dibedakan.

1b. Prasyarat, NIK, dan nomor IHS (±7 menit)

Sebelum mengirim data pendaftaran pasien dan diagnosis, dokumentasi menetapkan langkah persiapan: ^[9]

Autentikasi→ Organization (struktur organisasi)→ Location (struktur lokasi)→ nomor IHS Practitioner→ nomor IHS Patient→ Encounter, Condition, Observation, …

Nomor IHS pasien ({patient-ihs-number}) didapat dari Master Patient Index (MPI) Kemenkes, yang menyimpan data demografi berskala nasional. Nomor ini boleh disimpan di sistem internal, dan memudahkan pelaporan karena data diri pasien tidak perlu dikirim ulang setiap kali. ^[7] Resource klinis lalu merujuk pasien sebagai "Patient/{patient-ihs-number}". ^[10]
Alur pasien ber-NIK: cari dulu berdasarkan nomor IHS atau NIK. Kalau tidak ketemu, POST Patient dengan NIK sebagai identifier, nama, tanggal lahir, jenis kelamin, alamat, dsb.; data diverifikasi ke DUKCAPIL, dan bila cocok SATUSEHAT membuat nomor IHS baru. Kalau ada elemen yang tidak cocok, API mengembalikan error. ^[11]
Ini adalah id vs identifier dari lesson 0004 dalam versi Indonesia: NIK adalah business identifier, nomor IHS menjadi logical id di server SATUSEHAT, dan nomor rekam medis lokal adalah identifier lain lagi.

// Patient.identifier (contoh dari dokumentasi Patient SATUSEHAT, nilai disamarkan)
[
  { "use": "official", "system": "https://fhir.kemkes.go.id/id/nik",    "value": "################" },
  { "use": "official", "system": "https://fhir.kemkes.go.id/id/paspor", "value": "#########" },
  { "use": "official", "system": "https://fhir.kemkes.go.id/id/kk",     "value": "###############" }
]

// Encounter.identifier: nomor kunjungan LOKAL, namespace per organisasi
[ { "system": "http://sys-ids.kemkes.go.id/encounter/{organization-ihs-number}", "use": "official", "value": "REG-2026-0042" } ]

Sumber kedua potongan: ^[7] ^[12] {organization-ihs-number} adalah ID organisasi induk dari Master Sarana Index; value adalah ID atau nomor kunjungan lokal di sistem masing-masing organisasi. ^[12] Polanya persis "system menjamin keunikan" dari lesson 0004: dua rumah sakit boleh punya nomor REG-2026-0042, tapi system-nya berbeda. Alamat pasien juga memakai extension Indonesia, https://fhir.kemkes.go.id/r4/StructureDefinition/administrativeCode, untuk kode provinsi sampai desa, RT, dan RW. ^[7]

Latihan 2 — Prasyarat dan identifier

Latihan 3 — Jawab lisan

Pasang timer di ponsel, jawab dengan suara keras, baru buka jawaban contoh. Centang hanya poin yang benar-benar Anda sebut.

"Pernah dengar SATUSEHAT? Bagaimana sistem kami terhubung ke sana?" (60–90 detik)

Bandingkan dengan jawaban contoh dan checklist-nya

"SATUSEHAT adalah platform pertukaran data kesehatan nasional dari Kemenkes, sebuah Health Information Exchange yang memakai HL7 FHIR lewat HTTPS REST; IG-nya di Simplifier bernama SATUSEHAT FHIR R4 Implementation Guide dan base URL-nya memakai path fhir-r4/v1. Ada Sandbox untuk uji coba dengan pasien dummy, dan Production setelah fasyankes terdaftar. Autentikasinya OAuth2 client credentials: backend kami POST ke /oauth2/v1/accesstoken dengan client_id dan client_secret, lalu memakai Authorization: Bearer; token di-cache karena gagal autentikasi kena rate limit. Sebelum data klinis: Organization dan Location didaftarkan, nomor IHS Practitioner dan Patient diambil; Patient dicari lewat NIK. Setelah itu Encounter, Condition dengan ICD-10, Observation dengan LOINC, sesuai panduan use case. Error datang sebagai OperationOutcome yang kami simpan untuk diperbaiki."

Checklist: apakah Anda menyebut…

SATUSEHAT = HIE nasional Kemenkes berbasis HL7 FHIR (R4) + HTTPS REST?
Sandbox (pasien dummy) vs Production (setelah terdaftar)?
OAuth2 client_credentials: client_id + client_secret → Bearer token, dari backend?
prasyarat: Organization, Location, nomor IHS Practitioner dan Patient (MPI, NIK)?
resource klinis (Encounter, Condition, Observation) dengan terminologi standar?
error 4xx berupa OperationOutcome yang disimpan dan ditindaklanjuti?

Lulus kalau minimal 4 dari 6.

Berikutnya, lesson 0023: bagaimana data yang Anda kirim divalidasi, dan bagaimana data SIMRS lama dipetakan ke FHIR.

Sumber (SATUSEHAT diakses 2026-10-26): [1] Standar Terminologi (riwayat revisi) · [2] SATUSEHAT Playbook: Pendahuluan · [3] FHIR di SATUSEHAT · [4] Endpoint Information · [5] SATUSEHAT FHIR R4 Implementation Guide (Simplifier): profile Patient · [6] Kode Akses API (Sandbox) · [7] Resource Patient · [8] Katalog API: Akses Token · [9] Orientasi / Prerequisites · [10] Resource Observation · [11] MPI: Pasien dengan NIK · [12] Resource Encounter