What I'm advocating for is (1) loading the outbound queue via the API with an add-this-to-the-outbound-HL7-queue method and (2) providing an easy way (i.e., web services) to securely externalize the queue so the business of handling outbound messages – which is typically implementation-specific – can be as flexible as possible.
For example, authenticated web service access to pop entries off the outbound HL7 queue would allow for any solution – e.g., a small bundled module that simply dumps outbound HL7 messages into a pre-defined folder OR a Mirth instance pulling out messages and delivering them to dozens of different destinations using a variety of different channels. -Burke On Mon, Dec 5, 2011 at 10:53 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > We still need to be able to push a text file to be e-mailed or sneaker > netted elsewhere.**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Burke > Mamlin > *Sent:* Monday, December 05, 2011 9:53 AM > > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] About the progress in the HL7 Output > Messages Module**** > > ** ** > > Any code/processes putting HL7 messages *into* the outbound queue doesn't > need to be concerned with destination. Any code/processes pulling data * > out* of the outbound queue – which should be separate from the processes > loading the outbound queue – will need to consider the destination.**** > > ** ** > > There are two potential approaches: push or pull. A push-based approach > would be a process in OpenMRS that takes entries out of the outbound queue, > considers their destination, and sends the messages to an external > system/folder based on the destination. A pull-based approach would be to > expose the outbound queue through a web service (with appropriate privilege > checks), allowing an external process to pull items out of the outbound > queue.**** > > ** ** > > I would favor the pull-based approach, since it doesn't try to pre-define > how messages will be handled/directed. If we want to make a simple module > to use the web service and place messages into a folder or to send them to > TCP port with basic ack/nack support, that's fine. Larger installations > would probably install an interface engine (e.g., Mirth) to pull outbound > messages.**** > > ** ** > > -Burke**** > > ** ** > > On Mon, Dec 5, 2011 at 2:38 AM, Ben Wolfe <[email protected]> wrote:**** > > The 99% use-case is to send it to a port or url on another server. And > that should be automatic. The admin should not have to go in and send off > every one of them. > > You could add in a feature to download messages. This would help an admin > debug an issue and/or download a bunch of messages and send them to someone > to analyze if its possible to send to someone else. > > Ben**** > > ** ** > > On Thu, Dec 1, 2011 at 8:22 PM, Thothathri Srinivasan <[email protected]> > wrote:**** > > Hi Ben, > > Sure, I'll just put up the code later today, as a patch again, and I'm > updating the wiki docs right away. > Okay, so I'll send it just as the hl7 text message, and not send objects > or anything else to other systems. > > Roger, yes, I was under the impression that sending the HL7 Messages over > a network to a destination was also a major concern. Now I understand that > generating them is what interests us more. > So we have used HAPI to convert patient details into HL7 ADTA28 and ORUR01 > messages and save it into the db. > We thought we would modify the jsp page and have an option to send that > message to destinations as an option if the admin user wants to. I > understand that we might be interested to send it to another app on the > same server, and other cases which might not be satisfied by simply having > an option to send it over to a destination over the network. Should we > include a few more cases like writing the details to a file, for instance? > Any suggestions on how to go about this? Please let us know. > > Thanks, > Thothathri**** > > > > **** > > On Thu, Dec 1, 2011 at 5:45 AM, Ben Wolfe <[email protected]> wrote:**** > > The messages can just go out as the text hl7 message. Thats all you want > to send, don't send our objects or xml to other systems. > > Can you link to the most up-to-date code review so we can see your > code/tables/etc? (Or link to wiki docs that you have created) > > Ben**** > > ** ** > > On Thu, Dec 1, 2011 at 10:24 AM, Thothathri Srinivasan <[email protected]> > wrote:**** > > So I've used HAPI to convert into HL7 Message formats (ADT and ORU), and > stored these details into a table called HL7OutQueue in the database. > I have also created a HL7OutQueueDestination that has the destination > details. > I thought that we could serialize the objects in the HL7OutQueue table > (which would have transient data members too), and then send it over the > network to the destination from the HL7OutQueueDestination table. > Isn't this what we have to do to send the HL7 messages to a destination? > Please let me know. > > Thanks, > Thothathri**** > > ** ** > > On Thu, Dec 1, 2011 at 2:08 AM, Ben Wolfe <[email protected]> wrote:**** > > Serializing and sending to a destination? What do you mean by that? Can > you give you the steps in your processing? > > Ben**** > > ** ** > > On Thu, Dec 1, 2011 at 6:57 AM, Thothathri Srinivasan <[email protected]> > wrote:**** > > Hello Ben, > > We had talked to you a few days back about what we intended to do about > the HL7 Output Messages module. > We tried using Mirth like you had mentioned, but then decided to implement > the conversion of details into HL7 ADTA28 and ORUR01 messages using HAPI, > and then serializing and sending it over to a destination. > Please let us know if that's fine. > > Thanks, > Thothathri > > > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
