Skip to content
What a good Clinical Safety Officer (CSO) brings to digital health tech solutions
One of the main aspirations when introducing technology into healthcare processes is to improve clinical safety and patient outcomes. Whether that is something as simple as providing secure messaging between patient and clinician to improve access, to sophisticated artificial intelligence-powered algorithms that aid the diagnostic process in picking up issues that may have otherwise been missed. Introducing new technology, however, usually requires changes to existing workflows and ways of doing things that may have been established and honed over many years. When introducing your new system into this mix, consideration has to be given to what could go wrong in the effort to reduce existing risks and what new risks are potentially being added? This is where the practice of clinical risk analysis comes in.
Clinical Risk Analysis – DCB0129 & DCB0160
Clinical risk analysis should be a vital part of the software development lifecycle for healthcare IT systems in the same way one would consider software quality, performance and security. In the UK, this is enshrined in law under the Health and Social Care Act 2012. The Act mandates compliance with two standards which are published by the Data Control Board – DCB1029 and DCB0160. DCB0129 sets the clinical risk management requirements for manufacturers of health IT systems. It defines the processes you must have in place to ensure that released software is clinically safe and the set of documentation that must be maintained and kept updated with each release. It mandates that a named Clinical Safety Officer is in post with the responsibility of ensuring that processes are followed. The CSO is responsible for signing off on the clinical safety of each release. This individual must be an experienced clinician knowledgeable in risk management in clinical domains. DCB0160 is a very similar document looking at clinical risk from the perspective of healthcare organisations that are deploying the software.
The standards are actually fairly well written and clear. NHS Digital offers training on these for CSOs and others wishing to learn more, which are well worth attending. These are usually face-to-face but have been moved online during COVID.
It is important to ensure that this does not become a ‘tick box exercise’ with a remote CSO being fed information on software changes and rubber-stamping the new versions of safety documentation prior to every release. Clinical safety should form an integral and integrated part of the software development lifecycle. It is important that this is a multidisciplinary effort as different parts of the organisation will have a part to play. For example, design decisions made early in the development process can have safety consequences that are expensive to undo later; complaints received by your support desk may indicate an underlying unidentified hazard; discussions had with customers by your success team may reveal unintended use of the software which introduces unexpected risk.
One way to ensure multidisciplinary ownership is to set up a clinical risk team which should be headed by the CSO. This team should consist of senior representatives from development, product, success, QA, customer support, R&D, etc. – as appropriate for the structure of your company. Each of these would be responsible for any aspect of the process e.g. the customer support lead ensures that all potential incidents are brought to the group for discussion, the product ensures that clinical safety is considered early in the design of a new feature, etc. The responsibility of the CSO is to ensure that there is sufficient training and documentation of the process so that everyone knows and fulfills their responsibilities. This is confirmed by periodic audits of the process.
Despite the documentation and NHS Digital training provided, a common confusion for implementing organisations is how to translate the requirements into a process that actually works within their context. It’s fine knowing what the outputs of the process need to be, but at a practical level how do you actually achieve that? This can particularly be true in an agile working environment. The documentation does seem to assume a more ‘waterfall’ approach with distinct stages of software development and clean progression from one to the next – design, implementation, QA, release. However, most modern companies will work in a much more dynamic manner with frequent software releases, small iterations of functionality, releasing just enough for the current use case with planned subsequent improvements. The clinical safety process must be adapted to support this. Even if you are releasing every week it is still absolutely essential that every change has gone through the risk analysis process and the clinical safety of each release is signed off. This can only work if the clinical safety process is also agile. In my experience, this works best if the clinical safety steps run in cadence with the release cycle and that the clinical safety team has a detailed overview of the content of each sprint. This ensures that nothing is missed, clinical safety discussions can happen early and there are no surprises when it comes to release time.
Here at 8foldgovernance, our clinical safety team consists of clinicians who have hands-on experience of software development and product management in agile environments. We have helped organizations create clinical safety processes which are customized for them, integrated into their development practices, and more importantly, ensuring that clinical safety thinking is inculcated throughout the organization. Whether you are starting from scratch with this or just need some advice we can help. From just providing advice to get you started, to working with you to set up a clinical risk management processes and getting the initial set of documentation in place, to managing the ongoing process providing an appropriately experienced and qualified clinical safety officer for your team, we’re happy to help.
Do you meet the statutory requirements under DCB0129?
To you ensure that clinical safety is a core practice for your organisation and that the statutory requirements for health IT in the UK (DCB0129) are met, contact us for a no-obligation call. We’ll help you to understand what your obligations are and also what needs to be done to ensure that you are compliant with the mandatory requirements.
