Health IT developers are health IT users too

Written by Brendon Wickham on 01 January 2014.

This story first appeared in the November 2013 issue of Pulse+IT Magazine.

Implementing IT standards for healthcare is a bewilderingly complex field, even for experienced programmers, as behind each standard is a host of theory that can prove confronting for those itching to get in and start work. Standards adoption needs to become more participatory and more transparent.

My GP can send electronic scripts that a few pharmacists can scan, and he gets most pathology results in one electronic format or another. But he cannot seamlessly exchange electronically generated information about me with others. Not specialists. Nor hospitals. Nor practically anyone else in the health system. I haven’t asked him, but I’m sure he would like to be able to, especially to the level that service providers can do in other industries.

What prevents my GP is the lack of various types of interoperability between health IT systems. All around the world, governments and non-profit organisations are trying to redress this by working on standards. Some of these standards are for clinicians, but most, being health IT, will need to be implemented by programmers. So what is it like for a programmer to actually implement a complex health IT standard?

A standard is a compromise that gets adopted by as many as possible. That’s a simple definition to write, but it’s very hard to achieve. Compromise is a confronting concept: it means people have to change what they do, and it takes a long time to work out where compromises can be made. And a standard is not an end in itself. There’s no point to a standard if it’s not being used. It has to be implemented.

I recently implemented the Australian Medicines Terminology (AMT). The AMT contains standardised terms for medicines (terms that are themselves the result of many compromises). The task I needed it for was small but important. AMT’s standardisation makes it an ideal proposition because it removes a lot of ambiguity. A lot of decisions about how to represent medicine information have already been made, saving me time and invention.

But I found that implementing AMT is not straightforward. AMT is not a few columns in a spreadsheet. It is a subset of SNOMED CT, which is based on description logic. I didn’t need to know why it was so or why those decisions had been made. All I needed was, in the end, a bunch of columns in a spreadsheet. My implementation wasn’t elegant. It wasn’t something I’d claim was a beautifully architected piece of coding. All I had to use were the techniques, models and principles I have experience in. An expert programmer in terminology would probably tut tut at its flaws, but it did do what I wanted it to do quite well.