Recent changes to bugs

nHapi .NET 2.0 requires .NET 4.0

Anonymous — Wed, 27 Jun 2012 14:58:09 -0000

The dlls in the nHapi .NET 2.0 download directory seem to have been compiled in .NET 4.0. When I try to add them to a .NET 2.0 project, Visual Studio complains that the project now has indirect references to certain .NET 4.0 assemblies. Changing the project to .NET 4.0 resolves the problem, but I'd like to avoid the migration if possible.

XML encoding does not include BASE64 PDF data

Anonymous — Mon, 30 Jan 2012 15:14:57 -0000

For a pipe-formatted segment (part of a ORU-O01 message) that begins:

OBX|4|RP|||ADTX^Image^PDF^Base64^JVBERi0xLjQNJ ...

The pipe parser will succeed and the pipe encoder will re-encode the segment properly to pipe-delimeted format.

However, when attempting to re-encode the segment with the DefaultXmlParser, the resulting XML is missing the PDF data:

<OBX>
<OBX.1>4</OBX.1>
<OBX.2>RP</OBX.2>
<OBX.5>
<RP.1>ADTX</RP.1>
<RP.2>
<HD.1>Image</HD.1>
</RP.2>
<RP.3>PDF</RP.3>
<RP.4>Base64</RP.4>
</OBX.5>
<OBX.8>N</OBX.8>
<OBX.11>F</OBX.11>
</OBX>

20+ seconds to parse 37kb message

Anonymous — Wed, 25 Jan 2012 18:50:22 -0000

Hello,

The pipe parser is consistently taking 20+ seconds to (correctly) parse a pipe-formatted message. This message has a BASE64 encoded PDF in an OBX segment with OBX-2 = "RP" and OBX-5 having the base-64 encoding starting "ADTX^Image^PDF^Base64^JVBERi0xLjQN..."

The pipe parser will later re-encoded the parsed message back to an almost identical plaintext (minus a few trailing pipes, etc), so there don't seem to be any validation errors.

This 37kb message is our early test message and later messages could be longer.

Is this expected?
What is the root cause of this slow performance?
Are there workarounds without changing the communicated data that will speed this up?

My only guess that this is due to a Regexp-based parser with an inefficiently written rule.

Thanks!

Parser/FilterIterator populating unreferenced MSA segment

Anonymous — Thu, 12 Jan 2012 17:17:36 -0000

I'm very new to NHapi, but I'm tracing through and seeing what I can only imagine is a bug.

When PipeParser parse() an ACK for its AcknowledgementCode, the value is always coming back null, even though the text reads "AA".

As I trace through the parser routine, PipeParser.cs line 314 retrieves dirIter.Current for population by Parse() from the segment plaintext. When the segment loop has reached the MSA segment, dirIter.Current returns a new MSA object - not the same object reference as the one referenced by the local IMessage m.

Tracing into Parse from line 314 ... by the end of this function, the MSA's AcknowledgementCode field IS POPULATED CORRECTLY with "AA", but (restating the above) the segment object that is being populated is not the one referenced by the caller's local IMessage m and so the parsed segment is discarded and the default/empty segment originally created by InstantiateMessage() is returned.

I'm too new to NHapi to understand how to fix this, understand the extent of the impact of this behavior (beyond MSA-1). I'm using a codeset from December 21, 2011

v2.5 ADR_A19_QUERY_RESPONSE lost getPROCEDUREReps()

Anonymous — Mon, 10 Oct 2011 11:52:02 -0000

Only have a producedure property, can not get the count of PROCEDURE , But HAPI provide getPROCEDUREReps() http://hl7api.sourceforge.net/v25/apidocs/ca/uhn/hl7v2/model/v25/group/ADR_A19_QUERY_RESPONSE.html#getPROCEDUREReps\()

EventMap.properties missing from v251

Anonymous — Wed, 28 Sep 2011 05:27:27 -0000

The NHapi.Model.V251.zip is missing the 'NHapi.Model.V251\EventMapping\EventMap.properties file.
This is preventing the project from building.

EventMap.properties missing from v251

Anonymous — Wed, 28 Sep 2011 02:42:35 -0000

The NHapi.Model.V251.zip is missing the 'NHapi.Model.V251\EventMapping\EventMap.properties file.
This is preventing the project from building.

Terser getSegment() throws exception if segment not found

Steve Short — Fri, 12 Nov 2010 15:08:17 -0000

I'm trying to process a message that may (or may not) contain a non-standard ROL segment. I'm calling the Terser getSegment() method:

ISegment segment = messageTerser.getSegment("/.ROL");

This works fine when the non-standard ROL segment is present but fails with an HL7Exception and the message "End of message reached while iterating without loop" in MessageNavigator.iterate() if the segment is not present in the message.

Is this behaviour by design ?

If so, is there any way that I can programatically check whether the non-standard segment exists in the message before calling getSegment ? I've looked at methods such as Message.GetAll() and Terser.Finder.nextChild() but these only return the defined segments and don't include the non-standard segments. I can't find a way of determining whether the non-standard segment is present in the message or not.

Any help gratefully received...

Terser getSegment() throws exception if segment not found

Steve Short — Fri, 12 Nov 2010 14:19:35 -0000

I'm trying to process a message that may (or may not) contain a non-standard ROL segment. I'm calling the Terser getSegment() method:

ISegment segment = messageTerser.getSegment("/.ROL");

Is this behaviour by design ?

Any help gratefully received...

Terser getSegment() throws exception if segment not found

Steve Short — Fri, 12 Nov 2010 13:18:06 -0000

I'm trying to process a message that may (or may not) contain a non-standard ROL segment. I'm calling the Terser getSegment() method:

ISegment segment = messageTerser.getSegment("/.ROL");

Is this behaviour by design ?

Any help gratefully received...