DDRTDeterministic lifecycle
The same request follows the same phases in the same order, every time. No hidden paths, no special cases for “trusted” code.
The DDRT platform
One secure core. Every module runs on it.
DDRT is not a suite of applications sharing a login. It is a single platform — one identity model, one permission model, one transaction lifecycle, one audit trail — with every module, from triage to trial balance, running as governed configuration on the same core. This page explains how, in the language your IT team will ask for it.
The shape of the system
A platform, not a bundle.
Modules never talk to the database, to security, or to each other directly. They run on shared services, which run on the kernel. The dependency direction is one-way and it is enforced by an architecture linter in continuous integration — a forbidden import fails the build, not a code review.
That single rule is why DDRT deploys as one system instead of ten separate projects, and why the ward and the ledger agree by construction.
Modules — configuration on the core · hover any
ClinicalDiagnosticsPharmacyRevenue & NHISSupply ChainWorkforceFinanceAnalyticsPortalPOS
Shared servicesMetadata engine · Workflow · Documents · Notifications · Analytics · Integrations · Licensing
Secure kernelIdentity · Permissions · Transaction lifecycle · Events · Audit trail · Error handling
The kernel knows nothing about medicine, money, or stock — deliberately. Business meaning lives in metadata and modules; governance lives below them, where no module can bend it.
The execution lifecycle
Every write earns its place.
Nothing writes to a DDRT database casually. Every command — a vital sign, a dispense, a journal entry — passes through the same 13-phase pipeline, in order, every time. The pipeline is owned by the kernel; no module or extension can skip a step.
1
Verify
Adapter intakeContextAuthenticationAuthorization
Who are you, and may you do this — answered before anything else happens. Authorization is deny-by-default and evaluated centrally, never inside module code.
2
Shape
MetadataBefore-validateValidation
The record's rules come from metadata — required fields, types, business checks — and are enforced on the server. The client is a convenience, never the gate.
3
Commit
Before-savePersistenceAfter-saveCommit
All-or-nothing inside a kernel-owned transaction. Extensions get named hook points here; none of them can break atomicity, and none may reach outside the building mid-transaction.
4
Announce
After-commitResponse
Side effects — notifications, claim submissions, ledger postings — run only after the data is safely committed. A failed SMS can never corrupt a saved record.
Reads run a shorter eight-phase path with the same authentication and authorization. Every write is audited end to end; reads of sensitive data are audited too.
The guarantees
Guarantees, not intentions.
These rules come from DDRT's normative engineering blueprints — the platform's constitution. Breaking any of them requires a new major version of the framework, not a sprint.
G-01
G-02
Kernel-owned transactions
Only the kernel opens, commits, or rolls back a transaction. Modules and extensions operate inside boundaries they cannot move.
G-03
Centralized authorization
Every permission decision is made in one place, against one deny-by-default model. There is no second, weaker gate to sneak past.
G-04
Auditable transitions
Every state change is attributable — who, what, when, from where. Reads of sensitive data are audited too, not just writes.
G-05
No I/O inside transactions
External calls — payment providers, SMS, insurers — are forbidden inside a database transaction. Slow networks can never hold your data hostage.
G-06
Compatible upgrades
Minor versions are backward-compatible by rule. Your configuration and extensions survive updates — that is a contract, not a hope.
Why this matters to a buyer: feature lists converge; guarantees don't. Any vendor can demo a form. Very few can tell you, in writing, what their platform refuses to let happen.
The configuration engine
Changes in days, not projects.
The platform reads its own definition — tables, fields, forms, workflows, permissions, navigation — from metadata at startup. Adapting DDRT to your institution is a governed configuration exercise, not a software project with a release train.
Ships as configuration
- Clinical forms and fields — new templates, sections, conditional show/hide/require logic.
- Workflows and approvals — states, transitions, role gates, separation-of-duties guards.
- Roles and permissions — down to individual fields and commands.
- Tariffs, price rules, and posting rules — how money moves, per payer, per facility.
- Navigation and pages — what each role sees, entity pages generated from metadata.
Stays governed
- Schema changes ship as migrations — validated against the live database before any table is activated. No runtime schema mutation, ever.
- Every configuration change is versioned and audited — who changed the form, when, and what it looked like before.
- No raw SQL from clients — every read and write goes through the governed command pipeline.
- The physical database is the single source of truth — metadata is verified against it, not the other way round.
The proof it generalizes: the same kernel behind the full hospital build also drives a complete packaged-water product — production, route sales, an offline field app — and a multi-channel retail POS. Different industries, same kernel, different metadata.
Extensibility
Extensions that can't break the core.
When configuration isn't enough, DDRT extends through controlled hooks — additive only, at named lifecycle points, inside the same governance as everything else.
Hooks
Named lifecycle points
Extensions attach at Before-Validate, Before-Save, After-Save, and After-Commit — the same phases you saw above. Nowhere else.
Boundaries
What extensions may never do
Touch the database directly, override the lifecycle, grant permissions, or call external systems inside a transaction. These are architectural walls, not review comments.
Enforcement
Checked on every build
An architecture linter runs in CI on every change: forbidden imports, lifecycle bypasses, and boundary violations fail the build automatically.
Security & trust
Audited by design.
Security isn't a module that could be misconfigured off — it's the execution model itself. Every claim below is demonstrable in the live demo, on request, against the running system.
Read the security overviewDeny by defaultNo access exists until explicitly granted — to a person, in a role, for a reason.
Two authorization layersCommand-level policy and role-level grants — both must agree before anything happens.
Field-level controlSensitive fields are guarded individually, not just whole screens.
Complete audit trailReads and writes alike, attributable and tamper-evident.
Encrypted throughoutIn transit and at rest, on every deployment model.
Ghana DPA alignedData Protection Act (843) posture documented; ISO 27001 on the published roadmap.
AI on the platform
Intelligence inside the permission model.
Assistants are embedded in the workstations — summarizing patient timelines, drafting claims, flagging stock-outs — and they obey the same rules as the humans they help: scoped to the user's role, grounded in your institution's data, and audited on every read. On the appliance, AI can run entirely on your own hardware — so patient data never has to leave the building.
Deployment
Runs where your institution lives.
Most vendors offer you their cloud and call it a choice. DDRT was engineered for the harder reality — including facilities where power and connectivity cannot be assumed.
Option 1
Managed cloud
We run it, you govern it. Fastest path to live for connected facilities and multi-site groups.
Option 2
Private cloud
Your infrastructure, your policies, our platform. For institutions with existing IT estates and sovereignty requirements.
Option 3
On-premises appliance
A self-contained server image for your server room. Clinical work continues on your local network when the internet doesn't — payments and claims queue and retry.
What the appliance ships with
- Offline licensing — machine-bound, no phone-home required; expiry degrades to read-only, never lockout.
- Encrypted backups — with a documented restore path, rehearsed at handover, and a disaster-recovery runbook.
- Offline updates — applied on site from a signed bundle; migrations verified before the new version serves traffic.
- Local AI tier — sized to your hardware, from assistant-off to full on-box models.
What your IT team gets
- One integration surface — a documented command API, webhooks, HL7/ASTM analyser and DICOM imaging connectivity — with FHIR interoperability on the published roadmap.
- Self-service administration — users, roles, forms, and access managed in-house. No ticket, no waiting on us.
- One upgrade path — the whole platform versions together; minor upgrades are backward-compatible by rule (G-06).
- Diagnostics built in — health checks and a supportable, inspectable system rather than a black box.
13integrated products on one core
1,100+governed tables, metadata-verified
13lifecycle phases on every write
6written guarantees — breaking one needs a major version
Next step
Bring your IT lead. Bring your hardest question.
The demo runs on the live product, and everything on this page can be shown running — the permission model, the audit trail, the appliance, the offline behaviour. No slideware.