 ANSI/HL7 IMTRANS, R2-2016 HL7 Version 3 Standard: Transmission Infrastructure, Release 2 8/5/2016 |
Content Last Edited: 2016-01-23T19:38:06
2.2 Storyboards
2.3 Application Roles
2.4 Trigger Events
2.5 Refined Message Information Models
2.6 Hierarchical Message Descriptions
2.7 Interactions
This topic addresses those aspects about the communications environment that are considered to be common to all HL7 Version 3 messaging implementations. This topic includes a specification for the composite HL7 version 3 message as well as a specification of the interrelationships in the flow of messages and the communication of significant application level exceptions or error conditions.
The Generic Message Transmission topic in the HL7 Version 3 messaging standard addresses:
- The definition of transmission oriented wrappers (static models). These wrappers shall be used in all message interactions; they identify (amongst other things) the HL7 message interaction itself as well as the sending and receiving entities.
- The enforcement of a generic mode of message handling that is called for by the relationship between interactions and generic communication roles.
The Infrastructure and Messaging Work Group invites implementers with additional requirements to submit content proposals for future releases of the standard.
|
||||||||||||||||
|
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
The reader is referred to the introduction of this domain for a detailed discussion regarding use cases and to the state-based storyboards.
Note: The examples can be combined into more complex scenarios as needed by a domain.
Send HL7 Message Payload where no acknowledgement is required.
| Send Message Payload - No Acknowledgements |  MCCI_IN000000UV02 |
Describes the simple messaging scenario where a composite HL7 message payload is sent from the Sending Role to the Receiving Role without the requirement of any acknowledgement of the message reception by the Receiving Role.
An example would be a broadcast of an admit notification message where the sending application does not request an Accept Acknowledgement
Send HL7 Message Payload where accept level acknowledgement is required.
| Send Message Payload w/ Accept Acknowledgement | MCCI_IN000001UV02 |
| Accept Ack | MCCI_IN000002UV02 |
Describes the simple messaging scenario where a composite HL7 message payload is sent from the Sending Role to the Receiving Role and there is a requirement for the Receiving Role to acknowledge the message reception by sending an accept level acknowledgement message to the original Sending Role.
An example would be a broadcast of an admit notification message where the sending application requests an Accept Acknowledgement
Send HL7 Message Payload where immediate application level acknowledgement is requested and the Sending Communication Role can handle an immediate application level response instead of an application acknowledgement to the original message request.
| Send Req Msg w/ App Ack (Immed) can handle App Rsp | MCCI_IN000009UV02 |
| Application Response Request (Immed) | MCCI_IN000010UV02 |
| Application Response Request Ack (Immed) | MCCI_IN000011UV02 |
Describes the messaging scenario where a composite HL7 message payload is sent from the Sending Role to the Receiving Role and there is a requirement for the Receiving Communication Role to respond immediately with either an application level acknowledgement or an immediate application response request message. In the latter case, the original Sending Communication role must respond with an immediate application acknowledgement message (see next paragraph). Note, the requirement for immediate responses to all message interactions requires both the Sending Communication Role and the Receiving Communication Role to be able to respond to all messages received within a "reasonable" amount of time. If this requirement cannot be guaranteed, then the deferred processing mode should be used.
The additional requirement for this case means that the Sending Communication Role is able to handle an immediate application response request message to the initial HL7 message payload sent and the original Receiving Communication Role and expects an immediate application acknowledgement message to be forwarded by the original Sending Communication Role from the original sending healthcare application. This exchange of information will indicate whether the original sending healthcare application accepts or rejects the content of the received HL7 message payload. This exchange of information may optionally include an HL7 message payload to be returned to the original sending healthcare application. The original Sending Communication Role takes the result of the information exchange with the Receiving Communication Role and is able to respond with an application level acknowledgement message prepared by the local healthcare application with a minimal delay. The original Receiving Communication Role will receive the immediate application level response message and forward it to the original receiving healthcare application to complete the interaction sequence.
If the Sending Communication Role receives an application level acknowledgement to the original HL7 message payload from the Receiving Communication Role (and not the additional case as discussed in the preceding paragraph), it will then forward the application response to the original sending healthcare application to end the interaction sequence.
Send HL7 Message Payload where immediate application level acknowledgement is required.
| Send Request Message w/ Application Ack (Immed) | MCCI_IN000003UV02 |
| Application Acknowledgement 1 (Immed) | MCCI_IN000004UV02 |
The messaging scenario where a composite HL7 message payload is sent from the Sending Role to the Receiving Role and there is a requirement for the Receiving Communication Role to process an immediate application level acknowledgement. This requires the Receiving Communication Role to be able to establish an exchange of information with the healthcare application to whom the message is was intended in a "reasonable" amount of time. This exchange of information will indicate whether the healthcare application accepts or rejects the content of the received HL7 message payload. This exchange of information may optionally include an HL7 message payload to be returned to the original sending healthcare application. The Receiving Communication Role takes the result of the information exchange with the receiving healthcare application and returns an application level acknowledgement message to the original Sending Communication Role. The original Sending Communication Role will receive the "immediate" application level response message and forward the application response to the original sending healthcare application.
Send HL7 Message Payload where deferred application level acknowledgement is requested and accept level acknowledgements are required on each initiating message communication.
| Send Request Message w/ Application Ack (deferred) | MCCI_IN000005UV02 |
| Accept Ack on Request Message | MCCI_IN000006UV02 |
| Application Acknowledgement (deferred) | MCCI_IN000007UV02 |
| Accept Ack on Appl Ack (deferred) | MCCI_IN000008UV02 |
Describes the messaging scenario where a composite HL7 message payload is sent from the Sending Role to the Receiving Role and there is a requirement for the Receiving Communication Role to process a deferred application level acknowledgement. Additionally, accept level communication acknowledgements are required on each initial message send. This allows the Receiving Communication Role not to be constrained by time to response with an exchange of information with the original sending healthcare application. This exchange of information will indicate whether the healthcare application accepts or rejects the content of the received HL7 message payload. This exchange of information may optionally include an HL7 message payload to be returned to the original sending healthcare application. The Receiving Communication Role takes the result of the information exchange with the receiving healthcare application and returns an application level acknowledgement message to the original Sending Communication Role. The original Sending Communication Role will receiving the "deferred" application level response message and immediately respond with an accept level acknowledgement to the this message's originator. The original Sending Communication Role will then forward the application response to the original sending healthcare application.
Send HL7 Message Payload where deferred application level acknowledgement is requested and the Sending Communication Role can handle a deferred application level response instead of an application acknowledgement to the original message request. Accept level acknowledgements are required on each initiating message communication.
| Send Req Msg w/Appl Ack (Def) can handle App Resp | MCCI_IN000012UV02 |
| Accept Ack on Request Msg can handle Appl Resp | MCCI_IN000013UV02 |
| Application Response Request (Deferred) | MCCI_IN000014UV02 |
| Accept Ack on Application Response Request | MCCI_IN000015UV02 |
| Application Reponses Request Ack (Deferred) | MCCI_IN000016UV02 |
| Accept Ack on Application Reponses Request Ack | MCCI_IN000017UV02 |
Describes the messaging scenario where a composite HL7 message payload is sent from the Sending Role to the Receiving Role and there is a requirement for the Receiving Communication Role to process a deferred application level acknowledgement with accept level communication acknowledgements for each initial message send. This allows the Receiving Communication Role to not be constrained by time to response with an exchange of information with the original sending healthcare application.
Additionally, the Sending Communication Role is able to handle the case where the Receiving Communication Role does not send an application acknowledgement message, but sends an application response request message to the Original Sending Communication Role and expects an application acknowledgement message to be forwarded by the original Sending Communication Role from the original sending healthcare application. This exchange of information will indicate whether the original sending healthcare application accepts or rejects the content of the received HL7 message payload. This exchange of information may optionally include an HL7 message payload to be returned to the original sending healthcare application. The original Sending Communication Role takes the result of the information exchange with the receiving healthcare application and immediately responds with an accept-level acknowledgement to this message's originator. It passes the content of the received HL7 message on to the original sending healthcare application that is capable of preparing an application level acknowledgement message. The original Sending Communication Role is given the application level acknowledgement message and sends it to the original Receiving Communication Role. The original Receiving Communication Role will receive the "deferred" application level response message and immediately respond with an accept level acknowledgement to the this message's originator. The original Receiving Communication Role will then forward the application response to the original receiving healthcare application.
If the Sending Communication Role receives an application level acknowledgement to the original HL7 message payload from the Receiving Communication Role (and not the additional case as discussed in the preceding paragraph), it will respond with an accept-level acknowledgement to the Receiving Communication Role. The original Sending Communication Role will then forward the application response to the original sending healthcare application.
|
||||||||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
The justification for HL7 Communication Roles for Version 3 message control comes from a need to formalize the expectations of HL7 Application Roles for messaging communication services. Application Roles specify the expected message handling behavior for a set of interactions. The HL7 Message Development Framework has led to the creation of numerous Application Roles by the technical committees that are developing HL7 Version 3 messaging interactions. Communication Roles are intended to specify a core set of messaging communication services that can support the messaging communication requirements of HL7 Application Roles.
Note: These application roles are not used in their own right except for the inplementable interactions in this domain. Accept-level acknowledgements fall into this category. Domain interactions will define, and reference, two domain application roles.
Send HL7 composite message payloads.
Send HL7 composite message payloads. Expects no acknowledgement messages.
Send HL7 composite message payloads. Require accept-level acknowledgements.
Receive HL7 composite message payloads.
Receive HL7 composite message payloads. Does not acknowledge message receptions.
Receive HL7 composite message payloads. Send accept-level acknowledgements.
Send application response request.
Send application request HL7 composite message payloads. Require immediate application-level acknowledgements.
Send application request HL7 composite message payloads. Require immediate application-level acknowledgement. Can handle immediate application response request with an immediate application acknowledgement.
Send application request HL7 composite message payloads. Require deferred application-level acknowledgements with accept-level acknowledgements for initial message sends.
Send application request HL7 composite message payloads. Require deferred application-level acknowledgement. Can handle deferred application response request with a deferred application acknowledgement. Accept-level acknowledgements required for initial message sends.
Receive application response request.
Receive application request HL7 composite message payloads. Send immediate application-level acknowledgements.
Receive application request HL7 composite message payloads. Send immediate application-level acknowledgement or an immediate application response request. Application response request messages require an application level response from original application request sender.
Receive application request HL7 composite message payloads. Send deferred application-level acknowledgement or a deferred application response request. Application response request messages require an application level response from original application request sender. Accept-level acknowledgements required for initial message sends.
Receive application request HL7 composite message payloads. Send deferred application-level acknowledgements. Accept-level acknowledgements required for initial message sends.
|
||||||||||||||||
|
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
Communication level message control in HL7 Version 3 is defined by the handling of the events and state transitions identified in the Version 3 HL7 Message Control state diagram. Refer to domain interactions for domain trigger events.
| Type: | State-transition based |
| State Transition: | Message (MCCI_RM000100UV02) |
The processing of a send operation on an HL7 Composite Message Payload has started.
Note: This trigger event is for communication infrastructure purposes only. Domain interactions will define the Transmission Wrapper, domain trigger events, application roles, and domain payload.
| Type: | State-transition based |
| State Transition: | Message (MCCI_RM000200UV02) |
An HL7 Composite Message Payload send operation has been accepted for a guaranteed delivery.
Note: This trigger event is for communication infrastructure for accept-level acknowledgements which are implementable as a receiver responsibility.
| Type: | State-transition based |
| State Transition: | Message (MCCI_RM000200UV02) |
An application response to a request for application action has been accepted for guaranteed delivery to the originator of the application request for action.
Note: This trigger event is for communication infrastructure for accept-level acknowledgements which are implementable as a receiver responsibility.
| Type: | State-transition based |
| State Transition: | Message (MCCI_RM000300UV02) |
In response to an application response request, the application responsible for the initial request for action has started a send operation on an application level response to the proposed alternative request for action.
Note: This trigger event is for communication infrastructure purposes only. Domain interactions will define the Transmission Wrapper, domain trigger events, application roles, and domain payload.
| Type: | State-transition based |
| State Transition: | Message (MCCI_RM000300UV02) |
The processing of an application level acknowledgement has occurred in response to an HL7 Composite Message Payload send operation for a requested application action.
Note: This trigger event is for communication infrastructure purposes only. Domain interactions will define the Transmission Wrapper, domain trigger events, application roles, and domain payload.
| Type: | State-transition based |
| State Transition: | Message (MCCI_RM000300UV02) |
An application that received a request for application action is responding with an alternative application action that is to replace the original request for action.
Note: This trigger event is for communication infrastructure purposes only. Domain interactions will define the Transmission Wrapper, domain trigger events, application roles, and domain payload.
|
||||||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
| Parent: | Transmission Infrastructure (MCCI_DM000000UV) |
Describes the contents of the outer transport wrapper for HL7 V3 composite message payloads.
Note: This will not be implemented in its own right. Domain interactions will reference the appropriate Transmission Wrapper.
| Send Message Payload | MCCI_HD000100UV02 |
| Parent: | Transmission Infrastructure (MCCI_DM000000UV) |
Describes general message control acknowledgement structure for communication level acknowledgements.
Note: This message type is implementable as a receiver responsibility.
| Accept Acknowledgement | MCCI_HD000200UV02 |
| Parent: | Transmission Infrastructure (MCCI_DM000000UV) |
Describes structure of outer transport wrapper for general application acknowledgement messages.
Note: This will not be implemented in its own right. Domain interactions will reference the appropriate Transmission Wrapper.
| Application Acknowledgement | MCCI_HD000300UV02 |
|
||||||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
Describes the contents of the outer transport wrapper for HL7 V3 composite message payloads.
Note: This will not be implemented in its own right. Domain interactions will reference the appropriate Transmission Wrapper.
| R_NotificationPartyContact | COCT_MT040203UV09 |
| Send Message Payload | MCCI_MT000100UV02 | |
Describes general message control acknowledgement structure for communication level acknowledgements.
Note: This message type is implementable as a receiver responsibility.
| R_NotificationPartyContact | COCT_MT040203UV09 |
| Accept Acknowledgement | MCCI_MT000200UV02 | |
Structure of transmission wrapper for general application acknowledgement messages.
Note: This will not be implemented in its own right. Domain interactions will reference the appropriate Transmission Wrapper.
| R_NotificationPartyContact | COCT_MT040203UV09 |
| Application Level Acknowledgement | MCCI_MT000300UV02 | |
|
||||||||||||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
Send Message Payload with no Acknowledgements. Note: This interaction is for communication illustration purposes only. Refer to domain defined interactions which will indicate the appropriate transmission wrapper.
| Trigger Event | Send Message | MCCI_TE000001UV02 |
| Sender | Notification Message Sender (no Acks) | MCCI_AR000001UV02 |
| Receiver | Notification Message Receiver (no Ack) | MCCI_AR000002UV02 |
Send Message Payload w/ Accept Acknowledgement. Note: This interaction is for communication illustration purposes only. Refer to domain defined interactions which will indicate the appropriate transmission wrapper.
| Trigger Event | Send Message | MCCI_TE000001UV02 |
| Reason | Trigger Event | Interaction |
| Accept Acknowledgement is required by Communication Role. | MCCI_IN000002UV02 |
| Sender | Notification Message Sender with Accept Ack | MCCI_AR000003UV02 |
| Receiver | Notification Message Receiver with Accept Ack | MCCI_AR000004UV02 |
Accept Acknowledgment by Sender to the Receiver Note: This interaction is invoked, where appropriate, as a receiver responsibility. This message would not contain a domain payload.
| Trigger Event | Send Message Accept Acknowledgement | MCCI_TE000002UV02 |
| Sender | Notification Message Sender | MCCI_AR900001UV02 |
| Receiver | Request Message Receiver | MCCI_AR900004UV02 |
Accept Acknowledgement on Application Response Request Acknowledgement. Note: This interaction is invoked, where appropriate, as a receiver responsibility.
| Trigger Event | Send Message Accept Acknowledgement | MCCI_TE000002UV02 |
| Sender | Request Rcvr may snd App Rspns Req (Deferred) | MCCI_AR000012UV02 |
| Receiver | Request Sndr can hndl App Rspns Req (Deferred) | MCCI_AR000011UV02 |
Accept Acknowledgement on Application Response Request. Note: This interaction is invoked, where appropriate, as a receiver responsibility.
| Trigger Event | Send Message Accept Ack to Application Response | MCCI_TE000004UV02 |
| Sender | Request Sndr can hndl App Rspns Req (Deferred) | MCCI_AR000011UV02 |
| Receiver | Request Rcvr may snd App Rspns Req (Deferred) | MCCI_AR000012UV02 |
Accept acknowledgement on application level acknowledgement (deferred). Note: This interaction is invoked, where appropriate, as a receiver responsibility.
| Trigger Event | Send Message Accept Ack to Application Response | MCCI_TE000004UV02 |
| Sender | Request Sndr w/ App Ack (with Accept AckDeferred) | MCCI_AR000007UV02 |
| Receiver | Request Rcvr w/ App Ack (with Accept AckDeferred) | MCCI_AR000008UV02 |
Accept Acknowledgement on Request Message. Note: This interaction is invoked, where appropriate, as a receiver responsibility.
| Trigger Event | Send Message Accept Acknowledgement | MCCI_TE000002UV02 |
| Sender | Request Rcvr w/ App Ack (with Accept AckDeferred) | MCCI_AR000008UV02 |
| Receiver | Request Sndr w/ App Ack (with Accept AckDeferred) | MCCI_AR000007UV02 |
Accept Acknowledgement on Request Message. Note: This interaction is invoked, where appropriate, as a receiver responsibility.
| Trigger Event | Send Message Accept Acknowledgement | MCCI_TE000002UV02 |
| Sender | Request Rcvr may snd App Rspns Req (Deferred) | MCCI_AR000012UV02 |
| Receiver | Request Sndr can hndl App Rspns Req (Deferred) | MCCI_AR000011UV02 |
Application Response Request (Immed). Note: This interaction is for communication illustration purposes only. Refer to domain defined interactions which will indicate the appropriate transmission wrapper.
| Trigger Event | Send Message Application Response Rqst (Deferred) | MCCI_TE000005UV02 |
| Reason | Trigger Event | Interaction |
| Application Response Request Acknowledgement required by Communication Role. | MCCI_IN000011UV02 |
| Sender | Request Rcvr may send App Rspns Req (Immed) | MCCI_AR000010UV02 |
| Receiver | Request Sndr can hndl App Rspns Req (Immed) | MCCI_AR000009UV02 |
Send immediate application level acknowledgement. Note: This interaction is for communication illustration purposes only. Refer to domain defined interactions which will indicate the appropriate transmission wrapper.
| Trigger Event | Send Message Application Acknowledgement (Remote) | MCCI_TE000003UV02 |
| Sender | Request Rcvr w/ App Ack (Immed) | MCCI_AR000006UV02 |
| Receiver | Request Message Sender with App Acks (Immediate) | MCCI_AR000005UV02 |
Send deferred application level acknowledgement. Note: This interaction is for communication illustration purposes only. Refer to domain defined interactions which will indicate the appropriate transmission wrapper.
| Trigger Event | Send Message Application Acknowledgement (Remote) | MCCI_TE000003UV02 |
| Reason | Trigger Event | Interaction |
| Accept Acknowledgement required by Communication Role. | MCCI_IN000008UV02 |
| Sender | Request Rcvr w/ App Ack (with Accept AckDeferred) | MCCI_AR000008UV02 |
| Receiver | Request Sndr w/ App Ack (with Accept AckDeferred) | MCCI_AR000007UV02 |
Application Response Request Acknowledgement (Deferred). Note: This interaction is for communication illustration purposes only. Refer to domain defined interactions which will indicate the appropriate transmission wrapper.
| Trigger Event | Send Message Application Acknowledgement (Immed) | MCCI_TE000006UV02 |
| Reason | Trigger Event | Interaction |
| Accept Acknowledgement required by Communication Role. | MCCI_IN000017UV02 |
| Sender | Request Sndr can hndl App Rspns Req (Deferred) | MCCI_AR000011UV02 |
| Receiver | Request Rcvr may snd App Rspns Req (Deferred) | MCCI_AR000012UV02 |
Application Response Request Acknowledgement (Immed). Note: This interaction is for communication illustration purposes only. Refer to domain defined interactions which will indicate the appropriate transmission wrapper.
| Trigger Event | Send Message Application Acknowledgement (Immed) | MCCI_TE000006UV02 |
| Sender | Request Sndr can hndl App Rspns Req (Immed) | MCCI_AR000009UV02 |
| Receiver | Request Rcvr may send App Rspns Req (Immed) | MCCI_AR000010UV02 |
Application Response Request (Deferred). Note: This interaction is for communication illustration purposes only. Refer to domain defined interactions which will indicate the appropriate transmission wrapper.
| Trigger Event | Send Message Application Response Rqst (Deferred) | MCCI_TE000005UV02 |
| Reason | Trigger Event | Interaction |
| Accept Acknowledgement Required by Communication Role. | MCCI_IN000015UV02 | |
| Application Acknowledgement or Application Response Request Acknowledgement required by Communication Role. | MCCI_IN000016UV02 |
| Sender | Request Rcvr may snd App Rspns Req (Deferred) | MCCI_AR000012UV02 |
| Receiver | Request Sndr can hndl App Rspns Req (Deferred) | MCCI_AR000011UV02 |
Send application request HL7 composite message payload. Require immediate application level acknowledgement. Note: This interaction is for communication illustration purposes only. Refer to domain defined interactions which will indicate the appropriate transmission wrapper.
| Trigger Event | Send Message | MCCI_TE000001UV02 |
| Reason | Trigger Event | Interaction |
| Application Acknowledgement is required by Communication Role. | MCCI_IN000004UV02 |
| Sender | Request Message Sender with App Acks (Immediate) | MCCI_AR000005UV02 |
| Receiver | Request Rcvr w/ App Ack (Immed) | MCCI_AR000006UV02 |
Send Request Message w/ Application Ack (Immed) can handle App Response. Note: This interaction is for communication illustration purposes only. Refer to domain defined interactions which will indicate the appropriate transmission wrapper.
| Trigger Event | Send Message | MCCI_TE000001UV02 |
| Reason | Trigger Event | Interaction |
| Application Response Request is required by Communication Role. | MCCI_IN000010UV02 |
| Sender | Request Sndr can hndl App Rspns Req (Immed) | MCCI_AR000009UV02 |
| Receiver | Request Rcvr may send App Rspns Req (Immed) | MCCI_AR000010UV02 |
Send Request Message w/ Application Ack (Deferred) can handle Application Response Request. Note: This interaction is for communication illustration purposes only. Refer to domain defined interactions which will indicate the appropriate transmission wrapper.
| Trigger Event | Send Message | MCCI_TE000001UV02 |
| Reason | Trigger Event | Interaction |
| Accept Level Acknowledgement required by Communications Role. | MCCI_IN000013UV02 | |
| Application Response Request or Application Acknowledgement required by application role. | MCCI_IN000014UV02 |
| Sender | Request Sndr can hndl App Rspns Req (Deferred) | MCCI_AR000011UV02 |
| Receiver | Request Rcvr may snd App Rspns Req (Deferred) | MCCI_AR000012UV02 |
Send application request HL7 composite message payload. Require deferred application-level acknowledgement with accept-level acknowledgements for initial message sends. Note: This interaction is for communication illustration purposes only. Refer to domain defined interactions which will indicate the appropriate transmission wrapper.
| Trigger Event | Send Message | MCCI_TE000001UV02 |
| Reason | Trigger Event | Interaction |
| Accept Acknowledgement is required by Communication Role. | MCCI_IN000006UV02 | |
| Deferred Application Acknowledgement is required. | MCCI_IN000007UV02 |
| Sender | Request Sndr w/ App Ack (with Accept AckDeferred) | MCCI_AR000007UV02 |
| Receiver | Request Rcvr w/ App Ack (with Accept AckDeferred) | MCCI_AR000008UV02 |
| Return to top of page |