BAB III PEMBAHASAN 3.1 Jadwal Kerja Praktek Berdasarkan surat balasan kerja praktek dari Rumah Sakit Umum Pantura M.A Sentot Patrol Indramayu tanggal 27 Juli 2009 dengan nomor: 319/109/RSU Pantura, kerja praktek dilaksanakan selama kurang lebih satu bulan terhitung dari tanggal 3 29 Agustus 2009, dalam hal ini kerja praktek dilaksanakan setiap hari Senin sampai dengan hari Jumat, dimulai pada pukul 09.00 WIB sampai dengan pukul 15.00 WIB, atau tergantung situasi dan kebutuhan terutama untuk mendapatkan data dan informasi yang dibutuhkan untuk menyelesaikan program yang akan dibuat. 3.2. Teknik Kerja Praktek Cara pelaksanaan kerja praktek adalah dengan datang langsung ke Rumah Sakit Patrol sesuai dengan jam kerja yang telah ditetapkan atau ditentukan oleh Rumah Sakit tersebut, dan mulai mengikuti kegiatan pada hari itu seperti yang diberitahukan oleh pebimbing lapangan kerja praktek. Adapun teknik pengumpulan data yang dilakukan adalah sebagai berikut : 14
15 1. Wawancara (Interview). Kegiatan tanya jawab secara langsung kepada para pegawai dan para staf tentang hal-hal yang berhubungan dengan operasional kerja dimana penulis ditempatkan. 2. Pengamatan Langsung (Observasi). Kegiatan mengamati dan mempelajari secara langsung data-data yang ada di bagian dimana penulis ditempatkan. 3. Praktek (Practice). Kegiatan melakukan pengolahan data dari data yang sudah ada kedalam suatu aplikasi Website yaitu dengan menggunakan PHP-MySQL dengan Macromedia Dreamweaver sebagai tool pendukungnya 4. Pustaka (Library Research). Dalam mengerjakan laporan kerja praktek ini, penulis melakukan library research, untuk memperoleh informasi yang berhubungan dengan materi laporan kerja praktek melalui buku-buku, bahan kuliah dan bacaan lainnya yang memiliki relevansi dengan aplikasi yang akan dibuat
16 3.3 Data Kerja Praktek 3.3.1 Deskripsi Global Perangkat Lunak Pada deskripsi global perangkat lunak terdiri dari : 1. Perspektif Produk Aplikasi Data Berobat Pasien dibuat dengan menggunakan PHP dan MySQL (sebagai databasenya), data yang akan diolah akan tersimpan dan terintegrasi dengan baik. Sehingga petugas dapat menyimpan data-data yang dianggap penting kedalam database dengan aman. 2. Fungsi Produk Aplikasi Rekam Medik dibuat untuk membantu seorang dokter dan asisten administrasi (petugas pendaftaran) dalam mencatat, mencari dan melihat kembali riwayat klinis seorang pasien dengan cepat tanpa menggunakan kartu riwayat klinis yang secara fisik sangat merepotkan untuk penyimpanan dan pencariannya dibandingkan dengan menggunakan program komputer.
17 3.3.2 Deskripsi Rinci Kebutuhan 3.3.2.1 Kebutuhan Non Fungsional Spesifikasi kebutuhan non fungsioanal adalah spesifikasi yang rinci tentang hal-hal yang akan dilakukan system ketika diimplementasikan serta komponen-komponen yang akan dilibatkan pada system yang akan dibangun. Kebutuhan non fungsional terdiri dari : 1. Karakteristik Pengguna 2. Kebutuhan Pemakaian 3. Kebutuhan Perangkat Keras 4. Kebutuhan Perangkat Lunak 5. Prosedur Sistem Lama 6. Kebutuhan Basis Data 3.3.2.1.1 Karakteristik Pengguna Aplikasi ini akan digunakan oleh administrator (admin) bisa melakukan manipulasi data apa saja (tambah, edit, hapus), dokter dan asisten administrasi (petugas pendaftaran) dalam memasukkan data pendaftaran pasien (Hanya Pendaftaran) yang terhubung dengan komputer yang ada di ruang dokter sehingga dokter tidak perlu lagi mencari data pasien yang akan diperiksa.
18 3.3.2.1.2 Kebutuhan Pemakaian a. Sistem harus dapat membantu mempermudah proses rekam medis. b. Sistem harus dapat memberikan informasi tentang data pasien dengan cepat dan akurat. c. Sistem harus dapat dioperasikan oleh administrator. d. Semua proses rekam medis harus terintegrasi dalam database. 3.3.2.1.3 Kebutuhan Perangkat Keras Kebutuhan perangkat keras merupakan analisis terhadap kemampuan perangkat keras untuk menjalankan system yang akan dibangun. Adapun perangkat keras yang dibutuhkan system, minimal memiliki spesifikasi sebagai berikut : a. Processor : Pentium III (600 MHz) b. Memory : 256 MB c. Hardisk : 20 GB d. Monitor : 15 inchi 3.3.2.1.4 Kebutuhan perangkat lunak Kebutuhan perangkat lunak merupakan analisis kemampuan perangkat lunak untuk menjalankan system yang akan dibangun. Adapun perangkat lunak yang dibutuhkan system, minimal memiliki spesifikasi sebagai berikut :
19 Tabel 3.1 Spesifikasi perangkat lunak No. Jenis perangkat lunak Keterangan 1 Sistem Operasi Windows XP 2 Webserver Apache2 3 Database MySQL 5.0.18, phpmyadmin 2.7.0 3.3.2.1.5 Prosedur Sistem Lama Prosedur merupakan urutan dari langkah-langkah yang terjadi atau yang dilakukan pada sistem yang sedang berjalan. Adapun prosedur pada sistem yang sedang berjalan yaitu : 1) Prosedur pencarian data pasien Pencarian data pasien bertujuan untuk memberikan informasi tentang data pasien. Adapun langkah-langkahnya sebagai berikut : a. Pasien / keluarga pasien memberikan kartu berobat kepada petugas pendaftaran. b. Petugas pendaftaran mencarikan data / buku kemajuan kesehatan pasien. c. Setelah data / buku kemajuan kesehatan pasien ditemukan, kartu berobat di kembalikan ke pasien. Selanjutnya data / buku kemajuan kesehatan pasien diserahkan ke dokter untuk dicatatkan kemajuan kesehatannya. d. Data pasien yang sudah terisi oleh dokter, diserahkan kembali ke petugas pendaftaran sebagai arsip.
20 Pasien/Keluarga pasien Petugas Dokter Kartu Berobat Kartu Berobat Kartu Berobat Mencari data / buku kesehatan pasien Data / buku kemajuan kesehatan pasien Data / buku kemajuan kesehatan pasien Mengisi data / buku kesehatan pasien Data / buku kemajuan kesehatan pasien yang sudah terisi Data / buku kemajuan kesehatan pasien yang sudah terisi A Gambar 3.1 Flowmap Pencarian Data Pasien
21 3.3.2.1.6 Kebutuhan Basis Data Perancangan proses sistem ini meliputi Entity Relation Diagram (ERD) yang berfungsi untuk menjelaskan aliran data yang diproses sehingga dapat menghasilkan informasi yang diharapkan. Komponen utama pembentukan Entity Relationship Diagram atau biasa disebut Diagram E-R yaitu Entity (entitas) dan Relation (relasi) sehingga dalam hal ini Diagram E-R merupakan komponen-komponen himpunan entitas dan himpunan relasi yang dideskripsikan lebih jauh melalui sejumlah atribut-atribut (property) yang menggambarkan seluruh fakta dari system yang ditinjaau. Adapun Diagram E-R dari sitem dapat digambarkan sebagai berikut:
22 Gambar 3.2 Entity Diagram Relationship (ERD) Kamus data pada diagram Entity Diagram Relationship (ERD) : 1. T_login (userid, passid, ahir_login) 2. T_admin (id_admin, userid, passid) 3. T_petugas (id_ptgs, nama_ptgs, jenis_kelamin) 4. T_dokter (id_dokter, nama_dokter, spesialis) 5. T_pasien (id_psn, nama_psn, alamat, telp)
23 3.3.2.2 Kebutuhan Fungsional Kebutuhan fungsional dilakuakan untuk menghasilkan spesifikasi kebutuhan fungsional. Spesifikasi kebutuhan fungsional adalah spesifikasi yang rinci tentang hal-hal yang akan dilakukan pada saat imlementasi sistem. Berikut ini adalah kebutuhan fungsional system : 1. Context Diagram 2. Data Flow Diagram (DFD) 3. Process Spesification (PSPEC) 4. Data Dictionary (DD) 3.3.2.2.1 Context Diagram Kebutuhan-kebutuhan pemakai yang ada akan diubah kedalam model-model yang terstruktur yang dapat dimengerti dan menjadi suatu referensi bagi tahap pengembangan selanjutnya. Salah satu model tersebut adalah Diagram Konteks (Context Diagram) yang menggambarkan hubungan suatu sistem dengan lingkungan luarnya atau pengguna. Diagram konteks menggambarkan suatu sistem informasi secara global, termasuk aliran data dari masukan (input) ke proses kegiatan (process), dari proses ke proses, dan dari proses ke luaran (output) menjadi sebuah informasi yang terpadu. Untuk memudahkan proses penggambaran sistem maka terlebih dahulu dibuat diagram konteks terhadap sistem yang akan dibangun.
24 Gambar 3.3 Diagram Konteks Sistem 3.3.2.2.2 Data Flow Diagram (DFD) Data Flow Diagram (DFD) adalah suatu model logika data atau proses yang dibuat untuk menggambarkan dari mana asal data dan kemana tujuan data yang keluar dari sistem, dimana data disimpan, proses apa yang menghasilkan data tersebut dan interaksi antara data yang tersimpan dan proses yang dikenakan pada data tersebut. Data Flow Diagram (DFD) sering digunakan untuk menggambarkan suatu sistem yang telah ada atau sistem baru yang akan dikembangkan secara logika tanpa mempertimbangkan lingkungan fisik dimana data tersebut mengalir atau dimana data tersebut akan disimpan. Berikut adalah Data Flow Diagram (DFD) dari aplikasi yang akan dibangun :
25 3.3.2.2.2.1 Data Flow Diagram Level 0 Gambar 3.4 DFD Level 0
26 3.3.2.2.2.2 Data Flow Diagram Level 1 Proses 1 Login Gambar 3.5 DFD Level 1 Proses 1 Login
27 3.3.2.2.2.3 Data Flow Diagram Level 1 Proses 2 Manipulasi Data Dokter Gambar 3.6 DFD Level 1 Proses 2 Manipulasi Data Dokter
28 3.3.2.2.2.3 Data Flow Diagram Level 1 Proses 3 Manipulasi Data Petugas Gambar 3.7 DFD Level 1 Proses 3 Manipulasi Data Petugas
29 3.3.2.2.2.3 Data Flow Diagram Level 1 Proses 5 Manipulasi Data Pasien Gambar 3.8 DFD Level 1 Proses 5 Manipulasi Data Pasien
30 3.3.2.2.3 Process Spesification (PSPEC) Tabel 3.2 Process Spesification (PSPEC) No Proses Keterangan No. Proses 1 Nama Proses Login data login info login gagal 1 Proses Admin, petugas, dan dokter memasukkan userid dan passid. Jika userid dan passid benar maka admin, petugas dan dokter melanjutkan ke proses selanjutnya. Jika userid dan passid salah maka akan muncul info. 2 3 4 5 No. Proses 2 Nama Proses Manipulasi Data Dokter data manipulasi dokter info manipulasi dokter Logika Proses Admin dapat melakukan tambah data dokter, ubah data dokter, dan hapus data dokter. Semua data dokter disimpan di t_dokter. No. Proses 3 Nama Proses Manipulasi Data Petugas data manipulasi Petugas info manipulasi petugas Logika Proses Admin dapat melakukan tambah data petugas, ubah data petugas, hapus data petugas. Semua data petugas disimpan di t_petugas No. Proses 4 Nama Proses Update kondisi pasien data kondisi pasien info kondisi pasien Logika Proses Dokter melakukan update kondisi pasien, setelah pasien selesai diperiksa. Semua data kondisi pasien yang telah diupdate disimpan di t_pasien. No. Proses 5 Nama Proses Manipulasi data pasien data manipulasi pasien info manipulasi pasien Logika Proses Petugas dapat melakukan tambah data pasien, ubah data pasien, hapus data pasien dan cari data
31 pasien. Semua dta pasien disimpan di t_pasien. 6 7 8 9 10 11 No. Proses 1.1 Nama Proses Login Admin data login admin data login admin tidak valid, login admin valid Logika Proses Jika data valid maka menuju proses 3,4. Jika tidak valid maka akan muncul info login gagal. No. Proses 1.2 Nama Proses Login Dokter data login dokter data login dokter tidak valid, login dokter valid Logika Proses Jika data valid maka menuju proses 5. Jika tidak valid maka akan muncul info login gagal. No. Proses 1.3 Nama Proses Login Petugas data login petugas data login petugas tidak valid, login petugas valid Logika Proses Jika data valid maka menuju proses 6. Jika tidak valid maka akan muncul info login gagal. No. Proses 2.1 Nama Proses Tambah Data Dokter data tambah info data tambah Logika Proses Admin memasukkan data ke form tambah data dokter, setelah semua data ditambah maka data dokter yang telah ditambah akan disimpan di t_dokter. No. Proses 2.2 Nama Proses Ubah Data Dokter ubah data info ubah data Logika Proses Admin mengubah data dokter ke form tambah data dokter, setelah semua data diubah maka data dokter yang telah diubah akan disimpan di t_dokter. No. Proses 2.3 Nama Proses Hapus Data Dokter hapus data info hapus data
32 Logika Proses Admin akan menghapus data dokter, setelah semua data dihapus maka data dokter yang telah dihapus akan disimpan di t_dokter. 12 13 14 15 16 No. Proses 3.1 Nama Proses Tambah Data Petugas data tambah info tambah data Logika Proses Admin memasukkan data ke form tambah data petugas, setelah semua data ditambah maka data petugas yang telah ditambah akan disimpan di t_petugas. No. Proses 3.2 Nama Proses Ubah Data Petugas ubah data info ubah data Logika Proses Admin dapat mengubah data ke form ubah data petugas, setelah semua data diubah maka data petugas yang telah diubah akan disimpan di t_petugas. No. Proses 3.3 Nama Proses Hapus Data Petugas hapus data info hapus data Logika Proses Admin dapat menghapus data petugas, setelah semua data dihapus maka data petugas yang telah dihapus akan disimpan di t_petugas. No. Proses 5.1 Nama Proses Tambah Data Pasien data tambah info tambah data Logika Proses Petugas memasukkan data ke form tambah data pasien, setelah semua data ditambah maka data pasien yang telah ditambah akan disimpan di t_pasien. No. Proses 5.2 Nama Proses Ubah Data Pasien ubah data info ubah data Logika Proses Petugas dapat mengunbah data ke form ubah data pasien, setelah semua data diubah maka data
33 pasien yang telah diubah akan disimpan di t_pasien. 17 18 No. Proses 5.3 Nama Proses Hapus Data pasien hapus data info hapus data Logika Proses Petugas dapat menghapus data ke form hapus data pasien, setelah semua data dihapus maka data pasien yang telah dihapus akan disimpan di t_pasien. No. Proses 5.4 Nama Proses Cari Data Pasien data cari info data cari Logika Proses Petugas dapat menghapus data pasien, setelah semua data dihapus maka data pasien yang telah dihapus akan disimpan di t_pasien. 3.3.2.2.4 Data Dictionary (DD) Kamus Data (Data Dictionary) merupakan media penyimpanan dari elemen-elemen yang berada dalam satu sistem. Kamus data mempunyai fungsi yang sama dalam pemodelan sistem dan juga berfungsi membantu pelaku sistem untuk mengerti aplikasi secara detail, dan mereorganisasi semua elemen data yang digunakan dalam sistem sehingga pemakai dan penganalisa sistem punya dasar pengertian yang sama tentang masukan, keluaran, penyimpanan dan proses. Kamus data dalam aplikasi yang akan dibangun adalah sebagai berikut :
34 Tabel 3.3 Kamus Data data login (admin) Nama Deskripsi Struktur data @userid Passid : data login (admin) : berisikan data userid dan passid : @userid + passid : [ A Z a - z 0 9 ] : [ A Z a - z 0 9 ] Tabel 3.4 Kamus Data data edit (admin) Nama Deskripsi Struktur data @userid Passid Nama_situs Logo : data edit (admin) : berisikan data userid, passid, nama_situs_logo : @userid + passid + nama_situs + logo : [ A Z a - z 0 9 ] : [ A Z a - z 0 9 ] : [ A Z a - z] : [ A Z a - z 0 9 ] Tabel 3.5 Kamus Data data dokter Nama Deskripsi Struktur data Nama_dokter Spesialis : data dokter : berisikan data nama_dokter, spesialis : nama_dokter + spesialis : [ A Z a - z] : [ A Z a - z] Tabel 3.6 Kamus Data data tambah dokter Nama Deskripsi Struktur data @id Id_dokter Nama_dokter spesialis : data tambah dokter : berisikan data id, id_dokter, nama_dokter, spesialis : @id + id_dokter + nama_dokter + spesialis : [0 9 ] : [ 0 9 ] : [ A Z a - z] : [ A Z a - z] Tabel 3.7 Kamus Data login dokter Nama Deskripsi Struktur data @userid Passid : data login (dokter) : berisikan data userid dan passid : @userid + passid : [ A Z a - z 0 9 ] : [ A Z a - z 0 9 ]
35 Tabel 3.8 Kamus Data data petugas Nama Deskripsi Struktur data @id Id_petugas Nama_petugas : data petugas : berisikan data id, id_petugas, nama_petugas : @id + id_petugas + nama_petugas : [0 9 ] : [0 9 ] : [ A Z a - z] Tabel 3.9 Kamus Data login petugas Nama Deskripsi Struktur data @userid Passid : data login (petugas) : berisikan data userid dan passid : @userid + passid : [ A Z a - z 0 9 ] : [ A Z a - z 0 9 ] Tabel 3.10 Kamus Data pasien Nama : data cari data pasien Deskripsi : berisikan data id, id_pasien, nama_pasien, jenis_kelamin, gol-darah, alamat Struktur data : @id + id_pasien+ nama_pasien + jenis_kelamin + gol_darah + alamat @id : [0 9 ] Id_pasien : [0 9 ] Nama_pasien : [ A Z a - z] Jenis_kelamin : [ A Z a - z] Gol_darah : [ A Z a - z] Alamat : [ A Z a - z]
36 3.3.2.3 Perancangan Database 3.3.2.3.1 Skema Relasi Secara umum, sasaran perancangan database adalah menghasilkan himpunan skema relasi yang mengijinkan pengguna untuk menyimpan informasi-informasi tanpa redundansi yang tidak dikehendaki (meminialisasi redundansi) serta yang mengijinkan pengguna untuk mencari informasi yang dikehendaki dengan cara yang mudah. Salah satu pendekatan yang dapat digunakan adalah merancang relasi-relasi menjadi bentuk normal (normal form). Untuk menentukan skema suatu relasi ada dalam bentuk normal yang dikehendaki, kita perlu tambahan informasi dari kondisi sistem yang kita modelkan. Pada gambar di bawah ini dapat dilihat skema relasi yang akan dibangun. Gambar 3.8 Skema Relasi antar Tabel
37 3.3.2.3.2 Struktur Tabel Struktur tabel yang akan dibangun dalam pembuatan sistem ini adalah sebagai berikut: 1. Tabel t_admin Tabel 3.11 Struktur Tabel t_admin No. Nama Field Type Ukuran Keterangan 1 Userid Varchar 10 Primary Key 2 Passid Varchar 255 2. Tabel t_login Tabel 3.12 Struktur Tabel t_login No. Nama Field Type Ukuran Keterangan 1 Id_login Int 11 Primary Key 2 Userid Varchar 50 Foreign Key 3 Passid Varchar 255 4 Ahir_login Datetime 3. Tabel t_petugas Tabel 3.13 Struktur Tabel t_petugas No. Nama Field Type Ukuran Keterangan 1 Id_petugas Int 11 Primary Key 2 Userid Varchar 50 Foreign Key 3 Passid Varchar 255 4 Nama_petugas Varchar 100
38 4. Tabel t_dokter Tabel 3.14 Struktur Tabel t_dokter No. Nama Field Type Ukuran Keterangan 1 Id_petugas Int 11 Primary Key 2 Userid Varchar 50 Foreign Key 3 Passid Varchar 255 4 Nama_dokter Varchar 100 5. Tabel t_pasien Tabel 3.15 Struktur Tabel t_pasien No. Nama Field Type Ukuran Keterangan 1 Id_pasien int 11 Primary Key 2 Nama_pasien Varchar 100 3 Jenis_kelamin Varchar 10 4 Gol_darah Char 2 5 Alamat Tinytext
39 3.3.2.4 Perancangan Antar Muka Pearancangan antar muka menjelaskan tampilan kasar dari program yang akan dibangun. 3.3.2.4.1 Perancangan Antar Muka Aplikasi 1. Antar Muka Login Dokter 2. Antar Muka Home Dokter
40 3.Antar Muka Cari Data Pasien 4.Antar Muka Seting 5. Antar Muka Logout Dokter LOGO - header? Logout Menu Dokter? OK Cancel
41 6.Antar Muka Login Admin T1 LOGO-header Klik tombol login, maka akan menuju ke proses T2 Klik tombol admin maka akan menuju ke menu admin Jika login gagal, maka akan muncul pesan M1 username password login Main page M1 Footer 7.Antar Muka Home Admin
42 8.Antar Muka Seting Akun Admin 9. Antar Muka Logout Admin LOGO - header? Logout Menu Admin? OK Cancel