Masa Depan IT Kesehatan di Indonesia: Habis SATUSEHAT, Terus Apa?

Masa Depan IT Kesehatan di Indonesia: Habis SATUSEHAT, Terus Apa?

Ngaku deh, Sobat IT RS pasti sudah kenyang sama kata “SATUSEHAT”. Dari workshop, webinar, sampai grup WA isinya itu-itu melulu. Ada yang bilang SATUSEHAT ini solusi, ada juga yang curiga ini proyek “maksa” — apalagi kalo inget dulu era integrasi BPJS, banyak RS pusing kepala karena data claim tiba-tiba nyangkut. Sekarang, setelah semua pontang-panting migrasi ke SATUSEHAT, pertanyaannya: terus abis ini mau ngapain?

Bulan ini, roadmap digitalisasi Kemenkes makin jelas. Tapi, lapangan beda sama presentasi rapih di PowerPoint. Artikel ini bahas apa realita, tantangan, harapan, dan arah IT kesehatan Indonesia setelah SATUSEHAT. Bukan cuman “dari atas”, tapi ngelihat juga dari sudut pandang petugas IT RS: yang ngoprek server, migrasi data, sampai “tukang benerin printer” buat kebutuhan bridging.

SATUSEHAT: Titik Awal, Bukan Akhir

SATUSEHAT sering dikira finish line digitalisasi. Padahal, ini baru start. SATUSEHAT tujuannya konsolidasi data kesehatan nasional: rekam medis elektronik (RME), data imunisasi, farmasi, sampai logistik. Di lapangan, implementasinya jauh dari mulus:

  • RS belum semua punya SDM siap main API, JSON, OAuth2
  • Jaringan lelet, server sering “ngambek” gara-gara beban request naik drastis
  • Konversi kode (ICD-10, SNOMED, LOINC) bikin tim IT lembur tiap minggu
  • Data legacy dari SIMRS lama kadang ga compatible, penuh “sampah” dan entry ganda

Kemenkes sudah kasih beberapa guideline, tapi realitanya: tiap vendor dan RS akhirnya punya solusi “kreatif” sendiri-sendiri. Ada yang custom middleware, ada yang hardcode mapping, ada juga yang cuman upload CSV manual (asal lulus audit, bos!).

Studi Kasus: Middleware SATUSEHAT Lokal

RS X di Jawa Tengah, SIMRS-nya lawas (Delphi+Firebird). Semua bridging ke SATUSEHAT lewat service worker Node.js, “nangkring” di server lama. Format data seperti ini:

{
  "resourceType": "Patient",
  "identifier": [
    {
      "system": "http://sys-ktp.kemkes.go.id",
      "value": "3201234567890123"
    }
  ],
  "name": [
    {
      "family": "Setiawan",
      "given": [ "Adi" ]
    }
  ],
  "gender": "male",
  "birthDate": "1990-06-21"
}

Setiap data keluar, script cleaning jalan. Field kosong discard, data duplikat merge, value “aneh” (jenis kelamin: “L”, “P”, “Perempuan”, “Laki-laki”) di-normalisasi:

// Normalisasi gender
function normGender(str) {
  str = str.toLowerCase();
  if (str === 'l' || str === 'laki-laki' || str === 'male') return 'male';
  if (str === 'p' || str === 'perempuan' || str === 'female') return 'female';
  return 'unknown';
}

Walau kelihatan remeh, logika beginian yang bikin migrasi ke SATUSEHAT sering makan waktu berbulan-bulan. Karena tiap RS “DNA” datanya beda, mapping field dan cleaning ga bisa copy-paste dari satu RS ke RS lain.

Roadmap Digitalisasi Kemenkes: Lebih dari Sekadar SATUSEHAT

Kemenkes sudah rilis beberapa dokumen strategis digitalisasi kesehatan. Gambar besarnya:

  • 2023-2025: Konsolidasi data nasional via SATUSEHAT, adopsi RME wajib
  • 2026-2028: Interoperabilitas antar aplikasi kesehatan (RS, puskesmas, klinik, lab, apotek)
  • 2028+: Ekosistem healthtech — AI diagnosa, decision support, telemedicine terintegrasi, big data & research

Artinya, SATUSEHAT bukan finish line. Ini baru pondasi. Di depan mata, IT RS bakal “dituntut” siap main di beberapa area:

  • Standarisasi API: FHIR, HL7, OAuth2, OpenID Connect
  • Validasi & cleaning data real time, bukan cuma batch upload
  • Event-driven architecture (kudu ngerti queue, Kafka, message broker)
  • Data protection: enkripsi, masking, access log, audit trail
  • Monitoring & alerting: dashboard real time, bukan cuman “tunggu komplain user”

Contoh: Standarisasi API FHIR

FHIR (Fast Healthcare Interoperability Resources) jadi backbone standard SATUSEHAT. Dulu RS cukup pakai CSV atau web service “asal nyambung”. Sekarang kudu bisa “bicara” FHIR:

GET /fhir/Patient?identifier=3201234567890123
Authorization: Bearer <token>
Accept: application/fhir+json

Respons yang valid FHIR:

{
  "resourceType": "Bundle",
  "type": "searchset",
  "entry": [
    {
      "resource": {
        "resourceType": "Patient",
        "id": "12345",
        "identifier": [ ... ],
        "name": [ ... ],
        ...
      }
    }
  ]
}

Di dunia nyata, 70% masalah integrasi bukan karena server atau jaringan, tapi karena format data “nyeleneh” (misal, tanggal lahir ‘DD-MM-YYYY’ bukan ‘YYYY-MM-DD’), atau field wajib kosong karena data sumbernya ga lengkap.

Tantangan IT RS Setelah SATUSEHAT

1. Beban Integrasi Naik — Sumber Daya Tetap

Tim IT RS kecil. Satu-dua orang, ngerjain semuanya: SIMRS, jaringan, PC error, bridging BPJS, sekarang urusan FHIR SATUSEHAT. Demand naik, SDM tetap. Risiko burnout, error makin sering nongol:

  • Query delay, bottleneck waktu upload ke SATUSEHAT
  • Script cleaning crash, data gagal masuk
  • Notifikasi error ketumpuk sama email spam

Tips: automate yang bisa di-automate. Contoh, rekap error upload dibuat auto-email/messaging ke WA/Telegram admin. Contoh simple pakai Node.js + Telegram API:

const axios = require('axios');
function sendTelegram(msg) {
  axios.post(
    'https://api.telegram.org/bot<TOKEN>/sendMessage',
    { chat_id: '<CHAT_ID>', text: msg }
  );
}

2. Data Legacy Berantakan

SIMRS lama penyimpanan asal-asalan. Tabel pasien dobel, field kosong, kode diagnosis beda-beda. Proses cleaning dan migrasi makan waktu lama.

Struktur tabel standar FHIR:

CREATE TABLE patient (
  id SERIAL PRIMARY KEY,
  identifier VARCHAR(32) NOT NULL UNIQUE,
  name VARCHAR(128),
  gender VARCHAR(8),
  birth_date DATE
);

Bandingkan dengan SIMRS lama:

CREATE TABLE pasien (
  id INT,
  no_rm VARCHAR(12),
  nama_lengkap VARCHAR(100),
  sex CHAR(1),
  tgl_lahir VARCHAR(10)
);

Solusi: mapping & cleaning dengan script. Tapi cleaning manual makan waktu. Saran: setiap ada data baru masuk, validate langsung. Contoh trigger di PostgreSQL:

CREATE OR REPLACE FUNCTION check_gender()
RETURNS TRIGGER AS $$
BEGIN
  IF NEW.gender NOT IN ('male','female','unknown') THEN
    RAISE EXCEPTION 'Invalid gender value: %', NEW.gender;
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER gender_validate
BEFORE INSERT OR UPDATE ON patient
FOR EACH ROW EXECUTE FUNCTION check_gender();

3. Keamanan: Data Pasien Makin Mudah Bocor

API terbuka ke SATUSEHAT = permukaan serangan makin lebar. Data pasien muter di banyak sistem, belum tentu semua departemen paham privacy. Contoh kasus: token SATUSEHAT disimpan plaintext di server, ketahuan bocor lewat public repo GitHub. Fatal.

Wajib:

  • Token dan credential simpan di environment variable, bukan hardcode/script/source code.
  • Audit log aktif, akses ke log hanya admin.
  • Jangan asal expose API ke internet tanpa rate limit dan IP whitelist.
# .env
SATUSEHAT_CLIENT_ID=xxx
SATUSEHAT_CLIENT_SECRET=yyy

Di kode:

const clientId = process.env.SATUSEHAT_CLIENT_ID;
const clientSecret = process.env.SATUSEHAT_CLIENT_SECRET;

Jangan pernah commit file .env ke repo public.

4. Monitoring: Jangan Nunggu Komplain User

Kalau sistem “ngadat”, user komplain, baru IT cek. Ini pola lama. Sekarang data jalan 24 jam, traffic naik, harus proaktif monitor. Minimal:

  • Setup dashboard uptime (Grafana, Zabbix, Netdata, dsb)
  • Alert kalau API down/response error >3x berturut-turut
  • Log request/response SATUSEHAT (tanpa data sensitif) untuk troubleshooting
SELECT
  timestamp,
  status_code,
  response_time_ms
FROM
  satusehat_api_log
WHERE
  status_code != 200
  AND timestamp > NOW() - INTERVAL '1 day';

Data ini penting buat laporan ke manajemen dan audit.

Ke Depan: SIPA, Open Data, dan AI Medis

Sudah pada dengar SIPA? Sistem Informasi Pelayanan Administrasi, rencana Kemenkes berikutnya. Tujuan: semua pelayanan RS, puskesmas, lab, satu pintu integrasi. “Kepala naga” integrasi makin banyak: SATUSEHAT, SIPA, BPJS, Wajib Lapor Narkotika, dsb.

IT RS perlu siap:

  • Open API — siap “disuruh” integrasi ke aplikasi pihak ketiga (asuransi, riset, startup)
  • Adopsi cloud/hybrid — Kemenkes dorong digitalisasi pakai cloud native
  • Data analytics & AI — kedepan, data pasien bisa dipakai analisa tren penyakit, prediksi kebutuhan obat, deteksi fraud klaim, dsb

Contoh: Query Early Warning System

Analisa data pasien demam tinggi & saturasi rendah, AI kasih warning:

SELECT
  p.identifier,
  e.temperature,
  e.spo2
FROM
  patient p
JOIN
  encounter e ON p.id = e.patient_id
WHERE
  e.temperature > 38.5
  AND e.spo2 < 92
  AND e.encounter_date >= CURRENT_DATE - INTERVAL '7 days';

Output feed ini bisa dikirim ke dashboard IGD, atau trigger alert WhatsApp ke dokter jaga. Otomasi kayak gini yang akan jadi “mainan wajib” IT RS masa depan.

Bukan Cuma soal Teknologi: SDM dan Mindset

Teknologi bisa dibeli, skill susah dicari. Tantangan utama IT RS bukan alat, tapi SDM paham proses klinis dan IT sekaligus. SIMRS vendor sering asal jual, tanpa support after sales. IT RS dituntut upgrade skill: FHIR, Python, Node.js, query analytics, compliance PDPA/UU Perlindungan Data Pribadi.

  • Pelatihan FHIR/Web API dasar ke tim IT
  • Kerjasama antar RS tukar script/solusi open source (bukan saingan, tapi saling gotong royong)
  • Awareness privacy data pasien ke semua staff — bukan cuma tim IT

Kalau SDM siap, digitalisasi jalan. Kalau engga? Ya tetap manual, terus-terusan “kebakaran” tiap ada mandatory update dari pusat.

Kesimpulan Sambil Ngopi (Tanpa Frase AI!)

  • SATUSEHAT baru permulaan, bukan finish digitalisasi RS di Indonesia
  • Ke depan: API makin rumit, integrasi makin banyak, data makin sensitif
  • Tim IT kudu upgrade skill, automate proses, bangun kebiasaan monitoring
  • SDM, komunikasi, dan kolaborasi antar RS lebih penting dari sekadar alat atau vendor
  • Siap ga siap, digitalisasi jalan terus. Kalo ga ikut, siap-siap “ditinggal kereta”

Intinya: SATUSEHAT selesai, PR malah tambah panjang. Tapi, buat Sobat IT RS yang suka tantangan, ini saat tepat “naik kelas”. Bukan cuma tukang jaga server, tapi jadi arsitek ekosistem data kesehatan nasional. Siap gas? Pokok e ngene, ayo belajar bareng, saling support, dan jangan males baca changelog!