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
>>>>> listHl7api-devel@lists.sourceforge.nethttps://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
