PARADIGMA VOL. XVII. September 2015
SISTEM INFORMASI HASIL MEDICAL CHECK UP NASABAH ASURANSI JIWA INDIVIDU PADA PT. EQUITY LIFE INDONESIA
Popi Ismayanti AMIK BSI Tangerang Bumi Serpong Damai Sektor XIV Blok C1/1, Jl. Letnan Sutopo BSD Serpong, Tangerang Selatan
ABSTRAK Manusia saat ini secara ekonomi dituntut agar mengadakan persiapan secara matang untuk menghadapi masa-masa sulit jika menimpanya di masa yang akan datang. Praktik asuransi ataupun bisnis pertanggungan yang lain akan memudahkan seseorang untuk menyiapkan dan merencanakan kehidupannya dimasa mendatang dan dapat melindungi kepentingan ekonominya dari sebuah kerugian yang tidak terduga. Untuk menanggulangi kerugian atas resiko yang tidak pasti itu, banyak orang terlebih kalangan bisnis berusaha untuk menanggulanginya, artinya berupaya untuk meminimumkan ketidakpastian agar kerugian yang ditimbulkan dapat dihilangkan atau paling tidak diminimumkan.Untuk asuransi jiwa individu PT. Equity Life Indonesia penelitian data hasil medical check up nasabah masih berjalan secara manual, sehingga lebih banyak memakan waktu. Pengolahan data yang lambat dapat menyebabkan kegiatan operasional perusahaan tidak berjalan dengan semestinya. Untuk mempermudah dan mempercepat proses pengolahan data maka diperlukan suatu program pengolahan data yang menggunakan komputer sebagai alat bantu, sehingga informasi yang didapat lebih cepat,tepat dan mudah. Dengan didukung oleh perangkat lunak yang tepat maka komputer akan memberikan hasil yang maksimal dan menghasilkan informasi yang akurat dan berkualitas tinggi. Kata Kunci : Sistem Informasi, Medical Check Up, Asuransi Jiwa
I.
PENDAHULUAN
Asuransi jiwa pada saat ini semakin berkembang pesat, kesadaran masyarakat tentang pentingnya asuransi lambat laun mulai meningkat.Manusia saat ini secara ekonomi dituntut agar mengadakan persiapan secara matang untuk menghadapi masa-masa sulit jika menimpanya di masa yang akan datang. Praktik asuransi ataupun bisnis pertanggungan yang lain akan memudahkan seseorang untuk menyiapkan dan merencanakan kehidupannya dimasa mendatang dan dapat melindungi kepentingan ekonominya dari sebuah kerugian yang tidak terduga. Untuk menanggulangi kerugian atas resiko yang tidak pasti itu, banyak orang terlebih kalangan bisnis berusaha untuk menanggulanginya, artinya berupaya untuk meminimumkan ketidakpastian agar kerugian yang ditimbulkan dapat
70
dihilangkan atau paling tidak diminimumkan. Menurut Buliali, dkk (2007:97) menyatakan pencatatan data riwayat kesehatan pasien adalah hal yang penting dalam dunia medis dan dikenal dengan istilah data rekam medis. Selama pasien melakukan pemeriksaan atau menjalani perawatan medis oleh dokter atau suatu instansi medis, maka status kesehatan pasien akan dicatat sebagai data rekam medis pasien. Data rekam medis pasien tersebut dapat dipakai sebagai acuan untuk pemeriksaan kesehatan pasien selanjutnya, sekaligus sebagai bukti tercatat mengenai diagnosis penyakit pasien dan pelayanan medis yang diperoleh pasien. Tetapi sistem rekam medis yang dipakai selama ini masih memiliki kelemahan,karena data rekam medis pasien hanya tersimpan secara lokal di tempat dimana pasien tersebut menjalani pemeriksaan dan perawatan medis dan antar tempat tidak memungkinkan pertukaran data secara langsung. Oleh sebab itu untuk
PARADIGMA VOL. XVII. September 2015
mempermudah system pencatatan rekam medis maka menggunakan Microsoft.net.
II. TINJAUAN PUSTAKA Menurut Wahid (2010) Rekam medik merupakan berkas yang berisikan catatan dan dokumen tentang identitas pasien, pemeriksaan, pengobatan, tindakan dan pelayanan lain kepada pasien pada sarana pelayanan kesehatan.Rekam Medik harus dibuat secara tertulis, lengkap dan jelas dan dalam bentuk teknologi Informasi elektronik yang diatur lebih lanjut dengan peraturan tersendiri.Manfaat dari rekam medik elektronik/digital, yaitu: Kemudahan penelusuran dan pengiriman informasi, Bisa dikaitkan dengan informasi lain yang berasal dari luar rekam medik, Penyimpanan lebih ringkas, data dapat ditampilkan dengan cepat sesuai kebutuhan, Abstraksi pelaporan lebih mudah bahkan otomatis, Kualitas data dan standar dapat dikendalikan, Dapat diintegrasikan dengan perangkat lunak pendukung keputusan. Menurut Giyana (2012:49) Salah satu parameter untuk menentukan mutu pelayanan kesehatan di rumah sakit adalah data informasi dari rekam medis yang baik dan lengkap. Indikator mutu rekam medis yang baik adalah kelengkapan isi, akurat, tepat waktu.pengelolaan rekam medis di rumah sakit adalah untuk menunjang tercapainya tertib administrasi. Dalam pengelolaan rekam medis untuk menunjang mutu pelayanan bagi rumah sakit, pengelolaan rekam medis harus efektif dan efisien. Dari hasil survey pendahuluan didapatkan bahwa pengelolaan rekam medis di RSUD Kota Semarang belum berjalan optimal (Permenkes No. 269/MENKES/PER/III/2008 pasal 15), yaitu pengelolaan belum sesuai dengan tata kerja dan organisasi sarana pelayanan kesehatan. Terbukti dari dokumen rekam medis tidak tepat waktu dan tidak lengkap.Tujuan dari penelitian ini adalah untuk menganalisis sistem pengelolaan rekam medis pasien rawat inap di RSUD Kota Semarang. Oleh sebab itu RSUD kota Semarang tersebut menggunakan teknik assembling , koding, indeksing, filling dan analising.
A.
WATERFALL
Menurut Rosa dan Shalahuddin (2013a:28), Model SDLC air terjun (waterfall ) seringjuga disebut model sekuensial linier ( sequentiallinear) atau alur hidup klasik (classic life cycle ). Model air terjun menyediakan pendekatan alur hidup perangkat lunak secara sekuensial atau terurut dimulai dari analisis, desain, pengodean, pengujian, dan tahap pendukung ( support). Berikut adalah gambar model air terjun :
Sistem/ Rekayasa Informasi
Analisis
Desain
Pengodean
Pengujian
Gambar II.1Gambar Water fall Sumber Rosa dan Shalahuddin (2013)
Gambar di atas adalah tahapan umum dari model proses ini. Berikut adalah penjelasan dari tahap-tahap yang dilakukan (Rosa dan Shalahuddin,2013b:28). 1. Analisis Kebutuhan Perangkat Lunak Proses pengumpulan kebutuhan dilakukan secara intensif untuk menspesifikasikan kebutuhan perangkat lunak agar dapat dipahami perangkat lunak seperti apa yang dibutuhkan oleh user. Spesifikasi kebutuhan perangkat lunak pada tahap ini perlu untuk didokumentasikan. 2. Desain Desain perangkat lunak adalah proses multilangkah yang focus pada desain pembuatan program perangkat lunak termasuk struktur data,arsitektur perangkat lunak,representasi antarmuka, dan prosedur pengodean. Tahap ini mentranlasi kebutuhan perangkat lunak dari tahap analis kebutuhan ke representasi desain agar dapat didimplementasikan menjadi program pada tahap selanjutnya.Desain perangkat lunak yang dihasilkan pada tahap ini juga perlu didokumentasikan.
71
PARADIGMA VOL. XVII. September 2015
3. Pembuatan Kode Program Desain harus ditranslasikan kedalam program perangkat lunak. Hasil dari tahap ini adalah program computer sesuai dengan desain yang telah dibuat pada tahap desain 4. Pengujian Pengujian focus pada perangkat lunak secara dari segi lojik dan fungsional dan memastikan bahwa semua bagian sudah diuji. Hal ini dilakukan untuk meminimalisir kesalahan (error) dan memastikan keluaran yang dihasilkan sesuai dengan yang diinginkan. 5. Pendukung (support ) atau pemeliharaan (maintenance ) Tidak menutup kemungkinan sebuah perangkat lunak mengalami perubahan ketika sudah dikirimkan ke user.Perubahan bisa erjadi karena adanya kesalahan yang muncul dan tidak terdeteksi saat pengujian atau perangkat lunak harus beradaptai dengan lingkungan baru. Tahap pendukung atau pemeliharaan dapat mengulangi proses pengembangan mulai dari analisis spesifikasi untuk perubahan perangkat lunak yang ada, tapi tidak untuk membuat perangkat lunak baru.
4.
5.
6.
7.
8. B.
OOP (Object Oriented Programming)
Menurut Rosa dan Shalahuddin (2013d:104-110).Berikut ini adalah beberapa konsep dasar yang harus dipahami tentang metodologi berorientasiobjek : 1. Kelas (class) Kelas adalah kumpulan objek-objek dengan karakteristik yang sama. Kelas merupakan definisi static dan himpunan objek yang sama yang mungkin lahir atau diciptakan dan kelas tersebut 2. Objek (object) Objek adalah abstraksi dan sesuatu yang mewakili dunia nyata seperti benda, manusia , satuan organisasi, tempat , kejadian , struktur , status atau hal-hal yang bersifat abstrak. 3. Metode (method) Operasi atau metode atau methodpada sebuah kelas hampir sama dengan fungsi atau prosedur pada metodologi struktural. Sebuah kelas boleh memiliki lebih dari satu metode atau operasi.Metode atau operasi yang berfungsi untuk memanipulasi objek itu sendiri.Operasi atau metode merupakan fungsi atau transformasi
72
9.
C.
yang dapat dilakukan terhadap objek atau dilakukan oleh objek. Atribut (attribute) Atribut dari suatu kelas adalah variabel global yang dimiliki sebuah kelas.Atribut dapat berupa nilai atau elemen-elemen data yang dimiliki oleh objek dalam kelas objek.Atribut dapat berupa nilai atau elemen-elemen data yang dimiliki oleh objek dalam kelas objek. Abstraksi (abstraction) Prinsip untuk merepresentasikan dunia nyata yang kompleks menjadi satu bentuk model yang sederhana dengan mengabaikan aspek-aspek lain yang tidak sesuai dengan permasalahan. Enkapsulasi (encapsulation) Pembungkusan atribut data dan layanan (operasi-operasi) yang dipunyai objek untuk menyembunyikan implementasi dan objek sehingga objek lain tidak mengetahui cara kerjanya. Pewarisan (inheritance) Mekanisme yang memungkinkan satu objek mewarisi sebagian atau seluruh definisi dan objek lain sebagai bagian dan dirinya. Polimorfisme (polymorphism) Kemampuan suatu objek untuk digunakan di banyak tujuan yang berbeda dengan nama yang sama sehingga menghemat baris program. Package Package adalah sebuah container atau kemasan yang dapat digunakan untuk mengelompokkan kelas-kelas sehingga memungkinkan beberapa kelas yang bernama sama disimpan dalam package yang berbeda. UML (Unified Modelling Language)
Menurut Rosa dan Shalahuddin (2011a:113) “UML (Unified Modelling Language) adalah salah satu standar bahasa yang banyak digunakan didunia industry untuk mendefinisikan requirement, membuat analisis dan desain, serta menggambarkan arsitektur dalam pemrograman berorientasi objek”. Sedangkan menurut Sugiarti (2013:1) “UML(Unified Modelling Language)adalah sebuah bahasa yang telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasi sistem piranti lunak.UML menawarkan sebuah standar untuk merancang model sebuah sistem”.
PARADIGMA VOL. XVII. September 2015
Berikut ini adalah penjelasan mengenai berbagai diagram UML serta tujuannya: 1. Use Case Diagram Menurut Rosa dan Salahuddin (2011b:130) use case merupakan oermodelan untuk kelakuan(behavior) sistem informasi yang akan dibuat.Use case mendeskripsikan sebuah interaksi antara satu atau lebih actor dengan sistem informasi yang akan dibuat. Secara kasar, use case digunakan untuk mengetahui fungsi apa saja yang ada di dalam sebuah sistem informasi dan siapa saja yang berhak menggunakan fungsi-fungsi itu. 2. Activity Diagram Diagram aktivitas atau activity diagram menggambarkan workflow (aliran kerja) atau aktivitas dari sebuah sistem atau proses bisnis (Rosa dan Salahuddin 2011c:134) Yang perlu diperhatikan disini adalah bahwa diagram aktivitas menggambarkan aktivitas sistem bukan apa yang dilakukan aktor, jadi aktivitas yang dapat dilakukan oleh sistem. Diagram aktivitas mendukung perilaku paralel. Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masingmasing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi (Sugiarti: 2013:74) 3. Component Diagram Menurut Rosa dan Salahuddin (2011d:125) Diagram komponen atau component diagram dibuat untuk menunjukan organisasi dan ketergantungan di antara kumpulan komponen dalam sebuah sistem. Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time, Umumnya komponen terbentuk dari beberapa class dan atau package, tapi dapat juga dari komponenkomponen yang lebih kecil. 4. Deployment Diagram Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur system, dimana komponen akan terletak (pada mesin, server, atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi
tersebut, spesifikasi server, dari hal-hal lain yang bersifat fisikal menurut (Sugiarti: 2013b:80). D.
ERD (Entity Relationship Diagram)
Menurut Marlinda (2004a:17) Model ERD merupakan suatu model untuk menjelaskan hubungan antar data dalam basis data berdassarkan suatu persepsi bahwa real world terdiri dari object- object dasar yang mempunyai hibungan atau relasi antar object- object tersebut.
III. METODE PENELITIAN 1.
2.
3.
Metode Pengamatan atau Observasi Menggunakan metode ini dengan menguji hasil dari permasalahan dengan mencari banyak referensi yaitu dengan melakukan pengamatan dan menganalisa langsung pada seluruh kegiatan analisa resiko pada asuransi jiwa individu di PT. Equity Life Indonesia. Wawancara Melakukan wawancara secara langsung dengan Christina Sihaloho selaku user,Dr. Hendrikus Darmawan selaku dokter yang menganalisa hasil medical check up, dan Manager Underwriting Bapak Endy S. Tjen selaku pemberi keputusan akhir hasil medical check up, untuk menanyakan mengenai proses pengolahan data hasil medical check up bagaimana sistem itu diperlukan, sehingga diperoleh data yang akurat dan membantu memberikan keterangan-keterangan yang diperlukan. Metode Kepustakaan Penelitian ini ditunjang oleh beberapa buku-buku yang berisi teori-teori yang berkaitan dengan masalah yang dibahas serta catatan-catatan kuliah dan penunjang lainnya. Pada metode ini peneliti mendapat banyak bahan masukan tentang bagaimana merancang atau mengembangkan suatu sistem informasi menurut para ahlinya. Pada metode ini peneliti membuka, mengambil dan mengutip dari beberapa kutipan para ahli yang berdasarkan dari buku referensi dan juga berdasarkan dari jurnal ilmiah nasional.
73
PARADIGMA VOL. XVII. September 2015
A.
HASIL DAN PENELITIAN
PEMBAHASAN
1.
Tahap Analisis Sistem baru berbasis dekstop dimana staff,dokter, dan Manager dapat mengakses data hasil medical check up dari nasabah asuransi. Berikut ini spesifikasi kebutuhan (system requirement) dari sistem aplikasi dekstop.
b.
pkg Use Case Model Melihat data nasabah asuransi
Halaman Staff : A1.Staff dapat login dan input data nasabah asuransi A2.Staff dapat login dan input data hasil medical check up A3.Staff dapat login dan melihat keputusan medical check up Halaman Dokter : B1. Dokter dapat login dan melihat data nasabah asuransi B2. Dokter dapat login dan melihat data hasil medical check up B3. Dokter dapat login dan memberikan keterangan hasil analisa medical check up 2. a.
Package Diagram Package Diagram Sistem Informasi Staff
Package Diagarm Sistem Informasi Dokter
melihat data hasil medical check up
Memberikan Keterangan hasil analisa medical check up
Gambar III.2. Package Diagram Use Case Halaman Dokter 3. a.
Usecase Diagram Usecase Diagram Halaman Registrasi Nasabah
uc Use Case Diagram Registrasi Nasabah
pkg Use Case Model Input Data Nasabah Asuransi
Lihat status pengajuan «extend» Lihat Lihat Daftar Daftar Nasabah Nasabah
Input Data Hasil Medical Check Up
Staff Mengisi Biodata Nasabah «include»
Mendaftarkan nasabah
«include» Mengisi Data Asuransi Nasabah
Melihat Keputusan Hasil Medical check up «include» «include»
Mengisi Data Hasil medical Check Up
Gambar III.1. Package Diagram Use Case Halaman Staff
Upload Hasil Scan Medical
Gambar III.3. Use Case Diagram Halaman Registrasi Nasabah
74
PARADIGMA VOL. XVII. September 2015
b. Tabel III.1. Deskripsi Use Case Diagram Registrasi Data Nasabah Use Case Name Requirements Goal
Pre-Conditions
Post-Conditions
Failed end condition Primary Actors Main Flow / Basic Path
Invariant
User A1-A3 Staff dapat input data hasil nasabah,data medical check up, dan melihat hasil analisa data hasil medical check up Staff mengetahui data nasabah, data hasil medical dan scan hasil medical nasabah Staff dapat mengetahui hasil analisa dokter dan keputusan terakhir pengajuan asuransi Staff batal melihat informasi Staff 1. Staff login 2. Staff dapat menginput data nasabah 3.Staff dapat menginput hasil medical check up nasabah 4. Staff dapat menscan hasil medical check up 4. Staff dapat melihat analisa hasil medical check up nasabah 5. Staff dapat melihat keputusan akhir hasil medical check up nasabah -
Use Case Diagram Analisa Hasil Medical Check Up
uc Use Case Diagram Analisa Hasil Medical Check up
Melihat daftar nasabah
Melihat Status Pengajuan
«extend»
«extend»
Dokter
Memeriksa data nasabah
«include»
Meninjau hasil Medical check Up nasabah
«extend»
«extend»
«extend» Memberikan Komentar Medis nasabah
Melihat hasil scan Medical nasabah
Gambar III.4. Use Case Diagram Analisa Hasil Medical Check Up Tabel III.2. Deskripsi Use Case Analisa Hasil Medical Check Up Menganalisa hasil Use Case name medical check up B1-B3 Requirments Goal
Pre-Conditions Post-Conditions
Failed end Condition Primary Actors
Dokter dapat menganalisa data hasil medical check uo nasabah Dokter telah login Hasil analisa data medical check up tersimpan, teredit atau terhapus Gagal menyimpan, mengedit atau menghapus Dokter
75
PARADIGMA VOL. XVII. September 2015
1. Dokter login 2.Dokter dapat melakukan analisa hasil medical check up nasabah 5. Dokter dapat memberikan Diagnosa Penyakit / Keterangan hasil medical -
Main Flow/Basic path
Invariant c.
menghapus Primary Actors
Manager
Main Flow/Basic path
1. Manager dapat melihat data nasabah asuransi 2. Manager dapat melihat hasil analisa dokter 3. Manager dapat memberikan keputusan akhir dari hasil analisa data medical check up 4. Manager dapat menambahkan data staff / employee baru di sistem
Usecase Diagram Pengajuan Penerimaan Asuransi Nasabah
uc Use Case Diagram Approv al Data Hasil Medical Nasabah
melihat Daftar Nasabah
«extend»
«extend»
Manager
Melihat Status Pengajuan
Memeriksa Data Medical Check Up Nasabah «include»
Memeriksa Data Nasabah
«include» «extend»
Mempertimbangkan Komentar Dokter
Menerima Pengajuan Asuransi Nasabah
4. a.
Activity Diagram Activity Diagram Halaman Registrasi Data Nasabah
«extend»
Mendaftarkan Staff Baru
Gambar III.5. Use Case Diagram Pengajuan Penerimaan Asuransi Nasabah Tabel III.3 Deskripsi use case Pengajuan penerimaan asuransi nasabah Pengajuan Use Case name penerimaan asuransi nasabah B2 Requirments Goal
Pre-Conditions Post-Conditions
Failed end Condition
76
Manager dapat memberikan keputusan akhir pengajuan asuransi Manager telah login Daftar nasabah tersimpan, teredit atau terhapus Gagal menyimpan, mengedit atau
Gambar III.6. Activity Diagram Halaman Registrasi Data Nasabah
PARADIGMA VOL. XVII. September 2015
b.
Activity Diagram Medical Check Up
Analisa
Hasil
Entity Relationship Diagram
5. HIV HIV
Customer_pack Customer_pack Customer Customer etetduration duration packet packetmoney money
Treadmill Treadmill Manager_date Manager_date Manager_time Manager_time
HbsAg HbsAg
AFP AFP
Kolesterol Kolesterol
Trigliserida Trigliserida
Thorax Thorax
Customer_insur Customer_insurCustomer_empl Customer_empl ance oyee ance oyeeidid
Doctor_comme Doctor_comme Manager_comm Manager_comm ntnt
EKG EKG
Fx_Ginjal Fx_Ginjal
Gula_darah Gula_darah
Urine_Lengkap Urine_Lengkap
Fx_hati Fx_hati
Tensi Tensi
Darah Darahlengkap lengkap
Customerhealth Customerhealth _takendate _takendate
Taken_At Taken_At
Doctor_time Doctor_time
Doctor_date Doctor_date
Approval_statu Approval_statu sscustomer customer
Approval Approval SPAJ_id SPAJ_id
SPAJ_id SPAJ_id
Customers_id Customers_id
Customer_insurance
Memiliki
1
M
1 M
Approvalstatus Approvalstatus As_customer As_customer
Approval_Status 1 Mendaftar
Ch_Customer Ch_Customer Customerhealt_ID Customerhealt_ID Insurance Insurance
Memiliki
Customerhealth
1
1
Employee
Memiliki 1 1
1
Memiliki
1
Customer
Customer_nam Customer_nam Customer_id Customer_id ee
Memiliki
Emp_na Emp_na Employee_id Employee_id me me Employee_co Employee_co Emp_po Emp_po ntact sition ntact sition
Insurance_details Familyhistory
Family_id Family_id
Gambar III.7. Activity Diagram Analisa Hasil Medical Check Up c.
Family_custom Family_custom erer
Family_name Family_name Family_relation Family_relation Family_healths Family_healths Family_age Family_age
Activity Diagram Keputusan Akhir Hasil Medical Check Up
Family_health Family_health
Customer_born Customer_born Customer_age Customer_age
Employee_br Employee_br anch anch
Insurance Insurance Insurance Insurance Customer_gend Customer_gend Customer_job idid name Customer_job name erer Customer_heig Customer_weig Customer_weig Customer_heig htht htht
Insurance Insurance details details
Customer_smo Customer_over Customer_over Customer_smo keke underweight underweight Customer_habb Customer_habb Customer_drink itit Customer_drink Customer_insur Customer_insur ance ance
Gambar III.9. Entity Relationship Diagram
IV. KESIMPULAN DAN SARAN A. 1.
2. Gambar III.8. Activity Diagram Keputusan Akhir Hasil Medical Check Up
KESIMPULAN Sistem informasi hasil medical check up nasabah asuransi jiwa individu ini merupakan aplikasi sistem komputerisasi yang dibuat berbasis desktop dan memuat database pengolahan data hasil medical check up secara terpusat sehingga dapat mengelola database tersebut menjadi informasi yang dibutuhkan oleh staff,dokter dan manager. Sistem Informasi hasil medical check up nasabah asuransi jiwa individu berbasis desktop pada PT. Equity Life Indonesia memiliki beberapa keuntungan, sebagai berikut a. User dapat input data hasil medical check up ,menganalisa data hasil medical check up dan memberikan keputusan akhir data hasil medical check up b. Diharapkan dapat meningkatkan efisiensi dan efektifitas dalam 77
PARADIGMA VOL. XVII. September 2015
proses pekerjaan dan dokumentasi data. B.
SARAN
Berdasarkan kesimpulan diatas, maka peneliti bermaksud memberikan saran sebagai alternative pemikiran dengan harapan agar aspek ilmu pengetahuan tidak bersifat monoton dan terpaku pada disiplin dari ilmu pengetahuan itu sendiri. 1. Aplikasi desktop yang telah dibuat hendaknya dioperasikan secara baik dan benar untuk mencapai tujuan yang diharapkan. 2. Untuk meningkatkan kinerja serta untuk mengembangkan aplikasi ini maka sebaiknya diadakan pengembangan aplikasi mulai dari tampilan halaman sampai dengan maintenance-nya. 3. Memberikan pelatihan terhadap pegawai yang akan menjalankan sistem yang baru ini agar dapat mengerti sistem dengan baik saat bekerja.
V.
DAFTAR PUSTAKA
Adipratomo Wahid. 2010. Sistem Pencatatan Rekaman Medik Secara Digital Vol 1, No 2 - Tahun 2012 http://jurnal.ptkbaceh.ac.id/index.p hp/stie/article/view/40 Frenti,
Giyana. 2012. Analisis Sistem Pengelolaan Rekam Medis Rawat Inap Rumah Sakit Umum Daerah Kota Semarang. Vol 1, No 2 - Tahun 2012 Hal 48-61 http://ejournals1.undip.ac.id/index. php/dbr
Joko Lianto Buliali. 2007. Sistem Pencatatan Informasi Medis berbasis Teknologi Microsoft. Net). Vol. 3, Nomor 1. Juni 2007 97-118: http://ejurnal.its.ac.id/index.php/rek aintegra/article/view/202. Marlinda, Linda. 2004. Sistem Basis Data. Yogyakarta : Andi. Rosa,
78
Shalahuddin. 2011. Modul Pembelajaran Rekayasa Perangkat Lunak (Terstruktur dan Berorientasi Objek). Bandung : Modula.
