Parser will not generate all fields on string parsed from XML

[quinnmccourt]

Describe the bug Two Hl7 strings, one that is pulled from XML and one that plaintext, with all the same values - the XML one will not process PATIENT_RESULTS while the plaintxt will.

To Reproduce PipeParser parser = new PipeParser(); Process hl7 strings in files below with this method: (NHapi.Model.V251.Message.ORU_R01)parser.Parse(hl7message,"2.5.1");

Expected behaviour I expect both files to be parsed the same.

Screenshots If applicable, add screenshots to help explain your problem.

Sample HL7 workingstring.txt failingstring.txt

Environmental Details (please complete the following information):

• OS: Monterey

• Target Framework net5.0

• HL7 Version [e.g. 2.4]: 2.5.1

Additional context Add any other context about the problem here.

[quinnmccourt]

I wanted to leave a little update: It turns out these files are different in how their lines end, the working string is using CR and the failing is using LF. So i guess this would be more of a feature request to be able to read both types of line ends as opposed to a bug. I'll leave it open for a contributor to determine.

[milkshakeuk]

@quinnmccourt hi thank you for the effort of providing samples etc.

The following snippet is taken from the HL7 Messaging V2.5.1 Specification pdf, but the segment terminator is the same in all 2.X versions AFAIK.

In constructing a message, certain special characters are used. They are the segment terminator, the field separator, the component separator, subcomponent separator, repetition separator, and escape character. The segment terminator is always a carriage return (in ASCII, a hex 0D). The other delimiters are defined in the MSH segment, with the field delimiter in the 4th character position, and the other delimiters occurring as in the field called Encoding Characters, which is the first field after the segment ID. The delimiter values used in the MSH segment are the delimiter values used throughout the entire message. In the absence of other considerations, HL7 recommends the suggested values found in Figure 2-1 delimiter values.

If you see all our unit tests which contain HL7 test messages explicitly set the terminator as \r at the end, nhapi is forgiving if the segment terminator is \r\n as it will trim the \n.

I don't think adding this as a feature is a good idea since it goes against the specification.

If you think this is incorrect, please feel free to re-open this issue.

[milkshakeuk]

@quinnmccourt did you see this comment?

[quinnmccourt]

Thank you for the clarity on this issue!