Oops, never mind that. I do see it, I was calling toString() on the string
representation of the message and not the HAPI message object.
This is actually a quirk with the way the parser works internally. Calling
toString() actually just calls PipeParser.encode(message), and PipeParser
has a bit of unexpected behaviour in it. Essentially it creates a single
repetition of each repeatable segment in the message as a part of its scan
across the message. This means that once you have encoded a message once,
the getXXXReps() counts are no longer reliable.
There is an open bug about this issue (Issue 607 here
http://sourceforge.net/p/hl7api/bugs/207/ ) and the exact cause has been
found, but I'm still not sure if there would be regressions caused by
solving this. For now, probably your best bet is to not call toString()
unfortunately, or to call isEmpty() on the OBX segment before processing
it. This should be resolved in the next version of HAPI either way.
Cheers,
James
On Tue, Oct 14, 2014 at 5:54 PM, James Agnew <ja...@jamesagnew.ca> wrote:
> Hi Tim,
>
> Strangely I'm not seeing the same behaviour when I created a unit test to
> try this out. Do you see the same results with the following?
>
> @Test
> public void testEncodeDoesntChangeStructure() throws HL7Exception {
>
> String message =
> "MSH|^~\\&|SYSTEM|XXX|CLOVERLEAF|XXX|20141001170652|RISTECH|ORM^O01|1262|T|2.4|||||||||\r"
> +
>
> "PID|1||1234567^^^XXX^PI~100000000^^^NLMINBIZA^NNNLD||TEST&&TEST^T^^^^^L||19761201|M|TEST^^^||STREET
> 10&STREET&10^^CITY^^1234^NLD^M||^PRN^PH^^31|^WPN^PH^^31||||14205|188780348|||||||||||||\r"
> +
> "PD1||||||||||||||||||\r" +
>
> "PV1||||||||1106199999^GENERAL^SPECIALIST^^^^^^VEKTIS^^^^NPI|||||||||||14205|||||||||||||||||||||||||20141001152757|||||||V\r"
> +
>
> "ORC|NW|66955^EPC|743||Arrived||^^^20141001130500^^R||20141001170652|RISTECH^RADIOLOGY^TECHNOLOGIST.^^||1106199999^GENERAL^SPECIALIST^^^^^^VEKTIS^^^^NPI|101001103^^^101001^^^^^NUCLEAR
> MEDICINE||||||||||||||||I|\r" +
> "OBR|1|66955^EPC|743|^^^1052000729^DMSA
> UPTAKESCAN^L|R|20141001152757||||||||||1106199999^GENERAL^SPECIALIST^^^^^^VEKTIS^^^^NPI||743|743|E32||||NM|Arrived||^^^20141001130500^^R||||^test|||||20141001130500||||||||^^^1052000729^DMSA
> UPTAKE SCAN^L|\r" +
>
> "ORC|NW|66955^EPC|743||Planned||^^^20141001110500^^R||20141001170652|RISTECH^RADIOLOGY^TECHNOLOGIST.^^||1106199999^GENERAL^SPECIALIST^^^^^^VEKTIS^^^^NPI|101001103^^^101001^^^^^NUCLEAR
> MEDICINE||||||||||||||||I|\r" +
> "OBR|1|66955^EPC|743|^^^1052000728^INJECTION
> DMSA^L|R|20141001152757||||||||||1106199999^GENERAL^SPECIALIST^^^^^^VEKTIS^^^^NPI||743|743|E33||||NM|Planned||^^^20141001110500^^R||||^test|||||20141001110500||||||||^^^1052000728^INJECTION
> DMSA^L|\r" +
> "OBX|1|ST|WEIGHT^Weight patient (kg):||70|KG\r" +
> "OBX|2|ST|LENGTH^Length patient (cm):||180|CM\r";
>
> ca.uhn.hl7v2.model.v24.message.ORM_O01 orm = new
> ca.uhn.hl7v2.model.v24.message.ORM_O01();
> orm.parse(message);
>
> message.toString();
>
> ourLog.info(orm.printStructure());
>
> int orderCount = orm.getORDERReps();
> for (int i = 0; i < orderCount; i++) {
> ourLog.info("order("+i+") #OBX : " +
> orm.getORDER(i).getORDER_DETAIL().getOBSERVATIONReps());
>
> if (i == 0) {
> assertEquals(0,
> orm.getORDER(i).getORDER_DETAIL().getOBSERVATIONReps());
> }
> if (i == 1) {
> assertEquals(2,
> orm.getORDER(i).getORDER_DETAIL().getOBSERVATIONReps());
> }
>
> }
>
>
> }
>
> On Tue, Oct 14, 2014 at 4:45 AM, Tim de Wit <t.c.de...@gmail.com> wrote:
>
>> hi all,
>>
>> i'm busy developing an ORM-interface using Hapi v2.2 and encountered some
>> very strange behaviour when reading out OBX segments from the following
>> multiple-order ORM_O01 message:
>>
>>
>> MSH|^~\&|SYSTEM|XXX|CLOVERLEAF|XXX|20141001170652|RISTECH|ORM^O01|1262|T|2.4
>> |||||||||
>>
>> PID|1||1234567^^^XXX^PI~100000000^^^NLMINBIZA^NNNLD||TEST&&TEST^T^^^^^L||197
>> 61201|M|TEST^^^||STREET
>>
>> 10&STREET&10^^CITY^^1234^NLD^M||^PRN^PH^^31|^WPN^PH^^31||||14205|188780348||
>> |||||||||||
>> PD1||||||||||||||||||
>>
>> PV1||||||||1106199999^GENERAL^SPECIALIST^^^^^^VEKTIS^^^^NPI|||||||||||14205|
>> ||||||||||||||||||||||||20141001152757|||||||V
>>
>> ORC|NW|66955^EPC|743||Arrived||^^^20141001130500^^R||20141001170652|RISTECH^
>>
>> RADIOLOGY^TECHNOLOGIST.^^||1106199999^GENERAL^SPECIALIST^^^^^^VEKTIS^^^^NPI|
>> 101001103^^^101001^^^^^NUCLEAR MEDICINE||||||||||||||||I|
>> OBR|1|66955^EPC|743|^^^1052000729^DMSA UPTAKE
>>
>> SCAN^L|R|20141001152757||||||||||1106199999^GENERAL^SPECIALIST^^^^^^VEKTIS^^
>>
>> ^^NPI||743|743|E32||||NM|Arrived||^^^20141001130500^^R||||^test|||||20141001
>> 130500||||||||^^^1052000729^DMSA UPTAKE SCAN^L|
>>
>> ORC|NW|66955^EPC|743||Planned||^^^20141001110500^^R||20141001170652|RISTECH^
>>
>> RADIOLOGY^TECHNOLOGIST.^^||1106199999^GENERAL^SPECIALIST^^^^^^VEKTIS^^^^NPI|
>> 101001103^^^101001^^^^^NUCLEAR MEDICINE||||||||||||||||I|
>> OBR|1|66955^EPC|743|^^^1052000728^INJECTION
>>
>> DMSA^L|R|20141001152757||||||||||1106199999^GENERAL^SPECIALIST^^^^^^VEKTIS^^
>>
>> ^^NPI||743|743|E33||||NM|Planned||^^^20141001110500^^R||||^test|||||20141001
>> 110500||||||||^^^1052000728^INJECTION DMSA^L|
>> OBX|1|ST|WEIGHT^Weight patient (kg):||70|KG
>> OBX|2|ST|LENGTH^Length patient (cm):||180|CM
>>
>> This message contains two orders (2x ORC+OBR), with the first order having
>> no OBX and the second having two OBX segments. The following code:
>>
>> ORM_O01 orm = (ORM_O01) message;
>> //System.out.println(orm.toString());
>> int orderCount = orm.getORDERReps();
>> for (int i = 0; i < orderCount; i++) {
>> System.out.println("order("+i+") #OBX : " +
>> orm.getORDER(i).getORDER_DETAIL().getOBSERVATIONReps());
>> }
>>
>> gives the expected output:
>> order(0) #OBX : 0
>> order(1) #OBX : 2
>>
>> However... if i uncomment the .toString() line, i get the following wrong
>> output:
>> order(0) #OBX : 1
>> order(1) #OBX : 2
>> The same thing also happens if i use
>> "System.out.println(message.toString())" instead.
>>
>> Any ideas what i'm doing wrong?
>>
>> kind regards,
>>
>> Tim de Wit
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>> http://p.sf.net/sfu/Zoho
>> _______________________________________________
>> Hl7api-devel mailing list
>> Hl7api-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/hl7api-devel
>>
>
>
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Hl7api-devel mailing list
Hl7api-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
