Healthcare software development
This page is a factual reference, not a claim. It sets out what each standard relevant to UK and US healthcare software requires, who is typically responsible for it, and where it sits in a project timeline. Where a status specific to Zorix would normally be stated, it is marked as a placeholder rather than asserted.
For our own certification, insurance and data protection position, stated line by line rather than summarised, see security and compliance.
Reference table
| Standard | What it requires | Who owns it | Where it sits in a project timeline |
|---|---|---|---|
| NHS DTAC | Evidence across five domains: clinical safety, data protection, technical security, interoperability and usability with accessibility, assembled into a single assessment response. | Assembled jointly: the supplier produces the technical, clinical safety and interoperability evidence; the commissioning NHS organisation runs the assessment. | Evidence gathered continuously through the build; the formal assessment response is compiled ahead of NHS procurement or go-live, not written retrospectively. |
| DCB0129 | A clinical risk management plan, a hazard log maintained through development, and a clinical safety case report signed off by a clinical safety officer before release. | The manufacturer — the party building the software. Requires a named clinical safety officer, which may be a role held by the client or the supplier depending on the contract. | Hazard identification starts at discovery and the hazard log is updated at every significant design or scope change through to release. |
| DCB0160 | A deployment-level clinical risk management file covering how the software is configured and used within a specific care setting, distinct from the manufacturer's own risk assessment. | The deploying NHS organisation, typically supported by its own clinical safety officer, using the manufacturer's DCB0129 artefacts as an input. | Completed by the deploying organisation ahead of go-live in their specific setting, after the manufacturer's DCB0129 documentation is available. |
| DSPT | An annual self-assessment against the National Data Guardian's data security standards, covering staff training, process controls and technical measures for organisations handling NHS patient data. | Each organisation that processes NHS health and care data completes and submits its own DSPT return. | Reviewed annually and referenced during procurement due diligence rather than tied to a single project milestone. |
| UK GDPR | Lawful basis for processing special category health data, a documented data protection impact assessment for higher-risk processing, defined retention schedules, and processor obligations set out in contract. | The data controller — usually the client commissioning the software — with the supplier acting as processor and completing its obligations under the processing agreement. | The data protection impact assessment is started at discovery, before design decisions that affect data flows are finalised. |
| MHRA medical device classification | An assessment of whether the software's function falls within the UK Medical Device Regulations 2002, and if so, registration with the MHRA and a conformity assessment appropriate to the risk classification. | The manufacturer is responsible for the classification decision and any resulting registration; specialist regulatory advice is typically commissioned separately from the software build. | Assessed during discovery, because a positive classification materially changes scope, timeline and the applicable quality management approach. |
| HIPAA | Administrative, physical and technical safeguards for protected health information, plus a business associate agreement between a covered entity and any vendor handling that data on its behalf. | The US-based covered entity holds primary responsibility; a vendor acting as a business associate has direct obligations under the agreement it signs. | Safeguards are designed into the architecture from the outset for any US-facing health data product; retrofitting them is materially more expensive. |
| SOC 2 | An independent examination of a service organisation's controls against the trust services criteria — commonly security, availability and confidentiality — resulting in a Type I or Type II report. | The service organisation being examined commissions and holds the report; clients typically request it as part of vendor due diligence rather than the software project itself. | Usually pursued as an organisational initiative independent of any single project, though a project may need to align its controls with an existing or planned SOC 2 scope. |
In detail
NHS DTAC, the Digital Technology Assessment Criteria, is the framework NHS organisations use to assess digital health products before procurement. It does not certify a product once and for all; it consolidates evidence across five domains — clinical safety, data protection, technical security, interoperability and usability with accessibility — into a single assessment that a commissioning body reviews for its own purchasing decision.
DCB0129 and DCB0160 are the two halves of the NHS clinical risk management standard for health IT. DCB0129 applies to the manufacturer of the software and requires a clinical risk management plan, a hazard log identifying and tracking clinical safety hazards through development, and a clinical safety case report signed by a named clinical safety officer before release. DCB0160 applies to the organisation deploying the software into a specific clinical setting and requires its own risk assessment of how the software is configured and used there, built on top of the manufacturer's DCB0129 evidence.
DSPT, the Data Security and Protection Toolkit, is an annual online self-assessment against the National Data Guardian's data security standards. Organisations that access NHS patient data or the NHS network are generally expected to complete it, and NHS commissioners often ask suppliers to evidence their own submission as part of due diligence.
UK GDPR governs the processing of personal data, and health data is classified as special category data under Article 9, which carries a stricter lawful basis test than ordinary personal data. In practice this means a documented lawful basis, a data protection impact assessment for higher-risk processing, defined retention periods, and contractual terms that set out the processor's obligations.
MHRA medical device classification concerns whether software falls within the UK Medical Device Regulations 2002. The determining factor is function rather than technology: software that interprets clinical data to produce or support a diagnosis, or otherwise drives a clinical decision, may be classified as a medical device and require MHRA registration and an appropriate conformity assessment route. Software limited to storing, displaying or transmitting data is generally outside this scope, but the classification is assessed against the specific function of the product rather than assumed from its category.
HIPAA is US federal legislation governing protected health information held by covered entities — broadly, healthcare providers, insurers and clearinghouses — and by their business associates. It requires administrative, physical and technical safeguards, and a business associate agreement between the covered entity and any vendor processing data on its behalf.
SOC 2 is a voluntary examination, conducted by an independent auditor, of a service organisation's controls against defined trust services criteria, most commonly security, availability and confidentiality. It results in a Type I report, assessing controls at a point in time, or a Type II report, assessing whether those controls operated effectively over a review period, and is commonly requested by US enterprise and healthcare buyers during vendor due diligence.
Our position
| Standard | Zorix status |
|---|---|
| DSPT submission | Available on request during due diligence |
| Cyber Essentials Plus | Available on request during due diligence |
| ISO 27001 | Available on request during due diligence |
| SOC 2 report | Available on request during due diligence |
| HIPAA business associate readiness | Available on request during due diligence |
We do not display certification badges and we will not describe ourselves as certified, accredited or compliant with a standard we have not evidenced in writing. For the full statement of our position across certification, insurance and data protection, see security and compliance.
Where this sits
Questions
No. This page is a factual reference to what each standard requires and where responsibility for it typically sits in a project. Anywhere a status specific to Zorix would normally appear, it is marked Available on request during due diligence rather than asserted, and we will not state that we hold a certification or accreditation until the certificate and its scope statement can be produced.
DCB0129 is the clinical risk management standard for the manufacturer of health IT software — the party building the system. DCB0160 is the corresponding standard for the deploying organisation putting the system into clinical use. A supplier produces the DCB0129 hazard log and clinical safety case report; the NHS organisation deploying the system owns the DCB0160 assessment and depends on the supplier's artefacts to complete it.
Only products procured for use within NHS-commissioned services generally go through a formal DTAC assessment as part of procurement. Products sold to private providers are not assessed against DTAC by default, though building to an equivalent evidence standard from the outset is generally lower cost than retrofitting it later if the product is later sold into the NHS.
If software's function is to interpret clinical data and drive or influence a clinical decision, it may fall within the scope of the UK Medical Device Regulations 2002 and require MHRA registration and a conformity assessment route appropriate to its risk class. Software that only stores, displays or transmits data without interpretation is usually outside this scope, but the classification decision depends on function and is assessed case by case, not assumed either way.
They apply where the product serves US-based clients or handles data on their behalf, regardless of where the software is built. HIPAA governs protected health information handled by covered entities and their business associates in the United States, and SOC 2 is a voluntary examination of a service organisation's controls that many US healthcare buyers require of their vendors contractually.
Send us the buyer and the setting, and we will tell you which standards are actually in scope before you commit to a compliance programme you may not need.
Talk to us