Do long-standing Digital Health products require assurance under SCCI 0160?
Home / Blog / Do long-standing Digital Health products require assurance under SCCI 0160?
24 July 2017, by , in Blog, No comments

Most digital health manufacturers and healthcare organisations now realise that SCCI 0129 and SCCI 0160 are important and here to stay. It’s simply inappropriate (some would say reckless) to implement new health IT systems without conducting the clinical risk assessment which these standards mandate. But what about existing systems – those long-standing and trusted solutions that have been supporting a Trust for years?

NHS Digital who govern the two standards are quite clear on the matter; the requirements are exactly the same. It doesn’t matter whether you are creating a brand new innovative TeleHealth solution or supporting an aging ten-year-old PAS. Both need to be safe – as a patient, why would one want it to be any other way?

For healthcare organisations who may have dozens of existing systems, assuring them all poses a very practical problem. For some Trusts, the challenge is simply too great and much of the existing infrastructure simply remains unassessed. Unfortunately burying one’s head in the sand is not a strategic approach to clinical risk management and this can be hard to justify when things goes wrong.

But maybe there’s light at the end of the tunnel for Clinical Safety Officers. The SCCI 0129 and 0160 standards tell us that the effort involved in assuring a health IT system should be commensurate with the level of risk which that system presents. In other words, lower risk systems simply don’t warrant the same level of assurance rigour as those which are higher risk.

Many of a Trust’s existing systems are tried and tested. Users are familiar with the local configuration, workflows are well-defined, bugs have been fixed and those inevitable quirks and workarounds are all well understood. Safety engineers often use the term ‘proven in use’ to suggest that a system’s characteristics are sufficiently well understood that further assurance is likely to yield little helpful information. A documented Hazard Log and Safety Case should ideally still be in place. But if this is a purely bureaucratic exercise it might be reasonable to conclude that risk reduction efforts might better be spent elsewhere.

That sounds like a case for leaving these systems well alone and avoiding clinical risk management all together – but that’s not the full story. Digital health systems and the environment in which they are operated rarely stay the same for long. There are safety aspects of all clinical systems which warrant careful on-going thought and analysis:

  • Rarely used functionality – Powerful functions which are rarely used but critical to safety may be largely untested. These latent hazards can remain dormant for years until the functions are suddenly relied upon for some critical purpose.
  • Disaster recovery – DR plans for those systems which rarely fail often become forgotten, obsolete and ineffective. When a crisis does occur the out of date procedures often take staff by surprise.
  • Configuration changes – Safety-related changes in configuration can cause the proverbial spanner to be thrown into the workings of an otherwise reliable system. For this reason, SCCI 0129/0160 require continual assessment of change.
  • Other changes – Change isn’t just limited to configuration. Most suppliers issue new versions of their products. Operating systems, browsers, hardware and databases are inevitably upgraded and these changes can have deleterious effects on established technology.
  • Incident reporting – Users of any system, however well-established, may report safety-critical bugs and issues which can sometimes go ignored for established systems. Just because everyone has lived with a safety-related issue for years doesn’t make it safe, especially for new staff.
  • Integration – Interfacing or combining digital health products brings a whole new set of hazards which are often unrelated to the characteristics of the un-integrated product.

Focusing in on these areas however doesn’t mean we have the right to be unsystematic or slap-dash in our approach. The analysis still needs to be methodical and the outcome documented.

For proven-in-use systems, whilst a full-blown SCCI 0160 assessment simply might not be practical with limited resources, doing nothing cannot be justified either. By anticipating the potential threats to the safety position, we can concentrate our efforts on those areas. In this way, we maximise the safety returns for the least effort expended.

Dr Adrian Stavert-Dobson is the Managing Partner of Safehand, independent consultants in clinical risk management, and the author of Health Information Systems: Managing Clinical Risk.

About author:

Leave a Reply