The need for decoupling wire format from semantic model

This is another related point as part of my suggestion to HL7v3 fresh task.

Firstly, lets have a brief definition about the exchange model and semantic model. Exchange model is the the model than determines the wire format typically expressed in XML Schema Definition (XSD) when developers can use to create WSDL (web service definition language) for web service invocation. Semantic model is the model that defines the precise meaning and relationship between different data elements, and data element binding to the terminology such as SNOMED CT.

Use HL7v3 as an example, RMIM (Refined Message Information Model) is the semantic model, such as "POLB_RM004000UV01" for lab result. The wire format is directly serialized from RMIM if you are using messaging oriented XML ITS. (of course the alternative in HL7v3 is using document oriented XML ITS, that it is CDA R2 wire format). So as we can see, currently there is no so called exchange model in v3, so what's the problem we will face?

Below is my original comment.

My comments and suggestions, particular to the issue raised by Lloyd below about the wire format incompatibilities due to additional requirements or refactoring.


>>The problem at the implementer/project level is that when you take the UV model and tightly constrain it to fit your exact requirements, you discover 6 months >>down the road that one or more of your constraints was wrong and you need to loosen it, or you have a new requirement that wasn't thought of, and this too >>requires refactoring and often results in wire-level incompatibilities.

In general I think we need to separate the exchange model (determines the wire format) from the information model, and defines consistent way for mapping between exchange model and information model. This will provide few benefits

1) The decoupling of exchange model from information model, allows the evolution of these two models independently to cater for different needs. The evolution of information model is to address ongoing business needs, and the exchange model is to address the technical needs. In this way we will be able to solve the dilemma Lloyd mentioned above to some extent though I agree that the information model versioning challenge still remains. But again this is the really the design issue faced by every solution designer in every industry. e.g when we design data model, we need to ensure that the updated data model able to handle new system requirement but also at the same time meet the existing system requirement, or at least the design need to ensure that the existing data in the old data model shall be able to be mapped to the updated data model. So similar kind of information model versioning and governess shall be in place.

2) The information model needs to be very rigorous and extremely hierarchical to ensure reliable understanding, persistence and query within the application, however that same level of complexity does not need to be cascaded down to the exchange model which needs to be simpler and flatter. (I think that is why data type is simplified on the wire though it is largely based on ISO21090), so every developer can easily understand what information needs to be exchanged with a quick look at the wire format.

And I am glad that Lloyd has agreed.

From: owner-its@lists.hl7.org [mailto:owner-its@lists.hl7.org] On Behalf Of Lloyd McKenzie
Sent: Saturday, August 20, 2011 12:40 AM
To: Victor Chai
Cc: Grahame Grieve; Eliot Muir; Zel, M van der; HL7-MnM; RIMBAA; HL7 ITS
Subject: Re: A Fresh Look Proposal



Hi Victor,



I agree that the separation of semantic model and wire model is desirable, and I think essential. Furthermore, I think it's possible that there could be more than one wire model for a single semantic model. The pharmacy model *definitely* needs to support complex chemo-therapy protocols at a fully encoded level. That doesn't mean we can't produce a simplified wire format model for community pharmacy that satisfies the 80/20 rule. If a particular implementer needs a few more elements, odds are they're already defined in the "big" model so the necessary data dictionary codes would already be there. Furthermore, if both a simple and complex wire model are created, an implementer of the complex wire model could easily interpret the simple wire format due to the underlying mappings to a common semantic model.



The other benefit of the split is that it allows the committee to be a bit less paranoid and move forward sooner without being as "complete". If some refactoring is needed to the semantic model, they can do that while still retaining the original "simple" wire format model.


Grahame, can you clarify what you think the "high price" is that you think is associated with doing this?



Lloyd


Another related comment from Bernd from Germany.

Dear Lloyd,

I'm really happy that we at HL7 are slowly going to really look beyond the wire syntax bowl. This was the intention as we have started in the late nineties the discussion to introduce and mature the RM-ODP at HL7. So I strongly support your last statement regarding the need for separation of wire syntax and semantic models. However, this also holds for other parts of the points you addressed, where this separation is not strictly followed.

Very best regards

Bernd