7 simple strategies to avoid eHealth fiascos

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?”

The PCEHR 

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:

  1. 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.
  2. 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.
  3. Does the organisation hold certification for both ISO 9001 (Quality Management Systems) and ISO 27001 (Information Security Management) across all business units?
  4. Find out where the software is being developed and supported from.
  5. What is the quality like? Is it secure?
  6. 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.
  7. What contingencies are in place if the software fails to deliver as promised?

Software glitches: Are you keeping your head cool?

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?

Professor Enrico Coiera
Professor Enrico Coiera: “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.” Image: Twitter

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.”