Hmm… awal blog yang saya tulis hari minggu karena sembarang iseng apalagi ngasal hehehe, Ya, karena kebetulan lagi nyari inspirasi mau ngapain dengan laptop yang nganggur di depan saya, sambil ditemani hp yang dicolokin sebagai modem internet. Hmmm akhirnya terlintas juga ide, sebenarnya ide ini juga dah lama terpikir, tapi belum sempat direalisasikan. Ok… mengenai sistem informasi rumah sakit. Ini hal yang memang setiap hari saya geluti, sebagai analis, programmer, dan juga implementator sistem rumah sakit.. hehe ribet ya, emang hehehe kebanyakan yang musti ditangani. Berawal dari awal tahun 2004, saya direkrut sebagai seorang programmer yang diminta untuk menyiapkan sistem informasi rumah sakit untuk suatu perusahaan yang sampai sekarang exist di bisnis health care. hmmm awal saya dikenalkan dengan rumah sakit tidak terbayang akan mendapatkan masalah yang menurut saya seperti nightmare (hehehe bahasanya sedikit pesimis nih), tapi setelah itu saya sadar ternyata sistem informasi rumah sakit memberikan saya kesempatan untuk mengolah kreatifitas otak sekaligus juga tantangan yang memang selama ini saya cari sebagai seorang praktisi it. Banyak hal yang belum bisa saya prediksi (dengan status saya yang masih pemula saat itu – hmmm baru tamat 3 tahun dari kuliah di kampus). Tapi karena adanya dorongan dari atasan, yah saya terus tancap gas. Walaupun terkadang rasanya menyentuh tembok kapas yang makin di tekan semakin amblas, exactly… ndak ada batasnya. Hmmm setelah berjalan +- 4 tahun, saya makin sadar apa yang dibutuhkan suatu rumah sakit terhadap sistem informasi. Pada hakikatnya suatu rumah sakit memerlukan kepraktisan dalam pengolahan data dan informasi yang masuk. Kepraktisan yang dimaksud dapat dipilah menjadi : kesiapan management dalam merespon kebutuhan market(pasien) dan bagaimana cara respon tersebut diimplementasikan dalam pelayanan ke pihak pasien. Dan… jreng.. jreng.. Tool yang digunakan dalam mewujudkan hal ini adalah SISTEM INFORMASI. Oleh karena itu, hal yang menjadi pilar utama sebagai landasan pemikiran dalam analisa sistem informasi rumah sakit adalah bagaimana pengolahan data dan informasi dilakukan secara efektif dan efisien dalam meningkatkan daya jual suatu rumah sakit(yah sekarang pembangunan rumah sakit baru lagi mekar-mekarnya seperti kerupuk yang dicelupin ke dalam minyak panas), tapi jangan lupa.. hakikatnya rumah sakit dibangun adalah untuk merawat orang sakit, namanya juga rumah sakit. Ok.. sekarang kita turun lagi ke level yang lebih dalam, yup bagaimana cara kita mengimplementasikan landasan pemikiran di atas ? ok, saya lanjutkan lain waktu ya… oh ya, tulisan ini saya susun atas dasar pengalaman pribadi, bila ada masukan welcome aja…
Yup, balik lagi setelah setahun blog ini mati suri 
hmmm kita akan lanjut dengan hal yang sedikit tekhnis, tapi tdk utk sebagian orang yang sudah biasa, mungkin ini sudah seperti makan nasi yg dilakoni 3 x sehari ya, buat rekan2 se-profesi yang juga bergelut di bidang sistem informasi rumah sakit pasti sudah biasa menghadapi permasalahan, baik itu tantangan untuk membuat sistem yang bisa mencakup semua kebutuhan rumah sakit, tantangan untuk memenuhi tenggat waktu development module sistem dari management rumah sakit atau bahkan complain dari user yang keberatan dengan antar muka sistem yang menurut mereka “kok ribet amat sih ???” Hehehe saya berharap hanya saya yang menghadapi permasalahan seperti tersebut di atas Ok, kembali ke hal tekhnis yang saya sebutkan sebelumnya, untuk membangun suatu sistem rumah sakit kita butuh tool, dari pemilihan engine database yang powerful, bahasa pemrograman yang mendukung (wajib sudah mendukung oop, khususnya utk pemrograman web akan lebih baik mendukung mvc), design database yang tepat guna – tidak kedodoran dan juga tidak terlalu sempit(hihi kaya’ milih baju), dan yang terakhir tapi ini sering kurang diperhatikan yaitu design antar muka aplikasi yang user friendly – “pokoknya ndak ribet” itu bahasanya user. Untuk menjadikan keempat hal di atas menghasilkan output yang sesuai tentu tidak mudah. Saya punya satu rumus dan hanya satu kata untuk menjelaskan rumus tersebut yaitu “KETEKUNAN”. Yup, karena bukan masalah bagaimana kita menyelesaikan sistem dengan tekhnik pemrograman yang canggih, atau bagaimana kita bisa menghabiskan biaya mahal utk membeli database engine yang powerful, keberhasilan ternyata juga membutuhkan suatu hal jauh di luar yang bisa digambarkan oleh hal tekhnis tersebut. Bisa disimpulkan, untuk sukses kita butuh kemampuan tekhnis dan hmmm non tekhnis (begitu saya menyebutnya). Kembali lagi ke masalah tekhnis (karena kalo bahas maslh non tekhnis nanti jatuhnya jadi curhat hahahaha), bagi rekan-rekan yang senasib (yang saat ini sedang mendevelop ataupun me-maintain sistem informasi rumah sakit) kita akan mulai dari point :
1. Design struktur database
Apakah rekan2 pernah mengalami masalah design database yang mengalami kesulitan pada saat sistem rumah sakit makin berkembang ? Yup, memang dibutuhkan kejelian yang lebih dalam hal yang satu ini, pada prinsipnya suatu sistem akan tumbuh dan berkembang sesuai dengan bisnis yang berjalan, jadi sudah pasti kita memerlukan suatu bentuk design database yang dapat dengan mudah diperluas sesuai kebutuhan. Hmm ada satu hal yang perlu dipertimbangkan dalam design database yaitu konsep relational.
Pada dasarnya konsep relational database dibuat untuk memungkinkan suatu database dapat menyimpan data dengan struktur yang lebih efisien, tidak menyimpan informasi yang sama berkali kali karena tentunya hal ini akan membuat ukuran database membengkak, yah maka kita mengenal apa itu istilah “join table” dalam database. Dalam konsep relational kita juga mengenal level-level relational yang dapat kita terapkan, pada prinsipnya semakin tinggi level yang digunakan maka juga akan melibatkan semakin banyak table dalam menghasilkan suatu output data yang kita inginkan. Pertanyaannya adalah berapa level maksimal yang sebaiknya kita gunakan ? Hmm menjawab pertanyaan ini sebenarnya gampang2 susah. Ada kontradiksi antara prinsip relational database dengan sumberdaya yang diperlukan untuk menghasilkan data yang diinginkan dari suatu bentuk relasional database. Saya ingat ada satu ungkapan : “mau aman maka siap-siap untuk tidak nyaman”. Secara efisiensi memang ada baiknya suatu relational database dibuat sedetail mungkin yang artinya level yang diterapkan juga semakin tinggi. Tapi dari sisi efektifitas hmmm nanti dulu, karena dengan semakin detail relational yang diterapkan maka bisa dipastikan akan semakin banyak table yang terlibat dalam proses retrieving data, dan selanjutnya bisa dipastikan juga bahwa resource yang dibutuhkan untuk itu tidaklah sedikit apalagi table yang terkait memiliki ratusan ribu bahkan jutaan record wahhh siap2 deh didemo sama servernya Terus gimana dong ? 
hehe Ada beberapa hal yang bisa kita terapkan sebagai solusi untuk mengatasi masalah ini. Hmm prinsipnya adalah keseimbangan dan perlu diingat bahwa tidak ada tekhnik yang sempurna 100%. Sebagai solusi pertama kita bisa menentukan maksimal level relational yang akan diterapkan, saya punya angka bagus : 3. Yup, menurut saya level 3 cukup fair untuk dijadikan patokan. Selebihnya maka kita dapat membuat field di table detail diatas level 3 yang dapat di relationalkan langsung ke table detail level 2 atau 1. Hal ini tentu akan menghabiskan lebih banyak kapasitas untuk menyimpan field2 tambahan tersebut, tetapi percayalah performance yang didapat sangat pantas hehehe Hal ini bisa dibuktikan dengan menggunakan join ke table yang memiliki record ratusan ribu atau bila perlu jutaan dan… Rasakan bedanya, semakin banyak record pada table akan semakin terasa selisih waktunya. Ok, terus solusi selanjutnya apa ya ? Ok, ini terkait dengan rancangan module pada sistem rumah sakit yang akan dibangun. Biasanya kita mengenal istilah module frontoffice dan backoffice. Bisa kita petakan dalam sistem rumah sakit, module frontoffice mencakup semua module yang sebagian besar digunakan user untuk menginput data yang nantinya akan bermuara pada catatan medis(hasil pemeriksaan lab/radiologi, resep obat farmasi dll) dan billing transaksi pasien. Sedangkan untuk module backoffice biasanya mencakup module selain frontoffice hehehe ya iyalah wong dibedakan cuma 2 nah untuk module backoffice ini lebih ke pengolahan data transaksi yang dihasilkan oleh module frontoffice, mencakup module persediaan inventory dan juga keuangan/akunting. Nah, bisa dibayangkan begitu banyak data transaksi yang perlu disimpan dan juga proses pengolahan data yang perlu difasilitasi oleh sistem untuk memenuhi kebutuhan user. Bila kita menggunakan hanya satu jalur data saja, artinya rancangan relational database yang kita gunakan semuanya mengakses table yang sama untuk kebutuhan module frontoffice dan backoffice, woww pastilah kiamat akan segera datang hehehe. Untuk itu perlu keputusan bijaksana untuk memecah relational database berdasarkan struktur module sistem yang akan dibangun. Misalnya untuk kebutuhan module backoffice dibuatkan table buffer yang merupakan summary dari data transaksi module frontoffice, setidaknya banyak sekali level relational yang dapat kita potong, dan tentu saja issue locking table database dapat diminimalisasi. Kurang lebih ini yang bisa saya jabarkan untuk point pertama. Kita lanjut ke point berikut…
2. Database engine yang digunakan.
Hmm utk database engine yang canggih sudah tersedia fitur indexing, salah satu fitur favorit saya untuk mendongkrak performance sistem, apalagi utk kapasitas file database yang sudah besar, fitur ini sangat membantu. Hal ini masih terkait dengan point 1, karena kita perlu pengetahuan yang cukup untuk menyesuaikan kebutuhan rancangan struktur database dengan fitur dari database engine yang kita pilih. Kita akan bahas dulu mengenai jenis database engine yang ada sampai saat ini :
1. File server-based database
Database jenis file server-based mengandalkan konsep file sharing. Salah satu contoh database jenis ini adalah Microsoft Access (berbayar), salah satu produk Microsoft yang cukup populer, kalau versi gratis saya belum tahu nama produknya Cara kerjanya cukup sederhana, hanya dengan menyimpan file database di salah satu komputer (biasanya komputer yang dianggap layak menjadi server ) dan selanjutnya file tersebut disetting untuk sharing(dapat diakses) ke semua komputer yang menggunakan aplikasi yang mengakses file database tersebut… dan kemudian… selesai, lho kok ? iya memang sampai di situ saja tidak pake lama dan tidak pake susah hehe. Tapi perlu kita ketahui, bahwa di balik kemudahan yang ditawarkan, ternyata ada beberapa hal yang perlu kita perhatikan dalam mengaplikasikan jenis database ini; salah satunya adalah berkaitan dengan performa, terutama untuk aplikasi yang membutuhkan akses concurrent (akses yang dilakukan bersamaan oleh beberapa user dalam satu waktu) dan aplikasi dengan tingkat pertumbuhan data yang cepat (transaksi yang banyak). Dalam beberapa kasus di lapangan, performa aplikasi langsung drop/turun pada saat lebih dari 3 user melakukan akses secara bersamaan pada aplikasi. Memang perlu juga diperhatikan akses apa yang dilakukan oleh si user, apakah hanya sekedar view data atau proses manipulasi data (insert – update – delete). Pada prinsipnya bila aplikasi yang dibangun adalah aplikasi dengan tingkat akses concurrent yang rendah serta tingkat pertumbuhan data tidak cepat maka database engine jenis ini cukup ideal untuk diaplikasikan. Hmm dengan kata lain perlu pertimbangan yang matang bila ingin mengaplikasikan database engine jenis file server-based untuk aplikasi enterprise.
2. Client server-based database
Jenis database ini relatif lebih rumit dari sisi maintenance dibandingkan dengan jenis database file server-based. Contoh dari produk database engine jenis ini adalah :
Berbayar : Oracle, Microsoft SQL Server, Sybase
Gratisan : MySQL, PostgreSQL, FireBird
Beberapa hal (yang saya tahu) yang membedakannya dengan jenis database engine file server-based adalah :
- Client server-based biasanya membutuhkan setting yang lebih spesifik supaya dapat bekerja dengan maksimal : contohnya setting user dengan privilege yang dapat dibedakan sesuai dengan kebutuhan; setting table engine; dll.
- Membutuhkan spesifikasi server yang relatif lebih tinggi untuk mendapatkan performa maksimal.
Database jenis ini cocok digunakan untuk aplikasi skala menengah ke atas / enterprise. Issue akses concurrent dan juga pertumbuhan data relatif tidak menjadi kendala dalam hal ini, sepanjang pengembang aplikasi menerapkan konsep perancangan database yang sesuai dengan kebutuhan.
Secara pribadi saya menyarankan supaya digunakan database engine jenis client server-base dalam membangun aplikasi rumah sakit. Sederhana saja, coba bayangkan kalau kita membangun aplikasi rumah sakit total solution : module frontoffice sampai dengan backoffice. Berapa banyak user yang menggunakan aplikasi itu dalam satu waktu ? Tentu saja semakin besar rumah sakit maka semakin banyak pula user yang akan mengakses aplikasi. Berapa banyak data yang harus disimpan dalam satu hari ? Tentu saja semakin banyak transaksi yang diinput maka semakin banyak pula data yang harus disimpan. Dari yang pernah saya alami, untuk rumah sakit dengan jumlah pasien rawat jalan dalam satu hari rata-rata 500 pasien maka dalam kurun waktu satu tahun tidak kurang dari 2 GB data harus disimpan ke dalam database, dan data tersebut di luar data gambar/image (radiologi). Kemudian berapa jumlah akses concurrent nya ? 50 user, yup dalam satu waktu bersamaan kurang lebih 50 user akan mengakses aplikasi, bisa dibayangkan kalau kita menggunakan database engine jenis file server-based ?
Berikutnya saya akan mengulas satu persatu module dalam suatu sistem rumah sakit. Dikarenakan page ini sudah cukup panjang maka akan saya lanjutkan ke page yang baru : http://wp.me/ps2Sj-3
