tags:

views:

801

answers:

1

The problem is that the Inbound Message Template is expecting different type than I want to specify or work with. The requirement is to have a SINGLE channel convert HL7 v2 to v3, call a web service, then convert the SOAP resulting XML, and convert that to HL7 v2.x and send it back to the original caller. This must be done asynchronously.

Setup: Consider the situation in a Mirth channel:

  • Source is LLP listener. Type is HL7 v2.x. The sender is the HCIS (Health Care Information System).
  • Source Transformer, not relevant to problem at hand.
  • 4 Destinations (in order):

    • Javascript Writer - calling into Code Templates to do some database work.
    • SOAP Sender - calling a web service which returns HL7 v3.
    • Javascript Writer - containing a handful of Transformers DB writer calling into Code Templates. The problem lies here.
    • Javascript Writer - again calling into Code Templates.
  • the PostProcessor generates a custom Acknowledgement to send back to the HCIS.

Problem: The Inbound Message Template expects HL7 v2.x because it inherits the datatype from the Source. I need to map an HL7 v3 template to an Outbound Message Template. The Outbound Template is working fine, as it's not bound to anything.

 tmp['PID']['PID.5']['PID.5.1'] = msg['controlActProcess']['subject']['target']['identifiedPerson']['name']['family'].toString();

I have tested this setup in another channel with HL7 v3 as the incoming datatype, and it works perfectly.

Question: How can I force Mirth to recognize my Inbound Message Template as HL7 v3 instead of inheriting the channel's incoming data type?

+1  A: 

A little late, I know, but could you break it into 2 channels: a HL7 v2.x to a channel writer, and then another set up as a channel reader to HL7 v3.x?

If you've solved this, I'd be curious to know how.

bansley