Anda di halaman 1dari 5

Seminar Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010) ISSN: 1907-5022

Yogyakarta, 19 Juni 2010

DATA WAREHOUSE PADA RUMAH SAKIT
Henry Antonius, Eka Widjaja
Ilmu Komputer,Universitas Bina Nusantara
Jl. K. H. Syahdan No 9, Kemanggisan/Palmerah, Jakarta 11480
Telp. (021) 5345830 ext. 1213, Faks. (021) 5300244
E-mail: haew@binus.edu, h3nry_4@yahoo.co.id

ABSTRAKS
Sebuah rumah sakit pada umumnya memiliki jumlah data transaksi yang relatif besar per hari. Dengan kondisi
data tersebut, menjadi suatu tantangan tersendiri bagi organisasi Teknologi Informasi di lingkungan rumah
sakit untuk dapat menyediakan informasi kepada pimpinan rumah sakit dalam waktu yang singkat serta dengan
tingkat akurasi data yang tinggi dan tidak mengganggu jalan operasional rumah sakit tersebut. Ketersediaan
informasi yang dibutuhkan menjadi salah satu sarana bagi pimpinan rumah sakit untuk menilai dan
mengevaluasi kinerja dari rumah sakit berdasarkan data-data dan fakta yang terjadi. Kemudahan ini dapat
diperoleh bilamana sebuah rumah sakit menerapkan sebuah aplikasi datawarehouse yang berguna bagi
pengambilan keputusan medik.

Kata Kunci: informasi, datawarehouse, pengambilan keputusan, kinerja

1. PENDAHULUAN pandang yang berbeda, sehingga kualitas keputusan
Rumah sakit adalah pusat layanan yang sangat yang diambil oleh pihak eksekutif menjadi sangat
dibutuhkan oleh seluruh lapisan masyarakat yang akuat.
membutuhkan layanan kesehatan. Setiap hari dapat Masih cukup banyak rumah sakit di Indonesia
ditemukan hampir ratusan pasien yang harus dilayani yang belum memanfaatkan ketersediaan data yang
oleh rumah sakit untuk proses rawat jalan, rawat ada untuk mengevaluasi kinerja dari rumah sakit.
inap, rawat darurat, rawat intensif serta pemeriksaan Kendala ini biasanya diakibatkan karena belum
pendukung medis seperti pemeriksaan laboratorium, tersedianya teknologi yang dapat mengolah dan
radiology dan lain sebagainya. menyajikan informasi dari jumlah data yang sangat
Dengan jumlah transaksi yang luar biasa besar, besar. Selain itu kebutuhan dan keinginan pihak
sudah selayaknya rumah sakit menerapkan sistem eksekutif rumah sakit untuk memperoleh informasi
infomasi dan teknologi informasi untuk mendukung yang berbeda setiap saat menjadi tantangan
proses operasional rumah sakit sehingga menjadi tersendiri bagi organisasi TI di rumah sakit. Bisa
lebih cepat, efisien, efektif dan akurat. Hal ini sangat dibayangkan dengan keterbatasan personil TI,
erat hubungannya dengan peningkatan layanan kebutuhan informasi yang bergerak, lambatnya
rumah sakit terhadap para stakeholdernya, sehingga penyajian informasi dapat mengakibatkan keputusan
waktu tunggu pasien, akurasi data rekam medis, yang dibuat oleh pihak eksekutif menjadi kurang
kemudahan mendapatkan informasi dapat diperoleh maksimal.
dengan adanya sistem informasi. Dukungan Untuk dapat menangani data dalam jumlah besar
teknologi informasi menjadi sangat penting terutama dan memanfaatkannya semaksimal mungkin
dalam mendukung kemajuan suatu rumah sakit. bukanlah hal yang mudah. Oleh karena itu,
Banyak rumah sakit yang kini mulai menyadari diperlukan teknologi informasi yang dapat
bahwa salah satu kunci untuk meningkatkan kualitas mengatasinya, yaitu data warehouse, yang dapat
dan pelayanan suatu rumah sakit sangat bergantung mempercepat proses pengumpulan data untuk
pada kemampuan rumah sakit dalam memperoleh penyajian infomasi yang multidimensi (dapat dilihat
informasi yang berguna secara cepat dan tepat. dari berbagai sudut pandang) dan ringkas sehingga
Agar rumah sakit dapat memberikan layanan dapat memaksimalkan kualitas keputusan yang
yang terbaik kepada stakeholdernya, diperlukan dibuat oleh pihak eksekutif rumah sakit.
sejumlah informasi yang dapat digunakan untuk
pengambilan keputusan oleh pihak eksekutif rumah 2. LANDASAN PUSTAKA
sakit untuk menilai dan mengevalusi kinerja 2.1 Data Warehouse
terutama di bidang medik dari rumah sakit tersebut. Menurut Connolly dan Begg (2005, p1151),
Informasi yang disajikan dapat digunakan untuk “Data warehouse is a subject oriented, integrated,
membantu mengambil keputusan dalam menentukan time variant, and non-volatile collection of data in
strategi dan kebijakan rumah sakit, baik dari segi support of management’s decision-making process”,
waktu maupun kualitas informasi. Infomasi yang yang artinya data warehouse adalah sekumpulan data
dihasilkan harus dapat dlihat dari berbagai sudut yang berorientasi pada subjek, terintegrasi, memiliki

B-68

Menyimpan Pre-Calculation pada Tabel Fakta a. Pengaturan ini d. yang berarti tabel fakta c. penting untuk memperlakukan BOR = x 100% data fakta sebagai data referensi yang hanya dapat Jml tempat tidur x jml hari dibaca (read only reference data). yang berarti tabel dimensi sakit dipakai. yang tidak akan b. atau masing-masing penderita yang keluar dibagi ’fakta’. p7). Sekalipun data dapat diintegrasikan. 19 Juni 2010 rentang waktu. rumah sakit skema bintang (star schema) adalah struktur logikal merupakan salah satu dari sarana kesehatan tempat yang mempunyai sebuah tabel fakta berisi data menyelenggrakan upaya kesehatan. maka akan (Deciding the Query Priorities and the Query mempersulit pengaksesan. ”a set of smaller tables tertentu (biasanya satu tahun) tempat tidur rumah called dimension tables”. Sembilan tahap tersebut adalah : a. p1183) Jml hari perawatan Tabel Fakta adalah. p1183) menunjukkan berapa kali satu satuan waktu Tabel Dimemsi adalah. dengan rumus : fakta relatif sangat berhubungan dengan table Jml Hari perawatan rumah sakit dimensi. Memilih Grain (Choosing the Grain) Menurut Inmon (2005. indikator yang karakteristik dari data faktual di mana fakta dibuat paling penting sering digunakan yaitu: dari peristiwa yang muncul di masa lalu dan mustahil a. Dimension Tables) b. dan tidak mudah berubah untuk 9 tahapan. Average Length Of Stay (ALOS/LOS) adalah rata- berubah sepanjang waktu. Frekuensi pemakaian tempat tidur yang Menurut Connolly dan Begg (2005. dikelilingi oleh tabel dimensi berisi data referensi (yang dapat 2.4 Tabel Fakta dan Tabel Dimensi tertentu. Modes) 2. Skema bintang mengeksploitasi Menurut Muninjaya (2004. Duration of the Database) c.5 Perancangan Data Warehouse Berdasarkan kutipan dalam Connolly dan Begg (2005. yang terjadi untuk dengan jumlah penderita yang keluar tersebut selama jangka waktu tertentu atau periode 2. periode.2 Anatomi Data Warehouse Terpusat b. Perusahaan mengoperasikan sebuah model bisnis g. Melacak Perubahan dari Dimensi secara Perlahan sebuah penyimpanan tunggal yang terpusat. Bed Occupancy Rate (BOR) adalah rata-rata untuk berubah. jika data i. p232). Memilih Durasi dari Basis Data (Choosing the terpusat. Karena sebagian besar data dalam dihuni atau dipakai oleh penderita selama satu data warehouse ditampilkan sebagai fakta. sebagian besar c. Tabel fakta yang paling rata lamanya (dinyatakan dalam 1 hari) dari berguna berisi satu atau lebih ukuran numerik.7 Kinerja Pelayanan Rumah Sakit didenormalisasi). called the fact table”. metodologi yang dikemukakan oleh Kimball dalam membangun data warehouse ada B-69 . dengan rumus : adalah sekumpulan tabel-tabel yang lebih kecil dari Jml penderita yang keluar tabel fakta pada model dimensional. Methodology. ”Every dimensional model (DM) LOS = is composed of one table with a composite primary Jml penderita yang keluar key. p1183). dengan mengabaikan bagaimana presentase dari tempat tidur yang tersedia yang mereka dianalisis. Memilih Proses (Choosing the Process) 2. table periode waktu atau per hari. Identifikasi dan Penyesuaian Dimensi organisasi membangun dan memelihara lingkungan (Identifying and Conforming the Dimensions) data warehouse terpusat tunggal. Menurut Connolly dan Begg (2005. p1187-1193). Menurut Siregar (2003. Setiap tabel LOS = dimensi mempunyai non-composite primary key. Memutuskan Prioritas dan Mode dari Query diedarkan melalui banyak lokasi.3 Skema Bintang (Star Schema) 2. Data dalam warehouse terintegrasi antar (Storing Pre-calculation in the Fact-table) perusahaan dan gambaran terintegrasi digunakan f.6 Rumah Sakit Menurut Connolly dan Begg (2005. Seminar Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010) ISSN: 1907-5022 Yogyakarta. Melengkapi Tabel Dimensi (Rounding Out the hanya pada kantor pusat. p193). Jml tempat tidur yang tersedia 2. Memilih Fakta (Choosing the Fact) dilakukan karena beberapa alasan yaitu : e. yang dikenal dengan Nine-step mendukung proses pembuatan keputusan manajerial. Volume data dalam data warehouse seperti h. Karena itu. faktual yang ditempatkan di tengah. Bed Turn Over (BTO) adalah rata-rata penderita adalah satu tabel pada model dimensional yang yang menghuni sebuah tempat tidur selama suatu isinya composite primary key. (Tracking Slowly Changing Dimensions) d.

Penilaian Performa. persentase utilisasi Pada tahap ini dilakukan penyesuaian dimensi sarana rumah sakit. Grain vs Dimensi pada registrasi rawat inap pasien. tindakan operasi. penunjang Grain Jumlah medik. jumlah kunjungan pasien. b. umur. penilaian rawat jalan. dokter. meliputi Jumlah kebutuhan informasi dari pihak eksekutif. registrasi rawat inap. Tabel dimensi yang akan digunakan adalah: dimensi unit. registrasi rawat terhadap data yang dapat dihitung.1. jumlah pasien meninggal. meliputi nilai BOR (lama utilisasi pemakaian fasilitas rumah sakit. fasilitas. proses yang dipilih adalah: proses registrasi rawat f. Pemilihan proses dilakukan untuk memperjelas Fasilitas Rumah Sakit. Pemilihan grain dilakukan untuk memutuskan apa yang direpresentasikan record dari 3. yang ada pada tabel fakta antara lain : jumlah pasien utilisasi fasilitas rumah sakit. SAKIT Kematian. meliputi Jumlah kunjungan Grain merupakan calon fakta yang dapat Pasien. BTO. penunjang tempat tidur dihuni). 19 Juni 2010 3. keluhan. rekam medis. rawat darurat. 3. Kunjungan pasien. Rekam Medis.1. gross date rate (jml pasien meninggal dibagi jml pasien 3. Kalkulasi awal darurat. Adapun pasien rancangan skema bintang dari data warehouse dapat Dimensi dilihat pada gambar 1.1. dan BTO (tingkat hunian tempat tidur). dianalisis. Registrasi Unit Gawat Darurat. asal Tabel 1. meliputi Jumlah Keluhan rekam medis. dan kunjungan pasien menginap). meliputi Jumlah Pemakaian jalan. waktu. registrasi rawat jalan.1. kamar.6 Melengkapi tabel dimensi pada tabel 1. ALOS. keluhan pasien. Berikut contoh dari identifikasi dan penyesuaian dimensi untuk registrasi rawat inap yang dijelaskan 3.1. tindakan medis. Grain yang digunakan dalam Fakta perancangan data warehouse ini yaitu : registrasi Di dalam tabel fakta terdapat kalkulasi awal rawat inap. untuk selanjutnya ditampilkan dalam DimJenisKeluhan FactkeluhanPasien FactPenilaianPerforma DimKamar bentuk tabel atau grafik : PK IdJenisKeluhan NoJenisKeluhan NamaJenisKeluhan FK1 FK2 FK3 IdJenisKeluhan IdDokter IdPeriode BanyakKeluhanPasien FK1 FK2 IdPeriode IdKamar BOR ALOS PK IdKamar NoKamar BanyakBed NamaKelas a. Penunjang Medik. 3. Adapun Pemakaian fasilitas. BOR. Pada Pasien yang mendaftar / melakukan perawatan di umumnya semakin banyak data yang dipindahkan ke unit rawat darurat. dan grain yang ditampilkan dalam bentuk matriks. kematian. penilaian performa.7 Memilih durasi dari basis data yang mendaftar / melakukan perawatan di rawat Pemilihan durasi data histori yang dimiliki oleh jalan. Registrasi Rawat Jalan meliputi Jumlah Pasien 3. Skema bintang data warehouse rumah yang mendaftar / melakukan perawatan di rawat sakit inap.4 Memilih Fakta JumlahPasien PasienRegisterBaru FactTindakanOperasi Sesuai dengan grain yang telah ditentukan FK1 FK2 FK3 IdStatusKeberhasilan IdDokter IdTindakanOpr PK DimDokter IdDokter NoDokter NamaLengkapDokter FactAnalisaPenyakit FK1 FK2 IdUnit IdICD PK DimUnit IdUnit NoUnit FK4 IdPeriode NamaLengkapSpesialisasi NamaLengkapUnit FK3 IdPeriode sebelumnya yang merupakan calon-calon fakta. pasien dan jenis keluhan. registrasi rawat darurat. Tindakan Operasi. meliputi Jumlah Penyakit.2 Memilih Grain g. cara keluar. DATA WAREHOUSE PADA RUMAH d.1. status keberhasilan operasi. diagnose. meliputi Jumlah batasan data warehouse yang akan dibuat. Keluhan Pasien. meliputi Jumlah Pasien BTO Gambar 1.1 Perancangan Data Warehouse kematian keseluruhan.3 Identifikasi dan penyesuaian dimensi keluar) . jumlah tindakan operasi. JumlahTindakan JumlahPenyakit Factkematian Masing-masing fakta memiliki data yang dapat PK DimStatusKeberhasilan IdStatusKeberhasilan Status PK DimTindakanOpr IdTindakanOpr NoTindakanOpr NamaTindakanOpr PK DimICD IdICD NoICD NamaLengkapPenyakit FK1 FK2 IdPeriode IdUnit JumlahMeninggal GDR dihitung.5 Menyimpan Pre-Calculation pada Tabel tabel fakta. status keluar. meliputi Jumlah kematian dan tingkat 3. rumah sakit dapat dilakukan sesuai dengan c. jumlah performa dan kunjungan pasien penyakit terbesar. Umur X PK Dimumur Idumur Dokter X DimPasien Umur RentangUmur PK IdPasien Pasien X DimCaraKeluar DimStatusKeluar NamaJenisPasien PK IdCaraKeluar PK IdStatusKeluar NoPasien NamaPasien CaraKeluar StatusKeluar Wilayah Periode X FactRegisRWJ FactRegisRWI FactRegisUGD FK1 IdUmur FK1 IdUmur Status keluar X FK1 IdUmur FK2 IdDokter FK2 IdDokter DimAsalPasien FK2 IdDokter FK3 IdPasien FK3 IdPasien FK3 IdPasien FK4 IdPeriode FK4 IdPeriode PK IdAsalPasien FK4 IdPeriode JumlahPasien FK5 IdStatusKeluar FK5 IdStatusKeluar FK6 IdCaraKeluar AsalPasien FK6 IdCaraKeluar FK7 IdAsalPasien JumlahPasien Cara Keluar X JumlahPasien DimPenunjangMedik FactPenunjangMedik FactFasilitasRS PK IdPenunjangMedik DimPeriode Asal pasien X NoPenunjangMedik FK1 IdPenunjangMedik FK1 IdFasilitasRS NamaPenunjangMedik FK2 IdPeriode PK IdPeriode FK2 IdPeriode NamaLengkapTarif JumlahPemakaian JumlahPemakaian Tahun Kuartal Bulan DimFasilitasNonRS FactFasilitasNonRS DimFasilitasRS FactPasienUnitBaru PK IdFasilitasNonRS PK IdFasilitasRS NoFasilitasNonRS FK1 IdFasilitasNonRS NoFasilitasRS FK1 IdUnit NamaFasiltasNonRS FK2 IdPeriode NamaFasilitasRS FK2 IdPeriode NamaLengkapTarif JumlahPemakaian NamalengkapTarif 3. ALOS (lama pasien medic. tindakan medis. B-70 . rawat inap. meliputi Jumlah Tindakan. Seminar Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010) ISSN: 1907-5022 Yogyakarta.1. jumlah keluhan. Registrasi Rawat Inap.1 Memilih Proses e.

tipe data.1. Tampilan detil informasi penyakit lama tetap ada dan tidak dihapus.9 Memutuskan prioritas dan mode query dapat dilihat pada tampilan yang ada pada gambar 4 Periode proses extract. Tampilan untuk setting 3.1. Untuk melakukan proses transformasi data juga nama field. Bilamana fasilitas ini tidak tersedia. Tampilan informasi BOR. transform dan load (ETL) dapat dilakukan sesuai dengan kebutuhan informasi oleh pihak eksekutif rumah sakit. ALOS dan untuk membuat proses transformasi data. Halaman dashboard aplikasi data informasi yang bisa dihasilkan. membentuk record baru untuk setiap perubahan baru dan perubahan data yang membentuk kolom baru yang berbeda. secara lebih detil pada gambar berikut ini 3. BTO dan ALOS 3. Data baru akan dimasukkan sebagai record baru dan record Gambar 3. Seminar Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010) ISSN: 1907-5022 Yogyakarta. ukuran dari database sumber. Perlu diperhatikan warehouse rumah sakit pula tingkat akurasi yang dimiliki oleh data histori dengan memperhatikan isi dan format data yang ada.3 Aplikasi Data Warehouse transformasi data dan proses transformasi data dapat Aplikasi data warehouse dibangun untuk dilihat pada gambar 5 dan 6. dapat dilakukan melalui fasilitas yang disediakan pada aplikasi ini. Pada umumnya proses ini dapat dijalankan secara otomatis melalui fasilitas data transformation services (DTS) yang dimiliki oleh database engine pada database sistem informasi rumah sakit ke data warehouse. semakin lengkap pula Gambar 2. 3. dapat dilihat data sampah yang tidak bermanfaat sama sekali. maka proses pemindahan data dapat dilakukan oleh personil TI rumah sakit secara manual. digunakan oleh para eksekutif rumah sakit. Berdasarkan layar dashboard untuk eksekutif Jangan sampai data yang dipindahkan merupakan seperti yang tertera pada gambar 2. Hal ini dilakukan agar semua perubahan yang terjadi dapat ditelusuri. maka akan dibentuk record baru pada tabel dimensi. B-71 . Bentuk halaman utama dari aplikasi data warehouse dapat dilihat pada gambar 2. Sedangkam untuk melihat tingkat kinerja dari rumah sakit berdasarkan BOR.2 Metadata Metadata merupakan informasi yang mencatat tentang data yang digunakan sebagai alat bantu Gambar 4. Umumnya BTO metadata berisi atribut seperti nama field. Pada data warehouse ini telah dipilih cara kedua yaitu jika ada perubahan data. tipe data.8 Melacak perubahan dari dimensi secara perlahan Mengamati perubahan dari dimensi pada table dimensi dapat dilakukan dengan 3 cara yaitu mengganti secara langsung pada tabel dimensi. 19 Juni 2010 dalam data warehouse. dan ukuran dari data warehouse serta nama tabel.

(2005). PUSTAKA Connolly. Building the Data Warehouse. Thomas M. Hub. Begg. Hardisk dengan kapasitas 320GB SATA II. Kebutuhan keamanan komputer seperti UPS. dan Amalia. W. Media backup data. Wiley Publishing. Monitor. Pengguna: Sistem Operasi Windows XP. Database Systems : A Practical Approach to Design. SIMPULAN Dengan akan diimplementasikannya aplikasi data warehouse pada rumah sakit. Gambar 6. (2005). Jakarta. Server dengan spesifikasi teknis minimal sebagai berikut: Intel Pentium Q6600 QuadCore. Indianapolis.4 Kebutuhan Sistem Agar aplikasi dapat berjalan dengan baik. Longman Inc. Addison Wesley. and Management. diharapkan dapat memenuhi kebutuhan dan keinginan informasi oleh pihak eksekutif rumah sakit yang terkait dengan kinerja rumah sakit. USA.. d. Kemampuan pengolahan data dalam jumlah besar B-72 . Sedangkan kebutuhan piranti lunak untuk menjalankan aplikasi data warehouse adalah sebagai berikut: a. Edisi 2. Jakarta. Mouse dan Keyboard. dengan database Microsoft SQL Server 2005. Hardisk 80GB. diharapkan ketersediaan informasi dari berbagai sudut pandang yang berbeda dapat memenuhi harapan dari pimpinan rumah sakit. Indiana. (2004). Memori 4 GB ECC..H. Implementation. Edisi ke-1.8 Ghz. Lia.A Gde. Server: Sistem Operasi Window 2003 Server. dan aplikasi data warehouse yang sudah diinstall. Tampilan tabel fakta dan dimensi yang tidak lagi menjadi halangan bagi personil TI di dapat di transformasi rumah sakit untuk menyiapkan seluruh kebutuhan informasi yang diperlukan. Muninjaya. Tampilan setting Data Transformation services (DTS) 3. EGC. Charles J. Memori 1GB. 4th Edition. b. 4th Edition. Dengan kemampuan yang ditawarkan pada aplikasi ini. Seminar Nasional Aplikasi Teknologi Informasi 2010 (SNATI 2010) ISSN: 1907-5022 Yogyakarta. 4. Pengguna dengan spesifikasi teknis minimal sebagai berikut: Processor Dual Core 2. switch. Farmasi Rumah Sakit Teori & Penerapan. and Carolyn E. 19 Juni 2010 Gambar 5. Siregar. Kebutuhan Jaringan seperti: Jaringan internet. c. Manajemen Kesehatan.P. Inmon. Inc. A. (2003). Kedokteran EGC. b. maka kebutuhan perangkat keras yang harus disediakan adalah sebagai berikut: a. Mouse dan Keyboard. Monitor.