Can we enforce Healthcare Interoperability standards by law?
Apr 29, 2011“It’s not enough to say we’re providing standards, we’ve got to have laws that say you cannot place software in a health environment unless it meets standards,” he said. “Then we have to test the software against the standards.”
h/t Bridget Kirkham for the link.
As a consultant who works with both standards and health software development, I’m naturally very much in agreement with Prof Patrick.
Except…
There’s two major problems with this, and they’re related. The first is that any significant healthcare software is configurable and customisable. Some software packages are so configurable that they’re actually sold as source code, not a compiled product, and the implementor hires programmers to make the software work for them. Software like that, you can only certify a running installation. But who decides which software needs certification per installation - which is very much more expensive - and which doesn’t, and how do they decide?
The second reason is related to the first. The reason software packages are so different and customisable is that there’s so very much variation in how healthcare is done, how the processes are linked up. And in many cases, the variation is key to improved and more efficient healthcare work flows. Obviously this is less true in primary care than in secondary care - but this is only a matter of degree.
Because of this variation, the standards are descriptive, rather than proscriptive. They are best understand as frameworks for accelerating agreement between parties (again, in primary care this is less evident than in secondary care). This is true of HL7 v2 - all things to all users - and also true of Australian standards published by the IT-14 committees. And it’s just as true about the future NEHTA specifications. They represent steps on a path towards agreement.
Until we can get agreement on consistent practice in clinical medicine, the standards can’t do better than that. But getting consistency at the business practice level is hard. Very hard. People have to forgo their local efficiencies and their particular trading partner agreements on which their existing relationships are built.
This is where IHE offers a different approach: The business/clinical users (purchasers) get together and standardise their business approach first, then they seek a technical standard from the vendors that meets this business approach. Sadly, this order of things has generally been missing from IHE Australia - and it seems to me that it’s not for lack of trying on the part of my friends who are pushing IHE Australia. Rather, the market players (jurisdictions, care providers, colleges, and business managers - and any other purchasers) either don’t understand the benefits of collective action in these matters, or don’t believe that there will be collective action even if the benefits are known.
I’d like to see laws enforcing interoperability standards with testing in health environments. Not because it would solve all the problems - it wouldn’t. But because it would force us to solve these other problems. Which, I’m afraid, is exactly why it would fail.