System Requirements Document for rumah-sakit-administrasi

1. Introduction

Rumah Sakit Dhela Grup membutuhkan sebuah sistem administrasi rumah sakit berbentuk aplikasi yang lengkap, dengan cover dan template profesional yang lebih baik. Pemilik sekaligus direktur rumah sakit bertindak sebagai admin sistem, dan sistem ini menjadi tulang punggung administrasi harian rumah sakit: mulai dari pendaftaran pasien, pengelolaan data tenaga medis dan non-medis, rekam pasien per ruangan, penerbitan surat resmi poli, hingga pemantauan kondisi setiap ruangan melalui dasbor masing-masing.

Produk ini ditujukan untuk:

• Direktur / Pemilik Rumah Sakit (Admin) — pemilik tunggal kendali administrasi dan pemantauan seluruh modul.
• Perawat Ruangan — pengguna operasional yang mencatat dan memantau data pasien di ruangan tempat ia bertugas, dengan akun masing-masing.
• Petugas Poli — pengguna yang melayani kunjungan poli dan menerbitkan surat keterangan sakit serta surat cetak obat untuk farmasi.
• Dokter — tenaga medis yang datanya tercatat lengkap sesuai hukum yang berlaku dan yang menandatangani surat-surat poli.
• Pendaftar Online (Masyarakat Umum) — siapa pun yang mengakses pendaftaran online melalui barcode atau tautan.

Sistem ini bersifat operasional-kritis dan dokumenter-legal: waktu, dosis, nomor antrean, status ruangan, dan dokumen resmi harus terbaca sebagai nilai terukur pada instrumen yang dapat dipercaya.

2. System Overview

Aplikasi administrasi Rumah Sakit Dhela Grup adalah aplikasi web dengan backend terintegrasi yang menyediakan:

• Dasbor utama untuk pemantauan administrasi rumah sakit oleh admin.
• Pendaftaran online publik yang dapat diakses semua orang melalui barcode atau tautan, mencakup pendaftaran kunjungan poli dan pengambilan obat farmasi, dengan nomor antrean otomatis sesuai nomor urut.
• Pengelolaan data tenaga medis (dokter, perawat, farmasi, ahli gizi) lengkap sesuai hukum yang berlaku.
• Pengelolaan data pasien per ruangan dengan kriteria diagnosa lengkap, keterangan pelaksanaan, pemberian obat lengkap dengan jam dan tanggal, hasil lab, metode pelaporan S.B.A.R, kelompok penyakit sesuai diagnosa, unggah file seperti foto thorak dan ronsen, keterangan jam masuk dan jam pulang, serta keterangan rujuk atau meninggal dunia.
• Pengelolaan data ruangan lengkap: rawat inap, medikal bedah, IGD dan UGD, ICU, NICU, anak, farmasi, keamanan, dan poli lengkap — masing-masing dengan dasbor sendiri.
• Pengelolaan data karyawan non medis: petugas kebersihan, satpam, sarana dan prasarana, serta supir ambulan.
• Penerbitan surat poli berupa surat keterangan sakit dan surat cetak obat untuk farmasi, lengkap dengan kop surat, keterangan obat, dan tanda tangan dokter yang bertugas di poli tersebut.
• Akses perawat per ruangan: data pasien hanya dapat diakses oleh akun perawat yang bertugas di ruangan masing-masing.

2a. Product Interpretation and Delivery Boundary

Kepemilikan akses dan identitas. Aplikasi ini memiliki identitas sendiri. Admin, perawat, petugas poli, dan dokter masuk melalui halaman Login untuk mengakses area kerja yang terlindungi. Halaman Landing dan Pendaftaran online bersifat publik dan dapat diakses tanpa identitas, sesuai pernyataan eksplisit bahwa pendaftaran online "harus bisa di akses oleh semua orang dalam bentuk barcode atau link". Penetapan perawat pada ruangan tugasnya dan penetapan dokter penanggung jawab poli adalah mekanisme yang diperlukan agar pembatasan akses pasien per ruangan dan penandatanganan surat poli dapat berjalan; keduanya merupakan inferensi wajib, bukan fitur tambahan.

Batas saat ini. Seluruh modul yang diminta — Dasbor, Pendaftaran online, Data dokter, Data perawat, Data farmasi, Data ahli gizi, Data pasien, Data ruangan, Data karyawan non medis, Surat Poli, Landing, dan Login — berada dalam horizon saat ini.

Batas masa depan. Tidak ada permintaan eksplisit untuk fitur masa depan dalam sumber otoritatif. Tidak ada modul, halaman, atau kemampuan yang ditambahkan di luar yang diminta.

Pengecualian. Tidak ada pengecualian eksplisit yang dinyatakan pengguna. Sistem tidak menambahkan modul di luar daftar yang diminta (misalnya billing, klaim asuransi, atau rekam medis elektronik lintas fasilitas) karena tidak diminta.

2c. Page Content and Component Coverage

Landing

• Informasi/state: Identitas Rumah Sakit Dhela Grup, penjelasan singkat fungsi aplikasi administrasi, sasaran pengguna (admin, perawat, petugas poli, dokter, masyarakat umum), dan dua jalur masuk: area kerja terlindungi dan pendaftaran publik.
• Aksi utama: Tombol MASUK SEBAGAI ADMIN menuju Login; tautan PENDAFTARAN ONLINE dengan glyph QR menuju Pendaftaran online.
• Aksi pendukung: Navigasi ke informasi kontak/alamat rumah sakit bila tersedia; gulir ke bagian penjelasan modul.
• Entitas domain: Rumah Sakit Dhela Grup, modul aplikasi, peran pengguna.
• Tanggung jawab komponen: Hero full-bleed dark titanium dengan headline besar "RUMAH SAKIT DHELA GRUP" dan subjudul "Sistem Administrasi Rumah Sakit"; gauge instrumen melingkar dengan arc amber, tick teal live, dan angka tabular jumlah pasien hari ini; baris empat readout status (IGD, ICU, NICU, Poli) dengan label kecil uppercase dan angka tabular besar; rail instrumen kiri dengan wordmark dan daftar modul.
• State: Loading — skeleton pada gauge dan readout; Empty — bila belum ada data pasien hari ini, gauge menampilkan 0 dengan label "BELUM ADA DATA HARI INI"; Success — gauge dan readout terisi; Error — pesan "Data tidak dapat dimuat" dengan tombol coba lagi; Recovery — pengguna tetap dapat menuju Login atau Pendaftaran online meski data gagal dimuat.

Pendaftaran online

• Informasi/state: Formulir pendaftaran publik untuk dua jenis layanan — kunjungan poli dan pengambilan obat farmasi; pilihan poli/tujuan; data identitas pendaftar; ringkasan sebelum kirim; nomor antrean yang diterbitkan otomatis sesuai nomor urut.
• Aksi utama: Kirim pendaftaran; menerima nomor antrean.
• Aksi pendukung: Membaca ulang ringkasan; kembali mengubah data sebelum kirim; menyalin/menyimpan nomor antrean.
• Entitas domain: Pendaftaran, jenis layanan (kunjungan poli / pengambilan obat farmasi), poli tujuan, nomor antrean, urutan pendaftaran.
• Tanggung jawab komponen: Halaman publik sederhana bergaya dark titanium; pemilih jenis layanan; field identitas pendaftar; pemilih poli; tombol kirim berbentuk key persegi; panel hasil dengan nomor antrean amber besar, nama ruangan/poli, dan estimasi waktu di bawahnya.
• State: Loading — tombol kirim menampilkan status proses; Empty — formulir kosong dengan placeholder; Success — nomor antrean tampil besar dengan tick teal; Error — pesan kegagalan kirim dengan tombol coba lagi tanpa kehilangan data yang telah diisi; Recovery — pendaftar dapat mengirim ulang dan tetap menerima nomor antrean berikutnya sesuai urutan.

Login

• Informasi/state: Formulir masuk untuk admin, perawat, petugas poli, dan dokter; identitas peran setelah berhasil masuk.
• Aksi utama: Masuk ke area kerja terlindungi.
• Aksi pendukung: Tautan kembali ke Landing; tautan ke Pendaftaran online bagi masyarakat umum.
• Entitas domain: Akun pengguna, peran (admin / perawat / petugas poli / dokter), ruangan tugas (untuk perawat).
• Tanggung jawab komponen: Panel masuk bergaya instrumen dengan field identitas dan kredensial; tombol masuk berbentuk key persegi amber; pesan kesalahan inline.
• State: Loading — tombol menampilkan status proses; Empty — field kosong; Success — pengalihan ke Dasbor atau area kerja sesuai peran; Error — pesan kredensial tidak valid; Recovery — pengguna dapat mencoba lagi tanpa kehilangan konteks.

Dasbor

• Informasi/state: Ringkasan administrasi rumah sakit: jumlah pasien, status ruangan, antrean berjalan, dan indikator modul.
• Aksi utama: Membuka modul dari rail instrumen; menavigasi ke Data pasien, Data ruangan, dan modul lainnya.
• Aksi pendukung: Melihat detail ruangan; melihat antrean terkini.
• Entitas domain: Pasien, ruangan, antrean, tenaga medis, tenaga non medis.
• Tanggung jawab komponen: Gauge instrumen melingkar sebagai hero dasbor dengan arc amber dan tick teal live; baris readout status ruangan; rail instrumen kiri dengan modul sebagai label terukir; top status strip dengan tanggal, shift, jumlah antrean live, dan peran yang masuk.
• State: Loading — skeleton pada gauge dan tabel; Empty — tampilan "Belum ada data" pada setiap panel; Success — gauge, readout, dan tabel terisi; Error — pesan gagal memuat dengan tombol coba lagi; Recovery — modul lain tetap dapat dibuka meski satu panel gagal.

Data dokter

• Informasi/state: Daftar dokter lengkap sesuai hukum yang berlaku; detail per dokter; penetapan dokter penanggung jawab poli.
• Aksi utama: Menambah, mengubah, dan menghapus data dokter; menetapkan dokter pada poli.
• Aksi pendukung: Mencari dan menyaring daftar; melihat detail.
• Entitas domain: Dokter, data legal/izin, poli penugasan.
• Tanggung jawab komponen: Tabel ruled dengan kolom bergaris seperti readout instrumen; panel detail dua kolom; form tambah/ubah; penanda dokter bertugas di poli.
• State: Loading — skeleton tabel; Empty — "Belum ada data dokter" dengan tombol tambah; Success — baris data tampil; Error — pesan gagal simpan dengan data form tetap utuh; Recovery — pengguna dapat memperbaiki dan menyimpan ulang.

Data perawat

• Informasi/state: Daftar perawat lengkap sesuai hukum yang berlaku; penetapan ruangan tugas per perawat.
• Aksi utama: Menambah, mengubah, dan menghapus data perawat; menetapkan ruangan tugas.
• Aksi pendukung: Mencari dan menyaring; melihat detail.
• Entitas domain: Perawat, data legal/izin, ruangan tugas.
• Tanggung jawab komponen: Tabel ruled; panel detail; pemilih ruangan tugas; penanda ruangan aktif.
• State: Loading — skeleton tabel; Empty — "Belum ada data perawat" dengan tombol tambah; Success — baris data tampil; Error — pesan gagal simpan; Recovery — perbaikan dan simpan ulang.

Data farmasi

• Informasi/state: Daftar tenaga farmasi lengkap sesuai hukum yang berlaku.
• Aksi utama: Menambah, mengubah, dan menghapus data farmasi.
• Aksi pendukung: Mencari dan menyaring; melihat detail.
• Entitas domain: Tenaga farmasi, data legal/izin.
• Tanggung jawab komponen: Tabel ruled; panel detail; form tambah/ubah.
• State: Loading; Empty — "Belum ada data farmasi"; Success; Error — gagal simpan; Recovery — perbaikan dan simpan ulang.

Data ahli gizi

• Informasi/state: Daftar ahli gizi lengkap sesuai hukum yang berlaku.
• Aksi utama: Menambah, mengubah, dan menghapus data ahli gizi.
• Aksi pendukung: Mencari dan menyaring; melihat detail.
• Entitas domain: Ahli gizi, data legal/izin.
• Tanggung jawab komponen: Tabel ruled; panel detail; form tambah/ubah.
• State: Loading; Empty — "Belum ada data ahli gizi"; Success; Error — gagal simpan; Recovery — perbaikan dan simpan ulang.

Data pasien

• Informasi/state: Rekam pasien per ruangan dengan kriteria diagnosa lengkap, keterangan pelaksanaan, pemberian obat lengkap dengan jam dan tanggal, hasil lab, metode pelaporan S.B.A.R, kelompok penyakit sesuai diagnosa, lampiran file seperti foto thorak dan ronsen, keterangan jam masuk dan jam pulang, serta keterangan rujuk atau meninggal dunia.
• Aksi utama: Mencatat dan memperbarui data pasien; mengunggah file pemeriksaan; mencatat pemberian obat dengan jam dan tanggal; mencatat hasil lab; menulis laporan S.B.A.R; menandai status rujuk atau meninggal dunia; mencatat jam masuk dan jam pulang.
• Aksi pendukung: Mencari pasien dalam ruangan; menyaring berdasarkan kelompok penyakit/diagnosa; melihat riwayat.
• Entitas domain: Pasien, ruangan, diagnosa, kelompok penyakit, pelaksanaan, pemberian obat (jam, tanggal), hasil lab, laporan S.B.A.R, lampiran (foto thorak, ronsen), jam masuk, jam pulang, status rujuk, status meninggal dunia.
• Tanggung jawab komponen: Panel instrumen dua-pane: kiri = identitas, kriteria diagnosa, jam masuk/pulang, status rujuk atau meninggal; kanan = jadwal obat dengan cap waktu tabular, hasil lab, dan tile unggahan X-ray/thorax; kolom S.B.A.R; tabel ruled dengan band bergantian; pembatas amber 3px antar bagian.
• State: Loading — skeleton pada kedua pane; Empty — "Belum ada pasien di ruangan ini"; Success — data lengkap tampil; Error — pesan gagal simpan/unggah dengan data form tetap utuh; Recovery — pengguna dapat mengunggah ulang atau menyimpan ulang tanpa kehilangan entri lain.

Data ruangan

• Informasi/state: Daftar ruangan lengkap: rawat inap, medikal bedah, IGD dan UGD, ICU, NICU, anak, farmasi, keamanan, dan poli lengkap; masing-masing dengan dasbor sendiri.
• Aksi utama: Menambah, mengubah, dan menghapus data ruangan; membuka dasbor ruangan.
• Aksi pendukung: Mencari dan menyaring ruangan; melihat status hunian.
• Entitas domain: Ruangan, jenis ruangan, dasbor ruangan, hunian.
• Tanggung jawab komponen: Tabel ruled daftar ruangan; ring gauge hunian per ruangan; pembatas amber 3px; tautan ke dasbor masing-masing ruangan.
• State: Loading; Empty — "Belum ada data ruangan"; Success — daftar dan gauge tampil; Error — gagal memuat/simpan; Recovery — muat ulang atau simpan ulang.

Data karyawan non medis

• Informasi/state: Daftar karyawan non medis: petugas kebersihan, satpam, sarana dan prasarana, serta supir ambulan.
• Aksi utama: Menambah, mengubah, dan menghapus data karyawan non medis.
• Aksi pendukung: Mencari dan menyaring berdasarkan kategori; melihat detail.
• Entitas domain: Karyawan non medis, kategori (petugas kebersihan, satpam, sarana dan prasarana, supir ambulan).
• Tanggung jawab komponen: Tabel ruled dengan kolom kategori; panel detail; form tambah/ubah.
• State: Loading; Empty — "Belum ada data karyawan non medis"; Success; Error — gagal simpan; Recovery — perbaikan dan simpan ulang.

Surat Poli

• Informasi/state: Ruang kerja poli untuk menerbitkan surat keterangan sakit dan surat cetak obat untuk farmasi; pratinjau surat sebagai lembar A4 dengan kop surat lengkap, tabel obat bergaris, dan blok tanda tangan dokter yang bertugas di poli tersebut.
• Aksi utama: Membuat surat keterangan sakit; membuat surat cetak obat; menerbitkan surat dengan kop, keterangan obat, dan tanda tangan dokter bertugas.
• Aksi pendukung: Memilih pasien/kunjungan; memilih dokter bertugas di poli; mencetak atau menyimpan surat.
• Entitas domain: Surat keterangan sakit, surat cetak obat, kop surat, keterangan obat, dokter bertugas, poli, tanda tangan.
• Tanggung jawab komponen: Panel pemilihan pasien dan dokter; editor rincian obat; pratinjau A4 berbingkai dengan letterhead penuh; blok tanda tangan dokter; tombol terbitkan dan cetak.
• State: Loading — skeleton pratinjau; Empty — "Belum ada surat dibuat" dengan tombol buat surat; Success — surat terbit dengan kop, rincian obat, dan tanda tangan dokter; Error — pesan gagal terbit bila dokter bertugas belum ditetapkan atau data tidak lengkap; Recovery — pengguna dapat melengkapi data dan menerbitkan ulang.

3. Functional Requirements

Setiap persyaratan diberi label provenance: explicit (dinyatakan pengguna), basic_default (default yang wajar), atau required_inference (mekanisme wajib yang disimpulkan).

FR-01 — Sistem administrasi rumah sakit. Sebagai Direktur / Pemilik Rumah Sakit (Admin), saya harus memiliki sistem administrasi rumah sakit berbentuk aplikasi untuk RUMAH SAKIT DHELA GRUP, agar seluruh administrasi rumah sakit dapat dikelola dalam satu sistem. (explicit)

• Aktor: Admin. Trigger: membuka aplikasi. Hasil: aplikasi administrasi tersedia dan dapat diakses. Akses: area kerja terlindungi setelah Login. Kegagalan: bila aplikasi tidak dapat dimuat, pengguna mendapat pesan dan dapat mencoba lagi. Kelanjutan: pengguna masuk ke Dasbor.

FR-02 — Cover dan template profesional. Sebagai Admin, saya harus mendapatkan aplikasi yang lengkap dengan cover dan template profesional yang lebih bagus, agar tampilan institusi terasa serius dan terpercaya. (explicit)

• Aktor: Admin. Trigger: membuka Landing dan area kerja. Hasil: cover dan template profesional tampil konsisten. Akses: Landing publik; area kerja terlindungi. Kegagalan: bila aset tampilan gagal dimuat, konten tetap terbaca. Kelanjutan: pengguna melanjutkan ke modul.

FR-03 — Peran admin. Sebagai Direktur / Pemilik Rumah Sakit, saya bertindak sebagai admin sistem, agar saya memegang kendali penuh atas administrasi. (explicit)

• Aktor: Admin. Trigger: masuk melalui Login. Hasil: akses ke modul administrasi. Akses: area kerja terlindungi. Kegagalan: kredensial tidak valid ditolak dengan pesan. Kelanjutan: pengguna mengelola modul.

FR-04 — Modul Dasbor. Sebagai Admin, saya harus memiliki modul Dasbor, agar dapat memantau administrasi rumah sakit. (explicit)

• Aktor: Admin. Trigger: membuka Dasbor. Hasil: ringkasan administrasi tampil. Akses: area kerja terlindungi. Kegagalan: panel gagal dimuat menampilkan pesan dan tombol coba lagi. Kelanjutan: pengguna membuka modul terkait.

FR-05 — Modul Pendaftaran online. Sebagai Pendaftar Online (Masyarakat Umum), saya harus dapat melakukan pendaftaran online, agar saya dapat mendaftar tanpa datang lebih dulu. (explicit)

• Aktor: Pendaftar Online. Trigger: membuka tautan/barcode pendaftaran. Hasil: pendaftaran tercatat. Akses: publik tanpa identitas. Kegagalan: kirim gagal menampilkan pesan tanpa menghilangkan data. Kelanjutan: pendaftar menerima nomor antrean.

FR-06 — Data dokter lengkap sesuai hukum. Sebagai Admin, saya harus mengelola data dokter lengkap sesuai hukum yang berlaku. (explicit)

• Aktor: Admin. Trigger: membuka Data dokter. Hasil: data dokter tersimpan lengkap. Akses: area kerja terlindungi. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: data tersedia untuk penugasan poli.

FR-07 — Data perawat lengkap sesuai hukum. Sebagai Admin, saya harus mengelola data perawat lengkap sesuai hukum yang berlaku. (explicit)

• Aktor: Admin. Trigger: membuka Data perawat. Hasil: data perawat tersimpan lengkap. Akses: area kerja terlindungi. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: perawat dapat ditetapkan ke ruangan.

FR-08 — Data farmasi lengkap sesuai hukum. Sebagai Admin, saya harus mengelola data farmasi lengkap sesuai hukum yang berlaku. (explicit)

• Aktor: Admin. Trigger: membuka Data farmasi. Hasil: data farmasi tersimpan lengkap. Akses: area kerja terlindungi. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: data tersedia untuk rujukan surat cetak obat.

FR-09 — Data ahli gizi lengkap sesuai hukum. Sebagai Admin, saya harus mengelola data ahli gizi lengkap sesuai hukum yang berlaku. (explicit)

• Aktor: Admin. Trigger: membuka Data ahli gizi. Hasil: data ahli gizi tersimpan lengkap. Akses: area kerja terlindungi. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: data tersedia untuk administrasi.

FR-10 — Data pasien per ruangan. Sebagai Perawat Ruangan, saya harus mencatat data pasien masing-masing ruangan dengan kriteria diagnosa lengkap, agar kondisi pasien terdokumentasi. (explicit)

• Aktor: Perawat Ruangan. Trigger: membuka Data pasien untuk ruangannya. Hasil: data pasien tercatat per ruangan. Akses: hanya akun perawat yang bertugas di ruangan tersebut. Kegagalan: simpan gagal menampilkan pesan dengan data form tetap utuh. Kelanjutan: perawat melanjutkan pencatatan pelaksanaan dan obat.

FR-11 — Keterangan pelaksanaan. Sebagai Perawat Ruangan, saya harus mencatat keterangan pelaksanaan pada data pasien. (explicit)

• Aktor: Perawat Ruangan. Trigger: memperbarui data pasien. Hasil: keterangan pelaksanaan tersimpan. Akses: ruangan tugas. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: pelaksanaan tercatat dalam riwayat pasien.

FR-12 — Pemberian obat dengan jam dan tanggal. Sebagai Perawat Ruangan, saya harus mencatat pemberian obat lengkap dengan jam dan tanggal. (explicit)

• Aktor: Perawat Ruangan. Trigger: mencatat dosis. Hasil: jadwal obat dengan cap waktu tabular tersimpan. Akses: ruangan tugas. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: dosis berikutnya dapat dicatat.

FR-13 — Hasil lab. Sebagai Perawat Ruangan, saya harus mencatat hasil lab pada data pasien. (explicit)

• Aktor: Perawat Ruangan. Trigger: memasukkan hasil lab. Hasil: hasil lab tersimpan. Akses: ruangan tugas. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: hasil lab tampil pada panel pasien.

FR-14 — Metode pelaporan S.B.A.R. Sebagai Perawat Ruangan, saya harus mencatat metode pelaporan S.B.A.R pada data pasien. (explicit)

• Aktor: Perawat Ruangan. Trigger: menulis laporan S.B.A.R. Hasil: laporan S.B.A.R tersimpan dengan cap waktu. Akses: ruangan tugas. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: laporan tersedia untuk serah terima.

FR-15 — Kelompok penyakit sesuai diagnosa. Sebagai Perawat Ruangan, saya harus mencatat kelompok penyakit sesuai diagnosa. (explicit)

• Aktor: Perawat Ruangan. Trigger: memilih/mengisi diagnosa. Hasil: kelompok penyakit tersimpan dan dapat disaring. Akses: ruangan tugas. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: pasien dapat ditemukan berdasarkan kelompok penyakit.

FR-16 — Unggah file foto thorak dan ronsen. Sebagai Perawat Ruangan, saya harus dapat mengunggah file seperti foto thorak dan ronsen pada data pasien. (explicit)

• Aktor: Perawat Ruangan. Trigger: memilih file dan mengunggah. Hasil: lampiran tersimpan dan dapat dilihat. Akses: ruangan tugas. Kegagalan: unggah gagal menampilkan pesan dan file dapat diunggah ulang. Kelanjutan: lampiran tampil pada tile unggahan pasien.

FR-17 — Jam masuk dan jam pulang. Sebagai Perawat Ruangan, saya harus mencatat keterangan jam masuk dan jam pulang pasien. (explicit)

• Aktor: Perawat Ruangan. Trigger: mencatat waktu. Hasil: jam masuk dan jam pulang tersimpan. Akses: ruangan tugas. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: waktu tampil pada panel identitas pasien.

FR-18 — Keterangan rujuk atau meninggal dunia. Sebagai Perawat Ruangan, saya harus mencatat keterangan rujuk atau meninggal dunia pada data pasien. (explicit)

• Aktor: Perawat Ruangan. Trigger: menandai status. Hasil: status rujuk atau meninggal dunia tersimpan. Akses: ruangan tugas. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: status tampil pada panel pasien.

FR-19 — Data ruangan lengkap. Sebagai Admin, saya harus mengelola data ruangan lengkap: rawat inap, medikal bedah, IGD dan UGD, ICU, NICU, anak, farmasi, keamanan, dan poli lengkap. (explicit)

• Aktor: Admin. Trigger: membuka Data ruangan. Hasil: daftar ruangan tersimpan lengkap. Akses: area kerja terlindungi. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: setiap ruangan dapat dibuka dasbornya.

FR-20 — Dasbor masing-masing ruangan. Sebagai Admin, saya harus memastikan setiap ruangan memiliki dasbor masing-masing. (explicit)

• Aktor: Admin. Trigger: membuka dasbor ruangan. Hasil: dasbor ruangan tampil dengan gauge hunian, daftar pasien, kolom S.B.A.R, dan kolom dokumen/unggahan. Akses: area kerja terlindungi. Kegagalan: panel gagal dimuat menampilkan pesan. Kelanjutan: pengguna berpindah antar ruangan.

FR-21 — Data karyawan non medis. Sebagai Admin, saya harus mengelola data karyawan non medis meliputi petugas kebersihan, satpam, sarana dan prasarana, serta supir ambulan. (explicit)

• Aktor: Admin. Trigger: membuka Data karyawan non medis. Hasil: data karyawan non medis tersimpan per kategori. Akses: area kerja terlindungi. Kegagalan: simpan gagal menampilkan pesan. Kelanjutan: data tersedia untuk administrasi.

FR-22 — Akses pasien per akun perawat per ruangan. Sebagai Perawat Ruangan, saya harus dapat mengakses data pasien melalui akun saya yang bertugas di ruangan saya, agar akses pasien terbatas pada ruangan tempat saya bertugas. (explicit)

• Aktor: Perawat Ruangan. Trigger: masuk dan membuka Data pasien. Hasil: hanya data pasien ruangan tugas yang tampil. Akses: akun perawat dengan ruangan tugas. Kegagalan: akses ke ruangan lain ditolak dengan pesan. Kelanjutan: perawat bekerja pada ruangannya.

FR-23 — Surat keterangan sakit dari poli. Sebagai Petugas Poli, saya harus dapat mengeluarkan surat keterangan sakit dari poli. (explicit)

• Aktor: Petugas Poli. Trigger: membuat surat untuk pasien poli. Hasil: surat keterangan sakit terbit. Akses: area kerja terlindungi. Kegagalan: surat tidak dapat terbit bila data tidak lengkap, dengan pesan. Kelanjutan: surat dapat dicetak/disimpan.

FR-24 — Surat cetak obat untuk farmasi. Sebagai Petugas Poli, saya harus dapat mengeluarkan surat cetak obat untuk farmasi. (explicit)

• Aktor: Petugas Poli. Trigger: membuat surat cetak obat. Hasil: surat cetak obat terbit untuk farmasi. Akses: area kerja terlindungi. Kegagalan: surat tidak dapat terbit bila rincian obat kosong, dengan pesan. Kelanjutan: surat diteruskan ke farmasi.

FR-25 — Kelengkapan surat: kop, keterangan obat, tanda tangan dokter. Sebagai Petugas Poli, saya harus memastikan surat lengkap seperti kop surat dan keterangan obat beserta tanda tangan dokter yang bertugas di poli tersebut. (explicit)

• Aktor: Petugas Poli; Dokter (penandatangan). Trigger: menerbitkan surat. Hasil: surat tampil sebagai lembar A4 dengan kop surat, tabel obat bergaris, dan blok tanda tangan dokter bertugas. Akses: area kerja terlindungi. Kegagalan: bila dokter bertugas belum ditetapkan, penerbitan gagal dengan pesan. Kelanjutan: surat siap dicetak.

FR-26 — Pendaftaran kunjungan poli dan pengambilan obat farmasi. Sebagai Pendaftar Online (Masyarakat Umum), saya harus dapat mendaftar untuk kunjungan poli dan pengambilan obat farmasi. (explicit)

• Aktor: Pendaftar Online. Trigger: memilih jenis layanan pada Pendaftaran online. Hasil: pendaftaran tercatat sesuai jenis layanan. Akses: publik. Kegagalan: kirim gagal menampilkan pesan. Kelanjutan: pendaftar menerima nomor antrean.

FR-27 — Akses publik melalui barcode atau link. Sebagai Pendaftar Online (Masyarakat Umum), saya harus dapat mengakses pendaftaran online dalam bentuk barcode atau link, agar semua orang dapat mendaftar. (explicit)

• Aktor: Pendaftar Online. Trigger: memindai barcode atau membuka tautan. Hasil: halaman Pendaftaran online terbuka tanpa identitas. Akses: publik. Kegagalan: tautan tidak valid menampilkan pesan. Kelanjutan: pendaftar mengisi formulir.

FR-28 — Nomor antrean otomatis sesuai nomor urut. Sebagai Pendaftar Online (Masyarakat Umum), saya harus menerima nomor antrean yang keluar otomatis sesuai nomor urut setelah mendaftar. (explicit)

• Aktor: Pendaftar Online. Trigger: menyelesaikan pendaftaran. Hasil: nomor antrean terbit otomatis sesuai urutan pendaftaran. Akses: publik. Kegagalan: bila penerbitan gagal, pendaftar mendapat pesan dan dapat mengirim ulang. Kelanjutan: pendaftar menuju poli/farmasi dengan nomor antreannya.

FR-29 — Akun aplikasi untuk peran kerja. Sebagai Admin, saya harus memastikan akun aplikasi tersedia bagi admin, perawat, petugas poli, dan dokter sebelum akses kerja terlindungi. (required_inference)

• Aktor: Admin. Trigger: menyiapkan akun. Hasil: akun tersedia dan dapat digunakan untuk masuk. Akses: area kerja terlindungi. Kegagalan: kredensial tidak valid ditolak. Kelanjutan: pengguna masuk sesuai perannya.

FR-30 — Penetapan perawat pada ruangan tugas. Sebagai Admin, saya harus menetapkan perawat pada ruangan tugasnya, agar akses pasien dibatasi sesuai ruangan. (required_inference)

• Aktor: Admin. Trigger: menetapkan ruangan pada data perawat. Hasil: perawat terikat pada ruangan tugas. Akses: area kerja terlindungi. Kegagalan: penetapan gagal menampilkan pesan. Kelanjutan: perawat hanya melihat pasien ruangannya.

FR-31 — Penetapan dokter bertugas di poli. Sebagai Admin, saya harus menetapkan dokter yang bertugas di poli sebelum tanda tangan surat poli digunakan. (required_inference)

• Aktor: Admin. Trigger: menetapkan dokter pada poli. Hasil: dokter bertugas terhubung ke poli. Akses: area kerja terlindungi. Kegagalan: penetapan gagal menampilkan pesan. Kelanjutan: surat poli dapat diterbitkan dengan tanda tangan dokter tersebut.

FR-32 — Urutan nomor antrean. Sebagai sistem, saya harus mempertahankan nomor antrean sesuai urutan pendaftaran. (required_inference)

• Aktor: Sistem (pendukung); hasil terlihat oleh Pendaftar Online. Trigger: pendaftaran diterima. Hasil: nomor antrean berurutan tanpa duplikasi. Akses: publik. Kegagalan: bila terjadi benturan urutan, sistem menerbitkan nomor berikutnya yang valid. Kelanjutan: antrean tetap berurutan.

4. User Personas

Direktur / Pemilik Rumah Sakit (Admin)

• Konteks produk: Pemilik sekaligus direktur Rumah Sakit Dhela Grup yang bertindak sebagai admin sistem administrasi. Ia adalah pengguna dengan cakupan terluas dan pemegang keputusan atas kelengkapan aplikasi.
• Tujuan utama: Mengelola dan memantau seluruh data administrasi rumah sakit — dasbor, data dokter, perawat, farmasi, ahli gizi, pasien per ruangan, ruangan, dan karyawan non medis — serta memastikan aplikasi lengkap dengan cover dan template profesional.
• Tanggung jawab yang diterima: Mengelola seluruh modul data; menetapkan perawat pada ruangan tugasnya; menetapkan dokter bertugas di poli; memastikan setiap ruangan memiliki dasbor; memastikan akun aplikasi tersedia bagi peran kerja.
• Input/keputusan: Data tenaga medis dan non medis; daftar ruangan; penetapan ruangan tugas perawat; penetapan dokter poli.
• Interaksi dengan peserta lain: Menyediakan akun dan penugasan yang menjadi prasyarat kerja Perawat Ruangan, Petugas Poli, dan Dokter.
• Keberhasilan yang terlihat: Seluruh modul administrasi tersedia dan dapat diakses serta dikelola olehnya sebagai admin.

Perawat Ruangan

• Konteks produk: Perawat yang bertugas di ruangan tertentu dan memiliki akun masing-masing. Pekerjaannya melekat pada satu ruangan, sehingga cakupan datanya berbeda dari admin.
• Tujuan utama: Mencatat dan memantau data pasien di ruangan tempat ia bertugas secara lengkap.
• Tanggung jawab yang diterima: Mencatat kriteria diagnosa lengkap, keterangan pelaksanaan, pemberian obat beserta jam dan tanggal, hasil lab, metode pelaporan S.B.A.R, kelompok penyakit sesuai diagnosa, unggah file seperti foto thorak dan ronsen, keterangan jam masuk dan jam pulang, serta keterangan rujuk atau meninggal dunia.
• Input/keputusan: Data pasien ruangannya; waktu pemberian obat; hasil lab; status akhir pasien (rujuk atau meninggal dunia).
• Interaksi dengan peserta lain: Bergantung pada penetapan ruangan oleh Admin; datanya menjadi sumber bagi Dokter dan Petugas Poli dalam pelayanan.
• Keberhasilan yang terlihat: Data pasien ruangannya tercatat lengkap dan dapat diakses sesuai akun ruangannya.

Petugas Poli

• Konteks produk: Petugas yang melayani kunjungan di poli dan menerbitkan dokumen resmi poli. Pekerjaannya berpusat pada penerbitan surat, bukan pada pencatatan pasien per ruangan.
• Tujuan utama: Menerbitkan surat keterangan sakit dan surat cetak obat untuk farmasi secara lengkap dan sah.
• Tanggung jawab yang diterima: Membuat surat lengkap dengan kop surat, keterangan obat, dan tanda tangan dokter yang bertugas di poli tersebut.
• Input/keputusan: Data pasien/kunjungan poli; rincian obat; pemilihan dokter bertugas.
• Interaksi dengan peserta lain: Bergantung pada penetapan dokter bertugas oleh Admin; surat cetak obat ditujukan ke farmasi; tanda tangan berasal dari Dokter.
• Keberhasilan yang terlihat: Surat keterangan sakit dan surat cetak obat dapat dikeluarkan lengkap dan sah dari poli.

Dokter

• Konteks produk: Dokter yang bertugas di poli dan datanya tercatat lengkap sesuai hukum yang berlaku. Perannya terikat pada keabsahan dokumen poli.
• Tujuan utama: Memastikan surat-surat poli terbit dengan tanda tangannya sebagai dokter yang bertugas di poli tersebut.
• Tanggung jawab yang diterima: Menandatangani surat keterangan sakit dan surat cetak obat yang dikeluarkan poli; datanya tercatat lengkap sesuai hukum.
• Input/keputusan: Identitas dan data legalnya; penugasan poli; persetujuan penandatanganan surat.
• Interaksi dengan peserta lain: Ditunjuk oleh Admin pada poli; bekerja bersama Petugas Poli yang menyiapkan surat.
• Keberhasilan yang terlihat: Surat-surat poli terbit dengan tanda tangan dokter yang bertugas di poli tersebut.

Pendaftar Online (Masyarakat Umum)

• Konteks produk: Masyarakat umum yang mengakses pendaftaran online melalui barcode atau tautan, tanpa identitas aplikasi. Pekerjaannya adalah pendaftaran mandiri, bukan pengelolaan data rumah sakit.
• Tujuan utama: Melakukan pendaftaran secara mandiri dan menerima nomor antrean otomatis sesuai nomor urut.
• Tanggung jawab yang diterima: Mengisi pendaftaran untuk kunjungan poli atau pengambilan obat farmasi; menyimpan nomor antreannya.
• Input/keputusan: Jenis layanan; identitas pendaftar; poli tujuan.
• Interaksi dengan peserta lain: Hasil pendaftarannya menjadi antrean yang dilayani Petugas Poli dan farmasi.
• Keberhasilan yang terlihat: Pendaftaran berhasil dan nomor antrean keluar otomatis.

5. Core User Flows

Alur 1 — Admin masuk dan memantau administrasi (Direktur / Pemilik Rumah Sakit)

1. Admin membuka Landing dan membaca identitas Rumah Sakit Dhela Grup beserta penjelasan fungsi aplikasi.
2. Admin menekan MASUK SEBAGAI ADMIN dan diarahkan ke Login.
3. Admin memasukkan kredensialnya. Bila kredensial tidak valid, ia mendapat pesan kesalahan dan mencoba lagi.
4. Setelah berhasil, Admin masuk ke Dasbor dan melihat gauge instrumen dengan arc amber, tick teal live, dan angka tabular jumlah pasien hari ini, serta baris readout status ruangan.
5. Admin membuka modul dari rail instrumen sesuai kebutuhan (Data dokter, Data perawat, Data farmasi, Data ahli gizi, Data pasien, Data ruangan, Data karyawan non medis, Surat Poli).
6. Bila satu panel gagal dimuat, Admin mendapat pesan dan tombol coba lagi; modul lain tetap dapat dibuka.
7. Admin melanjutkan pemantauan atau berpindah modul.

Alur 2 — Admin mengelola data tenaga medis dan non medis

1. Admin membuka Data dokter dan menambah/mengubah data dokter lengkap sesuai hukum yang berlaku.
2. Admin menetapkan dokter penanggung jawab pada poli yang sesuai.
3. Admin membuka Data perawat, menambah/mengubah data perawat lengkap sesuai hukum yang berlaku, dan menetapkan ruangan tugas setiap perawat.
4. Admin membuka Data farmasi dan Data ahli gizi, menambah/mengubah data masing-masing lengkap sesuai hukum yang berlaku.
5. Admin membuka Data karyawan non medis dan mencatat petugas kebersihan, satpam, sarana dan prasarana, serta supir ambulan.
6. Bila penyimpanan gagal, Admin mendapat pesan dan data form tetap utuh sehingga dapat memperbaiki dan menyimpan ulang.
7. Admin melanjutkan ke modul berikutnya.

Alur 3 — Admin mengelola ruangan dan dasbor masing-masing

1. Admin membuka Data ruangan dan menambah/mengubah ruangan: rawat inap, medikal bedah, IGD dan UGD, ICU, NICU, anak, farmasi, keamanan, dan poli lengkap.
2. Admin membuka dasbor salah satu ruangan dan melihat ring gauge hunian dengan arc amber dan tick teal live, daftar pasien, kolom S.B.A.R, serta kolom dokumen/unggahan.
3. Admin berpindah ke dasbor ruangan lain untuk membandingkan status.
4. Bila panel gagal dimuat, Admin mendapat pesan dan dapat memuat ulang.
5. Admin melanjutkan pemantauan ruangan.

Alur 4 — Perawat mencatat data pasien ruangannya

1. Perawat Ruangan membuka Login dan masuk dengan akunnya yang telah ditetapkan pada ruangan tugasnya.
2. Perawat membuka Data pasien dan hanya melihat pasien pada ruangan tempat ia bertugas. Bila ia mencoba mengakses ruangan lain, akses ditolak dengan pesan.
3. Perawat memilih pasien dan mencatat kriteria diagnosa lengkap serta kelompok penyakit sesuai diagnosa.
4. Perawat mencatat keterangan pelaksanaan.
5. Perawat mencatat pemberian obat lengkap dengan jam dan tanggal pada kolom jadwal bertimestamp tabular, dengan tick teal per dosis yang telah diberikan.
6. Perawat mencatat hasil lab.
7. Perawat menulis laporan S.B.A.R dengan cap waktu.
8. Perawat mengunggah file seperti foto thorak dan ronsen pada tile unggahan. Bila unggahan gagal, ia mendapat pesan dan dapat mengunggah ulang.
9. Perawat mencatat keterangan jam masuk dan jam pulang pasien.
10. Perawat mencatat keterangan rujuk atau meninggal dunia bila berlaku.
11. Bila penyimpanan gagal pada salah satu langkah, Perawat mendapat pesan dan data form tetap utuh sehingga dapat menyimpan ulang tanpa kehilangan entri lain.
12. Perawat melanjutkan pemantauan pasien pada ruangannya.

Alur 5 — Petugas Poli menerbitkan surat keterangan sakit

1. Petugas Poli masuk melalui Login dan membuka Surat Poli.
2. Petugas Poli memilih pasien/kunjungan poli.
3. Petugas Poli membuat surat keterangan sakit dan memilih dokter yang bertugas di poli tersebut.
4. Sistem menampilkan pratinjau sebagai lembar A4 berbingkai dengan kop surat lengkap dan blok tanda tangan dokter.
5. Bila dokter bertugas belum ditetapkan atau data tidak lengkap, penerbitan gagal dengan pesan; Petugas Poli melengkapi data dan menerbitkan ulang.
6. Surat terbit lengkap dengan kop surat dan tanda tangan dokter yang bertugas di poli tersebut.
7. Petugas Poli mencetak atau menyimpan surat dan melanjutkan ke pelayanan berikutnya.

Alur 6 — Petugas Poli menerbitkan surat cetak obat untuk farmasi

1. Petugas Poli membuka Surat Poli dan memilih pasien/kunjungan poli.
2. Petugas Poli membuat surat cetak obat dan mengisi rincian obat pada tabel obat bergaris.
3. Petugas Poli memilih dokter yang bertugas di poli tersebut sebagai penandatangan.
4. Bila rincian obat kosong atau dokter belum ditetapkan, penerbitan gagal dengan pesan; Petugas Poli melengkapi dan menerbitkan ulang.
5. Surat cetak obat terbit lengkap dengan kop surat, keterangan obat, dan tanda tangan dokter.
6. Surat diteruskan ke farmasi untuk pengambilan obat.
7. Petugas Poli melanjutkan ke pasien berikutnya.

Alur 7 — Dokter menandatangani surat poli

1. Dokter masuk melalui Login dan membuka Surat Poli.
2. Dokter melihat surat yang disiapkan Petugas Poli untuk poli tempat ia bertugas.
3. Dokter memeriksa kelengkapan kop surat dan keterangan obat.
4. Dokter memberikan tanda tangannya pada blok tanda tangan surat.
5. Surat terbit dengan tanda tangan dokter yang bertugas di poli tersebut dan siap dicetak.
6. Bila data belum lengkap, Dokter menolak/menunda dan memberi tahu Petugas Poli untuk melengkapi.
7. Dokter melanjutkan ke pasien berikutnya.

Alur 8 — Masyarakat umum mendaftar online dan menerima nomor antrean

1. Pendaftar Online (Masyarakat Umum) memindai barcode atau membuka tautan pendaftaran, lalu masuk ke halaman Pendaftaran online tanpa identitas aplikasi.
2. Pendaftar memilih jenis layanan: kunjungan poli atau pengambilan obat farmasi.
3. Pendaftar mengisi data identitas dan memilih poli tujuan bila berlaku.
4. Pendaftar memeriksa ringkasan dan mengirim pendaftaran.
5. Bila pengiriman gagal, pendaftar mendapat pesan dan dapat mengirim ulang tanpa kehilangan data yang telah diisi.
6. Sistem menerbitkan nomor antrean otomatis sesuai nomor urut dan menampilkannya besar dalam warna amber, dengan nama ruangan/poli dan estimasi waktu di bawahnya.
7. Pendaftar menyimpan nomor antrean dan menuju poli atau farmasi sesuai jenis layanannya.
8. Nomor antrean tersebut menjadi urutan pelayanan yang dilanjutkan oleh Petugas Poli atau farmasi.

6. Visuals Colors and Theme

Muse dan headline: MARQ by Garmin — presisi instrumen administrasi: dark titanium, amber signal, condensed clinical data. Headline arah: "RUMAH SAKIT DHELA GRUP — Sistem Administrasi Rumah Sakit", dibaca sebagai perangkat klinis yang tenang, otoritatif, dan terukur.

Mode: Dark mode menyeluruh. Tidak ada ground putih atau near-white.

Token warna (peran):

• Background (ground): #0E1114 — dark titanium, membawa seluruh aplikasi.
• Surface (panel): #171C21 — panel dengan hairline rgba(237,233,225,0.10) dan gradien brushed-metal tipis.
• Surface alternatif (band tabel): #12161A — band bergantian pada baris data ruled.
• Text utama: #EDE9E1 — warm bone, kontras ±13:1 pada ground.
• Primary (instrument amber): #C9A45C — navigasi aktif, arc dial, nomor antrean, section rule, aksi utama. Tidak pernah sebagai large fill.
• Accent (clinical teal): #3FBFA8 — khusus state live/terukur: status online, vital in range, "sedang ditangani", timestamp S.B.A.R, tick dosis diberikan, keberhasilan penerbitan antrean.
• Muted: #8A9099 — label, metadata sekunder, disabled. Tidak untuk body copy.
• Status indikator: hijau aktif/aman #16A34A, kuning peringatan #FACC15, merah kritis #EF4444.
• Focus ring: amber 2px dengan garis dalam teal 1px.
• Tidak ada biru, indigo, atau violet dalam peran apa pun — termasuk link, chart, focus ring, dan ikon.

Tipografi:

• Headings: Saira Condensed 600/700, uppercase untuk judul seksi dan nama ruangan, tracking -0.01em.
• Body: Barlow.
• Angka: Barlow Semi Condensed 600 dengan tabular figures.
• Skala 1.25 modular pada basis 4/8pt: display 40/96, h1 32/64, h2 24/40, h3 18/28, body 15/17, label 11/12 uppercase dengan letterspacing 0.14em, data 32/72 tabular.
• Display mobile tidak melebihi 40px; desktop dibatasi 96px; semua heading memakai clamp() agar membungkus di dalam 375px.
• Tidak ada bobot di bawah 400; tidak ada italic.

Shape language: Geometri instrumen — panel persegi bertepi keras dengan radius 2px (bezel, bukan kartu lembut), border hairline 1px, dan motif gauge melingkar. Dasbor ruangan memakai ring gauge dengan arc amber dan tick teal live; hunian digambar sebagai bezel tersegmentasi di sekeliling angka. Baris data ruled dengan band #171C21 dan #12161A bergantian, pasangan label/value sejajar, dan pembatas seksi berupa rule amber 3px. Tombol persegi radius 2px dengan inset highlight 1px seperti key yang dimachining; tanpa pill, tanpa blob.

Layout: Rail instrumen kiri tetap (72px collapsed, 240px expanded) dengan wordmark RS Dhela Grup di atas dan modul sebagai label terukir; modul aktif mendapat bar amber 3px di kiri dan key amber terisi. Konten memakai grid 12 kolom ketat dengan top status strip persisten berisi tanggal, shift, jumlah antrean live, dan peran yang masuk (admin / perawat / poli / dokter). Setiap ruangan memiliki dasbor sendiri: baris gauge di atas, lalu daftar pasien, lalu kolom serah terima S.B.A.R, lalu kolom dokumen/unggahan. Detail pasien adalah panel instrumen dua-pane. Surat poli dirender sebagai lembar A4 berbingkai dengan letterhead penuh, tabel obat bergaris, dan blok tanda tangan dokter. Pendaftaran publik adalah halaman dark sederhana yang berakhir pada nomor antrean amber besar.

Imagery: Fotografi material makro dan instrumen — permukaan titanium brushed dan kaca sapphire, tepi dial, bell stetoskop, blister pack obat, koridor rumah sakit dalam cahaya hangat rendah, tekstur garis topografis sebagai pola latar tipis pada 6% opacity. Tanpa stok medis bernuansa biru, tanpa clip art, tanpa stok orang tersenyum. Ikon adalah piktogram garis tipis 1.5px bergaya marking instrumen pada grid 24px, dengan amber atau teal sebagai satu-satunya warna.

7. Signature Design Concept

"Dial Rumah Sakit" — cover sebagai instrumen, bukan hero SaaS.

Landing dirender sebagai scene dark titanium full-bleed. Tujuh kolom kiri memuat headline uppercase Saira Condensed "RUMAH SAKIT DHELA GRUP" bertumpuk tiga baris, dari 40px di mobile hingga 96px di desktop, dengan subjudul "Sistem Administrasi Rumah Sakit" dalam Barlow 11px uppercase bertracking 0.14em di atasnya, dan rule amber 3px di bawahnya. Di bawah headline, satu baris empat readout status ruled — IGD, ICU, NICU, Poli — dengan label uppercase kecil dan angka tabular besar. CTA utama MASUK SEBAGAI ADMIN adalah key persegi berbingkai amber yang dipasang di bawah headline, dan tautan sekunder PENDAFTARAN ONLINE dengan glyph QR berada di sebelahnya.

Lima kolom kanan memuat gauge instrumen melingkar besar — 420px di desktop, 220px di mobile — dengan arc hunian amber, tick teal live, dan angka tabular yang menghitung naik ke total pasien hari ini di dalam dial. Gauge dan headline tidak pernah tumpang tindih; pada 375px gauge turun ke bawah headline dan menyusut ke 220px, sementara readout status membungkus menjadi dua baris.

Konsep ini hanya menyusun ulang konten, state, dan kontrol yang telah diterima: identitas rumah sakit, dua jalur masuk (area kerja terlindungi dan pendaftaran publik), serta indikator ruangan. Tidak ada perilaku, halaman, atau tujuan baru yang diperkenalkan.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: dimensional_css

Landing Hero Motion Brief

• Focal subject: Gauge instrumen melingkar dengan arc hunian amber dan tick teal live, ditemani headline wordmark rumah sakit.
• Input → transformation → outcome: Saat Landing dimuat, arc gauge menyapu perlahan dari nol ke nilai hunian saat ini dan angka tabular di dalam dial menghitung naik ke total pasien hari ini selama 900ms dengan cubic-bezier(0.2, 0.8, 0.2, 1); hasil akhirnya adalah dial yang terbaca sebagai denyut rumah sakit, bukan kartu KPI.
• Motion vocabulary: Sapuan jarum yang lambat dan mekanis; angka tabular yang menghitung naik; nomor antrean yang masuk dengan satu slide vertikal 180ms; tick teal yang berdenyut 1s hanya pada titiknya, tidak pernah pada teks; transisi halaman berupa fade 160ms tanpa bounce.
• Composed first frame: Ground dark titanium #0E1114; headline uppercase besar di kiri dengan rule amber 3px; gauge di kanan dengan arc amber pada posisi awal nol dan tick teal statis; baris readout status ruled di bawah headline; key amber MASUK SEBAGAI ADMIN dan tautan PENDAFTARAN ONLINE dengan glyph QR.
• Reduced-motion state: Sapuan dan hitungan naik langsung dirender pada nilai akhir, denyut teal menjadi titik teal statis, dan seluruh daftar tetap terbaca secara statis.

9. Non-Functional Requirements

• NFR-01 — Kelengkapan data sesuai hukum. Data dokter, perawat, farmasi, dan ahli gizi harus lengkap sesuai hukum yang berlaku. (explicit) Rasional: kepatuhan legal institusi kesehatan.
• NFR-02 — Pembatasan akses pasien per ruangan. Data pasien hanya dapat diakses oleh akun perawat yang bertugas di ruangan masing-masing. (explicit) Rasional: kerahasiaan rekam pasien dan pembatasan lingkup kerja per ruangan.
• NFR-03 — Aksesibilitas publik pendaftaran. Pendaftaran online harus dapat diakses oleh semua orang dalam bentuk barcode atau link, tanpa identitas aplikasi. (explicit) Rasional: menjangkau masyarakat umum tanpa hambatan masuk.
• NFR-04 — Kelengkapan dokumen resmi. Surat keterangan sakit dan surat cetak obat harus lengkap dengan kop surat, keterangan obat, dan tanda tangan dokter yang bertugas di poli tersebut. (explicit) Rasional: keabsahan dokumen resmi rumah sakit.
• NFR-05 — Dasbor per ruangan. Setiap ruangan harus memiliki dasbor masing-masing. (explicit) Rasional: pemantauan operasional per unit.
• NFR-06 — Ketertelusuran waktu. Pemberian obat, laporan S.B.A.R, jam masuk, dan jam pulang harus tercatat dengan cap waktu yang tepat. (explicit) Rasional: rekam klinis dan serah terima yang dapat diaudit.
• NFR-07 — Ketahanan unggahan berkas. Unggahan file seperti foto thorak dan ronsen harus dapat diulang tanpa kehilangan entri lain pada data pasien. (required_inference) Rasional: lampiran pemeriksaan adalah bagian rekam pasien yang harus utuh.
• NFR-08 — Urutan antrean yang konsisten. Nomor antrean harus terbit otomatis sesuai nomor urut pendaftaran tanpa duplikasi. (required_inference) Rasional: keadilan urutan pelayanan.

• NFR-09 — Keterbacaan dan kontras. Body text harus memenuhi kontras minimal 4.5:1 pada ground gelap; muted #8A9099 hanya untuk label, bukan body copy. (explicit — creative direction) Rasional: keterbacaan pada lingkungan kerja klinis.
• NFR-10 — Ketahanan tata letak. Headline, wordmark, label, angka, teks kartu, dan kontrol harus tetap utuh di dalam viewport dan kontainernya pada 375px, 768px, dan 1280px, membungkus atau menskalakan dengan clamp(). (explicit — creative direction) Rasional: akses lintas perangkat termasuk ponsel.

10. Tech Stack

• Frontend: React (aplikasi web) — antarmuka dark titanium dengan rail instrumen, gauge, tabel ruled, dan pratinjau surat A4. (basic_default — tidak ditentukan pengguna)
• Backend: Python / FastAPI — satu backend bersama yang melayani API administrasi, pendaftaran publik, penerbitan nomor antrean, dan penerbitan surat. (basic_default — tidak ditentukan pengguna)
• Penyimpanan: Basis data relasional untuk data tenaga medis, pasien per ruangan, ruangan, karyawan non medis, pendaftaran, antrean, dan surat; penyimpanan objek untuk lampiran foto thorak dan ronsen. (basic_default — tidak ditentukan pengguna)
• Kontainerisasi: Docker dan docker-compose untuk menjalankan frontend dan backend. (basic_default — tidak ditentukan pengguna)
• Kubernetes: Tidak disertakan; kebutuhan deployment saat ini tidak menuntut orkestrasi tersebut. (basic_default — tidak ditentukan pengguna)

Tidak ada pilihan teknologi yang dinyatakan secara eksplisit oleh pengguna; seluruh entri di atas adalah default yang wajar dan tidak menciptakan perilaku produk.

11. Assumptions and Constraints

Asumsi:

• A-01 — Aplikasi berbentuk aplikasi web yang dapat diakses melalui peramban, sesuai permintaan "dalam bentuk apk" yang dipahami sebagai aplikasi perangkat lunak. (asumsi, label sempit)
• A-02 — Identitas aplikasi diperlukan agar admin, perawat, petugas poli, dan dokter dapat mengakses area kerja terlindungi dan agar data pasien terikat pada ruangan tugas perawat. (required_inference)
• A-03 — Penetapan perawat pada ruangan tugas dan penetapan dokter bertugas di poli adalah mekanisme wajib yang membuat pembatasan akses pasien dan penandatanganan surat poli dapat berjalan. (required_inference)
• A-04 — Nomor antrean diterbitkan berurutan berdasarkan urutan pendaftaran yang diterima. (required_inference)
• A-05 — Data "lengkap sesuai hukum yang berlaku" diisi sesuai ketentuan legal yang berlaku di Indonesia untuk tenaga kesehatan. (asumsi, label sempit)

Batasan:

• C-01 — Data dokter, perawat, farmasi, dan ahli gizi harus lengkap sesuai hukum yang berlaku. (explicit)
• C-02 — Data pasien hanya dapat diakses oleh akun perawat yang bertugas di ruangan masing-masing. (explicit)
• C-03 — Pendaftaran online harus dapat diakses oleh semua orang dalam bentuk barcode atau link. (explicit)
• C-04 — Surat keterangan sakit dan surat cetak obat harus lengkap dengan kop surat, keterangan obat, dan tanda tangan dokter yang bertugas di poli tersebut. (explicit)
• C-05 — Setiap ruangan harus memiliki dasbor masing-masing. (explicit)
• C-06 — Tidak ada biru, indigo, atau violet dalam peran apa pun, termasuk link, chart, focus ring, dan ikon. (explicit — creative direction)
• C-07 — Tidak ada ground putih atau near-white; sistem tetap dark titanium. (explicit — creative direction)
• C-08 — Amber hanya untuk struktur dan aksi; teal hanya untuk pengukuran live. (explicit — creative direction)
• C-09 — Template SaaS indigo/biru-di-atas-putih dilarang untuk proyek ini. (explicit — creative direction)
• C-10 — Tidak ada modul di luar daftar yang diminta (misalnya billing, klaim asuransi, atau rekam medis lintas fasilitas) karena tidak diminta. (batasan lingkup)

12. Glossary

• S.B.A.R — Metode pelaporan terstruktur (Situation, Background, Assessment, Recommendation) yang dicatat pada data pasien.
• Dasbor ruangan — Dasbor khusus untuk setiap ruangan (rawat inap, medikal bedah, IGD dan UGD, ICU, NICU, anak, farmasi, keamanan, poli) yang menampilkan gauge hunian, daftar pasien, kolom S.B.A.R, dan kolom dokumen/unggahan.
• Kop surat — Kepala surat resmi rumah sakit yang tercetak pada surat keterangan sakit dan surat cetak obat.
• Nomor antrean — Nomor urut otomatis yang diterbitkan setelah pendaftaran online berhasil.
• Poli — Unit layanan rawat jalan tempat kunjungan pasien dan penerbitan surat keterangan sakit serta surat cetak obat.
• Surat cetak obat — Surat resmi dari poli yang memuat keterangan obat untuk diteruskan ke farmasi.
• Surat keterangan sakit — Surat resmi dari poli yang menyatakan pasien sakit, lengkap dengan kop surat dan tanda tangan dokter bertugas.
• Ruangan tugas — Ruangan tempat seorang perawat ditetapkan bertugas, yang menentukan cakupan akses data pasiennya.
• Dokter bertugas — Dokter yang ditetapkan pada suatu poli dan berwenang menandatangani surat-surat poli tersebut.
• Foto thorak dan ronsen — Berkas pemeriksaan radiologi yang diunggah pada data pasien.