Center of Excellent Rumah Sakit

November 16, 2011 1 comment

Beberapa waktu yang lalu, saya, dokter Anton, dan Mbak Nana dari farmasi berbincang ringan disela-sela waktu kerja. Sebenarnya saat itu saya ingin berdiskusi tentang rencana kedatangan mahasiswa MMF UGM ke RSA, karena kebetulan saya harus membantu assistensi presentasi yang berhubungan dengan sistem informasi farmasi yang ‘sedang’ dikembangkan oleh tim IT.

Meskipun diskusi relatif ringan dan tidak fokus, tapi ada topik menarik terkait dengan manajemen rumah sakit. Dokter Anton (saya lupa sumbernya dari mana), mengangkat isu terbentuknya Center of Excelent (CoE) bagi rumah sakit. Lumayan menarik karena bagi saya sebagai salah satu pengembang SIMRS, tujuan dari semua pengembangan SIMRS adalah terbentuknya layanan yang baik di rumah sakit bagi customer, pegawai, manajemen dan semua yang berkepentingan dengan SIMRS.

Center of Excelent adalah pusat pengembangan dan studi yang terdiri dari semua disiplin ilmu yang terkait dengan rumah sakit, baik medis maupun non medis untuk mengkaji wacana dan inovasi yang bisa diterapkan oleh manajemen. Sebagaimana induk organisasinya, CoE bertujuan untuk menjaga reputasi institusi dengan melakukan inovasi responsif untuk memajukan rumah sakit, membangun pelayanan yang paripurna bagi customer sebagai bentuk pengabdian pada masyarakat, dan tidak ketinggalan, untuk meningkatkan kesejahteraan pegawai. Read more…

Categories: SIMRS

PACS, Personal Notes

April 7, 2010 3 comments

Tadi sore saya berkesempatan mengikuti kuliah tamu tentang PACS, picture archiving communication system di UGM. PACS sendiri adalah sistem untuk management imaging, dengan empat penggunaan dasar: hard copy replacement, remote access, electronic image integration platform dan radiology workflow management. Berikut ini beberapa catatan kecil setelah mengikuti kuliah, yang mayoritas diisi dengan jualan salah satu produk dari Fujifilm Medical System, yakni Synapse.

Pertama, sistem imaging kesehatan di indonesia ternyata sudah jauh ketinggalan. Penggunaan teknologi film untuk dunia kesehatan sudah digunakan sejak tahun 1930an. Kalau dihitung-hitung, teknologi ini sudah berumur 70 tahun, dan sampai sekarang masih digunakan di mayoritas instalasi radiologi di indonesia.

Kedua, investasi. PACS hanya satu dari beberapa potongan puzzle yang harus disatukan. Potongan yang lain, seperti hospital information system, apalagi yang mendukung standard data kesehatan, masih minim. Selain itu, masih ada peralatan kesehatan (biasa disebut modality) yang harus mendukung DICOM (DICOM compliance) yang juga membutuhkan investasi yang besar. Mayoritas peralatan kesehatan di indonesia, terutama rumah sakit yang ada di daerah, belum memiliki. Implementasi PACS mau tidak mau harus siap dengan investasi yang tidak sedikit.

Ketiga, infrastruktur teknologi informasi. Ini juga satu potongan puzzle yang lain. Impementasi PACS membutuhkan setidaknya storage server, web server, DICOM server, database server dan beberapa infrastruktur lainnya. Pertanyaannya, ada berapa rumah sakit di indonesia yang sudah siap dengan infrastruktur tersebut? Ini belum dihitung interkoneksi antar rumah sakit dalam rangka integrasi, yang sebenarnya justru menjadi tujuan dasar dari penggunaan PACS dan DICOM standard.

Keempat, isu standard dan integrasi. Untuk mengakses resource dari DICOM dan PACS modalities, dibutuhkan unique ID untuk setiap pasien. Indonesia belum memiliki standard nomer rekam medis pasien (atau saya tidak tahu ya?). untuk penggunaan satu rumah sakit, PACS masih memungkinkan, tapi untuk integrasi dengan unit kesehatan yang lain, masih perlu pengembangan lebih lanjut. PACS juga membutuhkan sistem informasi yang HL7 compliance untuk komunikasi data.

Cepat atau lambat, standard ini akan digunakan di indonesia. Proses adaptasi dari sistem imaging analog menggunakan film ke  sistem digital butuh investasi yang tidak sedikit. Tidak hanya terkait masalah finansial, Mr. Ong Swee Hong juga mengatakan, butuh adaptasi dan perubahan perilaku untuk implementasi sistem.

Mengawali Pengembangan SIMRS

March 25, 2010 4 comments

Selama kurang lebih lima belas bulan terakhir ini saya melakukan maintenance dan pengembangan sistem informasi rumah sakit berbasis open source yang dikembangkan dari Rumah Sakit Cipto Mangunkusumo, RSCM Jakarta. Awalnya, saya sempat shock melihat struktur database yang dalam ukuran saya, luar biasa kompleks. Ada kurang lebih 250 table yang saling terkait satu dengan yang lain. Termasuk didalamnya adalah table-table yang mengadopsi standard data kesehatan yang digunakan organisasi kesehatan international, seperti UMLS.

Proses bisnis di rumah sakit termasuk proses bisnis yang kompleks dan rumit, meskipun banyak proses bisnis yang mirip antara satu dengan yang lain. Misalnya, proses bisnis antar unit outpatient, inpatient, supporting unit dan sebagainya. Hanya saja, jumlah unit yang banyak, dengan layanan dan proses yang unik biasanya menjebak pengembang sehingga terjadi double development module. Padahal beberapa garis dan benang merah bisa disatukan agar pengembangan lebih cepat dan tidak tumpang tindih.

Beberapa hal berikut ini saya kutip dari pengalaman selama pengembangan dan maintenance SIMRS di RSUD Gunungsitoli Nias, RSUD Nagan Raya dan RSUD Cut Nyak Dhien Meulaboh.

Pertama, identifikasi unit layanan. Unit layanan ini bisa berupa unit layanan rawat jalan seperti poliklinik dan Unit Gawat Darurat, unit layanan instalasi rawat inap, unit instalasi farmasi, unit logistik obat dan bahan medis, unit manajemen dan sebagainya. Termasuk dalam unit layanan ini adalah layanan penerimaan pasien atau pendaftaran sebagai pintu masuk pasien. Dari unit layanan inilah, hal-hal lain bisa diidentifikasi, seperti layanan administrasi, layanan pemeriksaan, tindakan dan sebagainya.

Kedua, identifikasi proses bisnis. Dari semua unit yang sudah teridentifikasi, semua memiliki proses bisnis, baik proses independent yang tidak terhubung dengan unit lain dan proses yang terintegrasi dengan proses bisnis unit layanan yang lain. Unit layanan klinik gigi misalnya, memiliki proses bisnis independent, seperti kunjungan pasien, pemeriksaan pasien, identifikasi diagnosa dan prosedure dan sebagainya. Selain proses independent, ada proses yang terintegrasi dengan unit layanan pendaftaran, seperti data pasien yang diinput oleh unit pendaftaran, pemberian obat yang terintegrasi dengan unit layanan farmasi, dan penagihan yang terintegrasi dengan kasir dan sebagainya.

Ketiga, identifikasi user dan group. Semua proses bisnis yang disebutkan diatas harus tercatat, sampai sedetail-detailnya, termasuk siapa pelaku dan user. Setiap user harus terkelompokkan dalam sebuah group. Dari group inilah, akses akan diberikan. Misalnya, perawat-perawat yang bekerja di bangsal bedah, dikelompokkan dalam group dengan nama perawat bedah. Perawat yang bekerja di rekam medis dikelompokkan dalam group dengan nama staff rekam medis dan seterusnya.

Keempat, identifikasi akses. Akses diberikan kepada group, sehingga semua anggota group akan memiliki akses yang sama. Ada dua jenis akses yang diberikan, yakni akses unit layanan dan akses modul. Akses unit layanan diberikan untuk melakukan proses bisnis pada unit yang bersangkutan. Misalnya, group perawat poli gigi memiliki akses pada unit layanan poli gigi, tetapi tidak memiliki akses pada unit layanan poli bedah, demikian juga sebaliknya. Akses modul diberikan sesuai dengan proses bisnis pada unit layanan yang bersangkutan. Misalnya, modul untuk pendaftaran pasien hanya bisa diakses oleh group pendaftaran dan tidak bisa diakses oleh group kasir. Akses diagnosa pasien hanya diberikan oleh group dokter dan tidak bisa diakses oleh group perawat dan seterusnya.

Kelima, pengelompokan proses bisnis yang sejenis. Banyaknya proses bisnis di rumah sakit, berakibat pada jumlah modul yang harus dibuat karena setiap unit layanan memiliki proses bisnis yang unik. Namun dari semua unit layanan yang ada, banyak kemiripan proses yang bisa disatukan dalam satu modul. Misalnya, proses bisnis pada poli anak, poli gigi, poli bedah hampir sama, yakni pencatatan kunjungan, pencatatan diagnosa, pencatatan tindakan, pencatatan resep dan pencatatan pelaku (dokter). Proses bisnis di instalasi rawat inap juga hampir sama, yakni pencatatan kunjungan pasien, pengaturan bed, visite dokter, pengaturan diet dan lain-lain.

Keenam, identifikasi dan perancangan modul. Dari proses-proses bisnis yang teridentifikasi pada point kelima, maka akan teridentifikasi modul-modul yang dibutuhkan. Lakukan perancangan modul yang fleksibel, agar mudah dikembangkan tanpa melakukan harus menyentuh level coding. Bila perlu, perancangan modul bisa mengakomodasi dynamic form sebagaimana software ERP, yang bisa diatur jenisnya tanpa harus menyentuh level coding. Ini penting mengingat semirip apapun proses bisnis yang ada di unit-unit terkait, tetap memiliki unsure-unsur yang unik.

Langkah-langkah diatas, hanya sedikit dari yang pernah saya lakukan dalam perancangan SIMRS berdasarkan apa yang pernah saya alami di lapangan. Pada tulisan-tulisan yang akan datang, saya akan mencoba mengulas beberapa hal yang berkaitan dengan pengembangan SIMRS, seperti perancangan role akses, manajemen kontrol user dan hal-hal lain yang terkait, termasuk modul-modul yang terkait dengan akuntansi dan keuangan.

Categories: SIMRS Tags: ,

CODEIGNITER, CAKEPHP DAN YII MENURUT SAYA

July 11, 2009 8 comments

Selama beberapa hari ini saya masih merasa impressif dengan CakePHP, meskipun sebelumnya lebih banyak menggunakan CodeIgniter. Aneh, ketika banyak orang lebih senang dengan CodeIgniter, saya justru terkesan dengan pola pengembangan menggunakan CakePHP, dengan aturan main yang sangat ketat. Jauh berbeda dengan CodeIgniter yang longgar aturannya, karena CakePHP lebih murni MVC. Pada CodeIgniter, apapun bisa dilakukan di model, view maupun controller. Bahkan, saya pernah membuat library abal-abal yang ada SQLnya. Meskipun mudah, tapi saya merasa kurang nyaman dengan kelonggaran yang diberikan CodeIgniter. Bahkan, query builder (active record) CodeIgniter, bisa dieksekusi pada controller. Dengan pengembangan seperti ini, jumlah baris kode controller menjadi sangat banyak. Ujung-ujungnya, membingungkan maintenance. Belum lagi ketika bicara standard pengembangan. Wah, untuk pengembangan yang tidak kecil jangan menggunakan CodeIgniter lah sebaiknya. Pergantian programmer, selalu diikuti dengan pergantian style coding. Begitu terjadi pergantian programmer sampai sepuluh kali, hampir dipastikan programmer terakhir bakalan mabok melakukan maintenance code yang nggak karuan stylenya.
Kasus seperti inilah yang bisa diminimalisir oleh CakePHP. Perhatikan baris code berikut:

class CategoriesController extends AppController {
	function add() {
		if ( !empty ( $this->data ) ) {
			$this->Category->create();
			if ($this->Category->save($this->data)) {
				$this->Session->setFlash(__('The Category has been saved', true));
				$this->redirect(array('action'=>'index'));
			} else {
				$this->Session->setFlash(__('The Category could not be saved. Please, try again.', true));
			}
		}
	}
}

Penamaan controller dalam CakePHP sudah ada aturannya. Ini memiliki benang merah dengan penamaan model. penamaan fungsi, memiliki benang merah dengan nama view. Semua jelas aturannya, dan harus sesuai dengan convention agar bisa bekerja.
Sekarang perhatikan baris

$this->Category->save($this->data);

Baris inilah yang membuat saya sangat terkesan dengan CakePHP. ORM benar-benar membantu melakukan operasi yang berhubungan dengan database. Semua relasi dipetakan, dan tinggal dicomot untuk digunakan. Bahkan, validasi form bisa dilakukan dengan sangat sederhana, hanya mendefinisikan array di model, dan semua sudah bekerja. What do we expect more?
Bagaimana dengan Yii? Saya mencobanya hari ini, dan begitu melihat bagaimana code dibangun dengan Yii, saya langsung pesimis. Meskipun hasil test performance luar biasa, mengungguli CakePHP dan CodeIgniter, tapi style code yang ditawarkan tidak saya sukai. Selain itu, berdasarkan pengalaman, performance aplikasi lebih banyak dipengaruhi oleh database query dari pada rendering halaman PHP.
Perhatikan contoh code controller berikut untuk membuat hello world:

class SiteController extends CController
{
	public function actionIndex()
	{
		echo 'Hello World';
	}
}

Hehehe, ini adalah baris code pertama yang saya lihat di Yii, dan langsung membuat saya pesimis untuk menggunakannya. CakePHP tidak akan mengizinkan hal serupa terjadi. Output hanya bisa digenerate lewat view, dan controller murni berisi business logic. Sebagian programmer cenderung lebih menyukai model coding seperti ini di CodeIgniter maupun Yii, karena bebas dan leluasa melakukan coding. Boleh dan sah-sah saja. Tapi untuk pengembangan skala kecil.
Bagaimana dengan pengembangan skala menengah sampai besar? Hal yang harus diingat dalam pengembangan skala menengah dan besar adalah konsistensi pengembangan jangka panjang dan maintenance yang membutuhkan code convention (aturan code) yang baku. Dalam hal ini, CakePHP lebih menjanjikan, karena memang convention dalam CakePHP jauh lebih ketat. Aturan penamaan class, fungsi, file naming, form handling, dan sebagainya sudah baku. Bahkan, penempatan file pendukung seperti file JavaScript, CSS, image, external resource, component, library, template, layout dan sebagainya sudah ditentukan. Aturan-aturan seperti ini akan sangat membantu untuk pengembangan dan maintenance jangka panjang, karena programmer, dengan style apapun, dipaksa mengikuti aturan main yang sudah ditentukan oleh framework. Standard inilah yang juga harus diikuti oleh programmer-programmer yang baru bergabung.
Sampai saat ini, selain ORM dan auto generate code , convention yang ditawarkan oleh CakePHP benar-benar membuat saya nyaman untuk memulai pengembangan project baru. Untuk ke depannya, saya sudah tidak perlu lagi cuap-cuap jika ada programmer baru, tinggal menyuruhnya mempelajari CakePHP, dan saya bisa tidur dengan nyaman

BELAJAR CAKEPHP: HELLO WORLD (FIRST BEHAVIOR)

July 8, 2009 1 comment

Perkenalan dengan Bake pada CakePHP yang fantastis kemarin, berlanjut pada pada project kecil untuk memahami behavior pada framework ini. Untuk lebih mudahnya, saya menyebutnya project ‘Friend.’ Tujuannya sederhana, bisa melakukan operasi CRUD pada table independent (tidak memiliki relasi dengan table yang lain).
Controller, memiliki aturan penamaan file dengan namacontroller_controller.php yang diletakkan dibawah directory /root/my_cake/controllers.
Berikut ini isi file /root/my_cake/controllers/friends_controller.php yang saya buat:


View, memiliki aturan penamaan file dengan extensi .ctp. Untuk controller diatas, yang tidak didefinisikan viewnya, secara default akan menampilkan view sesuai dengan nama fungsi (dalam hal ini index) dibawah direktori ‘namacontroller’ yang dalam project ini bernama ‘friends’ dibawah directory /root/my_cake/views.
Berikut ini isi file view yang saya buat (/root/my_cake/views/friends/index.ctp):

Hello World…

Hasilnya adalah sebagai berikut (diakses dari url http://localhost/my_cake/friends):
Read more…

MoU

July 8, 2009 Leave a comment

Barusan membaca postingan di bawah ini, jadi nggak tahu mau komentar apa. Meskipun sudah terjadi tahun 2006, tapi baru sekarang saya baca salinannya. Ada yang komen, ini MoU apa pemerasan yah?
Oh, bangsaku

http://priyadi.net/archives/2006/12/22/rangkuman-dan-analisis-mou-siluman-antara-pemerintah-indonesia-dan-microsoft/

Entahlah…
Entahlah…
Entahlah…

Categories: Uncategorized

WAKTU UBUNTU TIDAK SAMA DENGAN BIOS

July 8, 2009 1 comment

Santai, buka file

/etc/default/rcs

terus, set disable UTC menjad

UTC=no

terus direstart kompinya. Bisa juga diganti pake perintah

hwclock --hctosys

gara-gara ini server nggak pernah bener waktunya setiap kali restart

Categories: Teknologi Informasi Tags: , , ,