Pasca Implementasi SIMRS GOS

Aku tak menyangka tulisanku tentang SIMRS GOS mendapatkan respon yang lumayan bagus dari para pembaca, khususnya mereka yang saat ini sedang/sudah mengembangkan aplikasi tersebut. Beberapa dari mereka ada yang bertanya lewat email dan ada juga via DM instagram. Tapi mohon maaf, tidak semua dibalas, apalagi di bulan Januari ini, aku (kami) tengah sedang mengimplementasikan aplikasi gratis dari Kemenkes tersebut.

Baca : Tentang SIMRS GOS

Sudah satu bulan SIMRS GOS digunakan di rumah sakit ini. Kami sepakat menggunakan aplikasi ini per 1 Januari 2018. Jadilah malam tahun baru, kami stand by di rumah sakit untuk melakukan migrasi data dari aplikasi lama. Aku tidak termasuk, biarkan para bapak-bapak yang melakukan itu semua. Setelah migrasi selesai, mereka melakukan sweeping ke pengguna, khususnya yang saat itu berada di Instalasi Gawat Darurat, instalasi yang buka 24 jam dan menjadi pengguna pertama dari aplikasi ini. Sweeping dilanjutkan ke ruangan-ruangan yang akan melakukan tindakan dan memasukkannya ke dalam sistem.

Sekitar pukul 08.00 WIB, aku sampai di rumah sakit. Bukan hanya sebatas solidaritas, tapi juga ikut bekerja. Aku bersama satu orang temanku, menuju Depo Farmasi untuk melakukan pengaturan printer. Dari tiga depo yang ada, satu sudah dikerjakan temanku, dua diantaranya belum. 

Mengapa harus dilakukan pengaturan printer? Karena printer yang digunakan bukanlah printer tinta, yang apabila dokumen jenisnya PDF, tinggal klik Print, cetak, selesai. Printer yang digunakan, khususnya yang ada di Depo Farmasi, ada dua jenis, satu printer dotmatrix dan satu lagi printer label. Kami harus melakukan pengaturan printer agar hasil cetakan bisa sesuai dengan ukuran kertas. Dan ternyata, pengaturan printer ini membutuhkan waktu yang cukup lama, selain jumlah komputer dan printer yang memang lumayan banyak, aku sendiri kurang berpengalaman dalam hal ini. Tapi pada akhirnya, semua terselesaikan pada hari itu juga, dan siap digunakan pada tanggal 2 Januari, saat kehidupan rumah sakit sudah kembali normal.

Contoh hasil cetakan yang tidak sesuai

Pagi harinya, seluruh karyawan, khususnya pengguna aplikasi SIMRS GOS, seakan mendapat "kado tahun baru" dengan hadirnya aplikasi ini. 

***

Bagaimana pasca implementasi SIMRS GOS? 

Seperti yang sudah kami prediksikan sebelumnya, akan terjadi chaos. Banyak kekacauan yang terjadi dan jenisnya pun bermacam-macam.

#1. Sumber Daya Manusia

SIMRS GOS ini dipakai oleh pengguna yang berada di Pendaftaran, Poli Rawat Jalan, Ruang Rawat Inap, dan Layanan Penunjang. Sebelum adanya aplikasi ini, kami sudah menggunakan aplikasi berbasis dekstop. Mereka (para pengguna aplikasi) sudah menggunakan aplikasi tersebut selama bertahun-tahun. Ketika SIMRS GOS ini hadir menggantikan, mereka seakan memberontak. "Kok jadi seperti ini?"

Proses input menjadi lama karena mereka belum terbiasa dengan tampilan aplikasi yang baru. Bahkan beberapa ada yang double entry (input dua kali).

Pendaftaran rawat jalan menjadi terhambat. Pasien sudah hadir di poli, ternyata dokumen rekam mediknya belum sampai. Dokumen sudah ada, ternyata data pasien belum masuk ke sistem. Hal itu bisa terjadi karena untuk menjaga pelayanan tetap stabil, sebagian pekerjaan dilakukan dengan cara manual.

Para pengguna aplikasi ini membutuhkan adaptasi ulang dengan sistem yang baru. Tidak serta merta mereka bisa menggunakan aplikasi dengan cepat dan sempurna.

#2. Perubahan Alur Kerja

Dengan adanya SIMRS GOS ini, rumah sakit berharap bisa lebih menertibkan kinerja karyawan. Sebagai contoh begini, saat pasien berobat di poli rawat jalan, perawat akan mencatat data medis maupun tindakan yang diberikan secara manual terlebih dahulu. Keesokan harinya, saat pasien belum datang, mereka akan memasukkan data pasien kemarin ke dalam sistem. 

Akan tetapi, setelah diganti dengan SIMRS GOS, mereka dituntut untuk memasukkan data pada hari itu juga. Data pasien kemarin tidak dimunculkan sistem. 

Perubahan alur kerja tersebut membutuhkan kerja keras. Dan lagi-lagi, mereka seaakan memberontak. Ibaratnya; pakai aplikasi itu aja belum terbiasa, kok udah disuruh realtime! 

Dan itu tidak hanya terjadi  di satu bagian saja. Hampir semua bagian mengeluhkan hal yang sama. "Dulu di sistem lama, kami bisa begini... begini... Di sistem baru gimana? Masak tidak bisa?"

Pada akhirnya, kami dari tim PDE harus memodifikasi ulang SIMRS GOS ini. Tentunya tidak serta merta "Cringg" langsung jadi, kami butuh waktu. Sebenarnya berat karena aplikasi ini sudah diatur sedemikian rupa, tapi ternyata masih belum sesuai dengan kondisi pengguna.

#3. Migrasi Data 
Sehubungan dengan sistem lama dibuat oleh pihak ketiga, maka kami dari PDE kurang mengetahui secara detail mengenai alur sistem yang berjalan selama ini. Kami hanya mengetahui secara umum. Alhasil, saat migrasi data dilakukan dan setelah sistem baru digunakan, ada laporan dari pengguna tentang kelengkapan data yang tidak diakomodir oleh sistem baru. Misalnya daftar tindakan di poli maupun bangsal kurang lengkap. Ruangan yang seharusnya dilengkapi dengan extrabed, ternyata tidak ada. Dan sebagainya, dan sebagainya.

Adapula laporan dari farmasi mengenai obat yang tidak bisa di-entry karena datanya tidak ada atau kalaupun ada datanya tapi stoknya kosong (padahal di sistem lama ada). Setelah ditelusuri ternyata ada kesalahan saat migrasi data. Perbedaan struktur tabel di database ternyata mempengaruhi perpindahan data.

Akan tetapi, berkat kerja keras dan kesabaran dari semua pihak, semuanya dapat diatasi dengan baik.

#4. Perangkat Lunak dan Perangkat Keras
Dari sekian poin, hal inilah yang paling dikhawatirkan semua pihak. Kekacauan terjadi karena ketidaksiapan dari aplikasi itu sendiri dan perangkat keras yang mendukung berjalannya aplikasi tersebut.

Hari pertama kekacauan terjadi karena ada data yang tidak terinput dan ada data yang double input. Okelah, wajar, pengguna belum terbiasa.

Hari kedua, ketiga, sistem mulai berjalan lambat. Kami mengira karna data yang masuk sudah terlalu banyak dan besar sehingga memberatkan server dalam bekerja. Tapi belum ada seminggu lho, masak iya selemah ini sistemnya?!

Hari-hari berikut, kelambatan sistem mulai menjadi-jadi. Koneksi sering kali terputus. Hal itu menyebabkan ketidaksempurnaan sistem dalam menyimpan data transaksi. Data menjadi kacau, tidak sinkron sana sini.

Unable to connect

Para pengguna mulai teriak, merasa lelah dengan keadaan. Kami dari tim PDE gelisah dan tertekan, sembari mencari tahu sumber masalahnya. Hingga di titik dimana aplikasi benar-benar tidak bisa digunakan. Server kami rusak dan tak bisa melakukan booting (proses menghidupkan komputer). Berjam-jam berkutat dengan server itu, 'rusak dimananya?'

Selama masa itu, para pengguna aplikasi kembali menggunakan proses manual, seluruh tindakan yang dilakukan dicatat, label resep obat ditulis tangan, dan sebagainya. Sampai akhirnya server bisa kembali nyala. Aktivitas kembali normal. Normal dalam artian sistem bisa digunakan tapi masih lambat koneksinya.

Kami terus mengupayakan optimalisasi dari sistem tersebut. Dimulai dari setting database, yang justru malah menambah masalah baru. Memisahkan aplikasi dan database di server yang berbeda, dan sebagainya.

Setelah dicari-cari penyebabnya, rasanya beban database terlalu berat, apalagi jika ada query yang dieksekusi terlalu lama. Ada satu yang meng-query panjang, maka proses query yang lain harus menunggu query panjang itu selesai diproses. Wajarlah jika sistem berjalan lambat. Kami pun mulai mencari query mana saja yang bisa disederhanakan.

Selain itu, kami menemukan sebuah tool yang membantu kami dalam mengidentifikasi query. Namanya MySQL Workbench. Aku sendiri kurang paham cara kerjanya bagaimana. Tapi yang jelas, dengan tool ini, kita bisa melihat pengguna aktif yang sedang mengakses ke database. Kegiatan yang dilakukan si pengguna pun bisa terlihat. Misal pengguna A sedang melakukan update. Pengguna B sedang melakukan proses select. Apabila proses yang dilakukan si B (misalnya) tidak selesai-selesai dan ada laporan dari pengguna aplikasi kalau sistem melambat, maka bisa dipastikan query si B ini bermasalah. Kami pun harus segera bertindak memperbaiki aktivitas si B ini. Huft, kenapa tak sedari awal menginstall MySQL-Workbench ?! Selama ini kami hanya menebak-nebak masalahnya dimana? Siapa si pembuat masalah?

Setelah sebulan berjalan, kondisi mulai membaik. Kami terus melakukan perbaikan sana sini untuk memperkecil laporan masalah. Selain itu, kami juga terus berusaha menyempurnakan aplikasi agar bisa mengakomodir seluruh kebutuhan pengguna. 

***

Saat mengimplementasikan sebuah sistem baru, dibutuhkan kerjasama dari seluruh pihak, bukan hanya dari pengembang, tapi juga dari pengguna. Semuanya harus berjuang dan bersabar.

Bayangkan saja jika para pengguna melakukan mogok menggunakan aplikasi baru atau pengembang tidak mengusahakan perbaikan sistem. Apa yang akan terjadi? Sistem itu akan mangkrak. Berhenti. Selesai. Tidak ada perubahan. Itulah mengapa dukungan manajemen sangat sangat sangat dibutuhkan sekali. Saat semuanya lelah, manajemen lah yang bisa menguatkan semua pihak. Mereka akan menyediakan solusi dari permasalahan yang terjadi.

Beruntungnya kami karena memperoleh dukungan manajemen tersebut. Tetapi ada satu kesalahan yang tidak dapat kami pungkiri; kurangnya persiapan. Demi mengejar tanggal cantik 1 Januari, waktu untuk sosialisasi dan pelatihan pengguna sangat lah kurang. Selain itu kami tidak bisa memprediksikan kondisi server akan bagaimana (karena selama ini baik-baik saja). Waktu trial aplikasi, kami hanya menggunakan data dummy yang sedikit, sementara setelah diimplementasi, dalam satu hari ribuan data bisa masuk. Oleh karena itu, seharusnya dilakukan perencanaan yang matang dan persiapan (software maupun hardware) yang lebih baik lagi. 

***

Jujur ini menjadi pengalaman yang luar biasa buatku. Meski dua minggu pertama harus pulang lebih telat dari biasanya, tubuh bahkan sempat tumbang, tapi kerja keras ini tak pernah sia-sia. Niatkan semuanya buat ibadah, pasti terasa menyenangkan 😇