When we eventually deploy the new service for breast screening (Run Breast Screening in England), we have to comply with the DCB0129 and DCB0160 NHS clinical safety standards.
The standards are to help with ‘effective application of clinical risk management’ for organisations building and deploying health IT system (or software in our case).
DCB0129 is essentially for those ‘building’ the software (our product teams in the Breast Screening Pathway) and DCB0160 is for those ‘deploying’ the software (the Breast Screening Offices or Trusts they belong to). This is already kind of strange given that we mandate the use of the software, so it’s not exactly a choice for the deploying organisations.
To help us meet these standards, NHS England employs clinical safety officers that help provide the risk assessment for the services that we need to deploy. Our current DCB0160 Clinical Safety Officer Dr Jim Steel has written a blog about his experience here too - which comes at the issue from his experience in breast screening.1
Even though the standards technically allow for iterative and agile ways of working, it doesn’t feel like that at the moment. It feels like a series of gates to constantly get through, trying to find some sort of risk where there is basically none - because of how early we are in the build.
But it gets stranger when you are applying agile delivery principles and have multidisciplinary teams taking a user centred design approach to the problem. We’re thinking of how to build a clinically safe service all the time.
I think a clinical safety process is obviously still needed - but one that works with a modern, agile, internally built service. It feels like there is a much better, collaborative way of doing things.
Cybersecurity and clinical safety
About a year ago I did the Information Security Management Principles exam (and passed), as I wanted to learn more about cybersecurity (or see what I didn’t know). The thing I found about working about the Government Digital Service is that I tended to just soak up a lot of the risks around digital technology by just working there. And while maybe I didn’t know about the specific ISO standard for something or all of the different encryption methods - much of the process of managing security was very familiar - because it’s something we thought about every day.
Speed ahead to now working in NHSE. Because I’m a bit obsessive, I recently did the training modules available to me for DCB0129/0160 clinical safety process. Mainly because it’s something we need to do as a programme and I want to know about everything we have to do to get this service live.
And it surprised me. Not because it was something so fundamentally different than assessing risks in other contexts, but because it was so similar.
Some of the concepts feel like parallels the Information Security Management Principles. And the reason for that, is that it’s all just down to risk, risk assessment and what you do about it. There’s nothing terribly different about assessing risk for security or for clinical - it’s the same process.
Understand the context.
Identify Risks.
Assess Risks.
Decide what you’re going to do about it (accept, mitigate, etc).
Write it down, monitor and review.
There are some other similarities, for example, the responsibility of senior management to appoint a person who has the responsibility of assessing or managing the process - such as an information security officer or clinical safety officer.
It sometimes feels that if everyone follows the same set of rules, the outcomes will be the same. But all services are different, all deploying organisations are different, so it naturally follows that sometimes you need to do things a bit differently in order to achieve the right outcome - reducing or mitigating as much risk as possible.
Where things differ
Where I think things differ, in the favour of information security management, is that we think of security as a process. It’s not a one and done. There’s a matter of regular review and a culture of embedding safety everywhere. In software development, there is also the concept of security by design - which is embedding good security practices from the get go. This is in contrast to leaving it to the end of a build.
The DCB 0129/0160 standards contain many of the right concepts, but I think because the conceptual default for their use is an external organisation developing software and trying to sell it, it’s less of a culture of clinical safety and more of reporting and updating.2 Fundamentally, people can sue the NHS or Trust who has deployed a particular system or software. So a lot of it feels like creating enough documentation to argue that something is safe, rather than actually creating something safe to use.
The one thing that that I did take away from the training, was that the standard states that one of the best ways to manage clinical safety is through good design. And yet, it feels like the implementation of the rules for that standard doesn’t necessarily leave space for that good design - through testing and iteration. Instead you get trapped in these big stage-gate activities that don’t add any value in making the service clinically safe. It just feels like overburdensome admin. This is especially the case where we are right now - lots of very small scale testing where there is virtually no clinical risk.
I think the best way to make a clinically safe service is not necessarily sitting in a room and thinking about what might constitute risk - it’s designing a system together with those who will use it. We already know our users don’t do things in just one way, so the best way to mitigate the risk is understanding their day to day and where things can go wrong.
Can we make things better
For fans of the DCB0129/0160 standard - there’s currently a consultation going on about it. So get your views in before it’s too late.
I think we can improve the process by embracing the spirit of the standard, building a clinically safe service by design, just like we build a secure service by design.
Building a nationally mandated service isn’t something that fits nicely within the standard. We can’t ignore it, but we can also do what we think is appropriate. I think this means more a hybrid 0129/0160 approach, where we’re working in partnership with the breast screening offices and Trusts to truly understand the risks associated with deploying the service in each new context (all 77 of them).
There are different technologies, different Trust policies, different people in each service that we need to account for. We won’t need to hypothesise (or prophesise as Jim points out in his blog) because we will be so much closer to the clinical risks by working collaboratively.
Just like security by design, it does feel like we can do clinical safety by design. We have lovely clinical SMEs and partners in breast screening offices that get us to the heart of understanding clinical risk. It’s just that the internal rules have meant that once in awhile, we have to stop, go through a stage-gate, instead of continuing on. It’s a bit of a waterfall practice jammed into a continuous design and risk management process.
We can still meet the letter of the standard by doing all the relevant documentation to prove that it’s a safe service. However, it’ll be that constant dialogue between us and our users that will make it an actually safe service to use.
One of the many joys of being in this programme has been working with Jim. There’s definitely a huge benefit to having someone who knows how screening works. I feel like he short cuts the time it takes to really understand an issue (alongside our other fabulous screening expert Dr Louise Wilkinson). Also, he’s just the very definition of a lovely human being.
Technically, it’s supposed to be applicable for all types of development, but in reality, its an old world model of something getting procured and then bought. Or perhaps commissioned and then deployed. Either way, it doesn’t naturally seem to fit a world internally developed services or continuous deployment.
As someone who's worked a bit in security and taken an onlooker's interest in safety engineering, I too have been struck by parallels between the two. As far as I can tell the main difference is that in security engineering they really are out to get you, whereas in safety engineering it merely feels like it.