|
| From: | Vittorio Meloni |
| Subject: | Re: [Health-dev] HL7 module in GNU Health |
| Date: | Mon, 29 Sep 2014 11:37:25 +0200 |
Subject changed from "GNU Health User at Savannah - development team"
Hi Vittorio,
2014-09-19 12:49 GMT+02:00 Vittorio Meloni <address@hidden>:
> 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]
| [Prev in Thread] | Current Thread | [Next in Thread] |