Thanks Eugene, same solution also provided by James..
Would like to know about the decision for the first point of James's, That
is , it is a bug or not, in that case, what would be the trigger event for
this type of messages..
Regards;
-Ratha
On 14 June 2013 18:31, Eugene Berman <eugene.ber...@mulesoft.com> wrote:
> 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
>
>
--
-Ratha
http://vvratha.blogspot.com/
------------------------------------------------------------------------------
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
