DOKUMEN PENGEMBANGAN PROYEK

II3240 REKAYASA SISTEM TEKNOLOGI INFORMASI

SMART HEALTH CARE

Disusun Oleh:

1. Rezki Khairunnas (18214002)

2. Muh Aji Ismail (18214036)
3. Feisal Ramadhan Maulana (18214040)

PROGRAM STUDI SISTEM DAN TEKNOLOGI INFORMASI

INSTITUT TEKNOLOGI BANDUNG

2017
 TIM PROYEK

Feisal Ramadhan Maulana Penulis merupakan salah satu mahasiswa

Program Studi Sistem dan Teknologi Informasi, Sekolah Teknik Elektro
dan Informatika di Institut Teknologi Bandung. Saat ini penulis sedang
menempuh pendidikan semester 6. Penulis aktif berkegiatan di organisasi
kemahasiswaan universitas dan juga merupakan ketua dari unit
kebudayaan Banten yang ada di ITB.

Email : feisalramadhanm@gmail.com (+62 857 7444 5565)

Muh Aji Ismail adalah salah satu nama penulis makalah ini. Penulis lahir
di Ujung Pandang 28 April 1996. Sejak kecil penulis menempuh pendidikan
di Kota Makassar hingga di bangku SMA dimulai dari TK Dharma
Wanita(lulus tahun 2002), SD Nusantara (lulus tahun 2008), SMP
Nusantara (lulus tahun 2011), SMA Negeri 17 Makassar (lulus tahun 2014).
Pada saat duduk di bangku kuliah ia pergi ke Kota Bandung dan menempuh
pendidikan sarjana di Institut Teknologi Bandung pada program studi Sistem dan Teknologi
Informasi. Penulis dapat dihubungi melalui alamat e-mail muh.ajiismail@gmail.com

Rezki Khairunnas merupakan salah satu mahasiswa Program Studi Sistem

dan Teknologi Informasi, Sekolah Teknik Elektro dan Informatika di Institut
Teknologi Bandung. Saat ini penulis sedang menempuh pendidikan
semester 6.

Email : rezki_khairunnas@yahoo.com
 RINGKASAN

Rekam medis adalah hal yang sangat krusial pada bidang kedokteran. Rekam medis
menunjukkan riwayat kesehatan seseorang. Pemeriksaan yang dilakukan oleh dokter harus
mempertimbangkan rekam medis yang ada agar tidak salah dalam melakukan diagnosa. Setiap
dokter ataupun dokter gigi diharuskan melakukan rekam medis kepada pasiennya.

Seringkali rekam medis dicatat dengan pencatatan manual. Hal tersebut dirasa tidak
efektif dan efisien dari segi sumber daya yang digunakan, usaha dalam melakukan pencatatan,
dan efisiensi dalam melacak kembali rekam medis. Untuk itu kami menyediakan solusi yaitu
proyek smart health card. Proyek ini memanfaatkan aplikasi mobile yang akan membaca suatu
barcode pada kartu dan mengambil data rekam medis pasien pada berdasarkan data pada barcode
tersebut.

Kami mengimplementasikan proyek ini dengan memanfaatkan web service API dalam
melakukan pengolahan database secara cloud. Pada aplikasi mobile-nya kami memanfaatkan
barcode API yang disediakan oleh Mobile Vision. Kami juga akan melakukan standarisasi rekam
medis agar hasil dari proyek ini dapat diimplementasikan di Indonesia.

Metode rekayasa yang kami gunakan adalah metode waterfall. Langkah-langkah yang
dilaksanakan adalah inisiasi proyek, perencanaan dan desain proyek, implementasi proyek,
testing dan sosialisasi, dan penutupan Proyek. Proyek ini dimulai pada bulan Januari tahun 2017
dan selesai pada akhir bulan April tahun 2017.
 DAFTAR ISI

TIM PROYEK.............................................................................................................................................i
RINGKASAN.............................................................................................................................................ii
DAFTAR ISI..............................................................................................................................................iii
DAFTAR TABEL........................................................................................................................................v
DAFTAR GAMBAR..................................................................................................................................vi
BAB I DESKRIPSI SISTEM KOMPLEKS.............................................................................................1
1.1. Alasan Pemilihan Berdasarkan Problem Operasional/Opportunity Teknologi.............................1
1.2. Hasil Akhir yang Akan Dicapai...................................................................................................2
1.2.1. Tujuan..................................................................................................................................2
1.2.2. Manfaat................................................................................................................................2
1.3. Deskripsi Subsistem CPSS..........................................................................................................2
1.4. Hirarki Sistem..............................................................................................................................3
BAB II NEEDS ANALYSIS PHASE..........................................................................................................4
2.1 Sasaran Operasional.....................................................................................................................4
2.2 Fungsi Subsistem.........................................................................................................................4
2.3 Feasible Concept System.............................................................................................................5
2.3.1. Visualization of Subsystem Implementation.........................................................................5
2.3.2. Definition of a Feasible Concept.........................................................................................6
2.3.3. Operational Requirements...................................................................................................7
BAB III - Concept Exploration Phase.......................................................................................................10
3.1 Refined Operational Requirements............................................................................................10
3.1.1. Projected Need Analysis.....................................................................................................10
3.1.2. Performance Parameters...................................................................................................12
3.1.3. Performance Requirements................................................................................................13
3.1.4. Performance Characteristic...............................................................................................14
BAB IV CONCEPT DEFINITION PHASE............................................................................................16
4.1 Refined Performance Requirements...........................................................................................16
4.2 Preliminary Functional Design..................................................................................................19
4.3 Concept Effectiveness................................................................................................................20
4.3.1. Alternatif konstruksi pencatatan rekam medis...................................................................20
4.3.2. Alternatif konstruksi pendaftaran pasien............................................................................21
 4.3.3. Alternatif konstruksi pengambilan obat menggunakan resep dokter..................................22
BAB V ADVANCED DEVELOPMENT PHASE.....................................................................................24
5.1 Candidate Component for Development....................................................................................24
5.2 Functional Design.....................................................................................................................25
5.4.1 Functional Requirement.....................................................................................................25
5.4.2 Use Case Smart Health Care System.................................................................................25
5.4.3 Actor Definition Smart Health Care System.......................................................................26
5.2.4 Use Case Definition Smart Health Care System................................................................26
5.2.5 Non Functional Requirement.............................................................................................27
5.3 Critical Component and Design Deficiencies............................................................................28
5.4.1 System Component............................................................................................................28
5.4.2 General Boundaries............................................................................................................30
5.4.3 Operational Environment...................................................................................................30
5.4.4 Assumption and Dependency.............................................................................................32
5.4 Validated Design........................................................................................................................33
5.4.1 Prototype Development......................................................................................................33
5.4.2 Development Testing..........................................................................................................33
DAFTAR REFERENSI.............................................................................................................................35
 DAFTAR TABEL

Tabel 1 Visualisasi Implementasi Subsistem...............................................................................................5

Tabel 2 Parameter Kinerja...........................................................................................................................7
Tabel 3 Pengukuran Keefektifan..................................................................................................................8
Tabel 4 Pengukuran Performa......................................................................................................................9
Tabel 5 Parameter Kinerja.........................................................................................................................12
Tabel 6 Kebutuhan Kinerja........................................................................................................................13
Tabel 7 Performance Requirements...........................................................................................................16
Tabel 8 Refined Performance Requirements..............................................................................................17
Tabel 9 Preliminary Functional Design.....................................................................................................19
Tabel 10 Penilaian Perbandingan Alternatif Konstruksi Pencatatan Rekam Medis....................................21
Tabel 11 Penilaian Perbandingan Alternatif Konstruksi Pendaftaran Pasien..............................................22
Tabel 12 Penilaian Perbandingan Alternatif Konstruksi Pengambilan Obat Menggunakan Resep Dokter 23
Tabel 13 Candidate Component for Development.....................................................................................24
Tabel 14 Functional Requirement..............................................................................................................25
Tabel 15 Actor Definition..........................................................................................................................26
Tabel 16 Use Case Definition....................................................................................................................27
Tabel 17 Non Functional Requirement......................................................................................................27
Tabel 18 Critical Component of System....................................................................................................28
Tabel 19 Development Test.......................................................................................................................33
 DAFTAR GAMBAR

Gambar 1 Hirarki Sistem Smart Health Care...............................................................................................3

Gambar 2 Functional Block Diagram........................................................................................................20
Gambar 3 Use Case Smart Health Care.....................................................................................................26
0
 BAB I DESKRIPSI SISTEM KOMPLEKS

Smart Health Care adalah sebuah sistem pelayanan rumah sakit yang terotomatisasi yang
menggunakan konsep Internet of Things (IoT). Smart Health Care memungkinkan rumah sakit
untuk memberikan pelayanan yang lebih baik pada pasien. Sistem ini mencakup beberapa sistem
yang ada di rumah sakit, salah satunya adalah pencatatan rekam medis pasien.

Smart Health Care memiliki solusi, yaitu sebuah smart card. Apabila sistem ditinjau
berdasarkan sudut pandang Cyber-Physical-Social System (CPSS), maka sistem dapat dipecah
menjadi tiga bagian, yaitu:

Cyber. Adanya pertukaran informasi dan data melalui jaringan internet. Informasi
atau data selain tersimpan dalam smart card, juga disimpan dan di-maintain dalam
server.
Physical. Sistem berinteraksi melalui elemen fisik, yaitu smart card, reader/scanner,
dan perangkat lainnya.
Social. Smart card akan menjadi media komunikasi antara pasien, administrator
rumah sakit, dokter, dan pihak berkepentingan lainnya.

1.1. Alasan Pemilihan Berdasarkan Problem Operasional/Opportunity Teknologi

Penerapan smart health care ini merupakan suatu langkah maju dalam
mengimplementasikan konsep smart city. Kesehatan selain menjadi salah satu faktor utama yang
harus diperhatikan dalam rangka mensejahterakan masyarakat, juga menjadi hal yang paling
penting untuk seseorang. Tanpa adanya kesehatan, aktivitas seseorang dapat terganggu sehingga
menyebabkan menurunnya produktifitas seseorang.

Saat ini, hampir seluruh rumah sakit di Indonesia masih melakukan pencatatan rekam
medis pasien secara manual. Hal ini terbukti kurang efisien dikarenakan dalam keadaan genting,
sering terjadi kendala-kendala yang dapat menghentikan atau menghalangi perawatan pada
pasien. Kesalahan pada rekam medis juga dapat menyebabkan kesalahan fatal yang berujung
pada kematian pasien. Berikut kendala-kendala yang sering terjadi.

1
 Ketika pasien tidak sadar, maka pihak rumah sakit akan kesulitan untuk mendapatkan
rekam medis pasien.
Pasien kebingungan menjelaskan rekam medisnya.
Perbedaan bahasa yang menyebabkan komunikasi tidak dapat berjalan dengan baik.

Selain didukung masalah-masalah di atas, perkembangan teknologi yang memungkinkan

penyimpanan data atau informasi pada server dan chip, menjadi faktor utama dapat
dikembangkannya sistem smart health care ini untuk mensejahterakan masyarakat.

1.2.Hasil Akhir yang Akan Dicapai

1.2.1. Tujuan
Tujuan utama dari pengembangan sistem smart health care ini adalah untuk
meningkatkan kulaitas pelayanan kesehatan.

1.2.2. Manfaat
Manfaat yang diharapkan dari pengembangan sistem ini adalah berkurangnya human
error dalam pelayanan kesehatan, memudahkan administrasi dan pengaksesan rekam medis oleh
pihak bersangkutan, hingga meningkatkan kualitas pelayanan kesehatan.

1.3. Deskripsi Subsistem CPSS

Berikut merupakan subsistem dari sistem smart health care.

Pencatatan rekam medis.

Pencatatan rekam medis mencatat seluruh riwayat penyakit dan pemeriksaan pasien.
Pendaftaran pasien.
Mencatat identitas pasien termasuk informasi mengenai jaminan kesehatan.
Pengambilan obat berdasarkan resep dokter
Informasi mengenai pengambilan obat juga akan dicatat termasuk keterangan obat,
tanggal pengambilan, dan keterangan dokter yang memberikan resep.

2
1.4. Hirarki Sistem
Berikut adalah hirarki dari sistem CPPS yang kami rancang.

Smart Health Care

Pencatatan Rekam
Pendaftaran Pasien Pengambilan Obat
Medis

Informasi
Informasi Informasi
Pengambilan Obat
Pemeriksaan (Hasil Pendaftaran Pasien
(Resep dokter,
Informasi Dokter Pemeriksaan dan (Tanggal, Jaminan
Tanggal
Tanggal Kesehatan,
Pengambilan,
Pemeriksaan) Identitas, dll)
Informasi Dokter)

Gambar 1 Hirarki Sistem Smart Health Care

3
 BAB II NEEDS ANALYSIS PHASE

2.1 Sasaran Operasional

Dalam upaya memperjelas sasaran operasional dari smart health care, maka akan
dilakukan pendefinisian kondisi akhir dari skenario sistem, tujuan sistem dan pengatur kepuasan
sistem, serta alasan kebutuhan sistem.

1. End State of Scenario

Dengan adanya sistem smart health care, rumah sakit dapat memberikan pelayanan
kesehatan yang baik pada pasien, juga memudahkan rumah sakit dalam mengelola
kegiatan operasionalnya. Selain itu, sistem ini juga diharapkan dapat meminimalisir
human error yang dapat berakibat fatal bagi pasien dan rumah sakit.

2. Purpose of The System

Tujuan dari sistem smart health care adalah memudahkan rumah sakit dalam
mengelola kegiatan operasionalnya, memberikan pelayanan kesehatan yang baik pada
pasien. Selain itu, sistem juga dapat menyimpan informasi dan data mengenai identitas,
rekam medis, dan riwayat pengambilan obat pasien.

3. Constitution of Satisfaction

Berikut ini adalah pernyataan-pernyataan yang menggambarkan upaya untuk

menjamin kepuasan pengguna dari sistem.

Pasien menjadi aktor yang paling mendapatkan kemudahan dengan adanya sistem
ini karena adanya rekam medis yang memudahkan pasien mendapatkan pelayanan
kesehatan yang cepat dan baik.
Data dari rekam medis dapat dijadikan sebagai statistik yang mungkin dapat
digunakan untuk memprediksi dan mencegah penyakit.
Memudahkan rumah sakit dalam mengelola kegiatan operasional.

2.2 Fungsi Subsistem

Berikut merupakan fungsi dari setiap subsistem.

4
 Pencatatan rekam medis.
Pencatatan rekam medis berfungsi untuk menyimpan informasi mengenai riwayat
penyakit dan pemeriksaan pasien. Informasi ini nantinya dapat digunakan dalam keadaan
darurat, seperti ketika kondisi pasien kritis dan tidak sadarkan diri.
Pendaftaran pasien.
Pendaftaran pasien berfungsi untuk mencatat informasi mengenai keluar masuknya
pasien dan jenis perawatan yang diberikan. Data dan informasi dari subsistem ini berguna
untuk keperluan administratif rumah sakit.
Pengambilan obat berdasarkan resep dokter
Pengambilan obat berdasarkan resep dokter berfungsi untuk mencegah terjadinya
kesalahan dan penipuan dalam pengambilan obat.S

2.3 Feasible Concept System

2.3.1. Visualization of Subsystem Implementation
Pembuatan sistem Smart Health Care ini memerlukan dukungan teknologi. Teknologi
yang dibutuhkan perlu divisualisasikan terlebih dahulu untuk dipelajari feasibility-nya di bab
berikutnya. Berikut ini adalah hasil visualisasi dari teknologi yang dibutuhkan oleh Smart Health
Care berbasiskan smart card.

Tabel 1 Visualisasi Implementasi Subsistem

No Nama Teknologi Status Deskripsi

1 Online Platform Belum ada Teknologi berbasis software komputer
yang akan menjadi tempat diupdatenya
informasi terakhir mengenai pasien
2 Database Belum ada Teknologi untuk mencatat informasi
pasien. Informasi tersebut melingkupi data
pasien, rekam medis,dll.
3 Smart Card Belum ada Teknologi sebagai media penyimpanan
data dalam bentuk barcode yang akan
4 Card Reader Belum ada Teknologi untuk membaca kartu dan
menghubungkan ke database sehingga
informasi dapat diakses.

5
2.3.2. Definition of a Feasible Concept
Berikut ini adalah penjabaran konsep yang feasible dari functional system online delivery
system. Konsep feasible ini akan dibahas melalui tiga aspek yaitu relation to thecurrent system,
application of advanced technology, dan cost.
Relation to the Current System
Smart Health Care merupakan sebuah sistem yang dikembangkan untuk
memperbaharui sistem informasi yang ada di rumah sakit. Penggunaan Smart Health
Care bertujuan untuk memudahkan pasien dalam memiliki informasi mengenai rekam
medis mereka, memudahkan dokter untuk mendiagnosa penyakit pasien, dan
mempermudah rumah sakit dalam urusan administrasi karena pendataan yang
terintegrasi.
Application of Advanced Technology
Smarth Health Care menggunakan teknologi yang advanced pada bagian kartu
yang bertujuan agar pada saat card reader membaca kartu, maka aplikasi dapat
langsung terhubung ke database dan langsung mengeluarkan output berupa informasi
pasien. Dalam penyimpanan informasi Smarth Health Care menggunakan database
online sehingga dapat memudahkan dalam melakukan akses. Smart Health Care ini
dapat digunakan di smartphone maupun pada komputer akan tetapi, pada smartphone
kita hanya dapat melihat informasi sedangkan untuk menambahnya hanya dapat
melalui komputer yang ada pada rumah sakit.
Cost
Dalam pengembangan Smart Health Care diperlukan investasi yang besar. Dana
ini diperlukan pada pengadaan barang seperti smart card, card reader, dan juga
aplikasi yang ada, selain itu diperlukan juga biaya untuk mengimplementasikan dan
merawat sistem agar berkelanjutan. Biaya pengembangan dan pengimplementasikan
ini diharapkan didapatkan dari pemerintah.
Development Process

Pengembangan sistem Smart Health Care menggunakan metode System

Engineering Life Cycle dan Waterfall Method.Setiap tahapan di dalam metode
dilakukan untuk setiap iterasi siklus hidup pengembangan sistem.

6
2.3.3. Operational Requirements
Pada bagian ini akan dilakukan peninjauan kembali relevansi pendefinisian kebutuhan
fungsional yang telah ditetapkan dalam keadaan lingkungan rumah sakit secara umum.
Peninjauan akan dilakukan dengan melihat tiga bagian besar yakni parameter performansi,
pengukuran efektivitas dan pengukuran performansi
2.3.3.1. Performance Paramteres
Dalam melakukan validasi kebutuhan diperlukan parameter yang dapat
digunakan untuk mengetahui performansi dari sistem yang ada. Berikut ini akan
dijelaskan pendefinisian peninjauan kebutuhan dalam bentuk tabel.

Tabel 2 Parameter Kinerja

Needs Functional Satisfier Satisfied/Dissatisfied

Menangani Sistem pendataan Satisfied
permasalahan rekam medis yang
pendataan yang terintegrasi antar rumah
terintegrasi sakit
Memastikan kebenaran Sistem pendataan dapat Satisfied
dari tiap informasi yang diverifikasi
di update kebenarannya
Keterlibatan pemerintah Sistem yang melibatkan Satisfied
pemerintah
Memudahkan pasien Sistem yang Satisfied
untuk mendapatkan memudahkan pasien
informasi yang ada dalam melakukan
pada smart card proses administrasi dari
satu rumah sakit ke
rumah sakit yang lain
Berkurangnya Sistem ini dapat Satisfied
penggunaan sistem diimplementasikan
tradisional dalam pada rumah sakit yang
pendataan rekam medis masih menggunakan
sistem tradisional

2.3.3.2. Measure of Effectiveness

7
 Pengukuan efektivitas dari sistem yang dirancang dan dilakukan berdasarkan
tingkat keberhasilan dari pengurangan penggunaan kertas yang digunakan oleh rumah
sakit. Sistem ini akan dinilai efekti jika dapat memenuhi metric yang ada. Berikut ini
akan dijelaskan metric, unit, kondisi untuk pengukuran efektivitas solusi dilengkapi
dengan keterangan singkat

Tabel 3 Pengukuran Keefektifan

Metric Unit Condition Note

Persentase 50 Peningkatan penggunaan Smart Mulai
Card pada rumah sakit diberlakukannya
smart card pada
setiap pasien yang
telah terdaftar
pada rumah sakit
Persentase 50 Penurunan penggunaan kertas Proses pendataan
pada rumah sakit yang awalnya
dilakukan secara
tradisional yaitu
dicatat
menggunakan
kertas diharapkan
dengan penerapan
smart card akan
berkurang
2.3.3.3. Measure of Performance
Dalam melakukan validasi kebutuhan diperlukan pengukuran performa dari
sistem yang akan dirancang. Sistem akan dinilai memiliki performa yang baik jika dapat
memenuhi metric yang ada. Beriku ini akan dijelaskan metric, unit, kondisi untuk
pengukuran efektivitas solusi dilengkapi dengan keterangan singkat

Tabel 4 Pengukuran Performa

Metric Unit Condition Note

Query 1000 Traffic maksimum Sistem ini dapat

8
 dalam pencarian melakukan pencarian
online hingga 1000 pasien
dalam satu waktu
Error 0.001 Kesalahan sistem Sistem akan menerima
dalam menerima inputan id pasien dari
masukan kartu kartu dan akan dicari
informasi mereka pada
database
Availability 95% Ketersediaan layanan Baik sistem pembacaan
ataupun pendataan
akan mempengaruhi
dari kepuasan diberikan
Response 0.05 s Waktu server Dalam sistem
Time memproses query pendataan dan
pencarian informasi
diperlukan waktu
respon yang sangat
singkat. Hal ini
digunakan untuk
meningkatkan
kenyamanan pasien
pada saat pembacaan
smart card

BAB III - Concept Exploration Phase

3.1 Refined Operational Requirements

3.1.1. Projected Need Analysis

Pada bagian ini akan dijelaskan secara lebih rinci mengenai kebutuhan yang harus
dipersiapkan pada saat sistem kompleks Smart Health Care mulai diimplementasikan. Hal ini
dilakukan agar dari tim pengembang dapat lebih siap dalam menentukan proyeksi kebutuhan

9
berdasarkan hasil akhir yang diharapkan saat sistem sudah mulai berjalan serta mulai
melayani request dari pengguna.

1. Infrastruktur pendukung pada rumah sakit

Pada setiap rumah sakit diharapkan telah mempunyai komputer beserta card
reader miniman satu buah yang digunakan dalam pembacaan dan melakukan proses
update database.

2. Bagian administrasi yang menguasai bidang teknologi

Dibutuhkan tenaga ahli yang mengerti bidang teknologi untuk dapat

mengoperasikan dan melakukan manajemen sistem secara keseluruhan terutama
menjadi Admin dari sistem kompleks Smart Health Care. Orang tersebut akan
bertanggung jawab dalam menangani masalah yang terjadi dan melakukan optimasi
pada sistem dalam memberikan layanan baik kepada petani maupun
pelanggan website yang ingin membeli produk.

3. Server Hosting & Domain Name

Ketersediaan akan server untuk menyimpan data dan juga nama domain dari
website yang digunakan untuk men-display setiap hasil pertanian yang diproduksi
oleh petani menjadi hal yang penting. Oleh karena itu, perlu dilakukan analisis
kebutuhan terlebih dahulu mengenai kemampuan hardware dalam
menangani request dari pelanggan.

4. Penentuan role untuk setiap pengguna sistem

Di dalam sistem ini, tidak hanya interaksi admin dan pasien saja yang akan
terjadi. Akan tetapi terdapat juga peran pemerintah yang dapat memantau,
memberikan berita, bahkan menentukan kebijakan tentang penggunaan smart card
ini.. Hal tersebut dilakukan agar meningkatkan sosialisasi pemerintah melalui satu
saluran yang lebih mudah dengan mempertemukan juga antara rumah sakit dan
pengembang.

3.1.1.1. Operational Obejctive Analysis

10
 Bagian ini akan mendeskripsikan mengenai setiap tujuan dan kondisi akhir yang
akan dicapai. Selain itu, melalui analisis pada bagian ini dapat dilakukan dekomposisi
dari tujuan menjadi kebutuhan-kebutuhan serta fungsi-fungsi yang lebih detail. Dalam
upaya memperjelas kebutuhan operasional dari Smart Health Care maka akan dilakukan
pendefinisian kondisi akhir dari skenario sistem, tujuan sistem dan pengatur kepuasan
sistem, serta alasan kebutuhan sistem.

1. End State of Scenario

Dengan adanya Smart Health Care ini diharapkan pendataan pasien dari satu
rumah sakit ke rumah sakit yang lain sudah tidak diperlukan karena segala informasi
telah terintegrasi dan terdokumentasi kedalam satu data center yang dapat diakses
oleh semua rumah sakit dengan cara membaca smart card dari pasien.

2. Purpose of The System

Tujuan dari sistem adalah mewujudkan terintegrasi dan terdokumentasinya

informasi pasien yang ada di setiap rumah sakit sehingga setiap individu dapat
mengunjungi semua rumah sakit dan setiap rumah sakit itu telah memiliki informasi
yang lengkap mengenai si pasien. Agar dapat mengakses informasi tersebut rumah
sakit memerlukan smart card si pasien yang dapat menghubungkan rumah sakit agar
dapat mengakses database pasien.

3. Constitution of Satisfaction

Berikut ini adalah pernyataan-pernyataan yang menggambarkan upaya untuk

menjamin kepuasan pengguna dari sistem.

Pasien menjadi aktor yang paling mendapatkan kemudahan dengan adanya sistem ini
karena data-data yang sangat membantu pasien dalam melakukan pengobatan telah
tersedia sehingga proses administrasi akan semakin sederhana

Pasien dapat dengan mudah mendapatkan informasi mengenai rekam medis mereka
dengan cara membuka database mereka.

11
 Memudahkan rumah sakit dalam mengurus administrasi karena segala informasi telah
terintegrasi.

Dokter memiliki referensi dalam mendiagnosa penyakit pasien karena telah memiliki
rekam medis yang lengkap dari pasien.

3.1.2. Performance Parameters

Dalam melakukan validasi kebutuhan diperlukan parameter yang dapat digunakan untuk
mengetahui performansi dari sistem yang ada. Berikut ini akan dijelaskan pendefinisian
peninjauan kebutuhan dalam bentuk tabel.

Tabel 5 Parameter Kinerja

Needs Functional Satisfier Satisfied/Dissatisfied

Menangani Sistem pendataan Satisfied
permasalahan rekam medis yang
pendataan yang terintegrasi antar rumah
terintegrasi sakit
Memastikan kebenaran Sistem pendataan dapat Satisfied
dari tiap informasi yang diverifikasi
di update kebenarannya
Keterlibatan pemerintah Sistem yang melibatkan Satisfied
pemerintah
Memudahkan pasien Sistem yang Satisfied
untuk mendapatkan memudahkan pasien
informasi yang ada dalam melakukan
pada smart card proses administrasi dari
satu rumah sakit ke
rumah sakit yang lain
Berkurangnya Sistem ini dapat Satisfied
penggunaan sistem diimplementasikan
tradisional dalam pada rumah sakit yang
pendataan rekam medis masih menggunakan
sistem tradisional

12
 Seperti yang telah dibahas pada subbab sebelumnya, parameter yang akan digunakan
untuk mengukur daya kerja dari sistem yang kami usulkan adalah dengan menggunakan tabel
diatas. Tujuan dari penetapan parameter tersebut adalah untuk memudahkan kami dalam menilai
apakah sistem baru yang diterapkan tersebut dapat dikatakan berhasil dalam menyelesaikan
masalah yang ada atau tidak. Paramater tersebut dibuat dengan koordinasi bersama pihak
penyelenggara penanganan kesehatan yang akan menjadi objek tujuan diimplementasikannya
sistem ini. Parameter yang dibuat juga telah memenuhi keseluruhan kebutuhan penilaian yang
harus dikontrol dan dikelola secara berkala.

3.1.3. Performance Requirements

Dalam melakukan validasi kebutuhan diperlukan pengukur performa dari sistem yang
akan dirancang. Sistem akan dinilai memiliki performa yang baik jika dapat memenuhi metric
yang ada. Berikut ini akan dijelaskan metric, unit, kondisi untuk pengukuran efektivitas solusi
dilengkapi dengan keterangan singkat.

Tabel 6 Kebutuhan Kinerja

Metric Unit Condition Note

Query 1000 Traffic maksimum Sistem ini dapat
dalam pencarian melakukan pencarian
online hingga 1000 pasien
dalam satu waktu
Error 0.001 Kesalahan sistem Sistem akan menerima
dalam menerima inputan id pasien dari
masukan kartu kartu dan akan dicari
informasi mereka pada
database
Availability 95% Ketersediaan layanan Baik sistem pembacaan
ataupun pendataan
akan mempengaruhi
dari kepuasan diberikan
Response 0.05 s Waktu server Dalam sistem
Time memproses query pendataan dan
pencarian informasi

13
 diperlukan waktu
respon yang sangat
singkat. Hal ini
digunakan untuk
meningkatkan
kenyamanan pasien
pada saat pembacaan
smart card

Performance requirements yang dianalisis mencakup empat aspek, query, error,

availability, dan response time. Keempat elemen tersebut dinilai sangat penting dalam penerapan
sistem yang kami ajukan tersebut. Apabila keempat elemen tersebut memiliki performansi yang
kurang baik, maka sistem tidak dapat berjalan dengan semestinya. Selain itu, pada tahap
maintenance, keempat elemen tersebut harus selalu dipantau dan dikelola secara teliti karena
meningkat atau menurunnya kinerja sistem dapat ditinjau dari penilaian keesmpat aspek tersebut.

3.1.4. Performance Characteristic

Dari performance parameters dan performance requirements serta tujuan dan manfaat
yang ingin dicapai dari pengimplementasian sistem ini, maka didapatkan rumusan mengenai
performance characteristic yang harus dimiliki oleh sistem. Berikut adalah rincian dari
karakteristik yang harus dimiliki oleh sistem.

Sistem harus mampu bekerja selama 24 jam setiap harinya.

Sistem menghasilkan output yang sesuai, kegagalan yang dapat ditolerir tidak lebih
dari 0.1%.
Sistem memiliki response time tidak lebih dari 0.05 detik.
Sistem dapat menggunakan Bahasa Indonesia maupun Bahasa Inggris.
Sistem dapat melakukan pencarian maksimum data pasien sebanyak 1000 pasien
setiap hari.
Sistem dapat dioperasikan dengan mudah.

Karakteristik dari kinerja sistem di atas harus dapat dipenuhi agar sistem dapat bekerja
secara optimal. Selain itu, karena tujuan dari penerapan sistem ini untuk meningkatkan performa
pengelola rumah sakit, maka sistem tersebut harus mampu beroperasi dengan baik setiap saatnya.

14
Dari sisi keamanan dan pengelolaan, pihak yang akan menerapkan sistem tersebut juga harus
mempersiapkan metodenya. Karena sistem ini berhubungan dengan informasi pribadi pasien,
maka sistem harus dapat membuat sistem keamanan yang baik dalam melaksanakan fungsinya.

15
 BAB IV CONCEPT DEFINITION PHASE

4.1 Refined Performance Requirements

Pada bagian ini akan dilakukan analisis terhadap performance requirements yang telah
dijelaskan sebelumnya pada bagian 1.7.3. Analisis ini dilakukan dengan tujuan untuk
menyempurnakan performance requirements yang telah didefinisikan sebelumnya. Berikut
merupakan performance requirements yang telah didefinisikan sebelumnya.

Tabel 7 Performance Requirements

Metric Unit Condition Note

Query 1000 Traffic maksimum Sistem ini dapat
dalam pencarian melakukan pencarian
online hingga 1000 pasien
dalam satu waktu
Error 0.001 Kesalahan sistem Sistem akan menerima
dalam menerima inputan id pasien dari
masukan kartu kartu dan akan dicari
informasi mereka pada
database
Availability 95% Ketersediaan layanan Baik sistem pembacaan
ataupun pendataan
akan mempengaruhi
dari kepuasan diberikan
Response 0.05 s Waktu server Dalam sistem
Time memproses query pendataan dan
pencarian informasi
diperlukan waktu
respon yang sangat
singkat. Hal ini
digunakan untuk
meningkatkan
kenyamanan pasien

16
 pada saat pembacaan
smart card
Performance requirements di atas masih memiliki beberapa kelemahan, salah satunya
adalah requirements cenderung terlalu fokus pada kapabilitas sistem, namun tidak
memperhitungkan maintenance, compatibility, dan sebagainya. Oleh karena itu, performance
requirements perlu disempurnakan dengan cara menambah requirements serta mengkategorikan
requirements ke dalam salah satu kategori, yaitu:
Compatibility Requirements
Kategori ini berfokus pada bagaimana sistem berhubungan dengan tempat
operasinya, pendukung logistiknya, dan sistem lainnya.
Reliability, Maintainability, Availability Requirements
Kategori ini berfokus pada seberapa reliable sistem dapat memenuhi tujuannya,
bagaimana cara merawatnya, dan fasilitas pendukung apa yang dibutuhkan.
Environmental Requirements
Kategori ini berfokus pada lingkungan ekstrim apa yang yang harus dapat dihadapi
oleh sistem.

Berikut merupakan penjabaran dari refined performance requirements.

Tabel 8 Refined Performance Requirements

Metric Unit Condition Note Category

Query 1000 Traffic maksimum Sistem ini dapat Reliability,
dalam pencarian melakukan pencarian Maintainability,
online hingga 1000 pasien Availability
dalam satu waktu Requirements
Error 0.001 Kesalahan sistem Sistem akan Reliability,
dalam menerima menerima inputan id Maintainability,
masukan kartu pasien dari kartu dan Availability
akan dicari informasi Requirements
mereka pada
database

17
Availability 95% Ketersediaan Baik sistem Reliability,
layanan pembacaan ataupun Maintainability,
pendataan akan Availability
mempengaruhi dari Requirements
kepuasan diberikan
Response 0.05 s Waktu server Dalam sistem Reliability,
Time memproses query pendataan dan Maintainability,
pencarian informasi Availability
diperlukan waktu Requirements
respon yang sangat
singkat. Hal ini
digunakan untuk
meningkatkan
kenyamanan pasien
pada saat pembacaan
smart card
Compatibilit 100% Kesesuaian Keseluruhan sistem Compatibility
y implementasi harus compatible Requirements
sistem dengan terhadap lingkungan
lingkungan sistem sistem, mulai dari
aplikasi yang
compatible dengan
sistem operasi, smart
card dengan aplikasi
dan scanner.
Ketidaksesuaian
salah satu subsistem
ataupun komponen
dapat menyebabkan
kegagalan sistem.
Endurance 95% Ketahanan sistem Sistem dapat Environmental
terhadap kondisi bertahan terhadap Requirements

18
 ekstrim
4.2 Preliminary Functional Design
Dalam merumuskan preliminary functional design dari sistem, diperlukan pendefinisian
functional requirements terlebih dahulu. Berikut merupakan functional requirements dari sistem
Smart Health Care.
Tabel 9 Preliminary Functional Design
ID Kebutuhan
Sistem dapat menerima teknis
F-01 Log In dari Administrator dan
Dokter yang terdaftar
Sistem dapat menerima
F-02 masukan berupa rekam medis
dari Dokter
Sistem dapat menerima
F-03 masukan berupa data
administrasi saat pendaftaran
Sistem dapat menerima
F-04 masukan berupa daftar data
obat yang diberikan
Kartu yang terintegrasi dengan
sistem dapat memberikan
F-05
informasi mengenai data
pasien
kondisi ekstrim yang
dapat menyebabkan
penurunan kinerja
sistem, seperti
bencana alam yang
menyebabkan sistem
mengalami down.
Penjelasan
Administrator Rumah Sakit dan Dokter yang telah
terdaftar sebagai pengguna dapat mengakses
perangkat lunak sistem
Perangkat lunak sistem dapat menerima masukan
berupa hasil diagnosis dokter terhadap penyakit yang
diderita oleh pasien yang diperiksa
Perangkat lunak sistem dapat menerima masukan
berupa data-data yang diperlukan dalam proses
pendaftaran pasien untuk pemeriksaan di rumah
sakit
Perangkat lunak sistem dapat menerima masukan
berupa data mengenai obat yang akan diberikan
kepada pasien oleh apoteker yang sedang bertugas
Perangkat keras berupa kartu terintegrasi dengan
perangkat lunak sistem yang berguna untuk
menyimpan informasi mengenai kondisi kesehatan
pasien
19
 Berdasarkan functional requirements di atas, dapat dirumuskan preliminary functional
design yang digambarkan dalam diagram blok fungsional di bawah ini.

Gambar 2 Functional Block Diagram

4.3 Concept Effectiveness

4.3.1. Alternatif konstruksi pencatatan rekam medis
Berikut merupakan alternatif mengenai konstruksi pencatatan rekam medis
Alternatif pertama yaitu pengembangan pencatatan rekam medis menggunakan
database terpusat dengan autentifikasi menggunakan Smart Card yang memiliki
memory sedikit yang hanya mampu berisi id yang akan menuntun pada database.
Alternatif kedua yaitu penggunaan Smart Card yang menyimpan informasi di
dalam memori yang terdapat pada Smart Card
Tabel 10 Penilaian Perbandingan Alternatif Konstruksi Pencatatan Rekam Medis

No Aspek Database+Smart Card Smart Card + Memory

1 Performa Performanya lebih lambat dari Performanya cepat karena
operasional alternatif kedua karena harus informasi langsung dapat
membaca id pada smart card diakses menggunakan card
kemudian mengakses reader
database

20
 2 Biaya Biaya dibutuhkan lebih
sedikit dengan menimbang
harga database lebih murah
dibandingkan smart card
dengan memori.
3 Jadwal proyek Lebih cepat karena pengadaan
database lebih cepat
dibandingkan smart card
4 Risiko Resikonya kecil karena
kerusakan pada database
memiliki peluang yang kecil
Biaya yang harus
dikeluarkan besar dengan
menimbang banyaknya
pengguna Smart Card di
masa depan.
Pengadaan membutuhkan
waktu yang lama mengingat
jumlah smart card yang
dibutuhkan sangatlah banyak
Resiko penggunaan Smart
Card besar karena apabila
kartunya hilang, orang lain
langsung dapat mengakses
informasi di dalamnya

4.3.2. Alternatif konstruksi pendaftaran pasien

Berikut merupakan alternatif konstruksi pendaftaran pasien
Alternatif pertama menggunakan database sebagai media penyimpanan informasi
pendaftaran.
Alternatif kedua menggunakan memori pada smart card sehingga tiap melakukan
pendaftaran semua rumah sakit dapat mengakses informasi tanpa memiliki
database pasien.
Tabel 11 Penilaian Perbandingan Alternatif Konstruksi Pendaftaran Pasien

No Aspek Database+Smart Card Smart Card + Memory

1 Performa Performanya lebih lambat dari Performanya cepat karena
operasional alternatif kedua karena harus untuk melakukan
membaca id pada smart card pendaftaran pihak
kemudian mengakses administrasi langsung dapat
database untuk melakukan mengakses inforsmasinya
pendaftaran dengan menggunakan card
reader
2 Biaya Biaya dibutuhkan lebih Biaya yang harus
sedikit dengan menimbang dikeluarkan besar dengan

21

3 Jadwal proyek
4 Risiko
harga database lebih murah
dibandingkan smart card
dengan memori.
Lebih cepat karena pengadaan
database lebih cepat
dibandingkan smart card
Resikonya kecil karena
kerusakan pada database
memiliki peluang yang kecil
menimbang banyaknya
pengguna Smart Card di
masa depan.
Pengadaan membutuhkan
waktu yang lama mengingat
jumlah smart card yang
dibutuhkan sangatlah banyak
Resiko penggunaan Smart
Card besar karena apabila
kartunya hilang orang lain
langsung dapat mengakses
informasi di dalamnya

4.3.3. Alternatif konstruksi pengambilan obat menggunakan resep dokter

Berikut merupakan alternatif konstruksi pengambilan obat menggunakan resep dokter.
Alternatif pertama yaitu memasukkan informasi tersebut ke dalam database
sehingga dalam mengambil obat harus mengakses ke database terlebih dahulu
Alternatif kedua yaitu informasi obat tersimpan pada memori smart card
Tabel 12 Penilaian Perbandingan Alternatif Konstruksi Pengambilan Obat Menggunakan Resep Dokter

No Aspek Database+Smart Card Smart Card + Memory

1 Performa
operasional
2 Biaya
3 Jadwal proyek
Performanya lebih lambat dari Performanya cepat karena
alternatif kedua karena harus
membaca id pada smart card
kemudian mengakses
database untuk mengetahui
obat yang akan diambil
Biaya dibutuhkan lebih
sedikit dengan menimbang
harga database lebih murah
dibandingkan smart card
dengan memori.
Lebih cepat karena pengadaan
database lebih cepat
informasi obat langsung
dapat diakses menggunakan
card reader
Biaya yang harus
dikeluarkan besar dengan
menimbang banyaknya
pengguna Smart Card di
masa depan.
Pengadaan membutuhkan
waktu yang lama mengingat

22
 dibandingkan smart card
4 Risiko Resikonya kecil karena
kerusakan pada database
memiliki peluang yang kecil
jumlah smart card yang
dibutuhkan sangatlah banyak
Resiko penggunaan Smart
Card besar karena apabila
kartunya hilang orang lain
langsung dapat mengakses
informasi di dalamnya

4.4 Selected Concept

Dari ketiga subsistem yang dimiliki dengan menimbang alternatif konsep yang dimiiki
maka ditentukan bahwa :
Untuk pengembangan pencatatan rekam medis menggunakan smart card yang
memiliki memori yang kecil tetapi memiliki akses ke dalam database sehingga
dapat melihat semua informasi mengenai rekam medis di dalam database tersebut.
Untuk pengembangan pendaftaran pasien menggunakan smart card yang memiliki
memori yang kecil tetapi memiliki akses ke dalam database sehingga dapat
melihat semua informasi mengenai pasien sehingga dapat melakukan pendaftaran.
Untuk pengembangan pengambilan obat dengan menggunakan resep dokter juga
menggunakan smart card yang memiliki memori yang kecil tetapi memiliki akses
ke dalam database sehingga dapat melihat semua informasi mengenai pasien
sehingga dapat melakukan pendaftaran.
Dari ketiga subsitem diatas dapat disimpulkan bahwa pengembangan sistem Smart Health
Care akan menggunakan sebuah smart card dengan memori yang sedikit tapi memiliki
autentifikasi ke sebuah database yang memiliki informasi baik itu rekam medis, data pasien,
hingga obat yang telah diberikan oleh dokter.

BAB V ADVANCED DEVELOPMENT PHASE

5.1 Candidate Component for Development

Berikut merupakan komponen-komponen kandidat yang akan digunakan dalam
pengembangan sistem.

23
 Tabel 13 Candidate Component for Development

No. Komponen Deskripsi

1 Smart Card Kartu yang memiliki chip untuk menyimpan data.
2 Database Database yang menyimpan informasi mengenai
rekam medis pasien, riwayat pengambilan obat, dan
informasi pasien.
3 Server Server berfungsi sebagai tempat penyimpanan
database.
4 Card Reader Card reader digunakan untuk membaca chip pada
smart card.
5 Aplikasi Pengolah Data Aplikasi digunakan untuk oleh dokter dan pihak
rumah sakit dalam mengentri, mengubah, dan
menghapus data.

5.2 Functional Design

5.4.1 Functional Requirement
Kebutuhan dari sistem Smart Health Care adalah sebagai berikut.

Tabel 14 Functional Requirement

ID Kebutuhan Penjelasan

Sistem dapat menerima teknis Administrator Rumah Sakit dan Dokter yang telah
F-01 Log In dari Administrator dan terdaftar sebagai pengguna dapat mengakses
Dokter yang terdaftar perangkat lunak sistem

Sistem dapat menerima Perangkat lunak sistem dapat menerima masukan

F-02 masukan berupa rekam medis berupa hasil diagnosis dokter terhadap penyakit yang
dari Dokter diderita oleh pasien yang diperiksa

Perangkat lunak sistem dapat menerima masukan

Sistem dapat menerima
berupa data-data yang diperlukan dalam proses
F-03 masukan berupa data
pendaftaran pasien untuk pemeriksaan di rumah
administrasi saat pendaftaran
sakit

Sistem dapat menerima Perangkat lunak sistem dapat menerima masukan

F-04 masukan berupa daftar data berupa data mengenai obat yang akan diberikan
obat yang diberikan kepada pasien oleh apoteker yang sedang bertugas

24
 Kartu yang terintegrasi dengan
sistem dapat memberikan
F-05
informasi mengenai data
pasien
Perangkat keras berupa kartu terintegrasi dengan
perangkat lunak sistem yang berguna untuk
menyimpan informasi mengenai kondisi kesehatan
pasien

5.4.2 Use Case Smart Health Care System

Berikut adalah diagram use case dari Smart Health Care System.

Gambar 3 Use Case Smart Health Care

5.4.3 Actor Definition Smart Health Care System

Berikut adalah daftar aktor dan deskripsi role untuk setiap actor.

Tabel 15 Actor Definition

ID Aktor Deskripsi

A-01 Bagian Pendaftaran Aktor dengan role ini dapat melakukan login dan
memasukkan data diri pasien

A-02 Dokter Aktor dengan role ini dapat melakukan login,

memasukkan rekam medis dari pasien

A-03 Kartu Pasien Aktor dengan role ini dapat memberikan

25
 informasi mengenai pasien yang tersimpan di
dalamnya

5.2.4 Use Case Definition Smart Health Care System

Berikut adalah daftar use case dari Integrated Health Information System beserta
deskripsi singkatnya.

Tabel 16 Use Case Definition

ID Use Case Deskripsi

UC-01 Login Pengguna/Administrator dapat masuk ke dalam

sistem agar dapat mengakses beberapa fitur yang
ada sesuai dengan level otoritasnya

UC-02 Memasukkkan Data Sistem dapat menerima masukan berupa data diri
Pasien pasien

UC-03 Memasukkan Rekam Sistem dapat menerima masukan berupa rekam

Medis medis/hasil diagnosis, rekomendasi obat-obatan,
dan informasi lain yang diperlukan oleh Dokter
terhadap penyakit pasien

UC-04 Memberikan Informasi Sistem dapat menampilkan informasi yang

Pasien tersimpan di dalam kartu yang dimiliki oleh
pasien

UC-05 Melihat Informasi Sistem dapat mengintegrasikan informasi yang

Pasien disimpan didalam databasenya kepada aplikasi
android yang dimiliki oleh dokter

5.2.5 Non Functional Requirement

Bagian ini menjelaskan tentang kebutuhan non-fungsional apa saja yang dibutuhkan oleh
sistem.

Tabel 17 Non Functional Requirement

ID Kebutuhan Penjelasan

NF-01 Availability Sistem harus dapat beroperasi dengan baik selama

26
 24 jam

Fault tolerance application tidak boleh lebih dari

NF-02 Reliability
0.01%

Sistem yang dirancang berbasis web dengan HTML5

NF-03 Portability
beserta CSS3 dan aplikasi android

Memory server dari sistem harus memiliki kapasitas

NF-04 Memory
sebesar 10TB

Sistem tersebut memiliki response time maksimal

NF-05 Response Time
0.5s

Sistem harus memiliki tingkat keamanan yang

NF-05 Safety tinggi. Server harus memiliki backup di beberapa
tempat berbeda.

Sistem ini hanya dapat digunakan oleh administrator

NF-06 Security yang memiliki akses untuk dapat login ke dalam
sistem

5.3 Critical Component and Design Deficiencies

5.4.1 System Component
Area dari sistem ini dibagi menjadi 4 kategori, yaitu :
a. Usually High Performance
b. Special Material and Process
c. Extreme Conditions
d. Complex Interface

Komponen dari sistem Smart Health Care ini terdiri dari Smart Card,
Database, Server, Card Reader, dan Aplikasi Pengolah Data. Berikut adalah penjelasan
lebih lanjut mengenai level kritis dari tiap komponen yang ada.

Tabel 18 Critical Component of System

Component Potential Problem Area Critical Level

Barcode Mode Usually High High
Performance : Harus dapat
membaca barcode yang ada

27
 secara cepat dan tepat
Card Reader Usually High High
Performance : Harus dapat
membaca barcode yang ada
pada kartu dengan tepat dan
menghasilkan informasi
yang dapat diolah olah
administrator

Complex interface :
interface card reader
terhubung kepada aplikasi
pengolah data yang
dipasang di area kerja
administrator
Buzzer Exterme Condition : Low
Buzzer dapat berbunyi
sebagai tanda bahwa kartu
telah berhasil dipindai
Microprocessor Complex interface : High
interface dari mikroprosesor
terhubung ke banyak
komponen yang terhubung
dalam sistem pembacaan
barcode kartu.
Smart Card Special Material and High
Process : Terbuat dari
material yang mampu
menjaga kualitas memori di
dalamnya pada kondisi
yang berbeda-beda
Server Usually High High
Performance : Harus dapat

28
 menyimpan, mengelola, dan
memelihara seluruh
informasi yang disimpan di
dalamnya dengan baik dan
tahan terhadap berbagai
kondisi
LCD Complex interface : Medium
interface dari lcd terhubung
dengan mikroprosesor dan
aplikasi pengolah data
sebagai indikator bahwa
kartu telah berhasil dipindai

5.4.2 General Boundaries

Berikut merupakan batasan-batasan yang dimiliki oleh perangkat lunak sistem:

1. Sistem harus terhubung ke internet agar dapat mengakses data pada server

2. Tidak dimilikinya server cadangan yang menyimpan backup data pasien

3. Sistem bergantung pada perangkat lunak lain, yaitu Apache dan Web Browser

4. Sistem tidak case sensitive, sehingga apabila terdapat perbedaan kapitalisasi huruf,
sistem akan menganggap itu data yang berbeda

5. Perangkat lunak hanya dapat beroperasi pada platform Windows

5.4.3 Operational Environment

Agar perangkat lunak dapat bekerja dengan optimal, tentunya dibutuhkan lingkungan
operasi yang mendukung keberjalanan sistem. Berikut merupakan spesifikasi yang perlu dimiliki
agar perangkat lunak dapat berfungsi dengan baik:

29
 1. Hardware

Sistem yang dibangun akan menggunakan perangkat komputer sebagai media utama
operasinya. Oleh karena itu, tentu dibutuhkan perangkat komputer dengan spesifikasi tertentu
agar sistem dapat berjalan dengan baik. Sistem ini membutuhkan dua jenis komputer, yaitu
perangkat komputer untuk dijadikan sebagai server serta perangkat komputer yang digunakan
untuk transaksi sehari-hari.

Spesifikasi minimum yang dibutuhkan untuk perangkat komputer yang akan digunakan
sebagai server adalah sebagai berikut.

a. Prosesor Intel Xeon E3-1220

b. RAM DDR3 8GB

c. 1TB SATA Harddisk

d. Gigabit LAN

Spesifikasi minimum yang dibutuhkan untuk perangkat komputer yang akan digunakan
sehari-hari yaitu sebagai berikut.

a. Prosesor Intel Core i3

b. RAM DDR3 2GB

c. 320GB SATA Harddisk

d. Gigabit LAN

Selain itu, alat-alat tambahan seperti keyboard, mouse serta layar monitor pun dibutuhkan
untuk kelancaran keberjalanan sistem terkait.

Spesifikasi minimum yang dibutuhkan untuk perangkat smartphone yang akan digunakan
sehari-hari yaitu sebagai berikut.

a. Iphone 5/ Android

30
b. iOS 8 / Android 5.0

c. Memori internal 500m

31
 2. Software

Untuk menunjang keberjalanan sistem yang dibuat, hardware yang dimiliki harus
dilengkapi dengan berbagai perangkat lunak yang berkaitan dengan sistem. Dalam perangkat
lunak data anggota HIMASTI ini, dibutuhkan berbagai perangkat lunak yang memiliki fungsi
pengaksesan data anggota pada server, yakni:

a. XAMPP

b. Apache

c. Web browser

d. MySQL

5.4.4 Assumption and Dependency

Asumsi pada proyek pengembangan proyek ini adalah sebagai berikut:

1. Pihak rumah sakit dapat memenuhi kebutuhan teknologi secara mandiri untuk
mengimplementasikan hasil proyek ini yaitu berupa komputer dan koneksi internet.
2. Dokter telah memiliki perangkat mobile yang sesuai dengan spesifikasi untuk
dipasang aplikasi sistem tersebut.
3. Pegawai rumah sakit dan dokter belum memiliki kompetensi sehingga perlu diberi
pelatihan dan sosialisasi.
4. Pihak rumah sakit menyetujui kontrak yang disusun mengenai penggunaan sistem ini.

Terdapat tiga macam ketergantungan pada sistem yang dibangun yaitu ketergantungan
teknologi, pengguna, dan kebijakan. Penjabaran dari ketiga hal tersebut adalah sebagai berikut:

1. Teknologi
Terdapat dua komponen ketergantungan pada bagian teknologi yaitu hardware dan
software. Performa dari implementasi hasil proyek ini ditentukan oleh kemampuan
hardware, minimal terpenuhi seperti yang telah dijelaskan pada lingkungan operasi.
Ketergantungan software secara spesifik adalah dalam hal pemanfaatan teknologi
barcode API, web services, database system, dan mobile apps development. Hasil dari

32
 proyek ini bergantung kepada ketersediaan layanan yang diberikan pada pemanfaatan hal
tersebut.
2. Pengguna
Pengerjaan proyek ini bergantung kepada karakteristik dan kapabilitas pengguna.
Meskipun akan diadakan sosialisasi dan pelatihan, desain dari proyek ini tetap
mempertimbangkan kemampuan pengguna yang ada saat ini. Hal tersebut dilakukan agar
hasil pengerjaan proyek dapat diimplementasikan dengan baik dan mudah. Pengguna
sistem yang dimaksud adalah pihak rumah sakit (dokter dan bagian pendaftaran) dan
pasien.
3. Kebijakan
Kebijakan dari pemerintah akan mempengaruhi desain dari proyek ini. Kebijakan
tersebut berupa isi dari rekam medis, prosedur pencatatan rekam medis, dan pihak yang
memiliki wewenang dalam melakukan pencatatan rekam medis. Kebijakan tersebut
diambil dari hukum baku tertulis dari pemerintah (undang-undang dan peraturan menteri)
dan aturan lain dari Ikatan Dokter Indonesia atau organisasi sejenis yang telah diakui dan
diterapkan oleh mayoritas rumah sakit.

5.4 Validated Design

Setelah melalui beberapa proses pengembangan teknologi sebelumnya, maka didapatkan
sebuah sistem baru yang telah tervalidasi. Kemudian tahapan yang harus dilakukan adalah
persiapan untuk melakukan prototyping dan pengujian pengembangan.
5.4.1 Prototype Development
Pengembangan prototype dari sistem ini menggunakan mikrokontroler Arduino
UNO, HTML5 & CSS3, MySQL DBMS, Ethernet Shield, dan juga Barcode Scanner.
Selain itu, akan dikembangkan pula aplikasi yang bertujuan untuk memudahkan dokter
untuk melakukan pengelolaan data terhadap rekam medis pasien.

5.4.2 Development Testing

Tabel 19 Development Test

No. Aspek Deskripsi Pengujian

1 Compatibility Bertujuan untuk menguji kesesuaian Menguji penerapan
sistem dengan kebutuhan sistem apakah
dapat berjalan
selaras antar sub-
sistem
2 Reliability, Bertujuan untuk menguji Menguji sistem

33
 Maintainability, ketersediaan dan ketahanan sistem dengan berbagai
Availability kemungkinan
input untuk
mengetes perilaku
sistem
3 Environmental Bertujuan untuk mengeuji perilaku Menguji sistem
sistem terhadap lingkungan pada beberapa
operasional kemungkinan
kondisi
operasional sistem
4 Efficiency Bertujuan untuk mengukur sistem Menguji sistem
dalam respon dan kemampuan dengan
sistem dalam mengelola sumber memberikan
daya yang dimiliki banyak input dan
melihat daya
tanggap sistem
dalam mengelola
input tersebut
5 Portability Bertujuan untuk menguji apakah Menguji sistem
perangkat lunak mampu beradaptasi dengan melakukan
dengan perangkat lunak lainnya integrasi dengan
dalam satu lingkungan operasional sistem lain dalam
satu lingkungan
yang sama.

DAFTAR REFERENSI

34
[1] Menteri Kesehatan Republik Indonesia. 2008. Peraturan Menteri Kesehatan Republik
Indonesia No. 269/MENKES/PER/III/2008. Jakarta.

[2] Republik Indonesia. 2004. Undang-Undang No. 29 Tahun 2004 tentang Praktik Kedokteran.
Lembaran Negara RI Tahun 2004. No. 4431. Sekretariat Negara. Jakarta.

[3] Admin. 27 Juni 2016. Introduction to Mobile Vision, [online],

(https://developers.google.com/vision/introduction, diakses tanggal 22 Februari 2017).

[4] Admin. 6 Februari 2017. Barcode API Overview, [online],

(https://developers.google.com/vision/android/barcodes-overview, diakses tanggal 22 Februari
2017).

[5] Admin. 22 Februari 2017. Cloud Storage, [online],

(https://en.wikipedia.org/wiki/Cloud_storage, diakses tanggal 23 Februari 2017).

35