PCEHR: What really went wrong

Anyone with the slightest idea of large-scale software development would have been staggered by the surpassing silliness contained in yesterday’s piece in the Medical Observer, in which “ehealth consultant” David More trots out his analysis of the problem which has brought the desktop software side of the PCEHR project to a temporary halt.

According to More, it would have been terribly easy to avoid trouble: “Had they planned properly they would have had a consistent data model for all the sites and they would have noted that there was this issue [at the outset],” he said. “It just reflects incompetence, frankly. If they knew what they were doing they would have addressed these problems before they started.”

The only illumination one could gain from that is that More simply had no idea of the cause of the problem, no inkling of a solution, and insufficient humility to admit that in truth, he’s not much of an ehealth expert. It really is long past time lazy journalists scratched him out of their sadly tattered contact books.

The very idea that you can anticipate every problem before you begin a hugely complex IT project and construct a data model that uncovers every deviation is ludicrous.

The very nature of software development is that it’s a process of getting things right. The recipe is largely the following: Develop, test, identify bugs, fix them. Endlessly repeat.

What happened in this particular case is that the wave site developments were a dynamic operation, with the developers constantly engaging with NEHTA staff to identify problems and challenges. As issues arose, NEHTA made changes to the specifications to address them. In parallel with that, the specifications were being run through further quality assurance testing.

As the work proceeded through 2011, NEHTA kept the sites informed about the changes that were being implemented to resolve their concerns, allowing them to integrate them in the work.

What when wrong, essentially, was that in October, the change log was finalised. The list of issues NEHTA provided at that point of things that would be fixed in November omitted a number of new items that had been included in response to feedback or problems, or new issues that were still to be identified during testing in November.

That meant developers working on the October change log would have had to upgrade their software later to reflect the changed specifications.

NEHTA decided that rather than have that happen, it was better to call a halt, have everyone build to the November specifications, and deploy the software once.

The main impact is that they deploy later than expected. Rather than February it’s more likely to be May. Of course this will be worked out between NEHTA and the sites, but it’s the sort of rational reaction coming from sites, rather than the sort of hysteria coming from some commentators.

Anyone who’s actually involved in doing ehealth, as opposed to just talking about how others should do it, will know that you have feedback loops on early versions of specs to later ones. They will also know that keeping a complete change log is essential. That is how you address this sort of issue before the project starts. Data models have nothing to do with it.