BAB III ANALISIS DAN PERANCANGAN SISTEM. Bangun Sistem Informasi Monitoring dan Evaluasi Pelaksanaan Program

47

BAB III ANALISIS DAN PERANCANGAN SISTEM

Pada bab ini membahas tentang identifikasi permasalahan, analisis permasalahan, solusi permasalahan dan perancangan sistem dalam Rancang Bangun Sistem Informasi Monitoring dan Evaluasi Pelaksanaan Program Tuberkulosis Berbasis Web. Dalam melakukan identifikasi dan analisis permasalahan menggunakan teknik wawancara dan observasi yang dilakukan di Dinas Kesehatan Kota Surabaya. Adapun hasil dari wawancara dan observasi berikut ini.

3.1 Identifikasi Permasalahan Identifikasi permasalahan dilakukan pada saat maupun setelah proses wawancara pada perusahaan dilakukan, identifikasi dilakukan yaitu untuk menemukan titik permasalahan yang terjadi pada perusahaan. Analisis yang dilakukan yaitu menggunakan model value chain. Model value chain merupakan model yang akan digunkan untuk menganalisis aktifitas-aktifitas spesifik bisnis yang terjadi yang akan menciptakan nilai dan keuntungan kompetitif bagi organisasi. Pada setiap langkah yang diambil pada suatu segmen, akan berdampak pada keseluruhan proses. Jadi dapat dikatakan bahwa setiap segmen saling memiliki keterkaitan dengan yang lain. Dengan melakukan analisis mulai dari aktivitas Inbound Logistic sampai Service, akan diperoleh sebuah kesimpulan bahwa permasalahan utama yang terjadi pada Dinkes Kota Surabaya adalah pada bagian outbound logistic. Dimana

48

pada saat ini pada Dinkes Kota Surabaya belum tersedia bentuk penyajian monitoring secara realtime sehingga untuk mengetahui adanya perubahan membutuhkan waktu yang lama. Permasalahan lain adalah pada saat melakukan evaluasi tidak dapat segera dilakukan. Tahapan selanjutnya adalah dengan melakukan analisis permasalahan. Analisis permasalahan digunakan untuk mendefinisikan suatu permasalahan dan cara mengatasi permasalahan tersebut. Dari hasil pengumpulan data yang dilakukan, diketahui beberapa dokumen mengenai peran (role), tanggung jawab (responsibility), aturan (rule), kebijakan (policy) serta stakeholder atau pengguna yang terlibat dengan sistem yang sudah ada saat ini, yaitu Petugas TB, Wasor TB, dan KaSIE P2M. Untuk penjelasan lengkapnya dapat dilihat pada lampiran 3 Secara garis besar proses bisnis perencanaan monitoring dan evaluasi pada Dinas Kesehatan dimulai dari pencatatan form harian yang dilakukan oleh pihak Petugas TB yang dilanjutkan dengan monitoring dan pengelolaan data yang dilakukan oleh Wasor TB, dan proses evaluasi yang dilakukan oleh KaSIE P2M Dinkes Kota Suarabaya. Sebelum menggambarkan proses bisnis menggunakan desain flowchart, perlu diketahui terlebih dahulu mengenai peran (role), aturan (rule) dan kebijakan (policy) yang ada pada perusahaan, lebih lengkapnya bisa dilihat pada tabel 3.1. Tabel 3.1 Proses Bisnis Bredasarkan Stakeholder Stakeholder Petugas TB

Proses Bisnis Mencatat form harian

Phase Rule 1 R.1. pasien positif

policy -

49

Stakeholder Wasor TB

Proses Bisnis Monitoring

Phase Rule 2. R.2. proporsi pasien TB BTA positif diantara suspek 5-15 %

policy _

R.3. proporsi pasien TB paru BTA positif diantara pasien diobati < 65% R.4.angka konversi <80%

KaSIE P2M

evaluasi

3.

R.5. angka kesembuhan <85% R.6. Proporsi pasien TB positif di antara suspek harus mencapai angka 5- 15%.

-

R.7. Proporsi penderita TB yang ditemukan harus berada di angka 65% atau <65% R.8. angka konversi harus diatas 80% R.9.angka kesembuhan harus diatas 85%

Dari peran (role), aturan (rule) dan kebijakan (policy) yang didapatkan, selanjutnya adalah menggambarkan kedalam bentuk flowchart, sehingga diharapkan desain yang akan dibuat sesuai dengan peran, aturan, dan kebijakan yang ada di perusahaan. Serta dengan digambarkan kedalam flowchart, proses bisnis mengenai monitoring dan evaluasi dapat mudah untuk dipahami, Adapun proses saat ini akan dijelaskan lebih detil untuk masing-masing pengguna sistem, dengan tujuan untuk dapat dengan mudah mengetahui proses-proses yang harus dieliminasi, ditambahkan atau diintegrasikan dengan sistem yang baru nantinya, sehingga sistem yang akan dibuat sesuai dengan kebutuhan pengguna.

50

A. Alir proses mencatat form harian saat ini Berikut ini merupakan alir sistem yang lebih detil untuk Alir Proses Mencatat form harian. Dimana hasilnya dapat dilihat pada gambar 3.1.

Gambar 3.1. Alir proses mencatat form harian

51

Adapun penjelasan dari alir proses mencatat form harian yang sesuai dengan gambar 3.1 dapat dilihat pada tabel 3.2. Tabel 3.2 Penjelasan Alir Proses Mencatat Form Harian phase 1

No. Proses 1

Nama Proses Mencatat form pemeriksaan laboratorium

Input

R.1.

Decision

form pemeriksaan laboratorium

2

Mencatat kartu pengobatan pasien


3

Mencatat daftar suspek yang periksa dahak

Form pemeriksaan laboratorium

Data pasien

Proses

Output

Proses ini menjelaskan tentang petugas TB yang mencatat form pemeriksaan laboratorium Proses ini menjelaskan tentang pengecekan hasil pemeriksaan laboratorium yang dilakukan oleh pasien Proses ini menjelaskan tentang petugas TB yang mencatat kartu pengobatan pasien jika hasil pemeriksaan laboratorium positif Proses ini menjelaskan tentang petugas TB yang merekap hasil pemeriksaan laboratorium ke dalam data penemuan pasien


Buku daftar suspek yang periksa dahak

Kartu pengobatan pasien

Daftar suspek yang periksa dahak

52

phase

No. Proses 4

Nama Proses Mencatat form register TB

Input

Proses

Output

Daftar suspek yang periksa dahak dan kartu pengobatan pasien

Proses ini menjelaskan petugas TB yang mencatat form register TB sebagai alat pelaporan ke pihak Dinkes Kota Surabaya setiap triwulan

Form Register TB

B. Alir proses monitoring Berikut ini merupakan alir sistem yang lebih detil untuk Alir Proses Mencatat form harian. hasilnya dapat dilihat pada gambar 3.2 dan gambar 3.3

53

Gambar 3.2 Alir proses monitoring

54

Gambar 3.3 Alir proses monitoring

Adapun penjelasan dari alir proses mencatat form harian yang sesuai dengan gambar 3.2 dapat dilihat pada tabel 3.3. Tabel 3.3 Penjelasan Alir Proses Monitoring Phase No. proses 2 1

Nama Proses

Input

Proses

Output

Menyimpan data input ke microsoft excel

Laporan form TB 03 fasyankes

Proses ini menjelaskan tentang wasor TB yang melakukan input data laporan ke micrososft excel

Laporan form TB03 fasyankes

55

Phase No. proses 2

Nama Proses

Input

Memantau proporsi pasien positif diantara suspek diperiksa Decision


3.

Memantau proporsi pasien positif diantara pasien diobati


R.3

Decision


4.

Memantau angka konversi


R.2


Proses

Output

Proses ini Laporan hasil menjelaskan tentang pemantauan wasor TB yang proporsi memantau proporsi pasien positif pasien positif diantara diantara suspek suspek diperiksa diperiksa Proses ini Laporan hasil menjelaskan tentang pemantauan Wasor TB yang proporsi akan memeriksa pasien positif hasil proporsi pasien diantara positif diantara suspek suspek diperiksa jika diperiksa hasil diantara 5-15% maka Wasor TB akan membuat laporan hasil pemantauan Proses ini Laporan hasil menjelaskan tentang pemantauan wasor TB yang proporsi memantau hasil pasien positif proporsi pasien diantara pasien positif diantara diobati pasien diobati Proses ini Laporan hasil menjelaskan tentang pemantauan Wasor TB yang proporsi akan memeriksa pasien positif hasil proporsi pasien diantara pasien positif diantara diobati pasien diobati, jika hasil < 65% maka Wasor TB akan membuat laporan hasil pemantauan Proses ini Laporan hasil menjelaskan tentang pemantauan wasor TB yang angka angka memantau hasil konversi angka konversi

56

Phase No. proses R.4

Nama Proses

Input

Proses

Output

Decision


Laporan hasil pemantauan angka konversi

5.

Memantau angka kesembuhan


R.5.

Decision


Proses ini menjelaskan tentang Wasor TB yang akan memeriksa hasil angka konversi, jika hasil < 80% maka Wasor TB akan membuat laporan hasil pemantauan Proses ini menjelaskan tentang wasor TB yang memantau hasil angka kesembuhan Proses ini menjelaskan tentang Wasor TB yang akan memeriksa hasil angka kesembuhan, jika hasil < 85% maka Wasor TB akan membuat laporan hasil pemantauan

Laporan hasil pemantauan angka kesembuhan Laporan hasil pemantauan angka kesembuhan

C. Alir Proses Evaluasi Berikut ini merupakan alir sistem yang lebih detil untuk Alir Proses Evaluasi. hasilnya dapat dilihat pada gambar 3.4

57

Gambar 3.4 Alur Proses Evaluasi

58

Adapun penjelasan dari alir proses mencatat form harian yang sesuai dengan gambar 3.4 dan gambar 3.4 dapat dilihat pada tabel 3.4. Tabel 3.4 Penjelasan Alir Proses Evaluasi Phase No. proses 3 1

Nama Proses

Input

Proses

Output

Mengevaluasi proporsi pasien positif diantara suspek diperiksa

Laporan penemuan pasien (TB07)

Laporan hasil evaluasi proporsi pasien positif diantara suspek diperiksa

R.5

Decision


2

Mengevaluasi proporsi pasien positif diantara pasien diobati


R.6

Decision


Proses ini menjelaskan tentang Kasie P2M yang melakukan evaluasi hasil proporsi pasien positif diantara suspek diperiksa Proses ini menjelaskan tentang Kasie P2M yang akan memeriksa hasil evaluasi jika hasil tidak diantara 515% maka Kasie P2M akan membuat laporan hasil evaluasi Proses ini menjelaskan tentang Kasie P2M yang melakukan evaluasi proporsi pasien positif diantara pasien diobati Proses ini menjelaskan tentang Kasie P2M yang akan memeriksa hasil evaluasi jika hasil kurang dari angka 65% maka Kasie P2M akan membuat laporan hasil evaluasi

Laporan hasil evaluasi proporsi pasien positif diantara suspek diperiksa

Laporan evaluasi proporsi pasien positif diantara pasien diobati

Laporan evaluasi proporsi pasien positif diantara pasien diobati

59

Phase No. proses 3.

Nama Proses

Input

Proses

Output

Mengevaluasi angka konversi

Laporan angka konversi (TB11)

Laporan hasil evaluasi angka konversi

R.7

Decision

Laporan angka konversi (TB11)

4.

Mengevaluasi angka kesembuhan

Laporan angka kesembuhan (TB08)

R.8

Decision

Laporan angka kesembuhan (TB08)

Proses ini menjelaskan tentang Kasie P2M yang melakukan evaluasi angka konversi Proses ini menjelaskan tentang Kasie P2M yang akan memeriksa hasil evaluasi jika hasil kurang dari angka 80% maka Kasie P2M akan membuat laporan Proses ini menjelaskan tentang Kasie P2M yang melakukan evaluasi angka kesembuhan Proses ini menjelaskan tentang Kasie P2M yang akan memeriksa hasil evaluasi jika hasil kurang dari angka 85% maka Kasie P2M akan membuat laporan

Laporan hasil evaluasi angka konversi

Laporan hasil evaluasi angka kesembuhan

Laporan hasil evaluasi angka kesembuhan

Pada gambar alir sistem yang sudah dibahas sebelumnya yaitu gambaran mengenai alir sistem yang sedang berjalan pada perusahaan saat ini. Dari alir sistem tersebut maka analisis dilakukan untuk mengetahui kebutuhan dari masingmasing pengguna. Selain itu dari hasil analisis pada setiap alir sistem, dapat diketahui proses yang akan dilakukan eliminasi, proses yang dilakukan integrasi

60

menjadi satu fungsi, atau membangun fungsi baru, hal ini dilakukan untuk membangun fungsi sesuai dengan kebutuhan masing-masing pengguna sistem nantinya.

3.2 Analisis Permasalahan Setelah diketahui proses atau alir sistem yang dilakukan oleh masingmasing pengguna, maka proses berikutnya adalah melakukan analisis kebutuhan yang sesuai dengan proses-proses tersebut. Analisis kebutuhan ini diperlukan untuk merancang perangkat lunak yang memiliki fungsi-fungsi yang sesuai dengan kebutuhan masing-masing pengguna sistem. Analisis ini dilakukan pada setiap pengguna yang secara langsung berinteraksi dengan sistem nantinya. Berikut ini merupakan hasil analisis kebutuhan untuk masing-masing pengguna.

3.2.1 Analisis pada Proses Mencatat Form Harian Dalam proses pelaporan yang dilakukan oleh pihak puskesmas yang dikumpulkan pada setiap triwulan sering terjadi keterlambatan pengumpulan laporan yang disebabkan oleh pihak puskemas tersebut, hal seperti ini tentu saja akan membutuhkan waktu yang lama dalam pengumpulan data pada dinas kesehatan untuk dijadikan untuk kebutuhan monitoring dan evaluasi.

3.2.2 Analisis pada Proses Monitoring Dalam proses Monitoring

yang dilakukan oleh Wasor TB akan

memakan banyak waktu karena saling menunggu data laporan antara petugas TB puskesmas dengan Wasor TB, untuk proses selanjutnya yaitu laporan dari

61

puskesmas akan dientry ulang oleh Wasor TB ke aplikasi MS Excel, sehingga hal tersebut juga rawan terjadi kesalahan entry yang dilakukan oleh Wasor TB dan juga akan berpengaruh pada proses pengelolaan data jika data yang dientry salah.

3.2.3 Analisis pada Proses Evaluasi Dalam proses evaluasi

ini membutuhkan banyak waktu yang

dikarenakan untuk bisa melakukan evaluasi dibutuhkan data dari petugas TB puskesmas dan juga laporan dari Wasor TB jika terjadi revisi pada Wasor TB akan saling menunggu data antara Wasor TB dengan KaSIE P2M, dan KaSIE P2M diharuskan mendapat hasil evaluasi yang tepat sasaran sehingga hal ini akan dibutuhkan data yang benar-benar akurat dari laporan-laporan yang sudah dikumpulkan oleh Wasor TB.

3.3

Solusi Permasalahan Setelah dilakukan pengumpulan data melalui proses wawancara dan

observasi, pengolahan data dari hasil observasi, dilanjutkan dengan melakukan identifikasi dan analisis permasalahan, didapatkan suatu permasalahan yang harus diselesaikan dengan memberikan solusi yang sesuai dengan permasalahan yang ada. Dalam menyelesaikan permasalahan, solusi yang diberikan adalah dengan membangun aplikasi yang dapat menghubungkan pihak Petugas TB puskesmas dengan Wasor TB dan KaSIE P2M untuk memberikan data monitoring secara realtime kepada Dinkes Kota Surabaya dan juga data yang akurat guna melakukan evaluasi dalam pengembangan program kedepan.

62

Dalam membangun sebuah aplikasi sebagai solusi pada permasalahan yang ada Dinkes Kota Surabaya yaitu dengan melalui beberapa tahapan. Tahapan pengembangan aplikasi tersebut yaitu terdiri dari :

3.3.1 Kebutuhan Perangkat Lunak (Software Requirement) Langkah awal dalam membangun sebuah aplikasi yaitu dengan menganalisa kebutuhan perangkat lunak, hal ini dilakukan agar aplikasi yang dibangun sesuai dengan kebutuhan pengguna. Dalam melakukan identifikasi kebutuhan perangkat lunak, ada beberapa tahapan yaitu : A. Elisitasi Kebutuhan (Requirement Elicitation) Elisitasi kebutuhan atau pengumpulan kebutuhan adalah aktivitas awal untuk proses rekayasa kebutuhan (Requirement Engineering). Proses elisitasi dilakukan yaitu dengan cara wawancara dan observasi awal, namun yang dilakukan wawancara hanya kepada stakeholder yang terkait saja. Sebelum kebutuhan dapat dianalisis, kebutuhan harus dikumpulkan melalui proses elisitasi. Pada tahapan ini dilakukan penyeleksian data yang diperoleh sehingga dapat diketahui data-data yang digunakan dan yang tidak digunakan terkait dengan pengembangan perangkat lunak. Berikut ini data yang dikumpulkan melalui proses wawancara ataupun observasi pada perusahaan. Data tersebut meliputi :

63

a.

Data pasien Data pasien digunakan oleh petugas TB untuk mencatat seluruh pasien yang melakukan pemeriksaan laboratorium. Tabel 3.5 data pasien Nama pasien Jenis kelamin usia Alamat lengkap Kab/kota Provinsi No Telp Parut bcg Nama PMO Alamat PMO Status pasien Nama upk

b.

solichan Laki-laki 20 Jl.Mastrip IX no. 33 surabaya surabaya Jawa Timur +62839 3012 2211 jelas Abdul Jl. Mastrip IX lengkap kedurus

Data instansi Data instansi digunakan untuk mencatat instansi mana saja yang tercatat sebagai pengguna sistem. Tabel 3.6 data instansi Nama instansi Alamat instansi kecamatan Jml pasien diperiksa Jml penduduk tahun ini

Pucang sewu Jl. Pucang anom Pucang sewu 33 31.228

64

c.

Data permohonan lab Data permohonan lab digunakan untuk mencatat pasien yang akan melakukan pemeriksaan laboratorium. Tabel 3.7 data permohonan lab klasifikasi Alasan pemeriksaan

No registerasi TB No identitas sediaan Tgl pengambilan dahak terakhir Tanggal pengiriman dahak Tanda tangan pengambil sediaan Nanah lendir Air liur Bercak darah No registerasi lab Spesimen sewaktu 1 Spesimen pagi Spesimen sewaktu 2 Tanggal pemeriksaan sewaktu 1 Tanggal pemeriksaan pagi Tanggal pemeriksaan sewaktu 2 Nama pemeriksa

d.

1. Paru 2. ekstra paru 1. diagnosa 2. akhir tahap awal 3. akhir sisipan 4. 1 bulan sebelum Ap 5. akhir pengobatan(AP) 123 78/36/160 28/04/2015 28/04/2015 permadi Sewaktu 1 pagi Sewaktu 2 65 +++ +++ +++ 16/04/2015 17/04/2015 17/04/2015 mia

Data pengobatan Data pengobatan digunakan untuk mencatat jenis pengobatan pasien yang akan melakukan pengobatan Tabel 3.8 data pengobatan Tahun No registerasi TB03 No registerasi TB03 kota Riwayat berobat catatan Tipe pasien

2015

Pernah diobati lebih dari 1 bulan baru

65

Jenis obat kategori Jumlah KDT Jumlah streptomicin

e.

KDT Kategori 1 4 tablet/hr

Data hasil pemeriksaan dahak Data hasil pemeriksaan dahak digunakan untuk memantau hasil dari pengobatan pasien yang dilakukan secara berkala. Tabel 3.9 data hasil pemeriksaan dahak Bulan ke

Tanggal No reg lab BTA

Berat badan

f.

1. 0 (awal) 2. 2 3. 3 4. 4 5. 5/6 6. 7/8 7. AP 16/04/2015 652 1. +++ 2. ++ 3. + 4. 1-9 5. neg 60 kg

Data pengobatan intensif Data pengobatan intensif digunakan untuk mencatat hasil dari pengobatan pasien yang dilakukan. Tabel 3.10 data pengobatan intensif Tanggal pengobatan Status pengobatan

16/04/2015 -

66

B. Analisis Kebutuhan (Requirement Analysis) Sesuai dengan dari hasil elisitasi data-data yang dibutuhkan untuk membangun

perangkat

lunak, dibutuhkan sistem yang dibangun secara

terhubung antara puskesmas dengan Dinkes Kota Surabaya. B.1 Analisis Kebutuhan Petugas TB (Puskesmas) Setelah dilakukan analisis pada tahap yang sebelumnya, maka dapat disimpulkan bahwa puskesmas membutuhkan peningkatan pemanfaatan informasi yang berhubungan dengan proses pelaporan. Untuk meningkatkan proses yang sudah disebutkan dibutuhkan beberapa data, antara lain: 1. 2. 3. 4. 5. 6. 7.

Data pasien Data permohonan lab Data instansi Data hasil periksa dahak Data pengobatan Data keterangan tahap intensif Data pengobatan intensif

Untuk membantu peningkatan pemanfaatan informasi pelaporan, proses yang akan dilakukan yaitu : a. b.

Petugas mengisi form pemeriksaan laboratorium. Petugas mengisi form pengobatan pasien.

Dengan adanya perubahan tersebut, maka proses kedepannya akan mengalami peningkatan pemanfaatan informasi pada saat proses pencatatan dan perekapan jika dibandingkan pada saat ini. B.2 Analisis Kebutuhan Wasor TB Setelah dilakukan analisis pada tahap sebelumnya, maka Wasor TB dinas kesehatan membutuhkan peningkatan sistem pada proses Monitoring dan

67

pengelolaan data. Adapun data yang dibutuhkan dalam proses monitoring dan pengelolaan data antara lain: 1. 2. 3. 4.

Data hasil periksa dahak Data pengobatan Data keterangan tahap intensif Data pengobatan intensif

Untuk membantu peningkatan pemanfaatan informasi monitoring dan pengelolaan data, proses yang akan dilakukan yaitu : Wasor TB secara langsung dapat monitoring setiap indikator secara realtime. Dengan adanya perubahan tersebut, maka proses kedepannya akan mengalami

peningkatan

pemanfaatan

informasi

pada

saat

proses

pengelolaan data dan monitoring jika dibandingkan pada saat ini. B.3 Analisis Kebutuhan KaSIE P2M Setelah dilakukan analisis pada tahap sebelumnya, maka KaSIE P2M Dinkes Kota Surabaya

membutuhkan peningkatan sistem pada proses

evaluasi. Adapun data yang dibutuhkan dalam proses evaluasi antara lain: 1. Data hasil periksa dahak 2. Data pengobatan 3. Data keterangan tahap intensif 4. Data pengobatan intensif Untuk membantu peningkatan pemanfaatan informasi evaluasi, proses yang akan dilakukan yaitu : Kasie P2M dapat secara langsusng melakukan evaluasi setiap hasil monitoring.

68

C. Spesifikasi kebutuhan perangkat lunak. Dalam membangun dan mengembangkan perangkat lunak diperlukan perancangan spesifikasi perangkat lunak yang tepat, yang bertujuan agar perangkat lunak yang akan dikembangkan memiliki deskripsi fungsi yang sesuai dengan apa yang dibutuhkan pada masing-masing pengguna. Kebutuhan fungsi tersebut meliputi kebutuhan fungsional dan non-fungsional. C.1 Kebutuhan Fungsional Kebutuhan fungsional merupakan dasar penyusunan fungsi-fungsi yang akan dibangun didalam perangkat lunak. Fungsi-fungsi aplikas tersebut telah melewati proses identifikasi kebutuhan pada setiap pengguna. Adapun kebutuhan fungsional yang sudah disetujui oleh stakeholder tersebut adalah: C.1.1 Petugas TB Kebutuhan fungsional beserta penjelasannya untuk Petugas TB dapat dilihat pada tabel 3.12. Tabel 3.12 Detil Kebutuhan Fungsi Mencatat form harian Nama Fungsi Stakeholder Deskripsi

Kondisi Awal

Mencatat form harian Petugas TB Fungsi ini di gunakan untuk membantu petugas TB pada proses mencatat form pemeriksaan laboratorium dan form pengobatan pasien serta membantu puskesmas untuk melakukan pelaporan dan pembuatan daftar suspek yang melakukan pemeriksaan laboratorium. 8. 1. Data pasien 9. 2. Data permohonan lab 10. 3. Data intansi 11. 4. Data kontak serumah 12. 5. Data hasil periksa dahak 13. 6. Data pengobatan 14. 7. Data keterangan tahap intensif 15. 8. Data pengobatan intensif

69

Alur Normal

Aksi Pengguna

Respon Sistem 1. login 1.memasukan username 1. a. sistem akan dan password melakukan validasi user name dan password. b. jika validasi benar maka sistem akan menampilkan halaman selanjutnya c. jika validasi salah maka sistem akan menampilkan warning berupa kesalahan pada username dan password dan harap melakukan login ulang 2. Mencatat data pasien 1. memilih menu form 1. sistem akan data pasien menampilkan halaman form data pasien 2.mengisi form data 2. sistem akan mevalidasi pasien hasil input pengguna 3. memilih button 3. a. Jika data inputan simpan berhasil divalidasi maka sistem akan menampilkan info data berhasil disimpan dan sistem akan menyimpan id_upk, nama_upk, id_pasien, nama_pasien, jenis_kelamin, alamat_lengkap, kab/kota, provinsi, no_telp, dan umur pada data_pasien. b. jika data inputan gagal validasi maka sistem akan menampilkan peringatan bahwa data yang dimasukkan belum lengkap 3. Mencatat form pemeriksaan laboratorium 1. memilih menu 1. sistem akan permohonan menampilkan halaman laboratorium(klasifikasi form permohonan penyakit dan alasan laboratorium(klasifikasi pemeriksaan) dan alasan pemeriksaan)

70

2.mengisi permohonan laboratorium(klasifikasi penyakit dan alasan pemeriksaan) 3. memilih button simpan

4. mengisi form permohonan laboratorium (pengambilan dahak) 5. memilih button simpan

2. a. Sistem akan mencari data pasien. b. sistem akan mevalidasi hasil input pengguna 3. a. Jika data inputan berhasil divalidasi maka sistem akan menampilkan info data berhasil disimpan dan sistem akan menyimpan id_permohonan, id_pasien, nama_pasien, klasifikasi, dan alasan pemeriksaan di tabel permohonan_lab dan sistem akan menampilkan form permohonan laboratorium(pengambilan dahak). b. jika data inputan gagal validasi maka sistem akan menampilkan peringatan bahwa data yang dimasukkan belum lengkap 4. . a. Sistem akan mencari data pasien. b. sistem akan mevalidasi hasil input pengguna 5. a. Jika data inputan berhasil divalidasi maka sistem akan menampilkan info data berhasil disimpan dan sistem akan menyimpan no_identitas_sediaan, tgl_pengambilan_dhk, tgl_pengiriman_dahak, visual_dahak, ttd_pengambil di tabel permohonan_lab dan sistem akan menampilkan form permohonan laboratorium(hasil laboratorium).

71

b. jika data inputan gagal validasi maka sistem akan menampilkan peringatan bahwa data yang dimasukkan belum lengkap 6. mengisi form 6. a. Sistem akan mencari permohonan data pasien. laboratorium (hasil b. sistem akan mevalidasi laboratorium) hasil input pengguna 7. memilih button 7. a. Jika data inputan simpan berhasil divalidasi maka sistem akan menampilkan info data berhasil disimpan dan sistem akan menyimpan no_registerasi_lab, tgl_periksa_s1, tgl_periksa_pagi, tgl_periksa_s2, hsl_periksa_s1, hsl_periksa_pagi, hsl_periksa_s2, ttd_pemeriksa di tabel permohonan_lab b. jika data inputan gagal validasi maka sistem akan menampilkan peringatan bahwa data yang dimasukkan belum lengkap 4. Mencatat data pengobatan pasien 1. memilih menu form 1. sistem akan pengobatan menampilkan halaman pasien(pengawas form pengobatan meminum obat) pasien(pengawas meminum obat) 2.mengisi form 2. a. Sistem akan mencari pengobatan data pasien. pasien(pengawas b. sistem akan mevalidasi meminum obat) hasil input pengguna. 3. memilih button 3. a. Jika data inputan simpan berhasil divalidasi maka sistem akan menampilkan info data berhasil

72

disimpan dan sistem akan menyimpan nama_pmo, status_pmo, alamat_pmo, kecamatan_pmo, kelurahan_pmo, dan status_pmo di tabel data_pasien dan menampilkan halaman pengobatan pasien(tipe_pasien) b. jika data inputan gagal validasi maka sistem akan menampilkan peringatan bahwa data yang dimasukkan belum lengkap 4. mengisi form 4. a. Sistem akan mencari pengobatan data pasien. pasien(pengawas b. sistem akan mevalidasi meminum obat) hasil input pengguna. 5. memilih button 5. a. Jika data inputan simpan berhasil divalidasi maka sistem akan menampilkan info data berhasil disimpan dan sistem akan menyimpan tahun_pengobatan, no_reg_tb, parut_bcg, riwayat_pengobatan, tipe_pasien, catatan pada tabel pengobatan_pasien dan menampilkan halaman pengobatan pasien(hsl_periksa_dhk) b. jika data inputan gagal validasi maka sistem akan menampilkan peringatan bahwa data yang dimasukkan belum lengkap 6. mengisi form 6. a. Sistem akan mencari pengobatan pasien(hasil data pasien. periksa dahak) b. sistem akan mevalidasi hasil input pengguna. 7. memilih button 7. a. Jika data inputan

73

simpan

8. mengisi form pengobatan pasien(pengobatan rutin) 9. memilih button simpan

Alur Alternatif Alur Eksepsi

Aksi Pengguna Aksi Pengguna 1. Pengguna memasukkan username atau

berhasil divalidasi maka sistem akan menampilkan info data berhasil disimpan dan sistem akan menyimpan bulan_ke, tgl_pemeriksaan, no_reg_lab, BTA, berat_badan pada tabel hsl_periksa_dahak dan menampilkan halaman pengobatan pasien(pengobatan_rutin) b. jika data inputan gagal validasi maka sistem akan menampilkan peringatan bahwa data yang dimasukkan belum lengkap 8. a. Sistem akan mencari data pasien. b. sistem akan mevalidasi hasil input pengguna. 9. a. Jika data inputan berhasil divalidasi maka sistem akan menampilkan info data berhasil disimpan dan sistem akan menyimpan status_pasien, tgl_berobat, jenis_obat, kategori, jumlah_obat pada tabel intensif dan hsl_akhir pada tabel data_pasien b. jika data inputan gagal validasi maka sistem akan menampilkan peringatan bahwa data yang dimasukkan belum lengkap Respon Sistem Respon Sistem 1. Sistem akan memunculkan warning

74

password yang salah

Kondisi Akhir

Kebutuhan Non-Fungsional

bahwa username atau password yang di masukkan salah. 2. Pengguna 2. a) Sistem akan memasukkan data memberikan warning pasien yang tidak bahwa masukan tidak sesuai dengan form sesuai. b) sistem tidak dapat menyimpan data masukkan 1. Data pemeriksaan laboratorium 2. Data pengobatan pasien 3. Data hasil pemeriksaan dahak 4. Data pengobatan intensif 5. Data pengobatan lanjutan 6. Data hasil akhir Security Fungsi mencatat form harian ini hanya dapat digunakan oleh yang memiliki hak akses aja. Correctness Sistem memberikan peringatan jika terjadi salah input Interface 1. menu yang tersedia dalam bahasa indonesia 2. menu dan warna mudah dipaham dan tidak mencolok Performance Operability

75

C.1.2 Wasor TB Kebutuhan fungsional dan beserta penjelasannya untuk Wasor TB dapat dilihat pada tabel 3.13 Tabel 3.13 Detil Kebutuhan Fungsi Monitoring Nama Fungsi Stakeholder Deskripsi

Kondisi Awal

Alur Normal

Fungsi Monitoring Wasor TBC Fungsi ini digunakan oleh Wasor TB sebagai alat untuk memantau pelaksanaan program tuberkulosis yang sudah dijalankan oleh puskesmas. 1. Data pemeriksaan laboratorium 2. Data pengobatan pasien 3. Data hasil pemeriksaan dahak 4. Data pengobatan intensif 5. Data pengobatan lanjutan 6. Data hasil akhir Aksi Pengguna Respon Sistem 1. Monitoring Proporsi pasien TB positif diantara suspek yang diperiksa dahaknya 1. Pengguna 1. a) sistem akan menganalisa pasien memilih TB paru BTA positif diantara suspek menu dengan cara jumlah pasien TB BTA monitoring positif yang ditemukan pasien TB paru BTA positif diantara suspek b) sistem akan menampilkan hasil perhitungan dalam bentuk dashboard .

2. Monitoring dan menganalisa jumlah penderita TB yang ditemukan 1. Pengguna 1. a) sistem akan menganalisa Memilih indikator pasien TB BTA positif diantara menu seluruh suspek yang diambil monitoring pasien TB paru BTA

76

positif diantara b) sistem akan menampilkan hasil semua perhitungan dalam bentuk pasien dashboard. tercatat 3. Monitoring dan menganalisa cohort untuk angka konversi dahak akhir tahap intensif 1. a) sistem akan menganalisa indikator 1. pengguna angka konversi memilih menu monitoring angka kesembuhan b) sistem akan menampilkan hasil perhitungan dalam bentuk dashboard. 4. Monitoring dan menganalisa cohort untuk Angka Kesembuhan 1. pengguna 1. a) sistem akan menganalisa memilih menu indikator angka kesembuhan monitoring angka kesembuhan

b) sistem akan menampilkan hasil perhitungan dalam bentuk dashboard. Respon Sistem

Alur Alternatif

Aksi Pengguna

Alur Eksepsi

Aksi Pengguna 1. Pengguna memasukkan username atau password yang salah

Kondisi Akhir Kebutuhan NonFungsional

1. Data hasil monitoring Security Fungsi mencatat form harian ini hanya dapat digunakan oleh yang memiliki hak akses aja. Correctness Sistem memberikan peringatan jika terjadi salah input Interface 1. menu yang tersedia dalam

Respon Sistem 1. Sistem akan memunculkan message bahwa username atau password yang di masukkan salah.

77

bahasa indonesia 2. menu dan warna mudah dipaham dan tidak mencolok Performance Operability

C.1.3 KaSIE P2M Kebutuhan fungsional dan beserta penjelasannya untuk KaSIE P2M dapat dilihat pada tabel 3.14 Tabel 3.14 Detil Kebutuhan Fungsi evaluasi Nama Fungsi Stakeholder Deskripsi

Kondisi Awal Alur Normal

Fungsi evaluasi KaSie P2M Fungsi ini di gunakan oleh KaSIE P2M Dinas Kesehatan Kota Surabaya sebagai alat bantu pada proses evaluasi program penanggulangan TB. 1. Data indikator Aksi Pengguna

Respon Sistem

1. evaluasi Proporsi pasien TB positif diantara suspek yang diperiksa dahaknya

1. Pengguna memilih menu evaluasi pasien TB paru BTA positif diantara suspek

1. a) sistem akan menampilkan hasil pasien TB paru BTA positif diantara suspek selama tiga bulan b) sistem akan menampilkan hasil perhitungan dalam bentuk dashboard. C.jika hasil perhitungan < 5% maka sistem akan menampilkan warning penjaringan suspek terlalu longgar, d.) jika hasil perhitungan >15% maka sistem akan menampilkan warning

78

penjaringan terlalu ketat 2. evaluasi jumlah penderita TB yang ditemukan

1. Pengguna Memilih menu monitoring pasien TB paru BTA positif diantara semua pasien tercatat

1. a) sistem akan menampilkan indikator pasien TB BTA positif diantara seluruh suspek selama tiga bulan b) sistem akan menampilkan hasil perhitungan dalam bentuk dashboard c.) jika hasil perhitungan <65% maka sistem akan menampilkan warning

3. evaluasi cohort untuk angka konversi dahak akhir tahap intensif

1. pengguna Memilih menu evaluasi angka konversi

1. a) sistem akan menampilkan indikator angka konversi b) sistem akan menampilkan hasil perhitungan dalam bentuk dashboard. c.) jika hasil perhitungan kurang dari 80% maka sistem akan memberikan warning

4. evaluasi cohort untuk Angka Kesembuhan

1. pengguna memilih menu evaluasi angka kesembuhan

1. a) sistem akan menampilkan indikator angka kesembuhan selama tiga bulan b) sistem akan menampilkan hasil perhitungan dalam bentuk dashboard. c.)jika hasil perhitungan kurang dari 85% maka sistem akan menampilkan warning

79

Alur Alternatif

Aksi Pengguna

Respon Sistem

Alur Eksepsi

Aksi Pengguna 1. Pengguna memasukkan username atau password yang salah

Respon Sistem 1. Sistem akan memunculkan message bahwa username atau password yang di masukkan salah.

Kondisi Akhir Kebutuhan Non-Fungsional

1. Data evaluasi Security Fungsi mencatat form harian ini hanya dapat digunakan oleh yang memeliki hak akses aja. Correctness Sistem memberikan peringatan jika terjadi slah input Interface 1. menu yang tersedia dalam bahasa indonesia

C.2 Kebutuhan Non-Fungsional Dalam penerapan fungsi tersebut yang bertujuan untuk mendukung kinerja fungsi utama pada sistem dan selain itu juga membutuhkan non-fungsional. Adapun kebutuhan non-fungsional yang sudah disetujui stakeholder tersebut dapat dilihat lebih detil pada tabel 3.15. Tabel 3.15 Hubungan Fungsional dan Non-Fungsional Sistem No 1.

Stakeholder

Fungsional System

Petugas TB

Mencatat Form Harian

Non-Fungsional system a. Security b. Correctness c. Interface d. Operability

80

2.

Wasor TB

monitoring

a. b. c. d.

Security Correctness Interface Operability

3.

KaSIE P2M

Evaluasi

a. b. c. d.

Security Correctness Interface Operability

3.3.2 Desain Sistem (Software Design) Rancangan perangkat lunak merupakan suatu kegiatan dalam merancang perangkat lunak yang akan dibangun sesuai dengan kebutuhan pengguna. Proses perancangan pada tahap selanjutnya yaitu dilakukan berdasarkan hasil analisis kebutuhan yang telah dilakukan pada tahap sebelumnya. Beberapa model perancangan perangkat lunak tersebut adalah sebagai berikut : 1. Alir Sistem (System Flow) 2. Data Flow Diagram 3. Entity Relationship Diagram, dan 4. Tampilan Antar Muka (Interface) A. Alir Sistem (System Flow) Sesuai hasil analisis kebutuhan yang ada pada tahap sebelumnya, dapat diketahui bahwa pengguna yang akan menggunakan sistem ada 3 (tiga), yaitu Petugas TB, Wasor TB dan KaSIE P2M. Proses perancangan alir sistem ini adalah alir desain sistem yang baru, dan perancangan tersebut harus disesuaikan dengan hasil analisis kebutuhan. Saat melakukan perancangan sistem yang baru, data pendukung perancangan seperti aturan dan kebijakan harus disesuaikan dengan sistem

81

yang baru, oleh karena itu data tersebut telah diperbarui dan telah disetujui oleh stakeholder. Data yang digunakan untuk perancangan alir sistem baru dapat dilihat pada tabel 3.16. Tabel 3.16 Kebijakan Berdasarkan Stakeholder Sesuai Sistem Baru Stakeholder Petugas puskesmas Wasor TB

Proses Bisnis pencatatan

Phase

Rule

1

R.1 hasil diagnosa positif.

Monitoring

2

R.2. angka pasien TB paru positif harus 15 %, bila angka pasien TB paru positif <5% maka penjaringan suspek terlalu longgar dan ada masalah laboratorium negatif palsu R.2.a bila angka pasien TB paru positif > 15%, maka penjaringan suspek terlalu ketat dan ada masalah laboratorium positif palsu R.3. merupakan angka prosentase pasien tuberkulosis paru BTA positif diantara semua pasien tuberkulosisparu tercatat. Angka ini tidak boleh kurang dari 65%, jika angka ini <65% maka mutu diagnosis yang sudah dilakukan rendah dan kurang memberi prioritas untuk pasien menular. R.4. merupakan prosentase pasien baru TB paru BTA positif yang mengalami perubahan menjadi BTA negatif setelah menjalani masa pengobatan intensif. Angka minimal untuk prosentasi ini adalah 80%, jika angka ini <80% maka pengawasan meminum obat belum dilakukan dengan benar. R.5. angka yang menunjukkan prosentase pasien baru TB paru BTA positif yang sembuh setelah selesai masa pengobatan, diantara

Policy -

-

82

Stakeholder Kasie P2M

Proses Bisnis Evaluasi

pasien baru TB paru BTA positif yang tercatat. Angka ini tidak boleh <85%, jika pencapaian <85% maka hasil pengobatan belum memenuhi target. Phase Rule 3.

R.6. angka pasien TB paru positif selama tiga bulan harus 5-15 %, bila angka pasien TB paru positif selama tiga bulan <5% maka penjaringan suspek terlalu longgar dan ada masalah laboratorium negatif palsu R.6.a bila angka pasien TB paru positif selama tiga bulan > 15%, maka penjaringan suspek terlalu ketat dan ada masalah laboratorium positif palsu R.7. merupakan angka prosentase pasien tuberkulosis paru BTA positif diantara semua pasien tuberkulosis paru tercatat selama tiga bulan. Angka ini tidak boleh kurang dari 65%, jika angka ini <65% maka mutu diagnosis yang sudah dilakukan rendah dan kurang memberi prioritas untuk pasien menular. R.8. merupakan prosentase pasien baru TB paru BTA positif yang mengalami perubahan menjadi BTA negatif setelah menjalani masa pengobatan intensif selam tiga bulan. Angka minimal untuk prosentasi ini adalah 80%, jika angka ini <80% maka pengawasan meminum obat belum dilakukan dengan benar. R.9. angka yang menunjukkan prosentase pasien baru TB paru BTA positif yang sembuh setelah selesai masa pengobatan, diantara pasien baru TB paru BTA positif yang tercatat selama tiga bulan.

Policy -

83

Angka ini tidak boleh <85%, jika pencapaian <85% maka hasil pengobatan belum memenuhi target.

Pembuatan aturan dan kebijakan yang baru ini tentu dibuat dengan tidak mempersulit

proses

yang

nantinya

dibuat,

melainkan

dibuat

dengan

mempermudah pengguna dalam menjalankannya. Setelah data aturan dan kebijakan sudah dibuat dan sudah di setujui oleh pihak stakeholder, maka proses perancangan alir sistem terbaru dapat dilakukan. A.1 Alir Sistem Baru Petugas TB Berikut ini merupakan alir sistem yang lebih detil untuk alir sistem Petugas TB, dimana alir sistem Petugas TB telah disesuaikan dengan proses bisnis berdasarkan stakeholder sistem baru. Lebih jelasnya mengenai alir sistem barunya dapat dilihat pada gambar 3.5.

84

Gambar 3.5 Alir Sistem Baru proses pencatatan dan pelaporan Adapun penjelasan dari Alir Sistem mencatat form harian yang sesuai dengan gambar 3.5 dapat dilihat pada tabel 3.17.

85

Tabel 3.17 Alir Sistem Baru Mencatat Form Harian Phas e

No. Prose s 1. 1.

Nama Proses Mencatat data pasien

Input

Data pasien

2. Mencatat Data pasien form pemeriksa an laboratoriu m

Uraian proses Proses ini menjelaska n tentang proses mencatat data pasien yang dilakukan oleh petugas TB Proses ini menjelaska n tentang proses mencatat data pemeriksaa n laboratoriu m yang dilakukan oleh petugas TB

Output

Data pasien tersimpan pada data_pasien

Data hasil pemeriksaan dahak yang disimpan di pemeriksaan_lab

86

Phas e

No. Prose s

Nama Proses decision

3. mencatat kartu pengobata n pasien

Input

Uraian proses

*R.1. Proses ini menjelaska n tentang hasil pemeriksaa n yang dilakukan oleh laboratoriu m, jika hasil +++ dan ++ maka pasien akan dicatat didalam kartu pengobata n pasien jika tidak maka pasien dianggap bukan penderita TB Membaca Proses ini M.pasien, M.tipe, menjelaksa M.jenis_obat dan n tentang m. user yang riwayat_pengoba akan tan mencatat kartu pengobata n pasien

Output

Pemeriksaan_lab

Disimpan pada tabel detil_pengobatan, M. pengobatan_inten sif, m. pengobatan_lanjut an, dan m.hsl_akhir

87

A.2 Alir Sistem Baru Wasor TB Berikut ini merupakan alir sistem yang lebih detil untuk alir sistem Wasor TB, dimana alir sistem Wasor TB telah disesuaikan dengan proses bisnis berdasarkan stakeholder sistem baru. Lebih jelasnya mengenai alir sistem barunya dapat dilihat pada gambar 3.6. dan gambar 3.7

88

Gambar 3.6 Alir Sistem Baru Monitoring

89

Gambar 3.7 Alir Sistem Baru Monitoring Adapun penjelasan dari Alir Sistem monitoring yang sesuai dengan gambar 3.6 dan 3.7 dapat dilihat pada tabel 3.18.

90

Tabel 3.18 Alir Sistem Baru Monitoring Phas e

No. Prose s 1.

Nama Proses monitoring proporsi pasien TB BTA positif diantara suspek

Decisison

Decision

Input

Uraian proses

Output

Data puskesmas dan data pemeriksaan laboratoriu m

Proses ini menjelaskan tentang sistem yang akan menghitung proporsi pasien TB BTA positif diantara suspek dengan cara jumlah pasien TB BTA positif yang ditemukan, dibagi dengan jumlah seluruh suspek TB yang di periksa, kemudian dikalikan dengan 100% *R.2. Proses ini menjelaskan tentang hasil capaian dari setiap puskesmas, jika capaian <5% maka sistem akan memberikan hasil temuan.

monitoring

*R.2.a Proses ini menjelaskan tentang hasil capaian dari setiap puskesmas, jika capaian >15% maka sistem akan memberikan hasil temuan

Menampilka n hasil indikator dengan warning penjaringan terlalu ketat

hasil indikator dengan warning penjaringan suspek terlalu longgar

91

Phase

No. Prose s 2.

Nama Proses

Input

Uraian proses

Monitoring proporsi pasien TB paru BTA positif diantara semua pasien tercatat

Data pengobatan pasien

Proses ini menjelaskan sistem yang akan menghitung proporsi pasien TB BTA positif diantara seluruh semua pasien tercatat dengan cara jumlah pasien TB BTA positif(baru+kambuh) , dibagi dengan jumlah seluruh pasien TB(semua tipe), kemudian dikalikan dengan 100% *R.3. Proses ini menjelaskan tentang hasil capaian dari setiap puskesmas, jika capaian <65% maka sistem akan memberikan hasil temuan.

monitoring

Proses ini menjelaskan sistem yang akan menghitung angka konversi dengan cara jumlah pasien baru TB paru BTA positif yang konversi dibagi dengan jumlah pasien baru TB paru BTA positif yang diobati dan dikalikan dengan 100%

Monitoring

Decision

3.

Monitoring angka konversi


Output

Menampilka n hasil indikator dengan warning mutu diagnosis masih rendah

92

Phase

No. Prose s

Nama Proses

Input

Decisison

4.

Monitoring angka kesembuha n

Decision


Uraian proses

Output

*R.4. Proses ini akan menjelaskan tentang hasil capaian dari setiap puskesmas, jika capaian >80% maka sistem akan memberikan hasil temuan

Menampilka n hasil indikator dengan warning target belum terpenuhi

Proses ini menjelaskan sistem yang akan menghitung angka kesembuhan dengan cara jumlah pasien baru TB BTA positif yang sembuh dibagi dengan jumlah pasien baru TB BTA positif yang diobati dan dikalikan dengan 100% *R.5. Proses ini akan menjelaskan tentang hasil capaian dari setiap puskesmas, jika capaian >85% maka sistem akan memberikan hasil temuan

Monitoring

Menampilka n hasil indikator dengan warning target belum terpenuhi

93

A.3 Alir Sistem Baru KaSIE P2M Berikut ini merupakan alir sistem yang lebih detil untuk alir sistem KaSie P2M, dimana alir sistem KaSie P2M telah disesuaikan dengan proses bisnis berdasarkan stakeholder sistem baru. Lebih jelasnya mengenai alir sistem barunya dapat dilihat pada gambar 3.8.

94

Gambar 3.8 Alir Sistem Baru Evaluasi

95

Gambar 3.9 Alir Sistem Baru Evaluasi Adapun penjelasan dari Alir Sistem evaluasi yang sesuai dengan gambar 3.19 dan 3.9 dapat dilihat pada tabel 3.19.

96

Tabel 3.19 Alir Sistem Baru Evaluasi Phas e 3

No. Nama Pros Proses es 1. Evaluasi proporsi pasien TB positif diantara suspek yang diperiksa dahakanya

Decisison

Input

Uraian proses

Output

Membaca M.pasien dan M.hsl_periksa_dahak

Proses ini menjelaskan tentang sistem yang akan menampilkan proporsi pasien TB BTA positif diantara suspek selama tiga bulan dengan cara jumlah pasien TB BTA positif yang ditemukan, dibagi dengan jumlah seluruh suspek TB yang di periksa, kemudian dikalikan dengan 100% *R.6. Proses ini menjelaskan tentang hasil capaian dari setiap puskesmas, jika capaian <5% maka sistem akan memberikan hasil temuan.

Evaluasi proporsi pasien TB positif diantara suspek yang diperiksa dahakanya

Hasil evaluasi indikator dengan warning penjaringa n suspek terlalu longgar

97

Phas e

No. Pros es 2.

Nama Proses

Input

Uraian proses

Output

Menampilk an hasil evaluasi indikator dengan warning penjaringa n suspek terlalu longgar


Proses ini menjelaskan tentang sistem yang akan menampilkan proporsi pasien TB BTA positif diantara suspek

Hasil evaluasi indikator dengan warning penjaringa n suspek terlalu longgar

*R.6.a Proses ini menjelaskan tentang hasil capaian dari setiap puskesmas, jika capaian >15% maka sistem akan memberikan hasil temuan

Menampilk an hasil evaluasi indikator dengan warning penjaringa n terlalu ketat

Proses ini menjelaskan tentang sistem yang akan menampilkan proporsi pasien TB BTA positif diantara suspek terlalu ketat

Menampilk an hasil evaluasi indikator dengan warning penjaringa n terlalu ketat

Decision

3.

Menampilk an hasil evaluasi indikator dengan warning penjaringa n suspek terlalu ketat


98

Phas e

No. Nama Pros Proses es 4. Evaluasi jumlah penderita TB yang ditemukan

Decision

Input

Membaca Detil_Pengobatan

Uraian proses

Proses ini menjelaskan sistem yang akan menampilkan proporsi pasien TB BTA positif diantara seluruh semua pasien tercatat selama tiga bulan dengan cara jumlah pasien TB BTA positif(baru+kamb uh), dibagi dengan jumlah seluruh pasien TB(semua tipe), kemudian dikalikan dengan 100% *R.7. Proses ini menjelaskan tentang hasil capaian dari setiap puskesmas, jika capaian <65% maka sistem akan memberikan hasil temuan.

Output

Menampilk an hasil evaluasi indikator dengan warning mutu diagnosis masih rendah

99

Phas e

No. Pros es 5.

6.

Nama Proses

Input

Uraian proses

Menampilk Membaca Detil_Pengobatan an hasil evaluasi indikator dengan warning mutu diagnosis masih rendah

Proses ini menjelaskan sistem yang akan Menampilkan hasil indikator dengan warning mutu diagnosis masih rendah

Evaluasi cohort untuk angka konversi dahak tahap intensif

Proses ini menjelaskan sistem yang akan menampilkan angka konversi selama tiga bulan dengan cara jumlah pasien baru TB paru BTA positif yang konversi dibagi dengan jumlah pasien baru TB paru BTA positif yang diobati dan dikalikan dengan 100%

Membaca M.hsl_pemeriksaan_d ahak , Detil_pengobatan

Output

Menampilk an hasil evaluasi indikator dengan warning mutu diagnosis masih rendah

100

Phas e

No. Pros es

Nama Proses

Input

Decisison

7.

Menampilk an hasil evaluasi indikator dengan warning target belum terpenuhi

Membaca M.hsl_pemeriksaan_d ahak , Detil_pengobatan

Uraian proses

Output

*R.8. Proses ini akan menjelaskan tentang hasil capaian dari setiap puskesmas, jika capaian >80% maka sistem akan memberikan


Proses ini menjelaskan sistem yang akan Menampilkan hasil indikator dengan warning target belum terpenuhi


101

Phas e

No. Pros es 8.

Nama Proses

Input

Uraian proses

Evaluasi cohort untuk angka kesembuh an

Membaca M.hsl_pemeriksaan_d ahak dan Detil_pengobatan

Proses ini menjelaskan sistem yang akan menampilkan angka kesembuhan selama tiga bulan dengan cara jumlah pasien baru TB BTA positif yang sembuh dibagi dengan jumlah pasien baru TB BTA positif yang diobati dan dikalikan dengan 100% *R.9. Proses ini akan menjelaskan tentang hasil capaian dari setiap puskesmas, jika capaian >85% maka sistem akan memberikan hasil temuan

Decision

9.


Membaca M.hsl_pemeriksaan_d ahak dan Detil_pengobatan

Proses ini menjelaskan sistem yang akan Menampilkan hasil indikator dengan warning target belum terpenuhi

Output



102

B.Context Diagram Berikut ini adalah desain context diagram untuk perangkat lunak yang akan dikerjakan. Pada terlihat bahwa memiliki empat pengguna yang nantinya akan berinteraksi dengan sistem, hal tersebut disesuaikan dengan stakeholder yang sudah diketahui pada tahap analisis.seperti yang sudah dijelaskan sebelumnya, bahwa pada penelitian ini akan dijelaskan mengenai perencanaan obat, adapun fungsi atau peran dari sistem sebelumnya yaitu memberikan laporan kepada pihak yang terkait, dimana laporan tersebut membutuhkan inputan awal data obat yang dilakukan untuk proses perencanaan. Lebih lengkapnya dapat dilihat pada gambar 3.10. data puskesmas

PATUGAS_TB

data pasien WASOR_TB data monitoring penemuan pasien diantara suspek data monitoring penemuan pasien positif diantara pasien tercatat DATA_PEMERIKSAAN_LABORATORIUM

0 DATA_HASIL_PERIKSA_LAB DATA_PMO

SI monitoring dan evaluasi program penanggulangan TB

data pengobatan

laporan hasil konversi laporan hasil pengobatan pasien laporan pasien positif diantara suspek diperiksa

data hasil pengobatan

laporan pasien positif diantara pasien diobati

KASIE_P2M laporan angka konversi laporan angka sucess rate

Gambar 3.10 Context Diagram

103

B.1. Data Flow Diagram Proses yang terdapat pada Data Flow Diagram digambarkan sesuai dengan alir sistem baru masing-masing stakeholder. Pada data flow diagram ini akan dijelaskan secara detil mengenai proses monitoring dan evaluasi. Data Flow Diagram (DFD) untuk aplikasi yang sedang dikembangkan telah didefinisikan menjadi sub sistem Level 0 yang terdiri dari 3(tiga) fungsional yaitu: pencatatan, monitoring, dan evaluasi oleh KaSie P2M. Pada level 0 akan digambarkan lebih detil interaksi antara pengguna dengan sistem nantinya. Untuk lebih jelasnya dapat dilihat pada gambar 3.11.

DATA_INSTANSI INSTANSI [data puskes mas] data_input_pas ien [data pasien] [DATA_PEM ERIKSAAN_LABORATORIUM]

PATUGAS _TB

DATA_PASIEN

PERM OHONAN_LAB [DATA_HASIL_PERIKSA_LAB] data_input_periksa_lab

1

HSL_PERIKSA_DAHAK

data_input_hsl_periksa_lab

PENCATATAN [DATA_PMO] data_input_pengobatan [data peng obatan]

+

KARTU_PENGOBATAN

[data hasil peng obatan]

TAHAP_INTENSIF data_input_pengobatan_intens if data_pasien_terjaring

PERM OHONAN_LAB2

2 HSL_PERIKSA_DAHAK2

[laporan has il konversi]

data_pasien_pos itif

[laporan has il pengobatan pasien] MONITORING

data_pasien_konversi

+

data_pasien_sembuh

[data monitoring penemuan pas ien pos itif diantara pas ien tercatat] KARTU_PENGOBATAN 2

data_pasien_diobati WASOR_TB

[data monitoring penemuan pas ien diantara s uspek]

data_evaluasi_pasien_terjaring

PERM OHONAN_LAB22

3 HSL_PERIKSA_DAHAK22

[laporan pas ien pos itif diantara sus pek diperiks a]

data_evaluasi_pasien_positif evaluasi

data_evaluasi_pasien_konversi data_evaluasi_pasien_sembuh

KARTU_PENGOBATAN 22

+

[laporan ang ka suces s rate] data_evaluasi_pasien_diobati [laporan pas ien pos itif diantara pas ien diobati]

Gambar 3.11 DFD Level 0

[laporan ang ka konversi]

KASIE_P2 M

104

Proses yang terdapat pada data flow diagram digambarkan sesuai dengan alir sistem baru masing-masing stakeholder. Pada data flow diagram ini akan dijelaskan secara detail mengenai proses monitoring dan evaluasi, data flow diagram (DFD) untuk aplikasi yang terdiri dari 3 fungsional yaitu, pencatatan from pemeriksaan, monitoring, dan evaluasi a) Level 1 pencatatan Pada level 1 ini merupakan rancangan detil dari proses mencatat form pemeriksaan laboratorium yang didapatkan dari level 0, untuk detil rancangan mencatat form pemeriksaan laboratorium dapat dilihat pada gambar dibawah ini. Untuk detail penjelasan dapat dilihat pada gambar 3.12.

[DATA_INSTANSI]

INSTANSI

[data pasien]

PATUGAS_TB

DATA_PASIEN : 2

[data_input_pasien]

[data puskesmas]

DATA_PASIEN : 1

1.1

[data_input_pasien] pencatatan data pasien

1.2

[DATA_PEM ERIKSAAN_LABORATORIUM]

pencatatan_data_permohonan_lab

PERM OHONAN_LAB

[data_input_periksa_lab] [data_input_hsl_periksa_lab]

[DATA_HASIL_PERIKSA_LAB]

HSL_PERIKSA_DA HAK 1.3 [DATA_PMO]

[data_input_peng obatan]

[data peng obatan] pencatatan_data_peng obatan [data hasil peng obatan]

KARTU_PENGOBA TAN [data_input_peng obatan_intensif] TAHAP_INTENSIF

Gambar 3.12 DFD Level 1 mencatat form pemeriksaan laboratorium

Proses yang terdapat pada data flow diagram digambarkan sesuai dengan alir sistem baru masing-masing stakeholder. Pada data flow diagram ini akan

105

dijelaskan secara detail mengenai proses pencatatan form harian, data flow diagram (DFD) untuk aplikasi yang terdiri dari 3 fungsional yaitu, mencatat form pemeriksaan laboratorium, mencatat form pengobatan pasien, menampilkan daftar suspek periksa lab. Untuk lebih detailnya dapat dilihat pada tabel 3.20. Tabel 3.20 Penjelasan DFD Level 1 pencatatan form pemeriksaan Nama Proses Pencata tan

No proses 1.1

1.2

1.3

Nama sub Input proses Pencatatan 1. data data pasien pasien 2.data instansi

Pencatatan 1. data pemeriksa puskesmas an lab 2. data pemeriksa an lab 3. data hasil pemeriksa an lab

Pencatatan 1. data pengobata pmo n 2. data pengobata n 3. data hasil pengobata n

Uraian proses

output

Proses menjelaskan mengenai aktititas pencatatan datapasien Tabel yang dibaca : Proses ini menjelaskan mengenai aktifitas pencatatan hasil pemeriksaan laboratorium pasien yang dilakukan oleh petugas TB Tabel yang dibaca: 1. data_pasien 2. intsansi

1. pasien Disimpan pada tabel : 1. data_pasien 2.instansi

Proses ini menjelaskan mengenai aktifitas pencatatan pengobatan pasien yang dilakukan oleh petugas TB Tabel yang dibaca: 1. data pasien 2.hsl_periksa_dhk

1. data pengobatan 2. data hasil pengobatan Disimpan pada tabel: 1. kartu pengobatan 2. tahap intensif

1. data periksa lab 2.data hsl periksa lab Disimpan pada tabel:

1. permohonan_lab 2. hsl_periksa_dhk

106

b) Level 1 monitoring Pada level 1 ini merupakan rancangan detil dari proses monitoring yang didapatkan dari level 0, untuk detil rancangan monitoring dapat dilihat pada gambar dibawah ini. Untuk detail penjelasan dapat dilihat pada gambar 3.13. PERM OHONAN_LAB2

[data_pasien_terjaring ]

2.1

[data_pasien_positif]

[data monitoring penemuan pasien diantara suspek] monitoring _proporsi_pasien_positif_diantara _pasien_terjaring HSL_PERIKSA_DAHAK2 : 1

KARTU_PENGOBA TAN2

2.2

monitoring proporsi pasien positif diantara pasien diobati

[data monitoring penemuan pasien positif diantara pasien tercatat]

[data_pasien_diobati]

HSL_PERIKSA_DAHAK2 : 2 WASOR_TB 2.3

[data_pasien_konversi]

monitoring pasien konversi [laporan hasil konversi]

HSL_PERIKSA_DAHAK2 : 3

2.4

monitoring pasien sembuh [data_pasien_sembuh]

[laporan hasil pengobatan pasien]

Gambar 3.13 DFD Level 1 monitoring

Proses yang terdapat pada data flow diagram digambarkan sesuai dengan alir sistem baru masing-masing stakeholder. Pada data flow diagram ini akan dijelaskan secara detail mengenai proses monitoring, data flow diagram (DFD) untuk aplikasi yang terdiri dari 9 fungsional yaitu, monitoring angka penjaringan suspek, monitoring proporsi pasien TB BTA positif diantara seluruh pasien, monitoring proporsi pasien TB paru BTA positif diiantara semua pasien tercatat, monitoring pasien TB anak diantara seluruh pasien TB, monitoring angka penemuan kasus, monitoring angka notifikasi kasus, monitoring angka konversi,

107

monitoring angka kesembuhan dan monitoring angka keberhasilan pengobatan. Untuk lebih detailnya dapat dilihat pada tabel 3.21. Tabel 3.21 Penjelasan DFD Level 1 monitoring Nama Proses monitoring

No proses 2.1

Nama sub proses Monitoring proporsi pasien positif diantara suspek

Input

Uraian proses

Proses ini menjelaskan mengenai aktifitas monitoring proporsi pasien positif diantara suspek Tabel yang dibaca: 1. m_pasien 2.detail_pengobatan Monitoring 1. jumlah Proses ini proporsi pasien menjelaskan pasien positif positif baru mengenai aktifitas diantara dan monitoring proporsi pasien yang kambuh pasien positif diantara diobati 2. jumlah pasien yang diobati pasien Tabel yang dibaca: semua tipe 1.detail_pengobatan

1. capaian proporsi pasien positif diantara suspek Disimpan pada tabel:

2.3

Monitoring angka konversi

Proses ini menjelaskan mengenai aktifitas Monitoring angka konversi Tabel yang dibaca: 1.detail_pengobatan

1. capaian angka konversi Disimpan pada tabel: -

2.4

Monitoring angka kesembuhan

Proses ini menjelaskan mengenai aktifitas Monitoring angka kesembuhan Tabel yang dibaca: 1.detail_pengobatan

1. capaian angka kesembuhan Disimpan pada tabel: -

2.2

1. data pasien terjaring 2. jumlah pasien positif yang ditemukan

output

1. jumlah pasien baru positif yang konversi 2. jumlah pasien baru positif yang diobati 1. jumlah pasien baru positif yang diobati 2. jumlah pasien baru positif yang sembuh

1.capaian proporsi pasien positif diantara pasien diobati Disimpan pada tabel: -

108

c) Level 1 evaluasi Pada level 1 ini merupakan rancangan detil dari proses evaluasi yang didapatkan dari level 0, untuk detil rancangan evaluasi dapat dilihat pada gambar dibawah ini. Untuk detail penjelasan dapat dilihat pada gambar 3.14.

[data_evaluasi_pasien_terjaring]

PERM OHONAN_LAB22

[laporan pasien positif diantara suspek diperiksa]

3.1 HSL_PERIKSA_DAHAK22 : 1

[data_evaluasi_pasien_positif] evaluasi proporsi pasien positif diantara suspek

KARTU_PENGOBATAN22 3.2 [laporan pasien positif diantara pasien diobati] [data_evaluasi_pasien_diobati]

evaluasi proporsi pasien positif diantara pasien diobati


3.3 [laporan ang ka konversi] [data_evaluasi_pasien_konversi]

KASIE_P2M

evaluasi pasien konversi


3.4

[data_evaluasi_pasien_sembuh]

evaluasi pasien sembuh

[laporan ang ka sucess rate]

Gambar 3.14 DFD Level 1 evaluasi Proses yang terdapat pada data flow diagram digambarkan sesuai dengan alir sistem baru masing-masing stakeholder. Pada data flow diagram ini akan dijelaskan secara detail mengenai proses evaluasi, data flow diagram (DFD) untuk aplikasi yang terdiri dari 4 fungsional yaitu, Mengukur target yang telah tercapai, Mereview hasil temuan selama pelaksaan program, Menentukan jadwal rapat koordinasi,dan membuat laporan. Untuk lebih detailnya dapat dilihat pada tabel 3.22.

109

Tabel 3.22 Penjelasan DFD Level 1 evaluasi Nama Proses Evaluasi

No proses 3.1

Nama sub proses Evaluasi proporsi pasien positif diantara suspek

1. capaian proporsi pasien positif diantara suspek

3.2

Evaluasi proporsi pasien positif di antara semua pasien

1. capaian proporsi pasien positif diantara semua pasien

3.3

Evaluasi capaian angka konversi

1. data capaian angka konversi

3.4

Evaluasi capaian angka kesembuh an

Input

1. capaian angka kesembuh an

Uraian proses Proses ini menjelaskan mengenai aktifitas Evaluasi proporsi pasien positif diantara suspek Tabel yang dibaca: 1.detail_pengobat an Proses ini menjelaskan mengenai aktifitas Evaluasi proporsi pasien positif di antara semua pasien Tabel yang dibaca: 1.detail_pengobat an Proses ini menjelaskan mengenai aktifitas Evaluasi capaian angka konversi Tabel yang dibaca: 1.detail_pengobat an Proses ini menjelaskan mengenai aktifitas Evaluasi capaian angka kesembuhan Tabel yang dibaca: 1.detail_pengobat an

output 1. mutu proses penemuan dan diagnosa pasien Disimpan pada tabel:

-

1.penemuan pasien menular Disimpan pada tabel: -

1. hasil pengobatan

dan penilaian pengawas meminum obat Disimpan pada tabel: 1. prosentase pasien

baru positif yang sembuh Disimpan pada tabel: -

110

C. Entity Relationship Diagram Entity Relationship Diagram (ERD) merupakan suatu desain sistem yang digunakan untuk mempresentasikan, menentukan dan mendokumentasikan kebutuhan sistem kedalam suatu bentuk dengan tujuan untuk menunjukkan struktur keseluruhan dari data pemakai. Dalam perancangan aplikasi ini, telah terbentuk ERD yang merupakan lanjutan dari pembuatan desain dengan menggunakan Data Flow Diagram (DFD), yang disimbolkan dalam bentuk entity.

1. Conceptual Data Model (CDM) Conceptual Data Model (CDM) merupakan gambaran secara keseluruhan tentang konsep struktur basis data yang dirancang untuk program atau aplikasi yang akan dibuat untuk kedepannya. Adapun CDM yang ditunjukkan pada gambar 3.15.

Gambar 3.15 Conceptual Data Model (CDM)

111

2. Physical Data Model (PDM) Physical Data Model (PDM) menggambarkan secara detil konsep struktur basis data untuk suatu program atau aplikasi. PDM terbentuk dari Conceptual Data Model (CDM) yang menggambarkan tabel-tabel penyusun basis data beserta field-field yang terdapat pada setiap tabel. Adapun PDM tersebut dapat dilihat pada gambar 3.16.

Gambar 3.16 Physical Data Model (PDM)

D. Struktur Basis Data Sesuai dengan Physical Data Model (PDM) yang telah dirancang, dapat dibentuk suatu struktur basis data yang akan digunakan untuk penyimpanan data yaitu : 1. Nama Tabel Primary Key Fungsi

:

DATA_PASIEN

:

ID_PASIEN

: Menyimpan data pasien

112

Tabel 3.23 Struktur Tabel data_pasien No 1. 2. 3. 4. 5. 6. 7. 8. 11. 12. 13.

Field Id_pasien Id_instansi Nama_UPK Nama_pasien Jenis_kel Umur_pasien Alamat_pasien Kota_pasien Provinsi_pasien No_telp_pasien Parut_BCG

Tipe data Varchar (12) Varchar (12) Varchar (50) Varchar(30) Varchar (10) Integer Varchar(100) Varchar(20) Varchar(25) Varchar(15) Varchar(15)

constraint Primary Key Foreign Key Allow Null Allow Null Allow null Allow null Allow null Allow null Allow null Allow null Allow null

14.

Nama_PMO

Varchar(30)

Allow null

15.

Alamat_PMO

Varchar(100)

Allow null

16.

Status_Pasien

Varchar(30)

Allow null

keterangan Id_pasien Id_instansi Nama puskesmas Nama dari pasien Jenis kelamin pasien Usia dari pasien Alamat pasien Kota pasien Provinsi pasien No telp pasien Keterangan parut BCG pada pasien Nama pengawas meminum obat Alamat pengawas meminum obat Status pasien

1. Nama Tabel : PERMOHONAN_LAB Primary Key : ID_PERMOHONAN Fungsi

: Menyimpan data permohonan pemeriksaan laboratorium

Tabel 3.24 Struktur Tabel permohonan lab No 1.

Field Id_permohonan

Tipe data Varchar(12)

constraint Primary Key

2. 3. 4.

Id_pasien Klasifikasi Lokasi

Varchar (12) Varchar (15) Varchar(30)

Foreign Key Allow Null Allow Null

5.

Alasan

Varchar (30)

Allow null

6. 7.

No_Reg_TB No_Identitas_sedi

Varchar(8) Varchar(9)

Allow null Allow null

keterangan Id permohonan laboratorium Id_pasien Klasifikasi pasien Lokasi nyeri pada pasien Alasan pasien melakukan pemeriksaan laboratorium No registerasi TB Nomor identitas

113

8.

aan Tgl_ambil_terakhir

Date

Allow null

9.

Tgl_pengiriman

Date

Allow null

10.

Tanda_tangan_am bil

Varchar(30)

Allow null

11.

Sewaktu1

Varchar(30)

Allow null

12.

Pagi

Varchar(30)

Allow null

13.

Sewaktu2

Varchar(30)

Allow null

14.

No_reg_lab

Varchar(5)

Allow null

15.

Spes_sewaktu1

Varchar(10)

Allow null

No 16.

Field Spes_pagi


constraint Allow null

17.

Spes_sewaktu2

Varchar(10)

Allow null

18.

Tgl_periksa_s1

Date

Allow null

19.

Tgl_periksa_pagi

Date

Allow null

20.

Tgl_periksa_s2

Date

Allow null

21.

Nma_pemeriksa

Varchar(30)

Allow null

sediaan pasien Tanggal pengambilan dahak terakhir pasien Tanggal pengiriman dahak pasien ke laboratorium Tanda tangan pengambil sediaan pasien Visual dahak pasien saat pengambilan dahak pertama Visual dahak pasien saat pengambilan dahak pagi hari Visual dahak pasien saat pengambilan dahak terakhir No registerasi laboratorium pemeriksa Spesimen dahak pada saat pengambilan sampel pertama keterangan Spesimen dahak pada saat pengambilan sampel pagi Spesimen dahak pada saat pengambilan sampel terakhir Tanggal pemeriksaan dahak pertama Tanggal pemeriksaan dahak pagi Tanggal pemeriksaan dahak terakhir Nama pemeriksa dahak

114

2. Nama Tabel : KARTU_PENGOBATAN Primary Key : ID_PENGOBATAN Fungsi

: Menyimpan data pengobatan pasien Tabel 3.25 Struktur Tabel kartu pengobatan

No 1.

Field Id_pengobatan



2. 3.

Id_pasien Tahun_pengobatan

Varchar (12) Varchar (5)

Foreign Key Allow Null

4.

No_reg_tb03_upk

Varchar(8)

Allow Null

5.

Riwayat_berobat

Varchar (30)

Allow null

6.

Catatan

Varchar(1000)

Allow null

7.

Tipe_pas

Varchar(30)

Allow null

No 8.

Field Jenis_obat


constraint Allow null

9.

Kategori

Varchar(15)

Allow null

10.

Jml_KDT

Integer

Allow null

11.

Jml_streptomicin

Integer

Allow null

keterangan Id pengobatan pasien Id_pasien Tahun pasien melakukan pengobatan No registerasi TB03 upk Riwayat pengobatan pasien Catatan tambahan pasien Tipe pasien

keterangan Jenis obat yang diberikan pada pasien Kategori pasien saat melakukan pengobatan Jumlah obat KDT yang diberikan pada pasien Jumlah obat streptomicin yang diberikan pada pasien

115

3. Nama Tabel : HSL_PERIKSA_DHK Primary Key : ID_PERIKSA_DHK Fungsi

: Menyimpan data hasil periksa dahak pasien Tabel 3.26 Struktur Tabel periksa dahak

No 1.

Field Id_periksa_dhk



2.

Id_pengobatan

Varchar(12)

Foreign Key

3.

Bulan_ke

Varchar (3)

Allow Null

4.

Tgl_hsl_periksa_dhk

Date

Allow Null

5.

No_reg_lab_periksa

Varchar (5)

Allow null

6.

BTA

Varchar(10)

Allow null

7.

BB

Integer

Allow null

keterangan Id periksa dahak pasien Id pengobatan pasien Urutan bulan pemeriksaan pasien Tanggal hasil pemeriksaan dahak dirilis No registerasi laboratorium pemeriksa dahak Hasil BTA pemeriksaan laboratorium Berat badan pasien

4. Nama Tabel : TAHAP_INTENSIF Primary Key : ID_INTENSIF Fungsi

: Menyimpan data pengobatan tahap intensif pasien Tabel 3.27 Struktur Tabel tahap intensif

No 1.

Field Id_intensif



2.

Id_pengobatan

Varchar(12)

Foreign Key

3.

Tgl_periksa_intensif

Date

Allow Null

4.

Status_intensif

Varchar(10)

Allow Null

keterangan Id intensif pegobatan pasien Id pengobatan pasien Tanggal pemeriksaan intensif pasien secara berkala Status pasien yang melakukan pengobatan rutin

116

5. Nama Tabel : INSTANSI Primary Key : ID_INSTANSI Fungsi

: Menyimpan data instansi yang menjalankan sistem Tabel 3.28 Struktur Tabel instansi

No 1. 2. 3. 4. 5.

Field Id_intansi Nama_instansi Alamat_instansi kecamatan kelurahan

Tipe data Varchar(12) Varchar(50) Varchar(100) Varchar(30) Varchar(30)

constraint Primary Key Allow null Allow Null Allow null Allow null

keterangan Id instansi Nama instansi Alamat instansi Nama kecamatan Nama Kelurahan

3.3.3 Perancangan Prosedur dan Program Unit Detil Sistem merupakan penjabaran aplikasi dengan menggunakan pseudocode sehingga konstruksi awal pemrograman aplikasi yang akan dibangun dapat terlihat serta memberikan deskripsi dari setiap fungsi yang akan dibangun, dan juga disertai dengan desain tampilan antarmuka aplikasi. Pada tugas akhir ini, penjelasan lebih detil dari sistem akan dibagi dan disesuaikan dengan pengguna aplikasi yang sudah dijelaskan sebelumnya. Perancangan ini tentu saja disesuaikan dengan proses-proses yang ada pada Data Flow Diagram (DFD). Berikut adalah rancangan yang disesuaikan dengan fungsional dan pengguna sistem nantinya. a)

puskesmas

1.

petugas TB Menampilkan menu untuk mencatat dan melaporkan form harian, seperti terlihat pada Tabel 3.28.

117

Tabel 3.29 Detil Form Mencatat dan melaporkan form harian Nama Fungsi Stakeholder Deskripsi Desain Interface

Pencatatan harian Petugas TB Fungsi form ini digunakan untuk melakukan pencatatan data pasien Pencatatan daftar pasien(form TB06) Nama Puskesmas:

Nama puskesmas

Nama pasien:

Nama pasien

Usia :

Usia pasien

Jenis kelamin :

L

P

Alamat lengkap: Alamat lengkap pasien

Kecamatan :

kecamatan

Kelurahan :

Kelurahan

Simpan

Deskripsi Nama Fungsi Desain Interface

Fungsi form ini digunakan untuk melakukan pencatatan pemeriksaan laboratorium (klasifikasi penyakit dan alasan pemeriksaan lab) Pencatatan harian Permohonan laboratorium (klasifikasi penyakit dan alasan pemeriksaan)(form TB05) Nama Puskesmas:

Nama puskesmas

Nama Pasien:

Nama pasien

....

Klasifikasi Penyakit : Paru Ekstra paru Sebutkan : Alasan pemeriksaan:

Bagian tubuh yang sakit

Diagnosa Akhir tahap awal Akhir sisipan 1 bulan sebelum AP Akhir Pengobatan (AP)

Simpan

118

Deskripsi Desain Interface

Fungsi form ini digunakan untuk mencatat proses permohonan laboratorium(pengambilan dahak)(form TB05) Permohonan laboratorium (pengambilan dahak)(form TB05) Nomor Identitas Sediaan:

No kabupaten

/

Tanggal Pengambilan dahak:

Tgl pengambilan dahak

Tanggal pengiriman dahak :

Tgl pengiriman dahak

No puskesmas

/

No sediaan

Visual dahak tampak : Nanah lendir :

Sewaktu

Bercak darah:

Sewaktu

Air liur :

Sewaktu

Pagi

Pagi

Pagi

Sewaktu

Sewaktu

Sewaktu

Tanda tangan pengambil spesimen :

Nama pengambil

Simpan

Deskripsi

Fungsi form ini digunakan untuk mencatat proses permohonan laboratorium(hasil laboratorium)(form TB05)

Nama Fungsi Desain Interface

Pencatatan harian Permohonan laboratorium (hasil laboratorium)(form TB05) Nomor registerasi laboratorium:

No registerasi lab Keterangan:

Spesimen :

Hasil :

Tgl pemeriksaan pertama

Sewaktu

+++

Positif

Tgl pemeriksaan pagi

Pagi

+++

Positif

Tgl pemeriksaan terakhir

Sewaktu

+++

Positif

Tanggal pemeriksaan:

Tanda tangan pemeriksa:

Nama pemeriksa

Simpan

Deskripsi

Fungsi form ini digunakan untuk mencatat data pengobatan (pengawas meminum obat)(form TB01)

119

Desain Interface

Pengobatan pasien(pengawas meminum obat)(TB01) Nama Puskesmas:

Nama puskesmas

Nama pasien:

Nama pasien

Nama PMO:

Nama PMO

Status PMO:

Status PMO

....

Alamat PMO: Alamat lengkap pasienPMO

Kecamatan :

kecamatan

Kelurahan :

Kelurahan

Simpan

Nama Fungsi Deskripsi

Pencatatan harian Fungsi form ini digunakan untuk mencatat data pengobatan (tipe pasien)(TB01)

120

Desain Interface

Pengobatan pasien(Tipe pasien)(TB01) Tahun :

Tahun memulai pengobatan

No Registerasi TB kabupaten/kota :

No reg TB kota

Parut BCG :

Jelas Tidak ada meragukan

__________________________________________________________________ Riwayat Pengobatan :

Belum pernah/kurang dari 1 bulan

Pernah diobati lebih dari 1 bulan __________________________________________________________________ Tipe pasien :

Baru Kambuh Pengobatan setelah default gagal

kronis __________________________________________________________________ Catatan : Catatan pendukung

Simpan

Deskripsi Desain Interface

Fungsi form ini digunakan untuk mencatat data pengobatan (hasil periksa dahak)(TB01) Pengobatan pasien(hasil periksa dahak)(TB01) Bulan ke :

Bulan pemeriksaan

Tanggal pemeriksaan:

Tanggal pemeriksaan

No registerasi lab:

No registerasi lab

BTA:

Hasil BTA

Berat badan:

Berat badan pasien

Simpan

Deskripsi

Fungsi form ini digunakan untuk mencatat data pengobatan (pengobatan rutin)(TB01)

121

Desain Interface

Pengobatan pasien(pengobatan rutin)(TB01) Status :

Status pasien

Tanggal berobat:

Tgl berobat

Jenis obat:

Kombipak KDT(FDC)

__________________________________________________________________ Kategori :

Kategori -1 Kategori -2 Anak Sisipan

__________________________________________________________________ Jumlah obat:

4KDT(FDC)

Jumlah obat

Streptomicin

Jumlah obat

Hasil akhir :

Hasil akhir pasien

Simpan

Table Input Table Output Kebutuhan NonFungsional

Data_pasien, instansi, hsl_periksa_dhk, tahap_intensif, keterangan_thp_intensif Permohonan_lab, kartu_pengobatan Security Correctness Interface Performance Operability

122

b) Dinas Kesehatan 1.

Wasor TB Menampilkan menu untuk melakukan monitoring, seperti terlihat pada tabel 3.29. Tabel 3.30 Detil Form monitoring

Nama Fungsi Stakeholder Deskripsi Desain Interface

Monitoring

Deskripsi

Fungsi form ini digunakan untuk monitoring hasil penemuan pasien dan hasil

Wasor TB Fungsi form ini digunakan untuk monitoring angka penjaringan suspek

pengobatan pasien

Table Input Table Output Pseudocode Kebutuhan NonFungsional

M_pasien, M_puskesmas, T_pemeriksaan laboratorium, T_pengobatan pasien M_indikator 1. Save monitoring dan analisa() 2. Get data monitoring dan analisa() Security Correctness Operability

123

2.

Kasie P2M Menampilkan menu untuk melakukan evaluasi seperti terlihat pada tabel 3.31. Tabel 3.31 Detil Form evaluasi

Nama Fungsi Stakeholder Deskripsi Desain Interface

evaluasi

Table Input Table Output Pseudocode

M_pasien, M_puskesmas, T_pemeriksaan laboratorium, T_pengobatan pasien M_indikator

Kebutuhan NonFungsional

KaSie P2M Fungsi form ini digunakan untuk evaluasi penemuan pasien TB

1. Save evaluasi() 2. Get data evaluasi dan analisa() Security Correctness Interface

124

Performance Operability

3.3.4 Program Unit Program unit merupakan kumpulan dari setiap pseudocode yang ada dalam setiap fungsi yang akan dibangun yang berfungsi sebagai dasar dalam membangun aplikasi dan menerapkan fungsi-fungsi tersebut ke dalam pemrograman dan konstruksi aplikasi yang akan dikembangkan. Program unit tersebut seperti terlihat pada tabel 3.32. Tabel 3.32 Program Unit Sistem Nama Fungsional Pencatatan dan pelaporan form harian

Proses 1. mencatat data pasien

Program Unit 1. Login() 2. Save data pasien()

2. mencatat form permohonan lab

1. Save permohonan lab() 2. Save hasil periksa dahak()

3. mencatat data pengobatan pasien

Monitoring

Monitoring

Evaluasi

Evaluasi

1. Save kartu pengobatan pasien( ) 2. update data pasien() 3. Save kontak serumah() 4. Save keterangan tahap intensif() 5. Save tahap intensif () 3. Login( ) 4. Get data monitoring( ) 1. Login() 2. Get data evaluasi()

125

3.3.5 Program Pseudocode Berikut ini merupakan hasil rancangan pseudocode secara detil dari beberapa program unit yang telah dirancang, Adapun hasil pseudocode program unit dan listing program dapat dilihat pada tabel 3.32. Tabel 3.32 Program Flowchart dan Pseudocode Program Unit Login ()

Save data pasien()

Pseudocode START U=”user_name” P=”password” READ U,P IF U="user_name" and P=”password” THEN WRITE "selamat datang, anda login sebagai puskesmas kedurus" ELSE WRITE "username dan password salah, silahkan masukan username dan password ulang" ENDIF END START Idp=”id_pasien” Idi=”id_instansi” Nupk=”nama_upk” Npas=”nama_pasien” Jk=”jenis_kelamin” Um=”umur” Ap=”alamat_pasien” Kp=”kota_pasien” Pv=”provinsi_pasien” Ntelp=”no_telp_pasien” Pbcg=”parut_BCG” Npmo=”nama_PMO” Alpmo=”alamat_PMO” Statp=”status_pasien” INSERT idp, idi, nupk, npas, jk, um, ap, kp, pv, ntelp, pbcg, npmo, alpmo, statp TO data_pasien WHILE idp, idi, nupk, npas, jk, um, ap, kp, pv, ntelp, pbcg, npmo, alpmo, statp = 0 DO WRITE “data kolom tidak boleh kosong” ENDWHILE WRITE “data telah tersimpan” END

126

Pseudocode Program Unit Save data START pemeriksaan Idpl=”id_permohonan_lab” laboratorium() Idp=”id_pasien” Kls=”klasifikasi” Lks=”lokasi” Als=”alasan” Nrt=”no_reg_tb” Nis=”no_identitas_sediaan” Tat=”tgl_ambil_terakhir” Tp=”tgl_pengiriman” Tta=”tanda_tangan_pengambil” Nl=”nanah_lendir” Bd=”bercak_darah” Al=”air_liur” Nrl=”no_reg_lab” Ss1=”spesimen_sewaktu1” Sp=”spesimen_pagi” Ss2=”spesimen_sewaktu2” Tps1=”tgl_pengambilan_sewaktu1” Tpp=”tgl_pengambilan_pagi” Tps2=”tgl_pengambilan_sewaktu2” Npem=”nama_pemeriksa” INSERT idpl, idp, kls, als, nrt, nis, tat, tp, tta, nl, bd, al, nrl, ss1, sp, ss2, tps1, tpp, tps2, npem TO permohonan_lab IF kls = “ekstra_paru” THEN READ lks ENDIF WHILE idpl, idp, kls, als, nrt, nis, tat, tp, tta, nl, bd, al, nrl, ss1, sp, ss2, tps1, tpp, tps2, npem = 0 DO WRITE “kolom tidak boleh kosong” ENDWHILE WRITE “data telah tersimpan” END

127

Pseudocode Program Unit Save hasil START periksa dahak() Idpd=”id_periksa_dahak” Idobt=”id_pengobatan” blnk=”bln_ke” thpd=”tgl_hsl_periksa_dahak” nrlp=”no_reg_lab_periksa” bta=”bta” bb=”berat_badan” INSERT idpd, idobt, blnk, thpd, nrlp, bta, bb TO hsl_periksa_dhk WHILE idpd, idobt, blnk, thpd, nrlp, bta, bb = 0 DO WRITE “data kolom tidak boleh kosong” ENDWHILE WRITE “data telah tersimpan” END Save kartu START pengobatan pasien() Idobt=”id_pengobatan” Idp=”id_pasien” thobt=”th_pengobatan” Nrtb03=”no_reg_tb03_upk” rb=”riwayat_berobat” ctt=”catatan” tpe=”tipe_pasien” jns=”jenis_obat” ktgr=”kategori_pasien” jkdt=”jml_kdt” jstrep=”jml_streptomicin” INSERT idp, idobt, thobt, nrtb03, rb, ctt, tpe, jns, ktgr, jkdt, jstrep TO kartu_pengobatan WHILE idp, idobt, thobt, nrtb03, rb, ctt, tpe, jns, ktgr, jkdt, jstrep = 0 DO WRITE “data kolom tidak boleh kosong” ENDWHILE WRITE “data telah tersimpan” END

128

Program Unit Save tahap intensif ()

Pseudocode START Idint=”id_intensif” Idobt=”id_pengobatan” tpint=”tgl_periksa_intensif” statint=”status_intensif” INSERT idint, idobt, tpint, statint TO tahap_intensif WHILE idint, idobt, tpint, statint = 0 DO WRITE “data kolom tidak boleh kosong” ENDWHILE WRITE “data telah tersimpan” END

Program Unit Get data monitoring ( )

Get evaluasi ( )

data

Pseudocode start inp1="inputan 1" inp2="inputan 2" read inp1, inp2, capaian, ind capaian=inp1/inp2*100 IF capaian >= ind THEN write"angka capaian telah melebihi batas maximum" ENDIF end start tr1=” triwulan 1” tr2="triwulan 2" tr3="triwulan 3" tr4="triwulan 4" read tr1, tr2,tr3,tr4, capaian, ind capaian=tr1+tr2+tr3+tr4/4 IF capaian >= ind THEN write"angka capaian telah melebihi batas maximum" ENDIF end

129

3.3.6 Desain Uji Coba Fungsional

Desain uji coba (testing) fungsional pada sistem ini akan dilakukan menggunakan metode white box, yang berarti bahwa pengujian sistem yang didasarkan pada pengecekan terhadap detail perancangan di setiap fungsional sistem. Beberapa fungsi-fungsi yang akan dilakukan pengujian, diantaranya: A. Petugas TB Kebutuhan testing pada masing-masing test case sesuai dengan skenario yang telah dibuat untuk Fungsi Fungsi Pencatatan Harian oleh Petugas TB dapat dilihat pada Tabel 3.33 Tabel 3.33 Skenario Testing Fungsi Pencatatan Nama Fungsi Stakeholder Deskripsi Alur Normal

Fungsi Pencatatan Petugas TB Proses ini merupakan desain sekenario testing dalam fungsi mencatat data periksa laboratorium dan pengobatan pasien Memasukan Data Suspek INPUT 1. Petugas TB memilih menu data daftar pasien. 2. Petugas TB memasukan data-data pasien pada form daftar pasien dan tekan tombol “simpan” 3. Petugas TB memasukan data-data pada form hasil laboratorium dan tekan tombol simpan PROSES Sistem akan mengecek semua validasi pada kolom-kolom yang tersedia. OUTPUT Sistem akan menyimpan data suspek dan hasil laboratorium. Memasukan Data Permohonan Laboratorium INPUT 1. Petugas TB memilih menu pengobatan pasien 2. Petugas TB memasukan data-data pada form pengobatan dan menekan tombol “simpan” 3. Petugas TB memasukan data-data pada hasil akhir dan menekan tombol “simpan”

130

PROSES Sistem akan mengecek semua validasi pada kolom-kolom yang tersedia. OUTPUT Sistem akan menyimpan data pengobatan pasien dan data hasil akhir Memasukan Data Pengobatan Pasien INPUT 4. Petugas TB memilih menu pengobatan pasien 5. Petugas TB memasukan data-data pada form pengobatan dan menekan tombol “simpan” 6. Petugas TB memasukan data-data pada hasil akhir dan menekan tombol “simpan” PROSES Sistem akan mengecek semua validasi pada kolom-kolom yang tersedia. OUTPUT Sistem akan menyimpan data pengobatan pasien dan data hasil akhir B. Wasor TB Kebutuhan testing pada masing-masing test case sesuai dengan skenario yang telah dibuat untuk Fungsi Monitoring oleh Wasor TB dapat dilihat pada Tabel 3.34. Tabel 3.34 Skenario Testing Fungsi Monitoring Nama Fungsi Stakeholder Deskripsi Alur Normal

Fungsi monitoring Wasor TB Proses ini merupakan desain sekenario testing dalam fungsi Monitoring Monitoring INPUT Wasor TB memilih menu monitoring PROSES Sistem akan memproses data monitoring OUTPUT Sistem akan menampilkan data monitoring

131

C. Kepala Seksi Pengendalian penyakit menular Kebutuhan testing pada masing-masing test case sesuai dengan skenario yang telah dibuat untuk Fungsi evaluasi oleh Kepala Seksi pengendalian penyakit menular dapat dilihat pada Tabel 3.24. Tabel 3.35 Skenario Testing Fungsi evaluasi Nama Fungsi Stakeholder Deskripsi Alur Normal

Fungsi evaluasi Kasie P2M Proses ini merupakan desain sekenario testing dalam fungsi evaluasi evaluasi INPUT 1. Wasor TB memilih menu “monitoring angka penjaringan suspek” PROSES Sistem akan menghitung dan menganalisa data evaluasi OUTPUT Sistem akan menampilkan dashboard evaluasi

3.3.7 Desain Uji Coba Non- Fungsional

Desain uji coba (testing) non-fungsional pada sistem ini akan dilakukan menggunakan metode white box, yang berarti bahwa pengujian sistem yang didasarkan pada pengecekan terhadap detail perancangan di setiap non-fungsional sistem. Detail dari desain tersebut terlihat pada Tabel 3.36 berikut ini. Tabel 3.36 Skenario Uji Coba Non-Fungsional Non-Fungsional Correctnes

Security Interface

Skenario Sistem akan menampilkan pesan kepada stakeholder , jika stakeholder menjalankan aplikasi tidak berdasarkan rule yang ada. Sistem akan membatasi menu-menu yang dapat diakses oleh stakeholder berdasarkan role yang dimiliki stakeholder . Sistem menggunakan bahasa indonesia

132

Non-Fungsional

Operability

Performance

Skenario dalam fungsionanya sehingga mudah dipahami oleh stakeholder dan dapat dibaca secara jelas. Sistem memberikan manual book sebagai pedoman menjalankan sistem secara baik dan benar. Sistem apakah mampu berjalan dengan baik walaupun dengan beban stakeholder (25 orang) secara bersamaan.

3.3.8 Desain Implementasi Data

Desain implementasi data ini berfungsi sebagai pengujian sistem yang didasarkan pada alir data di setiap detail perancangan fungsional sistem. Dalam desain implementasi data ini akan digunakan sepuluh data puskesmas yang masing-masing puskesmas akan terdiri dari sepuluh data pasien. Beberapa fungsifungsi yang akan dilakukan pengujian, diantaranya: A. Petugas puskesmas Pengujian implementasi data untuk Fungsi pencatatan dan pelaporan harian oleh Petugas TB dapat dilihat pada Tabel 3.37. Tabel 3.37 Skenario Testing Fungsi pencatatan dan pelaporan harian Nama Fungsi Stakeholder Deskripsi Alur Normal

Fungsi pencatatan Petugas TB Proses ini merupakan desain implementasi data dalam fungsi pencatatan Memasukan Data suspek INPUT 1. Data puskesmas 2. Data pasien 3. Data pemeriksaan laboratorium PROSES Sistem akan mengecek apakah data tersebut valid atau tidak berdasarkan tipe dari data itu sendiri

133

OUTPUT 1. Data pasien 2. data hasil pemeriksaan laboratorium Memasukaan Data Periksa Lab INPUT 1. Data pemeriksaan laboratorium 2. Data hasil Periksa Lab PROSES Sistem akan mengecek apakah data tersebut valid atau tidak berdasarkan tipe dari data itu sendiri OUTPUT 1. Data periksa Lab 2. data hasil pemeriksaan laboratorium Memasukan Data pengobatan INPUT Data pengobatan PROSES Sistem akan mengecek apakah data tersebut valid atau tidak berdasarkan tipe dari data itu sendiri. OUTPUT 1.Data pengobatan 2. data hasil pengobatan

B. Wasor TB Pengujian implementasi data untuk Fungsi monitoring oleh Wasor TB dapat dilihat pada Tabel 3.38. Tabel 3.38 Skenario Testing Fungsi monitoring Nama Fungsi Stakeholder Deskripsi Alur Normal

Fungsi monitoring Wasor TB Proses ini merupakan desain implementasi data dalam fungsi monitoring Monitoring INPUT 1. Data indikator 2. Data penemuan pasien 3. Data data hasil pengobatan PROSES Sistem akan menghitung dan menampilkan hasil monitoring

134

OUTPUT Data hasil monitoring

C. Kepala Seksi Pengendalian Penyakit menular Pengujian implementasi data untuk Fungsi evaluasi oleh Kepala Seksi pengendalian penyakit menular dapat dilihat pada Tabel 3.39 Tabel 3.39 Skenario Testing Fungsi evaluasi Nama Fungsi Stakeholder Deskripsi

Alur Normal

Fungsi evaluasi Kepala Seksi Pengendalian Penyakit menular Proses ini merupakan desain implementasi data dalam fungsi evaluasi yang dilakukan oleh Kepala Seksi Pengendalian Penyakit bagi puskesmas yang telah menjalankan program penanggulangan TB Evaluasi INPUT Data data hasil monitoring PROSES Sistem akan mengkalkulasi hasil capaian sesuai dengan tahun dan periode yang dipilih OUTPUT Data evaluasi

3.3.9 Desain Arsitektur

Pengembangan perangkat lunak perlu adanya perangkat keras yang tepat, sehingga perangkat lunak tidak mengalami gangguan dan dapat berjalan dengan baik. Kebutuhan sisitem memberikan definisi keperluan perangkat keras untuk mendukung kinerja perangkat lunak yang terdiri dari spesifikasi sistem, spesifikasi hosting, dan spesifikasi lainnya.

135

Sesuai dari hasil dari kebutuhan perangkat lunak yang akan digunakan, dapat memberikan solusi peragkat lunak dan perangkat keras yang akan digambarkan pada gambar 3.16.

Web Server

Modem

Modem Internet

Internet

Gambar 3.17 WEB Client

Dari gambar diatas dapat dilihat bahwa terdiri dari 4 komputer, Domain, dan Hosting server. Adapun spesifikasi minimum perangkat keras pada puskesmas dan dinas kesehatan untuk mendukung kinerja perangkat lunak yang dikembangkan dapat dilihat pada tabel 3.40. Tabel 3.40 Spesifikasi Kebutuhan Perangkat Keras

a) b) c) d) e) f) g) h)

Spesifikasi kebutuhan perangkat keras Client Hosting Prosessor Intel Core 2 Duo 2GHz a) Space 50 GB 2 GB RAM DDR2 b) Bandwith 1 GB/Month 120 GB HDD c) Anti Spam Standart VGA d) MySQL Database Network Interface Card e) 10 Table LCD Monitor Keyboard Optical Mouse

BAB III ANALISIS DAN PERANCANGAN SISTEM. Bangun Sistem Informasi Monitoring dan Evaluasi Pelaksanaan Program

Recommend Documents