Ehealth Limited · Operational
Reg. England EHL/CSC/2026 Clinical Safety · UK
EHL · 2026 · Standards-grade clinical safety

Clinical safety,
engineered for evidence.

DCB0129. DCB0160. SaMD. Specialist consulting for health software manufacturers and the NHS organisations that deploy them, grounded in the standards and written like the regulator reads.

Book a discovery call → Explore services →
◊ Engagement profile
StandardDCB0129 / 0160
FrameworkISO 14971
RegulationUK MDR 2002
SectorsMfr · NHS
StatusAccepting briefs
§ 01 · Services

Three disciplines.
One safety case.

Whether you manufacture clinical software or deploy it into an NHS organisation, the safety burden is real, evidenced, and now expected to be auditable end-to-end.

SVC-001 · For manufacturers

DCB0129

Clinical risk management for health IT manufacturers.

Hazard identification, clinical risk analysis, and the construction of a defensible safety case for software placed onto the NHS market. Built around a Claims, Arguments, Evidence (CAE) model the regulator already knows how to read.

Typical deliverables
  • Clinical Risk Management Plan
  • Hazard Log & SWIFT analysis
  • Clinical Safety Case Report
  • Letter of Transfer
    • SVC-002 · For deploying orgs

    DCB0160

    Local clinical safety for NHS trusts, ICBs and providers.

    Assessment of how a system actually behaves inside your organisation, with the local hazards, workflows, mitigations and residual risks documented to standard. The bit that becomes painfully visible at go-live, done properly upstream.

    Typical deliverables
  • Local Hazard Assessment
  • Deployment Risk Register
  • Clinical Safety Case (local)
  • Transfer acceptance evidence
    • SVC-003 · Cross-cutting

    SaMD

    Software as a Medical Device under UK MDR 2002.

    Classification, Essential Requirements, technical file authoring, and the alignment of your clinical risk management activity with regulatory expectations under UK MDR. Sensible advice on where the lines actually are.

    Typical deliverables
  • SaMD classification rationale
  • Essential Requirements Matrix
  • Technical File construction
  • PMS & vigilance plan
    • § 02 · Credentials

    Standards-fluent.
    Audit-ready by habit.

    Hands-on experience across the standards and frameworks that matter, and the document conventions the assessors actually look for.

    C.001 DCB0129 Clinical Risk Management — Manufacture of Health IT Systems Expert
    C.002 DCB0160 Clinical Risk Management — Deployment & Use of Health IT Systems Expert
    C.003 ISO 14971 Application of risk management to medical devices Applied
    C.004 IEC 62304 Medical device software lifecycle processes Applied
    C.005 UK MDR 2002 Software as a Medical Device — classification, ERs, technical file Practised
    C.006 NMC Registered Clinical authority underpinning safety reasoning and hazard rationale Active
    C.007 BSI MDR Professional Medical Device Regulation Professional, BSI Group qualification Certified
    C.008 IEEE AI Ethics Assessor Authorised Assessor under the IEEE AI ethics certification programme Certified
    — end of overview —
    Start a conversation →
    DocumentEHL · § 02 · Services
    Issued byEhealth Limited
    ScopeDCB0129 · DCB0160 · SaMD
    Status● Current

    A short
    catalogue of services.

    Each engagement begins with the same first move: locating the boundary of clinical responsibility, then mapping the evidence required to defend it.

    § 02.1 · For manufacturers

    DCB0129
    Clinical risk management for health IT.

    A complete DCB0129 engagement, end-to-end, structured around a defensible safety case rather than a checklist of artefacts.

    02.1.1 · Establish

    Plan & scope

    Clinical Risk Management Plan authored against your software's actual scope of use, with clinical roles, hazard methodology and review cadence locked down before work starts.

    Outputs
  • CRMP (project-level)
  • Scope of clinical risk
  • Methodology statement
    • 02.1.2 · Analyse

    Hazards & risk

    SWIFT-led hazard identification with multidisciplinary input, mapped into a hazard log with risk scoring, controls and residual risk; explicit and traceable.

    Outputs
  • SWIFT workshop pack
  • Hazard log (live)
  • Risk control evidence
    • 02.1.3 · Defend

    Safety case

    Clinical Safety Case Report assembled as a Claims, Arguments, Evidence document, with subsidiary claims and a clean evidence register the regulator can follow without translation.

    Outputs
  • CSCR (CAE-structured)
  • Evidence register
  • Letter of Transfer
    • § 02.2 · For deploying organisations

    DCB0160
    Local clinical safety, properly upstream.

    Deployment is where the manufacturer's safety case meets reality, your local processes, users and patient pathway. Done well, it shortens go-live, not lengthens it.

    02.2.1 · Receive

    Transfer review

    Assessment of the manufacturer's safety case and Letter of Transfer against your intended use, with explicit acceptance of residual risks and gaps that local controls must close.

    Outputs
  • Transfer assessment
  • Gap analysis
  • Acceptance memo
    • 02.2.2 · Localise

    Local hazard work

    Local hazards identified across configuration, workflow and clinical user behaviour, with mitigations woven into training, SOPs and configuration choices, not bolted on.

    Outputs
  • Local hazard log
  • Workflow risk maps
  • Mitigation register
    • 02.2.3 · Operate

    Deploy & sustain

    Local Clinical Safety Case Report, plus a sustainment model for incident review, change assessment and periodic safety review that survives go-live and beyond.

    Outputs
  • Local CSCR
  • Incident & change SOPs
  • Periodic review cycle
    • § 02.3 · Cross-cutting

    SaMD
    Software as a Medical Device.

    If your software meets the definition of a medical device, UK MDR 2002 applies. The clinical safety work and the regulatory work should be one programme, not two.

    02.3.1 · Classify

    Classification

    Determination of whether the software is a medical device under UK MDR, its class, and the evidence path that follows from that decision; documented so it withstands later scrutiny.

    Outputs
  • Qualification rationale
  • Classification statement
  • Regulatory route plan
    • 02.3.2 · Evidence

    Technical file

    Essential Requirements matrix and technical file constructed to UK MDR 2002, integrated with the clinical risk management file so the same evidence does both jobs.

    Outputs
  • Essential Requirements matrix
  • Technical file pack
  • Clinical evaluation summary
    • 02.3.3 · Sustain

    Post-market

    Post-market surveillance and vigilance plans aligned to your release cadence; clinical incidents, change control and periodic re-assessment running as one stream of evidence.

    Outputs
  • PMS plan
  • Vigilance SOPs
  • Periodic Safety Update Report
    • — end of services —
    Discuss your engagement →
    DocumentEHL · § 03 · About
    SubjectStatement of practice
    ModelFounder-led consultancy
    Status● Open to briefs

    A founder-led
    practice, not a panel.

    Ehealth Limited is a specialist consultancy in clinical safety and Software as a Medical Device, led by a clinician with hands-on programme experience inside the standards.

    Founded
    United Kingdom
    Practice model
    Solo expert, founder-led
    Client mix
    Manufacturers · NHS
    Engagement
    Fixed-scope or retained
    Discipline
    Clinical + regulatory

    Clinical safety sits in an awkward place. It is governed by standards, written for engineers, and policed by clinicians, and most teams have only one of those three fluencies. Ehealth Limited exists to bridge them.

    The practice is founder-led on purpose. Clinical safety work is, in the end, an argument; that a system is acceptably safe in its intended use, defended with evidence. That argument is built sentence by sentence, and is hard to delegate. Clients get the senior practitioner from intake to letter of transfer.

    "The argument the regulator reads, and the evidence that holds it up, are the same document seen twice."

    Engagements draw on a clinical background (registered nurse), programme experience inside national-scale health IT, and document-engineering habits learned the hard way from years of safety case authoring. The output looks like what the standards intended: clear, traceable, and readable.

    Work is undertaken under UK jurisdiction, against DCB0129, DCB0160, ISO 14971, IEC 62304, and UK MDR 2002 as applicable. Where a client needs more hands, trusted associates are introduced; the engagement lead does not change.

    § 03.1 · Skills

    Where the
    fluency sits.

    Three tracks of practical capability, drawn on in different proportions depending on the engagement.

    03.1.1 · Track 1

    Standards & regulation

    The frameworks the work is held to.

    • DCB0129, clinical risk management for manufacture
    • DCB0160, clinical risk management for deployment
    • ISO 14971, risk management for medical devices
    • IEC 62304, medical device software lifecycle
    • UK MDR 2002, GB medical device regulation
    • Essential Requirements authoring (UK MDR)
    • Post-market surveillance & vigilance frameworks
    03.1.2 · Track 2

    Methods & techniques

    How the safety case actually gets built.

    • SWIFT facilitation (Structured What-If)
    • Hazard identification & hazard log management
    • Clinical Safety Case Report construction
    • Claims, Arguments, Evidence (CAE) reasoning
    • Risk scoring & residual risk acceptance
    • Letter of Transfer authoring & assessment
    • Clinical Risk Management Plan authoring
    • Periodic safety review cycles
    03.1.3 · Track 3

    Clinical domain

    The view from inside the care setting.

    • NMC registered nurse
    • NHS care pathway literacy
    • Triage & urgent care workflows
    • Primary, secondary & community care
    • Clinical user experience assessment
    • Information governance in clinical contexts
    • Patient safety culture & incident review
    — end of about —
    Get in touch →
    DocumentEHL · § 04 · Contact
    FormRequest for engagement
    Response SLAWithin 2 working days
    Status● Accepting briefs

    Start a
    conversation.

    Send a short brief, drop an email, or book a call. Whichever is easiest; the first conversation is short and unbilled.

    ◊ Direct email enquiries@ehealth.ltd Reply within 2 working days
    ◊ Book a call Schedule 30 minutes → Discovery, free of charge
    ◊ Office hours Mon–Fri · 09:00–17:30 GMT Out-of-hours by arrangement
    ◊ Jurisdiction England & Wales UK MDR 2002 · DCB standards
    Request for engagement FRM · 01
    Submissions are private and used only to respond to your enquiry.
    ✓ Request received. Expect a response within two working days at the email you provided.
    — end of document —