Health professionals often complain about software and IT. It doesn’t always do what we want it to do. It slows us down, makes us do extra work.
A common problem is lack of interoperability. Computer systems are not talking to each other, a bit like Microsoft and Apple many years ago. Patients have also noticed that important information is not always available, which leads to inconvenience, delays and sometimes more tests.
At the same time GPs are unhappy that the hospital doesn’t provide essential info, for example when a patient has passed away, and hospital staff complain that referral letters don’t contain important triage information. Etc etc.
This raises the question, how ‘interoperable’ are health professionals? Do we know how we can best facilitate transfers and improve clinical handovers? What information do our colleagues need and when? How often do we meet to sort out issues in a collegial way?
It’s good to see there are passionate people working on these issues – but they need help. Computer systems are a reflection of the silos we work in. First fix human interoperability and our IT systems will follow.
In healthcare we’re often confronted with poor quality software. Bugs and security issues are common, and the design is usually not intuitive. I spoke to Frank (not his real name), an insider in the health IT industry. Frank gives us an interesting look behind the scene and seven strategies for developing or implementing new software.
“Any industry can be a target for poor software,” says Frank, “but healthcare certainly has its fair share. Believe it or not, medical software is unregulated. Medical software that runs on a computer, mobile phone or tablet does not fit the definition of a medical device in section 41BD of the Therapeutic Goods Act 1989, as they were not intended by the manufacturer to be used for therapeutic purposes.”
“How many software developers have clinical employees? Do these employees have input into design or are they there to sell the dream?
“There is a serious gap between software design and the real-world application. Often software developers do not fully understand what is actually required by the healthcare industry to support the services that they provide.”
“Far too often, developers over-promise and under-deliver. What software can do often does not live up the expectations of the customer. How many software developers have clinical employees? Do these employees have input into design or are they there to sell the dream?”
Causes of poor quality
Some argue that developers should test their product better before it can be used in patient care. Is this an issue?
Frank: “Quality must be incorporated into the entire software development life cycle, from inception through implementation and this is not always happening.”
“A lot of the actual coding occurs overseas, in countries like India, where the employment costs are much lower. Code may be written cheaply and quickly overseas but it isn’t necessarily quality code.”
“Testing is often an after thought and done quickly due to time constraints
“Testing is often an afterthought and done quickly due to time constraints. The most crucial functionality usually gets tested but bugs can still slip though.”
“On the other hand, sometimes the client is not specific about their requirements. This could be a result of not engaging the organisation to understand what requirements need to be met. How often are clinical and other front line staff asked what they need before software arrives?”
Talking about client requirements: Let’s look at the Australian national E-health records database, the PCEHR. The Government wants to use the data and eventually save money (even though so far they have wasted millions of dollars on the project). Consumers want full control of the data, and doctors need a reliable, safe, secure and easy-to-use tool. Is it possible to develop a national product that ticks all these boxes?
Frank: “Highly unlikely. There are too many competing interests and egos with those that have been involved. In the early days, NEHTA was an interesting organisation to observe. It was obvious that they didn’t understand the complexity of system interoperability or consumer expectations on how information is to be shared and stored.”
“Fear, uncertainty, and doubt also play a part in the slow uptake of the PCEHR
“The reality is that software used in healthcare is effectively a closed shop, and it’s difficult for different systems to be integrated. Once you’ve bought a solution from one vendor, it’s incredibly difficult – but not impossible – to walk away from it.”
“Also in recent years, there has been a seismic shift in patient expectations overseas and we’re starting to see the rise of patient advocates and patient hackers. These are savvy people who aren’t going to sit back and be a passenger in their personal health journey.”
“Fear, uncertainty, and doubt play a part in the slow uptake of the PCEHR. Some providers don’t want patients to be able to access reports on the PCEHR, others are concerned that patients may choose to make some information not sharable or viewable which may compromise care. I think the truth lies somewhere in between.”
7 tips to avoid fiascos
I asked Frank what doctors, healthcare managers and business owners can do to avoid disappointments. Here’s his list of 7 tips:
Be as clear as possible about your expectations and needs. Make sure you discuss the features you’re looking for and categorise them: absolutely essential, must have, good to have, nice to have, can live without. Ask how many features the software developer can provide in your first 3 categories.
Make sure that the software vendor understands your requirements. Get them to provide their understanding in writing so that you can see that they’ve understood.
Does the organisation hold certification for both ISO 9001 (Quality Management Systems) and ISO 27001 (Information Security Management) across all business units?
Find out where the software is being developed and supported from.
What is the quality like? Is it secure?
Don’t pay anything to a software developer before you are sure what you’ve been given is fit for purpose and what you asked for.
What contingencies are in place if the software fails to deliver as promised?
Healthcare around the world is plagued by software problems. To give just a few examples:
Issues with the Obamacare website caused user frustration, but also security breaches. Personal information was disseminated over the internet, affecting millions of people.
Closer to home, the Australian PCEHR has difficulties getting off the ground because of concerns at various levels. Major security problems with the Australian MyGov website – which also gives access to our eHealth records – were exposed by a researcher who was able to hack into the secure part of the website.
Queensland Health has an unfortunate track record of software problems, most recently with Metavision, an intensive care software package that created medication errors.
Why is the healthcare industry prone to these software debacles?
I caught up with Australian health IT experts to get some answers. In this post I’m talking to Sydney professor Enrico Coiera, who has extensive experience in the field of health informatics and bioinformatics. He’s got interesting things to say about eHealth, the PCEHR, and Telstra’s plans to enter the healthcare market.
What’s the cause of e-health fiascos?
Coiera: “Today in Australia there is still, inexplicably, no governance system for e-health safety. No one is looking at your GP desktop system to make sure patients will not be harmed through its use.”
“Yet, look at what has been achieved in the airline industry, and then compare their safety governance processes to those that we have in healthcare IT. A functional and effective governance system needs a rapid reporting arm, and a rapid response arm.”
“If something goes wrong it must be reported, and rapidly communicated back to all other users who might be experiencing the same issue, and then quickly repaired.”
“The other thing is of course that while we are fiddling and doing nothing, clinical software is getting more complex, with more functions and more opportunities for failure, and as a result, patient harm.”
“In the past, software failures weren’t always seen as a patient safety issue. IT glitches were regarded as annoying, perhaps time-wasting.”
“It’s only in the last decade that we’ve realised that unsafe IT makes for unsafe care. And now that we know that e-health is a patient safety issue, people are not putting up with it anymore. They do want to know that their clinical systems are safe.”
Man vs machine
I often wonder if software solutions are tested thoroughly enough before they are introduced in the clinical setting, but according to professor Coiera I’m underestimating human factors as a cause for errors:
“I’m not sure that improving software testing is the only challenge with e-health safety. Having said that, in Australia there are no requirements on testing for clinical systems, so we don’t know whether or not even this basic requirement is being met by software vendors.”
“My biggest criticism of the e-health industry is that their software is often not very innovative.
“Keep in mind that there is no such thing as a safe system: While about 50% of e-health incidents are primarily technical in origin, the other 50% of incidents are caused by a human factors, for example someone selecting the wrong medication or medication dose from a drop down menu.”
“This means that to have a safe system, both our software needs to be built to appropriate standard, but also that clinicians must be trained to be safe users of the technology. Implementations of software in clinical settings also need to be carried out with an eye to risk reduction.”
“My biggest criticism of the e-health industry is that their software is often not very innovative, and not designed with human factors in mind. It is hard to comprehend how unusable some clinical systems are, with too many clicks to achieve even simple tasks, and user interfaces simply adding in new functions and becoming complex over time, rather than focusing on clarity and simplicity in design.”
“This lack of innovation is probably a function of the size of the e-health market, and the ability of vendors to lock in customers by making it hard to move from their system to others. Innovation comes from true competition, as well as customers who reward innovation.”
How do we fix the PCEHR?
Many people are calling for a rethink of the PCEHR, saying that a massive data repository is not the answer.
Coiera: “There has never been a strong case to develop a centralised national record. The main issue with the PCEHR design is that its explicit clinical purpose has never been clear.”
“GPs should have access to hospital patient data, but that can happen by logging on directly to the hospital system.
“There are actually many compelling reasons to move data around the system, using more interoperable records and networks. GPs for example should have access to hospital patient data, but that can happen by logging on directly to the hospital system, not looking at some extract of the data in a central repository.”
“Wasn’t that the whole point of the Internet, for goodness sake? Data needs to be fluid, it should move around.”
Big business vs big government
Frustrated with the government’s PCEHR, some are hoping big business will solve the problems. Telstra has announced plans to get involved in telemedicine and e-health. The question is whether this will be an improvement, as Telstra has had its fair share of software malfunctions – including at least one security breach affecting one million BigPond customers. But Coiera is positive:
“We should welcome big companies, it’s good for us. The government’s job is to protect privacy and security through regulation and law. The government should stick to what it’s good at, and leave software development to industry. Government is used to being in charge and driving change top down, whereas businesses are usually better at listening to the client.”
“I think we will be seeing that government gets out-of-the-way in e-health, while still protecting the rights of citizens via law. With the arrival of industry should come competition and innovation. The companies that listen best to what we want as clinicians and consumers will win.”
Where are we at with the PCEHR? I asked four leaders in the field about their thoughts: Has it been a success or a failure? Can it still be improved and if so, how?
Dr Frank Jones, President of the Royal Australian College of General Practitioners: “The concept was always good, but it failed to engage with front line medical professionals and was hijacked by lawyers. I am also really unhappy with the government’s plan to upload results if not viewed by the requesting doctor after seven days – a disastrous situation!”
“The other thing that is never talked about and that people outside GP-land are unaware of, is that GPs can already access their practice patients’ notes, anywhere, anytime. GPs leading the way again – in many ways this has diminished the value of a PCEHR at a front line GP level.”
“Lets get the basics right first: Initially we need the information such as active relevant medical issues, allergies and OTD medications.”
In its present form a failure
Dr Brian Morton, Chair of the AMA Council of General Practice: “In its present form as a GP I would have to say it’s a failure. There is no recognition nor remuneration for GPs to spend the time to prepare and submit the data which must be done with the patient present. Professional clinical input to the design process has not been given the status needed to make PCEHR workable and relevant to medical practice.”
“Privacy and consumer political correctness have over-ridden safe principles of health care. The very poor uptake of the PCEHR is evidence of this. If we are to reap the benefits then recognition of the cost of data entry needs to be made.”
“Remove and prevent data which is not clinically relevant for care, for example Medicare billing data, as medical assumptions cannot be safely made based on a billing event. Identify clearly in the record that data has been removed or data hidden; the ability to over-ride the control of this is inadequate for safe care. Start the use of PCEHR with small and focused data entry such as active medical history.”
“Make a Medicare item number for the initial entry of data and an item for review yearly by the patient’s usual GP. Enable the functionality of automatic loading of diagnostic imaging & pathology data to the PCEHR when it is received and reviewed by the requesting provider. For example in our software: when it is transferred from inbox to patient record.”
A clear disaster
E-health blogger Dr David More says: “It is a clear disaster as it has failed to be utilised by, and successfully engage with, either clinicians or patients to any significant degree after what is over two years since initial implementation.”
“It should simply be abandoned and a new eHealth Strategy based on serving the needs of clinicians in information sharing and use developed. Patient engagement should be at the level of providing useful e-Health services to such as e-mail, repeats, referrals, results and record access via local practitioners.”
Dr David Glance, Director Centre for Software Practice, University of Western Australia: “I would say that the PCEHR is effectively dead – there is some interesting commentary here. The liberal government has not killed it but they haven’t supported it actively either. Nor have they put forward any other strategy. So given the financial climate we are in now, I don’t expect that to change.”
“I fundamentally believe that Australia has a basic structural issue when it comes to implementing central strategies around eHealth. We are still lagging in electronic record adoption in our hospitals and public health services and to a lesser extent within the specialist community. Until that changes, any shared electronic health record will always have gaps and be less than useful.”
“Clearly NEHTA needs to be disbanded and something else put in its place. It was self-serving, bureaucratic and pretty hopeless when it came down to it.”
“With regard to opt-in/opt-out, I would say that opt-out is always a better option with a far easier access mechanism than was implemented for the PCEHR. But given how awful the implementation was, the point was moot. Talking of the implementation, given what we know about user interface, you would have thought that the interface to the PCEHR could have been a lot better than it was.”