REKAM KESEHATAN ELEKTRONIK 1

Presentasi berjudul: "REKAM KESEHATAN ELEKTRONIK 1"— Transcript presentasi:

1 REKAM KESEHATAN ELEKTRONIK 1
PENILAIAN KEBUTUHAN FUNGSIONAL PERTEMUAN 9 LILY WIDJAYA, SKM.,MM , PRODI D-III REKAM MEDIS DAN INFORMASI KESEHATAN, FAKULTAS ILMU-ILMU KESEHATAN

2 KEMAMPUAN AKHIR YANG DIHARAPKAN
Kemampuan akan memahami: Ruang lingkup dan tujuan dari kebutuhan fungsional untuk RKE. Model-model untuk memahami pengguna dan kegunaan RKE dan fungsi yang diperlukan untuk mencapai manfaat RKE dan mendukung manfaat bagi penerima. Menjelaskan pelaksanaa penilaian kebutuhan fungsional.

3 Ruang lingkup dan tujuan
Ada beberapa usaha dalammelaksanakan RKE al.: Memperoleh insentif dari pemerintah pusat (USA) Kemampuan melakukan yang orang lain lakukan. Proses untuk membangun jalur migrasi menuju RKE (pada pertemuan 6-7) Alat yang diperlukan untuk mempelajari fungsi RKE. (pada pertemuan 8) Ruang lingkup untuk kebutuhan fungsional untuk RKE: INFRASTRUKTUR INFORMASI Gambar 8.1

4 Ruang lingkup dan tujuan
Tujuan dari sistem informasi. menerima dan mendistribusikan data ke setiap sistem keuangan/administrasi, operasional, dan klinis (dalam dan luar perusahaan) dan Memproses data secara efektif untuk mencapai transformasi klinis yang dimaksud oleh RKE.

5 Payer/ supplier

6 Tabel 8.2 : Persyaratan pengguna IOM asli
Persyaratan Kategori Contoh Konten Catatan Elemen inti data yang seragam Standar dan format sistem pengkodean, Kamus data umum, Informasi tentang hasil perawatan dan status fungsional Format rekaman "Halaman Depan " daftar masalah, Kemampuan untuk "membolak-balikan catatan", Integrasi antara disiplin dan situs perawatan Sistem Kinerja Pengambilan yang cepat, Akses 24 jam, Tersedia ruang kerja yang nyaman, Input data mudah Sumber : Institute of Medicine (IOM.) 2003

7 Tabel 8.2 : Persyaratan pengguna IOM asli
Persyaratan Kategori Contoh Kecerdasan Pendukung keputusan, Pengingat klinis, "Alarm" sistem yang mampu disesuaikan Hubungan Keterkaitan dengan Sistem Informasi lainnya (radiologi, laboratorium), Pengalihan informasi di antara spesialisasi dan situs, Hubungan dengan literatur ilmiah yang relevan, Keterkaitan dengan pendaftar dan database kelembagaan lain Keterkaitan dengan catatan anggota keluarga, Transfer informasi penagihan elektronik. Sumber : Institute of Medicine (IOM.) 2003

8 Table 8.2 Persyaratan pengguna IOM asli
Persyaratan Kategori Contoh Kemampuan pelaporan "Memperoleh Dokumen " (bentuk asuransi), Output dan Pengguna interface lainnya mudah disesuaikan, Standar laporan klinis (ringkasan debit), Disesuaikan dengan laporan (pertanyaan evaluasi yang spesifik), Tren Laporan dan grafik. Akses dan kontrol Akses yang mudah untuk mendukung pasien Penjagaan terhadap pelanggaran kerahasiaan Pelatihan dan implementasi Pelatihan yang minimal diperlukan untuk penggunaan sistem, Lulus implementasi. Sumber : Institute of Medicine (IOM.) 2003

9 Apa yang membuat RKE dilaksanakan ?
Sistem yang sangat kompleks Mempunyai hubungan timbal balik dari semua aplikasi, tetapi juga terintegrasi dengan semua komponen dari infrastruktur informasi RKE. Ada manfaat dan keuntungan dari sistem untuk organisasi internal dan penggunaan lain dari luar organisasi.

10 Model untuk memahami Persyaratan Fungsional
Harus dimulai dengan : Mengidentifikasi kebutuhan informasi internal dan eksternal organisasi. Adanya Alur kerja dan alat pemetaan proses yang dijelaskan pada bab 7 merupakan sumber utama untuk memastikan input dan ouput yang dibutuhkan pada tingkat yang lebih detail. Komisi Akreditasi, 2008 : “ Memperlakukan informasi sebagai sumber daya penting untuk dikelola secara efektif dan efisien”

11 Model untuk memahami Persyaratan Fungsional
Hal itu menunjukkan bahwa pengelolaan informasi adalah sebuah aktifitas aktif, terencana dan proses identifikasi kebutuhan informasi harus dilakukan dengan baik untuk mencapai tujuan fungsi manajemen informasi : Mendukung pengambilan keputusan untuk meningkatkan kepuasan pasien, meningkatkan dokumentasi kesehatan, menjamin keselamatan pasien, dan meningkatkan kinerja dalam perawatan pasien, pengobatan, jasa, tata kelola manajemen dan proses pendukung ”

12 Komisi Akreditasi (JC 2008)
“ Standar Komisi Akreditasi dirancang untuk kompatibel dengan sistem berbasis kertas, sistem elektronik, atau sistem hybrid. “Kualitas perawatan, pengobatan, dan layanan dipengaruhi oleh banyak transisi dalam manajemen informasi yang berlangsung dalam perawatan kesehatan. Seperti : transisi dari RM berbasis kertas/ tradisional menjadi RKE transisi dari teks bebas menjadi teks terstruktur dan interaktif "

13 Tabel 8.1 Penggunaan Utama Dan Sekunder dari Sistem RKE
Penerima perawatan pasien Manajemen perawatan pasien Proses pendukung perawatan pasien Keuangan dan proses administrasi lainnya Menajemen diri pasien Penggunaan Sekunder Pendidikan Peraturan Penelitian Kesehatan masyarakat dan keamanan dalam negeri Dukungan kebijakan Sumber : Institute of Medicine (IOM.) 2003

14 Pengertian dari kebutuhan Fungsional :
Ada beberapa sumber dari model kebutuhan fungsional yang telah dikembangkan pada beberapa tahun lalu. Ini adalah titik awal sempurna bagi suatu organisasi untuk menyusun dengan menggunakan daftar kebutuhan fungsionalnya. IOM terlibat pada model ke Kesehatan Tingkat Tujuh (HL7), yang mana pada saat ini digunakan oleh CCHIT dalam program sertifikasi menyeluruh RKE.

15 IOM ( Lembaga Kedokteran )
Menjalankan RKE pada tahun 1991 mengenai kebutuhan pemakai untuk dokumentasi pasien dan sistem catatan. Keabsahannya thn IOM meninjau kembali pelaporan, sampai 11 tahun bekerja dengan pedoman Andrew dan Bruegel (2005). Pemerintah Pusat di minta IOM untuk membimbing lanjut tentang RKE, di dalam “ Kunci keberhasilan dari suatu sistem RKE adalah Keselamatan Pasien “.

16 Sistem RKE meliputi ( IOM 2003,1 )
Informasi Kesehatan di gambarkan sebagai informasi yang menyangkut kepada kesehatan dari suatu individu atau kesehatan yang diberikan pada individu. Akses informasi hanya yang memberi hak dan diberi hak oleh pemakai. Penambahan pengetahuan dan pendukung keputusan yang meningkatkan mutu, keselamatan, dan efisiensi perawatan pasien. Pendukung tentang proses efisiensi untuk pelayanan kesehatan.

17

18 Table 8.3 IOM 2003, Kemampuan Inti untuk Suatu Sistem RKE
Fungsi Inti Contoh Informasi kesehatan dan data Kunci data yang menggunakan kode distandardisasi ditetapkan jika tersedia Informasi naratif (klinis dan pasien) Pasien Akut/ penyesuaian tingkat keparahan dari penyakit/ resiko Mencakup pengidentifikasi Hasil-hasil Manajemen Hasil pelaporan Hasil Pencatatan Berbagai pandangan data/ penyajian Multimedia pendukung Manajemen/ Order entry Entry instruksi pemberi pelayan secara komputerisasi (CPOE) Sumber : Institute of Medicine (IOM.) 2003

19 Table 8.3 IOM 2003, Kemampuan Inti untuk Suatu Sistem RKE
Fungsi Inti Contoh Pendukung keputusan (Decision Support) Akses ke sumber pengetahuan Alergi Obat Aturan lain didasarkan tanda (kecenderungan laboratorium penting, laboratorium untuk menguji obat/racun) Peringatan untuk layanan pencegahan Pedoman klinis dan Petunjuk klinis Manajemen penyakit kronis Daftar dinas Dokter Pilihan penggabungan pasien dan/ keluarga Pendukung keputusan diagnostik Penggunaan data epidemiologi Pengawasan Waktu riil secara otomatis Sumber : Institute of Medicine (IOM.) 2003

20 Table 8.3 IOM 2003, Kemampuan Inti untuk Suatu Sistem RKE
Fungsi Inti Contoh Komunikasi Elektronik dan konnektivitas Antar pemberi pelayanan Koordinasi Tim Antara Pasien- Pemberi pelayanan Alat-alat Medis Mitra dagang (External) Pengaturan antara IMR Pendukung pasien Edukasi pasien Pendidikan pd kel. dan pembantu perawatan Data yang dimasukkan oleh pasien, keluarga, dan/atau pembantu perawatan

21 Table 8.3 IOM 2003, Kemampuan Inti untuk Suatu Sistem RKE
Fungsi Inti Contoh Proses Administrasi Mengelola Penjadwalan Penentuan hal yang memenuhi syarat Pelaporan dan manajemen kesehatan populasi Laporan Mutu dan Keselamatan Pasien Laporan kesehatan masyarakat Identifikasi data Registrasi penyakit Sumber : Institute of Medicine (IOM.) 2003

22 HL7 ( Health Level Seven )
Sistem model fungsional RKE HL7 ini dipilih sebagai standar akhir lembaga Standar Nasional Amerika (ANSI ). Dalam HL7 mencatat : bahwa maksud dari standar ini adalah untuk menyediakan semua pemangku kepentingan yang terlibat dalam pelaksanaan sistem RKE dengan memahami dasar dari fungsi. fungsi yang visioner dan sangat sedikit vendor akan memiliki kemampuan untuk menggabungkan semua dari mereka segera. Profil HL7 yang pertama terkait dengan : Pengobatan Darurat Profil kedua di rilis menggambarkan Hukum RKE Profil lain untuk Prilaku Kesehatan, Kesehatan Anak, Penelitian klinis, Unit Gawat Darurat, Perawatan jangka panjang, dan otoritas kesehatan.

23

24 Komisi SertifikaSI pada Teknologi Informasi Kesehatan
Lingkup pekerjaan CCHITs mencakup : Sertifikasi produk untuk RKE dalam pengaturan rawat jalan, dimulai tahun 2006. Pengaturan rawat inap dimulai tahun 2007 Suatu penilaian kelayakan sertifikat infrastruktur atau komponen jaringan dimulai tahun 2008. Program Sertifikasi CCHIT termasuk kreteria “inti’’ dan sertifikat “opsional” Sertifikasi juga tersedia untuk sistem resep elektronik dan RKE yang digunakan klinik rawat jalan dan perawatan jangka panjang (LTC) dan pengaturan perawatan pasca akut. CCHIT juga telah mengembangkan suatu Sertifikasi Alternatif Rumah Sakit (EACH) untuk RKE, yang mengevaluasi seberapa baik langkah-langkah teknologi sampai dengan kriteria manfaatnya.

25 Sumber-sumber lain dari Kebutuhan Fungsional RKE
Sebagaimana dicatat oleh pemerintah federal (USA) dalam pembukaan peraturan Manfaat (M.U), bagaimanapun, kriteria memenuhi kebutuhan minimum serta kemampuan teknologi RKE dan telah dilaksanakan dengan baik untuk mencapai sertifikasi. Fungsi RKE pada masyarakat telah mengembangkan sebuah standar ISO (ISO 2005: persyaratan untuk arsitektur referensi RKE) untuk memandu pengembang menuju ke arah rangka Standarisasi yang merupakan RKE dari perspektif global.

26 Sumber-sumber lain dari Kebutuhan Fungsional RKE
Ada banyak fungsi mempelajari sistem dalam RKE : Setiap YanKes harus memahami RKE, dan memastikan bahwa penyedia memperoleh RKE yang benar. Menujukan fitur set yang relatif stabil dan komprehensif Sistem harus disesuaikan untuk mengakomodasi variasi, harus interoperabilitas dan komparabilitas data untuk mencapai informasi kesehatan untuk perawatan pasien.

27 Persyaratan untuk kegunaan RKE:
Fungsi dari RKE RKE menjadi “mudah untuk belajar " dan Efisien untuk menggunakan" (Holliday 2008; Dolan 2009). CCHIT dan pemerintah federal : meningkatkan kegunaan dan menghapus subjektivitas dari penilaian kegunaan . ONC pada (2007) : menjelaskan persyaratan dalam meningkatkan kualitas data dalam RKEs, dan AHIMA (2007) : memberikan kontribusi untuk menjelaskan persyaratan untuk meningkatkan kualitas data di RKEs, memberikan pedoman untuk penggunaan persyaratan kualitas data - baik upaya dimaksudkan untuk mencegah penyalahgunaan dokumentasi RKE.

28 Proses Penilaian Kebutuhan Fungsional

29 Setiap organisasi perlu menetapkan persyaratan fungsional
Setiap organisasi dimulai dari titik yang berbeda Setiap organisasi memiliki kebutuhan yang berbeda Setiap vendor menawarkan pendekatan yang agak berbeda Unsur lain dari pemilihan produk harus diperhatikan Mengidentifikasi Kebutuhan Fungsional : Lakukan Survei kebutuhan fungsional pengguna Jika set lengkap fungsi tidak direncanakan sebelumnya, maka pilihan vendor yang salah bisa terjadi. Proses survei memulai upaya pendidikan dan pengguna terlibat dari awal. Sebagai pengguna lebih memahami kemampuan fungsional miliknya, mereka dapat berkontribusi lebih banyak untuk upaya perencanaan. Proses melibatkan pengguna itu penting untuk sukses pemilihan dan pelaksanaan RKE

30 SURVEI PENGGUNA Sebagai contoh:
seorang individu telah menggunakan satu produk secara lengkap akan menguntungkan vendor dan mendorong organisasi untuk mengadopsi produk vendor, terlepas dari fungsi tersebut. Di sisi lain, pengguna yang memiliki pengalaman buruk dengan produk dapat memperkenalkan pengalaman terhadap produk vendor tersebut. Proses survei pengguna pada fungsi RKE’s seharusnya vendor netral. Penting bagi pengguna membuat kuesioner untuk mengidentifikasi setiap fungsi

31 Kasus Penggunaan Misalnya, dalam kasus RKE/Hasil Laboratorium di NHIN, persyaratan fungsional akan mencakup (Tercantum dalam urutan deskripsi mereka dalam kasus penggunaan): Kesesuaian Identitas Pasien Persetujuan Manajemen Catatan Layanan Dokter Gudang Hasil Laboratorium Pemberitahuan dari ketersediaan hasil untuk pemesanan dokter dengan RKE Pemberitahuan ketersediaan hasil untuk pemesanan dokter tanpa RKE Verifikasi pemesanan tanggal penerimaan dokter Permintaan proses dan memberikan hasil laboratorium untuk penyedia perawatan dengan RKE Pemberitahuan ketersediaan hasil laboratorium baru

32

33 Langkah Memverifikasi Persyaratan Pengguna :
1. Kemampuan Inventaris Fungsional saat ini Kemampuan fungsional ada dan diinginkan harus diidentifikasi dari alur kerja dan proses peta atau kasus penggunaan. 2. Melakukan InventarisAplikasi Fungsi RKE bergantung pada ketersediaan sistem sumber untuk memasok data. Pendekatan lain untuk menentukan kebutuhan fungsional adalah melakukan aplikasi inventarisasi untuk mengidentifikasi semua aplikasi yang saat ini ada dan bagaimana hubungan satu sama lain .

34 Langkah Memverifikasi Persyaratan Pengguna :
Inventaris Aplikasi ada 3 kategori utama : 1. Fungsi administratif Manajemen inventaris, Penjadwalan staf, Kontrol kualitas, akutansi dan jasa penagihan 2. Fungsi Perawatan Manajemen spesimen di laboratorium, manajemen dosis dalam sistem farmasi dan penjadwalan perawat. 3. Fungsi Feeder dimana sumber sistem mengirim dan menerima data dari sistem RKE, misalnya : Sistem farmasi perlu mengirim informasi resep dan menerima semua informasi resep. Langkah Memverifikasi Persyaratan Pengguna :

35 Langkah Memverifikasi Persyaratan Pengguna
3. Melakukan Review Laporan Inventaris Menyusun Laporan Inventaris adalah komponen lain dari penilaian kebutuhan fungsional secara keseluruhan. Dalam menyusun Inventaris tersebut, setiap laporan yang dihasilkan secara elektronik atau secara manual harus ditinjau; perlu review bahwa yang diinventaris yg diperlukan saja Melakukan Analisis Kebutuhan Informasi Ad Hoc Dilakukan untuk menggambarkan kebutuhan informasi yang paling sulit seperti kejasian yg jarang. Misalnya, presentasi dari dokter yang merawat pasien dengan gejala atipikal, dan DD/nya sulit dipahami. Analisis kebutuhan informasi Ad Hoc dapat dilakukan dengan membuat serangkaian pengamatan atau dengan mengembangkan skenario kasus penggunaan dengan spesialis.

36 Langkah Memverifikasi Persyaratan Pengguna
5. Melakukan Analisis Retrospektif dari pengambilan Keputusan adalah cara lain untuk memperoleh kebutuhan informasi Ad Hoc yang sulit untuk diinventarisasi. Biasanya pengambilan keputusan tidak menggunakan informasi yg ada tapi berdasarkan pengalaman. Dengan adanya informasi yang faktual maka pengambilan keputusan akan lebih tepat. 6. Membandingkan Manfaat dari Fungsi RKE penilaian kebutuhan fungsional adalah dengan membandingkan fungsi dari fungsi RKE yang ada (lihat gambar 8.6) Pertimbangan perlu diberikan untuk menggunakan kata-kata yang sederhana dan sehingga persyaratan yang jelas untuk semua pengguna potensial dari dokumen (Cantoria 2011).

37

38 Kesimpulan RKE adalah hasil akhir dari mengintegrasikan semua aplikasi dan guna menerapkan teknologi yang tepat dan alat-alat analisis untuk membuat informasi yang memberikan kontribusi untuk perbaikan sistem pelayanan kesehatan. Memahami infrastruktur informasi yang diperlukan untuk mencapai RKE sangat penting untuk semua orang yang terlibat dalam proyek. Proyek RKE harus dimulai dengan pemahaman tentang kebutuhan pengguna dan kebutuhan fungsional. Kebutuhan pengguna terdiri dari isi informasi yang diperlukan untuk membuat keputusan eksekutif atau klinis. Kebutuhan fungsional merupakan data yang menjadi informasi untuk memenuhi kebutuhan pengguna.