An overview of the HL7 Version 3 interaction is given here for the purpose of conveying where information about a Version 3 interaction can be found by an application or message handling service that will be responsible for implementing the transport of HL7 Version 3 interactions. At the highest level, an HL7 Version 3 Interaction is composed of 2 parts:
An "HL7 Transmission wrapper(s)" (always)
The "HL7 Transmission Content" (optional)
HL7 Transmission Wrapper
A "HL7 Transmission wrapper" includes information needed by a sending application or message handling service to package and route the V3 interaction to the designated receiving application(s) and/or message handling service(s). This wrapper also includes attributes that influence the message handling behavior of the receiving application that is consistent with the HL7 defined messaging interaction for which the interaction has been created.
All HL7 Version 3 interactions have an appropriately configured "HL7 Transmission wrapper".
The HL7 Transmission Wrapper exists to two different forms:
The Message Transmission Wrapper. This wrapper contains zero or one instances of HL7 Transmission Content.
The Batch Transmission Wrapper. This wrapper contains zero or more Message Transmission Wrappers. Each Message Transmission Wrapper contains zero or one instances of HL7 Transmission Content. The Batch wrapper is occasionally used to group Message Transmissions.
An interaction that has the Message Transmission Wrapper as its "outermost" wrapper is commonly referred to as a "message" or a "message-based interaction". An interaction that has the Batch Transmission Wrapper as its "outermost" wrapper is commonly referred to as a "batch" or a "batch-based interaction".
HL7 Transmission Content The HL7 Transmission Content is comprised of 2 parts:
A "Trigger Event Control Act" (required for all messages except accept-level acknowledgements, for which it is not permitted)
The "HL7 Domain Content" specified by an HL7 domain specific technical committee (required for each Trigger Event Control Act)
The "Trigger Event Control Act" contains administrative information related to the "controlled act" which is being communicated as a messaging interaction. It is also the part of HL7 messages that can convey status or commands for logical operations being coordinated between healthcare applications, e.g., the coordination of query specification/query response interactions and registry act interactions.
The "HL7 Domain Content" is the primary domain content of the messaging interaction (when it is present). It contains domain specific content that is specified by an HL7 technical committee to satisfy a use case driven requirement for an HL7 messaging interaction. If an interaction contains HL7 Domain Content, then it also contains a Trigger Event Control Act.
Levels of Acknowledgement
The HL7 standard has historically maintained "Application (Level 7) Processing Rules" regardless of the lower layer protocols of the communications environment to guarantee reliable message delivery. Briefly, these rules specify
A commit-level acknowledgement by a receiver
An accept-level acknowledgement by a transmission receiver
An application level response by an interaction receiver
The HL7 transmission wrapper will specify what levels of acknowledgement will be provided by the receiving system and/or application. The levels are the commit-level, the accept-level and the application-level.
Commit Level Acknowledgement
A commit-level acknowledgement is sent once the transmission has been saved to reliable storage by the protocol software on the receiving system. The implementation of the commit-level acknowledgement will differ depending on the underlying Transport Protocol. The commit-level acknowledgement is not an HL7 interaction, and is out of scope of this domain.
Note that all Transmission Infrastructures have to offer support for reliable messaging as of Release 2 of this domain. See the Abstract Transport Protocol domain for details of this requirement.
Accept Level Acknowledgement
The protocol software on the receiving system makes an initial determination as to whether or not the interaction can be accepted, based on factors such as:
The syntactical correctness of the interaction, if the design of the receiving system includes this type of validation at this phase
The interaction identifier, structure type identifier, version, processing code, processing mode code, if the design of the receiving system includes this type of validation at this phase.
The Sending system will determine (as conveyed in the HL7 Transmission Wrapper) whether or not an accept-level acknowledgement has to be sent by the Receiver. All receiving applications have to be able to send an accept-level error interaction should they discover an issue which prevents them from processing an interaction. All sending applications are required to be able to receive and process these accept-level interactions. (they may do this by e-mailing the system manager, or flag something in an audit file, the exact process is left up to the application).
Notes:
An accept-level error interaction may be generated by any routing application (e.g. interface engines) or by its destination. The Sending system should process these accept-level errors as if they were sent by the Receiver. See the Abstract Transport Specification for a description of the expected behaviour of Intermediaries, Bridges and Gateways.
Accept-level acknowledgement interactions are always sent to the sending device as contained in the Transmission Wrapper. The RespondTo class of the initial interaction is not used.
Application Level Response
If the interaction, as indicated by the interaction identifier in the HL7 transmission wrapper, indicates that the initiating system also requires an application response (a.k.a. application acknowledgment, functional response, or query response), this can be returned as an immediate response or as the initial message of a later (or deferred) exchange.
For the Application Level Response, the receiving system acts as the initiator. Since the interaction the receiving system sends is application-specific, the models of these application-level response interactions are defined in the relevant application-specific domain. Whether an application response may request another application acknowledgement interaction, is dependent on the design of the message interaction sequence as defined in the relevant application-specific domain.
Application-level response interactions are sent to the RespondTo device as contained in the Transmission Wrapper of the initial interaction. If the RespondTo class is not present in the initial interaction is not used, the response interaction will be sent to the Sender device.
No comments:
Post a Comment