PROTOTYPE DATABASE ELEKTORNIC MEDICAL RECODR

LAPORAN TUGAS AKHIR PROTOTYPE DATABASE ELEKTORNIC MEDICAL RECODR (EMR) MENGGUNAKAN HL7 messages SEBAGAI SOLUSI INTEGRASI DATABASE GUNA MENUNJANG PELAYANAN KESEHATAN MASYARAKAT Disusun Oleh: Nama : Wise Herowati NIM : A11.2009.04739 Program Studi : Teknik Informatika-S1 FAKULTAS ILMU KOMPUTER UNIVERSITAS DIAN NUSWANTORO SEMARANG 2013

BAB I PENDAHULUAN 1. Latar Belakang Masalah Kesehatan dan masyarakat merupakan dua relasi yang saling terkait kuat. Masyarakat (sebagai terjemahan istilah society) adalah sekelompok orang yang membentuk sebuah sistem semi tertutup (atau semi terbuka), dimana sebagian besar interaksi adalah antara individu-individu yang berada dalam kelompok tersebut. Kata "masyarakat" sendiri berakar dari kata dalam bahasa Arab, musyarak. Lebih abstraknya, sebuah masyarakat adalah suatu jaringan hubungan-hubungan antar entitas-entitas. Masyarakat adalah sebuah komunitas yang interdependen (saling tergantung satu sama lain). Umumnya, istilah masyarakat digunakan untuk mengacu sekelompok orang yang hidup bersama dalam satu komunitas yang teratur.[1] Menurut Syaikh Taqyuddin An-Nabhani, sekelompok manusia dapat dikatakan sebagai sebuah masyarakat apabila memiliki pemikiran, perasaan, serta sistem/aturan yang sama. Dengan kesamaan-kesamaan tersebut, manusia kemudian berinteraksi sesama mereka berdasarkan kemaslahatan. Masyarakat terdiri dari individu utuh yang tidak dapat dipisah-pisah, termasuk dalam riwayat kesehatannya. Sedangkan untuk kesehatan menurut WHO adalah Health is a state of complete physical, mental and social well-being and not merely the absence of diseases or infirmity, dapat dikatakan bahwa sehat merupakan kondisi optimal fisik, mental dan sosial seseorang sehingga dapat memiliki produktivitas, bukan hanya terbebas dari bibit penyakit.[2] Kondisi sehat dapat dilihat dari dimensi produksi dan dimensi konsumsi. Dimensi produksi memandang keadaan sehat sebagai salah satu modal produksi atau prakondisi yang dibutuhkan seseorang sehingga dapat beraktivitas yang produktif. Masyarakat dan kesehatan terhubung tentunya karena manusia pastinya memiliki kondisi fisik yang berbeda-beda dan tidak jarang terjadi gangguan

yang tidak sekedar sekali atau dua kali yang dapat dibuat sebuah catatan kesehatan atau dapat dikatakan sebuat riwayat kesehatan. Riwayat kesehatan yang berkesinambungan akan menghindarkan dari kasus medical error. Dalam Surat Keputusan Menteri Kesehatan RI Nomor 1027/MENKES/SK/IX/2004 disebutkan bahwa pengertian medication error adalah kejadian yang merugikan pasien, akibat pemakaian obat selama dalam penanganan tenaga kesehatan, yang sebetulnya dapat dicegah. Studi yang dilakukan oleh Commonwealth Fund menunjukkan bahwa 44.000 98.000 kematian per tahun terjadi karena medical error. [3] Medical error ini terjadi dikarenakan tidak berkesinambungan informasi medis pada seorang individu karena terpecah-pecah di setiap institusi pelayanan kesehatan yang pernah didatangi sehingga pelayanan kesehatan yang diberikan sering menjadi tidak tepat. Kesinambungan informasi medis atau riwayat kesehatan seorang individu dapat terpenuhi ketika berbicara tentang Electronic Health Record (EHR). Saat ini tantangan dalam EHR adalah dibutuhkan interoperability standard yang dapat membuat sistem komputer di sarana pelayanan kesehatan dapat melakukan share data kesehatan dengan sarana pelayanan kesehatan lain dengan tetap menjaga kualitas klinis tiap individu di dalamnya. Di Indonesia semakin banyak rumah sakit, poliklinik, puskesmas yang mulai menggunakan Tehnologi Informasi dan Komunikasi (TIK) di dalam pelayanan kesehatan yang diberikan, akan tetapi dengan software yang sifatnya tailor-made (bisa diubah-ubah sesuai kebutuhan) sehingga mengakibatkan terciptanya beragam software/aplikasi di sarana pelayanan kesehatan. Hal ini dapat menimbulkan masalah jika suatu saat institusi kesehatan tersebut saling bertukar data atau informasi. Integrasi sistem di Indonesia menjadi semakin sulit karena tidak ada standarisasi pada sistem informasi software di Indonesia baik struktur data, hardware, software, dll. Di Amerika Serikat telah lama dikembangkan konsep standarisasi yang menunjang integrasi sistem di dalam institusi medis, yaitu HL7 (Health Level Seven), yang merupakan standar ANSI (American National Standards

Institute), yang telah terakreditasi oleh SDO (Standards Developing Organizations); standarisasi ini dipakai khususnya untuk bidang atau area healthcare system. Khusus untuk HL7 bidang yang dikaji adalah administrasi data klinik atau rumah sakit. HL7 tidak mengembangkan aplikasi software healthcare atau hospital information system melainkan hanya mengembangkan konsep, metodologi, spesifikasi dan standar yang akan memungkinkan beberapa aplikasi software kesehatan yang berbeda dapat bertukar data satu dengan yang lainnya. 2. Rumusan Masalah Guna mendukung integrasi data kesehatan di masyarakat dibutuhkan standar komunikasi pertukaran data yang bersifat internasional sehingga data dapat dimanfaatkan dimanapun, kapanpun dan oleh siapapun. Maka pada tugas akhir ini penulis akan membahas mengenai Prototype Database Elektornic Medical Record (EMR) Menggunakan HL7 messages sebagai Solusi Integrasi Database guna Menunjang Pelayanan Kesehatan Masyarakat. 3. Batasan Masalah Untuk menghindari penyimpangan dari judul dan tujuan yang sebenarnya serta keterbatasan pengetahuan yang dimiliki penulis, maka penulis membuat ruang lingkup dan batasan masalah yakni penulis menyusun laporan akhir sebatas pada pembuatan prototype database dan kode-kode HL7 message hanya terbatas untuk proses pendataan hasil diagnosa pasien dengan menggunakan acuan beberapa field record sebagai pembuatan kode-kode standar komunikasi HL7 message. 4. Tujuan Penelitian Berdasarkan rumusan masalah di atas, maka tujuan dari laporan tugas akhir yang dibuat oleh penulis ini adalah a. Mendeskripsikan pembuatan database electornik medical record (EMR) khususnya untuk proses pendataan hasil diagnosa pasien.

b. Mendeskripsikan HL7 message yang telah di sarana pelayanan kesehatan c. Mengembangkan kode-kode prototype HL7 message. 5. Manfaat Penelitian Manfaat dari laporan tugas akhir ini adalah : a. Bagi Penulis Menambah wawasan mengenai HL7 dan cara mengimplemantasi dan mengembangkannya. b. Bagi Instansi Kesehatan Tersedianya akses informasi medis pasien yang dapat didistribusikan antar instansi serta dibangun dari berbagai macam variasi narasi, struktur, kode dan multimedia dengan terciptanya Electronic Medical Record (EMR) sebagai wujud implementasi HL7 message sebagai standart pertukaran data, dalam hal ini tentukan data-data yang berhubungan dengan kesehatan. c. Bagi Masyarakat Kesinambungan informasi medis atau riwayat kesehatan seorang individu dapat terpenuhi ketika berbicara tentang Electronic Medical Record(EHR). Penerapan HL7 message pada EMR ini dapat mengurangi resiko medical error yang dapat merugikan masyarakat pada umumnya. Manfaat dari pencegahan medical error adalah: (1) Pencegahan adverse event, (2) Memberikan respon cepat segera setelah terjadinya adverse event, (3) Melacak serta menyediakan umpan balik mengenai adverse event.

BAB II TINJAUAN PUSTAKA 2.1 Landasan Teori 2.1.1 Pengertian Electronic Health Record (EHR) Electronic Health Record (EHR) merupakan kegiatan mengkomputerisasikan isi rekam kesehatan dan proses yang berhubungan dengannya[4]. Rekam Medis Kesehatan menurut Lampiran SK PB IDI No 315/PB/A.4/88 adalah rekaman dalam bentuk tulisan atau gambaran aktivitas pelayanan yang diberikan oleh pemberi pelayanan medis / kesehatan kepada seorang pasien. Berdasarkan SK Menteri Kesehatan Nomor:269/Menkes/PER/III/2008 tentang rekam medis menjelaskan bahwa rekam medis adalah berkas yang berisikan catatan dan dokumen tentang identitas pasien, pemeriksaan, pengobatan, tindakan dan pelayanan lain yang telah diberikan kepada pasien (Bab I pasal 1). EHR bukanlah sistem informasi yang dapat dibeli dan diinstall seperti paket word-processing atau sistem informasi pembayaran dan laboratorium yang secara langsung dapat dihubungkan dengan sistem informasi lain dan alat yang sesuai dalam lingkungan tertentu. EHR merupakan sistem informasi yang memiliki framework lebih luas dan memenuhi satu set fungsi harus mempunyai kriteria sebagai berikut: Mengintegrasikan data dari berbagai sumber (Integrated data from multiple source) Mengumpulkan data pada titik pelayanan (Capture data at the point of care) Mendukung pemberi pelayanan dalam pengambilan keputusan (Support caregiver decision making).[5]

Sedangkan Gemala Hatta menjelaskan bahwa EHR terdapat dalam sistem yang secara khusus dirancang untuk mendukung pengguna dengan berbagai kemudahan fasilitas untuk kelengkapan dan keakuratan data; memberi tanda waspada; peringatan; memiliki sistem untuk mendukung keputusan klinik dan menghubungkan data dengan pengetahuan medis serta alat bantu lainnya.[6] WHO juga memiliki pandangan yang berbeda tentang pengertian EHR, yang berlandaskan pada beberapa perbedaan penerapan EHR di beberapa negara. Namun demikian, WHO menjelaskan bahwa EHR idealnya harus mampu: Collect clinical, administrative and financial data at the point time; Exchange data more easily between health professionals to facilitate continuing care; Measure clinical improvement and health outcomes, compare the outcomes againts benchmarks and facilitate research and clinical trials; Provide valuable statistical data in a timely and efficient manner to public health and goverment ministries (such reporting of health data is important in the detection and monitoring of disease outbreaks, as well as providing meaningful and accurate statistics to measure the health status of the population; and Support management in administrative and financial reporting and other processes. [7] Sistem EHR secara umum merupakan suatu sistem pencatatan kesehatan pasien yang yang terdapat pada berbagai lembaga kesehatan seperti administratif, klinik, farmasi, radiologi, laboratorium dan sebagainya. Secara definisi, sistem EHR merupakan kumpulan sistematis informasi kesehatan elektronik pasien secara individu maupun dalam populasi, yang merupakan rekaman dalam format digital dan dapat di share dalam berbagai media, melalui sistem informasi yang

terhubung dalam jaringan. Catatan tersebut dapat berisi berbagai jenis data komprehensif maupun ringkasan, termasuk demografis, rekaman medis, pengobatan dan alergi, status imunisasi, hasil tes laboratorium, gambar radiologi, tanda-tanda vital, status personal seperti usia dan berat badan, serta informasi tagihan. Sistem EHR dikenal juga sebagai EPR (Electronic Patient Record) atau EMR (Electronic Medical Record). Arsitektur rancangan dalam sistem EHR terdiri dari beberapa komponen dan pengaksesan secara bersama-sama. Adapun komponen utama pada sistem EHR, antara lain yaitu administratif, klinik (rumah sakit, puskesmas dan klinik), radiologi, laboratorium, farmasi, input order dokter dan klinis. Dengan gambar dibawah akan menunjukkan arsitektur sistem EHR secara konseptual. Dimana pada gambar tersebut terdapat beberapa komponen saling terhubung. Gambar 2.1 Arsitektur Konseptual HER Menurut Johan Harlan, komponen fungsional EHR, meliputi: 1. Data pasien terintegrasi Repository (gudang data) yang memusatkan data dari berbagai komponen lain atau cara lain untuk mengintegrasikan data.

2. Dukungan keputusan klinik Rules engine, yang menyediakan program logic yang dapat dipakai untuk menunjang keputusan seperti: kewaspadaan dan pernyataan, daftar permintaan (order set) dan protokol klinis. 3. Pemasukan perintah klinikus Human interface, memperoleh data dalam waktu yang tepat bagi pelayanan (at the point of care) dan kemampuan untuk mengakses data, aturan dan proses data (mined data) melalui data agregat dan analisis data. 4. Akses terhadap sumber pengetahuan Sumber pengetahuan, yakni membuat informasi yang selalu tersedia bagi kepentingan sumber-sumber luar. 5. Dukungan komunikasi terpadu Gudang data (data warehouse) data spesifik yang dapat diproses (yakni data agregat dan data yang akan dianalisis) yang menghasilkan informasi yang amat berguna. Penyelenggaraan EHR di rumah sakit sejalan dengan adanya tuntutan masyarakat akan pelayanan kesehatan yang semakin berkualitas. Keuntungan peralihan dari paper-based pada EHR adalah menjamin kualitas perawatan (quality of care) dan memicu produktivitas, antara lain: Mereduksi duplikasi pengujian Mereduksi kesalahan medis (medication errors) Mencegah efek kerugian dari konflik materi pengobatan/perawatan Mengurangi waktu yang dihabiskan oleh pasien dan tenaga medis dalam menunggu order medis, hasil test, diagnosa yang akurat, intervensi medis Mengeliminasi pengulangan visit yang tidak perlu

Mereduksi kerja dengan kertas Penghematan biaya dari penggunaan kertas untuk pencatatan, Tidak memerlukan gudang yang besar dalam penyimpanan arsip Penyimpanan data (record) pasien menjadi lebih lama EHR yang dirancang dengan baik akan mendukung otonomi yang dapat dipertanggung jawabkan Meningkatkan produktivitas bekerja Mengurangi kesalahan dalam menginterprestasikan pencatatan Standarisasi, terdapat pelaporan data klinik yang standar yang mudah dan cepat diketahui Meningkatkan kualitas informasi klinik dan sekaligus meningkatkan waktu perawat berfokus pada pemberian asuhan Accessibility, legibility, artinya mudah dalam membaca dan mendapat informasi klinik tentang semua pasien dan suatu lokasi. [8] 2.1.2 Pengertian Health Level Seven (HL7) Message Menurut Amatayakul Magret K dalam bukunya Electronic Health Records: A Practical, Guide for Professionals and Organizations kriteria dari EHR salah satunya mengintegrasikan data dari berbagai sumber (Integrated data from multiple source) dan guna melakukan integrasi data tersebut, EHR dapat didukung dengan Health Level Seven (HL7) message yang merupakan standar untuk bertukar informasi antara aplikasi medis. Standar ini mendefinisikan format untuk transmisi informasi terkait kesehatan. Informasi yang dikirim menggunakan standar HL7 dikirim sebagai kumpulan dari satu atau lebih pesan, yang masing-masing mengirimkan satu record atau item informasi terkait kesehatan. Didirikan tahun 1987, Health Level Seven (HL7) adalah salah satu dari beberapa standar ANSI (American National Standards Institute), yang telah terakreditasi oleh SDO (Standards Developing Organizations. HL7 merupakan organisasi yang mengembangkan

standard bersifat non profit, dimana misinya adalah menyediakan standar untuk pertukaran data, integrasi, share dan penyimpanan informasi kesehatan elektronik untuk mendukung praktis klinis dan mendukung managemen, mengirimkan dan mengevaluasi pelayanan kesehatan. Dapat dikatakan HL7 bukan standar arsitektur aplikasi dan basis Data namun HL7 merupakan standar pertukaran data secara elektronik dalam bentuk messaging standard. Gambar 2.2 Antarmuka tanpa HL7 Gambar 2.3 Antarmuka tanpa HL7 HL7 atau Health Level Seven maksudnya Layer ke tujuh dari OSI Model yang diaplikasikan dalam konsep healthcare system. Penerapan model OSI atau Open System Interconnection yang mengatur konsep

protocol layers terdiri dari 7 layers. HL7 berada di posisi aplikasi atau di layer ke 7 dan berbasis pada aplikasi healthcare. HL7 menerbitkan suatu framework berupa template struktur data berdasarkan Reference Information Model (RIM) yang berisi spesifikasi tabel dan field sesuai kebutuhan sistem administrasi di klinik maupun rumah sakit secara spesifik. Template tersebut akan dijadikan sumber acuan standar bagi para pengembang aplikasi software. HL7 interface engine adalah interface atau mesin integrasi yang dibuat khusus untuk industry sarana pelayanan kesehatan. Interface tersebut merupakan system yang ada dengan menggunakan standard messaging protocol, dikarenakan rumah sakit dan sarana pelayanan kesehatan lain biasanya mempunyai system yang berbeda untuk berbagai aspek pelayanan yang mereka miliki. Mereka seringkali tidak dapat berkomunikasi satu sama lain. HL7 memecahkan masalah tersebut dengan menyediakan framework untuk bertukar data, integrasi, berbagi, pengambilan data dari informasi kesehatan elektronik. 2.1.1 Pemanfaatan HL7 pada EHR Sistem Informasi Pelayanan Kesehatan berkembang sangat pesat akhir-akhir ini. Bermula dari sistem informasi yang terisolasi di masing-masing rumah sakit ataupun organisasi pelayanan kesehatan primer. Hal ini menyebabkan kondisi spesifik yang dihadapi. Saat ini di Indonesia tercatat sekitar 1300 RS dan ribuan puskesmas (Menkes RI) yang tentunya pemerintah perlu memikirkan rancangan induk (grand disain) EHR yang disusun secara strategis per regional meliputi wilayah Indonesia Timur, Tengah dan Barat. Rancangan EHR tersebut tentunya harus dapat mengatasi hal-hal yang sering terjadi pada rekam medis berbasis kertas antara lain: (1) Aksesibilitas informasi kesehatan pasien belum real time, (2) kelengkapan, keakuratan dan keamanan informasi kesehatan pasien masih rendah, (3) Pemanfaatan data pasien dalam pengambilan keputusan, perencanaan, pelaksanaan

dan evaluasi di sarana pelayanan kesehatan oleh para pengelola sarana pelayanan kesehatan belum optimal, (4) Data pasien belum dioptimalkan oleh para tenaga kesehatan untuk memberikan pelayanan secara berkesinambungan dalam rangka pelayanan yang efektif dan efisien. EHR terdefinisikan sebagai pencatatan pelayanan kesehatan dalam paket format proses komputer yang dapat terbaca tetapi dapat diperluas termasuk di dalamnya dimanipulasi dalam program dan proses otomatis. (ISO TC 215, ISO/TR 20514). Interoperability dalam EHR didefinisikan sebagai kemampuan dua atau lebih aplikasi untuk berkomunikasi secara efektif tanpa melakukan kompromi ketika melakukan transmisi EHR. Sangat penting untuk mengembangkan standar secara nasional dan internasional untuk EHR agar dapat : Bertukar data informasi pasien antara profesi kesehatan dalam berbagai macam pelayanan kesehatan Bertukar data informasi pasien antara berbagai macam organisasi, lingkup enterprise, regional atau system nasional bahkan antar negara. Mendukung interoperability antara aplikasi dari pembuat yang berbeda Terdapat dua tipe interoperability yang sesuai untuk tujuan tersebut yaitu functional interoperability dan semantic interoperabilityi. Functional interoperability berkaitan dengan pertukaran informasi antara dua atau lebih sistem dalam format yang dapat dibaca oleh manusia. Sedangkan Semantic interoperability berkaitan dengan pertukaran informasi antara dua atau lebih system dalam format yang terproses computer dan diterima system. Untuk memenuhi Semantic Interoperability ada persyaratan yang harus terpenuhi yaitu

Standarisasi EHR reference model, berkaitan dengan EHR struktur Standarisasi service interface, berkaitan dengan semantic interface antara EHR dan service lain Standarisasi dalam domain-spesific consept models, berkaitan dengan archetypes dan template untuk domain konsep yang berbeda. Standarisasi terminology, berkaitan dengan bahasa yang digunakan dalam archetypes. Dua persyaratan awal berkaitan juga dengan functional interoperability. Informatika sarana pelayanan kesehatan penuh dengan berbagai macam standar yang membantu untuk menyusun berbagai aspek aplikasi di pelayanan kesehatan. Aplikasi dibangun dari standar tersebut untuk penyimpanan dan struktur semantic. Terdapat berbagai interoperability dalam EHR di Amerika dan Eropa diantaranya adalah ISO adalah organisasi internasional untuk standarisasi yang telah diakui di 157 negara. ISO memproduksi standar EHR terbatas pada struktur dan fungsi EHR serta system yang diproses dalam EHR CEN adalah European Committee for Standardisation, yang terlibat dalam pengembangan multidisiplin standar termasuk system di pelayanan kesehatan. CEN dipakai di Uni Eropa dan beberapa negara di luar Eropa HL7 adalah Health Level Seven, merupakan salah satu American National Standards Institute (ANSI), terstandarisasi oleh American National Standards Institute (ANSI)-yang bergerak di area pelayanan kesehatan. HL7 dipakai di Amerika, Eropa, Asia dan Australia. Tujuannya adalah menyediakan standar untuk pertukaran data antara berbagai tipe aplikasi computer. HL7 domain termasuk data klinis dan administrative.

DICOM Digital Imaging and Communication in Medicine adalah asosiasi industry medis dan organisasi profesi medis, berada di bawah the National Electrical Manufacturers Association (NEMA). Mereka telah membuat DICOM sebagai standar untuk komunikasi gambar medis. Standar ini mengatur pertukaran gambar medis dan informasi yang berkaitan. Pemilihan HL7 dalam pembangunan HER ini karena HL7 menerbitkan suatu framework berupa template struktur data berdasarkan Reference Information Model (RIM) yang berisi spesifikasi tabel dan field sesuai kebutuhan sistem administrasi di klinik maupun rumah sakit secara spesifik. Template tersebut mendukung karena : Template tersebut akan dijadikan sumber acuan standar bagi para pengembang aplikasi software. Human-to-Human Communication - templates ini menyediakan konsep atau struktur bagi suksesnya komunikasi antar orang dalam suatu institusi ataupun antar kelompok organisasi yang membutuhkan pertukaran informasi khususnya informasi dalam bidang medis. Constraint and validation of computer-to-computer messages - templates ini digunakan untuk merancang validasi atau verifikasi input data dalam suatu medical system. Construction - templates untuk mengarahkan dan mengatur informasi pada media input data. Selain itu mendefinisikan field-field apa saja yang dibutuhkan dalam sebuah informasi data, apa saja tipe datanya, nilai field-field tertentu dalam sebuah medical system dll. Predication - templates untuk memastikan output apa saja yang dibutuhkan pada suatu sistem atau sub-system determine, contohnya apa saja yang perlu diinformasikan berkenaan dengan deskripsi hasil test laboratorium, dan informasi apa saja yang dapat dimanfaatkan

untuk para pengambil keputusan seperti dokter dll untuk membantu klien. Description - templates ini menjelaskan hubungan antara elemen yang dapat dilihat dari sebuah sistem. Selain itu terdapat HL7 interface engine, dengan melalui HL7 interface engine sarana pelayanan kesehatan dapat mengambil manfaat informasi yang telah ada tanpa melakukan investasi besar lagi dengan teknologi baru, biaya yang murah serta tanpa menganggu sistem yang telah ada. Disamping itu terdapat peluang untuk berhubungan dengan sistem di luar sarana mereka. Alasan lain menggunakan HL7 adalah biasanya rumah sakit dan organisasi kesehatan lainnya memiliki banyak sistem komputer yang berbeda digunakan untuk segala sesuatu dari catatan penagihan untuk pelacakan pasien.semua sistem harus berkomunikasi dengan satu sama lain (atau "interface") ketika mereka menerima informasi baru, tetapi tidak semua melakukannya. HL7 menetapkan sejumlah standar yang fleksibel, pedoman, dan metodologi di mana sistem berbagai kesehatan dapat berkomunikasi satu sama lain. Pedoman atau standar data adalah seperangkat aturan yang memungkinkan informasi untuk dibagikan dan diproses dengan cara yang seragam dan konsisten. Standar-standar data dimaksudkan untuk memungkinkan organisasi kesehatan untuk dengan mudah berbagi informasi klinis.secara teoritis, kemampuan untuk bertukar informasi harus membantu untuk meminimalkan kecenderungan untuk perawatan medis secara geografis terisolasi dan sangat bervariasi. HL7 mengembangkan standar konseptual (misalnya, HL7 RIM ), standar dokumen (misalnya, HL7 CDA ), standar aplikasi (misalnya, HL7 CCOW ), dan standar pesan (misalnya, HL7 v2.x dan v3.0).pesan standar sangat penting karena mereka mendefinisikan bagaimana informasi dikemas dan dikomunikasikan dari satu pihak kepada pihak

lain. Standar tersebut mengatur jenis bahasa, struktur dan data yang diperlukan untuk integrasi mulus dari satu sistem ke sistem lain. HL7 meliputi siklus hidup lengkap dari sebuah spesifikasi standar termasuk pengembangan, adopsi, pengakuan pasar, pemanfaatan, dan kepatuhan. Bisnis menggunakan standar HL7 membutuhkan keanggotaan organisasi dibayar dalam HL7 HL7 Anggota Inc dapat mengakses secara gratis standar dan non anggota dapat membeli standar dari HL7 atau ANSI.

BAB III METODOLOGI PENELITIAN 3.1 Metode Penelitian Metode penelitian yang digunakan dalam penelitian yang dilakukan oleh penulis adalah penelitian tindakan atau sering disebut sebagai action research. Zuriah (2003: 54) mengemukakan bahwa penelitian tindakan menekakan pada kegiatan (tindakan) dengan mengujicobakan suatu ide ke dalam praktek atau siduasi nyata dalam skala mikro yang diharapkan kegiatan tersebut mampu memperbaiki, meningkatkan kualitas, dan melakukan perbaikan sosial.[9] Selain itu penelitian tindakan dapat dikatakan mempunyai tujuan mengembangkan keterampilan-keterampilan baru atau cara pendekatan baru dan untuk memecahkan masalah dengan penerapan langsung didunia kerja. Dari pengertian dan tujuan tersebut penulis merasa cocok menggunakan metode penelitian tindakan atau action research guna mendukung tercapainya tujuan penulis. Secara garis besar, langkah-langkah dalam penelitian tindakan ini meliputi perencanaan (planning), pelaksanaan (acting), pengamatan (monitoring), dan refleksi/ penilaian (reflecting). Keempat langkah tersebut dapat dilihat dari bagan berikut ini: Gambar 3.1 Langkah Penelitian Tindakan Dari gambar tersebut, dapat kita ketahui bahwa dari langkah-langkah tersebut dapat menjadi satu siklus. Yang artinya, siklus dari keempat langkah

tersebut dapat berulang. Siklus dapat berhenti bila peneliti sudah merasa puas akan hasil yang dicapainya. Dalam Nazir (1988: 97-98) dikemukakan langkah-langkah pokok dalam penelitian tindakan sebagai berikut: 1. Rumusan masalah dan tujuan penelitian bersama-sama antara peneliti dan pekerja praktis dan decision maker 2. Himpun data yang tersedia tentang hal-hal yang berhubungan dengan masalah ataupun metode-metode dengan melakukan studi kepustakaan. 3. Rumuskan hipotesa serta strategi pendekatan dalam memecahkan masalah 4. Buat desain penelitian bersama-sama antara peneliti dengan pelaksana program serta rumuskan prosedur, alat dan kondisi pada mana penelitian tersebut akan dilaksanakan 5. Tentukan kriteria evaluasi, teknik pengukuran, serta teknik-teknik analisa yang digunakan 6. Kumpulkan data, analisa, beri interpretasi serta generalisasi dan saran-saran 7. Laporkan penelitian dengan penulisan ilmiah Setelah mendapatkan teori mengenai acuan guna melaksanakan penelitian, peneliti memilih tempat penelitian di Rumah Sakit Telogorejo yang beralamat di Jalan KH.A. Dahlan Semarang Jawa Tengah Indonesia. 3.2 Metode Pengumpulan Data 3.2.1 Jenis Data Jenis data yang digunakan dalam penelitian ini adalah jenis data kualitatif. Jenis data kualitatif yaitu prosedur penelitian yang menghasilkan data tidak dalam bentuk angka, meliputi informasi tentang kriteria kriteria apa saja yang dibutuhkan guna mencapai komunikasi data antar database yang berbasis HL7 message.

3.2.2 Sumber Data a. Data Primer Data primer yaitu data yang diperoleh secara langsung dari sumber data tersebut yang berhubungan dengan penelitian yang dilakukan, yaitu data-data yang diperoleh dari wawancara dan survei atau pengamatan langsung, yang digunakan sebagai bahan acuan dalam pembuatan aplikasi. Contoh data primer yang dibutuhkan penulis untuk menunjang pembuatan aplikasi adalah data detail dari pasien, data detail dari penyakit, dimana nanti hasil dari data pasein dan penyakit itu dapat dimasukan ke dalam hasil diagnosa. Dan dari hasil diagnosa tersebut akan dibuat standar konumkasi menggunakan HL7 message agar data yang terdapat pada diagnosa pasien bisa dikomunikasikan. b. Data Sekunder Data yang diperoleh dari data penulis dalam bentuk yang sudah jadi yang bersifat informasi dan kutipan, baik dari internet maupun literatur, pustaka, jurnal yang berhubungan dengan penelitian yang dibuat. Contoh data sekunder yang dibutuhkan penulis adalah data yang memuat informasi penggunaan HL7 message dan bagaimana cara atau penentuan dan pengunaan standar-standar yang bisa digunakan pada proses transaksi dan komunikasi data. 3.3 Rancangan Penelitian Berdasarkan latar belakang masalah serta tujuan yang telah diuraikan pada bab 1, peneliti menggunakan pendekatan kualitatif yaitu berawal pada data dan berakhir pada kesimpulan. Dengan adanya batasan masalah maka penelitian yang dilakukan pada objek penelitian dimungkinkan tidak melebar dari tujuan yang ingin dicapai, sehingga pengumpulan data dapat dilakukan secara tepat. Agar penelitian semakin terarah dan sesuai dengan tujuan yang ingin dicapai, maka diperlukan sebuah rancangan yang

digunakan sebagai pedoman dalam penelitian, dengan tahapan yang akan penulis gambarkan dengan bagan sebagai berikut : Studi Pustaka Analisis Data Perancangan sistem Studi Lapangan Pembuatan Laporan Pengujian Sistem Implementasi Gambar 3.2 Bagan Rancangan Penelitian Rincian mengenai rancangan penelitian yang akan penulis gunakan akan penulis jelaskan sebagai berikut : 1. Studi Pustaka Data sekunder peneliti dapatkan dari hasil studi pustaka. Tahap ini dilakukan dengan mempelajari buku-buku referensi atau sumbersumber yang berkaitan dengan skripsi ini, baik dari text book maupun internet. Data data yang peneliti kumpulkan dari hasil studi pustaka adalah : a) Konsep mengenai penerapan HL7 message yang dapat bermanfaat untuk sinkronisasi database yang bisa diterapkan pada database rumah sakit. b) Materi mengenai pemnyusunan kode-kode HL7 message. c) Pengumpulan jurnal jurnal yang berhubungan dengan konsep database rumah sakit dan penggunaan HL7 message. d) Teori teori yang dibutuhkan selama penelitian yang telah diuraikan pada bab 2 tinjauan pustaka. 2. Studi Lapangan Pada tahap ini data data primer dikumpulkan. Proses pengumpulan data yaitu dilakukan dengan wawancara kepada kepala Kepala Bagian IT di Rumah Sakit Telogorejo dan melakukan survei

langsung ketika proses pengolahan data pasien. Data data yang berhasil peneliti kumpulkan selama proses wawancara dan survei adalah : a) Proses-proses yang biasa terjadi pada rumah sakit yang berhubungan dengan teknik informatika. b) Kriteria kriteria yang harus dipenuhi dalam pembuatan database untuk rumah sakit. c) Kriteria kriteria yang harus dipenuhi dalam proses-proses transaksi pada rumah sakit. d) Proses dan manfaat penerapan HL7 message untuk data-data rumah sakit. 3. Analisis Data Ketika semua data telah terkumpul, maka tahapan selanjutnya adalah melakukan proses analisis data. Pada tahapan ini proses analisis yang dilakukan ada dua hal, yang pertama adalah analisis data yang diperoleh dan analisis kebutuhan, dan yang kedua adalah definisi dari kebutuhan tersebut. Analisis data primer yang telah dikumpulkan meliputi analisis data-data yang dibutuhkan untuk pasien, dokter, dan penyakit. Dan untuk analisis kebutuhan meliputi kebutuhan dari sistem yang tentunya meliputi kriteria proses yang harus memenuhi standar sehingga data dan laporannya dapat diperlakukan sesuai standar HL7 message. Selain itu kebutuhan informasi, kebutuhan perangkat keras, kebutuhan perangkat lunak juga memerlukan analisis guna mendapatkan hasil olahan data untuk sistem yang benar yang tentunya sesuai dengan standar yang diinginkan.

4. Perancangan Sistem Dalam melakukan perancangan sistem, peneliti menggunakan alat bantu perancangan yaitu Diagram Konteks (Contex Diagram), Diagram Dekomposisi (Decompotition Diagram) dan Diagram Alir Data (Data Flow Diagram / DFD). Sedangkan untuk melakukan perancangan basis datanya, peneliti menggunakan Entity Relationship Diagram (ERD), Transformasi ERD ke tabel. Kemudian dilanjutkan dengan perancangan isian fields yang berisikan kode-kode HL7 message untuk hasil diagnosa pasien. 5. Implementasi Pada tahap ini mulailah penyusunan kode-kode HL7 message untuk hasil diagnosa pasien sesuai dengan standar-standar HL7 message. Kode tersebut diharapkan dapat digunakan sebagai isian fields agar tabel tersebut dapat dikomunikasikan dengan database yang lain. 6. Pengujian Sistem (Testing) Setelah semua proses implementasi selesai dilakukan, tahap selanjutnya adalah pengujian yang bertujuan untuk menguji kebenaran dalam penyusunan kode-kode standar HL7 message untuk komunikasi data hasil diagnosa pasien. 7. Pembuatan Laporan Dan tahapan paling akhir adalah pembuatan laporan yang bertujuan untuk dijadikan sebagai dokumentasi hasil penelitian.

3.4 Variabel Penelitian Variabel penelitian merupakan suatu informasi yang nilainya tidak tetap. Dalam penelitian, terdapat klasifikasi variabel yang akan digunakan untuk mempersiapkan alat dan metode pengumpulan data, metode analisis atau pengolahan data, serta untuk melakukan pengujian. Karena penelitian ini bersifat kualitatif, maka variabel penelitiannya adalah orang atau aktor yang berperan dalam sistem yang berjalan. Dan aktor yang dimaksud antara lain adalah Kepala Bagian IT Rumah Sakit Telogorejo. 3.5 Populasi dan Sampel Populasi merupakan kumpulan atau keseluruhan anggota dari objek penelitian dan memenuhi kriteria tertentu yang telah ditetapkan dalam penelitian. Penelitian yang melibatkan populasi sebagai objek disebut sensus. Sedangkan sampel adalah bagian tertentu dari unit populasi. Dalam penelitian yang bersifat kualitatif ini, penelitian hanya berfokus pada satu objek penelitian saja yaitu proses penerapan HL7 message untuk integrasi database rumah sakit Telogorejo sebagai objek utamanya. Karena sistem yang akan dibuat adalah sistem yang akan menggunakan penerapan HL7 message untuk solusi inegrasi Database guna Mendukung Pelayanan Kesehatan Masyarakat. Sedangkan untuk sampelnya adalah contoh hasil laporan dan data-data dari penerapan HL7 message. 3.6 Instrumen Penelitian Instrumen penelitian adalah alat yang digunakan untuk mengumpulkan data selama proses penelitian berlangsung. Instrumen atau alat penelitian ini dapat berupa angket atau kuisioner. Karena pada penelitian yang dilakukan oleh peneliti bersifat kualitatif maka instrumen penelitian adalah peneliti sendiri, karena peneliti sebagai pengumpul data yang mempengaruhi terhadap faktor instrumen. Adapun reliabilitas dan validitasnya lebih pada kelayakan dan kredibilitas peneliti karena alat ukur

dalam penelitian kualitatif juga bersifat kualitatif juga, sehingga sangat abstrak akan tetapi lengkap dan mendalam. 3.7 Ruang Lingkup Penelitian Ruang lingkup penelitian sangat dibutuhkan agar penelitian tetap terarah dan sesuai dengan tujuan dari penelitian ini. Ruang lingkup yang dimaksud adalah menentukan batasan batasan yang diperlukan untuk melakukan pengumpulan data sebagai bahan analisa data, perancangan sistem dan mendefinisikan kebutuhan kebutuhan yang diperlukan, untuk membangun sistem serta mengimplementasikannya kepada objek penelitian. Batasan batasan penelitian didasarkan pada latar belakang serta tujuan penelitian. Adapun ruang lingkup dalam proses penelitian ini adalah peneliti hanya melakukan penyusunan kode-kode menggunakan standar HL7 message untuk data diagnosa pasein, penyusunan tersebut diharapkan dapat bermanfaat untuk komunikasi data tersebut di pihak lain. 3.8 Prosedur Pengumpulan Data Metode pengumpulan data memiliki peran yang sangat penting, karena metode pengumpulan data akan menentukan kualitas dan keakuratan data yang akan dikumpulkan selama proses penelitian. Dengan berbagai macam metode pengumpulan data, peneliti akan menggunakan metode sebagai berikut : 1. Wawancara (Interview) Metode pengumpulan data melalui wawancara ini dilakukan pada pihak rumah sakit dan poliklinik guna mendapatkan data-data yang berhubungan dan mendukung untuk pendataan pasien dan pendataan penyakit. Kebutuhan data ini penulis penuhi dengan melakukan wawancara pada pihak Rumah Sakit Telogorejo Semarang.

2. Survei Metode in dilakukan dengan cara melakukan pengamatan dengan mengamati objek secara langsung dimana objek tersebut tentunya mendukung atau berhubungan dengan penelitian. Kegiatan yang dilakukan adalah melakukan riset mengamati langsung proses olah data dan transaksi data yang dibutuhkan oleh pasien dan penyakit. Dengan metode survei ini penulis akan mencoba mengamati proses dari transaksi data pasien dan penyakit, contohnya proses yang untuk identifikasi penyakit pada pasien. 3. Studi Pustaka (Library Research Method) Merupakan metode yang dilakukan dengan cara mencari sumber dari buku-buku yang ada, selain buku juga terdapat paper atau artikel yang dapat menambah informasi guna mendukung penelitian. Dengan metode studi pustaka ini penulis sedikit banyak mendapatkan info dari beberapa jurnal yang tentunya menambah informasi penulis mengenai HL7 message. 3.9 Kerangka Pikir Setelah menjelaskan mengenai rancangan penelitian yang akan dilakukan penulis dalam menyusun laporan tugas akhir ini, sebelum mengungkapkan mengenai variabel penelitian yang memuat informasiinformasi yang dibutuhkan, penulis akan menjabarkan mengenai kerangka pikir dalam proses penelitian yang dilakukan penulis. Penjabaran kerangka pikir akan digambarkan dalam bagan sebagai berikut :

Kebutuhan standar integrasi data rumah sakit Penggunaan HL7 message Integrasi data rumah sakit Meminimalisir kesalahan pengolahan data Gambar 3.3 Bagan Kerangka Pikir Melihat bagan kerangka pikir di atas, penulis memiliki kerangka pikir bahwa masalah yang ada adalah guna melakukan integrasi data-data rumah sakit atau dapat dikatakan data-data rekam medik, dibutuhkan standar komunikas tersendiri, karena pada dasarnya data-data rekam medik memilih kecenderungan isinya sama, hanya penamaan field pada databasenya berbeda tergantung pada pembuatnya. Maka itu, agar terjadi integrasi data sehingga dapat menjalin komunikasi data-data tersebut, diperlukan standar komunikasi. Pada data rekam medik, terdapat standar komunikasi yakni HL7 message yang dapat digunakan untuk integrasi data-data rekam medik. Sehingga data-data tersebut dapat terjalin integrasi data yang diharapkan dapat memudahkan pengembang dalam mengolah data-data yang sudah ada. Sehingga kesalahan-kesalahan dalam komunikasi data dapat diminimalisir yang dapat berdampak positif pula pada pasien.

3.10 Teknik Analisis Data Setelah semua data diperoleh, langkah selanjutnya adalah melakukan analisa terhadap data tersebut secara kualitatif. Karena penelitian ini bersifat kualitatif maka alat yang digunakan dalam analisis data adalah peneliti sendiri. Peneliti melakukan analisa data untuk mengidentifikasi kebutuhan, merancang sistem, mengimplementasikan sistem pada objek yang diteliti. Dalam tahap analisis data ini, dilakukan tahap tahap sebagai berikut : 1. Pengelompokan data Data yang diperoleh selama proses penelitian kemudian dianalisis sesuai dengan jenis datanya, yaitu jenis data primer dan jenis data sekunder. Jenis data primer adalah data yang didapatkan langsung pada objek penelitian yang berhubungan dengan penelitian yang dilakukan. Data - data tersebut diperoleh dari wawancara dan survei atau pengamatan langsung, yang digunakan sebagai bahan acuan dalam pembuatan aplikasi. Dan yang kedua adalah jenis data sekunder yaitu data yang diperoleh dari hasil studi pustaka yang peneliti ambil dari buku, jurnal, literatur dan media internet yang berhubungan dengan penelitian yang dilakukan. Dan semua data data tersebut dianalisis agar dapat digunakan dan sesuai dengan standar HL7message yang gunakan oleh peneliti. 2. Analisa kebutuhan Seteleh menganalisis data dan mengelompokkannya berdasarkan jenis datanya maka tahap selanjutnya adalah melakukan analisis kebutuhan data. Analisis kebutuhan tersebut meliputi : a. Kebutuhan informasi Kebutuhan informasi mencakup semua informasi yang dibutuhkan. Baik oleh aktor yang memahami mengenai transaksi HL7 message maupun mengenai penyusunan kode-kode HL7 message.

b. Kebutuhan perangkat keras Untuk kebutuhan perangkat keras, peneliti menggunakan perangkat keras yang sudah dimiliki oleh peneliti sendiri. c. Kebutuhan perangkat lunak Kebutuhan perangkat lunak disesuaikan dengan kebutuhan pengguna dan kebutuhan dari pembuatan aplikasi nantinya. 3. Perancangan Setelah tahap analisis kebutuhan selesai dilakukan maka tahap selanjutnya adalah melakukan perancangan sistem yang akan dibuat. Tahap perancangan adalah : a. Context diagram Menjelaskan struktur terluar dan paling umum dari sebuah sistem dimana sistem ini akan menggunakan penerapan HL7 message pada database rumah sakit. Penerapan HL7 message yang akan penulis rancangan adalah penerapan pada proses diagnosa penyakit pada pasien. Identifikasi urutan proses yang harus dilalui adalah : i. Menentukan entitas terkait dalam pembuatan database untuk penerapan HL7 message, entitas tersebut antara lain : 1) Entitas Penyakit 2) Entitas Pasein 3) Entitas Diagnosa ii. Menentukan data flow arus input output antara entitas dan sistem diagnosa penyakit pada pasien. b. DFD levelled Jika sebuah context diagram telah dirancang, maka akan digambarkan data flow yang lebih terperinci lagi, yaitu DFD level 0 dan seterusnya. i. DFD level 0 1) Pendataan pasein 2) Pendataan penyakit

3) Pendataan diagnosa ii. DFD level 1 1) DFD level 1 (pendataan pasien) a) Input data pasien 2) DFD level 1 (pendataan penyakit) a) Input data penyakit 3) DFD level 1 (pendataan diagnosa) a) Input data dokter b) Edit data dokter c. Mendesain database 1) Membuat Entity Relationship Diagram (ERD) 2) Membuat transformasi ERD ke tabel d. Membuat kode HL7 message Penyusunan kode HL7 message ini langsung menggunakan pada SQLyog, dimana sebelumnya dapat dilakukan pada notepad ++ yang kemudian dicopy dan paste ke dalam isian fields tabel hasil diagnosa. e. Melakukan pengujian Pada tahap ini akan dilakukan 2 tahap pengujian, yang pertama adalah tahap pengujian tiap-tiap program atau unit program untuk memperbaiki error (bug) dalam penulisan kode dan untuk meyakinkan bahwa fungsi-fungsi yang dibentuk dapat berjalan sesuai keinginan. Tujuan dari tahap pertama ini adalah untuk menghasilkan unit program yang dapat dieksekusi dan valid. Pada pengujian tahap pertama, peneliti akan menggunakan metode pengujian User Acceptence Test. Sedangkan untuk tahap pengujian yang kedua adalah tahap pengujian pencocokan standart HL7 message dari data-data yang telah ada dengan standar-standar yang seharusnya ada saat melakukan transaksi penggunaan data kesehatan. Dalam tahap pengujian ini akan dilakukan pengujian pencocokan hasil

pengolahan data yang dilakukan oleh aplikasi dan dilakukan secara manual oleh peneliti. f. Melakukan implementasi Setelah tahap pengujian kode-kode yang telah peneliti buat dan diuji sesuai dengan standar, maka kode tersebut dapat langsung dipakai untuk isia fields tabel hasil diagnosa atau yang berhubungan dengan data diagnosa pasien. Tentunya penerapan tersebut dilakukan pada objek penelitian yaitu pada Rumah Sakit Telogorejo Semarang.

BAB IV HASIL PENELITIAN DAN PEMBAHASAN 4.1 Hasil Penelitian Hasil penelitian memuat data hasil penelitian yang relevan dengan tujuan tugas akhir. Data hasil penelitian diperoleh dari hasil wawancara dan survei yang dilakukan langsung di lapangan dan studi pustaka yang penulis lakukan secara bertahap dan berkelanjutan untuk mendapatkan data yang sesuai dan benar-benar relevan. Data - data yang diperoleh kemudian dianalisa lebih lanjut. Sebagai tahap awal, data dikelompokkan berdasarkan jenis sumbernya, yaitu data primer dan data sekunder. 1. Data primer Data primer merupakan data yang diperoleh secara langsung pada objek penelitian yaitu proses-proses data yang menggunakan standar komunikasi HL7 message. Peneliti melakukan analisa terhadap proses-proses yang berlangsung pada rumah sakit Telogorejo yang berhubungan dengan komunikasi data yang menggunakaan standar HL7 message. Dari analisa dan pengamatan tersebut, peneliti mendapatkan data-data yang dibutuhkan yang dapat dikatakan sebagai data primer. Data tersebut antara lain : 1) Proses diagnosa pasien yang sering terjadi dan pada proses tersebut dapat diterapkan proses standarisasi komunikasi data menggunakan standar HL7 message. 2) Data - data pasien yang diperlukan guna berjalannya proses diagnosa pasien. 3) Data - data diagnosa itu sendiri guna nanti mengehatui hasil diagnosa terhadap pasien rumah sakit. 4) Contoh hasil diagnosa terhadap sorang pasien.

5) Perangkat keras Untuk perangkat keras, peneliti mengoptimalkan perangkat keras yang dimiliki oleh instansi. 6) Perangkat lunak Peneliti menggunakan windows xp. Untuk database beserta peneliti menggunakan SQLyog yang dirasa cukup mudah dalam pembuatan dan pembuktian penggunaan standar HL7message. 2. Data Sekunder Data sekunder adalah data yang diperoleh secara tidak langsung untuk mendukung penelitian. Data sekunder tersebut diperoleh dari hasil studi pustaka yang peneliti ambil dari berbagai buku, jurnal, dan media global internet. Data sekunder yang berhasil dikumpulkan untuk mendukung penelitian ini antara lain : 1) Materi mengenai penggunaan standar HL7 message untuk data rumah sakit. 2) Teori teori yang berkaitan dengan penelitian yang telah dituangkan dalam tinjauan pustaka pada bab 2. 4.2 Analisis Hasil Penelitian Data hasil penelitian yang telah diperoleh dan dikelompokkan menurut jenis sumber datanya, kemudian dianalisa lebih lanjut. Sebelum melakukan pembuatan sebuah pembuktian komunikasi data menggunakan HL7message, dilakukan suatu perancangan akan perangkat lunak tersebut. Perancangan berguna untuk melakukan semua persiapan pembuatan perangkat lunak, termasuk menganalisa kebutuhan kebutuhan yang ada. 4.2.1 Kebutuhan Sistem Kebutuhan sistem disini akan meliputi kebutuhan informasi yang dibutuhkan, kebutuhan perangkat keras yang akan digunakan, dan juga kebutuhan perangkat lunak yang nantinya digunakan untuk pembuatan program aplikasinya

4.2.1.1 Kebutuhan Informasi Agar kode-kode HL7 message ini dapat disusun dengan baik dan benar sesuai standar HL7 message, maka perlu dilakukan identifikasi informasi. Informasi yang dibutuhkan antara lain : a. Informasi untuk data penyakit Jika proses diagnosa sudah mendapatkan hasil, tentunya hasil dari proses diagnosa ini nantinya akan diberitahukan kepada dokter-dokter yang bersangkutan sesuai dengan kategori dokter yang sesuai dengan hasil diagnosa tersebut. b. Informasi untuk pasien Jika pasien telah menjalani proses diagnosa, maka nantinya hasil dari proses tersebut dapat diberitahukan kepada pasien yang berobat dengan sangat menjaga kerahasiaannya. Kerahasiaan tersebut dengan cara tidak memberikan hasil diagnosa kepada pihak yang tidak berwenang. 4.2.1.2 Kebutuhan Perangkat Keras Aplikasi sistem pendukung keputusan ini akan dibangun secara standalone. Dalam penelitian ini, peneliti memanfaatkan perangkat keras yang sudah dimiliki sebelumnya oleh instansi. Perangkat keras yang dimaksud yaitu sebuah netbook dengan prosesor intel atom @1,83 GHz, RAM berkapasitas 1 GB DDR3, Harddisk 250 GB, dan mouse standar. 4.2.1.3 Kebutuhan Perangkat Lunak Aplikasi sistem pendukung keputusan yang akan dibuat membutuhkan perangkat lunak sebagai berikut :

1. Windows xp Windows xp sebagai sistem operasinya. Alasan penggunaan sistem operasi berbasis windows yaitu karena kebanyakan end-user sudah familiar dengan interface dari sistem operasi yang berbasis windows. Dan juga karena fileds tabel diisi HL7 message maka agar mempermudah penulis menggunakan SQLyog. 2. SQLyog Dalam pembuatan database ini yang nantinya diikuti dengan membuatan kode-kode standar HL7 message untuk proses diagnosa pasien, penulis memilih menggunaan SQLyog agar mempermudah penulis. Karena software ini telah sering digunakan. 4.2.2 Proses Perancangan 4.2.2.1 Skenario yang akan Dicapai Sebagai tahap awal dalam proses perancangan, maka peneliti akan memberikan deskripsi atau gambaran mengenai tujuan yang akan dicapai : Pada proses diagnosa, diharapakan hasil yang diperoleh nantinya bisa mengalami proses transaksi data, dikarenakan hasil proses diagnosa ini dapat ditangani tidak hanya di Rumah Sakit Telogorejo, namun di rumah sakit lain dengan standar komunikasi yang sama yakni HL7 versi 2.3. 4.2.2.2 Diagram Konteks Diagram Konteks adalah diagram yang menggambarkan sistem dalam satu lingkaran dan menunjukkan hubungan antara proses dengan entitas luarnya. Sistem yang dimaksud proses diagnosa pasien yang dapat digambarkan diagram konteksnya sebagai berikut.

Penyakit Data penyakit 0 Diagnosa Data pasien Pasien Data diagnosa Data diagnosa Hasil_Diagnosa Gambar 4.1 Diagram Konteks Proses Diagnosa Pasien 4.2.2.3 Diagram Alir Data / Data Flow Diagram (DFD) Diagram alir data merupakan penggambaran lebih detail dan lebih rinci dari proses yang telah digambarkan sebelumnya pada konteks diagram. Dari proses yang dijelaskan pada konteks diagram akan diperinci ke DFD level 0, dan proses yang dijelaskan pada DFD level 0, akan diperinci lagi pada DFD level 1, dan seterusnya. 4) DFD level 0 i. Pendataan Penyakit ii. Pendataan Pasein iii. Pendataan Hasil Diagnosa 5) DFD level 1 (pendataan penyakit) i. Input data penyakit 6) DFD level 1 (pendataan pasien) i. Input data pasien 7) DFD level 1 (pendataan hasil diagnosa) i. Input data diagnosa

data penyakit 1 Pendataan penyakit data penyakit penyakit data pasien 2 Pendataan pasien data pasien pasien data penyakit data pasien 3 Hasil diagnosa data diagnosa diagnosa Gambar 4.2 DFD Level 0 4.2.3 Perancangan Basis Data Setelah tahap perancangan sistem selesai dilakukan maka tahapan selanjutnya adalah melakukan perancangan basis data. Dalam tahapan ini akan dilakukan beberapa hal, yaitu pertama pembuatan ERD, kemudian mentransformasikan ERD ke tabel, normalisasi tabel, pembuatan relasi antar tabel, dan yang terakhir adalah pembuatan kamus data. ERD merupakan sebuah diagram yang menggambarkan hubungan antar objek data dalam sebuah sistem basis data. Objek data atau entitas yang saling berhubungan dalam sistem basis data yang

akan dibuat antara lain adalah penyakit, pasien,hasil diagnosa. ERD yang dapat dijelaskan oleh penulis adalah sebagai berikut: kd_pelayanan kd_puskesmas kd_penyakit kd_icd_induk jns_kasus kd_penyakit kd_pasien message penyakit 1 m pemeriksaan diagnosa m is_default penyakit kd_pasien dimiliki kd_puskesmas tgl_pendaftaran m nama_tengah pasien nama_belakang status_maritial nama_depan tgl_lahir kd_agama kd_jenis_kelamin Gambar 4.3 Entity Relationship Diagram (ERD)

Tabel yang telah didefinisikan dalam ERD kemudian digambarkan secara fisik melalui relasi tabel sebagai berikut : Gambar 4.4 Relasi tabel Definisi adri fields yang terdapat pada tabel-tabel yang telah dibuat pada database dapat dijelaskan dalam kamus data sebagai berikut : 1. Tabel penyakit Nama tabel : penyakit Field kunci : KD_PENYAKIT KD_ICD_INDUK No. Nama Field Type Width Keterangan 1 KD_PENYAKIT Varchar 20 Kode penyakit 2 KD_ICD_INDUK Varchar 20 Kode icd induk 3 PENYAKIT Varchar 500 Nama penyakit

4 INCLUDE Varchar 20 Include penyakit 5 EXCLUDE Varchar 20 Exclude penyakit 6 NOTE Varchar 255 Catatan penyakit 7 STATUS_APP Varchar 255 Status penerapan penyakit 8 DESCRIPTION Varchar 255 Deskripsi penyakit 9 IS_DEFAULT Bit 1 Default penyakit Tabel 4.1 Tabel penyakit 2. Tabel pasien Nama tabel : pasien Field kunci : KD_PASIEN No. Nama Field Type Width Keterangan 1 KD_PASIEN Varchar 20 Kode pasien 2 KD_PUSKESMAS Varchar 20 Kode puskesmas 3 TGL_PENDAFTAR Datetime - Tanggal pendaftaran 4 NAMA_DEPAN Varchar 50 Nama depan pasien 5 NAMA_TENGAH Varchar 50 Nama tengah pasien 6 NAMA_BELAKANG Varchar 50 Nama belakang

pasien 7 TEMPAT_LAHIR Varchar 50 Tempat lahir pasien 8 KD_JENIS_KELAMIN Varchar 20 Kode janis kelamin pasien 9 WARGA_NEGARA Bit 20 Warga negara pasien 10. ALAMAT Varchar 500 Alamat pasien 11. KD_PROPINSI Varchar 20 Kode propinsi 12. KD_KABKOTA Varchar 20 Kode kabupaten 13. KD_KECAMATAN Varchar 20 Kode kecamatan 14. KD_KELURAHAN Varchar 20 Kode kelurahan 15. KD_POS Varchar 20 Kode pos 16. KD_PENDIDIKAN Varchar 20 Kode pendidikan 17. KD_PEKERJAAN Varchar 20 Kode pekerjaan 18. KD_AGAMA Varchar 20 Kode agama 19. STATUS_MARITAL Varchar 20 Status marital pasien 20. KD_GOL_DARAH Varchar 5 Kode golongan

daraha 21. NAMA_AYAH Varchar 20 Nama ayah pasien 22. NAMA_IBU Varchar 20 Nama ibu pasien 23. NAMA_KLG_LAIN Varchar 20 Nama keluarga lain pasien 24. RINCIAN _PENANGGUNG Varchar 200 Rincian penanggung 25. TELEPON Varchar 50 Telepon 26. HP Varchar 50 No hp 27. KD_CUSTOMER Varchar 20 Kode kostumer 28. KET_WIL Varchar 20 Keterangan wilayah 29. STATUS_HIDUP Bit 1 Status hidup 30. NAMA_ASURANSI Varchar 20 Nama asuransi 31. KETERANGAN Varchar 255 Keterangan 32. NO_ASURANSI Varchar 20 Nomer asuransi 33. KD_RAS Varchar 20 Kode ras 34. KK Varchar 255 Kakrtu kelurga 35. Created_By Varchar 20 Ditulis oleh 36. Created_Date Datetime - Ditulis tanggal 37. Update_By Varchar 20 Diperbaharui oleh

38. Update_Date Datetime - Diperbaharui tanggal 39. NAMA_SUAMI Varchar 20 Nama suami Tabel 4.2 Tabel pasien 3. Tabel diagnosa Nama tabel : diagnosa Field kunci : KD_PELAYANAN No. Nama Field Type Width Keterangan 1 KD_PELAYANAN Varchar 20 Kode pelayanan 2 KD_PUSKESMAS Varchar 20 Kode puskesmas 3 KD_PENYAKIT Varchar 20 Kode penyakit 4 JNS_KASUS Varchar 10 Jenis kasus 5 KD_PETUGAS Varchar 20 Kode petugas 6 TANGGAL Datetime - Tanggal 7 MESSAGE Text - Pesan HL7message Tabel 4.3 Tabel diagnosa 4.2.4 Perancangan Antarmuka 1. Desain input penyakit

Gambar 4.5 Desain antarmuka form input penyakit 2. Desain input pasien Gambar 4.6 Desain antarmuka form input pasien 3. Desain input diagnosa Gambar 4.7 Desain antarmuka form input diagnosa 4.3 Pembahasan i. Tampilan Form

Sebelum membahas mengenai pengkodean HL7 message untuk data hasil diagnosis pasien. Penulisan sajikan terlebih dahulu form untuk input data-data yang dibutuhkan dalam proses diagnosis itu sendiri. Dalam hal ini form yang penulis buat adalah form input penyakit, data pasein dan form hasil diagnosanya. Gambar 4.8 Form Input Penyakit Form input penyakit diperlukan untuk data-data penyakit yang nantinya berelasi dengan tabel hasil diagnosa. Selain form input penyakit terdapat pula form input pasien yakni digunakan untuk mendata data pasien.

Gambar 4.9 Form Input Pasien Dan yang paling dibutuhkan adalah form untuk pendataan hasil diagnosa itu sendiri. Gambar 4.10 Form Input Hasil Diagnosa Sedangkan dalam penggunaan HL7 terdapat standar penulisan kode agar nantinya isi fields dapat diintegrasikan oleh para pengembang. Dalam standar tersebut terdapat pula susunan struktur penulisan dan komposisi isian data. Ada pula istilah-istilah yang harusnya dipahami sebelum penyusunan HL7 message. ii. LIONC LIONC singkatan dari Logical Observation Identifier Names and Codes merupakan kumpulan elemen data yang telah mengandung isian nama dan kode-kode untuk identifikasi penyusunan HL7 message. Jadi dapat dikatakan bahwa LIONIC ini sendiri adalah acuan penerjemahan kode-kode yang dapat disusun menjadi HL7 message.

LIONC ini menyediakan set nama universal dan kode-kode id untuk mengidentifikasi hasil tes laboratorium, klinis dan unit lainnya serta informasi yang terkait dalam pembentukan HL7 message. Set kode yang terdapat dalam LIONC ini meliputi : a. Kode numerik yang mengidentifikasi pengamatan, komponenkomponen isian misalnya Kalium, Hepatitis C. b. Properti yang dapat diukur contohnya konsentrasi massa, panjang(jarak). c. Pengukuran sesaat, misalnya waktu, atau observasi yang telah dijalani dalam kurun waktu tertentu. d. Jenis sample atau sumber lain pengamatan, misalnya urin, darah, EMS transportasi. e. Jenis skala, misalnya pengukuran kuantitatif atau nominal. Contoh isian LIONC yang telah kita bahas pengertiannya di atas adalah sebagai berikut:

Example From LOINC Publication SEQ Element Name Required Value MSH-1 Field Separator (recommended) MSH-2 Encoding Characters ^~\& (recommended) MSH-7 Date/Time Of Message MSH-9 Message Type ORU^R01 MSH-10 Message Control ID An identifier that uniquely identifies this message. MSH-11 Processing ID P MSH-12 Version ID 2.3 MSH-15 Accept Acknowledgment Type NE MSH-16 Application Acknowledgment NE Type PID-3 Patient ID (Internal ID) Provider identification number for patient. PID-5 Patient Name last^first^mi^prefix^suffix^title OBR-4 Universal Service ID Code to identify attachment data element in value table, below OBX-2 Value Type Code to identify data type of OBX-5, see value table, in the section for a specific electronic attachment. OBX-3 Observation Identifier See value table, in the section for a specific electronic attachment. OBX-5 Observation Value See value table in the section for a specific electronic attachment. OBX-6 Units See value table in the section for a specific electronic attachment. OBX-11 Observ Result Status See HL7 table 0085. This application of HL7 does not include the protocol for amending results. Where the status of the source data is known it must be represented with one of these values: C - This report was received as a correction to a prior result; F - Final results; P - Preliminary results; S - Partial results; X - Results cannot be obtained for this observation. Where the source does not track revisions to its data, send F. Tabel 4.4 Contoh kode-kode LOINC iii. Data Type Dalam menyusun HL7 message terdapat aturan0aturan tipe data yang dapat dipakai, tipe data ini tidak jauh berbeda penggunaannya serperti dalam penyusunan program-program menggunakan bahasa pemrograman yang lain. Dalam HL7 message tipe data yang dapat dipakai adalah sebagai berikut:

Data Type Category/ Data type Data Type Name Comment Alphanumeric ST String TX Text data FT Formatted text Not used for Claims Attachments Numerical CQ Composite quantity with units Not used for Claims Attachments MO Money Not used for Claims Attachments NM Numeric SI Sequence ID SN Structured numeric Identifier ID Coded values for HL7 tables IS Coded value for userdefined tables HD Hierarchic designator EI Entity identifier RP Reference pointer PL Person location PT Processing type Date/Time DT Date TM Time TS Time stamp Code Values CE Coded element CF Coded element with formatted values CK Composite ID with check digit CN Composite ID number and name Not used for Claims Attachments CX Extended composite ID with check digit XCN Extended composite ID number and name Generic CM Composite Demographics AD Address Not used for Claims Attachments PN Person name Not used for Claims Attachments TN Telephone number XAD Extended address XPN Extended person name XON Extended composite Not used for Claims Attachments name and ID number for organizations XTN Extended Not used for Claims Attachments telecommunications number Specialty/Chapter Specific Waveform CD Channel definition Not used for Claims Attachments MA Multiplexed array Not used for Claims Attachments NA Numeric array Not used for Claims Attachments

Data Type Category/ Data type Data Type Name Comment ED Encapsulated data Price data CP Composite price Patient Administration/Financial Information FC Financial Class Not used for Claims Attachments Extended Queries QSC Query selection Not used for Claims Attachments criteria QIP RCD DLN JCC Query input Not used for Claims Attachments parameter list: Row column Not used for Claims Attachments definition: Master Files Driver s license number Job code/class VH Visiting hours Not used for Claims Attachments Medical Records/Information Management PPN Performing person time stamp Time Series DR Date/time range RI Repeat interval Not used for Claims Attachments SCV Scheduling class value pair Not used for Claims Attachments TQ Timing/quantity 4.5 Tabel tipe data iv. Karakter Khusus dalam HL7 message (Message Delimiters) Dalam menyusun kede-kode baik untuk program maupun pesan, tentunya terdapat karakter-karakter khusus yang tentu diperlukan untuk segmen terminator, pemisah kolom, pemisah komponen, pemisah subkomponen, pemisah pengulanagan. Dalam penyusunan HL7 message terdapat karakter-karakter khusu yang akan penulis jabarkan dalam tabel sebagai berikut :

Delimiter Segment Terminator Suggested Value <cr> hex 0D (this value required) Encoding Character Position Usage - Terminates a segment record. This value cannot be changed by implementors. Field Separator - Separates two adjacent data fields within a segment. It also separates the segment ID from the first data field in each segment. Component Separator Subcomponent Separator ^ 1 Separates adjacent components of data fields, where allowed. & 4 Separates adjacent subcomponents of data fields, where allowed. If there are no subcomponents, this character may be omitted. Repetition Separator ~ 2 Separates multiple occurrences of a field, where allowed. Escape Character \ 3 Escape character for use with any field represented by an ST, TX or FT data type, or for use with the data (fourth) component of the ED data type. If no escape characters are used in a message, this character may be omitted. However, it must be present if subcomponents are used in the message. v. HL7 Message Tabel 4.6 Karakter khusus dalam HL7 mesage Semua pesan yang akan dibuat menjadi kode-kode HL7 message ini berasal dari HL7 ORU terdiri dari MSH, PID,OBR dan OBX. Maka pada setiap pola kode HL7 message akan membentuk pola seperti berikut :

ORUObservational Results (Unsolicited) MSH Message Header PIDPatient Identification {OBRObservations Report ID {OBX}Observation/Result } Berikut kode-kode yang dapat dipakai sesuai dengan standar HL7 yang telah ada. Agar lebih lengkapnya penulis akan menjelaskan berikut contoh penulisan HL7 message yang dapat digunakan dalam urusan pelaporan data rumah sakit terutama yang berhubungan dengan pasien. Pesan HL7 adalah tentang Hay Jon pasien, yang tinggal di 124 N. Elm St, Elmo, Utah, 85.912. Sistem pengiriman mengidentifikasi pasien menggunakan nomor 184.569. Pernyataan bahwa adalah subjek dari 275 dikaitkan dengan X48507924 penagihan akun dalam sistem pengiriman. Dalam kunjungan sebelumnya pasien telah diidentifikasi sebagai JJ Hay dan John J. Hay. Penulisan HL7message: PID 184569 Hay^Jon^J Hay^JJ~Hay^John^J 124 Elm St^^Elmo^UT^85912 X48507924<cr> PID merupakan karakter yang menjelaskan mengenai identifikasi pasien, dalam HL7 PID merupakan singkatan dari patient identification dimana dalam penggunaan PID sendiri memilik struktur sebagai berikut : PID-3 Patient ID (Internal ID) Provider identification number for patient. PID-5 Patient Name (PN) PID-9 Patient Alias (XPN) PID-11 Patient Address PID-18 Patient Account Tabel 4.7 Tabel PID Untuk PID-9 yang merupakan penyebutan nama alis tidak wajib dicantumkan. Untuk penulisan dalam HL7 message yang

telah disebutkan di atas, pemisah antar struktur komponen PID adalah tanda sedangkan tanda ^ mengartikan sebagai spasi dalam HL7 message. Berikut ini penulis telah menggabungkan beberapa komponen yang ada berdasarkan peraturan pembuatan role untuk HL7 message guna menyusun kode-kode untuk hasil diagnosa pasien. MSH ^~\& 199808121425 ORU^R01 Regenstrief0128765419 P 2.3 NE NE <CR> PID 184569 Hay^Jon^J Hay^JJ~Hay^John^J 124 Elm St^^Elmo^UT^85912 X48507924<cr> OBR 00257 199808121425<cr> OBX CE 00571 ^CONGESTIVE HEART FAILURE F Penerjemahan setiap baris dari kode diagnosa dia atas adalah sebagai berikut : Pada baris pertama ini menerangkan mengenai message header yang telah dijelaskan di awal, yakni HL7 message yang telah dibuat dimasukkan dalam sistem 275 pada pukul 02.35 pada tanggal 12 Agustus 1998 dan pada sistem tersimpan nomer registrasi f0128765419. Penerjemahan tersebut berdasarkan pada aturan penulisan MSH sebagai berikut : ELEMENT NAME AND REQUIRED SEQ DATA TYPE VALUE MSH-1 Field Separator (ST) MSH-2 Encoding Characters (ST) ^~\& MSH-7 Date/Time Of Message (TS) MSH-9 Message Type ORU^R01 MSH-10 Message Control ID MSH-11 Processing ID P MSH-12 Version ID 2.3 MSH-15 Accept Acknowledgment Type NE MSH-16 Application Acknowledgment Type NE Tabel 4.8 Penulisan MSH Penerjamahan baris yang kedua adalah untuk patient identifier telah dijelaskan diatas sesuai dengan contoh yang talh penulis buat. Kemudian untuk baris ketiga mengenai observation request segment yang telah dijelaskan sedikit di LOINC, dapat dijelaskan bawah pasein yang sesuai dengan patient identifier di atas, mendapatkan segmen

observasi berkode 00257 yang berarti Diagnostic Serv Sect ID yang berarti mendapatkan segmen diagnosis berdasarkan id dari patient identifier pada pukul 02.35 pada tanggal 12 Agustus 1998. Penerjemahan tersebut berdasarkan aturan penulisan OBR sebagai berikut : SEQ OBR-4 OBR-7 ELEMENT NAME AND DATA TYPE Universal Service ID Observation date/time Tabel 4.9 Penulisan OBR SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 1 4 SI C 00237 Set ID - OBR 2 22 EI C 00216 Placer Order Number 3 22 EI C 00217 Filler Order Number + 4 200 CE R 00238 Universal Service ID 5 2 ID O 00239 Priority 6 26 TS O 00240 Requested Date/time 7 26 TS C 00241 Observation Date/Time # 8 26 TS O 00242 Observation End Date/Time # 9 20 CQ O 00243 Collection Volume * 10 60 XCN O Y 00244 Collector Identifier * 11 1 ID O 0065 00245 Specimen Action Code * 12 60 CE O 00246 Danger Code 13 300 ST O 00247 Relevant Clinical Info. 14 26 TS C 00248 Specimen Received Date/Time * 15 300 CM O 0070 00249 Specimen Source * 16 80 XCN O Y 00226 Ordering Provider 17 40 XTN O Y/2 00250 Order Callback Phone Number 18 60 ST O 00251 Placer field 1 19 60 ST O 00252 Placer field 2 20 60 ST O 00253 Filler Field 1 + 21 60 ST O 00254 Filler Field 2 + 22 26 TS C 00255 Results Rpt/Status Chng - Date/Time + 23 40 CM O 00256 Charge to Practice + 24 10 ID O 0074 00257 Diagnostic Serv Sect ID 25 1 ID C 0123 00258 Result Status + 26 400 CM O 00259 Parent Result + 27 200 TQ O Y 00221 Quantity/Timing 28 150 XCN O Y/5 00260 Result Copies To 29 150 CM O 00261 Parent * 30 20 ID O 0124 00262 Transportation Mode 31 300 CE O Y 00263 Reason for Study 32 200 CM O 00264 Principal Result Interpreter + 33 200 CM O Y 00265 Assistant Result Interpreter + 34 200 CM O Y 00266 Technician + 35 200 CM O Y 00267 Transcriptionist + 36 26 TS O 00268 Scheduled Date/Time +

SEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME 37 4 NM O 01028 Number of Sample Containers * 38 60 CE O Y 01029 Transport Logistics of Collected Sample * 39 200 CE O Y 01030 Collector's Comment * 40 60 CE O 01031 Transport Arrangement Responsibility 41 30 ID O 0224 01032 Transport Arranged 42 1 ID O 0225 01033 Escort Required 43 200 CE O Y 01034 Planned Patient Transport Comment Tabel 4.10 Segmen OBR Untuk baris terakhir adalah baris observation/result segment yang telah dijelaskan sedikit di LOINC, dapat dijelaskan bawah pasein yang sesuai dengan patient identifier di atas, mendapatkan segmen observasi berkode 00571 yang berarti observasion identifier yang berarti mendapatkan hasil diagnosis penyakit congestive heart failure. Penerjemahan tersebut berdasarkan aturan penulisan OBX sebagai berikut : SEQ OBX-3 OBX-5 OBX-6 OBX-11 ELEMENT NAME AND DATA TYPE Observation Identifier Observation Value and code source Units Observ result status (CE) Tabel 4.11 Penulisan OBX

SEQ LEN DT OPT RP/# TBL # ITEM # ELEMENT NAME 1 10 SI O 00569 Set ID - OBX 2 2 ID C 0125 00570 Value Type 3 590 CE R 00571 Observation Identifier 4 20 ST C 00572 Observation Sub-ID 5 65536 1 * C Y 2 00573 Observation Value 6 60 CE O 00574 Units 7 10 ST O 00575 References Range 8 5 ID O Y/5 0078 00576 Abnormal Flags 9 5 N M O 00577 Probability 10 2 ID O Y 0080 00578 Nature of Abnormal Test 11 1 ID R 0085 00579 Observ Result Status 12 26 TS O 00580 Date Last Obs Normal Values 13 20 ST O 00581 User Defined Access Checks 14 26 TS O 00582 Date/Time of the Observation 15 60 CE O 00583 Producer's ID 16 80 XC N O 00584 Responsible Observer 17 60 CE O Y 00936 Observation Method Tabel 4.12 Segmen OBX 4.4 Pengujian Pengujian terhadap pembuatan tabel menggunakan standar komunikasi HL7 message untuk hasil diagnosa ini dilakukan dengan menggunakan kuisioner. Kuesioner disebarkan menggunakan teknik sampling yaitu Simple Random Sampling yang disebarkan kepada 10 pengguna. Dari hasil kuesioner tersebut akan dilakukan perhitungan agar dapat diambil kesimpulan terhadap penilaian penerapan sistem yang baru. Kuesioner ini terdiri dari 7 pertanyaan (contoh kuesioner dapat diliihat pada lampiran) dengan menggunakan skala likert dengan skala 1 sampai 4. 1 The length of the observation value field is variable, depending upon value type. See OBX-2-value type. 2 May repeat for multipart, single answer results with appropriate data types, e.g., CE, TX, and FT data types.

No Keterangan 1 Sangat Setuju 2 Cukup Setuju 3 Kurang Setuju 4 Tidak Setuju Tabel 4.13 Tabel Skala Likert Berdasarkan data hasil kusioner tersebut, dapat dicari prosentase masingmasing jawaban dengan menggunakan rumus : Y = P/Q * 100% Keterangan : P = Banyaknya jawaban responden tiap soal. Q = Jumlah responden Y = Nilai persentase Berikut ini adalah hasil prosentase masing-masing jawaban yang sudah dihitung nilainya dengan menggunakan rumus diatas. Kuisioner ini diujikan kepada 10 orang. 1. Apakah pembuatan database telah cocok untuk proses diagnosa pasien? No Keterangan Responden Prosentase 1 Sangat Setuju 6 60% 2 Cukup Setuju 3 30% 3 Kurang Setuju 0 0% 4 Tidak Setuju 1 10% Tabel 4.14 Hasil pengujian kuisioner soal nomor 1 Berdasarkan hasil prosentase diatas maka dapat disimpulkan sebanyak 6 orang atau 60% menyatakan sangat setuju, 3 orang atau 30% menyatakan

cukup setuju dan, 1 orang atau 10% menyatakan tidak setuju bahwa database cocok untuk proses diagnosa pasien. 2. Apakah pembuatan tabel telah cocok untuk proses diagnosa pasien? No Keterangan Responden Prosentase 1 Sangat Setuju 5 50% 2 Cukup Setuju 4 40% 3 Kurang Setuju 1 10% 4 Tidak Setuju 0 0% Tabel 4.15 Hasil pengujian kuisioner soal nomor 2 Berdasarkan hasil prosentase diatas maka dapat disimpulkan sebanyak 5 orang atau 50 % menyatakan sangat setuju, 4 orang atau 40% menyatakan cukup setuju dan, 1 orang atau 10% menyatakan kurang setuju bahwa pembuatan tabel cocok untuk proses diagnosa pasien. 3. Apakah isi field tabel telah cocok dengan aturan HL7 message? No Keterangan Responden Prosentase 1 Sangat Setuju 4 40% 2 Cukup Setuju 6 60% 3 Kurang Setuju 0 0% 4 Tidak Setuju 0 0% Tabel 4.16 Hasil pengujian kuisioner soal nomor 3 Berdasarkan hasil prosentase diatas maka dapat disimpulkan sebanyak 4 orang atau 40% menyatakan sangat setuju, 6 orang atau 60% menyatakan cukup setuju bahwa isi field tabel telah cocok dengan aturan HL7 message.

4. Apakah standar HL7 message yang digunakan cocok untuk komunikasi data diagnosa pasien? No Keterangan Responden Prosentase 1 Sangat Setuju 5 50% 2 Cukup Setuju 5 50% 3 Kurang Setuju 0 0% 4 Tidak Setuju 0 0% Tabel 4.17 Hasil pengujian kuisioner soal nomor 4 Berdasarkan hasil prosentase diatas maka dapat disimpulkan sebanyak 5 orang atau 50% menyatakan sangat setuju dan, 5 atau 50% menyatakan cukup setuju bahwa standar HL7 message yang digunakan cocok untuk komunikasi data diagnosa pasien. 5. Apakah untuk pengembang yang berbeda namun menggunakan versi HL7 yang sama yakni V.2.4 akan dapat mendapatkan isian fileds yang sama? No Keterangan Responden Prosentase 1 Sangat Setuju 4 40% 2 Cukup Setuju 6 60% 3 Kurang Setuju 0 0% 4 Tidak Setuju 0 0% Tabel 4.18 Hasil pengujian kuisioner soal nomor 5 Berdasarkan hasil prosentase diatas maka dapat disimpulkan sebanyak 4 orang atau 40 % menyatakan sangat setuju dan, 6 orang atau 60% menyatakan cukup setuju bahwa untuk pengembang yang berbeda namun menggunakan versi HL7 yang sama yakni V.2.4 akan dapat mendapatkan isian fileds yang sama.

Berdasarkan hasil prosentase yang didapatkan dari pengujian User Acceptence Test menggunakan kuisioner untuk pengguna yaitu para admin di Rumah sakit Telogorejo, maka dapat ditarik kesimpulan bahwa pembuatan sekaligus pengisian fields pada tabel dan database yang telah penulis buat ini telah dapat menerapkan standar komunikasi data menggunakan HL7 message untuk proses diagnosa pasien.

BAB V KESIMPULAN DAN SARAN 5.1 Kesimpulan Berdasarkan penelitian yang telah dilakukan oleh peneliti, maka dapat disimpulkan bahwa dengan pembuatan database dan pengisian fields pada tabel yang sesuai dengan standar HL7 message versi 2.4, dapat dilakukan komunikasi data untuk data diagnosa pasien. Database dan tabel yang telah penulis buat pun dengan menggunkan standar komunikasi database HL7 message dapat menunjukan pembuktian keefektifan penggunaan HL7 message untuk database rumah sakit. 5.2 Saran Dalam pembuatan database dan tabel ini masih terbatas hanya menggunakan tiga tabel dan satu field utnuk transaksi data, disarankan agar pembuatan database ini diperlengkap dan dikembangkan sampai dengan pengujian pada tahap user yang sesungguhnya. Sehingga nantinya semakin banyak komunikasi data yang dilakukan dengan menggunakan standar komunikasi HL7 message.

DAFTAR PUSTAKA [1] Anthony, Robert N.(2009). MANAGEMENT CONTROL SYSTEM.Jakarta: Salemba Empat. [2] Gibney, Michel J.(2005).Gisi Kesehatan Masyarakat. Terjemahan: dr.andry Hartono.(2009).Jakarta:Buku Kedokteran EGC. [3] Cermin Dunia Kedokteran No. 152(2006). [4] Mohd, H, and Syed Mohamed, Sh.M. (2006).Acceptance Model of Medical Record. Journal of Advancing Information Management System (JAIMS),;2(1),pp.75-92 [5] The Fifth Annual HealthGrades Patient Safety in American Hospitals Study(2008), HealthGrades. [6] Gemala Hatta.,(2003). The pitfall and benefits of electronic medical record ( Enhancing your practice). Patient Care, March 2003. [7] Burtis CA, Ashwood ER. Tietz Textbook of Clinical Chemistry, 2nd ed. (1994).Philadelphia: W.B. Saunders. [8] Chin,H.,L., (2004).The Reality of EMR Implementation Lesson from the Field.The Permanent Journal, fall 2004, Vol. 8, No. 4..pp.43-48. [9] Zuriah. (2003).Macam-macam Penelitian. Yogyakarta: Andi. LAMPIRAN Hasil wawancara dengan Kepala Bagian IT Rumah Sakit Telogorejo Semarang

No Pertanyaan Jawaban 1. Penggunaan HL7 message pada sistem di Rumah Sakit Telogorejo? HL7 message digunakan untuk proses radiologi, pada data-data hasil dari radiologi. 2. Manfaat dari penggunaan HL7 message? Karena HL7 message digunakan untuk proses radiologi, terutama data-data hasil dari radiologi. Maka bisa melakukan transaksi data-data yang berhubungan dengan hasil radiologi dengan pihak lain. 3. Kesulitan dalam penggunaan HL7 message? Mulai dari penyusunan kode HL7 message sampai dengan penyusunan interface user pihak telogorejo membeli program dari India, sehingga sebenarnya tidak begitu memahami betul HL7 messagenya 4. Peluang pengembangan HL7 message? Sebenarnya memang HL7 message lebih bermanfaat dari pihak pengembang dalam hal ini adalah programmer. Karena dengan mengetahui versi HL7 nya saja, pengembang sangatlah mudah mendapatnya data-data pada isi tabel, itulah manfaatnya menggunakan HL7 message. Jadi para pengembang tersebut tidak perlu repot mencari data-data yang dibutuhkan.

KUISIONER Kuisioner ini merupakan kuisioner untuk pengujian HL7 message yang telah peneliti buat. Dimana peneliti telah membuat HL7 message untuk hasil diagnosa pasien. Untuk pengisian kuisioner ini cukup menjawab 5 pertanyaan dengan mencentang salah satu pilihan yakni Sangat Setuju, Cukup Setuju, Kurang Setuju dan Tidak Setuju.Sebelum menjawab pertanyaan diharapkan mengisi identitas yang telah penulis cantumkan. Nama : Bagian : Spesifikasi Kemampuan : Pertanyaan: 1. Apakah pembuatan database telah cocok untuk proses diagnosa pasien? Sangat Setuju Cukup Setuju Kurang Setuju Tidak Setuju 2. Apakah pembuatan tabel telah cocok untuk proses diagnosa pasien? Sangat Setuju Cukup Setuju Kurang Setuju Tidak Setuju 3. Apakah isi field tabel telah cocok dengan aturan HL7 message? Sangat Setuju Cukup Setuju Kurang Setuju Tidak Setuju 4. Apakah standar HL7 message yang digunakan cocok untuk komunikasi data diagnosa pasien? Sangat Setuju Cukup Setuju Kurang Setuju Tidak Setuju 5. Apakah untuk pengembang yang berbeda namun menggunakan versi HL7 yang sama yakni V.2.4 akan dapat mendapatkan isian fileds yang sama? Sangat Setuju Cukup Setuju Kurang Setuju Tidak Setuju