Characteristics of IPs

Goal of this document

The goal of this page is to create something that's basically an extension of [1] - in other words: if one accepts the notion that the 3 interoperability paradigms (IPs) exist next to each other, and that certain categories of use-cases may be best served by one IP or another one, (given the inherent characteristics of that IP) then how does one answer the question what the best IP is for a given use-case? If your answer is that IP X can be used to cover all use-cases: that may (or not) be true, but we’ll have to work in a mixed environment for a pretty long time.

Notes:

• This discussion is in no way bound by, nor limited to, the ArB of SOA/HSSP work. It is a bottom-up approach, which may someday ïn the middle" meet the top-down approach used in the ArB documents.
• Given that the result will be 'guidance' (only), because of the grey areas that could be covered by multiple IPs there may not be any form of 'official adoption' by HL7.
• when we talk about services, then we’re talking about services that have a RIM-based static content model.
• Rene: Personally I don't think we should use too many SOA terms. That mainly because I, like most people in HL7 (and most readers of the future paper), have a messaging background, and using too many SOA terms will surely cause the readers to stop reading. In order to express some of the differences we may need to use SOA terms, but it would probably be best to tread lightly.

shared context

In case of documents almost no context is shared, for messages some context is shared and in case of real-time service calls a lot of context is shared.

The less shared context (contractual) between communicating partners, the more the requirement to include the context of the data within the data itself. Thus a document contains lots of context, and a service contains almost not context at all. Systems with a lot of shared context are said to be ‘closely coupled’, systems that share little or no context are ‘loosely coupled’. ('Shared' here means 'having in common', rather than 'actively sharing' as in communicating that context, which is actually the opposite thing).

One also recognizes this in the way that things are addressed (when communicated): documents are addressed to a human reader or an organization, messages are sent to an application (as a whole), services are sent to a process within an application.

Another aspect: if we look to the mechanisms where messaging (notably v2) has been most successful, then it's "notifications": something has happened in my application, and I'm sending a single snapshot of the data (including contextual related information) to other applications to enable them to synchronize their database. Query-mechanisms, and order/confirmation type of exchanges, although they have been implemented, have been far less successful. For order/confirmation type workflows I assume that's because they actually assume tightly-coupled systems whereas most traditional messaging systems are not.

To loosely quote Charles Parisot (about IHE XDS): The more tightly coupled the systems are, the more detailed (use-case specific) the queries are. Or in other words: if your systems are loosely coupled, use only generic queries.

scope of the semantic model

Rene: Ernst de Bel mentioned that he's using a "add participation to act" service. To me this highlights another characteristic of messages v. services: services are more atomic in scope, because of the real-time characteristics of services. The example given was "a meeting where multiple people attend" - in the messaging IP one would send 1 message after the meeting was finalized (and maybe 1 when it begins). In de services IP one would use a "add participant to meeting" service whenever someone enters the room.

The semantic content models in a service tend to be relative small - one doesn't send a snapshot of a complicated object structure to update 1 attribute (which one does in messaging).

"add note to identified Act" has a service-like ring to it, much more so than a message, yet it is defined in the v3 messaging standard as an interaction. "add participant to identified act" is another prime example of a service, and it doesn't exist as a v3 message.

development environement

Michael: I have noticed that the Services model is easier to use in the current development environments like Java6 en .Net.

• Rene: Are you saying that the choice of development environment more or less forces you to puck one paradigm over another one? That would not be a good thing - one chooses the most appropriate paradigm first, and then the most appropriate tool to support that paradigm.. (I'm aware it happens the other way around, but it's not something I'd mention as a best practice).

Transformation between paradigms

• how to transform message constructs into services? why might you want to do this?
  • To me this is only worthwhile if two applications use different paradigms. It would require a pretty intelligent agent to do the translation. Rene spronk 13:02, 10 October 2008 (UTC)

The Scope of HL7 Standardization Activities

The question at the beginning of the document, which says "In a real life setting, how to choose between 3 IP models (or 2, if we focus on messaging and services paradigms)?" is really important one. However, IMHO, the question "Who should answer it?" should be even more important to this community. The answer to that one seems to be obvious - SW architects in charge of the projects, and not HL7 standard developers!

The use case approach often causes us to misinterpret our roles, and it is a fair mistake to be made. However, we should really differentiate what should we as standards developers deliver to SW architects around the world. I'd say, it's the standard that has a unique place on the market, and would bring value to semantic interoperability requirements, which no other well established standard or industry initative could do better. Having said that, I strongly believe that the biggest value people get from HL7 is (or should be) RIM based methodology (including CDA), vocabularies and terminology sets, and implementation guidelines which not only provide tips and tricks around the methodlogy, but also give guidance in regards to HL7v2 backwards compatibility, communication protocols and IP models, etc. For everything else, we should declare it out of the scope of HL7 standard, because it's either not something to be standardized or somebody else is already doing it better. The way fwd to me is:

• Continue work on Wrappers R2 model
• Declare TW obsolete and optional, but provide backwards compatibility models
• Implementation profiles and guidelines how to implement RIM based methodology with different scenarios, which will also implicitely provide cross mapping instructions
• Reanimate ATS work, which should clearly express the "boarders" of HL7 standard and mappings of various concepts in HL7 world and various IP models and comm. infrastructures

--Miroslav Koncar 15:06, 28 October 2008 (UTC)