Part 2: GP Journey with Heidi AI - Navigating DCB0160
April 2025 brought a fundamental shift in how we needed to think about digital safety in primary care. This deep dive into DCB0160 compliance reveals the reality of implementing clinical risk management from scratch, with support from North Central London Integrated Care Board's (NCL ICB) Clinical Safety Officers (CSOs).

Dr. Chad Okay
NHS Resident Doctor & Physician-Technologist
Deep Dive into Digital Clinical Safety - Navigating DCB0160 from Scratch
Back in March, I was waiting for templates from our ICB and beginning to understand what DCB0160 actually demanded of us. What I discovered over the following weeks in April 2025 was that this wasn't just another box-ticking exercise. It was a fundamental shift in how we needed to think about digital safety in primary care.
Understanding DCB0160: More Than Just Compliance
Let me start with the basics. DCB0160 is the Clinical Risk Management standard that's legally mandated under Section 250 of the Health and Social Care Act 2012. If you're deploying any health IT system that processes patient data in the NHS, this applies to you. No exceptions.
The critical insight here is that DCB0160 works hand-in-hand with DCB0129. While DCB0129 requires the software manufacturer to assess risks in their product, DCB0160 demands that we, the deploying organisation, conduct our own risk assessment specific to how we'll actually use that system. We needed to localise every risk assessment to our specific practice environment, workflows, and patient population.
The Clinical Safety Officer Challenge - Solved by NCL ICB
The first major relief came when we discovered that the NCL ICB provided CSO support through their dedicated team. Dr Ode Omohwo, as Principal Clinical Safety Officer, and Sithabile Tshabalala had already established processes for supporting practices like ours. This solved what could have been an insurmountable hurdle. Without this support, individual practices would have needed to identify, train, and maintain their own CSO, requiring specialised training that takes days to complete.
However, this didn't absolve us of responsibility. We still needed to work closely with the ICB's CSOs, providing practice-specific context and maintaining our local safety documentation. The CSOs could guide and validate our approach, but the practice remained accountable for understanding and managing our specific risks.
Beyond the Supplier Documentation
Here's where it got challenging. The supplier provided us with their DCB0129 clinical safety case report and hazard log. But DCB0160 requires us to look beyond their generic risk assessment and consider how their identified hazards apply in our specific context.
Working with the ICB's CSO, I spent three days going through their documentation, identifying which hazards were referred to us and what additional controls we needed. For example, their hazard log identified risks around system unavailability, but we needed to assess what backup procedures we had in place specifically for our practice workflow.
The Documentation Trinity: CRMP, CSCR, and Hazard Log
The process involved creating our own localised versions of three key documents:
Clinical Risk Management Plan (CRMP): This became our framework document, defining how we approach clinical safety in our practice, covering our governance structure, roles and responsibilities, and incident management processes. The critical element was making it practice-specific - not just copying templates.
Clinical Safety Case Report (CSCR): This is your evidence that the system is safe for deployment in your environment. This had to demonstrate that we had systematically considered all hazards and implemented appropriate controls.
Hazard Log: This living document required the most time, and ongoing maintenance. Every potential source of patient harm needs to be documented, risk-scored, and controlled.
Working Through the ICB's Identified Hazards
The NCL ICB's Clinical Safety Case Report identified four key hazards that every practice needed to address:
H-001: Misinterpretation of Clinical Information - Risk that the AI might misinterpret speech or medical terminology, potentially leading to incorrect diagnosis or treatment. The ICB scored this as moderate to significant risk.
H-002: Wrong Patient Record - Risk that information could be applied to the incorrect patient record. The ICB emphasised that this could have catastrophic consequences.
H-003: Sub-optimal Care Due to Missing Information - Risk that the AI might fail to capture vital clinical observations not verbalised, such as BP readings, non-verbal cues, or body language.
H-004: Inappropriate Sharing of Sensitive Information - Risk that sensitive or safeguarding information could be inappropriately included in generated letters.
For each hazard, the ICB had developed specific mitigations focusing on mandatory clinician review, proper training, and clear protocols. The key message was consistent: clinicians must review all AI outputs as they remain professionally and legally liable for accuracy.
The Time Investment Reality
Let me be specific about the time this actually took. For our practice implementing Heidi AI Scribe, working with NCL ICB support:
- •Initial consultation with ICB CSO: 1 day
- •Document review and analysis: 3 days
- •CRMP development (using ICB templates): 2 day
- •CSCR creation (localising ICB templates): 4 days
- •Hazard log development (adapting ICB version): 4 days
- •Staff training delivery: 1 day
Total initial investment: Approximately 15 days of clinical time
This was significantly less than it would have been without ICB support - their templates and guidance saved us weeks of work. The ICB CSOs had already completed the heavy lifting of initial risk assessment and documentation structure.
Practical Advice for GPs Starting This Journey
Start early: Don't wait until go-live is imminent. The DCB0160 process takes weeks, not days.
Engage with your ICB's CSO early: They're a valuable resource, but they're also supporting multiple practices. Book your consultations' "AI Clinics" well in advance.
Focus on your context: Generic templates won't suffice. Every hazard needs to be considered for your specific practice circumstances.
Document everything: The standard requires evidence of your risk management process, not just the outcomes.
Plan for maintenance: This isn't a one-time activity. Budget for ongoing safety management time.
The steep learning curve was real, but by the end of April 2025, I could see how this systematic approach to clinical safety was making us a more thoughtful, safer practice. The investment in time and expertise was significant, but the patient safety benefits were becoming clear.
This is Part 2 of a 6-part series documenting the implementation of Heidi AI Scribe in NHS primary care. ← Part 1: The Starting Line | Part 3: Data, DPIAs, and the Accountability Trap →
Share this article

Dr. Chad Okay
I am a London‑based NHS Resident Doctor with 8+ years' experience in primary care, emergency and intensive care medicine. I'm developing an AI‑native wearable to tackle metabolic disease. I combine bedside insight with end‑to‑end tech skills, from sensor integration to data visualisation, to deliver practical tools that extend healthy years.