When we extended our bungalow some years ago we added a lounge with an open fire.
The chimney was architect-designed. The fire-surround was elegant, and antique French. The grate was a Baxi: among the very best! The plans passed all the detailed building regulations.
But when we lit the fire, it smoked us out — every time.
It transpired that although each bit worked perfectly, the whole thing wasn’t connected up as it should have been.
There was a shapeless void in the middle of the chimney that everyone thought was someone else’s responsibility.
Without a linear flow of air throughout the entire structure, the chimney didn’t work properly. Once we shaped the void, it all worked fine.
This is a neat metaphor for NHS IT: although individual bits may work well, it’s not yet fully connected up. People haven’t recognised there’s a whole layer of work still to be done – and it’s not all IT…
Obstructions to information flow
Nationally, huge practical hurdles arise from consent and information governance issues — most notoriously in relation to acute invoice validation software.
Just reflect on the contortions that have resulted from the Section 251 problem (the bit of the Health and Social Care Act that stopped commissioners getting access to the patient identifiable information that they and their suppliers had previously used for administration and planning purposes, with the approval of the health secretary).
ASHs, DSCROs, Controlled Environments for Finance – the fallout has been immense, the costs large, the inconvenience huge. Fragmentation of the NHS and the purchaser-provider split have had the worst possible effect here.
In addition, users are also now wary of sharing information for purely clinical purposes, especially between different organisations and trusts – after all, a half-million-pound fine potentially awaits any individual who gets it really wrong.
The solution is simple, but the problem needs unpicking centrally. If the whole NHS and its sub-contracted healthcare work were to be considered as a single legal entity for IG purposes, at a stroke this would remove most of the practical problems – and, crucially, the inhibitions to sharing clinical information.
Mutual interference
It’s very easy for individual users of any interconnected IT system to interfere unintentionally with what another unit is doing.
Our local primary care trust (as it was then) encountered this some years ago when allied health professionals first started using joint primary care patient records.
They would put down diagnosis codes such as ‘diabetes’ instead of state-of-play (assessment) codes such as ‘diabetic on insulin’ – which promptly messed up practices’ QOF results. This was resolved by teaching AHPs about coding.
Moral: whatever software you employ, and at whatever level – primary care, secondary care, community – if it uses codes to store information, then you need actively to teach their proper use to all users.
As a completely separate matter, consider ‘patient led sharing’ – a splendid way to record consent and then automatically share access to records on the basis of the chosen permissions.
The program itself works well: the difficulty lies outside the IT. Firstly, there’s no national legal agreement on the mechanics of recording patient consent: is verbal consent adequate, or should the patient’s signature be scanned into the record?
As a result, each NHS organisation has invented its own mechanism — and they all seem to be different. Secondly, there is as yet no national agreement on how to set organisational permissions within patient led sharing.
IG and IT committees in different providers may insist on wildly differing settings, and teach its use in different ways — and it now looks as though some of these may inadvertently mess up other units’ consenting arrangements. Locally, this situation is progressively being addressed: site tuition will be key.
Understanding how to use the IT
Users often have a poor understanding of how to utilise their IT to solve clinical problems. Help files may be excellent, but mostly these answer questions about detail, such as: "What happens if I click on this button?"
Crucially, help files frequently don’t tell users how to utilise the program as a whole to organise their day-to-day work.
Indeed, whenever I teach healthcare staff to use their IT, I seem inevitably to end up writing them a booklet called ‘A short friendly guide to (whatever the name of the program is)’ in order to correct this.
In future, help files for all NHS applications need to have two parts: as now, detailed information about check boxes and tabs; but, in addition, a complete section on how to use the application as a whole within the structure of the NHS. This may be something for the Health and Social Care Information Centre to oversee.
‘P’ soup
Currently there’s often no easy relationship between the IT and existing or continuing NHS structures and procedures: in other words, the IT hasn’t truly been integrated with the paperwork and the processes.
What the user really wants
Finally, there can often be limited appreciation of what the user actually needs – usually not so much within individual programs, but in relation to wider issues. Again, this isn’t application-specific.
I’m a GP. When the patient’s with me I want to see:
- Data from my own practice
- Data from other units at same level (out-of-hours, ambulance information) – and to acquire this transparently; preferably without even realising that I’m now looking at information on another provider’s system
- I also want to see data from secondary care on this patient – without having to log-in separately, or remember a password that I may last have used five months ago.
Nor do I just want a summary: I may need details of what happened during an admission.
But my need for information doesn’t just relate to patient data. I’d also like immediate access to:
- Approved, up to date generic medical data. For example, what’s the latest way to diagnose coeliac disease? I haven’t seen a new case for seven years: can I be sure that my current method of investigation is up to date?
- Legal data, regulations, incentive schemes, local recommendations and information about my unit’s performance.
Finally, as most clinicians really want to do healthcare, not IT, all this must be pre-organised, and easily accessible by IT novices.
Removing the smoke-filled void
- Integrating IT across the entire NHS is an order of magnitude more complex than previously believed, and – somewhat counterintuitively – the problems are often non-programmatic.
- The responsibility for filling gaps, voids and joins shouldn’t lie with individual software providers as much as with HSCIC, which may need to maintain an active overview of the situation as a whole.
- At the very least we need an ultra-smooth primary-secondary care interface (in both directions).
- Clinicians also need easy access to ‘general medical’, legal and management information.
- It isn’t sufficient to test each component of the system intensively. Like my chimney, it’s the throughput of the whole system that matters most.
Dr John Lockley
Dr John Lockley is clinical lead for informatics at Bedfordshire Clinical Commissioning Group and a part-time GP.