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.

Dalam aktifitasnya, CoE harus peka terhadap masalah yang ada. Kepekaan tidak terbatas pada manajemen pelayanan, tapi juga masalah-masalah internal yang secara tidak langsung mempengaruhi pelayanan. masalah-masalah ini dijadikan bahan dan sumber kajian untuk dicarikan solusi strategis yang mungkin diterapkan di lapangan. Dari perspektif ini, CoE adalah pustaka masalah dan solusi strategis implementatif di lapangan. Kajian yang diangkat tidak terbatas pada masalah yang ada di rumah sakit, tapi juga bisa bersumber dari riset dan teori akademis. Strategi rumah sakit lain dalam operasionalnya juga bisa diangkat untuk memperkaya sumber kajian.

Anggota CoE yang terdiri dari multi disiplin ilmu akan mengkaji strategi untuk diterapkan sesuai dengan pendekatan disiplin ilmu masing-masing. Anggota ini bisa terdiri dari disiplin ilmu kedokteran, keperawatan, manajemen, keuangan, IT, farmasi dan sebagainya. Keberagaman disiplin ilmu ini menuntut personal yang terlibat harus terbuka, open mind dan tidak memaksakan pendekatan disiplin ilmu yang dimiliki. Ini bisa menjadi sebuah challenge tersendiri, mengingat setiap disiplin ilmu menghasilkan ego profesi pada praktisinya. Sikap netral dan dan terbuka menjadi syarat penting bagi personal yang terlibat dalam CoE. Selain sifat netral dan terbuka, personal yang terlibat juga harus memiliki kepedulian dan kepekaan terhadap masalah dan tidak memiliki tendensi terhadap profesi yang diwakili, mengingat tujuan dari terbentuknya CoE adalah untuk kepentingan bersama. tendensi profesi ini justru bisa merusak netralitas CoE dalam perjalanannya.

CoE bertanggung jawab secara vertikal dalam bentuk wacana tertulis, berikut rekomendasi stragegis pada direksi. rekomendasi strategis ini mengkaji kemungkinan implementasi di lapangan dengan memperhatikan sumber daya yang mungkin terimbas dan dibutuhkan. Sumber daya tersebut bisa dalam bentuk financial, pelayanan, profesi dan sebagainya. Kajian juga harus menyebutkan system koordinasi, pelatihan, mentoring dan pendampingan apa yang dibutuhkan di lapangan. Tidak terbatas sampai di situ, kajian secara komprehensif juga menyebutkan probabilitas keberhasilan di lapangan dengan memperhatikan resource yang dimiliki. Kajian ini bersifat rekomendasi, dan implementasinya di lapangan akan tergantung pada keputusan direksi dengan memperhatikan secara menyeluruh perbandingan resource yang dibutuhkan dan ketersediaannya di rumah sakit.

Membangun CoE tidak mudah. Challenge terbesar justru memulai dari siapa yang memiliki kualifikasi keanggotaan. Keanggotaan CoE harus terdiri dari open mind people, karena akan dibenturkan dengan multi disiplin ilmu. Anggota CoE dituntut untuk berkomitmen mengkaji dan menyediakan solusi yang evidence base, tidak hanya berdasarkan pertimbangan emosional semata. Eksplorasi data, pengkajian, simulasi implementasi secara terus menerus dan konsisten adalah aktifitas yang akan dihadapi sehari-hari. aktifitas ini pasti akan berbenturan dengan keterbatasan resource yang ada. Karenanya, setiap anggota harus kreatif untuk menyiasati agar keterbatasan resource tersebut bisa tidak menjadi kendala saat implementasi di lapangan.

Benturan lain adalah prioritas dan tanggung jawab profesi masing-masing anggota. Aktifitas di CoE akan menyita sebagian aktifitas dan tanggung jawab profesi. Kompensasi dari semua itu harus dipikirkan agar keduanya bisa berjalan harmonis dan seimbang.

Sebagai penutup, perlu dukungan kultur organisasi agar CoE ini bisa berfungsi efektif sesuai namanya, Center of Excelent. Dukungan pihak manajemen dan semua pihak yang berkepentingan akan menjadi faktor pendukung terwujudnya CoE di rumah sakit. Wa Allah A’lam bi ash showab

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.

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.

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);

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

Hello World…

Lihat, ada proses query

DESCRIBE `friends`

Saya masih belum paham tentang perilaku ini. Apakah setiap controller harus merepresentasikan sebuah table? Jika memang demikian, berarti semakin jelas, siapa mengatur siapa. Untuk project jangka panjang, model pengembangan strict seperti ini menguntungkan, karena pergantian programmer tidak berpengaruh pada stadard pengembangan. Hanya saja, saya masih bingung dengan pengaturan ACLnya. Misalkan sebuah table diakses dari dua macam ACL yang berbeda, satu untuk public dan satu untuk admin, bagaimana pengaturannya? Baiklah, out of this simple project I guess and will be explored later

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

Entahlah…
Entahlah…
Entahlah…

/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

CREATE TABLE `categories` (
	`id` int(10) NOT NULL auto_increment,
	`name` varchar(50) default NULL,
	PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `posts` (
	`id` int(10) NOT NULL auto_increment,
	`title` varchar(100) default NULL,
	`content` text,
	`created` datetime default NULL,
	`updated` datetime default NULL,
	`category_id` int(10) default NULL,
	PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Table ‘posts’ memiliki relasi ke table ‘categories,’ yang direpresentasikan pada ‘category_id’. Nama table harus bentuk plural seperti ‘posts’, ‘categories’. Foreign key harus menggunakan namatable_id, yang mana ‘namatable’ akan merujuk pada nama table dan dan ‘id’ adalah aturan dalam cake. Pada table ‘posts’ berbentuk kolom ‘category_id’.

Dengan model aturan seperti itu, auto generate code sudah menghasilkan model, view dan controller secara otomatis dengan Bake. Saya jadi paham mengapa CakePHP memang ditujukan untuk Rapid Application Development. Dan ternyata pengembangan yang saya lakukan selama ini bukan rapid development, tapi stupid development

Tutorial yang saya gunakan download disini

Catatan:
Saya menggunakan wamp server versi 2.0
Perintah

cake bake all

cake -app C:/wamp/www/caketest/ bake all

cake.bat

@echo.
@echo off

SET app=%0
SET lib=%~dp0

c:\wamp\bin\php\php5.2.8\php.exe -q "%lib%cake.php" -working "%CD%" %*

echo.

Kedua, teknologi itu harusnya little thing works miracle. Apapun teknologinya, selama bisa membuatnya works miracle, that’s fine. Jadi jangan dilihat teknologinya, tapi lihat manfaatnya. Ingat, riset2 kecil dalam pengembangan software kesehatan. Teknologinya sederhana, tapi works miracle. MyFamily Accounting sendiri pun saya pikir memiliki prinsip yang sama. So, kenapa dipermasalahkan tentang teknologi database tadi? Toh tidak melenceng dari disiplin akademik OODB? Justru aneh kalau dilarang karena diajarkan.

Ketiga, teknologi itu menjadi sederhana kalau kita tahu cara kerjanya. Apa sih yang hebat dari teknologi desktop, internet, games, networking, multimedia, user interface, kernel, security berbasis KDE, GNOME, maupun project-project di sourceforge.net itu jika kita tahu teknologinya? biasa saja, tidak ada yang istimewa, sama tidak istimewanya dengan sistem informasi database tadi. jadi apakah teknologi itu nanti akan dilarang juga jika sudah jenuh? That’s a matter right?

So, let’s get down to the earth. Technology is just a technology. look at facebook, it’s not about technology, but how it works miracle