I’ve read and heard a number of comments recently about health IT suppliers / manufacturers /deploying organisations wanting to cut corners and believing that the role of the Clinical Safety Officer is to simply sign off the documentation, forming part of a tick box exercise.
My experience of this is interesting. It is true that many organisations begin with this approach or attitude initially, and to an extent I can understand their frustration with confusing compliance requirements, many of which overlap: clinical safety, medical device, information governance, data security….
I always have a preliminary conversation with the potential client or organisation, explain how DCB0129/DCB0160 work, how they are different to, but complement the other elements mentioned above, how the approach taken when identifying hazards is quite different, and that above all, the ultimate aim and focus is on patient safety. Not the safety of the organisation, or its employees, or even its data, but the patients themselves (including, of course, their personal and clinical data, which if compromised becomes a clinical safety risk).
Most, if not all, of my clients complete their clinical safety journey saying that the process has been beneficial not only for the end result of obtaining compliance with the standards, but because they have had to review their organisation-wide quality management and risk management processes, think really carefully about the intended purpose, users and care setting into which they wish to deploy their product, identify all the areas where risk may be introduced or hazards may occur, which if left unmitigated, could result in patient harm. They need to define their risk appetite, put mitigation measures in place, and above all, provide evidence for these measures, be it design requirements, specific test evidence, usability studies, instructions for use, and updated processes and procedures.
Then comes along the big difference with the DCB 0129 standard – the health IT manufacturer is expected to share the output of their clinical safety review with the deploying health organisation and support them in the safe implementation of their product.
And it doesn’t stop there. The supplier must have documented clinical incident management procedures in place, including a safety incident log and a process for clinically assessing all reported incidents, defects and customer feedback. They are expected to keep their clinical risk management file up to date, perform audits and train their staff on the importance of clinical safety. So being a CSO for an organisation is so much more than signing a Clinical Safety Case Report.
All that said, I do believe that the work can be tailored to the organisation and to the potential level of risk associated with the product. Some health IT solutions, like an app to support wellbeing, are relatively simple and low risk, whilst a complex EPR system is clearly going to require much greater input to assure its clinical safety and integrity. Therefore, whilst the process can be completed fairly quicky in some circumstances, in others, much less so.
In a world of automation and artificial intelligence, clinical safety officers should be using their valuable skills and knowledge to focus on the detail, whilst if we can work more smartly with regard to the documentation, surely this is a win-win scenario for everyone – suppliers, health organisations, compliance platforms and above all, patients and citizens – the end users of the products.
Comments