Otomatisasi MCU sebaiknya diadopsi sebagai rangkaian perubahan alur kerja yang terkelola, bukan sebagai satu tombol yang langsung menghasilkan laporan klinis akhir. Institusi perlu menetapkan tujuan, memetakan proses saat ini, menyiapkan kontrol, mengonfigurasi alur penyusunan draf yang terbatas, menjalankan pilot terkendali, lalu memutuskan perluasan berdasarkan bukti.
Dalam artikel ini, otomatisasi tidak berarti pelaporan klinis yang otonom. Otomatisasi berarti mendukung tugas persiapan tertentu, sementara dokter yang berwenang tetap bertanggung jawab untuk mengoreksi, menafsirkan, dan menyetujui hasil akhir. AI menyusun draf. Dokter yang memutuskan.
Artikel ini membahas jalur adopsi, bukan hambatan ulasan klinis
Artikel pendamping tentang mengapa laporan MCU masih memerlukan banyak ulasan klinis menjelaskan sumber beban pelaporan ketika masukan, konteks, templat, dan langkah persetujuan belum membentuk kesimpulan klinis yang utuh. Panduan ini menjawab pertanyaan yang berbeda: bagaimana institusi bergerak dari alur saat ini menuju pilot otomatisasi MCU yang terkelola?
Pemisahan tersebut mencegah panduan adopsi berubah menjadi janji tanpa bukti tentang waktu, kapasitas, kualitas, atau hasil. Tujuan tahapan berikut adalah membuat proses pengambilan keputusan dapat diulas sebelum teknologi diperluas.
Tahap 0: Tetapkan keputusan dan batas penggunaan
Mulailah dengan menetapkan proses pengambilan keputusan operasional yang ingin diperbaiki oleh institusi. Tetapkan siapa yang akan menggunakan alur tersebut, dokumen atau tugas apa yang termasuk dalam cakupan, siapa yang membuat keputusan klinis akhir, dan kegiatan apa yang tetap berada di luar pilot.
Batas keluarannya juga perlu dinyatakan dengan jelas. Laporan klinis individu ditujukan bagi peserta dan tim klinis yang berwenang. Keluaran untuk perusahaan perlu diatur secara terpisah dan tidak boleh otomatis membuka diagnosis, hasil mentah, riwayat obat, atau narasi klinis lengkap. Artikel tentang apa yang seharusnya diterima perusahaan dari hasil MCU karyawan menjelaskan batas tersebut secara lebih rinci.
Sebelum melanjutkan, catat tujuan penggunaan, penggunaan yang dikecualikan, penanggung jawab, pemberi persetujuan akhir, serta bukti yang diperlukan untuk memutuskan apakah alur perlu dilanjutkan, ditunda, atau dirancang ulang.
Tahap 1: Petakan alur saat ini dan bukti pembanding awal
Dokumentasikan alur sebagaimana dijalankan saat ini. Peta tersebut perlu mengidentifikasi dokumen sumber, format masukan, pengenal pasien dan kunjungan, templat laporan, peran persiapan, langkah ulasan dokter, jalur koreksi, penanganan pengecualian, serta titik ketika dokumen berubah menjadi hasil yang telah disetujui.
Jangan menganggap semua institusi memulai dari sistem atau masukan yang sama. Satu tim mungkin menggunakan ekspor terstruktur, tim lain menerima berkas terkendali, dan tim berikutnya bergantung pada antarmuka yang telah disetujui. Peta harus menggambarkan lingkungan yang nyata, bukan arsitektur HIS atau LIS yang bersifat umum.
Pengamatan dasar dapat mencakup masukan yang tidak tersedia atau terlambat, lokasi pengisian data berulang, alasan draf dikembalikan untuk dikoreksi, pengecualian yang memerlukan eskalasi, serta konteks yang harus disusun ulang oleh pengulas sebelum persetujuan. Pengamatan tersebut menjadi bukti pembanding bagi pilot tanpa menjanjikan hasil di awal.
Tahap 2: Siapkan kontrol masukan dan aturan persetujuan
Otomatisasi tidak sebaiknya dikonfigurasi di atas proses masukan yang belum jelas. Institusi perlu lebih dahulu menetapkan cara informasi sumber dikenali, dicocokkan dengan orang dan kunjungan yang benar, diberi atribusi, dikelola versinya, serta ditampilkan ketika suatu bagian hilang atau bertentangan.
Tahap ini juga perlu menetapkan:
- sumber mana yang menjadi acuan untuk setiap bagian data;
- templat dan versi laporan yang berlaku untuk pilot;
- siapa yang dapat menyiapkan, mengulas, mengoreksi, menolak, dan menyetujui draf;
- cara membedakan status draf dari status yang telah disetujui dengan jelas;
- cara koreksi, pengecualian, dan persetujuan dicatat; dan
- proses pengganti ketika masukan atau koneksi tidak tersedia.
Kontrol tersebut merupakan bagian dari desain alur, bukan pengaturan tambahan yang baru dipasang setelah pilot dimulai.
Untuk konteks rekam medis Indonesia, gunakan halaman resmi Permenkes Nomor 24 Tahun 2022. Panduan WHO tentang etika dan tata kelola AI untuk kesehatan menjadi rujukan yang lebih luas mengenai tanggung jawab dan akuntabilitas manusia. Kedua sumber tersebut tidak menetapkan satu arsitektur otomatisasi MCU yang berlaku universal, sehingga setiap institusi tetap perlu memvalidasi alur dan kontrolnya sendiri.
Micromeet, AI untuk tata kelola layanan kesehatan. AI menyusun draf. Dokter yang memutuskan.
Tahap 3: Konfigurasikan penyusunan draf terbatas dan koneksi yang spesifik untuk institusi
MCU CoPilot dirancang untuk menyiapkan draf laporan MCU terstruktur dari data yang telah didokumentasikan agar diulas oleh dokter yang berwenang. Dokter memeriksa konteks sumber, mengoreksi draf bila diperlukan, menafsirkan temuan, dan menyetujui kesimpulan klinis akhir. MCU CoPilot tidak boleh digambarkan sebagai pihak yang membuat diagnosis atau keputusan kelayakan akhir, menyetujui laporan, atau secara otomatis mengirimkannya kepada pihak lain.
Metode untuk menyediakan masukan atau mengembalikan keluaran yang telah disetujui bersifat spesifik untuk setiap institusi. Metode tersebut dapat berupa proses berbasis berkas yang terkendali atau antarmuka yang disetujui untuk institusi tersebut. Kelayakannya bergantung pada sistem sumber, dukungan vendor, pengenal, pemetaan, izin, ulasan keamanan, persyaratan audit, dan kebijakan writeback. Tidak ada koneksi universal ke HIS, LIS, SIMRS, atau RME yang dapat diasumsikan, dan HIS atau RME institusi tetap menjadi sistem pencatatan utama.
Karena itu, konfigurasi perlu mengikuti peta alur dan keputusan koneksi yang telah disetujui, bukan dimulai dengan klaim bahwa semua sistem yang ada dapat dihubungkan dengan cara yang sama.
Tahap 4: Jalankan pilot terbatas
Pilot perlu memiliki kelompok pengguna, jenis laporan, jalur masukan, versi templat, peran pengulas, kriteria penerimaan, jalur eskalasi masalah, serta kondisi yang mengharuskan pilot dihentikan atau dikembalikan ke kondisi sebelumnya. Data harus tetap berada dalam lingkungan dan proses akses yang telah disetujui institusi.
Bandingkan pilot dengan bukti pembanding awal dalam kondisi yang dinyatakan. Bukti yang berguna dapat mencakup:
- apakah masukan yang diperlukan tetap lengkap dan dapat ditelusuri;
- bagian draf yang dikoreksi dokter beserta alasannya;
- masukan yang hilang atau bertentangan yang ditemukan sebelum persetujuan;
- cara kasus bergerak melalui ulasan dan eskalasi;
- upaya pengulas yang dibutuhkan dalam alur pilot; dan
- apakah kontrol akses, persetujuan, dan batas keluaran berjalan sesuai desain.
Hasilnya merupakan bukti untuk pilot, pengguna, dan kondisi tersebut. Hasil itu tidak boleh digeneralisasi menjadi klaim universal tentang penghematan waktu, kapasitas, kualitas, atau hasil klinis.
Tahap 5: Perluas, pertahankan, atau rancang ulang berdasarkan bukti
Perluasan merupakan keputusan tata kelola, bukan langkah otomatis setelah pilot berfungsi secara teknis. Lanjutkan hanya jika kriteria penerimaan yang telah ditetapkan terpenuhi, setiap masalah penting memiliki penanggung jawab, staf siap menjalankan alur yang disetujui, dan institusi dapat mempertahankan kontrol ulasan serta audit.
Validasi ulang diperlukan ketika paket pemeriksaan, templat laporan, fasilitas, sistem sumber, metode koneksi, kelompok pengulas, atau keluaran untuk perusahaan berubah. Alur yang dapat diterima dalam satu kondisi terbatas tidak boleh dianggap telah terbukti untuk semua kondisi.
Jika bukti belum mendukung perluasan, keputusan yang tepat dapat berupa mempertahankan cakupan terbatas, mengubah alur, memperkuat kontrol, atau menghentikan pilot. Semua itu merupakan hasil yang sah dari proses adopsi yang terkelola.
Apa yang perlu dihasilkan oleh asesmen alur kerja MCU
Asesmen yang bermanfaat perlu menghasilkan peta alur saat ini, batas penggunaan yang disetujui, inventaris sumber dan keluaran, peran ulasan dan persetujuan, keputusan koneksi yang spesifik untuk institusi, pengamatan awal, protokol pilot terbatas, serta kriteria untuk memperluas, mempertahankan cakupan, atau merancang ulang.
Untuk memahami kerangka kontrol yang lebih luas, baca arti AI kesehatan yang terkelola. Jika institusi Anda sedang mengevaluasi otomatisasi MCU, gunakan permintaan asesmen alur kerja pada artikel ini. Hasil pertama adalah rencana adopsi yang dapat diulas, bukan janji tentang kecepatan, kualitas, atau hasil.
Pertanyaan yang Sering Diajukan
Apa saja tahapan adopsi otomatisasi MCU?
Enam tahap yang disarankan adalah menetapkan keputusan dan batas penggunaan; memetakan alur saat ini dan bukti pembanding awal; menyiapkan kontrol masukan dan aturan persetujuan; mengonfigurasi penyusunan draf dengan supervisi dokter serta koneksi yang spesifik untuk institusi; menjalankan pilot terbatas; lalu memperluas, mempertahankan cakupan, atau merancang ulang berdasarkan bukti.
Dari mana institusi sebaiknya memulai otomatisasi MCU?
Mulailah dari alur saat ini, bukan konfigurasi produk. Identifikasi tujuan penggunaan, dokumen sumber, format masukan, templat laporan, peran persiapan, titik ulasan dan persetujuan dokter, batas keluaran, pengecualian, serta bukti pembanding awal sebelum menetapkan pilot.
Apa yang diotomatisasi oleh MCU CoPilot?
MCU CoPilot dirancang untuk menyiapkan draf laporan MCU terstruktur dari data yang telah didokumentasikan agar diulas oleh dokter yang berwenang. Dokter mengoreksi, menafsirkan, dan menyetujui kesimpulan klinis akhir; MCU CoPilot tidak membuat atau menyetujui keputusan akhir tersebut.
Apakah otomatisasi MCU memerlukan integrasi HIS atau LIS yang universal?
Tidak. Metode koneksi bersifat spesifik untuk institusi dan dapat menggunakan proses berbasis berkas yang terkendali atau antarmuka yang disetujui. Kelayakannya bergantung pada sistem sumber, dukungan vendor, pengenal, pemetaan, izin, ulasan keamanan, persyaratan audit, dan kebijakan writeback.
Kapan pilot otomatisasi MCU sebaiknya diperluas?
Perluas hanya jika kriteria penerimaan yang telah ditetapkan terpenuhi, masalah penting memiliki penanggung jawab, staf dapat menjalankan alur yang disetujui, serta kontrol ulasan, akses, batas keluaran, dan audit berjalan sesuai desain. Jika tidak, pertahankan cakupan, rancang ulang alur, atau hentikan pilot.
