ANALISIS DAN PERANCANGAN

BAB 3 Analisis Dan Perancangan

BAB 3. 3.1

ANALISIS DAN PERANCANGAN

Metodologi Dalam penelitian ini, kerangka kerja software engineering yang digunakan

adalah metode waterfall. Dengan kondisi dimana jangka waktu penelitian sangat sempit dan sumber daya manusia yang terbatas, maka metode waterfall dirasa sesuai untuk dijadikan dasar penelitian ini dibanding dengan metode-metode lainnya.

Gambar 3.1 Metode Waterfall Penelitian ini diawali dengan sebuah penelitian kecil mengenai penggunaan rekam medis elektronik pada rumah sakit di DKI Jakarta. Total DKI Jakarta memiliki 154 unit rumah sakit yang tersebar di 5 kota madya, Jakarta Pusat, Jakarta Barat, Jakarta Timur, Jakarta Utara, dan Jakarta Selatan.

35

36

Gambar 3.2 Data Persebaran Rumah Sakit di DKI Jakarta per 6 Maret 2014 (sumber: depkes.go.id) Adapun secara terperinci pembagian rumah sakit per kota madya lengkap dengan tingkatan klasifikasi yang telah ditetapkan oleh Otoritas tertinggi yang menangani perumahsakitan di Indonesia, Departemen Kesehatan Republik Indonesia, adalah sebagai berikut (data pada lampiran): 1. Jakarta Pusat memiliki total 45 unit rumah sakit, dengan tingkatan klasifikasi, 45 unit rumah sakit tidak teridentifikasi. 2. Jakarta Barat memiliki total 21 rumah sakit, dengan tingkatan klasifikasi, 4 unit rumah sakit kelas A, 5 unit rumah sakit kelas B, 6 unit rumah sakit kelas C, 1 unit rumah sakit non-kelas, dan 6 unit rumah sakit tidak teridentifikasi. 3. Jakarta Timur memiliki total 33 unit rumah sakit, dengan tingkatan klasifikasi, 3 unit rumah sakit kelas A, 10 unit rumah sakit kelas B, 7 unit rumah sakit kelas C, 4 unit rumah sakit kelas D, 2 unit rumah sakit non-kelas, dan 7 rumah sakit tidak teridentifikasi. 4. Jakarta Utara memiliki total 18 unit rumah sakit, dengan tingkatan klasifikasi, tidak ada rumah sakit kelas A, 8 unit rumah sakit kelas B, 5 unit rumah sakit kelas C, 4 unit rumah sakit kelas D, 1 unit rumah sakit non-kelas, dan tidak ada rumah sakit yang tidak teridentifikasi. 5. Jakarta Selatan memiliki total 37 unit rumah sakit, dengan tingkatan klasifikasi, 2 unit rumah sakit kelas A, 5 unit rumah sakit kelas B, 12 rumah

37 sakit kelas C, 3 unit rumah sakit kelas D, 2 unit rumah sakit non-kelas, dan 13 rumah sakit tidak teridentifikasi.

Dengan menganggap rumah sakit yang tidak teridentifikasi adalah kesalahan human error, maka dari data tersebut didapatkan fakta sebagai berikut : 1. Jakarta Pusat memiliki persebaran jumlah rumah sakit terbesar di antara keempat kota madya lainnya dengan total 45 unit, Jakarta Selatan di posisi kedua dengan 37 unit, Jakarta Timur di posisi ketiga dengan 33 unit, Jakarta Barat di posisi keempat dengan 21 unit , dan terakhir adalah Jakarta Utara dengan 18 unit. 2. Jakarta Barat memiliki persebaran jumlah rumah sakit dengan tingkatan klasifikasi kelas A terbesar dengan 4 unit, Jakarta Timur di posisi kedua dengan 3 unit, Jakarta Selatan di posisi ketiga dengan 2 unit, Jakarta Utara tidak memiliki rumah sakit dengan tingkatan klasifikasi kelas A, sedang Jakarta Pusat tidak dapat diikutsertakan. 3. Jakatrta Utara memiliki tingkat kesalahan human error terkecil dengan tidak adanya rumah sakit yang tidak teridentifikasi terkait tingkatan klasifikasi rumah sakit, Jakarta Barat di posisi kedua dengan 6 unit, Jakarta timur di posisi ketiga dengan 7 unit, Jakarta Selatan di posisi keempat dengan 13 unit, sedang Jakarta Pusat menjadi yang terbesar tingkatan kesalahan human error.

Dengan menggunakan teknik cluster sampling, setelah mempertimbangkan aspek tingkatan klasifikasi rumah sakit dan tingkat kesalahan human error, peneliti memilih Jakarta Barat sebagai sampel penelitian. Rumah sakit dengan tingkatan klasifikasi kelas A terbanyak dan rumah sakit dengan tingkat kesalahan terkecil kedua setelah Jakarta Utara, alasan kenapa Jakarta Barat terpilih sebagai sampel penelitian ini. Dengan menyebarkan kuesioner kepada 21 unit rumah sakit, hanya 10 unit rumah sakit yang mengembalikan kuesioner peneliti. Adapun 10 unit rumah sakit ini terdiri atas 4 unit rumah sakit dengan tingkatan klasifikasi kelas A, 1 unit rumah sakit kelas B, 3 unit rumah sakit kelas C, dan 2 unit rumah sakit dengan tingkatan klasifikasi yang tidak teridentifikasi. Dan dengan melakukan perhitungan menggunakan rumus penentuan jumlah sampel yang ada pada bab 2, didapatkan taraf signifikansi data sebesar 50% dengan dk sama dengan 1.

38 Selain menyebarkan kuisoner untuk menemukan permasalahan rekam medis. Peneliti juga bekerja sama dengan Rumah Sakit Pusat Angakatan Darat Gatot Soebroto agar mendapatkan data yang akurat mengenai sistem pengolahan rekam medis pada suatu rumah sakit. Selama kurang lebih satu minggu, survey dilaksanakan, termasuk didalamnya wawancara terhadap stakeholder-stakeholder yang terkait dengan rekam medis. Semua hasil dari survey dan wawancara tersebut akan disusun untuk mengindentifikasi semua permasalahan yang terjadi. Jika semua permasalahan sudah teridentifikasi dan segala kebutuhan para stakeholder sudah semua terkumpul, maka dimulailah tahapan perencanaan. Setelah data-data yang diperlukan sudah lengkap maka dilakukan tahap perencanaan. Dalam tahap ini peneliti membuat perkiraan waktu yang diperlukan dalam pengembangan aplikasi dan langkah-langkah apa yang perlu dilakukan setelahmya. Setelah itu dilakukan perencanaan, tahap selanjutnya adalah tahap perancangan. Dalam tahapan ini terdapat juga di dalamnya rancangan antarmuka aplikasi rekam medis elektronik. Rancangan antarmuka ini kemudian diajukan kepada pihak rumah sakit sebagai buah pemecahan dari permasalahan yang mereka alami. Tahapan ini pula yang akan menjadi gambaran besar bagaimana penyelesaian dan pengharapan aplikasi rekam medis elektronik. Setelah rancangan aplikasi telah disetujui oleh pihak rumah sakit, tahapan selanjutnya adalah perancangan diagram-diagram UML. Tahapan ini dimulai dengan merancang diagram use-case, diagram aktivitas, diagram kelas, kemudian diakhiri dengan diagram sequences. Diagram-diagram ini nantinya akan membantu tahapan implementasi pengkodean aplikasi. Pada tahapan pengembangan pengkodean aplikasi digunakan dengan menggunakan bahasa pemrograman html, javascript, dan php yang kemudian dibungkus dalam framework phonegap. Dengan menggunakan bahasa-bahasa tersebut diharapkan akan mempermudah dan mempercepat programmer dalam pengimplementasian ke dalam basis mobile dan basis web. Sebagai tambahan, basis data yang digunakan adalah MySQL. Setelah aplikasi telah selesai dan basis data telah tertanam dalam server, langkah berikutnya adalah menguji coba aplikasi apakah masih ada kesalahan yang mucul dalam menjalan aplikasi. Setelah tahap pengembangan telah selesai, tahap selanjutnya adalah memverifikasi kebutuhan rumah sakit dengan fitur-fitur yang ditawarkan dalam aplikasi. Dalam prakteknya, tahapan ini juga sekaligus menguji kepuasan para

39 stakeholder terhadap sistem yang dikembangkan guna mengatasi permasalahan pada sistem yang sedang berjalan sekarang. Pada tahap ini juga dilakukan pengambilan tingkat kepuasan user dalam menggunakan aplikasi ini. Adapun metode yang digunakan untuk mengukur tingkat kepuasan para stakeholder adalah dengan cara menggunakan kuisoner dan juga metode wawancara dengan menggunakan metode purposive sampling. Hasil kuisoner dan wawancara tersebut akan menjadi salah satu penilaian evaluasi terhadap penelitian ini. Segala kekurangan dan kelebihan akan menjadi saran dan acuan agar penelitian berikutnya dapat memberikan hasil yang lebih memuaskan.

3.2

Analisis

3.2.1 Analisis sistem yang berjalan Rumah Sakit Pusat Angkatan Darat Gatot Soebroto adalah salah satu rumah sakit yang masih menerapkan metode rekam medis konvensional dengan kertas sebagai medianya. Meskipun dengan lokasi peyimpanan rekam medis pasien yang sudah terpusat, dengan jumlah kunjungan pasien yang setiap harinya ratusan, berbanding terbalik dengan berbatasnya karyawan bagian penyimpanan rekam medis, sistem pengolahan rekam medis pun yang sekarang dijalankan dirasa kurang memuaskan. Padahal dengan maksud efisiensi pekerjaan, pihak rumah sakit telah menerapkan dua sistem yang berbeda dalam melayani pencarian dan pengantaran rekam medis pasien. Kedua sistem ini ditentukan dengan kondisi pasien ketika datang kepada rumah sakit, ketika pasien dalam kondisi normal atau dalam kondisi darurat. Dalam kondisi normal memiliki arti bahwa pasien datang dalam kondisi tersadarkan diri dan tidak dalam kondisi yang membahayakan keselamatan jiwanya. Tujuan pasien ini biasanya hanya untuk berkonsultasi mengenai kesehatannya meskipun secara fisik ia sehat. Pasien dapat datang pada instalasi poliklinik tergantung pada keluhan yang ia miliki. Ketika pasien belum mengetahui secara pasti poliklinik apa yang harus ia tuju, maka pegawai loket pendaftaran akan meneruskan pasien kepada dokter umum. Namun apabila pasien telah mengetahui poliklinik apa yang harus ia tuju sesuai dengan keluhannya,

40 maka pegawai loket pendaftaran akan mendaftarkan pasien langsung kepada dokter poliklinik yang bersangkutan. Sesudah proses pendaftaran, pasien akan dipersilahkan menunggu antrian konsultasi terhadap dokter yang bersangkutan. Selagi pasien menunggu, pegawai loket pendaftaran akan mengajukan pencarian nomor rekam medis pasien kepada pegawai rekam medis. Rekam medis yang telah ditemukan akan dikumpulkan dalam keranjang berjalan, disusun dengan permintaan rekam medis pasien lainnya, sebelum diantarkan ke ruangan masing-masing dokter. Pasien akan mendapatkan gilirannya berkonsultasi ketika rekam medis yang ia miliki telah sampai di ruangan dokter. Di ruangan dokter, pasien akan ditanyai seputar keluhan-keluhan dan juga gejala apa saja yang ia rasakan, Pada akhir konsultasi, dokter bisa saja langsung membuat kesimpulan mengenai penyakit pasien dan pemberian obat apa saja yang perlu diberikan kepada pasien, akan tetapi ada kasus dimana seorang dokter tidak yakin tentang jenis penyakit pasien dan oleh karena itu dibutuhkan bukti penunjang analisis dokter seperti hasil pemindaian sinar x atau MRI atau USG, uji kandungan darah atau urin atau tinja, dan lain lain. Jika dokter membutuhkan bukti penunjang lainnya, maka dokter akan membuat surat permintaan pemeriksaan, baik untuk uji pemeriksaan lab atau radiologi. Surat tersebut akan diberikan kepada staff yang bertugas untuk kemudian dilakukan pemeriksaan yang hasil pemeriksaanya akan diberikan lagi ke dokter. Seorang dokter juga dapat merujuk pasien untuk berkonsultasi kepada dokter spesialis tertentu yang ahli di bidangnya. Bagaimanapun juga. semua hasil konsultasi tersebut akan dimasukan ke dalam arsip rekam medis pasien, termasuk bukti penunjang analisis dokter. Bila kasus penyakit pasien perlu dikonsultasikan kepada dokter spesialis tertentu, maka rekam medis pasien akan diantarkan ke ruang dokter yang dituju, dan pasien terpaksa diminta kembali menunggu antrian bersama pasien lainnya. Ada pula kasus, dimana penyakit pasien perlu ditindaklanjuti lebih serius dengan mengadakan operasi atau rawat inap. Pada kasus ini pasien akan diberikan dokumen yang berisikan prosedur detail sebab dan tindak lanjut terhadap penyakitnya. Pasien memiliki kebebasan untuk menangguhkan tindakan pengobatan dokter dengan sebab-sebab yang harus dapat ditolerir secara medis, seperti: second opinion (menanyakan pendapat dokter lain mengenai penyakit

41 pasien), kesiapan materi dan psikis pasien, dan lain sebagainya. Disetujui atau tidaknya dokumen ini, akan menjadi bukti tegas mengenai kondisi pasien, karenanya penting agar dokumen ini turut disertakan di dalam rekam medis pasien. Seselesainya konsultasi, rekam medis pasien akan dikumpulkan di ruangan terakhir rekam medis tersebut berada, disusun dengan rekam medis pasien lainnya. Ketika jam praktek dokter bersangkutan selesai, pegawai rekam medis akan berkeliling mengumpulkan rekam medis tersebut untuk dikembalikan ke dalam ruangan penyimpanan.

Gambar 3.3 Alur Proses Bisnis Rekam Medis Berbeda kasus bilamana pasien datang kepada rumah sakit dalam kondisi darurat, yang berarti pasien bisa saja dalam kondisi yang tidak tersadarkan diri atau dalam kondisi yang dapat mengancam nyawa pasien. Bila pada kondisi umum, pasien harus terlebih dahulu mengurus proses administrasi dengan cara

42 mengajukan pendaftaran pada loket, maka pada kondisi darurat keselamatan pasien akan dilebihdahulukan daripada proses administrasi. Bila pasien datang dengan anggota keluarga atau dengan seseorang yang dapat bertanggung jawab mengenai proses administrasi pasien, maka proses administrasi pasien dapat dilakukan selagi tim medis memberikan pertolongan kepada pasien. Dengan begitu, rekam medis pasien dapat dicarikan atau dapat dibuat baru bila pasien belum pernah berobat sebelumnya. Rekam medis pasien menjadi krusial karena segala tindakan medis harus disesuaikan dengan riwayat medis pasien meskipun sebelum tindak medis diberikan lebih jauh, biasanya tindakan tim medis sudah terlebih dahulu memeriksa kondisi pasien. Ketika tindakan medis telah selesai diberikan, pasien juga telah keluar dari kondisi yang membahayakan nyawanya, dan segala proses administrasi yang bersangkutan dengan rekam medis pasien telah usai, maka barulah tim medis mencatat segala tindakan medis yang diberikan kepada pasien dalam rekam medis tersebut.

3.2.2 Pembahasan Hasil Kuisoner Berikut ini adalah hasil dari kuisoner yang telah diisi oleh 10 dari 21 rumah sakit di Jakarta Barat mengenai permasalahan rekam medis dengan menggunakan media kertas.

1. Bagaimanakah sistem rekam medis pada institusi tempat anda bekerja dijalankan?

43

Gambar 3.4 Diagram Pertanyaan No. 1 Sebanyak

20% rumah sakit sudah menggunakan rekam medis

elektronik sementara 80% rumah sakit lainnya masig menggunakan rekam medis konvensional.

2. Standar rekam medis apakah yang digunakan oleh institusi dimana Anda bekerja?

Gambar 3.5 Diagram Pertanyaan No. 2

44 Sebanyak 90% rumah sakit menggunakan rekam medis berstandar nasional sementara 10% sisanya menggunakan rekam medis berstandar internasional.

3. Apa sajakah yang diisikan pada rekam medis di rumah sakit ini?

Gambar 3.6 Diagram Pertanyaan No. 3 Sebanyak identitas

10 dari 10 rumah sakit terdapat informasi mengenai

pasien,

tindakan/pengobatan

pemeriksaan

fisik,

yang diberikan dalam

diagnosis/masalah, berkas rekam

dan

medisnya.

Sementara hanya 9 dari 10 rumah sakit yang memiliki catatan pelayanan lain yang diberikan kepada pasien dan persetujuan rekam medis dalam berkas rekam medisnya.

4. berapa lama waktu yang anda gunakan dalam mengisi rekam medis pasien?

45

Gambar 3.7 Diagram Pertanyaan No. 4 Lama waktu pengisianrekam medis bervariasi untuk setiap rumah sakit. Sebanyak 10% responden mengisi rekam medis hanya dalam waktu 2 menit. Sepuluh persen lainnya juga memerlukan waktu 3 menit.Sepuluh persen responden juga memerlukan waktu kurang dari 5 menit.Sepuluh persen lagi memerlukan waktu 5 sampai dengan 10 menit dan sepuluh persen lainnya juga memerlukan waktu 10 menit. Sementara sebanyak 20% rumah sakit memerlukan waktu 15 menit dan 30% sisanya memerlukan waktu sebanyak 5 menit.

5. Berapa lama waktu yang digunakan dalam mencari rekam medis pasien?

46

Gambar 3.8 Diagram Pertanyaan No. 5 Lama waktupencarioan rekam medis juga bervariasi untuk setiap rumah sakit. Sebanyak 10% responden memerlukan waktu 2 menit. Sepuluh persen lainnya juga memerlukan waktu 3 menit.Sepuluh persen responden juga memerlukan waktu kurang dari 10 menit.Sepuluh persen lagi memerlukan waktu 15 menit.Sementara waktu pencarian 5 menit, 5 – 10 menit dan 10 menit masing-masing sebanyak 20% dari keseluruhan responden.

6. Menurut anda, apakah kelemahan rekam medis yang sekarang ini institusi Anda gunakan?

47

Gambar 3.9 Diagram Pertanyaan No. 6 Sebanyak 5 rumah sakit menyatakan bahwa kelemahan yang dalam pengguanan rekam medis konvensional mudah hilang, Delapan rumah sakit menyatakan mudah kotor(sobek, kotor, basah). Empat rumah sakit mengalami duplikasi dan enam rumah sakit menyatakan bahwa rekam medis mudah hilang.

7. Apakah arsip rekam medis institusi tempat Anda bekerja tersimpan semua dalam satu ruangan?

48

Gambar 3.10 Diagram Pertanyaan No. 7 Sebanyak 50% rumah sakit menyimpan semua arsip rekam medis dalam satu ruangan sementara 50% sisanya menyimpan dalam ruangan terpisah.

Dari hasil kuisoner di atas, dapat disimpulkan bahwa masih banyak rumah sakit yang menggunakan rekam medis konvensional. Dan kelemahan rekam medis konvensional, menurut data dari kuisoner, memiliki banyak kesamaan untuk setiap rumah sakit. Setiap rumah sakit di Jakarta Barat yang berhasil kami survey sebagian besar masih memakai rekam medis berstandar nasional dan hanya satu ruamah sakit yang sudah menggunakan standar internasional. Walaupun demikian format pengisian rekam medis secara garis besar sama untuk setiap rumah sakit. Untuk waktu pengisian dan pencarian rekam medis masing-masing memiliki waktu pencarian rata-rata berkisar 5 – 10 menit. Untuk ruang penyimpanan rekam medis, ada rumah sakit yang seluruh arsipnya disimpan di dalam suatu ruangan dan ada juga yang memiliki ruangan terpisah.

3.2.3 Hasil Wawancara dengan Petugas Rekam Medis Dalam menyusun skripsi ini, kami melakukan wawancara dengan staf rekam medis. Kami berhasil mewawancarai beberapa rumah sakit di Jakarta Barat seperti Rumah Sakit Pelni dan RS Jantung Harapan Kita

49 Kesimpulan yang dapat kami peroleh dari wawancara tersebut kami jabarkan dalam poin-poin di bawah ini: 1. Rekam medis konvensional merupakan kumpulan berkas analisa penyakit pasien, tindakan medis terhadap pasien, bukti pendukung diagnosis dokter, serta dokumen perizinan tindakan medis. Karenanya, rekam medis pasien rentan

sekali

duplikasi,

tercecer,

hilang,

dan

rusak

sehingga

ketidaklengkapannya dapat merugikan pihak pasien serta pihak rumah sakit. 2. Semua rumah sakit memiliki prosedur yang sama dalam menangani pasien yang datang dan memerlukan tindakan perawatan. Yaitu, pasien akan memberikan kartu rumah sakit yang terdapat nomor pasien dan kemudian kartu tersebut akan digunakan dalam melakukan rekam medis pasien tersebut. 3. Seiring dengan pertambahan pasien yang mendaftar, maka ruangan penyimpanan rekam medis pasien dituntut untuk lebih diperbesar. 4. Jumlah pasien terdaftar adalah sama dengan jumlah rekam medis yang dimiliki rumah sakit. Jika setiap jamnya rumah sakit menerima puluhan pasien yang ingin berobat, maka proses pencarian rekam medis akan sangat memakan waktu. Terlebih dengan terbatasnya pegawai yang bekerja di bagian rekam medis. 5. Dengan terbatasnya jumlah pegawai rekam medis, meski rekam medis pasien telah diketemukan, proses pengiriman rekam medis dari bagian rekam medis menuju ruangan dokter, yang mana ruangan dokter tersebar di lantai satu, dua, tiga, dan empat, dapat menyita tenaga pegawai. Proses ini pun dapat menambah lama waktu pasien untuk mendapatkan pelayanan kesehatan. 6. Setiap rekam medis yang keluar dari ruang arsip rekam medis harus dengan sepengetahuan petugas rekam medis dan tercatat dalam buku register rekam medis 7. Isi rekam medis dapat tidak lengkap atau hilang dikarenakan masih kurang rapinya sistem pendataan rekam medis yang keluar ruangan. 8. Pasien dapat melihat isi rekam medisnya dengan persetujuan dari dokter.

50 9. Apabila diharuskan melakukan tindakan pembedahan, maka dokter akan membuat surat pengantar operasi dan diberikan ke kasir untuk dibuatkan perkiraan biaya sesuai dengan golongan operasi yang dibuat oleh dokter.

3.2.4 Permasalahan yang Dihadapi Berdasarkan hasil wawancara dan kuisoner yang diperoleh, dapat diketahui permasalaham yang dihadapi: 1. Rekam medis konvensional merupakan kumpulan berkas analisa penyakit pasien, tindakan medis terhadap pasien, bukti pendukung diagnosis dokter, serta dokumen perizinan tindakan medis. Karenanya, rekam medis pasien rentan

sekali

duplikasi,

tercecer,

hilang,

dan

rusak

sehingga

ketidaklengkapannya dapat merugikan pihak pasien serta pihak rumah sakit. 2. Meskipun penggunaan rekam medis sudah sangat diminimalisir karena rentan tercecer, hilang dan rusak, penggunaan rekam medis untuk mengedukasi profesi-profesi di bidang kesehatan tidak dapat dihindari. 3. Seiring dengan pertambahan pasien yang mendaftar, maka ruangan penyimpanan rekam medis pasien dituntut untuk lebih diperbesar. 4. Jumlah pasien terdaftar adalah sama dengan jumlah rekam medis yang dimiliki rumah sakit. Jika setiap jamnya rumah sakit menerima puluhan pasien yang ingin berobat, maka proses pencarian rekam medis akan sangat memakan waktu. Terlebih dengan terbatasnya pegawai yang bekerja di bagian rekam medis. 5. Dengan terbatasnya jumlah pegawai rekam medis, meski rekam medis pasien telah diketemukan, proses pengiriman rekam medis dari bagian rekam medis menuju ruangan dokter, yang mana ruangan dokter tersebar di lantai satu, dua, tiga, dan empat, dapat menyita tenaga pegawai. Singkat

51 cerita, proses ini pun dapat menambah lama waktu pasien dalam menunggu konsultasi. 6. Ketika dokter memerlukan serangkaian uji analisa terhadap pasien demi menguatkan hipotesis penyakit pasien, maka dokter meminta pasien sendiri yang mengantarkan formulir uji tersebut ke bagian tertentu di rumah sakit. Hal ini dapat menguras tenaga dan waktu pasien.

3.2.5 Usulan Pemecahan Masalah Dari analisis permasalahan yang mengitari rekam medis konvensional serta dari analisis kebutuhan-kebutuhan apa saja yang diperlukan oleh para stakeholder/pengguna rekam medis, maka dapat diusulkan pemecahannya seperti berikut: 1. Rekam medis yang semula bermediakan kertas diubah agar bermedia elektronik. 2. Dengan bermediakan elektronik, maka dibutuhkan ruangan server untuk menyimpan data-data rekam medis pasien. Yang mana ruangan server tidak memerlukan ruangan sebesar ruangan penyimpanan rekam medis konvensional sekarang. 3. Isi rekam medis menjadi tidak mudah hilang karena tersimpan dalam server. 4. Untuk dapat meningkatkan mobilitas staf kesehatan, penggunaan platfotm mobile sangat dianjurkan. Meskipun tidak menutup kemungkinan untuk menggunakan platform lainnya. 5. Tidak terjadi duplikasi karena rekam medis pasien memiliki tanda pengenal yang unik di dalam sistem.

52 6. Proses pencarian rekam medis pasien tidak perlu dilakukan oleh pegawai rekam medis, akan tetapi dapat dilakukan oleh staf kesehatan dengan menggunakan fitur pencarian pada aplikasi rekam medis elektronik.

3.3

Perancangan

3.3.1 Software Design Document a. Deskripsi software Aplikasi rekam medis elektronik adalah sebuah aplikasi berbasis mobile smartphonedan web serta terintegrasi dengan sebuah server basis data. Aplikasi ini diciptakan agar dapat membantu rumah sakit dalam mengelola rekam medis pasien dan menjadi sebuah solusi dari permasalahan-permasalahan yang dihadapi dengan penggunaan sistem rekam medis konvensional sekarang ini.

b. Fungsi-fungsi software Sistem penyimpanan rekam medis secara elektronik yang berbasis web dan mobile ini menyediakan beberapa fungsi yang dirancang berdasarkan jenis jabatan yang dimiliki oleh pengguna. Ada 9 peran terkait dalam sistem penyimpanan rekam medis elektronik, yakni dokter, pasien, perawat, bidan, paramedis, staf laboratorium, staf rontgen, staf medical record dan admin. Masing-masing dari jabatan tersebut memiliki kewajiban dan haknya masingmasing, yang satu antar lainnya tidak dapat saling mengintervensi. Jabatan dokter memiliki tugas untuk mencatat segala kondisi yang dialami pasien ke dalam catatan rekam medis, meminta uji laboratorium dan foto rontgen sebagai penguat hasil diagnosis penyakit pasien, serta mengajukan dokumen tindakan medis dalam kaitan untuk menyembuhkan penyakit pasien tersebut. Selain itu, aplikasi ini dapat memberikan dokter akses segala hal yang berkaitan dengan rekam medis pasien. Meskipun diberi akses untuk melihat arsip rekam medis pasien dan bertugas mencatat segala aktivitas perkembangan kondisi kesehatan pasien, berbeda dengan dokter, perawat, bidan, dan paramedis tidak memiliki hak untuk

53 membuat suatu diagnosis penyakit pasien. Karenanya, fungsi-fungsi seperti permintaan uji laboratorium dan foto rontgen, serta pengajuan tindakan medis tidak diikutsertakan untuk ketiga jabatan ini. Di antara kedelapan jabatan yang disebutkan di awal, staf laboratorium, dan staf rontgen memiliki hak dan kewenangan yang lebih sedikit dibanding jabatan lainnya. Tidak diperkenankan untuk mengakses rekam medis milik pasien adalah suatu batasan yang dimiliki keduanya. Masing-masingnya hanya membawahi bidang pekerjaan yang mereka kuasai. Staf laboratorium hanya dapat melihat perkembangan hasil uji laboratorium milik pasien dan membuat hasil uji laboratorium baru berdasarkan surat keterangan dari dokter. Sedangkan staf rontgen hanya dapat melihat hasil foto rontgen yang dimiliki pasien, dan dapat mengunggah foto rontgen baru sesuai kebutuhan dokter. Untuk staf laboratorium dan juga staf rontgen dikarenakan dalam menjalankan tugasnya berhubungan dengan data yang didapat dari sistem pengelolaan informasi yang lain, maka lebih lebih diutamakan menjalankan aplikasi rekam medis ini dalam basis webmenggunakankomputer desktop. Berbeda dengan staf laboratorium dan staf rontgen, staf medical record memiliki akses untuk melihat isi rekam medis pasien. Selain itu, staf medical record juga dapat melihat hasil uji laboratorium dan foto rontgen milik pasien. Hal ini diperlukan, jika sewaktu-waktu diperlukan untuk kepentingan administrasi pasien yang terdiri atas resume dari rekam medis pasien, laporan hasil uji laboratorium, dan foto rontgen milik pasien. Terakhir adalah pasien. Aktor ini tidak mempunyai peran untuk menambahkan, mengganti, ataupun mengurangi isi dari rekam medis miliknya. Akan tetapi, pasien memiliki hak untuk mengawasi seluruh isi catatan rekam medis, termasuk dengan hasil uji laboratorium, foto rontgen, dan dokumen tindakan medis miliknya. Jadi berdasarkan fungsi-fungsi yang diperlukan dalam menjalankan aplikasi ini, dapat disimpulkan bahwa dari 9 role yang ada hanya staf laboratorium dan staf radiologi yang memerlukan aplikasi berbasis web sehingga dapat digunakan dengan menggunakan komputer desktop. Untuk role petugas medis lainnya, walaupun dianjurakan untuk menggunakan aplikasi dengan basis desktop karena pekerjaan yang mereka lakukan cendung statis (tidak bersifat mobile), mereka juga dapat menggunakan aplikasi berbasis mobile apabila

54 diperlukan. Sementara untuk pasien dapat menggunakan aplikasi rekam medis baik berbasis web ataupun mobile.

c. Kebutuhan teknologi Adapun teknologi yang dibutuhkan dalam menjalankan aplikasi rekam medis elektronik adalah sebagai berikut: •

Basis data yang dipergunakan adalah MySQL server.

•

Programming Language yang dipergunakan adalah html, javascript, dan php.

•

Framework yang dipergunakan adalah framework phonegap.

3.3.2 Perancangan Layar Aplikasi Pada subbab ini akan ditampilkan perancangan layar Graphic User Interface (GUI) aplikasi rekam medis elektronik dalam versi web dan mobile. Perancangan layar yang tersedia adalah sebagai berikut:

A. Perancangan Layar Login

Gambar 3.11 Perancangan Layar Login Perancangan layar loginini ditujukan untuk semua aktor yang berperan dalam penggunaan aplikasi rekam medis elektronik, seperti pasien, dokter, staff

55 laboratorium, staff radiologi, paramedis, perawat, bidan, dan staff administrasi. Adapun perancangan layar login ini terdiri atas: • Judul aplikasi • TextBox atau EditText ID pengguna, untuk memasukan data IDpengguna yang telah terdaftar. • Password, untuk memasukan kata rahasia yang hanya diketahui oleh si pemilik ID. • Button Sign In, sebagai pemicu untuk melanjutkan ke halaman baru dari aplikasi yakni dengan cara memcocokan ID pengguna dengan kata rahasia yang sebelumnya telah diberikan.

B. Perancangan Layar Registrasi

Gambar 3.12 Peracangan Layar Registrasi Pasien Perancangan layar registrasi ditujukan untuk staff administrasi dan digunakan dalam pendaftaran pasien atau staf rumah sakit baru. Untuk dijelaskan lebih lanjut, pada perancangan layar registrasi terdiri atas: • TextBox atau EditTextnomor IDyang akan dihasilkan secara otomatis oleh sistem.

56 • TextBox nama,password, konfirmasi password, tanggal lahi, nomor telepon, alamat, dan radiobutton kelamin • Button submit, sebagai tombol pemicu.

Gambar 3.13 Perancangan Layar Registrasi Staf Baru Berbeda dengan perancangan layar registrasi untuk pasien, pada perancangan layar registrasi staf rumah sakit terdapat kolom spesifikasi pekerjaan. Adapun spesifikasi pekerjaan yang dimaksud adalah dokter, perawat, staf laboratorium, staf rontgen, bidan, petugas paramedis, atau staf rekam medis. Untuk halaman update data pasien dan staff, dapat dilihat pada gambar dibawah.

57

Gambar 3.14 Perancangan Layar UpdateData Staff

Gambar 3.15 Perancangan Layar UpdateData Pasien

C. Perancangan Layar Utama Konsistensi merupakan salah satu kunci persyaratan dalam merancang sebuah halaman antarmuka dari sebuah perangkat lunak. Hal ini dapat membantu pengguna agar mudah dan cepat dalam memahami dan menggunakan sebuah perangkat lunak. Demkian hal serupa diimplementasikan dalam merancang halaman antarmuka dari perangkat lunak rekam medis elektronik.

58 Dengan banyak pengguna, seperti dokter, perawat, bidan, staf rekam medis, staf laboratorium, staf rontgen, dan paramedis, perancangan halaman antarmuka dari aplikasi rekam medis elektronik ini dibuat hampir menyerupai satu antar lain penggunanya. Adapun menyerupai yang dimaksud adalah rancangan utama halaman antarmuka dari aplikasi rekam medis elektronik ini dibagi ke dalam dua bagian, bagian kanan dan bagian kiri.

Gambar 3.16 Perancangan Layar Utama Dasar Ketika pengguna memasuki halaman ini, maka secara otomatis sisi kanan dan kiri akan kosong sebelum pengguna memasukan nomor ID pasien pada kotak isian di sisi kiri aplikasi. Ketika ID pasien telah ditemukan, maka pada sisi kiri aplikasi akan terisi biodata dari pasien, dan di sisi kanan akan terisi informasi mengenai rekam medis pasien. Meskipun dikatakan menyerupai halaman antarmuka tiap pengguna, akan tetapi terdapat fungsi-fungsi khusus yang hanya dapat dilakukan oleh para stakeholder. Sebagai contoh, pekerjaan dokter dengan pekerjaan staf rekam medis. Meskipun kedua pekerjaan tersebut berhubungan dengan rekam medis, akan tetapi ada hal tertentu yang hanya dapat dilakukan oleh dokter dan staf rekam medis tidak boleh melakukannya. Oleh sebab itu, penjelasan-penjelasan selanjutnya mengenai rancangan antarmuka aplikasi rekam medis elektronik ini akan lebih dispesifikasikan sesuai dengan karakterisitik stakeholder yang berkepentingan dalam bidang rekam medis.

59

a. Dokter

Gambar 3.17 Perancangan Layar Utama untuk Dokter Dapat dilihat pada gambar perancangan layar utama untuk dokter di atas, pada sisi bagian kanan, posisi utama dokter dalam berinteraksi dengan aplikasi rekam medis elektronik, terdapat 5 tabulasi dan 2 button. Setiap tabulasi-tabulasi tersebut terdiri atas list-list dari rekam medis pasien. Adapun kelima tabulasi tersebut merepresentasikan terdiri atas apa sajakah sebuah rekam medis; hasil diagnonsis, hasil laboratorium, hasil radiologi, dokumen rekam medis dan menu rekam medis yang dapat menampilkan listlist pemeriksaan secara menyeluruh. Pada bagian bawah terdapat menu naviagasi untuk berpindah ke halaman medical record, yaitu halaman yang sesuai gambar dan halaman profileuser. Pada bagaian atas terdapat tombol menu yang akan menampilkan pilihan bantuan dan logout. User dapat melihat profile pasien dengan menekan tombol di bagian bawah ‘patientinformation’.

60

Gambar 3.18 Perancangan Layar Tabulasi Hasil Laboratorium (dokter) Pada halaman diagnosis, hasil lab, radiologi, dan dokumen, terdapaat 2 tombol, yaitu tombol refresh dan add.

Gambar 3.19 Perancangan Layar Tabulasi Hasil Rontgen (dokter)

61

Gambar 3.20 Perancangan Layar Tabulasi Dokumen Rekam Medis (dokter) Dari tampilan list-list dari rekam medis pasien, dokter dapat melihat detil dari data informasi yang ia kehendaki. Hanya cukup dengan memilih salah satu list tersebut.

Gambar 3.21 Perancangan Layar Detil Rekam Medis (dokter)

62 Pada halaman diagnosis pasien terdapat nama pemeriksaan diagnosis, detail pemeriksaan yang sudah pernah dilakuakan, kolom update untuk menambahkan detail pemeriksaan dan tombol update.

Gambar 3.22 Perancangan Layar Detail Dokumen (dokter) Sedangkan pada detail dokumen akan terdapat nama dokumen, detail tindakan medis dan status penindaklanjutan. Adapun perihal isi dari dokumen ini adalah mengenai persetujuan tindak lanjut dan tata cara penanganan terhadap penyakit yang pasien idap.

Gambar 3.23 Perancangan Layar Detil Hasil Laboratorium (dokter)

63 Salah satu dokumen penting agar dokter dapat menganalisis penyakit yang diidap oleh pasien dengan tepat adalah dokumen hasil laboratorium. Pada rancangan dokumen hasil uji laboratorium ini akan tercatat sejumlah data mengenai kandungan-kandungan dalam darah maupun urin pasien. Seperti kandungan hemoglobin dalam darah, kandungan gula dalam urin, kadar empedu dalam hati, dan banyak lainnya. Pada tampilan hasil laboratorium, terdapat nama pemeriksaan lab dan juga jenis pemeriksaan yang diminta dokter beserta hasilnya. Tidak kalah pentingnya dengan dokumen hasil tes laboratorium, dokumen hasil rontgen dapat pula menjadi kunci kesuksesan seorang dokter untuk mengetahui tindakan medis seperti apa yang perlu diberikan kepada pasien. Dalam rancangan hasil rontgen pada aplikasi rekam medis elektronik ini akan menunjukan sebuah gambar pemeriksaan radiologi pasien, berikut dengan keterangan dari dokter dan catatan dari staff radiologi.

Gambar 3.24 Perancangan Layar Detil Hasil Rontgen (dokter) Pada halaman pembuatan diagnosis baru, terdapat nama diagnosis, detail diagnosis dan checkbox yang dapat memberikan akses untuk pasien untuk melihat hasil diagnosisnya.

64

Gambar 3.25 Perancangan Layar Formulir Rekam Medis (dokter)

Gambar 3.26 Perancangan Layar Formulir Dokumen Tindakan Medis (dokter) Pada rancangan layar formulir dokumen tindakan medis di atas, dokter akan diminta untuk menjelaskan sedetil mungkin mengenai tindakan medis yang pasien akan terima berikut dengan konsekuensi atas tindakan tersebut. Pada halaman ini akan tersedia textbox untuk menjelaskan detil tindakan medis dengan konsekuensinya, serta button ‘submit’ untuk menyimpan dokument tersebut sebagi arsip rekam medis pasien. Nantinya dokumen ini akan disampaikan kepada pasien untuk ditanggapi.

65

Gambar 3.27 Perancangan Layar Formulir Permintaan Uji Laboratorium (dokter) Rancangan layar formulir permintaan uji laboratorium terdiri atas kolom nama pemeriksaan, checkbox yang terkelompok-kelompokan dan button ‘submit’ sebagai pemicu untuk diolahnya formulir ini.

Gambar 3.28 Perancangan Layar Formulir Permintaan Rontgen (dokter)

66 Sedangkan pada rancangan layar formulir permintaan radiologi terdiri atas combobox yang berisikan pemeriksaan yang diminta. Selain itu terdapat juga detail foto radiologi yang diminta agar staff radiologi mengerti apa yang diminta dokter. Lalu seperti halnya dengan halaman permintaan uji laboratorium, pada halaman ini akan dipicu melalui button ‘submit’.

b. Pasien Pasien merupakan salah satu aktor penting dalam sistem pencatatan rekam medis. Dalam perancangannya, halaman layar utama aplikasi rekam medis elektronik untuk pasien dibuat hampir menyerupai halaman untuk dokter. Letak perbedaan halaman kedua aktor terletak pada bagian patientinformation yang tidak ada pada tampilan untuk pasien. Selain itu button ‘add’ pun dihilangkan. Hal tersebut dikarenakan pasien tidak mendapatkan hak untuk menambah, mengurangi, atau mengubah isi dari rekam medis pasien, akan tetapi pasien memiliki hak untuk mengawasi rekam medis dirinya.

Gambar 3.29 Perancangan Layar Awal untuk Pasien

67

Gambar 3.30 Perancangan Layar Detail Diagnose(Pasien) Pada rancangan layar detail diagnose di atas dirancang dengan tidak terdapat button ‘update’ sehingga pasien tidak dapat mengubah isi dari rekam medis tersebut. Sementara kolom nama pemeriksaan dan kolom detail pemeriksaan masih ada pada halaman detail diagnosis pasien.

Gambar 3.31 Perancangan Layar Detil Hasil Uji Laboratorium (Pasien)

68

Gambar 3.32 Perancangan Layar Detail Hasil Pemeriksaan Radiologi(Pasien) Perbedaan signifikan pada halaman-halaman aplikasi rekam medis elektronik untuk aktor pasien terletak pada detail dokumen tindakan medis. Pasien memiliki hak untuk menerima atau menangguhkan saran tindakan medis yang diajukan oleh dokter. Oleh karena itu, terdapat radiobutton yang dapat dipilih oleh pasien.

Gambar 3.33 Perancangan Layar Detil Dokumen Tindakan Medis (Pasien)

69 c. Staff Laboratorium Staf laboratorium hanya boleh mengerjakan sampel cairan tubuh pasien. Mereka tidak diperkenankan untuk melihat dokumen, hasil rontgen, maupun diagnosis. Karenanya pada perancangan layar aplikasi rekam medis elektronik untuk staf laboratorium hanya ditampilkan mengenai hasil laboratorium pasien. Pada perancangan layar utama terdapat tabulasi yang berisikan dokumen permohonan uji laboratorium oleh dokter. Selain itu juga terdapat halaman yang menampilkan daftar pemeriksaan yang sudah selesai dilakukan.

Gambar 3.34 Perancangan Layar Utama untuk Staff Laboratorium

70

Gambar 3.35 Perancangan Daftar Laboratorium untuk Staff Laboratorium

Gambar 3.36 Perancangan Layar Formulir Hasil Uji Laboratorium

71

Gambar 3.37 Perancangan Layar Detil Hasil Uji Laboratorium d. Staff Rontgen Seperti halnya dengan staf laboratorium, staf rontgen hanya diperkenankan membuka segala aktifitas yang berhubungan dengan rontgen. Bagian-bagian rekam medis lain, seperti hasil laboratorium, diagnosis, maupun dokumen tindakan medis pasien, tidak dapat diakses oleh staff radiologi. Pada perancangan layar utama aplikasi rekam medis elektronik untuk staf rontgen terdiri atas 2 bagian, yaitu permintaan radiologi yang belum diproses dan yang sudah diproses

72

Gambar 3.38 Perancangan Layar Utama untuk Staf Rontgen

Gambar 3.39 Perancangan Layar Daftar permintaan untuk StaffRadiology

73

Gambar 3.40 Perancangan Layar Formulir Pengunggahan Hasil Rontgen

e. Bidan, Perawat, dan Staf Paramedis Bidan, perawat, dan staf paramedis memiliki peranan penting dalam membantu kinerja dokter menyelamatkan jiwa. Meskipun begitu, para aktoraktor ini tidak mempunyai tugas sebanyak yang dimiliki oleh dokter. Mereka diperlukan untuk melakukan pertolongan pertama sebelum dokter tiba, namun apapun yang mereka kerjakan terhadap pasien perlu tercatat dalam rekam medis. Dalam perancangan layar aplikasi rekam medis untuk bidan, perawat, staf paramedis, hanya diperkenankan untuk menambahkan dan memperbarui isi rekam medis pasien yang mereka tangani.

74

Gambar 3.41 Perancangan Layar Utama untuk Bidan, Perawat, dan Paramedis

Gambar 3.42 Perancangan Layar Detil Rekam Medis

75

Gambar 3.43 Perancangan Layar Formulir Rekam Medis Baru f. Lain-lain Di bawah ini merupakan tampilan rancangan halaman profile dan bantuan.

Gambar 3.44 Perancangan Layar HalamanProfil

76

Gambar 3.45 Perancangan Layar HalamanBantuan

77

3.3.3 Perancangan UML Berikut ini adalah metode-metode perancangan Unified Modelling Languages yang digunakan dalam aplikasi rekam medis elektronik, baik itu versi tablet maupun versi web.

78 a.

Diagram Use Case

Gambar 3.46 Perancangan Primary Use Case Diagram

79 b. Diagram Activity

Gambar 3.47 Register New Medical Staff Activity Diagram Activity ini menjelaskan bagaimana proses pendaftaran staf medis baru oleh admin pada aplikasi, baik padaweb maupun mobile. •

Pertama kali admin perlu melakukan login.

•

Pada halaman ‘Register New Medical Staff’, admin mengisi fielddata-data profil staf medis baru.

•

Setelahadmin menekan tombol ‘Submit’, aplikasi akan memeriksa apakah data yang diisikan adalah valid atau tidak.

•

Bila ternyata data yang diisikan tidak valid, maka aplikasi akan memunculkan pesan error dan aplikasi akan meminta user untuk mengisikan kembali data profil staf medis.

•

Bila ternyata data yang diisikan valid, maka aplikasi akan menampilkan pesan bahwa proses pendaftaran staf medis telah berhasil.

80

Gambar 3.48 Register New Patient Activity Diagram Activity ini menjelaskan bagaimana proses pendaftaran pasien baru oleh admin pada aplikasi, baik pada web maupun mobile. •

Pertama kali admin perlu melakukan login.

•

Pada halaman ‘Register New Patient’, admin mengisi fielddata-data profilpasien baru.

•

Setelah admin menekan tombol ‘Submit’, aplikasi akan memeriksa apakah data yang diisikan adalah valid atau tidak.

•

Bila ternyata data yang diisikan tidak valid, maka aplikasi akan memunculkan pesan error dan aplikasi akan meminta user untuk mengisikan kembali data profil pasien.

•

Bila ternyata data yang diisikan valid, maka aplikasi akan menampilkan pesan bahwa proses pendaftaran pasien telah berhasil.

Gambar 3.49 Update Medical Staff Profile Activity Diagram

81 Activity ini menjelaskan bagaimana proses penbaharuan profil staf medis yang dilakukan oleh admin menggunakan aplikasi, baik pada aplikasi versi web ataupun mobile. •

Pertama, admin perlu melakukan login.

•

Admin perlu memasukan ID staf yang hendak diperbarui profil pribadinya.

•

Setelah aplikasi memberikan respon lanjutan, admin memilih menu ‘Update’ sehingga akan tampil halaman ‘Update Staff Profile’.

•

Pada halaman ‘Update Staff Profile’, admin dipersilahkan mengisi atau mengubah data profil yang hendak diubah.

•


•

Bila ternyata data yang diisikan tidak valid, maka aplikasi akan memunculkan pesan error dan aplikasi akan meminta user untuk mengisikan kembali data profil staf medis.

•

Bila ternyata data yang diisikan valid, maka aplikasi akan menampilkan pesan bahwa proses pembaruan profilstaf medis telah berhasil.

Gambar 3.50 Update Patient Profile Activity Diagram Activity ini menjelaskan bagaimana proses penbaharuan profil pasien yang dilakukan oleh admin menggunakan aplikasi, baik pada aplikasi versi web ataupun mobile. •

Pertama, admin perlu melakukan login.

•

Admin perlu memasukan ID pasien yang hendak diperbarui profil pribadinya.

82 •

Setelah aplikasi memberikan respon lanjutan, admin memilih menu ‘Update’ sehingga akan tampil halaman ‘Update Patient Profile’.

•

Pada halaman ‘Update Patient Profile’, admin dipersilahkan mengisi atau mengubah data profil yang hendak diubah.

•


•

Bila ternyata data yang diisikan tidak valid, maka aplikasi akan memunculkan pesan error dan aplikasi akan meminta user untuk mengisikan kembali data profil pasien.

•

Bila ternyata data yang diisikan valid, maka aplikasi akan menampilkan pesan bahwa proses pembaruan profil pasien telah berhasil.

Gambar 3.51 Submit New DiagnosticActivity Diagram Activity diagram submit new diagnostic di atas menjelaskan proses bagaimana menambahkan diagnosis. •

Pertama User perlu untuk login.

•

User yang dapat melakukan activity ini terbatas hanya oleh dokter, perawat, bidan, dan paramedis.

•

Selanjutnya, user harus memasukan ID pasien.

83 •

Setelah aplikasi memberikan respon balik, user harus memilih menu ‘New Diagnostic’ sehingga akan tampil halaman formulir diagnosis baru.

•

Pada halaman tersebut, user dipersilahkan mengisi diagnosis pasien sesuai dengan standar bahasa ilmu kesehatan selayaknya penggunaan rekam medis konvensional.

•

Setelah user menekan tombol ‘Submit’, aplikasi akan memeriksa apakah data yang diisikan adalah valid atau tidak.

•

Bila ternyata data yang diisikan tidak valid, maka aplikasi akan memunculkan pesan error dan aplikasi akan meminta user untuk mengisikan kembali diagnosis pasien.

•

Bila ternyata data yang diisikan valid, maka aplikasi akan menampilkan pesan bahwa proses pembuatan diagnosis baru telah berhasil.

Gambar 3.52 View DiagnosisActivity Diagram Activity diagram viewdiagnostic di atas menjelaskan proses bagaimana menambahkan diagnosis. •


•

User yang dapat melakukan activity ini terbatas hanya oleh pasien, dokter, perawat, bidan, dan paramedis.

•

Ketika login, aplikasi akan memeriksa apakah user adalah pasien atau bukan.

84 •

Jika user adalah pasien, maka aplikasi akan menampilkan daftar diagnosis yang telah diberikan kepada pasien.

•

Jika user adalah bukan pasien, maka user akan diminta terlebih dahulu memasukan ID pasien yang diagnosisnya hendak diperlihatkan.

•

Setelah aplikasi memberikan respon balik berupa daftar diagnosis pasien,userdipersilahkan memilih salah satu diagnosis tersebut.

•

Sistem akan menampilkan secara rinci diagnosis yang telah dipilih oleh user.

Gambar 3.53 Update DiagnosisActivity Diagram Activity diagram submit new diagnostic di atas menjelaskan proses bagaimana menambahkan diagnosis baru pada rekam medis pasien. •


•

User yang dapat melakukan activity ini terbatas hanya oleh dokter, perawat, bidan, dan paramedis.

•

Setelah sistem memberikan respon, user akan diminta terlebih dahulu memasukan ID pasien.

85 •

Sistem memberikan respon balik berupa daftar diagnosis pasien, user dipersilahkan memilih salah satu diagnosis tersebut.

•

Aplikasi akan menampilkan secara rinci diagnosis yang telah dipilih oleh user.

•

Pada halaman detail diagnosis pasien akan terdapat menu ‘Update’, untuk memperbarui diagnosis pasien, user harus memilih menu tersebut.

•

Ketika menu tersebut dipilih, sistem akan memeriksa apakah user pembuat diagnosis tersebut dengan user yang sedang membuka diagnosis adalah sama atau tidak.

•

Apabila berbeda, sistem akan memberitahukan user bahwa ia tidak dapat otoritas untuk mengubah isi detil diagnosis.

•

Sedang apabila sama, maka sistem akan menampilkan halaman formulir pembaruan diagnosis.

•

Setelah selesai memperbarui diagnosis pasien dan user telah menekan tombol ‘Submit’, sistem akan memeriksa validitas data terbaru tersebut.

•

Bila ternyata data yang diisikan tidak valid, sistem akan menampilkan pesan kegagalan dan user diminta mengulangi proses pembaruan diagnosis.

•

Bila ternyata data yang diisikan valid, maka aplikasi akan menampilkan pesan bahwa proses pembaruan diagnosis baru telah berhasil.

Gambar 3.54 Request Laboratory Test Activity Diagram

86 Activity diagram di atas menjelaskan proses bagaimana permintaan uji laboratorium oleh dokter. •


•


•

Setelah aplikasi memberikan respon balik, user harus memilih menu ‘New Request Laboratory’ sehingga akan tampil halaman formulir permintaan uji laboratorium.

•

Pada halaman tersebut, user dipersilahkan mengisi detil uji laboratorium yang diperlukan.

•

Setelah user menekan tombol ‘Submit’, aplikasi akan memeriksa apakah data yang diisikan adalah valid atau tidak.

•

Bila ternyata data yang diisikan tidak valid, maka aplikasi akan memunculkan pesan error dan aplikasi akan meminta user untuk mengisikan kembali formulir permintaan uji laboratorium.

•

Bila ternyata data yang diisikan valid, maka aplikasi akan menampilkan pesan bahwa proses permintaan uji laboratorium telah berhasil.

Gambar 3.55 View Laboratory Test Request Activity Diagram Activity ini menjelaskan proses seorang staf laboratorium dapat memeriksa permohonan uji laboratorium terhadap pasien. •

Pertama staf laboratorium perlu login ke dalam aplikasi.

•

Setelah itu, staf laboratorium terlebih dahulu harus memasukan ID pasien.

87 •

Setelah itu, sistem akan menampilkan daftar permintaan uji laboratorium terhadap pasien.

•

Staf laboratorium dapat memilih salah satu dari daftar tersebut.

•

Setelah memilih salah satu dari daftar tersebut, sistem akan menampilkan rincian uji laboratorium yang diminta oleh dokter.

Gambar 3.56 Submit New Laboratory Test Result Acitivity Diagram Activity ini menjelaskan proses pencatatan hasil uji laboratorium oleh staf laboratorium sesuai atasrincian permohonan dari dokter sebelumnya. •

Pertama staf laboratorium perlu login ke dalam aplikasi.

•

Setelah itu, staf laboratorium terlebih dahulu harus memasukan ID pasien.

•

Setelah itu, sistem akan menampilkan daftar permintaan uji laboratorium terhadap pasien.

•


•

Setelah memilih salah satu dari daftar tersebut, sistem akan menampilkan halaman rincian uji laboratorium yang diminta oleh dokter.

88 •

Pada halaman rincian uji laboratorium tersebut juga sekaligus formulir pencatatan hasil uji laboratorium untuk user.

•

Staf laboratorium hanya perlu mengisikan hasil uji laboratorium pada formulir tersebut.

•

Ketika hasil pengisian uji laboratorium yang diberikan tidak valid, maka akan tampak pesan error di layar aplikasi.

•

Sedangkan bila hasil pengisian uji laboratorium tersebut valid maka akan tampak pesan bahwa pengerjaan hasil uji laboratorium telah selesai dilakukan.

Gambar 3.57 Viewing Laboratory Lab Result Activity Diagram Activity diagram di atas menjelaskan proses bagaimana user dapat melihat rincian hasil uji laboratorium. •


•

User yang dapat melakukan activity ini terbatas hanya oleh pasien, dokter, pasien dan staf laboratorium.

•


•

Jika user adalah pasien, maka aplikasi akan langsung menampilkan daftar hasil uji laboratorium.

•

Jika user adalah bukan pasien, maka user akan diminta terlebih dahulu memasukan ID pasien.

•

Setelahnyasistem akan memberikan respon balik berupa daftar hasil uji laboratorium pasien.

89 •

User dipersilahkan memilih salah satu dari daftar tersebut.

•

Setelahnya, sistem akan menampilkan secara rinci hasil uji laboratorium yang telah dipilih oleh user.

Gambar 3.58 Request Rontgen Scanning Activity Diagram Activity diagram di atas menjelaskan proses bagaimana permintaan uji radiologi oleh dokter. •


•


•

Setelah aplikasi memberikan respon balik, user harus memilih menu ‘New Request Radiology’ sehingga akan tampil halaman formulir permintaan uji radiologi.

•

Pada halaman tersebut, user dipersilahkan mengisi detil uji radiologi yang diperlukan.

•

Setelah user menekan tombol ‘Submit’, sistem akan memeriksa apakah data yang diisikan adalah valid atau tidak.

•

Bila ternyata data yang diisikan tidak valid, maka aplikasi akan memunculkan pesan error dan aplikasi akan meminta user untuk mengisikan kembali formulir permintaan uji radiologi.

•

Bila ternyata data yang diisikan valid, maka aplikasi akan menampilkan pesan bahwa proses permintaan uji radiologi telah berhasil.

90

Gambar 3.59 View Rontgen Scanning Request Activity Diagram Activity ini menjelaskan proses seorang staf rontgen dapat memeriksa permohonan pemindaian radiologi terhadap pasien. •

User harus terlebih dahulu login.

•

Setelah itu, user diharapkan memasukan ID pasien yang dikehendaki.

•

Sistem akan memberikan respon dengan cara menampilkan daftar permintaan radiologi.

•

User dapat memilih salah satu dari daftar tersebut.

•

Bila usertelah menentukan pilihannya, sistem akan menampilkan secara rinci permohonan radiologi oleh dokter.

91

Gambar 3.60 Submit New Rontgen Result Activity Diagram Activity ini menjelaskan bagaimana proses staf radiologi dapat mengunggah hasil radiologi pasien berdasarkan dari lembar permohonan dari dokter. •

Pertama kali, user harus terlebih dahulu login.

•

Setelahnya, user memasukan ID pasien yang bersangkutan.

•

Sistem akan memberikan umpan balik berupa daftar permintaan radiologi.

•

User dapat memilih salah satu dari daftar tersebut.

•

Bila usertelah menentukan pilihan dari daftar tersebut, sistem akan menampilkan secara rinci permohonan radiologi yang juga sekaligus formulir pengunggahan hasil radiologi.

•

User dapat mengisi formulir tersebut.

•

Bila telah selesai mengerjakan hasil radiologi pasien, user diminta untuk menekan tombol ‘Submit’ agar sistem dapat memproses data yang telah diisikan.

•

Bila data yang diisikan tidak valid, user diminta untuk mengulangi proses pengisian formulir pengunggahan hasil radiologi pasien.

92 •

Bila data yang diisikan valid, sistem akan menampilkan pesan bahwa proses pengunggahan hasil radiologi pasine telah berhasil.

Gambar 3.61 View Radiology Result Activity Diagram Activity diagram di atas menjelaskan proses bagaimana user dapat melihat rincian hasil radiologi pasien. •


•

User yang dapat melakukan activity ini terbatas hanya oleh pasien, dokter, pasien dan staf radiologi.

•


•

Jika user adalah pasien, maka aplikasi akan langsung menampilkan daftar hasil radiologi.

•

Jika user adalah bukan pasien, maka user akan diminta terlebih dahulu memasukan ID pasien.

•

Setelahnya sistem akan memberikan respon balik berupa daftar hasil radiologi pasien.

•

User dipersilahkan memilih salah satu dari daftar tersebut.

•

Setelahnya, sistem akan menampilkan secara rinci hasil radiologi yang telah dipilih oleh user.

93

Gambar 3.62 Submit New Document Activity Diagram Activity ini akan menjelaskan proses seorang dokter mengajukan sebuah dokumen tindakan medis kepada pasien. • Pertama, dokter perlu melakukan login. • Setelah itu dokter harus memasukan ID pasien. • Lalu memilih menu ‘New Document’ • Sistem akan menampilkan halaman formulir pembuatan dokumen medis baru. • Dokter dapat menuliskan secara rinci perihal persetujuan tindakan medis untuk pasien. • Setelah selesai mengisi formulir tersebut, dokter dapat menekan tombol ‘Submit’. • Sistem akan memvalidasi data isian oleh dokter. • Bila data yang diisikan tidak valid, akan tampil pesan yang menjelaskan bahwa proses gagal dan user diminta untuk mengulangi pengisian data baru. • Bila data yang diisikan valid, akan tampil pesan yang menjelaskan bahwa proses pembuatan dokumen medis baru telah berhasil.

94

Gambar 3.63 Responding New Document Activity Diagram Activity ini akan menjelaskan proses seorang pasien memberi tanggapan terhadap dokumen tindakan medis yang diajukan oleh dokter. Activity dapat dilakukan menggunakan aplikasi berbasis web atau mobile. •

Pertama, userperlu untuk login.

•

Sistem akan menampilkan daftar dokumen tindakan medis pasien.

•

Pasiendapat memilih salah satu dari daftar dokumen tersebut.

•

Setelah memilih salah satu dari daftar tersebut, sistem akan memeriksa apakah dokumen tersebut telah diberikakan tanggapan oleh pasien.

•

Bila dokumen tersebut telah mendapat respon pasien, maka sistem hanya akan menampilkan rincian dokumen.

•

Bila dokumen tersebut belum mendapat respon pasien, maka sistem akan menampilkan halaman rincian dokumen dan formulir tanggapan pasien.

95 •

Dalam formulir tanggapan pasien akan tersedia 2 pilihan yakni, ‘Approve’ atau ‘Disapprove’.

•

‘Approve’ untuk menerima tindakan medis oleh dokter, sedangkan ‘Sisapprove’ untuk menolak tindakan medis oleh dokter.

Gambar 3.64 View Document Activity Diagram Activity ini akan menjelaskan proses bagiamana dokter dan pasien dapat melihat detil dari dokumen persetujuan tindakan medis pasien. •

Pertama, user perlu untuk login terlebih dahulu.

•

User yang dapat melakukan proses ini hanya dokter dan pasien.

•

Setelah user telah login, sistem akan memeriksa apakah user adalah pasien atau bukan.

•

Bila user adalah pasien, sistem akan menampilkan daftar dokumen persetujuan tindakan medis.

•

Bila user adalah dokter, sistem akan meminta dokter memasukan ID pasien yang dikehendaki, barulah sistem akan menampilkan daftar dokumen persetujuan tindakan medis.

•

Para aktor dapat memilih salah satu dari daftar dokumen tersebut untuk melihat detil rincian isi dari dokumen tersebut.

96

c.

Diagram Kelas

95

Gambar 3.65 Class Diagram Aplikasi Rekam Medis

97 d. Diagram Sequences

Gambar 3.66 New Medical Staff Registration Sequence Diagram Gambar di atas adalah diagram yang menjelaskan bagaimana proses pendaftaran staf medis baru yang dilakukan oleh admin. •

Pertama kali admin harus melakukan login aplikasi.

•

Setelah itu admin dapat memilih menu ‘New Staff Registration’

•

Sistem akan menampilkan halaman pendaftaran staf baru yang berisikan formulir pendaftaran staf baru.

•

Jika admin telah selesai mengisi data-data staf baru dan telah menekan tombol ‘Submit’, sistem akan memeriksa kevaliditasan data yang telah diisikan

dengan

‘registerNewStaff(id,

menjalankan

fungsi

dari

kelas

password,

name,

phoneNumber,

‘staffCR’, gender,

98 department)’ dengan sebagai parameternya adalah data yang diisikan pada formulir. •

Jika data yang diisikan tidak valid, maka kelas controller‘staffCR’ akan memerintahkan User Interface untuk menampilkan pesan error.

•

Jika data yang diisikan adalah valid, kelas controller‘staffCR’ akan menjalankan fungsi ‘insertStaffData(id, password, name, phoneNumber, gender, department)’pada kelas ‘staffClass’

•

Fungsi tersebut berisikan perintah untuk menyimpan data-data staf baru tersebut ke dalam basis data.

•

Setelah berhasil disimpan, kelas controller ‘staffCR’ akan memerintahkan User Interface menampilkan pesan konfirmasi bahwa pendaftaran staf baru telah berhasil.

Gambar 3.67 New Patient RegistrationSequence Diagram

99 Gambar di atas adalah diagram yang menjelaskan bagaimana proses pendaftaran pasien baru yang dilakukan oleh admin. •


•

Setelah itu admin dapat memilih menu ‘New Patient Registration’

•

Sistem akan menampilkan halaman yang berisikan formulir pendaftaran pasien baru.

•

Jika admin telah selesai mengisi data-data pasien baru tersebut dan telah menekan tombol ‘Submit’, sistem akan memeriksa kevaliditasan data yang telah diisikan dengan menjalankan fungsi dari kelas ‘patientCR’, ‘registerNewPatient(idPatient,

namePatient

password,

phoneNumber,

gender, socialNumber, address)’ dengan sebagai parameternya adalah data yang diisikan pada formulir. •

Jika data yang diisikan tidak valid, kelas controller‘patientCR’ akan memerintahkan User Interface untuk menampilkan pesan error.

•

Jika data yang diisikan adalah valid, kelas controller‘patientCR’ akan menjalankan fungsi ‘insertPatientData(idPatient, namePatient password, phoneNumber, gender, socialNumber, address)’pada kelas ‘patientClass’

•

Fungsi tersebut berisikan perintah untuk menyimpan data-data staf baru tersebut ke dalam basis data.

•

Setelah

berhasil

disimpan,

kelas

controller

‘patientCR’

akan

memerintahkan User Interface menampilkan pesan konfirmasi bahwa pendaftaran pasien baru telah berhasil.

100

Gambar 3.68 Update Medical Staff ProfileSequence Diagram Gambar di atas adalah diagram yang menjelaskan bagaimana proses pembaruan data diri staf rumah sakit yang dilakukan oleh admin. •


•

Lalu, admin diminta untuk memasukan ID staf yang profilnya hendak diperbarui.

•

Setelah sistem memberi umpan balik, admin dapat memilih menu ‘Update Staff Profile’

•

Sistem akan menampilkan halaman yang berisikan formulir pembaruan profil staf.

•

Jika admin telah selesai mengganti data-data profil staf tersebut dan telah menekan tombol ‘Submit’, sistem akan memeriksa kevaliditasan data yang telah diisikan dengan menjalankan fungsi dari kelas ‘staffCR’,

101 ‘updateProfile(id, phoneNumber, password, address)’ dengan sebagai parameternya adalah data yang diisikan pada formulir. •

Jika data yang diisikan tidak valid, kelas controller‘staffCR’ akan memerintahkan User Interface untuk menampilkan pesan error.

•

Jika data yang diisikan adalah valid, kelas controller‘staffCR’ akan menjalankan fungsi ‘updateStaffData(idPatient, namePatient password, phoneNumber, gender, socialNumber, address)’pada kelas ‘staffClass’

•

Fungsi tersebut berisikan perintah untuk menyimpan profil baru staf tersebut ke dalam basis data.

•

Setelah berhasil disimpan, kelas controller ‘staffCR’ akan memerintahkan User Interface menampilkan pesan konfirmasi bahwa pembaruan profil telah berhasil.

Gambar 3.69 Update Patient ProfileSequence Diagram

102 Gambar di atas adalah diagram yang menjelaskan bagaimana proses pembaruan data diri pasien yang dilakukan oleh admin. •


•

Lalu, admin diminta untuk memasukan ID pasien yang profilnya hendak diperbarui.

•

Setelah sistem memberi umpan balik, admin dapat memilih menu ‘Update Patient Profile’

•

Sistem akan menampilkan halaman yang berisikan formulir pembaruan profil staf.

•

Jika admin telah selesai mengganti data-data profil staf tersebut dan telah menekan tombol ‘Submit’, sistem akan memeriksa kevaliditasan data yang telah diisikan dengan menjalankan fungsi dari kelas ‘patientCR’, ‘updateProfile(id, phone, occupation, address)’, dengan sebagai parameter adalah data yang diisikan pada formulir.

•

Jika data yang diisikan tidak valid, kelas controller‘patientCR’ akan memerintahkan User Interface untuk menampilkan pesan error.

•

Jika data yang diisikan adalah valid, kelas controller‘patientCR’ akan menjalankan

fungsi

‘updatePatientData(id,

phone,

occupation,

address)’pada kelas ‘patientClass’ •

Fungsi tersebut berisikan perintah untuk menyimpan profil baru pasien tersebut ke dalam basis data.

•

Setelah

berhasil

disimpan,

kelas

controller

‘patientCR’

akan

memerintahkan User Interface menampilkan pesan konfirmasi bahwa pembaruan profil telah berhasil.

103

102

104

Gambar 3.70 Submit New Medical Diagnostic Sequence Diagram untuk User ‘Dokter’

105

Gambar 3.71 Submit New Medical Diagnostic Sequence Diagram untuk User ‘Perawat’ 103

104

106

Gambar 3.72 Submit New Medical DiagnosticSequence Diagram untuk User ‘Bidan’

107

Gambar 3.73 Submit New Medical Diagnostic Sequence Diagram untuk User ‘Paramedis’ 105

108 Gambar-gambar

di

atas

adalahdiagram

sequence

yang

dapat

mendeskripsikan proses pembuatan rekam medis baru oleh seorang dokter, perawat, bidan atau paramedis. •

Pertama kali, user harus terlebih dahulu melakukan login aplikasi.

•

Bila user berhasil login aplikasi, user akan diminta memasukan ID pasien yang bersangkutan.

•

Kemudian, userdapat memilih tautan new medical diagnostic.

•

Sistem akan memberi umpan balik berupa tampilan halaman formulir pembuatan diagnosis baru.

•

Setelah user selesai mencatat hasil anamnesa dengan pasien, dan telah menekan button ‘submit’, sistem akan memroses data yang telah diisikan dengan

menjalankan

fungsi

‘newDiagnostic(idMedRec,

dari

kelas

dateSubmit,

‘medicalRecordCR’,

idDiagnostic,

idStaff,

typeMedRec, idPatient)’, dengan sebagai parameter adalah data yang diisikan pada formulir. •

Pada akhir fungsi tersebut, sistem akan menjalankan fungsi dari kelas ‘medicalRecordClass’,

submitNewDiagnostic(idMedRec,

dateSubmit,

idDiagnose, idStaff, typeMedRec, idPatient, accessStatus), yang berisikan perintah untuk menyimpan data ke dalam tabel medicalRecord pada basis data aplikasi rekam medis. •

Bila berhasil, sistem akan memberi umpan balik kepada kelas ‘medicalRecordCR’ untuk menjalankan fungsi kelas ‘diagnosticCR’, ‘newDiagnostic(idMedRec,

DateSubmit,

idDiagnose,

idStaff,

typeMedRec, idPatient)’. •

Setelah memproses data yang diisikan user, fungsi tersebut akan menjalankan

fungsi

dari

‘submitNewDiagnostic(idDiagnose,

kelas

‘diagnosticClass’,

tittleDiagnose,

detailDiagnose,

statusDiagnose)’, yang berisikan perintah untuk menyimpan profil baru pasien tersebut ke dalam basis data. •

Setelah

berhasil disimpan,

kelas

controller

‘diagnosticCR’

akan

memerintahkan User Interface menampilkan pesan konfirmasi bahwa pembuatan diagnosis baru telah berhasil.

109

Gambar 3.74 Update Medical Diagnostic Sequence Diagram untuk User ‘Dokter’

110

Gambar 3.75 Update Medical Diagnostic Sequence Diagram untuk User ‘Perawat’

111

Gambar 3.76 Update Medical Diagnostic Sequence Diagram untuk User ‘Bidan’

112

Gambar 3.77 Update Medical Diagnostic Sequence Diagram untuk User ‘Paramedis’ Gambar-gambar di atas adalah diagram-diagram yang menjelaskan bagaimana proses pembaruan isi dari rekam medis yang dapat dilakukan oleh seorang dokter, suster, bidan, maupun paramedis. •

Pertama kali, user harus melakukan login aplikasi.

113 •

Lalu, memasukan ID pasien yang bersangkutan.

•

Setelah memasukan ID pasien yang bersangkutan, sistem akan menjalankan

fungsi

kelas

controller

‘diagnosticCR’,

‘getDiagnosticList(idPatient)’, yang berisikan perintah-perintah untuk memproses input yang diberikan oleh user. •

Seselesai pemrosesan, fungsi ini akan menjalankan fungsi kelas ‘diagnosticClass’, ‘getDiagnosticList(idPatient)’, yang berisikan perintah untuk mengambil data-data yang diperlukan dari basis data.

•

Data-data yang didapatkan oleh fungsi ‘getDiagnosticList(idPatient)’ kelas ‘diagnosticClass’

akan

menjadi

return

value

kepada

fungsi

‘getDiagnosticList(idPatient)’ kelas controller ‘diagnosticCR’. •

Return value tersebut yang nantinya akan ditampilkan oleh User Interface berupa daftar diagnosis pasien sebelum-sebelumnya.

•

Agar dapat melihat rincian dari suatu diagnosis, User kemudian dapat memilih salah satu dari daftar tersebut.

•

Setelah memilih salah satu dari daftar tersebut, sistem akan menjalankan fungsi

kelas

controller

‘diagnosticCR’,

‘getDetailDiagnostic(idDiagnostic)’, untuk memulai pemrosesan suatu input. •

Setelah selesai memroses input oleh user, fungsi ini akan menjalankan fungsi dari kelas ‘diagnosticClass’, ‘getDetailDiagnostic(idDiagnostic)’, yang berisikan perintah-perintah untuk mengambil data-data yang diperlukan pada basis data.

•

Data-data ini adalah retun value yang akan dikirim kembali kepada fungsi kelas

controller

‘diagnosticCR’,

‘getDetailDiagnostic(idDiagnostic)’,

untuk diproses. •

Adapun proses ini penting karena harus memeriksa pembuat diagnosa yang akan dilihat secara rinci.

•

Bila user yang membuka rincian diagnosa pasien bukanlah pembuat diagnosa, maka user tersebut tidak berhak untuk memperbarui diagnosa pasien. Sistem hanya akan menampilkan rincian diagnosa tanpa menu untuk memperbarui diagnosis.

114 •

Bila user yang membuka rincian diagnosa pasien adalah pembuat diagnosa, maka sistem akan menampilkan rincian diagnosis dengan tambahan tampilan formulir untuk memperbarui diagnosis.

•

Setelah mengisi dengan lengkap form tersebut, sistem akan menjalankan fungsi kelas controller ‘diagnosticCR’, updateDiagnostic(idDiagnostic, tittleDiagnostic, detailDiagnostic, status, dateUpdateDiagnostic), yang berisikan perintah-perintah untuk pemrosesan data yang diinput oleh user.

•

Setelah

diproses,

fungsikelas

controller

‘diagnosticCR’,

updateDiagnostic(idDiagnostic, tittleDiagnostic, detailDiagnostic, status, dateUpdateDiagnostic)akan

menjalankan

fungsi

dari

kelas

‘diagnoscticClass’,

updateDiagnostic(dateUpdateDiagnostic,

idDiagnostic, tittleDiagnostic, detailDiagnostic, status), yang berisikan perintah untuk menyimpan data diagnosis yang telah diperbaruike dalam basis data. •

Setelah berhasil tersimpan, kelas controller ‘diagnosticCR’ akan mendapat umpan balik dari fungsi sebelumnya sehingga dapat memerintahkan User Interface menampilkan pesan konfirmasi bahwa pembaruan diagnosis telah berhasil.

115

Gambar 3.78 View Medical Diagnostic Sequence Diagram untuk User ‘Dokter’

Gambar 3.79 View Medical Diagnostic Sequence Diagram untuk User ‘Bidan’

116

Gambar 3.80 View Medical Diagnostic Sequence Diagram untuk User ‘Perawat’

Gambar 3.81 View Medical Diagnostic Sequence Diagram untuk User ‘Paramedis’

117 Gambar-gambar

di atas adalah diagram sequence yang dapat

mendeskripsikan proses untuk menampilkan rinciandiagnosis rekam medis oleh userdokter, perawat, bidan atau paramedis. •


•

Bila user berhasil login aplikasi, user akan diminta memasukan ID pasien yang bersangkutan.

•

Setelah memasukan ID pasien yang bersangkutan, sistem akan menjalankan

fungsi

kelas

controller

‘diagnosticCR’,

‘getDiagnosticList(idPatient)’, yang berisikan perintah-perintah untuk memproses input yang diberikan oleh user. •


•


akan

menjadi

return

value

kepada

fungsi



•


•


kelas

controller

‘diagnosticCR’,



•

Data-data ini adalah return value yang akan dikirim kembali kepada fungsi kelas

controller

‘diagnosticCR’,


untuk diproses. •

Kemudain

kelas

controller

akan

memerintahkan

user

interface

menampilkan return value tersebut, yakni rincian diagnosis pasien.

118

Gambar 3.82 View Medical Diagnostic Sequence Diagram untuk User ‘Pasien’ Gambar di atas adalah diagram sequence yang dapat mendeskripsikan proses untuk menampilkan rincian diagnosis rekam medis oleh pasien. •


•

Perbedaan diagram sequence yang digunakan oleh user dokter, perawat, bidan dan paramedis dengan user pasien terletak pada proses setelah melakukan login aplikasi.

•

Bila pada diagram sequence ‘view medical diagnostic’ untuk dokter, perawat, bidan, dan paramedis, setelah melakukan login aplikasi, user diminta untuk memasuk ID pasien, maka pada diagram sequence ‘view medical diagnostic’ untuk pasien, user tidak lagi perlu memasukan ID pasien.

•

User cukup melakukan login aplikasi dan sistem akan menjalankan fungsi kelas controller ‘diagnosticCR’, ‘getDiagnosticList(idPatient)’, yang berisikan perintah-perintah untuk memproses input yang diberikan oleh user.

119 •


•


akan

menjadi

return

value

kepada

fungsi



•


•


kelas

controller

‘diagnosticCR’,



•

Data-data ini adalah return value yang akan dikirim kembali kepada fungsi kelas

controller

‘diagnosticCR’,


untuk diproses. •

Kemudain

kelas

controller

akan

memerintahkan

user

interface

menampilkan return value tersebut, yakni rincian diagnosis pasien.

118

120

Gambar 3.83 Request Laboratory Test Sequence Diagram

121 Gambar di atas menjelaskan proses permohonan uji laboratorium oleh dokter kepada staf laboratorium. •

Pertama kali user perlu melakukan login aplikasi.

•

Kemudian, memasukan ID pasien yang bersangkutan.

•

Jika sudah, user dipersilahkan memilih menu ‘New Laboratory Test Request’

•

Sistem akan menampilkan halaman yang berisi formulir permintaan uji laboratorium.

•

Setelah user selesai mengisi formulir tersebut, dan telah menekan button ‘submit’, sistem akan memroses data yang telah diisikan dengan menjalankan fungsi dari kelas ‘medicalRecordCR’, ‘newLab(idMedRec, dateSubmit,

idLab,

idStaff,

typeMedRec,

idPatient)’,untuk

memvalidasikan data yang diinput oleh user. •

Selesai

divalidasi,

fungsi

akan

menjalankan

fungsi

dari

kelas

‘medicalRecordClass’, ‘submitNewLab(idMedRec, dateSubmit, idLab, idStaff,

typeMedRec,

idPatient)’,

yang

berisikan

perintah

untuk

menyimpan data ke dalam tabel medicalRecord pada basis data aplikasi rekam medis. •

Setelah berhasil disimpan akan fungsi tersebut akan memberikan umpan balik kepada fungsi kelas controller ‘medicalRecordCR’ agar menjalankan fungsi dari kelas controller ‘labCR’, ‘newRequest(idLab, tittleLab, statusLab)’, untuk diproses sebelum nantinya disimpan ke dalam basis data.

•

Bila sudah diproses, fungsi tersebut akan menjalankan fungsi kelas ‘labClass’, ‘submitNewLabRequest(idLab, tittleLab, statusLab)’, yang berisikan perintah untuk menyimpan ke dalam tabel ‘Lab’ pada basis data.

•

Setelah

itu,

secara

sekuensial

controller‘detailLabCR’,

akan

menjalankan

‘newDetailLabRequest(idLab,

fungsi

kelas

idDetail,

labelDetail)’, untuk memproses rincian detil uji laboratorium yang diinginkan. •

Untuk menyimpan rincian uji laboratorium yang diinginkan dokter, fungsi kelas controller ‘detailLabCR’, ‘newDetailLabRequest(idLab, idDetail,

122 labelDetail)’, akan menjalankan fungsi kelas ‘detailLabClass’, yakni ‘submitNewDetailLabRequest(idLab, idDetail, labelDetail)’ •

Bila telah disimpan, akan memberi umpan balik agar memerintahkan User Interface menampilkan pesan bahwa proses permintaan uji laboratorium telah berhasil.

123

121

Gambar 3.84 View Laboratory Test Request Sequence Diagram

124 Gambar di atas adalah diagram sequence yang dapat menggambarkan bagaimana proses seorang staf laboratorium memeriksa lembar permohonan uji laboratorium pasien. •

Pertama kali, user perlu melakukan login aplikasi.

•

Setelah berhasil melakukan login aplikasi, user diminta untuk memasukan ID pasien.

•

User Interface akan menjalankan fungsi dari kelas controller ‘labCR’, ‘getLabRequestList(idPatient, status)’ dengan sebagai parameter adalah ID pasien dan staus bertipe boolean ‘false’

•

Variabel statuspada parameter fungsi tersebut berguna sebagai pembeda record hasil lab dengan request pada tabel‘Lab’di basis data aplikasi rekam medis.

•

Setelah sebelumnya data yang diinput oleh user diproses, maka berikutnya fungsi kelas controller ‘labCR’, ‘getLabRequestList(idPatient, status)’ akan memanggil fungsi kelas ‘labClass’, ‘getLabRequestList(idPatient, status)’ yang berisikan perintah untuk mengambil data dari basis data aplikasi rekam medis.

•

Bila berhasil, fungsi tersebut akan memberikan return value kepada kelas controller untuk menampilkan daftar permohonan uji laboratorium pasien.

•


•

Ketika ia memilih salah satunya, user inteface akan menjalankan fungsi dari kelas controller ‘detailLabCR’,‘getDetailLabRequest(idLab)’, yang berisikan perintah-perintah untuk memroses inputan dari user.

•

Setelah selesai diproses, fungsi tersebut akan menjalankan fungsi dari kelas ‘detailLabClass’, ‘getDetailLabRequest(idLab)’, yang berisikan perintah untuk mengambil data dari basis data yang digunakan aplikasi rekam medis.

•

Data

yang

didapatkan

dari

fungsi

kelas

‘detailLabClass’,

‘getDetailLabRequest(idLab)’, akan menjadi return value kepada kelas controller ‘detailLabCR’ agar dapat ditampilkan pada user interface.

125

123

Gambar 3.85 Submit New Laboratory Test Result Sequence Diagram

126 Gambar di atas adalah diagram sequence untuk menjelaskan proses seorang staf laboratorium mencatat hasil uji laboratorium pasien. •


•

Setelah berhasil melakukan login aplikasi, user diminta untuk memasukan ID pasien.

•

User Interface akan menjalankan fungsi dari kelas controller ‘labCR’, ‘getLabRequestList(idPatient, status)’ dengan sebagai parameter adalah ID pasien dan staus bertipe boolean ‘false’

•

Variabel status pada parameter fungsi tersebut berguna sebagai pembeda record hasil lab dengan request pada tabel ‘Lab’ di basis data aplikasi rekam medis.

•

Setelah sebelumnya data yang diinput oleh user diproses, maka berikutnya fungsi kelas controller ‘labCR’, ‘getLabRequestList(idPatient, status)’ akan memanggil fungsi kelas ‘labClass’, ‘getLabRequestList(idPatient, status)’ yang berisikan perintah untuk mengambil data dari basis data aplikasi rekam medis.

•

Bila berhasil, fungsi tersebut akan memberikan return value kepada kelas controller untuk menampilkan daftar permohonan uji laboratorium pasien.

•


•

Ketika ia memilih salah satunya, user inteface akan menjalankan fungsi dari kelas controller ‘detailLabCR’,‘getDetailLabRequest(idLab)’, yang berisikan perintah-perintah untuk memroses inputan dari user.

•

Setelah selesai diproses, fungsi tersebut akan menjalankan fungsi dari kelas ‘detailLabClass’, ‘getDetailLabRequest(idLab)’, yang berisikan perintah untuk mengambil data dari basis data yang digunakan aplikasi rekam medis.

•

Data

yang

didapatkan

dari

fungsi

kelas


‘getDetailLabRequest(idLab)’, akan menjadi return value kepada kelas controller ‘detailLabCR’ agar dapat ditampilkan pada user interface. •

Adapun tampilan yang diberikan langsung berupa formulir pengerjaan hasil uji laboratorium.

•

Setelah selesai menginput hasil uji laboratorium dan menutupnya dengan menekan tombol ‘submit’, user interface akan menjalankan fungsi dari

127 kelas controller ‘labCR’, ‘newResult(idLab, dateExecute, tittleLab, statusLab, idStaff)’, yang berguna untuk memroses data yang dimasukan oleh user. •

Setelah

selesai

pemrosesan,

fungsi

kelas

controller

‘labCR’,

‘newResult(idLab, dateExecute, tittleLab, statusLab, idStaff)’, akan menjalankan

fungsi

kelas

‘labClass’,

submitNewLabResult(idLab,

dateExecute tittleLab, statusLab, idStaff) berfungsi untuk mengubah isi status menjadi ‘true’ yang berarti telah selesai dikerjakan dan sudah bukan lagi berupa request, dan menambahkan tanggal dan penanggung jawab pengerjaan hasil laboratorium. •

Setelahnya

menjalankan

fungsi

kelas

controller

‘detailLabCR’,

‘newDetailResult(idLab, idDetail, valueDetail)’, yang berisikan perintahperintah untuk memroses inputan dari user. •

Dan

setelah


selesai

diproses,

akan

dijalankan

’submitNewDetailLabResult(idLab,

fungsi

kelas

idDetail,

valueDetail)’. •

Fungsi tersebut bertugas untuk menjalankan query sql ‘update’ untuk menambahkan isi field valueDetail pada tabel detailLabpada basis data.

•

Setelah semua data berhasil tersimpan, controller ‘detailLabCR’, akan memberikan perintah untuk menampilkan pesan konfirmasi bahwa hasil uji laboratorium berhasil disimpan.

126

128

Gambar 3.86 View Laboratory Test Result Sequence Diagram untuk User ‘Dokter’

129

127

Gambar 3.87 View Laboratory Test Result Sequence Diagram untuk User ‘Staff Laboratorium’

130 Gambar di atas adalah diagram sequence yang digunakan untuk mennggambarkanbagaimana proses seorang dokter dan staf laboratorium dapat melihat hasil uji laboratorium melalui aplikasi rekam medis. •


•

Jika telah berhasil melakukan login aplikasi, user diminta untuk memasukan ID pasien yang bersangkutan.

•

Setelah user interface akan menjalankan fungsi kelas controller ‘labCR’,‘getLabResultList(idPatient, status)’ dengan sebagai parameter adalah ID pasien yang sebelumnya dimasukan dan status bervariabel boolean, ‘true’, yang menandakan bahwa data tersebut adalah ‘result’.

•

Pada fungsi tersebut ID pasien akan diproses terlebih dahulu sebelum nantinya akan digunakan untuk mencari data yang diperlukan pada basis data aplikasi.

•

Setelah diproses, fungsi tersebut akan menjalankan fungsi dari kelas ‘labClass’, ‘getLabResultList(idPatient, status)’, yang berisikan perintah untuk mendapatkan data dari basis data aplikasi.

•

Setelah ditemukan data yang hendak digunakan, maka data tersebut akan dikembalikan sebagai return value fungsi kelas controller ‘labCR’, ‘getLabResultList(idPatient, status)’.

•

Selanjutnya fungsi tersebut akan memerintahkan user interface agar menampilkan data tersebut sebagai daftar hasil uji laboratorium pasien.

•

User dapat memilih salah satu dari daftar tersebut nantinya bila hendak melihat secara terperinci.

•

Ketika salah satu lembar hasil uji laboratorium tersebut dipilih, user interface akan menjalankan fungsi kelas controller ‘detailLabCR’, ‘getDetailLabResult(idLab)’, yang berisikan perintah-perintah pemrosesan data parameter yang digunakan sebelum nantinya digunakan untuk mendapatkan data yang diinginkan pada basis data.

•

Setelah selesai pemrosesan, akan dijalankan fungsi kelas ‘detailLabClass’, ‘getDetailLabResult(idLab)’, yang berisikan perintah untuk mendapatkan data pada basis data.

131 •

Data yang didapatkan oleh fungsi tersebut akan dikembalikan kepada fungsi kelas controller ‘detailLabCR’, ‘getDetailLabResult(idLab)’, sebagai return value.

•

Data yang didapatkan tersebut akan diproses terlebih dahulu sebelum ditampilkan oleh user interface.

•

Kemudian, nantinya akan ditampilkan oleh user interface pada halaman detail lab result yang berisikan detil-detil dari hasil uji laboratorium yang sebelumnya dipilih oleh user.

130

132

Gambar 3.88 View Laboratory Test Result Sequence Diagram untuk User ‘Pasien’

133 Gambar di atas adalah diagram sequence yang digunakan untuk mennggambarkan bagaimana proses pasien dapat melihat hasil uji laboratorium melalui aplikasi rekam medis. •


•

Berbeda dengan user dokter dan staf laboratorium, pasien tidak perlu lagi memasukan ID pasien.

•

Setelah login, user interface akan secara langsung menjalankan fungsi kelas controller ‘labCR’, ‘getLabResultList(idPatient, status)’ dengan sebagai parameter adalah ID pasien yang sebelumnya dimasukan dan status bertipe boolean, ‘true’, yang menandakan bahwa data adalah sebuah ‘result’.

•


•

Setelah diproses, fungsi tersebut akan menjalankan fungsi dari kelas ‘labClass’, ‘getLabResultList(idPatient, status)’, yang berisikan perintah untuk mendapatkan data dari basis data aplikasi.

•

Setelah ditemukan data yang hendak digunakan, maka data tersebut akan dikembalikan sebagai return value fungsi kelas controller ‘labCR’, ‘getLabResultList(idPatient, status)’.

•

Selanjutnya fungsi tersebut akan memerintahkan user interface agar menampilkan data tersebut sebagai daftar hasil uji laboratorium pasien.

•


•

Ketika salah satu lembar hasil uji laboratorium tersebut dipilih, user interface akan menjalankan fungsi kelas controller ‘detailLabCR’, ‘getDetailLabResult(idLab)’, yang berisikan perintah-perintah pemrosesan data parameter yang digunakan sebelum nantinya digunakan untuk mendapatkan data yang diinginkan pada basis data.

•

Setelah selesai pemrosesan, akan dijalankan fungsi kelas ‘detailLabClass’, ‘getDetailLabResult(idLab)’, yang berisikan perintah untuk mendapatkan data pada basis data.

134 •

Data yang didapatkan oleh fungsi tersebut akan dikembalikan kepada fungsi kelas controller ‘detailLabCR’, ‘getDetailLabResult(idLab, status)’, sebagai return value.

•

Data yang didapatkan tersebut akan diproses terlebih dahulu sebelum ditampilkan oleh user interface.

•

Kemudian, nantinya akan ditampilkan oleh user interface pada halaman detail lab result yang berisikan detil-detil dari hasil uji laboratorium yang sebelumnya dipilih oleh user.

135

133

Gambar 3.89 Request Radiology Test Sequence Diagram

136 Gambar di atas adalah diagram sequence untuk menggambarkan proses permohonan radiologi pasien seperti, pemindaian sinar x, mri, atau usg oleh dokter. •

Pertama kali user harus melakukan login aplikasi.

•

Kemudian, user memasukan ID pasien yang bersangkutan.

•

Setelah sistem memberikan umpan balik, user diminta untuk memilih menu ‘New Radiology Request’

•

User interface akan menampilkan halaman baru berisikan formulir permintaan uji radiologi.

•

Setelah user selesai mengisi formulir tersebut, dan telah menekan button ‘submit’, sistem akan memroses data yang telah diisikan dengan menjalankan fungsi dari kelas ‘medicalRecordCR’, ‘newRad (idMedRec, dateSubmit,

idRad,

idStaff,

typeMedRec,

idPatient)’,untuk

memvalidasikan data yang diinput oleh user. •

Selesai

divalidasi,

fungsi

akan

menjalankan

fungsi

dari

kelas

‘medicalRecordClass’, ‘submitNewRad(idMedRec, dateSubmit, idRad, idStaff,

typeMedRec,

idPatient)’,

yang

berisikan

perintah

untuk

menyimpan data ke dalam tabel medicalRecord pada basis data aplikasi rekam medis. •

Setelah berhasil disimpan akan fungsi tersebut akan memberikan umpan balik kepada fungsi kelas controller ‘medicalRecordCR’ agar menjalankan fungsi dari kelas controller ‘radiologyCR’, ‘newRequest(idRad, tittleRad, statusRad)’, untuk diproses sebelum nantinya disimpan ke dalam basis data.

•

Bila sudah diproses, fungsi tersebut akan menjalankan fungsi kelas ‘radiologyClass’, ‘submitNewRadRequest(idRab, tittleRad, statusRad)’, yang berisikan perintah untuk menyimpan ke dalam tabel ‘radiology’ pada basis data.

•

Bila

data

telah

tersimpan,

fungsi

kelas

‘radiologyClass’,

‘submitNewRadRequest(idRab, tittleRad, statusRad)’, akan memberikan umpan

balik

kepada

fungsi

kelas

newRequest(idRad, tittleRad, statusRad)’.

controller

‘radiologyCR’,

137 •

Umpan balik tersebut menjadi pemicu agar fungsi tersebut memerintahkan user interface menampilkan pesan bahwa permohonan radiologi dokter telah berhasil ditambahkan.

Gambar 3.90View Radiology Test Request Sequence Diagram Sequence ini menjelaskan proses seorang staf rontgen memeriksa lembar permohonan permeriksaan rontgen terhadap pasien yang dapat dilakukan melalui aplikasi ini, baik web ataupun mobile. •


•

Kemudian setelah itu, user diminta untuk memasukan ID pasien yang bersangkutan.

•

User

Interface

akan

menjalankan

fungsi

dari

kelas

controller

‘radiologyCR’, ‘getRadRequestList(idPatient, status)’ dengan sebagai parameter adalah ID pasien dan staus bertipe boolean ‘false’ yang menandakan bahwa data yang diminta adalah berupa ‘request’

138 •

Setelah sebelumnya data yang diinput oleh user diproses, maka berikutnya fungsi kelas controller ‘radiologyCR’, ‘getRabRequestList(idPatient, status)’

akan

memanggil

fungsi

kelas


‘getRabRequestList(idPatient, status)’ yang berisikan perintah untuk mengambil data dari basis data aplikasi rekam medis. •

Bila berhasil, fungsi tersebut akan memberikan return value kepada kelas controlleryang kemudian akan memerintahkan user intefaceuntuk menampilkan data tersebut menjadi daftar permohonan radiologi untuk pasien.

•

Staf radiologi dapat memilih salah satu dari daftar tersebut.

•

Ketika ia memilih salah satunya, user interface akan menjalankan fungsi kelas controller ‘radiologyCR’, ‘getDetailRadRequest(idRad)’

•

Pada fungsi tersebut parameter yang digunakan akan diproses terlebih dahulu sebelum nantinya digunakan untuk mencari dan mengambil data yang diperlukan pada basis data aplikasi.

•

Setelah selesai diproses, barulah controller menjalankan fungsi kelas ‘radiologyClass’, ‘getDetailRadRequest(idRad)’, yang berisikan perintahperintah yang diperlukan untuk mencari dan mengambil data yang diperlukan pada basis data aplikasi.

•

Data yang didapatkan akan menjadi return value untuk fungsi kelas controller ‘radiologyCR’, ‘getDetailRadRequest(idRad)’, yang akan memroses data tersebut sebelum ditampilkan oleh user interface.

139

Gambar 3.91Submit New Rontgen Scanning Result Sequence Diagram Gambar di atas adalah diagram sequence untuk menjelaskan proses seorang staf rontgen dapat mengunggah hasil rntgen baru milik pasien. •


•

Kemudian setelah itu, user diminta untuk memasukan ID pasien yang bersangkutan.

•

User

Interface

akan

menjalankan

fungsi

dari

kelas

controller

‘radiologyCR’, ‘getRadRequestList(idPatient, status)’ dengan sebagai parameter adalah ID pasien dan staus bertipe boolean ‘false’ yang menandakan bahwa data yang diminta adalah berupa ‘request’ •

Setelah sebelumnya data yang diinput oleh user diproses, maka berikutnya fungsi kelas controller ‘radiologyCR’, ‘getRadRequestList(idPatient, status)’

akan

memanggil

fungsi

kelas


140 ‘getRadRequestList(idPatient, status)’ yang berisikan perintah untuk mengambil data dari basis data aplikasi rekam medis. •

Bila berhasil, fungsi tersebut akan memberikan return value kepada kelas controller yang kemudian akan memerintahkan user inteface untuk menampilkan data tersebut menjadi daftar permohonan radiologi untuk pasien.

•

Staf radiologi dapat memilih salah satu dari daftar tersebut.

•

Ketika ia memilih salah satunya, user interface akan menjalankan fungsi kelas controller ‘radiologyCR’, ‘getDetailRadRequest(idRad)’

•

Pada fungsi tersebut parameter yang digunakan akan diproses terlebih dahulu sebelum nantinya digunakan untuk mencari dan mengambil data yang diperlukan pada basis data aplikasi.

•

Setelah selesai diproses, barulah controller menjalankan fungsi kelas ‘radiologyClass’, ‘getDetailRadRequest(idRad)’, yang berisikan perintahperintah yang diperlukan untuk mencari dan mengambil data yang diperlukan pada basis data aplikasi.

•

Data yang didapatkan akan menjadi return value untuk fungsi kelas controller ‘radiologyCR’, ‘getDetailRadRequest(idRad)’, yang akan memroses data tersebut sebelum ditampilkan oleh user interface.

•

Adapun

data

yang

ditampilkan akan

langsung berupa

formulir

pengunggahan hasil radiologi pasien. •

Setelah staf radiologi harus mengisi formulir tersebut secara lengkap dan menekan tombol ‘Submit’, user interface akan menjalankan fungsi kelas controller ‘radiologyCR’, ‘newRad(idRad, status, imagePath, detailRad, dateExecute)’, untuk memroses data yang diinput sebelum nantinya akan diunggah ke dalam basis data aplikasi.

•

Setelah terproses, kelas controller‘radiologyCR’ akan menjalankan fungsi kelas

‘radiologyClass’, ‘submitNewRad(idRad, status, imagePath,

detailRad, dateExecute)’. •

Fungsi kelas ‘radiologyClass’, ‘submitNewRad(idRad, status, imagePath, detailRad, dateExecute)’, memiliki peran untuk menjalankan query sql ‘update’ dengan sebagai parameter adalah id radiologi. Adapun yang perlu untuk diperbarui adalah field status menjadi ‘true’ yang berarti sudah

141 dikerjakan, imagepath yakni alamat penyimpanan file unggahan, detil penjelasan file unggahan, dan tanggal pengerjaan serta staf yang mengerjakan. •

Setelah

data

tersimpan,

Fungsi

kelas


‘submitNewRad(idRad, status, imagePath, detailRad, dateExecute)’, akan memberikan return value kepada fungsi kelas controller ‘radiologyCR’, ‘getDetailRadRequest(idRad)’, bahwa data berhasil tersimpan. •

Dengan return value tersebut, fungsi kelas controller ‘radiologyCR’, ‘getDetailRadRequest(idRad)’, akan memerintahkan user interface untuk menampilkan pesan bahwa data berhasil tersimpan ke dalam basis data.

Gambar 3.92 View Radiology Result Sequence Diagram untuk User ‘Dokter’

142

Gambar 3.93 View Radiology Result Sequence Diagram untuk User ‘Staf Radiologi’ Gambar-gambar di atas adalah diagram sequence yang digunakan untuk menggambarkan bagaimana proses seorang dokter dan staf radiologi dapat melihat hasil radiologi yang telah dikerjakan. •


•

Jika telah berhasil melakukan login aplikasi, user diminta untuk memasukan ID pasien yang bersangkutan.

•

Setelah user interface akan menjalankan fungsi kelas controller ‘radiologyCR’, ‘getRadResultList(idPatient, status)’ dengan sebagai parameter adalah ID pasien yang sebelumnya dimasukan dan status bervariabel boolean, ‘true’, yang menandakan bahwa data tersebut adalah ‘result’.

•


143 •

Setelah diproses, fungsi tersebut akan menjalankan fungsi dari kelas ‘radiologyClass’, ‘getRadResultList(idPatient, status)’, yang berisikan perintah untuk mendapatkan data dari basis data aplikasi.

•

Setelah ditemukan data yang hendak digunakan, maka data tersebut akan dikembalikan sebagai return value fungsi kelas controller ‘radiologyCR’, ‘getRadResultList(idPatient, status)’.

•

Selanjutnya fungsi tersebut akan memerintahkan user interface agar menampilkan data tersebut sebagai daftar hasil radiologi pasien.

•


•

Ketika salah satu lembar hasil radiologi tersebut dipilih, user interface akan

menjalankan

fungsi

kelas

controller

‘radiologyCR’,

‘getDetailRadResult(idRad)’, yang berisikan perintah-perintah pemrosesan data parameter yang digunakan sebelum nantinya digunakan untuk mendapatkan data yang diinginkan pada basis data. •

Setelah selesai pemrosesan, akan dijalankan fungsi kelas ‘detailLabClass’, ‘getDetailRadResult(idRad)’, yang berisikan perintah untuk mendapatkan data pada basis data.

•

Data yang didapatkan oleh fungsi tersebut akan dikembalikan kepada fungsi kelas controller ‘radiologyCR’, ‘getDetailRadResult(idRad)’, sebagai return value yang akan terlebih dahulu diproses sebelum ditampilkan oleh user interface.

•

Seselesainyapemrosesan data pada fungsi kelas controller ‘radiologyCR’, ‘getDetailRadResult(idRad)’, user interfaceakan menampilkan hasil pemrosesan tersebut pada halaman detil radiologi pasien.

144

Gambar 3.94 View Radiology Result Sequence Diagram untuk User ‘Pasien’ Gambar di atas adalah diagram sequence yang digunakan untuk menggambarkan bagaimana proses pasien dapat melihat hasil radiologi milikinya yang telah dikerjakan. •


•

Berbeda dengan user dokter dan staf laboratorium, pasien tidak perlu lagi memasukan ID pasien.

•

Setelah user interface akan menjalankan fungsi kelas controller ‘radiologyCR’, ‘getRadResultList(idPatient, status)’ dengan sebagai parameter adalah ID pasien yang sebelumnya dimasukan dan status bervariabel boolean, ‘true’, yang menandakan bahwa data tersebut adalah ‘result’.

•


145 •

Setelah diproses, fungsi tersebut akan menjalankan fungsi dari kelas ‘radiologyClass’, ‘getRadResultList(idPatient, status)’, yang berisikan perintah untuk mendapatkan data dari basis data aplikasi.

•

Setelah ditemukan data yang hendak digunakan, maka data tersebut akan dikembalikan sebagai return value fungsi kelas controller ‘radiologyCR’, ‘getRadResultList(idPatient, status)’.

•

Selanjutnya fungsi tersebut akan memerintahkan user interface agar menampilkan data tersebut sebagai daftar hasil radiologi pasien.

•


•

Ketika salah satu lembar hasil radiologi tersebut dipilih, user interface akan

menjalankan

fungsi

kelas

controller

‘radiologyCR’,

‘getDetailRadResult(idRad)’, yang berisikan perintah-perintah pemrosesan data parameter yang digunakan sebelum nantinya digunakan untuk mendapatkan data yang diinginkan pada basis data. •

Setelah selesai pemrosesan, akan dijalankan fungsi kelas ‘detailLabClass’, ‘getDetailRadResult(idRad)’, yang berisikan perintah untuk mendapatkan data pada basis data.

•

Data yang didapatkan oleh fungsi tersebut akan dikembalikan kepada fungsi kelas controller ‘radiologyCR’, ‘getDetailRadResult(idRad)’, sebagai return value yang akan terlebih dahulu diproses sebelum ditampilkan oleh user interface.

•

Seselesainya pemrosesan data pada fungsi kelas controller ‘radiologyCR’, ‘getDetailRadResult(idRad)’, user interface akan menampilkan hasil pemrosesan tersebut pada halaman detil radiologi pasien.

144

146

Gambar 3.95 Submit New Document Sequence Diagram

147 Gambar di atas adalah diagram sequence untuk menjelaskan proses pengajuan dokumen tindakan medis oleh seorang dokter melalui aplikasi web ataupun mobile. •

Pertama user perlu melakukan login aplikasi.

•

Setelah itu, user diminta untuk memasukan ID pasien yang bersangkutan.

•

Untuk dapat menampilkan halaman dokumen medis baru, user diminta untuk memilih menu ‘New Document’

•

User interface akan memberi umpan balik dengan menampilkan halaman formulir pengajuan dokumen.

•

Setelah usermengisi dengan lengkap formulir tersebut dan menekan tombol ‘Submit’,

user

interface

akan

menjalankan

fungsi

dari

controller‘medicalRecordCR’,‘newDocument(idMedRec,

kelas

dateSubmit,

idDocument, idStaff, typeMedRec, idPatient)’, untuk melakukan pemrosesan data yang diinput oleh user sebelum digunakan secara lanjut sebagai parameter. •

Selanjutnya fungsi tersebut akan mengakhir pemrosesan dengan memanggil fungsi kelas

‘medicalRecordClass’,

‘submitNewDocument(idMedRec,

idPatient,

dateSubmit, typeMedRec, idDocument, idStaff)’, yang berisikan perintah-perintah untuk memasukan data ke dalam basis data aplikasi. •

Bila data berhasil disimpan ke dalam basis data aplikasi, fungsi tersebut akan memberi pesan kepada ‘medicalRecordCR’ bahwa data berhasil disimpan.

•

Pesan ini menjadi pemicu agar kelas controller menjalankan fungsi kelas controller ‘documentCR’, ‘newDocument(idDocument, tittleDocument, detailDocument)’

•

Kelas controller mempunyai fungsi untuk mengatur data yang diinput oleh user sebelum dimasukan ke dalam basis data aplikasi.

•

Setelah data terproses, barulah dijalankan fungsi kelas ‘documentClass’, ‘submitNewDocument(idDocument,

tittleDocument,

detailDocument)’

yang

berisikan perintah untuk menyimpan data ke dalam basis data aplikasi. •

Setelah data berhasil tersimpan, fungsi kelas ‘documentClass’ akan memberi pesan kepada kelas controller ‘documentCR’, agar menampilkan pesan kepada user bahwa pembuatan dokumen tindakan medis berhasil tersimpan.

148

Gambar 3.96 Responding New Document Sequence Diagram Gambar di atas adalah diagram sequence untuk menjelaskan bagaimana proses sistem pasien dapat memberi tanggapan mengenai dokumen tindakan medis yang diajukan oleh dokter. •

Pertama pasien perlu melakukan login aplikasi.

•

setelah itu user interface akan menjalankan fungsi dari kelas ‘documentCR’, ‘getDocumentList(idPatient)’, yang bertugas untuk memroses paramaeter yang akan digunakan.

149 •

Bila data telah terproses barulah dijalankan fungsi kelas ‘documentClass’, ‘getDocumentList(idPatient)’ yang berisikan perintah-perintah untuk mencari data yang diperlukan berdasarkan parameter yang digunakan pada basis data aplikasi.

•

Data yang telah didapatkan akan kembali dikirim kepada kelas controller untuk kembali diproses sebelum ditampilkan oleh user interface.

•

Jika sudah, pasien dapat memilih salah satu dari daftar dokumen tersebut.

•

Ketika salah satu dari dokumen tersebut dipilih, user interface akan menjalankan fungsi kelas controller ‘documentCR’, ‘getDetailDocument(idDocument)’, untuk diproses terlebih dahulu.

•

Setelah

itu,

fungsi

kelas

controllerkelas

‘getDetailDocument(idDocument)’,

akan

controller

memanggil

‘documentCR’, fungsi

kelas

‘documentClass’, getDetailDocument(idDocument)’, yang berisikan perintahperintah untuk mencari dan mendapatkan data yang dibutuhkan pada basis data aplikasi. •

Setelah data didapatkan, data akan dikirim kembali kepada fungsi kelas controller ‘documentCR’, ‘getDetailDocument(idDocument)’, yang akan menjalankan fungsi ‘checkStatus()’

•

Adapun kegunaan fungsi tersebut untuk membedakan antara tampilan ketika dokumen tindakan medis yang sudah ditanggapi dengan dokumen tindakan medis yang belum diberikan tanggapan.

•

Apabila dokumen telah diberi tanggapan, user interface akan diberikan perintah untuk hanya menampilkan rincian dokumen.

•

Sedangkan apabila dokumen tindakan medis belum diberikan tanggapan, user interface akan diperintahkan untuk menampilkan, tidak hanya rincian isi dokumen, namun juga formulir tanggapan pasien mengenai tindakan medis tersebut.

•

Pasien dapat menolak dan menyetujui isi dari dokumen tersebut, dan menekan tombol ‘submit’ untuk menyimpannya.

•

Setelah menekan tombol ‘Submit’, user interface akan menjalankan fungsi kelas controller

‘documentCR’,‘respondDocoment(idDocument,

statusDocument,

dateUpdate)’, untuk terlebih dahulu diproses. •

Data yang telah diproses akan disimpan dengan cara memanggil fungis kelas ‘documentClass’,

updateDocument(idDocument,

statusDocument,

150 dateUpdate)yang berfungsi untuk menambahkan status dokumen pada table document. •

Setelah data berhasil disimpan, user interface akan diperintahkan untuk menampilkan pesan kepada userbahwa data telah tersimpan ke dalam pusat data aplikasi.

Gambar 3.97 View Document Sequence Diagram untuk User ‘Dokter’ Gambar di atas adalah diagram sequence untuk menjelaskan bagaimana proses bagaimana dokter dapat melihat dokumen persetujuan tindakan medis yang ditujukan untuk pasien. •

Pertama dokter perlu melakukan login aplikasi.

•

Jiks berhasil login aplikasi, dokter akan diminta untuk memasukan ID pasien terkait.

151 •

Selepas ID pasien dimasukan, user interface akan menjalankan fungsi dari kelas ‘documentCR’, ‘getDocumentList(idPatient)’, yang bertugas untuk memroses paramaeter yang akan digunakan.

•


•


•

Dokter dapat memilih salah satu dari daftar dokumen tersebut.

•


•

Setelah

itu,

fungsi

kelas


controllerkelas akan

controller

memanggil


kelas


Kelas controller akan terlebih dahulu memroses data yang didapatkan.

•

Data yang telah terproses akan ditampilkan oleh user interface pada halaman detil dokumen.

152

Gambar 3.98 View Document Sequence Diagram untuk User ‘Pasien’ Gambar di atas adalah diagram sequence untuk menjelaskan bagaimana proses bagaimana pasien dapat melihat dokumen persetujuan tindakan medis yang ditujukan untuk pasien. •

Pertama pasien perlu melakukan login aplikasi.

•

Hampir menyerupai dengan diagram sequence view document untuk user ‘dokter’

•

Jika setelah berhasil melakukan login aplikasi, dokter akan diminta untuk memasukan ID pasien terkait, maka pasien tidak perlu melakukan hal tersebut.

•

Setelah pasien berhasil melakukan login aplikasi, user interface akan menjalankan fungsi dari kelas ‘documentCR’, ‘getDocumentList(idPatient)’, yang bertugas untuk memroses paramaeter yang akan digunakan.

•


153 •


•

pasien dapat memilih salah satu dari daftar dokumen tersebut.

•


•

Setelah

itu,

fungsi

kelas


controllerkelas akan

controller

memanggil


kelas


Kelas controller akan terlebih dahulu memroses data yang didapatkan.

•

Data yang telah terproses akan ditampilkan oleh user interface pada halaman detil dokumen.

ANALISIS DAN PERANCANGAN

Recommend Documents