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]
