In our series of blog articles about potential revisions to the DCB 0129/0160 standards, we turn in this post to a couple of the definitions.
Now let’s face it, how many of us actually read the definitions in standards? Personally, I always start out with a well-meaning plan to read them all but half-a-dozen in, I tend to throw in the towel and skip to the substance. But it turns out, they are important – especially when it comes to precision. And there are a couple of definitions that always irk me. Let’s start with that for a ‘Health IT System’.
The titles of the DCB 0129 and 0160 standards contain the term ‘Health IT Systems’
Clinical Risk Management: its Application in the Manufacture/Deployment and Use of Health IT Systems
Thus it is the definition of ‘Health IT System’ which will subsequently govern the whole applicability of the two standards – hence it’s a thoroughly fundamental concept.
So let’s consider the current definition:
Health IT System: “Product used to provide electronic information for health or social care purposes. The product may be hardware, software or a combination.”
At first sight, this seems a reasonable definition, but on closer inspection it reveals a few oddities.
Firstly, there are a whole host of products which meet this definition but, according to NHS England’s guidance, would not require DCB 0129/0160. For example, an ultrasound machine or a vital signs monitor would meet this criterion perfectly, yet they do not need to comply. What these products have in common is that the software is embedded within a physical medical device and, in these circumstances, DCB 0129/0160 would not apply - according to NHS England’s guidance.
Similarly, there is another group of software products which provide health information in relation to populations or anonymous cohorts of patients. For example, a system which generates statistics with regards the local prevalence of diabetes for the purposes of research or informing health planning at a local or national level. Whilst such systems meet the current definition of a Health IT System, they fall out of scope of DCB 0129/0160.
Secondly, “The product may be hardware, software or a combination”. One route through this logic suggests that a Health IT System could be manifest as hardware alone, i.e. in the vacuum of software. Really? Would a server or a laptop realistically fall in scope of the standards and therefore require an assessment? To me, a Health IT System fundamentally consists of software. Of course, this software is supported by the hardware on which it executes and indeed, that hardware might contribute its own failure modes. But I doubt that hardware qualifies as a Health IT System in its own right.
So what should be done? Clearly, no definition of Health IT System is going to be perfect, and a degree of interpretation and clarification is always going to be required. However, I propose my own definition below based on our experience at Safehand:
“Software product, executing on a conventional computing platform, used to provide electronic information to directly support the care of individual patients.”
Let’s turn now to another definition, that of the ‘Hazard Log’. In DCB 0129 and 0160 this is defined as:
“A mechanism for recording and communicating the on-going identification and resolution of hazards associated with a Health IT System.”
In this case, it’s just one particular word which I, and indeed many others, find misleading – ‘resolution’.
If we’re at all confused by the term ‘resolution’ let’s consult the standards for a definition. Well it turns out that that the term resolution/resolve are only used a couple of times elsewhere in the standard and these are both in relation to incident logs rather than hazard logs. Now it’s not just pedantry going on here, the term ‘resolution’ implies a solution or fix – a notion that our goal is to make hazards go away so that they are no longer a thing. Yet, in the majority of cases, that's simply not realistic.
Let’s take the following example. Suppose we take an Electronic Patient Record, there exists a hazard that the system could become unavailable such that it can no longer support clinical care. Whilst ever that system exists, such a hazard will always be present. One would hope that a combination of architectural resilience and business continuity measures might mitigate the risk but I’m not sure that I’d have the confidence to deem it ‘resolved’ to the extent that the problem had now been solved.
Surely this is just a matter of semantics? – No, not so. There are many practitioners who grapple with the differences between hazard logs, incident logs, bug lists, project risk/issue logs and backlogs. For some of these, the notion of ‘resolution’ is indeed a goal whilst, for others, less so.
For me, I wonder whether what the author of this definition really meant was ‘mitigation’. In which case, I’d argue the definition works perfectly.
So there’s a couple of definitions for us, as a community, to consider. As always, we’d be keen to get your thoughts.