Synthesis

‘When I use a word,’ Humpty Dumpty said, in a rather scornful tone, ‘it means just what I choose it to mean, neither more nor less.’

‘The question is,’ said Alice, ‘whether you can make words mean so many different things.’
‘The question is,’ said Humpty Dumpty, ‘which is to be master – that’s all.’
-- Lewis Carol, Alice in Wonderland

It's been interesting reading the shift in discussions around REST vs. SOAP in the blogosphere this week now moving towards HTTP and HTML , or device-based connectivity.  See blog posts from John Halamka, Sean Nolan, and Wes Rishel.  My head exploded with insight -- and the sleep that I promised myself is gone by the wayside.

I'm a web, HTML and XML geek from way back.  In 2001 I claimed 7 years of experience with XML (a test my employer passed).  I've got dog-eared copies of the HTTP specifications (as well as HTML and XML specs) sitting on my shelf that are rather aged.  In the thirty years since the development of the OSI seven layer model, we've now seen a shift in how we view HTTP.  Most mappings of the web stack refer to HTTP as an "application layer" protocol, but SOAP, REST, Web Services and Web 2.0 seem to have driven it down the stack to "transport" by layering yet more on top of it.

The complexity of what has been identified as "SOAP" in all these discussions is not SOAP at all, but rather the information models in SOAP.  There's an important difference between the information models that SOAP and RESTful implementations offer that needs to be considered.  These models by the way, are not demanded of SOAP and REST, they just happen to be broadly adopted models that are often associated with these different protocols.

What REST implementations typicall offer that SOAP typically does not is something that HL7 geeks will recognize as a "model of use".  Models of use offer up business friendly names and representations for sometimes fairly complex semantic constructs (and they do it compactly).  The business concepts map closely to the Business Viewpoint of the HL7 SAEAF model.

What ebXML, HL7 Version 3, and similar protocol specifications offer up through SOAP that REST does not is a model of meaning.  The model of meaning maps closely to the Information Viewpoint represented in the HL7 SAEAF model.  Models of meaning are more complex, and contain a lot more explicit information, but they are bigger and harder to understand.  They become a language in which one must express the meaning of "simple" business concepts (although I note those concepts are not really all that simple).

Models of use are easy for people to understand and to perform simple and often very useful computations with (e.g., pretty UI).  Models of meaning are easy to perform complex and often revealing computations with (e.g., clinical decision support).  Geeks like me who've been immersed in various models of meaning don't have large problems speaking those languages and crossing between them, but trying to teach people new languages is rather hard after a certain age.  I seem to have a knack for computer languages that I just wish applied to spoken ones.

The benefits of models of use are conciseness and direct applicability to business processes, but to cross "models of use" boundaries often requires a great deal more translation (e.g., from clinical to financial).  That's because the concepts communicated in a model of meaning assume a great deal of implicit domain knowledge.  The hidden domain knowledge into the model of use makes translations hard.

The benefits of models of meaning are explicit representations of domain knowledge using a controlled information model.  All the possible sematic relationships are explicitly stated and controlled.  This simplifies translation between different models of meaning because one can work at the more atomic level of the controlled information model.  This is why (computer or human) language translators build "parse trees" first, and translate from those "models of meaning".  Models of meaning are more readily marshalled into data storage systems.

The importance of models of meaning in healthcare IT comes into play when we start talking about clinical decision support.  I illustrated one of these examples in Gozinta and Gosouta back in August.  In short, the "model of use" described in the guideline needs to be translated into a "model of meaning" representation in order to compute the guideline through a decision support rule.

So, I think I've successfully convinced myself that we need both model of use and model of meaning in the HIT standards space.  The simple business oriented representations are needed to make implementations easier for engineers.  The more complex information models are needed to compute with.

I think I see a way through the muddle, but it will take some time.  The right solution will not just adopt the first model of use that comes to us.  We will need to put some thought into it.  I believe that we can provide some motion towards an answer that could begin to use in 2013 (or earlier), would be easily adapatable with solutions deployed for 2011.

But if we move towards a model of use in communication patterns, we run into a translation problem that someone has to address.


In a nutshell, WE need to fully specify (in a normative way) translations from model of use to model of meaning and back.  The former is easy (with a common model of meaning), the latter more difficult.  Compilers are easy (use to meaning), but decompilers are hard (meaning to use).  When I say WE, I've got all my big hats on: HL7, IHE and HITSP.  And, we need to agree on a common model of meaning (and this we is the SCO, for which I have no hat).  The HL7 RIM is a really good start for a reference information model in healthcare (Wes and I both know that you can say almost anything in HL7 V3, and I have the V3 model to prove it.)

Having a common reference model provides the interlingua that will truly allow for interoperable healthcare standards.  If all models of use can be expressed in one (and nearly only one) model of meaning based on a common reference model, then translation between the models of use becomes a real possibility.  I know I can translate the "transports" that we've all been talking about into a model of use that would make a number of nay-sayers really happy.

There's also a way to use the same WSDL to enable either SOAP or RESTful transports which makes interfacing a lot easier and more negotiable.  The last problem is how to secure all of this RESTfully, which I'm somewhat unsure of.  I'm not sure it's safe to leave in the hands of the giants that gave us SOAP and WS-* (and insisted on XDS.b) but maybe they've learned their lesson

There's a lot more engineering that is needed to really make this work, and this blog posting is already too long to go into all the details.  The solution isn't simple (making hard problems easy never is) and it needs to address a lot of different business considerations.  There's also a need to address the migration issues for the current installed base (not just one, but at least 10 different HIE's in the US are using the HITSP protocols, many in production, and that doesn't count the Federal agencies, and a heck of a lot more internationally have been using the IHE specifications upon which the HITSP protocols are built for even longer).

My main concerns about all of this discussion is CHURN and disenfrancisement.  Over the past five years we've taken huge steps forward, and this seems like a big step backwards.  It may be a step backwards that prepares for a huge leap ahead, and because of that, I'm willing to engage.  I get what REST can do (this blog and my whole standards communications campaign are built on RESTful protocols).  The concern about disenfranchisement is the suggestion that a group of uber architects could do this quickly and outside the bounds of a governance model that organizations like IHE, HITSP and HL7 impose.  If this is to work, it needs the buy-in of those organizations, and their constituencies.  It needs to have two key goals:  simplicy and compatibility with the industry investments of the last five years.  XML was a three year long project that replaced SGML and changed the world.  It had those same two key goals.

If we can synthesizes models of meaning and models of use together, we will truly have a model of meaningful use.

I'll probably get a heap of flack for this post tomorrow (or at least the pun), but what can I say?