In HL7, the source and destination for a message are optionally specified by MSH-3 & MSH-4 (sending application and facility, respectively) and MSH-5 & MSH-6 (receiving application and facility, respectively). I've usually heard of these pairs referred to as an "app-fac" (pronounced ap-fak) as an abbreviated name for the application/facility pair. They also use the terms "sender" and "receiver" rather than source & destination.
The app-fac values are implementation-specific (more specifically, application-specific) and usually set according to an agreement between the sending & receiving applications, so creating & managing a Hl7Receiver (or Hl7Destination) object is probably overkill. Instead of imagining picking event messages out of the outbound queue by receiver (which is kinda backwards), think of the process forwards: either core or a module performs a clinical event that should generate HL7 message – in some cases the event should be "broadcast" (like ADT message*) and in other cases there's a specific target (a module sending a lab order to an external lab system). Since we'll be using this shared mechanism for handling the flow of the HL7 messages, the question is: how do we get the messages to the right receivers? In most cases, receivers are passive – i.e., a receiver sets up a port to listen on and then processes any messages sent to that port. It's not really fair to make a big queue in OpenMRS and then expect receivers to come and sift through the messages to find the ones they want. In any enterprise environment, we'd just pass all of the messages to an interface engine (like MIrth) and let it take care of delivering the messages to the right places. Upon reflection, maybe the better approach is to just throw all the messages into the queue and then make a "poor man's" interface engine within OpenMRS that can pull out the next message and then direct it to a folder or port based on some configuration that can take the receiving app-fac into consideration. Cheers, -Burke On Sat, Oct 29, 2011 at 5:19 PM, Darius Jazayeri <[email protected]>wrote: > Burke, so you're proposing that this project should create: > * hl7_out_queue table and domain object > * hl7_destination table and domain object (for now just a plain > OpenmrsMetadata, with name + description + audit info) > * the method > Hl7Service.getNextMessageFromOutQueueByDestination(Hl7Destination) -> > Hl7OutQueue > > But the actual work of calling that service method, and doing something > with the message, will be done by someone else at some other time. > > Right? > > -Darius > > > On Sat, Oct 29, 2011 at 1:57 PM, Burke Mamlin <[email protected]>wrote: > >> Most important would be an API method to get the next outbound message by >> destination application/facility (ideally, the option to get the next >> outbound message via Java API call or via web service call). It would >> be nice to support some basic destinations (e.g., to file system or to TCP >> port); however, I wouldn't put a lot of effort into an already-solved >> problem. Any one looking for robust delivery of messages (robust queuing, >> re-play, re-connect on lost connection, sophisticated ack-nack, etc.) would >> do well to implement mirth >> connect<http://www.mirthcorp.com/products/mirth-connect> or >> a similar third-party interface engine. All we need to do is expose these >> outbound messages to such an engine. >> >> -Burke >> >> On Sat, Oct 29, 2011 at 2:45 PM, Ben Wolfe <[email protected]> wrote: >> >>> I think for now we don't have to worry about the destination. >>> >>> We also would like to have just one hl7_out_queue instead of the 3 like >>> the in queues. Give it a "status" column for a simplistic way of knowing >>> if its been acted on. >>> >>> A second project after this is completed could be to add >>> hl7_out_destination and hl7_out_destination_status tables. >>> >>> Ben >>> >>> >>> On Sat, Oct 29, 2011 at 6:39 AM, Thothathri Srinivasan <[email protected] >>> > wrote: >>> >>>> I'm presently working on the HL7 Output Messages Project, and had a few >>>> questions: >>>> How does the admin choose the destination where he sends the HL7 >>>> messages? >>>> My understanding is that we need to do something similar to HL7InQueue, >>>> HL7InQueueProcessor, and have something like HL7OutQueue and >>>> HL7OutQueueProcessor. We would also need HL7Destination that knows the >>>> server to send the HL7 messages to, right? >>>> So do we have to ask the admin about which destination to send it to, >>>> and >>>> just give like a server address for that, or how should this design be >>>> done? >>>> >>>> Any help will be greatly appreciated! >>>> >>>> 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] >>>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ 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]
