“v3 Dynamic Model”
Proposal#806
For Discussion by CQ
- Updated up to 2004-08-17 10:00 UTC –
Editor : René Spronk,
The contents of this document have been placed in the public domain. Note that the images in this document are based on HL7 Artifacts, these are © HL7 Inc.
Content Page
1. Introduction 2
1.1. Response levels 3
1.2. Accept/commit ack 8
1.2.1. Commit ack 8
1.2.2. Accept Rejection 11
1.3. Application responses 11
1.3.1. Response mode (immediate/deferred/polled) 13
1.3.2. One or many responses 15
1.3.3. Eavesdropping 15
1.4. Routing & relaying of messages 17
1.5. Documentation of dynamic modelling artefacts 20
Introduction
Note: the enhancements related to routers/relay applications and the constraining of the dynamic model towards a simpler version are for R2 (2006+) of the Infrastructure Management domain, not for R1 (2004).The v3 material describes the dynamic model. A discussion was started in an attempt to simplify and/or clarify the dynamic model in v3. This document tries to summarize the discussion by including snippets from e-mails written by various persons. Only those snippets have been included where they express some degree of consensus.
Once a subject has been detailed in a proposal, the snippets that point towards the conclusion as described in the proposal will be deleted from the document to limit it’s size. Only those snippets that address issues not (yet) covered by the proposal will continue to be listed.
The model needs to have the following characteristics:
· It is the intent to simplify the existing dynamic model without breaking the inherent understanding that the HL7 community has of the dynamic model. Let's try and sort out what needs sorting rather than redesigning from scratch.
· To be truly successful in the domain currently implemented in V2, we need to be ready for a lot of V2 to V3 interfacing to occur - things need to map well.
· Once a vendor implements a decent infrastructure, they probably won't feel like changing it. So our initial V3 infrastructure that first gets wide implementation may be one of the only ones we ever see.
· we have a chance to make a leap in advancement - if we leap too far, we won't get enough jumpers. If we leap too little, we might not get enough advancement.
· I want to be confident that we're not going to have tremendous 'backward-compatibility' grief in making the changes we feel are necessary for Relese 2.0.
· We need to get a level of comfort that the committee is going to be willing to make such a significant change.
Response levels
(Lloyd) The response levels (based on Mike's note) therefore are:
1. Have you received and stored it (commit ack)? (Until you receive this, keep resending on assumption they haven't gotten yet) „I've received it, stored it“
2. Have you been able to parse and process it (accept ack)? (Until you receive this, be prepared to resend because the message might have been corrupted) „I can understand it enough to deliver it where it needs to go - please stop sending it“
3. Are you willing to do it? (application response/application ack) (Until you receive this, be prepared to send the request to someone else, or modify the request to ensure that something actually gets done.) "Yes, I will do what you asked", "Yes, I will do what you asked – and I’ve already done it", "No, I won't do what you asked", "No, I won't do that, but I could do this instead . . .".
Proposal Statement #806.7: (20040930: CQ WGM THU Q3, approved 7-1-4)Note: As detailed in proposal #901.1, all message transmissions are guaranteed, all underlying transport protocols support reliable messaging. This specific proposal only addresses the HL7 dynamic model, not the dynamic behaviour that is internal to the underlying transport protocol. That internal behaviour, including the use of ‘commit acks’ will be detailed in the transport specification.
Accept the following description of the dynamic ack/nak model as the basis for the dynamic model in R2.
1.The message is sent.
2. Followed by one of A or B:
A) Accept Rejection (a.k.a. Accept NAK, OSI-layer 6 issues)
Ok, I've now started to look at your message, and there's some serious problem at the parsing or conformance level. Therefore I'm not going to process it. Please fix and try again. An Accept Rejection message is sent to the sending application.
The accept NAK may be generated by any routing application (e.g. interface engines) or by its destination.
B) Message Acceptance: I've been able to parse your message, it's directed at the correct place and seems to be valid according to the balloted spec. I'm therefore going to start processing it.
If there are NO receiver responsibilities, nothing (no positive accept acknowledgement) will be sent back.
If the interaction has reciever responsabilities attached to it, then the processing results in one of the following messages:
i) Rejection Application Response (OSI-layer 7 issues, and remaining OSI-layer 6 issues)
Sorry, I'm unable to do what you asked me to do, and this receiver responsibility message has a payload explaining why
ii) Confirmation Application Response
Ok I have done/will do what you ask
iii) Application Response (other than confirmation/rejection)
e.g. I can't do that, but I could do this instead.
In terms of where responses go, the following rules apply:
· Accept Rejections go to whoever's identified as the "message sender"
· Application Responses go to whoever's identified in the "Respond To" in the Transmission Wrapper, or (if there isn't one), to whoever's identified as the "message sender"
(in favor: Lloyd, Rene, Andrew, Mike, Miroslav, Lloyd)
FAQ: The behaviour as proposed by 806.7 can be accomplished in HL7 version 3 ballots before 2005 as follows:· Set Message.acceptAckCode to “ER” in all messages except accept level reject messages;
· Set Message.acceptAckCode to “NE” in accept level reject messages.
(Rene) Is your question: why is there no accept ACK, whereas there is an accept NACK ?
Well,
1. Various persons on this thread have indicated that they're only interested in rejections.
2. In almost 100% of implementations of accept acks in v2, they're actually used as v3 commit acks, i.e. no syntax checking is done.
This raise the question: how do we avoid that the accept ack is used for a different purpose than what it was intended for ? In v2 it is effectively only used as a commit ack.
If interface engines are allowed to create v3 accept acks, then we're back to square one, they are guaranteed to be 'faked' and be used as commit acks.
Given that we already have a commit ack at the transport protocol level, there is NO NEED for an accept ack, so let's get rid of it and only use a accept NAK. (no accept ack = no problem with them being used for unintended purposes)
If I send a message via a series of routers/interface engines to its destination, and I receive an accept NAK from any of these systems, that's fine. Someone has detected an error in my message header stuff, I have to correct it and send again. A NAKs from one of these parties has a value to me as a sender. (This also means that accept NAKs have to be routed to the orginal sender of the mesage, not just to the 'previous router' in the series, as most v2 implementations do)
If I send a message and get an accept ACK, then what does that say ? It says that the next router in the chain has accepted my message header. The one after that may refuse however refuse it because it is more critical than the first one. So it sends an accept NAK. As the original sender I get 2 responses (which I don't really like if I'm working in synchronous mode), and it provides me with a rather mixed "message", since I get both an aye as well as a nay vote.
This is the reason for wanting to get rid of the accept ACK.
If the message was successful (at the accept level), and if there was a reciever responsability, I'll get the application response. That is proof enough.
If the message was successful (at the accept level), and there isn't a reciever responsability (i.e. in case of a notification), then the sender gets no response. If it wants a response, it should have used an interaction that carries a reciever responsability, as domains are free to define reciever responsabilities for notifications if they choose to do so.
If someone is aware of a solid use-case which requires the accept ack, then please step forward and tell us.. Lloyd an I can't think of one.
(Rene) (Assuming for a second we keep the accept ACK:) An additional problematic use-case: what if the message is kept 'on hold' in a queue on an interface engine for a couple of hours (because the destination system is temporarily unavailable) ? The sender has received its commit ack from the integration engine. But it won't recieve an accept ack nor an application response from the destination, even though there was no problem whatsoever with the original message. Relying on timeouts/delays is extremely tricky, i.e. the dynamic model should never rely on timing.
(Lloyd) Anyone can make the statement "I don't support/can't parse/can't validate". However, only the end recipient can make the statement "I do support and have parsed & validated". Thus Accept NAKs can be created by anyone, but Accept ACKs can only be created by the end recipient, and as a result are redundant with the application response.
(Rene) True – but what is the use-case for this message (the accept ACK) ?
(Rene) The sequencing of messages can't be guaranteed at the transport level. Imagine an environment with various paralel routes to the destination. 'commit' acks are recived from the next router in the link, not by the final destination of the message. The destination application is the only one who can check proper sequencing.
For that reason the sequence number protocol needs to be supported by the accept NAK or the application response.
1. Send message
2. if the message was an immediate/synchronous message that carries receiver responsabilities: block, wait for either an Accept Rejection (go to A) or an application response (go to B).
3. Go to 1.
Now if your message was deffered/asynchronous, or if you timed out on step 2, you may recieve, at any point in time, an accept rejection or an application response.
A. If accept rejection, then there was a syntactic issue with a previously sent message, You'd better have some archives/auditing files/message database. The message was not processed by its intended destination, so you shall resolve the issue and send a corrected message (Go to 1).
B. If application response, check its validity, send an accept rejection if not correct. If correct, process the message. If there are reciever responsabilities related to this application response, then create your own application response; send application response (Go to 1)
FAQ: Sender behaviour in case of an interaction without receiver responsibilities:
1. Send message
2. Go to 1.
You may recieve, at any point in time, an accept rejection. There was a syntactic issue with a previously sent message, You'd better have some archives/auditing files/message database. The
message was not processed by its intended destination, so you shall resolve
the issue and send a corrected message (Go to 1).
(Rene) The classic use-case for RespondTo is a query by A to B, and responses being sent from B to C. This either because C doesn't support queries, or in a form of pre-fetching of information. Patient Everyman has an appointment with department D tomorrow morning, so the scheduling application sends a query to the EHR system to send all available info to department D's decision support system.
Proposal #806.11All receiving applications have to be able to send an accept reject should they discover an issue which prevents them from processing the message, all senders are required to be able to receive and process these accept rejects. (they may do this by e-mailing the system manager, or flag something in an audit file, the exact process is up to the application).
(in favor: Rene, Kreso, Mike, Miroslav, Virginia, Lloyd)
(Virginia) The bottom line is, does doing this improve conformance and interoperability - does it get me closer to plug and play and over time reduce my interface negotiation costs. It sounds like it has potential.
One of the highly marketed goals of V3 is reduced optionality. If I hear a persuasive sales pitch enough times, I buy it.
(Dick) Well the problem that we have had to deal with occurs when the sender fails to process NACK messages (receives them and ignores them).
I believe that V3 needs to make the sender responsible for dealing with NACKs in some way. But it needs to accept them, process them and deal with them.
The responsibility for dealing with the actual problem must be subject to some operational discussion between the parties as such errors occur.
(Rene) To twist things around: suppose that they didn't have this requirement. Being the lazy programmers we all are we'll ignore all inbound NAKs (Dick's issue). Which means there's no real good usecase to send them either. Which in turn means a sender can never be sure the mesage was accepted or not, and that the receiver can't report the fact that it has detected issues. Hmm. Sounds like v2 to me
In this case we really have only 2 options: make accept NAKs mandatory accross the board for all interactions, or to do away with them entirely. There is no way inbetween these extremes for that would automatically degrade to near zero usage.
Of these 2 options we have chosen to document the "mandatory support" case; to obtain a quality of mesaging that is better than that of v2. I hope you agree that the acking business (in actual implementations) in v2 is a mess.