Tahapan Adopsi Otomatisasi MCU: Menuju Pilot yang Terkelola

Salah satu cara praktis untuk mendekati otomatisasi MCU adalah sebagai rangkaian perubahan alur kerja yang terkelola, bukan sebagai satu tombol yang langsung menghasilkan laporan klinis akhir. Institusi dapat memulai dengan menetapkan tujuan penggunaan, memetakan proses saat ini, menyiapkan kontrol yang diperlukan, mengonfigurasi alur penyusunan draf yang terbatas, dan mengujinya dalam pilot terkendali sebelum 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. Penilaian klinis tetap menjadi kewenangan dokter; AI tidak mendiagnosis dan tidak menandatangani.

Bergerak dari alur pelaporan yang jelas menuju pilot terkelola

Artikel pendamping tentang penyusunan temuan MCU untuk ulasan klinis menjelaskan cara menyiapkan masukan, konteks, templat, dan langkah persetujuan yang tersebar agar siap diulas dokter. Panduan ini menjawab pertanyaan berikutnya: 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 menyebutkan keputusan operasional yang ingin diperbaiki 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. Perspektif kami tentang kebutuhan berbagai pihak atas hasil MCU karyawan membahas perbedaan tersebut secara lebih rinci.

Tim dapat mencatat tujuan penggunaan, penggunaan yang dikecualikan, penanggung jawab, pemberi persetujuan akhir, serta bukti yang dapat mendukung keputusan untuk melanjutkan, menunda, atau merancang 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

Mengonfigurasi otomatisasi sebelum proses masukan ditetapkan dapat membuat pilot lebih sulit dievaluasi. Institusi dapat terlebih 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.

Pertanyaan untuk tahap ini meliputi:

• 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.

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 dipresentasikan seolah-olah 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 EMR yang dapat diasumsikan, dan HIS atau EMR 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 terbatas dapat menetapkan kelompok pengguna, jenis laporan, jalur masukan, versi templat, peran pengulas, kriteria penerimaan, jalur eskalasi masalah, serta kondisi penghentian atau rollback. 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. Perluasan dapat dipertimbangkan ketika 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.

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?
Salah satu urutan praktis yang terdiri dari enam tahap 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.