contoh dfd.doc

87
PUSAT KESEHATAN MAHASISWA Universitas Indonesia Analisis dan Perancangan Sistem Sistem Informasi Pelayanan Kesehatan Mata Kuliah Rekayasa Perangkat Lunak Contoh Dokumen Pengembangan Perangkat Lunak Menggunakan Framework for the Application of Systems Thinking (FAST) Tahun 2004

Upload: auly-nahrudin

Post on 19-Jan-2016

64 views

Category:

Documents


1 download

DESCRIPTION

contoh DFD

TRANSCRIPT

Page 1: contoh DFD.DOC

PUSAT KESEHATAN MAHASISWA

Universitas Indonesia

A n a l i s i s d a n P e r a n c a n g a n S i s t e m

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

Mata Kuliah Rekayasa Perangkat LunakContoh Dokumen Pengembangan Perangkat Lunak Menggunakan Framework

for the Application of Systems Thinking (FAST)

Tahun 2004

Page 2: contoh DFD.DOC

ABSTRAK

Laporan akhir ini berisi penjelasan tiap tahapan-tahapan kerja dalam pengembangan

Sistem Informasi Pelayanan Kesehatan pada Pusat Kesehatan Mahasiswa Universitas

Indonesia. Metodologi yang digunakan dalam pengembangan adalah metode Framework

for the Application of Systems Thinking (FAST). Oleh karena itu, langkah-langkah

pengembangan yang dilakukan sesuai dengan tahapan yang terdapat dalam metode

FAST. Namun pengembangan yang dilakukan hanya meliputi beberapa tahapan, yaitu

dari tahap scope definition hingga tahap desain sistem.

Pada 3 proposal terdahulu telah dijelaskan beberapa tahapan pada FAST, yaitu dari tahap

scope definition sampai dengan tahap desain sistem. Laporan akhir ini akan menyusun

dan melakukan revisi terhadap ketiga laporan sebelumnya.

11

Page 3: contoh DFD.DOC

DAFTAR ISI

ABSTRAK_______________________________________________________1

DAFTAR ISI______________________________________________________2

DAFTAR GAMBAR________________________________________________5

DAFTAR TABEL__________________________________________________6

BAB I. PENDAHULUAN_________________________________________7

I.1. Latar Belakang____________________________________________________________7

I.2. Sistematika Penulisan_______________________________________________________7

BAB II. LATAR BELAKANG ORGANISASI_________________________10

II.1. Profil PKM_______________________________________________________________10

II.2. Visi dan Misi PKM UI______________________________________________________10

II.3. Struktur Organisasi PKM UI________________________________________________11

II.4. Standard Operating Procedure (SOP) PKM UI_________________________________11

BAB III. PROBLEM STATEMENT__________________________________13

III.1. PIECES Framework_____________________________________________________13

III.2. Hasil Analisa dengan PIECES Framework__________________________________13

BAB IV. PROJECT CHARTER____________________________________16

IV.1. Preliminary Findings and Analysis_________________________________________16IV.1.1. Deskripsi Proyek_________________________________________________________16IV.1.2. Project Environment______________________________________________________17IV.1.3. Preliminary Solutions and Ideas____________________________________________19

BAB V. ANALISA PERMASALAHAN______________________________21

V.1. Latar Belakang Informasi__________________________________________________21

V.2. Gambaran Sistem Lama____________________________________________________22

V.3. Analisa Sistem Lama_______________________________________________________22

12

Page 4: contoh DFD.DOC

V.4. Rekomendasi_____________________________________________________________24

BAB VI. ANALISA KEBUTUHAN__________________________________26

BAB VII. LOGICAL DESIGN_______________________________________29

VII.1. Pemodelan Data________________________________________________________29

VII.2. Pemodelan Alur Proses__________________________________________________30

VII.3. Database Schema_______________________________________________________34

VII.4. Desain dan Prototipe Output Sistem________________________________________38VII.4.1. Physical Output Design___________________________________________________39

VII.5. Desain dan Prototipe Input Sistem_________________________________________43VII.5.1. Physical Input Design_____________________________________________________44

Pemodelan User Interface_________________________________________________________50

BAB VIII. ANALISA KEPUTUSAN_________________________________52

BAB IX. DESAIN SISTEM________________________________________57

PENUTUP______________________________________________________60

IX.1. Kesimpulan____________________________________________________________60

IX.2. Saran_________________________________________________________________60

DAFTAR PUSTAKA______________________________________________61

LAMPIRAN_____________________________________________________62

1. Interview antara Tim dengan Wakil Kepala PKM UI________________________________62

13

Page 5: contoh DFD.DOC

14

Page 6: contoh DFD.DOC

DAFTAR GAMBAR

GAMBAR 1 STRUKTUR ORGANISASI PKM UI_____________________________11GAMBAR 2 STRUKTUR BIDANG PELAYANAN MEDIK_____________________11GAMBAR 3 ER DIAGRAM_______________________________________________29GAMBAR 4. DFD LEVEL 0_______________________________________________30GAMBAR 5 DFD LEVEL 2_______________________________________________31GAMBAR 9. OUTPUT DAFTAR ANTRIAN PASIEN____________________________39GAMBAR 10. OUTPUT DAFTAR ANGGOTA_______________________________41GAMBAR 11. OUTPUT DATA LENGKAP ANGGOTA________________________42GAMBAR 12. OUTPUT MEDICAL CHECK-UP_______________________________43GAMBAR 13. INPUT DAFTAR ANTRIAN PASIEN___________________________45GAMBAR 14. INPUT DAFTAR ANTRIAN__________________________________46GAMBAR 15. INPUT TAMBAH ANGGOTA BARU___________________________47GAMBAR 16. INPUT HAPUS DAN UBAH DATA____________________________48GAMBAR 17. INPUT MEDICAL CHECK-UP_________________________________49GAMBAR 6 DIAGRAM INTERFACE UNTUK PETUGAS PENDAFTARAN PASIEN

__________________________________________________________________50GAMBAR 7 DIAGRAM INTERFACE UNTUK DOKTER_______________________51Gambar 8. Physical DFD__________________________________________________57

15

Page 7: contoh DFD.DOC

DAFTAR TABEL

TABEL 1 MATRIKS CAUSE AND EFFECT ANALYSIS_______________________22TABEL 2 MATRIKS SYSTEM IMPROVEMENT OBJECTIVES_________________24TABEL 3 FUNCTIONAL REQUIREMENT___________________________________26TABEL 4 NONFUNCTIONAL REQUIREMENT_______________________________26TABEL 7 MATRIKS SISTEM KANDIDAT__________________________________53Tabel 8 Matriks feasibility_________________________________________________55

16

Page 8: contoh DFD.DOC

Bab I. Pendahuluan

I.1. Latar Belakang

Pusat Kesehatan Mahasiswa Universitas Indonesia (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 publik 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.

Sampai saat ini, PKM UI belum memiliki sistem informasi untuk kegiatan pelayanannya.

Biasanya data pasien yang ada diletakkan dalam dokumen-dokumen kertas dan file-file

yang tersebar dalam komputer di bagian administrasi PKM UI.

Berdasarkan paparan di atas, kami tertarik untuk menganalisa dan merancang suatu

sistem yang tepat untuk menunjang kegiatan pelayanan di PKM UI. Hasil analisa dan

perancangan sistem yang baru diharapkan dapat membantu PKM UI guna meningkatkan

mutu pelayanannya.

I.2. Sistematika Penulisan

Pada proposal ini kami menggunakan sistematika penulisan sebagai berikut :

17

Page 9: contoh DFD.DOC

BAB I PENDAHULUAN

Bab ini menjelaskan mengenai kondisi bisnis pengiriman barang saat ini, yang

menjadi alasan kami untuk melakukan proyek ini.

BAB II LATAR BELAKANG ORGANISASI

Bab ini menjelaskan mengenai perusahaan secara umum. Penjelasannya meliputi

profil, jasa yang ditawarkan, visi, misi, proses bisnis, struktur organisasi serta SOP.

BAB III PROBLEM STATEMENT

Bab ini menjelaskan mengenai framework PIECES yang kami gunakan untuk

menganalisa problems, opportunities serta directives yang dimiliki oleh perusahaan.

BAB IV PROJECT CHARTER

Bab ini menjelaskan secara detil mengenai proyek yang akan kami lakukan.

Penjelasannya meliputi tujuan proyek, gambaran proyek, tahapan pelaksanaan

proyek, visi proyek, batasan bisnis serta perencanaan sumber daya proyek.

BAB V ANALISA PERMASALAHAN

Bab ini berisi mengenai problem, opportunities, dan objective, yang dijumpai pada

pelaksanaan kegiatan operasional PKM UI berikut analisanya.

BAB VI ANALISA KEBUTUHAN

Bab ini berisi daftar kebutuhan yang harus dipenuhi sistem (functional requirement)

dan kebutuhan pendukung lain yang tidak harus untuk dipenuhi (non functional

requirements). Dalam menganalisa kebutuhan digunakan logical sistem models

sebagai representasi grafik dari kebutuhan sistem

BAB VII LOGICAL DESIGN

Bab ini memberikan gambaran desain sistem yang akan dibangun. Bentuknya

berupa sistem pemodelan dari kebutuhan bisnis yang telah dijelaskan dalam bagian

analisa kebutuhan. Pemodelan yang diberikan mencakup: Pemodelan data dengan

18

Page 10: contoh DFD.DOC

Entity Relationship Diagram, Pemodelan alur proses dengan data flow diagram,

dan Pemodelan user interface.

BAB VIII ANALISA KEPUTUSAN

Pada bab ini kami akan memaparkan dan membandingkan semua alternatif solusi

beserta karakteristik-karakteristik masing-masing. Dari hasil perbandingan akan

dipilih satu solusi sistem yang akan dikembangkan.

BAB IX DESAIN SISTEM

Pada bab ini kami akan membuat desain dari solusi sistem yang telah dipilih pada

bab sebelumnya. Desain sistem terdiri dari alur dialog antar muka, dan desain

arsitektur aplikasi.

BAB X PENUTUP

Pada bab ini kami akan menarik kesimpulan dari keseluruhan bab-bab diatas, dan

mengajukan saran kepada para pengguna maupun pihak yang ingin lebih lanjut

mengembangkan Sistem Informasi Pelayanan Kesehatan PKM UI.

19

Page 11: contoh DFD.DOC

Bab II. Latar Belakang Organisasi

II.1. 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.

II.2. 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

110

Page 12: contoh DFD.DOC

II.3. Struktur Organisasi PKM UI

Struktur dari PKM UI terbagi menjadi tiga bagian penting seperti terlihat dalam gambar1,

dan bagian keuangan langsung dipegang oleh Wakil Ketua PKM.

Gambar 1 Struktur Organisasi PKM UI

Bidang pelayanan medik dibagi lagi menjadi beberapa unit operasional yang akan

melayani langsung pasien yang mendaftar, unit tersbut sebagaimana dalam gambar 2

adalah emergensi, gigi, umum dan jantung.

Gambar 2 Struktur Bidang Pelayanan Medik

II.4. Standard Operating Procedure (SOP) PKM UI

Prosedur Penerimaan Pasien, sebagai berikut:

111

Page 13: contoh DFD.DOC

Penerimanaan pasien adalah suatu proses: pendaftaraan, pencatatan dan penyaluran

pasien ke unit pelayanan. Selanjutnya diberikan penanganan sesuai dengan

penyakitnya.

Penerimaan pasien dilakukan di loket pendaftaran

Pada waktu pendaftaran pasien menunjukkan kartu peserta

Kartu peserta dicocokkan dengan data yang ada di komputer

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:

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

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

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

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.

112

Page 14: contoh DFD.DOC

Bab III. Problem Statement

III.1. PIECES Framework

Untuk menggambarkan sistem lama dari PKM UI akan digunakan framework PIECES.

Framework PIECES adalah kerangka yang dipakai untuk mengklasifikasikan suatu

problem, opportunities, dan directives yang terdapat pada bagian scope definition analisa

dan perancangan sistem [WHI01]. Dengan kerangka ini, dapat dihasilkan hal-hal baru

yang dapat menjadi pertimbangan dalam pengembangan sistem. Setiap huruf dalam

PIECES merepresentasikan sebuah kategori dalam perumusan masalah yang ada, yaitu :

1. P adalah kebutuhan untuk meningkatkan performance.

2. I adalah kebutuhan untuk meningkatkan informasi dan data.

3. E adalah kebutuhan untuk meningkatkan ekonomi atau biaya kontrol.

4. C adalah kebutuhan untuk meningkatkan kontrol maupun keamanan (security)

5. E adalah kebutuhan untuk meningkatkan efisiensi dari kegiatan setiap orang

maupun proses yang ada.

6. S adalah kebutuhan untuk meningkatkan layanan kepada para pasien.

III.2. Hasil Analisa dengan PIECES Framework

Berikut adalah pengembangan problem, opportunities, dan directives dalam

pengembangan sistem informasi untuk PKM UI dengan acuan framework PIECES.

P – Performance

PKM UI ingin meningkatkan waktu layanan bagi pasien, sehingga pasien tidak

perlu menunggu lama.

Pengurangan waktu, tenaga dan biaya untuk pendaftaran dan entri data pada

kasus mahasiswa baru UI dan PNJ (Politeknik Negeri Jakarta)

I – Information

Mengurangi kesalahan-kesalahan yang terjadi karena faktor human error dalam

membaca data kesehatan pasien. Dan dalam data penyakit yang terjadi dalam kurun

waktu tertentu.

E – Economics

113

Page 15: contoh DFD.DOC

Untuk menghemat biaya operasional yang setiap tahun harus dikeluarkan untuk

pendaftaran dan pelayanan.

C – Control

Kontrol terhadap kinerja tenaga medis dan penyakit yang diderita oleh pasien

dalam waktu tertentu dan kondisi tertentu.

Pengawasan terhadap dat pasien mahasiswa yang masih terdaftar maupun

yang sudah lulus

E – Efficiency

Efisiensi pada tahap pengolahan data untuk diajukan ke pihak rektorat dan

puskesmas setempat, serta untuk pengolahan data sehari-hari.

S - Service

Pelayanan yang diberikan oleh PKM saat ini cukup baik, tetapi kedepannya akan

banyak kendala jika masih menggunakan sistem lama, terlebih dengan makin

banyaknya mahasiswa UI, maka pelayanan harus makin cepat dan mudah.

Berikut ini Tabel pernyataan masalah, seperti tercantum pada tabel 1 Matriks problem

statement.

Table 1 Matriks Problem Statement

Brief Statements of

Problem, Opportunity, or

Directive

Urgency VisibilityAnnual

BenefitsRank

Proposed

solution

Sistem manual pelayanan

kesehatan PKM UI tidak

feasible

3 month High 1 Merancang sistem

baru

Keakuratan data tidak terjamin 3 month High 2 Merancang sistem

baru

Waktu pelayanan pasien terlalu

lama.

3 month High 3 Merancang sistem

baru

114

Page 16: contoh DFD.DOC

Biaya operasional PKM UI

terkait dokumentasi yang cukup

besar

3 month High 2 Merancang sistem

baru

Entri data mahasiswa baru

yang dilakukan pihak Rektorat,

tidak perlu lagi diulang oleh

PKM UI.

3 month High 3 Pengembangan

sistem yang

terhubung dengan

pihak rektorat

Waktu yang diperlukan untuk

memasukan data mahasiswa

baru terlalu lama.

3 month High 3 Pengembangan

sistem baru

115

Page 17: contoh DFD.DOC

Bab IV. Project Charter

Tujuan dari Project Charter ini adalah menampilkan temuan awal dari investigasi untuk

memperkuat argumen mengenai fisibilitas proyek Sistem Pelayanan Medis (SPM) PKM

UI Depok. Dokumen ini juga dimaksudkan untuk pelaporan jadwal dan batasan-batasan

dalam pengerjaan proyek.

IV.1. Preliminary Findings and Analysis

Berdasarkan investigasi awal yang telah dilakukan, berikut ini akan dijelaskan mengenai

proyek yang dapat membantu PKM UI untuk mengatasi masalah inefisiensi dalam data

kesehatan mahasiswa.

IV.1.1. Deskripsi Proyek

Pada bagian ini akan dibahas mengenai latar belakang dan ruang lingkup dari proyek

SPM PKM UI Depok yang akan dikerjakan.

IV.1.1.1.Latar Belakang Proyek.

SPM adalah suatu sistem informasi berbasiskan komputer yang khusus dirancang untuk

memenuhi kebutuhan PKM UI Depok. Sistem informasi ini diharapkan dapat membantu

kegiatan tenaga medis di tiap unit operasional PKM UI Depok dan juga mempu untuk

mengatur manajemen data kesehatan mahasiswa UI.

Selama ini PKM UI melakukan menajemen data kesehatan mahsiswa dengan sistem

manual, yaitu dengan menggunakan media kertas dan file-file yang tersimpan dalam rak

besar dan data tersebut kurang dikontrol dan dipergunakan dengan baik. Cara ini akan

menyulitkan pihak PKM untuk melakukan entri data 8000 mahasiswa baru UI tiap

tahunnya.

Dengan adanya SPM PKM UI ini diharapkan pelayanan kepada para pasien akan lebih

cepat dan terintegrasi dengan baik. Karena dengan sistem yang terhubung dengan Local

116

Page 18: contoh DFD.DOC

Area Network (LAN) maka proses pengambilan keputusan oleh para tenaga medis yang

membutuhkan data yang lengkap akan semakin mudah dilakukan.

IV.1.1.2.Ruang Lingkup Proyek.

Proyek SPM PKM UI lebih menitik beratkan kepada masalah pelayanan medis kepada

para pasien yang menjadi klien PKM UI. Bidang pelayanan medis di PKM UI sendiri

dipimpin oleh seorang Kepala Bidang yang berada langsung dibawah pengawasan Wakil

Ketua PKM UI.

Proyek SPM PKM UI ini mencakup bisnis fungsi berikut ini:

1. Pelayanan Penerimaan Pasien.

Pada bagian ini bertujuan untuk mempermudah anggota yang ingin berobat,

maupun petugas penerima pasien. Terhadap sistem antrian elektronik yang

terhubung secara on-line dengan dokter pemeriksa.

2. Data warehousing Catatan Medis Pasien

Fungsi ini mengatur pengelolaan dan penyimpanan data anggota PKM UI.

Melalui fungsi ini terjadi perubahan media penyimpanan yang semula

menggunakan kertas-kertas diganti dengan menggunakan basisdata.

3. Pelayanan Medis Pasien

Fungsi ini dibangun untuk mempermudah pasien maupun dokter pemeriksa

memonitor dan mengontrol kesehatan pasien.

IV.1.2. Project Environment

Pada bagian ini akan dibahas mengenai project environment dari pelaksanaan proyek ini,

yang terdiri dari project participants atau orang-orang yang terlibat didalam proyek ini

dan project constraints yang akan membatasi dalam mengembangkan solusi bagi

permasalahan yang dihadapi.

IV.1.2.1.Project Participants

Berikut ini adalah orang-orang yang terkait dalam pengunaan SPM PKM UI.

1. Manajemen

a. Ketua PKM UI

117

Page 19: contoh DFD.DOC

b. Wakil Ketua PKM UI (yang menangani administrasi dan

keuangan)

c. Kabid Pelayanan Medis

2. Non-Managemen

a. Operator komputer/ petugas administrasi

b. Dokter yang bertugas

3. Pihak di luar organisasi yang berhubungan dengan sistem ini

a. Pasien

b. Biro Akademis Rektorat UI

IV.1.2.2.Project Constraints

Berikut ini adalah batasan-batasan dalam pengembangan solusi bagi permasalahan yang

terjadi di bidang pelayanan medis PKM UI.

Technical

Tidak tersedianya jaringan komputer yang menghubungkan antara unit PKM

dengan rektorat

Belum tersedianya jaringan lokal yang menghubungkan antar komputer di

PKM UI.

Tersedianya 26 komputer dengan 4 buah printer yang tidak dipergunakan di

PKM UI.

Monetary

Sulit mendapatkan dana dari pihak rektorat untuk membangun jaringan antara

pihak PKM UI dengan rektorat itu sendiri

Time

Waktu pengerjaan sistem ini hanya sekitar 3 bulan (Maret-Mei 2004)

Political

Sulitnya mendapatkan akses ke database mahasiswa yang dimiliki oleh pihak

akademis rektorat

118

Page 20: contoh DFD.DOC

IV.1.3. Preliminary Solutions and Ideas

Berdasarkan permasalahan, opportunities, dan batasan-batasan yang ada, maka dihasilkan

ide solusi untuk proyek SPM PKM UI.

IV.1.3.1.Client's perceptions of what they want or expect.

Sistem yang diharapkan oleh klien mampu untuk melakukan hal-hal dibawah ini:

1. Komputerisasi PKM UI, setiap unit operasional saling mendukung dan

berhubungan

Dengan komputer yang ada dan sistem yang akan dikembangkan, pihak

manajemen berharap agar sistem ini dapat mendukung integrasi antar unit

operasional di PKM UI, dan dapat mendukung program komputerisasi di PKM

UI.

2. Meningkatkan kepuasan pasien dalam mendapatkan pelayanan medis

Pihak manajemen PKM UI menginginkan adanya peningkatan pelayanan

terhadap pasien dengan adanya sistem ini, salah satunya dengan membuat pasien

tidak perlu terlalu lama menunggu dan mendapat pelayanan kesehatan yang tepat

bagi pasien.

3. Mempermudah kinerja tenaga medis dalam memberikan pelayanan medis

Tenaga medis PKM UI menginginkan kemudahan dalam mengakses data

kesehatan pasien, sehingga mereka tidak perlu menunggu berkas yang dibutuhkan

dari bagian administrasi terlebih dahulu sebelum melakukan tindakan medis.

4. Meningkatkan efisiensi dalam penyimpanan data kesehatan mahasiswa

Data kesehatan yang selama ini disimpan dalam bentuk kertas diharapkan dapat

diganti, hal ini untuk mengurangi resiko keamanan data pasien dan penghematan

di tubuh PKM UI.

IV.1.3.2.The analyst’s perceptions of possible solutions and ideas

1. Pembuatan system yang stand alone

Pembuatan sistem yang stand alone dapat memenuhi keinginan tenaga medis

untuk dapat mengakses data pasien langsung dari komputer mereka masing-

masing.

2. Membuat system yang terhubung dengan jaringan LAN

119

Page 21: contoh DFD.DOC

Dengan sistem yang terhubung dengan jaringan lokal maka integrasi antar unit

operasional di PKM UI dapat diwujudkan. Sehingga tindakan yang dilakukan

oleh suatu unit operasional langsung dapat diketahui dan ditindak lanjuti oleh unit

selanjutnya.

3. Pembuatan system yang dapat diakses oleh semua tenaga medis yang terhubung

dengan database kesehatan mahasiswa

4. Pembuatan database yang tersentralisasi

120

Page 22: contoh DFD.DOC

Bab V. Analisa Permasalahan

Tahapan analisa permasalahan (Problem Analysis) bertujuan untuk mempelajari dan

memahami permasalahan inti yang dihadapi oleh suatu system secara menyeluruh, untuk

kemudian dianalisa problem, peluang dan constraint-nya.

Oleh karena itu, pada tahapan ini dibahas mengenai problem , opportunities dan

objective, yang dijumpai pada pelaksanaan kegiatan operasional Pusat Kesehatan

Mahasiswa Universitas Indonesia (PKM UI) berikut analisanya. Pembahasan dimulai

dengan latar belakang informasi yang menjadi acuan penjelasan-penjelasan di bagian

berikutnya, dilanjutkan dengan gambaran mengenai sistem lama termasuk data, proses,

dan yang terlibat dalam sistem tersebut. Kemudian akan dibahas mengenai analisa dari

sistem lama dengan frame work PIECES (Performance, Information, Economic, Control,

Efficiency, dan Service) dalam bentuk matriks cause-effect. Selanjutnya akan dijelaskan

tentang rekomendasi sistem dengan matriks System Improvement Objectives beserta

constraint menyertainya.

V.1. Latar Belakang Informasi

Teknik pengumpulan informasi yang dilakukan untuk analisa sistem di PKM UI adalah

teknik pengumpulan informasi dengan menggunakan metode wawancara, metode

wawancara sendiri adalah metode untuk pengumpulan informasi dimana seorang analis

melakukan interasi secara langsung dengan narasumber.

Wawancara dilaksanakan pada hari Kamis tanggal 18 Maret 2004 pukul 13.00-14.00

bertempat di PKM UI lantai 1 dengan Hendrico D dan Zidni A dari kelompok 4 dan Bpk.

drg. Teuku A Arbi selaku Wakil PKM UI Bidang Administrasi dan Keuangan. Tipe

wawancara yang digunakan adalah tipe terstruktur untuk memanfaatkan waktu

wawancara yang terbatas dan memudahkan dalam pendokumentasian.

121

Page 23: contoh DFD.DOC

V.2. Gambaran Sistem Lama

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.

V.3. Analisa Sistem Lama

Pada bagian analisa sistem lama PKM UI ini akan dituliskan mengenai hasil analisa dari

masalah, opportunities dan directives yang telah diidentifikasikan pada bagian gambaran

sistem sebelumnya. Analisa sistem lama ini dilakukan dengan matriks cause-effect

sebagai terangkum dalam tabel 1 berikut :

Tabel 1 Matriks Cause and Effect analysis

CAUSE-AND-EFFECT ANALYSIS

Problem Causes and Effects

1. Sistem manual pelayanan

kesehatan PKM UI tidak feasible

a. Data pasien PKM UI yang

semakin besar

b. Data dalam bentuk kertas dapat

hilang atau rusak

2. Keakuratan data tidak terjamin. a. Entri data yang dilakukan ke

dalam dokumen kertas

meningkatkan kemungkinan

kesalahan akibat human error.

b. Kesalahan pada data, terutama

pada data kesehatan, dapat

menyebabkan terjadinya kesalahan

122

Page 24: contoh DFD.DOC

pada pelayanan medis yang

diberikan.

3. Waktu pelayanan pasien terlalu

lama.

a. Data kesehatan pasien ada

dalam bentuk hard copy. Untuk

mencari data kesehatan pasien

yang akan dilayani, tim medis harus

menunggu bagian administrasi

menyerahkan data kesehatan

pasien tersebut. Proses pencarian

yang lama menyebabkan proses

pelayanan yang lama.

b. Pasien akan mengeluh bila

dibuat menunggu terlalu lama. Hal

ini akan memperbesar

ketidakpuasan pasien terhadap

pelayanan medis di PKM UI

4. Biaya operasional PKM UI terkait

dokumentasi yang cukup besar

a. Mahasiswa Universitas Indonesia

dan Politeknik Negeri Jakarta

berjumlah sekitar 8000. Setiap

mahasiswa itu perlu dibuat

dokumen catatan kesehatannya

b. Berkurangnya dana untuk

pengadaan dokumen berupa form

dan kertas

5. Entri data mahasiswa baru yang

dilakukan pihak Rektorat, tidak

perlu lagi diulang oleh PKM UI.

a. Entri data mahasiswa baru tidak terintegrasi sehingga entri data perlu dilakukan berulang-ulang.

b. PKM UI membuang resource (waktu, tenaga manusia, dan dana) dalam melakukan entri data ulang tersebut.

6. Waktu yang diperlukan untuk

memasukan data mahasiswa baru

a. Tidak adanya sistem komputer yang menunjang kegiatan

123

Page 25: contoh DFD.DOC

terlalu lama. pencatatan kesehatan mahasiswa.b. Pencatatan data dilakukan pada

dokumen-dokumen kertas yang disimpan dalam file-file.

c. PKM UI membuang resource (waktu, tenaga manusia, dan dana) dalam melakukan entri data tersebut.

V.4. Rekomendasi

Berdasarkan analisa sistem lama di PKM UI dengan matriks cause-effect tersebut, maka

dihasilkan rekomendasi berupa matriks system objectives dan constraint dari sistem,

yang hasilnya terangkum pada tabel 2 :

Tabel 2 Matriks System Improvement Objectives

SYSTEM IMPROVEMENT OBJECTIVES

System Objectives System Constraints

1. Menggantikan sistem penyimpanan

dokumen dari dokumen kertas

kepada dokumen elektronik

2. Sistem menyediakan data

kesehatan yang tersentralisasi.

3. Waktu pelayanan pasien dikurangi

sekitar 10%.

4. Sistem meyediakan interface

pengaksesan data kesehatan

secara langsung melalui komputer

5. Sistem mampu memberikan data

statistik pasien dan penyakit yang

1. Komputer-komputer di PKM UI,

yang menggunakan sistem ini,

harus terhubung ke jaringan lokal

PKM UI.

2. Sistem yang akan dibuat harus

berbasis web.

3. Sistem yang akan dibuat harus

dibuat menggunakan free licensed

software.

4. Kapasitas penyimpanan database

di PKM UI yang disesuaikan

124

Page 26: contoh DFD.DOC

pernah tercatat di PKM.

125

Page 27: contoh DFD.DOC

Bab VI. Analisa Kebutuhan

Tahapan analisa kebutuhan (business requirement) yang bertujuan mendefinisikan

kebutuhan dari sistem yang akan dikembangkan

PKM UI membutuhkan beberapa hal yang menjadi kebutuhan functional dan kebutuhan

nonfunctional dari sistem yang dikembangkan. Beberapa contoh nonfunctional

requirement adalah penghematan biaya, kinerja, alokasi waktu, dan lain-lain. Berikut ini

akan diperlihatkan functional requirement atau kebutuhan aktivitas / layanan yang harus

disediakan oleh sistem yang terdapat pada tabel 3.

Tabel 3 Functional Requirement

No. Functional Requirement

1. Pendaftaran pasien baru dengan pencatatan biodata pasien

2. Pencatatan data kesehatan pasien

3. Melihat biodata dan data kesehatan pasien

4. Melakukan pengaturan pasien dan alokasi dokter

Sedangkan nonfunctional requirement adalah deskripsi dari fitur, karakteristik dan

constraints yang membentuk sistem yang memuaskan. Nonfunctional requirement

dijabarkan dalam tabel 4, sebagai berikut:

Tabel 4 Nonfunctional Requirement

Tipe dari

Nonfunctional

Requirement

Penjelasan

Performance Sistem ini harus mudah akses. Sehingga petugas

penerima pasien dan dokter tidak menunggu lama

ketika memulai sistem ini.

126

Page 28: contoh DFD.DOC

Response time dalam mengupdate database harus

cepat.

Information Ketika pendaftaran pasien baru, maka input dari

sistem ini adalah biodata pasien (khusus pasien

mahasiswa, ada tambahan berupa data

pemeriksaan awal (berat badan, tinggi, rontgen

awal) ). Outputnya berupa database pasien (Biodata

pasien dan Form Medical Record buat pasien

tersebut).

Ketika pasien berobat, maka input dari sistem ini

adalah id_pasien. Outputnya berupa tampilan

Biodata Pasien dan Form Medical Record yang akan

diserahkan ke dokter yang menanganinya.

Economy Sistem ini akan megnhilangkan biaya penggunaan

kertas untuk Form Medical Record dan form

pendaftaran (khusus untuk pasien mahasiswa).

Biaya untuk pengadaan buku absen pasien juga

akan dihilangkan. Hal ini dikarenakan absensi

pasien dapat diketahui melalui medical record yang

diterima dokter.

Control Sistem ini butuh administrator yang akan

mengkontrol kebaradaan pasien (per lima tahun

dicek, jika pasien tersebut tidak pernah berobat

maka data pasien tersebut akan ditandai dan

kemudian akan dihapus). Dalam sistem ini yang

menjadi administrator adalah petugas penerima

pasien.

Efficiency Biasanya setelah pasien datang ke petugas

penerima pasien untuk dicek keberadaan medical

recordnya, petugas penerima pasien akan

mengantarkan medical record tersebut ke dokter

127

Page 29: contoh DFD.DOC

yang akan menangani pasien tersebut. Sistem ini

akan mengurangi waktu petugas penerima pasien

untuk mengantarkan medical record ke dokter

(medical record akan dikirim melalui jaringan

komputer).

Perhitungan statistik kunjungan pasien ke PKM

dapat dilakukan dengan cepat dibanding sebelum

ada sistem ini. Hal ini dikarenakan statistik tersebut

dihitung dengan komputer. Datanya didapatkan dari

jumlah medical record pasien yang ditangani dokter

dalam rentang waktu tertentu (misal sebulan).

Service Sistem ini akan digunakan oleh Petugas Penerima

Pasien dan Dokter yang bertugas di PKM.

Sistem ini akan berada di ruangan Penerimaan

Pasien, Dokter Gigi, dan Dokter Umum.

Petugas Penerima Pasien dapat mengisi, melihat,

dan menghapus database biodata pasien. Selain itu

beliau juga dapat melihat database Medical Record.

Dokter hanya dapat melihat database biodata

pasien. Namun, dia dapat mengisi dan melihat

database Medical Record.

Sebelum sistem ini digunakan, maka diperlukan

training penggunaan sistem ini. Training ini diadakan

oleh Tim kami kepada para pengguna dari sistem ini

(Dokter dan Petugas Penerima Pasien di PKM).

Dalam sistem ini akan ada manual penggunaan

sistem.

128

Page 30: contoh DFD.DOC

Bab VII. Logical Design

Tahapan logical design bertujuan memberikan gambaran desain sistem yang akan

dibangun. Tahapan ini merupakan sistem pemodelan dari kebutuhan bisnis yang telah

dijelaskan dalam bagian analisa kebutuhan. Pemodelan yang diberikan mencakup:

Pemodelan data dengan Entity Relationship Diagram, Pemodelan alur proses dengan

data flow diagram, dan Pemodelan user interface.

VII.1. Pemodelan DataBerikut ini adalah Entity Relationship Diagram (ER-Diagram) dari sistem PKM UI

seperti terdapat pada gambar 3.

Gambar 3 ER Diagram

129

Page 31: contoh DFD.DOC

ER Diagram tersebut memiliki lima entitas, yaitu: mahasiswa sebagai obyek layanan

PKM UI, umum yang merupakan masyarakat umum yang terdaftar di PKM UI,

karyawan_UI yang mendaftar ke PKM UI, pasien merupakan seluruh pasien yang hari

itu mendaftar/ mengantri dan medical_ record yang merupakan catatan kesehatan pasien.

VII.2. Pemodelan Alur Proses

Di sub bab ini akan dijelaskan mengenai aliran data pada proses-proses yang ada di setiap subsistem.

Gambar 4. DFD Level 0

Gambar 4. DFD Level 1

130

1

2

3

Page 32: contoh DFD.DOC

Gambar 5 DFD Level 2

Penjelasan mengenai proses secara umum dalam gambar di atas:

Petugas Pendaftaran Pasien akan memberikan input ke dalam sistem berupa data pasien.

Pasien Lama (pasien yang sudah terdaftar) akan dimasukan ke dalam antrian. Pasien Baru

(pasien yang belum terdaftar) akan disimpan datanya ke dalam database untuk

menyimpan Data Pribadi dan Medical Record pasien-pasien; selain itu Pasien Baru

tersebut juga dimasukan ke dalam antrian.

Dokter akan memberikan pelayanan medis kepada pasien sesuai dengan urutan pasien

yang menunggu dalam antrian. Dokter akan memeriksa medical record pasien yang akan

menerima pelayanan medis. Dokter yang akan bertanggung jawab untuk melakukan

perubahan medical record pasien yang dirawatnya, bila setelah pelayanan medis

dilakukan, perlu dilakukan perubahan terhadap medical record pasien tersebut.

Tabel Deskripsi EntityNama Entity Deskripsi

Petugas Pendaftaran Pasien Petugas Pendaftaran Pasien bertanggung jawab untuk mendaftarkan pasien yang ingin meminta pelayanan medis dari PKM UI.Petugas Pendaftaran Pasien bertanggung jawab terhadap manajemen data pasien bila memang perlu dilakukan.

Dokter Dokter akan bertanggun jawab untuk memberikan pelayanan medis terhadap pasien. Dokter akan menerima medical record pasien yang akan dirawat dan bertanggung

131

Page 33: contoh DFD.DOC

jawab terhadap perubahan medical record pasien yang dirawatnya.

Tabel Deskripsi Data StoreNama Data Store Deskripsi

Data Pribadi dan Medical Record Pasien

Data store ini menyimpan data pribadi dan medical record pasien-pasien yang pernah mendapatkan pelayanan medis di PKM UI.

Antrian Pasien Data store ini menyimpan antrian pasien yang menunggu untuk menerima pelayanan medis dari PKM UI.

Tabel Deskripsi ProsesNama Proses Deskripsi

Cek Data Pasien Proses ini akan menerima Data Pasien dari Petugas Pendaftaran Pasien untuk menentukan apakah pasien yang mendaftar itu sudah atau belum terdaftar di PKM UI.Bila pasien sudah terdaftar, maka pasien akan langsung dimasukan ke antrian. Sedangkan bila pasien belum terdaftar, maka data pasien akan disimpan terlebih dahulu sebelum pasien itu dimasukan ke dalam antrian.

Tambah Data Pasien Baru Proses ini akan menyimpan data pasien yang baru mendaftar ke PKM UI.

Tambah Antrian Pasien Proses ini akan menambahkan pasien yang mendaftar ke dalam antrian pasien yang menunggu untuk menerima pelayanan medis.

Pemanggilan Pasien dalam Antrian

Proses ini akan mengurangi antrian saat pasien yang berada di antrian paling depan dipanggil untuk menerima pelayanan medis.Saat satu pasien dipanggil, proses ini akan mengambil medical record pasien yang bersangkutan sehingga dokter yang akan merawat bisa melihat medical record tersebut.

Cari Data Pasien Proses ini akan mencari data pasien yang perlu dilihat.Ubah Data Pasien Proses ini akan mengubah data pribadi pasien yang perlu

diubah. Proses ini dibatasi sehingga perubahan yang dilakukan hanya pada data pribadi pasien dan bukan pada medical record pasien.

Update Medical Record Proses ini akan memperbaharui medical record dari pasien setelah pasien tersebut menerima pelayanan medis.

Tabel Input/Output ProsesNama Proses Input Output

Cek Data Pasien - Data Pasien : Data pasien yang mendaftar di PKM UI untuk menerima pelayanan medis.

- Data Pasien Baru : Data pasien yang baru mendaftar di PKM UI.

- ID & Nama Pasien Lama: Id dan nama pasien yang sudah

132

Page 34: contoh DFD.DOC

terdaftar di PKM UI.Tambah Data Pasien Baru - Data Pasien Baru : Data

pasien yang baru mendaftar di PKM UI.

- Data Pasien Baru : Data pasien yang baru mendaftar di PKM UI untuk disimpan di dalam database Data Pribadi & Medical Record Pasien.

Tambah Antrian Pasien - ID & Nama Pasien Lama: Id dan nama pasien yang sudah terdaftar di PKM UI.

- ID & Nama Pasien Baru: Id dan nama pasien yang baru mendaftar di PKM UI yang didapat dari database Data Pribadi & Medical Record Pasien saat melakukan proses Tambah Data Pasien Baru.

- ID & Nama Pasien : Id dan nama pasien yang akan dimasukan ke dalam database Antrian Pasien.

Pemanggilan Pasien dalam Antrian

- Nomor Antrian & ID Keanggotaan Pasien: Nomor antrian pasien yang ada di urutan depan dari database Antrian Pasien, serta Id anggota pasien tersebut.

- Medical Record Pasien : Medical Record pasien yang sedang dipanggil untuk menerima pelayanan medis yang didapat dari database Data Pribadi & Medical Record Pasien.

- Medical Record Pasien yang akan dirawat: Medical Record pasien yang akan menerima pelayanan medis sesuai dengan Id anggota yang dipanggil dari database Antrian Pasien untuk diserahkan kepada Dokter yang akan merawat.

Cari Data Pasien - ID Keanggotaan Pasien : Id anggota pasien yang ingin dicari dan dilihat datanya.

- ID Keanggotaan Pasien : Id anggota pasien yang ingin dicari dan dilihat datanya dari dalam database Data Pribadi & Medical Record Pasien.

133

Page 35: contoh DFD.DOC

Ubah Data Pasien - Data Pasien yang Baru : Data pasien terbaru yang akan diubah.

- Updated Data Pasien : Data pasien yang sudah diubah untuk disimpan di dalam database Data Pribadi & Medical Record Pasien.

Update Medical Record - Medical Record yang Baru: Medical Record pasien yang sudah menerima perawatan oleh Dokter.

- Updated Medical Record: Medical Record pasien yang sudah menerima perawatan oleh Dokter untuk disimpan ke dalam database Data Pribadi & Medical Record Pasien.

VII.3. Database Schema

Berdasarkan ERD pada logical design, kami membuat pemetaan serta melakukan

normalisasi yang hasil akhirnya sebagai berikut:

Pasien

id_pasien nama_pasien alamat_pasien gol_darah tinggi berat tgl_hsl_rontgen_awal

Mahasiswa

NPM kampus fakultas id_pasien

Karyawan UI

no_kui tmp_kerja id_pasien

Umum

134

Page 36: contoh DFD.DOC

KTP id_pasien

Medical Record

id_med_rec tgl_berobat nama_penyakit terapi tgl_hsl_rontgen_baru

Tgl_hasil_lab id_pasien

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 datanya char dengan

panjang data sepuluh.

nama_pasien

nama_pasien merupakan informasi nama pasien. Tipe datanya varchar

dengan panjang data maksimum dua puluh.

alamat_pasien

alamat_pasien merupakan alamat pasien yang bersangkutan. Tipe datanya

varchar dengan panjang data maksimum 254.

gol_darah

gol_darah merupakan keterangan golongan darah pasien. Tipe datanya

char dengan panjang data empat karakter.

tinggi

tinggi merupakan informasi tinggi dari pasien. Tipe datanya integer.

berat

berat merupakan informasi berat dari pasien. Tipe datanya integer.

tgl_hsl_rontgen_awal

135

Page 37: contoh DFD.DOC

Merupakan tanggal dari hasil rontgen pada awal pemeriksaan. Adapun tipe

tipe datanya adalah date.

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 datanya char dengan panjang

data sepuluh.

kampus

kampus adalah tempat mahasiswa berada dalam hal ini bisa bernilai UI

atau PNJ (Politeknik Negeri Jakarta). Tipe datanya varchar dengan

panjang data dua puluh.

fakultas

fakultas adalah tempat mahasiswa menjalani perkuliahan. Tipe datanya

varchar dengan panjang data dua puluh.

id_pasien

id_pasien merupakan suatu nomor yang unik. Tipe datanya char dengan

panjang data sepuluh.

Tabel 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 UI. Tipe datanya char dengan maksimal

data sepuluh.

tmp_kerja

tmp_kerja ini berisi informasi tempat karyawan UI bekerja. Tipe datanya

char dengan maksimal data dua puluh.

id_pasien

136

Page 38: contoh DFD.DOC

id_pasien merupakan suatu nomor yang unik. Tipe datanya char dengan

panjang data sepuluh.

Tabel Umum

Tabel ini digunakan untuk menyimpan keterangan pasien yang berasal umum atau

masyarakat sekitar. Data-data terkait yang akan disimpan adalah sebagai berikut :

KTP

KTP merupakan nomor KTP yang unik. Tipe datanya char dengan

panjang data sepuluh.

id_pasien

id_pasien merupakan suatu nomor yang unik. Tipe data datanya char

dengan panjang data sepuluh.

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

datanya char dengan panjang data sepuluh.

tgl_berobat

tgl_berobat merupakan data tanggal pada saat pasien berobat. Tipe

datanya date.

nama_penyakit

nama_penyakit ini memberikan informasi tentang penyakit yang dialami

atau diderita pasien. Tipe datanya varchar dengan panjang data dua puluh.

terapi

terapi ini berisi informasi tentang terapi pasien. Adapun Tipe datanya

varchar dengan panjang data dua puluh.

tgl_hsl_rontgen_baru

tgl_hsl_rontgen_baru ini berisi informasi waktu hasil rontgen terbaru.

Tipe datanya date.

137

Page 39: contoh DFD.DOC

tgl_hasil_lab

Menginformasikan tanggal hasil periksa laboratorium terakhir. Tipe

datanya date.

id_pasien

id_pasien merupakan suatu nomor yang unik. Tipe datanya char dengan

panjang data sepuluh.

VII.4. 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 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 langkah-langkah

pengobatan ataupun untuk mengetahui perkembangan kesehatan pasien.

138

Page 40: contoh DFD.DOC

VII.4.1.Physical Output DesignPhysical 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.

Output Daftar Antrian

Gambar 6. Output Daftar Antrian Pasien

Gambar 9 menunjukkan 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

139

Page 41: contoh DFD.DOC

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.

Output Data Anggota

Output Data Anggota ini terdiri dari dua, yaitu :

140

Page 42: contoh DFD.DOC

1. Daftar Anggota

Gambar 7. Output Daftar Anggota

Gambar 10 menampilkan daftar semua anggota yang terdaftar di PKM UI. Pada output

ini terdapat link menuju output detail data tiap-tiap anggota dan output medical check-up-

nya

Di bagian ini juga terdapat link untuk menuju ke fitur-fitur lain, yang dalam hal ini adalah

fitur daftar pasien dan fitur tambah anggota.

141

Page 43: contoh DFD.DOC

2. Data lengkap Anggota

Gambar 8. Output Data Lengkap Anggota

Gambar 11 menampilkan 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.

142

Page 44: contoh DFD.DOC

Output Medical Check-Up

Gambar 9. Output Medical Check-Up

Gambar 12 menampilkan 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.

VII.5. Desain dan Prototipe Input Sistem

Desain Input dalam Sistem Informasi Pelayanan Kesehatan Mahasiswa meliputi 3 bagian

yaitu:

143

Page 45: contoh DFD.DOC

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

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

VII.5.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 design-nya 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

144

Page 46: contoh DFD.DOC

Pada antrian pasien, Inputnya menjadi satu dengan tampilan output. Interface-nya dapat

dilihat sebagai berikut pada gambar 13

Gambar 10. Input Daftar Antrian Pasien

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 interface-nya seperti yang

ditampilkan dalam gambar 14.

145

Page 47: contoh DFD.DOC

Gambar 11. Input Daftar Antrian

Input suatu anggota dapat dilakukan apabila terdapat anggota baru yang mendaftar,

penghapusan anggota ataupun mengadakan perubahan data pada seorang anggota. Oleh

karena itu interface-nya juga dibagi menjadi dua:

1. Interface untuk penambahan anggota baru

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. Adapun interface-nya

seperti yang ditampilkan dalam gambar 15

146

Page 48: contoh DFD.DOC

Gambar 12. Input Tambah Anggota Baru

2. Interface 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 interface-nya seperti yang

ditampilkan dalam gambar 16

147

Page 49: contoh DFD.DOC

Gambar 13. 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 interface-nya sama dengan waktu pengisian data baru.

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, Adapun interface-nya seperti yang ditampilkan

dalam gambar

148

Page 50: contoh DFD.DOC

Gambar 14. Input Medical Check-Up

149

Page 51: contoh DFD.DOC

Pemodelan User Interface

Di dalam sub bab ini akan dijelaskan tentang model user interface yang akan menjadi

dasar desain user interface.

Gambar 15 Diagram interface untuk Petugas Pendaftaran Pasien

Diagram interface untuk petugas pendaftaran pasien seperti pada gambar 5 merupakan

pemodelan dari bagaimana tampilan dari user interface yang diinginkan untuk petugas

pendaftaran pasein. Pertama kali sistem akan menampilkan tiga pilihan bagi petugas,

yaitu: Daftar Antrian Pasien, Tambah Pasien/ Anggota Baru, dan Daftar Pasien/ Anggota

Baru. Daftar Antrian Pasien akan memberikan pilihan pada petugas untuk menambah

pasien ke daftar antrian atau menghapus pasien dari daftar antrian. Sedangkan Daftar

Anggota/ Pasien memberikan pilihan untuk menampilkan Medical Record atau

menampilkan Data Lengkap pasien/ anggota, jika pilihannya adalah menampilkan data

lengkap maka petugas dapat menghapus data lengkap ataupun mengubah data lengkap

pasien/ anggota.

150

Page 52: contoh DFD.DOC

Gambar 16 Diagram interface untuk dokter

Diagram interface untuk dokter seperti pada gambar 6 merupakan pemodelan dari

bagaimana tampilan dari user interface yang diinginkan untuk dokter PKM UI. Pada

Halaman Utama sistem akan menampilkan hanya satu pilihan bagi dokter, yaitu: Daftar

Antrian Pasien. Daftar Antrian Pasien akan memberikan pilihan pada dokter untuk

mengubah medical record pasien, menghapus pasien dari daftar antrian atau

menampilkan data lengkap pasien. Jika pilihannya adalah menampilkan data lengkap

maka dokter dapat menghapus data lengkap ataupun mengubah data lengkap pasien/

anggota.

151

Page 53: contoh DFD.DOC

Bab VIII. Analisa Keputusan

Tahapan decision analysis yang akhirnya bertugas untuk memilih alternatif teknologi

yang akan digunakan dengan mekanisme pembobotan. Tahapan ini dilakukan setelah

kebutuhan bisnis ditentukan dan keputusan tentang pengembangan sistem perlu segera

diambil. Langkah pengambilan keputusan adalah dengan menyusun kandidat teknologi

dari sistem, menentukan kandidat terbaik berdasarkan bobot yang ada.

Berikut ini adalah kandidat dari sistem yang akan dikembangkan seperti tercantum dalam

tabel 7. Penyusunan kandidat dilakukan berdasarkan beberapa karakteristik, seperti

software, hardware, penyimpanan data, dan lain-lain.

152

Page 54: contoh DFD.DOC

Tabel 5 Matriks Sistem Kandidat

Karakteristik Kandidat 1 Kandidat 2 Kandidat 3

Software yang digunakan untuk pengembangan sistem

Software-software seperti DBMS, bahasa pemrograman yang dipakai, dll

PHP 4.0 untuk web-application dan MySQL sebagai DBMS

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

Microsoft ASP untuk web-application dan Microsoft SQL Server 2000 sebagai DBMS

Hardware yang digunakan dalam sistem

Hardware-hardware yang akan dipakai sistem, seperti untuk server dan workstation

Server: Komputer dengan kemampuan setara Pentium 4

Workstation: Komputer Pentium 2

Sama seperti kandidat 1

Sama seperti kandidat 1

Keuntungan yang didapat

Penjelasan singkat tentang keuntungan yang dimiliki kandidat sistem

Biaya pengembangan dapat ditekan seoptimal mungkin

Pengembangan sistem yang dapat dikembangkan menjadi sistem yang besar

Pengembangan yang dapat beralih ke teknologi .NET dan kesesuaian dengan Windows OS

Sarana untuk input data

Cara input yang dipakai untuk memasukan data.

Keyboard dan mouse

Sama seperti kandidat 1

Sama seperti kandidat 1

Sarana untuk output data

Cara output yang dipakai untuk menampilkan data

Printer Laser HP Sama seperti kandidat 1

Sama seperti kandidat 1

153

Page 55: contoh DFD.DOC

Sarana untuk menyimpan data

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

Seagate 40 GB, 7200 RPM

Sama seperti kandidat 1

Sama seperti kandidat 1

Bagian yang terkomputerisasi

Pemilihan bagian yang akhirnya dikomputerisasi oleh pengembangan sistem

Data Kesehatan Pasien, pendaftaran dan pelayanan kesehatan

Sama seperti kandidat 1

Sama seperti kandidat 1

Teknologi pemrosesan data

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

Penentuan kandidat terbaik dilakukan dengan melaksanakan analisa terhadap kandidat

yang ada berdasarkan beberapa kriteria feasibility yang ada, diantaranya Operational,

Technical, dan lain-lain. Setelah dianalisa berdasarkan kriteria tersebut, maka dilakukan

pembobotan terhadap kandidat, proses tersebut tercantum dalam tabel 8 Matriks

feasibility.

154

Page 56: contoh DFD.DOC

Tabel 6 Matriks feasibility

Kriteria feasibility Bobot Kandidat 1 Kandidat 2 Kandidat 3

Operational feasibility

Penilaian terhadap seberapa besar kandidat mempengaruhi lingkungan kerja user dan apakah dapat memenuhi kebutuhan user dan bukan semakin mempersulit user

30% Sistem owner akan mudah mempelajari PHP 4.0 dan dengan sistem baru yang berbasis web dan user-friendly akan mengurangi terjadinya human error

Skor: 90

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

Skor: 50

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

Skor: 90

Technical feasibilty

Penilaian terhadap kemampuan dari kandidat untuk menyelesaikan masalah yang ada dengan keunggulan teknis yang dimiliki

30% MySQL sudah dikenal sebagai DBMS yang cukup handal dengan karakteristik response time yang cepat.

Skor : 90

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

Economic feasibility

Penilaian berdasarkan keefektifan biaya yang dikeluarkan untuk kandidat tertentu

30% Kombinasi PHP 4.0 dan MySQL dirasakan cukup economic feasible mengingat keduanya didistribusikan secara freeware.

Skor: 100

Kombinasi Java Sun JDK1.4 dan MySQL dirasakan cukup economic feasible mengingat keduanya didistribusikan secara freeware.

Kombinasi Microsoft ASP dan Microsoft SQL Server kurang feasible. Microsoft ASP: $850 US Microsoft SQL Server: $19,999 US

155

Page 57: contoh DFD.DOC

Skor: 100 Skor: 40

Schedule feasibility

Penilaian yang dilakukan terhadap keefektifan waktu yang diperlukan oleh tiap-tiap kandidat

10% Pihak PKM UI sudah terbiasa menggunakan PHP dan My SQL dalam sistem absensi mereka, jadi waktu pembelajaran yang diperlukan untuk pengembangan sistem yang baru lebih sedikit kurang lebih

3 bulan

Skor: 100

Pihak PKM UI belum terbiasa menggunakan Java jadi waktu pembelajaran yang diperlukan untuk pengembangan sistem yang baru lebih banyak di bandingkan kandidat satu, kurang lebih 5 bulan

Skor: 80

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

Skor: 90

Ranking 100% 94 80 69

Setelah melalui tahapan pembobotan seperti pada tabel sebelumnya, maka diperoleh

bahwa kandidat satu memiliki nilai yang lebih tinggi dibandingkan kandidat 2 dan 3.

Kandidat 1 memperoleh nilai 94 sedangkan kandidat 2 hanya mendapat nilai 80 dan

kandidat 3 mendapat 69. Kandidat 1 memiliki keunggulan dalam kemudahan

implementasi.

Oleh karena itu kandidat terbaik yang diusulkan untuk PKM UI adalah kandidat 1.

Kandidat 1 telah memenuhi kebutuhan dari sistem informasi pelayanan kesehatan PKM

UI.

156

Page 58: contoh DFD.DOC

Bab IX. Desain SistemSetelah 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 17. Physical DFD

Penjelasan proses-proses pada Physical Data Flow Diagram di atas:

1. Cek Data Pasien.

Tujuan:

Memeriksa apakah pasien merupakan pasien lama atau bukan.

Input:

- Kartu anggota yang berisi data pasien

Output:

- Bagi pasien yang telah terdaftar, data pasien tersebut akan dimasukkan ke

dalam antrian, dalam bentuk halaman HTML, agar pasien tersebut dapat

menerima pelayanan medis.

- Bagi pasien yang belum terdaftar, petugas pendaftaran pasien akan

memasukkan ke dalam database Data Pribadi dan Medical Record.

2. Tambah Data Pasien Baru.

157

Page 59: contoh DFD.DOC

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 dimasukkan ke dalam antrian pasien,

dalam bentuk halaman HTML, agar pasien tersebut dapat menerima

pelayanan medis.

3. Tambah Antrian Pasien

Tujuan:

Membuat antrian pasien dalam urutan pelayanan medis

Input:

- Form HTML yang berisi ID dan nama pasien baru

- Form HTML yang berisi ID dan nama pasien lama

Output:

Urutan ID dan nama pasien yang akan dilayani dimasukan ke dalam

database Antrian Pasien.

4. Cari Data Pasien.

Tujuan:

Mengetahui data pribadi dan medical record dari pasien yang diinginkan

Input:

Form HTML yang berisi ID yang akan dilihat data pribadi dan medical

record-nya

Output:

Menampilkan medical record dari pasien kepada dokter yang melayani

5. Ubah Data Pasien

Tujuan:

Memperbaharui data pasien-pasien yang telah berubah

Input:

158

Page 60: contoh DFD.DOC

Form HTML yang berisi data pasien terbaru yang akan diperbaharui. Data

tersebut dimasukan oleh Petugas Pendaftaran Pasien.

Output:

Data Pasien yang sudah diperbaharui akan dimasukan ke dalam database

Data Pribadi dan Medical Record.

6. Pemanggilan Pasien dalam Antrian.

Tujuan:

Memanggil pasien yang akan dirawat berdasarkan urutan yang kemudian

data pasien tersebut akan dilihat.

Input:

- Nomor antrian dan ID keanggotaan pasien yang akan dilayani oleh dokter

berasal dari database Antrian Pasien

- Form HTML yang berisi medical report pasien yang akan dilayani

Output:

Data Pasien yang sudah diperbaharui akan dimasukan ke dalam database.

7. Update Medical Record.

Tujuan:

Memperbaharui medical record pasien-pasien yang sudah menerima

perawatan

Input:

Form HTML yang berisi medical record pasien terbaru yang akan

diperbaharui. Data tersebut dimasukan oleh Dokter.

Output:

Data Pasien yang sudah diperbaharui akan dimasukan ke dalam database

Data Pribadi dan Medical Record.

159

Page 61: contoh DFD.DOC

Penutup

IX.1. Kesimpulan

PKM UI adalah sebuah unit layanan yang memiliki peran utama sebagai pusat layanan

kesehatan mahasiswa di Universitas Indonesia. PKM UI memiliki 2 klinik dan

menyediakan layanan kesehatan bagi seluruh warga UI yang meliputi mahasiswa,

karyawan, dan masyarakat sekitar UI. Dalam malakukan kegiatan operasionalnya, PKM

UI mengalami kendala dalam melaksanakan tugasnya. Salah satu kendala yang dihadapi

adalah besarnya biaya untuk dokumentasi dan sering tidak terurusnya dokumentasi di

PKM UI. Dari kendala tersebut maka pelayanan kepada pasien sering terhambat,

walaupun tidak sampai membuat layanan pada PKM UI terhenti

Semakin meningkatnya jumlah mahasiswa dan untuk meningkatkan kualitas pelayanan

serta efisiensi dan efektifitas layanan, PKM memerlukan suatu sistem yang dapat

mempermudah arus informasi pendokumentasian data pelayanan kesehatan di PKM UI.

Pengembangan sistem yang dilakukan terdiri dari beberapa tahap yang diharapkan

melalui proyek ini maka kendala dokumentasi dapat diatasi.

IX.2. Saran

Pengembangan sistem informasi pelayanan kesehatan di PKM UI sampai saat ini sudah

cukup baik, namun tidak menutup kemungkinan seiring dengan perkembangan teknologi,

sistem informasi pelayanan kesehatan PKM UI dapat dikembangkan menjadi sebuah

sistem informasi yang lebih besar, yang mencakup sistem penunjang medis dan keuangan

PKM UI, dengan ditunjang teknologi yang lebih maju serta infrastruktur yang lebih

canggih. Kami sarankan untuk pengembangan sistem informasi pelayanan kesehatan

PKM UI lebih lanjut, setiap bagian pada PKM UI dapat tergabung dalam sistem ini dan

akhirnya dapat menjadi sistem informasi PKM UI secara utuh.

160

Page 62: contoh DFD.DOC

Daftar Pustaka

Whitten L,Jeffrey, and Lonnie D. Bentley . Sistem Analysis And Design Methods, 6 th ed.

New York : McGraw-Hill, 2002.

161

Page 63: contoh DFD.DOC

Lampiran

1. Interview antara Tim dengan Wakil Kepala PKM UI

Naskah interview antara tim, terdiri dari :a. Zidni Agni Apriya (ZAA)b. Hendrico Dharma Kurnia (HDK)

Dengan Wakil Kepala PKM UI bernama Pak Arbi (PA)

Ini merupakan interview kedua dengan Wakil Kepala PKM pada tanggal , tujuan dari interview kali ini adalah untuk mengumpulkan informasi mengenai perusahaan yang masih kurang dari interview awal, mengetahui bussiness case dan kemungkinan solusi yang dapat ditawarkan melalui sistem informasi yang memenuhi requirement ZAA: Assalamu’alaikum, Pak Arbi

PA: Wa’alaikumsalam.

ZAA : Kami dari Fakultas Ilmu Komputer UI yang waktu itu pernah kemari, sebelumnya perkenalkan lagi nama saya Zidni, dan ini Hendrico. Sekarang kami hanya berdua karena teman satu tim yang lainnya sedang berhalangan hadir . Sebelumnya, seperti yang telah saya jelaskan di telepon, bahwa tujuan utama kami datang kesini adalah dalam rangka memenuhi tugas tahap 2 kuliah Analisa Perancangan Sistem. Mungkin selama 30 menit ke depan kami akan mewawancarai Bapak.

PA : Oh ya silahkan. Mau bertanya apa?

ZAA : Terimakasih atas waktu yang diberikan. Begini, pak. Dari interview yang sebelumnya, tampaknya kami belum tahu sejarah pendirian PKM UI secara lebih mendetail. Bisakah Bapak terangkan kepada kami mengenai hal itu.

PA: Sebentar ya, saya ambil dokumen PKM UI yang menerangkan sejarah PKM terlebih dahulu. Jadi begini, Di Universitas Indonesia pada tahun 1964 telah berdiri poliklinik untuk masalah fisik mahasiswa UI. Pada tanggal 17 Februari 1965, berdirilah PKM UI dengan kepalanya pada waktu itu adalah M.K. Tadjudin. Pelayanan pada waktu ditujukan untuk membentuk kader revolusi paripurna yang memiliki sehat jasmani. Usaha-usaha yang dilakukan antara lain Kesehatan mahasiswa UI, poliklinik, pemeriksaan tahunan, menjaga kesehatan asrama serta kegiatan lain yang sesuai tujuan yayasan pendiri pada waktu itu. Keorganisasian PKM UI lebih disempurnakan pada tahun 1986 lalu pada tahun 1987 pelayanan dibuka untuk seluruh warga UI.

HDK: Pada saat ini PKM telah membuka pelayanan kepada siapa saja?

162

Page 64: contoh DFD.DOC

PA : PKM UI tidak hanya membuka layanan kepada mahasiswa UI dan PNJ (Politeknik Negeri Jakarta) saja namun juga membuka layanan kepada karyawan UI dan masyarakat yang berdekatan dengan sekitar lingkungan UI

HDK : Mengapa juga membuka layanan kepada PNJ?

PQ : Karena mereka juga membantu pendanaan kepada PKM UI untuk melayani mahasiswa mereka ZA : Bagaimanakah penerimaan awal pasien?I : Secara garis besar prosesnya adalah sebagai berikut :Pertama-tama pasien yang akan mendaftar untuk menjadi pasien pelanggan menyerahkan kartu mahasiswa apabila ia dari mahasiswa, kartu karyawan atau surat keterangan dari faskultas apabila dia bekerja sebagai karyawan lingkungan UI sedangkan dari masyarakat umum tidak perlu menunjukkan kartu apapun. Lalu bagi mahasiswa dan karyawan UI akan dilakukan pencocokan wajahnya dengan yang ada di foto kartunya, hal ini dilakukan agara tidak terjadi penyalahgunaan penggunaan kartu. Setelah cocok, pasien pelanggan baru akan diberikan kartu berobat yang terdiri kartu kuning kecil yang selalu dibawa oleh pasien dan kartu kuning besar untuk medical record. Selanjutnya kartu kecil akan diberikan kepada pasien tersebut sedangkan kartu besar akan diserahkan kepada dokter untuk melihat medical recordnya. Setelah pasien diperiksa oleh dokter, dokter akan me-update medical record pasien pada kartu besar dan memberikan resep obat kepada pasien yang berikutnya akan diserahkan kepada apoteker

ZAA : Lalu bagaimana dengan yang sudah terdaftar?

PA : Kurang lebih sama, pasien memberikan kartu kecil kepada petugas penerima pasien lalu mengisi absensi pasien. Dari nomor yang ada dalam kartu kuning kecil itu, petugas penerima pasien akan mencari kartu kuning besar yang dimiliki pasien pada rak kartu kuning besar. Petugas akan memberikan kepada dokter kartu kuning besar itu.

AD : Dengan proses bisnis yang sedemikian, sebenarnya hambatan apa saja yang PKM alami?

I : Well, mungkin saya akan menjawab sesuai dengan kapabilitas saya sebagai orang kedokteran, masalah utamanya adalah seluruh pekerjaan medical report harus secara manual dengan menggunakan kertas dan itu harus diketik dengan mesin tik. Sangat repot, karena berhubungan dengan begitu banyak data pasien dan sebagainya yang memiliki tingkat perubahan cukup tinggi (Pak Arbi Inda lalu memperlihatkan salah satu kartu kuning besar yang dibawanya yang berisi biodata dan medical report dari seseorang pasien terdaftar.

163

Page 65: contoh DFD.DOC

HDK : Jadi mungkin kendala utama dalam tugas PKM dalam penerimaan pasien ini adalah penggunaan banyak kertas dan repotnya mencari kartu kuning besar dalam manual?

PA : Kurang lebih seperti itu

ZAA : Ya, justru masalah-masalah manualisasi inilah yang ingin kami teliti lebih lanjut Pak, karena untuk beberapa kategori perusahaan, otomatisasi sistem dari sistem manual terkadang bukanlah pemecahan yang baik, karena berdampak pada SDM, struktur organisasi dan tentunya budget perusahaan.

HDK: Berapa lama pasien bisa terdaftar di sini Pak?

PA: Untuk mahasiswa hanya bisa selama ia menjadi mahasiswa saja, jadi ketika dia telah lulus, kartu kuning besarnya akan kami buang, begitu juga dengan karyawan UI harus selama ia memiliki tercatat sebagai karyawan UI. Namun bagi masyarakat biasa akan terdaftar selama seumur hidup.

ZAA: Mungkin untuk saat ini, kami hanya perlu mendapatkan informasi itu saja, Pak. Karena sudah waktunya Bapak kembali bekerja setelah jam istirahat, tampaknya kami harus pamit dulu. Terima kasih atas waktu dan infornasinya,Pak..

PA : Yah sama-sama, semoga sukses tugas Anda.

ZAA & HDK : Assalamu’alaikum

PA: Wa’alaikumsalam

164