Sistem informasi praktek dokter umum studi kasus : klinik dokter di Barepan, Cawas, Klaten.

(1)

ABSTRAK

Dalam Pasal 26 Undang-Undang Republik Indonesia Nomor 29 tahun 2004 yang mengatur tentang Praktik Kedokteran disebutkan bahwa setiap dokter atau dokter gigi dalam menjalankan praktik wajib membuat rekam medis. Dalam pencatatan rekam medis di klinik dokter Hapsari masih dilakukan secara manual. Hal ini menimbulkan masalah baru ketika dokter ingin mencari data rekam medis. Pencatatan stok dicatat secara teratur agar dokter segera mengetahui stok obat mana yang persediannya menipis, sehingga tidak terjadi kekosongan obat. Selain itu, pencatatan pemasukan dokter juga perlu dicatat dengan baik, sehingga dokter dapat mengetahui pemasukan setiap bulannya. Oleh karena itu, dibangun Sistem Informasi Praktek Dokter Umum yang diharapkan dapat membantu proses pengegelolaan data-data di klinik dokter Hapsari.

Sistem ini dibangun dengan menggunakan bahasa PHP dan DBMS mySQL. Untuk pencatatan data keluar masuk obat menggunakan konsep manajemen transaksi dengan teknik Two Phase Locking (2PL) untuk menjamin konsistensi data terhadap masalah lost update problem. Adapun metode pengembangan perangkat lunak dengan menggunakan metode FAST (Framework for the Application of System Technique).

(2)

ABSTRACK

In 26 statute no 29 2004 of Indonesia Republic which about doctor practice explain that every doctor or dentist is an practice must have the medical records. In Hapsari clinic’s, the register medical records are still done manually. As as consequence, the doctor feel difficult to find the medical records. Stock of medicine must be registered clearly, so the doctor know that the medicine is measly and never the medicine is stockout. The income of doctor should be reported clearly too, in order to the doctor know her income every month. Because of that, general doctor information system is created to help clinic’s data management process.

This system was built by PHP’s language and DBMS MySQL. For register in data and out data uses management transaction concept with Two Phase Locking (2PL) to guarantee that data is consistent toward the lost update problem. The software developing method uses FAST (Framework for the Application of System Technique) Method.

The result is an general doctor information system with abilty to serve the

report of medical record’s, incomes and stock of medicine. This system has a capability to solve the lost problem of transaction simultaneously in a purchasing and registering prescription proces. After the system was tested by administration staff, assistant of doctor and the doctor, this system show that it can help and faster in

(3)

SISTEM INFORMASI PRAKTEK DOKTER UMUM

STUDI KASUS : KLINIK DOKTER DI BAREPAN, CAWAS, KLATEN

SKRIPSI

Ditujukan untuk Memenuhi Salah Satu Syarat Memperoleh Gelar Sarjana

Program Studi Teknik Informatika

Oleh : SEPEN MULYANI

NIM : 105314091

PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI

UNVERSITAS SANATA DHARMA YOGYAKARTA

(4)

i

GENERAL DOCTOR INFORMATION SYSTEM

CASE STUDY AT DOCTOR CLINIC IN BAREPAN, CAWAS, KLATEN

THESIS

Presented as Partial Fullfilment of the Requirements To Obtain the Computer Bachelor Degree

In Informatics Engineering

By :

SEPEN MULYANI NIM : 105314091

INFORMATION TECHNOLOGY DEPARTMENT FACULTY SCIENCE AND TECHNOLOGY

SANATA DHARMA UNIVERSITY YOGYAKARTA

(5)

ii

HALAMAN PERSETUJUAN

SKRIPSI

SISTEM INFORMASI PRAKTEK DOKTER UMUM

STUDI KASUS : KLINIK DOKTER DI BAREPAN, CAWAS, KLATEN

Oleh:

Sepen Mulyani

NIM : 105314091 Telah disetujui oleh:

Pembimbing

(6)

iii

HALAMAN PENGESAHAN

SKRIPSI

SISTEM INFORMASI PRAKTEK DOKTER UMUM

STUDI KASUS : KLINIK DOKTER DI BAREPAN, CAWAS, KLATEN

Dipersiapkan dan disusun oleh: Sepen Mulyani

NIM : 105314091

Telah dipertahankan di depan Panitia Penguji pada tanggal 24 Agustus 2015

dan dinyatakan memenuhi syarat

Susunan Panitia Penguji

Nama Lengkap Tanda Tangan

Ketua JB. Budi Darmawan, S.T., M.Sc. ……….

Sekretaris Alb. Agung Hadhiatma, S.T., M.T. ……….

Anggota A.M Polina S.Kom., M.Sc. ……….

Yogyakarta,

Fakultas Sains dan Teknologi Universitas Sanata Dharma

Dekan,

(7)

iv

PERNYATAAN KEASLIAN KARYA

Penulis menyatakan dengan sesungguhnya bahwa skripsi yang ditulis ini tidak memuat karya atau sebagian karya orang lain, kecuali yang telah disebutkan dalam kutipan dan daftar pustaka, sebagaimana layaknya sebuah karya ilmiah

Yogyakarta,

Penulis

(8)

v

PERNYATAAN PERSETUJUAN PUBLIKASI KARYA UNTUK KEPENTINGAN AKADEMISI

Yang bertandatangan dibawah ini, saya mahasiswa Universitas Sanata Dharma :

Nama : Sepen Mulyani

NIM : 105314091

Demi pengembangan ilmu pengetahuan, saya memberikan kepada perpustakaan Universitas Sanata Dharma karya ilmiah saya yang berjudul:

“Sistem Informasi Praktek Dokter Umum

Studi kasus : Klinik Dokter di Barepan, Cawas, Klaten”

bersama perangkat yang diperlukan (bila ada). Dengan demikian saya memberikan kepada perpustakaan Universitas Sanata Dharma hak untuk menyimpan, mengalihkan dalam bentuk lain, mengelolanya dalam bentuk pangkalan data, mendistribusikannya secara terbatas, dan mempublikasikannya di internet atau media lain untuk kepentingan akademis tanpa perlu memberikan royalti kepada saya selama tetap mencantumkan saya sebagai penulis.

Demikian pernyataan ini saya buat dengan sebenarnya.

Yogyakarta, Penulis

(9)

vi

ABSTRAK

Dalam Pasal 26 Undang-Undang Republik Indonesia Nomor 29 tahun 2004 yang mengatur tentang Praktik Kedokteran disebutkan bahwa setiap dokter atau dokter gigi dalam menjalankan praktik wajib membuat rekam medis. Dalam pencatatan rekam medis di klinik dokter Hapsari masih dilakukan secara manual. Hal ini menimbulkan masalah baru ketika dokter ingin mencari data rekam medis. Pencatatan stok dicatat secara teratur agar dokter segera mengetahui stok obat mana yang persediannya menipis, sehingga tidak terjadi kekosongan obat. Selain itu, pencatatan pemasukan dokter juga perlu dicatat dengan baik, sehingga dokter dapat mengetahui pemasukan setiap bulannya. Oleh karena itu, dibangun Sistem Informasi Praktek Dokter Umum yang diharapkan dapat membantu proses pengegelolaan data-data di klinik dokter Hapsari.

Sistem ini dibangun dengan menggunakan bahasa PHP dan DBMS mySQL. Untuk pencatatan data keluar masuk obat menggunakan konsep manajemen transaksi dengan teknik Two Phase Locking (2PL) untuk menjamin konsistensi data terhadap masalah lost update problem. Adapun metode pengembangan perangkat lunak dengan menggunakan metode FAST (Framework for the Application of System Technique).

(10)

vii

ABSTRACK

In 26 statute no 29 2004 of Indonesia Republic which about doctor practice explain that every doctor or dentist is an practice must have the medical records. In Hapsari clinic’s, the register medical records are still done manually. As as consequence, the doctor feel difficult to find the medical records. Stock of medicine must be registered clearly, so the doctor know that the medicine is measly and never the medicine is stockout. The income of doctor should be reported clearly too, in order to the doctor know her income every month. Because of that, general doctor information system is created to help clinic’s data management process.

This system was built by PHP’s language and DBMS MySQL. For register in data and out data uses management transaction concept with Two Phase Locking (2PL) to guarantee that data is consistent toward the lost update problem. The software developing method uses FAST (Framework for the Application of System Technique) Method.

The result is an general doctor information system with abilty to serve the

(11)

viii

KATA PENGANTAR

Puji syukur dipanjatkan kehadirat Allah SWT atas berkat dan rachmat-Nya sehingga penulis dapat menyelesaikan skripsi ini. Penulisan skripsi ini bertujuan untuk memenuhi salah satu syarat untuk memperoleh gelar sarjana pada program studi Teknik Informatika, Fakultas Sains dan Teknologi, Universitas Sanata Dharma.

Dalam menyelesaikan skripsi ini penulis mendapat bantuan, bimbingan dan arahan serta dukungan dari berbagai pihak. Oleh karena itu, penulis mengucapkan terimakasih yang tak terhingga kepada :

1. Bapak dan Ibuk saya, Bapak Sunarto Wiyono dan Ibu Lagiyem yang telah melahirkan, merawat dan membesarkan saya, dan juga telah memberikan dulungan moral, spiritual maupun finansial di dalam penyusunan skripsi ini.

2. Keluarga besar saya terutama mas Agung Sawitri yang telah memberikan dukungan spiritual dan finalsial dalam penyusuan skripsi ini.

3. Ibu P.H. Prima Rosa, S.Si., M.Sc. selaku Dekan Fakultas Sains dan Teknologi Universitas Sanata Dharma.

4. Ibu Dr. Anastasia Rita Widarti, M.Kom selaku Ketua Jurusan Teknik Informastika Universitas Sanata Dharma.

5. Ibu A.M. Polina, S.Kom, M.Sc., selaku Dosen Pembimbing yang telah banyak membantu serta membimbing dengan baik kepada penulis dalam menyelesaikan skripsi ini.

6. Bapak JB. Budi Darmawan, S.T., M.Sc. dan Alb. Agung Hadhiatma, S.T., M.T. selaku penguji.

7. Dokter Hapsari yang telah memberikan kepada saya kesempatan melakukan studi kasus di klinik dokter umum di dalam penulisan skripsi ini.

(12)

ix

9. Sahabat-sahabat terbaik Teknik Informatika di Universitas Sanata Dharma: Venti, Nofi, Amel, Andhini, Ria, Maria, Reni, Stella, Vita, Karl, Edo, Fave, Doni dan semua teman-teman TI lainnya yang telah memberikan saya semangat, support, candaan dan tawa kalian.

10.Teman-teman Forum Keluarga Muslim Universitas Sanata Dharma dan juga semua teman Unit Kegiatan Mahasiswa Karawitan atas dukungan dan kebersamaannya selama ini.

11.Teman-teman kost Amada atas dukungan dan kebersamaannya selama ini.

12.Semua pihak yang tidak dapat disebutkan satu per satu

Akhir kata, penulis menyadari bahwa skripsi ini masih banyak kekurangan, oleh karena itu penulis mengharapkan kritik dan saran. Semoga skripsi ini dapat bermanfaat bagi pembaca.

(13)

x DAFTAR ISI

HALAMAN JUDUL ... i

HALAMAN PERSETUJUAN ... ii

HALAMAN PENGESAHAN ... iii

PERNYATAAN KEASLIAN KARYA ... iv

PERNYATAAN PERSETUJUAN PUBLIKASI KARYA ... v

ABSTRAK ... vi

ABSTRACK ... vii

KATA PENGANTAR ... viii

DAFTAR ISI ... x

DAFTAR GAMBAR ... xiii

DAFTAR TABEL ... xix

BAB I PENDAHULUAN ... 1

1.1 Latar Belakang ... 1

1.2 Rumusan Masalah ... 2

1.3 Batasan Masalah... 3

1.4 Tujuan dan Manfaat Penelitian ... 3

1.5 Metodologi Penelitian ... 4

1.6 Sistematika Penulisa ... 5

BAB II LANDASAN TEORI ... 7

2.1 Sistem Informasi ... 7

2.1.1 Kualitas Informasi ... 7

2.2 Rekam Medis ... 8

2.2.1 Pengertian Rekam Medis ... 8

2.2.2 Isi Rekam Medis ... 8

2.2.3 Manfaat Rekam Medis ... 9

2.3 SQL (Structured Query Language) ... 10

2.4 DFD (Data Flow Diagram) ... 11

2.6 Metode Perancangan Basis Data ... 14

(14)

xi

2.8 Manajemen Transaksi ... 15

2.8.1 Locking Methods ( Metode-metode Penguncian ) ... 17

2.8.2 Two Phase Locking ( 2PL ) ... 18

2.9 Metedologi FAST (Framework for the Application of system Technique)19 BAB III ANALISA DAN PERANCANGAN SISTEM ... 21

3.1 Analisa Sistem ... 21

3.1.1 Gambaran Umum Sistem Lama ... 21

3.1.2 Gambaran Umum Sistem Baru ... 22

3.1.3 Use Case Diagram ... 22

3.1.4 Pemodelan Proses ( Data Flow Diagram ) ... 23

3.1.5 Pemodelan Data ... 31

3.2 Desain Sistem ... 33

3.2.1 Desain Basis Data ... 33

3.2.2 Desain Fisikal Basis Data ... 35

3.3 Daftar Stored Procedure. ... 39

3.4 Desain Manajemen Transaksi ... 40

3.5 Desain Antarmuka ... 43

3.5.1 Halaman Login ... 43

3.5.2 Staff Administrasi ... 43

3.5.3 Asisten Dokter ... 45

3.5.4 Dokter ... 50

3.5.5 Admin ... 57

BAB IV IMPLEMENTASI SISTEM ... 64

4.1 Struktur Menu Sistem ... 64

4.2 Tampilan Program dan Penjelasan ... 66

4.2.1 Koneksi Database ... 66

4.2.2 Halaman Login ... 66

4.2.3 Staff Administrai ... 68

4.2.4 Asisten Dokter ... 72

4.2.5 Dokter ... 83

(15)

xii

4.3 Implementasi Manajemen Transaksi... 104

BAB V ANALISA HASIL ... 112

5.1 Analisa Hasil Perangkat Lunak ... 112

5.1.1 Kelebihan dan Kekurangan Sistem ... 112

5.2 Analisa Hasil Uji Coba Sistem Terhadap Pengguna ... 113

5.2.1 Sasaran Penyebaran Kuisioner ... 113

5.2.2 Hasil dan Pembahasan... 113

5.3 Pengujian Manajemen Transaksi ... 121

BAB VI PENUTUP ... 129

6.1 Kesimpulan ... 129

6.2 Saran ... 130

DAFTAR PUSTAKA ... 131

(16)

xiii

DAFTAR GAMBAR

Gambar 3 1. Use Case Diagram ... 23

Gambar 3.2. Diagram Konteks... 24

Gambar 3.3. Diagram Berjenjang ... 25

Gambar 3.4. Overview Diagram ... 26

Gambar 3.14. Conseptual Design Database (ER Diagram). ... 32

Gambar 3.15. Desain Logikal Basis Data ... 34

Gambar 3.16. Flowchart untuk Stored Procedure Pembelian ... 41

Gambar 3.17. Flowchart untuk Stored Procedure Resep Obat ... 42

Gambar 3.18. Desain Antarmuka Halaman Login ... 43

Gambar 3.19. Desain Antarmuka Halaman Tambah Data Pasien ... 43

Gambar 3.20. Desain Antarmuka Halaman Ubah Data Pasien ... 44

Gambar 3.21. Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Pasien .. 44

Gambar 3.22. Desin Antarmuka Halaman Tambah Data Antrian ... 44

Gambar 3.23. Desain Antarmuka Halaman Lihat data Antrian ... 45

Gambar 3.24. Desain Antarmuka Halaman Lihat Data Antrian ... 45

Gambar 3. 25. Desain Antarmuka Halaman Tambah Data Antrian ... 45

Gambar 3.26. Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Pemeriksaan ... 46

Gambar 3.27. Desain Antarmuka Halaman Ubah Data Pemeriksaan ... 46

(17)

xiv

Gambar 3.29. Desain Antarmuka Halaman Tambah Data Obat ... 47

Gambar 3.30. Desain Antarmuka Halaman Ubah Data Obat ... 47

Gambar 3.31. Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Pembelian Obat ... 47

Gambar 3.32. Desain Antarmuka Halaman Tambah Data Pembelian Obat ... 48

Gambar 3.33. Desain Antarmuka Halaman Desain Ubah Data Pembelian ... 48

Gambar 3.34. Desain Antarmuka Halaman Lihat, Cari Data Pengambilan Obat . 49 Gambar 3.35. Desain Antarmuka Cetak Pengambilan Obat ... 49

Gambar 3.36. Desain Antarmuka Halaman Cetak Laporan Pemasukan ... 50

Gambar 3.37. Desain Antarmuka Halaman Lihat Data Antrian ... 50

Gambar 3.38. Desain Antarmuka Halaman Tambah Data Pemeriksaan ... 51

Gambar 3.39. Desain Antarmuka Halaman Ubah Data Pemeriksaan ... 51

Gambar 3.40. Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Pemeriksaan ... 52

Gambar 3.41. Desain Antarmuka Halaman Lihat Data Pemberian Resep Obat ... 52

Gambar 3.42. Desain Antarmuka Halaman Tambah Data Resep Obat ... 53

Gambar 3.43. Desain Antarmuka Halaman Tambah Data Biaya Obat ... 53

Gambar 3.44. Desain Antarmuka Halaman Lihat antrian Data Pemberian Resep Obat Dalam ... 54

Gambar 3.45. Desain Antarmuka Tambah Data Pemberian Resep Obat Dalam .. 54

Gambar 3.46. Desain Antarmuka Halaman Cetak Pemberian Resep Obat Luar .. 55

Gambar 3.47. Desain Antarmuka Halaman Lihat dan Cari Data Obat ... 55

Gambar 3.48. Desain Antarmuka Halaman Lihat dan Cari Laporan Data Rekam

Gambar 3.51. Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Pengguna ... 57

(18)

xv

Gambar 3.53. Desain Antarmuka Halaman Ubah Data Pengguna ... 58

Gambar 3.54. Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Kategori59 Gambar 3.55. Desain Antarmuka Halaman Tambah Data Kategori ... 59

Gambar 3.56. Desain Antarmuka Halaman Ubah Data Kategori ... 60

Gambar 3.57. Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Satuan.. 60

Gambar 3.58. Desain Antarmuka Halaman Tambah Data Satuan ... 61

Gambar 3.59. Desain Antarmuka Halaman Ubah Data Satuan ... 61

Gambar 3.60. Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Apotik . 62 Gambar 3.61. Desain Antarmuka Halaman Tambah Data Apotik... 62

Gambar 3.62. Desain Antarmuka Halaman Ubah Data Apotik ... 63

Gambar 4.1. Struktur Menu Sistem... 64

Gambar 4.2. Lanjutan Struktur Menu Sistem ... 65

Gambar 4 .3. Implementasi Halaman Login ... 66

Gambar 4.4. Implementasi Halaman Tambah Data Pasien... 68

Gambar 4.5. Implementasi Halaman Ubah Data Pasien ... 69

Gambar 4.6. Implemnetasi Halaman Lihat, Cari dan Hapus Data Pasien ... 70

Gambar 4.7. Implementasi Halaman Tambah Data Antrian ... 71

Gambar 4.8. Implementasi Halaman Lihat Data Antrian ... 71

Gambar 4.10. Implementasi Halaman Tambah Data Pemeriksaan ... 73

Gambar 4.11. Implementasi Halaman Lihat, Cari dan Hapus Data Pemeriksaan 74 Gambar 4.12. Implementasi Halaman Ubah Data Pemeriksaan ... 75

Gambar 4.13. Implementasi Halaman Lihat, Cari dan Hapus Data Obat ... 76

Gambar 4.14. Implementasi Halaman Tambah Data Obat ... 77

(19)

xvi

Gambar 4.16. Implementasi Halaman Lihat, Cari dan Hapus Data Pemebelian .. 78

Gambar 4.17. Implementasi Halaman Tambah Data Obat ... 79

Gambar 4.18. Implementasi Halaman Ubah Data Pembelian Obat ... 79

Gambar 4.19. Implementasi Halaman Lihat dan Cari Data Pengambilan Obat ... 80

Gambar 4.20. Implementasi Halaman Cetak Pengambilan Obat ... 81

Gambar 4.21. Implementasi Halaman Cetak Laporan Pemasukan ... 82

Gambar 4.23. Implementasi Halaman Tambah Data Pemeriksaan ... 84

Gambar 4.24. Implementasi Halaman Ubah Data Pemeriksaan ... 85

Gambar 4.25. Implementasi Halaman Lihat, Cari dan Hapus Data Pemeriksaan 86 Gambar 4.26. Implementasi Halaman Lihat Antrian Data Pemberian Resep Obat ... 87

Gambar 4.27. Implementasi Halaman Tambah Data Resep Obat ... 88

Gambar 4.28. Implementasi Halaman Tambah Data Biaya Obat ... 89

Gambar 4.29. Implentasi Halaman Lihat Antrian Data Pemberian Resep Obat Luar ... 89

Gambar 4.30. Implementasi Halaman Tambah Data Pemberian Resep Obat Luar ... 90

Gambar 4.31. Implementasi Halaman Cetak Pemberisan Resep Obat Luar ... 91

Gambar 4.32. Implementasi Halaman Lihat dan Cari Data Obat ... 92

Gambar 4.33. Implementasi Halaman Lihat dan Cari Laporan Data Rekam Medis Per Pasien ... 93

(20)

xvii

Gambar 4.36. Implementasi Halaman Lihat, Cari dan Hapus Data Pengguna ... 96

Gambar 4.37. Implementasi Halaman Tambah Data Pengguna ... 97

Gambar 4.38. Implementasi Halaman Ubah Data Pengguna ... 97

Gambar 4.39. Implementasi Halaman Lihat, Cari dan Hapus Data Kategori ... 98

Gambar 4.40. Implementasi Halaman Tambah Data Kategori ... 99

Gambar 4.41. Implementasi Halaman Ubah Data Kategori ... 99

Gambar 4.42. Implementasi Halaman Lihat, Cari dan Hapus Data Satuan ... 100

Gambar 4.43. Implementasi Halaman Tambah Data Satuan ... 101

Gambar 4.44. Implementasi Halaman Ubah Data Satuan ... 101

Gambar 4.45. Implementasi Halaman Lihat, Cari dan Hapus Data Apotik ... 102

Gambar 4.46. Implementasi Halaman Tambah Data Apotik ... 103

Gambar 4.47. Implementasi Halaman Ubah Data Apotik. ... 103

Gambar 4.48. Stored Procedure Pembelian Obat ... 106

Gambar 4.49. Stored Procedure Tambah Resep Obat... 110

Gambar 5.1. Grafik Kuisioner Pernyataan 1 ... 114

Gambar 5.3. Gfafik Kuisioner Pernyataan 3 ... 115

Gambar 5.10. Hasil Pencarian Data Obat Antasidan. ... 121

(21)

xviii

Gambar 5 .12. Halaman Penambahan Resep Obat Yang Dilakukan Oleh User 2

(Dokter) ... 122

Gambar 5.13. Transaksi berjalan bersamaan karena delay ... 123

Gambar 5.14. Halaman Pembelian Obat Oleh User 1 (Asisten Dokter) ... 124

Gambar 5.15. Halaman Penambahan Resep Obat Oleh User 2 (Dokter) ... 124

Gambar 5.16. Halaman Stok Obat Antasida setelah dilakukan pencatatan Pembelian Obat dan Penambahan Resep Obat Secara Bersamaan Oleh User 1 (Asisten Dokter) dan User 2 (Dokter). ... 124

Gambar 5.17. Hasil Pencarian Data Obat Ethambutol ... 125

Gambar 5.18. Halaman Penambahan Data Pembelian Obat Yang Dilakukan Oleh User 1 (Asisten Dokter). ... 125

Gambar 5 19. Halaman Penambahan Resep Obat Yang Dilakukan Oleh User 2 (Dokter) ... 126

Gambar 5.20. Transaksi berjalan bersamaan karena delay ... 126

Gambar 5.21.Halaman Penambahan Resep Obat Oleh User 2 (Dokter) ... 127

Gambar 5.22. Halaman Penambahan Resep Obat Oleh User 2 (Dokter) ... 127

(22)

xix

DAFTAR TABEL

Tabel 2 .1. Notasi DFD ... 13 Tabel 2 .2. Notasi Use Case ... 14 Tabel 3 .1. Desain Fisikal untuk Tabel Apotik...35 Tabel 3.2 . Desain Fisikal untuk Tabel Kategori ... 35 Tabel 3. 3. Desain Fisikal untuk Tabel Obat ... 35 Tabel 3 .4. Desain Fisikal untuk Tabel Pasien ... 36 Tabel 3. 5. Desain Fisikal untuk Tabel Pembelian... 36 Tabel 3 .6. Desain Fisikal Tabel Obat ... 37 Tabel 3 .7. Desain Fisikal untuk Tabel Pengguna ... 37 Tabel 3 .8. Desain Fisikal untuk Tabel Rekam Medis ... 38 Tabel 3. 9. Desain Fisikal untuk Tabel Resep Obat ... 38 Tabel 3 .10. Desain Fisikal untuk Tabel Resep Obat Luar ... 38 Tabel 3 .11. Desain Fisikal untuk Tabel Satuan... 39 Tabel 3. 12. Desain Fisikal untuk Tabel Uraian Resep Obat ... 39 Tabel 3 .13. Daftar Stored Procedure ... 40

Tabel 4 .1. Skenario Manajemen Transaksi 2 Pembelian Obat ... 105 Tabel 4 .2. Skenario Manajemen Transaksi 2 Resep Obat. ... 108 Tabel 4.3. Skenario Manajemen Transaksi Pembelian dan Resep Obat ... 111

(23)

(24)

BAB I

PENDAHULUAN

1.1 Latar Belakang

Sistem informasi pada saat ini sudah menjadi bagian penting dalam kehidupan. Dengan adanya sistem informasi dapat diketahui apa yang terjadi sekarang dan memberi gambaran apa yang akan terjadi di waktu yang akan datang. Banyak sekali sistem informasi yang sangat berguna bagi kehidupan, salah satunya adalah sistem informasi praktek dokter umum.

Pada pasal 46 Undang-Undang Republik Indonesia Nomor 29 tahun 2004 yang mengatur tentang Praktik Kedokteran, disebutkan bahwa :

(1) Setiap dokter atau dokter gigi dalam menjalankan praktik kedokteran wajib membuat rekam medis.

(2) Rekam medis sebagaimana dimaksud pada ayat (1) harus segera dilengkapi setelah pasien selesai menerima pelayanan kesehatan.

(3) Setiap catatan rekam medis harus dibubuhi nama, waktu, dan tanda tangan petugas yang memberikan pelayanan atau tindakan.

Dengan adanya Undang-Undang tersebut seorang dokter harus mempunyai rekam medis. Rekam medis sebenarnya tidak hanya digunakan oleh seorang dokter, tetapi hasil dari rekam medis juga merupakan hak pasien seperti dijelaskan pada pasal 52 tentang hak dan kewajiban pasien, pada bagian (e) dijelaskan bahwa seorang pasien berhak mendapat isi rekam medis

(25)

2

dokter sangatlah penting. Data pasien harus diarsipkan agar pasien yang sudah berobat dan datang kembali dapat mengetahui riwayat berobat dan penyakit, sehingga menghasilkan laporan yang akurat untuk tindakan medis yang tepat.

Untuk pencatatan stok obat, di klinik dokter Happy tidak dicatat secara teratur. Untuk mengetahui stok obat biasanya melihat apakah stok obat masih ada atau tidak, jika stok obat tinggal sedikit maka dokter atau asisten dokter akan menulis di buku yang telah disediakan. Pencatatan manual menjadi masalah besar jika dokter atau asisten dokter lupa mencatat apakah obat sudah habis atau stok tinggal sedikit. Stok obat harus dicatat rapi agar dokter segera mengetahui obat mana yang persediannya menipis, sehingga tidak terjadi kekosongan obat.

Selain rekam medis yang penting, pencatatan pemasukan dokter juga perlu dicatat dengan baik, sehingga dokter dapat mengetahui kalkulasi pemasukan setiap bulannya. Akan tetapi terkadang seorang dokter tidak memperhatikan pencatatan tersebut, sehingga pencatatan pemasukan tidak tercatat dengan baik.

Dari latar belakang tersebut, penulis tertarik untuk membangun Sistem Informasi Praktek Dokter Umum, yang dapat membantu proses pengelolaan data pasien serta mempermudah dokter dalam melakukan monitoring terhadap pasien. Diharapkan dokter lebih mudah memberikan keputusan tentang penyakit atau tindakan yang tepat untuk pasien berdasarkan riwayat penyakit dari pasien, membuat laporan jumlah stok obat. Selain itu juga memberikan laporan keuangan yang diperoleh dokter dalam waktu tertentu.

1.2 Rumusan Masalah

Berdasarkan latar belakang diatas, rumusan masalah pada penelitian ini adalah :

(26)

3

mengolah data pasien, data pemeriksaan, data obat, data resep obat dan data pemasukan yang sesuai dengan kebutuhan dr. Hapsari.

2. Apakah sistem informasi ini efektif (tepat guna) dapat membantu pihak dokter, asisten dokter dan staff administrasi dalam mengelola data pasien, data pemeriksaan, data obat, data resep obat dan data pemasukan dokter. 3. Apakah sistem ini mudah digunakan dan mudah dipahami oleh pengguna

(dokter, asisten dokter dan staff administrasi ).

1.3 Batasan Masalah

Batasan masalah dari penelitian ini adalah :

1. Rekam medis pasien dalam kasus ini meliputi : rekam data pasien, rekam keluhan pasien, rekam hasil pemeriksaan, rekam diagnosa, rekam pemberian obat.

2. Transaksi pembayaran pemeriksaan pasien, meliputi biaya pemeriksaan dan obat.

3. Laporan keuangan meliputi pemasukan dari pembayaran pasien saat berobat. 4. Implementasi menggunakan bahasa pemograman PHP dengan database

MySQL.

5. Studi kasus di klinik dr. Hapsari

1.4 Tujuan dan Manfaat Penelitian

Tujuan dari penelitian ini adalah sebagai berikut :

Membangun Sistem Informasi Praktek Dokter Umum yang dapat membantu dokter umum untuk menyimpan dan memproses data rekam medis maupun data administrasi.

Manfaat dari penelitian ini adalah sebagai berikut :

(27)

4

2. Membantu dokter dalam memonitoring dan mengambil keputusan bagi pasien.

3. Membantu dokter untuk mengetahui stok obat.

4. Membantu dokter untuk mengetahui pemasukan setiap bulannya. 5. Membantu staf administrasi untuk membuat laporan keuangan.

6. Sebagai masukan dalam pengembangan dan penelitian lebih lanjut mengenai Sistem Informasi Praktek Dokter Umum.

1.5 Metodologi Penelitian

Metode penelitian yang dilakukan untuk menyelesaikan masalah pada tugas akhir ini adalah studi kasus dengan langkah-langkah sebagai berikut :

1. Survei awal untuk mengetahui permasalahan yang dihadapi klinik dokter dr. Hapsari. Melakukan survey awal ke klinik dokter umum.

a. Mengamati secara garis besar proses ketika seorang pasien berobat, pencatatan data pasien, pencatatan pemeriksaan, pencatatan stok obat dan pencatatan pemasukan.

b. Interview dengan dokter, asisten dokter dan staff administrasi tentang informasi apa yang perlu disimpan.

2. Pengembangan sistem informasi menggunakan metode FAST (Framework for the Application of System Technique) menurut Whiten, et al, 2004, yang fasenya meliputi:

a. Analisa sistem.

1. Scope definition (Defisi Lingkup)

Hal yang dilakukan pada tahap ini adalah mendefisinikan ruang lingkup dengan cara melakukan pengamatan dan wawaancara kepada dokter, asisten dokter dan staff administrasi mengenai pengolahan data-data yang ada dan permasalahan yang dihadapai untuk menentukan ruang lingkup masalah.

2. Problem analysis (Analisa Permasalahan).

(28)

5

3. Requirement analysis (Analisa Kebutuhan).

Hal yang dilakukan pada tahan ini adalah mengidentifikasi kebutuhan sistem, dengan cara mengumpulkan data kebutuhan yang kemudian dimodelkan dalam diagram use case.

b. Desain sistem

Pada tahap ini dilakukan desain basis data dan desain teknologi untuk sistem informasi ini.

1. Logical Design.

Menggambarkan logical data model, logical proses dan logical interface model.

2. Decision Analysis.

Dalam tahan ini dilakukan implementasi sistem ke dalam bentuk bahasa pemograman PHP dan MySQL sebagai pengelola database. Perangkat keras yang digunakan dalam implementasi adalah laptop atau computer desktop.

3. Physical Design and Integration.

Implementasi secara teknik dengan membuat physical database design dan physical user interface.

4. Contruction and Testing.

Implementasi rancangan ke dalam program menggunakan PHP dan MySQL sebagai pengelola basisdatanya. Pada tahap ini juga

dilakukan uji coba terhadap sistem melalui α test.

3. Uji coba sistem praktik dokter umum untuk mengetahui sejauhmana dapat membantu dan mudah digunakan oleh pihak dokter, asisten dokter dan staff administrasi dalam mengolah data pasien, data pemeriksaan, data obat, data resep obat dan data pemasukan.

1.6 Sistematika Penulisa

Sistematika penulisan laporan tugas akhir ini adalah sebagai berikut :

(29)

6

Berisi tentang latar belakang masalah, rumusan masalah, tujuan sistem yang dibangun, batasan masalah, tujuan sistem, metodologi penelitian dan sistematikan penulisan.

BAB II LANDASAN TEORI

Berisi teori-teori yang digunakan sebagai dasar untuk mengembangankan sistem informasi praktek dokter umum.

BAB III ANALISA DAN DESAIN SISTEM

Berisi tentang analisa sistem meliputi gambaran umum sistem, use case diagram, pemodelan proses, pemodelan data. Desain sistem yang meliputi desain antarmuka dan desain basisdata.

BAB IV IMPLEMENTASI SISTEM

Berisi tentang penjelasan implementasi sistem informasi praktek dokter umum yang meliputi struktur menu sistem dan tampilan program.

BAB V ANALISA SISTEM

Berisi tentang analisa dari hasil implementasi sistem, membahas kelebihan dan kekurangan yang ada pada sistem. Bab ini juga membahas hasil uji cona sistem terhadap pengguna yaitu dokter, staff administrasi dan pasien. Uji coba dilakukan juga dilakukan kepada pengguna awam yaitu teman-teman mahasiswa jurusan Teknik Informatika maupun bukan.

BAB VI PENUTUP

(30)

BAB II

LANDASAN TEORI

2.1 Sistem Informasi

Suatu sistem adalah suatu jaringan kerja dari prosedur-prosedur yang saling berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau menyelesaikan suatu sasaran tertentu. (Jerry FithGerald, 1981 dalam Jogiyanto 2001).

Informasi adalah data yang diolah menjadi bentuk yang lebih berguna dan lebih berarti bagi yang menerimanya.

Sistem Informasi adalah suatu sistem dalam di dalam suatu organisasi yang mempertemukan kebutuhan pengolahan transaksi harian, mendukung operasi, bersifat manajerial dan kegiatan strategi dari suatu organisasi dan menyediakan pihak luar tertentu dengan laporan-paoran yang diperlukan. (Robert A. Leitch, 1983 dalam Jogiyanto 2001).

2.1.1 Kualitas Informasi

Kualitas dari suatu informasi (quality of information) tergantung dari tiga hal, yaitu informasi harus akurat (accurate), tepat pada waktunya (timelines) dan relevan (relevance).

Akurat, berarti informasi harus bebas dari kesalahan-kesalahan dan tidak bias atau menyesatkan. Akurat juga berarti informasi harus jelas mencerminkan maksudnya. Informasi harus akurat karena dari sumber informasi sampai ke penerima informasi kemungkinan banyak terjadi gangguan (noise) yang dapat merubah atau merusak informasi tersebut.

(31)

8

Bila pengambilan keputusan terlambat, maka dapat berakibat fatal untuk organisasi.

Relevan, artinya informasi tersebut mempunyai manfaat untuk pemakainya. Relevansi informasi ini untuk tiap-tiap orang satu dengan lainnya berbeda. Misalnya informasi mengenai sebab-musahab kerusakan mesin produksi kepada akuntan perusahaan adalah kurang relevan dan akan lebih relevan bila ditujukan kepada ahli teknik perusahaan.

2.2 Rekam Medis

2.2.1 Pengertian Rekam Medis

Rekam medis adalah berkas yang berisikan catatan, dan dokumen tentang identitas pasien, pemeriksaan, pengobatan, tindakan dan pelayanan lain pada pasien pada sarana pelayanan kesehatan (Peraturan Menteri Kesehatan Nomor 749a/Menkes/Per/XII/1989).

2.2.2 Isi Rekam Medis

Untuk pasien rawat jalan termasuk pasien gawat darurat rekam medis memuat informasi pasien antara lain sebagai berikut (Keputusan Dirjen Pelayanan Medik No.78 /Yanmed /RSUmdik/YMU /I/91) :

a. Identitas pasien b. Anamnesis:

 Keluhan utama

 Riwayat sekarang

 Riwayat penyakit yang pernah diderita

 Riwayat keluarga tentang penyakit yang mungkin diturunkan/kontak c. Pemeriksaan fisik, laboratorium, khusus lainnya

(32)

9 2.2.3 Manfaat Rekam Medis

Terdapat 6 manfaat rekam medis yang disebutkan dalam manual rekam medis yaitu :

a. Pengobatan Pasien

Rekam medis bermanfaat sebagai dasar dan petunjuk untuk merencanakan dan menganalisis penyakit serta merencanakan pengobatan, perawatan dan tindakan medis yang harus diberikan kepada pasien.

b. Peningkatan Kualitas Pelayanan

Membuat Rekam Medis bagi penyelenggaraan praktik kedokteran dengan jelas dan lengkap akan meningkatkan kualitas pelayanan untuk melindungi tenaga medis dan untuk pencapaian kesehatan masyarakat yang optimal. c. Pendidikan dan Penelitian

Rekam medis yang merupakan informasi perkembangan kronologis penyakit, pelayanan medis, pengobatan dan tindakan medis, bermanfaat untuk bahan informasi bagi perkembangan pengajaran dan penelitian di bidang profesi kedokteran dan kedokteran gigi.

d. Pembiayaan

Berkas rekam medis dapat dijadikan petunjuk dan bahan untuk menetapkan pembiayaan dalam pelayanan kesehatan pada sarana kesehatan. Catatan tersebut dapat dipakai sebagai bukti pembiayaan kepada pasien.

e. Statistik Kesehatan

Rekam medis dapat digunakan sebagai bahan statistik kesehatan, khususnya untuk mempelajari perkembangan kesehatan masyarakat dan untuk menentukan jumlah penderita pada penyakit-penyakit tertentu. f. Pembuktian Masalah Hukum, Disiplin dan Etik

(33)

10 2.3 SQL (Structured Query Language)

SQL merupakan suatu bahasa yang digunakan untuk mengakses basis data. SQL dapat digunakan untuk menjelaskan struktur dari suatu data, modifikasi data pada basis data dan menetapkan batasan keamanan. SQL terbagi atas beberapa bagian, yaitu :

a. Data-Definition Language (DDL) yang menyediakan perintah untuk menjelaskan relasi, menghapus relasi dan memodifikasi relasi. DDL menyediakan perintah-perintah seperti :

1. CREATE nama_objek 2. ALTER nama_objek 3. DROP nama_objek

b. Data-Manipulation Language (DML) yang merupakan bahasa query berbasis relational algebra dan truple relational calculus. DML menyediakan perintah-perintah seperti :

1. SELECT

Digunakan untuk membaca data dari basis data. Bentuk umum perintah ini adalah :

SELECT * | {[DISTINCT|DISTINCTROW] column | expression[alias],

…}

FROM table

[WHERE condition(s)] [GROUP BY condition(s)] [HAVING condition(s)]

[ORDER BY condition(s) [ASC|DEC]] 2. INSERT

Digunakan untuk menambahkan satu atau lebih data dari basis data. Bentuk umum perintah ini adalah :

INSERT INTO table (column1, column2, [columnN]) VALUES (value1, value2, [valueN])

3. UPDATE

(34)

11

UPDATE table SET column1 = value1, column2 = value2, [columnN = valueN] [WHERE id_column=value]

4. DELETE

Digunakan untk menghapus satu atau lebih data dari data base dari suatu tabel. Bentuk umum perintah ini adalah :

DELETE FROM tablename [where field1=value1 [AND | OR] field2 = value2[AND | OR ] fieldN = ValueN]

c. View-Definition yang merupakan bagian dari DDL yang menyediakan perintah view untuk melihat data dari satu tabel atau lebih.

d. Transaction control yang menyediakan perintah untuk memulai dan mengakhiri transaksi.

e. Embedded SQL yang menjelaskan dimana perintah SQL dapat diintegrasikan ke dalam bahasa pemograman seperti C, C++, Java, Cobol, Pascal dan lain-lain.

f. Integrity yang merupakan bagian dari DDL yang menyediakan perintah untuk menspesifikasi integritas data yang masuk ke basis data.

g. Authorization yang merupakan bagian dari DDL yang menyediakan perintah untuk menspesifikasikan aturan akses.

2.4 DFD (Data Flow Diagram)

(35)

12 Pedoman menggambar DFD:

1. Mengidentifikasikan terlebih dahulu semua kesatuan luar (external entities)

yang terlibat dalam sistem. Kesatuan luar ini merupakan kesatuan di luar sitem, karena di luar bagian pengolahan data (sistem informasi). Kesatuan luar ini merupakan sumber arus data ke sistem informasi serta tujuan penerima arus data hasil dari proses sistem informasi, sehingga merupakan kesatuan di luar sistem informasi.

2. Identifikasi semua input dan output yang terlibat dalam kesatuan luar.

3. Gambarlah terlebih dahulu suatu diagram konteks. DFD merupakan alat untuk stuctured abalysis. DFD yang pertama kali digambarkan adalah level teratas dan disebut dengan diagram konteks. Dari diagram konteks ini kemudian akan digambardengan lebih rinci lagi yang disebut dengan

overview diagram. Tiap-tiap proses di overview diagram (level 0) akan digambar kembali dengan terinci lagi dan disebut dengan level 1. Tiap-tiap prose di level 1 akan digambar kembali lebih terinci lagi dan disebut dengan level 2, dan seterusnya sampai tiap-tiap proses tidak dapat digambar lebih terinci lagi. (Jogiyanto HM, 1990).

Notasi yang digunakan dalam DFD (Teknik Gane/Sarson):

No Notasi Keterangan

1 Entity luar dapat digambarkan dengan simbol

bujursangkar. Seringkali entity luar diberi huruf sebagai identitas. Entity luar merupakan sumber atau tujuan dari aliran dara dari atau ke sistem.

2 Menggambarkan aliran data dari satu proses ke

proses lainnya.

3 Proses atau fungsi mentransformasikan data

(36)

13

kata kerja dan diikuti objek.

4 Menggambarkan sebuah berkas, merupakan

komponen yang berfungsi untuk menyimpan data atau file.

Tabel 2 .1. Notasi DFD

Pembuatan use case diagram yang sesungguhnya merupakan deskripsi peringkat tinggi bagaimana perangkat lunak (aplikasi) akan digunakan oleh penggunanya. Selanjutnya use case diagram tidak hanya sangat penting pada tahap analisis, tetapi juga sangat penting untuk perancangan (design), untuk mencari (mencoba menentukan) kelas-kelas yang terlibat dalam aplikasi, dan untuk melakukan pengujian (testing).

Membuat use case diagram yang komprehensif merupakan hal yang sangat penting dilakukan pada tahap analisis. Dengan menggunakan use case diagram, akan didapatkan banyak informasi yang sangat penting yang berkaitan dengan aturan-aturan bisnis yang coba kita tangkap. Dalam hal ini, setiap objek yang berinteraksi dengan sistem/perangkat lunak (misalnya orang, suatu perangkat keras, sistem lain, dan sebagainya) merupakan aktor untuk sistem/perangkat lunak, sementara use case merupakan deskripsi lengkat tentang bagaimana sistem/perangkat lunak berperilaku untuk para aktornya. Dengan demikian, use case diagram merupakan deskripsi lengkap tentang interaksi yang terjadi antara para aktor dengan sistem/perangkat lunak yang sedang dikembangkan.

Saat akan mengembangkan use case diagram, hal yang pertama kali dilakukan adalah mengenali aktor untuk sistem/aplikasi yang sedang dikembangkan. Dalam hal ini, ada beberapa karakteristik untuk para aktor, yaitu aktor ada di luar sistem yang sedang dikembangkan, dan aktor berinteraksi dengan sistem yang sedang dikembangkan. (Adi Nugroho, 2009).

Notasi yang digunakan dalam use case :

(37)

14

1 Gambar disamping adalah notasi untuk aktor.

Aktor menggambarkan segala pengguna

software aplikasi (user).

2 Gambar disamping adalah notasi untuk use case.

Use case menjelaskan urutan kegiatan yang dilakukan aktor dan sistem untuk mencapai tujuan tertentu.

3 Gambar disamping adalah notasi untuk

interaction. Interaction digunakan untuk menunjukan baik aliran pesan atau informasi antar obyek maupun hubungan antar obyek.

4 Gambar disamping adalah notasi untuk paket.

Paket adalah mekanisme pengelompokan yang digunakan untuk mendakan pengelompokan elemen-elemen model.

Tabel 2 .2. Notasi Use Case

2.6 Metode Perancangan Basis Data

Proses desain basis data dibagi menjadi tiga tahap utama, yaitu : 1. Conceptual Design Database (ER Diagram)

Berupa conceptual schema yang mengacu pada suatu conceptual model (ER model)

2. Logical Design

Menterjemahkan conceptual schema ke dalam model data yang sesuai dengan DBMS yang digunakan. Berupa logical schema basis data yang mengacu pada logical data model (Relational model).

3. Physical Design

(38)

15 2.7 PHP

Menurut Bunafit Nugroho(2004:139) ada beberapa pengertian tentang PHP. Akan tetapi, kurang lebih PHP dapat diartikan sebagai PHP Hypertext Preprocesor. Ini merupakan bahasa yang hanya dapat berjalan pada server yang hasilnya dapat ditampilkan pada klien.

Interpreter PHP dalam mengeksekusi kode PHP pada sisi sever (disebut server-side) berbeda dengan mesin maya Java yang mengeksekusi program pada sisi klien (client-side).

PHP merupakan bahasa standar yang digunakan dalam dunia web site. PHP adalah bahasa pemograman yang berbentuk script yang diletakan di dalam server web. Jika kita lihat dari sejarah, mulanya PHP diciptakan dari ide Rasmus Lerdof yang membuat sebuah script perl. Script tersebut sebenarnya dimaksdukan untuk digunakan sebagai program untuk dirinya sendiri. Akan tetapi, kemudian dikembangkan lagi sehingga menajdi sebuah bahasa yang

disebut “Personal Home Page”.

Beberapa cara penulisan PHP: 1. <? Skript PHP anda disini ?> atau 2. <?php Skript PHP anda disini ?> atau 3. <% Skript PHP anda disini %> atau

4. <SCRIPT language=”php”> Skript PHP anda disini </SCRIPT>

2.8 Manajemen Transaksi

Transaksi merupakan kegiatan atau sekumpulan kegiatan yang dilakukan oleh seorang pengguna atau program aplikasi yang membaca atau mengubah konten pada basis data. Transakasi mempunyai sifat yang disebut ACID, yaitu (Haerder dan Reuter, 1983):

a. Atomicity, dimana sebuah transaksi merupakan sebuah unit yang tidak dapat dibagi yang dilakukan secara keseluruhan atau tidak sama sekali.

(39)

16

c. Isolation, dimana transaksi dijalankan secara bebas. Dengan kata lain, jika terjadi transaksi yang tidak selesai, maka transaksi lain tidak akan terpengaruh.

d. Durability, dimana transaksi dapat tercatat secara permanen dalam basis data dan tidak hilang karena kesalhan pada transaksi berikutnya.

Untuk menciptakan transaksi yang menciptakan hasil sesuai dan dapat meningkatkan integritas dan konsistensi basis sata, maka dibutuhkan

concurrency control. Concurency control merupakan proses mengatur kegiatan yang terjadi secara bersamaan pada basis data tanpa harus menganggu transaksi satu sama lain. Masalah yang dapat terjadi jika tidak ada kontrol terhadap

concurrency adalah : a. The lost update problem

Merupakan masalah yang terjadi jika data transaksi yang telah

di-update tidak diakses oleh traksaksi yang lainnya. Misalnya transaksi A melakukan perubahan pada data A. Kemudian transaksi B mengakses data A sebelum diubah sebelum diubah transaksi A dan kemudian melakukan perubahan terhadap data A tersebut. Maka yang tercatat hanya perubahan data yang dilakukan oleh transaksi B.

b. The uncommitted dependency (dirty read) problem

Masalah ini terjadi jika suatu transakasi melakukan perubahan data. Kemudian data tersebut digunakan oleh transaksi lainnya, meskipun transaksi yang dilakukan perubahan data tersebut membatalkan perubahan data yang dilakukan. Misalnya transaksi A mengubah data A dan data tersebut digunakan transaksi B untuk melakukan perubahan terhadap data A. Kemudian transaksi A membatalkan seluruh kegiatan transaksinya, maka data A menjadi tidak akurat.

c. The inconsistent analysis problem

(40)

17

Misalnya transaksi A mengubah data A. Transaksi B melakukan perubahan pada data B berdasarkan data A yang belum mengalami perubahan yang dilakukan oleh transaksi A. Ini menyebabkan data B menjadi data yang tidak konsisten.

2.8.1 Locking Methods ( Metode-metode Penguncian )

Locking adalah suatu prosedur yang digunakan untuk mengendalikan akses bersamaan pada suatu data. Saat sebuah transaksi mengakses basisdata, suatu kunci (lock) boleh menolak akses dari transaksi akses dari transaksi lain untuk mencegah hasil yang tidak benar. Sifat dasar locking pada sebuah transaksi adalah transaksi harus dinyatakan sebagai shared untuk proses baca

(read) dan sepenuhnya terkunci untuk proses tulis (write). Aturan pada locking adalah:

1. Share lock yaitu jika suatu transaksi memiliki suatu shared lock pada item datanya, maka data tersebut dapat dibaca namun tidak dapat diubah.

2. Exclusive lock yaitu jika suatu transaksi memiliki suatu exclusive lock

pada item datanya, maka data tersebut dapat dibaca dan dapat diubah. Karena operasi baca tidak menimbuklan konflik, maka diijinkan lebih dari 1 transaksi untuk melakukan lock bersama secara serentak pada saat yang bersamaan. Sedangkan pada exclusive lock jika suatu transaksi melakukan exclusive lock pada suatu item data, maka tidak ada transaksi-transaksi lain dapat membaca atau mengubah item data tersebut. Lock dapat dilakukan dengan cara sebagai berikut :

1. Setiap transaksi perlu mengakses suatu item data maka pertama-tama ia harus meminta shared lock untuk akses baca saja atau exclusive untuk akes baca dan tulis.

2. Jika item data tersebut belum dikunci oleh transaksi lain, maka lock akan diberikan.

(41)

18

dalam kondisi shared lock, maka permintaan shared lock akan diberikan. Sebaliknya jika tidak, transaksi tersebut harus menunggu (waiting) sampai

lock yang sedang aktif dilepaskan atau dibuka.

4. Sebuah transaksi melakukan lock sampai dilepaskan pada saat eksekusi atau saat operasi transaksi berakhir (abort atau commit). Efek dari perubahan data dapat dilihat oleh transaksi lain hanya pada saat exclusive lock telah dilepaskan.

Sebagai tambahan dari peraturan tersebut, beberapa sistem mengijinkan untuk :

1. Upgrade the lock (meningkatkan penguncian) yaitu dari shared lock ke

exclusive lock.

2. Downgrade the lock (menurunkan penguncian) dari exlucive lock ke

shared lock.

2.8.2 Two Phase Locking ( 2PL )

Sebuah transaksi menerapkan protokol 2PL jika semua operasi

locking mendahului operasi yang terkunci (unlock) dalam transaksi tersebut. Menurut aturan tersebut, setiap transaksi dapat dibagi menjadi 2 fase, yaitu : 1. Growing phase : memperoleh semua locks yang dibutuhkan tetapi tidak

dapat melepaskan satu locks pun.

2. Shrinking phase : melepaskan semua locks yang dimiliki tetapi tidak dapat memperoleh locks yang baru.

Peraturan yang ditetapkan adalah sebagai berikut :

1. Sebuah transaksi harus memperoleh suatu lock pada suatu item data, sebelum melakukan operasi terhadap data tersebut. Macam lock dapat untuk read atau write tergantung kebutuhan.

(42)

19

2.9 Metedologi FAST (Framework for the Application of system Technique)

FAST (Framework for the Application of Systems Technique) memiliki fase-fase sebagai berikut (Whitten, 2004) :

1. Scope Definition Phase.

Pada tahap ini dilakukan pengumpulan informasi yang akan diteliti tingkat

feasibility dan ruang lingkup proyek yaitu dengan menggunakan kerangka PIECES (Performance, Information, Economics, Control, Efficieny, Service). Hal ini dilakukan untuk menemukan inti dari masalah-masalah yang ada, kesempatan untuk meningkatkan kinerja organisasi dan kebutuhan-kebutuhan baru. Pada tahap ini jga ditentukan apa masalah yang sedang dihadapi sehingga harus diselesaikan.

2. Problem Analysis Phase.

Pada tahap ini akan diteliti masalah-masalah yang muncul pada sistem lama. Hasil dari tahap ini adalah peningkatan performa sistem yang akan memberikan keuntungan dari segi bisnis perusahaan. Hasil lain dari tahapan ini adalah sebuah laporan yang menerangkan tentang problem, causes, effects dan solution benefit.

3. Requirement Analysis Phase.

Pada tahap ini akan dilakukan pengurutan prioritas dari kebutuhan-kebutuhan bisnis yang ada. Tujuan dari tahapan ini adalah mengidentifikasi data, proses dana antarmuka yang diinginkan pengguna dari sistem yang baru. Alat bantu untuk memahami kebutuhan bisnis yang ada adalah dengan pemodelan use case.

4. Logical Design Phase.

Tujuan dari tahapan ini adalah mentrasformasi kebutuhan-kebutuhan bisnis dari fase requiremeny analysis ke sistem model yang akan dibangun nantinya. Dengan kata lain pada fase ini akan menjawab pertanyaan-pertanyaan seputar penggunaan teknologi (data, prosess, interface) yang menjamin usability, reliability, completeness, performance dan quality

(43)

20

a. Data Modelling¸yaitu memodelkan tabel-tabel yang akan digunakan untuk menyimpan data-data di dalam database. Untuk menyelesaikan tahapan ini digunakan Entity Relationship Diagram (ER Diagram). b. Process Modelling, yaitu memodelkan proses-proses yang akan terjadi

dalam suatu sistem. Untuk menyelesaikan tahapan ini digunakan data flow diagram (DFD).

5. Decision Analysis Phase.

Pada tahap ini akan dipertimbangkan beberapa kandidat dari perangkat lunak dan keras yang nantinya akan dipilih dan dipakai dalam implementasi sistem sebagai solusi atas problem dan requirements yang sudah didefiniskan pada tahapan-tahapan sebelumnya.

6. Physical Design and Integration Phase.

Tujuan dari tahapan ini adalah mentransformasikan kebutuhan bisnis yang direpresentasikan sebagai logical design menjadi physical design yang nantinya akan dijadikan sebagai acuan dalam membuat sistem yang akan dikembangkan. Jika di dalam logical design tergantung kepada berbagai solusi teknis, maka physical design merepresentasikan solusi teknis yang lebih spesifik.

7. Construction and Testing Phase

Setelah membuat physical design, makan akan dimulai untuk mengkontruksi dan melakukan tahap uji coba terhadap sistem yang memenuhi kebutuhan-kebutuhan bisnis dan spesifikasi desain. Basis data, program aplikasi dan antarmuka akan mulai dibangun pada tahap ini. Setelah itu dilakukan uji coba terhadap keseluruhan sistem desain.

8. Installation and Delivery Phase.

(44)

BAB III

ANALISA DAN PERANCANGAN SISTEM

3.1 Analisa Sistem

Analisa sistem merupakan penguraian dari suatu sistem informasi yang utuh ke dalam bagian-bagian komponen yang bertujuan untuk mengidentifkasi dan mengevaluasi permasalahan-permasalahan yang terjadi sehingga dapat diusulkan perbaikan-perbaikannya.

3.1.1 Gambaran Umum Sistem Lama

(45)

22 3.1.2 Gambaran Umum Sistem Baru

Sistem baru yang akan dirancang dan dibangun ini merupakan sebuah sistem informasi untuk klinik dr. Happy yang berbasis web. Dimana tujuannya adalah untuk membantu proses pengolahan data pegawai, data pasien, rekam medis, data obat, dan data pemasukan.

Dalam sistem yang baru ini, jika pengguna akan menggunakan sistem, pengguna harus login terlebih dahulu. Kemudian sistem akan mengecek apakah pengguna berhak atau tidak. Sistem ini juga menyediakan fasilitas untuk menyimpan dan menyajikan hasil cetak laporan dari rekam medis, stok obat dan juga penghasilan dr. Happy.

(46)

23

Gambar 3 1. Use Case Diagram

3.1.4 Pemodelan Proses ( Data Flow Diagram ) 3.1.4.1 Diagram Konteks

(47)

24

Gambar 3.2. Diagram Konteks

(48)

25

(49)

26 3.1.4.3 Overview Diagram

1 Data Pasien Id_pasien, nomor_pasien,

nama_pasien, tempat_lahir, tanggal_lahir, alamat, agama, jenis_kelamin, telepon, pekerjaan Nomor antrian, nomor pasien, nama

pasien, keluhan, keterangan Data Resep Obat

Dalam nomor pasien, nama

pasien, keterangan aturan, jumlah, Nama_obat, keterangan, biaya Data Resep Obat

Luar

nomor pasien, nama pasien, keterangan Data resep obat luar

Id_rekam_medis,

(50)

27

Gambar 3.5. DFD Level 1 Proses 1

3.1.4.5 DFD Level 1 Proses 2

Data Rekam medis (id_rekam_medis, id_pasien,

nomor_antrian, keluhan) Data Rekam medis (id_rekam_medis, id_pasien,

nomor_antrian, keluhan)

Nomor_antrian, nama_pasien, keluhan, keterangan

(51)

28

Data Rekam Medis (tensi, nadi, respirasi, suhu

Dokter Riwayat, diagnosa, biaya Data Rekam Medis riwayat,

diagnosa, biaya

Data rekam medis baru

Data Rekam Medis

Data rekam medis

Gambar 3.7. DFD Level 1 Proses 3 3.1.4.7 DFD Level 1 Proses 4

(52)

29

Data pembelian obat baru

3.1.4.8 DFD Level 1 Proses 6

(53)

30 rekam medis per

pasien

7.3.p

Mencetak laporan rekam medis per

tanggal

Data rekam medis, biaya

Data rekam medis

Data resep obat

Data rekam medis

Gambar 3.11. DFD Level 1 Proses 7 3.1.4.10 DFD Level 1 Proses 8

Pasien

(54)

31 3.1.4.11 DFD Level 1 Proses 9

9.1.p

Data resep obat luar baru

data resep obat luar laporan

3.1.5 Pemodelan Data

(55)

32

(56)

33 3.2 Desain Sistem

Desain sistem dapat diartikan setelah analisi dari siklus pengembangan sistem, pendefisinian dari kebutuhan-kebutuhan fungsional, persiapan untuk rancang bangun implementasi, menggambarkan bagaimana suatu sistem dibentuk, yang dapat berupa penggambaran, perencanaan dan pembuatan sketsa atau pengaturan dari beberapa elemen yang terpisah ke dalam suatu kesatuan yang utuh dan berfungsi, termasuk menyangkut mengkonfigurasi dari komponen-komponen perangkat lunak dan perangkat keras dari suatu sistem.

Tujuan dari desain sistem yaitu untuk memenuhi kebutuhan pemakai sistem, dan untuk memberikan gambaran yang jelas dan rancang bangun yang lengkap kepada pemogram komputer dan ahli-ahli teknik lainnya yang terlibat.

3.2.1 Desain Basis Data

(57)

34

(58)

35 3.2.2 Desain Fisikal Basis Data

1. Tabel Apotik

Nama Field Tipe Keterangan

id_apotik int(11) Primary key untuk tabel

apotik.

nama_apotik varchar(30) Field untuk nama apotik

alamat_apotik varchar(100) Field untuk alamat apotik Tabel 3 .1. Desain Fisikal untuk Tabel Apotik

2. Tabel Kategori

id_kategori int(11) Primary key untuk tabel

kategori

nama_katgori varchar(30) Field untuk nama kategori

Tabel 3.2 . Desain Fisikal untuk Tabel Kategori

3. Tabel Obat

id_obat int(11) Primary key untuk tabel

obat

nama_obat varchar(30) Field untuk nama obat

stok_obat double Field untuk stok obat

id_kategori int(11) Foreign key untuk

menghubungkan ke tabel kategori

id_satuan Int(11) Foreign key untuk

menghubungkan ke tabel satuan

Tabel 3. 3. Desain Fisikal untuk Tabel Obat

4. Tabel Pasien

(59)

36

pasien

nama_pasien varchar(75) Field untuk nama pasien

tempat_lahir varchar(75) Field untuk tempat lahir pasien

tanggal_lahir date Field untuk tanggal lahir

pasien

alamat varchar(100) Field untuk alamat pasien

agama varchar(100) Field untuk agama pasien

jenis_kelamin varchar(30) Field untuk jenis kelamin pasien

telepon varchar(25) Field untuk telepon pasien

pekerjaan varchar(25) field untuk pekerjaan

pasien

Tabel 3 .4. Desain Fisikal untuk Tabel Pasien

5. Tabel Pembelian

id_pembelian int(11) Primary key untuk tabel

pembelian

no_faktur varchar(30) Field untuk nomor faktur

pembelian

id_apotik int(11) Foreign key untuk

menghubungan dengan tabel apotik

tanggal date Field untuk tanggal lahir

pembelian Tabel 3. 5. Desain Fisikal untuk Tabel Pembelian

6. Tabel Pembelian Obat

id_pembelian obat

int(11) Primary key untuk tabel

pembelian obat

id_obat int(11) Foreign key untuk

menguhungkan dengan tabel obat

id_pembelian int(11) Foreign key untuk

(60)

37

jumlah double Field untuk jumlah

pembelian obat Tabel 3 .6. Desain Fisikal Tabel Obat

7. Table Pengguna

id_pengguna int(11) Primary key untuk tabel

pengguna

status varchar(30) Field untuk status tabel

pengguna

username varchar(30) Field untuk username

tabel pengguna

password varchar(30) Field untuk password

tabel pengguna Tabel 3 .7. Desain Fisikal untuk Tabel Pengguna

8. Tabel Rekam Medis

id_rekam_medis int(11) Primary key untuk tabel

rekam medis

no_antrian varchar(3) Field untuk no antrian

rekam medis

id_pasien int(11) Foreign key untuk

menguhungkan dengan tabel pasien

tanggal date Field untuk tanggal rekam

medis

keluhan varchar(30) Field untuk keluhan rekam

medis

tensi varchar(35) Field untuk tensi rekam

medis

nadi varchar(35) Field untuk nadi rekam

medis

respirasi varchar(35) Field untuk respirasi

rekam medis

suhu varchar(35) Field untuk suhu rekam

medis

riwayat varchar(35) Field untuk riwayat rekam

medis

diagnosa varchar(35) Field untuk diagnose

(61)

38

biaya double Field untuk biaya rekam

medis

keterangan varchar(100) Field untuk keterangan

rekam medis Tabel 3 .8. Desain Fisikal untuk Tabel Rekam Medis

9. Tabel Resep Obat

id_resep_obat int(11) Primary key untuk tabel

resep obat

id_rekam_medis int(11) Foreign key untuk

menguhungkan dengan tabel rekam medis

tanggal date Field untuk tanggal resep

obat

biaya double Field untuk biaya resep

obat

status varchar(100) Field untuk status resep

obat

Tabel 3. 9. Desain Fisikal untuk Tabel Resep Obat

10.Tabel Resep Obat Luar

id_resep_obat_luar int(11) Primary key untuk tabel resep obat luar

id_rekam_medis int(11) Foreign key untuk

menguhungkan dengan tabel rekam medis

tanggal date Field untuk tanggal resep

obat luar

nama_obat varchar(100) Field untuk nama obat

resep obat luar

aturan varchar(100) Field untuk aturan resep

obat luar

resep obat luar Tabel 3 .10. Desain Fisikal untuk Tabel Resep Obat Luar

(62)

39

id_satuan int(11) Primary key untuk tabel

satuan

nama_satuan varchar(20) Field untuk nama satuan

Tabel 3 .11. Desain Fisikal untuk Tabel Satuan

12.Tabel Uraian Resep Obat

id_uraian_resep_obat int(11) Primary key untuk tabel uraian resep obat

id_resep_obat int(11) Foreign key untuk

menguhungkan dengan tabel resep obat

id_obat int(11) Foreign key untuk

menguhungkan dengan tabel obat

aturan varchar(100) Field untuk aturan

uraian resep obat

jumlah int(11) Field untuk jumlah

uraian resep obat

uraian resep obat Tabel 3. 12. Desain Fisikal untuk Tabel Uraian Resep Obat

3.3 Daftar Stored Procedure.

Nama stored procedure

Alasan Keterangan

SPPembelian Penambahan data

pembelian, data pembelian obat dan update stok obat yang terdapat pada tabel obat.

Mengantisipasi data

Kondisi awal AUTOCOMMIT=0

(63)

40 pembelian obat yang masuk bersamaan dengan data resep obat dan

mengantisipasi jika proses penambahan ini tidak semua

commit

pembelian akan dimasukan jika belum ada di database.

Status rollback jika data pembelian obat telah ada di

database.

Setelah proses selesai nilai AUTOCOMMIT=1

SPResepTambah Penambahan data resep obat, data uraian resep obat dan update stok obat yang terdapat pada tabel obat. Mengantisipasi data uraian resep obat yang mengupdate data stok obat bersamaan dengan data pembelian dan mengantisipasi proses penambahan ini tidak semua

commit.

Kondisi awal AUTOCOMMIT=0

Status commit jika ada data resep obat, data uraian resep obat dan data stok obat telah di-update. Data resep obat dan data uraian resep obat akan dimasukan jika belum ada di

database.

Status rollback jika stok obat=0 atau jumlah obat > stok obat.

Setelah proses selesai nilai AUTOCOMMIT=1.

Tabel 3 .13. Daftar Stored Procedure

3.4 Desain Manajemen Transaksi

(64)

41

transaksi resep obat. Proses pengaturan ini digambarkan pada Gambar 3.16. berupa flowchart menejemen transaksi pembelian.

START

Inisialisasi :

Vpembelian untuk kode pembelian Vstok untuk data stok obat

Data Input : No_Faktur, Id_Apotik, Tanggal, Id_Obat, Jumlah

Data obat tidak ada di pembelian obat berdasarkan

nomor faktur?

ROLLBACK

Data pembelian sudah ada?

Select stok_obat into vstok from obat for update

INSERT tabel pembelian

Update stok obat

INSERT ke tabel pembelian_obat

COMMIT

(65)

42

Selain pada transaksi pembelian, transaksi resep obat juga menggunakan manajemen transaksi untuk mengatur data penjualan yang masuk. Gambar 3.17. merupakan flowchart manajemen transaksi resep obat.

START

Inisialisasi : V_stok_obat untuk stok obat, v_id_resep_obat untuk id resep obat

Data Input : Id_obat, id_rekam_medis,

tanggal, aturan, jumlah, katerangan

Stok obat > 0 dan jumlah <=

stok obat ? ROLLBACK

Data resep obat sudah ada?

Select stok_obat into v_stok from obat for update

INSERT tabel resep_obat

Update stok obat

INSERT ke tabel uraian_resep_obat

COMMIT

(66)

43 3.5 Desain Antarmuka

3.5.1 Halaman Login

Gambar 3.18. Desain Antarmuka Halaman Login

3.5.2 Staff Administrasi

3.5.2.1 Desain Antarmuka Halaman Tambah Data Pasien

Gambar 3.19. Desain Antarmuka Halaman Tambah Data Pasien

(67)

44

Gambar 3.20. Desain Antarmuka Halaman Ubah Data Pasien

3.5.2.3 Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Pasien

Gambar 3.21. Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Pasien 3.5.2.4 Desain Antarmuka Halaman Tambah Data Antrian

(68)

45

3.5.2.5 Desain Antarmuka Halaman Lihat Data Antrian

Gambar 3.23. Desain Antarmuka Halaman Lihat data Antrian

3.5.3 Asisten Dokter

3.5.3.1 Desain Antarmuka Halaman Lihat Data Antrian

Gambar 3.24. Desain Antarmuka Halaman Lihat Data Antrian 3.5.3.2 Desain Antarmuka Halaman Tambah Data Pemeriksaan

header

footer Informasi Data Rekam Medis

Antrian Pemeriksaan Pemeriksaan Obat Pembelian Obat Pengambilan Obat Laporan Logout

No Rekam Medis : - Umur : -Data Pasien Alamat : -Id Pasien : - Pekerjaan:-Nama Pasien : - Keluhan : -Jenis Kelamin :

-Tambah Data Pemeriksaan

Gambar 3. 25. Desain Antarmuka Halaman Tambah Data Antrian

header

footer

Data Antrian

Nomor Antrian

Id Pasien Nama Pasien

(69)

46

3.5.3.3 Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Pemeriksaan

header

footer

Data Pemeriksaan

Gambar 3.26. Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Pemeriksaan

3.5.3.4 Desain Antarmuka Halaman Ubah Data Pemeriksaan header

footer

Antrian Pemeriksaan Pemeriksaan Obat Pembelian Obat Pengambilan Obat Laporan Logout Ubah Data Pemeriksaan

Gambar 3.27. Desain Antarmuka Halaman Ubah Data Pemeriksaan 3.5.3.5 Desain Antarmuka Halaman Lihat, Cari dan Hapus Data Obat

header

footer

Data Antrian

Keluahan Keterangan Aksi header

footer

Data Obat

Pencarian Cari

No Nama Obat Kategori Stok Satuan Aksi

Tambah Data