A popular truism, when giving guidance, is to "keep it simple, stupid" – or KISS. But should we? Can something always be simple?
My personal approach is different. The right answer is sometimes simple, sometimes complex; but almost always elegant. Above all, the right answer is the right answer.
Proof perfect
Listening to a podcast of Radio 4's ‘Infinite monkey cage’ gave me an interesting perspective on this issue. A mathematician was discussing what had drawn him in to mathematics.
It had nothing to do with a love of numbers per se; instead he was attracted by the search for beautiful proofs for problems. Think of Fermat's Last Theorem.
Fermat was a brilliant mathematician who famously left a series of conjectures that he said were true, but didn't always bother to prove himself. All but one of these conjectures had been proven over the subsequent centuries, so the last one remaining was ‘Fermat's last theorem’.
When he wrote the conjecture, Fermat stated that he could prove it but "the margin wasn't big enough for the proof.” Many tried and failed to prove his conjecture, until eventually a British mathematician solved it in 1995.
The proof ran to 108 pages, and utilised a number of areas of mathematics that weren't discovered until decades or centuries after Fermat's death. That proof is brilliant, but it is far from simple.
Not everything in life is simple, and healthcare is no exception. It takes five years to qualify as a doctor, and then of the order of ten years to train as a specialist. I am somewhat perplexed when people expect healthcare IT systems to be simple.
I hate Apple
Actually I don't – I think the company is fantastic at what it does and I love my iPad. However, Apple does a particular thing – it creates products with fantastic design and excellent functionality. It also spends a lot of time getting a product right, and then reaps the benefits for years.
My problem is that people expect healthcare IT to conform to "Apple-like" ease of use, and the tasks that we are tackling often don't conform to delivery without a degree of complexity.
At Liverpool Heart and Chest Hospital, we have decided to take a pause in our electronic patient record optimisation to really push training with our end users.
The system that we have is complete and functional, if un-optimised. However, the value it delivers is dependent on people using it to its capabilities.
We may have moved from a metaphorical horse and cart to a fuel efficient hybrid car; but if people try to hook up the horse to drag the car around, we aren't going to see many benefits.
Leaving the car in the garage and continuing to use the horse and cart is even worse – we have invested in our car and need to use it. The road tax and other maintenance costs still need to be paid.
Some people might see the pause in development as a failure, but I don't. We are going to see far more benefit from the adoption of what is already there – but not being used – than we would see from the time we are going to take getting it adopted being devoted to development of more features.
After all, if we just push on with development then we will be adding features to the system that staff would add to the list of features that they don't know how to use.
One source of truth
Not everything has paused. We have continued working on a few critically important projects. Our users might need training, but CQUINN targets still need to be met.
Also, we have to meet a new national audit dataset requirement, and the exciting thing about this is that it has allowed us to build the new process entirely within EPR.
One of my personal mantras is that there is no such thing as audit data or corporate reporting data – there is only data. That data, if collected properly, can be used for a multitude of purposes.
In healthcare, its primary purpose will always be to facilitate the highest possible standard of clinical care, but the same data should be used to feed clinical decision support (further enhancing care quality), clinical audit and corporate reporting.
What we are doing in both the QUINN work and in the national audit work is making the data source for the secondary purpose come from structured elements of the EPR.
Using the system
In a well designed EPR, all data has a home, but the user needs to know where that home is. Medical staff record their patient encounters predominantly as documents, but nursing colleagues work in flow sheets.
Past medical history can be documented as free text or via check-box responses on forms; but if you record it in the problem list then it carries forward for all future patient encounters.
Similarly, if medications are documented in the appropriate module then they are carried forward in the system and are also available to be analysed using the e-prescribing clinical decision support engine. And this can be used to facilitate the prescribing of inpatient medications.
Is this simple stuff? No, or at least not at first. Once you understand the design intent, it becomes intuitive, powerful and elegant. To quote the mathematician, it could even be described as beautiful.
Dr Johan Waktare
Dr Johan Waktare is a consultant cardiac electrophysiologist at Liverpool Heart and Chest Hospital, specialising in interventional procedures for heart rhythm disorders. He is the clinical lead on the trust’s electronic patient record project, as well as being a clinical lead for IT and the trust’s Caldicott Guardian.
A self-confessed IT geek, Dr Waktare has always been interested in computer hardware and software. His status was cemented when, several years ago, the IT helpdesk agreed to replace a user’s PC rather than look at it – after hearing that he had failed to repair it.