Getting Clinical Safety in Primary Care Right

Executive Summary

This case study describes how Appt Health worked with Network 6, the Bromley by Bow Health Partnership, and their outsourced Clinical Safety Officer (CSO), Keith Grimes at Curistica, to complete the DCB0160 clinical risk management process for the deployment of Appt Coordinate.

The process was characterised by open collaboration, clear role boundaries, and a shared commitment to patient safety. Eleven hazards were reviewed across a two-hour workshop on 5 June 2026, with all scored as acceptable after controls. No significant safety concerns were identified that would prevent deployment.

What distinguished this process was the quality of preparation beforehand and the diversity of voices in the room. GPs, practice managers, a network coordinator, a digital transformation lead, an IG lead, and the Appt Health product team all contributed. The result was a hazard log grounded in real operational experience, not theoretical risk.

This document sets out what was done, what was discussed, and why it worked. It offers practical guidance for other primary care networks considering a similar approach.

Introduction

The deployment of health IT into NHS primary care settings requires careful attention to clinical risk. DCB0160, the NHS standard for clinical risk management, sets out what health organisations must do when deploying health software: identify hazards, assess their severity and likelihood, implement controls, and document the process.

For primary care networks deploying digital tools, this can feel daunting. There is often uncertainty about who is responsible for what, how detailed the hazard analysis needs to be, and whether existing clinical workflows are adequately accounted for.

The experience of Appt Health and Network 6 suggests a better way: one in which the software supplier and the network work through the process together, with clear responsibilities on each side, and a focus on patient outcomes rather than compliance formality.

The Deployment Context

About Appt Coordinate

Appt Coordinate is a care coordination platform for NHS primary care. It automates the identification, invitation, and management of patients due for long-term condition reviews, screening, vaccinations, and other proactive care interventions. It integrates directly with EMIS & SystmOne, using rules-based searches to identify eligible patients, then manages multi-channel outreach (NHS app, email, SMS, letter, and automated voice) and appointment booking.

Important terminology: Appt Coordinate uses deterministic, rules-based patient identification. It is not an AI system. The same EMIS search criteria that a practice would configure manually are executed automatically. This distinction matters for GDPR compliance and was a significant point of discussion during the workshop.

About Network 6

Network 6, the Bromley by Bow Health Partnership, is a primary care network in Tower Hamlets, east London. It serves a diverse, multilingual population with significant health inequalities, including a large Bengali-speaking community, elderly residents, and care home populations. This demographic context shaped several of the hazard discussions, particularly around digital exclusion and communication burden.

Who Was in the Room

The workshop brought together thirteen participants across five distinct roles. The breadth of representation was deliberate and proved essential to the quality of the discussion.

Clinical Safety Officer: Keith Grimes (Kiristica), an experienced CSO and former GP, facilitated the session. His clinical background meant he could engage with practice-level concerns in their own language, while maintaining the structured approach DCB0160 requires.

GPs: Three GPs attended, including Sangeeta (Clinical Director for the PCN), Kish (CSO for the partnership, who joined from annual leave abroad), and Raul (who was on call during the session). Their input was particularly valuable on coding quality, clinical record chronology, and the clinical implications of patient identification errors.

Practice managers: Lisa (XX Place and Bromley by Bow) and Shahana Bhavit (St Andrews and St Paul's Way) brought operational detail that no other role could provide. Lisa's contributions on opt-out management and the practical reality of SMS decline handling were especially significant.

Network operations: Sam (Network Coordinator), Phoenix Hickman (Digital and Transformation Lead), and Graham Satter all contributed. Sam's role in supporting practices day to day meant she understood the handoff points and potential gaps in operational processes.

IG and data protection: Roberto, the network's IG/GDPR lead, contributed by voice and chat throughout. His intervention on AI terminology was one of the most consequential moments of the workshop, resulting in a real-time update to the hazard log wording.

Supplier: Hector Smethurst (founder) and Maria (Founder's Associate) represented Appt Health, providing product context, responding to clinical questions, and committing to specific actions.

Before the Workshop

Providing access to documentation

Before any workshop activity took place, Appt Health gave Network 6 and their CSO access to the Appt Health Trust Centre. This gave the network a structured view of all relevant safety materials, including the Appt Health DCB0129 Clinical Safety Case, the DCB0130 Hazard Log, and supporting technical and product documentation.

Making this documentation available early was deliberate. It allowed the CSO to form an independent view of the product's risk profile before the workshop, rather than relying on the supplier to present a curated summary during the session itself.

The CSO's independent review

Keith reviewed the DCB0129 documentation ahead of the workshop. This review served two purposes: it gave the CSO a working understanding of the product, and it surfaced the areas of greatest uncertainty or concern that would benefit from discussion.

Preparing the hazard list

Appt Health prepared a working hazard list for the workshop. This was structured around the core risk profile of the product, which can be expressed simply: the primary clinical risks are (1) eligible patients are not identified or recalled when they should be, and (2) ineligible patients are recalled when they should not be. All other hazards are generally variants of these two scenarios, with different contributing causes and different severities.

Framing the discussion around this high-level risk profile at the outset helped participants engage with the material at the right level of abstraction before moving into specific hazard scenarios.

Clarifying role boundaries

Before the workshop, Appt Health and the network agreed a working principle for risk delegation. Where a hazard relates to product behaviour, system configuration, or supplier-controlled processes, responsibility sits with Appt Health. Where a hazard relates to clinical workflow, coding practice, or actions taken by practice staff, responsibility sits with the practice or network.

This clarity avoided ambiguity during the workshop and made it easier to agree mitigations quickly.

Inside the Workshop

The workshop took place on 5 June 2026 and ran from 09:02 to 11:00 BST. Keith facilitated using the Curistica platform to present and update the hazard log live, so all participants could see changes as they were made. Eleven hazards were reviewed, all scored acceptable after controls.

What follows is an account of the key discussions, structured by theme rather than in strict hazard-log order, to give a clearer picture of how the conversation unfolded and what made it productive.

Patient identification and eligibility

Three hazards dealt with the core question of whether the right patients are being identified: patients eligible but not invited (H1), targets correctly selected but not run (H2), and inappropriate patients being assigned (H3).

The discussion quickly established that these risks are not new. Every practice already runs manual EMIS searches and makes judgement calls about patient eligibility. What Appt Coordinate changes is that the process is automated, auditable, and consistent across the network.

Graham raised the need for a pre-launch checklist so staff could verify their configuration before initiating invitations. This was a practical contribution that would not have surfaced from a purely technical review. Hector committed to co-creating this checklist with Sam.

A new cause was added to H3 during the session: incorrect coding in the patient record leading to a patient being wrongly included or excluded. The group agreed that this is an existing data quality issue, not one introduced by the software, but one that the software should help surface through pre-launch testing that compares EMIS search outputs against Appt Coordinate outputs.

The terminology decision

The discussion around H2 produced one of the most consequential moments of the workshop. Roberto, the IG/GDPR lead, flagged that describing Appt Coordinate's patient identification as "AI" would trigger GDPR Article 22 automated decision-making rights, creating unnecessary regulatory burden.

Keith agreed and updated the hazard log wording in real time, changing "AI outputs" to "algorithmic outputs (deterministic)." This was not a cosmetic change. It reflected the technical reality that Appt Coordinate uses the same rules-based search logic as EMIS, executed automatically rather than manually, and it removed a compliance risk that would have complicated the deployment.

The group clarified that AI is used in two specific features: (a) automated voice powered by a large language model, which is not deployed at Network 6, and (b) a contextual bandit algorithm for optimising SMS send times, which is an administrative function with no clinical decision-making role.

Communication burden and patient experience

Hazard 4 (multiple appointment invitations) drew extensive discussion from Gita, a GP partner, who raised concerns about patients being overwhelmed by text messages from multiple systems. She described a reality in which patients receive messages from Appt Coordinate, Accurx, and network-level feedback requests, and questioned whether the cumulative burden was being adequately managed.

Hector confirmed that Appt Coordinate consolidates multiple care needs into a single appointment where possible, invites one target at a time, and includes configurable delays between invitation sequences. He referenced a published article on minimising patient bombardment. The group acknowledged that the broader coordination of messaging across different systems is a genuine challenge, but one that extends beyond any single supplier's control.

Hazard 10 (message sending failure) also sat in this domain. The group confirmed that practices use only the most recent mobile number on file, to avoid the risk of contacting the wrong family member. When messages fail, the system falls down to the next available channel, and non-contactable patients are reported back to the practice.

Digital exclusion and health equity

Gita and Sangeeta both raised concerns about patients who cannot engage through digital channels: the Bengali-speaking population, elderly residents, and care home patients. This was a recurring theme rather than a single hazard, and it enriched the discussion across several areas.

The group reviewed the available channels. SMS is the primary channel, with letters available for patients without mobile numbers or who have opted out of digital contact. Automated voice with translation capability is in development. Hector acknowledged that digital exclusion is an industry-wide challenge, not fully solved, and that ongoing monitoring of which patient groups are and are not being reached is part of the operational commitment.

Hazard 7 (appointment slot unavailability) also intersected with equity concerns. In "accessible mode," patients receive an SMS with three appointment options (A, B, C) that are not reserved in the clinical system, creating a race condition where a selected slot may already have been booked. Keith and Hector agreed this is an accepted risk-benefit trade-off: accessible mode is the most effective channel for reaching underserved populations, and the alternative (not offering it) would widen inequalities.

Data, consent, and opt-outs

Hazard 5 (patient opts out of data sharing) prompted a discussion that went beyond the technical handling of national data opt-outs. Roberto flagged that the DPIA wording on the direct patient care legal basis needed strengthening, a point that was noted as an action for Phoenix, who is leading the DPIA.

Lisa raised a practical feature request: the ability for practice staff to mark a patient as unsubscribed directly in Appt Coordinate, rather than requiring the patient to reply "stop" to an SMS. This is a workflow gap that matters most in contexts where patients express preferences verbally during consultations. Hector confirmed this as a planned feature development.

Keith added a new cause to this hazard: a patient opting out without understanding the health consequences. The agreed control is staff training on explaining what opting out of recall communications means in practice.

Hazard 9 (declined patients excluded inappropriately) was resolved by confirming that Appt Coordinate checks the timestamp of any opt-out and automatically re-includes patients whose decline has lapsed. For Appt Recall, the workaround is creating new targets each financial year. Lisa confirmed that practices already return patients to search eligibility annually.

Technical resilience

Hazard 6 (data unavailable due to technical issues) covered API failures that could prevent data retrieval. The key control is a 24-hour ceiling on stale demographic data: if the system cannot update patient demographics within 24 hours, outreach activity ceases. Practices are notified within one hour of system downtime. Roberto confirmed that Appt Health provides 30 days written notice before changing sub-processors.

Hazard 8 (patient list fails to upload) relates specifically to Appt Recall rather than Appt Coordinate. Roberto raised the data breach risk from CSV files containing patient identifiable data being emailed or downloaded. The key insight here is that Appt Coordinate eliminates this risk entirely by running searches directly in EMIS, removing the need for data export.

Coding quality and record accuracy

Hazard 11 (medical record chronology inaccuracy) addressed a subtle but important risk: when a clinical event is coded in the record on a different date from when it actually happened, recall timing can drift. Two scenarios were discussed: retrospective coding entered on today's date rather than the intervention date, and lab results coded when returned rather than when blood was drawn.

Sam confirmed that the network is actively training staff to correct dates when coding. The group agreed that this is an existing data quality issue that predates any software deployment, and that the controls are the same whether or not Appt Coordinate is in use: staff training, ongoing quality improvement, and awareness of the implications for recall timing.

Conclusions and Agreed Actions

The workshop produced four clear conclusions:

1. Clinical hazards are manageable

No risks were identified that would prevent deployment. Most identified hazards already exist within current recall processes. Appt Coordinate reduces several of them by automating manual steps, increasing auditability, and improving visibility of patient recall status.

2. Standard operating procedures to be co-developed

The workshop identified a need for SOPs to be developed collaboratively between Network 6 and Appt Health. These cover target configuration and eligibility checklist review, opt-out handling and suppression list management, fallback processes in the event of a technical failure, and pre-launch verification steps for practice staff.

3. Feature requests added to the Appt Health roadmap

Several improvements were identified that would further reduce clinical risk, including practice-side patient unsubscribe capability and enhanced pre-launch comparison tooling. These have been logged and added to the Appt Health product roadmap for prioritisation. Surfacing these through a structured safety process ensures they are treated as safety-relevant, not just nice-to-haves.

4. Network-level training and best practice commitment

Network 6 committed to continuing training and best practice initiatives within member practices as part of its network-level governance responsibilities. This includes ensuring practice staff are familiar with the eligibility configuration, understand when to contact Appt Health, and know how to handle patient queries arising from outreach. Specific areas of focus include opt-out communication, coding date accuracy, and the distinction between Appt Coordinate's role and broader messaging coordination.

What Made It Work

Several factors contributed to the quality of the session:

1. Pre-reading was done. Attendees had reviewed materials in advance and came with informed questions rather than starting from zero.
2. The high-level risk framing helped. Opening with a clear articulation of the two core risk types meant the group had a shared frame of reference throughout.
3. Roles were clear. Because the supplier/network boundary had been agreed ahead of time, discussions about responsibility were quick and constructive.
4. The facilitation was experienced. Keith kept the session moving without cutting discussion short, and created space for practice staff to raise concerns in their own words.
5. The right people were in the room. Having GPs, practice managers, network operations, IG, and the supplier together meant that every hazard could be examined from multiple angles. Roberto's intervention on AI terminology, Lisa's feature request on opt-out handling, and Graham's checklist suggestion all came from distinct professional perspectives.
6. The hazard log was updated live. Using the Kiristica platform to make changes visible in real time meant participants could see their input being captured, which reinforced engagement and trust in the process.

How Other Networks Can Do the Same

The Network 6 process is replicable. The steps below set out what any primary care network working with a health software supplier needs to do to run a proportionate, effective DCB0160 process.

What you need from your supplier

Access to their Trust Centre or equivalent documentation repository. A completed DCB0129 Clinical Safety Case. A completed Hazard Log. A named Clinical Safety Officer or equivalent contact. Willingness to attend and contribute to the workshop as a participant, not just present a use case at it.

What your network needs to bring

A named CSO, whether in-house or outsourced. Clinical representation from practices, including someone with direct knowledge of current recall workflows. Operational staff who understand how the product will be used day to day. An IG or data protection lead who can speak to consent, opt-outs, and data processing. An open mindset: the goal is to identify and manage risk, not to find reasons to block deployment.

What good looks like

Documentation reviewed before the workshop, not during it. A clear high-level risk framing that sets the tone for the session. Agreed role boundaries between supplier and network before you start. Specific, owned actions coming out of the workshop, not vague commitments. A positive, collaborative atmosphere in which practice staff feel safe raising concerns.

Appt Health builds care coordination tools for NHS primary care, helping practices identify, recall, and manage patients with long-term conditions more effectively and more equitably. For more information, contact us at hello@appt-health.co.uk

Appendix: Hazard Summary

The following table summarises the eleven hazards reviewed during the workshop. All were scored as acceptable after controls.

H1. Appropriate target not assigned to patient. An eligible patient is not invited due to a software bug or incorrect target selection. Severity: significant. Likelihood: very low. Controls include testing, manual fallback, training, and SOPs. Hector committed to co-creating SOPs with the network coordinator.

H2. Target correctly selected but not run. A paused target is forgotten, a software bug prevents execution, or there are insufficient appointment slots. Severity: significant. Likelihood: low. Controls include email notifications when targets are paused or slots are insufficient, manual fallback, and training. This hazard prompted the terminology decision: the group changed "AI outputs" to "algorithmic outputs (deterministic)" after the IG lead flagged GDPR Article 22 implications.

H3. Inappropriate target assigned to patient. A wrong patient is invited due to a software bug, human configuration error, or incorrect coding in the patient record. Severity: significant. Likelihood: very low. Controls include reflecting search criteria back to the user on upload, extensive pre-launch testing comparing EMIS and Appt Coordinate outputs, and post-launch monitoring. A new cause (incorrect EMIS coding) was added during the session. Graham requested a pre-launch checklist for staff.

H4. Multiple appointment invitations. A patient with several care needs is overwhelmed by messages. Severity: significant. Likelihood: low. Controls include consolidating multiple care needs into a single appointment, inviting one target at a time, configurable delays between invitation sequences, and personalised messaging. Gita raised concerns about cumulative text burden across Appt Coordinate, Accurx, and network feedback requests.

H5. Patient opts out of data sharing. A patient is not processed due to national data opt-out or personal preference. Controls include manual fallback, training, and practice searches for patients not seen. Roberto flagged the need to strengthen DPIA wording on the direct patient care legal basis. Lisa requested a feature allowing practice staff to mark patients as unsubscribed directly (confirmed as planned development). Keith added a new cause: patient opting out without understanding health recall consequences.

H6. Data unavailable due to technical issues. API failures prevent data retrieval. Controls include a 24-hour ceiling on stale demographic data (activity ceases if unable to update within 24 hours), practice notification within one hour of downtime, and manual fallback. Roberto confirmed 30 days written notice before sub-processor changes.

H7. Appointment slot unavailability. A race condition where offered slots are booked by someone else before the patient selects. Higher likelihood in "accessible mode" (SMS with three options not reserved in EMIS). Controls include offering alternatives if a selected slot is taken and re-messaging with new options. Accepted as a risk-benefit trade-off: accessible mode is the most effective channel for reaching underserved populations.

H8. Patient list fails to upload. Relates to Appt Recall specifically. Roberto raised the data breach risk from CSV files containing patient identifiable data. Controls include design controls on upload format, content validation, and positive confirmation of receipt. Appt Coordinate eliminates this risk entirely by running searches directly in EMIS.

H9. Declined patients excluded inappropriately. Patients who declined last year are incorrectly excluded from this year's recall. Appt Coordinate resolves this by checking the timestamp of any opt-out and re-including patients whose decline has lapsed. For Appt Recall, the workaround is creating new targets each financial year. Lisa confirmed practices already return patients to search eligibility annually.

H10. Message sending failure. SMS or notification fails to reach the patient. Controls include fail-down to the next communication channel, non-contactable patients reported back to the practice, and coding the invitation only when successfully delivered. Practices confirmed they use the most recent mobile number only, to avoid contacting the wrong family member.

H11. Medical record chronology inaccuracy. Coding timestamp versus actual intervention date creates drift in recall timing. Two scenarios: retrospective coding entered on today's date rather than the intervention date, and lab results coded when returned rather than when blood was drawn. Controls include existing practice processes, staff training on correcting dates when coding, and ongoing quality improvement. Sam confirmed the network is actively training staff on this.