As clinicians, we take clinical safety very seriously – it’s baked into our ways of working, but what about in our digital roles? Digitising workflow can eliminate certain errors within analogue processes, but it can also introduce new ones too.
For example, introducing electronic prescribing eliminates the risk of manual transcription. But what if the electronic prescribing system crashes, or suffers an outrage? This just doesn’t happen with paper and pens…
This is where clinical safety processes come in. By undertaking a robust assurance process on a digital product or service, we can plan for what might go wrong before going live.
Undertaking comprehensive clinical safety assessments can also help reassure frontline colleagues that a new digital innovation is as safe as existing analogue workflows.
What is clinical safety?
As CCIOs, we must ensure the technologies we roll out are safe for patients and reduce risks in the delivery of care. “Clinical Safety” simply refers to all standards, guidelines and practices relating to the safety of health technologies.
How do I know if something requires a clinical safety process?
Any application/digital platform that impacts on clinical care delivery or decision-making requires adherence to a Clinical Safety Standard.
There are two main standards to be aware of:
- DCB0129, which is the standard that software manufacturers must adhere to; and,
- DCB0160 which is the standard that healthcare providers must adhere to when they deploy products for clinical use.
As a CCIO in an NHS Trust, you’ll mostly need to familiarise yourself with DCB0160. Persuading suppliers to undertake an DCB0129 isn’t always easy. My advice would always be to err on the side of caution and undertake a DCB0160, at least. More on this later…
Handily, as well as the existence of these national standards, there’s also plenty of training and guidance for Clinical Safety Officers (CSO), who are tasked with overseeing these processes.
So, who should the CSO be?
This is a thornier issue than it appears…
According to national guidance, the CSO must be a “suitably qualified and experienced clinician”, which makes it easy to see why this often ends up tagged on to the CCIO role. After all, CCIOs are generally experienced senior clinicians, familiar with digital systems, who work closely with digital teams.
However, there are a couple of disadvantages. If you are both the clinical informatics lead and CSO for a digital project, this can smack a little of “marking your own homework”.
There’s also the issue of workload. Most clinical informatics teams are under-resourced. Having a separate CSO not only spreads the workload, but also increases clinical leadership with the digital department – no bad thing at all.
So, if you are a CCIO and have also been asked to be the CSO for your organisation, it may be worth considering whether separating the two roles is beneficial.
How do you “do” clinical safety?
The NHS England website has information on the process, but to summarise – once you’ve identified that a product/service needs to be compliant, the following steps should take place before the system goes live:
Beginning the process
- Someone should be identified to lead the Clinical Safety process
Supplier documentation
- You should scrutinise the supplier’s DCB0129 Hazard Log and Clinical Safety Case Report. If you’re concerned that they don’t have this documentation, the CSO should enter a dialogue. I’ve found the national clinical safety team helpful in mediating, where necessary.
Hazard Workshop
- You should convene a Hazard Workshop(s) with end users to identify potential clinical risks. These should be recorded in a Hazard Log and mitigations identified for each. Mitigations may require, for example, a change to the system design, or the provision of training.
- Next, ensure these mitigations are implemented – it’s no good if you don’t act on them. It’s enormously helpful to have technical colleagues and operational managers to advise on this.
Clinical Safety Case Report
- The person leading the Clinical Safety process must document key elements of the Hazard Log in a Clinical Safety Case Report. Crucially, the report should contain the “Clinical Safety Case Statement”, which details whether the CSO believes the system is safe to deploy.
- The CSO must sign off the report and present it to the project board, so the Senior Responsible Officer and other decision makers have confidence clinical safety processes have been followed and can make a go/no-go decision.
Post-Implementation Hazard Log
- The final step (often missed) is ensuring the Hazard Log can be updated post-implementation and during decommissioning, so unanticipated risks can be mitigated.
Top tips for Implementing Clinical Safety
As a former CSO, I’d recommend you:
Get Help from Colleagues
While the CSO must sign off the Clinical Safety Case Reports, other colleagues can compile Clinical Safety Case Reports or hold Hazard Workshops.
Invite a broad range of stakeholders to your Hazard workshops
Stakeholders can include administrators who will use the system; operational managers who can authorise workflow changes to mitigate risks; and technical colleagues who can advise on the feasibility of system design changes.
And, of course, bring someone to record the meeting!
Network within your Organisation
Meet with your organisation’s patient safety lead. They probably won’t be familiar with digital Clinical Safety processes but can be vital allies. The same goes for the executive colleague with responsibility for governance in your organisation. This is especially important if resourcing the Clinical Safety function is an issue.
Ensure your Programme Managers broadly understand Clinical Safety Processes. For example, by putting on informal training. We were able to get our PMO to embed Clinical Safety activities in all their project processes and plans, so it became an integral part of the culture.
A Note on Medical Devices
If the technology that you’re introducing is classified as a “medical device”, a different set of regulations applies. Guidance on medical devices is out of scope of this chapter, but the bar for compliance is very high – do seek specialist advice!