We know that Health IT systems can introduce risk into the clinical environment. UK Safety Standards ISB 0129 and 0160 call for suppliers of Health IT systems and their implementing healthcare organisations to undertake Clinical Risk Management activities to manage that risk. In particular the Standards require organisations to nominate a Clinical Safety Officer (CSO), a named individual who is “… responsible for ensuring the safety of a Health IT System in that organisation through the application of clinical risk management.”
The Standard requires the CSO to be an experienced clinician, have a current registration with a professional body and be trained in Clinical Risk Management. But who would want to take on such a mammoth responsibility?
The causes of adverse incidents involving Health IT are nearly always multifactorial. There are many contributing elements which the CSO has little or no influence or authority over and yet we ask of them to put their professional standing on the line. What’s more, if we accept that risk can never be eliminated then surely it is purely a matter of time before a Health IT related incident occurs. Is the role of CSO not a poisoned chalice? Is the CSO merely a scapegoat for more fundamental organisational failings?
For a moment let’s take a step back and look at what the Standards really require of the CSO. We can quickly see that their responsibilities are primarily to ensure that process is followed, that they are included in the multi-disciplinary group undertaking the safety analysis and that they sign off appropriate documentation. In other words, the CSO needs to ensure that Clinical Risk Management activities occur and that the conclusions which are drawn are complete, evidence-based and objective. The CSO is then in a position to make a recommendation (not necessarily a decision) to Top Management.
The Standards’ definition of a CSO carefully uses the term ‘responsible’ rather than ‘accountable’. He/she is expected to drive the risk analysis, to demand a level of analytical rigour and to justify the reasons for claiming that hazards have or have not been appropriately mitigated. But when it comes to being personally accountable for each line of system code, every implementation decision and user interaction, this is a burden that no reasonable person could expect the CSO to shoulder.
The Standards stop short of defining who is accountable for safety in an organisation but the numerous references to Top Management clearly sets an expectation that it lives at this level and not with the CSO. Once this is understood, the burden of acting in the capacity of CSO certainly feels more in line with their real-world authority. Organisations therefore need to ensure that they observe and understand the expectations of the CSO as set out in ISB 0129 and ISB 0160 and provide support for the individual accordingly.
Being a CSO is a fascinating and intellectually rewarding role – yes it comes with responsibilities but ones which are reasonable and realistic. Far from being a poisoned chalice, clinicians should embrace the challenge and relish the opportunity to be involved in the next generation of innovative and safe Health IT.