Sentra Healthcare — Edge Cases & Incident Handling¶
Operasional klinik medis dipenuhi oleh situasi tak terduga yang menuntut penanganan kesalahan secara otomatis dan tangguh. Berikut adalah skenario edge case utama beserta solusi sistemnya.
Emergency Bypass — Pasien Gawat Darurat¶
Isu: Pasien serangan jantung datang tiba-tiba. Waktu sangat krusial, pendaftaran administratif biasa memakan waktu terlalu lama.
Solusi Sistem:
- Kasir/Suster dapat memicu tombol "Emergency Bypass" di antrean.
- Sistem segera menghasilkan nomor rekam medis darurat otomatis (RM-EMERGENCY-TEMP-#####).
- Menerbitkan tiket prioritas tertinggi (Triage Red) dan membuka EMR SOAP IGD secara instan tanpa mengharuskan input NIK/KTP pasien di awal.
- Profil dapat dilengkapi setelah pasien stabil di ruang rawat.
- Setelah NIK diinput, sistem menggabungkan RM-EMERGENCY-TEMP-##### dengan profil pasien sebenarnya dan mencatat riwayat merger ke audit_logs.
Kontrol Akses: Emergency Bypass dapat digunakan oleh role: Nurse, Doctor, Clinic Manager, Cashier.
Duplikasi Identitas Pasien (Double NIK / RM)¶
Isu: Pasien mendaftar dua kali di waktu berbeda karena lupa pernah berkunjung 5 tahun lalu, sehingga memiliki dua nomor rekam medis yang memisahkan riwayat kesehatannya.
Solusi Sistem:
- Sistem menggunakan detektor kemiripan fonetik (Levenshtein Distance pada nama + tanggal lahir) dan pencocokan NIK mutlak.
- Jika sistem menemukan kemiripan > 90% di database, sistem menampilkan notifikasi peringatan "Potensi Pasien Duplikat" kepada Frontdesk sebelum registrasi selesai.
- Jika terlanjur terbit, Admin Klinik berwenang memicu modul "Merge Medical Record" yang:
1. Menggabungkan seluruh catatan sejarah SOAP dan riwayat vital sign dari RM duplikat ke RM utama secara logis.
2. Menandai RM duplikat sebagai MERGED (soft delete — data tidak dihapus fisik).
3. Mencatat riwayat merger ke audit_logs dengan detail merged_from_rm dan merged_to_rm.
- Setelah merge, seluruh kunjungan historis tampil di bawah satu RM utama secara kronologis.
Pencegahan: IHS ID dari SatuSehat berfungsi sebagai identitas global unik antar klinik — mencegah duplikasi antar Fasyankes berbeda.
Salah Input Resep & Peringatan Kontraindikasi Alergi¶
Isu: Dokter tidak sengaja menulis resep antibiotik Amoxicillin kepada pasien yang terdaftar memiliki alergi penisilin di sistem.
Solusi Sistem:
- Begitu dokter menambahkan obat yang bertentangan dengan profil alergi terdaftar, sistem secara instan menampilkan modal peringatan berkedip warna merah yang mengharuskan dokter memilih antara:
- (a) Batalkan resep obat: Item dihapus dari daftar resep.
- (b) Bypass manual dengan justifikasi medis darurat: Dokter wajib mengetikkan alasan klinis (misal: "Manfaat melebihi risiko klinis, dilakukan pengawasan ketat"). Bypass ini dicatat ke audit_logs dengan level HIGH_SEVERITY_ALLERGY_OVERRIDE dan ditampilkan sebagai peringatan permanen di profil pasien.
- Sistem tidak memperbolehkan resep tersimpan tanpa salah satu pilihan di atas dieksekusi.
Sinkronisasi Data Bentrok Pasca Internet Mati¶
Isu: Klinik offline selama 6 jam. Dokter A mengubah riwayat resep pasien di database lokal cabang, sementara Dokter B di cabang satelit lainnya mengubah riwayat SOAP pasien yang sama di sistem cloud (pasien dirujuk mendadak).
Solusi Sistem: - Ketika internet kembali online, daemon sync melakukan rekonsiliasi berbasis Version Vector Clock. - Karena EMR Dokter bersifat append-only, sistem menggabungkan kedua encounter tersebut sebagai catatan peristiwa terpisah dalam urutan waktu kronologis — tidak saling menimpa. - Untuk perubahan biodata pasien, sistem mengutamakan data bertanda tangan digital dokter atau timestamp terupdate. - SOAP yang sudah di-BSrE sign: Tidak bisa di-overwrite dalam kondisi apapun. Jika ada konflik pada SOAP yang sudah locked, sistem mempertahankan kedua versi dan memicu alert ke Clinic Manager untuk resolusi manual via mekanisme Addendum.
Conflict Types:
| Tipe Konflik | Resolusi |
|---|---|
| Vital sign offline vs cloud (data berbeda) | Simpan keduanya dengan timestamp masing-masing; dokter bisa review |
| Biodata pasien offline vs cloud | Versi dengan updated_at terbaru menang |
| SOAP unlocked (belum sign) | Versi dengan updated_at terbaru menang |
| SOAP locked (sudah BSrE sign) | Tidak bisa di-overwrite; alert ke Clinic Manager |
| Stok obat terpotong ganda | Validasi ulang stok fisik; admin menerima alert untuk rekonsiliasi |
BPJS API Failure Mid-Transaction¶
Isu: BPJS PCare API timeout persis saat sistem sedang memproses pengiriman data kunjungan pasien BPJS di jam sibuk.
Solusi Sistem: - Data kunjungan disimpan ke antrian retry lokal (SQLite edge atau RabbitMQ cloud). - Kasir tetap bisa memproses pembayaran (sistem mencatat bahwa tagihan BPJS sedang "pending submission"). - Background worker mencoba re-submit ke BPJS API dengan exponential backoff (5 menit, 10 menit, 20 menit — maksimum 3 retry). - Jika gagal setelah 24 jam, admin menerima notifikasi untuk submit manual via portal BPJS Kesehatan. - Invoice pasien tetap tercetak dengan notasi "BPJS Claim Pending — akan diproses dalam 1x24 jam".
SatuSehat Sync Failure¶
Isu: SatuSehat IHS API mengalami downtime total (kejadian ini pernah terjadi beberapa kali sejak platform diluncurkan pada 2023).
Solusi Sistem: - Payload FHIR masuk ke Dead Letter Queue (DLQ) setelah 5 kali retry gagal. - Admin menerima alert dashboard: "X encounter belum tersinkronisasi ke SatuSehat". - Dashboard compliance rate menampilkan persentase data yang terkirim vs pending per hari. - Saat SatuSehat online kembali, admin bisa melakukan bulk re-trigger dari dashboard untuk memproses semua DLQ sekaligus. - Data yang sudah tersimpan lokal dijamin tidak hilang — hanya status sinkronisasinya yang pending.
Pasien dengan Identitas Tidak Lengkap (Emergency Registration)¶
Isu: Pasien tidak sadarkan diri, tidak membawa KTP, tidak ada keluarga yang bisa memberikan data.
Solusi Sistem:
- RM darurat otomatis RM-EMERGENCY-TEMP-##### dibuat tanpa NIK.
- Field NIK ditandai sebagai UNKNOWN_PENDING.
- Setelah identitas terverifikasi (dari KTP saat sadar / dari keluarga / dari database DUKCAPIL via kode sidik jari), admin melakukan update profil dan SatuSehat lookup untuk mendapatkan IHS ID.
- Jika NIK sudah ada di database (pasien pernah berobat sebelumnya), sistem mendeteksi dan menawarkan merge ke profil existing.