Nama : muhammad haekal

Npm : 21.199.032

A. Lingkup dan Tujuan Asesmen Kebutuhan RKE

Ada banyak pandangan berbeda tentang apa yang merupakan sistem EHR.
Program insentif pemerintah federal untuk membuat penggunaan yang berarti (M.U.) dari
teknologi EHR mengidentifikasi fungsi utama yang harus ditunjukkan oleh pengguna
untuk mendapatkan insentif. Namun, program insentif mengakui bahwa ada fungsi lain
yang dapat diberikan oleh EHR dan aplikasi lain yang harus mendukung fungsi EHR.
Selain itu, satu ukuran tidak cocok untuk semua dalam mengadopsi EHR. Beberapa
organisasi memerlukan lebih banyak kemampuan penyesuaian daripada yang dilakukan
orang lain. Spesialis memiliki kebutuhan yang berbeda dari generalis. Cakupan penuh
kebutuhan fungsional, persyaratan data, dan kemampuan teknis dapat dianggap sebagai
infrastruktur informasi secara keseluruhan. Gambar 8.1 menampilkan skema infrastruktur
informasi.

Memenuhi kebutuhan informasi pengguna adalah tujuan dari setiap sistem

informasi. Ketika dipertimbangkan dalam kaitannya dengan bisnis inti organisasi
perawatan kesehatan, EHR harus menerima data dari dan memasok data ke hampir setiap
sistem keuangan/administratif, operasional, dan klinis (di dalam dan di luar perusahaan)
dan harus memproses data secara efektif untuk mencapai transformasi klinis yang EHR
dimaksudkan. Berikut ini contohnya: Seorang dokter perawatan primer yang mengadakan
depariment darurat (ED) disajikan dengan pasien koma perencanaan nyeri dada.
Menggunakan protokol nyeri dada di EHR. dokter diarahkan untuk cepat menilai gejala
dan mengamati tanda-tanda dalam menanggapi intervensi tertentu. Sebagai hasil
penilaian berasal dari berbagai sistem sumber dan dokter yang bekerja dengan dokter,
semua anggota tim perawatan pasien di UGD memiliki kesempatan untuk meninjau hasil
yang datang dari vanous intervensi dan mengambil langkah selanjutnya yang sesuai
dengan cara yang lemah. Sistem seperti itu telah ditemukan untuk.
 akurat dan cepat mendiagnosis nyeri chcst dan mengurangi penerimaan unit
perawatan koroner. (Mausel 2001) Apa yang membuat EHR menjadi sistem yang
kompleks untuk diterapkan tidak hanya keterkaitan semua aplikasi tetapi juga integrasi
semua komponen lain dari infrastruktur informasi. EHR mengharuskan aplikasi untuk
bekerja sama. Selain menjadi tantangan teknis, ini adalah kebijakan, organisasi. tantangan
finansial, dan politik.

Meminjam dari model pemrosesan data klasik. aplikasi adalah output dari
infrastruktur informasi secara keseluruhan. Untuk mendapatkan output yang diinginkan,
input yang tepat harus disediakan: oleh karena itu, fungsionalitas bertumpu pada
infrastruktur informasi. Infrastruktur informasi mendukung kemampuan input sistem.
Pencapaian output dari input merupakan komponen pengolahan yang meliputi alat
analisis dan teknologi. Pemrosesan inputProses output tidak benar-benar sebuah sistem
tanpa pengguna dan penggunaan informasi. Ini adalah penerima manfaat dan manfaat
dari sistem. Beberapa di antaranya adalah pengguna dan kegunaan organisasi internal,
yang lain adalah eksternal organisasi.

Untuk sebuah organisasi untuk memastikan memiliki infrastruktur yang

diperlukan untuk mendukung manfaat EHR yang diinginkan, proses logis harus
dilakukan untuk mengidentifikasi cakupan penuh dari infrastruktur informasi yang
dibutuhkan untuk mencapai EHR. Ini dimulai dengan penilaian kebutuhan fungsional
(dijelaskan dalam bab ini), pindah ke penilaian infrastruktur data (dijelaskan dalam Bab
9), dan menyelesaikan siklus dengan penilaian infrastruktur teknologi (dijelaskan dalam
bab 10). Hasil akhir dari penilaian ini adalah pernyataan spesifikasi persyaratan yang
dapat digunakan untuk membandingkan kemampuan saat ini, mengidentifikasi
kesenjangan. mengevaluasi penawaran vendor, dan akhirnya membangun sistem EHR.
B. Model-model Persyaratan Fungsional RKE

Proses penilaian kebutuhan fungsional harus dimulai dengan mengidentifikasi

kebutuhan informasi internal dan eksternal organisasi. Kebutuhan ini akan mencakup
kebutuhan primer dan sekunder dari sistem EHR, seperti yang dijelaskan dalam laporan
IOM Kev Kemampuan Sistem Catatan Kesehatan Elektronik (TOM 2003). Pada tingkat
tinggi, hal tersebut diidentifikasi dalam tabel 8.1. Alat pemetaan alur kerja dan proses
yang dijelaskan dalam bab 7 adalah sumber utama untuk mengonfirmasi input dan output
yang diberikan pada tingkat yang lebih terperinci dan terperinci.

Dalam Manual Akreditasi Komprehensif untuk Rumah Sakit (CAMH), Komisi

Gabungan mengakui bahwa “penyediaan perawatan” organisasi. tracatment, dan services
merupakan upaya kompleks yang sangat bergantung pada informasi” Joint Commission
2008). Dengan demikian, dalam pengelolaannya standar informasi» untuk akreditasi.
Komisi Gabungan mewajibkan organisasi untuk “memperlakukan informasi sebagai
sumber daya penting untuk mengelola bc secara efektif dan efisien.” Hal ini selanjutnya
menunjukkan bahwa mengelola informasi adalah aktivitas aktif, terencana, dan proses
identifikasi kebutuhan informasi harus dilakukan.

dilakukan dengan baik untuk mencapai "tujuan dari fungsi manajemen informasi
(yang adalah untuk mendukung pengambilan keputusan untuk meningkatkan hasil pasien,
meningkatkan dokumentasi perawatan kesehatan, menjamin keselamatan pasien, dan
meningkatkan kinerja dalam perawatan pasien, pengobatan, dan layanan. tata kelola,
manajemen, dan mendukung proses" (Joint Commission 2008). Standar Joimt
Commission dirancang agar kompatibel dengan sistem berbasis kertas, sistem elektronik,
atau sistem hybrid. Komisi Gabungan selanjutnya mengakui bahwa "kualitas perawatan,
pengobatan, dan layanan terpengaruh. oleh banyak transisi dalam manajemen informasi
yang saat ini sedang berlangsung dalam perawatan kesehatan, seperti transisi dari manual
dan dokumentasi berbasis kertas tradisional ke manajemen informasi elektronik, serta
transisi dari teks bebas ke teks terstruktur dan interaktif” Joint Commission 2008) .
 Komisi Gabungan mengharuskan rumah sakit "mendasarkan proses manajemen
informasi mereka pada penilaian kebutuhan informasi internal dan eksternal." Mereka
harus mengidentifikasi “aliran informasi di seluruh rumah sakit, termasuk penyimpanan
informasi dan mekanisme umpan balik,” dan mengidentifikasi “data dan informasi yang
dibutuhkan: di dalam dan di antara

departemen, layanan. atau program: di dalam dan di antara staf, administrasi, dan
tata kelola untuk mendukung hubungan dengan layanan luar dan kontraktor, dengan
badan perizinan, akreditasi, dan pengatur: dengan pembeli, pembayar, dan pemberi kerja:
untuk informasi pendukung yang diperoleh antara rumah sakit dan pasien: dan untuk
berpartisipasi dalam penelitian dan database” Joint Commission 2008).

a. Institute of Medicine (IOM)

Ketika IOM mengeluarkan laporan pertamanya tentang EHRs pada tahun 1991,
IOM mengidentifikasi seperangkat persyaratan pengguna untuk catatan pasien dan sistem
catatan. Ini dikonfirmasikan sebagai masih berlaku dalam laporan IOM 1997 yang
direvisi dan terus ditegaskan kembali melalui 11 tahun kerja oleh Andrew dan Bruegel
(2005). Persyaratan pengguna IOM asli untuk catatan pasien dan sistem catatan
direproduksi dalam tabel 8.2. Persyaratan pengguna ini telah divalidasi dalam pembuatan
edisi revisi dan tetap berlaku hingga hari ini.

Dengan minat baru pada EHR yang terjadi sebagai akibat dari masalah
keselamatan pasien. pemerintah federal meminta IOM untuk memberikan panduan lebih
lanjut tentang kemampuan utama sistem EHR. Dalam Key Capabiliries of an Electronic
Health Record System, IOM mengidentifikasi bahwa sistem EHR mencakup (IOM 2003,
1):
 Pengumpulan informasi kesehatan elektronik secara longitudinal untuk dan tentang
orang, di mana "informasi kesehatan" didefinisikan sebagai informasi yang berkaitan
dengan kesehatan individu atau layanan kesehatan yang diberikan kepada individu

 Akses elektronik langsung ke informasi tingkat orang dan populasi oleh pengguna yang
berwenang (dan hanya berwenang)

 Penyediaan pengetahuan dan dukungan keputusan yang meningkatkan kualitas,

keamanan, dan efisiensi perawatan pasien

 Mendukung proses yang efisien untuk pemberian layanan kesehatan

B. HL7

Selain menerbitkan panduannya tentang fungsionalitas EHR, pekerjaan IOM

tahun 2003 berkontribusi pada pekerjaan HL7, yang merupakan organisasi
pengembangan standar yang ditargetkan oleh HHS untuk mengembangkan standar untuk
model fungsional sistem EHR. Model Fungsional Sistem HL7 EHR dipilih sebagai
standar akhir yang disetujui oleh American National Standards Institute (ANSI) pada
musim semi 2007. Model ini diberikan dalam lampiran B dan didasarkan pada kerangka
yang diilustrasikan pada Gambar 8.2.

Akhirnya, HL7 telah mengakui pentingnya interoperabilitas memainkan baik di

aplikasi yang berbeda dalam organisasi pemberian perawatan serta dalam pertukaran
informasi kesehatan. Ini mengembangkan HL7 Serviccs-Aware Interoperability
Framework (2010) untuk memberikan konsistensi di seluruh infrastruktur informasi.
apakah mereka bertukar data terstruktur atau tidak terstruktur, dokumen, pesan dan
layanan, metadata, atau sumber daya lainnya.

C. Komisi Sertifikasi Teknologi Informasi Kesehatan (CCHIT)

Pada musim semi 2004, Presiden George W. Bush menyerukan penyebaran luas
teknologi informasi kesehatan (HIT). Selanjutnya, HHS mendirikan Kantor Koordinator
Nasional untuk Teknologi Informasi Kesehatan (ONC) dan Komunitas Informasi
Kesehatan Amerika (AHIC). Pada bulan Juli 2004, ONC menerbitkan Kerangka Aksi
Strategis, yang termasuk dalam tujuan luasnya “sertifikasi sektor swasta produk HIT”
(Thompson dan Brailer 2004). Sebagai tanggapan, AHIMA. HIMSS, dan Aliansi
Nasional untuk Teknologi Informasi Kesehatan (Aliansi) mendanai dan meluncurkan
Komisi Sertifikasi Teknologi Informasi Kesehatan (CCHIT). Tujuannya adalah "untuk
mempercepat adopsi HIT yang kuat dan dapat dioperasikan di seluruh sistem perawatan
kesehatan AS dengan menciptakan mekanisme yang efisien, kredibel, dan berkelanjutan
untuk sertifikasi produk HIT" (CCHIT 2005). Kemudian, beberapa organisasi lain
bergabung dalam upaya tersebut, dan CCHIT diberikan kontrak HHS untuk
mengembangkan dan menilai kriteria dan proses inspeksi EHR dan sertifikasi nctwork.7

Lingkup pekerjaan CCHIT termasuk sertifikasi produk untuk EHR dalam

pengaturan perawatan rawat jalan, yang dimulai pada tahun 2006: sertifikasi produk
untuk EHR dalam pengaturan perawatan rawat inap, yang dimulai pada tahun 2007: dan
penilaian kelayakan infrastruktur sertifikasi atau komponen jaringan (seperti organisasi
pertukaran informasi kesehatan) dimulai pada tahun 2008. Untuk sertifikasi produk EHR-
nya, CCHIT mengidentifikasi fungsionalitas, intcroperability, dan kriteria keamanan—
yang sebagian besar diambil dari Model Fungsional Sistem EHR HL7 serta berbagai
organisasi pengembangan standar lainnya. HIPAA, dan standar keamanan lainnya.
Beberapa ratus kriteria diidentifikasi, dan kasus penggunaan dibuat sebagai enanos
pengujian. Penyeberangan antara kriteria dan skenario dikembangkan untuk memandu
vendor dan konsumen mengenai kerangka waktu di mana berbagai kriteria akan
dibutuhkan dalam produk untuk disertifikasi.

Meskipun CCHIT sekarang menjadi salah satu dari beberapa badan sertifikasi
yang disetujui ONC yang mengevaluasi produk EHR untuk menilai apakah mereka
memenuhi M.U. kriteria insentif, ia terus mempertahankan dan meningkatkan apa yang
sekarang tidak diakuinya sebagai program CC HIT Cenufied (2011). Ini dirancang untuk
memelihara inventaris yang luas dari kriteria fungsional, serta kriteria untuk
interoperabilitas dan keamanan. Program CCHIT Cerufied mencakup kriteria "inti" dan
sentifikasi "opsional". Sertifikasi opsional adalah sertifikasi tambahan untuk kesehatan
perilaku, kedokteran kardiovaskular, kesehatan anak, dan dermatologi. Sertifikasi
opsional untuk penelitian klinis, onkologi. dan kesehatan wanita sedang dcvclopcd.
Perusahaan yang memiliki produk bersertifikat di rawat jalan, rawat inap. dan
departemen darurat membenarkan opsi tambahan sertifikasi perusahaan yang
menunjukkan interoperabilitas di antara pengaturan tersebut. Sertifikasi juga tersedia
untuk sistem peresepan elektronik dan EHR yang digunakan di klinik rawat jalan
kesehatan perilaku dan rangkaian perawatan jangka panjang dan pasca akut. CCHIT juga
telah mengembangkan Sertifikasi Alternatif EHR untuk Rumah Sakit (EACH). yang
mengevaluasi seberapa baik teknologi mengukur hingga M.U. kriteria dan
memungkinkan rumah sakit untuk mengejar Sertifikasi untuk teknologi EHR yang ada
yang belum tercakup oleh sertifikasi vendor. Dengan cara ini, sistem yang dikembangkan
sendiri atau sistem lama yang telah disesuaikan secara signifikan dapat disertifikasi untuk
M.U.

D. Sumber lain dari Peraturan Fungsional EHR

Model fungsional EHR yang paling diakui secara nasional dan terluas telah
dijelaskan. Perhatikan bahwa M.U. kriteria tidak dimasukkan sebagai model
fungsionalitas EHR yang komprehensif. Ini karena kriteria dimaksudkan untuk melayani
tujuan yang sangat spesifik dan terbatas—untuk memberikan insentif untuk
menggunakan fungsi tertentu. Sebagaimana dicatat oleh pemerintah federal dalam
pembukaan M.U. peraturan, namun. kriteria tersebut mewakili kemampuan minimum
yang harus disertakan oleh teknologi EHR dan telah diterapkan dengan benar untuk
mencapai sertifikasi. Ada fungsi tambahan yang sebagian besar organisasi anggap
penting yang tidak disertakan. Mungkin yang paling menonjol adalah fungsi pencatatan
administrasi obat untuk rumah sakit dan fungsi penangkapan biaya untuk semua bentuk
EHR.

Namun, ada banyak set daftar fungsi lain yang dapat membantu organisasi dalam
penilaian fungsional, terutama di mana organyaton memiliki kebutuhan khusus. Sebagian
besar dari masyarakat khusus dokter telah mengembangkan Iis dari negusremen
fungsional FHR yang berhubungan dengan nceds anggota mereka. Banyak dari ini
bekerja dekat dengan CCHIT, menyumbangkan pekerjaan mereka ke "sertifikat
opunonal." atau contoh. Spooner (2007) menjelaskan persyaratan khusus untuk EHR
 yang digunakan dalam pediatncs. American Society of Clinal Oncology (2009)
menciptakan "Peraturan Fungsional EHR Onkologi Tingkat Tinggi dan Khusus
Pengguna." Mereka juga merupakan beberapa Iis komersial fungsi EHR di pasar yang
melaporkan informasi dari survei vendor atau pelanggan Akhirnya, komunitas
internasional telah mengembangkan sandard ISO ISO 2005:18308—Reguirements for
EHR Reference Architecture) untuk memandu pengembang menuju standarisasi
kerangka kerja tentang apa yang membentuk EHR dari perspektif global.

Mengamati banyaknya daftar fungsi. Drury (2006) melakukan perbandingan lima

Isis tersebut. Ini termasuk orang-orang dari HL7 dan CCHIT serta daftar dari Burcau of
Primary Hcalih Care. COPIC Insurance, dan The Physicians Foundauon Gucstonnaire
(didirikan oleh perusahaan asuransi Actna dan CIGNA). Ada banyak tujuan untuk
mempelajari sejumlah besar daftar fungsi, termasuk:

 Tingkat ketajaman mencerminkan hampir putus asa di bagian dari sistem pemberian
layanan kesehatan untuk bcttcr memahami EHR dan memastikan bahwa penyedia yang
menerapkan EHRS tidak diduplikasi.

 Tingkat kesamaan dalam pernyataan tujuan dan fungsionalitas, setelah terminologi

dinormalisasi, menunjukkan fitur dan fungsi yang relatif stabil dan komprehensif yang
telah secara konsisten dikenal sebagai terdiri dari EHR.

 Beberapa versi dengan terminologi dan kerangka waktu yang berbeda mencerminkan
bahwa tugas 4 kompleks, dan jika pengembangan dan perolehan EHR ingin dicapai oleh
"massa", harus ada standar yang mendukung "produksi massal" yang lebih besar dan
biaya produksi yang lebih rendah. kepemilikan. Meskipun sistem harus disesuaikan 10
mengakomodasi variasi, ada juga harus interoperabilitas komponen sistem dan
komparabilitas data untuk mencapai bentuk longitudinal untuk perawatan produk di
seluruh bagian dan rangkaian mobil mereka.

e. Persyaratan kegunaan untuk EHRs

 Meskipun bab ini berfokus pada penilaian fungsi EHR, banyak yang meminta
kegunaan yang lebih baik dan fungsionalitas yang dicari. Kegunaan 1 sering dapat
memberikan pengaturan yang fungsional. bahkan jika secara umum banyak yang
memisahkan nada suara fum dari kegunaan. Lessons from History (2011) membedakan
persyaratan fungsional sebagai "Apa yang harus dapat dilakukan oleh sistem atau
komponen 2", dari persyaratan nonfungsional yang menggambarkan "bagaimana suatu
sistem berperilaku". Sebagai cxamplc, "rekam/nyanyikan perubahan vigns vital" 1 salah
satu M.U. cntena. Sedangkan "tampilan tanda-tanda vital pasien harus merespon
perubahan status paten dalam waktu dua detik" adalah peraturan kegunaan pelengkap.

Menilai kegunaan produk seringkali subjektif. Pengamat EHR menyerukan agar

EHR menjadi Tcaxy untuk Ica” dan “efisien untuk digunakan” (Holliday 2008: Dolan
2009). Sebagai hasil dari permintaan untuk kegunaan yang lebih baik dari sebuah EHRS,
baik CCHIT dan pemerintah federal telah mulai menangani aspek-aspek penting yang
terkait dengan fungsi EHR, sebuah upaya baik untuk meningkatkan kegunaan dan
menghapus subjek dari penilaian kegunaan.

Untuk tahun 2011, CCHIT akan memasukkan pengujian kegunaan dalam proses
sertifikasi EHR rawat jalan. Uji tamu untuk kriteria kegunaan CCHIT dikembangkan
dengan berkonsultasi dengan User Centric, ahli di bidang pengujian kegunaan, yang telah
disertakan. misalnya penelitian untuk melacak pergerakan mata untuk mengetahui
kegunaan mesin pencari (Bojko 2011).

ONC (2047) telah berkontribusi untuk menjelaskan persyaratan untuk

meningkatkan kualitas data dalam EHR, dan AHIMA (2007) telah memberikan pedoman
untuk penggunaan persyaratan kualitas data, kedua upaya yang dimaksudkan untuk
mencegah penipuan melalui penyalahgunaan yang tidak disengaja dari alat bantu
dokumentasi EHR. Pekerjaan ONC telah diperpanjang, dalam hubungannya dengan
Agency for Healthcare Research and Ouality (AHRO). untuk menggambarkan
pertimbangan desain antarmuka (manusia-komputer) untuk kegunaan EHR (AHRO
2009).
 Institut Nasional Standar dan Teknologi (NIST), yang digunakan ONC untuk
melakukan pengujian produk komponen sertifikasi untuk produk EHR ke M.U. program
insentif, telah mengambil pekerjaan ini dan membuat panduan untuk pendekatan proses
untuk meningkatkan kegunaan EHR (2010) dan template format industri umum yang
disesuaikan untuk pengujian kegunaan EHR (2010).

C. Proses Asesmen Kebutuhan Fungsional RKE

Orang mungkin bertanya-tanya, jika model persyaratan fungsional ada dan

sertifikasi produk sedang berjalan, mengapa organisasi tertentu harus mereplikasi proses
pendefinisiannya sendiri. peraturan. Setiap organisasi perlu mendefinisikan persyaratan
fungsionalnya karena sejumlah alasan, termasuk:

 Setiap organisasi dimulai dari titik yang berbeda. Beberapa organisasi mungkin memiliki
otomatisasi minimal, yang lain mungkin memiliki otomatisasi yang sangat terspesialisasi,
dan yang lain mungkin memiliki otomatisasi moderat di seluruh organisasi. Beberapa
mungkin beroperasi pada platform lama yang tidak mendukung beberapa fungsi yang
lebih baru. Mendefinisikan persyaratan relatif terhadap infrastruktur teknis yang ada
sangat penting.

 Setiap organisasi memiliki kebutuhan yang berbeda. Apa yang mungkin dianggap oleh
satu organisasi sebagai persyaratan penting, yang lain mungkin hanya menganggapnya
"diinginkan." Fungsionalitas juga akan berkembang dari waktu ke waktu sebagai hasil
pembelajaran dari penggunaan yang ditingkatkan.

 Setiap vendor menawarkan pendekatan yang agak berbeda. Meskipun banyak vendor
menawarkan produk dengan semua kriteria yang diuraikan dalam satu daftar fungsi atau
lainnya, fungsionalitas tidak selalu ditawarkan dalam satu aplikasi atau bahkan melalui
satu vendor. Organisasi perlu memutuskan apakah mereka ingin (1) fokus pada satu
vendor dan menerima penawaran vendor tersebut, (2) bekerja dengan vendor inti yang
dapat mencapai serangkaian fungsi yang lebih luas, (3) mendapatkan produk terbaik
 untuk semua fungsi dan mencoba mengintegrasikannya, atau (4) mengembangkan
beberapa aplikasi mereka sendiri untuk mengisi celah.

 Elemen lain dari pemilihan produk harus dipertimbangkan. CCHIT telah menekankan
bahwa sejarah dan kelangsungan hidup perusahaan. staf, jumlah dan jenis klien, sifat
implementasi dan pelatihan yang diberikan, tingkat dan kualitas dukungan dan, tentu saja,
biaya. adalah semua faktor yang harus dipertimbangkan.

Penilaian kebutuhan fungsional organisasi mana pun. karena itu. perlu

menggunakan fungsional Model Teguirements sebagai sumber daya, tetapi model
tersebut juga harus mencerminkan organisasi kemampuan dan kebutuhan.

1. Mengidentifikasi kebutuhan fungsional

Sebuah penilaian kebutuhan fungsional sering dimulai dengan survei kebutuhan

fungsional pengguna. Dalam survei semacam itu, pengguna diminta untuk
mengidentifikasi fungsionalitas yang dibutuhkan dan mungkin memberi peringkat
prioritas. Meskipun survei pengguna penting, pengguna harus cukup terdidik tentang
fungsionalitas EHR agar sepenuhnya responsif. Tanpa benar-benar memahami
kedalaman dan keluasan fungsionalitas. pengguna mungkin dapat mengidentifikasi hanya
persyaratan terbatas pada awalnya. Tetapi setelah beberapa fungsionalitas
diimplementasikan. mereka mungkin mulai melihat potensi dan menyadari bahwa EHR
mampu memberikan lebih banyak lagi. Jika serangkaian fungsionalitas lengkap tidak
direncanakan sebelumnya, pilihan vendor yang salah dapat dibuat atau. berpotensi, jalur
migrasi mungkin piccemeal dan menghasilkan komponen yang berbeda yang tidak
mendukung satu sama lain. Karena pengguna layanan kesehatan biasanya sangat
terspesialisasi dan oleh karena itu fokus pada aktivitas tertentu. mereka mungkin tidak
melihat gambaran besar atau memahami bagaimana suatu tindakan di satu area
berdampak pada area lain.

Terlepas dari kekurangan survei pengguna dan cara alternatif yang membantu
deskripsi fungsionalitas, proses melibatkan pengguna sangat penting untuk pemilihan dan
implementasi EHR yang sukses. Proses survei memulai upaya pendidikan dan melibatkan
pengguna sejak awal. Karena pengguna lebih memahami kemampuan fungsional EHR,
mereka dapat berkontribusi lebih banyak pada upaya perencanaan.

a. Mensurvei pengguna (survey pengguna) Beberapa pendekatan dapat dilakukan untuk

mensurvei pengguna. Cara yang baik untuk memulai adalah dengan sekelompok
pengguna inti yang telah terpapar sistem EHR melalui minat pribadi atau
menggunakannya dalam pengaturan lain. Teknik fasilitasi kelompok dapat digunakan
untuk memastikan bahwa proses survei pengguna memberikan nilai bagi organisasi.
Proses kelompok nominal bekerja sangat baik jika pengguna diantisipasi untuk
dipilih. Misalnya, seorang individu yang telah menggunakan satu produk secara
ekstensif mungkin menguntungkan vendor dan mendorong keras untuk organisasi
untuk mengadopsi produk vendor, terlepas dari fungsinya. Di sisi lain, pengguna yang
memiliki pengalaman buruk dengan suatu produk dapat menimbulkan bias terhadap
vendor itu produk. Proses survei pengguna pada fungsionalitas EHR harus netral
vendor.

Setelah pengguna inti mengidentifikasi satu set fungsi, dimungkinkan untuk

membuat & membuat daftar tamu di mana orang lain diminta untuk memberi
peringkat pentingnya fungsionalitas dan mengidentifikasi fungsi yang hilang yang
dianggap penting atau diinginkan. Lagi. dibutuhkan “konsumen terdidik” untuk dapat
membedakan antara fungsi-fungsi. Jika sebagian besar narasumber kembali dengan
setiap fungsi diperiksa sebagai kritis, tamu undangan mungkin hanya berfungsi
sebagai proses token untuk melibatkan pengguna. Sebagus-bagusnya. pengguna akan
berpikir bahwa mereka telah berkontribusi pada proses tersebut. Sayangnya. banyak
yang mungkin menyadari kekurangan dari proses tersebut dan merasa bahwa mereka
belum ditawari kesempatan untuk memberikan masukan yang benar. Selain itu. jika
grup inti tidak mewakili komunitas pengguna penuh, tebakan mungkin dilihat sebagai
cara bagi individu tertentu untuk melakukan proses. Efek negatif lain dari acara tamu
seperti itu adalah bahwa calon pengguna mungkin memiliki kesan yang salah bahwa
 karena mereka telah mencentang semuanya, sistem akan menyediakan semuanya
secara otomatis.

Mungkin tepat untuk menggunakan seperangkat pernyataan peraturan

fungsional yang disertakan dalam tamu undangan sebagai titik awal untuk diskusi
kelompok fokus Setelah pengguna yang berpengalaman dan tidak berpengalaman
telah memberikan volume masukan yang cukup, mungkin efektif untuk kembali ke
format daftar tamu sebagai validasi. dan penyempurnaan dari semua input yang
diterima. Jika memungkinkan untuk membuat narasi tamu dengan cara yang meminta
pengguna potensial untuk mengidentifikasi Apa yang mereka bisa hidup tanpanya,
atau dalam kerangka ume apa yang mereka bayangkan implementasinya,
guesuonnaire mungkin lebih memakan ume untuk diselesaikan tetapi menghasilkan
lebih bernilai informasi.

B. Usecases

Pendekatan lain untuk mendefinisikan persyaratan fungsional adalah teknik use-

case. yang seringkali lebih mudah diberikan oleh dokter. Use case pada dasarnya adalah
skenario yang menggambarkan perilaku sistem saat merespons reguest yang berasal dari
luar sistem itu. Use case menggambarkan interaksi antara aktor utama atau inisiator
interaksi, seperti perawat, dan sistem itu sendiri, seperti memberikan pemberitahuan
bahwa pasien harus menjalani pengobatan. Kasus penggunaan dapat dideskripsikan
secara berbeda tingkat kerumitan yang berbeda dan tidak memerlukan kerangka atau
struktur standar untuk dokumentasi. meskipun ini tersedia untuk digunakan jika
diinginkan. Saat melibatkan dokter dalam pengembangan kasus penggunaan, mudah
untuk meminta mereka memikirkan beberapa peristiwa perawatan pasien yang khas,
kompleks luar biasa, dan luar biasa. kasian. Mereka mungkin memilih untuk
menuliskannya, mungkin dalam daftar. Seperti halnya peta proses yang dijelaskan dalam
bab 7, atau menghubungkannya dengan analis sistem yang mungkin membuat catatan dan
memasukkannya ke dalam format diagram alur.
 Dalam mendokumentasikan kasus penggunaan secara formal. format standar akan
membuatnya lebih mudah untuk digunakan nanti dalam proyek EHR. Bagian khas dari
use case tercantum dalam gambar 8.4.

Setelah kasus penggunaan dikembangkan. masing-masing kondisi. pemicu.

peristiwa, jalur alternatif, dan aturan bisnis dapat dianalisis untuk menentukan fungsi apa
yang ada di EHR untuk mendukungnya.

Komunitas Informasi Kesehatan Amerika (AHIC), yang didirikan oleh Sekretaris

HHS Leavitt, telah sangat terlibat dalam menciptakan kasus penggunaan untuk jaringan
informasi kesehatan nasional (NHIN), yang kemudian digunakan oleh Panel Standar
Teknologi Informasi Kesehatan (HITSP) untuk mengembangkan spesifikasi

Diagram kasus penggunaan ini disematkan dalam dokumen setebal 30 halaman di

mana prasyarat disahkan termasuk skenario yang menggambarkan 15 skenario di mana
seorang dokter menerima hasil laboratorium melalui NHIN. Hal ini jelas berbeda dengan
jika dokter hanya menerima hasil lab dari sistem informasi laboratorium internal (SI).
Ada juga aturan bisnis yang terkait dengan skenario ihus yang dijelaskan dalam narasi.
Misalnya, peraturan CLIA

ulangi bahwa dokter yang memesan harus menerima hasil laboratorium sebelum
orang lain dapat mengaksesnya. Dalam diagram uscif. baris atas simbol menggambarkan
aktor. dan kotak dan garis alur yang tersisa menggambarkan rangkaian peristiwa dasar,
Perhatikan bahwa tidak ada jalur alternatif pada contoh kasus penggunaan khusus ini,
tetapi ini ditunjuk sebagai Skenario 1. Skenario lain dalam rangkaian kasus penggunaan
depki alternatif.Kasus penggunaan ini menggambarkan betapa sederhananya bagi
pengguna mana pun untuk mengembangkan skenario, dan seberapa kuat hasilnya bagi
mereka yang menyusun peraturan fungsional.

Kasus penggunaan ini menggambarkan betapa sederhananya bagi pengguna mana

pun untuk mengembangkan skenario, dan seberapa kuat hasilnya bagi persyaratan
fungsional kompilasi tersebut. Misalnya, dalam hal Hasil EHR/Laboratorium di NHIN,
persyaratan fungsional akan mencakup (tercantum dalam urutan deskripsinya dalam
kasus penggunaan):
 Pencocokan identitas pasien

 Manajemen persetujuan

 Layanan pencari rekaman

 Tempat penyimpanan hasil laboratorium

 Pemberitahuan ketersediaan hasil untuk memesan dokter dengan EHR

 Pemberitahuan ketersediaan hasil kepada dokter yang memesan tanpa EHR

 Verifikasi tanggal penerimaan klinisi pemesanan

 Proses mengatur dan memberikan hasil laboratorium kepada penyedia perawatan dengan
EHR

 Pemberitahuan ketersediaan hasil laboratorium baru

Selain ONC menggunakan pendekatan use case untuk menentukan persyaratan

fungsional untuk NHIN, AHRO (2009) juga merekomendasikan pengembangan skenario
use case untuk mengevaluasi kegunaan EHR. AHRO menjelaskan empat skenario dan
bagaimana interaksi komputer dilakukan di masing-masing skenario. Skenario termasuk
untuk episode perawatan akut, manajemen kondisi kronis, layanan pencegahan dan
promosi kesehatan, dan pengembangan diagnosis berbasis bukti pada gejala yang tidak
berdiferensiasi (yaitu, yang berasal dari multifaktorial dan beragam dalam spektrum, di
mana gejala yang muncul adalah umum untuk beberapa diagnosis potensial dan mungkin
atau mungkin tidak terkait dengan kondisi sebelumnya atau penyakit kronis).

A. Inventarisasi kapabilitas fungsional saat ini

Mengidentifikasi kapabilitas fungsional sistem yang sudah ada sebagai inventaris

kapabilitas fungsional formal tidak hanya membantu pengguna potensial untuk melihat
ruang lingkup kapabilitas saat ini tetapi juga menetapkan landasan untuk memahami
kapabilitas fungsional esensial apa yang mungkin hilang yang diperlukan untuk
mendukung kemampuan lain yang lebih kuat. Kemampuan fungsional yang ada dan
 diinginkan harus diidentifikasi dari alur kerja dan peta proses atau kasus penggunaan. Ini
dapat didokumentasikan terhadap salah satu model peraturan fungsional atau daftar
peraturan fungsional organisasi. Dimensi lain mungkin untuk mensurvei penggunaan
aktual dari kemampuan fungsional saat ini karena banyak organisasi telah menerapkan
sistem yang tidak sepenuhnya digunakan. Ini dapat membantu menggambarkan tingkat
manajemen perubahan dan pendidikan/pelatihan yang dibutuhkan untuk EHR.

B. Melakukan inventarisasi aplikasi Fungsi

EHR tergantung pada ketersediaan sistem sumber untuk memasok data.

Pendekatan lain untuk menentukan persyaratan fungsional adalah dengan melakukan
inventarisasi aplikasi untuk mengidentifikasi semua aplikasi yang ada saat ini dan
bagaimana mereka dapat saling berhubungan (atau tidak). Gambar 8.5 menunjukkan
contoh alat yang sering digunakan oleh departemen teknologi informasi (TI) untuk
menggambarkan antarmuka IS. Ini adalah cara yang baik untuk memulai inventaris
aplikasi. Sistem apa pun yang tidak terhubung atau aplikasi apa pun yang merupakan
bagian integral dari sistem yang lebih besar harus ditambahkan ke daftar. Sistem yang
tidak terhubung tetapi mungkin bertukar data dengan EHR dapat mencakup, misalnya,
sistem penjadwalan ruang operasi atau sistem departemen darurat. Aplikasi yang
merupakan bagian integral dari IS rumah sakit mungkin termasuk akses pasien, grafik
perawatan pasien, pengambilan biaya, dan sebagainya.

 Sistem sumber umumnya melakukan tiga kategori fungsi utama:

 Fungsi administratif untuk departemen yang mereka layani yang independen dari EHR:
misalnya, manajemen inventaris, penjadwalan staf, kontrol kualitas, akuntansi, dan
layanan penagihan

 Fungsi perawatan tambahan yang spesifik untuk aplikasi, seperti manajemen spesimen di
sistem laboratorium, manajemen dosis di sistem farmasi, dan penjadwalan perawat di
sistem keperawatan

 Fungsi pengumpan di mana sistem sumber mengirim data ke dan menerima data dari
sistem EHR, seringkali melalui komunikasi pesanan dan komponen pengambilan hasil
 (misalnya, sistem farmasi perlu mengirim informasi resep ke, dan menerima informasi
resep dari, sistem EHR)

Organisasi perawatan kesehatan mungkin kekurangan semua sistem sumber yang

diperlukan untuk memenuhi persyaratan fungsional tertentu yang diinginkan dari sistem
EHR. Sangat berguna untuk melakukan inventaris aplikasi di mana sumber dan
penggunaan data diidentifikasi s0 informasi ini dapat diterapkan pada jalur migrasi
organisasi karena mungkin perlu menginstal satu sistem sumber sebelum yang lain.
Misalnya, SI laboratorium harus ada sebelum sistem komunikasi pesanan yang
mengirimkan pesanan ke laboratorium dapat diimplementasikan.

Lakukan Laporan Tinjauan Fisik

Menyusun laporan Inventaris adalah komponen lain dari penilaian kebutuhan fungsional secara
keseluruhan. Dalam menyusun inventarisasi semacam itu, setiap laporan yang dihasilkan secara
elektronik atau manual harus ditinjau: pertama apakah laporan itu benar-benar dibutuhkan, dan
kedua untuk informasi yang dihasilkan. Salah satu cara untuk menentukan apakah laporan
diperlukan adalah dengan menghentikan pembuatan semua laporan untuk jangka waktu dan detik
siapa yang meminta laporan tertentu. Jika tidak ada yang meminta laporan dan tidak diwajibkan,
mungkin tepat untuk mempertimbangkan untuk menghentikan fungsi pelaporan tersebut. Untuk
laporan yang diperlukan atau diinginkan, organisasi harus menilai apakah semua bidang sudah
lengkap dan apakah informasi yang dilaporkan terkini, akurat, dan lengkap. Pengguna juga harus
ditanya apakah ada aktivitas pelaporan yang diinginkan di mana mereka tidak berpartisipasi
karena mereka tidak memiliki data yang memadai atau dapat diakses dengan mudah. Jika
demikian, salinan laporan-laporan ini harus diperoleh dan analisisnya dimasukkan dalam
penilaian ncds. Terakhir, semua permintaan untuk laporan informasi atau akses ke data tertentu
harus dicatat dan dievaluasi untuk menentukan apakah mereka juga mewakili kebutuhan
pelaporan untuk EHR.
Lakukan analisis Persyaratan Informasi Ad Hoc

Analisis persyaratan informasi ad hoc dilakukan untuk menangkap kebutuhan informasi yang
paling sulit, seperti yang terjadi secara tidak rutin atau sesekali. Misalnya, seorang dokter yang
merawat pasien dapat memutuskan bahwa gejala atipikal disajikan, dan diagnosis banding sulit
dipahami. Pengetahuan khusus tertentu akan sangat membantu untuk mencapai diagnosis yang
lebih pasti dan menentukan rencana perawatan yang tepat. Dukungan tersebut mungkin perlu
diberikan—seperti utilitas pendukung keputusan khusus atau pencarian literatur, dengan data
yang tidak diambil secara rutin sebagai bagian dari template EHR standar.

Misalnya, bidang dermatologi memiliki alat bantu diagnostik yang disebut VisualDx (2010) yang
memungkinkan dokter kulit untuk membandingkan foto lesi kulit pasien mereka dengan foto
stok berbagai penyakit atau kondisi yang berbeda (dan seringkali jarang) (seperti gigitan
serangga yang tidak biasa atau alergi). Isabel (Isabel Healthcare 2011) 1s contoh lain dari
dukungan keputusan yang mengkhususkan diri dalam membantu dalam diagnosis kondisi yang
tidak biasa. Hal ini memungkinkan diagnosa untuk keluar dari protokol pengambilan data EHR
normal untuk menambahkan informasi yang bekerja melawan database pengetahuan yang
canggih. Spesialisasi lain juga memiliki kebutuhan khusus, seperti kalkulator untuk stadium
penyakit ginjal atau kanker tertentu. Pemahaman yang lebih baik tentang persyaratan unik ini
akan memungkinkan organisasi untuk mencari produk atau meningkatkan produk untuk
memenuhi kebutuhan khusus ini. Analisis kebutuhan informasi ad hoc dapat dilakukan dengan
membuat serangkaian pengamatan atau dengan mengembangkan skenario use case dengan