UDENTIVA embeds the process maturity sought in health software into the architecture itself. This page presents, with evidence, our development lifecycle, our SPICE / ISO-IEC 15504 capability levels, our continuous error-logging and control mechanisms, our version and security criteria, and our development history.
Basis: Regulation on Health Information Management Systems (Regulation No. 39682), Art. 6 and Art. 20 — software quality (CMMI/SPICE) certification requirement.
Process definition, implementation, and traceable work products are structured; quantitative measurement, defect prevention, and continuous improvement mechanisms operate in production. An official capability level declaration is subject to an independent appraisal.
SPICE assesses processes on a capability scale from 0 to 5. UDENTIVA is structured to meet Level 1-3 expectations at the level of process definition, implementation and traceable work products; for Levels 4-5, quantitative measurement and continuous-improvement mechanisms are in operation. An official level declaration is subject to independent assessment.
The quantitative control and continuous-improvement mechanisms for Levels 4-5 are operated below with their evidence (live measurement, defect/CAPA log, deployment records).
Every process area corresponds to a concrete implementation in UDENTIVA and to auditable evidence. The process is not a document — it is running code.
| Process Area | UDENTIVA App | Evidence |
|---|---|---|
| ENG.1 Requirements Elicitation | Phase map + vertical-slice requirement definition; the UDENTIVA.md project charter locks the requirements. | UDENTIVA.md (GOLDEN RULES), 02_tech_spec/ technical specification, phase/module map |
| ENG.4 Software Design | Modular monolith; context packages do not share each other's tables; communication via interfaces; external service = adapter. | internal/{identity,patient,billing,export,...} boundary rule; ADR-001..008 |
| ENG.5 Software Construction | Explicit SQL (sqlc, no ORM); context as the first parameter in every function; error wrapping with %w; money = numeric. | sqlc.yaml type override (numeric→string), db/queries/*.sql, gofmt/golangci-lint |
| ENG.6 Software Integration | PHP(BFF) ↔ Go ↔ PostgreSQL ↔ Redis loopback chain; single public surface. | web/core/ApiClient, /healthz component health (db+redis) |
| ENG.7 Software Testing | Cross-tenant isolation test (most critical), idempotency, appointment conflict, monetary precision, 2FA/OTP, TOTP RFC6238 vector, QR (OpenCV+ISO verification). | internal/integration/*_test.go, platform/totp/totp_test.go, go test ./... |
| SUP.1 Quality Assurance | Every PR must comply with the GOLDEN RULES; lint clean; no merge if the isolation test is red in CI. | golangci-lint, Definition of Done kontrol listesi |
| SUP.8 Configuration Management | Git version control (branch core); goose sequential schema versioning; build artifacts are backed up. | git, goose_db_version tablosu, .tools/deploy yedekleri |
| SUP.9 Problem Resolution | Append-only audit log + email/SMS outbox (a record for every send) + deploy backup/rollback discipline. | audit_log, email_outbox/sms_outbox, bin/server.exe.bak-* rollback |
| SUP.10 Change Request Management | Every schema change is a new numbered migration; reversible (goose Down); deploy classifier approval. | db/migrations/0001..0027, +goose Up/Down |
| MAN.3 Project Management | Vertical-slice delivery (each slice works end to end); session handover notes. | super-devam.md, faz tablosu (DoD per dilim) |
| MAN.6 Measurement | Health check, capacity measurement, email/SMS send metrics, audit volume, live event telemetry. | /healthz, Process Monitoring & Quality dashboard (event/error/deploy/KPI) |
Responsibilities are separated into layers; the domain authority resides at a single point and is isolated via loopback. The browser sees only the thin BFF and can never access the domain and data layers directly.
| Layer | Responsibility & Security | Location |
|---|---|---|
| Sunum (BFF) | PHP 8.4 — thin BFF: session, render, CSRF, routing. NO business rules/DB. Single public surface (IIS:443). | web/ |
| Uygulama / Domain | Go modular monolith — the SOLE authority of the domain. RBAC, business rules, transactions. Listens only on 127.0.0.1. | api/internal/ |
| Veri | PostgreSQL — every table has tenant_id + RLS FORCE; explicit SQL (sqlc), parameterized. Money as numeric. | api/db/ |
| Cache / Queue | Redis — session, idempotency, distributed lock, asynq queue (SMS/e-Fatura). | platform/redisx |
| Nesne Depolama | S3-compatible — large files (X-rays) presigned/stream; blobs never in the DB. | platform/storage |
| External Service (adapter) | e-Fatura, SMS (NetGSM), email (SMTP), (later e-Nabız/MEDULA/DICOM) — abstracted behind an interface. | internal/notify |
Measurement isn't a statement, it's a working system. All operations are counted live (success/failure), production errors are captured in a permanent log, and the KPI framework below is tied to periodic actions. The data sources are real tables: event_counter (live operation counter), error_log (permanent error log), deploy_log (deployment log).
| Measurement Area | KPI | Target | Data Source | Period | Action |
|---|---|---|---|---|---|
| Tenant isolation security | cross-tenant test fail | 0 | CI / izolasyon testi | her PR | Merge block |
| Production error | explicit error (5xx/panic) | 0 | error_log (persistent) | continuous/live | RCA + CAPA zorunlu |
| Operation success rate | success / toplam event | ≥ 99% | event_counter (live) | continuous/live | Root cause on decline |
| Resolution time | MTTR (avg. resolution) | ↓ decreasing trend | error_log (resolved) | monthly | Trend incelemesi |
| Deployment reliability | rollback rate | < %5 | deploy_log | 30 days | Rollback review |
| Identity security | 2FA/OTP kritik olay | 0 | audit + event_counter | monthly | Hardening |
| Messaging reliability | SMS/e-posta failure | ↓ low | *_outbox | daily | Provider review |
| Restore readiness | restore test success | %100 | DR test (hedef) | quarterly | Update runbook |
Every production error goes through a standard root-cause analysis (RCA) and corrective/preventive action (CAPA) cycle; recurrence of the same error is prevented through regression control and trend monitoring.
Production errors (5xx/panic) are captured automatically → persistent error_log (on repeat of the same signature, count++, defect trend).
The level (error/panic), impact, and repeat count are determined; prevalence is measured via failed-event counters.
Root cause analysis is performed and recorded on the Process Monitoring dashboard.
A corrective action + preventive action (code, test, migration rule, security control) is defined and recorded.
A test/rule preventing recurrence of the same error is added; it is monitored via continuous telemetry.
KPI trends (MTTR, error rate, rollback) are periodically evaluated; a process-level action is opened for recurring errors.
The essence of SPICE Level 5: continuous logging of errors, keeping them under control, defect prevention and continuous improvement. UDENTIVA operates these mechanisms in production.
The immutable (append-only) audit_log records every critical operation; email_outbox/sms_outbox persist every send (status, attempts, error). No event is silently lost.
Consistent error envelope {error:{code,message}}; internal error/stack is never leaked. Before every deploy, a binary + web backup; in case of an outage, rollback within seconds via bin/server.exe.bak-*.
Fail-closed architecture: no RLS context means 0 rows; idempotency prevents double processing; numeric money makes float errors impossible; whitelist (export dataset) prevents SQL injection. Errors are prevented by design from the start.
Critical components are verified by two independent methods: TOTP RFC6238 test vector, for QR an OpenCV cv2 decode + ISO/IEC 18004 reference codeword, and the cross-tenant isolation test.
In every session, security review → findings → hardening (e.g. Phase 2/Phase 3 RBAC added, 2FA, Export API). Institutional memory is preserved via process notes (super-devam.md).
A new regulatory requirement (VEM View) is turned directly into a product feature and evidence; regulatory changes are continuously monitored and mapped into the compliance map.
One codebase, narrowed with a flag — no fork.
A traceable version at the schema, source, deployment and API layers.
The entire development process is under version control; every deployment is reversible (rewind/rollback).
Security isn't a feature, it's the architecture itself. The non-negotiable rules whose breach means a PR is rejected:
The system was built with vertical slices, each running end to end. Below is a chronology of the phases and recent security/regulation work.
pgx+sqlc, goose, RLS fail-closed test, WithTenantTx, session middleware, login+RBAC, audit, PHP↔Go loopback, asynq foundation, health.
Patient CRUD + cross-tenant isolation test → Appointment (exclusion constraint + Redis lock) → Odontogram/Treatment plan (FDI, append-only) → Collection/Account/Cash (derive, idempotent) → e-Fatura adapter (fast-follow) → Inventory → X-ray (S3) → SMS reminder (asynq backoff).
Platform-operator (super-admin) tier (X-Platform-Key, separate identity plane); tenant management, subscription/billing model, capacity measurement, legal version editor, reCAPTCHA, NetGSM settings.
i18n (20 dil, key-based, RTL); 20 tema + klinik public site (/s/{slug}) + lead-booking; demo klinik siteleri.
Shared OTP primitive; password reset + magic-link + account activation (real SMTP); NetGSM SMS core; multi-tenant public auth; clinic user management.
TOTP (RFC6238) + backup codes; MANDATORY QR (external-independent, CSP-clean qr.js; independently verified with OpenCV+ISO); SMS phone verification (KVKK consent).
VEM View (Minimum Data Model) 12 export views + Export API (SuperUser-defined, tenant-locked, fail-closed); Legislation & Compliance map; 100% legislation-oriented legal contract revision.
Ticket-tracked Support Center; SPICE process documentation (this page); continuous security review + hardening.
For detailed information about architecture, security and regulatory compliance, get in touch with our team.
We use cookies necessary for core functionality; analytics and marketing cookies are enabled only with your consent. Cookie Policy