Rancang Bangun Aplikasi Instalasi Rawat Jalan dengan Paradigma Pengembangan Terintegrasi Menggunakan Enterprise Service Bus (ESB)

Transkripsi

1 Rancang Bangun Aplikasi Instalasi Rawat Jalan dengan Paradigma Pengembangan Terintegrasi Menggunakan Enterprise Service Bus (ESB) Aditya Oktalifryan*, Bambang Setiawan, Radity Prasetiant Wibw Jurusan Sistem Infrmasi, Fakultas Teknlgi Infrmasi, Institut Teknlgi Sepuluh Npember, Surabaya, Indnesia * aditya.ryan1@gmail.cm 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. Metde yang bisa dirujuk untuk mengatasi hal tersebut adalah menggunkan Service-Oriented Architecture (SOA). Selain itu, juga terdapat teknlgi yang memiliki kemampuan sebagai suatu jembatan/middleware yang bisa mengenal dan mentransfrmasi service dari suatu mdul agar bisa dibaca leh mdul lain, yaitu Enterprise Service Bus (ESB). Dengan teknlgi ESB, walaupun dikembangkan leh vendr aplikasi ataupun bahasa pemrgraman dan menggunakan atau menyediakan service dengan standarisasi yang berbeda karena, mdul IRJA tetap bisa diintegrasikan dengan mdul lain yang ada di Sistem Infrmasi Rumah Sakit. Hasil yang dicapai dari Tugas Akhir ini adalah aplikasi Instalasi Rawat Jalan yang terintegrasi dengan mdul Rekam Medis, Instalasi Rawat Inap (IRNA) dan Pint f Sales yang terdapat pada Sistem Infrmasi Rumah Sakit. Enterprise Service Bus(ESB) yang digunakan pada implementasi adalah WSO2 yang merupakan versi GUI dari Synapse. Fungsi ESB yang digunakan adalah menggunakan Endpint dan juga Prxy Service dari WSO2 untuk mengarahkan service ke server tujuan dari web service. Kata Kunci : Instalasi Rawat Jalan, Sistem Infrmasi Rumah Sakit, Enterprise Service Bus. 1. Pendahuluan Rumah Sakit sebagai penyedia layanan kesehatan memiliki berbagai unit bisnis yang saling terkait, seperti Aptek, Instalasi Rawat Inap(IRNA),Instalasi Rawat jalan (IRJA), Labratrium, 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 metde yang bisa dirujuk untuk mengatasi hal tersebut adalah menggunakan framewrk Organic Healthcare Infrmatin System (OHIS). Framewrk ini sendiri fkus pada cara untuk mengintegrasikan antar mdul aplikasi dalam tiap unit bisnis pada sistem infrmasi suatu rumah sakit. Dasar teknlgi yang pada framewrk OHIS adalah Service-Oriented Architecture (SOA). Masalah muncul ketika seluruh aplikasi tersebut memang sudah dirancang untuk bisa saling terintegrasi dengan menyiapkan webservice ataupun teknlgi integrasi lain pada aplikasinya Untuk mengatasi masalah tersebut, terdapat suatu teknlgi yang bernama Enterprise Service Bus (ESB) yang mampu menerjemahkan setiap teknlgi integrasi dari aplikasi yang akan diintegrasikan agar bisa dibaca pada masing-masing leh aplikasi tersebut. Dengan adanya ESB, maka aplikasi-aplikasi pada setiap unit bisnis rumah sakit bisa terintegrasi walaupun dikembangkan dengan menggunakan standar webservice yang berbedabeda. Teknlgi Webservice yang digunakan adalah sesuai dengan yang digunakan pada framewrk OHIS, yaitu menggunakan standar webservice SOAP. Sedangkan untuk Integrasi antar mdul yang ada pada mdul IRJA adalah dengan mdul keuangan, rekam, IRNA, dan kepegawaian. Dengan dibangunnya mdul aplikasi IRJA dengan menerapkan framewrk OHIS, rumah sakit dapat menyediakan infrmasi dan data-data yang diperlukan bagi setiap departemen secara knsisten karena saling terintegrasinya infrmasi antar unit bisnis. Selain itu dengan diterapkannya framewrk OHIS, diharapkan dapat menjadi slusi lw-cst bagi manajemen rumah sakit dalam mengembangkan mdul aplikasi, karena sifatnya

2 yang rganic membuat aplikasi lain bisa dikembangkan tanpa harus mengganti keseluruhan sistem yang sudah ada 2. Tinjauan Pustaka A. Framewrk OHIS OHIS adalah suatu framewrk yang memberikan slusi alternatif bagi pengembangan sistem infrmasi rumah sakit dengan hanya membuat desain perangkat lunak sebagai mdul service dan membuat database untuk tiap mdul untuk bisa mengimplementasikannya[3]. Dengan diterapkannya OHIS, pengembang bisa melakukan pembangunan aplikasi dimulai dari yang kecil ataupun menerapkan yang sudah kmpleks sekalipun dikarenakan sudah adanya standar framewrk dalam penulisan kde pada setiap aplikasi baru yang akan dibuat. Selain itu, juga terdapat dukungan framewrk SOA didalam OHIS yang menggunakan teknlgi webservice yang mampu mengintegrasikan antar mdul pada framewrk OHIS. Hal yang juga penting pada framewrk ini adalah adanya service lcatr,service lader, dan service requester yang memungkinkan untuk terjadinya integrasi antar mdul, seperti yang terdapat pada gambar 1 dibawah ini : Gambar 1 Arsitektur Framewrk OHIS B. Web Service Teknlgi web service memberikan kemudahan untuk mengakses infrmasi dari berbagai sumber tanpa mempedulikan database apa yang digunakan leh server yang memberikan infrmasi kepada aplikasi yang menjadi klien web service tersebut. Web service sebenarnya adalah kumpulan dari fungsi dan methd yang terletak pada suatu server web service yang dapat di request leh klien dengan memanggil methd yang disediakan leh server web service, klien sendiri bisa bebas dikembangkan menggunakan bahasa pemrgraman maupun berjalan di platfrm apa saja Berikut adalah kmpnen 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 berkmunikasi dengan aplikasi-aplikasi yang terhubung di dalamnya, sepanjang aplikasi yang terhubung tersebut bisa menerjemahkan tag XML yang diterima atau dikirim untuk dilah menjadi data yang sesungguhnya. [4] ii. Simple Object Access Prtcl (SOAP) SOAP merupakan suatu frmat standar dari XML yang dapat diterjemahkan leh web service untuk melakukan prses request dan respnse antara klien dan server web service yang menggunakan prtkl Hypertext Transfer Prtcl (HTTP) sebagai prtkl pengiriman datanya. SOAP memiliki 3 struktur utama yaitu : SOAP envelpe, SOAP header dan SOAP bdy.[5] iii. Web Service Definitin Language (WSDL) WSDL merupakan suatu dkumen dalam frmat XML yang berisikan penjelasan suatu infrmasi 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 methd-mehd apa yang bisa dipanggil, apa saja parameternya yang dibutuhkan dalam melakukan request, apa saja hasil respn setelah melakukan request dan juga termasuk tipe data yang dibutuhkan saat melakukan request dan tipe data yang dikembalikan saat respn 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 leh webservice, seperti : Integrasi antar webservice dan teknlgi middleware yang berbeda, Tingkat keamanan, ketergantungan dan rbustness yang tinggi Kntrl dan pengellaan dari kmunikasi dan servis dari webservice ESB mampu mengntrl, menjembatani antar web service agar dapat saling berhubungan dengan jangkauan yang lebih luas, kmpleks, dan mudah. ESB menyediakan suatu service platfrm dalam sebuah bus yang mengkneksikan seluruh service yang ada pada enterprise. Beberapa knsep dari ESB adalah : - ESB menyediakan lingkungan ekseskusi service tingkat enterprise (enterprise-grade)

3 - ESB menyediakan sebuah service bus yang membuat service dapat diakses dalam skala enterprise [2] Dengan penggunaan ESB, maka akan semakin meningkatkan kemampuan mdularitas pada OHIS, karena semakin dimungkinkan mengembangkan mdul-mdul lain yang menggunakan webservice ataupun teknlgi yang berbeda dengan yang sudah dipakai leh mdul-mdul 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 fungsinal dari hasil survey di Puskesmas daerah Bendul Merisi Surabaya. Setelah melakukan survey, berikut adalah kebutuhan-kebutuhan menu yang bisa dibutuhkan leh puskesmas : registrasi pasien, pengellaan antrian instalasi rawat jalan, diagnsa dkter, dan administrasi Instalasi Rawat Jalan. Untuk registrasi pasien, data-data yang dibutuhkan leh puskesmas adalah : - Nama Pasien, Jenis kelamin, Tempat / tanggal lahir, Telepn, Alamat, Agama, Pekerjaan, Status nikah, Tipe Asuransi (ASKES / ASKESKIN) Dari registrasi ini maka pasien tersebut akan mendapatkan n RM yang menjadi ID dari pasien tersebut ketika akan melakukan pendaftaran antrian di Instalasi Rawat Jalan maupun di Instalasi Rawat Inap. Untuk Pengellaan antrian, data-data yang dibutuhkan leh puskesmas adalah : - N RM Pasien, Jenis Klinik, Tanggal antri Dari data-data tersebut, puskesmas juga mengharapkan adanya lapran yang bisa menampilkan rekapitulasi jumlah pasien yang mengantri di tiap klinik dengan jangka waktu tertentu yang bisa diinputkan sendiri leh pihak puskesmas. Untuk Diagnsa dkter, data-data yang dibutuhkan leh puskesmas adalah : - Status kasus (kasus baru / kasus lama / kunjungan kasus lama / utama / kmplikasi), Anamnesa pasien, Alergi pasien, Hasil diagnsa pasien, Tindakan yang diberikan pada pasien, Tindakan bat 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 lapran hasil diagnsa dkter untuk setiap pasien yang hanya bisa dilihat leh dkter saat itu sedang melakukan diagnse pada pasien. Selain itu dkter juga diharapkan bisa melihat histri dari pasien-pasien yang pernah di diagnsanya untuk melakukan cek ulang apakah tindakan yang dilakukan sudah benar. Hal yang paling penting adalah hasil diagnsa tidak bisa diubah leh siapapun apabila hasil diagnse sudah disimpan kedalam sistem. Untuk administrasi Instalasi Rawat Jalan, fungsifungsi yang dapat dilakukan adalah : - Melakukan pengellaan klinik yang tersedia di instalasi rawat jalan - Melakukan pengellaan data tindakan dan bat yang tersedia di instalasi rawat jalan. - Melakukan pengellaan user dkter dan perawat yang bisa masuk ke dalam aplikasi instalasi rawat jalan B. Katalg Servis Katalg servis memberikan keterangan servisservis yang terjadi di antar mdul di sistem infrmasi rumah sakit Gambar 3. katalg servis Pada Katalg Servis di gambar 3 terlihat bahwa service yang berhubungan dengan aplikasi Instalasi Rawat Jalan adalah: - Mdul Rekam Medis

4 Mendapatkan list daftar pasien dari mdul rekam Mendapatkan infrmasi detail pasien dengan parameter id pasien dari mdul rekam Mendapatkan infrmasi detail pasien dengan parameter nmr Rekam Medis Pasien dari mdul rekam Mendapatkan list daftar layanan tindakan dan tindakan pengbatan dari mdul rekam Mendapatkan infrmasi detail layanan tindakan dan tindakan pengbatan dari mdul dengan parameter id layanan dari mdul rekam Mendapatkan list anamnesa pasien dengan parameter id pasien dari mdul rekam Mendaptkan detail anamnesa pasien dengan parameter id anamnesa dari mdul rekam Mendapatkan list tindakan dan tindakan pengbatan yang didapatkan pasien dengan parameter id pasien dari mdul rekam Mendapatkan detail tindakan atau tindakan pengbatan yang didapatkan pasien dengan parameter id tindakan dari mdul rekam Mengirimkan data anamnesa pasien yang di diagnsa untuk disimpan di mdul rekam Mengirimkan data tindakan atau tindakan pengbatan pasien yang di diagnsa untuk disimpan di mdul rekam Mengirimkan data pasien baru yang registrasi untuk disimpan di mdul rekam. Mengirimkan data anamnesa pasien yang didiagnsa untuk diedit di mdul rekam Mengirimkan data tindakan atau tindakan pengbatan pasien yang di diagnsa untuk diedit di mdul rekam Mengirimkan data pasien baru yang registrasi untuk diedit di mdul rekam Mengirimkan data tindakan atau tindakan pengbatan pasien yang di diagnsa untuk dihapus di mdul rekam - Mdul Instalasi rawat jalan Mengirimkan data pasien yang akan di rujuk ke instalasi rawat jalan - Mdul Pint f Sales Mengirimkan data tindakan atau tindakan pengbatanyang dilakukan terhadap pasien ke mdul Pint f Sales - Mdul Human Resurces Mengirimkan username dan passwrd ke mdul human resurces untuk kemudian mendapatkan return value entity user, jika tidak cck 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 framewrk Vaadin yang merupakan salah satu framewrk pada JAVA untuk membangun aplikasi web. Berikut adalah technical architecture yang digunakan pada Vaadin seperti yang tampak pada gambar 4 Gambar 4. Arsitektur Vaadin Terdapat 2 skenari untuk data binding di aplikasi IRJA : Melalui database aplikasi IRJA Apabila aplikasi IRJA merupakan aplikasi yang stand alne, maka data binding dilakukan lewat nilai kembalian dari JPA yang merupakan entity ataupun list entity dimana data didapatkan dari database lkal dari Instalasi Rawat Jalan. Melalui web service mdul Rekam Medis Apabila aplikasi IRJA sudah melakukan kneksi servis dengan mdul lain, maka data binding dilakukan lewat nilai kembalian dari JPA, namun sumber datanya berasal dari servis Rekam Medis dimana data kembalian dari mdul Rekam Medis dilakukan mapping untuk bisa dibuat entity yang sama dengan entity sejenis yang terdapat pada aplikasi IRJA.

5 Diagram alur dari kedua penjelasan diatas dapat dilihat pada gambar 5 dibawah ini Gambar 5. Arsitektur Aplikasi IRJA (flw-based) Kemudian pada gambar 6 merupakan gambar diagram arsitektur secara stack-based, Gambar 6. Arsitektur Aplikasi IRJA (stack-based) 4. Implementasi dan Uji Cba Sistem A. Knfigurasi 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 vendr penyedia Enterprise Service Bus lainnya - Knfigurasi yang mudah karena adanya GUI yang cukup membantu dalam penggunan mdul ESB - Open surce, sehingga tidak memerlukan biaya tambahan untuk implementasi ESB menggunakan WSO2 Berikut adalah knfigurasi-knfigurasi yang harus dilakukan pada ws2 untuk bisa dipakai menjadi server ESB : i. Setting file axis2.xml pada ws2 Mengatur nilai parameter prt, nn-blcking, bind-addres, WSDLEPRPrefix pada transprtreceiver http dan https agar server esb mengetahui ip server dimana user mengekstrak ws2. ii. Membuat EndPint Fungsi endpint adalah untuk mengetahui dimana target atau server servis berada. iii. Membuat Prxy Service Fungsi dari prxy service adalah sebagai alamat url service yang nantinya akan diakses leh aplikasi yang berfungsi menjadi sebagai client. iv. Setting prxy service parameter Fungsi dari setting prxy service parameter adalah agar file wsdl yang di daftarkan pada esb server tidak di transfrmasikan ke frmat standard yang ditetapkan leh esb server. B. Knfigurasi 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 mdul Rekam Medis, IRNA, dan Pint f Sales menggunakan wsdl yang ada pada prxy service di WSO2. Berikut adalah url yang digunakan untuk masing-masing mdul yang terintegrasi : - Rekam Medis : mmedis?wsdl - IRNA : A?wsdl - Pint f Sales: t_f_sales?wsdl Dengan memasukkan alamat wsdl itu, secara tmatis netbeans akan melakukan generate methdmethd yang tersedia di server web service sekaligus membuat bjek-bjek yang digunakan sebagai parameter ataupun return value dalam setiap servis tersebut. C. Uji Cba Sistem Tahapan ini meliputi 2 tahapan pengujian, yaitu 1) uji cba fungsinal menggunakan unit test, yaitu test case yang telah dibuat sebelumnya. Dari hasil uji cba ini, aplikasi ini telah menunjukkan pemenuhan kebutuhan fungsinal.. 2) Uji cba Nn Fungsinal atau uji cba perfrma sistem. Untuk uji cba perfrma 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 prfiler prject. Dengan menggunakan fitur ini, dapat terlihat methd mana yang membuat lad time menjadi lama, sehingga bisa dilakukan ptimasi lebih lanjut pada methd atau

6 fungsi tersebut. Berikut pada tabel 1adalah hasil uji perfrma dengan Apache Benchmark pada aplikasi IRJA. Setting yang dilakukan pada saat melakukan uji cba adalah menggunakan parameter n sebesar 1000 yang artinya ttal 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 secnd nya : Tabel 1 Hasil uji cba dengan Apache Benchmark Nama Lgin Registrasi Pasien Antrian Diagnsa Pasien Request per secnd (secnd) 50 cncurrent user user 10 cncurrent user 100 cncurrent Dari tabel hasil uji cba, maka dapat diambil kesimpulan bahwa halaman yang paling banyak memakan resurce adalah halaman diagnsa pasien. Oleh karena itu halaman diagnse pasien akan kembali di uji perfrma menggunakan Netbeans prfiler untuk mendapatkan methd atau fungsi yang menyebabkan kelambatan request. Pengujian yang selanjutnya adalah menggunakan netbeans prfiler. Dari hasil prfiling diatas, didapatkan 5 methd yang memakan menghasilkan lad time paling lama seperti yang ditampilkan pada gambar 7, yaitu : Gambar 7. Tp 5 methd penghasil lad time paling lama Analisis yang dapat diambil dari 5 methd penghasil lad time paling banyak bahwa yang membuat aplikasi berjalan lambat adalah pada JPAcntrller pengguna pada methd init() dan getentitymanager(), hal ini bisa disebabkan karena pengguna dijadikan sessin 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 teknlgi JPA EclipseLink yang digunakan pada aplikasi membuat init dan getentitymanager pada pengguna menjadi lambat. Pada tp 5 juga terdapat methd find di berbagai class JPAcntrller, jadi semakin banyak yang dilakukan find pada JPAcntrller maka bisa jadi lad time menjadi lebih banyak. Dapat diambil analisis juga apabila web service dilakukan pada methd find ini maka dapat dimungkinkan waktu lad aplikasi akan semakin lama karena dari invcatin nya saja, untuk methd 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 mdul Rekam Medis, Pint f Sales, dan Instalasi Rawat Inap(IRNA) dengan menggunakan teknlgi web service SOAP. 2. Fitur-fitur yang tersedia pada aplikasi IRJA adalah manajemen master tindakan, manajemen klinik, manajemen pasien, manajemen antrian, pembuatan diagnsa dan tindakan terhadap pasien, dan histri pasien, dimana kesemua fitur tersebut dapat terintegrasi dengan mdul Rekam Medis. Untuk integrasi dengan mdul Pint f Sales terdapat pada fitur pembuatan tindakan atau bat terhadap pasien. Untuk integrasi dengan mdul IRNA, terdapat pada terdapat pasien yang dirujuk ke IRNA. 3. Implementasi fungsi ESB yang dipakai di WSO2 adalah pemanfaatan fungsi Endpint dan Prxy Service yang berguna untuk mengarahkan server dari web service yang ada pada mdul Rekam Medis, IRNA, dan Pint f Sales. 4. Apabila terjadi perubahan letak alamat IP server, maka IP yang baru bisa diubah pada setting endpint di WSO2 tanpa perlu melakukan knfigurasi server secara manual di aplikasi Instalasi Rawat Jalan. 5. Hindari pemanggilan akses data lewat web service di methd yang sering diakses karena akan memperlambat waktu lad dari aplikasi. Usahakan untuk menyimpan data yang sering di akses leh aplikasi di database lkal aplikasi. Cnth methd yang cukup banyak diakses pada aplikasi IRJA adalah methd find() di JPAcntrller, jadi usahakan untuk methd ini akses datanya melalui database lkal aplikasi. 6. Daftar Pustaka [1]Christensen, E. d. (2001, March 2001). Web Services Descriptin Language (WSDL) 1.1. Retrieved July 18, 2011, frm w3c: [2]Juric, M. B., Lganathan, R., Sarang, P., & Jennings, F. (2007). SOA Apprach t Integratin. i M. B. Juric, R.

7 Lganathan, P. Sarang, & F. Jennings, SOA Apprach t Integratin (ss ). Birmingham-Mumbai: PACKT Publishing. [3]Mahanant, F., P.W., Radity., N.A., Ahmad Hlil., & E.R., Mahendrawathi. (2010). OHIS: SOA Based Grwable Healthcare Infrmatin System. JICA PREDICT-ITS, 1-8. [4]Quin, L. (2011, April 23). Extensible Markup Language (XML). Retrieved July 18, 2011, frm w3c: [5]w3schls. (n.d.). SOAP Tutrial. Retrieved July 18, 2011, frm w3schls.cm: