In conversation with… Dr Malcolm Phillips.

Welcome back to the ICU Heart blog. This month, we met with Dr Malcolm Phillips, Head of Medical Equipment Management for NHS Lothian, to discuss with him the early considerations required for algorithm implementation. This part of our work looks to use patients’ electronic health record and physiological waveforms (such as ECGs) to identify patients in near real-time who are at high risk of heart attacks during their ICU stay. This could enable clinicians to put in place treatments that would reduce this risk at the right time, for the right patient.

Malcolm’s background:

Malcolm has a first degree in Electrical and Electronic Engineering and a PhD in Physiological Measurement from the University of Kent, and has many years’ experience in ensuring the reliability and robustness of new medical devices. He leads the Medical Physics team, who are responsible for the management, safety and governance of most of the medical devices in general clinical use within NHS Lothian. His role also includes reviewing and approving prototype and other novel devices used for research purposes. He provides advice to the Scottish Government on the governance of medical devices, their safety, and future trends. We are excited to work with him throughout the programme to ensure our algorithm and software are developed to a high standard, in accordance with best practice and international standards and can be depended-on to produce timely and clinically useful information.

Malcolm’s involvement with ICU Heart:

It is really important to think about the regulation and governance of our software while it is in development, not just at the point of implementation and maintenance, and Malcolm has offered to advise and engage with us throughout this process. This blog serves as an opportunity to document what we have learned from Malcolm at the beginning of our algorithm development in order to create a risk prediction model that is as robust as possible, and results in better outcomes for patients.

In his experience, Malcolm has found that there is often a disconnect between researchers and regulators about what should be considered, why, and at what stage. He feels that researchers can sometimes approach regulatory compliance as an overly burdensome requirement because the research phase of use feels a long way removed from real-world use, before implementation becomes a realistic goal. However, all those working within the medical field, be that clinically or in research, have a duty of care to patients to prevent potential harm that may occur as a consequence of any faults or bugs that arise within these new initiatives. Devices, like ours, that are software developments don’t have direct physical elements that may cause injury or harm. However, software may provide incorrect information to support clinical decisions that are therefore misinformed, potentially negatively impacting patients through misdiagnosis, delays to treatments, and in the context of critical care, life-threatening adverse events. These can result from occurrences such as unintended biases, classification or prediction errors, algorithmic errors or functional failures. Medical device regulators, as well as clinicians, patients, and managers must have the confidence that the information produced and delivered via the new software is safe, robust, and reliable.

There are a few elements that come into play when looking at the dependability of software. The first is failure path analysis: the ability of the development team to ask themselves what could go wrong, what happens when it does, and what are the hazards? Teams must work systematically to model all possibilities that could potentially cause failures. From his extensive experience with medical device governance, Malcolm is aware that there is a high likelihood of all code having bugs, which could affect the function of the software, even with our best efforts to avoid this. Ensuring we can reduce these, while acknowledging the risks associated with them and the likelihood of them occurring, is an important part of algorithm development and considerations for regulation. The second element follows on from this. Using unit testing to make sure that there are specifically designed tests running in and around the written code that can track and detect when bugs occur, and that the code is therefore performing its intended purpose, is essential. A part of this is having a specific, methodically written development process to ensure that what is being written is what was intended and ultimately developed, and that the code is able to be tested and traced by auditors or approvers like Malcolm to ensure these occurrences are kept to a minimum. International and national coding standards help to do this.

There is a third, crucial element. Even if the written code is perfect, tested, and bugs have been kept to an absolute minimum, there must be a way to inform the end users, in our case critical care staff, if and when something goes wrong with the code or the platform the software is hosted on. If this is not developed as part of the software, there is a risk that clinical decisions could be made based on potentially out-of-date data, or for the wrong patient, that could have significant consequences within an ICU environment.

How will what we have learnt impact and improve the ICU Heart project?

The conversation with Malcolm was helpful for everyone involved, and it is clear that his advice on regulation and governance will be invaluable throughout the development of our risk prediction model. There are a few elements of the conversation that resonated particularly with our data analysts, Craig, Rosalyn, and Ian.

Abiding by good standard coding practices and having a detailed process outline has been integral in the initial planning and research stages of our model development. Despite the clear benefits, blanket application of the “production code” approach to everything we do would slow down the development substantially. Instead, we need to be able to try different approaches with relative agility in the research and development phase, but plan and take steps to move towards a fully comprehensive approach when we determine an element is likely to be part of the final output. A key part of this is identifying early on when parts of the pipeline have a high chance of being used at the data-care interface with patients at the end point. For these parts especially, robust development is critical. Some techniques to do this have been discussed by the team, such as unit testing and failure path analysis, both of which were described above. Using these will improve our awareness of any potential issues, and help to catch them at a stage where we are able to implement changes or mitigations.

Malcolm’s insights into the early considerations we as a team need to be making for algorithm development were beneficial and provide a solid foundation for reflections and planning to ensure our work has robust and reliable roots for ongoing development. We have welcomed Malcolm into our group and the team is grateful for his advice. We are looking forward to collaborating with him throughout the ICU-Heart programme.