Bayangkan pukul 08.15, poli penuh pasien, lalu layar SIMRS mendadak blank. Antrean memanjang, perawat bertanya "Berkasnya di mana?", dan semua mata menoleh ke unit rekam medis. Kamu mau jawab apa? Di sinilah menyusun contingency plan unit rekam medis jadi penyelamat. Artikel ini untuk kamu, mahasiswa D3 RMIK semester 3 yang sebentar lagi memegang data pasien sungguhan. Kita bahas komponen, peran tim, dan simulasi kasus supaya kamu siap menjaga layanan tetap jalan.
๐ Seri Keamanan dan Perlindungan Data. Ini artikel penutup. Setelah membaca, kamu mampu menjelaskan dan menentukan komponen contingency plan agar layanan RME tetap berjalan saat sistem gangguan, data hilang, atau terjadi insiden keamanan (Sub-CPMK T5, CPMK 4).
1. Mengapa Menyusun Contingency Plan Unit Rekam Medis Itu Wajib?
Analogi gampangnya begini: pesawat punya prosedur darurat bukan karena sering jatuh, tapi karena kalau jatuh akibatnya fatal. Rekam medis elektronik (RME) sama. Datanya menentukan keputusan klinis, jadi saat sistem mati, pelayanan tidak boleh ikut mati. Pada artikel sebelumnya kamu sudah belajar dasar backup, recovery, dan prosedur darurat. Sekarang kita rangkai semuanya menjadi satu dokumen kerja yang utuh.
๐ DEFINISI KUNCI
Contingency plan = dokumen tertulis berisi langkah, penanggung jawab, dan sumber daya untuk menjaga layanan tetap berjalan (business continuity) serta memulihkan sistem dan data ketika terjadi gangguan.
๐ก Tips Rencana yang tidak pernah dibaca sama dengan tidak punya rencana. Tulis dengan kalimat pendek, pakai kata kerja, dan cetak satu lembar ringkasnya untuk ditempel di meja pendaftaran.
2. Komponen Utama Contingency Plan Unit Rekam Medis
Contingency plan sederhana tidak perlu tebal. Yang penting lengkap. Berikut enam komponen yang harus ada, dari yang paling dasar sampai yang sering terlupa.
Komponen
Isi Utama
Contoh di Unit RM
1. Ruang lingkup & risiko
Skenario gangguan dan dampaknya
Server mati, ransomware, listrik padam
2. Prosedur darurat
Langkah saat gangguan terjadi
Beralih ke formulir manual
3. Backup & recovery
Jadwal salinan dan cara pemulihan
Backup harian, uji restore bulanan
4. Peran & kontak
Siapa memutuskan dan siapa mengeksekusi
Daftar nomor telepon tim IT
5. Komunikasi
Cara memberi tahu unit lain dan pasien
Pengumuman lewat pengeras suara
6. Pasca-insiden
Input ulang data, evaluasi, perbaikan
Rekonsiliasi formulir manual ke RME
⚡ Insight Penting Backup tanpa uji restore itu seperti membawa ban serep yang belum pernah dipompa. Kamu baru tahu bocor saat benar-benar butuh. Jadwalkan uji pemulihan, bukan hanya jadwal backup.
๐ ANALISIS: Tiga Jenis Gangguan, Tiga Respons Berbeda
๐ฅ️
Sistem down Fokus: kecepatan beralih ke prosedur manual.
๐พ
Data hilang Fokus: restore dari backup terakhir yang valid.
๐จ
Insiden keamanan Fokus: isolasi sistem dulu, pulihkan kemudian.
3. Peran Tim dalam Contingency Plan Unit Rekam Medis
Saat panik, orang cenderung semuanya mengerjakan hal yang sama, atau malah tidak ada yang bergerak. Karena itu pembagian peran harus jelas sebelum gangguan terjadi. Versi sederhana untuk rumah sakit atau klinik:
Koordinator (kepala unit RM): menyatakan status darurat, memutuskan kapan beralih ke prosedur manual dan kapan kembali normal.
Petugas pendaftaran: memakai formulir manual dan menomori setiap berkas agar mudah diinput ulang.
Petugas filing: menyiapkan berkas fisik atau cetakan ringkasan pasien terjadwal.
Tim IT: diagnosis penyebab, restore data, dan amankan log kejadian.
Petugas input data: memasukkan ulang data manual setelah sistem pulih, lalu memverifikasi.
๐ฅ Fakta Menarik Sektor kesehatan termasuk target favorit pelaku ransomware karena data pasien sangat berharga dan layanan sulit berhenti. Di Indonesia, pengamanan data pasien juga punya dasar hukum, antara lain Permenkes No. 24 Tahun 2022 tentang Rekam Medis dan UU Perlindungan Data Pribadi (UU No. 27 Tahun 2022).
4. Langkah Menyusun Contingency Plan Unit Rekam Medis
Praktikkan lima langkah ini di tugas kelompokmu. Kamu bisa memakai unit rekam medis puskesmas atau klinik kampus sebagai studi kasus.
1
Identifikasi risiko. Daftar semua gangguan yang mungkin: mati listrik, jaringan putus, server rusak, virus, salah hapus. Beri skor kemungkinan dan dampak 1 sampai 5.
2
Tentukan target pemulihan. Tanyakan: berapa lama sistem boleh mati (RTO) dan berapa data terakhir yang boleh hilang (RPO)? Contoh: RTO 2 jam, RPO 24 jam.
3
Tulis prosedur per skenario. Satu skenario, satu halaman, langkah berurutan, dan penanggung jawab jelas.
4
Siapkan sumber daya. Formulir manual cadangan, laptop dan flash disk terenkripsi untuk backup, nomor kontak, serta alat tulis.
5
Latih dan evaluasi. Adakan simulasi minimal dua kali setahun, catat waktu respons, lalu perbarui dokumen.
Supaya lebih konkret, ini kerangka dokumen yang bisa kamu salin dan sesuaikan:
contingency-plan-rm.yaml
skenario: Server SIMRS mati
status_darurat: dinyatakan oleh Koordinator RM
target:
RTO: 2 jam
RPO: 24 jam
langkah:
- 1: Umumkan downtime ke semua unit
- 2: Pendaftaran pakai formulir manual (beri nomor urut)
- 3: Filing keluarkan ringkasan pasien terjadwal
- 4: Tim IT cek penyebab dan restore backup terakhir
- 5: Setelah pulih, input ulang data dan verifikasi
- 6: Catat kejadian dan evaluasi dalam 24 jam
kontak:
koordinator_RM: 08xx-xxxx-xxxx
tim_IT: 08xx-xxxx-xxxx
⚠️ Perhatian Formulir manual berisi data pasien juga harus diamankan. Jangan tinggalkan di meja terbuka, dan jangan foto lewat ponsel pribadi. Setelah diinput ulang, simpan atau musnahkan sesuai kebijakan retensi.
5. Simulasi Kasus: Contingency Plan Unit Rekam Medis Saat Server Mati
๐งช KASUS: Klinik Sehat Sentosa, Senin 08.15
Server RME klinik mati akibat listrik padam mendadak. Ada 35 pasien menunggu dan layanan harus lanjut.
Respons tim: Koordinator menyatakan status darurat pukul 08.20. Pendaftaran beralih ke formulir manual bernomor, filing menyiapkan ringkasan pasien kontrol, IT memeriksa UPS dan menyalakan genset. Server pulih 09.40, restore dari backup semalam selesai 10.15, lalu petugas input mengejar data 2 jam terakhir.
Evaluasi: Layanan tidak berhenti. Catatan perbaikan: UPS ternyata hanya bertahan 10 menit, jadi masuk daftar perbaikan prioritas. Nah, itulah gunanya simulasi.
๐ฏ Latihan mandiri: Buat skenario serupa untuk ransomware. Bedanya, apa yang harus kamu lakukan lebih dulu, mematikan jaringan atau langsung restore? (Petunjuk: lihat tabel komponen di atas.)
Kesimpulan
Menyusun contingency plan unit rekam medis intinya enam komponen: risiko, prosedur darurat, backup dan recovery, peran, komunikasi, serta pasca-insiden. Tim yang tahu tugasnya, formulir cadangan yang siap, dan simulasi rutin membuat layanan RME tetap berjalan saat sistem gangguan, data hilang, atau insiden keamanan terjadi. Itulah bekal Sub-CPMK T5 yang sudah kamu pelajari.
Menurutmu, risiko mana yang paling mungkin terjadi di tempat praktikmu? Tulis di kolom komentar ya!
ARTIKEL 15 DARI 16 · KEAMANAN DAN PERLINDUNGAN DATA
Kalau Sistem Down atau Data Hilang, Apa yang Terjadi?
Dasar-dasar contingency plan: backup, recovery, dan prosedur darurat untuk menjaga layanan RME tetap berjalan.
#ContingencyPlan#Backup#Recovery#ProsedurDarurat
⏱️
8 menit
Estimasi baca
๐ฏ
Pemula–Menengah
Level
๐
2026
Tahun
Senin pagi, pukul 07.45. Antrean pendaftaran sudah mengular, dokter meminta riwayat alergi pasien, lalu layar SIMRS berhenti merespons. Server mati, dan tidak ada yang tahu kapan menyala lagi. Apa yang kamu lakukan? Kalau jawabanmu "panik dulu", artikel ini memang untukmu. Di sini kamu akan mengenal contingency plan rekam medis elektronik: rencana tertulis agar layanan tetap berjalan ketika sistem gagal, data hilang, atau terjadi insiden keamanan. Artikel ini bagian dari seri Keamanan dan Perlindungan Data, dan kita bahas dengan santai tapi tetap akademis.
๐ Target belajarmu (Sub-CPMK T5)
Setelah membaca, kamu mampu menjelaskan komponen contingency plan dan menentukan komponen yang tepat untuk menjaga pelayanan RME saat terjadi gangguan sistem, kehilangan data, atau insiden keamanan.
Apa Itu Contingency Plan Rekam Medis Elektronik?
Analogikan dengan perjalanan naik motor. Kamu membawa ban serep, tahu lokasi bengkel terdekat, dan punya nomor teman yang bisa menjemput. Kamu tidak berharap ban bocor, tapi kamu tahu langkahnya kalau itu terjadi. Begitu juga di fasilitas pelayanan kesehatan: sistem pasti bisa gagal, jadi yang dinilai adalah kesiapan kita.
๐ DEFINISI KUNCI
Contingency Plan RME = Backup + Recovery + Prosedur Darurat
Rencana kesinambungan yang menjawab tiga hal: data kita aman di mana, bagaimana memulihkannya, dan siapa mengerjakan apa selama sistem mati.
Menurut Permenkes Nomor 24 Tahun 2022 tentang Rekam Medis, fasilitas pelayanan kesehatan wajib menjaga keamanan dan kerahasiaan data RME. Keamanan di sini bukan hanya mencegah kebocoran, tetapi juga memastikan data tetap tersedia saat dibutuhkan. Ketersediaan data itulah yang dijaga oleh rencana kontingensi.
Gangguan yang perlu diantisipasi umumnya terbagi tiga. Pertama, gangguan sistem: server mati, jaringan putus, listrik padam, atau aplikasi error setelah pembaruan. Kedua, kehilangan data: file terhapus tidak sengaja, hard disk rusak, atau database korup. Ketiga, insiden keamanan: ransomware yang mengenkripsi data, akses tanpa izin, atau perangkat hilang. Penyebabnya berbeda, tetapi pertanyaannya sama: bagaimana pelayanan pasien tetap berjalan, dan seberapa cepat data kembali? Ketiga skenario itu perlu kamu kenali karena langkah penanganannya tidak selalu sama.
๐ฅ Fakta Menarik
Banyak organisasi merasa aman karena "sudah rutin backup", padahal belum pernah mencoba memulihkan salinannya. Backup yang tidak pernah diuji restore hanyalah harapan, bukan jaminan.
Tiga Pilar Contingency Plan Rekam Medis Elektronik
Setiap rencana kontingensi bertumpu pada tiga pilar yang saling melengkapi. Tabel berikut membantumu membedakannya, termasuk pertanyaan kunci untuk menentukan komponen mana yang paling mendesak di unit kerjamu.
Komponen
Fungsi
Contoh di unit RM
Pertanyaan kunci
Backup
Menyalin data RME ke tempat lain
Salinan harian database + salinan mingguan di luar gedung
Kapan salinan terakhir dibuat?
Recovery
Memulihkan sistem dan data dari salinan
Restore database ke server cadangan
Berapa lama sistem pulih?
Prosedur darurat
Menjaga layanan tetap jalan saat sistem mati
Formulir downtime manual, tim siaga, jalur komunikasi
Pasien tetap terlayani tanpa data hilang?
Dua istilah wajib kamu kenal. RPO (Recovery Point Objective) adalah batas data yang masih boleh hilang, misalnya maksimal 1 jam transaksi. RTO (Recovery Time Objective) adalah batas waktu sistem boleh mati sebelum layanan terganggu berat, misalnya 2 jam. Dua angka ini menentukan seberapa sering backup dilakukan dan seberapa cepat tim harus bergerak.
⚡ Insight Penting
RPO menentukan frekuensi backup, RTO menentukan kecepatan recovery. Poliklinik kecil dan IGD rumah sakit jelas butuh angka yang berbeda. Jangan menyalin angka dari tempat lain tanpa menilai risiko di unitmu.
Contoh perhitungan sederhana: sebuah klinik mencatat sekitar 200 kunjungan per hari. Bila backup hanya dilakukan sekali sehari pukul 23.00 dan server rusak pukul 14.00, maka transaksi selama 15 jam, kira-kira 120 kunjungan, berpotensi hilang. Apakah itu bisa diterima? Kalau tidak, jadwalkan backup tiap jam atau gunakan replikasi data ke server kedua. Inilah cara kamu menentukan komponen contingency plan berdasarkan kebutuhan, bukan perasaan.
๐ Analisis: dua unit, dua nasib
❌ Tanpa contingency plan
Server mati, petugas bingung. Pasien menunggu, catatan ditulis di kertas bekas, dan data akhirnya tidak pernah dimasukkan ulang.
✅ Dengan contingency plan
Tim siaga aktif dalam hitungan menit, formulir downtime keluar dari map darurat, dan data direkonsiliasi setelah sistem pulih.
Langkah Praktis Backup dan Recovery dalam Contingency Plan Rekam Medis Elektronik
Teori sudah cukup. Berikut lima langkah yang bisa kamu praktikkan, baik di laboratorium kampus maupun saat magang di fasilitas kesehatan.
1
Petakan data kritis dan tetapkan RPO/RTO
Daftar data yang paling dibutuhkan pelayanan: identitas pasien, riwayat alergi, resume medis, dan data resep. Tentukan angka RPO dan RTO bersama pimpinan unit.
2
Terapkan aturan 3-2-1
Simpan 3 salinan data, pada 2 jenis media berbeda, dengan 1 salinan di lokasi terpisah (luar gedung atau cloud terpercaya).
3
Otomatiskan jadwal backup
Jangan mengandalkan ingatan petugas. Gunakan penjadwal tugas agar backup berjalan sendiri, lengkap dengan catatan log.
4
Lindungi salinan backup
Enkripsi file backup dan batasi akses hanya untuk petugas berwenang. Backup yang bocor sama bahayanya dengan database yang bocor.
5
Uji restore secara berkala
Minimal tiap triwulan, pulihkan salinan ke server uji dan cek apakah data bisa dibuka serta lengkap. Catat berapa lama prosesnya untuk dibandingkan dengan RTO.
Contoh skrip sederhana berikut menunjukkan langkah 2 sampai 4 pada server Linux. Sesuaikan nama database, direktori, dan alamat server tujuan dengan lingkunganmu.
๐ป backup_rme.sh
#!/bin/bash
# Backup harian database RME (contoh sederhana)
TGL=$(date +%Y%m%d_%H%M)
DIR=/backup/rme
mkdir -p $DIR
# 1. Dump database lalu kompres
mysqldump -u backup_user -p"$DB_PASS" simrs_db | gzip > $DIR/simrs_$TGL.sql.gz
# 2. Cek integritas file (simpan checksum)
sha256sum $DIR/simrs_$TGL.sql.gz > $DIR/simrs_$TGL.sha256
# 3. Salin ke media kedua (server lain / NAS)
rsync -av $DIR/ backup_user@192.168.1.50:/arsip/rme/
# 4. Hapus salinan lokal yang lebih dari 14 hari
find $DIR -type f -mtime +14 -delete
echo "Backup selesai: $TGL" >> $DIR/log_backup.txt
Perhatikan beberapa hal penting pada skrip tersebut. Baris dump membuat salinan database dalam bentuk terkompres, sedangkan checksum memastikan file tidak rusak saat dipindahkan. Perintah rsync menyalin file ke media kedua, sehingga satu perangkat yang rusak tidak membuat semua salinan ikut hilang. Terakhir, pembersihan otomatis menjaga kapasitas penyimpanan. Dalam praktik, skrip ini dijadwalkan lewat cron dan kata sandi disimpan di variabel lingkungan, bukan ditulis langsung di dalam file.
๐ก Tips
Beri nama file backup dengan tanggal dan jam, lalu simpan satu halaman "buku panduan recovery" berisi urutan langkah restore. Saat sistem mati, tidak ada yang mau menebak-nebak.
Satu kesalahan klasik yang sering terjadi: backup dianggap urusan bagian TI saja. Padahal petugas rekam medis juga berperan, mulai dari menentukan data mana yang kritis, memastikan formulir manual sesuai kebutuhan klinis, sampai memverifikasi kelengkapan data setelah recovery. Bayangkan TI berhasil memulihkan database, tetapi tidak ada yang mengecek apakah data kunjungan terakhir sudah lengkap. Pemulihan teknis berhasil, namun data pelayanan masih bolong. Karena itu, recovery baru dianggap selesai setelah petugas rekam medis menyatakan datanya sah dan dapat dipakai kembali.
Prosedur Darurat: Contingency Plan Rekam Medis Elektronik di Lapangan
Backup dan recovery mengurus datanya. Lalu siapa yang mengurus pasiennya selama sistem pulih? Di sinilah prosedur darurat berperan. Alurnya bisa kamu ringkas menjadi lima tahap:
1) Aktivasi: petugas pertama yang mengetahui gangguan segera melapor ke koordinator, dan koordinator menyatakan status downtime. 2) Komunikasi: beri tahu unit pelayanan, IT, dan pimpinan lewat jalur cadangan seperti grup pesan atau telepon internal. 3) Kerja manual: gunakan formulir downtime cetak yang sudah disiapkan, lengkap dengan nomor urut dan tanda tangan petugas. 4) Pengamanan: kumpulkan formulir di tempat terkunci supaya tetap rahasia. 5) Rekonsiliasi: setelah sistem pulih, input semua formulir, verifikasi, lalu arsipkan.
Selain alur di atas, contingency plan harus menyebutkan siapa yang bertanggung jawab. Minimal ada koordinator downtime, petugas teknis TI untuk recovery, petugas rekam medis untuk pengelolaan formulir manual, dan perwakilan pimpinan untuk keputusan strategis. Setiap nama beserta nomor kontaknya dicantumkan dalam dokumen dan diperbarui secara berkala, karena orang yang bertugas hari ini belum tentu sama dengan bulan depan. Rencana yang hanya tersimpan di server RME tentu tidak berguna saat server itu sendiri yang mati, jadi cetak satu salinannya.
Terakhir, jangan lupa mendokumentasikan setiap kejadian. Catat waktu gangguan dimulai, penyebab yang diduga, langkah yang diambil, waktu pulih, dan data yang perlu dikoreksi. Catatan ini berguna untuk evaluasi, memperbaiki contingency plan, dan menjadi bukti akuntabilitas bila fasilitas kesehatanmu diaudit.
⚠️ Perhatian
Formulir manual berisi data pasien, jadi tetap wajib dijaga kerahasiaannya. Jangan difoto lewat ponsel pribadi dan jangan dibiarkan tergeletak di meja pendaftaran.
๐ก Tips Siaga
Siapkan "map darurat" berisi formulir downtime, daftar kontak, dan buku panduan recovery. Simpan di tempat yang mudah dijangkau, lalu latih seluruh petugas minimal setahun sekali lewat simulasi singkat 15 menit.
Kalau penyebab gangguannya insiden keamanan seperti ransomware, tambahkan satu langkah: isolasi dulu. Putuskan perangkat yang terdampak dari jaringan sebelum memulai restore, agar salinan bersih tidak ikut terinfeksi. Detail penyusunan tim dan simulasi kasus akan kita bahas di artikel berikutnya.
๐
Kesimpulan
Sistem bisa down dan data bisa hilang kapan saja. Yang menentukan dampaknya adalah kesiapanmu. Ingat tiga pilar: backup menjaga salinan data, recovery memulihkan sistem sesuai RPO dan RTO, dan prosedur darurat menjaga pelayanan tetap berjalan. Dengan memahami contingency plan rekam medis elektronik, kamu sudah selangkah lebih dekat menjawab Sub-CPMK T5: menjelaskan dan menentukan komponen rencana kontingensi.
Menurutmu, komponen mana yang paling sering terlupakan di fasilitas kesehatan? Tulis di kolom komentar dan bagikan artikel ini ke temanmu!
Artikel 14 dari 16 · Keamanan dan Perlindungan Data
Menilai dan Memprioritaskan Risiko: Dampak × Kemungkinan Kejadian pada Pelayanan Rekam Medis Elektronik
Semua risiko tidak sama beratnya. Belajar memilah mana yang harus ditangani hari ini, mana yang bisa menunggu.
#RisikoRME#MatriksRisiko#DampakxKemungkinan#RMIK
⏱ 8 mnt
Estimasi baca
๐ Menengah
Level
๐ 2026
Tahun
Bayangkan kamu jaga unit rekam medis, lalu dalam satu pagi ada tiga masalah: kabel server longgar, password pendaftaran ditempel di monitor, dan laporan ada update antivirus yang tertunda. Mana yang kamu urus duluan? Kalau jawabanmu "yang kelihatan paling heboh", kamu butuh penilaian risiko keamanan rekam medis elektronik. Metode ini membantu kamu memilih berdasarkan angka, bukan firasat atau siapa yang paling panik.
Di artikel ke-14 seri Keamanan dan Perlindungan Data ini, kamu akan belajar menghitung skor risiko dari dampak dan kemungkinan kejadian, lalu menyusun prioritasnya. Setelah selesai, kamu mampu mengidentifikasi, menganalisis, dan menentukan prioritas risiko pada pelayanan RME, sesuai Sub-CPMK T4.
Mengapa Penilaian Risiko Keamanan Rekam Medis Elektronik Itu Penting?
Di artikel sebelumnya kamu sudah mengenal sumber ancaman, kerentanan, dan insiden. Sekarang kita naik satu tingkat: risiko muncul ketika ancaman bertemu kerentanan dan menimbulkan kerugian. Sebuah rumah sakit atau puskesmas punya puluhan risiko sekaligus, sementara waktu, tenaga, dan anggarannya terbatas. Jadi kamu harus memilih.
Analogi gampangnya begini: dokter IGD memakai triase. Pasien yang henti napas ditangani sebelum pasien yang luka lecet, walaupun si luka lecet datang lebih dulu. Penilaian risiko adalah triase untuk keamanan sistem. Risiko yang paling berbahaya dan paling mungkin terjadi mendapat penanganan paling awal.
๐ก Tips Mulailah dari proses, bukan dari alat. Telusuri alur pasien: pendaftaran, pemeriksaan, pengkodean, penyimpanan, pelaporan. Di setiap titik tanya, "Apa yang bisa salah di sini?"
Rumus Dasar Penilaian Risiko: Dampak × Kemungkinan Kejadian
Rumusnya sederhana, dan kamu cukup memakai skala 1 sampai 5 untuk keduanya:
๐ RUMUS UTAMA
Skor Risiko = Dampak × Kemungkinan
Dampak (1–5): seberapa parah kerugiannya jika terjadi. Kemungkinan (1–5): seberapa sering atau seberapa mudah kejadian itu terjadi. Skor akhir berkisar 1–25.
Dampak pada layanan RME mencakup keselamatan pasien (data alergi hilang), kerahasiaan (diagnosis bocor), dan kelangsungan layanan (sistem mati berjam-jam). Kemungkinan kamu nilai dari riwayat kejadian, kondisi kontrol yang ada, dan seberapa mudah celahnya dimanfaatkan.
Skala
Dampak
Kemungkinan
1
Tidak signifikan
Hampir tidak pernah (<1x/tahun)
2
Ringan, layanan tetap jalan
Jarang (1x/tahun)
3
Sedang, layanan terganggu
Kadang (beberapa kali/tahun)
4
Berat, data pasien terpapar
Sering (bulanan)
5
Kritis, keselamatan pasien terancam
Hampir pasti (mingguan/harian)
⚡ Insight Penting Skor 25 tidak berarti "paling mendesak" secara otomatis. Dampak 5 dengan kemungkinan 1 (skor 5) sering kalah prioritas dari dampak 4 dengan kemungkinan 5 (skor 20). Karena itu, jangan hanya lihat satu angka.
Langkah Praktis Penilaian Risiko Keamanan Rekam Medis Elektronik di Unit RMIK
Ikuti lima langkah ini. Kamu bisa langsung mencobanya dengan kertas dan spreadsheet.
1
Identifikasi aset dan proses. Catat aset yang kamu lindungi: server RME, data pasien, jaringan, komputer pendaftaran, dan akun petugas.
2
Petakan ancaman dan kerentanan. Untuk tiap aset, tulis ancamannya (ransomware, pencurian kredensial) dan celahnya (tanpa backup, password lemah).
3
Beri skor dampak dan kemungkinan. Pakai tabel skala di atas. Diskusikan bersama rekan, karena penilaian tim lebih objektif daripada penilaian sendirian.
4
Hitung skor dan tentukan level. Kalikan dampak dengan kemungkinan, lalu kelompokkan: 1–5 Rendah, 6–11 Sedang, 12–19 Tinggi, 20–25 Kritis.
5
Urutkan dan tetapkan tindakan. Tangani yang Kritis lebih dulu, tunjuk penanggung jawab, dan tentukan tenggat waktunya.
⚠️ Perhatian Jangan menilai kemungkinan dengan kalimat "kayaknya aman-aman saja". Gunakan data: catatan insiden, log akses, atau laporan petugas. Penilaian tanpa bukti hanya menghasilkan rasa aman palsu.
Kalau kamu ingin mengotomatiskan langkah 4 dan 5, berikut contoh kode Python sederhana. Kamu bisa menyalinnya dengan tombol di bawah.
risiko_rme.py
risiko = [
("Ransomware di server RME", 5, 3),
("Password dibagi antarpetugas", 4, 5),
("Listrik padam tanpa UPS", 4, 4),
("Salah input identitas pasien", 3, 4),
("Laptop pendaftaran hilang", 3, 2),
]
def level(skor):
if skor >= 20: return "Kritis"
if skor >= 12: return "Tinggi"
if skor >= 6: return "Sedang"
return "Rendah"
hasil = [(n, d, k, d * k) for n, d, k in risiko]
hasil.sort(key=lambda x: x[3], reverse=True)
for n, d, k, s in hasil:
print(f"{s:>2} | {level(s):<6} | {n}")
๐ฅ Fakta Menarik Berbagi password sering dianggap sepele karena "biar cepat". Padahal pada skor di atas, kebiasaan itu menempati posisi teratas. Alasannya: dampaknya berat dan terjadi setiap hari, sehingga kemungkinannya hampir pasti.
Matriks Prioritas: Hasil Penilaian Risiko Keamanan RME dalam Satu Tabel
Jalankan kode tadi, dan kamu mendapat daftar prioritas berikut. Ini yang disebut risk register versi mini.
Prioritas
Risiko
D × K
Level
1
Password dibagi antarpetugas
4×5 = 20
Kritis
2
Listrik padam tanpa UPS
4×4 = 16
Tinggi
3
Ransomware di server RME
5×3 = 15
Tinggi
4
Salah input identitas pasien
3×4 = 12
Tinggi
5
Laptop pendaftaran hilang
3×2 = 6
Sedang
๐ Analisis: Kenapa Ransomware Bukan Nomor 1?
Ransomware punya dampak tertinggi (5), tetapi kemungkinannya di unit ini hanya 3 karena server sudah di belakang firewall. Berbagi password punya dampak 4 namun terjadi hampir tiap shift. Hasilnya, risiko "kecil" yang rutin justru lebih mendesak daripada risiko "besar" yang jarang.
Pelajarannya: prioritas ditentukan oleh gabungan dampak dan kemungkinan. Pelajaran kedua: skor 15 tetap tergolong Tinggi, jadi ransomware tidak boleh diabaikan. Lanjutkan ke penyusunan contingency plan di artikel berikutnya.
๐ก Tips Latihan Ambil unit kerjamu (misalnya ruang pendaftaran), temukan 5 risiko, lalu beri skor. Bandingkan hasilmu dengan teman sekelas. Kalau skornya berbeda jauh, diskusikan alasannya. Di situlah kamu belajar menganalisis.
๐ฏ Kesimpulan
Penilaian risiko keamanan rekam medis elektronik membantumu memilih dengan kepala dingin. Ingat tiga hal: risiko lahir dari pertemuan ancaman dan kerentanan, skor risiko dihitung dari dampak × kemungkinan, dan prioritas disusun dari skor tertinggi dengan bukti yang jelas.
Dengan lima langkah tadi, kamu sudah bisa mengidentifikasi, menganalisis, dan menentukan prioritas risiko pada pelayanan RME. Sekarang giliranmu berlatih.
Pertanyaan untukmu: risiko apa di tempat praktikmu yang menurutmu paling sering diabaikan? Tulis di kolom komentar!
saifiahmada.com adalah blog belajar programming Indonesia, membahas lengkap materi bahasa pemrograman: code HTML, CSS, Bootstrap, Desain, PHP, MySQL, coding Java, Query, SQL, dan dunia linux
