Yang termasuk dalam module frontoffice :

Module Poliklinik

Management Ruang Poli
Pendaftaran Pasien Umum
Pendaftaran Pasien Perusahaan
Transaksi Tindakan
Transaksi Konsultasi
Transaksi Obat/Alkes Charge
Transaksi Obat/Alkes NonCharge
Pasien Rujuk ke Poli
Pasien Rujuk ke Laboratorium
Pasien Rujuk ke Radiologi
Pasien Rujuk ke RehabMedis
Pasien Rujuk resep farmasi (Paten dan Racikan)
Pasien Rujuk ke Rawat Inap
Pasien Rujuk ke Ruang Operasi
Posting Billing Per-Poli

Module Rawat Inap

Pendaftaran Pasien Umum
Pendaftaran Pasien Perusahaan
Transaksi Tindakan
Transaksi Konsultasi
Transaksi Obat/Alkes Charge
Transaksi Obat/Alkes NonCharge
Pasien Rujuk ke Poli
Pasien Rujuk ke Laboratorium
Pasien Rujuk ke Radiologi
Pasien Rujuk ke RehabMedis
Pasien Rujuk resep farmasi (Paten dan Racikan)
Pasien Rujuk ke Ruang Operasi
Mutasi Bed
Posting Billing Semua Unit Pelayanan Medis

Module Laboratorium

Transaksi Lab
Posting Billing Pasien
Input hasil pemeriksaan dan validasi nilai rujukan pemeriksaan
Print Out Hasil Pemeriksaan
Management Bank Darah

Module Radiologi

Transaksi Radiologi
Posting Billing Pasien
Input hasil pemeriksaan
Print Out Hasil Pemeriksaan

Module POS /Penjualan Farmasi

Opening / Closing Shift dan Laporannya
Resep OnLine
Penjualan Obat Resep
Penjualan Obat Bebas

Module Kasir

Opening / Closing Shift
Migrasi status pasien umum -> perusahaan dan sebaliknya, atau ganti perusahaan
Pelunasan, Deposit, Pembatalan, Cicilan.
Konsolidasi dengan Module Akunting
Konfirmasi transaksi outstanding
Print Out Detail Billing Farmasi, Lab, Rad, Poli, dan departemen penunjang medis lainnya.
Print Out Rekap Billing : Rawat Jalan, Rawat Inap dan MCU
Blocking transaksi selama kasir melakukan verifikasi billing.
Revisi Billing

Module MCU

Setting Paket MCU
Migrasi data peserta MCU(perusahaan) ke sistem.
Auto Transfer Paket MCU ke Departemen Pelayanan Medis
Penginputan hasil pemeriksaan MCU
Laporan hasil pemeriksaan MCU

Module Kamar Operasi

Pendaftaran kamar operasi
Transaksi Jasa dokter operator
Transaksi Jasa dokter anastesi
Transaksi Jasa dokter Pendamping
Transaksi penyewaan alat kesehatan dokter / rumah sakit.
Transaksi pemakaian obat dan alkes (Charge)
Transaksi pemakaian obat dan alkes (NonCharge)
Posting Billing

Yang termasuk dalam module backoffice :

Module Administrator :

Setting Master Tarif Administrasi
Setting Master dan Tarif Tindakan Poli
Setting Master dan Tarif Konsultasi / Visit
Setting Master Dokter
Setting Master Group User
Setting Master User
Setting Master dan Tarif Paket
Setting Master Poli
Setting Master dan Tarif Laboratorium
Setting Master dan Tarif Radiologi
Setting Master dan Tarif Perusahaan Kerjasama
Setting Master dan Tarif Promosi Umum
Setting Master Ruangan
Setting Master Bed
Setting Master dan Tarif Kelas Perawatan
Setting Share Dokter
Setting Master COA
Setting Master Laporan Keuangan
Setting Group Shift
Setting Master Tarif Operasi
Setting Master dan Tarif Rehab Medis

Module Inventory

Master Inventory
Master Supplier
Master Satuan
Konversi Satuan
Master Gudang
Opening Stock
Stock Opname
Purchase Request
Request Order
Package Item
Purchase Order
Delivery Order
Good Received
Good Disposal
Purchase Return
Management Inventory Konsinyasi
Management Inventory per-Gudang
Management Purchase Order (outstanding)
Management Request Order (outstanding)
Verifikasi Good Received untuk Payment Voucher

Module Gizi

Master Menu
Kategori Diet
Permintaan Menu Pasien
Penyiapan Menu Pasien
Delivery Menu Pasien

Module Fixed Asset

Master Fixed Asset
Rekapitulasi biaya dan penyusutan bulanan
Auto posting jurnal penyusutan

Module Akunting

Verifikasi Billing
Pendapatan Harian / General Cashier Income
AR
AP Supplier
Verifikasi honor dokter
AP Hondok
Bank Payment
Bank Received
Cash Payment
Cash Received
Petty Cash (Kas Bon)
Auto Jurnal Pendapatan Harian
Jurnal Memorial
Jurnal InHouse Patient
CutOff COGS bulanan
Rekonsiliasi Bank
Financial Statement
Monthly Closing(Kurs)
Monthly Closing(Jurnal)
Yearly Closing(Jurnal)

Module EMR

Master Rekam Medis
Intefacing SharpSonic -> RIS (PACS)
Intefacing SharpSonic -> LIS (Sysmex)
Catatan klinis umum
Pohon keluarga (Dengan riwayat rekam medis masing-masing anggota keluarga)
Catatan perawatan rawat jalan, rawat inap
Input Diagnosa
Vital Sign
Kontradiksi obat

Cukup banyak bukan ? Itulah sebabnya butuh waktu tahunan dalam mengembangkan satu sistem informasi rumah sakit yang benar-benar siap pakai

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