Hi Emilien, I agree with the acknowldgement system you've described. Regarding the two acknowldgement modes, the PDQ IHE profile states: "The receiver shall respond to the query by sending the RSP^K22 message. This satisfies the requirements of original mode acknowledgment; no intermediate ACK message is to be sent". So we're going to implement the original mode for this transaction. About the HL7 version, we are using 2.5, that's because PDQ, as other IHE profiles, specifies the HL7 version to use. Our library supports all versions until 2.6 and in the future we will support 2.7. Maybe the HL7 version can be set in the configuration interface.
Vittorio 2014-09-21 14:57 GMT+02:00 Emilien Klein <[email protected]>: > Subject changed from "GNU Health User at Savannah - development team" > Hi Vittorio, > > 2014-09-19 12:49 GMT+02:00 Vittorio Meloni <[email protected]>: > > Hi Emilien. > > we will try to clarify some issues. > > Probably we didn't explain well how we would like to implement the > module. > > I think that it is very similar to the process you are describing for > > incoming messages: it is a process that listens for MLLP connections from > > clients and returns an HL7 message as an answer. Currently it accepts > only > > PDQ messages, but it can be easily extended to accept other kinds of > > messages. In this way you can have just one entry point for all HL7 > > transactions. > > Regarding the database access, we agree to implement an interface which > can > > be reused by other transactions and hides the method for querying the > > database. The implementation, will use Tryton/GNUHealth methods. > > I had understood that you wanted to create an external executable, > which would perform SQL queries directly to the PostgreSQL database > I know understand you want to have this integrated in GNU Health > itself, so that addresses my worries. > > > I think the difference from your vision is that we take configurations > > parameters from the Tryton configuration files while you think it is > best to > > create a Tryton module to configure it via GUI and that can be a good > > solution indeed. > > The manual configuration files would grow out of hand pretty quickly, > as the number of different interfaces and their respective settings > would grow in the future. > Each interface would not only have port/IP address information, but > also configurations such as which types of codes you want to send for > providers/procedures, and as we will likely support multiple types of > interfaces, building the foundation directly into GNU Health from the > start makes it easier on us for the future. It would also be easier on > the maintainers of systems "out there", as they could do all their > configuration right from the same place, as the rest of GNU Health > build/configuration is done from GNU Health itself, and not in the > Tryton config file. > > > This scenario is different from Mirth, since you'll have a native module > in > > your HIS and you won't need to install another middleware to support > > interoparibility with external systems. Mirth is a terrific tool when you > > have to integrate systems which speak different languages; if you > implement > > a native interface you can avoid another level of complexity. > > Completely agree. > > > Regarding the 3 types of interface you described, actually HL7 v2 > > transactions require always a response with an ACK. If the sender does > not > > receive it in a predefined period of time it will retransmit the message. > > Yes, you are correct. We naturally need to support sending and > receiving ACK messages, as they are mandatory in the HL7 standard. > The way people usually talk about interfaces is related to the > direction in which the functional payload goes. So that you're not > just talking about an "orders" interface, but an "outgoing orders from > GNU Health to lab system X", with outgoing meaning that the actual > order message is generated by GNU Health, for which an ACK message > will be received back. > > In practice, once you've got the ACK mechanism working, you don't > really do much with it: > - If you've gotten a successful ACK, you might note it down, but you > don't do anything much more with the ACK message itself. > - If you're receiving an incoming message, you just mechanically > respond with an ACK. > - This is further watered down as you usually have an interface engine > in between systems. e.g. if you are sending Registration and ADT > messages out, you'll want that information in more than one system. > Instead of having N outgoing Reg/ADT interfaces, you'd typically just > have one outgoing to the interface engine (Mirth, Cloverleaf, BizTalk, > Symphony, etc.) which then splits the messsage out to the N systems. > So the ACK you would be receiving is the ACK of the interface engine. > And the interface engine receives the ACKs from all the systems. If > one out of 20 is not responding, the interface engine will take care > of re-sending the message, but only to that one message. So in > practice you don't get a funcitonal ACK (receiving system here, I was > able to process your message without errors) from each system, but a > technical ACK (Interface Engine here, I have received your message and > will pass it on). > - So if your interface engine is down, you'll indeed not receive any > ACK and will send the message again. But if your interface engine is > down, you'll most probably be facing larger-scale issues, and just > resending the message will likely not be sufficient. Manual action > (restart, configuration change) on your interface engine will probably > be needed. > > > As > > you said, in case of QRY messages (for example PDQ requests messages) the > > ACK will encapsulate also the results of the query within the response. > So > > we think the interfaces are always bidirectional. > > Techically yes, but I'm sure you agree that in the case of a QRY > message the "bidirectionallity" is a much more important factor ;) > > > That said we agree with you about the two processes: > > - One for incoming messages: this process gets the messages from an > external > > system and responds with the ACK message, but it doesn't answer AA for > > messages with errors, since this behavior isn't compliant with HL7 > > specification. This process is the one we're trying to implement > > The problem is how to determine if you should send an > > > - One for outgoing messages: this creates the messages, send them to the > > external system then wait for the ACK from it. If an error happened, so > the > > answer is AE (Applicaiton Error) or AR (Application Reject), it should > > implement a retransmission mechanism. > > The message might have errored out in their system because the patient > ID was unknown, or because they couldn't recognize a procedure code > due to missing build on their side. If a receiving application sent an > AE or AR back, it's pretty unlikely they will accept the message a > second time if you just resend it. > So at best you could log something on our side, so that it can be > reviewed in the future to detect potential issues (but really the > receiving side should keep an error log that gets reviewed > frequently). > Resending the message can make sense when you haven't received an ACK > back, but resending because of an AE or AR in the ACK is just calling > for infinite loops: > - We send a message out > - Application responds with AE or AR > - We resend the message > - Application responds with AE or AR > - We resend the message > - Application responds with AE or AR > - etc. > > This makes more sense to me: > - We send a message out > - Application responds with AE or AR > - We log a warning on our side that can be reviewed later, and go on > to the next message. > > There are 2 types of acknowledgements specified in the HL7 standard, > chapter 2: > 2.3.2 Acknowledgments: original mode > 2.3.3 Acknowledgments: enhanced mode > > Extract from the original mode: "The HL7 Standard makes no functional > interpretation of the requirement that a system commit the data in a > message to its database before acknowledging it. All that is required > is that the receiving system accept responsibility for the data, > providing the same integrity test that it would apply to data from any > source." > That's what I base my interpretation on, that you can send an AA > (Application Accept) even if you haven't processed the message yet, as > long as you commit to handle the message appropriately. Should you > fail to process the message as sent, you will take [manual] action to > solve the problem, getting in touch with the sending system if need > be. > > Extract from the enhanced mode: "With a positive accept > acknowledgment, the receiving system commits the message to safe > storage in a manner that releases the sending system from the need to > resend the message. After the message has been processed by the > receiving system, an application acknowledgment may be used to return > the resultant status to the sending system." > So you could send an AA to indicate you're going to process the > message, and [later] send another AA to indicate the message was > processed. I have yet to encounter systems that really bother to take > that step, in particular since most interface engines just discard any > ACK messages, so you would be shouting into the void. > > I didn't find references to obligations to resend message when > receiving an AE or AR. Please let me know if you've found any > clarification. > > > If you agree, we'd like to implement a first version of incoming messages > > process where the Tryton module for now implements the basic parameters > (e.g > > listening host and port) which can be extended in the future with others. > > > > Let us know your thoughts, > > Vittorio > > > > By the way, on which version of HL7 are we going to standardize on first? > I'm most used to version 2.4, the most recent is 2.7. > HL7 v2 versions are backwards compatible (a 2.4 message can be > understood by a 2.7-compliant system), but not the other way around (a > 2.7 message *might* not be received well by a 2.4 system). I've > downloaded the 2.7 specs for now [0], but please tell me with which > version you'd feel most comfortable with. > > [0] > http://www.hl7.org/implement/standards/product_brief.cfm?product_id=146 > > Let's get this rolling! > > +Emilien > P.S.: Vittorio, Alessandro, Chris: I by now assume you are subscribed > to the health-dev mailing list, and have thus put you in BCC (to make > sure you at least receive this message), but will just respond to the > mailing list on the next message. > > [snip] > >
