UDENTIVA menanamkan kematangan proses yang dicari untuk perangkat lunak kesehatan ke dalam arsitektur itu sendiri. Halaman ini memaparkan dengan bukti: siklus hidup pengembangan kami, level kapabilitas SPICE / ISO-IEC 15504, mekanisme pencatatan dan kontrol kesalahan berkelanjutan, kriteria versi dan keamanan, serta riwayat pengembangan kami.
Dasar hukum: Peraturan tentang Sistem Manajemen Informasi Kesehatan (No. Perundangan 39682) Pasal 6 dan Pasal 20 — persyaratan sertifikasi kualitas perangkat lunak (CMMI/SPICE).
Definisi proses, penerapan, dan produk kerja yang dapat dilacak telah terstruktur; mekanisme pengukuran kuantitatif, pencegahan cacat, dan perbaikan berkelanjutan dijalankan di produksi. Pernyataan tingkat kapabilitas resmi tunduk pada lingkup penilaian independen (appraisal).
SPICE mengevaluasi proses dengan tingkat kapabilitas dari 0 hingga 5. UDENTIVA distrukturkan untuk memenuhi ekspektasi Tingkat 1-3 pada level definisi proses/implementasi/produk kerja yang dapat dilacak; untuk Tingkat 4-5, mekanisme pengukuran kuantitatif dan perbaikan berkelanjutan telah dijalankan. Deklarasi tingkat resmi tunduk pada penilaian independen.
Mekanisme kontrol kuantitatif dan perbaikan berkelanjutan pada Tingkat 4-5 dijalankan di bawah beserta buktinya (pengukuran langsung, registri kesalahan/CAPA, catatan deployment).
Setiap area proses berkorespondensi dengan implementasi konkret dan bukti yang dapat diaudit di UDENTIVA. Proses bukanlah dokumen, melainkan kode yang berjalan.
| Area Proses | Aplikasi UDENTIVA | Bukti |
|---|---|---|
| ENG.1 Elisitasi Kebutuhan | Definisi kebutuhan peta fase + vertical slice; kontrak proyek UDENTIVA.md mengunci kebutuhan. | UDENTIVA.md (ATURAN EMAS), spesifikasi teknis 02_tech_spec/, peta fase/modul |
| ENG.4 Desain Perangkat Lunak | Monolit modular; paket konteks (context) tidak berbagi tabel satu sama lain; komunikasi melalui interface; layanan eksternal = adapter. | Aturan batas internal/{identity,patient,billing,export,...}; ADR-001..008 |
| ENG.5 Konstruksi Perangkat Lunak | SQL eksplisit (sqlc, tanpa ORM); context sebagai parameter pertama di setiap fungsi; pembungkusan kesalahan %w; uang = numeric. | Override tipe sqlc.yaml (numeric→string), db/queries/*.sql, gofmt/golangci-lint |
| ENG.6 Integrasi Perangkat Lunak | Rantai loopback PHP(BFF) ↔ Go ↔ PostgreSQL ↔ Redis; satu permukaan publik. | web/core/ApiClient, kesehatan komponen /healthz (db+redis) |
| ENG.7 Pengujian Perangkat Lunak | Uji isolasi cross-tenant (paling kritis), idempotency, konflik jadwal janji temu, presisi uang, 2FA/OTP, vektor TOTP RFC6238, QR (verifikasi OpenCV+ISO). | internal/integration/*_test.go, platform/totp/totp_test.go, go test ./... |
| SUP.1 Penjaminan Kualitas | Setiap PR wajib mematuhi ATURAN EMAS; lint bersih; jika uji isolasi merah di CI maka tidak ada merge. | golangci-lint, Definition of Done kontrol listesi |
| SUP.8 Manajemen Konfigurasi | Kontrol versi Git (branch core); pemversian skema berurutan goose; artefak build dicadangkan. | git, goose_db_version tablosu, .tools/deploy yedekleri |
| SUP.9 Penyelesaian Masalah | Catatan audit append-only + outbox email/SMS (setiap catatan pengiriman) + disiplin cadangan/rollback deploy. | audit_log, email_outbox/sms_outbox, bin/server.exe.bak-* rollback |
| SUP.10 Manajemen Permintaan Perubahan | Setiap perubahan skema adalah migration bernomor baru; dapat dibatalkan (goose Down); persetujuan classifier deploy. | db/migrations/0001..0027, +goose Up/Down |
| MAN.3 Manajemen Proyek | Pengiriman vertical-slice (setiap slice berjalan ujung ke ujung); catatan serah terima sesi. | super-devam.md, faz tablosu (DoD per dilim) |
| MAN.6 Pengukuran | Pemeriksaan kesehatan, pengukuran kapasitas, metrik pengiriman email/SMS, volume audit, telemetri event langsung. | /healthz, panel Pemantauan Proses & Kualitas (event/kesalahan/deploy/KPI) |
Tanggung jawab dipisahkan ke dalam lapisan-lapisan; otoritas domain berada di satu titik dan diisolasi dengan loopback. Browser hanya melihat BFF tipis dan tidak pernah dapat mengakses lapisan domain serta data secara langsung.
| Lapisan | Tanggung Jawab & Keamanan | Lokasi |
|---|---|---|
| Sunum (BFF) | PHP 8.4 — BFF tipis: sesi, render, CSRF, perutean. TANPA aturan bisnis/DB. Satu-satunya permukaan publik (IIS:443). | web/ |
| Uygulama / Domain | Monolit modular Go — SATU-SATUNYA otoritas domain. RBAC, aturan bisnis, transaction. Hanya mendengarkan 127.0.0.1. | api/internal/ |
| Veri | PostgreSQL — setiap tabel tenant_id + RLS FORCE; SQL eksplisit (sqlc), berparameter. Uang numeric. | api/db/ |
| Cache / Antrean | Redis — sesi, idempotency, kunci terdistribusi, antrean asynq (SMS/e-fatura). | platform/redisx |
| Nesne Depolama | Kompatibel dengan S3 — file besar (rontgen) presigned/stream; blob tidak pernah di DB. | platform/storage |
| Layanan Eksternal (adapter) | e-Fatura, SMS(NetGSM), email(SMTP), (ke depannya e-Nabız/MEDULA/DICOM) — diabstraksikan di balik interface. | internal/notify |
Pengukuran bukanlah pernyataan, melainkan sistem yang bekerja. Semua transaksi dihitung secara langsung (berhasil/gagal), kesalahan produksi ditangkap dalam catatan permanen, dan kerangka KPI di bawah ini terhubung ke tindakan berkala. Sumber datanya adalah tabel nyata: event_counter (penghitung transaksi langsung), error_log (catatan kesalahan permanen), deploy_log (catatan deployment).
| Area Pengukuran | KPI | Sasaran | Sumber Data | Periode | Tindakan |
|---|---|---|---|---|---|
| Keamanan isolasi tenant | cross-tenant test fail | 0 | CI / izolasyon testi | her PR | Blokade merge |
| Kesalahan produksi | kesalahan terbuka (5xx/panic) | 0 | error_log (persisten) | berkelanjutan/langsung | RCA + CAPA zorunlu |
| Tingkat keberhasilan operasi | success / toplam event | ≥ %99 | event_counter (langsung) | berkelanjutan/langsung | Akar penyebab saat penurunan |
| Waktu penyelesaian | MTTR (rata-rata penyelesaian) | ↓ tren menurun | error_log (resolved) | bulanan | Trend incelemesi |
| Keandalan deployment | tingkat rollback | < %5 | deploy_log | 30 hari | Rollback review |
| Keamanan identitas | 2FA/OTP kritik olay | 0 | audit + event_counter | bulanan | Pengerasan |
| Keandalan perpesanan | SMS/e-posta failure | ↓ rendah | *_outbox | harian | Tinjauan penyedia |
| Kesiapan pemulihan | keberhasilan uji restore | %100 | DR test (hedef) | kuartalan | Perbarui runbook |
Setiap kesalahan produksi melewati siklus analisis akar penyebab (RCA) baku dan tindakan korektif/preventif (CAPA); terulangnya kesalahan yang sama dicegah dengan kontrol regresi dan pemantauan tren.
Kesalahan produksi (5xx/panic) ditangkap otomatis → error_log persisten (pada pengulangan tanda tangan yang sama count++, tren cacat).
Tingkat (error/panic), dampak, dan jumlah pengulangan ditentukan; prevalensi diukur dengan penghitung event yang gagal.
Analisis akar penyebab dilakukan dan dicatat di panel Pemantauan Proses.
Aksi korektif + aksi preventif (kode, uji, aturan migration, kontrol keamanan) didefinisikan dan dicatat.
Uji/aturan yang mencegah pengulangan kesalahan yang sama ditambahkan; dipantau dengan telemetri berkelanjutan.
Tren KPI (MTTR, tingkat kesalahan, rollback) dievaluasi secara berkala; untuk kesalahan yang berulang, aksi tingkat-proses dibuka.
Inti dari SPICE Tingkat 5: pencatatan kesalahan berkelanjutan, menjaganya tetap terkendali, pencegahan cacat, dan perbaikan berkelanjutan. UDENTIVA menjalankan mekanisme ini di produksi.
audit_log yang tidak dapat diubah (append-only) mencatat setiap operasi kritis; email_outbox/sms_outbox mencatat setiap pengiriman (status, attempts, error) secara persisten. Tidak ada peristiwa yang hilang secara diam-diam.
Amplop kesalahan yang konsisten {error:{code,message}}; kesalahan internal/stack tidak pernah dibocorkan. Cadangan binary + web sebelum setiap deploy; saat outage, rollback dalam hitungan detik dengan bin/server.exe.bak-*.
Arsitektur fail-closed: tanpa konteks RLS 0 baris; idempotency mencegah operasi ganda; uang numeric membuat kesalahan float menjadi mustahil; whitelist (dataset export) mencegah injeksi SQL. Kesalahan dicegah sejak awal melalui desain.
Komponen kritis diverifikasi dengan dua metode independen: vektor uji TOTP RFC6238, decode OpenCV cv2 + codeword referensi ISO/IEC 18004 untuk QR, uji isolasi cross-tenant.
Di setiap sesi audit keamanan → temuan → pengerasan (mis. RBAC fase2/fase3 ditambahkan, 2FA, Export API). Memori korporat dijaga dengan catatan proses (super-devam.md).
Permintaan regulasi baru (VEM Görüntüsü) diubah langsung menjadi fitur produk dan bukti; perubahan peraturan dipantau terus-menerus dan dicatat ke dalam peta kepatuhan.
Satu basis kode, penyempitan dengan flag — tanpa fork.
Versi yang dapat dilacak di lapisan skema, sumber, deployment, dan API.
Seluruh proses pengembangan dalam kontrol versi; setiap deployment dapat dikembalikan (rewind/rollback).
Keamanan bukanlah sebuah fitur, melainkan arsitektur itu sendiri. Aturan yang pelanggarannya berarti penolakan PR dan tidak dapat dinegosiasikan:
Sistem dibangun dengan irisan vertikal yang masing-masing bekerja dari ujung ke ujung. Di bawah ini tercantum fase-fase dan kronologi pekerjaan keamanan/regulasi periode terakhir.
pgx+sqlc, goose, uji RLS fail-closed, WithTenantTx, middleware sesi, login+RBAC, audit, loopback PHP↔Go, dasar asynq, health.
CRUD Pasien + uji isolasi cross-tenant → Janji Temu (exclusion constraint + Redis lock) → Odontogram/Rencana Perawatan (FDI, append-only) → Penagihan/Piutang/Kas (derive, idempotent) → adapter e-Fatura (fast-follow) → Stok → Rontgen (S3) → pengingat SMS (asynq backoff).
Tier operator-platform (super-admin) (X-Platform-Key, bidang identitas terpisah); manajemen tenant, model langganan/penagihan, pengukuran kapasitas, editor versi legal, reCAPTCHA, pengaturan NetGSM.
i18n (20 dil, key-based, RTL); 20 tema + klinik public site (/s/{slug}) + lead-booking; demo klinik siteleri.
Primitif OTP bersama; reset kata sandi + magic-link + aktivasi akun (SMTP nyata); inti SMS NetGSM; auth publik multi-tenant; manajemen pengguna klinik.
TOTP (RFC6238) + kode cadangan; QR WAJIB (independen-eksternal, qr.js bersih-CSP; diverifikasi independen dengan OpenCV+ISO); verifikasi nomor telepon SMS (persetujuan KVKK).
VEM Görüntüsü (Model Data Minimum) 12 export view + Export API (ditentukan SuperUser, terkunci-tenant, fail-closed); peta Peraturan & Kepatuhan; revisi kontrak legal 100% berorientasi peraturan.
Pusat Dukungan dengan pelacakan tiket; dokumentasi proses SPICE (halaman ini); audit keamanan berkelanjutan + pengerasan.
Untuk informasi rinci tentang arsitektur, keamanan, dan kepatuhan regulasi, hubungi tim kami.
We use cookies necessary for core functionality; analytics and marketing cookies are enabled only with your consent. Kebijakan Cookie