DDRTDeny by default
Access is granted, never assumed. There is no “default user” with quiet capabilities, and no code path that skips the check.
Security & trust
Audited by design.
Most systems add security around the product. In DDRT, security is the product's execution model — deny-by-default access, a governed 13-phase lifecycle on every write, and an audit trail that covers writes and sensitive reads alike. Every claim on this page can be demonstrated on the live system, during your evaluation, on request.
Deny by default — alwaysHash-chained, tamper-evident audit trailOn-premises deployment, data never has to leave GhanaNo decorative badges — if it isn't ours yet, this page says so
Access control
Nothing is accessible until someone decides it should be.
A freshly created DDRT user can do exactly nothing. Every capability they gain is an explicit, recorded grant — and every grant can be traced to who made it.
Principle
Structure
Two layers must agree
Every action passes both a command-level policy and role-level permission grants. A gap in one layer is caught by the other.
Granularity
Field-level control
Sensitive fields — costs, diagnoses, salaries — are guarded individually. A role can see a record without seeing everything on it.
Scope
Profiles bound the world
What a user sees is scoped by profile: which products, which facility, which wards and stores. A pharmacist and a matron inhabit different systems.
Enforcement
The server is the gate
Client-side checks are treated as UI hints only — a stance written into the code itself. Every decision that matters is made server-side, centrally.
Sessions
Sessions are governed
Per-profile session timeouts, controlled re-authentication, and — for offline field devices — cryptographically signed, revocable device sessions.
The audit trail
Every change. And the reads that matter.
Most systems audit changes. DDRT also audits access — because in a hospital, who looked at a record matters as much as who changed it.
Coverage
Every write — and sensitive reads
Every change leaves a record, and access to sensitive records is audited too — including when the reader is the AI assistant rather than a person.
Attribution
Who, what, when, from where
Every entry is attributable to a person, a role, a time, and a source. “The system did it” is never the end of an investigation.
Integrity
Tamper-evident
Audit records are hash-chained — an altered or deleted entry breaks the chain visibly. The trail protects itself.
Retention
Kept for the long haul
Retention configurable to your records policy — seven years by default — with the storage and export mechanics to make it practical, not aspirational.
Data protection
Encrypted, vaulted, and never in our shipping images.
In transit
Encrypted in transit
Browser to server, server to integrations — TLS is the standard configuration, including on your local network.
At rest
Encrypted storage
Database and file storage encrypted at rest on every deployment model, appliance included.
Secrets
No default passwords, ever
Every installation generates its own unique keys and refuses to start on known defaults. The “default credentials” finding that haunts hospital IT audits cannot happen here.
Credentials
Per-tenant secret vault
Integration credentials — payment providers, SMS, insurers — live in an encrypted vault, scoped per tenant, never in configuration files.
Backups
Encrypted, tested backups
Scheduled backups are passphrase-encrypted end to end, and the restore path is documented — a restore rehearsal is part of every handover. A backup you've never restored is a hope, not a plan.
Provisioning
Zero patient data in ship images
The appliance's provisioning baseline is PHI-free by construction — it carries schema, configuration, and reference catalogues. Patient data only ever originates at your facility.
And for AI: on the appliance, assistant models can run locally on your own hardware — patient data never has to leave the building.
Sovereignty & continuity
Your data. Your building. Your keys.
Trust in a vendor should never require betting the institution on that vendor's future. DDRT is structured so it doesn't.
Residency
Full on-premises option
The complete platform runs as a self-contained appliance in your server room. Data residency isn't a contract clause — it's physics.
Licensing
Read-only, never lockout
If a licence lapses, the system degrades to read-only. It never switches off and never holds patient records hostage — enforced in the platform, not promised in a letter.
Exit
Your data is exportable
Full data export is a contractual right and a working feature. Choosing DDRT must never mean being unable to leave DDRT.
Continuity
Escrow and perpetual licence
Source-code escrow with defined release conditions, and a perpetual-licence option for institutions that want ownership outright.
Compliance posture
Where we stand — stated plainly.
Certifications are earned, not implied. Here is exactly where DDRT stands today, in the same words we'd use across a procurement table.
| Framework | Status | What that means in practice |
|---|---|---|
| Ghana Data Protection Act, 2012 (Act 843) | Aligned | Documented alignment: in-country residency via on-premises deployment, consent and access-rights handling, encryption, access control, audit, and retention. The posture document is available to evaluating institutions. |
| Data-subject rights (GDPR-style) | Designed in | Access, correction, and export patterns are built into the platform — useful today, and ready for cross-border partners who ask. |
| ISO/IEC 27001 | Roadmap | On our certification roadmap, published honestly. The architecture was built to its control philosophy; the certificate follows with our first enterprise deployments. |
| SOC 2 | Roadmap | Sequenced after ISO 27001. We will not display a badge we do not hold. |
| HIPAA (United States) | Not claimed | Not our market today. The platform's technical safeguards map cleanly to HIPAA's requirements, and we maintain that mapping for the day it becomes relevant — but we don't claim what we haven't certified. |
Why this table looks different from other vendors': nothing on it is decorative. Honesty about being early — paired with an architecture you can inspect running — is the trust we can offer today, and we think it's worth more than a borrowed logo.
For procurement
The RFP answers, in one table.
Copy this into your evaluation. Every row is demonstrable on the live system — and we'd rather demonstrate than assert.
| Requirement | DDRT's answer |
|---|---|
| Access control | Deny-by-default; dual authorization layers (command policy + role grants); field-level control; profile-scoped facilities, wards, and stores; all decisions server-side. |
| Audit | Every state change audited and attributable (who/what/when/where); reads of sensitive records audited too; tamper-evident hash-chained trail; retention configurable to policy (seven-year default). |
| Encryption | TLS in transit; encrypted at rest; passphrase-encrypted backups; per-tenant encrypted credential vault; unique per-install secrets, no defaults. |
| Data residency | Full on-premises appliance option — data never required to leave the facility, or Ghana. |
| Backup & disaster recovery | Scheduled encrypted backups; documented restore procedure, rehearsed with your team at handover; disaster-recovery runbook. |
| Vendor failure / lock-in | Source-code escrow; perpetual-licence option; licence expiry degrades to read-only, never lockout; contractual and working data-export right. |
| Updates | Signed update bundles applied on site (no internet required); database migrations verified before the new version serves traffic; backward-compatible minor upgrades by rule. |
| Integrations | Documented command API, webhooks, HL7/ASTM analysers, DICOM imaging — all governed by the same authorization and audit as human users. FHIR interoperability on the published roadmap. |
| AI governance | Assistants operate inside the user's permission scope; every AI read is audited; local on-box AI option keeps patient data in the building. |
| Verification | All of the above shown running, on the live system, during evaluation. No slideware. |
Don't take our word for it
Three things to make us prove in the demo.
We invite scrutiny because the system stands up to it. Bring your IT lead, and ask for these three, live:
1
Watch a denial.
Have us log in as a nurse and attempt a cashier's action, or open a restricted field. Watch the platform refuse — and then find that refusal in the audit trail, attributed and timestamped.
2
Audit the demo itself.
At the end of the session, ask us to pull the audit trail of the session — every change we made and every sensitive record we touched, including by the AI assistant.
3
Break the network.
Ask us to pull the network cable on an appliance demo. Clinical work continues on the local network; queued payments and claims sync when connectivity returns. This is the failure mode, rehearsed.
Next step
Put this page in your RFP. Then make us demonstrate it.
A 45-minute session on the live product, with your scenarios and your IT lead's hardest questions. Security walkthroughs on request.
Security researchers and disclosures: security@ddr-technologies.com · we acknowledge within two business days · security.txt.