Trust & Compliance
Which standards apply — and when
Healthcare compliance is a map, not a wall. Here's how the main UK standards fit together, and where we help.
Standards matrix
Applicability at a glance
| Standard | Applies when… | What it requires |
|---|---|---|
| DTAC | Buying or building any NHS digital product | Baseline assessment across 5 areas. |
| DCB0129 | You manufacture a health IT system | Clinical safety case + hazard log. |
| DCB0160 | You deploy a health IT system | Local clinical risk management. |
| UK GDPR + DPIA | You process personal/health data | Lawful basis, Art.9 condition, DPIA for high-risk. |
| DSP Toolkit | You access NHS data/systems | Annual data-security assurance. |
| WCAG 2.2 AA | Any public-facing service | Accessibility conformance. |
| MHRA (SaMD) | Your software has a medical purpose | May be a regulated medical device. |
Reading the map
Compliance is a map, not a wall
Teams new to digital health often picture compliance as a single barrier to clear. In reality it is a set of overlapping standards, each triggered by a different fact about your product, your organisation and your data. The most important question is rarely "is this hard?" but "which of these actually applies to us?" — and the honest answer depends on three things: the role you play, whether your software has a medical purpose, and the kind of data you handle.
Your role is the first fork. If you build a health IT system you are a manufacturer, and clinical safety under DCB0129 sits squarely with you. If you implement someone else's system into a care setting you are a deployer, and DCB0160's local risk management is yours. Many organisations are both at once, which is fine provided each obligation is owned deliberately. The second fork is intended use: software with a medical purpose may be a device regulated by the MHRA, regardless of how simple the technology looks. The third is data — any processing of health information pulls in UK GDPR, a special-category condition and, for high-risk or AI processing, a DPIA.
The thread that ties it together. For NHS-facing products the DTAC assessment pulls clinical safety, data protection, technical security, interoperability and accessibility into one buyer-facing response — which is why it tends to expose any gap in the others.
Where we help
Preparation, not approval
Meds Global Health helps you get ready to meet these standards. We map applicability to your specific intended use, structure the artefacts each standard expects, and quality-assure them so they withstand the scrutiny of an NHS clinical safety review, an information-governance team or a vendor-security assessment. What we do not do is issue regulatory approvals, act as a notified body, or substitute for your organisation's accountable sign-off — those decisions are yours to make with your advisers, and we are clear about that boundary throughout.
- Applicability mapping against your role, intended use and data
- Clinical-safety evidence aligned to DCB0129 and DCB0160
- Data-protection footing, including DPIAs for AI
- DTAC response preparation and review — see what is NHS DTAC
- DSP Toolkit alignment for organisations accessing NHS data
For the full procurement-facing picture, our NHS Buyer Readiness page sets out the artefacts buyers ask for, and our AI Validation & Clinical Safety service shows how product evidence is built and tested.
Answers
Frequently asked questions
How do I know which standards apply to us?
It depends on your role (manufacturer vs deployer), whether your product has a medical purpose, and what data you process. Use the matrix above as a starting point and book a call — we map applicability to your specific intended use and context.
Do you provide legal or regulatory sign-off?
No. We provide assurance support, evaluation and governance guidance to prepare you. Formal legal, regulatory and notified-body decisions remain with you and your advisers.
How do manufacturer and deployer obligations differ?
Your role changes which standards bite. A manufacturer of a health IT system owns the product clinical safety case and hazard log under DCB0129; the organisation deploying it owns a local clinical risk-management file under DCB0160. The same split runs through data protection, where controller and processor carry different accountabilities. We help you identify which role you occupy — sometimes both — before mapping obligations.
When does software become a regulated medical device?
If software has a medical purpose — for example, diagnosis, prevention, monitoring, prediction or treatment — it may be a medical device regulated by the MHRA and require UKCA marking. The trigger is intended use, not the technology. We help you articulate intended use and prepare the supporting documentation, but the classification decision and any submission rest with you and your regulatory advisers.
In what order should we tackle these standards?
Start with intended use and role, because they determine applicability. Then settle the data-protection footing (lawful basis, DPIA), build clinical-safety evidence appropriate to your role, complete the DTAC assessment that draws those threads together, and address DSP Toolkit and accessibility in parallel. We sequence this so each artefact feeds the next rather than being redone.
Map your compliance
Tell us your product and role; we'll map what applies and how to prepare.