Each different domain, covered by HL7 v2 standard, has a set of message definitions which support message exchanges for a particular domain. Most of the message definitions for a domain share certain segments. Many of the segments are optional and perhaps not used in a particular messaging environment.
In any but the simplest of HL7 messaging environments there will be multiple sources and multiple destinations of HL7 messages. It is very unlikely that all, or even a majority of these, will use exactly the same HL7 message structures in terms of versions, optional/mandatory segments, extension Z segments, and so on.
It is common for integrating specialists, if the tooling which they use permits, to develop one or few generalised message structures which can be used to represent more than one distinct message from a domain they work with. These are typically called canonical models. The overriding purpose is to standardise the message payload being passed around between integration components, enabling reuse and reducing complexity. The Canonical Message model (CMM) works hand-in-glove with the enterprise architecture in which transformation to/from the CMM is performed at the edges of the integration domain, standardizing as much as possible, payload structure within the integration domain.
The article, whose full text is available at https://blogs.czapski.id.au/wp-content/uploads/2012/09/SOASuiteHCI_ch5_CanonicalMessage_v0.1.0.pdf, works through the mechanics of deriving a Canonical Message Model for the series of articles on SOA Suite for healthcare integration using the “Oracle SOA Suite for healthcare integration” tooling. It contains an abridged version of the article “Healthcare Enterprise – IT Architecture Building Blocks – Canonical Message Model for a HL7 Enterprise”, available at https://blogs.czapski.id.au/2010/10/healthcare-enterprise-%e2%80%93-it-architecture-building-blocks-canonical-message-model-for-a-hl7-enterprise, but adds new material related to testing the canonical structure against sample data and modifying the structure to accommodate data idiosyncrasies.
Sep 02
