However, our Google Analytics charts show that even IE6 is on a slow but steady decline. Thanks for posting this article, it’s great to know that we’re not alone in this

I learned Fortran at University but never really got to put it into practice – my first language was basic on a BBC micro running a 6502 processor – they were popular in the UK and to some extent New Zealand which is where I am from. Incidentally Acorn the company that made that machine when on to invent the ARM chip which has now become ubiquitous in the new world of mobile devices. But that’s another story…

It would have been great to have been a fly on the wall at that insurance company to learn just how much of the issue was due to less than wonderfully designed software and if the problems could have solved in a different way. Personally I’m unlikely to have the opportunity to do an internship maintaining COBOL software on AS400 in the near future so I won’t be likely to get that insight any time soon . Maybe someone else reading the blog will have more of an idea that has actually worked in this area. There ought to be some trend towards reaching some larger common subset of information as domain problems are better understood. a.k.a commoditization.

Reminds me of classic folk tale of the programmer at the bank that deposited all the rounding errors from millions of accounts into his account. My guess is rounding errors with insurance add up faster…

My mum has been getting some treatment lately and it’s interesting looking at the forms you have to fill out with hospitals – HL7 ADT messages are really quite closely modeled on the typical processes hospitals follow which is good and bad. It means the standard meets a lot of the needs, but from a data modelling perspective it’s very hard coded around those needs. The structure is not orthogonal (or in other terminology ‘normalized’) which makes it difficult to extend gracefully.

Nice to hear from you! I guess it really depends on what kinds of systems hospitals buy. There are commercial systems that have useful applications in healthcare that aren’t necessary ‘healthcare’ systems. Those support web service interfaces often.

A lot of our customers are starting to structure their applications so that their core interfaces are web services and then they are using Iguana as a translator between all sorts of legacy formats – not just HL7 but flat files, directly querying old DB2 databases etc. It just turns out to be an efficient way to implement support for HL7 and other types of interfaces – sometimes better than having staging tables and so on.

For us I just noticed an ever increasing trend in our pre-sales conversations that more and more people were asking support for web services. Since our core value is making integration easier it became very obvious that we really needed to revamp our technology to handle a lot more than just HL7. The hunch was right – roughly 70% of our new customers are implementing web services as well as HL7. Almost every business in the world is interested in integrating their data and being able to make it available in a SaaS model – ala web services or FTP file type interfaces.

As for the energy industry having bad technology I guess its exactly the same underlying issues – a healthcare company or energy company can both be very successful because of their core products – and yet have mediocre IT technology. If you are selecting say a lab company then the fact that their integration APIs might be a bit grungy isn’t going to be enough to shift your decision to use another lab which doesn’t offer the tests you need and the price point you are willing to accept. i.e. if the Cost of interface = 50,000 and the cost of lab procedures = 1,000,000 – interfacing is only 5% of the overall cost so it’s not going to matter than much.

We’re positioning ourselves to more than just a healthcare solution – basic message is “Iguana can suck your data from any of your systems, in any format and allow you to integrate it and publish it to the web faster and less expensively than any other solution.” Got to work on that messaging but that’s the basic gist. The translator is really quite spectacular – it’s going to useful for many industries.

Protocol: LLP says how to transport a HL7-2 message and how it can be consumed (between these separators).
Format: Well, the pipes
Views on data: guidance on where to look for data.

On the other hand, we have some other not so interesting “specs” which might be applied to healthcare (XML, RIM v3, JSON etc.) Now, considering the 3 points above, is there any difference between all these? While XML doesn’t have any formal guidance on where the data is, it helps in that field with schemas. Actually, it claims some flexibility on the “view” aspect. While this can be problematic because of its hierarchical structure, I’m not sure HL7-2 is any better.

Actually, it seems to me that the comparison between these formats is more related to whether they make the integration process easier on a rather theoretical plan. However, in reality, although hospitals have system integration problems, the JSON, RDF, RIM or whatever won’t make it, imho, if those 800 pound gorillas you mention in a different blog don’t have it in their products and the hospital IT doesn’t adopt it (read: sees it) because is less work for them. And while Oracle sales people try selling ice to Eskimos, they might succeed

I have no idea whether RIM v3 will die or not (I think your point 3 above on this is very important), the question is does it bring any value which is worth supporting it despite the criticism and complexity? Representing models with very little support formalism introduces complexity as well, especially in implementing translators (ok, I know iNTERFACEWARE makes it easier) but also in training and maintenance.

Thanks

PS: As for the healthcare being some of the worst in terms of technology innovation, I point you towards the “energy industry”. Boy, those software systems are old!

This is Vitaly Furman… we spoke briefly at HIMSS and you emailed me
afterwards with a demo suggestion.

I just wanted to let me know that as of May 16th, I had joined the Brooklyn
Health Information Exchange… In this decison, I had shortnened my daily
commute by about 2/3

As this is a InterSystems shop, I have a lot to learn… but it sort of
similar to Chameleon in some ways…

As you can see, I am finally in the HealthIT space… I saw your post on the
Health Information Technology page about the future of HL7.

I will contact you of/when I have time to see your new stuff… it may not
be for awhile….

Thanks

Vitaly

You’ve put your finger right on the button. One of the most broken aspects of the HL7 protocol is the way it’s typically implemented in a broadcast mode. A better model for interoperability are APIs which are what are described as RESTful.

If you have a health information system it should be possible for me to use APIs on your system which allow me to query at any given time for any of the data I need to get from it. It’s dumb that I have to drink from the fire hose receiving an endless stream of events that my application is not interested in.

With RESTful APIs it’s much less of a big deal if a system goes offline for a few hours – no data is lost, systems don’t get out of sync.

Also the APIs should be open and documented. It’s a broken model when you have to be spending a lot of time talking to your vendors. Go have a look at the web APIs for a product called Highrise and you get a feel for just how backward interfacing is within healthcare.