Hi James..
Any update? would like to know the conclusion..
Thanks & regards
On 17 September 2013 22:11, vijayaratha vijayasingam
<vijayara...@gmail.com>wrote:
> Hi James,
> Any update on this MSH9 filed from InM team?
>
> Thanks
> -Ratha
>
>
>
> On 14 June 2013 20:47, vijayaratha vijayasingam <vijayara...@gmail.com>wrote:
>
>> 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/
>>
>
>
>
> --
> -Ratha
> http://vvratha.blogspot.com/
>
--
-Ratha
http://vvratha.blogspot.com/
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Hl7api-devel mailing list
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
