TA : Rancang Bangun Aplikasi Administrasi Rawat Jalan Pada Klinik Geo Medika.

JALAN PADA KLINIK GEO MEDIKA

TUGAS AKHIR Program Studi S1 Sistem Informasi

Oleh:

Ongky Anjar Yamanta 08.41010.0303

FAKULTAS TEKNOLOGI DAN INFORMATIKA

INSTITUT BISNIS DAN INFORMATIKA STIKOM SURABAYA

2016

x

Halaman

ABSTRAK ... vii

KATA PENGANTAR ... viii

DAFTAR ISI ... x

DAFTAR TABEL ... xiiii

DAFTAR GAMBAR ... xv

DAFTAR LAMPIRAN ... xviii

BAB I PENDAHULUAN ... 1

1.1 Latar Belakang Masalah ... 1

1.2 Perumusan Masalah ... 3

1.3 Batasan Masalah ... 3

1.4 Tujuan ... 3

1.5 Manfaat...4

1.6 Sistematika Penulisan ... ...5

BAB II LANDASAN TEORI ... .6

2.1 Rancang Bangun ... ..6

2.2 Aplikasi ... ..7

2.3 Rawat Jalan ... .8

2.4 Administrasi ... .9

2.5 Administrative Workflow System ... 10

2.6 Klinik ... 12

2.7 Rekam Medik ... 14

xi

2.11 Business Process Model Notation ... 21

2.12 Prototying ... 21

BAB III Analisis dan Desain... 22

3.1 Identifikasi Kebutuhan User ... 22

3.1.1 Menentukan User Utama ... 26

3.1.2 Mengumpulkan Data Mentah ... 26

3.1.3 Studi Literatur ... 33

3.2 Analisis Sistem... 37

3.3 Perancangan Sistem ...39

3.3.1 Diagram Arsitektur ... 42

3.3.2 Business Process Modelling Notation ... 49

3.3.3 Mengembangkan Prototipe...52

3.3.4 Prototipe Satu ...53

3.3.5 Evaluasi Prototipe Satu ...59

3.3.6 Prototipe Dua ...60

3.3.7 Evaluasi Prototipe Dua ...61

3.3.2 Memprogram sistem baru ... 62

3.3.2 Diagram Konteks ... 63

3.3.2 diagram jenjang ... 64

3.3.2 Business Process Modelling Notation ... 65

3.3.2 DFD level 0 ... 64

xii

3.3.2 DFD level 1 ... 72

BAB IV UJI COBA DAN EVALUASI ... 91

4.1 Evaluasi Sistem ... 91

4.1.1 Evaluasi Hasil Uji Coba Sistem ... 91

4.1.2 Analisis Hasil Uji Coba Sistem ... 113

BAB V PENUTUP ... 114

5.1 Kesimpulan ... 114

5.2 Saran ... 114

xiii

Halaman

Tabel 3.1 Informasi Rumah Sakit ... 41

Tabel 3.2 Pekerjaan ... 41

Tabel 3.3 Pasien ... 42

Tabel 3.4 Registrasi ... 42

Tabel 3.5 Pembayaran ... 43

Tabel 3.6 Instalasi ... 44

Tabel 3.7 Tindakan... 44

Tabel 3.8 Dokter... 44

Tabel 3.9 Transaksi Klinik ... 45

Tabel 3.10 Barang ... 45

Tabel 3.11 Satuan ... 46

Tabel 3.12 Bank ... 46

Tabel 3.13 Debitur ... 47

Tabel 3.14 Jenis ... 47

Tabel 3.15 Status ... 48

Tabel 3.16 Dokumen Rekam Medis... 48

Tabel 3.17 Pemeriksaan Klinis ... 48

Tabel 3.18 Tabel ICD ... 49

Tabel 3.19 Dokter Instalasi ... 49

Tabel 4.1 Tabel Uji Coba Form Login... 80

Tabel 4.2 Tabel Uji Coba Form Pendaftaran ... 81

xiv

Tabel 4.5 Tabel Uji Coba Form Farmasi ... 89 Tabel 4.6 Tabel Uji Coba Laporan ... 94

xv

Halaman

Lampiran 1 Kartu Berobat ... 91 Lampiran 2 Kartu Rekam Medik Pasien ... 92 Lampiran 3 Kartu Resep ... 92

1

1.1 Latar Belakang Masalah

Klinik Geo Medika merupakan klinik milik swasta dengan nomor izin 551.41/042/KLIN/404.3.2/2014 berdiri pada awal tahun 2010 dan beralamat di Jln. Brigjend Katamso Blok P.VII No.03, Rewwin-Waru, Sidoarjo. Pelayanan kesehatan utama yang disediakan oleh Klinik Geo Medika adalah praktik rawat jalan Dokter Umum dan Dokter Spesialis, dimana dokter spesialis yang tersedia diantaranya Dokter Anak, Dokter Gigi, Dokter Kulit dan Kelamin dan Dokter Penyakit Dalam. Klinik Geo Medika juga didukung fasilitas penunjang seperti Unit Gawat Darurat, Apotek, dan Laboratorium. Dengan praktik rawat jalan sebagai pelayanan kesehatan utama, maka administrasi rawat jalan menjadi fungsi penting didalam prosesnya.

Administrasi adalah pekerjaan tulis menulis atau ketatausahaan atau kesekretarisan, meliputi kegiatan: menerima, mencatat, menghimpun, mengolah, mengadakan, mengirim, meyimpan, menghitung (Irra Christiyani, 2011). Administrasi rawat jalan yang ada saat ini memiliki beberapa proses bisnis yaitu: pendaftaran, pemeriksaan, dan pembayaran. Proses pendaftaran diawali dengan perawat mencatat data identitas pasien baru pada kartu rekam medik atau mencari kartu rekam medik pasien jika dia pernah berobat sebelumnya, kemudian pasien menunggu panggilan masuk. Proses pemeriksaan dimulai setelah pasien mendapat panggilan masuk dan perawat menyerahkan kartu rekam medik pasien pada dokter, kemudian dilakukan tindakan medik pada pasien dan pengisian kartu rekam medik

serta resep bila ada. Setelah itu dokter/perawat menyerahkan data rekam medik dan resep pada kasir dan pasien melakukan pembayaran pada kasir untuk mendapatkan resep dan juga nota pembayaran.

Masalah yang ada pada sistem administrasi rawat jalan saat ini adalah pada proses pendaftaran masih ditemukan terjadinya kesulitan pencarian hingga kehilangan data rekam medik pasien yang berdampak pada terhambatnya proses pendaftaran, terjadinya redudansi data, dan kesalahan diagnosa dokter. Pada awal proses pembayaran, kegiatan dokter yang membawa rekam medik pasien ke kasir membuat proses pemeriksaan pasien selanjutnya tidak dapat langsung dilakukan. Ini berdampak pada bertambahnya waktu tunggu pasien. Bahkan pada beberapa kasus sering ditemukan pasien diminta membawa sendiri rekam medis dan resep ke kasir. Ini tentunya bisa berdampak pada hilangnya kartu rekam medik dan pasien tidak melakukan proses pembayaran.

Dari analisa permasalahan di temukan bahwa penggunaan kartu dalam pembuatan data pasien dan rekam medik, serta tidak terintegrasinya sistem administrasi yang ada merupakan masalah utama yang ada di pelayanan praktek rawat jalan Klinik Geo Medika. Permasalahan tersebut dapat diatasi dengan adanya aplikasi yang terintegrasi mulai dari pendaftaran sampai pada pembayaran. Aplikasi ini dapat membantu dalam proses pendaftaran sampai proses pembayaran, karena dapat membantu dalam pencatatan data pasien dan rekam medik serta dapat mengurangi antrian pendaftaran dan membantu dokter untuk mempertimbangkan rekam jejak pasien pada rawat jalan sehingga menghasilkan rekam medis yang akurat dan mudah dicari. Untuk proses pembayaran menjadi terkomputerisasi dan

terintegrasi demi mencegah terjadinya kehilangan data dan rekam medis pasien dan membantu dalam pembuatan laporan klinik.

1.2 Perumusan Masalah

Berdasarkan Bagaimana merancang dan membangun aplikasi administrasi rawat jalan pada Klinik Geo Medika yang dapat:

1. Menggantikan peran kartu dalam penulisan data rekam medik pasien. 2. Mempercepat pencarian data rekam medik pasien.

3. Mengintegrasikan proses administrasi rawat jalan secara real time

1.3 Batasan Masalah

Batasan-batasan masalah yang digunakan di dalam Tugas Akhir ini yaitu: 1. Hanya membahas administrasi rawat jalan yang terdiri dari proses pendaftaran,

pemeriksaan dan pembayaran.

2. Administrasi rawat jalan yang dibahas mencakup praktek dokter umum dan juga dokter spesialis.

3. Tidak mencakup implementasi sistem.

4. Rekam medik dapat diakses oleh beberapa dokter yang berbeda dalam klinik Geo Medika untuk kepentingan diagnosa penyakit pasien.

1.4 Tujuan

Menghasilkan Rancang Bangun Aplikasi Administrasi Rawat Jalan Pada Klinik Geo Medika.

1.5 Sistematika Penulisan

Secara garis besar sistematika penulisan pada laporan ini adalah sebagai berikut:

Bab I : Pendahuluan

Pada bab ini akan dijelaskan mengenai latar belakang permasalahan yang terjadi, perumusan permasalahan yang didapat dari latar belakang, pembatasan permasalahan, tujuan dilakukannya penelitian, manfaat yang akan diberikan kepada stakeholder, serta penjelasan mengenai sistematika penulisan pada penelitian ini.

Bab II : Landasan Teori

Pada bab ini akan dijelaskan mengenai teori-teori yang mendukung atau digunakan sebagai acuan pada saat atau sebelum melakukan penelitian.

Bab III : Analisis dan Desain

Pada bab ini akan dijelaskan bagaimana awal proses penelitian ini dilakukan hingga menghasilkan sebuah perancangan yang diperoleh melalui beberapa tahapan seperti, identifikasi kebutuhan user,

mengembangkan dan evaluasi prototipe, diakhiri dengan memprogram sistem baru .

Bab IV : Uji Coba dan Evaluasi

Pada bab ini akan membahas tahap terakhir dari metodologi prototipe yaitu pengujian sistem baru. Dijelaskan mengenai uji coba prototipe yang telah dibentuk apakah apakah telah memenuhi target-target yang ingin dicapai.

Bab V : Penutup

Pada bab ini akan dijelaskan mengenai kesimpulan yang diperoleh dari penelitian ini, yaitu hasil dari evaluasi, serta saran terkait dengan sistem yang dikembangkan.

6

2.1 Rancang Bangun

Menurut Jogiyanto (2005:197), Rancang Bangun (desain) adalah tahap dari setelah analisis dari siklus pengembangan sistem yang merupakan pendefinisian dari kebutuhan-kebutuhan fungsional, serta menggambarkan bagaimana suatu sistem dibentuk yang dapat berupa penggambaran, perencanaan dan pembuatan sketsa atau pengaturan dari beberapa elemen yang terpisah ke dalam satu kesatuan yang utuh dan berfungsi, termasuk menyangkut mengkonfirmasi dari komponen-komponen perangkat keras dan perangkat lunak dari semua sistem.

2.2 Aplikasi

Aplikasi adalah perangkat lunak yang ada pada komputer digunakan untuk melayani berbagai macam kebutuhan. Teknologi yang canggih dari perangkat keras akan berfungsi bila instruksi-instruksi tertentu telah diberikan kepadanya. Instruksi-instruksi tersebut disebut dengan perangkat lunak (Jogiyanto, 2003).

2.3 Rawat Jalan

Menurut Marsuli (2005) pelayanan rawat jalan adalah salah satu bentuk pelayanan kedokteran yang disediakan untuk pasien tidak dalam bentuk rawat inap yang tidak hanya diselenggarakan oleh sarana pelayanan kesehatan yang lazim dikenal sepeti rumah sakit/klinik, tetapi juga yang diselenggarakan di rumah pasien serta di rumah perawatan. Tujuan pelayanan rawat jalan diantaranya adalah untuk

memberikan konsultasi kepada pasien yang memerlukan pendapat dari seorang dokter spesialis dengan tindakan pengobatan atau tidak. Selain itu juga melaksanakan pelayanan tindak lanjut bagi pasien rawat inap yang sudah diizinkan pulang tetapi masih harus dikontrol kondisi kesehatannya.

2.4 Administrasi

Secara luas, administrasi merupakan proses kerjasama beberapa individu dengan cara yang efisien dalam mencapai tujuan sebelumnya. Berdasarkan hal tersebut, administrasi dipandang dari 3 sudut pengertian ( Ira Chrisyanti Dewi, 2011) yakni:

1. Sudut proses

Administrasi merupakan proses kegiatan pemikiran, penentuan tujuan, sampai pelaksanaan kerja hingga akhirnya tujuan yang telah ditentukan dapat tercapai.

2. Sudut fungsi

Administrasi merupakan kegiatan yang dilakukan sekelompok individu maupun individu itu sendiri sesuai dengan fungsi yang telah dilimpahkanuntuk mencapai tujuan yang ditentukan sebelumnya misalnya: kegiatan perencanaan, pengorganisasian, penggerakan, pengawasan, dan sebagainya.

3. Sudut

institusional

Administrasi merupakan personil-personil baik individu maupun sekelompok individu yang menjalankan kegiatan untuk mencapai tujuan yang ditentukan sebelumnya. Personil-personil yang ada pada institusional, antara lain :

 Administrat or

 Manajer

 Staff/Asiste

n

 Worker

Secara sempit, administrasi berasal dari kata administratie (bahasa belanda) yang artinya sebagai pekerjaan tulis menulis atau ketatausahaan / kesekretarisan. Pekerjaan ini berkaitan dengan kegiatan menerima, mencatat, menghimpun, mengolah, menggandakan, mengirim, menyimpan, dan sebagainya (Irra Chrisyanti Dewi, 2011).

2.5 Administrative Workflow System

Administrativeworkflowsystem adalah sebuah sistem workflow umum, yang memanfaatkan penggunaan formulir elektronik yang terhubung dengan email. Sistem ini biasa diaplikasikan ke dalam tugas-tugas administrasi rutin seperti persetujuan pengajuan cuti, pemrosesan pemesanan pembelian, dll. The Gartner Group memperkirakan bahwa 83% dari semua dokumen bisnis di Amerika Serikat adalah dokumen formulir dengan biaya pembelian tahunan sebesar 6-8 milyar dolar Amerika dan biaya pemroresan mencapai 360 milyar dolar Amerika. Formulir-formulir kertas ini menjadi target dari 1995 Paper Reduction Act (Chaffey, 1963).

Manfaat yang besar dapat terjadi melalui mengotomatisasikan proses berbasis formulir. Proses dapat berbalik lebih cepat menggunakan formulir elektronik dan mengurangi biaya melalui pengurangan biaya pembelian formulir dan waktu siklus yang lebih pendek. Salah satu penghematan biaya terbesar adalah koordinasi pengolahan formulir yang sekarang ditangani oleh logika bisnis yang dibangun ke dalam aplikasi (Chaffey, 1963).

2.6 Klinik

Menurut PERMENKES RI NO.028/MENKES/PER/I/2011 klinik adalah fasilitas pelayanan kesehatan yang menyelenggarakan pelayanan kesehatan perorangan ynag menyediakan pelayanan medis dasar dan/atau spesialistik, diselenggarakan oleh lebih dari satu jenis tenaga kesehatan dan dipimpin oleh seorang tenaga medis. Tenaga medis adalah seorang dokter, dokter spesialis, dokter gigi atau dokter gigi spesialis.

Berdasarkan jenis pelayanannya, klinik dibagi menjadi Klinik Pratama dan klinik Utama. Klinik Pratama merupakaan klinik yang menyelenggarakan pelayanan medik dasar. Klinik Utama merupakan klinik yang menyelenggarakan pelayanan medik spesialistik atau pelayanan medik dasar dan spesialistik. Klinik Pratama atau klinik Utama dapat mengkhususkan pelayanan pada satu bidang tertentu berdasarkan disiplin ilmu, golongan umur, organ, atau jenis penyakit tertentu.

Jenis Klinik Pratama atau Klinik Utama dapat diselenggarakan oleh pemerintah, pemerintah daerah atau masyarakat atau swasta. Klinik menyelenggarakan pelayanan kesehatan yang bersifat promotif, preventif, kuratif dan

rehabilitatif. Pelayanan kesehatan yang dilaksanakan dalam bentuk rawat jalan, one day care, rawat inap dan/atau home care. Kepemilikan Klinik Pratama yang menyelenggarkan rawat jalan dapat secara perorangan atau berbentuk badan usaha.

2.7 Rekam medik

Menurut Permenkes No. 269 Tahun 2008, rekam medik adalah berkas yang berisikan catatan dan dokumen tentang identitas pasien, pemeriksaan, pengobatan, tindakan, dan pelayanan yang telah diberikan kepada pasien.

Rekam medik adalah keterangan baik yang tertulis maupun yang terekam tentang identitas, anamnesis penentuan fisik laboratorium, diagnosis segala pelayanan dan tindakan medik yang diberikan kepada pasien dan pengobatan fisik yang dirawat inap, rawat jalan, maupun yang mendapatkan pelayanan gawat darurat. Selain itu, rekam medik juga berisikan berkas yang berisi catatan dan dokumen tentang identitas pasien, pemeriksaan, pengobatan, tidakan, dan pelayanan lain kepada pasien di sarana pelayanan kesehatan. Rekam medik merupakan dokumen fakta yang berkaitan dengan keadaan pasien, riwayat penyakit dan pengobatan masa lalu, serta saat ini yang tertulis oleh profesi kesehatan yang memberikan pelayanan kepada pasien tersebut (Huffman, 1999: 10).

Dalam Permenkes No 749 Tahun 1989 tentang Rekam medik disebutkan bahwa rekam medik adalah berkas yang berisikan catatan dan dokumen tentang identitas pasien, pemeriksaan, pengobatan, tidakan dan pelayanan lain kepada pasien pada sarana pelayanan kesehatan. Dijelaskan lebih lanjut dalam Surat Keputusan Direktorat Jenderal Pelayanan Medik No 78 Tahun 1991 tentang Penyelenggaraan

Rekam medik di Rumah Sakit, bahwa rekam medik adalah berkas yang berisikan catatan dan dokumen tentang identitas, anamnesis, pemeriksaan, diagnosis, pengobatan, tindakan dan pelayanan lain yang diberikan kepada seorang pasien selama dirawat di rumah sakit yang dilakukan di unit-unit rawat jalan termasuk unit gawat darurat dan rawat inap.

Tujuan rekam medik adalah menunjang tercapainya tertib administrasi dalam rangka upaya peningkatan pelayanan kesehatan. Tanpa didukung suatu sistem pengelolaan rekam medik yang baik dan benar, tidak mungkin tertib administrasi di tempat pelayanan kesehatan akan berhasil sebagaimana yang diharapkan. Sedangkan tertib administrasi merupakan salah satu faktor yang menentukan di dalam upaya pelayanan kesehatan.

Rekam medik mempunyai dua bagian yaitu bagian pertama adalah tentang individu suatu informasi tentang kondisi kesehatan dan penyakit pasien yang bersangkutan dan sering disebut patent record, bagian kedua adalah tentang manajemen suatu informasi tentang pertanggungjawaban apakah dari segi manajemen maupun keuangan dari kondisi kesehatan dan penyakit pasien yang bersangkutan. Secara umum, informasi yang tercantum dalam rekam medik seorang pasien adalah sebagai berikut

1. Siapa (who) pasien tersebut dan siapa (who) yang memberikan pelayanan kesehatan/medik.

2. Apa (what), Kapan (when), Kenapa (Why) dan Bagaimana (How) pelayanan kesehatan/medik diberikan.

Rekam medik merupakan salah satu sumber data penting yang nantinya akan diolah menjadi informasi. Berdasarkan proses pelayanan rekam medik yang ada pada rumah sakit, dapat terlihat bahwa pasien yang datang ke rumah sakit dapat datang sendiri atau membawa surat rujukan. Di unit pendaftaran, identitas pasien dicatat di kartu atau status rekam medik dan selanjutnya pasien beserta kartu atau status rekam mediknya dibawa ke ruang pemeriksaan. Oleh tenaga kesehatan, pasien akan dianamnesis dan diperiksa serta membutuhkan pemeriksaan penunjang. Akhirnya dilakukan penegakkan diagnosis sesuai dengan kebutuhan, pasien tersebut diberi obat atau tindakan medik lainnya. Semua pelayanan kesehatan ini dicatat dalam status rekam medik. Setiap tenaga kesehatan yang melakukan pelayanan kesehatan dan atau tindakan medik harus menuliskan nama dan memubuhi tandatangannya di status rekam medik tersebut. Semua kegiatan ini merupakan kegiatan bagian pertama rekam medik (pattent record).

Setelah melalui ini semua, pasien dapat pulang atau dirujuk. Kegiatan pengelolaan rekam medik tidak berhenti. Status rekam medik dikumpulkan biasanya kembali ke ruang rekam medik untuk dilakukan ICD-10 penyakit dan dilakukan pendataan di buku-buku registrasi harian yang telah disediakan. Setelah diolah, status rekam medik disimpan pada tempatnya di ruang arsip agar lain kali pasien yang sama datang, maka status rekam mediknya dapat dipergunakan kembali.

2.8 Data Flow Diagram

Menurut Kristanto (2004), Data Flow Diagram (DFD) adalah suatu model logika data atau proses yang dibuat untuk menggambarkan darimana asal data dan

kemana tujuan data yang keluar dari sisem, di mana data tersebut disimpan, proses apa yang menghasilkan data tersebut dan interaksi antara data yang tersimpan, dan proses yang dikenakan pada data tersebut.

Data Flow Diagram merupakan suatu metode pengembangan sistem yang terstruktur (structure analysis and design). Penggunaan notasi dalam data flow diagram sangat membantu untuk memahami suatu sistem pada semua tingkat kompleksitas. Pada tahap analisis, penggunaan notasi ini dapat membantu dalam berkimunikasi dengan pemakai sistem untuk memahami sistem secara logika.

Di dalam data flow diagram, terdapat empat simbol yang digunakan yaitu

process, external entity, data store, dan data flow. Simbol process digunakan untuk melakukan suatu perubahan berdasarkan data yang dimasukkan dan menghasilkan data dari perubahan tersebut.

2.9 System Development Life Cycle (SDLC)

Menurut McLeod (2007) Pendekatan sistem merupakan suatu metodologi. Metodologi aalah suatu jalan atau cara yang direkomendasikan dalam melakukan sesuatu. Pendekatan sistem adalah metodologi dasar untuk pemecahan berbagai macam permasalahan. Siklus hidup pengembangan sistem (system development life cycle-SDLC) adalah suatu aplikasi dari pendekatan sistem untuk pengembangan suatu sistem informasi. Contoh dari SDLC diantaranya adalah SDLC tradisional,

prototyping, rapid application development (RAD), phased development dan lain-lain.

2.10 Blackbox Testing

Menurut Romeo (2003), Blackbox Testing merupakan pendekatan komplementer dari teknik whitebox, karena pengujian blackbox diharapkan mampu mengungkapkan kelas kesalahan yang lebih luas dibandingkan teknik whitebox. Pengujian blackbox berfokus pada pengujian persyaratan fungsional perangkat lunak, untuk mendapatkan serangkaian kondisi input yang sesuai dengan persyaratan fungsional suatu program. Pengujian blackbox adalah pengujian aspek fundamental sistem tanpa memperhatikan struktur logika internal perangkat lunak.

Metode ini digunakan untuk mengetahui apakah perangkat lunak berfungsi dengan benar. Pengujian blackbox merupakan metode perancangan data uji yang didasarkan pada spesifikasi perangkat lunak. Data uji dibangkitkan, dieksekusi pada perangkat lunak dan kemudian keluaran dari perangkat lunak dicek apakah telah sesuai dengan yang diharapkan.

Pengujian blackbox berusaha menemukan kesalahan dalam kategori : a) Fungsi – fungsi yang tidak benar atau hilang.

b) Kesalahan interface.

c) Kesalahan dalam struktur data atau akses database eksternal. d) Kesalahan kinerja.

e) Inisialisasi dan kesalahan terminasi.

Berbeda dengan pengujian whitebox, pengujian blackbox cenderung diaplikasikan selama tahap akhir pengujian. Pengujian blackbox harus dapat menjawab pertanyaan sebagai berikut :

b) Kelas input apa yang akan membuat kasus pengujian menjadi lebih baik. c) Apakah sistem akan sangat sensitive terhadap input harga tertentu. d) Bagaimana batasan dari suatu data diisolasi.

e) Kecepatan data apa dan volume data apa yang akan ditoleransi oleh sistem. f) Apa pengaruh kombinasi tertentu dari data terhadap sistem operasi.

2.11 Business Process Model Notation

Menurut Rosmala dan Falahah (2007), BPMN adalah singkatan dari

Business Process Management Notation, yaitu suatu metodologi baru yang dikembangkan oleh Business Process Modeling Initiative sebagai suatu standard baru pada pemodelan proses bisnis, dan juga sebagai alat desain pada sistem yang kompleks seperti sistem e-Business yang berbasis pesan (message-based).

Tujuan utama dari BPMN adalah menyediakan notasi yang mudah digunakan dan bisa dimengerti oleh semua orang yang terlibat dalam bisnis, yang meliputi bisnis analis yang memodelkan proses bisnis, pengembang teknik yang membangun sistem yang melaksanakan bisnis, dan berbagai tingkatan manajemen yang harus dapat membaca dan memahami proses diagram dengan cepat sehingga dapat membantu dalam pengambilan keputusan.

Notasi BPMN yang baru juga dirancang untuk sifat sistem berbasis layanan web. BPMN dapat memodelkan pesan kompleks yang dilewatkan diantara pelaku bisnis atau bagian dari pelaku bisnis, kejadian yang menyebabkan pesan dilewatkan, dan aturan bisnis yang membatasi kejadian tersebut. BPMN memugkinkan proses bisnis dipetakan ke bahasa eksekusi bisnis berbasis XML seperti BPEL4WS

(Business Process Execution Language for Web Service) dan BPML (Business Process Modeling Language).

Terdapat 4 kategori dari elemen-elemen dalam BPMN, yaitu: 1. Flow Objects

 Events, sebuah event direpresentasikan dengan lingkaran. Events dapat berupa Start, Intermediate, atau End.

Gambar 1 Simbol Events

 Activities, sebuah aktivitas direpresentasikan dengan persegi dengan sudut melingkar dan memperlihatkan pekerjaan yang harus dilakukan.

Gambar 2. Simbol Activities

 Gateways, sebuah gateway direpresentasikan dengan belah ketupat dan memperlihatkan pilihan yang berbeda. Gateway juga menjelaskan mengenai percabangan dan penggabungan dari path yang ada.

Gambar 3. Simbol Gateways 2. Connecting Objects

 Sequence Flow, sequence flow direpresentasikan dengan garis lurus dengan panah tertutup dan menjelaskan mengenai urutan aktivitas yang akan dijalankan.

Gambar 4. Sequance Flow

 Message Flow, message flow direpresentasikan dengan garis putus-putus dan panah terbuka. Message flow menjelaskan pertukaran pesan yang sedang terjadi.

Gambar 5. Message Flow

Association, association direpresentasikan dengan garis putus-putus. Association digunakan untuk mengasosiasikan sebah artifak, data, maupun flow object.

Gambar 6. Association

3. Swimlanes

 Pool, pool direpresentasikan dengan persegi besar yang didalamnya dapat berisi flow objects, connecting object, maupun artifak.

 Lane, lane merupakan bagian lebih mendetail dari pool.

4. Artifacts

 Data Objects, data object digunakan untuk menjelaskan mengenai data yang dibutuhkan atau dihasilkan dari sebuah aktivitas.

Gambar 8. Data Objects

 Group, group direpresentasikan dalam persegi dengan sudut melingkar dan garis luar putus-putus. Group untuk melakukan grouping aktivitas.

Gambar 9. Group

2.12 Prototyping

Menurut McLeod (2007) prototipe adalah suatu versi sistem potensial yang disediakan bagi pengambang dan calon user yang dapat memberikan gambaran bagaimana kira-kira sistem tersebut akan berfungsi bila telah disusun dalam bentuk yang lengkap. Proses dalam memproduksi suatu prototipe adalah prototyping. Tujuannya adalah menghasilkan prototipe secepat mungkin, bahkan dalam satu malam, dan memperoleh umpan balik dari user yang akan memungkinkan prototipe akan ditingkatkan secepat mungkin. Proses ini bisa diulang beberapa kali sehingga menghasilkan prototipe yang dianggap sempurna.

Prototipe requirement (requierement prototipe) dikembangkan sebagai cara untuk menentukan kebutuhan fungsional dari sistem baru pada saat para user tidak

mampu mengungkapkan dengan tepat apa yang mereka butuhkan. Dengan melihat prototipe requirement sebagai fasilitas-fasilitas baru yang ditambahkan pada sistem yang telah ada, para user bisa menentukan processing yang diperlukan untuk sistem baru. Saat kebutuhan telah ditentukan, prototipe requirement dapat mulai dikerjakan dan proyek siap untuk mengembangkan suatu sistem baru. Tahapan dalam prototipe requirement antara lain:

1. Mengidentifikasi kebutuhan user

Pengembang mewawancarai user untuk memperoleh suatu gagasan mengenai apa yang dibutuhkan dari sistem.

2. Mengembangkan prototipe

Pengembang menggunakan satu atau lebih perkakas prototyping untuk mengembangkan satu prototipe. Yang termasuk ke dalam perkakas prototyping adalah bagian-bagian sistem perangkat lunak, seperti spread sheet elektronik dan sistem manajemen database. Masing-masing perkakas tersebut mampu memproduksi bagian dari fasilitas baru yang akan ditambahkan pada sistem yang dibuat.

3. Mengevaluasi prototipe

Pengembang mendemonstrasikan prototipe kepada user untuk menentukan apakah prototipe sudah memuaskan apa belum, jika sudah bisa langjut ke langkah 4, jika belum prototipe diperbaiki dengan mengulangi langkah 1, 2, dan 3.

Pengembang menggunakan prototipe sebagai dasar untuk memprogram sistem baru.

5. Pengujian sistem baru

Pengembang menguji sistem baru. 6. Evaluasi sistem baru

User memberikan masukan kepada pengembang mengenai kelayakan sistem tersebut. Jika sistem baru dapat diterima, selanjutnya diambil langkah ke 7. Jika belum dapat diterima langkah 4 dan 5 diulangi.

Mengembangkan Prototipe

Evaluasi Prototipe

Memprogram Sistem Baru

Pengujian Sistem Baru Tidak Ada Perubahan

Ada Perubahan Mengidentifikasi

Kebutuhan Pemakai

Evaluasi Sistem Baru

Implementasi Sistem Baru Tidak Ada Perubahan

Ada Perubahan

BAB III

ANALISIS DAN DESAIN

3.1 Identifikasi Kebutuhan User

Untuk dapat membuat aplikasi yang mampu mengatasi permasalahan administrasi rawat jalan pada klinik Geo Medika, maka langkah pertama yang harus dilakukan adalah mengidentifikasi terlebih dahulu apa saja kebutuhan user

yang akan menggunakan aplikasi ini nantinya. Sehingga akan mempermudah bagi penulis dalam pembuatan prototipe untuk menentukan siapa saja user dari aplikasi ini, alur dari proses penggunaan aplikasi, serta fitur-fitur apa saja yang harus dimuat dalam aplikasi yang akan dibuat.

Dalam mengidentifikasi kebutuhan user maka terlebih dahulu harus diketahui siapa saja yang terlibat dalam kegiatan administrasi rawat jalan, setelah itu memperoleh informasi dari mereka tentang peran, kegiatan, kendala, dan saran dari mereka terhadap sistem administrasi rawat jalan yang ada. Setelah itu dibutuhkan studi literatur yang berkaitan dengan sistem rawat jalan klinik, baik itu mencari buku, aplikasi, jurnal, dan lain-lain. Dari semua langkah dalam mengidentifikasi kebutuhan user yang telah dilakukan maka penulis dapat mengakhirinya dengan menganalisis informasi-informasi yang telah didapat dan menjabarkannya.

Dari penjelasan di atas maka dapat maka dapat dirangkum tahapan dalam mengidentifikasi kebutuhan user adalah sebagai berikut:

 Menentu

 Mengum pulkan data mentah

 Studi

literatur

 Analisis

kebutuhan sistem

Berikut adalah penjelasan secara lengkap tentang bagaimana cara penulis melakukan tiap tahapan dalam identifikasi kebutuhan user.

3.1.1 Menentukan User Utama

User utama merupakan orang-orang yang akan berinteraksi langsung dengan produk serta akan memperoleh dampak langsung akan pengembangan produk sedang dilaksanakan. Dalam hal ini produk yang sedang dikembangkan adalah sebuah aplikasi untuk bantu jalannya sistem administrasi rawat jalan pada klinik Geo Medika, maka pihak-pihak yang terlibat langsung atau user utamanya antara lain:

 Dokter Umum

 Dokter Spesialis

 Manager Klinik

 Kasir

 Perawat

3.1.2 Mengumpulkan Data Mentah

Dalam mengumpulkan data mentah penulis akan menggunakan metode wawancara kepada para user utama dan observasi tempat. Proses wawancara akan

berfokus pada peran atau job description masing-masing user utama serta mencari tahu bagaimana alur proses administrasi rawat jalan yang sedang berjalan sekarang, serta kendala dan juga saran dari user utama dengan sistem yang ada.

Dari observasi dan wawancara yang telah dilakukan, didapatkan beberapa data yang dihasilkan dalam penelitian yang tampak pada Tabel 3.1.

Tabel 3.1 Data Penelitian

No. Jenis Data Metode Pengumpulan Data

Instrumen Pengumpulan Data

1. Kartu rekam medik, kartu pasien, dan kertas resep.

Wawancara Meminta langsung pada

user utama kasir

2. Data alur sistem lama Wawancara Pertanyaan yang diajukan seluruh user utama tentang alur sistem lama, kekurangan sistem lama, dan harapan pada sistem yang baru

3. Foto lokasi tempat terjadinya proses administrasi rawat jalan

Observasi Kamera

Berikut ini adalah gambar-gambar hasil observasi dan wawancara yang didapatkan berikut penjelasannya.

Gambar 3.1 Klinik GEO MEDIKA

Gambar 3.1 adalah foto dari bangunan klinik Geo Medika yang beralamat pada Jalan Brigjend Katamso Blok P.VII No.03 Rewwin, Waru. Klinik Geo Medika adalah bangunan yang terdiri dari dua lantai dan terletak diantara komplek-komplek ruko.

Gambar 3.3 Ruang Pendaftaran dan Pembayaran (2)

Gambar 3.2 dan 3.3 adalah foto dari ruang pendaftaran dan pembayaran yang terletak di lantai satu dan berada tepat setalah pintu masuk klinik. Disini pasien yang akan berobat akan mendaftar dulu ke perawat yang berada disisi kanan dari pintu masuk klinik, lalu setelah dilakukan pemeriksaan pasien melakukan proses pembayaan pada meja sisi kiri dari pintu masuk klinik.

Gambar 3.5 Ruang Tunggu Pasien Lantai Dua

Gambar 3.4 dan 3.5 adalah foto dari ruang tunggu pasien yang mana terdiri dari ruangan lantai satu dan lantai dua. Ruang tunggu ini terletak didepan ruang praktek dokter. Lantai satu adalah ruang tunggu pasien untuk praktek dokter umum, dokter spesialis anak dan dokter spesialis penyakit dalam. Sedangkan lantai dua adalah ruang tunggu pasien untuk praktek dokter gigi dan dokter spesialis kulit dan kelamin.

Gambar 3.6 Ruang Praktek Dokter Umum

Gambar 3.6 adalah foto dari ruang praktek dokter umum yang terletak di lantai satu. Penulis hanya berkesempatan mengambil foto dari satu ruang praktek dokter saja, yaitu ruang praktek dokter umum yang ditunjukkan pada gambar 3.6. Ruang praktek dokter umum terletak pada ujung lorong dari lantai satu.

Gambar 3.7 Kartu Berobat

Gambar 3.7 adalah foto dari kartu berobat klinik Geo Medika yang berisi nama pasien dan no rekam medis pasien. Dengan menunjukkan kartu ini maka

perawat akan lebih mudah mengetahui apakah pasien merupakan pasien lama atau baru dan juga mempermudah pencarian kartu rekam medis pasien. Dokter harus selalu mengisi kartu rekam medik untuk setiap pasien yang berobat kepadanya.

Gambar 3.8 Kartu Rekam Medis Pasien

Gambar 3.8 adalah foto dari kartu rekam medis pasien yang berisi data identitas pasien dan data diagnosa pasien oleh oleh dokter yang memeriksanya. Satu kartu rekam medik dari satu pasien bisa diisi oleh dokter yang berbeda.

Gambar 3.9 Kertas Resep

Gambar 3.9 adalah foto dari kertas resep yang berisi obat apa saja yang ditujukan pada pasien yang bersangkutan berikut dengan dosisnya serta tanda tangan siapa dokter yang membuat. Tidak semua pasien yang berobat akan mendapatkan resep.

3.1.3 Studi Literatur

Studi literatur dalam sebuah penelitian pada dasarnya dilakukan untuk mendapatkan gambaran yang menyeluruh tentang apa yang sudah dikerjakan oleh orang lain dan bagaimana mengerjakannya. Hal ini penting agar dapat

menghindari usaha yang sebenarnya sudah pernah dilakukan orang lain dan bisa digunakan pada penelitian ini untuk menghemat waktu, tenaga, dan biaya.

Dalam melaksanakan studi literatur dapat dilakukan dengan mencari dan mempelajari literatur yang terkait dengan penelitian yang akan dilaksanakan. Literatur tidak hanya berupa buku, namun dapat berupa jurnal ilmiah, paper, skripsi mahasiswa sebelumnya, aplikasi yang sudah ada, serta artikel blog dari para akademisi dengan tahun terbit lebih dari sepuluh tahun.

Penelitian mengenai Rancang Bangun Aplikasi Administrasi Rawat Jalan Pada Klinik Geo Medika akan membutuhkan literatur yang berkaitan dengan hal berikut:

1. Rekam medik

2. Prototyping

3. Client Server

4. DBMS (Database Management System)

5. MySQL

6. Administrative Worklow System

Dalam penelitian ini akan dilakukan studi literatur yang lebih banyak dengan mengunjungi perpustakaan dan membaca serta meminjam buku yang mengandung materi yang telah disebutkan di atas. Selain itu, materi dan daftar literatur yang digunakan akan dituliskan di bagian landasan teori dan daftar pustaka.

3.1.4 Analisis Sistem

Berdasarkan hasil wawancara dan observasi yang dilakukan, maka selanjutnya dapat dilakukan identifikasi dan analisis permasalahan. Adapun

langkah identifikasi dan analisis permasalahan pada tahap awal ini merupakan langkah untuk menemukan permasalahan utama, serta bagaimana sebaiknya solusi yang tepat untuk mengatasi permasalahan tersebut. Alur proses praktik rawat jalan penanganan pasien klinik Geo Medika terdiri dari proses pendaftaran, proses pemeriksaan, proses pembayaran dapat dilihat pada gambar 3.1 halaman 29. Calon pasien melakukan pendaftaran terlebih dahulu di kasir dan mendapatkan antrean. Setelah itu pasien menuju ke ruang dokter untuk dilakukan pemeriksaan, lalu pasien melakukan pembayaran di kasir.

Mulai

Pendaftaran

Pemeriksaan

Pembayaran

Selesai

Gambar 3.10 Alur Proses Administrasi Rawat Jalan

. Adapun gambaran sistem administrasi rawat jalan yang sudah ada di Klinik Geo Medika, dapat dilihat pada gambar 3.2.

Pasien Perawat Dokter Kasir P h a s e Mulai

Data pasien Data pasien

Pasien lama? Mengecek status pasien Melakukanpen pendaftaran pasien baru Mengambil rekam medik pasien Tidak ya Mendaftarkan pasien ke dalam antrian Memanggil pasien Rekam medik Rekam medik Mendapatkan tindakan dari dokter Menulis rekam medik baru dan

resep

Rekam medik Resep

Rekam medik Resep

Menghitung total biaya tagihan Tagihan Tagihan Melakukan

pembayaran Membuat nota

Nota Nota

Selesai

Gambar 3.11 Gambaran sistem yang sudah ada

Pada gambar 3.2 di atas menggambarkan garis besar sistem administrasi rawat jalan yang sudah ada pada Klinik Geo Medika.

1. Pasien datang ke klinik

2. Kasir melakukan registrasi pasien

3. Jika pasien merupakan pasien baru dari klinik tersebut, maka petugas kasir melakukan pendaftaran rekam medik baru dengan mengisi data identitas pasien baru pada selembar kartu rekam medik baru. Lalu menumpuk kartu rekam medik pada tumpukan antrian lalu meminta pasien menunggu untuk dipanggil

4. Jika pasien lama, petugas kasir akan langsung mengambil rekam mediknya dan menumpuk kartu rekam medik pada tumpukan antrian lalu meminta pasien menunggu untuk dipanggil

5. Kasir menyerahkan rekam medik pasien yang akan diperiksa selanjutnya dan pasien dipanggil dan menuju ruang dokter sesuai dengan nomor urut dan ruang dokter yang dituju

6. Dokter melakukan entri data riwayat kesehatan, diagnosis, tindakan, obat, dan pemeriksaan medik pada kartu rekam medik pasien yang diperiksanya

7. Dokter menuliskan resep

8. Dokter mengantar pasien keluar disertai dengan membawa kartu rekam medik dan resep untuk diserahkan ke kasir

9. Bagian kasir membuat tagihan

Adapun solusi yang ditawarkan adalah merancang dan membangun Rancang Bangun Aplikasi Administrasi Rawat Jalan Pada Klinik Geo. Dengan adanya solusi tersebut diharapkan dapat membantu para kasir dan juga dokter dengan terintegrasinya sistem rawat jalan yang baru.

Dari gambaran sistem yang sudah ada seperti yang tampak pada gambar 3.11, akan dijelaskan lebih detil untuk masing-masing user sistem, dengan tujuan agar dapat dengan mudah mengetahui proses-proses yang harus dieliminasi, ditambahkan, atau diintegrasikan dengan sistem yang baru nantinya, sehingga sistem yang akan dirancang sesuai dengan kebutuhan user.

Informasi-informasi yang didapatkan dari proses menentukan user

utama, pengumpulan data mentah, serta studi literatur nantinya akan digunakan untuk menganalisis sistem yang akan dibuat dan menjabarkannya. Disini penulis menjabarkan sistem yang akan dibuat dalam bentuk diagram arsitektur dan

Business Process Model Notation (BPMN).

3.1.4.1Diagram Arsitektur

Diagram arsitektur menggambarkan rancangan arsitektur kebutuhan aplikasi administrasi rawat jalan klinik yang akan dibangun. Berikut ini adalah gambar diagram arsitektur yang akan dibangun untuk aplikasi administrasi rawat pada klinik Geo Medika.

Database MySql

Zeos User: Dokter

Sub Prosess: Pemeriksaan Application: Delphi 5

OS Office: Windows 7 Profesional

User: Kasir

Sub Prosess: Pendaftaran dan Pembayaran Application: Delphi 5

OS Office: Windows 7 Profesional

Zeos

Data Rekam Medis dan Data Antrian Data Tindakan

Gambar 3.12 Diagram Arsitektur

Dokter dengan subproses pemeriksaan yang menggunakan aplikasi delphi 5 dan OS Windows 7 Professional memberikan data tindakan dan menerima data rekam medis dan data antrean dari kasir dengan subproses pendaftaran dan pembayaran yang menggunakan aplikasi delphi 5 dan OS Windows 7 Professional. Kedua pengguna terhubung dengan database MySQL melalui ZeosLib.

3.1.4.2Business Process Modeling Notation (BPMN)

Business process modeling notation (BPMN) adalah notasi grafis yang menggambarkan logika dari langkah-langkah dalam proses bisnis. Notasi ini telah didesain khusus untuk mengkoordinasikan urutan proses dan pesan yang mengalir antara peserta dalam kegiatan yang berbeda. Dengan BPMN ini nantinya akan menggambarkan apa saja dan bagaimana proses bisnis yang berjalan pada proses administrasi rawat jalan, siapa pelaksanaanya dan apa saja data yang dialirkan. Berikut ini merupakan gambaran BPMN pada gambar 3.4 halaman 25.

Pada pool pasien, terdapat tiga aktivitas, yaitu mendaftar antrian, meakukan pembayaran tindakan, dan menerima bukti pembayaran. Pada pool petugas, terdapat enam aktivitas, yaitu mengecek data pasien, entri data pasien, entri data pasien baru, memanggil pasien selanjutnya untuk dirawat, menerima pembayaran, entri pembayaran dan mencetak bukti pembayaran. Pada pool dokter, terdapat lima aktivitas, yaitu memroses pasien selanjutnya, memeriksa riwayat medik, melakukan tindakan perawatan, entri rekam medik, dan membuat resep.

Kegiatan pertama yang dilakukan adalah dari pool pasien, pasien melakukan pendaftaran kepada petugas. Data data pendaftaran tersebut petugas memeriksa nama dan tanggal lahir pasien, untuk memeriksa apakah pasien tersebut adalah pasien lama atau baru. Bila pasien lama, petugas langsung memproses antrean pasien tersebut. Bila pasien baru, petugas menginputkan data pasien tersebut ke dalam database terlebih dahulu. Pasien kini menunggu antrean. Saat nomor antrean pasien dipanggil, pasien menuju ke ruang dokter. Kegiatan dokter terhadap pasien adalah memeriksa rekam medik pasien, melakukan tindak perawatan, entri rekam medik saat ini, dan menulis resep. Resep tersebut kemudian dibawa oleh pasien kepada petugas untuk melakukan pembayaran. Petugas kemudian menerima pembayaran tersebut dan mengentrikan pembayaran tersebut, serta mencetak bukti pembayaran. Bukti pembayaran tersebut kemudian

Do kt er P e tu ga s P as ie n Memproses pasien selanjutnya Memanggil pasien selanjutnya untuk dirawat

Melak ukan ti ndakan perawatan Entry rekam medik Melak ukan pembayaran ti ndakan Membuat resep Memeriksa riwayat medik Menerima pembayaran Entry pembayaran dan mencetak bukti pembayaran

Menerima buk ti pembayaran

Mendaftar antrian Mengecek

data pasien

Nama & Tanggal Lahir

Entry data antrian Entry Data pasien baru Pasien Lama Pasien Baru

Data identitas diri

Keluhan Pasien

3.2 Mengembangkan Prototipe

Dalam tahap mengembangkan prototipe ini penulis melakukan dua kali pengembangan prototype dengan dua kali evaluasi yang diakhri dengan produk akhir setelah evaluasi yang kedua. Dalam tahap mengembangkan protoype ini, penulis menggunakan aplikasi Delphi 5 untuk membuat prototipe berupa user intrface aplikasi yang akan dibuat nantinya. Diharapkan dengan menyajikan protipe yang seperti ini dan dilakukan ujicoba prototipe, pengguna dapat langsung mengetahui apa yang mereka harapkan dari aplikasi untuk ditambakan atau dikurangi.

3.2.1 Prototipe Satu

Pada tahap pembuatan prototipe satu, penulis mengacu pada tahap mengidentifikasi user beserta tahapan didalamya agar prototipe pertama ini dapat dirancang sesuai dengan sistem yang ada dan mendekati kebutuhan pengguna. Penulis merancang terlebih dahulu fitur-fitur dalam aplikasi yang menjalankan proses utama dalam administrasi rawat jalan. Diantaranya adalah pembuatan

master dokter, pasien, pemeriksaan dan juga fitur transaski input pasien, yang diakhiri dengan fitur laporan buku pasien. Berikut adalah hasil perancangan prototipe satu.

Gambar 3.14 Form Utama

Pada gambar 3.21 merupakan MDI Form utama dari program perototipe satu. Terdapat tiga menu utama, yaitu master, transaksi, dan laporan.

Pada gambar 3.21 merupakan MDI Form utama dari program perototipe satu. Terdapat tiga menu utama, yaitu master, transaksi, dan laporan.

Gambar 3.16 Form Master Dokter Sub Tab Data Dokter

Pada gambar 3.23 merupakan form yang didapat ketika masuk ke menu dokter tab data dokter, dari menu utama master. Pada form ini pengguna dapat menambahkan data dokter yang baru.

Gambar 3.18 Form Master Pemeriksan Sub Tab Data Pemeriksaan

Gambar 3.20 Form Master Pemeriksan Sub Tab Cetak Daftar Pemeriksaan

Gambar 3.22 Form Master Pemeriksan Sub Tab Koreksi Harga

Gambar 3.24 Form Master Pasien Sub Tab Daftar Pasien

Gambar 3.26 Form Laporan Buku Pasien

Gambar 3.28 Form Laporan Buku Pasien Menentukan Range

Gambar 3.29 Form Laporan Buku Pasien Menentukan Range

3.2.2 Evaluasi Protipe Satu

Setelah Protipe Satu diberikan kepada calon pengguna unuk diuji coba, diharapkan mereka telah mengerti akan gambaran aplikasi yang sedang dibuat secara garis besar, dan mereka telah mampu memberikan masukan tentang fitur apa saja yang sekiranya perlu ditambah untuk membantu berjalannya sistem, atau

fitur apa yang tidak berguna untuk sistem. Dan berikut ini adalah hasil evaluasi terhadap protipe satu dari calon pengguna.

Adapun kekurangan dari prototipe satu yang diharapkan akan ditambahkan pada prototipe selanjutnya adalah:

1. Aplikasi belum multiuser beserta dengan hak aksesnya.

2. Belum mengakomodasi berbagai macam gelar dokter, sehingga harus menulis ulang gelar setiap ingin menambahkan entri data dokter yang baru. 3. Pengisian data master dokter masih belum lengkap, seperti data golongan dan

komisi.

4. Menambahkan jenis laporan, seperti laporan penerimaan kas harian, serta piutang pasien.

3.2.3 Prototipe Dua

Pada tahap pembuatan prototipe dua, penulis mengacu pada hasil evaluasi pengguna terhadap prototipe satu. Dari evaluasi satu yang diberikan, terlihat pengguna tidak mengalami masalah dalam memahami aplikasi beserta fitur-fitur yang ada sehingga tidak ada perubahan dari segi form dan fitur yang dibuat di prototipe satu, hanya saja pengguna merasa masih diperlukan beberapa form untuk melengkapi aplikasi agar dapat sepenuhnya menggantikan sistem yang telah ada dan bisa menambah nilai tambah bagi klinik Geo Medika. Berikut adalah hasil perancangan prototipe dua. Fitur yang tidak diubah pada prototipe satu tidak ditampilkan kembali.

Gambar 3.30 Menu Management User

Gambar 3.32 Sub-menu Master

Gambar 3.34 Preset Gelar Belakang Dokter

Gambar 3.36 Data Golongan Reward

Gambar 3.38 Laporan Penerimaan Kas Harian

Gambar 3.39 Laporan Piutan Pasien Harian

3.2.4 Evaluasi Prototipe Dua

Secara garis besar prototipe dua tidak terlalu memiliki perbedaan yang besar dalam hal user interface. Prototipe dua hanya menambahkan beberapa fitur yang diminta setelah prototipe satu ditunjukan. Setelah menunjukan prototipe dua,

pengguna merasa program yang dibuat sudah mendekati dari ekspektasi pengguna. Hasil dari evaluasi prototipe dua ini akan dijadikan landasan dalam membuat program tahap akhirnya yaitu prototipe tiga atau program akhir. Penjelasan tentang implementasi sistem yaitu menjelaskan cara kerja aplikasi ini ketika diimplementasikan. Fungsi lain dari penjelasan implementasi sistem adalah mengenalkan pengguna mengenai cara kerja atau alur dari aplikasi administrasi rawat jalan pada klinik Geo Medika.

a. Form Management User adalah sebuah form yang berfungsi untuk

mengelola data-data atau akun pengguna aplikasi ini. Tampilan Form ManagementUser dapat dilihat pada gambar 4.1.

Gambar 3.40 Form Management User

b. Form Data Dokter adalah sebuah form untuk menambahkan data dokter yang baru maupun memperbarui atau mengubah data dokter yang sudah ada. Tampilan Form daftar dapat dilihat pada Gambar 4.2.

Gambar 3.41 Form RegistrasiUser External

c. Daftar Dokter digunakan untuk melihat daftar-daftar dokter yang telah teregistrasi pada aplikasi ini. Tampilan Form daftar dokter dapat dilihat pada Gambar 4.3.

Gambar 3.42 Form Master User

d. Form Cetak daftar dokter adalah form yang digunakan untuk mencetak data-data dokter yang telah teregistrasi ke dalam aplikasi. Tampilan Form

cetak daftar dokter dapat dilihat pada Gambar 4.4.

e. Form Data Pemeriksaan adalah sebuah form untuk memasukan jenis pemeriksaan yang dapat dilayani pada klinik Geo Medika. Pada form ini pengguna dapat memasukan data pemeriksaan yang baru maupun mengubah data yang sudah tersimpan sebelumnya. Tampilan Form data pemeriksaan dapat dilihat pada Gambar 4.5.

Gambar 3.44 Form Monitoring Dokumen

f. Form Daftar Pemeriksaan adalah sebuah form yang menampung detil dari segala jenis pemeriksaan yang dapat dilayani pada klinik Geo Medika. Tampilan Form Daftar Pemeriksaan dapat dilihat pada Gambar 4.6.

Gambar 3.45 Form Daftar Pemeriksaan

g. Form Cetak Daftar Pemeriksaan adalah Form yang berfungsi untuk mencetak jenis-jenis pemeriksaan yang telah tersimpan di dalam database. Tampilan Form Cetak Daftar Pemeriksaan ini dapat dilihat pada Gambar 4.7.

h. Koreksi Harga adalah form untuk mengubah harga pelayanan pemeriksaan pada klinik Geo Medika. Tampilan Form Koreksi Harga dapat dilihat pada Gambar 4.8.

Gambar 3.47 Form Koreksi Harga

i. Data Pasien adalah Form yang berfungsi untuk menambahkan data pasien baru ke dalam database. Data Pasien dapat dilihat pada Gambar 4.9.

Gambar 3.48 Form Data Pasien

j. Form Daftar Pasien adalah Form yang berfungsi untuk menampilkan data-data pasien yang sudah tersimpan ke dalam data-database. Tampilan Form

Daftar Pasien dapat dilihat pada Gambar 4.10.

Gambar 3.49 Form Daftar Pasien

k. Form Transaksi Penerimaan Pasien adalah Form yang berfungsi untuk memulai transaksi penerimaan pasien ketika ada pasien yang ingin berobat. Kasir menginputkan nama pasien dari database pasien yang sudah pernah mendaftar. Bila pasien belum pernah dating sebelumnya, maka kasir menginputkan data pasien tersebut terlebih dahulu. Tampilan Form

Gambar 3.50 Form Transaksi Penerimaan Pasien

l. Form Antrean Pasien adalah Form yang berfungsi untuk menampilkan pasien-pasien yang sedang antre menunggu diperiksa atau dilayani oleh dokter. Tampilan Form Antrean Pasien dapat dilihat pada Gambar 4.12.

Gambar 3.51 Form Antrean Pasien

m. Form Input Rekam Medis merupakan form untuk menginputkan riwayat medis pasien setelah dilakukan pemeriksaan. Tampilan Form Input Rekam Medis dapat dilihat pada Gambar 4.13.

Gambar 3.52 Form Input Rekam Medis

n. Form Laporan Penerimaan Pasien Harian merupakan form untuk menghasilkan laporan mengenai daftar kunjungan pasien di Klinik Geo Medika. Pengguna memilih periode yang ingin dilihat jumlah kunjungan pasiennya dan system akan menampilkan laporannya. Tampilan Form

Laporan Penerimaan Pasien Harian dapat dilihat pada Gambar 4.14 dan Gambar 4.15

Gambar 3.54 Laporan Penerimaan Pasien Harian

o. Form Laporan Penerimaan Kas merupakan form untuk menghasilkan laporan mengenai jumlah kas yang masuk selama periode tertentu di Klinik Geo Medika. Pengguna memilih periode yang ingin dilihat jumlah kunjungan pasiennya dan system akan menampilkan laporannya. Tampilan

Form Laporan Penerimaan Pasien Harian dapat dilihat pada Gambar 4.16 dan Gambar 4.17

Gambar 3.56 Laporan Penerimaan Kas

p. Form Laporan Rekap Item merupakan form untuk menghasilkan laporan mengenai rekap tiap item atau tindakan-tindakan apa saja yang ditangani leh Klinik Geo Medika selama periode tertentu. Pengguna memilih periode yang ingin dilihat jumlah rekap itemnya dan system akan menampilkan laporannya. Tampilan Form Laporan Rekap Item dapat dilihat pada Gambar 4.18 dan Gambar 4.19

Gambar 3.58 Laporan Rekap Item

q. Form Fee Dokter merupakan form untuk menghasilkan laporan mengenai jumlah fee yang diterima oleh setiap dokter di klinik GEO Medika dalam setiap prakteknya berdasarkan periode dan dokter tertentu. Pengguna memilih periode yang ingin dilihat jumlah rekap itemnya dan system akan menampilkan laporannya. Tampilan Form Fee Dokter dapat dilihat pada Gambar 4.20 dan Gambar 4.21

Gambar 3.59 Laporan Fee Dokter

Gambar 3.60 Laporan Fee Dokter

r. FormFee Perawat merupakan form untuk menghasilkan laporan mengenai jumlah fee yang diterima oleh setiap perawat di klinik GEO Medika dalam setiap prakteknya berdasarkan periode dan perawat tertentu. Pengguna memilih periode yang ingin dilihat jumlah rekap itemnya dan system akan menampilkan laporannya. Tampilan Form Fee Perawat dapat dilihat pada Gambar 4.22 dan Gambar 4.23`

Gambar 3.61 Laporan Fee Dokter

3.3 Memprogram Sistem Baru

3.3.1 Diagram Konteks

Pada diagram konteks ini ada 4 entitas yang terlibat, yaitu dokter, kasir, direktur klinik, dan admin. Entitas-entitas tersebut memberikan data masukan yang akan diolah oleh sistem dan menerima keluaran sebagai hasil dari proses yang terjadi.

Kasir/perawat terlibat dalam proses pendaftaran rekam medik baru dan registrasi poliklinik. Pada proses pendaftaran rekam medik baru, kasir/perawat memberikan masukan berupa data pasien, sedangkan pada proses registrasi antrian kasir/perawat memberikan masukan berupa data dokter yang dipilih oleh pasien. Kasir/perawat merupakan entitas yang terlibat dalam proses pelayanan pemeriksaan dan pelayanan tindakan. Pada proses pelayanan tindakan, Kasir/perawat memberikan masukan berupa nomor antrian dan data rekam medis pasien yang meliputi data masukan antara isi keluhan, riwayat kesehatan, observasi. Kasir/perawat merupakan entitas yang terlibat dalam proses pembayaran tindakan dengan memasukkan nomor rekam medik dan nominal uang yang diberikan oleh pasien serta mencetak bukti pembayaran dan nomor antrian untuk melakukan tindakan.

Laporan Penerimaan Pasien Harian

Data Pasien Lama

Data Dokter Data User

Data Jenis Pemeriksaan

Data_Pemeriksaan data rekam medis

pasien

data dokter

data pasien lama data pasien baru

data pembayaran

data antrian Data pemeriksaan

Laporan Rekap Item Laporan Fee Dokter

Laporan Fee Klinik kasir/perawat

Dokter

1

Aplikasi Administrasi Rawat Jalan Klinik Geomedika

Manager

Admin

Gambar 3.63 Diagram Konteks Rancang Bangun Aplikasi Administrasi Rawat Jalan Pada Klinik Geo Medika

3.3.2 Diagram Jenjang

Diagram berjenjang merupakan alur perencanaan sistem yang dapat menampilkan seluruh proses yang terdapat pada suatu aplikasi tertentu dengan jelas dan terstruktur. Pada rancang bangun aplikasi administrasi rawat jalan terdapat tiga proses utama yaitu manage data master, pemeriksaan pasien, laporan.

Masing-masing dari proses utama tersebut akan dijabarkan kembali ke dalam beberapa sub proses. Dari diagram berjenjang berikut ini akan terlihat masing-masing sub level dari Data Flow Diagram (DFD). Seluruh proses yang terbentuk merupakan penjabaran dari masing-masing proses di atas dan semuanya telah tergambar jelas pada Diagram Konteks sebelumnya. Adapun secara garis besar, diagram jenjang yang membangun aplikasi dapat digambarkan pada Gambar 3.15

0 Rancang Bangun Aplikasi Administrasi Rawat Jalan 1 Manage Data Master 2 Pemeriksaan Pasien 3 Laporan 1.3 Input Data User

1.2 Input Data Dokter

1.1 Input Data Periksa

2.1 Registrasi Pasien Baru 2.2 Pendaftaran Antrian Pasien 3.1 Pembuatan Laporan Fee Dokter 3.2 Pembuatan Laporan Rekap Item 3.3 Pembuatan Laporan Fee Klinik

1.3 Input Data Pasien

2.3 Pemeriksaan Pasien Oleh Dokter 2.4 Pembayaran 3.3 Pembuatan Laporan Penerimaan Pasien Harian

3.3.3 DFD Level 0

DFD Level 0 berisi urutan proses yang terdapat dalam rancang bangun sistem informasi pelayanan dan rekam medis. Proses dibagi menjadi 3 sub yaitu manage data master, pemeriksaan pasien, laporan. DFD Level 0 dapat dilihat pada Gambar 3.16.

Pada proses manage data master, Entitas admin memasukkan semua data master dari dokter, user, pasien lama, dan data jenis pemeriksaan. Data-data ini digunakan sebagai data dasar dari tiap data yang nantinya akan digunakan dalam proses transaksi. Perawat/kasir yang telah memasukkan data pasien mengecek apakah pasien merupakan pasien lama atau baru dan mendapatkan hasil pengecekkan. Jika merupakan pasien baru, Entitas Kasir/Perawat memasukkan data pasien. Bila pasien tersebut merupakan pasien lama dan ada perubahan maka Entitas Kasir/Perawat menyimpan perubahan data pasien. Namun, bila pasien merupakan pasien baru, Entitas Kasir/Perawat memasukkan data Pasien baru dan mencetak nomor rekam medik pasien baru.

Pada proses Pemeriksaan Pasien, perawat/kasir yang telah memasukkan data pasien mengecek apakah pasien merupakan pasien lama atau baru dan mendapatkan hasil pengecekkan. Jika merupakan pasien baru, Entitas Kasir/Perawat memasukkan data pasien. Bila pasien tersebut merupakan pasien lama maka Entitas Kasir/Perawat memasukkan data pasien tersebut kedalam data antrian dokter. Namun, bila pasien merupakan pasien baru, Entitas Kasir/Perawat memasukkan data Pasien baru dan memasukkan data pasien tersebut kedalam data antrian dokter. Pasien yang telah mendapatkan nomor urut menunggu panggilan pada ruang tunggu. Entitas Dokter melakukan panggilan pasien berdasarkan

informasi nomor urut panggilan yang ditampilkan oleh Sistem. Setelah menampilkan pasien yang akan dilayani, sistem secara otomatis juga menampilkan riwayat medis pasien. Setelah dilakukan pemeriksaan, Entitas Dokter memasukkan data hasil pemeriksaan kedalam sistem. Data pemeriksaan entitas dokter akan terhubung dengan entitas perawat/kasir yang langsung memberikan hasil keluaran dalam sistemnya berupa tindakan apa saja yang diperoleh dan sudah beserta harga tinndakan dan totalnya. Entitas kasir/perawat pun sudah langsung bisa mencetak nota pembayaran dan pasien dapat langsung melakukan pembayaran

Pada Proses Pembuatan Laporan, Entitas Manager memasukkan tahun kedalam sistem dan sistem akan menampilkan laporan sesuai dengan kebutuhan masing-masing Entitas.

Data Dokter

Data Pasien Lama Data Jenis Pemeriksaan Data User

Data Rekam Medik Data Antrian

Data Pemeriksaan Data Pasien Lama

Data Pembayaran

Data Dokter

Data Pasien Baru

Data pemeriksaan

Laporan Penerimaan Pasien Harian

Laporan Rekap Item Laporan Fee Dokter

Laporan Fee Klinik kasir/perawat

Dokter

Manager 1.1

Manage Data Master

1.2 Pemeriksaan Pasien 1.3 Laporan 26 Pasien 34 Dokter 31 rekamh 36 head

35 PASIEN DFT

28 periksa 25 gluser

32 Dokter MFee 11 gelar2 12 gelar1 13 wil 14 detailer 15 instansi 16 rekami 17 detail 18 gol 19 jenis 20 glmenu

21 glmenuip Admin

3.3.4 DFD Level 1 Manage Data User

DFD Level 1 Manage Data User dapat dilihat pada gambar 3.17. Pada proses Manage Data User, terdapat empat subproses, yaitu input data periksa,

input data dokter, input data user, dan input data pasien.

Data Jenis Pemeriksaan

Data Dokter

Data User

Data Pasien Lama

34 Dokter

28 periksa

26 Pasien

25 gluser

1.1.1 Input Data Periksa

1.1.2 Input Data Dokter

1.1.3 Input Data User

1.1.4 Input Data Pasien

13 wil

18 gol

12 gelar1

11 gelar2

15 instansi

14 detailer

19 jenis

20 glmenu

21 glmenuip Admin

3.3.5 DFD Level 1 Pemeriksaan Pasien

Pada proses Pemeriksaan Pasien, terdapat empat subproses yaitu registrasi pasien baru, pendaftaran antrian pasien, pemeriksaan pasien oleh dokter, dan pembayaran.

Data Pasien Baru

Data Pasien Baru

Data Pasien Lama

Data antrian Data rekam medik Data pemeriksaan

Data pemeriksaan Data pembayaran

Dokter kasir

26 Pasien

34 Dokter

28 periksa

36 head

35 PASIEN DFT

31 rekamh

1.2.1 Registrasi Pasien

Baru

1.2.2 Pendaftaran Antrian Pasien

1.2.3 Pemeriksaan Pasien Oleh Dokter

1.2.4 Pembayaran

16 rekami

17 detail

3.3.6 DFD Level 1 Laporan

DFD level 1 Laporan dapat dilihat pada gambar 3.19 halaman 32. Pada proses Laporan, terdapat empat subproses yaitu pembuatan laporan rekap item, pembuatan laporan fee dokter, pembuatan laporan fee klinik, dan pembuatan laporan penerimaan pasien harian.

Manager 32 Dokter MFee

36 head

34 Dokter

1.3.1 Pembuatan Laporan

Rekap Item

1.3.2 Pembuatan Laporan

Fee Dokter

1.3.3

Pembuatan Laporan Fee Klinik

1.3.4 Pembuatan

Laporan Penerimaan 35 PASIEN DFT

Gambar 3.68 DFD Level 1 Laporan

3.3.7 Desain Database

Desain database dibagi dalam dua model, yang pertama Conceptual Data Model (CDM) dan Physical Data Model (PDM). CDM menggambarkan secara keseluruhan konsep struktur database yang dirancang untuk suatu program ataupun aplikasi. Pada CDM, belum tergambar dengan jelas bentukan tabel-tabel penyusunan database. Selain itu, relasi atau hubungan antar tabel dan field kunci (primary key) telah terlihat dengan jelas. PDM menggambarkan secara lebih terperinci relasi antar tabel serta field-field database yang berelasi (foreign key).

Rel ati onshi p_1 Rel ati onshi p_2

Rel ati onshi p_3

Rel ati onshi p_4

Rel ati onshi p_6

Rel ati onshi p_7 Rel ati onshi p_8

Rel ati onshi p_9 Rel ati onshi p_10

Rel ati onshi p_11 Rel ati onshi p_12

Rel ati onshi p_13

Rel ati onshi p_14 Rel ati onshi p_15

Rel ati onshi p_16

Rel ati onshi p_17 Rel ati onshi p_18

Rel ati onshi p_19

Rel ati onshi p_20

Rel ati onshi p_22

Rel ati onshi p_23 Rel ati onshi p_24

Rel ati onshi p_25

gl user Nuser

passwd

<pi > Vari abl e characters (20) Vari abl e characters (20)

<M > Identi fi er_1<pi >

gl m enui p ket

passwd

Vari abl e characters (30) Vari abl e characters (20)

gl m enu Nam aM enu

ket

<pi >Vari abl e characters (10) Vari abl e characters (30)

<M > Identi fi er_1 <pi >

gel ar1 kodegel ar1

nam a

<pi >Vari abl e characters (10) Vari abl e characters (20)

<M > Identi fi er_1 <pi >

gel ar2 kodegel ar2

nam a

<pi > Vari abl e characters (10) Vari abl e characters (20)

<M > Identi fi er_1 <pi >

dokter kodedokter

GELAR1 nam a GELAR2 al am atk tel ponk hp kota nm kota al am atr teponr detai l er gol 1 kom i si 1 gol 2 kom i si 2 gol 3 kom i si 3 gol 4 kom i si 4 gol 5 kom i si 5

<pi >Vari abl e characters (5) Vari abl e characters (15) Vari abl e characters (20) Vari abl e characters (15) Vari abl e characters (40) Vari abl e characters (15) <Undefi ned> Vari abl e characters (30) Vari abl e characters (20) <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <M >

Identi fi er_1 <pi >

wi l kodewi l

nam a

<pi >Vari abl e characters (10) Vari abl e characters (20)

<M > Identi fi er_1 <pi >

detai l er kodedetai l er

al am at tel pon kota nm kota

<pi >Vari abl e characters (20) Vari abl e characters (100) Vari abl e characters (15) Vari abl e characters (30) Vari abl e characters (20)

<M >

Identi fi er_1<pi >

gol kodegol

nam a kom i si

<pi > Characters (2) Vari abl e characters (20) Deci m al (10)

<M > Identi fi er_1 <pi >

j eni s kodej eni s

nam a

<pi > Characters (2) Vari abl e characters (20)

<M > Identi fi er_1<pi >

peri ksa kodeperi ksa

nam a j eni s nm j eni s norm al harga gol nm gol kom i si ST AT US

<pi > Vari abl e characters (15) Vari abl e characters (20) Characters (2) <Undefi ned> Vari abl e characters (40) Deci m al Characters (2) <Undefi ned> Deci m al (10) Characters (1)

<M >

Identi fi er_1<pi >

pasi en kodepasi en

nam a al am at T el p um ur

<pi >Vari abl e characters (10) Vari abl e characters (20) Vari abl e characters (100) Vari abl e characters (50) Characters (3)

<M >

Identi fi er_1<pi > i nstansi

kodei nstansi al am at tel pon person detai l er

<pi >Vari abl e characters (30) Vari abl e characters (100) Vari abl e characters (15) <Undefi ned> <Undefi ned>

<M >

Identi fi er_1 <pi >

dokterm fee kode GELAR1 nam a GELAR2 kodep nam ap harga kl i ni k fdokter fkl i ni k fee0 fee1 fee2 ket1 ket2

Vari abl e characters (10) Vari abl e characters (15) Vari abl e characters (20) Vari abl e characters (15) Vari abl e characters (30) Vari abl e characters (30) Deci m al Deci m al Deci m al Deci m al Deci m al Deci m al Deci m al Vari abl e characters (30) Vari abl e characters (30) head

kodehead kode1 nam a al am at tgl l ahi r i nstan T el p um ur l p dokter g1 g2 KODED al am atk tel ponk tgl str tgl hsl di sc di scrp total um l unas kem bal i di bayar1 di bayar2 tandal ns nuser tgl l ns

<pi >Vari abl e characters (30) Vari abl e characters (6) Vari abl e characters (20) Vari abl e characters (100) Date

Vari abl e characters (30) Vari abl e characters (50) Characters (3) Characters (1) Vari abl e characters (20) Vari abl e characters (15) Vari abl e characters (15) Vari abl e characters (5) Vari abl e characters (40) Vari abl e characters (15) Date

Date Deci m al Deci m al Deci m al Deci m al Deci m al Deci m al Deci m al Deci m al Characters (1) Vari abl e characters (20) Date

<M >

Identi fi er_1<pi >

detai l kode KODED tgl str kodep nam ap norm al hasi l harga gol j eni s ST AT US nu

Vari abl e characters (10) Vari abl e characters (5) Date

Vari abl e characters (30) Vari abl e characters (30) Vari abl e characters (40) Vari abl e characters (30) Deci m al Characters (2) Characters (2) Characters (1) Short i nteger rekam h

koderekam m edi s kodep nam a al am at T el p um ur l p tgl l ahi r i nstan tgl dftar j am rekam h KODED GELAR1 NAM AD GELAR2 ST AT US REKAM 1 REKAM 2 ...

<pi > Vari abl e characters (30) Vari abl e characters (30) Vari abl e characters (20) Vari abl e characters (100) Vari abl e characters (50) Characters (3) Characters (1) Date

Vari abl e characters (30) Date

Vari abl e characters (15) Vari abl e characters (5) Vari abl e characters (15) Vari abl e characters (30) Vari abl e characters (15) Characters (1)

Long vari abl e characters (1000) Long vari abl e characters (1000)

<M > rekam i kode kodep nam ap norm al hasi l harga gol j eni s nu

Vari abl e characters (10) Vari abl e characters (30) Vari abl e characters (30) Vari abl e characters (40) Vari abl e characters (30) Deci m al Characters (2) Characters (2) Short i nteger

pasi endft j am

kode nam a al am at T el p um ur l p tgl l ahi r i nstan tgl daftar KODED GELAR1 NAM AD GELAR2 ST AT US

<pi > Vari abl e characters (15) Vari abl e characters (10) Vari abl e characters (20) Vari abl e characters (100) Vari abl e characters (50) Characters (3) Characters (1) Date

Vari abl e characters (30) <Undefi ned> Vari abl e characters (5) Vari abl e characters (15) Vari abl e characters (30) Vari abl e characters (15) Characters (1)

<M >

Identi fi er_1<pi >

Gambar 3.70 Physical Data Modelling

(PDM)

FK_GLM ENUIP_RELAT IONS_GLUSER FK_GLM ENUIP_RELAT IONS_GLM ENU

FK_DOKT ER_RELAT IONS_GELAR1

FK_DOKT ER_RELAT IONS_GELAR2

FK_DOKT ER_RELAT IONS_DET AILER

FK_RELAT ION_RELAT IONS_GOL FK_RELAT ION_RELAT IONS_DOKT ER

FK_DOKT ER_RELAT IONS_WIL

FK_PERIKSA_RELAT IONS_JENIS FK_PERIKSA_RELAT IONS_GOL

FK_PASIEN_RELAT IONS_INST ANSI FK_INST ANSI_RELAT IONS_DET AILER

FK_DOKT ERM F_RELAT IONS_DOKT ER

FK_DOKT ERM F_RELAT IONS_PERIKSA FK_HEAD_RELAT IONS_DOKT ER

FK_PASIENDF_RELAT IONS_DOKT ER

FK_PASIENDF_RELAT IONS_PASIEN FK_REKAM H_RELAT IONS_PASIEN

FK_REKAM H_RELAT IONS_DOKT ER

FK_REKAM I_RELAT IONS_REKAM H

FK_DET AIL_RELAT IONS_HEAD

FK_DET AIL_RELAT IONS_PERIKSA FK_HEAD_RELAT IONS_GLUSER

FK_REKAM I_RELAT IONS_PERIKSA gl user Nuser passwd varchar(20) varchar(20) <pk>

gl m enui p Nuser

Nam aM enu ket passwd varchar(20) varchar(10) varchar(30) varchar(20) <pk,fk1> <pk,fk2> gl m enu

Nam aM enu ket varchar(10) varchar(30) <pk> gel ar1 kodegel ar1 nam a varchar(10) varchar(20) <pk> gel ar2 kodegel ar2 nam a varchar(10) varchar(20) <pk> dokter kodedokter kodegel ar1 kodegel ar2 kodewi l kodedetai l er GELAR1 nam a GELAR2 al am atk tel ponk hp kota nm kota al am atr teponr detai l er gol 1 kom i si 1 gol 2 kom i si 2 gol 3 kom i si 3 gol 4 kom i si 4 gol 5 kom i si 5

varchar(5) varchar(10) varchar(10) varchar(10) varchar(20) varchar(15) varchar(20) varchar(15) varchar(40) varchar(15) <Undefi ned> varchar(30) varchar(20) <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <Undefi ned> <pk> <fk1> <fk2> <fk4> <fk3> wi l kodewi l nam a varchar(10) varchar(20) <pk>

detai l er kodedetai l er al am at tel pon kota nm kota varchar(20) varchar(100) varchar(15) varchar(30) varchar(20) <pk> gol kodegol nam a kom i si

char(2) varchar(20) deci m al (10)

<pk>

j eni s kodej eni s nam a char(2) varchar(20) <pk> peri ksa kodeperi ksa kodegol kodej eni s nam a j eni s nm j eni s norm al harga gol nm gol kom i si ST AT US

varchar(15) char(2) char(2) varchar(20) char(2) <Undefi ned> varchar(40) deci m al char(2) <Undefi ned> deci m al (10) char(1) <pk> <fk2> <fk1> pasi en kodepasi en kodei nstansi nam a al am at T el p um ur varchar(10) varchar(30) varchar(20) varchar(100) varchar(50) char(3) <pk> <fk> i nstansi kodei nstansi kodedetai l er al am at tel pon person detai l er

varchar(30) varchar(20) varchar(100) varchar(15) <Undefi ned> <Undefi ned> <pk> <fk> dokterm fee kodedokter kodeperi ksa kode GELAR1 nam a GELAR2 kodep nam ap harga kl i ni k fdokter fkl i ni k fee0 fee1 fee2 ket1 ket2 varchar(5) varchar(15) varchar(10) varchar(15) varchar(20) varchar(15) varchar(30) varchar(30) deci m al deci m al deci m al deci m al deci m al deci m al deci m al varchar(30) varchar(30) <pk,fk1> <pk,fk2> head kodehead Nuser2 kodedokter kode1 nam a al am at tgl l ahi r i nstan T el p um ur l p dokter g1 g2 KODED al am atk tel ponk tgl str tgl hsl di sc di scrp total um l unas kem bal i di bayar1 di bayar2 tandal ns nuser tgl l ns

varchar(30) varchar(20) varchar(5) varchar(6) varchar(20) varchar(100) date varchar(30) varchar(50) char(3) char(1) varchar(20) varchar(15) varchar(15) varchar(5) varchar(40) varchar(15) date date deci m al deci m al deci m al deci m al deci m al deci m al deci m al deci m al char(1) varchar(20) date <pk> <fk2> <fk1> detai l kodehead kodeperi ksa kode KODED tgl str kodep nam ap norm al hasi l harga gol j eni s ST AT US nu varchar(30) varchar(15) varchar(10) varchar(5) date varchar(30) varchar(30) varchar(40) varchar(30) deci m al char(2) char(2) char(1) sm al l i nt

<pk,fk1> <pk,fk2>

rekam h koderekam m edi s kodepasi en kodedokter kodep nam a al am at T el p um ur l p tgl l ahi r i nstan tgl dftar j am rekam h KODED GELAR1 NAM AD GELAR2 ST AT US REKAM 1 REKAM 2 varchar(30) varchar(10) varchar(5) varchar(30) varchar(20) varchar(100) varchar(50) char(3) char(1) date varchar(30) date varchar(15) varchar(5) varchar(15) varchar(30) varchar(15) char(1) l ong varchar l ong varchar

<pk> <fk1> <fk2>

rekam i koderekam m edi s kodeperi ksa kode kodep nam ap norm al hasi l harga gol j eni s nu varchar(30) varchar(15) varchar(10) varchar(30) varchar(30) varchar(40) varchar(30) deci m al char(2) char(2) sm al l i nt

<pk,fk1> <pk,fk2> pasi endft kodepasi en j am kodedokter kode nam a al am at T el p um ur l p tgl l ahi r i nstan tgl daftar KODED GELAR1 NAM AD GELAR2 ST AT US

varchar(10) varchar(15) varchar(5) varchar(10) varchar(20) varchar(100) varchar(50) char(3) char(1) date varchar(30) <Undefi ned> varchar(5) varchar(15) varchar(30) varchar(15) char(1) <pk,fk2> <pk> <fk1> Rel ati onshi p_7

kodegol kodedokter char(2) varchar(5) <pk,fk1> <pk,fk2>

3.3.8 Struktur Tabel

a. Nama Tabel : PASIEN

Primary Key : KODEPASIEN

Foreign Key : KODEINSTANSI

Tabel 3.1 Tabel Pasien

Nama Kode Tipe Data Length

kodepasien KODEPASIEN varchar(10) 10

kodeinstansi KODEINSTANSI varchar(30) 30

nama NAMA varchar(20) 20

alamat ALAMAT varchar(100) 100

Telp TELP varchar(50) 50

umur UMUR char(3) 3

b. Nama Tabel : DOKTER

Primary Key : KODEDOKTER

Foreign Key : KODEGELAR1, KODEGELAR2, KODEWIL,

KODEDETAILER

Tabel 3.2 Tabel Dokter

Nama Kode Tipe Data Length

kodedokter KODEDOKTER varchar(5) 5

kodegelar1 KODEGELAR1 varchar(10) 10

kodewil KODEWIL varchar(10) 10

kodedetailer KODEDETAILER varchar(20) 20

GELAR1 GELAR1 varchar(15) 15

nama NAMA varchar(20) 20

GELAR2 GELAR2 varchar(15) 15

alamatk ALAMATK varchar(40) 40

telponk TELPONK varchar(15) 15

hp HP varchar(20) 20

kota KOTA varchar(30) 30

nmkota NMKOTA varchar(20) 20

alamatr ALAMATR varchar(20) 20

teponr TEPONR varchar(20) 20

detailer DETAILER varchar(20) 20

gol1 GOL1 varchar(20) 20

komisi1 KOMISI1 varchar(20) 20

gol2 GOL2 varchar(20) 20

komisi2 KOMISI2 varchar(20) 20

gol3 GOL3 varchar(20) 20

komisi3 KOMISI3 varchar(20) 20

gol4 GOL4 varchar(20) 20

komisi4 KOMISI4 varchar(20) 20

gol5 GOL5 varchar(20) 20

c. Nama Tabel : REKAMH

Primary Key : KODEREKAMMEDIS

Foreign Key : KODEPASIEN, KODEDOKTER

Tabel 3.3 Tabel Rekam Medik

Nama Kode Tipe Data Length

koderekammedis KODEREKAMMEDIS varchar(30) 30

kodepasien KODEPASIEN varchar(10) 10

kodedokter KODEDOKTER varchar(5) 5

kodep KODEP varchar(30) 30

nama NAMA varchar(20) 20

alamat ALAMAT varchar(100) 100

Telp TELP varchar(50) 50

umur UMUR char(3) 3

lp LP char(1) 1

tgllahir TGLLAHIR date

instan INSTAN varchar(30) 30

tgldftar TGLDFTAR date

jamrekamh JAMREKAMH varchar(15) 15

KODED KODED varchar(5) 5

GELAR1 GELAR1 varchar(15) 15

NAMAD NAMAD varchar(30) 30

GELAR2 GELAR2 varchar(15) 15

REKAM1 REKAM1 long varchar

REKAM2 REKAM2 long varchar

d. Nama Tabel : PERIKSA

Primary Key : KODEPERIKSA

Foreign Key : KODEGOL, KODEJENIS

Tabel 3.4 Tabel Periksa

Nama Kode Tipe Data Length

kodeperiksa KODEPERIKSA varchar(15) 15

kodegol KODEGOL char(2) 2

kodejenis KODEJENIS char(2) 2

nama NAMA varchar(20) 20

jenis JENIS char(2) 2

nmjenis NMJENIS varchar(20) 20

normal NORMAL varchar(40) 40

harga HARGA decimal

gol GOL char(2) 2

nmgol NMGOL varchar(20) 20

komisi KOMISI decimal(10) 10

STATUS STATUS char(1) 1

e. Nama Tabel : GLMENU

Primary Key : NAMAMENU

6. Evaluasi Hasil Uji Coba Pendaftaran Pasien

Proses ini bertujuan untuk mengetahui keberhasilan handle erorr proses inputan data melalui aplikasi dengan data seperti yang terlihat pada Tabel 4.13. Proses pendaftaran pasien pada halaman data pasien adalah proses penyimpanan data pasien baru berikut dengan segala atributnya yang mana akan langsung tersimpan jika semua field telah terisi dengan sempurna namun jika ada salah satu field yang belum terisi maka akan menampilkan pesan eror. Uji coba halaman data pasien dapat dijelaskan pada Tabel 4.14.

Tabel 4.13 Data Pasien Baru

Nama Kolom Data 1 Data 2

Kode 1920 1955

Nama NENCY Clara

Tgl.Lahir 3/17/2000 3/19/2005

Alamat Jl.Begundul Jl.SBY

Telpon 081253627268 02137657957

Umur

Instansi Adiguna, RSB Adiguna, RSB

Tabel 4.14 Tabel Uji Coba Halaman Data Pasien Baru

No Tujuan Input Output Output Sistem

13. Menyimpan Data Pasien Baru

Memasukkan Data 1 seperti pada tabel 4.9

Muncul pesan “Umur Belum Diisi“

1. Sukses

2. Muncul pesan “Umur Belum Diisi“

14. Menyimpan Data Pasien Baru

Memasukkan Data 2 seperti pada tabel 4.9

Semua field pada

pengisian data pasien baru menjadi kembali belum terisi

1. Sukses,

2. Semua field pada pengisian data pasien baru menjadi kembali belum terisi

111

Untuk uji coba No.13 pada Tabel 4.14, hasilnya dapat dilihat pada Gambar 4.22 dan Gambar 4.23 yang menunjukkan pengisian data sebelum di eksekusi tombol simpan dan setelahnya.

Gambar 4.22 Pengisian data pasien baru secara tidak benar

Untuk uji coba No.14 pada Tabel 4.14, hasilnya dapat dilihat pada Gambar 4.24 dan Gambar 4.25 yang menunjukkan pengisian data sebelum di eksekusi tombol simpan dan setelahnya.

Gambar 4.24 Pengisian data pasien baru secara benar

Gambar 4.25 Field yang kembali menjadi kosong setelah pengisian data pasien baru secara benar

113

4.1.2 Analisis Hasil Uji Coba

Analisis hasil uji coba terdiri dari analisis hasil uji coba untuk fitur dasar sistem dan analisis hasil uji coba untuk proses pengolahan data administrasi rawat jalan. Analisis hasil uji coba tersebut dapat dijelaskan sebagai berikut:

1. Analisis Hasil Uji coba Fitur Dasar Sistem

Analisis hasil uji coba dari keseluruhan uji coba yang dilakukan akan menentukan kelayakan dari fitur dasar sistem berdasarkan desain yang telah dibuat. Fitur-fitur dasar sistem disebut layak apabila output yang diberikan oleh sistem sesuai dengan output yang diharapkan. Berdasarkan hasil uji coba dari No.1 sampai dengan No.6 dapat disimpulkan bahwa fitur-fitur dasar tersebut telah berjalan dengan baik dan tidak terdapat error.

2. Analisis Hasil Uji Coba Proses Pengolahan Data Administrasi Rawat Jalan Analisis hasil uji coba status dilakukan untuk menguji kinerja sistem dalam menentukan kelayakan aplikasi berdasarkan desain yang telah ditetapkan. Sebuah proses dapat dinilai layak apabila keseluruhan hasil uji coba sesuai dengan output yang diharapkan.Berdasarkan hasil ujicoba No.1 sampai dengan No.6 yang sudah dilakukan, output proses pengolahan data administrasi rawat jalan sudah sesuai dengan yang diharapkan.

114

5.1 Kesimpulan

Berdasarkan hasil uji coba dan evaluasi yang dilakukan pada bab 4 maka dapat diperoleh kesimpulan sebagai berikut:

1. Aplikasi mampu merekam dan menyimpan data rekam medik pasien yang diinputkan oleh dokter sehingga klinik memiliki backup terhadap data rekam medik mereka.

2. Aplikasi dapat membuat user dokter, kasir/perawat, admin dan manajer yang memiliki hak aksesnya masing-masing.

3. Aplikasi antar user dapat berkomunikasi dangan baik melalui komputer server sebagai jembatannya sehingga setiap user dapat melihat, mengedit dan mengolah data, sesuai dengan hak akses masing-masing data yang telah di input oleh user lain dan diolah oleh aplikasi.

5.2 Saran

Adapun saran yang dapat diberikan pada penelitian ini adalah sebagai berikut:

1. Dapat ditambahkan fitur pembuatan laporan penggolongan penyakit berdasar daerah pasien sehingga bisa dapat segera diketahui arah sumber dan perkembangan sebuah penyakit menular.

2. Dapat ditambahkan fitur untuk pembuatan janji dengan dokter karena tidak jarang pasien ingin membuat janji terlebih dahulu dengan dokter sehingga dia tidak akan menggu terlalu lama setibanya dia di klinik.

115

DAFTAR PUSTAKA

Chaffey, Dave. 1963. Groupware, Workflow and intranets: reengineering the enterprise with collaborative Software. Amerika Serikat: Digital Press Dewi, Irra Chrisyanti. 2011. Pengantar Ilmu Administrasi, PT Prestasi

Pustakaraya. Jakarta.

Jogiyanto. 2003. Analisis dan Desain Sistem Informasi. Yogyakarta: ANDI. Jogiyanto. 2005. Analisis dan Desain Sistem Informasi. Yogyakarta: ANDI. Kristanto, Andri. 2004. Perancangan Sistem Informasi. Yogyakarta: Gaya Media. Mcleod, Raymond dan Schell. 2007. Sistem Informasi Manajemen. Edisi 9.

Jakarta: PT Index.

Marsuli dkk. 2005. Mutu Pelayanan Pasien Peserta Askes dan Umum di Instalasi Rawat Jalan Rumah Sakit Umum Daerah Dr. M. Yunus Propinsi Bengkulu. Jurnal Manajemen Pelayanan Kesehatan, 8 (1).

Permenkes Nomor 269 Tahun 2008, Tentang Rekam Medis diunduh pada 1 Desember 2015 jam 09:46.

Permenkes Nomor 749 Tahun 1989, Tentang Rekam Medis diunduh pada 1 Desember 2015 jam 10.15.

Permenkes Nomor 028 Tahun 2011, Tentang Klinik diunduh pada 1 Desember 2015 jam 10.50.

Rosmala, Dewi., Falahah (2007), “Pemodelan Proses Bisnis B2B dengan BPMN (Studi Kasus Pengadaan Barang Pada Divisi Logistik)”, Seminar Nasional Aplikasi Teknologi Informasi 2007.

Romeo. 2003. Testing dan Implementasi Sistem. STIKOM. Surabaya.

Surat Keputusan Direktorat Jenderal Pelayanan medis Nomor 78 Tahun 1991, Tentang Penyelenggaraan Rekam Medis di Rumah Sakit, diunduh pada 4 Desember 2015 jam 08:46.