On Tue, Nov 29, 2011 at 2:17 AM, Ben Wolfe <[email protected]> wrote: > See below > > On Sun, Nov 27, 2011 at 10:32 AM, Thothathri Srinivasan > <[email protected]>wrote: > >> Hi, >> >> We're working on the HL7 Output Messages module, and after talking to Ben, >> here's the gist of what we need to do after generating HL7 Format >> Messages: >> 1) Making these outbound messages optional. >> 1a) Creating a table hl7_out_queue_destination. hoqd_id, name, >> description, destination (e.g. ip addr, hostname), creator_*, changed_by*, >> retired_* >> 1b) Creating table hl7_out_queue_destination_message_type: hoqd_id, >> message_type (or should this be object type?) >> 1b) Create outbound queue entries for each destination listed that has >> that type defined >> 2) Create admin interface in webapp to manage the destinations and which >> types go to which destination >> 3) Create api methods to be able to get outbound messages for a certain >> destination. For speed, this means adding a column to the hoq table for >> the >> destination id. >> >> My questions now are these : >> # To generate the HL7 Outbound messages that are optional, is it for each >> patient (on a search based functionality), or is it for all patients? >> > > Its either all or none. If we really want to get fancy later we can > change it. If you make it an API method call then a module could override > it and change its behavior. e.g. > > public void HL7Service.createMessage(Patient); >
FWIW, HL7 is event-based messaging (not resource-based like REST), so I would favor method names that describe the event instead of just naming a resource. For example, HL7Service.patientCreated(Patient) and HL7Service.patientUpdated(Patient). > > That is called from the savePatient method. > > >> # Should we consider using Mirth to send the HL7 Messages to a >> destination, >> or not? Right now,we aren't using Mirth, and we are saving HL7 Format >> messages in the DB, and we thought we could serialize it and send it to a >> destination in the destination table over a network. >> > > Mirth's power is in both constructing the hl7 message and determining > where to send it. So it'd be better to send mirth a json or xml object and > it know how to translate that into hl7. If mirth has a lot of tools to > then deal with sending that somewhere, then I vote try integrating mirth > first. Why recreate something that someone else is doing better? > > >> # We are not storing the destination in the HL7 Message we have generated. >> Should the destination be stored in the HL7 Message as well? >> > > I thought Burke said there was a place in hl7 to put it. If so, then yes, > duplicate it there. > The MSH segment contains fields for application and facility of both sender and receiver. Typically, these values are agreed upon at the implementation level (between applications), so we should support their presence, but not enforce particular values. The process(es) responsible for handling outgoing HL7 messages will use the receiving application/facility to decide where the message should be routed. Cheers, -Burke _________________________________________ 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]
