How many software medical device and non-medical device healthcare software manufacturers out there are fully aware of their need to comply with DCB0129 when supplying the NHS? Sadly, the need to comply can come as a shock, either late in the process of procurement, putting the brakes on a sale, or even after putting software into service, causing a minor panic while everything is put in place, or even temporary withdrawal from service.
Thankfully, implementing a DCB0129 Clinical Risk Management File needn’t be difficult for medical device manufacturers, as the principles come straight from the regulatory and standards playbook. For healthcare software providers without a medical device classification, it’s a learning curve, but not one that should have you running for the hills. Charlton Regulatory are always happy to help where DCB0129 understanding and compliance is needed, but there’s a lot that companies with existing risk management processes can do for themselves that is very straightforward and doesn’t require any particularly new thinking or analysis - it’s redecoration, not construction work, so approach it with confidence!
For those with an ISO 14971 risk management process and risk management file for your software product, you should have existing documents and records you can easily reuse directly or repurpose for DCB0129, so you should already be most of the way there:
A Clinical Risk Management Plan is a lot like an ISO 14971 risk management plan, but with a few tweaks to state how the DCB0129 process will be fulfilled - you likely have all of this to hand, and should be able to repurpose a lot of risk management planning to this end.
Your hazard analysis should already have identified all of the clinical hazards that need to be given in the Clinical Hazard Log - it’s the set of hazardous situations that could lead to harm.
This should also have already assessed their severity, as well as all of the causes and their likelihoods, and this documentation can be reused or repurposed. Severity should be reusable as-is, and if you use the normal P1, P2 method for risk scoring, it’s P2 that you need to state for your clinical risk likelihood - it's the likelihood that the hazardous situation leads to harm they want.
All of the design controls, other mitigations and resulting modified risk assessment are likely already in your risk management file, and these can be reused in the clinical file.
As well as what you have done to reduce risk, remember, the Trust is required to understand and document what they have to do to make sure it’s as safe as possible, to comply with DCB0160. You’ll need to call out everywhere that you’re passing on residual risk information to the user through IFU, other accompanying documents, commissioning processes, required staff training, maintenance and so on. Again, your risk file should have all of this, already.
The clinical safety case statement and report is really an extract from your risk management report - it summarises the processes you’ve followed, the activities you’ve completed, that you’ve reduced all risks, that the residual risks are acceptable and the clinical benefit outweighs the risk. It’s your Clinical Safety Officer (CSO) that owns and approves this particular report - see below for a word on this person.
Your PMS records should already contain all information necessary to compile a Clinical Incident Log, with some modified assessment and categorisation to identify Clinical Safety Incidents alongside identifying complaints and vigilance incidents - a minor tweak to your feedback handling process and the records, and it should be compliant.
The last word is on having a CSO - if you already have a clinical presence in your risk management team (and you should!), then so long as someone is suitably qualified (a professionally registered clinician), then they can take the NHS CSO course and act in this capacity. Many choose to contract this role out, and that’s also totally fine, and when doing so, why not take advantage of some extra clinical risk input into your process?
While DCB0129 isn’t perfect (I could write more, but that’s for another day), and there are other standards to comply with (DSPT, DTAC), I do think it’s there for the benefit of the NHS for non-medical device software, plugging the gap for software that can result in harm, but doesn’t qualify by the medical device definition. For the SaMD audience, you’ve already had to manage the risks and have (hopefully!) done a very good job of it, so this repackaging to help NHS Trusts comply with their own standards for maintaining clinical safety really isn’t too much of an ask - let’s make it easy for them to realise the benefit of new software with the minimum of effort on their part, not to mention make sure your engagement with them goes as smoothly as possible!
Putting this all together in accordance with the standard is not hard - If you want to know more, the NHS resources are decent and relatively pithy, and with these in hand, you should be able to get the detail right quite rapidly. The training the NHS provides for CSOs seems affordable and succinct, and there are other training providers out there. Charlton Regulatory are always ready to help people new to this understand how to implement clinical risk management processes and documentation, as well as with other NHS standards such as DSPT and DTAC. Please contact us if you’d like to know more.
Comments