Bagaimana kami mencari tanda-tanda kesalahan medis



Pada tahun 2006, sebuah aneurisma meledak di kepala ayah mertua saya dan stroke menyerang dia. Menjelang sore hari ia bercanda dan berusaha berjalan-jalan di bangsal rumah sakit. Stroke kedua, yang terjadi di bawah pengawasan dokter, otaknya tidak tahan - ayah mertuanya berhenti berbicara, berjalan dan mengenali kerabat. Di rumah sakit lain, ia berdiri, tetapi karena kesalahan medis selama perawatan awal, ia selamanya tidak bisa berkata-kata, dan kepribadiannya berubah tak dapat dikenali.

Apa yang terjadi padanya disebut stroke nosokomial dan ini adalah salah satu penanda (atau pemicu) masalah sistemik dalam organisasi medis. Mereka perlu dianalisis untuk mengurangi jumlah kesalahan medis yang dapat dicegah di rumah sakit dan meningkatkan kualitas perawatan pasien.

Di AS, mereka bingung dengan masalah ini pada awal 2000-an. Institut Massachusetts untuk Peningkatan Kesehatan (IHI) mengembangkan Alat Pemicu Global IHI untuk Mengukur Kejadian Buruk , yang kemudian diimplementasikan oleh klinik AS dan Eropa terkemuka.

Pada tahun 2016, kami (kantor SAS di Rusia) mencoba membuat sistem untuk menganalisis pemicu medis menggunakan metodologi IHI di Rusia. Saya akan memberi tahu Anda apa yang terjadi.

Di mana Anda mulai?


Pertama-tama, kami mulai mencari dokter yang berpikiran sama yang memiliki gagasan untuk menganalisis kualitas perawatan medis. Kami mengundang kepala beberapa rumah sakit Moskow, kolega dari kantor kami di Eropa dan perwakilan dari rumah sakit Denmark Lillebaelt ke SAS Forum Russia 2016 , yang menciptakan sistem deteksi pemicu IHI berdasarkan platform analitik SAS pada 2015.

Kisah Denmark menarik kepala dokter dari sebuah rumah sakit multidisiplin Moskow yang besar, dan kami sepakat untuk melakukan percobaan untuk menganalisis catatan medis. Berdasarkan ketentuan NDA, kami tidak dapat mengungkapkan rincian proyek, jadi saya akan terus memanggil rumah sakit hanya Klinik, dan kepala - Kepala Dokter.

Pada bulan Juni - Juli 2016, kami mendiskusikan isi dan ruang lingkup proyek dengan manajemen klinik, pada bulan Agustus kami menyusun kerangka acuan dan mulai bekerja pada bulan September. Tulang punggung tim dari SAS terdiri dari Alexander Zhukov ( al_undefined ) dan Dmitry Kayatenko.

Teknik IHI mengandung 51 pemicu. Bersama dengan manajemen klinik, kami memilih yang berikut untuk proyek:

  • Leukosit darah <3.000 x 10 ^ 6 / μl (kecuali untuk pasien yang menjalani kemoterapi)
  • Trombosit darah <50.000 × 10 ^ 6 / μl (kecuali untuk pasien kemoterapi)
  • Stroke nosokomial
  • Infark nosokomial
  • Transfer berulang yang tidak direncanakan ke unit perawatan intensif (ICU) dalam waktu 24 jam
  • Resusitasi dalam 24 jam setelah operasi
  • Tindakan resusitasi di departemen tempat tidur

Seperti yang sering terjadi dalam analitik, bagian terbesar dari waktu diambil oleh persiapan data awal dan alokasi informasi penting di dalamnya.

Bagaimana catatan diambil


Data sistem informasi medis (MIS) dari Klinik ditempatkan di database Oracle dengan struktur yang rumit. Deskripsi skema tidak dapat ditemukan, jadi saya harus memulihkan struktur data dan hubungan entitas dengan membandingkan informasi database dengan informasi dari antarmuka grafis MIS.

Untuk proyek ini, kami membutuhkan jenis rekam medis berikut:

  • Data pemeriksaan dokter
  • Tabel diagnosis
  • Entri buku harian
  • Protokol transaksi dan konsep pra operasi
  • Janji temu dan informasi kinerja
  • Tahap dan keluarnya epikrisis
  • Epicrisis yang Diterjemahkan
  • Epicrisis Anumerta

Data ini (kecuali untuk tabel diagnosis) terletak di XML dalam CLOBs. Tidak ada deskripsi struktur XML di Klinik, sehingga isinya harus dibuat secara empiris selama diskusi panjang.

Ada kekacauan di dalam dokumen XML. Misalnya, simpul "Kondisi Umum" dapat berisi informasi tentang keluhan pasien, dan simpul "Keluhan" itu sendiri tetap kosong. Seringkali, dokter menuliskan semua data tentang pasien (keluhan, hasil pemeriksaan, rekomendasi untuk perawatan lebih lanjut dan resep obat, dll.) Dalam satu bidang, misalnya, dalam Komentar.

Pengembangan XML ke dalam tabel datar dilakukan oleh SAS XML Mapper standar. Dokumen yang paling kompleks, dengan informasi yang diperlukan di berbagai tingkat sarang, diuraikan menggunakan pengurai Python. Diluncurkan dari SAS dan diintegrasikan ke dalam satu proses yang dapat dieksekusi dari SAS Enterprise Guide:



Agar tidak menarik hasil tes laboratorium dari teks epikrisis (masih menyenangkan, mengingat kebiasaan beberapa dokter untuk menyiapkan dokumen), kami mengambil data pada mereka dari sistem informasi laboratorium (LIS). Mereka juga dibungkus dalam XML, tetapi dari bentuk sederhana - "analisis", "indikator", "nilai".

Bagaimana data diteliti


Ketika kami membawa catatan medis dalam bentuk yang dapat dimengerti dan cocok untuk diproses, ternyata hanya 2 dari 7 pemicu yang diformalkan - konten “sel darah putih” dan “trombosit”. Mereka diekspresikan dalam angka yang dapat dibandingkan dengan nilai ambang.

Kami harus meninggalkan analisis pemicu seperti "Transfer berulang yang tidak direncanakan ke ICU dalam waktu 24 jam". Penanda ini bergantung pada prangko waktu, dan mereka dimasukkan ke dalam IIA Klinik karena Tuhan menginginkannya menjadi sempurna - mereka dapat melewatkan beberapa hari atau bahkan menetapkan tanggal dari masa depan.

Stroke nosokomial, serangan jantung dan tindakan resusitasi tidak dikodekan dengan cara apa pun dan tidak dicatat dalam tabel sehubungan dengan ID pasien. Mereka seharusnya dicari dalam entri epikrisis dan buku harian. Oleh karena itu, 4 pemicu yang tersisa bersifat informal, yaitu, mereka menuntut analisis teks yang tidak terstruktur.

Untuk melakukan ini, kami menggunakan alat pemrosesan bahasa alami - SAS Contextual Analysis . Ini adalah solusi berbasis web dengan antarmuka visual yang memungkinkan Anda membuat model pemrosesan teks bahkan tanpa ketrampilan pemrograman dan pengetahuan dalam linguistik (namun, Anda masih tidak bisa melakukannya tanpa pengetahuan tentang area subjek dan bahasa tempat teks ditulis).

Sekarang telah menjadi mode untuk menyelesaikan masalah seperti itu dengan bantuan jaringan saraf. Tetapi kami secara sadar meninggalkannya dan menerapkan mekanisme aturan linguistik, karena:

  • Hasil yang baik dalam jaringan saraf hanya dimungkinkan pada sampel puluhan ribu catatan dokter yang berkualitas tinggi, tetapi kami tidak mendapatkannya dari kata sama sekali.
  • jaringan saraf tidak memberikan penjelasan yang jelas tentang keputusannya (tidak dapat diartikan), dan dokter tidak dapat bekerja dengan kotak hitam - mereka harus memahami dengan tepat gejala, indikator atau tindakan mana yang menunjukkan kejadian buruk

Cara melatih sistem


Meskipun kami berurusan dengan semua pemicu dari daftar, upaya utama difokuskan pada deteksi stroke nosokomial dan serangan jantung (kami akan menyebut infeksi nosokomial untuk singkatnya). Ini adalah beberapa pemicu paling berbahaya yang, selain membahayakan kesehatan pasien, sangat mengerikan karena tidak diiklankan oleh staf medis. Dan jika manajemen tidak tahu tentang masalahnya, dia tidak bisa mengatasinya.

Semuanya tidak mudah dengan NSI. Tidak ada standar atau peraturan yang wajib mendokumentasikan fakta stroke atau serangan jantung dalam bentuk yang seragam: beberapa dokter menggambarkan stroke sebagai "pelanggaran akut sirkulasi otak", yang lain sebagai (oh, ya!) "Stroke", dan yang lain sebagai "ONMK" ". Kadang-kadang, infeksi nosokomial hanya terlihat dengan pengobatan yang ditentukan.

Pada dasarnya, kita dapat:

  1. Wawancarai semua dokter tentang bagaimana mereka menggambarkan stroke dan serangan jantung. Namun, ada risiko kehilangan sesuatu - tidak ada yang mengingat daftar catatan yang pernah dibuat dan direktori singkatan. Dan ada beberapa orang yang ingin berbicara tentang hal ini.
  2. Bersama dengan para dokter, menjalani semua epikrisis dan menganalisis apakah mereka memiliki tanda-tanda infeksi nosokomial atau tidak. Tapi kami maupun mereka tidak punya banyak waktu.

Kami bertindak berbeda: kami mengunggah koleksi teks dalam Analisis Kontekstual dan membangun model tematik yang menyoroti ide-ide kunci untuk setiap entri. Tanpa merangkak ke dalam teks dokumen (misalnya, epikrisis), adalah mungkin untuk memilih hanya catatan dengan tema "stroke" atau "NMC" dan secara terpisah memeriksanya untuk bagaimana VBI dijelaskan dalam teks: kata-kata apa yang digunakan, seberapa jauh jaraknya ditemukan, dll. Plus, model itu sendiri menyarankan kemungkinan formulasi untuk menggambarkan ide-ide kunci.

Setelah markup dokumen secara tematik, kami berbicara dengan dokter, mengklarifikasi dan mengembangkan aturan linguistik untuk mengidentifikasi peristiwa yang mengindikasikan pemicu. Aturan-aturan memperhitungkan bentuk tata bahasa kata-kata, jarak di antara mereka, urutan urutannya, posisi (dalam satu kalimat, paragraf, awal / akhir teks), dll.

Jadi kami mencari langkah-langkah resusitasi:



Dan - stroke:



Saat menganalisis teks, Anda selalu perlu mengevaluasi jarak antara kata kunci dan urutannya, agar tidak menangkap terlalu banyak. Berikut adalah contoh ketika semua kata yang diperlukan ("akut", "pelanggaran", "otak", "sirkulasi darah") ada dalam frasa, tetapi stroke nosokomial tidak:



Sangat penting untuk memisahkan deskripsi fakta stroke nosokomial dari deskripsi konsekuensi stroke sebelumnya, di mana kata kunci yang sama digunakan:



Aturan yang dikecualikan "Konsekuensi stroke" (di atas dalam Remove_item):



Bersama dengan para dokter, kami mengembangkan sekitar 30 aturan linguistik yang menentukan apakah ada tanda-tanda pemicu dalam epikrisis. Mereka diunduh dari Analisis Kontekstual dalam bentuk kode penilaian, yang terhubung ke proses yang dapat dieksekusi untuk mengevaluasi catatan dalam SAS Enterprise Guide.

Namun, untuk stroke nosokomial dan serangan jantung, proses pengambilan keputusan tentang adanya pemicu tidak berakhir di sana. Kami harus menghapus dari daftar kandidat untuk pemicu kasus-kasus yang bisa diprediksi setelah masuk pasien. Untuk melakukan ini, kami membandingkan hasil mengerjakan aturan dengan daftar diagnosis.

Biarkan saya mengingatkan Anda bahwa pemicu adalah suatu peristiwa (memperburuk kondisi pasien), tidak terduga dalam hal diagnosis saat masuk. Ini adalah sinyal kesalahan medis atau masalah rumah sakit yang memerlukan langkah-langkah sistematis untuk mengecualikan komplikasi di masa depan, dan bukan sembarang penurunan dalam kesehatan pasien.

Katakanlah Analisis Kontekstual telah menetapkan label "infark nosokomial" pada beberapa catatan. Kami memeriksa diagnosis: jika pasien dirawat dengan penyakit jantung koroner, maka risiko infark miokard sudah tinggi. Acara ini, meskipun tidak menguntungkan, tetapi, sayangnya, diharapkan. Atribut rekam pemicu tidak ditetapkan.

Jika pasien dirawat dengan usus buntu dan mengalami stroke selama perawatan, maka ini bisa menjadi kesalahan medis. Misalnya, mereka tidak mengikuti tekanan atau memprovokasi lompatan dengan beberapa obat atau tindakan. Catatan menetapkan atribut "pemicu".

Hasilnya adalah proses bisnis:



Sangat nyaman bagi dokter - mereka dapat secara mandiri melengkapi aturan linguistik untuk analisis epikrisis, yang kemudian diunggah ke kode penilaian dan diambil oleh sistem analitik.

Bagaimana data divisualisasikan


Pada tahap terakhir, kami menyiapkan laporan dalam SAS Visual Analytics - ini adalah produk berbasis web kami untuk visualisasi dan tugas BI. Itu diperbarui setiap 5 menit dan menunjukkan statistik terjadinya pemicu dalam konteks departemen, dokter dan pasien. Dokter yang bertanggung jawab (misalnya, kepala departemen kardiologi) masuk ke dalam laporan dan melihat pemicu yang terdeteksi pada jam, hari, minggu terakhir. Bisa "gagal" di departemen, lihat dinamika pemicu untuk periode tersebut, dll .:



Agar tidak memuat artikel dengan tangkapan layar (terlebih-lebih “ternoda”), kami mencatat demonstrasi kecil pada data yang dipersonalisasi:


Kami juga ingin mengatur pemberitahuan pemicu secara otomatis - ini adalah nada yang bagus untuk sistem analitik yang memantau indikator kritis. Selain itu, fungsionalitas milis dibangun ke dalam SAS Visual Analytics. Tetapi Klinik tidak ingin memberikan akses ke server surat, sama seperti dia menolak untuk mengatur pengiriman surat melalui pemasangan dengan layanan eksternal.

Bagaimana semuanya berakhir


Manajemen rumah sakit melakukan percobaan yang membandingkan hasil deteksi manual dari pemicu efek samping oleh tim ahli medis dan analisis otomatis yang dilakukan oleh sistem SAS. Hasilnya tidak menguntungkan orang: sistem SAS mendeteksi lebih dari papan medis. Untuk beberapa pemicu - beberapa kali lebih banyak:



Tetapi peningkatan akurasi bukanlah hal utama yang diberikan oleh sistem deteksi pemicu. Yang paling penting, dia mengizinkan:

  1. Pastikan pemantauan terus menerus dari semua catatan medis. Bukan kebetulan dipilih atau kasus yang paling mengerikan, tetapi oleh dan oleh. Tidak hanya sekali seperempat, tetapi dalam mode mendekati waktu nyata.
  2. Luangkan waktu bagi personel yang berkualifikasi tinggi untuk terlibat dalam kegiatan inti. Hanya dalam kerangka percobaan, staf medis dapat dibuat bingung oleh audit manual skala penuh. Dalam mode normal, tidak ada waktu untuk melakukan ini - jika dokter sibuk dengan catatan, tidak akan ada yang merawat orang.

Penting untuk keberhasilan proyek ini adalah dukungan penuh dari administrasi - Kepala Dokter, wakilnya dan kepala departemen. Kepala Klinik dididik di AS, sehingga gagasan manajemen berdasarkan manajemen kualitas dan analisis data otomatis ternyata dekat dan jelas baginya

Sayangnya, tak lama sebelum penerapan sistem analitik skala penuh, Kepala Dokter mengundurkan diri. Penggantinya terus terang konservatif dan tidak suka membuat linen kotor di depan umum. Klinik menulis hasil proyek yang menjanjikan "ke meja" dan kembali ke metode kerja yang diuji dengan praktik selama bertahun-tahun.

Meskipun tidak menyenangkan untuk membuat produk yang tidak diklaim, pengalaman percobaan di Klinik itu sangat berguna bagi kami dalam proyek berikutnya pada audit catatan medis dalam sistem asuransi kesehatan wajib. Tetapi lebih banyak tentang itu lain kali.

Source: https://habr.com/ru/post/id426275/


All Articles