This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Message Wrappers section of the v3Guide"

From HL7Wiki
Jump to navigation Jump to search
(new content - major offline edit)
Line 1: Line 1:
 
{{INM Workitem}}
 
{{INM Workitem}}
Section 3.9 of the v3Guide (May2006) which needs to be updated to reflect the latest thinking on wrappers and infrastructure. The Wiki links have been added with the sole intent that terms are used in a consisten manner; the links won't show up in the v3Guide in ballot or normative standard publications.
+
Section 3.9 of the v3Guide (May2006) needs to be updated to reflect the latest thinking on wrappers and infrastructure. The Wiki links have been added with the sole intent that terms are used in a consistent manner (i.e. glossary style); the links won't show up in the v3Guide in ballot or normative standard publications. The text below replaces the entire section 3.9, inclusive of all subsections 3.9.x.
  
 
== 3.9 Version 3 Message Wrappers and Infrastructure ==
 
== 3.9 Version 3 Message Wrappers and Infrastructure ==
  
HL7 Version 3 provides a substantial level of functionality in the provision of envelopes to support the transport of HL7 messages from sender to receiver. HL7 calls these wrappers. Inside the wrapper is [[Domain Content]].  
+
HL7 Version 3 provides a substantial level of functionality in the provision of envelopes to support the transport (in a generic sense of the word) of HL7 messages from sender to receiver. HL7 calls these [[Wrapper|wrapper]]s. Inside the wrappers is the [[Domain Content|domain content]].  
  
Wrappers are all defined in the same way as for message content, by defining object classes and related relationships. These specifications can then be used to generate an ITS-defined syntax (e.g. XML schema) to go on the wire.  
+
Message wrappers are defined in the same way as message content, by defining object classes and related relationships. These specifications can then be used to generate an ITS-defined syntax (e.g. XML schema) to go on the wire.  
  
The Messaging Infrastructure part of the standard is organised as four separate domains. The four domains are:-
+
The [[Specification Infrastructure]] domain group (which consists of a number of wrapper related domains) specifies the two basic types of wrappers:
#Transmission Infrastructure  
+
*Transmission Wrapper – described in the (MCCI) Transmission Infrastructure domain.
#Message Control Act  
+
*Trigger Event Control Act Wrapper (also know as the Control Act Wrapper) – described in three domains, see below for details.
#Query Infrastructure
 
#Master File - Registry Infrastructure
 
  
Whenever domain payloads are transmitted in the form of messages they will use the wrappers as defined by the above domains. HL7 has defined a rich set of transmission oriented functions within the HL7 standards scope because there is no de facto way of providing these functions in a single standard that could be adopted. Standars such as Webservices or ebXML provide similar functionality, whereas MLLP or FTP do not.
+
Whenever [[Domain Content|domain content]] (as a payload) is transmitted in the form of messages they will use the wrappers as defined by the above domains. A HL7 Version 3 message typically consists of a Transmission Wrapper, a Trigger Event Control Act wrapper (conditional) and the [[Domain Content]] (optional).  
  
=== 3.9.1 HL7 Transmission Wrapper ===
+
HL7 has defined a rich set of transmission oriented functions within the HL7 standards scope because there is no de facto way of providing these functions in a single standard that could be adopted. [[Messaging Infrastructure]] standards such as Webservices or ebXML provide similar functionality, whereas [[MLLP]] or FTP do not.
  
The HL7 Transmission wrapper is required for all Version 3 messages. It contains a large number of optional fields so the message overhead will vary from one context to another. Technical committees or realms who perform refinement on the transmission wrapper need to ensure that tooling is in place to pick up their modified wrapper rather than just the default. For instance when using an XML ITS, the final output needs to be an XML schema comprising message content, the transmission wrapper, and, optionally, a Control Act wrapper.  
+
=== 3.9.1 Transmission Wrapper ===
  
Associated with use of the wrapper are a number of services that are available as needed:-  
+
The HL7 Transmission wrapper is required for all Version 3 messages. It contains a large number of optional fields so the message overhead will vary from one context to another. Loosely coupled systems may require the use of a larger set of attributes than tightly coupled systems. This wrapper may be constrained to fit the requirements of a specific use-case or realm.
  
Three messages are defined to support these functions and each one has an R-MIM and HMD. The two acknowledgement message types with very different roles. One is to support reliable delivery at the network level. Increasingly however HL7 V3 messaging will make use of external transport services that do not require use of an HL7-defined network acknowledgement. The same is true of the optional message sequence number protocol. It is an essential component of supporting reliable delivery at the network level, but again not required if an external reliable transport is used such as the three HL7 transport profiles now all at DSTU.  
+
All Transmission Wrappers have mandatory attributes which identify the sending and receiving systems of a message transmission by means of a Device ID. Additional information about the Sender and Receiver may also be transmitted in other classes, but the use of a mandatory attribute ensures that a [[Messaging Infrastructure]] such as ebXML can base its addressing mechanism on the ID of the receiving Device as contained in the Transmission Wrapper.  
  
The application acknowledgement is very different. It is triggered only by inclusion in an Interaction and with a defined trigger event. It may carry domain content and therefore combine the general functionality of an application acknowledgement, with the specific response defined by the domain for this Interaction.  
+
Associated with use of the Transmission Wrapper are a number of services and features that are available as needed:
 +
*A message with a corresponding R-MIM has been defined to support the reporting of any syntax issues (or the lack of any issues) by the communication software of the receiving application. Note that this is not a reliability feature (although it has been inappropriately used as such in HL7 version 2), HL7 assumes that the underlying [[Messaging Infrastructure]] is reliable.
 +
*An optional message sequence number protocol. It is an essential component of supporting in-sequence delivery at the network level. It is not required if an external mechanism for in-sequence delivery is used (e.g. by means of Webservices or ebXML).
 +
*An optional set of functions and messages to support polling. These functions are included for compatibility with some early V2 use. Polling is probably a matter of limited interest to implementers, other than those with particular legacy problems.
 +
*An optional [[Batch Transmission Wrapper]] used to group messages for transmission purposes. On occasion one may want to group messages before transmitting them, e.g. a batch of financial charge messages, or a group of response messages to a single query message.
  
All the message structures in the Transmission Domain have mandatory attributes which define the sending and receiving systems in a message transmission (DeviceID). Additional information about the Sender and Receiver in other classes, but the use of a mandatory attribute ensures that a transport protocol such as the ebXML DSTU can define an attribute copy procedure which will allow the values in Device ID to be also held in the ebXML wrappers. A later paragraph in this Section summarises the commonalities and differences between the three transport DSTU specifications.  
+
=== 3.9.2 Trigger Event Control Act Wrapper ===
  
The Transmission wrapper offers an additional set of functions to support polling. These functions are included for compatibility with some early V2 use. Polling is probably a matter of limited interest to implementors, other than those with particular legacy problems.  
+
Additional richness in functionality is provided by the [[Trigger Event Control Act Wrapper]] (a.k.a. Control Act Wrapper), which is used when information about the interaction which has triggered a message needs to be communicated within that message to the receiver. Almost all Version 3 messages contain trigger related information. In some exceptional cases there is no need for such information to be included in the message. The Version 3 standard documents which Control Act Wrapper needs to be used for a particular message. A generic wrapper definition is supplied as part of the Specification Infrastructure domain. This wrapper may be constrained to fit the requirements of a specific use-case or realm.  
#Send Poll Response w/ Message
 
#Send Accept Ack/Poll Next Msg
 
  
=== 3.9.2 Control Act wrapper(ballot: Infrastructure Domain) ===
+
Two particular areas of application of the Control Act Wrapper are query sessions and registry interactions (such as Master Person Index). Messages in those application areas use specializations (query or registration related extensions) of the basic Control Act Wrapper.
  
Additional richness in functionality is provided by the Control Act wrapper, which is used when information about the interaction which has triggered a message needs to be communicated within that message to the receiver. In some cases, these interactions will have been fully defined by the interaction model and therefore there is no need for such information to be included inthe message. Two particular areas of application are query sessions and registry interactions (such as Master Person Index). Technical committees will individually decide when a Control Act wrapper needs to be specified for a particular message. A generic wrapper definition is supplied as part of the Infrastructure ballot. Technical Committees may carry out refinement on the wrapper to meet their own needs. Future tooling will need to be able incorporate domain-specific wrappers when necessary. This is outside the capability of the current tooling.
+
The Control Act Wrappers are described in the HL7 standard in three separate domains:
 
+
*Message Control Act Infrastructure (MCAI) -defines the basic Trigger Event Control Act Wrapper.  
These wrappers are described in the HL7 ballot in three main groupings, described as separate domains:
+
*Query Infrastructure (QUQI) -describes how to use an extended version of the Control Act wrapper to support queries. The domain describes a generic parameter based query/response mechanism.
#Message Control Act Infrastructure (MCAI) -defining the Control Act itself.  
+
*Master File/Registry Infrastructure (MFMI) -describes how to use an extended version of the Control Act Wrapper to support master file and registry use-cases. The domain describes a generic pattern for the support of registry (e.g. MPI Master Patient Index) interactions.
#Query Infrastructure (QUQI) -which describes how to use the wrapper to support queries  
 
#Master File Infrastructure (MFMI)  
 
 
 
=== 3.9.3 Message Control Act Infrastructure ===
 
MCAI defines the detail of the Control Act. Key uses are for Query and Master File applications, these are summarised in the next two paragraphs.
 
 
 
=== 3.9.4 Query Infrastructure ===
 
The objective is to set up a general structure for queries and their response. Three messages are defined along with appropriate roles and interactions.  
 
#Query General Activate Query Continue
 
#Query General Response
 
#Query by Parameter specification
 
 
 
=== 3.9.5 Master File Infrastructure ===
 
A typical application is an MPI Master Patient Index. Again, the intention is to define a general set of messages that can be used to maintain any type of patient or professional database, or similar.
 
 
 
In these functional areas, there are no specific messages against the message functionality required. The Control Act is used to define what is needed, together with a set of standard trigger events, and an appropriate state diagram.
 

Revision as of 22:26, 7 August 2006

Section 3.9 of the v3Guide (May2006) needs to be updated to reflect the latest thinking on wrappers and infrastructure. The Wiki links have been added with the sole intent that terms are used in a consistent manner (i.e. glossary style); the links won't show up in the v3Guide in ballot or normative standard publications. The text below replaces the entire section 3.9, inclusive of all subsections 3.9.x.

3.9 Version 3 Message Wrappers and Infrastructure

HL7 Version 3 provides a substantial level of functionality in the provision of envelopes to support the transport (in a generic sense of the word) of HL7 messages from sender to receiver. HL7 calls these wrappers. Inside the wrappers is the domain content.

Message wrappers are defined in the same way as message content, by defining object classes and related relationships. These specifications can then be used to generate an ITS-defined syntax (e.g. XML schema) to go on the wire.

The Specification Infrastructure domain group (which consists of a number of wrapper related domains) specifies the two basic types of wrappers:

  • Transmission Wrapper – described in the (MCCI) Transmission Infrastructure domain.
  • Trigger Event Control Act Wrapper (also know as the Control Act Wrapper) – described in three domains, see below for details.

Whenever domain content (as a payload) is transmitted in the form of messages they will use the wrappers as defined by the above domains. A HL7 Version 3 message typically consists of a Transmission Wrapper, a Trigger Event Control Act wrapper (conditional) and the Domain Content (optional).

HL7 has defined a rich set of transmission oriented functions within the HL7 standards scope because there is no de facto way of providing these functions in a single standard that could be adopted. Messaging Infrastructure standards such as Webservices or ebXML provide similar functionality, whereas MLLP or FTP do not.

3.9.1 Transmission Wrapper

The HL7 Transmission wrapper is required for all Version 3 messages. It contains a large number of optional fields so the message overhead will vary from one context to another. Loosely coupled systems may require the use of a larger set of attributes than tightly coupled systems. This wrapper may be constrained to fit the requirements of a specific use-case or realm.

All Transmission Wrappers have mandatory attributes which identify the sending and receiving systems of a message transmission by means of a Device ID. Additional information about the Sender and Receiver may also be transmitted in other classes, but the use of a mandatory attribute ensures that a Messaging Infrastructure such as ebXML can base its addressing mechanism on the ID of the receiving Device as contained in the Transmission Wrapper.

Associated with use of the Transmission Wrapper are a number of services and features that are available as needed:

  • A message with a corresponding R-MIM has been defined to support the reporting of any syntax issues (or the lack of any issues) by the communication software of the receiving application. Note that this is not a reliability feature (although it has been inappropriately used as such in HL7 version 2), HL7 assumes that the underlying Messaging Infrastructure is reliable.
  • An optional message sequence number protocol. It is an essential component of supporting in-sequence delivery at the network level. It is not required if an external mechanism for in-sequence delivery is used (e.g. by means of Webservices or ebXML).
  • An optional set of functions and messages to support polling. These functions are included for compatibility with some early V2 use. Polling is probably a matter of limited interest to implementers, other than those with particular legacy problems.
  • An optional Batch Transmission Wrapper used to group messages for transmission purposes. On occasion one may want to group messages before transmitting them, e.g. a batch of financial charge messages, or a group of response messages to a single query message.

3.9.2 Trigger Event Control Act Wrapper

Additional richness in functionality is provided by the Trigger Event Control Act Wrapper (a.k.a. Control Act Wrapper), which is used when information about the interaction which has triggered a message needs to be communicated within that message to the receiver. Almost all Version 3 messages contain trigger related information. In some exceptional cases there is no need for such information to be included in the message. The Version 3 standard documents which Control Act Wrapper needs to be used for a particular message. A generic wrapper definition is supplied as part of the Specification Infrastructure domain. This wrapper may be constrained to fit the requirements of a specific use-case or realm.

Two particular areas of application of the Control Act Wrapper are query sessions and registry interactions (such as Master Person Index). Messages in those application areas use specializations (query or registration related extensions) of the basic Control Act Wrapper.

The Control Act Wrappers are described in the HL7 standard in three separate domains:

  • Message Control Act Infrastructure (MCAI) -defines the basic Trigger Event Control Act Wrapper.
  • Query Infrastructure (QUQI) -describes how to use an extended version of the Control Act wrapper to support queries. The domain describes a generic parameter based query/response mechanism.
  • Master File/Registry Infrastructure (MFMI) -describes how to use an extended version of the Control Act Wrapper to support master file and registry use-cases. The domain describes a generic pattern for the support of registry (e.g. MPI Master Patient Index) interactions.