Creating safer software for designers and users

The gulf between software application designers and end users is nowhere more apparent than in health IT, where systems can have an effect on life or death.

A case study of an actual death that came about in part due to a breakdown in communication between software designers and clinicians will be used as part of a one-day workshop being held in Melbourne, Brisbane and Perth next month.

Led by well-known health data standards expert Grahame Grieve and prepared in association with the Medical Software Industry Association's (MSIA) eHealth industry clinical safety and security committee, the workshops are aimed at anyone who makes decisions about applications that manage healthcare processes or data.

Mr Grieve said the case study that participants will work through to illustrate how essential clinical safety considerations are in application design involves a situation in which the system handled planned work in a way that made sense from a programmer's point of view, but not from a doctor's.

“The doctors got the impression that some work was due to be done and they were waiting for it to happen, and the patient died while they were waiting,” Mr Grieve said. “The work had been rejected internally because it has already been done, but it wasn't visible to the doctors because of some other privacy access rules which had recently changed.

“There was a whole cascade of things, all of them related to the way the software worked but none of them were bugs. But the cumulative response was a patient died and while it was not caused by the IT, it contributed to the bad culture.”

Mr Grieve said poor understanding of clinical safety among software developers was not simply a matter of education and training, but a combination of a number of elements.

“There is a huge gulf between the application developer and the user,” he said. “The users have so much specialised knowledge and the developers only pick it up slowly. If you are developing a game or home financial software, the developer is a potential customer, whereas in healthcare software they are not.

“It is the same in a lot of these domains where there is a huge amount of education to get in the door. The only people who can really develop reliably are the people who know how to do it and generally there is just not enough of them.”

Mr Grieve said one major issue facing clinical software safety was purely economic. Vendors can design systems with a high degree of consideration for safety built in, but if that system is more expensive than a rival's with a lower safety profile, the cheaper option almost always wins out.

“One of the problems is that the end users don't want to pay for safety,” he said.

Clinical safety in software development is an ongoing debate in Australia, particularly for those concerned that we will follow the lead of the US in mandating safety features.

The US FDA has declared that certain pieces of medical software have to be authorised, which is a long and tedious process for vendors and has added financial costs for the consumers at the other end.

“That industry is now frozen in place, running on fixed processes that can't be improved because the FDA has to approve the change,” Mr Grieve said. “There is a fair bit of worry that the Australian government will follow certain elements of that, which is why the MSIA has a clinical safety committee and these workshops are part of that movement.”

Based on an inaugural workshop held last November in Sydney, the new workshops will be held in Melbourne on March 11, Brisbane on March 13 and Perth on March 18.

In addition to the workshops, Mr Grieve has just seen his Fast Healthcare Interoperability Resources (FHIR) standards framework be released as a draft standard for trial use (DSTU) or beta version.

FHIR has been developed to make standards and implementation as simple as possible and to allow vendors to make interoperability cheaper and easier, Mr Grieve said.

FHIR's resources are tailored to be used with a RESTful interface, a design model for developing web APIs that is used by Facebook and Google.

The DSTU means interested parties can now start using it as a candidate or normative standard for the next two years, although it may be subject to change.

“That's a risk that you take but we would like you to try it,” Mr Grieve said. “Quite often a DSTU sits there and not many people use it because those are the rules, but that's not going to be the case with FHIR. It is going to be used all over the place because its advantages over the other standards are sufficiently compelling that people really really want to use it.”

For more information on the Clinical Safety for Healthcare Applications workshops, see Health Intersections.

Posted in Australian eHealth

You need to log in to post comments. If you don't have a Pulse+IT website account, click here to subscribe.

Sign up for Pulse+IT eNewsletters

Sign up for Pulse+IT website access

For more information, click here.

Copyright © 2017 Pulse+IT Magazine
No content published on this website can be reproduced by any person for any reason without the prior written permission of the publisher.