Main-main dengan ChatGPT

Beberapa hari ini, dunia dihebohkan dengan kehadiran model bahasa bernama ChatGPT. ChatGPT “dilatih” untuk bercakap-cakap dalam bahasa manusia. Tanggapan ChatGPT atas pertanyaan dan pernyataan yang disampaikan pengguna manusia terasa sangat natural.

Baru hari ini saya berkesempatan mencoba bercakap-cakap dengan ChatGPT ini. Saya mencoba bercakap-cakap dengan dua bahasa: Inggris dan Indonesia, dan semuanya ditanggapi dengan mulus olehnya.

Awalnya saya mencoba menanyakan pertanyaan-pertanyaan “mudah”, seperti berikut ini:

2006

Hari Senin kemarin ada pesan masuk ke ponsel saya. Isi pesannya begini:

“Slm mlm mas Albert. Maaf mengganggu. Kapan ada waktu memperbaiki program di Klinik saya? Tks”

Pengirimnya adalah seorang dokter, yang sudah lama menggunakan aplikasi yang saya buat. Saya menyanggupi datang ke klinik beliau sore ini tadi.

Saya ingat bahwa aplikasi itu sudah lama sekali saya buat, dan ada sekitar 5 kali beliau atau admin kliniknya menghubungi saya untuk konsultasi saat mereka mengalami kesulitan, entah PCnya atau printernya bermasalah. Bahwa beliau menghubungi saya berarti aplikasi saya masih mereka gunakan.

Ketika tadi saya datang ke klinik beliau, saya takjub melihat bahwa PC dan aplikasi saya di dalamnya masih ada lengkap dengan datanya. Pada aplikasi saya ada penanda tahun buatannya, 2006. PC bersih dan rapi, lengkap dengan sistem operasinya: Windows XP.

Beliau menyampaikan bahwa tiap hari beliau masih mengisikan data pasien ke dalamnya. Sudah ada puluhan ribu data pasien di situ. Hanya ada sedikit kendala: si admin klinik lupa passwordnya. Sambil saya bantu mengatur ulang password si admin, kami berbincang ringan mengenai kemungkinan upgrade aplikasi.

Saya senang mendapati bahwa aplikasi yang sudah lama sekali saya buat, masih terus bermanfaat untuk penggunanya.

Cara Baru Pengembangan SIMPUS?

Sudah beberapa bulan ini saya bersama tim bergelut dengan ritme cepat dalam pengembangan fitur baru dalam SIMPUS (Sistem Informasi Manajemen Puskesmas). Ini bermula dari keputusan kami untuk mulai membuat fitur bridging PCare – sebuah fitur untuk membuat SIMPUS mampu mengirim dan mengambil data dari WebService PCare milik BPJS Kesehatan – sekitar September 2015.

Sedari mula, kami sudah menyadari bahwa ini bukan proses sekali jadi. Mungkin ada penyesuaian di masa datang, baik penyesuaian fitur SIMPUS sendiri maupun penyesuaian WebService PCare (yang mengakibatkan ada penyesuaian di SIMPUS). Dengan kesadaran itu, saya merasa sepertinya baik jika kami “meminta bantuan” teman-teman di puskesmas selaku pengguna langsung SIMPUS (dan juga PCare). Yang terjadi pada akhirnya bukan interaksi searah: “teman-teman puskesmas membantu kami” tapi juga “kami membantu teman-teman puskesmas”.

Saya membuat satu grup kecil di Telegram yang berisi anggota tim inti pengembang SIMPUS dan beberapa teman-teman dari puskesmas (ada yang dokter, perawat, analis lab — yang memiliki kemampuan dan minat lebih di bidang IT). Teman-teman dari puskesmas ini memang sengaja dipilih yang kami rasa bersedia segera memberikan umpan balik kepada kami jika mereka menemukan kendala di SIMPUS, juga mereka yang bersedia “mencoba” update terbaru kami.

Komunikasi di dalam grup kecil ini berlangsung baik. Laporan kendala dan permintaan pengembangan fitur baru (terutama yang terkait dengan fitur bridging PCare) mengalir lancar. Di sisi lain, kami juga berupaya secepatnya memberikan update yang dibutuhkan untuk mengatasi kendala yang dilaporkan. Saat satu bagian fitur dianggap sudah stabil, barulah update untuk bagian tersebut didistribusikan ke puskesmas-puskesmas lain.

Saya bukan ahli konsep pengembangan software, tapi jika digambarkan secara sederhana kira-kira proses yang kami jalankan seperti ini:

Sekilas, sebetulnya model pengembangan software seperti ini tidak berbeda jauh dengan yang sebelumnya kami lakukan. Perbedaannya ada pada kecepatan ritme saling berbalas pesan, berbalas antara laporan kendala dan respon berupa update software. Proses coding juga dituntut lebih cepat, demikian pula proses testing. Perbaikannya mungkin untuk hal-hal kecil, update hanya meliputi perbaikan-perbaikan kecil tersebut, tapi perkembangannya jadi terasa, terlihat.

Model pengembangan seperti ini, jika diniatkan untuk berlangsung dalam jangka panjang, tentu butuh stamina yang memadai; dari sisi kami selaku programmer, tester, dan implementator, juga dari sisi teman-teman puskesmas selaku pengguna dan penyampai umpan balik. Pada akhirnya arah pengembangan software, tidak lagi hanya bergantung pada kami selaku pengembang, tapi banyak pula dipengaruhi dari masukan-masukan dari lapangan. Ini semua dengan harapan, agar SIMPUS semakin mempermudah pekerjaan banyak teman di puskesmas.

Kosa kata terkendali

If we cannot name it, we cannot control it, finance it, research it, teach it or develop public policies…
– Norma Lang, nursing professor –

Pada tulisan sebelumnya, telah disinggung soal interoperabilitas semantik. Interoperabilitas semantik mencoba memastikan bahwa data yang saling dipertukarkan dimaknai secara sama oleh pihak-pihak yang menggunakan data yang sama tersebut.
Berikut adalah kutipan komentar dari seorang dokter:

“If I’m sent an electronic note via email that notes “Allergy to MS”, is that interoperable? Of course MS could mean Morphine Sulfate, Magnesium Sulfate, or even Minestrone Soup.”

MS ternyata bisa dimaknai macam-macam, berarti dalam konteks cerita di atas MS tidak memenuhi syarat interoperabilitas semantik.

Sebuah sistem informasi berfungsi tidak hanya mengumpulkan dan menyimpan data, seperti misalnya keterangan “Allergy to MS” seperti di atas, namun juga mengelompokkannya sesuai keperluan. Agar data dapat dikelompokkan, data harus dapat dimaknai secara jelas terlebih dahulu. Dalam contoh di atas, apa itu “MS” harus jelas.

Seringkali tanpa kita sadari, bahasa yang kita gunakan sehari-hari mengandung banyak kerancuan. Beberapa contohnya:

• Sinonim: beberapa kata yang memiliki makna yang sama. Contohnya: demam dan pireksia.
• Polisemi: satu kata yang bisa memiliki beberapa makna. Contohnya: bisa, yang dapat bermakna “mampu”, dapat pula bermakna “racun”. Ada pula yang berupa singkatan, seperti “MS” di atas.

Dalam komunikasi antar manusia sehari-hari, kerancuan itu teratasi dengan adanya konteks. Namun komputer tak dapat mengenali konteks (baca: dalam tingkatan tertentu bisa tapi dengan usaha luar biasa). Penggunaan kode adalah cara agar komputer dapat memahami bahasa (manusia). Perlu ada daftar kode dengan makna yang jelas. Dalam bahasa Inggris, istilahnya adalah controlled vocabulary. Saya belum tahu apa padanan istilah tersebut dalam bahasa Indonesia. Kosa kata terkendali? Kita gunakan kosa kata terkendali saja ya. Saya terbuka untuk diberi masukan padanan kata yang lebih tepat.

Kosa kata terkendali berisi daftar kata (medis) yang dibatasi penggunaannya untuk keperluan tertentu. Dalam sebuah antarmuka elektronik, kosa kata terkendali muncul dalam daftar yang dapat dipilih oleh pengguna untuk mewakili satu kondisi nyata tertentu. Misalnya ada pasien dalam kondisi demam, maka kosa kata terkendali cukup mencantumkan salah satu istilah saja: demam atau pireksia, agar pengguna dapat memilih satu saja dari daftar kosa kata terkendali yang muncul. Dengan demikian, maka menjadi jelas bahwa ketika pengguna memilih “demam” dari kosa kata terkendali, maka yang dimaksudkan oleh pengguna adalah kondisi demam yang sedang dialami pasien. Tidak akan ada istilah lain dari kosa kata terkendali yang memiliki makna serupa. Kerancuan bahasa sehari-hari terhindarkan.

Karakteristik utama dari kosa kata terkendali:

• Ada satu set daftar kata yang terbatas, yang tidak ambigu, juga akurat.
• Kata-kata yang digunakan ditentukan dengan standar tertentu.
• Jika diperlukan penambahan kata/istilah, ada serangkaian proses tertentu yang harus dilakukan sebelumnya, sehingga biasanya penambahan kata baru tak dapat dilakukan seketika.
• Pengguna harus mengikuti pelatihan sebelum dapat menggunakannya.

Kosa kata terkendali adalah kunci penting untuk terwujudnya interoperabilitas antar sistem informasi kesehatan. Mengapa kosa kata terkendali penting? Kosa kata terkendali dapat digunakan untuk:

• Memberi standar istilah atas satu teks naratif.
• Mewakili hasil pengamatan atau hasil evaluasi.
• Mengkodekan hasil test (misalnya hasil test laboratorium).
• Mengenali dengan pasti berbagai jenis obat.
• Memudahkan pertukaran data secara real time.
• Memudahkan pengolahan dan analisis atas data, mendukung proses pengambilan keputusan.

Ada banyak contoh kosa kata terkendali yang sudah dikembangkan:

• Kosa kata terkendali untuk diagnosis: SNOMED CT, ICD-10, ICD-9-CM, ICPC-2
• Kosa kata terkendali untuk obat: ATC, NDA
• Kosa kata terkendali untuk laboratorium: LOINC

Sumber:
Coming to Terms: Scoping Interoperability for Health Care – Health Level Seven EHR Interoperability Work Group
HL7 E-Learning Course: Introduction to Vocabularies in Healthcare

Sedikit tentang interoperabilitas (dalam sistem informasi kesehatan)

Interoperabilitas adalah kemampuan dua sistem atau lebih untuk saling bertukar informasi, dan menggunakan informasi yang saling dipertukarkan tersebut. Kebutuhan akan interoperabilitas nyata di lingkungan fasilitas kesehatan yang menggunakan lebih dari satu sistem informasi. Sistem informasi rekam medis perlu dapat bertukar data dengan sistem informasi laboratorium, misalnya.

Interoperabilitas memerlukan satu set standar (atau banyak standar) untuk disepakati dan digunakan bersama oleh semua sistem informasi yang terlibat. Standar diperlukan agar data, di bagian manapun dari sistem informasi manapun, memiliki format dan makna yang sama. Dengan format dan makna yang sama, informasi dapat digunakan bersama oleh berbagai pihak yang terlibat dalam satu lingkungan kerja.

EHR Interoperability Work Group mengklasifikasikan interoperabilitas menjadi tiga:
– Interoperabilitas teknis: memastikan bahwa data dapat terkirim pada pihak-pihak yang berkepentingan, terlepas dari terstruktur atau tidaknya data yang dikirimkan tersebut.
– Interoperabilitas semantik: memastikan bahwa data dipahami secara sama oleh pihak-pihak yang berkepentingan, terlepas dari mekanisme pengirimannya.
– Interoperabilitas proses: memastikan bahwa data terkirim pada saat yang tepat, dalam urutan yang tepat, dalam satu kerangka koordinasi kerja antara pihak-pihak yang berkepentingan.
Untuk implementasi yang optimal dalam satu lingkungan kerja, ketiga klasifikasi interoperabilitas tersebut harus terwujud.

Namun ada yang membagi interoperabilitas hanya menjadi dua bagian saja: interoperabilitas sintaksis dan interoperabilitas semantik. Interoperabilitas sintaksis adalah tentang struktur atau format komunikasi data. Contoh standar interoperabilitas sintaksis adalah HL7 v2.x. Interoperabilitas semantik adalah tentang makna dari data yang dikomunikasikan/dipertukarkan, memastikan bahwa data yang dipertukarkan dimaknai secara sama oleh semua pihak/sistem yang saling bertukar data. Contoh standar interoperabilitas semantik adalah SNOMED CT atau LOINC. Tanpa interoperabilitas semantik, data dapat saling dipertukarkan, namun tak ada yang bisa memastikan penerima data akan memaknai data yang dikirimkan secara sama sebagaimana pihak pengirim data memaknainya.

Lalu bagaimana standar dibuat? Ada empat mekanisme yang mungkin dilakukan untuk terbentuknya sebuah standar.
1. Standar “ad hoc”.
Standar ini muncul ketika beberapa kelompok pengembang sistem informasi menyetujui secara informal untuk menggunakan seperangkat format yang sama, di mana kesepakatan tersebut tidak dipublikasikan secara meluas.
2. Standar “de facto”.
Standar ini muncul begitu saja ketika banyak pengguna sistem informasi yang terbiasa atau mengadopsi format yang sama.
3. Standar “de jure”.
Standar ini muncul ketika pemerintah menyusun, menetapkan, dan “memaksakan” implementasi seperangkat standar tertentu.
4. Standar berdasarkan konsensus.
Standar ini muncul dari hasil diskusi terbuka antara banyak pihak.

Sumber:
Coming to Terms: Scoping Interoperability for Health Care – Health Level Seven EHR Interoperability Work Group
HL7 E-Learning Course: Introduction to Healthcare Interoperability

Hubungan antara pasien buta huruf dan sistem informasi

“Yohana Anau!” panggil staf RS bagian farmasi. (Nama pasien, diagnosis, dan obat yang disebutkan adalah fiktif belaka, dimaksudkan sebagai contoh kasus saja.)

Seorang wanita muda yang menggendong anak berjalan mendekati loket farmasi. Ia menyerahkan selembar kartu pasien yang berlumur ingus anaknya kepada staf farmasi. Staf farmasi yang mengenakan sarung tangan karet menerima kartu pasien tersebut, memeriksa nomor rekam medisnya, mengambil obat yang sudah disiapkan, lalu berusaha menjelaskan cara pemakaian obat pada si pasien yang tidak begitu memahami bahasa Indonesia dan juga tak lincah membaca menulis.

“Mama sakit batuk kah?” tanya staf farmasi, sambil memperagakan batuk.
Si pasien mengangguk.
“Obat ini diminum sebutir sehari empat kali,” jelas staf farmasi, sambil menunjukkan empat jari tangan.
“Mengerti?”
Si pasien kembali mengangguk.
“Sekarang cap jempol tangan di sini.” Staf farmasi mengangsurkan selembar kertas bukti tanda terima obat dan bantalan tinta.
Pasien memberikan cap jempolnya di lembar yang disediakan, dan obat diserahterimakan.

==============

Rutinitas semacam itu yang tampak hampir sepanjang jam operasional di ruang farmasi pada sebuah RS kecil di bagian timur Indonesia sana.
Sekilas tampak normal. Namun di balik apa yang tampak itu, ada berbagai kendala yang dihadapi.

Sebagian besar pasien hanya sedikit memahami bahasa Indonesia. Dan sebanyak itu pula pasien yang tidak mampu membaca dan menulis.
Penjelasan mesti diberikan dengan bantuan bahasa isyarat, didukung dengan harapan: semoga informasi yang disampaikan dipahami dengan benar dan dijalankan oleh pasien. Terkadang ada pasien lain yang paham bahasa Indonesia, dan mereka dapat membantu menyampaikan penjelasan petugas medis pada si pasien dalam bahasa lokal.

Tidak jarang dijumpai pasien yang tidak mengonsumsi obat sesuai dengan cara yang telah dijelaskan. Obat yang berwarna-warni itu berakhir di dinding rumah, diperlakukan layaknya pajangan, karena warna-warninya yang dianggap menarik. Tidak jarang pula jatah obat untuk sekian hari dikonsumsi sekaligus, mungkin karena pasien mengira itu bisa membuat ia makin cepat sembuh.

Bukan hal yang langka pula, pasien yang datang mendekat ke loket bukanlah pasien yang memiliki nama yang sebelumnya dipanggil staf farmasi (atau dipanggil staf medis di poliklinik). Pasien yang mendekat itu datang hanya karena agar ia bisa segera menerima obat (yang adalah obat pasien lain) dan segera bisa pulang. Bila staf farmasi tidak jeli memeriksa kartu pasien, obat yang salah dapat diserahterimakan. Resiko ini makin besar untuk terjadi bila pasien kebetulan tidak membawa kartu, atau bahkan membawa kartu milik pasien lain.

Sebagian besar pasien yang datang tidak tahu tanggal lahirnya sendiri.

==============

Bagaimana cara memperkecil kemungkinan kesalahan pemberian obat? Bagaimana cara mengurangi kemungkinan kejadian salah panggil pasien (sekalipun si pasien dengan sengaja datang walau bukan namanya yang dipanggil)? Bagaimana cara mencatat umur pasien yang tidak diketahui jelas tanggal lahirnya?

Ini adalah sekedar beberapa contoh tantangan nyata bagi implementasi teknologi informasi. Bagaimana teknologi informasi mampu mendukung kerja staf RS dalam menghadapi berbagai persoalan non-teknis seperti itu. Sekedar membuat sistem informasi (sistem informasi apapun), yang memiliki kolom isian lengkap dan alur kerja yang detail tentu adalah hal yang benar. Tapi membuat agar sistem informasi dengan kolom isian lengkap dan alur kerja detail itu dapat diisi dengan data nyata dalam kerangka waktu yang masuk akal oleh petugas di lapangan, bagi saya adalah tantangan sebenarnya.

Tidak jarang penyusun kebijakan dan pengembang sistem informasi berbincang panjang dan lebar tentang berbagai aspek teknis dalam teknologi informasi: menggunakan DBMS apa, menggunakan framework apa, mengapa memilih teknologi ini ketimbang itu, seperti apa dataset yang lengkap dan mampu menampung seluruh data yang diminta berbagai stakeholder, dst.

Tapi mungkin adakalanya kita juga perlu berbicara tentang berbagai aspek ‘manusiawi’ dari kebijakan dan sistem informasi yang tengah dibangun: seberapa mampu SDM yang ada menggunakan sistem yang tengah dibuat, seberapa lama waktu yang dibutuhkan untuk mengisi sebuah form, apakah kolom data mandatory (harus terisi) yang ada di dalam form isian itu sungguh adalah data yang tersedia di lapangan, apakah sungguh sistem informasi yang tengah dibangun itu mempercepat kerja petugas lapangan alih-alih memperlambatnya, dst.

Menuliskan tulisan ini sungguh mengingatkan saya pada slogan: information technology for everyone..

Instalasi Ubuntu Server ke mesin dengan UEFI

Secara umum, proses instalasi Ubuntu Server pada mesin dengan UEFI tidak berbeda jauh dengan instalasi Ubuntu Server pada umumnya. Perbedaannya hanya ada pada kebutuhan sebuah partisi EFI boot.

Untuk bisa menambahkan partisi tersebut, pada saat akan memulai instalasi, device sumber installer harus diset agar booting sebagai device EFI.

Catatan: dalam artikel ini digunakan Ubuntu Server 11.10 64 bit dan server IBM Systems x3200 M3.

Berikut ini langkah-langkahnya:

1. Saat booting, ketika muncul opsi F1, F2, atau F12, pilih F1. Lalu pilih “Boot Manager”.

2. Lalu pilih “Add boot option”

3. Lalu pilih device yang digunakan untuk booting (dalam hal ini USB disk).

4. Cari lokasi file boot EFI:

5. Isi label boot option

6. Commit changes

7. Untuk mulai menjalankan installer, dari deretan menu utama pilih “Start Options”.

8. Pilih opsi boot yang tadi telah dibuat.

9. Selanjutnya akan muncul langkah-langkah instalasi seperti biasa. Buat partisi-partisi seperti biasa juga, namun sisakan ruang minimal 16MB untuk membuat partisi boot EFI.

10.  Untuk ruang tersebut, pilih jenis partisi: “EFI boot partition”

11. Lalu lanjutkan langkah instalasi selanjutnya seperti biasa. Ubuntu akan dijalankan secara otomatis tiap kali mesin booting.

Referensi: http://ubuntuforums.org/showthread.php?t=1958383&highlight=uefi

Semoga bermanfaat.

Ide itu gratis..

Sekitar 8 tahun yang lalu, saya dan beberapa teman mempunyai ide untuk membuat sebuah software manajemen parkir. Berbeda dengan software sejenis yang saat itu mulai marak digunakan, terutama di daerah Jateng – DIY, software yang kami buat itu menambahkan beberapa fitur yang dalam pengamatan kami belum digunakan di software sejenis yang lain. Salah satu dari fitur itu adalah karcis parkir dengan barcode, tanpa mencantumkan nomor polisi kendaraan yang diparkir. Karcis parkir yang mencantumkan nomor polisi akan sangat memudahkan orang untuk mencuri kendaraan kita. Karcis parkir itu adalah kunci penentu berhasilnya seorang pengendara mengeluarkan kendaraannya dari lahan parkir. Nomor polisi yang tercantum jelas, memudahkan orang lain (katakanlah pencuri karcis) yang memegang karcis parkir itu untuk menemukan kendaraan kita.

Software itu sudah dirancang dengan baik, dengan mempertimbangkan berbagai skenario yang mungkin muncul, misalnya karcis hilang, petugas gerbang masuk salah ketik nomor polisi, dll. Dalam kondisi terbatas, software itu sudah diujicoba, meski tentunya tidak dalam situasi nyata. Kecepatan proses pemberian karcis di gerbang masuk dan juga penerimaan pembayaran di gerbang keluar, semua sudah diperhitungkan, dan menghasilkan angka tunggu yang layak bagi para pengantre lahan parkir. Kekurangannya cuma satu: sangat sulit menemukan perusahaan pengelola lahan parkir yang bersedia mempercayai kualitas software buatan anak-anak muda dari antah berantah Yogya. Keberanian sudah dikumpulkan untuk akhirnya mencoba menghubungi berbagai perusahaan pengelola lahan parkir dan meminta waktu pihak manajemen untuk melihat presentasi dan demo software kami, namun tak satupun tembus. Beberapa eksemplar proposal juga sudah sempat dikirimkan, tapi tak ada balasan. Kami sepenuhnya menyadari, mengirimkan proposal yang menjelaskan secara sekilas beberapa fitur kunci yang kami tawarkan tentulah mengandung resiko: ide dibajak, tapi tak ada jalan lain untuk menawarkan produk kami tanpa melalui langkah itu.

Akhirnya, kami tak pernah mendapat satupun kesempatan untuk mempresentasikan software itu.

Beberapa bulan yang lalu, saya mendapati karcis parkir sebuah mal sudah mengimplementasikan ide kami dulu itu: karcis parkir yang tidak mencantumkan nomor polisi, dan menampilkan barcode sebagai gantinya. Beberapa minggu setelahnya, saya mendapati karcis parkir sebuah mal yang lain juga menggunakan model karcis parkir yang sama. Sambil tersenyum, saya cuma berkata di dalam benak, “Rupanya ide kami terlalu awal 8 tahun.”

Ide itu sesuatu yang gratis. Siapa saja bisa mendapat ide yang sama. Saya yakin bahwa kemungkinan besar kami bukanlah yang pertama kali menemukan ide itu, meski mungkin kami termasuk beberapa orang yang paling awal memikirkannya. Tapi, meski ide gratis, orang butuh daya upaya, butuh kemampuan, dan butuh kesempatan untuk mewujudkan dan menerapkannya. Satu hal yang kurang dari kami waktu itu adalah kesempatan. Pintu kesempatan belum terbuka bagi kami.

Tapi tentu saja, itu bukan berarti akhir dari segala-galanya. Kami mendapatkan pengalaman yang menarik terkait software manajemen parkir itu. Kami belajar banyak memikirkan berbagai skenario dalam pengelolaan lahan parkir. Kami belajar untuk berani menawarkan apa yang kami punya, mencoba mengetuk pintu-pintu yang asing bagi kami. Kami belajar menerima penolakan. Kami belajar banyak trik pemrograman baru saat membuatnya. Mungkin kami belum cukup keras berusaha, belum cukup ngotot dan berani mengetuk lebih banyak pintu lagi.

Anda punya ide? Jangan terburu gembira dulu dengan membayangkan bahwa mungkin Andalah orang pertama yang mendapatkan ide itu. Masih butuh banyak keringat untuk mewujudkannya menjadi sesuatu yang benar-benar berarti. Selamat berjuang.

Short course OpenMRS bersama Nyoman Winardi Ribeka

Dua hari ini, saya mengikuti short course OpenMRS yang diadakan oleh Simkes FK UGM. Acara short course dipandu oleh Nyoman Winardi Ribeka, pemuda Bali yang ramah dan bersemangat yang kini bekerja di Regenstrief Institute. Acara dibuka dengan sambutan dari Mas Anis Fuad, dan kemudian dilanjutkan dengan sesi instalasi OpenMRS. Kebetulan sejak 2 hari sebelum acara saya sudah mencoba2 sendiri menjalankan OpenMRS appliance, dan sudah berjalan baik, sehingga saya sekedar menyimak sekilas saja sesi instalasi itu.

Acara pengenalan konsep OpenMRS dimulai menjelang makan siang. Beberapa domain utama OpenMRS yaitu person, patient, user, concept, observation, encounter, dan form mulai diperkenalkan. Peserta dengan latar belakang teknis rasanya tidak terlalu mendapat kesulitan untuk mengikuti.

Menurut saya, “nyawa” OpenMRS terletak pada concept domain. Hampir semua dirumuskan, didefinisikan, dan direlasikan di situ. Malaria? Didefinisikan di concept. Berat badan? Juga didefinisikan di situ. Antibiotik? Ada juga di concept domain. Semua yang ada dalam bentuk concept, dapat direlasikan dan dapat saling dikelompokkan. Semua concept dapat digunakan dan disusun di dalam form yang kita buat, yang nantinya diisi data oleh pengguna.

Sejauh apa yang dapat saya pahami dalam dua hari ini, OpenMRS adalah sebuah platform yang menurut saya cukup fleksibel. Orang dapat mendefinisikan sendiri concept yang menurutnya perlu ditambahkan. Orang juga dapat membuat module untuk memperluas fungsionalitas OpenMRS, jika ia menguasai bahasa pemrograman Java, tentunya.

Dari apa yang saya ketahui tentang kebutuhan pengelolaan data rekam medis di sini, salah satu kebutuhan utama yang belum tercakup (setidaknya secara built-in) oleh OpenMRS adalah masalah billing. Bahkan banyak institusi medis yang cenderung lebih mendahulukan pembuatan sistem billing elektronis ketimbang sistem rekam medis elektronis. Apakah concept domain dapat menampung masalah billing ini? Saya masih perlu mencari tahu tentang itu.

Peserta short course cukup beragam, baik latar belakang ataupun asal daerah. Sangat menyenangkan dapat saling bertukar cerita dan pengalaman dengan beberapa rekan peserta (dan juga teman lama yang kebetulan bertemu lagi di situ) yang kebetulan bersilang jalan dengan saya. Pengalaman Mas Sigit dan Mas Yoga di RS Panti Rapih tentang pengembangan dan implementasi sistem informasi baru sangat menarik untuk disimak, dan memperkaya wawasan saya. Sharing Mas Agus Mutamakin dari RSCM tentang interaksi rekan2 dokter dengan teknologi canggih tak kalah menariknya. Baru kali ini saya menjumpai seorang dokter yang mampu dengan fasih berdiskusi tentang NoSQL 🙂 Kevin dari Jakarta juga berbagi cerita dengan saya tentang mengumpulkan informasi dan menimbang sistem informasi yang mampu menjawab kebutuhan Ukrida. Semuanya menarik.

Dalam beberapa kesempatan berbincang di luar forum, Win (panggilan Winardi) bercerita tentang Regenstrief Institute dan visi mereka untuk OpenMRS, sekilas kehidupan di Kenya dan implementasi OpenMRS di sana. Di sisi lain, saya juga mencoba berbagi cerita tentang tantangan implementasi Simpus di berbagai daerah. Adalah menarik bagi saya mengetahui Win sepakat dengan saya bahwa seharusnya developer mengenali betul tantangan yang ada di lapangan sana. Sebagai developer, kita bisa saja mengembangkan suatu aplikasi, dan merasa semuanya baik dan lancar saja. Padahal tantangan sesungguhnya adalah agar apa yang dengan susah payah kita kembangkan itu sungguh bermanfaat di lapangan. Di lapangan banyak sekali masalah non teknis yang harus dilihat dan dipikirkan solusinya, bukan saja melulu masalah teknis.

Saya menyambut baik rencana Mas Anis Fuad untuk mencoba membangun komunitas OpenMRS di sini, dengan harapan semakin banyak orang yang paham dan mendapat manfaat darinya, baik langsung ataupun tidak langsung.

Demikian cerita singkat saya, semoga bermanfaat.

Cake bake di Windows

Menggunakan bake CakePHP untuk pertama kali sering membingungkan, terutama bagi pengguna Windows. Padahal masalahnya sederhana saja: letak eksekusi perintah bake. Kita ambil saja contoh yang ada di manualnya. Di situ dikatakan:

“Once we have the table structure in the database we can start cooking. Use cake bake to quickly create your models, controllers, and views.”

Manual hanya menyebutkan agar kita menjalankan “cake bake” untuk dengan mudah menyiapkan model, controller, dan view (dari obyek2 yang tergambar pada tabel yang sudah dibuat).

Katakanlah, aplikasi kita ada di “D:\Localhost\simpleacl”, di dalamnya ada subfolder app, cake, dan vendors. File cake.bat terletak di folder “D:\Localhost\simpleacl\cake\console”. Biasanya, orang akan pindah ke folder tersebut dan menjalankan cake.bat dari situ. Ini pangkal kebingungan. Kita akan ditanya path aplikasi kita.

cake bake dari folder cake\console

Jika kita mau menyiapkan model, controller, dan view, lebih mudah jika kita menjalankan cake bake dari root folder aplikasi kita, dalam contoh ini berarti “D:\Localhost\simpleacl”.

cake bake dari root folder aplikasi

Semoga bermanfaat.