5 Pelajaran dari Integrasi EHR Lintas Batas
Saya menghabiskan waktu berbulan-bulan menghubungkan catatan pasien di dua negara yang berbeda. Saya bekerja dengan seorang Lead Business Analyst dengan sepuluh tahun pengalaman klinis. Pendekatannya mengubah cara saya memandang perangkat lunak layanan kesehatan.
Berikut adalah lima pelajaran dari proyek tersebut.
- Pemetaan terminologi lebih sulit daripada pemetaan data
Insinyur sering menganggap integrasi sebagai masalah skema. Anda memetakan bidang A ke bidang B dan selesai. Dalam layanan kesehatan, hal ini gagal.
Satu sistem menggunakan ICD-10 dan yang lainnya menggunakan ICD-11. Keduanya tidak dapat dipetakan secara bersih. Satu sistem menggunakan LOINC untuk hasil lab sementara yang lain menggunakan kode internal lama.
BA kami membuat pemetaan silang konsep (concept crosswalk) sebelum kami menulis kode. Ia memetakan kode lokal ke set standar seperti SNOMED CT. Tanpa ini, kami akan merusak makna klinisnya.
Pemetaan bidang yang rusak menghasilkan nilai yang salah. Pemetaan terminologi yang rusak menghasilkan nilai yang tampak masuk akal tetapi salah secara klinis. Yang terakhir jauh lebih berbahaya.
- Hukum data membentuk arsitektur sejak dini
Saya pikir kami akan merancang model data terlebih dahulu dan menangani kepatuhan nanti. Saya salah.
Data pasien yang melintasi batas negara bersinggungan dengan berbagai hukum seperti HIPAA atau GDPR. Beberapa negara melarang data kesehatan keluar dari perbatasan mereka.
BA kami bekerja dengan tim hukum sejak dini. Ia memutuskan bidang mana yang dapat direplikasi dan mana yang memerlukan de-identifikasi.
Hal ini mengubah arsitektur kami. Kami membangun lapisan kueri terfederasi (federated query layer) alih-alih satu basis data replikasi tunggal. Kami menambahkan tag klasifikasi data langsung ke dalam skema kami.
Libatkan ahli kepatuhan dan seorang BA sebelum Anda merancang model data Anda.
- Standar saja tidak cukup
Kedua sistem mendukung HL7. Namun, satu menggunakan HL7 v2 dan yang lainnya menggunakan FHIR R4. Mereka tidak dapat berkomunikasi tanpa lapisan penerjemah.
Bahkan di dalam FHIR, kami menemui ketidakcocokan profil. Kedua sistem mengklaim kepatuhan tetapi menggunakan panduan implementasi yang berbeda.
Jangan berasumsi integrasi itu mudah hanya karena sebuah sistem mendukung suatu standar. Selalu tanyakan tentang versi dan profil spesifiknya. Alokasikan waktu untuk lapisan adaptor (adapter layer).
- Diagram alur kerja menangkap kasus ekstrem (edge cases) yang tersembunyi
Dulu saya menganggap diagram alur kerja sebagai dokumentasi tambahan. Saya salah.
BA kami memetakan transfer pasien secara mendetail. Ia melihat apa yang terjadi ketika pasien pindah di tengah perawatan atau ketika hasil lab tiba setelah pasien pulang (discharge).
Ini bukanlah kasus ekstrem (edge cases) di rumah sakit. Hal ini terjadi setiap hari.
Diagram-diagram ini mengubah model data kami. Kami menambahkan konsep episode perawatan (care episode) untuk melacak perawatan berkelanjutan di kedua sistem.
- Bangun glosarium bersama sejak dini
Kata-kata seperti encounter atau discharge memiliki arti yang berbeda di sistem yang berbeda. Kami membuang-buang waktu karena tim menafsirkan istilah secara berbeda.
BA kami membangun glosarium bersama. Setiap pemangku kepentingan meninjau dan menyetujui definisi-definisi ini. Kami merujuk dokumen ini dalam setiap persyaratan.
Asumsikan setiap istilah domain bersifat ambigu. Definisikan dalam dokumen yang ditandatangani oleh kedua belah pihak.
Ringkasan
Seorang BA yang kuat melakukan lebih dari sekadar menulis tiket. Mereka bertindak sebagai arsitek untuk batasan regulasi dan makna klinis. Jika Anda membangun perangkat lunak yang kompleks, jangan menganggap peran ini sebagai beban tambahan (overhead). Peran ini mencegah keberhasilan teknis menjadi kegagalan klinis.
Optional learning community: https://t.me/GyaanSetuAi