i
PENGATURAN SMS KONSELING KESEHATAN BERBASIS OPEN SOURCE
(STUDI KASUS: RSU KHARISMA PARAMEDIKA)
Skripsi
Diajukan untuk Memenuhi Salah Satu Syarat Memperoleh Gelar Sarjana Teknik Program Studi Teknik Informatika
Oleh:
DYA SIFA SALVATIRA NIM: 055314059
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS SANATA DHARMA
YOGYAKARTA
ii
MEDICAL COUNSELING SMS MANAGEMENT BASED ON OPEN SOURCE
(CASE STUDY: KHARISMA PARAMEDIKA PUBLIC HOSPITAL)
A Thesis
Presented as Partial Fulfillment of the Requirements To Obtain the Sarjana Teknik Degree
In Study Program of Informatics Engineering
Created by: DYA SIFA SALVATIRA
NIM: 055314059
STUDY PROGRAM OF INFORMATICS ENGINEERING
FACULTY OF SCIENCE AND TECHNOLOGY
SANATA DHARMA UNIVERSITY
YOGYAKARTA
vi ABSTRAKSI
Tugas Akhir ini bertujuan untuk membangun suatu aplikasi SMS Konseling Kesehatan dengan menggunakan bahasa pemrograman Java dan MySQL.
vii ABSTRACT
The purpose of this final assignment is to build Medical Counseling SMS Application using Java and MySQL.
ix
KATA PENGANTAR
Puji dan syukur penulis panjatkan kepada Tuhan Yang Maha Esa yang telah mengaruniakan berkat dan hikmat-Nya sehingga penulis dapat menyelesaikan tugas akhir ini.
Dalam proses penulisan tugas akhir ini ada begitu banyak pihak yang telah memberikan bantuan dan perhatian dengan caranya masing-masing sehingga tugas akhir ini dapat diselesaikan. Oleh karena itu saya mengucapkan terimakasih diantaranya kepada :
1. Bapak Iwan Binanto, M.Cs, selaku Dosen Pembimbing Tugas Akhir yang telah banyak memberikan bimbingan dalam penyusunan tugas akhir ini. 2. Bapak Eko Hari Parmadi, S.Si., M.Kom dan Bapak Puspaningtyas Sanjaya
Adi, S.T., M.T. selaku panitia penguji yang telah memberikan banyak kritik dan saran sempurnanya tugas akhir ini.
3. RSU Kharisma Paramedika yang telah memberikan kesempatan sebagai tempat studi kasus.
4. Bapak Bele Bau dan Dimas Sadewo yang turut mendukung dalam persiapan ujian pendadaran.
x
6. Seluruh staff Sekretariat Teknik yang banyak membantu penulis dalam urusan administratsi akademik terutama menjelang ujian tugas akhir dan yudisium.
7. Ayah, Ibu, Bunda, Woro Wuryandaru, Eliska Kristiandaru dan segenap keluarga di rumah yang telah memberikan banyak nasehat hidup, doa, semangat, perhatian sehingga penulis dapat menyelesaikan tugas akhir ini. 8. Jepri Junial Fransisco yang telah memberikan banyak perhatian, pengertian,
nasihat, doa, semangat dan kasihnya untuk penulis dalam menyelesaikan tugas akhir ini.
9. Sahabat – sahabat terbaik penulis: Theresia Paulin, Maria Goretti, Phalita Nariwastu, Margareta Ratna, , Bernadhet Maya, Fransiskus Paranso, I Gusti Nyoman Sedana, I Kadek Dendy, Christiono Eka, Ignasius Hans, Dominikus Catur, Hendri Cahyana, Andriyanto, Gregorius Arif dan teman – teman kos. 10. Semua pihak yang telah membantu penulisan baik secara langsung maupun
tidak langsung, yang tidak dapat penulis sebutkan satu persatu.
Dengan rendah hati saya menyadari bahwa tugas akhir ini masih jauh dari sempurna, oleh karena itu berbagai kritik dan saran untuk perbaikan tugas akhir ini sangat saya harapkan.
Akhir kata semoga tugas akhir ini bermanfaat bagi semua pihak. Terima kasih.
Yogyakarta, September 2009
xi DAFTAR ISI
HALAMAN JUDUL………... i
HALAMAN PERSETUJUAN………..……….. iii
HALAMAN PENGESAHAN………..……….. ix
PERNYATAAN KEASLIAN KARYA………..……… v
ABSTRAKSI………..………. vi
ABSTRACT………..………... vii
LEMBAR PERNYATAAN PERSETUJUAN………..…….. viii
KATA PENGANTAR………..………... ix
DAFTAR ISI………..………..………... xi
DAFTAR TABEL ...………..……… xiv
DAFTAR GAMBAR ………. xv
BAB I PENDAHULUAN………..………. 1
1.1 Latar Belakang Masalah………..……… 1
1.2 Rumusan Masalah………..………. 2
1.3 Batasan Masalah………..……… 2
1.4 Tujuan Penelitian………..………... 2
1.6 Metodologi Penelitian………..………... 3
1.7 Sistematika Penulisan………..……… 4
BAB II LANDASAN TEORI………..………... 5
2.1 KONSELING ………..………... 5
2.2 SMS ………..……….. 5
2.3 GAMMU………..………... 6
2.4 JAVA………..………. 7
2.4.1 JME (Java Micro Edition) ………..………. 7
2.4.2 JSE (Jave Standard Edition) ………..…………. 7
2.4.3 JEE (Jave Enterprise Edition) ………. 8
2.4.3.1 JSP (JavaServer Pages) ………..…………. 8
2.4.3.2 Servlet………..……….. 9
2.5 JDBC………..………. 10
2.6 Metodologi FAST………..………. 11
2.6.1 Use Case Diagram………..………. 14
2.6.2 SequentialDiagram………..……… 15
2.7 UML………..………..……… 16
2.8 RDBMS dan MySQL………..……… 19
2.9 SQL………..………... 19
xii
BAB III ANALISIS DAN PERANCANGAN SISTEM……….. 23
3.1 Analisis Sistem………..……….. 23
3.1.1 Fase Definisi Ruang Lingkup (Scope Definition))………... 23
3.1.2 Fase Analisis Masalah (Problem Analysis)……….. 24
3.1.2.1 Sistem Yang Ada Saat Ini………..……….. 24
3.1.2.2 Sebab Akibat (Cause – effect Analysis)……… 26
3.1.2.3 Gambaran Sistem Baru………..………. 26
3.1.2.4 Orang Yang Terlibat Dalam Sistem………... 28
3.1.3 Fase Analisis Kebutuhan (Requirement Analysis)………... 29
3.1.3.1 Use Case Diagram……….. 29
3.1.3.2 Use Case Untuk Administrator………..…… 30
3.1.3.3 Use Case Untuk Paket Dokter……… 31
3.1.3.4 Narasi Use Case………. 31
3.1.3.4.1 Narasi Singkat Use Case………. 31
3.1.3.4.2 Tabel Ringkasan Use Case……….. 32
3.1.4 Fase Desain Logikal (Logical Design)………. 64
3.1.4.1 Diagram Aktivitas (Activity Digram)………. 64
3.1.4.2 Entity Relationalship Diagram (ERD)…..……… 79
3.1.5 Analisis Keputusan dan Design (Decision Analysis)…………... 80
3.1.5.1 Mengidentifikasi dan Mengklasifikasikan Kelas dalam Use Case Design………... 80
3.1.5.2 Mengidentifikasi Perilaku dan Responsibilities Menggunakan Sequence Diagram……….. 86
3.1.5.3. Memodelkan Status Object (Object State)……….. 106
3.2 Perancangan Sistem (Physical Design and Integration))…………... 119
3.2.1 Rancangan Database……… 119
3.2.1.1 Disain Tabel………... 119
3.2.2 Design Interface………... 121
BAB IV IMPLEMENTASI……… 136
4.1 Fase Konstruksi dan Percobaan……….. 136
4.1.1 Karakteristik Sistem………. 136
4.1.2 Kebutuhan Sistem……… 136
4.1.2.1 Kebutuhan Perangkat Keras……….. 136
4.1.2.2 Kebutuhan Perangkat Lunak………. 137
4.1.3 Implementasi Sistem……… 138
4.1.3.1 Pembuatan Database………..………... 138
4.1.3.2 Pembuatan Tabel-Tabel………. 138
4.1.3.3 Koneksi Program ke Database……….. 140
4.1.3.4 Koneksi Program ke Handphone……….. 141
xiii
4.1.3.5.1 Gammu……….. 143
4.1.3.5.2 Kirim SMS………. 144
4.1.3.5.3 Terima SMS………... 144
4.1.3.6 Penanganan Aplikasi Web……… 147
4.1.3.6.1 Poliklinik……… 147
4.1.3.6.2 Dokter………. 150
4.1.3.6.3 Inbox………... 154
4.1.3.6.4 Outbox……… 156
4.1.3.6.5 Laporan……….. 158
4.1.4 Antarmuka………..……….. 158
4.1.4.1 Aplikasi Server………..……… 158
4.1.4.2 Aplikasi Web………..………... 160
BAB V PENUTUP………..………. 181
5.1 Kelebihan Sistem………..………. 181
5.2 Kekurangan Sistem………..………... 181
5.3 Kesimpulan ………..………. 181
5.4 Saran………..………. 182
xiv
DAFTAR TABEL
Tabel 1 Notasi kardinalitas……..………..……..……….. 22
Tabel 2 Tabel cause and effect……..………..……..…….……… 26
Tabel 3 Ringkasan Use Case……..………..……..……… 32
Tabel 4 Klasifikasi Use Case Login……..………. 80
Tabel 5 Klasifikasi Use Case Lihat Account……..……… 80
Tabel 6 Klasifikasi Use Case Tambah Account….…..……….. 80
Tabel 7 Klasifikasi Use Case Hapus Account……..……….. 80
Tabel 8 Klasifikasi Use Case Edit Account……..………... 81
Tabel 9 Klasifikasi Use Case Lihat Detil Account……..………... 81
Tabel 10 Klasifikasi Use Case Lihat Poliklinik ……..……….... 81
Tabel 11 Klasifikasi Use Case Tambah Poliklinik……..………. 81
Tabel 12 Klasifikasi Use Case Hapus Poliklinik …..………... 81
Tabel 13 Klasifikasi Use Case Edit Poliklinik……..………... 82
Tabel 14 Klasifikasi Use Case Lihat Detil Poliklinik……..………... 82
Tabel 15 Klasifikasi Use Case Buat Laporan……..………... 82
Tabel 16 Klasifikasi Use Case Run Server……..………... 82
Tabel 17 Klasifikasi Use Case Stop Server……..………... 83
Tabel 18 Klasifikasi Use Case Edit Data Account Sendiri……..………. 83
Tabel 19 Klasifikasi Use Case Kirim SMS……..………... 83
Tabel 20 Klasifikasi Use Case Lihat Data Inbox……..………... 83
Tabel 21 Klasifikasi Use Case Kirim SMS……..………... 84
Tabel 22 Klasifikasi Use Case Lihat Data Outbox……..………. 84
Tabel 23 Klasifikasi Use Case Lihat Detil Data Outbox……..……… 84
Tabel 24 Klasifikasi Use Case Lihat Histori Inbox……..……… 84
Tabel 25 Klasifikasi Use Case Lihat Histori Outbox……..……… 84
Tabel 26 Klasifikasi Use Case Lihat Histori Inbox……..……… 85
Tabel 27 Klasifikasi Use Case Logout……..………... 85
Tabel 28 Struktur Tabel t_pengguna……..………... 119
Tabel 29 Struktur Tabel t_poliklinik……..………... 119
Tabel 30 Struktur Tabel t_inbox……..………... 120
Tabel 31 Struktur Tabel t_outbox……..………... 120
xv
DAFTAR GAMBAR
Gambar 1. Tahap – tahap metodologi FAST………. 3
Gambar 2. Use case diagram……… 14
Gambar 2. Simbol use case………... 15
Gambar 4. Simbol actor………..………. 15
Gambar 5. Simbol dalam Sequential Diagram……….………. 16
Gambar 6. Simbol Entitas……….………. 21
Gambar 7. Simbol Entitas dengan atribut……….………. 21
Gambar 8. Contoh ERD……….………... 22
Gambar 9. Diagram Konteks Sistem yang ada saat ini………. 25
Gambar 10. Diagram Konteks Sistem Baru……… 28
Gambar 11. Use Case Diagram Aplikasi Pengaturan SMS Konseling……….. 29
Gambar 12. Use Case Diagram Untuk Management Sistem……….. 30
Gambar 13. Use Case Diagram Untuk Management Klinik……….. 30
Gambar 14. Use Case Diagram Untuk Paket Dokter……….. 31
Gambar 15. Diagram Aktivitas Use Case Login………. 64
Gambar 16. Diagram Aktivitas Use Case Tambah Account………... 65
Gambar 17. Diagram Aktivitas Use Case Lihat Account……… 66
Gambar 18. Diagram Aktivitas Use Case Hapus Account……….. 66
Gambar 19. Diagram Aktivitas Use Case EditAccount………. 67
Gambar 20. Diagram Aktivitas Use Case Lihat Detil Account……….………. 68
Gambar 21. Diagram Aktivitas Use Case Tambah Poliklinik……… 68
Gambar 22. Diagram Aktivitas Use Case EditPoliklinik………... 69
Gambar 23. Diagram Aktivitas Use Case Lihat Poliklinik………. 69
Gambar 24. Diagram Aktivitas Use Case Hapus Poliklinik………... 70
Gambar 25. Diagram Aktivitas Use Case Lihat Detil Poliklinik……… 71
Gambar 26. Diagram Aktivitas Use Case Buat Laporan………. 71
Gambar 27. Diagram Aktivitas Use Case Run Server……… 72
Gambar 28. Diagram Aktivitas Use Case Stop Server……… 72
Gambar 29. Diagram Aktivitas Use Case Edit Data Account Sendiri………. 73
Gambar 30. Diagram Aktivitas Use Case Kirim SMS……… 74
Gambar 31. Diagram Aktivitas Use Case Lihat Data Inbox……….. 74
Gambar 32. Diagram Aktivitas Use Case Lihat Detil Data Inbox……….. 75
Gambar 33. Diagram Aktivitas Use Case Lihat Data Outbox……… 75
Gambar 34. Diagram Aktivitas Use Case Lihat Detil Data Outbox………... 76
Gambar 35. Diagram Aktivitas Use Case Lihat Histori Inbox……….. 76
Gambar 36. Diagram Aktivitas Use Case Lihat Histori Outbox………. 77
Gambar 37. Diagram Aktivitas Use Case Lihat Data Pasien……….. 77
Gambar 38. Diagram Aktivitas Use Case Logout………... 78
Gambar 39. Diagram Aktivitas Use Case Kirim Pesan……….. 78
Gambar 40. Diagram Aktivitas Use Case Daftar……… 78
Gambar 41. Entity Relationship Diagram…………... 79
xvi
Gambar 43. Sequence DiagramUse Case Login……… 86
Gambar 44. Sequence DiagramUse Case Lihat Account………... 87
Gambar 45. Sequence DiagramUse Case Tambah Account……….. 88
Gambar 46. Sequence DiagramUse Case Hapus Account………. 89
Gambar 47. Sequence DiagramUse Case EditAccount………. 90
Gambar 48. Sequence DiagramUse Case Lihat Detil Account……….. 91
Gambar 49. Sequence DiagramUse Case Tambah Poliklinik……… 92
Gambar 50. Sequence DiagramUse Case Edit Poliklinik……….. 93
Gambar 51. Sequence DiagramUse Case Lihat Poliklinik……… 95
Gambar 52. Sequence DiagramUse Case Hapus Poliklinik……….. 95
Gambar 53. Sequence DiagramUse Case Lihat Detil Poliklinik………... 96
Gambar 54. Sequence DiagramUse Case Buat Laporan……… 97
Gambar 55. Sequence DiagramUse Case Run Server……….. 98
Gambar 56. Sequence DiagramUse Case Stop Server………... 99
Gambar 57. Sequence DiagramUse Case Edit Data Account Sendiri……… 100
Gambar 58. Sequence DiagramUse Case Kirim SMS……….. 101
Gambar 59. Sequence DiagramUse Case Lihat Data Inbox……….. 102
Gambar 60. Sequence DiagramUse Case Lihat Detil Data Inbox………. 103
Gambar 61. Sequence DiagramUse Case Lihat Data Outbox……… 103
Gambar 62. Sequence DiagramUse Case Lihat Detil Data Outbox………... 104
Gambar 63. Sequence DiagramUse Case Lihat Histori Inbox……….. 104
Gambar 64. Sequence DiagramUse Case Lihat Histori Outbox……… 105
Gambar 65. Sequence DiagramUse Case Lihat Data Pasien………. 105
Gambar 66. Sequence DiagramUse Case Logou………... 106
Gambar 67. Class Diagram…………. 106
Gambar 68. Diagram Kelas Desain Use Case Login……….. 107
Gambar 69. Diagram Kelas Desain Use Case Lihat Account………. 107
Gambar 70. Diagram Kelas Desain Use Case Tambah Account………. 108
Gambar 71. Diagram Kelas Desain Use Case Hapus Account……… 108
Gambar 72. Diagram Kelas Desain Use Case Edit Account………... 109
Gambar 73. Diagram Kelas Desain Use Case Lihat Detil Account……… 109
Gambar 74. Diagram Kelas Desain Use Case Tambah Poliklinik……….. 110
Gambar 75. Diagram Kelas Desain Use Case Edit Poliklinik……… 110
Gambar 76. Diagram Kelas Desain Use Case LihatPoliklinik………...… 111
Gambar 77. Diagram Kelas Desain Use Case HapusPoliklinik………. 111
Gambar 78. Diagram Kelas Desain Use Case Lihat Detil Poliklinik……….. 112
Gambar 79. Diagram Kelas Desain Use Case Buat Laporan……….. 112
Gambar 80. Diagram Kelas Desain Use Case Run Server……….. 113
Gambar 81. Diagram Kelas Desain Use Case Stop Server………. 113
Gambar 82. Diagram Kelas Desain Use Case Edit Account Sendiri……….. 114
Gambar 83. Diagram Kelas Desain Use Case Kirim SMS………. 114
Gambar 84. Diagram Kelas Desain Use Case Lihat Data Inbox………. 115
Gambar 85. Diagram Kelas Desain Use Case Lihat Detil Data Inbox……… 115
Gambar 86. Diagram Kelas Desain Use Case Lihat Data Outbox……….. 116
Gambar 87. Diagram Kelas Desain Use Case Lihat Detil Data Outbox………. 116
xvii
Gambar 89. Diagram Kelas Desain Use Case HistoriOutbox……… 117
Gambar 90. Diagram Kelas Desain Use Case Lihat Data Pasien………... 118
Gambar 91. Diagram Kelas Desain Use Case Logout………. 118
Gambar 92. Desain Halaman Login. ……….. 121
Gambar 93. Desain Halaman Utama Administrator……… 121
Gambar 94. Desain Halaman Utama Dokter………... 122
Gambar 95. Desain Halaman Dokter Tampil……….. 122
Gambar 96. Desain Halaman Tambah Dokter………. 123
Gambar 97. Desain Halaman Sukses Hapus Account………….. 123
Gambar 98. Desain Halaman Dokter Edit………... 124
Gambar 99. Desain Halaman Dokter Detail……… 125
Gambar 100. Desain Halaman Poliklinik……… 125
Gambar 101. Desain Halaman Poliklinik Tambah……… 126
Gambar 102. Desain Halaman Sukses Tambah Poliklinik ………... 126
Gambar 103. Desain Halaman Poliklinik Edit……….. 127
Gambar 104. Desain Halaman Sukses Edit Poliklinik……….. 127
Gambar 105. Desain Halaman Hapus Poliklinik……….. 128
Gambar 106. Desain Halaman Error Delete Poliklinik……… 128
Gambar 107. Desain Halaman Detil Poliklinik……… 129
Gambar 108. Desain Halaman Laporan……… 129
Gambar 109. Desain Halaman Laporan Bulanan……….. 129
Gambar 110. Desain Halaman Utama Server……… 130
Gambar 111. Desain Halaman Akun Anda……….. 130
Gambar 112. Desain Halaman Sukses Edit Account……… 130
Gambar 113. Desain Halaman Inbox……… 131
Gambar 114. Desain Halaman Detil Data Inbox……….. 131
Gambar 115. Desain Halaman Kirim SMS……….. 132
Gambar 116. Desain Halaman Outbox………. 132
Gambar 117. Desain Halaman Detil Data Outbox……… 133
Gambar 118. Desain Halaman Inbox Tampil……… 133
Gambar 119. Desain Halaman Outbox Tampil………. 134
Gambar 120. Desain Halaman Pasien……….. 134
Gambar 121. Desain Halaman Pasien Tampil……….. 135
Gambar 122. Login Server………..……….. 159
Gambar 123. Halaman Utama Aplikasi Server………. 159
Gambar 124. Halaman Login………..……….. 160
Gambar 125. Halaman Utama Administrator……….. 161
Gambar 126. Halaman Akun Administrator………. 162
Gambar 127. Halaman Edit Password………..………. 162
Gambar 128. Halaman Pesan Error Password……….. 163
Gambar 129. Halaman Pesan Sukses Ganti Password……….. 163
Gambar 130. Halaman Dokter………..………. 163
Gambar 131. Halaman Tambah Account Dokter………..…… 164
Gambar 132. Halaman Pesan Errorusername………..…….………….. 164
Gambar 133. Pesan Error Kolom Kosong………..……….. 164
xviii
Gambar 135. Halaman Detil Data Dokter………..………... 165
Gambar 136. Halaman Edit Akun Dokter………..………... 166
Gambar 137. Pesan sukses edit………..………... 166
Gambar 138. Sukses Hapus dokter………..………. 166
Gambar 139. Halaman Poliklinik……..……… 167
Gambar 140. Halaman Tambah Poliklinik……..……….. 167
Gambar 141. Pesan Error Tambah Poliklinik……..……… 168
Gambar 142. Pesan Sukses Tambah Poliklinik……..……….. 168
Gambar 143. Halaman Detil Data Poliklinik……..……….. 168
Gambar 144. Halaman Edit Poliklinik……..……… 169
Gambar 145. Pesan Sukses Edit……..………..……..……….. 169
Gambar 146. Error Hapus Poliklinik……..……….. 170
Gambar 147. Pesan Sukses Hapus Klinik……..………... 170
Gambar 148. Halaman Pasien……..………..……..………. 171
Gambar 149. Halaman Pencarian Berdasarkan Nama……..………. 171
Gambar 150. Halaman Pencarian Berdasarkan Id Pasien……..………... 172
Gambar 151. Halaman Laporan……..………..……..………. 172
Gambar 152. Tampilan Laporan……..………..……..………. 173
Gambar 153. Halaman Utama Dokter……..………. 173
Gambar 154. Detail Account Dokter……..………..……..………... 174
Gambar 155. Halaman Edit Account……..………..……..……….. 175
Gambar 156. Halaman Edit Password……..………..……..……… 175
Gambar 157. Pesan Error Edit Password……..………... 176
Gambar 158. Pesan Sukses Edit Password……..………. 176
Gambar 159. Halaman Inbox……..………..……..……….. 176
Gambar 160. Halaman Detil Data Inbox……..………. 177
Gambar 161. Halaman Balas Pesan……..………. 177
Gambar 162. Pesan Sukses Kirim……..……… 177
Gambar 163. Halaman Histori Inbox……..……….. 178
Gambar 164. Halaman Outbox……..……… 178
Gambar 165. Halaman Detil Outbox……..……….. 179
Gambar 166. Halaman Histori Outbox……..……… 179
Gambar 167. Halaman Pasien……..………. 180
1
BAB I PENDAHULUAN
1.1 Latar Belakang Masalah
RSU Kharisma Paramedika merupakan salah satu rumah sakit yang
menerapkan layanan konseling kesehatan. Konseling dilakukan untuk beberapa
Poliklinik yang ada pada rumah sakit tersebut. Masing – masing Poliklinik
memiliki Dokter yang berbeda untuk menangani Konseling. Pasien yang akan
berkonsultasi datang ke rumah sakit kemudian mendaftarkan diri untuk
mengambil nomer antrian untuk bertemu dengan Dokter.
Prosedur konseling seperti diatas dirasa kurang effisien. Untuk itu perlu
dibuat sebuah aplikasi untuk membantu pasien mengatur waktunya agar lebih
effisien. Selain itu, aplikasi ini diharapkan dapat memberikan pelayanan yang
lebih baik lagi kepada pasien RSU Kharisma Paramedika yang menjadikan nilai
plus dari rumah sakit lainnya.
Teknologi komunikasi saat ini berkembang dengan pesat, salah satu
komunikasi yang banyak digunakan masyarakat umum, baik masyarakat bawah,
menengah, maupun atas yaitu komunikasi melalui Short Message Service (SMS). Oleh karena itu untuk mengatasi permasalahan pada RSU Kharisma Paramedika,
dibuat aplikasi pengaturan SMS Konseling masalah kesehatan untuk membantu
pasien agar tetap dapat melakukan konseling kepada dokter melalui komunikasi
SMS tanpa harus bertemu langsung dengan dokter sehingga waktunya lebih
1.2 Rumusan Masalah
Dari latar belakang masalah di atas dapat dirumuskan masalah yaitu
bagaimanan membuat suatu program aplikasi yang dapat membantu proses
konseling antara pasien dengan dokter di RSU Kharisma Paramedika dengan
menggunakan media komunikasi SMS.
1.3 Batasan Masalah
Dalam pembuatan program aplikasi ini dilakukan beberapa batasan masalah
sebagai berikut:
1. Pesan balasan yang dikirimkan sistem ditulis/diketik oleh dokter.
2. SMS yang diterima dan dikirimkan berupa teks alphabet latin.
3. Sistem menggunakan Service SMS Gammu untuk menerima dan
mengirimkan SMS.
4. Teknologi yang digunakan adalah Java, MySQL 5, dan dengan sistem
operasi Linux.
5. Pesan balasan kepada pasien ditujukan pada no Hp terakhir pesan
pasien, no Hp tidak disimpan hanya id pasien saja.
1.4 Tujuan Penelitian
Adapun tujuan penulisan skripsi adalah untuk membuat aplikasi pengaturan
SMS konseling untuk RSU Kharisma Paramedika yang akan memudahkan pasien
1.5 Metodologi Penelitian
Metodologi penelitian yang digunakan dalam pembuatan skripsi ini:
1. Studi pustaka dengan beberapa topik seperti berikut ini:
a. Teknik menggunakan MySQL 5 dan JAVA.
b. GAMMU dan implementasinya dengan database MySQL 5.
c. Sistem operasi Linux.
2. Metodologi pengembangan sistem menggunakan FAST (Framework for
the Application of Systems Thinking) menurut Whitten and Bentley (2007) dengan langkah – langkah sebagai berikut :
a. Scope Definition (Definisi ruang lingkup)
b. Problem Analysis (analisis masalah)
c. Requirements Analysis (analisis kebutuhan)
d. Logical Design (desain logika)
e. Decision Analysis (analisis keputusan)
f. Physical Design and Integration (desain fisik dan integrasi)
g. Construction and Testing (pembuatan program dan percobaan).
1.6 Sistematika Penulisan BAB I PENDAHULUAN
Bab ini sebagai pengantar sebelum memasuki isi tulisan. Bab ini meliputi
latar belakang masalah, rumusan masalah, batasan masalah, tujuan dan
manfaat penelitian, metodologi penelitian, sistematika penulisan yang
digunakan peneliti.
BAB II LANDASAN TEORI
Bab ini berisi tentang teori – teori dasar yang dipakai sebagai dasar
pembuatan analisis, perancangan dan implemntasi program.
BAB III ANALISIS DAN PERANCANGAN SISTEM
Bab ini berisikan tentang analisis sistem yang kemudian dari hasil analisis
yang dilakukan akan dibuat sebuah rancangan sistem untuk menyelesaikan
masalah dalam penelitian ini.
BAB IV IMPLEMENTASI DAN HASIL
Bab ini berisi tentang implementasi dari rancangan sistem yang sudah
dibuat, dan penjelasan fungsi program.
BAB V ANALISIS
5
BAB II LANDASAN TEORI
2.1 KONSELING
Gladding (1992, 2004) mengatakan bahwa konseling adalah suatu profesi.
Artinya yang dapat melakukan konseling adalah orang – orang yang mendapat
pendidikan untuk melakukan konseling dan melalui proses sertifikasi serta harus
mendapatkan lisensi untui melakukan konseling. Konseling juga mencakup
berbagai subspesialitas seperti konseling sekolah, konseling perkawinan dan
keluarga, konseling kesehatan, konseling rehabilitasi dan karier.
Gladding (1992) membuat kesimpulan bahwa:
“Counseling is a relatively short-term, interpersonal, theory-based, professional
activity guided by ethical and legal standards that focuses on helping persons who are basically psychologically healthy to resolve developmental and situational problems.”
2.2 SMS
Menurut Wibisono, G. dan Dwi, H.G. (2008), SMS adalah salah satu
fasilitas dari teknologi GSM yang memungkinkan MobileStation (MS) mengirim dan menerima pesan singkat berupa text dengan kapasitas maksimal 160 karakter. Kapasitas maksimal ini tergantung alphabet yang digunakan, untuk alphabet Latin
maksimal hanya 70 karakter. Pengiriman SMS menggunakan kanal signaling yang
merupakan kanal kendali dan memiliki dua tipe:
1. SMS point to point, yaitu pengiriman SMS hanya dari satu MS ke MS tertentu.
2. SMS Broadcast, yaitu pengiriman SMS ke beberapa MS sekaligus, misalnya dari operator kepada seluruh pelanggannya
2.3 GAMMU
Definisi gammu menurut www.gammu.org adalah nama sebuah project
yang ditujukan untuk membangun aplikasi, script dan drivers yang dapat
digunakan untuk semua fungsi yang memungkinkan pada telepon seluler atau alat
sejenisnya. Sekarang gammu telah menyediakan codebase yang stabil dan mapan untuk berbagai macam model telepon yang tersedia di pasaran dibandingkan
dengan project sejenis. Pengembangan jangka panjang diorientasikan untuk
membuat suatu API pada kelas – kelas dari device yang dibandingkan dengan
model single phone pendukung (yang akhirnya tidak terpakai karena datang
model baru).
Gammu merupakan project yang berlisensi GNU GPL 2 sehingga menjamin
kebebasan menggunakan tool ini tanpa perlu takut dengan masaah legalitas dan
biaya yang mahal yang harus dikeluarkan. Gammu mendukung berbagai macam
2.4 JAVA
Menurut Kadir, A. (2004) Java adalah bahasa pemrograman serbaguna yang
dikembangkan oleh Sun Microsystems pada Agustus 1991. Keunggulan java yaitu
tidak bergantung platform. Artinya, Java dapat dijalankan pada sembarang
komputer dan bahkan pada sembarang sistem operasi yang didukung oleh java.
Selain itu, Java merupakan bahasa pemrograman berorientasi objek (suatu
pengembangan perangkat lunak yang saat ini sangat popular) yang menggunakan
kelas untuk membentuk suatu objek. Selain itu Java mendukung multithreding.
Artinya, program dapat dibuat untuk dijalankan oleh thred (baik yang
menjalankan program Java maupun program lain) tertentu. Beberapa thred dapat
dijalankan secara bersama-sama.
2.4.1 JME (Java Micro Edition)
(www.sun.com/javame) JME merupakan salah satu platform java yang
cepat, fleksibel untuk aplikasi yang dijalankan di mobile (handphone) dan alat lainnya seperti personal digital assistans (PDA), TV set-top-boxes, dan printer. Java ME bersifat fleksibel mencakup user interface, robust security, protokol
jaringan, dan mendukung aplikasi jaringan dan aplikasi offline yang dapat
didownload secara dinamis. Aplikasi- aplikasi yang dibangun dengan Java ME
bersifat portable terhadap banyak alat, namun berpengaruh terhadap kemampuan
masing – masing alat. Wijono, S.H., Suharto, B.H. & Wijono, M.S. (2007).
2.4.2 JSE (Java Standard Edition)
Menurut Wijono, S.H., Suharto, B.H. & Wijono, M.S.(2007) Java SE
2.4.3 JEE (Java Enterprise Edition )
Menurut Wijono, S.H., Suharto, B.H. & Wijono, M.S.(2007) Java EE
merupakan platform Java yang berisikan subset dari class-class JSE dan dipakai
dalam produk-produk consumer-electronic.
2.4.3.1JSP (JavaServer Pages)
Menurut Kadir (2004), JSP merupakan teknologi yang didasarkan pada
bahasa Java yang dapat digunakan untuk membentuk halaman - halaman Web
yang bersifat dinamis dan mendukung multiplatform. Teknologi ini
dikembangkan oleh Sun Microsystems.
JSP bekerja hampir sama seperti ASP dan PHP yaitu kode sumber JSP
dijalankan pada sisi server yang memungkinkan untuk membuat aplikasi yang
independent terhadap keberadaan sistem Java disisi client. Tujuan utama
teknologi JSP untuk menghasilkan content dinamis berbasis web. Kemampuan
JSP diimplementasikan dengan menyimpan statement logika antara template data
(seperti HTML, XML, dll) dengan bersama menghasilkan dynamic content pada
basis request-by-request. Statement logika ini dapat diklasifikasikan pada elemen JSP yaitu:
1. Scriptingelements
Scripting elements digunakan dalam halaman JSP untuk memanipulasi
objek dan perhitungan yang memungkinkan generasi content dinamik.
Scripting elements memiliki beberapa kategori, yaitu comments <%-- This
is a JSP comment --%>,declaration <%! Date now = new Date(); %>, scriptlet
<% User user = User)request.getAttribute("User"); if (user != null)
2. Directives
Directive digunakan untuk passing informasi penting untuk engine JSP.
Halaman JSP memiliki 3 tipe directive dalam tiap penyelesaian yaitu page
directive <%@ page page_directive_attr_list %>, include directives <%@
include file="relativeURL" %>, dan taglib directives <%@ taglib
{uri="/tagLibraryURI" | tagdir="/WEB-INF/tags/dirname"
prefix="tagPrefix" %>.
3. Action elemen
Action elemen adalah alternativ yang digunakan untuk mengenkapsulasi
bagian dari logika fungsional. Action ini membuat halaman JSP lebih bersih dan menarik. Ada tiga tipe action elemen yaitu standard actions, custom actions, dan JSTL actions.
2.4.3.2Servlet
Menurut Hall, M. (1998) Servlet adalah teknologi Java yang menjawab
programming Common Gateway Interface (CGI). Servlet merupakan program
yang berjalan pada web server, bermain pada layer tengah antara request yang datang dari web browser atau dari client HTTP lain dan database atau aplikasi pada HTTP sever. Tugas Servlet antara lain:
1. Membaca semua data yang dikirim oleh user.
2. Melihat informasi tentang permintaan yang disimpan pada HTTP request. 3. Men-generateresult.
4. Menyusun result dalam sebuah dokumen.
5. Memberikan respon parameter HTTP dengan tepat.
Servlet memiliki life-cycle. Life-cycle ini dicerminkan dalam beberapa method dari interface javax.servlet.Servlet: init(), service(), dan destroy(). Ada
empat tingkat life-cycle dari servlet:
1. Loading dan pembuatan obyek (instantiation) dari class servlet, dilakukan dalam constructor dari class servlet.
2. Inisialisasi, dilakukan dalam method init().
3. Penanganan request, dilakukan oleh method service(). 4. Fase akhir, ditangani dalam method destroy().
Dalam praktik pada umumnya hanya dilakukan override terhadap
method init() dan destroy(). Inipun jika hal itu diperlukan mengingat override
keduanya tidak mutlak harus dilakukan.
2.5 JDBC
Menurut Prasetyo D. (2004), JDBC merupakan API Java Database
Connectivity dan merupakan bagian dari Java Enterprise APIs dari JavaSoft. Class
JDBC terdapat di dalam paket java.sql, dan semua program Java menggunakan
method serta objek dari paket tersebut untuk membaca serta menulis data source. JDBC memiliki DriverManager yang berfungsi untuk mengatur driver serta
menampilkan daftar driver yang pada program aplikasi. JDBC memungkinkan
untuk membuat aplikasi dengan Java dalam mengakses database server, baik itu secara lokal (stand-alone) maupun secara remote. JDBC API memudahkan untuk
mengirimkan perintah SQL ke sistem database relasional dan mendukung
Dengan menggunakan JDBC dapat dibuat program dengan portabilitas
tinggi dan cukup mudah karena secara umum pemrograman JDBC tidak memiliki
perbedaan kode yang berarti untuk pemrograman pada database tertentu dengan database lain. Perbedaan utama pada kode hanyalah kode yang mendefinisikan
driver dari database server serta perintah SQL tertentu yang mungkin memiliki perbedaan sintak atau perintah SQL khusus yang hanya terdapat pada database
tertentu. Pemrograman JDBC memiliki struktur seperti melakukan koneksi,
membuat object statement, mengeksekusi perintah SQL, mendapatkan hasil query, serta menangani error.
2.6 Metodologi FAST
Menurut Whitten (2001), Metode FAST (Framework for the Application of
Systems Thinking) merupakan sebuah hipotesis metodologi yang digunakan untuk mendemonstrasiakan wakil dari proses development systems. Fase – fase dari FAST adalah sebagai berikut:
1. Scope Definition
Tujuan dari scope definition ada dua. Pertama, adalah jawaban atas
pertanyaan “Apakah problem nampak berharga ? “. Kedua adalah “Asumsi bahwa problem adalah berharga, dengan penetapan ukuran dan batasan dari projek, visi proyek, konstrain dan limitation yang lain.
PIECES merupakan framework yang baik untuk dapat menentukan
problem statement. Problem statement bukanlah solusi masalah akan tetapi
2. Problem Analysis
Problem analysis adalah studi untuk sistem yang sekarang dan
menganalisa temuan-temuan untuk menyediakan informasi dengan lebih
memahami masalah yang ditrigger oleh proyek.
Hasil dari tahap ini yaitu sekumpulan system improvement objectives
(tujuan-tujuan peningkatan sistem) yang diperoleh melalui pemahaman
dari masalah bisnis.
3. Requirement Analysis
Tahap ini mendefinisikan dan memberi prioritas terhadap kebutuhan
sistem. Use-case diagram dapat digunakan untuk membantu
mendefinisikan kebutuhan sistem pada tahap ini.
4. Logical Design
Tahap ini menterjemahkan kebutuhan bisnis pemakai ke dalam sistem
model yang hanya memperhatikan kebutuhan bisnis dan tidak pada disain
technical atau implementasi dari kebutuhan tersebut.
5. Decision Analysis
Permasalahan yang dihadapi sistem biasanya dapat diselesaikan dengan
berbagai solusi. Dalam fase ini, system analyst bertugas untuk mencari dan menentukan solusi terbaik yang dapat digunakan untuk menyelesaikan
permasalahan yang dihadapi sistem. Pada tahap ini akan dilakukan
perbaikan model use case sehingga mampu menggambarkan lingkungan
implementasi, memodelkan interaksi kelas, perilaku, dan state yang
diagram kelas sehingga mampu menggambarkan lingkungan implementasi
dengan menggunakan diagram kelas design.
6. Physical Design and Integration
Tahap ini menterjemahkan kebutuhan bisnis user ke dalam sistem model yang menggambarkan implementasi teknik dari kebutuhan bisnis dari
kebutuhan bisnis user. Fokus tahap ini pada view yang berbasis dari sistem, yang meliputi (1) Physical Database design specification, (2)
Physical Business Process and Software Design Specification, dan (3)
Physical user and System Interface Specification. Ada 2 filosofi dalam tahap ini :
• Design by specification yaitu model sistem fisik dan detail spesifikasi
yang dihasilkan dari serangkaian penulisan (computer-generated)
blueprint untuk konstruksi.
• Design by Prototyping adalah suatu cara yang tidak lengkap tapi
merupakan aplikasi atau subsistem fungsional (prototypes) yang
dibangun dan didefinisikan berdasarkan feedback dari user dan designer lain.
7. Construction and Testing
Tujuan tahap ini yaitu (1) membangun dan menguji komponen sistem
apakah sudah sesuai dengan kebutuhan dan spesifikasi dari physical
8. Instalation and Delivery
Kegiatan – kegiatan yang dilakukan pada tahap ini adalah instalasi sistem,
training user, manual sistem, mengkonversi file dan database yang ada ke
dalam database yang baru, final testing, dan menyiapkan prosedur
konversi.
2.6.1 Use case diagram
Use case diagram adalah sebuah diagram yang menggambarkan interaksi antara sistem dan eksternal sistem dan user. Use case diagram berbasis grafik yang menggambarkan siapa yang menggunakan sistem dan dengan cara
bagaimana user berinteraksi dengan sistem. Berikut ini contoh use case diagram
sederhana:
Gambar 2. Use case diagram
tertera diatas , dibawah atau di dalam ellips. Berikut ini merupakan contoh simbol
use case:
Gambar 3. simbol use case
Actor adalah segala sesuatu yang dibutuhkan untuk berinteraksi dengan sistem untuk mengubah informasi. Dapat berupa orang, organisasi atau sistem informasi
yang lain atau juga suatu waktu kejadian. Berikut ini merupakan contoh actor:
Gambar 4. simbol actor
Temporal event adalah sebuah waktu kejadian yang ditrigger oleh user. Aktornya adalah waktu.
2.6.2 Sequential Diagram
Sequence Diagram adalah diagram UML yang memodelkan logika sebuah use case dengan cara menggambarkan interaksi pesan di antara
Gambar 5. Simbol Dalam Sequential Diagram
2.7 UML ( Unified Modelling Language )
Menurut Whitten (2004), UML merupakan konfensi pemodelan yang
digunakan untuk menentukan atau menggambarkan sebuah sistem software yang terkait dengan objek. UML tidak menentukan sebuah metode untuk
mengembangkan sistem tetapi hanya berupa notasi. UML memberikan Sembilan
diagram yang dikelompokan ke dalam lima group dengan sudut pandang yang
berbeda terhadap sebuah model sistem.
Berikut adalah pengelompokannya :
1. Use-Case Model Diagram
Use case diagram adalah sekumpulan diagram yang menggambarkan interaksi antara sistem dan eksternal sistem dan user. Use case secara
otomatis maupun manual dengan tujuan untuk melengkapi bisnis tunggal,
misalnya login ke sistem, manambah data barang, menghapus data barang,
dan sebagainya. Actor adalah segala sesuatu yang dibutuhkan untuk
berinteraksi dengan sistem untuk mengubah informasi.
2. Static Structure Diagram
Ada 2 diagram yang tergolong dalam kelompok ini yaitu:
a. Class diagram menggambarkan struktur dari objek sistem. Class diagram memperlihatkan class dalam sistem beserta relasi antara class. b. Object diagram sama dengan class diagram, tetapi lebih dari pada
menggambarkan class, object diagram memodelkan object instance
secara aktual, memperlihatkan nilai tertentu dari atribut instance.
Diagram ini tidak sering digunakan seperti class diagram tetapi
digunakan untuk membantu developer memahami struktur dari sistem. 3. Interaction Digaram
Interaction diagram memodelkan sebuah interaksi, yang berisi sekumpulan
objek dan relasinya, dan juga message yang dikirim antara objek dan
relasinya. Diagram ini memodelkan dinamic behaviour dari sistem. Ada dua diagram yaitu:
a.Sequence diagram menjelaskan interaksi objek yang disusun dalam suatu urutan waktu. Diagram ini secara khusus berasosiasi dengan use case.
b.Collaboration diagram sama dengan sequence diagram tetapi tidak berfokus pada timing atau ‘sequence’ dari message. Menggambarkan interkasi (collaboration) antar objek dalam format network. Antara
sequence diagram dan collaboration diagram bersifat isomorphic, yang berarti dapat melakukan transformasi satu bentuk ke bentuk yang
lainnya.
4. State Diagram
State diagram terdiri dari dua diagram yaitu:
a.Statechart diagram digunakan untuk model dinamic behaviour dari
particular object.
b.Activity diagram digunakan untuk menggambarkan aliran sequen dari aktifitas dari proses bisnis atau sebuah use case.
5. Implementation Diagram
Implementation diagram terdiri dari dua diagram:
a.Component diagram digunakan untuk menggambarkan organisasi dan
ketergantungan dari komponen sistem software. Component diagram
dapat digunakan utnuk memperlihatkan bagaimana kode program dibagi
ke dalam modul-modul (atau komponen).
2.8 RDBMS dan MySQL
Relational Database adalah suatu konsep database yang dimana tabel satu dengan tabel yang lainnya saling berhubungan atau mempunyai relasi, sehingga
pengaksesan data pada database dapat dilakukan dengan cepat dan efektif.
Menurut Nugroho, B. (2005), MySQL adalah sebuah program database
sever yang mampu menerima dan mengirimkan datanya dengan cepat, multiuser, serta menggunakan perintah standar SQL (Structured Query Language ). MySQL
merupakan sebuah database yang free, sehingga kita dapat dengan bebas
menggunakannya tanpa harus membeli atau membayar lisensi. Adapun kelebihan – kelebihan MySQL adalah sebagai berikut :
− MySQL sebagai Database Management System (DBMS).
− MySQL sebagai Relational Database Management System (RDBMS).
− MySQL bersifat open source atau gratis
MySQL merupakan database server dan merupakan database client. Mampu
menyimpan data berkapasitas sangat besar.
2.9 SQL
Menurut Nugroho, B( 2005) SQL (Struktur Query language) adalah sebuah bahasa permintaan database yang terstruktur. bahasaSQL dibuat sebagai bahasa
yang dapat merelasikan beberapa tabel dalam database. Bahasa SQL ditulis
langsung dalam sebuah program database sehingga seorang pengguna dapat
melihat langsung permintaan yang diinginkan, sekaligus melihat hasilnya.
1. DDL (Data Definition Language)
DDL adalah sebuah Metode Query SQL yang berguna untuk mendefinisikan
data pada sebuah database, adapun query yang dimiliki adalah :
-Create : Digunakan untuk melakukan pembuatan tabel dan database.
- Drop : Digunakan untuk melakukan penghapusan tabel maupun database.
- Alter : Digunakan untuk melakukan perubahan struktur tabel yang telah dibuat, baik menambah field (add), mengganti nama field (change),
ataupun menemakannya kembali (rename), serta menghapus (drop).
2. DML (Data Manipulation Language)
DML adalah sebuah Metode Query yang dapat digunakan apabila DDL telah
terjadi, sehingga fungsi dari query ini adalah untuk melakukan pemanipulasian
database yang telah ada atau telah dibuat sebelumnya. Adapun query yang
termasuk didalamnya adalah :
- Insert : Digunakan untuk melakukan penginputan/pemasukan data pada tabel datbase
-Update : Digunakan untuk melakukan perubahan atau peremajaan terhadap data yang ada pada tabel.
-Delete : Digunakan untuk penghapusan data pada tabel. Penghapusan ini dapat dilakukan secara sekaligus (seluruh isi tabel) maupun hanya
beberapa recordset.
2.10 ERD
relasi yang dijelaskan oleh data tersebut. Adapun beberapa konsep dasar dan
simbol-simbol yang mendasari semua model data, yaitu sebagai berikut :
a. Entitas (Entity)
Entitas adalah sebuah kumpulan dari orang, tempat, objek, kejadian atau
konsep yang diperlukan untuk men-capture atau menyimpan data.
Gambar 6. Simbol entitas
b. Atribut (Attribute)
Atribut merupakan sebuah properti yang deskriptif atau karakteristik dari
sebuah entitas. Sinonimnya adalah element, property, dan field.
Gambar7. Simbol Entitas dengan Atribut
c. Relasi (Relationship)
Relationship adalah sebuah asosiasi bisnis normal yang ada antara satu atau lebih entity. Relasi mungkin juga mewakili suatu kejadian yang
menghubungkan antara entity atau logika gabungan antara entity. Karena
semua hubungan bersifat dua arah, maka diperlukan kardinalitas yang
Student
Student Name
- Last Name
- First Name
Address
- Street
Address
- City
- State or
didefinisikan untuk setiap hubungan. Kardinalitas adalah jumlah minimum
dan maksimum kemunculan satu entitas yang mungkin dihubungkan dengan
kemunculan tunggal dari entitas lain.
Tabel 1 Notasi kardinalitas INTERPRESENTASI
KADINALITAS
CONTOH MINIMUM
CONTOH MAKSIMUM
NOTASI GRAFIS
Tepat satu
(satu dan hanya satu) 1 1
atau
Nol atau satu 0 1
Satu atau banyak 1 Banyak (>1) Atau
Nol atau banyak 0 >1 atau
Lebih dari satu >1 >1 Atau
d. Contoh Entity Relationship Diagram (ERD)
23
BAB III
ANALISIS DAN PERANCANGAN SISTEM
3.1 Analisis Sistem
3.1.1 Fase Definisi Ruang lingkup (Scope Definition)
RSU Kharisma Paramedika terletak di Jl. Khudori no.24 Wates,
Kulonprogo. Sistem konseling yang ada dalam RSU ini dilakukan secara manual
sehingga menyebabkan beberapa kesulitan. Adapun kesulitan – kesulitan tersebut
diuraikan menggunakan framework PIECES sebagai berikut:
Performance: dalam kinerja sistem lama, kuantitas pasien yang dapat ditangani
berkonsultasi lebih sedikit karena melakukan antri untuk konsultasi dan antri
untuk pemeriksaan sama.
Information: Informasi dalam sistem saat ini sudah mencukupi, akan tetapi
dengan adanya sistem baru, pasien dan sistem dapat menyimpan informasi
konsultasi yg berupa keluhan dan balasan.
Economics: Dari segi ekonomis, datang ke rumah sakit untuk berkonsultasi
membutuhkan biaya. Apabila konsultasi sering dilakukan, biaya yang
dikeluarkanpun akan bertambah besar.
Control: kadangkala data konsultasi tidak disimpan karena dianggap kurang
Eficiency: Sistem ini tidak effisien bagi pasien karena untuk berkonsultasi ke
rumah sakit membutuhkan waktu untuk perjalanan ke rumah sakit dan waktu
untuk antri jika banyak pasien yang datang.
Services: Pasien mendapatkan layanan konseling dengan cara datang ke rumah
sakit, kemudian antri untuk mendapatkan giliran konseling. Hal ini membutuhkan
waktu antri yang tidak sedikit.
3.1.2 Fase Analisis Masalah (Problem Analysis)
3.1.2.1Sistem yang ada saat ini
Sistem yang ada saat ini masih bersifat manual. Pasien yang akan
konsultasi dengan dokter pada poliklinik tertentu harus datang ke rumah sakit
untuk mendaftarkan diri dan mengambil nomor antrian. Pasien berinteraksi
dengan dokter dengan melakukan tanya jawab. Hasil konsultasi tidak dicatat
secara rinci, pencatatan hanya dilakukan untuk pemeriksaan rekam medis pasien.
Masing – masing poliklinik memiliki jadwal buka praktek seperti berikut ini:
1. Poliklinik umum
Hari : Senin sampai minggu
Pukul : 08.00 – 14.00, 14.00-20.00, dan 20.00 – 08.00.
2. Poliklinik kebidanan dan kandungan
Hari : Senin, Rabu, Jumat
Pukul : 10.00 – 12.00
3. Poliklinik telinga hidung tenggorokkan (THT)
Pukul : 13.00 – 14.00
4. Poliklinik penyakit dalam
Hari : Selasa, Rabu, dan Kamis
Pukul : 07.00 – 08.00
5. Poliklinik Syaraf
Hari : Jumat
Pukul : 13.00 – 14.00
Sistem
Konseling Pasien
Dokter Penjelasan pertanyaan Data pertanyaan
Jawaban pertanyaan pertanyaan
3.1.2.2Sebab Akibat (Cause – effect Analysis)
Tabel 2 Tabel Cause and Effect
Project : Aplikasi Pengaturan SMS Konseling Berbasis Open Source
Project Manager : Dya Sifa Salvatira
Created by : Dya Sifa Salvatira Last Update by : Dya Sifa Salvatira
Date Created : 12 November 2008 Date Last Update : 15 November 2008
CAUSE AND EFFECT ANALYSIS
SYSTEM IMPROVEMENT OBJECTIVES
Problem / Opportunity
Causes and effects
System objectives System constraint
1. Effisiensi waktu
pasien untuk
konsultasi dengan dokter.
1.Banyak pasien
yang akan
bertemu dengan dokter untuk periksa ataupun
konseling membutuhkan
waktu yang
tidak sedikit
1. Memberikan
pelayanan
konseling kepada
pasien melalui
SMS, sehingga
waktu pasien
lebih efisien.
1. Membutuhkan
perangkat lunak dan perangkat
keras untuk
mendukung berjalannya sistem baru.
2. Menambah daya
tarik RSU
Kharisma Paramedika. 1. RSU Kharisma Paramedika merupakan Rumah Sakit
yang masih
baru
1. Memberikan
daya tarik dan
pelayanan yang
lebih baik
melalui SMS
konseling kepada pasien.
1.Membutuhkan pelatihan penggunaan
sistem untuk
dokter.
3.1.2.3Gambaran Sistem Baru
Untuk menangani masalah – masalah diatas, maka akan dibuat sistem baru
(Studi Kasus: RSU Kharisma Paramedika). Sistem ini digunakan untuk aktifitas
konseling antara dokter dengan pasien. Selain itu sistem ini juga bertujuan untuk
menambah daya tarik dari RSU Kharisma Paramedika yang terbilang masih baru.
Dalam sistem yang baru ini, jika pengguna (Administrator dan Dokter)
akan menggunakan sistem, pengguna harus login terlebih dahulu. Sistem akan
mengecek apakah pengguna berhak atau tidak. Pada sistem ini, pengguna
mengisikan data sesuai dengan inputan yang diminta dalam sistem. Setelah itu
sistem akan memprosesnya secara otomatis untuk menyimpan ke dalam database
dan mengirimkan SMS sesuai dengan nomor yang dituju.
Sistem ini berbasis multiuser dan client server yang berfungsi sebagai
pengatur SMS yang masuk ke dalam sistem yang ditujukan ke poliklinik tertentu
berdasarkan ketentuan format yang ada. Aplikasi ini terdiri dari dua bagian yaitu
Aplikasi Server dan Aplikasi Client.
1. Aplikasi Server
Aplikasi server ini bertugas untuk menjalankan kebutuhan server misalnya
menyampaikan SMS yang masuk untuk account tertentu, membalas pesan
secara otomatis pada format yang telah ditentukan. Aplikasi ini digunakan oleh
Administrator.
2. Aplikasi Web
Aplikasi web merupakan user interface yang ditujukan untuk Dokter dan
Administrator. Melalui aplikasi ini Dokter dapat melihat inbox, outbox, dan
mengirimkan sms. Melalui aplikasi ini juga, administrator dapat melihat data
Sistem
Konseling Pasien
Dokter Penjelasan pertanyaan, data diri
Data pertanyaan
Jawaban pertanyaan Pertanyaan, SMS masuk, SMS keluar
Administrator
Laporan konseling, data poliklinik, data account
Gambar 10. Diagram Konteks Sistem Baru
3.1.2.4Orang Yang Terlibat Dalam Sistem
Pengguna yang terlibat di dalam sistem adalah sebagai berikut :
1. Administrator
Administrator merupakan orang yang bertugas untuk memanage
account Dokter, membuat laporan konseling, dan memanage keyword
SMS untuk masing-masing poliklinik.
2. Dokter
Dokter adalah orang yang bertugas untuk membalas SMS dari pasien
yang melakukan konseling dengannya. Masing-masing Dokter
memiliki poliklinik yang ditangani dalam konseling.
3. Pasien
Pasien merupakan orang yang berkonsultasi dengan dokter melalui
SMS. Pasien mengirimkan SMS ke sistem yang akan dilanjutkan
3.1.3 Fase Analisi Kebutuhan (Requirement Analysis)
3.1.3.1Use Case Diagram
login
lihat account tambah account
edit account hapus account
buat laporan
edit data account sendiri
kirim SMS lihat data inbox
lihat detil data inbox
lihat data outbox
lihat detil data outbox
logout
Aplikasi Pengaturan SMS Konseling
administrator dokter <<depends on>> Management account <<depends on>> edit poliklinik tambah poliklinik hapus polilklinik lihat poliklinik Management klinik
lihat history inbox
lihat history outbox
Paket dokter
run server
stop server
lihat detil account
cari pasien
lihat detil poliklinik
kirim pesan Sistem Penerima SMS
pasien daftar
3.1.3.2Use CaseDiagram Untuk Administrator
3.1.3.2.1 Use Case Diagram Untuk Management Account
Gambar 12.Use Case Diagram untuk Management Account
3.1.3.2.2 Use Case Diagram Untuk Management Klinik
Gambar13.Use case diagram untuk Management Klinik
lihat detil account
lihat account
edit account
tambah account Administrator
hapus account
lihat detil poliklinik
lihat poliklinik
edit poliklinik Administrator
tambah poliklinik
3.1.3.3Use casediagram untuk Paket Dokter
kirim sms
lihat data inbox
lihat detil data inbox
lihat data outbox
lihat detil data outbox
lihat histori inbox
lihat histori outbox dokter
Gambar 14.Use Case Diagram untuk Paket Dokter
3.1.3.4Narasi Use Case
3.1.3.4.1 Narasi Singkat Use Case
Nama aktor Keterangan
Administrator Orang yang mempunyai hak akses / kewenangan untuk melakukan penambahan, perubahan, penghapusan, melihat account dokter dan membuat laporan pada
sistem “Pengaturan SMS Konseling Berbasis
Opensource”.
Dokter Orang yang mempunyai hak akses untuk mengirim
SMS balasan yang ditujukan kepadanya dari pasien. Selain itu, dokter dapat merubah accountnya, melihat data inbox, melihat detil data inbox, melihat data outbox, melihat detil data outbox, dan melihat histori inbox dan outbox.
Pasien Orang yang mengirimkan pesan konseling untuk
3.1.3.4.2 Tabel Ringkasan Use Case
Tabel 3 Ringkasan Use Case
Nama use
case Keterangan Pelaku
login Melakukan proses otentifikasi pengguna
dengan memasukan poliklinik,
username dan password untuk dapat mengakses sistem dan database.
Administrator, Dokter
lihat account Melihat data – data account yang ada. Administrator tambah
account
Melakukan penambahan account ke
sistem untuk disimpan, sehingga
account baru dapat masuk ke dalam sistem.
Administrator
hapus account
Melakukan penghapusan account
dokter.
Administrator
edit account Melakukan perubahan data account Administrator dan account dokter.
Administrator
Lihat Detil Account
Melihat data detil account dokter Administrator
tambah poliklinik
Melakukan penambahan poliklinik ke sistem untuk disimpan.
Administrator
edit poliklinik
Melakukan perubahan data poliklinik. Administrator
lihat poliklinik
Melihat data – data poliklinik yang ada. Administrator
hapus poliklinik
Melakukan penghapusan poliklinik. Administrator
Lihat detil poliklinik
Melihat data detil poliklinik Administrator
run server Menjalankan server Administrator
stop server Menghentikan server Administrator
buat laporan Membuat laporan konseling secara berkala setip bulan, tentang pengiriman SMS (outbox) yang telah terjadi.
Administrator
edit data account
sendiri
NAMA USE CASE: Login
Author : Dya Sifa Salvatira Date: 15/11/2008
Version: 1.00
USE CASE NAME: Login USE CASE TYPE
USE CASE ID: US.SMS001 Business Requirements:
PRIORITY: High
1.1.1.1.1 SOURCE:
kirim SMS Mengirim pesan untuk membalas pesan dari pasien yang ditujukan ke padanya.
Dokter
lihat data inbox
Melihat data inbox yang ditujukan ke accountnya. Data inbox berisi daftar – daftar pesan yang masuk.
Dokter
lihat detil data inbox
Melihat detil data inbox yang ditujukan kepadanya. Detil data inbox berisi pesan text dari suatu nomor tertentu.
Dokter
lihat data outbox
Melihat data outbox yang ditujukan ke accountnya. Data outbox berisi daftar – daftar pesan yang telah dikirim.
Dokter
lihat detil data outbox
Melihat detil data outbox yang telah dikirim olehnya. Detil data outbox berisi pesan text untuk suatu nomor tertentu.
Dokter
lihat histori inbox
Melihat data – data sms masuk dari nomor yang dipilih.
Dokter
lihat histori outbox
Melihat data – data sms keluar dari nomor yang dipilih.
Dokter
logout Keluar dari sistem Administrator,
Dokter Kirim pesan Mengirimkan pesan untuk dokter yang
akan disampaikan oleh sistem
Pasien
Daftar Mendaftarkan diri untuk mendapatkan idPasien
PRIMARY
BUSINESS ACTOR:
Administrator, Dokter
DESCRIPTION: Use case ini mendeskripsikan proses masuk ke dalam sistem dan mengakses database.
PRE-CONDITION: User telah memiliki username, password dan tipe login.
TRIGGER: Use case ini dilakukan ketika user memasukkan username, tipe login dan password.
TYPICAL COURSE
OF EVENTS:
Actor Action System Response
Step 1: user membuka halaman login sistem
Step 2: sistem
menampilkan halaman login.
Step 3: mengisi
username, dan
password.
Step 4 : mencocokkan
username, dan password
ke database.
Step 5: bila inputan sesuai, sistem
menampilkna halaman utama dokter.
ALTERNATE COURSES:
Alternate Step 3 : user mengklik tombol [batal] untuk membatalkan proses login.
Alternate Step 4 : bila inputan tidak sesuai dengan yang tersimpan di dalam database, maka sistem akan menampilkan pesan error. Proses kembali ke step 2.
Alternate Step 5 : apabila hak akses pengguna adalah administrator, sistem menampilkan halaman utama administrator.
CONCLUSION: Hanya user yang memiliki account yang dapat masuk ke sistem.
POST-CONDITION:
User akan masuk ke halaman utama.
BUSINESS RULES User harus memasukkan username dan password
dengan benar.
N CONTRAINTS AND
SPECIFICATIONS
- Dapat diakses oleh user yang memiliki hak akses.
NAMA USE CASE : lihat account
Author: Dya Sifa Salvatira Date: 15/11/2008
Version: 1.00
USE CASE NAME: lihat account USE CASE TYPE
USE CASE ID: UC.SMS002 Business Requirements:
PRIORITY: Medium
1.1.1.1.2 SOURCE:
PRIMARY
BUSINESS ACTOR:
Administrator
DESCRIPTION: Use case ini mendeskripsikan proses untuk melihat data account dokter yang ada.
PRE-CONDITION: User telah berada di halaman utama Administrator.
TRIGGER: Use case ini dilakukan ketika User ingin melihat data account yang diinginkan.
TYPICAL COURSE
OF EVENTS:
Actor Action System Response
Step 1: mengklik tombol [akun dokter].
Step 2: sistem
menampilkan halaman data dokter.
ALTERNATE COURSES:
CONCLUSION: Sistem hanya akan menampilkan data sesuai dengan pilihan user.
POST-CONDITION:
User masuk ke halaman utama administrator.
masuk ke halaman daftar dokter.
IMPLEMENTATIO N CONTRAINTS AND
SPECIFICATIONS
Dapat diakses oleh user yang telah login yang memiliki hak akses .
NAMA USE CASE : tambah account
Author : Dya Sifa Salvatira Date: 15/11/2008
Version: 1.00
USE CASE NAME: tambah account USE CASE TYPE
USE CASE ID: UC.SMS003 Business Requirements:
PRIORITY: High
1.1.1.1.3 SOURCE:
PRIMARY
BUSINESS ACTOR:
Administrator
DESCRIPTION: Use case ini mendeskripsikan proses penambahan data account untuk dokter yang akan diproses oleh sistem.
PRE-CONDITION: User telah berada di halaman account dokter.
TRIGGER: Use case ini dilakukan ketika user ingin melakukan tambah account dokter.
TYPICAL COURSE
OF EVENTS:
Actor Action System Response
Step 1: memilih tombol [Tambah]
Step 2: sistem
menampilkan halaman tambah dokter.
Step 3: mengisi data dokter pada kolom yang tersedia.
Step 4: Sistem
ALTERNATE COURSES:
Alternate Step 3: user mengklik tombol [reset] untuk mengosongkan kolom – kolom yang sudah terisi menjadi kosong kembali pada keadaan semula.
CONCLUSION: Sistem hanya akan menerima inputan data yang sesuai untuk tiap – tiap pemrosesan data.
POST-CONDITION:
User masuk ke pesan berhasil hapus.
BUSINESS RULES User harus memasukan data dengan tipe yang sesuai.
IMPLEMENTATIO N CONTRAINTS AND
SPECIFICATIONS
- Harus dapat menginputkan data apabila telah melalui proses login.
- Dapat diakses oleh user administrator yang telah login.
NAMA USE CASE : hapus account
Author : Dya Sifa Salvatira Date: 15/11/2008
Version: 1.00
USE CASE NAME: hapus account USE CASE TYPE
USE CASE ID: UC.SMS004 Business Requirements:
PRIORITY: High
1.1.1.1.4 SOURCE:
PRIMARY
BUSINESS ACTOR:
Administrator
DESCRIPTION: Use case ini mendeskripsikan proses penghapusan data account untuk dokter yang akan diproses oleh sistem.
TRIGGER: Use case ini dilakukan ketika user ingin melakukan hapus account dokter.
TYPICAL COURSE
OF EVENTS:
Actor Action System Response
Step 1: memilih data account yang akan dihapus, kemudian klik tombol [HAPUS]
Step 2: sistem
menghapus data account yang telah dipilih.
Step 3: sistem menampilkan pesan bahwa data berhasil dihapus..
ALTERNATE COURSES:
-
CONCLUSION: Sistem hanya akan menerima inputan data yang telah dipilih untuk pemrosesan penghapusan data.
POST-CONDITION:
User berada di halaman sukses hapus .
BUSINESS RULES User harus memasukan data dengan tipe yang sesuai.
IMPLEMENTATIO N CONTRAINTS AND
SPECIFICATIONS
- Harus dapat menginputkan data apabila telah melalui proses login.
NAMA USE CASE : edit account
Author: Dya Sifa Salvatira Date: 15/11/2008
Version: 1.00
USE CASE NAME: edit account USE CASE TYPE
USE CASE ID: UC.SMS005 Business Requirements:
PRIORITY: High
1.1.1.1.5 SOURCE:
PRIMARY
BUSINESS ACTOR:
Administrator
DESCRIPTION: Use case ini mendeskripsikan proses edit data account dokter yang telah ada pada database.
PRE-CONDITION: User telah berada di halaman akun dokter.
TRIGGER: Use case ini dilakukan ketika User ingin melakukan pengeditan data account.
TYPICAL COURSE
OF EVENTS:
Actor Action System Response
Step 1: memilih data account yang akan diedit, kemudian klik simbol tombol [edit]
Step 2: sistem
menampilkan data yang akan diedit pada kolom – kolom yang tersedia.
step 3: merubah data yang telah
ditemukan,
kemudian klik [Edit]
Step 4: Sistem melakukan edit data, dan
menyimpannya ke dalam database.
Step 5: Sistem
menampilkan pe
