PUSAT KESEHATAN MAHASISWA

Universitas Indonesia

Tugas

Analisis dan Perancangan Sistem

S i s t e m

I n f o r m a s i P e l a y a n a n K e s e h a t a n

KELOMPOK 03 Ali K Hendrico DK M Rusdi Zidni A Amir S [120100701Y] [120100049Y] [1201001741] [1201001136] [1200000063]

Fakultas Ilmu Komputer, Universitas Indonesia, Depok, 2004

DAFTAR ISI
DAFTAR ISI ________________________________ __________________ 2 DAFTAR GAMBAR ________________________________ ____________ 4 DAFTAR TABEL ________________________________ ______________ 5 PENDAHULUAN ________________________________ ______________ 6
I. II. III. Latar Belakang Dokumen _____________________________________________________ 6 Tujuan Dokumen ____________________________________________________________ 6 Struktur Dokumen _________________________________________________________ 7

RINGKASAN ________________________________ _________________ 8

I. Profil PKM __________________________________________________________________ 8 Visi dan Misi PKM UI ____________________________________________________________ 8 Struktur Organisasi PKM UI ________________________________ _______________________ 9 Standard Operating Procedure Bidang Pelayanan Medik_________________________________ 9 Gambaran Sistem Lama ________________________________ ______________________ 10 Rencana Pengembangan PKM UI ________________________________ __________________ 10 Sistem Lama PKM UI ___________________________________________________________ 11 Rekomendasi _____________________________________________________________ 11

II.

III.

PHYSICAL DATA FLOW DIAGRAM ______________________________ 16

I. Logical Data Flow Diagram ________________________________ ___________________ 16 DFD Level 0 ________________________________ __________________________________ 16 DFD Level l ________________________________________________________________ ___ 17 Physical Data Flow Diagram ________________________________ __________________ 18

II.

DATABASE SCHEMA ________________________________ _________ 20

I. Logical ER Diagram _________________________________________________________ 20

II.

Physical ER Diagram __________________________________________________ 21 Pemetaan ER Diagram ___________________________________________________________ 22 Normalisasi ER Diagram _________________________________________________________ 23

DESAIN INPUT, OUTPUT, DAN INTERFACE ______________________ 27

I. Alur Interface ________________________________ ______________________________ 27 Alur interface untuk Petugas Pendaftaran Pasien ______________________________________ 27 Alur interface untuk Dokter _______________________________________________________ 28 Desain Interface_____________________________________________________________ 28

II.

2 1

Desain dan Prototipe Output Sistem ________________________________________________ 28 Physical Output Design ________________________________ __________________________ 29 Desain dan Prototipe Input Sistem ________________________________ __________________ 33 Physical Input Design ___________________________________________________________ 35

3 1

DAFTAR GAMBAR
GAMBAR 1. STRUKTUR ORGANISASI PKM UI __________________________9 GAMBAR 2. STRUKTUR BIDANG PELAYANAN MEDIK __________________ 9 GAMBAR 3. DFD LEVEL 0 ________________________________ ____________ 16 GAMBAR 4. PHYSICAL DFD ________________________________ ___________ 19 GAMBAR 5. ER DIAGRAM ________________________________ _____________ 21 GAMBAR 6. PHYSICAL PEMETAAN ERD ________________________________22 GAMBAR 7.DIALOGUE CHART UNTUK PETUGAS PENDAFTARAN PASIEN __________ 27 GAMBAR 8.DIALOGUE CHART INTERFACE UNTUK DOKTER ____________ 28 GAMBAR 9. OUTPUT DAFTAR ANTRIAN PSIEN __________________________30 GAMBAR 10. OUTPUT DAFTAR ANGGOTA ____________________________31 GAMBAR 11. OUTPUT DATA LENGKAP ANGGOTA _____________________32 GAMBAR 12. OUTPUT MEDICAL CHECK-UP ____________________________33 GAMBAR 13. INPUT DAFTAR ANTRIAN PASIEN ________________________35 GAMBAR 14. INPUT DAFTAR ANGGOTA_______________________________36 GAMBAR 15. INPUT TAMBAH ANGGOTA BARU________________________37 GAMBAR 16. INPUT HAPUS DAN UBAH DATA _________________________38 GAMBAR 17. INPUT MEDICAL CHECK-UP ______________________________39

4 1

DAFTAR TABEL
TABEL 1. MATRIKS SISTEM KANDIDAT _______________________________12 TABEL 2. MATRIKS FEASIBILITY ________________________________ ______ 13 TABEL 3. PENJELASAN DFD LEVEL 0 ________________________________ 16 _ TABEL 4. PENJELASAN DFD LEVEL 1 ________________________________ 18 __

5 1

Pendahuluan
I. Latar Belakang Dokumen
Persetujuan yang diberikan pada dokumen System Proposal membutuhkan tindak lanjut berupa penjabaran dari desain sistem informasi Pelayanan Kesehatan di PKM UI yang akan dikembangkan. Penjabaran tersebut berupa physical design dari logical design yang telah dibuat. Bila pada tahap system analysis perhatian lebih difokuskan kepada masalah bisnis, maka pada tahap system design ini perhatian lebih difokuskan kepada masalah teknis atau implementasi dari sistem.

Pengerjaan desain sistem dapat dilakukan dengan berbagai strategi dan teknik, pada dokumen ini strategi desain yang diambil adalah strategi FAST System Design untuk In-House Development dengan tahapan-tahapan task, sebagai berikut: 1. Mendesain Arsitektur Aplikasi 2. Mendesain Database sistem 3. Mendesain Interface sistem 4. Package Design Specification 5. Meng- update Project Plan Pemilihan strategi FAST System Design untuk In-House Development lebih disebabkan oleh kemudahan dalam pengerjaan rancangan physical design, karena waktu yang ditersedia untuk tahapan system design yang sedikit, maka strategi yang sederhana dan cukup singkat akan memudahkan penyusunan dokumen.

II. Tujuan Dokumen

Tujuan dari dokumen ini adalah untuk mempresentasikan hasil dari desain-desain yangtelah dilakukan, seperti desain arsitektur aplikasi dengan physical DFD yang menjelaskan alur proses dari sistem informasi Pelayanan Kesehatan di PKM UI, atau desain database schema yang bertujuan menggambarkan desain dari data-data yang akan digunakan dalam sistem, serta desain interface yang mengatur interaksi dengan pengguna. Selain itu dengan dokumen system design yang telah disetujui, maka

tahap konstruksi sistem baru dapat dimulai.

6 1

III. Struktur Dokumen

Dalam dokumen ini dibahas desain physical DFD, database schema, dan diakhiri dengan desain interface, input dan output. Pembahasan dalam dokumen ini dimulai dengan penjelasan singkat tentang isi dan tujuan dokumen, dilanjutkan dengan ringkasan latar belakang proyek, yangmencakup profil PKM UI, sistem lama PKM UI, dan alur kerja di bidang pelayanan medik. Akhirnya pembahasan mulai

memasuki tahapan desain dengan diawali dengan physical DFD, yang sebelumnya diberikan cuplikan dari logical DFD dari dokumen sebelumnya, pembahasan berlanjut ke database schema, yang didahului oleh logical ERD, dan pembahasan ditutup dengan desain interface, input, dan output, dengan disertai alur interface pada sistem.

7 1

Ringkasan
I. Profil PKM
Pusat Kesehatan Mahasiswa (PKM) Universitas Indonesia (UI) adalah saah satu unit pelayanan mahasiswa yang berada dibawah Rektorat UI. PKM bertugas untuk melayani masalah kesehatan mahasiswa dan memberikan pelayanan untuk masyarakat UI pada umumnya. Saat ini PKM UI telah memiliki dua buah klinik yang terdapat di kampus UI Depok dan kampus UI Salemba. PKM UI memiliki sekitar 28 orang pegawai, yang terdiri dari pegawai tetap, honorer dan pegawai magang.

Visi dan Misi PKM UI

Visi PKM UI adalah meningkatkankesejahteraan mahasiswa melalui pelayanan kesehatan fisik dan psikis dalam rangka menunjang kelancaran pendidikan di Universitas Indonesia.

Misi PKM UI adalah sebagai berikut: 1. Melaksanakan tidakan promotif, prventif, kuratif dan rehabilitatif medik pada mahasiswa Universitas Indonesia. 2. Melaksanakan konsultasi psikologis bagi mahasiswa UI yang membutuhkan. 3. Melaksanakan kegiatan-kegiatan yang dapat menunjang kesejahteraan fisik dan psikologis mahasiswa UI. 4. Menjadikan pusat rujukan medik bagi mahasiswa UI 5. Menjadikan PKM UI sebagai tempat magang bagi mahasiswa UI yang membutuhkan. 6. Mendampingi kegiatan-kegiatan kemahasiswaan yang membutuhkan

pengawasan medik. 7. Menyelenggarakan kegiatan pengabdian kepada masyarakat di lingkungan UI

8 1

Struktur Organisasi PKM UI

Gambar 1. Struktur Organisasi PKM UI

Gambar 2. Struktur Bidang Pelayanan Medik

Standard Operating Procedure Bidang Pelayanan Medik

Prosedur Penerimaan Pasien, sebagai berikut:
y

Penerimanaan pasien adalah suatu proses: pendaftaraan, pencatatan dan penyaluran pasien ke unit pelayanan. Selanjutnya diberikan penanganan sesuai dengan penyakitnya.

y y y

Penerimaan pasien dilakukan di loket pendaftaran Pada waktu pendaftaran pasien menunjukkan kartu peserta Kartu peserta dicocokkan dengan data yang ada di komputer

9 1

Data setiap pasien dimasukkan ke dalam komputer, sedangkan bagi non peserta data dimasukkan ke status khusus

Jika data pasien belum tercantum di sistem komputer/ sistem sedang tidak aktif, data pasien dimasukkan ke dalam status sementara

Setiap pasien diarahkan ke ruang periksa yang sesuai dan diminta untuk menunggu panggilan menurut urutan pendaftaran, kecuali gawat darurat

Setelah pemeriksaan dan tindakan oleh dokter, pasien diarahkan ke apotek/lab/rekam medis/rujuk/pulang sesuai dengan keputusan dokter yang merawat

Prosedur Pelayanan Medis Umum, adalah sebagai berikut:

y

Setiap pasien harus mendaftar di loket pendaftaran dan menunggu di ruang tunggu

y y y

Pasien masuk ke ruang periksa sesuai urutan pendaftaran Pasien gawat darurat diberikan prioritas Pasien yang pertama kali berobat, status di komputer atau status sementara harus diisi lengkap dengan pemeriksaan menyeluruh

Pengobatan yang diberikan mengacu pada SOP medis Ikatan Dokter Indonesia

y y y

Resep disusun secara rasional dan mempertimbangkan daftar obat PKM UI Pasien diarahkan untuk mengambil obat di unit farmasi Untuk pemeriksaan penunjang harus dilengkapi dengan lembar permintaan oleh dokter

y y

Jika diperlukan pasien dapat dirujuk ke dokter spesialis Bila ada tindakan khusus, pasien dan keluarga diberi penjelasan dan diminta mengisi informasi , bila menolak harus mengisi surat penolakan.

II. Gambaran Sistem Lama

Rencana Pengembangan PKM UI

10 1

PKM UI sebagai institusi yang telah berdiri sejak 50 tahun yang lalu merupakan salah satu intitusi di Universitas Indonesia yang memiliki peran besar bagi kesejahteraan mahasiswa. Di masa yang akan datang PKM UI sebagai sebuah institusi mau tidak mau harus melakukan pengembangan untuk meningkatkan pelayanannya ke public, dalam hal ini mahasiswa dan warga UI. Di lain pihak dalam menghadapi tantangan kedepan yang membawa UI menuju BHMN (Badan Hukum Milik Negara), PKM UI harus melakukan efisiensi sumber daya besar-besaran.

Untuk itu dalam program PKM UI kedepan telah dirumuskan rencana untuk melakukan program komputerisasi kegiatan pelayanan di PKM UI, dengan tujuan meningkatkan pelayanan, profesionalisme dan efisiensi biaya. Sehingga dalam 2-3 tahun kedepan PKM UI mampu memiliki sistem informasi yang sesuai dengan spesifikasi PKM UI. Jadi dapat disimpulkan bahwa PKM UI telah memiliki rencana besar untuk pengembangan sistem informasi yang sesuai dengan karakteristik PKM UI.

Sistem Lama PKM UI

PKM UI belum memiliki sistem informasi untuk kegiatan pelayanannya, selama ini data yang ada diletakkan dalam dokumen-dokumen kertas dan file-file yang tersebar dalam komputer di bagian administrasi PKM UI. Sistem lama yang dimaksud dalam dokumen ini adalah sistem manual yang dilakukan PKM UI dalam kegiatan sehari hari.

III. Rekomendasi
Berdasarkan dokumen System Proposal yang telah terlebih dahulu dikerjakan, didapatkan kandidat terbaik yang akan menjadi dasar pengerjaan desain sist m pada e pengembangan Sistem Informasi Pelayanan Kesehatan pada PKM UI. Kandidat

terbaik yang diperoleh dengan menggunakan matriks feasibility adalah kombinasi PHP 4.0 dan MySQL serta spesifikasi hardware seperti terlihat dalam matriks sistem kandidat berikut:
11 1

Tabel 1. Matriks Sistem Kandidat

Karakteristik

Kandidat 1

Kandidat 2

Kandidat 3

Software yang digunakan untuk pengembangan sistem

PHP 4.0 untuk web-application dan MySQL sebagai DBMS

Microsoft ASP.NET untuk web application dan Microsoft Access sebagai DBMS

Microsoft ASP untuk webapplication dan Microsoft SQL Server 2000 sebagai DBMS

Software-software seperti DBMS, bahasa pemrograman yang dipakai, dll Hardware yang digunakan dalam sistem Hardware-hardware yang akan dipakai sistem, seperti untuk server dan workstation Keuntungan yang didapat Penjelasan singkat tentang keuntungan yang dimiliki kandidat sistem
Sarana untuk input data

Server: Komputer dengan kemampuan setara Pentium 4 Workstation: Komputer Pentium 2 Biaya pengembangan dapat ditekan seoptimal mungkin

Sama seperti kandidat 1

Sama seperti kandidat 1

Pengembangan sistem yang dapat dikembangkan menjadi sistem yang besar Sama seperti kandidat 1

Pengembangan yang dapat beralih ke teknologi .NET dan kesesuaian dengan Windows OS Sama seperti kandidat 1

Keyboard dan mouse

Cara input yang dipakai untuk memasukan data.

Sarana untuk output data

Printer Laser HP

Sama seperti kandidat 1

Sama seperti kandidat 1

Cara output yang dipakai untuk menampilkan data

Sarana untuk

Seagate 40 GB,

Sama seperti

Sama seperti

12 1

menyimpan data

7200 RPM

kandidat 1

kandidat 1

Cara penyimpanan data ke perangkat keras (harddisk), kapasitas hardisk yang diperlukan, kecepatannya
Bagian yang terkomputerisasi

Pemilihan bagian yang akhirnya dikomputerisasi oleh pengembangan sistem

Teknologi pemrosesan data

Data Kesehatan Pasien, pendaftaran dan pelayanan kesehatan

Sama seperti kandidat 1

Sama seperti kandidat 1

Sarana yang dipakai untuk pemrosesan data

Pengaksesan data lewat LAN untuk aktivitas dalam satu cabang dan pengaksesan lewat internet(JUITA) untuk koordinasi dengan Salemba

Sama seperti kandidat 1

Sama seperti kandidat 1

Tabel 2. Matriks feasibility

Kriteria feasibility

Bobot

Kandidat 1

Kandidat 2

Kandidat 3

Operational feasibility

30%

Sistem owner akan mudah mempelajari PHP 4.0 dan dengan sistem baru yang berbasis web dan userfriendly akan mengurangi terjadinya human error

Sistem owner akan lebih sulit mempelajari Java dan dengan sistem baru yang berbasis web dan userfriendly akan mengurangi terjadinya human error

Sistem owner akan mudah mempelajari ASP dan dengan sistem baru yang berbasis web dan userfriendly akan mengurangi terjadinya human error

13 1

Skor: 90 Technical feasibilty 30% MySQL sudah dikenal sebagai DBMS yang cukup handal dengan karakteristik response time yang cepat.

Skor: 50 MySQL sudah dikenal sebagai DBMS yang cukup handal dengan karakteristik response time yang cepat.

Skor: 90 Microsoft SQL Server 7.0 dikenal sebagai DBMS yang handal tetapi memiliki keterbatasan response time yang kurang cepat bila dibandingkan MySQL. Skor : 70 Kombinasi Microsoft ASP dan Microsoft SQL Server kurang feasible. Microsoft ASP: $850 US Microsoft SQL Server: $19,999 US Skor: 40

Skor : 90 Economic feasibility 30% Kombinasi PHP 4.0 dan MySQL dirasakan cukup economic feasible mengingat keduanya didistribusikan secara freeware.

Skor: 90 Kombinasi Java Sun JDK1.4 dan MySQL dirasakan cukup economic feasible mengingat keduanya didistribusikan secara freeware. Skor: 100 Pihak IT belum terbiasa menggunakan Java jadi waktu pembelajaran yang diperlukan untuk pengembangan sistem yang baru lebih banyak di bandingkan kandidat satu, kurang lebih 5

Skor: 100 Schedule feasibility 10% Pihak IT 1001buku sudah terbiasa menggunakan PHP dan My SQL, jadi waktu pembelajaran yang diperlukan untuk pengembangan sistem yang baru lebih sedikit kurang lebih 3 bulan

Pihak IT belum terbiasa menggunakan SQL server, jadi waktu pembelajaran yang diperlukan untuk pengembangan sistem yang baru lebih banyak dibandingkan kandidat satu, kurang lebih 4

14 1

bulan Skor: 100 Ranking 94 Skor: 80

bulan Skor: 90

100%

80

69

15 1

Physical Data Flow Diagram

I. Logical Data Flow Diagram
DFD Level 0
Di sub bab ini akan dijelaskan mengenai aliran data pada proses-proses yang ada di setiap subsistem.

Gambar 3. DFD Level 0

Berikut ini akan dijelaskan DFD Level 0 yang telah digambarkan sebelumnya:
Tabel 3. Penjelasan DFD Level 0

External Factors

Input ke sistem

Output dari Sistem

Petugas Penerimaan Awal Pasien

Memasukkan/Menghapus informasi pasien yang terdiri dari biodata dan Medical Report Validasi pasien yang ingin

Sistem akan mengeluarkan validitas pasien yang terdaftar atau tidak

16 1

datang berobat, untuk mengetahui apakah pasien tersebut sudah terdaftar atau belum Mengirim Informasi Pasien kepada dokter sesuai urutan kedatangan pasien Dokter - Update informasi pasien berdasarkan keluhan penyakit - Menerima Informasi Pasien sesuai urutan - Informasi pasien yang sedang dilayani

Petugas Penerimaan Awal Pasien menjadi sumber input ke sistem berupa biodata dan medical report. Input ini akan diolah sistem sehingga menghasilkan infromasi pasien, dan validasi yang akan dikembalikan ke Petugas Penerimaan Awal Pasien. Apabila petugas penerimaan awal pasien menyetujui, maka proses pelayanan pasien akan dilanjutkan dengan mengirimkan informasi pasien kepada dokter. Setelah pemeriksaan pasien selesai, dan informasi pasien ditampilkan, maka Dokter akan meupdate medical record, yang akan dilihat apoteker melalui sistem.

DFD Level l

17 1

Gambar 4. DFD Level 1

Tabel 4. Penjelasan DFD Level 1

Proses Cek Validitas Data Pasien Lama

Input Data Pasien Lama yang dimasukan ke dalam sistem oleh Petugas Pendaftaran Pasien.

Proses Data Pasien Baru

Update Data Pasien yang Dirawat

Output Data Pasien Lama yang akan dirawat akan diserahkan ke Dokter (apabila pasien tersebut valid). Data Pasien yang Baru - Data Pasien Baru akan Mendaftar yang dimasukan dimasukan ke ke dalam sistem oleh database. Petugas Pendaftaran - Data Pasien Baru yang Pasien. akan dirawat juga diserahkan ke Dokter. Data Baru dari Pasien yang - Data Pasien yang dirawat oleh Dokter. Sudah di-update akan dimasukan ke database.

Level DFD hanya sampai level 1, karena prosesnya tidak dapat dipecah kembali menjadi lebih kompleks.

II. Physical Data Flow Diagram

18 1

Setelah melalui proses pemodelan proses pada tahapan logical design, maka sekarang akan dilakukan desain Physical Data Flow Diagram yang merupakan salah satu task pada tahapan Physical Design..

Gambar 4. Physical DFD

Penjelasan proses-proses pada Physical Data Flow Diagram di atas: 1. Cek Validitas Pasien Lama. Tujuan: Memeriksa validitas data pasien lama sehingga dapat dicari catatan kesehatan pasien tersebut. Input: Data Pasien Lama dari Kartu Anggota pasien terkait. Data Pasien yang ada di database.

Output: Bagi pasien yang valid (terdaftar), data pasien tersebut akan diserahkan ke dokter, dalam bentuk halaman HTML, agar pasien tersebut dapat menerima pelayanan medis.

19 1

2. Proses Data Pasien Baru. Tujuan: Menambah data pasien baru yang belum terdaftar. Input: Form HTML yang berisi data pasien terkait. Data tersebut dimasukan oleh Petugas Pendaftaran Pasien. Output: Data pasien yang baru tersebut akan diserahkan ke dokter, dalam bentuk halaman HTML, agar pasien tersebut dapat menerima pelayanan medis. 3. Update Data Pasien yang Dirawat. Tujuan: Memperbaharui data pasien-pasien yang sudah menerima perawatan, terutama mengenai data kesehatan mereka. Input: Form HTML yang berisi data pasien terbaru yang akan diperbaharui. Data tersebut dimasukan oleh Dokter. Output: Data Pasien yang sudah diperbaharui akan dimasukan ke dalam database.

Database Schema
I. Logical ER Diagram
Berikut ini adalah Entity Relationship Diagram (ER-Diagram) dari sistem PKM UI
20 1

Gambar 5. ER Diagram

II. Physical ER Diagram

Berikut ini adalah gambar physical diagram sistem informasi pelayanan kesehatan

21 1

Gambar 6. Physical Pemetaan ERD

Pemetaan ER Diagram
Berdasarkan ERD, kami membuat pemetaan serta melakukan normalisasi sebagai berikut: Pasien id_pasie n nama_pasie alamat_pasi n en gol_dara h tingg bera i t Tgl_hsl_rontgen_a wal

Mahasiswa NPM kampus fakultas id_pasien

Karyawan UI no_kui tmp_kerja id_pasien

22 1

Umum KTP id_pasien

Medical Record id_med_rec tgl_berobat nama_penyakit terapi Tgl_hasil_lab id_pasien tgl_hsl_rontgen_baru

Normalisasi ER Diagram
Pasien id_pasie n nama_pasie alamat_pasi n en gol_dara h tingg bera i t Tgl_hsl_rontgen_a wal

Mahasiswa NPM kampus fakultas id_pasien

Karyawan UI no_kui tmp_kerja id_pasien

Umum KTP id_pasien

Medical Record id_med_rec tgl_berobat nama_penyakit terapi tgl_hsl_rontgen_baru

Tgl_hasil_lab id_pasien

23 1

Pada Tabel pasien kolom alamat hanya dicatat satu entry saja sehingga tidak terdapat multiple value. Dengan begitu maka tiap tabel sudah mengalami normalisasi 1NF.

Karena tidak ada relasi dengan primary key yang memiliki atribut non key setiap tabel maka dianggap semua tabel sudah normal sampai 3NF. Dengan kata lain tabel yang telah dipetakan telah memenuhi syarat normalisasi atau telah normal.

Penjelasan Mapping ERD: Tabel Pasien Tabel ini digunakan untuk menyimpan semua data yang terkait dengan pasien. Data-data terkait yang akan disimpan dalam tabel pasien adalah: id_pasien id_pasien merupakan suatu nomor yang unik.. Tipe dari id_pasien adalah karakter dengan panjang data 10. nama_pasien nama_pasien merupakan informasi nama pasien. Tipe dari

nama_pasien adalah varchar dengan panjang data maksimum 20. alamat_pasien alamat_pasien merupakan alamat pasien yang bersangkutan. Tipe dari alamat pasien adalah varchar dengan panjang data maksimum 254. gol_darah gol_darah merupakan keterangan golongan darah pasien. gol_darah bertipe karakter dengan panjang data 4 karakter. tinggi Tinggi merupakan informasi tinggi dari pasien. Tipe dari tinggi adalah integer. berat berat merupakan informasi berat dari pasien. Tipe dari berat adalah integer. tgl_hsl_roentgen_awal Merupakan tanggal dari hasil roentgen pada awal pemeriksaan. Adapun tipe dari tgl_hsl_roentgen_awal adalah date.

24 1

Tabel Mahasiswa Tabel ini digunakan untuk menyimpan keterangan mahasiswa. Data-data terkait yang akan disimpan dalam tabel mahasiswa adalah: NPM NPM merupakan nomor yang unik.. Tipe dari NPM adalah karakter dengan panjang data 10. kampus kampus adalah tempat mahasiswa berada dalam hal ini bisa bernilai depok atau salemba. Kampus bertipe varchar dengan panjang data 20. fakultas Fakulatas adalah tempat mahasiswa menjalani perkuliahan. Fakultas bertipe varchar dengan panjang data 20. id_pasien Id_pasien merupakan suatu nomor yang unik. Tipe data dari id_pasien adalah karakter dengan panjang data 10. Karyawan_UI Tabel ini digunakan untuk menyimpan semua data yang terkait dengan karyawan ui. Data-data terkait dengan karyawan ui adalah: no_kui no_kui yaitu nomor karyawan uid dengan tipe data karakter dengan maksimal data 10. tmp_kerja tmp_kerja ini berisi informasi tempat karyawan ui bekerja. Tmp_kerja ini memiliki tipe data karakter dengan maksimal data 20. id_pasien Id_pasien merupakan suatu nomor yang unik. Tipe data dari id_pasien adalah karakter dengan panjang data 10.

Tabel umum Tabel ini digunakan untuk menyimpan keterangan pasien yang berasal umum atau masyarakat sekitar. Data-data terkait yang akan disimpan dalam tabel umum ini adalah: KTP

25 1

KTP merupakan nomor nomor ktp yang unik. Tipe dari ktp adalah karakter dengan panjang data 10. id_pasien Id_pasien merupakan suatu nomor yang unik. Tipe data dari id_pasien adalah karakter dengan panjang data 10.

Tabel Medical_Record Tabel ini digunakan untuk menyimpan keterangan Medical_Record dari pasien,. Data-data terkait yang akan disimpan dalam tabel medical_record adalah: id_med_rec id_med_rec merupakan nomor atau id medical record yang unik. Tipe dari id_med_rec adalah karakter dengan panjang data 10. tgl_berobat tgl_berobat merupakan data tanggal pada saat pasien berobat. Tgl_berobat ini tipenya adalah date. nama_penyakit nama_penyakit ini memberikan informasi tentang penyakit yang dialami atau diderita pasien. Tipe data dari nama_penyakit adalah varchar dengan panjang data 20 terapi terapi ini berisi informasi temtang terapi pasien. Adapun tipe datanya yaitu varchar dengan panjang data 20. tgl_hsl_rontgen_baru tgl_hsl_rontgen_baru ini berisi informasi waktu hasil rontgen terbaru. Tipe datanya date tgl_hasil_lab Menginformasikan tanggal hasil periksa laboratorium terakhir. Tipe datanya date. id_pasien id_pasien merupakan suatu nomor yang unik. Tipe data dari id_pasien adalah karakter dengan panjang data 10.

26 1

Desain Input, Output, dan Interface

Setelah tahapan pembuatan desain basis data dan desain physical DFD, maka akan dibuat spesifikasi input, output dan alur dialog pada Sistem Informasi Pelayanan Kesehatan PKM UI ini. Desain input meliputi desain interface untuk memasukkan data atau meng-update data yang telah ada di dalam sistem, sedangkan desain output meliputi desain untuk report yang ditampilkan melalui layar monitor pengguna. Alur dialog yang berupa alur interface yang akan dilalui oleh pengguna di dalam menggunakan sistem.

I. Alur Interface
Alur interface untuk Petugas Pendaftaran Pasien

Gambar 7.Dialogue Chart untuk Petugas Pendaftaran Pasien

27 1

Alur interface untuk Dokter

Gambar 8.Dialogue Chart interface untuk Dokter

II. Desain Interface

Desain dan Prototipe Output Sistem
Berdasarkan hasil tahapan analisa kebutuhan, physical data flow diagram dan desain basis data, terdapat tiga jenis output yang diperlukan di dalam Sistem Informasi Pelayanan Kesehatan. Output yang diperlukan adalah sebagai berikut: 1. Output Daftar Antrian Pasien Output Daftar Antrian Pasien dapat dilihat oleh user, yang dalam hal ini petugas penerima pasien atau dokter yang bertugas. Output ini diperlukan untuk mengetahui banyaknya antrian sekaligus urutan pemeriksaan pasien yang ada pada saat itu. Pada output ini terdapat suatu link yang menuju ke tampilan output berikutnya, yaitu output medical check up dan biodata lengkap pasien 2. Output Data Anggota Untuk dapat memeriksakan diri ke PKM, seseorang haruslah menjadi anggota terlebih dahulu sehingga user, yang dalam ini petugas PKM memerlukan suatu daftar berisikan semua anggotanya untuk mempermudah pengelolaan. Oleh karena

28 1

itu Sistem Informasi Pelayanan Kesehatan ini menghasilkan output Daftar Anggota. Pada daftar ini dapat diketahui lebih lanjut mengenai biodata lengkap dari anggota-anggota PKM UI. 3. Output Medical Check - Up PKM UI adalah suatu lembaga yang mengurusi kesehatan anggotanya, untuk itu diperlukan suatu output yang berisikan tentang data-data kesehatan seluruh anggotanya. Output ini dapat dilihat baik oleh petugas PKM UI ataupun dokter yang sedang bertugas. Output ini berguna bagi dokter untuk menentukan langkahlangkah pengobatan ataupun untuk mengetahui perkembangan kesehatan pasien.

Physical Output Design

Physical output design digunakan untuk menampilkan ketiga output utama yaitu:    Output Daftar Antrian Pasien Output Daftar Anggota Output Medical Check - Up

Karena Sistem Informasi Pelayanan Kesehatan ini berbasiskan Web, maka untuk menampilkannya diperlukan suatu browser dan dapat dijalankan baik dengan komputer dengan sistem operasi windows maupun komputer dengan sistem operasi linux. Dalam tampilannya output yang berupa daftar akan ditampilkan dalam bentuk tabel. Frekuensi penggunaan dari output diatas tidak terbatas dan dapat dilakukan kapan saja.

29 1

Output Daftar Antrian

Gambar 9. Output Daftar Antrian Psien

Output daftar antrian ini merupakan suatu list pasien yang ada pada saat itu. Pada output ini terdapat link menuju ke output medical Check-Up dari masing-masing pasien dan link menuju output data lengkap pasien. Di bagian ini juga terdapat link untuk menuju ke fitur fitur lain, yang dalam hal ini adalah fitur daftar anggota dan fitur tambah anggota.

30 1

Output Data Anggota Output Data Anggota ini terdiri dari dua, yaitu : 1. Daftar Anggota

Gambar 10. Output Daftar Anggota

Output ini merupakan daftar semua anggota yang terdaftar di PKM UI. Pada output ini terdapat link menuju output detail data tiap-tiap anggota dan output medical checkupnya

Di bagian ini juga terdapat link untuk menuju ke fitur fitur lain, yang dalam hal ini adalah fitur daftar pasien dan fitur tambah anggota.

31 1

2. Data lengkap Anggota

Gambar 11. Output Data Lengkap Anggota

Output ini merupakan keterangan lengkap dari semua anggota yang terdaftar di PKM UI. Di bagian ini juga terdapat link untuk menuju ke fitur fitur lain, yang dalam hal ini adalah fitur daftar anggota, daftar pasien dan fitur tambah anggota.

32 1

Output Medical Check-Up

Gambar 12. Output Medical Check-Up

Output ini merupakan keterangan lengkap perkembangan kesehatan dari semua anggota yang terdaftar di PKM UI. Di bagian ini juga terdapat link untuk menuju ke fitur fitur lain, yang dalam hal ini adalah fitur daftar anggota, daftar pasien dan fitur tambah anggota.

Desain dan Prototipe Input Sistem

Desain Input dalam Sistem Informasi Pelayanan Kesehatan Mahasiswa meliputi 3 bagian yaitu: 1. Input Tambah Antrian Bagian ini untuk melakukan pencatatan terhadap setiap anggota yang ingin memeriksakan diri. Daftar ini dilakukan oleh petugas PKM yang bertugas menerima pasien. 2. Input Tambah Anggota/Pasien

33 1

Bagian ini untuk memasukkan data anggota-anggota baru, Input ini dilakukan oleh petugas PKM UI. Pada bagian ini pula data-data mengenai semua anggota dapat dihapus atau diubah. 3. Input Medical Check-Up Input Medical Check-Up ini dibuat untuk memasukkan data-data kesehatan semua anggota-anggota PKM UI. Hanya dokter pemeriksa yang berhak memasukkan Input ke Medical Check-Up ini

34 1

Physical Input Design

Physical Input design digunakan untuk memberikan Input ke dalam database sehingga nantinya dapat ditampilkan melalui ketiga output utama yang telah

dijelaskan sebelumnya. Karena Sistem Informasi Pelayanan Kesehatan ini berbasiskan Web, maka untuk menampilkannya diperlukan suatu browser dan dapat dijalankan baik dengan komputer dengan sistem operasi windows maupun linux. Dalam memasukkan datanya dilakukan dengan bantuan keyboard sedangkan untuk berpindah halaman dapat digunakan mouse. Adapun masing masing interface Input designnya adalah sebagai berikut : 1. Daftar Antrian Pasien Daftar Antrian Pasien dapat dilakukan oleh dua user yaitu petugas penerima pasien dan doker pemeriksa. Petugas penerima pasien hanya boleh melakukan penambahan pasien, sedangkan dokter pemeriksa hanya boleh melakukan penghapusan data pasien yang telah diperiksa

Pada antrian pasien, Inputnya menjadi satu dengan tampilan output. Interfacenya dapat dilihat sebagai berikut pada gambar berikut :

Gambar 13. Input Daftar Antrian Pasien

35 1

Dalam memasukkan Input pasien maka petugas penerima pasien hanya perlu memasukkan nomor anggota yang ingin memeriksakan diri. Data-data lain mengenai pasien itu akan diambil dari database dengan menggunakan nomor anggota yang telah dimasukkan. Hal ini dapat dilakukan karena nomor anggota berfungsi sebagai primary key didalam database. Input yang dilakukan dokter adalah hanya melakukan proses penghapusan daftar pasien yang telah selesai diperiksa. Dokter pemeriksa hanya perlu menekan tombol delete yang terdapat pada daftar. Adapun interfacenya adalah sebagai berikut :

Gambar 14. Input Daftar Anggota

Input suatu anggota dapat dilakukan apabila terdapat anggota baru yang mendaftar, penghapusan anggota ataupun mengadakan perubahan data pada seorang anggota. Oleh karena itu interfacenya juga dibagi menjadi dua: 1. Interface untuk penambahan anggota baru

36 1

Penambahan anggota baru dilakukan biasanya pada saat penerimaan mahasiswa baru. Petugas pendata diharuskan mengisi field-field yang tersedia pada Input, Input ini nantinya akan dimasukkan ke dalam database dan kemudian akan ditampilkan melalui interface output.

Gambar 15. Input Tambah Anggota Baru

37 1

2. Input ubah dan hapus anggota Untuk menghapus atau mengubah suatu data seorang petugas diharuskan melihat data anggota yang akan dihapus atau diubah datanya. Hal ini untuk mengurangi kesalahan penghapusan. Adapun interfacenya adalah sebagai berikut :

Gambar 16. Input hapus dan ubah data

Untuk menghapus data user hanya perlu menekan tombol hapus, sedangkan untuk mengubah data, setelah menekan tombol edit, user diharuskan mengisi field-field yang akan diubah. Adapun bentuk interfacenya sama dengan waktu pengisian data baru.

38 1

Input Medical Check-Up Input Medical Check-Up hanya dapat diisi oleh dokter pemeriksa. Data-data yang dimasukkan didasarkan pada hasil pemeriksaannya terhadap pasien. Data -data yang dimasukkan nantinya akan dimasukkan ke dalam database dan kemudian ditampilkan pada interface output Medical Check-Up.

Gambar 17. Input Medical Check-Up

39 1