Re: [HAPI-devel] Hapi 2.1 version's MSH-9 filed concerns

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi James..
Any update? would like to know the conclusion..
Thanks & regards

On 17 September 2013 22:11, vijayaratha vijayasingam
<vij...@gm...>wrote:

> Hi James,
> Any update on this MSH9 filed from InM team?
>
> Thanks
> -Ratha
>
>
>
> On 14 June 2013 20:47, vijayaratha vijayasingam <vij...@gm...>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 <eug...@mu...> 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...@ja...> 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 <
>>> vij...@gm...> 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 <vij...@gm...>
>>> 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...@ja...> 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 <
>>> vij...@gm...> 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 <yve...@cs...> 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 <yve...@cs...> 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 <
>>> vij...@gm...> 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
>>> >>>
>>> >>> Hl7...@li...
>>> >>> 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
>>> >> Hl7...@li...
>>> >> 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
>>> > Hl7...@li...
>>> > 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
>>> > Hl7...@li...
>>> > 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
>>> > Hl7...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>>>
>>>
>>
>>
>> --
>> -Ratha
>> http://vvratha.blogspot.com/
>>
>
>
>
> --
> -Ratha
> http://vvratha.blogspot.com/
>

-- 
-Ratha
http://vvratha.blogspot.com/