Folks, just FYI, I had a similar issue while working on some projects; however,
Mule ESB provides a simple solution for this; you can intercept the ACK message
before it is returned to the caller, and replace the MSH-9 with any value that
client would expect, by using one of several available transformers that accept
HL7 messages. Ratha, perhaps you can do the same thing in your solution, e.g.
you could use HAPI Terser, e.g. terser.set("/MSH-9", "ACK"); etc.
Regards,
Eugene
--
Eugene Berman
Sr. Enterprise Solutions Architect
----
MuleSoft Inc.
77 Geary Street, Ste. 400
San Francisco, CA 94108
Office: 415 229 2063
Website: http://www.mulesoft.com <http://www.mulesoft.com/>
---
Entia non sunt multiplicanda praeter necessitatem!
On Jun 14, 2013, at 4:45 AM, James Agnew <ja...@jamesagnew.ca> wrote:
> Hi Ratha,
>
> To be completely honest, I have no idea what the right answer is to this.
> Certainly you are right, the standard seems to indicate that the R22 trigger
> is not allowable in an ACK message, but the standard also doesn't seem to
> provide any indication on what would be an appropriate trigger for an ACK to
> an OUL^R22 message.
>
> I think there are a few courses of action here:
>
> 1. It might make sense to take the question of "what belongs as a trigger
> event on an ACK to an OUL^R22 message" over to the HL7 Infrastructure and
> Messaging (InM) mailing list for broader consideration. I'm curious now too,
> so if you didn't want to handle this I would be willing to do so.
>
> 2. If you wanted to file a bug report for HAPI, we could probably code in the
> ability for HAPI to not use a trigger event for ACKs to messages that
> shouldn't get one according to Table 0003. I'll be honest though, this will
> be somewhat painful to implement so it probably won't happen overnight
> (unless you or someone else wanted to give it a shot?)
>
> 3. As a fairly simple workaround, you could add custom logic to your
> application to clear MSH-9-2 as needed after you generate your ACK message.
>
> Cheers,
> James
>
>
>
>
> On Fri, Jun 14, 2013 at 3:18 AM, vijayaratha vijayasingam
> <vijayara...@gmail.com> wrote:
> Hi James/all;
>
> Do you believe this as a BUG in Hapi or acceptable behavior?
>
> Thanks
>
>
>
> On 13 June 2013 14:45, vijayaratha vijayasingam <vijayara...@gmail.com> wrote:
> Hi James;
> Thanks for considering this.
> Please find the following HL7 Data definition tables [1] .In table 0003
> (page A-25) . The trigger event R22 can be associated only with the OUL event
> type (but NOT with an ACK event type) whereas the trigger event A01 can be
> associated with both ADT and ACK event type.[2,3]
>
> [1]http://www.hl7.org/special/committees/vocab/v26_appendix_a.pdf
>
> [1]0003 A01 ADT/ACK - Admit/visit notification
> [2]0003 R22 OUL - Unsolicited Specimen Oriented Observation Message
>
> Does this help you?
>
> Thanks
> -Ratha
>
>
> On 13 June 2013 01:40, James Agnew <ja...@jamesagnew.ca> wrote:
> Hi Ratha,
>
> While the HL7 standard doesn't seem to specifically mention whether or not
> the response for an OUL^R22 should have the R22 trigger event in it's ACK,
> the general pattern in processing HL7 v2 is that the trigger event will
> always be the same as the message being acknowledged. A quick scan of the
> standard for words to that effect has come up blank (but maybe I'm not
> looking in the right place- I checked Chapter 2 of the 2.6 standard at least)
> but this is definitely how basically every system I work with regularly
> behaves.
>
> What leads you to believe this is not desirable behaviour? Are you
> interfacing with a system that specifically rejects ACK messages with the R22
> trigger?
>
> Cheers,
> James
>
>
> On Wed, Jun 12, 2013 at 11:34 AM, vijayaratha vijayasingam
> <vijayara...@gmail.com> wrote:
> Oh..hapi generates this ack message, when i send OUL^R22 message..
> Others any clue?..
> Is this valid or bug?
>
>
> On 12 June 2013 20:22, VIOT Yves <yves.v...@csis.fr> wrote:
> Sorry, i never had to handle such triggers, but if i had to, i will produce
> an ACK - unless the sender doesn't need them.
> In specs, there is no ACK^R22 following de OUL^R22 definition but i can't say
> it's a mistake or not.
>
> Le 12/06/2013 16:46, vijayaratha vijayasingam a écrit :
>> Hi Viot;
>> Sorry i sent different initial sample message ;Please check my later replies;
>> Im getting following[1] ACK in MSH-9 filde fro my OUL^R22 message. Is that
>> valid?
>> ACK^R22^ACK|
>>
>> Thanks
>>
>>
>> On 12 June 2013 17:11, VIOT Yves <yves.v...@csis.fr> wrote:
>> Hi,
>> This is valid
>> Here is what you can find in the HL7 2.5 documentation, following the
>> ADT^A01^ADT_A01 messages structure definition.
>> ACK^A01^ACK
>> To get rid of it just get the MSH-9-1 with the terser.
>>
>> Yves
>>
>> Le 12/06/2013 13:25, vijayaratha vijayasingam a écrit :
>>> Hi all;
>>> Anyone have clue..?:(
>>> I badly need this to sort out..
>>> thanks
>>>
>>>
>>> On 12 June 2013 15:31, vijayaratha vijayasingam <vijayara...@gmail.com>
>>> wrote:
>>> Hi all;
>>> Im using Hapi 2.1 version release an dit works perfect. But i have an issue
>>> with an error response which i get from Hapi.
>>> My request is;
>>> MSH|^~\&|||||20130612143324.392+0530||ADT^A01^ADT_A01|2601|T|2.5
>>>
>>> And My response is;
>>> MSH|^~\&|||||20130612152510.448+0530||ACK^A01^ACK|1623|T|2.5
>>> MSA|AE|2601
>>> ERR|||207^Application internal error^HL70357^^^^^^OOPS|E
>>>
>>>
>>> In the above response , if you check the MSH-9 filed , it is;
>>>
>>> ACK^A01^ACK
>>>
>>> Shouldn't that be "|ACK". because it is additionaly adding "AO1" message to
>>> that filed, which is not valid. And i suspect that , it picks from that
>>> from original request.
>>>
>>> Can anybody help me on this? Ho w can i avoid that invalid segment?
>>> Why Hapi additionally adds that filed in the MSH-9 filed?
>>>
>>> Thanks
>>> -ratha
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Windows:
>>>
>>> Build for Windows Store.
>>>
>>>
>>> http://p.sf.net/sfu/windows-dev2dev
>>>
>>>
>>> _______________________________________________
>>> Hl7api-devel mailing list
>>>
>>> Hl7api-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Hl7api-devel mailing list
>> Hl7api-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Hl7api-devel mailing list
> Hl7api-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Hl7api-devel mailing list
> Hl7api-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
> Hl7api-devel mailing list
> Hl7api-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Hl7api-devel mailing list
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
