1

I have written a custom pipeline component assembler to modify the response ACK HL7 message.

I have invoked Assemble(pContext) of Microsoft.Solutions.BTAHL7.Pipelines.HL72fAsm in the implemented method Assemble(pContext) of IAssemblerComponent interface gives me result IBaseMessage which is an HL7, then I do my manipulations on it to fix one of the fields and return that modified IBaseMessage.

All these works just fine, I tried EvenLogger to verify it.

But still the Sender application doesn't receive the modified message, it receives the auto-generated message.

Is there something I'm missing out, why do I not get the custom assembler result out from the SendPipeline of 2 way receive port

Note : BTAHL7 Configuration explorer is configured for original mode. The send pipeline on RequestResponse receive port is set to my custom pipeline

Dijkgraaf
  • 9,324
  • 15
  • 34
  • 48
syyad
  • 61
  • 7
  • Same question: Why do you think you need to do this. You're essentially breaking HL7 which is not something you should even consider. – Johns-305 Feb 11 '17 at 16:21
  • i completely agree with you @Johns-305 but the trading partner based on misconception and misunderstanding have developed a solution which reads the Ack MSH.10 as reference to original message [refering the question asked here](http://stackoverflow.com/questions/41876779/how-to-make-sure-that-message-control-id-of-btahl7-ack-message-is-same-as-origin) and now they are not in a position to correct their system and customer is not in a position to change the vendor, so we as a partner looking out for some solution (nonstandard though) to get through this – syyad Feb 18 '17 at 16:32
  • and i also want to share that we have devised a solution the other way around, leveraged an open source project [SuperSocket](https://www.nuget.org/packages/SuperSocket/) opened an mllp connection works as a middleware / proxy endpoint service which gets the job done, requests go to and fro this proxy – syyad Feb 18 '17 at 16:42
  • You probably don't need to do that. I'll add more later. – Johns-305 Feb 18 '17 at 16:47

1 Answers1

1

My suggestion is after all the more important points.

The first thing you're employer or customer should say is NO. That is invalid HL7 and you cannot support that.

But, if they are unable to unwilling to comply, the next thing you need to do is inform your management that their non-compliance will cost you a lot of extra time and money to accommodate. To fully support this change will likely cost more then implementing the business messages, I am totally serious. This is not a problem with BizTalk Server, you app or you.

Depending on the relationship, your management can legitimately ask them how they are going to pay for this customization. It's going to cost your side a lot more to break HL7 to comply with them than it will for them to fix it.

Next, and perhaps most important, due to the nature of it's message content, HL7 has very strict completeness requirements, which they are fundamentally breaking. The Trading Partner needs to fully document this requirement to take ownership of it because there is a huge consequence, they are breaking tracing/tracking on you end.

This means that it will be substantially more difficult to investigate and resolve messaging issues for you, not them. This might raise legal or compliance issues your side needs to be aware of.

So, provided you technical, medical and legal teams are all satisfied, the first thing I would try is a Pipeline Component that simply swaps the two values, MSH10 and MSA02. That way, they will receive both values.

Finally, here's a novel solution. Since this is their problem, and a problem for every one of their trading partners, what if you offer help them fix it. All then need to do is what I suggested, swap MSH10 and MSA02 on the received message.

Johns-305
  • 10,704
  • 10
  • 21