How to Run a Really Good DCB0160 Hazard Workshop
What we learned from participating in a clinical safety hazard workshop with the Bromley by Bow Health Partnership (ran by Curistica), and what we would tell any network or practice about to do the same.
If your practice or primary care network is deploying a new piece of health technology or software, you will need to complete a DCB0160 clinical risk management process. The centrepiece of that process is usually a hazard workshop: a structured session where the people who understand the clinical workflows sit down with the people who built the software and work through what could go wrong.
Done well, this is one of the most useful meetings you will ever have. Its primary purpose is safety: identifying what could go wrong and agreeing how to control it. But a good workshop does more than that. It is also an opportunity to improve operational processes and governance across the practice and the network more broadly. For the technology provider, it surfaces feature requests and product improvements that would not emerge through any other channel. In our session, practice managers flagged workflow gaps, GPs raised data quality concerns that shaped how we think about pre-launch checks, and the IG lead prompted a terminology change that simplified our compliance position. All of that came from a meeting framed around clinical safety. Done badly, on the other hand, it is a box-ticking exercise that leaves everyone frustrated and the hazard log full of vague, unactionable entries.
We recently completed our hazard workshop with Network 6 in Tower Hamlets, the Bromley by Bow Health Partnership, for the deployment of Appt Coordinate (our technology to make care coordination more streamlined, more effective, and more inclusive). It went well. Here are the key insights we would pass on so that other technology providers and clinical providers can make the most of the DCB0160 process.
What needs to happen before the workshop
The quality of the workshop is largely determined by what happens in the days and weeks before it. A well-prepared session can cover a lot of ground in two hours. A poorly prepared one will spend most of that time getting people up to speed.
Get the documentation to your CSO early
Your Clinical Safety Officer needs time to review what can often be complex and dense documentation. At least two weeks, ideally more. They need to read the supplier's DCB0129 Clinical Safety Case and Hazard Log, and they need to form their own view of where the risk sits before anyone joins the meeting.
For our workshop, we gave Dr Keith Grimes at Curistica access to our Trust Centre well in advance. That meant he walked in with a working understanding of the product and a clear sense of which areas needed the most discussion. The difference between a CSO who has done the reading and one who is seeing the material for the first time is enormous.
Keith came prepared with a set of priority hazards that, if nothing else was covered, needed to be reviewed by the team. He also came with a clear agenda and an expectation of what should be covered during the session. That level of preparation from the CSO set the pace for the whole workshop.
Prepare a working hazard list
The supplier should come with a comprehensive hazard log that covers all hazards meeting the threshold for review. However, it is unlikely to be possible to review every one of those in depth during the meeting. The CSO should review the full log beforehand and identify which hazards are priority for discussion, based on severity, uncertainty, or where practice-level input is most needed. This is not about presenting a fait accompli; it is about giving the group something concrete to react to, with a clear sense of where the time should be spent.
For Appt Coordinate, we framed the hazard list around two core risks: eligible patients are not identified or recalled when they should be, and ineligible patients are recalled when they should not be. Every hazard on the list was a variant of one of those two scenarios, with different causes and different severities. Starting with that simple framing gave everyone in the room a shared lens before we got into specifics.
Agree the role boundaries
Before the workshop, get clear on who owns what. We agreed a simple principle with Network 6:
Where a hazard relates to product behaviour, system configuration, or supplier-controlled processes, responsibility sits with the supplier. Where a hazard relates to clinical workflows, coding practice, or actions that must be taken by practice staff, responsibility sits with the practice or network.
This sounds obvious, but without stating it explicitly, you will spend workshop time negotiating ownership rather than discussing risk. Getting it agreed in advance means the conversation can move quickly.
Circulate pre-reading
Send the agenda, the draft hazard list, and any relevant background materials to all attendees at least a few days before the session. Practice managers and GPs are busy. If they have not read the material, they will spend the first 30 minutes catching up and the rest of the session offering less informed input than they otherwise would.
When our attendees arrived, they came with questions. That is the sign that pre-reading has worked.
The agenda
Our session ran for two hours with thirteen attendees from across the network. Here is the structure we used:
0:00 to 0:10. Welcome and introductions. The CSO sets out the purpose: this is a DCB0160 hazard identification and assessment session. The output is a reviewed hazard log with agreed controls, risk scores, and assigned owners. Set the tone early: this is collaborative, not adversarial. The goal is to identify and manage risk, not to find reasons to block deployment.
0:10 to 0:20. High-level risk framing. The supplier presents the core risk profile. For us, that was the two-risk framing described above. This gives the group a shared frame of reference and helps them engage at the right level of abstraction before moving into specific scenarios.
0:20 to 0:40. Patient identification and eligibility. How are patients selected? What are the risks of over- or under-inclusion? What controls exist? This is typically the meatiest section and benefits from having the most time.
0:40 to 0:55. Communication and recall workflows. How are patients contacted? What is the risk of communication burden? How are non-responders handled?
0:55 to 1:10. Digital exclusion and health inequalities. Which patient groups may not be reached through digital channels? What safeguards are in place? For Network 6, this was a significant discussion given the Bengali-speaking population, elderly residents, and care home patients in Tower Hamlets.
1:10 to 1:25. Data, coding, and consent. Opt-out handling, consent mechanisms, coding quality, and record accuracy.
1:25 to 1:40. Technical failure modes. What happens if the system is unavailable? What are the fallback processes? Who is responsible?
1:40 to 1:50. SOPs, training, and audit. What operational procedures are needed? What training is required? How will the network monitor performance?
1:50 to 2:00. Summary and agreed actions. The CSO summarises findings, confirms the risk profile, and records agreed mitigations, owners, and timelines.
Two hours is enough if the preparation has been done. If it has not, it will not be.
Ways of thinking inside the workshop
Start with what already exists
Most of the hazards you will discuss are not new. They already exist in your current recall processes. The question is not "does this software introduce risk?" but "does this software change the risk profile, and if so, in which direction?"
In our workshop, the group consistently found that Appt Coordinate reduces existing risks by automating manual steps, increasing auditability, and improving visibility of patient recall status. That does not mean there are no new risks. But anchoring the discussion in "what is the baseline?" prevents the conversation from drifting into a mode where every identified hazard feels like a reason to pause.
Think about causes, not just scenarios
For each hazard, push beyond the scenario and ask what would cause it. A hazard like "inappropriate patient identified" has multiple possible causes: a software bug, a configuration error by the practice, or incorrect coding in the patient record. Each cause has different controls and different owners.
In our session, a GP raised the cause of incorrect date coding: when a clinical event is coded on the date the data is entered rather than the date the event happened. That is not a software issue, but it affects how the software behaves. It would not have surfaced in a purely technical review.
Let the IG person speak
If you have an IG or data protection lead in the room, make sure they have space to contribute. In our workshop, the DPO's intervention on AI terminology was one of the most consequential moments. He flagged that describing Appt Coordinate's patient identification as "AI" would trigger GDPR Article 22 automated decision-making rights, creating unnecessary regulatory burden. The technology in place here was not AI, so this was safe to change. The CSO updated the hazard log wording in real time.
That kind of contribution only happens when the IG lead is in the room and feels empowered to raise concerns that sit outside the purely clinical domain.
Distinguish between product risks and process risks
Some risks sit with the supplier. Some sit with the network. Keeping that distinction clear during the workshop prevents two common failure modes: the supplier taking responsibility for things it cannot control (like coding quality), and the network assuming the supplier will handle things that are actually operational (like fallback processes when a system is down).
When, one of our network attendees, asked for a pre-launch checklist for staff, that was a process risk being surfaced. The lead from the technology supplier committed to co-creating it with the network coordinator. Both sides had a clear action, and neither side was left holding something that belonged to the other.
Do not try to solve everything in the room
The workshop is for identifying and confirming the scoring of hazards, agreeing controls, and assigning owners. It is not for designing SOPs, building checklists, or specifying feature requests. When those needs surface, log them as actions and move on.
We came out of our session with commitments to co-develop SOPs with Network 6 team members, a feature request for practice-side patient unsubscribe capability, and a note to strengthen the DPIA wording. These were all useful takeaways, but none of them needed to be resolved during the workshop itself.
How different stakeholders should be involved
The single biggest determinant of workshop quality is who is in the room. Get this wrong and the hazard log will be shallow.
Clinical Safety Officer
The CSO facilitates the session and maintains the hazard log. They need clinical expertise, CSO training and experience with the DCB0160 framework. Their job is to keep the discussion structured, make sure every hazard is scored and owned, and create space for quieter attendees to contribute. An experienced CSO will know when to let a discussion run and when to move on.
Network 6 used Dr Keith Grimes at Curistica, who is a GP. His clinical background meant he could engage with practice-level concerns without needing them translated into technical language.
GPs
You need at least one GP, ideally two or three from different practices if the workshop spans a PCN. They bring clinical judgement on severity, knowledge of how coding works in practice, and credibility with other clinical attendees. In our session, several GPs contributed perspectives that practice managers and the supplier team could not have provided.
Practice managers
Practice managers understand the operational reality. They know how recall lists are managed, how patients respond to communications, and where the handoff points are between systems and staff. In our workshop, one practice manager's contributions on SMS opt-out handling and patient unsubscribe workflows were grounded in years of managing these processes.
Network operations
If the deployment is network-wide, you need someone who understands how the product will be coordinated across practices. In our workshop a Network Coordinator was the person who would be supporting practices day to day. Her involvement meant that SOP commitments were realistic and that training needs were properly scoped.
IG and data protection
An IG lead ensures that data processing, consent, and information governance concerns are addressed alongside clinical safety. Network 6's input on terminology and DPIA wording was unlikely to have come from any other attendee. If your network does not have a dedicated IG lead available, consider whether someone from the ICB or a shared service could attend.
The supplier
Whilst it isn't strictly necessary, it's massively helpful if the supplier can attend, not just to present as an expert in how the technology works, but to listen, respond, and commit to follow up actions. Sending someone who can only describe the product but cannot commit to actions defeats the purpose. In our case, Hector, as Appt's founder, could confirm roadmap changes and agree to co-create SOPs on the spot, which meant the workshop produced concrete outcomes rather than "we will take that away and get back to you."
Digital and transformation leads
If your network has someone leading digital adoption, get them in the room. Network 6's Digital and Transformation Lead was leading on collating updates to the DPIA and could pick up actions that sat at the intersection of clinical safety and information governance. Not every network will have this role, but where it exists, it bridges a gap that other attendees cannot.
A final thought
DCB0160 does not need to be burdensome. It does not need to take months. What it does need is proper preparation, the right people, and a collaborative mindset. If your supplier is doing its job, it will have a safety case, a hazard log, and a Trust Centre ready to share. If your network is doing its job, it will bring clinical, operational, and governance voices to the table and engage with the process as something valuable, not something to endure.
We completed our process in two hours, reviewed eleven hazards, and came away with a clear, evidenced safety position and a set of specific actions. Any network can do the same.
Hector Smethurst is the founder of Appt Health, which builds care coordination tools for NHS primary care. You can view our clinical safety documentation on our Trust Centre, or contact us at hello@appt-health.co.uk.
