Rancang Bangun Aplikasi Instalasi Rawat Jalan dengan Paradigma Pengembangan Terintegrasi Menggunakan Enterprise Service Bus (ESB) Aditya Oktalifryan*, Bambang Setiawan, Radityo Prasetianto Wibowo Jurusan Sistem Informasi, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember, Surabaya, Indonesia *E-mail :
[email protected] Abstract Setiap unit bisnis di Rumha Sakit biasanya memiliki aplikasi tersendiri yang memungkinkan data tidak terintegrasi dan tidak valid apabila digunakan pada aplikasi lainnya. Oleh karena itu perlu rancangan dan aplikasi instalasi rawat jalan yang dapat terintegrasi dengan aplikasi-aplikasi di rumah sakit. Metode yang bisa dirujuk untuk mengatasi hal tersebut adalah menggunkan Service-Oriented Architecture (SOA). Selain itu, juga terdapat teknologi yang memiliki kemampuan sebagai suatu jembatan/middleware yang bisa mengenal dan mentransformasi service dari suatu modul agar bisa dibaca oleh modul lain, yaitu Enterprise Service Bus (ESB). Dengan teknologi ESB, walaupun dikembangkan oleh vendor aplikasi ataupun bahasa pemrograman dan menggunakan atau menyediakan service dengan standarisasi yang berbeda karena, modul IRJA tetap bisa diintegrasikan dengan modul lain yang ada di Sistem Informasi Rumah Sakit. Hasil yang dicapai dari Tugas Akhir ini adalah aplikasi Instalasi Rawat Jalan yang terintegrasi dengan modul Rekam Medis, Instalasi Rawat Inap (IRNA) dan Point of Sales yang terdapat pada Sistem Informasi Rumah Sakit. Enterprise Service Bus(ESB) yang digunakan pada implementasi adalah WSO2 yang merupakan versi GUI dari Synapse. Fungsi ESB yang digunakan adalah menggunakan Endpoint dan juga Proxy Service dari WSO2 untuk mengarahkan service ke server tujuan dari web service. Kata Kunci : Instalasi Rawat Jalan, Sistem Informasi Rumah Sakit, Enterprise Service Bus.
1. Pendahuluan Rumah Sakit sebagai penyedia layanan kesehatan memiliki berbagai unit bisnis yang saling terkait, seperti Apotek, Instalasi Rawat Inap(IRNA),Instalasi Rawat jalan (IRJA), Laboratorium, kepegawaian, dan keuangan. Instalasi Rawat Jalan merupakan unit penting di RS, karena selain frekuensi pelayanannya yang tinggi, juga hampir semua layanan pada unit bisnis lain berawal dari unit ini. Oleh karena itu perlu rancangan dan aplikasi rawat jalan yang dapat terintegrasi dengan aplikasiaplikasi di rumah sakit. Salah satu metode yang bisa dirujuk untuk mengatasi hal tersebut adalah menggunakan framework Organic Healthcare Information System (OHIS). Framework ini sendiri fokus pada cara untuk mengintegrasikan antar modul aplikasi dalam tiap unit bisnis pada sistem informasi suatu rumah sakit. Dasar teknologi yang pada framework OHIS adalah Service-Oriented Architecture (SOA). Masalah muncul ketika seluruh aplikasi tersebut memang sudah dirancang untuk bisa saling terintegrasi dengan menyiapkan webservice ataupun teknologi integrasi lain pada aplikasinya
Untuk mengatasi masalah tersebut, terdapat suatu teknologi yang bernama Enterprise Service Bus (ESB) yang mampu menerjemahkan setiap teknologi integrasi dari aplikasi yang akan diintegrasikan agar bisa dibaca pada masing-masing oleh aplikasi tersebut. Dengan adanya ESB, maka aplikasi-aplikasi pada setiap unit bisnis rumah sakit bisa terintegrasi walaupun dikembangkan dengan menggunakan standar webservice yang berbedabeda. Teknologi Webservice yang digunakan adalah sesuai dengan yang digunakan pada framework OHIS, yaitu menggunakan standar webservice SOAP. Sedangkan untuk Integrasi antar modul yang ada pada modul IRJA adalah dengan modul keuangan, rekam medis, IRNA, dan kepegawaian. Dengan dibangunnya modul aplikasi IRJA dengan menerapkan framework OHIS, rumah sakit dapat menyediakan informasi dan data-data yang diperlukan bagi setiap departemen secara konsisten karena saling terintegrasinya informasi antar unit bisnis. Selain itu dengan diterapkannya framework OHIS, diharapkan dapat menjadi solusi low-cost bagi manajemen rumah sakit dalam mengembangkan modul aplikasi, karena sifatnya
yang “organic” membuat aplikasi lain bisa dikembangkan tanpa harus mengganti keseluruhan sistem yang sudah ada
2. Tinjauan Pustaka A. Framework OHIS OHIS adalah suatu framework yang memberikan solusi alternatif bagi pengembangan sistem informasi rumah sakit dengan hanya membuat desain perangkat lunak sebagai modul service dan membuat database untuk tiap modul untuk bisa mengimplementasikannya[3]. Dengan diterapkannya OHIS, pengembang bisa melakukan pembangunan aplikasi dimulai dari yang kecil ataupun menerapkan yang sudah kompleks sekalipun dikarenakan sudah adanya standar framework dalam penulisan kode pada setiap aplikasi baru yang akan dibuat. Selain itu, juga terdapat dukungan framework SOA didalam OHIS yang menggunakan teknologi webservice yang mampu mengintegrasikan antar modul pada framework OHIS. Hal yang juga penting pada framework ini adalah adanya service locator,service loader, dan service requester yang memungkinkan untuk terjadinya integrasi antar modul, seperti yang terdapat pada gambar 1 dibawah ini :
Gambar 1 Arsitektur Framework OHIS B. Web Service Teknologi web service memberikan kemudahan untuk mengakses informasi dari berbagai sumber tanpa mempedulikan database apa yang digunakan oleh server yang memberikan informasi kepada aplikasi yang menjadi klien web service tersebut. Web service sebenarnya adalah kumpulan dari fungsi dan method yang terletak pada suatu server web service yang dapat di request oleh klien dengan memanggil method yang disediakan oleh server web service, klien sendiri bisa bebas dikembangkan menggunakan bahasa pemrograman maupun berjalan di platform apa saja Berikut adalah komponen yang terdapat dalam web service : i. Extensible Markup Language (XML)
-
XML merupakan dasar dari terbentuknya suatu web service karena dengan XML ini lah web service bisa saling berkomunikasi dengan aplikasi-aplikasi yang terhubung di dalamnya, sepanjang aplikasi yang terhubung tersebut bisa menerjemahkan tag XML yang diterima atau dikirim untuk diolah menjadi data yang sesungguhnya. [4] ii. Simple Object Access Protocol (SOAP) SOAP merupakan suatu format standar dari XML yang dapat diterjemahkan oleh web service untuk melakukan proses request dan response antara klien dan server web service yang menggunakan protokol Hypertext Transfer Protocol (HTTP) sebagai protokol pengiriman datanya. SOAP memiliki 3 struktur utama yaitu : SOAP envelope, SOAP header dan SOAP body.[5] iii. Web Service Definition Language (WSDL) WSDL merupakan suatu dokumen dalam format XML yang berisikan penjelasan suatu informasi detail dari web service. Jadi untuk bisa mengakses suatu web service dibutuhkan terlebih dahulu alamat wsdl dari web service tersebut agar bisa digunakan. Di dalam WSDL sendiri dijelaskan method-mehod apa yang bisa dipanggil, apa saja parameternya yang dibutuhkan dalam melakukan request, apa saja hasil respon setelah melakukan request dan juga termasuk tipe data yang dibutuhkan saat melakukan request dan tipe data yang dikembalikan saat respon dilakukan.[1] C. Enterprise Service Bus ESB adalah infrastruktur perangkat lunak yang berlaku sebagai lapisan perantara dari middleware yang menjembatani persyaratan yang tidak bisa dipenuhi oleh webservice, seperti : • Integrasi antar webservice dan teknologi middleware yang berbeda, • Tingkat keamanan, ketergantungan dan robustness yang tinggi • Kontrol dan pengelolaan dari komunikasi dan servis dari webservice ESB mampu mengontrol, menjembatani antar web service agar dapat saling berhubungan dengan jangkauan yang lebih luas, kompleks, dan mudah. ESB menyediakan suatu service platform dalam sebuah bus yang mengkoneksikan seluruh service yang ada pada enterprise. Beberapa konsep dari ESB adalah : ESB menyediakan lingkungan ekseskusi service tingkat enterprise (enterprise-grade)
-
ESB menyediakan sebuah ”service bus” yang membuat service dapat diakses dalam skala enterprise [2] Dengan penggunaan ESB, maka akan semakin meningkatkan kemampuan modularitas pada OHIS, karena semakin dimungkinkan mengembangkan modul-modul lain yang menggunakan webservice ataupun teknologi yang berbeda dengan yang sudah dipakai oleh modul-modul yang sudah terpasang. Gambar 2 dibawah ini adalah arsitektur aplikasi apabila sudah terdapat ESB sebagai lapisan perantara:
Gambar 2. Arsitektur umum aplikasi setelah menggunakan ESB
3. Perancangan Perangkat Lunak A. Studi Kebutuhan Pada bagian ini akan dijelaskan mengenai kebutuhan fungsional dari hasil survey di Puskesmas daerah Bendul Merisi Surabaya. Setelah melakukan survey, berikut adalah kebutuhan-kebutuhan menu yang bisa dibutuhkan oleh puskesmas : registrasi pasien, pengelolaan antrian instalasi rawat jalan, diagnosa dokter, dan administrasi Instalasi Rawat Jalan. Untuk registrasi pasien, data-data yang dibutuhkan oleh puskesmas adalah : - Nama Pasien, Jenis kelamin, Tempat / tanggal lahir, Telepon, Alamat, Agama, Pekerjaan, Status nikah, Tipe Asuransi (ASKES / ASKESKIN) Dari registrasi ini maka pasien tersebut akan mendapatkan no RM yang menjadi ID dari pasien tersebut ketika akan melakukan pendaftaran antrian di Instalasi Rawat Jalan maupun di Instalasi Rawat Inap. Untuk Pengelolaan antrian, data-data yang dibutuhkan oleh puskesmas adalah : - No RM Pasien, Jenis Klinik, Tanggal antri Dari data-data tersebut, puskesmas juga mengharapkan adanya laporan yang bisa menampilkan rekapitulasi jumlah pasien yang
mengantri di tiap klinik dengan jangka waktu tertentu yang bisa diinputkan sendiri oleh pihak puskesmas. Untuk Diagnosa dokter, data-data yang dibutuhkan oleh puskesmas adalah : - Status kasus (kasus baru / kasus lama / kunjungan kasus lama / utama / komplikasi), Anamnesa pasien, Alergi pasien, Hasil diagnosa pasien, Tindakan medis yang diberikan pada pasien, Tindakan obat yang diberikan pada pasien ketika berada di klinik, Resep yang diberikan pada pasien, Rujukan pasien ke Instalasi Rawat Inap Dari data-data tersebut, puskesmas mengharapkan adanya laporan hasil diagnosa dokter untuk setiap pasien yang hanya bisa dilihat oleh dokter saat itu sedang melakukan diagnose pada pasien. Selain itu dokter juga diharapkan bisa melihat histori dari pasien-pasien yang pernah di diagnosanya untuk melakukan cek ulang apakah tindakan yang dilakukan sudah benar. Hal yang paling penting adalah hasil diagnosa tidak bisa diubah oleh siapapun apabila hasil diagnose sudah disimpan kedalam sistem. Untuk administrasi Instalasi Rawat Jalan, fungsifungsi yang dapat dilakukan adalah : - Melakukan pengelolaan klinik yang tersedia di instalasi rawat jalan - Melakukan pengelolaan data tindakan medis dan obat yang tersedia di instalasi rawat jalan. - Melakukan pengelolaan user dokter dan perawat yang bisa masuk ke dalam aplikasi instalasi rawat jalan B. Katalog Servis Katalog servis memberikan keterangan servisservis yang terjadi di antar modul di sistem informasi rumah sakit
Gambar 3. katalog servis Pada Katalog Servis di gambar 3 terlihat bahwa service yang berhubungan dengan aplikasi Instalasi Rawat Jalan adalah: - Modul Rekam Medis
Mendapatkan list daftar pasien dari modul rekam medis o Mendapatkan informasi detail pasien dengan parameter id pasien dari modul rekam medis o Mendapatkan informasi detail pasien dengan parameter nomor Rekam Medis Pasien dari modul rekam medis o Mendapatkan list daftar layanan tindakan medis dan tindakan pengobatan dari modul rekam medis o Mendapatkan informasi detail layanan tindakan medis dan tindakan pengobatan dari modul dengan parameter id layanan dari modul rekam medis o Mendapatkan list anamnesa pasien dengan parameter id pasien dari modul rekam medis o Mendaptkan detail anamnesa pasien dengan parameter id anamnesa dari modul rekam medis o Mendapatkan list tindakan medis dan tindakan pengobatan yang didapatkan pasien dengan parameter id pasien dari modul rekam medis o Mendapatkan detail tindakan medis atau tindakan pengobatan yang didapatkan pasien dengan parameter id tindakan dari modul rekam medis o Mengirimkan data anamnesa pasien yang di diagnosa untuk disimpan di modul rekam medis o Mengirimkan data tindakan medis atau tindakan pengobatan pasien yang di diagnosa untuk disimpan di modul rekam medis o Mengirimkan data pasien baru yang registrasi untuk disimpan di modul rekam medis. o Mengirimkan data anamnesa pasien yang didiagnosa untuk diedit di modul rekam medis o Mengirimkan data tindakan medis atau tindakan pengobatan pasien yang di diagnosa untuk diedit di modul rekam medis o Mengirimkan data pasien baru yang registrasi untuk diedit di modul rekam medis o Mengirimkan data tindakan medis atau tindakan pengobatan pasien yang di diagnosa untuk dihapus di modul rekam medis Modul Instalasi rawat jalan o
-
Mengirimkan data pasien yang akan di rujuk ke instalasi rawat jalan - Modul Point of Sales o Mengirimkan data tindakan medis atau tindakan pengobatanyang dilakukan terhadap pasien ke modul Point of Sales - Modul Human Resources o Mengirimkan username dan password ke modul human resources untuk kemudian mendapatkan return value entity user, jika tidak cocok maka nilai kembaliannya adalah null. C. Arsitektur Teknis Pada bagian ini akan diberikan gambaran arsitektur teknis yang digunakan dalam pengembangan aplikasi IRJA, arsitektur yang digunakan untuk membentuk tampilan pada aplikasi adalah menggunakan framework Vaadin yang merupakan salah satu framework pada JAVA untuk membangun aplikasi web. Berikut adalah technical architecture yang digunakan pada Vaadin seperti yang tampak pada gambar 4 o
Gambar 4. Arsitektur Vaadin Terdapat 2 skenario untuk data binding di aplikasi IRJA : • Melalui database aplikasi IRJA Apabila aplikasi IRJA merupakan aplikasi yang stand alone, maka data binding dilakukan lewat nilai kembalian dari JPA yang merupakan entity ataupun list entity dimana data didapatkan dari database lokal dari Instalasi Rawat Jalan. • Melalui web service modul Rekam Medis Apabila aplikasi IRJA sudah melakukan koneksi servis dengan modul lain, maka data binding dilakukan lewat nilai kembalian dari JPA, namun sumber datanya berasal dari servis Rekam Medis dimana data kembalian dari modul Rekam Medis dilakukan mapping untuk bisa dibuat entity yang sama dengan entity sejenis yang terdapat pada aplikasi IRJA.
Diagram alur dari kedua penjelasan diatas dapat dilihat pada gambar 5 dibawah ini
Gambar 5. Arsitektur Aplikasi IRJA (flow-based) Kemudian pada gambar 6 merupakan gambar diagram arsitektur secara “stack-based”,
Gambar 6. Arsitektur Aplikasi IRJA (stack-based)
4. Implementasi dan Uji Coba Sistem A. Konfigurasi ESB Enterprise Service Bus yang digunakan dalam implementasi tugas akhir ini adalah WSO2 Enterprise Service Bus. Berikut adalah beberapa alas an mengapa dipilih WSO2 dibanding dengan vendor penyedia Enterprise Service Bus lainnya - Konfigurasi yang mudah karena adanya GUI yang cukup membantu dalam penggunan modul ESB - Open source, sehingga tidak memerlukan biaya tambahan untuk implementasi ESB menggunakan WSO2 Berikut adalah konfigurasi-konfigurasi yang harus dilakukan pada wso2 untuk bisa dipakai menjadi server ESB : i. Setting file axis2.xml pada wso2 Mengatur nilai parameter port, non-blocking, bind-addres, WSDLEPRPrefix pada transportReceiver http dan https agar server esb
mengetahui ip server dimana user mengekstrak wso2. ii. Membuat EndPoint Fungsi endpoint adalah untuk mengetahui dimana target atau server servis berada. iii. Membuat Proxy Service Fungsi dari proxy service adalah sebagai alamat url service yang nantinya akan diakses oleh aplikasi yang berfungsi menjadi sebagai client. iv. Setting proxy service parameter Fungsi dari setting proxy service parameter adalah agar file wsdl yang di daftarkan pada esb server tidak di transformasikan ke format standard yang ditetapkan oleh esb server. B. Konfigurasi Client Web Service Untuk membuat client webservice pada aplikias IRJA, digunakan client web service bawaan dari netbeans yang kemudian hanya perlu memasukkan WSDL URL dari server web service, Karena sudah ada ESB yang menjembatani, maka path wsdl ke server modul Rekam Medis, IRNA, dan Point of Sales menggunakan wsdl yang ada pada proxy service di WSO2. Berikut adalah url yang digunakan untuk masing-masing modul yang terintegrasi : - Rekam Medis : http://ip_server_esb/services/proxy_service_reka mMedis?wsdl - IRNA : http://ip_server_esb/services/proxy_service_IRN A?wsdl - Point of Sales: http://ip_server_esb/services/proxy_service_Poin t_of_Sales?wsdl Dengan memasukkan alamat wsdl itu, secara otomatis netbeans akan melakukan generate methodmethod yang tersedia di server web service sekaligus membuat objek-objek yang digunakan sebagai parameter ataupun return value dalam setiap servis tersebut. C. Uji Coba Sistem Tahapan ini meliputi 2 tahapan pengujian, yaitu 1) uji coba fungsional menggunakan unit test, yaitu test case yang telah dibuat sebelumnya. Dari hasil uji coba ini, aplikasi ini telah menunjukkan pemenuhan kebutuhan fungsional.. 2) Uji coba Non Fungsional atau uji coba performa sistem. Untuk uji coba performa ini dilakukan terlebih dahulu dengan menggunakan Apache Benchmark untuk mendapatkan halaman yang memiliki request time paling lama, kemudian halaman yang paling lambat tersebut diuji lagi dengan menggunakan fitur yang ada pada Netbeans 6.8 yaitu profiler project. Dengan menggunakan fitur ini, dapat terlihat method mana yang membuat load time menjadi lama, sehingga bisa dilakukan optimasi lebih lanjut pada method atau
fungsi tersebut. Berikut pada tabel 1adalah hasil uji performa dengan Apache Benchmark pada aplikasi IRJA. Setting yang dilakukan pada saat melakukan uji coba adalah menggunakan parameter –n sebesar 1000 yang artinya total request yang dilakukan adalah 1000 request, sedangkan untuk parameter –c diubah-ubah mulai dari 10 sampai 100 untuk bisa mendapatkan grafik dari halaman yang paling sedikit request per second nya : Tabel 1 Hasil uji coba dengan Apache Benchmark Nama Halaman Halaman Login Halaman Registrasi Pasien Halaman Antrian Halaman Diagnosa Pasien
Request per second (second) 10 50 100 concurrent concurrent concurrent user user user 24.13 20.68 59.08 16.19
15.45
12.64
10.31
11.83
12.56
4.45
4.20
2.22
Dari tabel hasil uji coba, maka dapat diambil kesimpulan bahwa halaman yang paling banyak memakan resource adalah halaman diagnosa pasien. Oleh karena itu halaman diagnose pasien akan kembali di uji performa menggunakan Netbeans profiler untuk mendapatkan method atau fungsi yang menyebabkan kelambatan request. Pengujian yang selanjutnya adalah menggunakan netbeans profiler. Dari hasil profiling diatas, didapatkan 5 method yang memakan menghasilkan load time paling lama seperti yang ditampilkan pada gambar 7, yaitu :
Gambar 7. Top 5 method penghasil load time paling lama Analisis yang dapat diambil dari 5 method penghasil load time paling banyak bahwa yang membuat aplikasi berjalan lambat adalah pada JPAcontroller pengguna pada method init() dan getEntityManager(), hal ini bisa disebabkan karena pengguna dijadikan session pada aplikasi pada vaadin untuk dijadikan penentu hak akses bagi user, selain itu pada hak akses pada aplikasi ini sering dipanggil untuk penentuan menu kiri aplikasi. Hal ini juga bisa disebabkan karena teknologi JPA EclipseLink yang digunakan pada aplikasi membuat init dan getEntityManager pada pengguna menjadi lambat. Pada top 5 juga terdapat method find di berbagai class JPAcontroller, jadi semakin banyak yang dilakukan find pada JPAcontroller maka bisa jadi load time menjadi lebih banyak. Dapat diambil
analisis juga apabila web service dilakukan pada method find ini maka dapat dimungkinkan waktu load aplikasi akan semakin lama karena dari invocation nya saja, untuk method find ini sangat sering diakses, karena apabila dilakukan web service maka akan terjadi waktu tambahan untuk mengambil data daripada mengakses langsung lewat database IRJA.
5. Kesimpulan Berdasarkan hasil penelitian tugas akhir ini, maka dapat disimpulkan beberapa hal sebagai berikut: 1. Aplikasi Instalasi Rawat Jalan(IRJA) yang dibangun telah mampu terintegrasi dengan modul Rekam Medis, Point of Sales, dan Instalasi Rawat Inap(IRNA) dengan menggunakan teknologi web service SOAP. 2. Fitur-fitur yang tersedia pada aplikasi IRJA adalah manajemen master tindakan, manajemen klinik, manajemen pasien, manajemen antrian, pembuatan diagnosa dan tindakan terhadap pasien, dan histori medis pasien, dimana kesemua fitur tersebut dapat terintegrasi dengan modul Rekam Medis. Untuk integrasi dengan modul Point of Sales terdapat pada fitur pembuatan tindakan medis atau obat terhadap pasien. Untuk integrasi dengan modul IRNA, terdapat pada terdapat pasien yang dirujuk ke IRNA. 3. Implementasi fungsi ESB yang dipakai di WSO2 adalah pemanfaatan fungsi Endpoint dan Proxy Service yang berguna untuk mengarahkan server dari web service yang ada pada modul Rekam Medis, IRNA, dan Point of Sales. 4. Apabila terjadi perubahan letak alamat IP server, maka IP yang baru bisa diubah pada setting endpoint di WSO2 tanpa perlu melakukan konfigurasi server secara manual di aplikasi Instalasi Rawat Jalan. 5. Hindari pemanggilan akses data lewat web service di method yang sering diakses karena akan memperlambat waktu load dari aplikasi. Usahakan untuk menyimpan data yang sering di akses oleh aplikasi di database lokal aplikasi. Contoh method yang cukup banyak diakses pada aplikasi IRJA adalah method find() di JPAcontroller, jadi usahakan untuk method ini akses datanya melalui database lokal aplikasi.
6. Daftar Pustaka [1]Christensen, E. d. (2001, March 2001). Web Services Description Language (WSDL) 1.1. Retrieved July 18, 2011, from w3c: http://www.w3.org/TR/wsd [2]Juric, M. B., Loganathan, R., Sarang, P., & Jennings, F. (2007). SOA Approach to Integration. i M. B. Juric, R.
Loganathan, P. Sarang, & F. Jennings, SOA Approach to Integration (ss. 43-45). Birmingham-Mumbai: PACKT Publishing. [3]Mahananto, F., P.W., Radityo., N.A., Ahmad Holil., & E.R., Mahendrawathi. (2010). OHIS: SOA Based Growable Healthcare Information System. JICA PREDICT-ITS , 1-8. [4]Quin, L. (2011, April 23). Extensible Markup Language (XML). Retrieved July 18, 2011, from w3c: http://www.w3.org/XML/ [5]w3schools. (n.d.). SOAP Tutorial. Retrieved July 18, 2011, from w3schools.com: http://www.w3schools.com/soap/default.asp
