Anda di halaman 1dari 39

PUSAT KESEHATAN MAHASISWA

Universitas Indonesia

Tugas

3

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

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

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

6 1 . pada dokumen ini strategi desain yang diambil adalah strategi FAST System Design untuk In-House Development dengan tahapan-tahapan task. maka strategi yang sederhana dan cukup singkat akan memudahkan penyusunan dokumen. II. Pengerjaan desain sistem dapat dilakukan dengan berbagai strategi dan teknik.update Project Plan Pemilihan strategi FAST System Design untuk In-House Development lebih disebabkan oleh kemudahan dalam pengerjaan rancangan physical design. Tujuan Dokumen Tujuan dari dokumen ini adalah untuk mempresentasikan hasil dari desain-desain yangtelah dilakukan. karena waktu yang ditersedia untuk tahapan system design yang sedikit. seperti desain arsitektur aplikasi dengan physical DFD yang menjelaskan alur proses dari sistem informasi Pelayanan Kesehatan di PKM UI. 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. maka tahap konstruksi sistem baru dapat dimulai. Meng. serta desain interface yang mengatur interaksi dengan pengguna. 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. Package Design Specification 5. Mendesain Database sistem 3.Pendahuluan I. Mendesain Interface sistem 4. Mendesain Arsitektur Aplikasi 2. atau desain database schema yang bertujuan menggambarkan desain dari data-data yang akan digunakan dalam sistem. Selain itu dengan dokumen system design yang telah disetujui. sebagai berikut: 1. Penjabaran tersebut berupa physical design dari logical design yang telah dibuat.

database schema. dan alur kerja di bidang pelayanan medik. Akhirnya pembahasan mulai memasuki tahapan desain dengan diawali dengan physical DFD. input dan output. Struktur Dokumen Dalam dokumen ini dibahas desain physical DFD. dengan disertai alur interface pada sistem. sistem lama PKM UI. yang didahului oleh logical ERD. 7 1 . dilanjutkan dengan ringkasan latar belakang proyek. dan diakhiri dengan desain interface. pembahasan berlanjut ke database schema. yang sebelumnya diberikan cuplikan dari logical DFD dari dokumen sebelumnya. yangmencakup profil PKM UI. dan pembahasan ditutup dengan desain interface.III. input. Pembahasan dalam dokumen ini dimulai dengan penjelasan singkat tentang isi dan tujuan dokumen. dan output.

Saat ini PKM UI telah memiliki dua buah klinik yang terdapat di kampus UI Depok dan kampus UI Salemba. Mendampingi kegiatan-kegiatan kemahasiswaan yang membutuhkan pengawasan medik. Menjadikan pusat rujukan medik bagi mahasiswa UI 5. PKM bertugas untuk melayani masalah kesehatan mahasiswa dan memberikan pelayanan untuk masyarakat UI pada umumnya. honorer dan pegawai magang. Melaksanakan tidakan promotif. Melaksanakan kegiatan-kegiatan yang dapat menunjang kesejahteraan fisik dan psikologis mahasiswa UI. prventif. 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. 4. Misi PKM UI adalah sebagai berikut: 1. PKM UI memiliki sekitar 28 orang pegawai. kuratif dan rehabilitatif medik pada mahasiswa Universitas Indonesia. 3. yang terdiri dari pegawai tetap. Menjadikan PKM UI sebagai tempat magang bagi mahasiswa UI yang membutuhkan. Profil PKM Pusat Kesehatan Mahasiswa (PKM) Universitas Indonesia (UI) adalah saah satu unit pelayanan mahasiswa yang berada dibawah Rektorat UI. 7. 2. Menyelenggarakan kegiatan pengabdian kepada masyarakat di lingkungan UI 8 1 . 6.Ringkasan I. Melaksanakan konsultasi psikologis bagi mahasiswa UI yang membutuhkan.

Struktur Organisasi PKM UI Gambar 2.Struktur Organisasi PKM UI Gambar 1. 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 . 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.

pasien diarahkan ke apotek/lab/rekam medis/rujuk/pulang sesuai dengan keputusan dokter yang merawat Prosedur Pelayanan Medis Umum. bila menolak harus mengisi surat penolakan. 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 y 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. Gambaran Sistem Lama Rencana Pengembangan PKM UI 10 1 . sedangkan bagi non peserta data dimasukkan ke status khusus y Jika data pasien belum tercantum di sistem komputer/ sistem sedang tidak aktif. kecuali gawat darurat y Setelah pemeriksaan dan tindakan oleh dokter. II. data pasien dimasukkan ke dalam status sementara y Setiap pasien diarahkan ke ruang periksa yang sesuai dan diminta untuk menunggu panggilan menurut urutan pendaftaran. pasien dan keluarga diberi penjelasan dan diminta mengisi informasi .y Data setiap pasien dimasukkan ke dalam komputer.

didapatkan kandidat terbaik yang akan menjadi dasar pengerjaan desain sist m pada e pengembangan Sistem Informasi Pelayanan Kesehatan pada PKM UI. Rekomendasi Berdasarkan dokumen System Proposal yang telah terlebih dahulu dikerjakan.0 dan MySQL serta spesifikasi hardware seperti terlihat dalam matriks sistem kandidat berikut: 11 1 . selama ini data yang ada diletakkan dalam dokumen-dokumen kertas dan file-file yang tersebar dalam komputer di bagian administrasi PKM UI. Di lain pihak dalam menghadapi tantangan kedepan yang membawa UI menuju BHMN (Badan Hukum Milik Negara). Kandidat terbaik yang diperoleh dengan menggunakan matriks feasibility adalah kombinasi PHP 4. Sistem Lama PKM UI PKM UI belum memiliki sistem informasi untuk kegiatan pelayanannya.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. dengan tujuan meningkatkan pelayanan. Sehingga dalam 2-3 tahun kedepan PKM UI mampu memiliki sistem informasi yang sesuai dengan spesifikasi PKM UI. 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. Untuk itu dalam program PKM UI kedepan telah dirumuskan rencana untuk melakukan program komputerisasi kegiatan pelayanan di PKM UI. PKM UI harus melakukan efisiensi sumber daya besar-besaran. III. Sistem lama yang dimaksud dalam dokumen ini adalah sistem manual yang dilakukan PKM UI dalam kegiatan sehari hari. Jadi dapat disimpulkan bahwa PKM UI telah memiliki rencana besar untuk pengembangan sistem informasi yang sesuai dengan karakteristik PKM UI. profesionalisme dan efisiensi biaya.

0 untuk web-application dan MySQL sebagai DBMS Microsoft ASP. Matriks Sistem Kandidat Karakteristik Kandidat 1 Kandidat 2 Kandidat 3 Software yang digunakan untuk pengembangan sistem PHP 4. 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 . bahasa pemrograman yang dipakai. dll Hardware yang digunakan dalam sistem Hardware-hardware yang akan dipakai sistem.NET dan kesesuaian dengan Windows OS Sama seperti kandidat 1 Keyboard dan mouse Cara input yang dipakai untuk memasukan data.Tabel 1. Sama seperti Sama seperti 12 1 .NET untuk web application dan Microsoft Access sebagai DBMS Microsoft ASP untuk webapplication dan Microsoft SQL Server 2000 sebagai DBMS Software-software seperti DBMS. 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.

kecepatannya Bagian yang terkomputerisasi Pemilihan bagian yang akhirnya dikomputerisasi oleh pengembangan sistem Teknologi pemrosesan data Data Kesehatan Pasien. kapasitas hardisk yang diperlukan.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 .menyimpan data 7200 RPM kandidat 1 kandidat 1 Cara penyimpanan data ke perangkat keras (harddisk). 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.

Skor: 50 MySQL sudah dikenal sebagai DBMS yang cukup handal dengan karakteristik response time yang cepat. Microsoft ASP: $850 US Microsoft SQL Server: $19.4 dan MySQL dirasakan cukup economic feasible mengingat keduanya didistribusikan secara freeware.0 dikenal sebagai DBMS yang handal tetapi memiliki keterbatasan response time yang kurang cepat bila dibandingkan MySQL.0 dan MySQL dirasakan cukup economic feasible mengingat keduanya didistribusikan secara freeware. jadi waktu pembelajaran yang diperlukan untuk pengembangan sistem yang baru lebih sedikit kurang lebih 3 bulan Pihak IT belum terbiasa menggunakan SQL server. Skor: 90 Microsoft SQL Server 7. jadi waktu pembelajaran yang diperlukan untuk pengembangan sistem yang baru lebih banyak dibandingkan kandidat satu. Skor: 90 Kombinasi Java Sun JDK1. kurang lebih 4 14 1 . Skor : 70 Kombinasi Microsoft ASP dan Microsoft SQL Server kurang feasible. 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.Skor: 90 Technical feasibilty 30% MySQL sudah dikenal sebagai DBMS yang cukup handal dengan karakteristik response time yang cepat.999 US Skor: 40 Skor : 90 Economic feasibility 30% Kombinasi PHP 4.

bulan Skor: 100 Ranking 94 Skor: 80 bulan Skor: 90 100% 80 69 15 1 .

Physical Data Flow Diagram I. 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 . 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.

Menerima Informasi Pasien sesuai urutan . dan validasi yang akan dikembalikan ke Petugas Penerimaan Awal Pasien. Setelah pemeriksaan pasien selesai. DFD Level l 17 1 . Input ini akan diolah sistem sehingga menghasilkan infromasi pasien. yang akan dilihat apoteker melalui sistem. maka Dokter akan meupdate medical record. Apabila petugas penerimaan awal pasien menyetujui. untuk mengetahui apakah pasien tersebut sudah terdaftar atau belum Mengirim Informasi Pasien kepada dokter sesuai urutan kedatangan pasien Dokter . maka proses pelayanan pasien akan dilanjutkan dengan mengirimkan informasi pasien kepada dokter. dan informasi pasien ditampilkan.datang berobat.Update informasi pasien berdasarkan keluhan penyakit .Informasi pasien yang sedang dilayani Petugas Penerimaan Awal Pasien menjadi sumber input ke sistem berupa biodata dan medical report.

II. Level DFD hanya sampai level 1. Data Baru dari Pasien yang . Proses Data Pasien Baru Update Data Pasien yang Dirawat Output Data Pasien Lama yang akan dirawat akan diserahkan ke Dokter (apabila pasien tersebut valid). Sudah di-update akan dimasukan ke database. karena prosesnya tidak dapat dipecah kembali menjadi lebih kompleks. Petugas Pendaftaran . Physical Data Flow Diagram 18 1 .Data Pasien Baru yang Pasien. DFD Level 1 Tabel 4.Data Pasien yang dirawat oleh Dokter.1 2 3 Gambar 4. Data Pasien yang Baru . Penjelasan DFD Level 1 Proses Cek Validitas Data Pasien Lama Input Data Pasien Lama yang dimasukan ke dalam sistem oleh Petugas Pendaftaran Pasien.Data Pasien Baru akan Mendaftar yang dimasukan dimasukan ke ke dalam sistem oleh database. akan dirawat juga diserahkan ke Dokter.

Data Pasien yang ada di database. 19 1 . maka sekarang akan dilakukan desain Physical Data Flow Diagram yang merupakan salah satu task pada tahapan Physical Design. Output: Bagi pasien yang valid (terdaftar). Cek Validitas Pasien Lama. Physical DFD Penjelasan proses-proses pada Physical Data Flow Diagram di atas: 1.. Tujuan: Memeriksa validitas data pasien lama sehingga dapat dicari catatan kesehatan pasien tersebut. agar pasien tersebut dapat menerima pelayanan medis. Input: Data Pasien Lama dari Kartu Anggota pasien terkait. data pasien tersebut akan diserahkan ke dokter. Gambar 4. dalam bentuk halaman HTML.Setelah melalui proses pemodelan proses pada tahapan logical design.

Output: Data Pasien yang sudah diperbaharui akan dimasukan ke dalam database. dalam bentuk halaman HTML. Output: Data pasien yang baru tersebut akan diserahkan ke dokter. Database Schema I. Input: Form HTML yang berisi data pasien terbaru yang akan diperbaharui. Tujuan: Memperbaharui data pasien-pasien yang sudah menerima perawatan. Data tersebut dimasukan oleh Dokter. Update Data Pasien yang Dirawat. Proses Data Pasien Baru. Tujuan: Menambah data pasien baru yang belum terdaftar.2. 3. Data tersebut dimasukan oleh Petugas Pendaftaran Pasien. agar pasien tersebut dapat menerima pelayanan medis. terutama mengenai data kesehatan mereka. Logical ER Diagram Berikut ini adalah Entity Relationship Diagram (ER-Diagram) dari sistem PKM UI 20 1 . Input: Form HTML yang berisi data pasien terkait.

Physical ER Diagram Berikut ini adalah gambar physical diagram sistem informasi pelayanan kesehatan 21 1 .Gambar 5. ER Diagram II.

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 .Gambar 6.

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 .

berat berat merupakan informasi berat dari pasien. alamat_pasien alamat_pasien merupakan alamat pasien yang bersangkutan. nama_pasien nama_pasien merupakan informasi nama pasien. tinggi Tinggi merupakan informasi tinggi dari pasien. Tipe dari id_pasien adalah karakter dengan panjang data 10.. tgl_hsl_roentgen_awal Merupakan tanggal dari hasil roentgen pada awal pemeriksaan. Dengan kata lain tabel yang telah dipetakan telah memenuhi syarat normalisasi atau telah normal. Tipe dari tinggi adalah integer. Karena tidak ada relasi dengan primary key yang memiliki atribut non key setiap tabel maka dianggap semua tabel sudah normal sampai 3NF. Dengan begitu maka tiap tabel sudah mengalami normalisasi 1NF. gol_darah gol_darah merupakan keterangan golongan darah pasien.Pada Tabel pasien kolom alamat hanya dicatat satu entry saja sehingga tidak terdapat multiple value. gol_darah bertipe karakter dengan panjang data 4 karakter. 24 1 . 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 alamat pasien adalah varchar dengan panjang data maksimum 254. Tipe dari nama_pasien adalah varchar dengan panjang data maksimum 20. Adapun tipe dari tgl_hsl_roentgen_awal adalah date. Tipe dari berat adalah integer.

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

Adapun tipe datanya yaitu varchar dengan panjang data 20. Tipe datanya date. id_pasien id_pasien merupakan suatu nomor yang unik. Tipe dari id_med_rec adalah karakter dengan panjang data 10. tgl_hsl_rontgen_baru tgl_hsl_rontgen_baru ini berisi informasi waktu hasil rontgen terbaru. id_pasien Id_pasien merupakan suatu nomor yang unik.. nama_penyakit nama_penyakit ini memberikan informasi tentang penyakit yang dialami atau diderita pasien. Tipe datanya date tgl_hasil_lab Menginformasikan tanggal hasil periksa laboratorium terakhir. 26 1 . Tabel Medical_Record Tabel ini digunakan untuk menyimpan keterangan Medical_Record dari pasien. tgl_berobat tgl_berobat merupakan data tanggal pada saat pasien berobat.KTP merupakan nomor nomor ktp yang unik. Tgl_berobat ini tipenya adalah date. Tipe data dari id_pasien adalah karakter dengan panjang data 10. Tipe dari ktp adalah karakter dengan panjang data 10. Tipe data dari id_pasien adalah karakter dengan panjang data 10. Tipe data dari nama_penyakit adalah varchar dengan panjang data 20 terapi terapi ini berisi informasi temtang terapi 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.

Alur dialog yang berupa alur interface yang akan dilalui oleh pengguna di dalam menggunakan sistem. I. maka akan dibuat spesifikasi input. Output. Alur Interface Alur interface untuk Petugas Pendaftaran Pasien Gambar 7. 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. output dan alur dialog pada Sistem Informasi Pelayanan Kesehatan PKM UI ini.Dialogue Chart untuk Petugas Pendaftaran Pasien 27 1 .Desain Input. dan Interface Setelah tahapan pembuatan desain basis data dan desain physical DFD.

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

untuk itu diperlukan suatu output yang berisikan tentang data-data kesehatan seluruh anggotanya.itu Sistem Informasi Pelayanan Kesehatan ini menghasilkan output Daftar Anggota. Output ini berguna bagi dokter untuk menentukan langkahlangkah pengobatan ataupun untuk mengetahui perkembangan kesehatan pasien. Output Medical Check . 3.Up PKM UI adalah suatu lembaga yang mengurusi kesehatan anggotanya. Output ini dapat dilihat baik oleh petugas PKM UI ataupun dokter yang sedang bertugas. maka untuk menampilkannya diperlukan suatu browser dan dapat dijalankan baik dengan komputer dengan sistem operasi windows maupun komputer dengan sistem operasi linux. 29 1 . Dalam tampilannya output yang berupa daftar akan ditampilkan dalam bentuk tabel. Frekuensi penggunaan dari output diatas tidak terbatas dan dapat dilakukan kapan saja.Up Karena Sistem Informasi Pelayanan Kesehatan ini berbasiskan Web. Pada daftar ini dapat diketahui lebih lanjut mengenai biodata lengkap dari anggota-anggota PKM UI. Physical Output Design Physical output design digunakan untuk menampilkan ketiga output utama yaitu:    Output Daftar Antrian Pasien Output Daftar Anggota Output Medical Check .

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

yang dalam hal ini adalah fitur daftar pasien dan fitur tambah anggota. Output Daftar Anggota Output ini merupakan daftar semua anggota yang terdaftar di PKM UI. 31 1 . Daftar Anggota Gambar 10. yaitu : 1. 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.Output Data Anggota Output Data Anggota ini terdiri dari dua.

yang dalam hal ini adalah fitur daftar anggota.2. Data lengkap Anggota Gambar 11. daftar pasien dan fitur tambah anggota. Di bagian ini juga terdapat link untuk menuju ke fitur ± fitur lain. 32 1 . Output Data Lengkap Anggota Output ini merupakan keterangan lengkap dari semua anggota yang terdaftar di PKM UI.

yang dalam hal ini adalah fitur daftar anggota. Output Medical Check-Up Output ini merupakan keterangan lengkap perkembangan kesehatan dari semua anggota yang terdaftar di PKM UI. 2.Output Medical Check-Up Gambar 12. Input Tambah Antrian Bagian ini untuk melakukan pencatatan terhadap setiap anggota yang ingin memeriksakan diri. daftar pasien dan fitur tambah anggota. Di bagian ini juga terdapat link untuk menuju ke fitur ± fitur lain. Daftar ini dilakukan oleh petugas PKM yang bertugas menerima pasien. Input Tambah Anggota/Pasien 33 1 . Desain dan Prototipe Input Sistem Desain Input dalam Sistem Informasi Pelayanan Kesehatan Mahasiswa meliputi 3 bagian yaitu: 1.

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

Inputnya menjadi satu dengan tampilan output.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. Daftar Antrian Pasien Daftar Antrian Pasien dapat dilakukan oleh dua user yaitu petugas penerima pasien dan doker pemeriksa. sedangkan dokter pemeriksa hanya boleh melakukan penghapusan data pasien yang telah diperiksa Pada antrian pasien. Interfacenya dapat dilihat sebagai berikut pada gambar berikut : Gambar 13. Adapun masing masing interface Input designnya adalah sebagai berikut : 1. maka untuk menampilkannya diperlukan suatu browser dan dapat dijalankan baik dengan komputer dengan sistem operasi windows maupun linux. Karena Sistem Informasi Pelayanan Kesehatan ini berbasiskan Web. Petugas penerima pasien hanya boleh melakukan penambahan pasien. Dalam memasukkan datanya dilakukan dengan bantuan keyboard sedangkan untuk berpindah halaman dapat digunakan mouse. Input Daftar Antrian Pasien 35 1 .

Adapun interfacenya adalah sebagai berikut : Gambar 14. Data-data lain mengenai pasien itu akan diambil dari database dengan menggunakan nomor anggota yang telah dimasukkan. Interface untuk penambahan anggota baru 36 1 . Oleh karena itu interfacenya juga dibagi menjadi dua: 1. Input yang dilakukan dokter adalah hanya melakukan proses penghapusan daftar pasien yang telah selesai diperiksa. Hal ini dapat dilakukan karena nomor anggota berfungsi sebagai primary key didalam database. Dokter pemeriksa hanya perlu menekan tombol ³delete´ yang terdapat pada daftar. Input Daftar Anggota Input suatu anggota dapat dilakukan apabila terdapat anggota baru yang mendaftar. penghapusan anggota ataupun mengadakan perubahan data pada seorang anggota.Dalam memasukkan Input pasien maka petugas penerima pasien hanya perlu memasukkan nomor anggota yang ingin memeriksakan diri.

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

Adapun interfacenya adalah sebagai berikut : Gambar 16. Hal ini untuk mengurangi kesalahan penghapusan.2. sedangkan untuk mengubah data. 38 1 . setelah menekan tombol ³edit´. user diharuskan mengisi field-field yang akan diubah. Input hapus dan ubah data Untuk menghapus data user hanya perlu menekan tombol hapus. Adapun bentuk interfacenya sama dengan waktu pengisian data baru. Input ubah dan hapus anggota Untuk menghapus atau mengubah suatu data seorang petugas diharuskan melihat data anggota yang akan dihapus atau diubah datanya.

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