P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Sector specialist

Healthcare AI Assurance

Assurance for clinical and healthcare AI: DTAC, clinical risk under DCB0129 and DCB0160, data protection, and the evidence a trust's governance board actually asks for.

Healthcare AI is judged by two groups who rarely share a vocabulary. Clinical safety wants to know how the system fails and who notices. Information governance wants to know where the data goes. A vendor arrives with a model card and a penetration test and satisfies neither, and procurement stalls for months without anything actually being wrong.

2

Clinical safety standards

DCB0129 for manufacturers, DCB0160 for deploying organisations.

5

DTAC assessment areas

Clinical safety, data protection, technical security, interoperability, usability.

2

Audiences, two evidence packs

Clinical safety and information governance ask different questions.

2017

Building healthcare AI since

Zeromed commercialised for radiology and pathology workflow.

What it maps to

DTAC

The Digital Technology Assessment Criteria, covering clinical safety, data protection, technical security, interoperability and usability. The gate most healthcare deployments meet first.

DCB0129 and DCB0160

Clinical risk management for manufacturers and for deploying organisations respectively. Two standards, two hazard logs, and vendors routinely produce only the first.

ISO 42001

The AI management system, including the impact assessment on individuals that a clinical context makes concrete rather than theoretical.

UK GDPR and the common law duty of confidence

The question is almost always whether identifiable data leaves the organisation and on what lawful basis, not whether a DPIA exists.

How the engagement runs

  1. 1

    Establish the clinical claim

    What the system is asserted to do clinically, and what follows if it is wrong in each direction. False negative and false positive are rarely equally serious, and the safety case depends on the difference.

  2. 2

    Build the hazard log properly

    Written as clinical hazards with clinical mitigations, not as technical risks relabelled. This is the document a clinical safety officer will actually read.

  3. 3

    Trace the data

    Where identifiable data goes, who processes it, whether it leaves the organisation, and what the basis is. Including the training data, which is the question vendors answer least well.

  4. 4

    Assess the AI-specific failure modes

    Drift, provenance, and what happens to a clinical decision when the model is confidently wrong. Standard assessments do not cover these.

  5. 5

    Package the evidence twice

    Clinical safety and information governance read different documents and ask different questions. One combined pack satisfies neither.

  6. 6

    Support the review

    Through the governance board or procurement process, answering the follow-ups rather than handing over a file.

What you walk away with

  • A DTAC submission pack with the evidence behind each section
  • A clinical hazard log framed for DCB0129 or DCB0160 as appropriate
  • A data flow map showing every point identifiable data is processed, including training data
  • An AI-specific risk assessment covering drift, provenance and failure behaviour
  • Separate evidence packs for clinical safety and information governance
  • A plain summary for a governance board that does not require a technical reader

The regulatory landscape this works within

Stated as working knowledge rather than as delivery experience, because the distinction matters here. Clinical safety and regulatory sign-off belong to your named Clinical Safety Officer and your regulatory lead. What this brings is the ability to navigate that landscape with them, produce evidence in the form each reviewer expects, and recognise when an AI-specific question is not covered by the standard being applied.

Clinical risk management

  • DCB0129, manufacturers, and DCB0160, deploying organisations
  • Clinical Safety Case Report and Hazard Log: purpose and structure
  • The role of the named Clinical Safety Officer

NHS information governance

  • Data Security and Protection Toolkit
  • Caldicott Principles
  • Data protection impact assessment practice
  • National data opt-out
  • Digital Technology Assessment Criteria (DTAC)

Medical device regulation for AI

  • Software as a Medical Device classification under UK MDR 2002
  • UKCA conformity assessment routes
  • MHRA framework as it applies to AI in clinical settings

Supporting lifecycle and risk standards

  • IEC 62304, medical device software lifecycle
  • ISO 14971, risk management for medical devices
  • ISO 13485, quality management systems

How this plays out

Example scenario

An AI vendor repeatedly stalled in NHS procurement.

The work: Review of what had been submitted against what each reviewer needed.

The technical evidence was strong and there was no clinical hazard log at all. The vendor had answered the security question thoroughly and the safety question not at all.

Example scenario

A trust deploying a third-party imaging model.

The work: Clinical risk review under DCB0160, the deploying organisation's standard.

The vendor held DCB0129 and the trust had assumed that discharged its own duty. It does not; the deploying organisation carries its own clinical risk obligation.

Example scenario

A healthcare AI product claiming data never leaves the site.

The work: Data flow tracing including telemetry and model update paths.

Patient data genuinely stayed on site. Model performance telemetry did not, and nobody had characterised whether it could be reidentifying.

Start the conversation

A short call to understand your situation; a clear scope if the engagement fits, and a straight answer if it does not.

Discuss a healthcare engagement

Share this

Send it to whoever owns the budget or the risk.

← All services

The problem

Healthcare AI is assessed by two groups who rarely share a vocabulary. Clinical safety wants to know how the system fails and who notices. Information governance wants to know where the data goes. An AI vendor arrives with a model card and a penetration test, and satisfies neither.

The result is procurement that stalls for months, not because anything is wrong but because nobody has produced the evidence in the form the reviewer needs.

What you get

  • DTAC preparation across clinical safety, data protection, technical security, interoperability and usability
  • Clinical risk management framed for DCB0129 and DCB0160, with hazard logs that read as clinical rather than technical documents
  • An AI-specific view most assessments miss: training data provenance, drift, and what happens to a clinical decision when the model is wrong
  • Data protection work that addresses the actual question, which is usually whether identifiable data leaves the organisation and on what basis
  • Evidence packaged for the people who will read it, separately for clinical safety and information governance

Proof point

Grounded in building healthcare AI, not just reviewing it: Zeromed, commercialised in 2017 for radiology, pathology and back-office workflow, and OxRad, an on-premise AI radiology reporting platform designed to keep patient data on site. ISO 42001 Lead Auditor, and ISACA AAISM.