Human interoperability

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.

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


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?