One of the open debates in HL7 is the difference between messages (or messaging), services, and documents. How different are they? If they differ, how? And what does that mean?

Well, I can clarify this easily:

Messages	Messages exchange documents to build services
Services:	Services exchange documents in messages
Documents:	Documents are exchanged in messages and services are built on top of that

Right. That clarifies how they’re different to each other.

Actually, it’s no surprise that they’re superficially similar. Whenever you go about talking between systems, you need to address the same requirements however you go about it (or whatever you call your method).

The 3 methods broadly differ in how the various pieces are assembled, what pieces are delegated to integration time (or even later), and what technology stacks are used. They’re even called “Interoperability Paradigms” in HL7, which is a term that I have the dubious honor of having invented (Templates Specification).

The following sections describe how I see the current state of play in HL7 for messaging, services, and documents. Note that this write up is specific to what’s happening in HL7; I’m not speaking to other communities, or even how I think it should be done.

Messaging

The classic notion of Messaging in HL7 is to a series of information models that include the semantics of explicit exchange, and are bound to a single wire format and explicit technology-based exchange standards, along with a defined behavioral model that has loose mappings to business processes.

This is true of v2 and v3. In the messaging space, v3 attempts to provide rigor to the definitions of both the information and behavioral model, but is broadly trying to recreate the same kind of exchange.

Because the “messaging” environment is conceived of as a low-trust somewhat ad-hoc environment (Drive-By Interoperability), as much information as possible about the exchange is explicitly represented in each instance that is exchanged, and little allowance is made for out-of-band agreements about the exchange.

Services

In the services paradigm, HL7 intends to describe and map business processes to described exchanges, and to bind those loosely to information models. HL7 prefers not to bind these things to specific technology stacks; this is either delegated to OMG, or to the implementing user.

Along with this, there’s a focus on being explicit about expectations in contracts or trading partner agreements, and moving as much stuff as possible out of the instance and into the context.

Documents

In the documents paradigm, HL7 defines stand-alone content models along with minimal exchange semantics that are suitable for persisting, and being exchanged as is more than once.

The context of exchange, and the mapping of content and exchange to business processes are delegated elsewhere – to either related standards or specifications (such as IHE XDS), to project implementations, or even right through to humans to build ad-hoc services using email etc.

Broadly, Messaging -> Services -> Documents represent HL7 being less and less specific about the final interoperability outcome. The amount of effort being devoted to each is about the same (maybe services is the runt of the litter ;-)), but documents are far and away the most successful at this time.

The Future of V3

“V3 Messaging” – a fully bound stack where V3 defines the entire stuff – has been implemented in UK NHS (Connecting for Health), Canada Health Infoway, and NICTIZ in the Netherlands, and some other minor cases. These implementations all vary a little bit from the formal v3 standards, though many of the outcomes of these projects were worked back into the basic v3 standard.

One of the outcomes that came back was that the behavioral framework part of the “V3 messaging” standard was broken. As a consequence of this, HL7 is redefining this part of the standard. While this happens, there doesn’t appear to be any prospects of new adoptions of “v3 messaging”. What I don’t know is whether there will be any interest in implementations of V3 messaging if this work ever completes.

Many projects are exploring some kind of combination of services (either defined by HL7 or elsewhere) and documents – you can do some pretty useful things that way. The question I have is what use cases aren’t best met by this combination (i.e. are better met by V3 messaging)? And the answer appears to be, pure drive-by inteoperability. But right now the community that is interested in this is not interested in v3. I don’t know if they will ever be. (1. They’re not that interested in inbuilt semantics. 2. They like v2 lots. 3. The drive-by space is dying off anyway)

So I think that V3 messaging is probably a thing of the past. This is not the same as V3 is dead – services and/or documents where the information model is based on the V3 reference platform (modeled content based on the RIM, data types, and structural vocabulary) clearly has a bright future.