Handling missing Segment in a Group - change in default behaviour from 2.5.0.6?

[Jevonius]

Hi,

I'm in the process of updating from 2.5.0.6 to 3.1.0 and have noticed a change in behaviour that I can't find the commit/PR for, so am wondering about the rationale behind it; can anyone help? Under 2.5.0.6, a missing required field in a group still meant the message was parsed; the missing segment was silently created, and the rest of the group(s) populated as expected. Under 3.x, no [subsequent] groups are created, and the remaining segments all appear to be added to the message via AddNonStandardSegment.

Background: I'm upgrading a solution from Framework 4.7.2 to Core 3.1 (with eyes on 6 at some point). Having upgraded the nHapi packages, a test broke because of this change in behaviour. Reviewing the test, I'm not sure it was ever correct, but I'm not sure what the expected behaviour actually is, so wanted to review the thoughts behind the change.

The issue: I have a custom masterfile with the expected structure:

MSH
MFI
{ "Patient"
    MFE
    PID
    OBX
}

In the affected test, the sample message has two patient repetitions (the MFE/PID/OBX group), but the MFE segment is missing in the first one (given that MFE is required, the message is strictly invalid and using the new UnexpectedSegmentBehaviour confirms this). Using the default forgiving behaviour, in 2.5.0.6, the parsed message contains two Patient groups, 3 entries in Names/_items (MSH, MFI, PATIENT). Upgrading to 3.1.0 (no other code changes), there are no Patient groups, and 7 entries in Names/_items (MSH, MFI, PID, OBX, MFE, PID, OBX). I know that HL7 in general tries to be forgiving, but what's the expected behaviour supposed to be? Should it try to 'save' the format as much as it can (the 2.5.0.6 behaviour), save the data without the structure (3.1.0 behaviour) or something else (e.g. try and save structure and data, but remove invalid groups - i.e. my example message gets parsed with just one patient, or both but the first marked as invalid). Thanks!

[milkshakeuk]

Hi @Jevonius the PR which changed the default behaviour is #200, this was done to be in line with hapi (which nhapi is a port of), there is a section in the wiki which explains what happens when an unexpected segment is parsed and how to access the data.

As far as I am aware the "old" behaviour would just stop populating subsequent segments as soon as it came across an unexpected segment, that was my experience anyway, you seem to be suggesting something different.

There has since been a further change to allow you to choose where to add the unexpected segment, you can read about that here.

If you want the pre v3 behaviour you can use LegacyPipeParcer (which I created for people who which to keep the old behaviour for a time) in place of PipeParser which will probably behave as you currently expect however LegacyPipeParser will not be around forever and is not receiving any fixes or enhancements etc so I would recommend you keep using PipeParser, using the examples in the wiki you should be able to access your data.

Let me know if you have any more questions and or if this doesn't solve the problem you have.

[Jevonius]

Thanks for the pointer - my expectation of the old behaviour was the same as yours, so not entirely sure what's going on in my test. Will stick with the new behaviour, it's more predictable. As I say, I'm not sure the test as written was testing what it thought it was!