Interoperability Requirements #6: Common Understanding
May 12, 2011Finally, in order to be able to exchange data, two systems (or the people responsible for making them exchange data) need to share a common understanding about a number of other things, things that are taken for granted by the participants, an agreed context of operations. As an illustration – still sticking with the language parable - let’s take a simple case. In Isaac Asimov’s “Foundation”, one of the characters says: “Violence is the last refuge of the incompetent”. In the original book, the character means that only the incompetent will use violence because it doesn’t solve anything. But you can take those some words and grammar, with their known meanings, and make the polar opposite conclusion: that that competent people would have resorted to violence long before it’s time for the last refuge. What differs between these two understanding is the different background values people have, their different experiences and motivations.
Anybody involved in an interoperability project brings their previous experiences, their background knowledge, and their motivation to the table, so an important part of the project is for everyone to coalesce on these things as much as possible. Of course, it would be good to do this with explicit documentation, but that’s rarely feasible.
I don’t believe that I’ve ever seen a project where all the agreements concerning the other requirements are written down. Anything not written down is defaulted to the shared understanding of the participants - if it exists. And if it doesn’t exist, it will gradually form. I suspect that for all the chaos and cost of letting it coalesce like this, it’s still cheaper than trying to get everything right up front.
Even a project that made all the things discussed in the previous posts explicit will still have a huge knowledge base that is taken for granted, about how IT, healthcare and management works. And the lack of actual common understanding can become a problem at any time. Interoperability: it’s all about the people.
HL7
I often think that the primary value of HL7 is actually at this level, shared common understanding of healthcare interoperability. And it’s not even really documented in the standards.
It’s a hallmark of the implementation process, having a line in to the community. One way or another, most implementers - and certainly most successul implementers - have some communication connection to someone who personally knows the decision makers in the HL7 community, and can ask them questions directly. In some countries, this is explicitly managed to ensure that it exists. In other countries, it seems to arise by default. But as far as I can see, it’s necessary. And it seems to me that the success of the implementer is influenced by the quality of their line of communication.
I’ve heard a lot of people criticize this aspect of HL7, and particularly the independent consultants (me, now, too) who “profit” from this. It’s certainly a problem, but I don’t know how to solve it. How can the community know how much knowledge it should make explicit, and what should be left to other communities?