Archive

Archive for the ‘simpus’ Category

Mendadak ke Australia

Semua bermula dari keisengan belaka.

Suatu hari di bulan April 2016, saya mendapat informasi tentang acara HIMAA NCCH 2016 National Conference yang diadakan di Melbourne, Australia. Ada satu hal yang menarik dalam informasi yang saya baca: ada tawaran sponsorship bagi presenter paper yang naskahnya diterima. Sponsorship akan dapat digunakan untuk membiayai transportasi, akomodasi, dan biaya pendaftaran acara.

Saya, yang seumur-umur belum pernah menulis abstrak ilmiah untuk dikirimkan ke acara seminar, memberanikan diri menulis sebentuk abstrak. Saya memaparkan proses pengembangan dan implementasi bridging system SIMPUS dan PCare. Akhir Mei naskah saya nyatakan siap dan saya kirimkan. Saya juga melengkapi berbagai persyaratan yang diminta panitia. Setelah itu, saya pasrah dan bisa dibilang melupakan soal ini.

Hingga akhirnya kabar kejutan saya terima di awal Juli 2016. Saya mendapat email yang menyatakan naskah saya diterima, dan saya diminta memaparkannya dalam bentuk poster. Saya berkirim email dengan panitia untuk mendapat rincian informasi yang saya butuhkan. Dan petualangan dimulai.

Beberapa keputusan mesti diambil terlebih dahulu, seperti misalnya dalam soal: anak dan istri akan ikutkah (meski ini alasan utama perjalanan ini adalah urusan acara seminar ilmiah, ya konyol aja kalau tidak sekalian berwisata singkat, betul atau betul?) dan kapan tanggal persisnya berangkat dan pulang. Saya dan istri memutuskan bahwa istri akan ikut berangkat (orang menyebutnya hanimun, dan kami biasanya hanya senyum-senyum saja, tidak mengiyakan atau menolak), namun anak tidak, karena ia bersekolah dan ia akan terlalu lama meninggalkan sekolah bila ia ikut. Bantuan datang dari kedua pasang orang tua kami yang menyanggupi secara bergantian akan mendampingi anak kami selama kami pergi. Setelah bantuan ada, tanggal berangkat dan pulang kami putuskan.

Kebetulan ada kerabat kami yang tinggal di Melbourne, yang dengan girang menyambut rencana perjalanan kami dan menawarkan segenap bantuan yang bisa mereka berikan. Dalam pengurusan visa, kami mendapat bantuan dari banyak orang, berupa surat-surat rekomendasi yang dibutuhkan.

Setelah semua urusan akomodasi dan transportasi tuntas, tinggallah urusan utamanya: membuat poster. Selain poster, saya juga berkeinginan membuat satu naskah yang berisi penjelasan yang lebih lengkap tentang topik yang akan saya presentasikan. Bantuan dari teman dan kerabat amat memperlancar proses ini. Naskah saya yang amburadul dipermak agar lebih layak baca. Rancangan poster yang sempat saya buat, akhirnya juga dirancang ulang agar lebih menarik dan mudah disimak. Menjelang waktu keberangkatan, semuanya siap.

Bahkan hingga kami tiba di bandara untuk berangkat, saya masih terus meyakinkan diri bahwa rencana perjalanan ini nyata adanya dan bukan sekedar rencana gila. Pesawat mendarat selamat di tujuan, dan saya yakin bahwa ini buah karya Sang Maha Perencana yang Jenaka.

Perjalanan dan pemaparan saya berlangsung lancar, semuanya atas bantuan banyak pihak.

Terimakasih pada HIMAA NCCH yang berkenan mengundang saya untuk hadir dan menyampaikan paparan di sana.

Terimakasih pada kedua pasang orang tua kami yang bersedia berkorban waktu dan tenaga mendampingi cucu mereka selama kami pergi.

Terimakasih pada Icha dan Dion yang sudah mempermak habis naskah amburadul yang saya buat, yang sudah menyiapkan surat rekomendasi, dan yang kemudian memandu perjalanan kami, juga menyediakan tempat bagi kami untuk menginap.

Terimakasih pada Mas Jojok, tim Kinaryatama Raharja, dan tim Kunang yang memberikan dukungan informasi, foto, dan semangat.

Terimakasih pada Sinang, yang bersedia saya ganggu hari-harinya dengan urusan penyusunan poster.

Terimakasih pada Pak Judhi Pramono, yang berkenan memberikan surat rekomendasi yang berharga.

Advertisements

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:

Model_pengembangan_software

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

Catatan dari Forum Informatika Kesehatan (FIKI), 3-4 Desember 2011

Acara Workshop SIKDA Generik dan Connectathon dilanjutkan dengan FIKI 2011. Ini adalah catatan saya tentang FIKI 2011. Catatan ini tidak direncanakan untuk menjadi catatan kronologis, sehingga memang bisa jadi tidak akan lengkap.

FIKI adalah Forum Informatika Kesehatan Indonesia. FIKI 2011 adalah FIKI yang kedua. FIKI pertama diadakan tahun lalu, 2010, di Yogyakarta. FIKI 2011 ini diadakan di Jakarta, tepatnya di Novotel Mangga Dua Jakarta. Bagi saya, FIKI adalah forum yang menarik, karena menggabungkan dua bidang ilmu besar: ilmu kesehatan dan informatika. Informatika ditakdirkan sebagai ilmu yang fleksibel, karena ia hadir dengan harapan untuk mempermudah pengelolaan informasi, yang tentu saja diperlukan di banyak (atau bahkan semua) bidang kehidupan. Termasuk di bidang ilmu kesehatan.

Dari beragamnya latar belakang peserta FIKI yang saya jumpai, terlihat bahwa bidang informatika kesehatan menarik perhatian banyak pihak dari berbagai bidang ilmu. Sekedar menyebut beberapa di antaranya: tenaga medis (dokter, dokter gigi, perawat, dll), perusahaan pengembang SIK dan programmer lepas (terutama yang mengembangkan aplikasi untuk dunia medis, seperti Mas Jojok dan saya), pengelola RS, perusahaan telekomunikasi, perusahaan alat medis, akademisi dan universitas, peneliti, lembaga pemerintah (terutama yang terkait dengan soal kesehatan, dari berbagai lini: Dinkes Kabupaten, Dinkes Propinsi, lembaga di dalam Kemenkes).

FIKI Hari Pertama

Pada hari pertama, ada beberapa presentasi yang menarik bagi saya. Salah satunya adalah presentasi tentang Telkom e-Health Cloud yang sedang dikembangkan oleh PT. Telkom. Solusi cloud computing diajukan untuk menjawab beberapa persoalan, di antaranya: tidak terintegrasinya dan begitu beragamnya format data berbagai sistem informasi kesehatan (SIK) yang selama ini telah ada (persis dengan isu yang sedang dicoba untuk diatasi oleh Pusdatin – melalui penyusunan dataset standar), relatif mahalnya biaya investasi SIK, dan terbatasnya akses atas data kesehatan yang berada di dalam SIK.

Tentang cloud computing sebagai solusi untuk mengatasi masalah tidak terintegrasinya dan begitu beragamnya format data berbagai SIK yang selama ini ada, menurut saya solusi cloud computing yang diajukan hanya akan menjadi sekedar satu jenis SIK baru, dengan standar data dan alur proses yang juga baru. Ia baru akan menjawab persoalan itu, jika semua institusi medis yang ada meninggalkan SIK yang selama ini dipakai dan beralih pada cloud computing yang ditawarkan PT. Telkom. Format data yang digunakan, saya yakin (meski saya belum melihat), juga adalah format data yang berbeda, sejajar (dalam artian sama berbedanya) dengan berbagai format data dari SIK yang selama ini telah ada. Sehingga menurut saya, belum tentu cloud computing dapat hadir sebagai bentuk jawaban atas persoalan multi format data dan tidak terintegrasinya SIK yang ada.

Tentang cloud computing sebagai solusi atas mahalnya biaya investasi SIK, menurut saya persoalannya tidak sesederhana itu. Secara umum, biaya investasi sebuah sistem informasi (bukan hanya SIK) akan jauh melambung tinggi jika dirancang secara spesifik / custom. Biaya dapat ditekan jika sistem informasi yang ditawarkan bersifat generik, satu sistem yang sama untuk semua orang. Solusi cloud computing yang dijelaskan dalam presentasi itu, cenderung merupakan solusi satu sistem untuk semua orang. Variasi mungkin bisa disajikan dalam bentuk pilihan modul, tapi tentu saja ini terbatas, dan tidak bisa disebut sebagai solusi spesifik / custom. Pada kenyataannya, SIK selalu cenderung bersifat beragam, karena beragamnya kebijakan lokal, sesuai dengan tempat SIK tersebut digunakan. Ini saja terjadi di puskesmas, institusi yang sebetulnya relatif seragam, apalagi dengan RS (yang lebih banyak disinggung dalam presentasi kemarin). Sejauh tidak ada keseragaman kebijakan di berbagai institusi medis pengguna SIK, cloud computing akan menghadapi tantangan dalam menerapkan solusinya pada situasi dan kebutuhan yang amat beragam.

Tentang terbatasnya akses atas data kesehatan yang berada di dalam SIK yang selama ini terjadi, cloud computing menjanjikan akses yang lebih mudah, termasuk bagi mereka yang mobile. Asalkan koneksi internet tersedia, data kesehatan di dalam cloud dapat diakses di mana saja dan kapan saja. Pertanyaan saya adalah, sejauh mana ini sudah diperlukan di lingkungan Indonesia saat ini? Mungkin dalam sekian tahun mendatang, kebutuhan aksesibilitas semacam ini akan semakin nyata, meski mungkin sekarang belum tampak. Menurut saya, ini adalah sebentuk antisipasi PT. Telkom untuk bersiap memenuhi kebutuhan di masa mendatang. Jika antisipasi ini pas, PT. Telkom akan menjadi pionir dalam solusi e-health yang berupa cloud computing.

Saya rasa akan menarik jika Anda juga membaca tentang Practice Fusion, sebuah solusi cloud computing di dunia medis yang disediakan secara gratis. Menarik pula untuk membaca sebuah ulasan tentang Practice Fusion di sini: http://www.readwriteweb.com/archives/practise_fusion_partners_with_salesforce.php.

FIKI Hari Kedua

Pada hari kedua, terdapat pula beberapa presentasi yang cukup menarik perhatian saya. Satu di antaranya adalah presentasi dari Direktorat Jenderal Bina Upaya Kesehatan (BUK) Kemenkes. Presentasi dibuka dengan penjelasan tentang tugas pokok Ditjen BUK, yaitu “merumuskan serta melaksanakan kebijakan dan standarisasi teknis di bidang pembinaan upaya kesehatan”. Ditjen BUK melihat ada beberapa persoalan di lingkungan RS saat ini, di antaranya: pengembangan IT di RS masih dijalankan terpisah (tidak terintegrasi), belum tersedia blueprint untuk HMIS (Hospital Management Information System). Dari tugas pokok yang diberikan kepadanya, Ditjen BUK mengusulkan beberapa solusi untuk permasalahan yang ada saat ini. Beberapa usulan solusi itu di antaranya: penyusunan standar minimal SIMRS, penyusunan aplikasi SIMRS opensource. Di masa mendatang, Ditjen BUK juga berencana untuk menyiapkan sebuah data center yang menampung kiriman data dari semua RS yang ada. Disampaikan juga di dalam presentasi yang sama bahwa Ditjen BUK akan (atau mungkin telah) bekerja sama dengan PT. Telkom untuk mengimplementasikan e-RM (rekam medis online – yang dalam pemahaman saya mungkin adalah Telkom e-Health Cloud – lihat catatan saya di atas) sebagai bentuk kegiatan CSR PT. Telkom.

Secara sekilas tampak adanya kemungkinan tumpang tindih tugas dan kegiatan antara Pusdatin (silakan baca catatan saya sebelumnya) dan Ditjen BUK. Keduanya memiliki tugas pokok yang cukup mirip, dan kemudian juga melakukan beberapa kegiatan yang hampir sama. Pusdatin, meski saat ini masih bergelut dengan pengembangan SIKDA Generik yang ditujukan untuk puskesmas, pada tahun 2012 merencanakan untuk juga mengembangkan SIM RS Generik (yang akan diikuti dengan SIK Dokter Generik). Pusdatin juga tengah mengembangkan Bank Data Daerah dan Nasional untuk menampung data dari puskesmas dan juga RS nantinya (yang jika tidak mengalami kendala teknis, direncanakan untuk diujicoba pada acara Connectathon 2 hari sebelumnya).

Sebagai pengembang SIK, Mas Jojok dan saya merasa bingung dengan kemungkinan dualisme ini. Bagaimana jika nantinya muncul dua standar data dan standar minimal aplikasi, dari Pusdatin dan Ditjen BUK? Yang mana yang harus diikuti oleh para pengembang SIK?

Mas Jojok memutuskan untuk mengambil kesempatan untuk bertanya. Pertanyaannya kurang lebih adalah seperti ini:
“Saya kemarin diundang untuk mengikuti salah satu acara… (menghela nafas) BUK tadi menyampaikan tentang e-health blablabla, data center blablabla. Saya ikut di acara connectathon. Pusdatin sekarang sedang mengembangkan itu juga Pak. Bagaimana sebenarnya bisa ada dualisme pengembangan seperti ini? Pusat saja belum bisa berkoordinasi Pak, bagaimana mau membenahi sistem yang ada? Sudahkah ada koordinasi di antara Ditjen-ditjen yang ada di sini dan Pusdatin? Sudahkah semuanya duduk bareng dan membahas bersama? Saya vendor SIK dengan pengguna lebih dari 400 puskesmas, dan semuanya standar sesuai standar punya saya sendiri. Dan saya menunggu saat seperti ini untuk menyesuaikan diri dengan standar nasional. Kemarin semua vendor juga sudah hadir, dari Ngawi, dari Purworejo, dan semuanya sudah berkomitmen bahwa kami akan selalu mendukung upaya pemerintah untuk menstandarkan ini. Tapi tolong, pemerintah juga sepakat di jajarannya yang berbeda-beda ini untuk saling menstandarkan di antara mereka sendiri.”

Saya melihat pertanyaan ini mewakili kegelisahan para pengembang SIK yang hadir. Dan adanya kegelisahan terbukti dari munculnya pertanyaan senada dari penanya yang lain.

Presenter dari BUK kemudian menanggapi dengan menyatakan bahwa selama ini Ditjen BUK dan Pusdatin telah dan akan selalu berkoordinasi, komunikasi di antara mereka berjalan dengan sangat baik. Beliau menjelaskan bahwa memang setiap direktorat memiliki kebutuhan data yang berbeda, sesuai dengan bidang tugasnya. Dan dalam soal RS, BUK disebutkan sebagai pihak yang memahami kebutuhan data dari RS yang ada. Oleh karena itu BUK memiliki wewenang untuk menentukan dataset minimal RS. Beliau menjelaskan bahwa ini semua tidak berarti tidak ada koordinasi antara BUK dan Pusdatin. Koordinasi berjalan terus dalam rangka menyusun dan mengembangkan sistem-sistem yang diperlukan.

Dari tanggapan tersebut, saya memahami bahwa mungkin memang secara umum BUK lebih memiliki wewenang untuk soal RS, termasuk dalam soal menentukan dataset standar minimal. Dan tentu baik jika benar bahwa BUK telah dan selalu berkoordinasi dengan Pusdatin terkait masalah ini. Namun demikian, tanggapan yang diberikan, seingat saya, tidak menyinggung soal mengapa BUK juga mengembangkan SIMRS opensource dan sebuah data center. Bagaimana itu dikoordinasikan, belum dijelaskan. Sebagai orang lapangan, saya sangat berharap koordinasi itu benar telah dan akan selalu dilakukan. Tersusunnya sebuah dataset kesehatan standar yang dirancang secara matang dengan pertimbangan dan masukan banyak pihak, terutama dari para pengembang SIK dan para pengguna, tentu akan menjadi langkah awal yang baik untuk terbentuknya sebuah data kesehatan nasional yang utuh dan akurat.

Satu hal lain yang menarik dalam FIKI 2011 ini adalah hadirnya beberapa peserta dari Malaysia. Mereka tampak aktif mengikuti setiap acara, dan pada beberapa kesempatan ikut juga mengajukan pertanyaan. Dugaan saya, ini menunjukkan bahwa ada minat dari akademisi / pengusaha Malaysia untuk mulai melirik potensi pasar di dunia kesehatan Indonesia. Jika ini benar, tentu seluruh pihak yang terlibat di dunia kesehatan, terutama informatika kesehatan, patut menjadikan ini sebagai sebuah tantangan untuk makin serius menggarap peluang di negeri kita sendiri, sebelum pihak asing ikut masuk dan mendapat manfaat.

Tentu para peserta FIKI 2011 lainnya bisa memiliki sudut pandang yang berbeda soal hal mana saja yang menarik perhatian mereka. Catatan ini mewakili sudut pandang saya. Semoga catatan ini bermanfaat.

Catatan dari Workshop SIKDA Generik dan Connectathon, 2 Desember 2011

Pada tanggal 2 Desember 2011, saya dan Mas Jojok diundang untuk menghadiri Workshop SIKDA Generik dan Connectathon yang diadakan di Novotel Mangga Dua Jakarta. Workshop dan Connectathon adalah dua acara terpisah, meski diadakan di tempat dan hari yang sama. Workshop diselenggarakan pagi hingga menjelang sore, sedangkan Connectathon diselenggarakan setelahnya hingga larut malam, dengan hanya dihadiri oleh pihak pengembang sistem informasi kesehatan (SIK) yang diundang. Mengutip Term of Reference (TOR) yang dibagikan panitia, tujuan dari kegiatan workshop ini terutama adalah sebagai ajang sosialisasi SIKDA Generik sebagai salah satu alternatif pilihan dan acuan standar SIK di Puskesmas dan Dinas Kesehatan. Sedangkan connectathon direncanakan sebagai kegiatan ujicoba teknis dalam usaha mengintegrasikan data kesehatan dari berbagai sistem informasi puskesmas dengan Bank Data Nasional. Pada umumnya, connectathon diadakan dengan melibatkan tim programmer untuk memodifikasi kode program secara langsung di lokasi acara connectathon sesuai standar yang diharapkan. Kami diundang selaku salah satu pihak pengembang SIK di Puskesmas dan Dinas Kesehatan. Jika saya tidak salah menghitung, dalam acara tersebut terdapat 6 pihak pengembang yang diundang.

SIKDA Generik (Sistem Informasi Kesehatan Daerah Generik) adalah sebuah SIK yang sedang dikembangkan oleh Pusat Data dan Informasi Kementerian Kesehatan (Pusdatin Kemkes). SIKDA Generik dirancang untuk menjadi model SIK yang sesuai standar. Dalam waktu yang sama, sebuah format data kesehatan standar (agar sederhana, kita sebut saja sebagai dataset standar) sedang dikembangkan oleh Pusdatin, dan dataset standar inilah yang diacu oleh SIKDA Generik. Dataset standar ini direncanakan untuk menjadi acuan semua SIK yang telah ada selama ini. Keberadaan sebuah dataset standar diperlukan, karena selama ini SIK yang telah ada tidak memiliki dataset standar yang sama, dan tentu ini menimbulkan kesulitan ketika pengguna data (Kemkes misalnya) menerima data dengan berbagai format yang berbeda.

Workshop SIKDA Generik

Pada hari Jumat itu, dari pagi hingga menjelang sore acara diisi oleh paparan dari beberapa pihak yaitu: drg. Rudi Kurniawan, M.Kes. mewakili Pusdatin, Kelvin Hui dari GIZ selaku konsultan teknis yang membantu Pusdatin, Yudi Permana dari Dinkes Bekasi selaku pihak pengguna sebagai lokasi ujicoba SIKDA Generik, dr. Lutfan Lazuardi, PhD dari SIMKES UGM, dan tim pengembang SIKDA Generik. Sebagian besar (atau bahkan semua) paparan berisi daftar poin-poin dan bagan konseptual. Bahkan ketika tim pengembang SIKDA Generik memberikan paparan tentang fitur-fitur SIKDA Generik, screenshot SIKDA Generik (yang sebenarnya adalah tema utama workshop ini) tidak tampil. Setelah sedari pagi sebagian peserta menahan rasa penasaran tentang “look-and-feel” SIKDA Generik, akhirnya ada juga peserta yang meminta secara terbuka agar peserta dapat melihat tampilan dan jika memungkinkan mencoba SIKDA Generik. Tim pengembang menjelaskan bahwa sebenarnya SIKDA Generik akan ditampilkan dan dicobakan nanti pada sesi Connectathon (yang menurut rencana hanya akan dihadiri oleh para pengembang SIK yang diundang). Namun demi menjawab keinginan peserta workshop, akhirnya SIKDA Generik disediakan secara terbuka untuk diakses dan dicoba oleh para peserta. Saya sendiri belum begitu banyak mencoba, karena akses baru dibuka pada sekitar 15 – 30 menit terakhir sebelum sesi workshop diakhiri (dan kemudian dilanjutkan oleh acara Connectathon).

Dalam sesi tanya jawab yang dibuka pada acara workshop, ada beberapa pertanyaan yang diajukan, termasuk dari saya. Dari beberapa peserta yang mewakili Dinkes dari berbagai daerah (terutama yang telah mengembangkan atau menggunakan SIK non SIKDA Generik), muncul kekhawatiran adanya keharusan untuk beralih dari SIK yang selama ini telah dengan lancar digunakan ke SIKDA Generik. Pertanyaan ini dijawab tuntas oleh staf Pusdatin, bahwa itu tidak benar. SIKDA Generik disiapkan sebagai SIK alternatif, terutama bagi daerah yang selama ini tidak memiliki kemampuan dana yang memadai untuk membeli (atau apalagi mengembangkan) SIK. SIKDA Generik akan diedarkan secara gratis dan opensource (catatan: gratis dan opensource adalah dua hal yang berbeda), sehingga diharapkan ini akan mengeliminasi keperluan biaya pengadaan perangkat lunak SIK. Menurut saya pribadi, dari pengalaman selama ini, sejauh yang saya tahu, biaya harga SIK (terutama Simpus Jojok, dengan berbagai versinya) justru tidak pernah menjadi komponen biaya utama dari total biaya implementasi SIK di berbagai daerah. Komponen biaya terbesar justru terletak pada biaya pelatihan dan pendampingan sebagai upaya penyiapan manajemen dan SDM puskesmas / Dinkes pengguna. Oleh karena itu, menurut saya ketika SIK disediakan secara gratis (dalam konteks SIKDA Generik), persoalan masih ada: bagaimana dengan pembiayaan dan pelaksanaan pelatihan dan pendampingan? Belum lagi, bagaimana dengan pembiayaan pengadaan perangkat keras? Sayangnya pertanyaan ini belum sempat saya ajukan dalam acara workshop kemarin.

Pertanyaan lain yang juga diajukan oleh peserta adalah, bagaimana dengan pelatihan dan pendampingan penggunaan SIKDA Generik nantinya? Pusdatin menjawab, pelatihan dan pendampingan SIKDA Generik akan melibatkan penyedia jasa lokal. Para penyedia jasa lokal ini sebelumnya akan dilatih tentang penggunaan SIKDA Generik. Hanya memang bagaimana mekanismenya, juga seperti apa materi pelatihan para penyedia jasa lokal ini belum sempat dipaparkan secara terperinci. Saya sendiri mengajukan beberapa pertanyaan terkait dataset standar. Salah satu pertanyaan saya adalah tentang mekanisme sinkronisasi pengkodean. Di dalam rancangan dataset standar yang telah diedarkan secara terbatas di kalangan pengembang SIK, terdapat kode standar untuk berbagai variabel, misalnya kode jenis kelamin, kode obat, kode tindakan. Ada sebagian kode yang sifatnya dinamis, karena bisa diubah sesuai situasi di masing-masing daerah. Misalnya kode obat. Dengan sifatnya yang dinamis, tentu ada kemungkinan untuk terjadinya situasi kode obat yang sama digunakan untuk obat yang berbeda. Misalnya, di satu daerah, kode obat “A01” digunakan untuk obat bernama “Obat ABC”, sedangkan di daerah lain, kode obat “A01” digunakan untuk obat bernama “Obat ACD”. Ketika data dikirimkan ke Bank Data Nasional, tentu bisa terjadi kekacauan, karena yang dikirim sama-sama kode “A01”, padahal yang dimaksud adalah obat yang sepenuhnya berbeda. Bagaimana strategi sinkronisasinya? Tim pengembang menjawab, jika ditemui kejadian seperti itu, Pusdatin akan melakukan revisi dataset standar dengan menambahkan kode dan nama obat baru tersebut ke dalam dataset standar. Secara berkala, setiap puskesmas pengguna SIK (baik SIKDA Generik ataupun SIK lain) harus menyesuaikan kode-kode obat (juga kode-kode variabel lain yang direvisi) agar sesuai dengan dataset standar. Terus terang saya belum mampu membayangkan kerumitan pelaksanaannya. Kelvin Hui lalu menambahkan keterangan, bahwa revisi tidak bersifat historikal, artinya data yang sudah terlanjur ada dengan kode lama dibiarkan saja, kode baru hanya digunakan pada data yang baru saja. Ini tentunya lebih mudah dilaksanakan.

Connectathon

Terus terang, saya dan Mas Jojok berangkat tanpa memiliki bayangan akan seperti apa acara connectathon itu nantinya. Jika benar connectathon adalah acara yang bersifat sangat teknis (seperti yang saya jelaskan di atas), tentunya petunjuk dan dokumentasi teknis sudah disebarkan semenjak jauh-jauh hari, agar para peserta siap. Memang benar, petunjuk teknis telah dikirimkan sebelumnya, namun sejujurnya saya tidak begitu memahami isinya, karena isinya didominasi daftar variabel yang masuk dalam dataset standar, dan tanpa disertai satupun contoh. Melalui beberapa obrolan, saya mendapati peserta connectathon yang lain juga belum memahami petunjuk teknis yang telah dikirimkan.

Dalam pembukaan connectathon oleh Kelvin Hui, disampaikan bahwa connectathon kali ini tidak akan terlalu bersifat teknis, karena ini baru kali pertama connectathon diadakan. Connectathon ini akan didominasi oleh penjelasan konsep dataset standar dan jika memungkinkan, beberapa ujicoba sederhana. Ini sedikit melegakan beberapa peserta yang tidak membawa serta tim programmer mereka. Acara dilanjutkan dengan paparan konsep SDMX-HD dan rancangan dataset standar. Melihat kebingungan yang mungkin tampak di wajah sebagian peserta saat paparan teknis disampaikan, tim pengembang SIKDA Generik berulang kali bertanya, “apakah penjelasan teknis ini dapat diikuti?”. Saya mengajukan usul, bagaimana jika penjelasan teknis disampaikan dalam bentuk contoh, langsung saja didemokan bagaimana SIKDA Generik dioperasikan untuk mengirimkan data (dalam format yang sesuai dengan dataset standar, karena SIKDA Generik diposisikan sebagai acuan SIK lainnya terkait dengan dataset standar) ke Bank Data yang telah disiapkan. Usulan saya disambut baik oleh sebagian besar peserta dan juga tim pengembang SIKDA Generik. Server untuk menjalankan SIKDA Generik dan Bank Data disiapkan. Namun rupanya terjadi kendala teknis, sehingga server belum dapat difungsikan.

Sekian menit ditunggu-tunggu, penyebab permasalahan teknis tak kunjung ditemukan meski teman-teman itu sudah berupaya keras. Akhirnya Mas Jojok mengusulkan untuk mengisi waktu dengan perkenalan dan diskusi. Usulan ini disambut baik oleh Pak Rudi. Peserta yang hadir bergantian memperkenalkan diri. Bagi saya, terlepas dari kenyataan bahwa saya merupakan bagian dari tim Simpus Jojok, apa yang disampaikan oleh Mas Jojok dalam sesi diskusi malam itu sangat menarik dan menyentuh hati. Saya tidak yakin mampu menuliskannya secara akurat, tapi yang saya coba tulis berikut ini adalah kurang lebihnya.

Mas Jojok menyampaikan bahwa dia berangkat ke acara ini dengan membawa titipan dari beberapa teman staf Puskesmas pengguna Simpus Jojok. Mereka menyampaikan titipan harapan, agar jangan sampai Simpus yang telah mereka gunakan diubah atau diganti. Artinya ada harapan agar tidak terjadi perubahan yang berarti pada kenyamanan menggunakan SIK yang telah ada, meskipun akan diberlakukan standar nasional untuk data kesehatan. Di situ tampak jelas pentingnya komunikasi antara pembuat kebijakan dan stakeholder yang lain.

Mas Jojok juga menyampaikan bahwa dia mengawali perjalanan sebagai pengembang SIK sekitar 10 tahun yang lalu dengan kesadaran, bahwa ini adalah semacam panggilan hidup. Pengguna Simpus Jojok telah menaruh kepercayaan pada produk yang ia buat, dan dengan demikian ia mesti menjawab kepercayaan itu dengan pendampingan secara utuh. Relasi itu bukan sekedar relasi transaksi jual beli. Pengguna membeli Simpus Jojok, produk diinstall, dilatihkan, lalu selesai. Bukan seperti itu menurut Mas Jojok. Pengguna mesti selalu didampingi, terutama jika mereka mengalami kendala terkait penggunaan produk. Masalah bukan hanya mungkin datang sepanjang masa kontrak yang biasanya hanya 1 tahun setelah produk dibeli, tapi juga bisa datang dalam tahun-tahun mendatang, jauh setelah kontrak awal berakhir. Dan Mas Jojok berharap itu juga yang akan terjadi pada produk bernama SIKDA Generik. Dalam tahun-tahun sebelumnya, banyak produk hasil proyek dari instansi pusat dikirimkan dan “dipaksakan” untuk digunakan di puskesmas, hanya untuk diabaikan dan dilupakan segera setelah masa kontrak pengembang produk tersebut berakhir. (Mas Jojok menyebut beberapa contohnya, yang tidak akan saya kutip di sini.)

Mas Jojok menyadari bahwa adanya suatu standar format data secara nasional amat penting, bahkan standar semacam itu telah ia nanti-nantikan selama bertahun-tahun. Dalam momentum yang cukup baik ini (dalam konteks pengembangan SIK dan dataset standar), ia berharap komunikasi antara pengembang SIK dan Pusdatin selaku pembuat kebijakan tentang standar nasional untuk data kesehatan dapat terus berlangsung, agar pengalaman dari berbagai pengembang SIK selama bertahun-tahun dapat dimanfaatkan dalam proses pembuatan standar.

Satu hal lain yang sangat menarik dikemukakan di dalam diskusi oleh Mas Harmi, pengembang Sikesda (sebuah SIK yang dikembangkan oleh Sisfomedika). Di Kabupaten Sleman, terdapat 3 produk SIK yang hidup berdampingan. Ada puskesmas yang menggunakan Simpus Jojok, ada yang menggunakan Sikesda, dan ada yang menggunakan IHIS (semoga saya tidak salah menyebutkan nama produknya). Pak Haryanto dari Dinkes Sleman mengajak pengembang ketiga SIK ini untuk saling berkomunikasi, agar Dinkes Sleman tetap dapat memperoleh data dalam format seragam dari ketiga SIK tersebut. Dengan komunikasi intensif, terutama antara tim Sikesda dan Simpus Jojok, itu dapat diwujudkan. SIK yang ketiga menyusul kemudian. Format datanya tidak kompleks, hanya menggunakan text file berformat CSV (comma seperated value). Ini sebenarnya merupakan gambaran mini dari apa yang saat ini dihadapi oleh Pusdatin: ada berbagai SIK dengan fitur dan format beragam dan ada kebutuhan untuk mendapatkan data dari semua SIK dalam format seragam (agar dapat masuk dalam sebuah bank data). Seingat saya, proses teknis penambahan fitur untuk menghasilkan format data yang disepakati bersama itu hanya beberapa jam saja, tidak melebihi setengah hari. Sangat singkat! Tentu data yang dikirimkan belum semua, baru beberapa data standar saja, seperti data laporan LB 1. Tapi setidaknya, itu membuktikan bahwa hal semacam itu memungkinkan untuk dikerjakan. Mulai dengan sesuatu data dan format yang sederhana, disepakati bersama, lalu langsung dikerjakan.

Bagi saya, dalam forum itu, hal-hal yang penting telah disampaikan, terutama setidaknya dari yang saya ingat dari Mas Jojok dan Mas Harmi seperti saya tuliskan tadi. Sekarang perlu ditunggu kelanjutannya, baik dalam soal pengembangan SIKDA Generik dan dataset standar, juga dalam soal komunikasi antara Pusdatin dan para pengembang dan pengguna SIK yang telah ada. Semoga tulisan panjang ini bermanfaat.

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.

Categories: IT, OpenMRS, simpus Tags: , , ,