Dear Agony Aunt,

My husband is having an affair with his secretary. He brings her home and they hang out in our bedroom, while he wants me to make them pink daiquiris in the kitchen.

My problem is – how do I make a pink daiquiri?

For anyone that knows me, it is a favorite joke I like to repeat (probably too much) – I originally heard it from a great New Zealand comedy show called McPhail And Gadsby growing up in Wellington as a kid.

I love the absurdity of the poor wife that has lost sight of the real problem that her husband is having an affair and instead has focused herself on the technical problem of making a pink daiquiri.  I keep coming back to this joke because it’s a great parable for how many IT projects go.

Some mistake is made and not recognized early on and then people start tying themselves in knots to resolve the symptoms rather than the real underlying problem. We forget what the objectives are and lose sight that the tools we use are just a means to an end.

I often use this joke as a way to lighten things up and help my staff or customers have a chuckle and take step back to look at the problem they solving from a slightly different vantage point.

Hmmm – come to think of it …. I still don’t know how to make a Pink Daiquiri.

Been meaning to blog a post on this for ages.

It’s pretty obviously to any entrepreneur who runs a medical software company why technology in health care tends to lag behind what other industries have.  The best technology to be found is in the consumer sector – consumers buy products they themselves want to use.  They buy on price and functionality and there are huge economies of scale.

The process of how buying decisions are made in health care IT – and the heavy impact of government regulation – gives a very different landscape for health care IT.

If you are an EMR vendor selling to hospitals, the quality of your software product can almost be secondary to other issues when it comes to getting the business. Decision making in healthcare is highly centralized. The decision makers that have the budget are typically not the people that use the products. So products tend to be sold on the basis of arguments of return on investment.  These decision makers are highly risk adverse so they prefer to adopt solutions they know other people bought.

The sales process is highly political. To be a successful medical software vendor the game is actually more about optimizing your sales process than your actual technology. Companies often get acquired in health care IT not for their technology, but for their customer base. A very common play in health care software is to acquire a portfolio of different ‘solutions’ so you can sell them to the customers you have that look to you as their vendor to help them.

Now throw into that mix the huge role that governments play in regulating the industry, creating various compliance standards that vendors are constantly having to leap through instead of focusing on improving their products and you can start to understand the sorry state of health care IT. This is not an environment which greatly encourages technical innovation and progress.

My hope for the industry is that progress can be found coming from the physician EMR side of the house.  This is where there is the smallest gap between people making buying decisions – i.e. the doctors buying these systems and their staff who use them.  The money is not as great as it is for hospital IT but the structure of the market in this area offers much better hope for long term technological progress.

But government regulations in this area have great potential to screw things up. That’s one of the big risks of things like “Meaningful Use”.  Some really bad ideas could be forced on companies that could otherwise become the engine for innovation in healthcare IT.

This question came up on the HL7 mailing lists recently so I thought I would give a business perspective on it. I would say that less than 0.5% of the market implements the XML encoding of HL7 2.X in XML.  I gave some of my perspective already with my article on why a JSON encoding of HL7 2.X is not a great idea.

There are two business cases I know of for which it makes excellent sense to implement the XML encoding of HL7 2.X.

1. If you are large medical software vendor that wants to shut out your competition by making integration difficult, yet you need to maintain the appearance of being open and HL7 compliant then only supporting the HL7 2.X XML encoding is a brilliant idea.  I would suggest you go the whole hog and do the ACKnowledgements in XML and exploit any ambiguity you can find in the HL7 standard too since that will make it particularly hard for your competitors.
2. If you are a small medical software vendor that has no choice but to try and integrate with the 800 pound gorilla from point 1 then you may have no choice but to implement support for the XML encoding of HL7 2.X. Suck up the cost – that’s what it takes to compete with the big boys.

If you are a health care provider that merely sees interoperability as a cost then it probably is better to discourage vendors from only supporting the XML encoding of 2.X HL7. For you the only impact will be to increase costs and reduce your choice of available solutions since you already will need to be spending money interfacing with the traditional format of HL7.

Either way if you are using Iguana you’re good – it’s quite easy to support both traditional HL7 2.x and the XML variants.  We’ve supported the XML encoding of HL7 2.X since the first version came out and the Translator is even better since it parses XML natively.

SOAP stands for Simple Object Access Protocol. But there is nothing simple about it. If you don’t believe me, then go read the specification. It’s not surprising the thing got so out of hand – just look at the list of contributors.  They all had to ‘add value’ in some way.

One of the more challenging interfaces that many of our customers have to deal with is the E-Subscription interface from Surescripts.

The format uses XML with EDIFACT messages embedded in the XML encoded with base 64.

I had a customer on Friday asking about it and so I took the Iguana 5.0 Translator for a bit of a spin to see if it could handle the format.  Sure enough it wasn’t difficult.  Here’s a link to my implementation. It’s demonstrates how powerful a tool the translator is at handling what could otherwise be very snarly interface.

I’m curious.

Firstly is there anyone reading my blog which has more knowledge of Surescripts?  To me it looks like a wrapper around an older legacy system which talks EDIFACT.  It feels like Surescripts have put a more modern web services based front end in, but not altered the core system.  Anyone know the full story?

That strikes me as an increasingly common trend that we will see in the market place.  People putting web services wrappers around old legacy systems and coming up with these odd hybrid formats.

Anyway if you are doing a Surescripts interface or you have some other weirdo messaging format that you’re having trouble parsing then by all means push it over to me – I’ll see if the translator can handle it.