I heard the blindingly obvious statement at the recent Intellect stream of BCS HC2013 Conference in Birmingham that “If you give people software that makes their life easier then adoption is not a problem” Given the clear truth of this statement, I wonder why so many “designing” and procuring NHS IT Systems manage to deliver systems that make life more difficult for frontline staff undermining the quality and service they are able to offer patients.

If we are to get the benefits proposed by those promoting a paperless NHS this has to end and we have to introduce a regime of Zero-Tolerance for systems that make life more difficult for frontline staff.

How do we do this? I have some suggestions:

• Transparency – Let’s encourage NHS Staff to name and shame systems that make their life more difficult, with reviews and rankings published with maybe some new categories in the EHI Awards for good design and something akin to the “Golden Bull Awards” for the worst examples. Let’s be honest, when the Emperor has no clothes, too often I hear positive comments about NHS IT systems in front of senior management which evaporate when you talk to frontline staff in private. Both sides are to blame here, management can’t be expected to recognise the problem when they are continually told that the “heap of crap” they ask staff to use is “powerful fertiliser” and senior managers need to reward those who bring them bad news.

The work of Psychiatrist Dr Joe McDonald, who is one of the most insightful observers of UK Health IT, with www.comparethesoftware.co.uk could provide a good start as could ideas from NHS Hack Day about a broader NHS Bugs reporting system.

• Participation – We need to engage in agile user centred design that allows developers to truly understand and deliver against frontline end-user needs. This means embedding domain experts and end-users and their customers/patients in development teams through the entire product life-cycle (but not for so long that they “go native”) and careful testing of software in real situations with realistic data.

We also need to involve frontline staff in procurement decisions, but not in the tokenistic way that often happens, at the very least they need a veto and ideally it should be they not IT departments or senior management making the final choice.

• Design – Design, design and more design. Good design ensures form-fit-for-function and should create software that is lusciously desirable, highly functional and which adapts to and remembers users’ needs and preferences. Design needs to be all pervasive. Software code should be finely wrought, poetically beautiful and lovingly commented adhering to clear and consistent coding standards. Workflows should careful designed to provide efficient process flows and be capable of adapting to real-world variation in process. Information presentation should apply the science of information design and excellent graphic design. User-interface design should similarly apply both science and art, to create interfaces that are beautiful, intuitive, accessible and safe. Good design requires input in the development process from technical, creative and human-factors designers. There is a wealth of literature and experience to help system designers if they just go and look for it.

• End the dataset mentality – Except in exceptional circumstances only the information that is necessary and appropriate to the delivery of optimal care of the individual patient should be collected. This includes information to support both clinical and supporting business processes and the measurement of outcomes, but not data for purposes which can’t directly contribute to good outcomes for the individual patient. This information varies from patient to patient and encounter to encounter and can’t be useful expressed as a mandatory minimum data set. Data sets are never minimal but inevitably fail to include information that will be critical in some cases. The quality of data collected under duress which has no value to those collecting it, will be poor as users will guess it or make it up if it is not immediately to hand making it worse than useless for the purposes for which it was included in the dataset in the first place. Users have a natural investment in quality of data that affects the ease with which they can do a good job and typically such data is information rich and secondary uses can in general be better satisfied by using only such data. However, in exceptional cases where there is a strong downstream benefit from the collection of additional data this need must be “sold” to users who should also be provided with regular feedback that demonstrates that efforts are worthwhile.

While there is massive potential in using data collected routinely for secondary purposes, those doing so must always be aware of the risks of using data for purposes other than those for which it was collected. If those entering data don’t know about the other ways data they are entering will be used they can’t help ensure that it is also fit for these purposes. I would not go as far as the eponymous Dutch health informatician who coined Van de Lei’s law, “Data should not be used other than for the purposes for which it was collected”. However, it is important to understand the many data quality issues associated with health data  and the risks of using data beyond the “Hawking Horizon”

One way of mitigating these risks is to inform those who collect data how it will be used and to feed back to them the results of its use. This will not only encourage them to consider how they can make fit for these secondary purposes, but will also mean you are more likely to be alerted when you draw conclusion that those close to the data know they do not support.

• Finally of course Zero Tolerance – Zero tolerance for systems that make life harder for frontline staff, zero tolerance for those who fail to involve frontline users in design and procurement decisions and zero tolerance for the dataset mentality and most of all zero tolerance for poor design.