Sistem Informasi Klinik Internal Perusahaan

PreWords

Awalnya dari seorang teman yang bekerja di salah satu perusahaan manufaktur industri otomotif terkemuka di Indonesia, perusahaan yang sudah tidak asing lagi dan cukup lama berdiri ini ternyata hanya memiliki klinik yang tergolong cukup kecil untuk perusahaan sebesar itu. Hanya saja mungkin keperluan dari klinik juga tidak menuntut kebutuhan yang lengkap, sebut saja hanya penanganan pencegahan pada karyawannya jika terjadi permasalahan kesehatan tertentu. Atau hanya sekedar membutuhkan obat atau mulitivitamin saja.

Aktor

Oleh karena itu kebutuhan dari sisi pengguna system juga hanya ada 2 (dua) stakeholder yang berkepentingan:

• Si Pemilik Usaha itu sendiri, dan
• Si Karyawan selaku Operator Administrasi.

Akan selalu ada Non-Human Actor yang kita butuhkan untuk membangun system berBasis Client-Server, karena komputer yang tersedia di sana ada lebih dari 1 (satu). Komputer untuk server, untuk si operator melakukan pencatatan transaksi, dan dokter yang kadang suka membawa laptop-nya untuk keperluan pribadi.

Penggunaan System

Cara memulainya juga seperti biasa pada system yang berbasis Client-Server, yaitu pengguna harus melakukan log pada jendela login untuk system menentukan verifikasi level akses untuk keperluan keamanan.

Berikut adalah tampilan dari SplashScreen sebagai respon jika kita membuka program ini.

Pengguna cukup memasukkan ID dan PassWord yang ditentukan sebelumnya oleh System Administrator.

Kebutuhan System

Secara global, kebutuhan dari system ini juga sangat sederhana. Yaitu: kebutuhan penanganan transaksi dan pelaporan. Operator selaku karyawan dari klinik berperan sebagai Petugas Administrasi yang melakukan kegiatan rutin menangani pelayanan administrasi klinik dan si Pemilik Usaha (di sana ia berperan sebagai dokter) yang membutuhkan pelaporan hasil dari kegiatan usahanya.

Berikut adalah tampilan jendela utama dari system, tercatat di sana system ini dah dari Mei 2011. Ga kerasa juga ya? =D

Karena kebutuhan sederhana, ya menunya juga sesuai kebutuhan:

• Pengaturan,
• Transaksi, dan
• Pelaporan.

Hanya menu pengaturan yang memiliki kebutuhan paling banyak di antara menu lainnya, sebab biasanya menu pengaturan ini yang akan dikonfigurasi pertama kali. Selanjutnya biasanya hanya akan digunakan jika ada penambahan atau pengubahan tertentu.

Kebutuhan transaksi merupakan generalisasi dari 2 (dua) kebutuhan berikut: mencatat transaksi jasa dan obat yang dikeluarkan. Keduanya harus dapat dilakukan dalam 1 (satu) transaksi agar bukti keluaran sekaligus mencatat keduanya. Hm.. akan dikupas lebih lanjut pada sesi yang bersangkutan. OK? =)

Kebutuhan Konfigurasi System

Amat sangat sederhana, entitas yang dibutuhkan kurang lebih hanya ini. Kalo kita punya FrameWork yang dah bisa diDivide jadi partikel yang bener-bener bisa diAssembling sesuai kebutuhan alangkah indahnya! (cuma entah kapan bisa punya FrameWork kaya gitu, ngayal aja dulu. Sapa tau jadi kenyataan.. =D ).

Identitas dari Lembaga

Biasanya hanya untuk Header Pelaporan, entitas ini kita butuhkan supaya setiap kali mencetak keluaran ada semacam kop surat identitas dari perusahaan atau lembaga tertentu. Di system tertentu yang lebih canggih: mungkin dimanfaatkan untuk keperluan registrasi dari ekspirasi program.

Departemen

Karena pada saat itu perusahaan terdiri dari beberapa departemen, makanya entitas ini harus ada. Untuk identifikasi si pasien berasal dari departemen mana. Mungkin di sebagian perusahaan yang lain memiliki turunan divisi dari sebuah departemen.

Poli Klinik

Hm.. sbenarnya untuk poli si tidak terlalu dibutuhkan pada saat itu, sebab hanya ada 2 (dua) poli, yaitu: Poli Gigi dan Umum. Hm.. mungkin bisa dibentuk hanya dengan sebuah tombol option misalnya. Cuma karena untuk membedakan, entitas ini akhirnya dibuat. Tapi bisa jadi suatu saat untuk kebutuhan implementasi di klinik lain.

Dokter

Dokter berperan pada scenario transaksi, tidak terlalu spesifik. Hanya sebagai relasi siapa yang menangani seorang pasien tertentu.

Asuransi

Kadang ada pasien yang memiliki asuransi dari luar, kebutuhannya untuk penagihan ke perusahaan penyedia asuransi tersebut. Oleh karena itu sebagai bukti yang akan dilampirkan di transaksi, entitas ini juga diperlukan. Walaupun sbenarnya kebanyakan menggunakan asuransi yang telah disediakan oleh internal perusahaan.

Pasien

Ini adalah layout dari form utama pasien, perlakuannya sama dengan master lainnya pada umumnya.

Dan berikut adalah jendela editingnya, identifikasinya adalah: berasal dari departemen mana, penanggung yang bertanggung jawab terhadap pasien ini dan identitas dari pasien itu sendiri. Klinik ini biasanya menangani kurang lebih puluhan bahkan ratusan pasien setiap harinya.

Summary Konfigurasi

Kita akan menarik diri ke atas, terbang dan memandang kasus dari peran sebagai seekor burung yang terbang. Theory ini biasa disebut: BirdView, yaitu cara pandang dari atas agar tidak terjebak pada kerumitan suatu permasalahan. Beretorika ga pa-pa ya? =D

Ini kombinasi dari generalisasi dan komposisi, mengenai detail apa itu generalisasi dan komposisi dapat dipelajari dari UML. Silahkan mencari referensi sendiri mengenai hal itu. Pada beberapa chapter sebelumnya yang saya tulis juga banyak terdapat mengenai kebutuhan dengan pemilahan ini.

Menyederhanakan tingkat kerumitan agar mengetahui mana hubungan komposisi bisa dapat dipisahkan jika diperlukan, agar permasalahan benar-benar dapat dipetakan. Untuk membedakan mana karyawan internal dan karyawan klinik, saya membuatnya menjadi: entitas Pegawai dan entitas Karyawan. Hm.. keduanya sebenarnya bisa diGeneralisasikan menjadi satu entitas, katakan: kontak, tapi pada saat itu pertimbangannya masalah waktu, deadline! Jadi supaya cepet aja.. =D

Pembiayaan Jasa

Biaya untuk klinik seKecil itu juga banyak, pengelola menerapkan tarif yang berbeda-beda. Supaya diperoleh keluaran pelaporan yang lebih terManage, kita bisa mengelompokkannya menjadi per jenis.

Dan akhirnya, biaya itu sendiri. Penanganan pembiayaan ini bisa jadi amat sangat rumit dalam lingkup rumah sakit, apalagi rumah sakit dengan golongan A yang memiliki pelayanan kesehatan yang mencakup pelayanan menyeluruh. Yang jelas cukup bikin rambut kita jadi keriting.. =D

Obat

Ada 1 (satu) hal yang cukup menarik dalam kasus apotik, yaitu barang yang dapat diAssembling seperti halnya pada sebuah manufaktur. Atau barang rakitan seperti halnya pada industri kecil (industri rumahan misalnya), dan di apotik ini: biasanya disebut racikan. Jadi suatu obat berelasi dengan dirinya sendiri karena memang dirakit atau diAssembling dengan obat lain. Hasilnya adalah: 1 (satu) entitas yang menjadi barang lagi yang bisa kita sebut dengan namanya sendiri, contoh: puyer. =)

Satuan selalu diperlukan untuk kasus penanganan entitas barang, agar dapat diukur kalkulasinya. Multi-Satuan adalah implementasi penanganan barang dalam industri penjualan eceran. Itu adalah salah satu contoh kasus yang memerlukan ketelitan tinggi dalam penanganannya.. Dalam hal ini, satuan masih dalam batas yang wajar.

Jenis juga selalu dibutuhkan untuk pengelompokan yang sederhana jika memiliki suatu entitas yang membutuhkan diversifikasi dari kuantitas dalam jumlah banyak, mungkin bisa diturunkan lagi jika memang diperlukan, misalnya: tiap jenis memiliki type lagi.. dst..

Dalam penanganan barang yang diAssembling atau diRakit, harus ada handle untuk keperluan itu. Kita create 1 (satu) item, kemudian tentukan item tersebut dibentuk oleh komposisi apa saja. Perhatikan ilustrasi di atas, sebuah puyer memiliki komposisi lagi di dalamnya. Kira-kira begitu handle-nya.. =)

Berikut ilustrasi untuk membuat suatu item, penetapan harga juga ditentukan pada saat ini. Hm.. di sebuah lembaga kesehatan tertentu, biasanya rumah sakit, penetapan harga per asuransi juga berlaku. Jadi, tidak semua pasien dapat memperoleh obat dengan harga sama rata dengan pasien lainnya.

Kita dapat melihat bagaimana sebuah item: puyer diracik dari obat yang lain juga. Prinsip handle-nya sama dengan jenis barang rakitan pada industri lainnya, hanya implementasinya aja yang berbeda. OK?

Demikian penanganan pengaturan dari system ini, penanganan ini biasanya hanya dilakukan sekali saja pada saat awal system diImplementasikan. Selanjutnya biasanya jika ada penambahan atau pengubahan tertentu saja. Hm.. mungkin bisa lebih aman jika pengaturan ini hanya dapat dilakukan oleh aktor tertentu saja, tujuannya agar pengubahan tidak dapat dilakukan sembarang. Harga misalnya, bisa jadi ada kepentingan pihak yang tidak bertanggung jawab. Berikan hak akses administrator untuk dapat melakukan hal ini!

Kebutuhan Transaksi

Setelah membahas mengenai konfigurasi pada system, sekarang saatnya melakukan transaksi. Aktor yang berperan dalam hal ini adalah si karyawan dari klinik itu sendiri, sebagai pekerjaan rutinitas setiap harinya. Karena si pemilik usaha dalam hal ini berperan sebagai penerima laporan hasil usahanya saja.

Transaksi pada klinik, umumnya hanya terdiri dari transaksi jasa dan obat. Di lembaga kesehatan yang lebih besar, rumah sakit misalnya; mungkin bisa memuat transaksi dengan detail sebagai berikut:

• Kamar,
• Perawatan Inap,
• Laboratorium,
• Magnetic Resonance Imaging (MRI),
• Radiologi,
• Alat Kesehatan,
• Obat,
• Rawat Jalan,
• Konsultasi,
• Dan sebagainya.

Pada prinsipnya sama, yaitu: 1 transaksi yang memiliki banyak detail.

Sebagai kebutuhan transaksi tersebut, kita memerlukan handle di antaranya: untuk entry header dari transaksi, detail jasa dan detail obatnya. Ada 2 (dua) jenis pencetakan, faktur dan pelaporan. Atau jika ingin diGeneralisasikan mengenai output keluaran juga tidak masalah, di sini hanya untuk membedakan agar petugas bisa langsung akses tombol faktur untuk mencetak bukti transaksi, sementara keluaran output yang lain dapat diAkses melalui tombol laporan.

Header Transaksi

Berikut adalah contoh dari Header Transaksi yang dibutuhkan pada saat itu. Pada tanggal berapa transaksi terjadi, siapa yang diperiksa, dokter yang melakukan pemeriksaan dan untuk poli mana. Jika dibutuhkan keterangan lebih, dapat dicatat pada kolom keterangan yang tersedia. Klik tombol OK dan Header pun tersimpan.

Item Jasa

Sebenarnya jasa merupakan satuan dari item transaksi, karena ia memiliki tarif yang ditetapkan oleh klinik. Oleh karena itu diperlakukan sama halnya dengan item barang. Tarif di sini masih berkisar ratusan ribu saja yang paling mahal, tidak melebihi nilai dari itu.

Item Obat 

Dan Obat itu sendiri yang melengkapi transaksi ini, jadi setelah pasien diperiksa, ia dapat langsung memperoleh obatnya. Bagaimana jika jasa tidak diperlukan? Pasien dapat langsung membeli obat saja selayaknya di apotik. Oh ya, dalam kasus ini: tidak ada pembayaran tunai! Sebab pembayaran berupa reImbursement ke perusahaan terkait. Kelihatannya jadi kaya gratis, tapi mungkin dipotong dari pendapatan pegawai masing-masing. =)

Output Transaksi

Berikut adalah layout output keluaran berupa faktur yang dalam 1 (satu) transaksi memuat 2 (dua) detail sekaligus, tujuannya agar tidak terpisah masing-masing detailnya. Seperti yang disebutkan di atas, dalam sebuah rumah sakit mungkin faktur bisa lebih panjang bentuknya, mengingat detail pelayanan yang memiliki ruang lingkup yang luas.

Kebutuhan Pelaporan

Dan terakhir, kebutuhan akan pelaporan bagi pemilik usaha. Kebutuhan yang hanya dapat diAkses oleh si pemilik usaha itu sendiri, dalam hal ini ia juga berperan sebagai dokter di sana. Juga dapat diterapkan pemberian level akses untuk dapat membuka fasilitas pelaporan ini..

Filtrasi Pelaporan

Pelaporan dapat diFiltrasi sesuai dengan tanggal dan entitas yang lain, sebut saja:

• Per Transaksi,
• Jenis Pasien,
• Asuransi (jika pasien tidak menggunakan asuransi internal),
• Per Poli, dan
• Dokter yang menangani.

Output Pelaporan

Berikut adalah pelaporan yang diFiltrasi berdasarkan nomor transaksi, dengan demikian kita sudah sampai di penghujung sesi kali ini. Hm.. masih amat sangat sederhana dan memungkinkan untuk dikembangkan lebih lanjut.. =)