Oleh:
Nama : Priskilla Ucha Raharja NIM : 08.41010.0397
Program : S1 (Strata Satu) Jurusan : Sistem Informasi
SEKOLAH TINGGI
MANAJEMEN INFORMATIKA & TEKNIK KOMPUTER SURABAYA
2013
STIKOM
ix
ABSTRAK ... vi
KATA PENGANTAR ... vii
DAFTAR ISI ... ix
DAFTAR TABEL ... xii
DAFTAR GAMBAR ... xiii
DAFTAR LAMPIRAN ... xv
BAB I PENDAHULUAN ... 1
1.1 Latar Belakang Masalah ... 1
1.2 Perumusan Masalah ... 4
1.3 Pembatasan Masalah ... 4
1.4 Tujuan ... 5
1.5 Sistematika Penulisan ... 5
BAB II LANDASAN TEORI ... 7
2.1 HL7 version 2.5.1 ... 7
2.1.1 Sejarah HL7 ... 8
2.1.2 Struktur HL7 Message version 2 ... 8
2.2 HL7 Message ... 15
2.2.1 OMI^O23 ... 15
2.2.2 ORU^R01 ... 17
2.3 Broker HL7 ... 17
2.4 Radiology Information System ... 19
2.5 PACS ... 19
STIKOM
x
2.8 HAPI v.2.5.1 ... 22
2.9 Use Case Diagram ... 23
2.10 Fitur-fitur Broker HL7 ... 23
BAB III PERANCANGAN SISTEM ... 27
3.1 Identifikasi Permasalahan dan Analisa Kebutuhan Sistem ... 27
3.2 Analisa Kebutuhan Sistem... 29
3.3 Perancangan Sistem ... 31
3.3.1 Rancangan Sistem ... 31
3.3.2 Desain Sistem ... 32
3.4 Usecase Diagram Broker HL7 ... 34
3.5 Squence Diagram Broker HL7 ... 34
3.6 Class Diagram Broker HL7 ... 37
3.7 Desain Database ... 42
3.7.1 ERD Broker HL7 ... 42
3.7.2 Struktur Tabel Broker HL7 ... 42
3.8 User Interface Design ... 45
BAB IV IMPLEMENTASI DAN EVALUASI ... 50
4.1 Kebutuhan Sistem ... 50
4.2 Implementasi Sistem... 51
4.3 Uji Fitur Aplikasi ... 57
BAB V PENUTUP ... 62
5.1 Kesimpulan ... 62
STIKOM
xi
LAMPIRAN ... 65
STIKOM
vi
Banyaknya sistem informasi yang ada di suatu instansi kesehatan menyebabkan komunikasi antar sistem informasi rumah sakit menjadi sangat penting. Rumah sakit yang memiliki sistem informasi lebih dari satu, biasanya tidak berasal dari satu vendor. Setiap vendor pengembang sistem informasi rumah sakit juga menggunakan platform yang berbeda-beda. Contoh rumah sakit yang memiliki perbedaan vendor dan platform adalah National Hospital, sistem informasi yang dimiliki antara lain Radiology Information System (RIS) yang dikembangkan PT. Medixsoft dengan menggunakan platform Java, Picture Archiving and Communication System (PACS) yang dikembangkan PT.
Medixsoft menggunakan platform .Net, Hospital Information System (HIS) yang dikembangkan PT. QPRO Sukses Mandiri menggunakan platform .Net.
Untuk mengatasi masalah komunikasi pada dunia kesehatan, pada tahun 1987 ANSI menciptakan HL7. Dengan adanya HL7 komunikasi antar aplikasi RIS, PACS dan HIS akan dapat diatasi. Masalah yang diatasi dengan HL7 antara lain pasien tidak perlu melakukan registrasi berulang-ulang, tidak terjadi redudan data di database rumah sakit, mempermudah pertukaran data antar sistem informasi yang dimiliki rumah sakit walaupun letaknya berjauhan.
Broker HL7 adalah sistem yang dirancang sebagai antar muka yang
memiliki fungsi mengintegrasikan data pasien antara HIS, RIS dan PACS. Standar HL7 yang dipakai broker HL7 adalah HL7 Message version 2.5.1 bertipe ORU^R01 dan OMI^O23.
Kata kunci : RIS, HIS, PACS, HL7
STIKOM
1 BAB I PENDAHULUAN
1.1Latar Belakang Masalah
Usaha peningkatan kualitas pelayanan kesehatan adalah tanggung jawab besar bagi penyedia layanan medis. Kemudahan dalam mengakses, mengirim dan menerima data adalah hal yang diperlukan untuk meningkatkan kualitas pelayanan kesehatan (Benson T, 2010). Pada tahun 2009 Health Information for Economic and Clinical Health (HITECH) mencetuskan pertukaran data pasien
adalah hal yang dibutuhkan dalam dunia kesehatan. The US Federal Health Information Technology Strategic Plan mengungkapkan pertukaran informasi
kesehatan antar produk sistem teknologi informasi (TI) harus konsisten, data yang spesifik dan memenuhi standar teknis.
Dalam dunia kesehatan, komunikasi berperan penting. Tidak adanya komunikasi antar penyedia layanan medis khususnya dalam bidang radiologi menyebabkan banyak masalah timbul, antara lain (1) proses administrasi yang dilakukan berulang kali setiap datang di rumah sakit, (2) sulitnya membuat dan membaca laporan kesehatan pasien, serta (3) sulitnya komunikasi antar dokter spesialis. Oleh sebab itu dibutuhkan standar pengiriman data, agar data yang dikirim lebih aman, efektif, terpusat kepada pasien, tepat waktu, efisien dan adil (Institute of Medicine 2001).
STIKOM
Ketiadaan standar dalam pertukaran data akan menghambat pelayanan kesehatan yang berbasis teknologi. Dengan adanya standar setiap dokter, pasien dan staff lain dapat dengan mudah membaca data tersebut. Catatan medis yang tidak terorganisir dan tidak terbaca serta sulit dipahami oleh pembaca merupakan suatu hal yang tidak diharapkan (Bleich and Lawrence, 1993).
Untuk menyelesaikan masalah diatas, standar HL7 menjadi solusi utama. Health Level 7 (HL7) adalah salah satu dari beberapa standar American National Standars Institute (ANSI), yang telah diakreditasi oleh Standars Developing
Organizations (SDO). Standarisasi ini dipakai khususnya untuk bidang atau area
healthcare system. HL7 merupakan standar pertukaran data medis yang berbentuk
teks (Benson T, 2010). Contoh pesan yang dikirim oleh HL7 seperti catatan pasien, catatan laboratorium dan informasi pembayaran. Dalam pembuatan HL7 ada beberapa hal yang harus diperhatikan, diantaranya (1) bagaimana membuat standarisasi yang menghubungkan sistem satu ke sistem lain untuk memindahkan data, (2) memastikan sistem-sistem dapat memahami data dengan cara yang sama, (3) memungkinkan proses bisnis dapat bekerja sama (Gibbons et al, 2007).
Standar HL7 (HL7) sangat membantu para penyedia layanan medis dalam mengurangi biaya pembuatan antarmuka, dan mengurangi resiko dalam perpindahan data (Benson T, 2010:6). Dengan adanya HL7, kebutuhan akan antarmuka semakin berkurang karena semua sistem yang membutuhkan data pasien akan terhubung pada satu antarmuka. Banyaknya antarmuka akan menyulitkan setiap penyedia layanan medis dalam mengkomunikasikan data pasien serta memunculkan banyak resiko dalam proses integrasi data antar penyedia layanan medis. Resiko yang sering muncul dalam perpindahan data
STIKOM
antara lain data tidak konsisten, tidak jelas dan tidak bisa terbaca di sistem lain. Inilah yang menjadi bahan pemikiran bagi developer dalam memenuhi kebutuhan pertukaran data dari setiap penyedia layanan medis.
Salah satu sistem informasi yang membutuhkan HL7 adalah Radiology Information System (RIS). RIS merupakan sebuah sistem yang dirancang untuk
mendukung alur kerja operasional dan analisis dalam suatu departemen radiologi (The Royal College of Radiologists, 2008). Solusi yang ditawarkan standar HL7 kepada RIS diantaranya (1) kebutuhan akan penyimpanan data pasien yang sama dapat diminimalisasikan, pasien tidak perlu melakukan registrasi setiap datang ke rumah sakit untuk melakukan pemeriksaan karena data pasien akan diintegrasikan antar penyedia layanan medis, agar tidak terdapat redudansi data pasien di dalam database rumah sakit, (2) perpindahan data antara penyedia layanan medis yang satu dengan yang lain dapat diintegrasikan dengan baik, perbedaan cara penulisan data membuat dokter di setiap rumah sakit kesulitan dalam memahami catatan medis pasien, oleh sebab itu dibutuhkan standar penulisan data agar dokter dapat dengan mudah dalam membuat dan membaca catatan medis pasien, serta (3) mengurangi biaya dalam membuat antarmuka, dimana untuk menghubungkan dua buah sistem harus ada sebuah antarmuka, sedangkan jika terdapat banyak antarmuka yang dibutuhkan membuat para penyedia layanan medis harus mengeluarkan biaya yang banyak untuk membuat antarmuka agar data pasien bisa diintegrasikan (Benson T, 2010:91).
Berdasarkan permasalahan di atas, tugas akhir ini akan menerapkan HL7 pada RIS yang dapat memenuhi kebutuhan para penyedia layanan medis dalam pertukaran data. Para penyedia layanan medis mampu mengintegrasikan data-data
STIKOM
pasien dan catatan medis pasien, sehingga para ahli radiologi mampu mengatasi masalah dalam membuat dan membaca laporan medis pasien.
1.2Perumusan Masalah
Berdasarkan latar belakang yang telah diuraikan di atas, maka dapat dirumuskan permasalahan dalam Tugas Akhir ini, yaitu:
1. Bagaimana membuat broker HL7 dengan menerapkan standar HL7 version 2.5.1.
2. Bagaimana mengintegrasikan RIS, PACS dan HIS.
1.3Batasan Masalah
Dalam pembuatan Tugas Akhir Penerapan Health Level 7 pada Radiolgy Information System ini, ruang lingkup permasalahan dibatasi pada :
1. Sistem ini dibuat untuk integrasi data pasien antar RIS, PACS dan HIS di dalam sebuah rumah sakit.
2. Penerapan HL7 version 2.5.1 akan diintegrasikan dengan RIS dan PACS yang dikembangkan oleh PT. Medixsoft.
3. Penerapan HL7 version 2.5.1 akan diintegrasikan dengan HIS yang dikembangkan oleh PT. QPRO Sukses Mandiri.
4. Sistem yang diterapkan berdasarkan pada standar HL7 version 2.5.1.
5. Pembuatan sistem ini tidak membahas mengenai perangkat keras yang digunakan.
6. Ruang lingkup broker HL7 menggunakan Post Method
7. HL7 Message version 2.5.1 yang akan dibahas adalah ORU^R01 dan OMI^O23
STIKOM
1.4Tujuan
Dengan mengacu pada perumusan masalah maka tujuan yang hendak dicapai dalam penyusunan Tugas Akhir ini adalah membuat broker dengan menerapkan standar HL7 version 2.5.1 untuk mengintegrasikan RIS, PACS dan HIS.
1.5Sistematika Penulisan
Sistematika yang digunakan dalam penulisan Tugas Akhir ini dibagi menjadi beberapa Bab dan Sub-Bab. Adapun pembagian Bab ini sebagai berikut :
BAB I : PENDAHULUAN
Bab ini mengutamakan perumusan dan penjelasan masalah umum dari Health Level 7 (HL7), sehingga dapat diperoleh gambaran umum mengenai seluruh penelitian yang dilakukan oleh penulis. Bab ini menyangkut beberapa masalah yang meliputi : Latar Belakang Masalah, Tujuan, Identifikasi Permasalahan Ruang Lingkup Permasalahan, dan dilanjutkan dengan Sistematika penulisan Tugas Akhir. BAB II : LANDASAN TEORI
Bab ini memberikan uraian tentang teori yang digunakan dalam penyusunan tugas akhir. Menjelaskan tentang standar Health Level 7 (HL7), Radiology Information System (RIS), broker HL7, dan Picture Archiving and Communication System (PACS).
STIKOM
BAB III : METODE PENELITIAN / PERANCANGAN SISTEM Berisi tentang permasalahan yang ada dan solusi yang diajukan dalam pembuatan broker HL7. Dalam bab ini juga membahas use case, class diagram, ERD, rancangan antar muka, dan desain uji coba broker HL7.
BAB IV : IMPLEMENTASI DAN EVALUASI
Menjelaskan tentang spesifikasi kebutuhan dari broker HL7, implementasi broker HL7, uji coba dan analisis hasil
uji coba dari implementasi broker HL7.
BAB V : PENUTUP
Pada bab ini merupakan bab yang berisi tentang kesimpulan dan saran dari perancangan dan pembuatan
STIKOM
7 2.1. Health Level 7 version 2.5.1
Heath Level 7 (HL7) adalah salah satu dari beberapa standard ANSI
(American National Standards Institute), yang telah diakreditasi oleh SDO (Standards Developing Organizations). Standarisasi ini dipakai khususnya untuk bidang atau area healthcare system. HL7 menciptakan standard untuk pertukaran, manajemen, dan integrasi informasi kesehatan elektronik untuk tujuan klinis dan administratif. HL7 tidak mengembangkan perangkat lunak, tetapi hanya menyediakan organisasi kesehatan dengan spesifikasi untuk membuat sistem dapat saling bertukar informasi. HL7 merupakan standard pertukaran data medis yang berbentuk teks (Benson, 2010:91).
HL7 version 2.5.1 menggunakan metodologi yang didefinisikan dengan baik berdasarkan informasi data model. HL7 version 2.5.1 menggunakan analisis yang teliti, teknik penulisan, menggabungkan message dan format message dengan kerumitan lebih sedikit.
Level 7 dari HL7 berasal dari level ketujuh dari Open System Interconnection (OSI). Dimana level ketujuh mempunyai fungsi mengkomunikasikan data antara aplikasi satu dengan aplikasi lainnya. Dengan demikian Health Level 7 memiliki arti komunikasi data kesehatan antar satu aplikasi dengan aplikasi lainnya. (ANSI, 2007)
STIKOM
2.1.1 Sejarah HL7
HL7 version 2 adalah standard pengiriman data yang digunakan paling besar di dunia. Lebih dari 90% rumah sakit yang ada di USA menggunakan HL7 sebagai standard pengiriman data. HL7 pertama kali dikenalkan pada tahun 1987, dengan nama HL7 version 1.0. HL7 version 1.0 hanya fokus pada pertukaran informasi diantaranya admissions, discharges dan transfers (ADT). Pada tahun 1988 HL7 version 2.0 mulai dikenalkan, dengan ada penambahan perlakuan pada permintaan pertukaran dan pembuatan laporan, yang berbasis pada standard ASTM (American Society of Testing and Materials) E.1238.88. Dan pada tahun 1991, version 2.1 mulai dikeanalkan.
HL7 version 2 dikembangkan selama lebih dari 20 tahun. Waktu penulisan, versi yang terakhir adalah versi 2.6, dan standard ANSI telah menyetujuinya. Selama pengembangan beberapa periode lingkup HL7 version 2 mengalami peningkatan besar sekali, tetapi dengan prinsip dasar yang susah untuk dirubah. Standard HL7 version 2.6 sekarang mempunyai 1.965 lembar dan 717.000 kata. Ini adalah alasan mengapa HL7 version 2 mengalami perubahan yang besar sekali dalam informasi kesehatan.
Salah satu prinsip dasar HL7 adalah tetap kompability dengan versi yang lama, walaupun standard telah dikembangkan terus menerus. Ide itu digunakan dalam pembuatan sistem, sistem yang menggunakan versi baru harus dapat mengerti message dari versi lama (Benson T, 2010:93).
2.1.2 Struktur HL7 Message version 2
Struktur HL7 version 2.5.1 terdiri dari namespace, datatype namespace, group namespace, message namespace dan segment namespace.
STIKOM
A. Namespace
Namespace merupakan kelas-kelas yang digunakan oleh datatype.
Tabel 2.1 Tabel contoh namespace
Kelas Deskripsi
DT Date
ID Identifier
IS ID Set
ST Short String
TM Time
B. Datatype Namespace
Datatype merupakan bagian dasar penyusun format HL7 message
version 2.5. Datatype digunakan untuk membangun atau membatasi setiap
elemen. Datatype memiliki 89 macam data, tapi kebanyakan aplikasi HL7 hanya memakai beberapa macam Datatype. (Benson T, 2010:101)
Tabel 2.2 Tabel contoh datatype
Kelas Komponen Datatype
AD (Address) Street ST
Other Designation ST
City ST
State or Province ST
Zip or Postal Code ST
Country ID
Address Type ID
Other Geographic ST
STIKOM
Kelas Komponen Datatype Designation
C. Segment Namespace
Segment didefinisikan sebagai sebuah tabel yang ada di bawah segment
MSH (Message Header). Semua HL7 message version 2 dimulai dengan MSH dan ini merupakan contoh bagaimana sebuah pesan dapat didefinisikan. (Benson, 2010:96)
Segment memiliki field-field, dan setiap field memiliki arti yang
berbeda-beda. Pada pembentukan HL7 message version 2.5.1, setiap field pada segment akan menggantikan setiap data pasien yang ada.
Tabel 2.3 Tabel contoh segment
Segment Field Datatype
ABS ABS-1: Discharge Care Provider XCN
ABS-2: Transfer Medical Service Code CE ABS-3: Severity of Illness Code CE ABS-4: Date/Time of Attestation TS
ABS-5: Attested By XCN
ABS-6: Triage Code CE
ABS-7: Abstract Completion Date/Time TS
ABS-8: Abstracted By XCN
ABS-9: Case Category Code CE ABS-10: Caesarian Section Indicator ID ABS-11: Gestation Category Code CE ABS-12: Gestation Period - Weeks NM
ABS-13: Newborn Code CE
ABS-14: Stillborn Indicator ID
ACC ACC-1: Accident Date/Time TS
STIKOM
Segment Field Datatype
ACC-2: Accident Code CE
ACC-3: Accident Location ST
ACC-4: Auto Accident State CE ACC-5: Accident Job Related Indicator ID ACC-6: Accident Death Indicator ID
ACC-7: Entered By XCN
ACC-8: Accident Description ST
ACC-9: Brought In By ST
ACC-10: Police Notified Indicator ID ACC-11: Accident Address XAD
D. Message Namespace
Message Namespace merupakan struktur message. Message namespace
menggabungkan setiap segmen dari message. Setiap kelas dalam message namespace memiliki kegunaan masing-masing.
Tabel 2.4 Tabel contoh message
Message Segment Deskripsi
ADT 01 0 : MSH Message Header
1 : SFT Software Segment
(optional repeating)
2 : EVN Event Type
3 : PID Patient Identification
4 : PD1 Patient Additional
Demographic (optional) 5 : ROL Role (optional repeating) 6 : NK1 Next of Kin / Associated Parties (optional repeating)
7 : PV1 Patient Visit
8 : PV2 Patient Visit - Additional Information (optional) 9 : ROL Role (optional repeating)
10 : DB1 Disability (optional
STIKOM
Message Segment Deskripsi repeating)
11 : OBX Observation/Result
(optional repeating) 12 : AL1
Patient Allergy Information (optional
repeating)
13 : DG1 Diagnosis (optional
repeating)
14 : DRG Diagnosis Related Group (optional)
15 : ADT_A01_PROCEDURE a Group object
16 : GT1 Guarantor (optional
repeating) 17 : ADT_A01_INSURANCE a Group object
18 : ACC (Accident) optional
19 : UB1 UB82 (optional)
20 : UB2 UB92 Data (optional)
21 : PDA Patient Death and Autopsy (optonal)
ADT 02 0: MSH Message Header
1: SFT Software Segment
(optional repeating)
2: EVN Event Type
3: PID Patient Identification
4: PD1 Patient Additional
Demographic (optional) 5: ROL Role (optional repeating)
6: PV1 Patient Visit
7: PV2 Patient Visit - Additional Information (optional) 8: ROL Role (optional repeating)
9: DB1 Disability (optional
repeating)
10: OBX Observation/Result
(optional repeating) 11: PDA Patient Death and Autopsy
(optional)
STIKOM
E. Group Namespace
Group namespace merupakan sebuah grup dari sekumpulan segmen
message yang dapat diulangi secara bersama-sama atau dipilih untuk dimasukkan
atau dikeluarkan secara bersama-sama. (Benson T, 2010:100)
Tabel 2.5 Group namespace
Message Group Datatype
ABS ABS-1: Discharge Care Provider XCN
ABS-2: Transfer Medical Service Code CE ABS-3: Severity of Illness Code CE ABS-4: Date/Time of Attestation TS
ABS-5: Attested By XCN
ABS-6: Triage Code CE
ABS-7: Abstract Completion Date/Time TS
ABS-8: Abstracted By XCN
ABS-9: Case Category Code CE ABS-10: Caesarian Section Indicator ID ABS-11: Gestation Category Code CE ABS-12: Gestation Period - Weeks NM
ABS-13: Newborn Code CE
ABS-14: Stillborn Indicator ID
ACC ACC-1: Accident Date/Time TS
ACC-2: Accident Code CE
ACC-3: Accident Location ST
ACC-4: Auto Accident State CE ACC-5: Accident Job Related Indicator ID ACC-6: Accident Death Indicator ID
ACC-7: Entered By XCN
ACC-8: Accident Description ST
ACC-9: Brought In By ST
ACC-10: Police Notified Indicator ID
STIKOM
Message Group Datatype ACC-11: Accident Address XAD
F. Delimeters
Untuk menyusun pesan HL7 version 2.5 dibutuhkan Delimeters, yang digunakan untuk memisahkan setiap elemen yang ada.
Tabel 2.6 Simbol delimeters
Simbol Kegunaan
| field separator
^ component separator
~ repetition separator
\ escape character
& subcomponent separator <CR> segment terminator
Field Separator merupakan pembatas antara field satu dengan yang
lainnya. Namun bila ada field yang tidak ada data maka ditulis dengan || . Contohnya pada segmen MSH ada sembilan field, maka disana juga harus ada sembilan field separator untuk membatasi satu dengan yang lainnya.
Component separator merupakan pemisah komponen dalam satu field.
Contohnya ADT^01.
Repetition separator merupakan pemisah bila terjadi pengulangan.
Escape character digunakan untuk menandai di sebuah text bahwa ada perlakuan
khusus. Escape character dapat digunakan mengirim delimeters dengan sebuah
STIKOM
pesan. Dan escape character juga dapat digunakan untuk mengindikasi adanya format. Contohnya seperti \.br\ mengindikasikan baris berakhir, \.sp3\ mengindikasikan akan dilompati 3 ruang di format datatype Formatted Text (FT).
Subcomponent separator digunakan untuk memisahkan antara
sub-komponen dan sub-komponennya.
Segment terminator digunakan untuk mengakhiri segmen yang
menggunakan ASCII. (Benson T, 2010:95)
2.2. HL7 Message
2.2.1 OMI^O23 (Imaging Order Message)
Gambar 2.1 Penggunaan OMI Message
HL7 Message ini digunakan dalam komunikasi antar sistem informasi yang terlibat dalam pemenuhan permintaan yang diarahkan ke departemen pencitraan, seperti Radiologi Information System (RIS) dan Picture Archiving and Communication System (PACS).
STIKOM
Tabel 2.7 Struktur OMI Message
Segmen Description
MSH Message Header, berisi informasi bagaimana message diproses dan diuraikan. Ini termasuk identifikasi message, pengirim, penerima, tipe message, dll.
PID Patient Identification, digunakan untuk menyediakan dasar demografi mengenai subyek pengujian
PV1 Patient Visit, berisi informasi kunjungan pasien di setiap pemeriksaan
ORC Common Order, berisi informasi dasar pengujian setiap order yang diterima. Segmen ini mencakup pengidentifikasi urutan, siapa yang melakukan order, kapan dilakukan order, tindakan apa yang perlu diambil, dll.
OBR Observation Request, berisi informasi permintaan pemeriksaan. OBR mengidentifikasi tipe pemeriksaan yang dilakukan, dan mengunci informasi order
pemeriksaan.
NTE Notes and Comments
2.2.2 ORU^R01
ORU^R01 dibuat untuk mengembalikan hasil pemeriksaan dari RIS ke HIS.
STIKOM
Tabel 2.8 Struktur ORU Message
Segmen Description
MSH Message Header, berisi informasi bagaimana message diproses dan diuraikan. Ini termasuk identifikasi message, pengirim, penerima, tipe message, dll.
OBR Observation Request, berisi informasi permintaan pemeriksaan. OBR mengidentifikasi tipe pemeriksaan yang dilakukan, dan mengunci informasi order
pemeriksaan.
OBX Observation/Result, berisi informasi hasil pemeriksaan yang telah dilakukan. Ini termasuk identifikasi
pemeriksaan, hasil pemeriksaan, kapan pemeriksaan dilakukan, dll.
2.3. Broker HL7
Broker HL7 adalah sebuah aplikasi yang dirancang sebagai antarmuka
antar aplikasi-aplikasi kesehatan yang ada di rumah sakit. Broker menyimpan istilah-istilah yang di pakai dalam standard HL7. Broker bertugas menerjemahkan setiap data pasien menjadi data HL7. Dan dikirim ke setiap aplikasi rumah sakit yang telah memakai standard HL7. Apabila aplikasi rumah sakit tidak memakai standard HL7, maka broker tidak dapat mengirim data ke aplikasi tersebut.
Broker bertugas untuk melakukan seleksi dari setiap data pasien yang diterimanya. Broker secara otomatis akan melakukan disable pada message namespace yang tidak ada datanya. Dan broker akan menujukkan data apa saja
STIKOM
yang dikirim, agar memudahkan dokter dalam memeriksa riwayat pasien. Broker juga akan mencatat setiap pesan yang telah dikirim atau diterima. Apabila terjadi error pada saat pengiriman atau penerimaan data, maka akan muncul informasi pada broker. Dengan adanya informasi ini, admin akan lebih mudah melakukan tracking pada broker.
Keberhasilan pengiriman data menggunakan standard HL7 sangat bergantung pada broker. Oleh sebab itu desain broker yang sederhana, akan memudahkan user dalam menjalankan aplikasi ini. Dengan adanya broker, para dokter tidak perlu ragu apakah data pasien berhasil dikirim atau tidak. Karena pengiriman data akan dipantau terus historinya, dan admin dapat dengan mudah mencari di bagian apa tidak tercapainya pengiriman data. Gagalnya pengiriman dan penerimaan data akan dapat dengan mudah teratasi.
Gambar 2.2 Interface antar aplikasi di rumah sakit
Gambar 2.2 merupakan perbandingan antara rumah sakit yang memakai standard HL7 maupun tidak. Pada rumah sakit yang tidak memakai standard HL7 membutuhkan banyak antar muka agar bisa berkomunikasi satu sama lain. Sedangkan pada rumah sakit yang memakai standard HL7 hanya membutuhkan satu antar muka saja agar bisa berkomunikasi satu dengan lainnya yang disebut dengan broker HL7 (Benson, 2010:26).
STIKOM
2.4. Radiology Information System
Radiology Information System (RIS) merupakan sebuah sistem yang
dirancang untuk mendukung alur kerja operasional dan analisis dalam suatu departemen radiologi. RIS juga merupakan tempat penyimpanan data pasien dan pelaporan data pasien, dan memberikan kontribusi terhadap catatan data pasien secara elektronik, baik sebagai pendiagnosa suatu penyakit maupun sebagai acuan pemberian arah pengobatan bagi para petugas radiologi dalam sebuah rumah sakit (The Royal College of Radiologists, 2008).
RIS adalah penggerak alur kerja departemen radiologi. RIS bertanggung jawab untuk pemesanan penjadwalan, membagikan informasi klinis yang di butuhkan dalam membuat pemesanan penjadwalan dan menyediakan informasi klinis untuk departemen lain yang memerlukannya, mempersiapkan worklist atau daftar kerja modality, dan menyediakan informasi data yang dibutuhkan Picture Archiving and Communication System (PACS) untuk menjalankan perannya.
2.5. PACS
Picture Archiving and Communication System (PACS) adalah filmless
dan metode komputerisasi komunikasi dan menyimpan data gambar medis seperti computed radiographic, digital radiographic, computed tomographic, ultrasound, fluoroscopic, magnetic resonance dan foto X-ray (Tong dkk, 2009). Selama lebih dari 100 tahun, effisiensi praktek radiologi telah dibatasi oleh film dan kegiatan penanganan film, dengan adanya PACS memungkinkan gambar radiologi dapat dilihat secara virtual atau elektronik dimanapun pada computer server ataupun computer personal biasa (Dreyer dkk, 2006).
STIKOM
Akusisi citra adalah titik awal data citra masuk ke PACS dari hasil pemeriksaan citra yang dilakukan oleh berbagai modalitas citra digital (seperti CT - Computed Tomography, MR - Magnetic Resonance, PET - Positron Emission Tomography, US - Ultrasound, XA - XRay Angiography, dll).
Saat citra telah diakusisi, PACS akan mengelolanya dengan tepat untuk memastikan penyimpanan, pengambilan, dan pengiriman seluruh citra dapat dilakukan tanpa kesalahan. Selain itu PACS akan menjamin penyimpanan data citra jangka panjang, dan dapat digunakan kapan saja saat dibutuhkan, secara real time, terutama untuk interpretasi citra. Inti PACS terdiri dari: sistem manajemen database relasional (seperti Oracle, MS-SQL, Sybase), media penyimpan (seperti RAID, Jukebox), software pengendali (image manager), dan antarmuka RIS.
Sistem manajemen database adalah jantung dari PACS. Relasi antara citra dan lokasi penyimpanan disimpan dan dikelola di dalam database, berikut dengan semua data terkait yang dibutuhkan untuk pemanfaatan citra. Sistem manajemen database harus dapat menyediakan data citra berdasarkan pada pencarian pasien atau pemeriksaan tertentu saat diminta (to be queried) oleh RIS atau sistem lainnya.
2.6. Hospital Information System
Hospital Information System (HIS) pada dasarnya adalah sebuah sistem informasi yang membantu para penyedia layanan medis dapat mengelola semua semua informasi secara efektif. HIS ada pertama kali pada tahun 1960 dan dengan seiring waktu mengalami perkembangan. Saat itu HIS masih mengelola penagihan dan persediaan rumah sakit. Sekarang HIS di desain untuk mengatur administrasi,
STIKOM
aspek keuangan dan semua aspek klinis yang ada di rumah sakit (EMR Consultant, 2013).
Rumah sakit yang telah beralih ke HIS memiliki akses informasi yang cepat dan dapat diandalkan termasuk catatan pasien. Catatan pasien yang disimpan dalam HIS lebih detail seperti rekam medis pasien. Keuntungan rumah sakit yang menggunakan HIS adalah (1) memudahkan dokter dalam memproses catatan medis pasien yang bervariasi, (2) membantu pihak yang berwenang di rumah sakit dalam mengembangkan kebijakan, (3) efisien dan akurat dalam mengolah rekam medis pasien, serta (4) meningkatkan pemantauan akan pasien dalam menggunakan obat dan mengurangi redudan data pasien (EMR Consultant, 2013). Fungsi dari HIS antara lain:
1. Menjadi sistem inti di rumah sakit 2. Menjadi sistem pendukung medis 3. Menjadi sistem dokumentasi medis 4. Menjadi sistem manajemen rumah sakit
5. Menjadi sistem komunikasi dan jaringan di rumah sakit 6. Menjadi sistem bisnis dan finansial di rumah sakit
Gambar 2.3 Fungsi dari HIS
STIKOM
2.7. Post Method
Metode pengiriman data dari client ke server yang paling dikenal ada 2 yaitu GET dan POST. GET dan POST dapat mengirim permintaan dan melakukan respon tapi kedua metode ini terdapat perbedaan. Perbedaannya adalah metode GET menggunakan parameter URL, pengiriman data dengan menggunakan metode GET hanya bisa terbatas sedangkan dengan metode POST bisa mengirimkan data ke server dalam jumlah yang besar, metode GET biasanya digunakan untuk menampilkan data (contoh SQL select) dan metode POST digunakan untuk melakukan pembaharuan (contoh SQL insert, SQL update).
Metode POST mengirimkan datanya ke server tidak sebagai bagian dari URL string, tetapi menggunakan bagian dari badan pesan. Metode POST mengirimkan data lebih aman daripada metode GET, karena data yang dikirimkannya tidak terlihat di URL string. Informasi yang sensitif dan bersifat rahasia harus dikirimkan ke server dengan metode POST.
2.8. HAPI V2.5.1
HAPI adalah komponen yang didesain khusus untuk pembuatan HL7 Message. HAPI membantu para developer dalam menerjemahkan data-data pasien
ke dalam pesan HL7 version 2 atau ke format XML. HAPI mengembangkan HL7 Message version 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1 dan 2.6. Komponen HAPI digunakan oleh developer dengan bahasa pemrograman JAVA. HAPI bersifat open-source.
STIKOM
2.9. Use Case Diagram
Use case diagram adalah diagram yang menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Use case diagram juga disebut gambaran graphical dari beberapa atau semua aktor, use case dan interaksi diantara komponen-komponen tersebut yang memperkenalkan suatu sistem yang akan dibangun. Dalam menggambarkan proses sistem, use case diagram menggambarkannya dari sudut pandang user dan memfokuskan pada proses komputerisasi.
2.10. Fitur-Fitur Broker HL7 A. Communication protocol
Communication protocol yang digunakan broker HL7 adalah Simple Object Access Protocol (SOAP). SOAP merupakan standar untuk bertukar
pesan-pesan berbasis XML melalui jaringan komputer atau sebuah jalan untuk program yang berjalan pada suatu sistem operasi (OS) untuk berkomunikasi dengan program pada OS yang sama maupun berbeda dengan menggunakan HTTP dan XML sebagai mekanisme untuk pertukaran data. SOAP menspesifikasikan secara jelas bagaimana cara untuk meng-encode header HTTP dan file XML sehingga program pada suatu komputer dapat memanggil program pada pada komputer lain dan mengirimkan informasi, dan bagaimana program yang dipanggil memberikan tanggapan.
B. Message Tree
Message Tree merupakan salah satu fitur yang ditujukan untuk
menghubungkan antara sistem dengan user. Sintaks HL7 merupakan sederetan baris data pasien yang dirubah menjadi kode yang tidak bisa terbaca oleh user.
STIKOM
Oleh sebab itu, fitur pembacaan sintaks HL7 sangat dibutuhkan. Hasil generate sintaks HL7 disajikan dengan diagram tree. Dengan tujuan agar memudahkan
user membaca dengan cepat data pasien apa saja yang dikirimkan.
Broker akan membaca sintaks HL7 tiap segment yang ada di message. Satu segment akan dirincikan satu per satu field nya. Setiap field pasti memiliki arti yang berbeda-beda, oleh sebab itu broker akan menguraikan HL7 Message agar user tidak mengalami kesulitan dalam membaca arti sintaks HL7.
C. Contol Activity
Control Activity merupakan fitur yang berguna bagi seorang admin
dalam mengatur jalannya pengiriman dan penerimaan HL7 Message. Error sering terjadi pada saat pengiriman maupun penerimaan data, dengan adanya fitur ini admin dapat melihat error apa yang terjadi. Error bisa terjadi di bagian jaringan internet atau message yang dikirimkan tidak sesuai dengan aturan yang ada. Hal ini akan bisa di telusuri oleh control activity dan melaporkannya ke admin.
D. Log Console
Log Console merupakan fitur yang berfungsi sebagai log history. Semua
kegiatan pada broker akan di monitoring dengan ftur ini. Fitur ini akan mencatat semua proses dari seorang admin login, mengaktifkan communication protocol, melakukan pengiriman atau penerimaan data, berhasil atau gagalnya dalam melakukan pengiriman message, dan log off dari broker.
Broker harus terus dipantau kegiatannya, agar tidak terjadi kesalahan
dalam penggunaanya. Fitur ini sangat membantu dalam menganalisa siapa yang mengirim message ke sistem lain maupun menerima message dari sistem lain.
STIKOM
Dengan tujuan data pasien dapat terjaga dengan baik, dan tidak disalah gunakan oleh pihak-pihak yang tidak bertanggung jawab.
E. Integrasi dengan Sistem
Broker terintegrasi dengan beberapa aplikasi yang ada di rumah sakit,
diantaranya PACS, RIS dan sistem informasi lainnya. Setiap perubahan data pasien dan rekam medis pasien yang ada di broker harus merubah data yang ada di setiap sistem yang ada di rumah sakit.
Broker merupakan antar muka setiap sistem yang ada di rumah sakit.
Data pasien dan rekam medis pasien akan selalu berubah, oleh sebab itu broker bertanggung jawab penuh atas perubahan data tersebut. Apabila sebuah sistem terlambat mengetahui perubahan data tersebut, maka akan terjadi kesalahan komunikasi. Sehingga sistem yang lain tidak akan berjalan dengan baik.
F. Read and Write Message
Dengan adanya fitur ini, broker mampu membaca dan menulis HL7 message yang dibutuhkan sistem informasi di rumah sakit. Dalam fitur read
message, peran broker menjadi pembaca HL7 Message yang dikirimkan oleh RIS,
PACS, HIS, dll. Sedangkan pada fitur write message, peran broker sebagai penulis HL7 message yang dibutuhkan oleh RIS, PACS, HIS, dll.
G. Setting MSH
Setting MSH merupakan fitur tambahan yang tidak dimiliki oleh semua
broker HL7 di dunia seperti 7edit, iGuana, HL7Connect, dll. Setting MSH
digunakan untuk merubah data yang ada di MSH seperti merubah sender atau receiver HL7 Message.
STIKOM
Keuntungan dari fitur ini adalah developer tidak perlu merubah koding setiap melakukan penginstalan broker di beberapa rumah sakit. Contoh kasus ketika para developer melakukan penginstalan di Rumah Sakit Adi Husada, MSH HL7 telah ditentukan siapa sender dan receiver. Ketika aplikasi yang sama diinstal di National Hospital, para developer harus merubah MSH nya. Para developer bisa merubah MSH nya melalui fitur setting MSH. Jadi para developer tidak perlu membongkar kodingnya untuk merubah MSH nya.
STIKOM
27 BAB III
PERANCANGAN SISTEM
3.1Identifikasi Permasalahan dan Analisa Kebutuhan Sistem
Komunikasi antar sistem informasi di dunia kesehatan saat ini harus menjadi perhatian yang utama untuk para penyedia layanan medis (Westbrook dkk, 2008). Banyaknya sistem informasi yang ada di instansi kesehatan mewajibkan para penyedia layanan medis harus mencari solusi untuk memecahkan masalah komunikasi. Saat ini yang menjadi kendala utama di bidang kesehatan bukan dari teknologi melainkan dari komunikasi (Benson, 2010).
Rumah sakit yang memiliki sistem informasi lebih dari satu, dan biasanya tidak berdiri pada satu vendor. Contoh sistem informasi yang dimiliki oleh sebuah rumah sakit adalah Laboratory Information System (LIS), Radiology Information System (RIS), Picture Archiving and Communication System (PACS),
Hospital Information System (HIS), dll. Perbedaan vendor dalam sebuah instansi
memicu permasalahan komunikasi diantaranya mampukah sistem A memindahkan data ke sistem B, mampukah sistem A dan sistem B memahami data dengan cara yang sama, serta mampukah sistem A dan sistem B mengkoordinasikan proses kerjanya (Gibbsons dkk, 2007). Seperti perbedaan platform dari setiap sistem informasi yang ada di rumah sakit..
Faktor lain yang menyebabkan komunikasi antar sistem informasi sangat penting adalah letak geografis antara tempat praktik yang satu dengan lainnya berjauhan (Benson, 2010). Contohnya seorang pasien yang periksa di poliklinik dan mendapat rujukan ke rumah sakit di bagian radiologi. Pasien yang telah
STIKOM
melakukan registrasi di poliklinik, harus melakukan registrasi kembali di bagian radiologi. Hal ini menyebabkan redudansi data di database rumah sakit.
Untuk mengatasi masalah komunikasi pada dunia kesehatan, pada tahun 1987 ANSI menciptakan HL7. Dengan adanya HL7 komunikasi antar aplikasi RIS, PACS dan HIS akan diatasi. Pasien tidak perlu melakukan registrasi berulang-ulang, tidak terjadi redudan data di database rumah sakit, mempermudah pertukaran data antar sistem informasi yang dimiliki rumah sakit walaupun letaknya berjauhan, dll. Semua data pasien akan disimpan di dalam server dan akan diintegrasikan ke setiap sistem di rumah sakit dengan HL7.
Broker HL7 adalah salah satu sistem yang dirancang sebagai antar muka
sistem yang ada di rumah sakit. Broker bertugas menerjemahkan setiap data pasien menjadi data HL7 agar bisa dikirim ke setiap sistem yang memakai standard HL7. Fungsi utama dari broker HL7 adalah mengintegrasikan data pasien antar aplikasi seperti HIS, RIS dan PACS (Benson, 2010). Saat ini yang terjadi di dunia kesehatan adalah dua sistem memiliki satu antar muka. Berapa banyak antar muka yang akan dibuat jika sistem yang dipakai lebih dari lima. Namun dengan adanya broker HL7, semua sistem akan diintegrasikan pada satu antar muka saja. Hal ini akan menjadi keuntungan bagi semua pemilik penyedia layanan medis.
Standard HL7 yang dipakai oleh RIS dan PACS adalah HL7 Message bertipe ORU^R01 dan OMI^O23. HL7 Message version 2.5.1 bertipe ORU^R01 berfungsi mengirim hasil laboratorium ke sistem informasi lainnya. HL7 Message version 2.5.1 bertipe OMI^O23 merupakan message yang digunakan untuk
STIKOM
komunikasi antar sistem informasi yang terlibat dalam pemenuhan kebutuhan akan pencitraan (ANSI, 2007).
3.2Analisa kebutuhan sistem
Berdasarkan pada permasalahan yang telah diuraikan di atas, maka perlu adanya satu aplikasi Broker HL7 yang memenuhi kriteria yang ada. Yaitu :
1. Pengiriman HL7 Message dilakukan dengan cara Post Method .
2. Broker HL7 yang dapat merincikan HL7 Message menjadi message tree agar mudah dibaca oleh user.
3. Broker HL7 yang dapat merincikan error yang terjadi saat pengiriman atau penerimaan message.
4. Broker HL7 yang dapat menampilkan log history semua kegiatan yang terjadi di aplikasi. Fitur Log Console akan mencatat semua kejadiannya agar para admin dapat melakukan pemeriksaan.
5. Broker HL7 yang dapat merincikan struktur setiap segmen HL7 Message. Struktur HL7 Message dirincikan sebagai berikut :
5.1 OMI^O23
A. Message Header Segmen (MSH) Contoh:
MSH|^~\&|Sphaira||ThirdParty||20110906100705||ORM^O01|0000000000 0000000138|P|2.5.1|||NE|AL|||||
Struktur OMI MSH dapat dilihat pada lampiran 1. B. Patient Identification Segmen (PID)
Contoh:
STIKOM
PID|1||00-00-05
06|04^Civilian^0|Peacock^Margareth^^S.Kom^Mrs.||19670829|F|Marga|0 05^Jawa|Jl.Boulevarad Barat Raya^Kelapa Gading
Strukutur OMI PID dapat dilihat pada lampiran 2. C. Patient Visit Segmen (PV1)
Contoh :
PV1|1|I|AlexanderWard^Room001^001
02||ZAPP/2012040200001^110^^^^^201109051400 ||KL^Leonardi^Kurniawan^^MMR^Prof
Struktur OMI PV1 dapat dilihat pada lampiran 3 D. Order Common Segmen(ORC)
Contoh :
ORC|NW|ZLAB/20110906000002|ZLAB/20110906000002||||^^^^^Regula r^0||20110906180005|||KL^Leonardi^Kurniawan^^Prof
Dr^MMR|||||||||||||||||Laboratory^0||
Struktur OMI ORC dapat dilihat pada lampiran 4 E. Observation Request Segmen (OBR)
Contoh :
OBR|1|ZLAB/20110906000002|ZLAB/20110906000002|CHOL^Kolester olTotal||||||||||||KL^Leonardi^Kurniawan^^MMR^Prof
Dr|||||||300000.0000||||1^PCS^^^^^201109062000^Regular| Struktur OMI OBR dapat dilihat pada lampiran 5
F. Notes and Comments Segmen (NTE) Contoh : NTE|||CPOERemarks
STIKOM
Struktur OMI NTE dapat dilihat pada lampiran 6 5.2 ORU^R01
A. Message Header Segmen (MSH) Contoh :
MSH|^~\&|ThirdParty||Sphaira||20110906100705||ORU^R01|0000000 0000000000138|P|2.5.1|||NE|AL|||||
Struktur ORU MSH dapat dilihat pada lampiran 7 B. Observation Request Segmen (OBR)
Contoh :
OBR|1|LAB/2012010500000004^ProHMS|^ChironLab||||20120105155 9|||||||||||||||201201051559|||R|
Struktur ORU OBR dapat dilihat pada lampiran 8 C. Observation/Result Segmen (OBX)
Contoh:
OBX|1|ST|CHOL^Kolesterol Total^|1|150|mg/dL|Desirable < 200 \r\nBorderLine High Risk 200-239\r\n\High Risk >=240||||P|||201201051559||||8|
Struktur ORU OBX dapat dilihat pada lampiran 9
3.3Perancangan Sistem 3.3.1 Rancangan Sistem
Berdasar pada kebutuhan sistem pada bagian 3.2, maka rancangan sistem Broker HL7 sebagai berikut :
1. Broker HL7 harus dapat menampilkan data dan rekam medis pasien yang dikirim oleh RIS, PACS serta HIS dengan format data HL7.
STIKOM
2. Setiap data yang diterima, harus secara otomatis di perbaharui oleh Broker ke aplikasi-aplikasi yang menggunakan standard HL7.
3. Setiap HL7 Message yang diterima oleh Broker, akan disajikan dalam message tree. Dengan tujuan agar mudah dipahami oleh user.
4. Broker HL7 dilengkapi dengan log history yang mencatat semua kegiatan dari Broker.
5. Broker HL7 dilengkapi dengan fitur Setting MSH yang berfungsi membantu para developer Broker dalam melakukan penginstalan.
3.3.2 Desain Sistem
Gambar 3.1 Blok Diagram Integrasi Informasi
STIKOM
Pada blok diagram di atas, menggambarkan proses integrasi informasi dari HIS, RIS, modality dan PACS. Proses order sampai pembacaan gambar adalah sebagai berikut :
A. HIS mengirimkan medical imaging order ke RIS
B. Broker menerima pengiriman HIS meng-generate order menjadi HL7 Message OMI^O23 dan mengirimkan ke RIS.
C. RIS melakukan penjadwalan ke Modality Worklist (MWL) D. Modality Worklist mengirimkam data pasien ke modality
E. Modality memberikan status pasien yang telah melakukan pencitraan dan mengirimkannya ke RIS.
F. Modality mengirimkan image ke PACS Server dalam format .dcm
G. PACS Server mengirimkan image ke PACS workstation ke PACS workstation untuk dibaca dokter
H. PACS workstation mengirimkan laporan pembacaan image yang telah dilakukan oleh dokter ke RIS
I. RIS mengirimkan laporan pembacaan image ke broker
J. Broker HL7 meng-generate hasil pembacaan kedalam HL7 Message tipe ORU^R01 dan dikirimkan ke HIS
STIKOM
3.4Usecase Diagram Broker HL7
Gambar 3.2 Usecase Diagram Broker HL7
3.5Sequence Diagram Broker HL7
Untuk memberikan penjelasan yang berasal dari masing-masing use case berdasarkan pada use case diagram broker HL7, maka dibutuhkan sequence diagram untuk menggambarkan jalannya suatu proses yang melibatkan object atau instance dari suatu class dalam broker HL7. Untuk lebih detilnya akan dijelaskan sebagi berikut :
STIKOM
3.5.1 Sequence Diagram Melakukan Koneksi Database
Sequence diagram dari use case Melakukan Koneksi Database dapat digambarkan seperti pada lampiran 10.
3.5.2 Sequence Diagram Melakukan Konfigurasi
Sequence diagram dari use case Melakukan Konfigurasi dapat digambarkan seperti pada gambar pada lampiran 11.
3.5.3 Sequence Diagram Melakukan Setting MSH
Sequence diagram dari use case Melakukan Setting MSH dapat digambarkan seperti pada lampiran 12.
3.5.4 Sequence Diagram Menerima HL7 Message
Sequence diagram dari use case Menerima HL7 Message dapat digambarkan seperti pada lampiran 13.
3.5.5 Sequence Diagram Membaca HL7 Message bertipe OMI
Sequence diagram dari use case Membaca HL7 Message bertipe OMI dapat digambarkan seperti pada lampiran 14.
3.5.6 Sequence Diagram Membaca MSH Segmen
Sequence diagram dari use case Membaca MSH Segmen dapat digambarkan seperti pada lampiran 15.
3.5.7 Sequence Diagram Membaca NTE Segmen
Sequence diagram dari use case Membaca NTE Segmen dapat digambarkan seperti pada lampiran 16.
3.5.8 Sequence Diagram Membaca OBR Segmen
Sequence diagram dari use case Membaca OBR Segmen dapat digambarkan seperti pada lampiran 17.
STIKOM
3.5.9 Sequence Diagram Membaca ORC Segmen
Sequence diagram dari use case Membaca ORC Segmen dapat digambarkan seperti pada lampiran 18.
3.5.10 Sequence Diagram Membaca PID Segmen
Sequence diagram dari use case Membaca PID Segmen dapat digambarkan seperti pada lampiran 19.
3.5.11 Sequence Diagram Membaca PV1 Segmen
Sequence diagram dari use case Membaca PV1 Segmen dapat digambarkan seperti pada lampiran 20.
3.5.12 Sequence Diagram Menyimpan di Database RIS
Sequence diagram dari use case Menyimpan di Database RIS dapat digambarkan seperti pada lampiran 21.
3.5.13 Sequence Diagram Mengambil Data di Database RIS
Sequence diagram dari use case Mengambil Data di Database RIS dapat digambarkan seperti pada lampiran 22.
3.5.14 Sequence Diagram Menulis HL7 Message bertipe ORU
Sequence diagram dari use case Menulis HL7 Message bertipe ORU dapat digambarkan seperti pada lampiran 23.
3.5.15 Sequence Diagram MSH Segmen
Sequence diagram dari use case MSH Segmen dapat digambarkan seperti pada lampiran 24.
3.5.16 Sequence Diagram OBR Segmen
Sequence diagram dari use case OBR Segmen dapat digambarkan seperti pada lampiran 25.
STIKOM
3.5.17 Sequence Diagram OBX Segmen
Sequence diagram dari use case Mengambil Data di Database RIS dapat digambarkan seperti pada lampiran 26.
3.5.18 Sequence Diagram PV1 Segmen
Sequence diagram dari use case PV1 Segmen dapat digambarkan seperti pada lampiran 27.
3.5.19 Sequence Diagram Mengirim HL7 Message
Sequence diagram dari use case Mengirim HL7 Message dapat digambarkan seperti pada lampiran 28.
3.5.20 Sequence Diagram Membuat Accesion Number
Sequence diagram dari use case Membuat Accesion Number dapat digambarkan seperti pada lampiran 29.
3.6Class Diagram Broker HL7
Berdasarkan perencanaan sistem use case diagram, dibutuhkan class-class untuk membangun dan mendukung jalannya aplikasi. Class Diagram atau Diagram Kelas digunakan untuk menampilkan kelas-kelas atau paket-paket di dalam sistem serta relasi antar kelas tersebut.
3.6.1 Class AutoNumber
Class AutoNumber merupakan class untuk membuat nomor secara otomatis untuk setiap order message HL7 yang ada.
STIKOM
Gambar 3.3 Class AutoNumber
3.6.2 Class Connection SQL
Class Connection SQL untuk membuat koneksi untuk database.
Gambar 3.4 Class Connection SQL 3.6.3 Class Create Message ORU
[image:43.595.41.552.92.715.2]Class Create Message ORU merupakan class yang digunakan untuk membuat HL7 Message version 2.5.1 bertipe ORU.
Gambar 3.5 Class Create Message ORU
STIKOM
3.6.4 Class Konfigurasi
Class Konfigurasi digunakan untuk mengatur HL7 Message version 2.5.1 pada saat melakukan decode (membaca) dan encode (membuat).
Gambar 3.6 Class Konfigurasi 3.6.5 Class ReadOMI
Class ReadOMI digunakan untuk membaca HL7 Message version 2.5.1 dengan tipe OMI O23.
STIKOM
Gambar 3.7 Class Read OMI 3.6.6 Class ReadConfig
Class ReadConfig digunakan untuk membaca file koneksi untuk database.
Gambar 3.8 Class ReadConfig 3.6.7 Class PesanBalik
Class PesanBalik digunakan untuk memberikan status balikan kepada HIS. Status yang dibuat ada 3 macam yaitu OK, Not Available dan Realisasi.
STIKOM
Gambar 3.9 Class PesanBalik 3.6.8 Class SaveOMI
Class SaveOMI digunakan untuk menyimpan HL7 Message version 2.5.1 bertipe OMI yang dikirimkan oleh HIS ke dalam broker ataupun sebaliknya.
Gambar 3.10 Class Save OMI
STIKOM
3.7Desain Database
3.7.1 ERD Broker HL7
Gambar 3.11 Struktur Tabel Broker HL7
3.7.2 Struktur Tabel Broker HL7
A. Tabel fromQPRO
Nama Tabel : fromQPRO Primary Key : FromQproID Foreign Key : -
Fungsi : Menyimpan Data Dari QPRO
STIKOM
Tabel 3.1 Struktur Tabel fromQPRO
No Nama Field Tipe
Data Lebar Keterangan
1 FromQproID Int - Kode Data Dari QPRO 2 MessageHL7 Varchar Max HL7 Message
3 TanggalTerima Datetime Tanggal Terima
B. Tabel ServerSetting
Nama Tabel : ServerSetting Primary Key : SettingID Foreign Key : -
Fungsi : Menyimpan Pengaturan Server
Tabel 3.2 Struktur Tabel ServerSetting
No Nama Field Tipe
Data Lebar Keterangan
1 SettingID Varchar 50 Kode Pengaturan 2 SettingDesc Varchar 255 Pengertian Pengaturan 3 SettingValue Text - Nilai Pengaturan
C. Tabel SettingMSH
Nama Tabel : SettingMSH Primary Key : SettingID Foreign Key : -
Fungsi : Menyimpan Pengaturan MSH
Tabel 3.3 Struktur Tabel SettingMSH
No Nama Field Tipe
Data Lebar Keterangan
1 SettingID Varchar 50 Kode Pengaturan 2 SettingDesc Varchar 50 Pengertian Pengaturan 3 SettingValue Varchar 50 Nilai Pengaturan
STIKOM
D. Tabel ToQPRO
Nama Tabel : ToQPRO Primary Key : ToQproID Foreign Key : -
Fungsi : Menyimpan Data Yang Akan Dikirim Ke QPRO
Tabel 3.4 Struktur Tabel ToQPRO
No Nama Field Tipe
Data Lebar Keterangan
1 ToQproID Int - Kode Pengiriman Ke
QPRO
2 MessageHL7 Varchar Max HL7 Message 3 TanggalKirim Datetime - Tanggal Kirim
E. Tabel UserLogin
Nama Tabel : UserLogin Primary Key : UserName Foreign Key : -
Fungsi : Menyimpan Data Login
Tabel 3.5 Struktur Tabel UserLogin
No Nama Field Tipe
Data Lebar Keterangan
1 UserName Varchar 50 Nama Pengguna 2 UserPsw Varchar 50 Password Pengguna 3 ActualName Varchar 255 Nama Asli Pengguna 4 Address Varchar 255 Alamat Pengguna 5 Phone Varchar 50 Telephone Pengguna
6 HPNo Varchar 50 Nomor handphone
7 Email Varchar 255 Email Pengguna 8 UserStatus Int - Status Pengguna
9 LevelID Int - Kode level
STIKOM
No Nama Field Tipe Data
Lebar Keterangan
10 IsPhysician Bit - Dokter
3.8User Interface Design (Rancangan Antar Muka)
Pembuatan tampilan sangat diperlukan agar user dapat berinteraksi dengan sistem, sehingga dibutuhkan perancangan secara detil mengenai tampilan aplikasi berdasarkan informasi yang ditampilkan. Desain antarmuka ini dibuat dengan menggunakan perangkat lunak Microsoft Visio 2007. Dalam sub bab ini akan dijelaskan rancangan antar muka dari form-form yang ada serta penjelasan singkat aplikasi HL7 Broker.
3.8.1 Rancangan Form Login
Form Login muncul saat pertama kali program dijalankan. Disini user harus mengisi username dan password yang telah didaftarkan oleh RIS. Disini broker tidak berhak mendaftarkan user baru. Apabila user menekan tombol cancel maka secara otomatis aplikasi akan menutup sendiri.
Gambar 3.12 Rancangan Form Login
STIKOM
3.8.2 Rancangan Form Menu
Form Menu akan muncul setelah login berhasil. Pada form menu ada beberapa pilihan menu seperti Setting, Log Console, HL7 Message dan About.
[image:51.595.43.552.181.711.2]Gambar 3.13 Rancangan Form Menu 3.8.3 Rancangan Form Setting MSH
Gambar 3.14 Rancangan Form Setting MSH
STIKOM
3.8.4 Rancangan Form HL7 Message IN
Form HL7 Message IN adalah tampilan untuk setiap HL7 Message yang diterima RIS.
Gambar 3.15 Rancangan Form HL7 Message IN 3.8.5 Rancangan Form HL7 Message OUT
Form HL7 Message OUT adalah tampilan untuk setiap HL7 Message yang dikirim oleh RIS.
STIKOM
Gambar 3.16 Rancangan HL7 Message OUT 3.8.6 Rancangan Form Message Tree
[image:53.595.44.558.87.729.2]Form Message Tree adalah form yang muncul ketika data di salah satu form HL7 Message IN dan HL7 Message OUT ditekan. Message Tree menampilkan rincian data yang diterima maupun dikirim oleh RIS.
Gambar 3.17 Rancangan Form Message Tree
STIKOM
3.8.7 Rancangan Form About
Form About menampilkan identitas perusahaan dan versi HL7 yang saat ini dipakai.
Gamba3.18 Rancangan Form About
STIKOM
50 BAB IV
IMPLEMENTASI DAN EVALUASI
4.1 Kebutuhan Sistem
Sebelum melakukan implementasi dan menjalankan broker HL7, dibutuhkan spesifikasi perangkat lunak (software) dan perangkat keras (hardware) tertentu agar aplikasi dapat berjalan dengan baik.
4.1.1 Kebutuhan perangkat keras
Persyaratan minimal perangkat keras yang diperlukan untuk menjalankan broker HL7 pada RIS adalah sebagai berikut:
A. Prosesor minimal core2duo 2,0 GHz. B. Monitor.
C. Memori minimal 4 GB. D. VGA Card minimal 16 MB.
E. Hard Disk dengan free space 1 TB. F. DVD writer
G. Keyboard. H. Mouse.
4.1.2 Kebutuhan perangkat lunak
Persyaratan minimal perangkat lunak yang diperlukan untuk menjalankan broker HL7 ini adalah:
A. Sistem operasi Windows versi desktop (Microsoft® Windows® XP) maupun Windows versi server (Microsoft® Windows® 7 Profesional Edition).
STIKOM
B.SQL-Server 2000Microsoft 4.2 Implementasi Sistem
Setelah kebutuhan perangkat keras dan perangkat lunak telah terpenuhi, maka tahap selanjutnya adalah melakukan implementasi sistem yang telah dibuat. Pada pembahasan implementasi sistem, akan dijelaskan bagaimana menggunakan fitur-fitur yang terdapat pada aplikasi broker HL7.
4.2.1 Form Login
Pada saat aplikasi pertama kali dijalankan, aplikasi akan menampikan form login. Tampilan form login bisa dilihat pada gambar 4.1
Gambar 4.1 Tampilan Form Login 4.2.2 Form Menu
Pada form menu terdapat pilihan-pilihan menu yang dapat dipilih oleh pengguna aplikasi. Tampilan form menu utama dapat dilihat pada Gambar 4.2.
STIKOM
Gambar 4.2 Tampilan Form Menu 4.2.3 Form Setting MSH
Setting MSH digunakan untuk merubah data-data yang ada di segmen MSH, seperti merubah sender dan receiver HL7 Message. Tampilan form Setting MSH dapat dilihat pada gambar 4.3.
STIKOM
Gambar 4.3 Tampilan Form Setting MSH 4.2.4 Form HL7 Message IN
Form HL7 Message IN menampilkan HL7 Message yang diterima oleh RIS. Gambar 4.4 dan 4.5 menunjukkan tampilan form HL7 Message IN.
STIKOM
Gambar 4.4 Tampilan Form HL7 Message IN
Gambar 4.5 Tampilan Form HL7 Message IN View Data
STIKOM
4.2.5 Form HL7 Message OUT
Form HL7 Message OUT menampilkan HL7 Message yang dikirim oleh RIS. Gambar 4.6 dan 4.7 menunjukkan tampilan form HL7 Message OUT.
[image:60.595.43.551.161.718.2]Gambar 4.6 Tampilan Form HL7 Message OUT
Gambar 4.7 Tampilan Form HL7 Message OUT View Data
STIKOM
4.2.6 Message Tree
Message Tree adalah fitur yang digunakan untuk menampilkan data HL7 Message. Message Tree merincikan setiap segmen dari HL7 Message, untuk
memudahkan pengguna dalam membaca HL7 Message. Tampilan Message Tree dapat dilihat pada gambar 4.8.
Gambar 4.8 Tampilan Message Tree 4.2.7 Form About
Form About berfungsi untuk melihat data pembuat dan version dari HL7 Message.
STIKOM
Gambar 4.9 Form About 4.3 Uji Fitur Aplikasi
Pada tahap ini dilakukan uji coba aplikasi atau sistem yang telah dibuat dengan melakukan serangkaian testing terhadap validasi dan kemampuan sistem dari broker HL7 untuk menghasilkan informasi yang tepat bagi pengguna. Uji coba terhadap kebutuhan ini bertujuan untuk memastikan bahwa aplikasi telah dibuat dengan benar sesuai dengan kebutuhan fungsionalitas sistem yang diharapkan. Kekurangan atau kelemahan aplikasi pada tahap ini akan dievaluasi sebelum diimplementasikan secara nyata.
4.3.1 Uji coba pengiriman HL7 Message
Dalam satu order pemeriksaan pasien, terjadi 3 proses pengiriman HL7 Message yaitu dari HIS ke RIS, RIS ke HIS dan PACS ke RIS. Dengan demikian
dilakukan pengujian dan evaluasi terhadap 3 proses tersebut.
STIKOM
A. Pengiriman HL7 Message dari HIS ke RIS
Pengiriman HL7 Message pertama dilakukan oleh HIS ke RIS. HIS mengirimkan registration information ke RIS.
Hasil test case pengiriman dari HIS ke RIS dapat dilihat pada tabel 4.1 Tabel 4.1 Test Case pengiriman dari HIS ke RIS
Test
case ID Tujuan Input
Output yang
diharapkan Output Sistem
1 Melakukan pengisian data form Registration Information pada HIS Input data pasien pada form Registration Information pada HIS Data Registration Information sesuai dengan apa yang diinputkan Data Registration Information sesuai dengan yang diinputkan (lampiran 30)
B. Pengiriman HL7 Message dari RIS ke HIS
Pengiriman HL7 Message kedua dilakukan oleh RIS ke HIS. RIS mengirimkan job order information kepada HIS sebagai balikan dari registrasi yang telah dilakukan.
Hasil test case pengiriman dari RIS ke HIS dapat dilihat pada tabel 4.2 Tabel 4.2 Test Case pengiriman dari RIS ke HIS
Test
case ID Tujuan Input
Output yang
diharapkan Output Sistem
C. Pengiriman HL7 Message dari PACS ke RIS
Pengiriman HL7 Message ketiga dilakukan oleh PACS ke RIS. PACS mengirimkan hasil pembacaan gambar dari pasien tersebut. Hasil pembacaan dikirimkan ke RIS, sehingga dapat dibuatkan laporan medis pasien.
Hasil test case pengiriman dari PACS ke RIS dapat dilihat pada tabel 4.3 Tabel 4.3 Test Case pengiriman dari PACS ke RIS
Test
case ID Tujuan Input
Output yang
diharapkan Output Sistem
3 Melakukan pengisian data hasil pembacaan gambar Input hasil pembacaan gambar pada form Create Report pada PACS Hasil pembacaan gambar berhasil dikirimkan ke RIS
Hasil pembacaan berhasil dikirimkan ke RIS (lampiran 32 dan lampiran 33)
4.3.2 Uji coba penerimaan HL7 Message
Dalam satu order pemeriksaan pasien, terjadi 3 proses penerimaan HL7 Message yaitu oleh RIS dari HIS, oleh HIS dari RIS serta oleh RIS dari PACS.
Dengan demikian dilakukan pengujian dan evaluasi terhadap 3 proses tersebut. A. Penerimaan HL7 Message oleh RIS dari HIS
HL7 Message yang dikirimkan oleh HIS dan diterima oleh RIS. RIS menerima HL7 Message berupa data pasien yang telah melakukan registrasi
Hasil test case RIS menerima data dari HIS dapat dilihat pada tabel 4.4
STIKOM
Tabel 4.4 Test Case RIS menerima data dari HIS
Test
case ID Tujuan Input
Output yang
diharapkan Output Sistem
4 Menampilkan setiap pasien yang akan melakukan pemeriksaan Masukkan data pasien serta radiografer dan dokter yang memeriksa
Setiap pasien yang terdaftar dilakukan pembuatan jadwal Setiap pasien yang terdaftar dilakukan pembuatan jadwal (lampiran 34)
B. Penerimaan HL7 Message oleh HIS dari RIS
HL7 Message yang dikirimkan oleh HIS dan diterima oleh RIS. RIS menerima HL7 Message berupa data pasien yang telah melakukan registrasi.
Hasil test case HIS menerima data dari RIS dapat dilihat pada tabel 4.5 Tabel 4.5 Test Case HIS menerima data dari RIS
Test
case ID Tujuan Input
Output yang
diharapkan Output Sistem
5 Menampilkan jadwal pemeriksaan pasien pada form Record List Memilih ruangan pemeriksaan Memunculkan jadwal pemeriksaan pasien berdasarkan ruangan Memunculkan jadwal pemeriksaan pasien berdasarkan ruangan (lampiran 35, lampiran 36, lampiran 37 dan lampiran 38)
C. Penerimaan HL7 Message oleh RIS dari PACS
HL7 Message yang dikirimkan oleh PACS dan diterima oleh RIS. RIS menerima HL7 Message berupa data pasien yang telah melakukan registrasi.
Hasil test case RIS menerima data dari PACS dapat dilihat pada tabel 4.6
STIKOM
Tabel 4.6 Test Case RIS menerima data dari PACS
Test
case ID Tujuan Input
Output yang
diharapkan Output Sistem
6 Mengupdate database pasien dengan hasil pembacaan gambar Hasil pembacaan gambar Mengupdate data pasien khususnya pada tabel Appointment pada kolom Result Value Pada Tabel Appointment data pasien di update
4.3.3 Uji coba membaca HL7 Message
Broker HL7 dapat membaca HL7 Message yang dikirimkan oleh RIS, PACS dan HIS.
Hasil test case membaca HL7 Message dapat dilihat pada tabel 4.7 Tabel 4.7 Test Case membaca HL7 Message
Test
case ID Tujuan Input
Output yang
diharapkan Output Sistem
62 PENUTUP
5.1 Kesimpulan
Berdasarkan hasil evaluasi yang telah dilakukan dalam Penerapan Health Level 7 (HL7) pada Radiology Information System (RIS), dapat disimpulkan bahwa tugas akhir telah sesuai dengan tujuan. Berikut adalah beberapa poin kesimpulan dari pengerjaan tugas akhir ini:
1. Broker HL7 dibuat dengan menerapkan standar HL7 Message version 2.5.1 bertipe ORU^R01 dan OMI^O23. HL7 Message version 2.5.1 bertipe ORU^R01 berfungsi mengirim hasil pemeriksaan ke sistem informasi lainnya. HL7 Message version 2.5.1 bertipe OMI^O23 merupakan message yang digunakan untuk
komunikasi antar sistem informasi yang terlibat dalam pemenuhan kebutuhan akan pencitraan.
2. Berdasarkan hasil uji coba, broker HL7 telah berhasil mengintegrasikan data pasien antara RIS, PACS dan HIS.
5.2Saran
Tugas akhir Penerapan Health Level 7 (HL7) pada Radiology Information System (RIS) dapat dikembangkan sesuai dengan kebutuhan sistem informasi yang terus meningkat dan teknologi informasi yang semakin berkembang. Berikut adalah saran-saran dalam pengembangan aplikasi:
1. Penambahan jenis HL7 Message pada broker, sehingga kebutuhan HL7 Message bisa memenuhi kebutuhan sistem informasi yang ada di rumah sakit,
seperti dengan Laboratory Information System.
STIKOM
dengan versi 3.0, sehingga dapat menjembatani implementasi antar sistem informasi yang menggunakan HL7 messages dengan versi yang berbeda.
STIKOM
64
DAFTAR PUSTAKA
A Division of EHR Scope, LLC . 2013. Hospital Information Systems (HIS). 20 januari 2013. < http://www.emrconsultant.com/education/hospital-information-systems >
Benson T. 2010. Principles of Health Interoperability HL7 and SNOMED. New York:Springer.
Bleich HL, Lawrence L. 1993. Weed and the problem-oriented medical record. Missouri: MD Computing.
Dreyer, Keith J., Hirschorn, David S., Thrall, James H., & Metha Amit. 2006. PACS A Guide To Digital Revolution Second Edition. New York: nger Science+Business Media, Inc.
Gibbson P et al. 2007. Coming of Terms : Scoping Interoperability in Health Care. Seattle: H
