Context of Interoperability

Interoperability Law #1 says that Interoperability is all about the people.

That has some interesting consequences. One is about the radically different contexts for interoperability. The people who are involved, and the context of their involvement, makes a massive difference to how you approach the problem.

I’ll illustrate by providing two different scenarios, both of which are thoroughly based in real life (I know the people, but names have been changed to protect the guilty and the innocent – and me).

Alice vs Bob

Alice and Bob are integration managers who work for two different vendors, Acme Healthcare Systems and Best Computing. Both vendors sell clinical records systems and laboratory information systems. Alice and Bob have known each other for twenty years, since Bob first worked for Alice. Acme has just won a contract to supply a clinical records system to EverGood Hospital, against stiff competition from Best. Best made a better offer, and has a system more suited to EverGood’s requirements, but EverGood already uses Acme’s laboratory system, and Acme was chosen because both Acme and Best made wildly conflicting claims about how well Best’s clinical records system would integrate with Acme’s Laboratory Information system. Both Alice and Bob know that they were both, err, “generous” with the truth during the sale process, but they’ve been doing this for twenty years now. And over those twenty years, they have come to hate each other with a passion. No opportunity is missed to stab each other in the back.

Now the GoodFeelings Hospital over in the next city wants to get a closer integration between Acme’s clinical records system and Best’s Laboratory information system, and they have called Alice and Bob to a meeting to discuss the problems they are having, and how they can get better results.

Peter and George

Peter and George both work for a large program that is funded and administered by large corporations, universities, and the national government. All the work of the program is published as open source software, and there are multiple virtual and face-to-face interactions through the year. Peter and George have worked together closely over the last few years, and though they don’t actually work in the same team or physical location, they’ve become good friends. In fact, so much so that their families holidayed together over the last major holiday (had a great time camping, and their rooms both feature photos of the fish they caught). Peter generates data that requires analysis as part of the program, and George works for the analysis group.

They need to share their data. Peter and George are used to sharing – they share more than 90% of their data models, libraries, and development methodology as part of the overall program, and even what they don’t share, they can look at anyway. Now Peter and George are discussing how to get even more data exchanged over a drink while meeting at a conference.

In both these, the two people need to improve the way their systems interoperate. And they face the same technical challenges (discussed in a later post).

But because of their relationships, the way that they can go about solving problems is radically different. An approach that will work for one is surely gauranteed to fail for the other.

Generally, Alice and Bob are going to spend a great deal of additional money to solve their problems. But even with George and Peter, conflict may arise, and it can be harder to solve in that case.

Interoperability – it’s all about the people. And there’s not that much difference between interoperability and diplomacy.

Drive By Interoperability

I refer to the case of Alice and Bob as “drive-by interoperability”. They both want a clean encounter, with as little interaction with each other as possible. And the hospital does too – conflict between vendors can be a real problem to resolve. Also, due to variation between institutions etc, what works at one institution probably won’t just work elsewhere.

So all three players want a clean hit with the most bang for the buck in terms of solving local problems with real technical change.

This is the historical context of HL7. That’s what we do: sharing data between two systems where we can take nothing for granted. We don’t assume any rational sharing of any nature between the systems at all, except for the specific interaction that is under consideration. The more interactions you depend on, the more risky the overall implementation.

Forget talking about enterprise buses. We aren’t even talking about shared authentication contexts or user databases. No trust. Ever.

(Aside: I reckon this matches the healthcare system I know far better than any other approach. Trust is just a word you can find in the dictionary 🙁 )

So that’s the classic background of HL7. Drive By Interoperability.

In a case like this, the HL7 standard is a framework for solving problems. The players want fixed technology – because technological change is expensive, and easy adjustment to particular and peculiar business practices between institutions. v2 gives this – Minimal Lower layer Protocol exchanges, common syntax, loose semantics in the fields, highly adaptible. Fit for purpose.

National Programs

That approach was just fine for vendors and small providers. But the problem was that it didn’t scale. If you’ve seen one v2 interface, you’ve seen one v2 interface. And once healthcare institutions started rationalising themselves or their IT, this adaptability of v2 actually become the pain point. You’d think that you had things sorted out, but no.

v2 got a bad name for it’s adaptability (though I think that was the symptom, not the problem). HL7 folks decided that it’s loose semantics were a problem. And kicked off V3, with the reasonable and laudable aim of solving this. And they have too, in many respects. (now we stand on the new mountain top of our work, and see how many new mountains are now visible).

Along the way, HL7 attracted the national programs. They have very different concerns indeed. Firstly, they are much more infrastructural and community centric (i.e. they build their own community). Peter and George fit into the national program picture (though it’s not usually so rosy as that picture). They want to share what can be shared in a rational fashion. It’s not scoring points with the national programs to keep the contact points between systems down, and armor up the ones that do exist with a myriad of possibly related data items. That’s a big disadvantage for them.

Also, they know that  changing technology is expensive (we all know that!). And they need to operate across multiple institutions without having to impose new technology on them. Further what they want to do is impose common semantics and behavior (this is just rationalizing writ large). So what they want is leveragable exchange protocols (web services…), fixed semantics, and highly adaptable technology.

That’s almost the exact opposite of what the original players in HL7 wanted – and still want (sort of).

One house fits all

How do all these players fit in the HL7 house? Well, there’s a fair bit of  tension, not helped by the fact that it’s hard to see this particular problem.

There’s the v2-centric players. They’re still living in the days of pre-rationalisation. (And they’ve got a point too – just what has this rationalisation created, since the underlying problems are still there?)

There’s the big national SOA guys. They’re playing to their script – give us deep integration, what we want. Don’t muck as around with technology. (oh, and, btw, these guys have money and corporate/governance expertise to take over HL7).

Then there’s the techies. They said, “yeah, sure, we can do that. HL7 v3 can solve everybody’s problems.”

Only… I don’t think that’s true (If anything, it doesn’t solve anyone’s problems – see other posts). We actually need to figure out how to capture these different player’s interests, and express the differences without that destroying the larger commonality which does exist.

We solve interoperability

HL7 does solve interoperability. We’ve sorted half adjusted to the SOA/large program community by allowing more points of contact and so forth. But in our hearts, we still design the information models for worst case interoperability. You can see that manifesting, for instance, in HXIT attributes in ISO 21090 (subject of yet another post).

Programs that take up HL7 interoperability solutions need to be aware that the closer they get to Peter and George (and the further from Alice and Bob), the less HL7 is going to seem like a good fit off the shelf. That doesn’t mean it’s not useful – just that you need to know how to correct for these assumptions of badness that HL7 implicitly makes.

HL7: Interoperability in the worst case.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen

*

%d bloggers like this: