Incorrect parsing of RXR when no ORDER_DETAIL group present

[gap777]

Given the following message:

MSH|^~\&|EXACTDATA||ALL|ALL|20101217181500||RDE^O11^RDE_O11|EF010000000071000000_4|T^T|2.5.1
PID|1||7010566270^^^^DODID~EM010000008000000^^^^MR||ZZEDConner^Dean^J^^Mr.||19810611|MALE||WHITE^^HL70005|^^^^^USA^H||||ENGLISH^^HL70296|SINGLE^^HL70002||EF010000000071000000||||NOTHISPANICORLATINO^^HL70189|||||ACTIVEDUTY^^HL70172
PV1|1|OUTPATIENT|^^^MBCC^^AMBLOC||||1853210951^Pennington^Zachary|||MEDICINEGENERAL|||||||1853210951^Pennington^Zachary|||||||||||||||||||01|||||ACTIVE|||20101217181500|20101217184500||||||V
PV2|||V70.0^General medical examination^I9C|||||||||||||||||||||||||||||||||||||||||N
AL1|1|DRUG^^HL70127|70618^Penicillin^RXNORM|MODERATE^^HL70128|Dry Mouth|20100928
ORC|NW|101217-833651^ExD|||ORDERED
RXE|^^^20101217184500|54569-4888-0^Oseltamivir|1||75 mg||^po bid x 5d||N|10||0||||||||||||||||||||20101217184500
RXR|^Oral^HL70162

Since the RXR is following the RXE, it should not be parsed as part of the ORDER_DETAIL group. nHapi PipeParser incorrectly puts it there.

The problem seems to be because of the following lines in PipeParser.DoParse:

if (!name.Equals(lastSegmentName, StringComparison.CurrentCultureIgnoreCase))
{
    // If the message iterator passes a segment that is later encountered the message object won't be properly parsed.
    // Rebuild the iterator for each segment, or fix iterator logic in handling unexpected segments.
    messageIter = new MessageIterator(theMessage, "MSH", true);
    lastSegmentName = name;
}

where each search for the right spot to place segment data starts again at the top and looks for the first segment to match by name.

This approach forgets the position of previously placed data. In this scenario, the RXR can't possibly be considered to be a part of the ORDER_DETAIIL because it follows the RXE, and the RXE is not a part of the ORDER_DETAIL.

We've made changes that appear to fix the problem, and would love your review.

[Eric-Cadwell]

It looks like you've pulled the code from my fork based on the fix I had done for issue #40. Do you know if you're change works with the parsing for the message fragment in that issue?

Originally the code stayed at the last structure but this got out of sort when you had an unexpected segment followed by expected segments, the parser would navigate until if found part of a segment that would take unexpected segments and would begin parsing from that location. This caused the valid segments afterwards to not always be placed in the message object where they should go. Effectively a NTE segment above your PID segment would mean that no patient data would parse correctly and be returned from the message when asking for it.

[gap777]

Eric,

I haven't tested against the fragment mentioned in issue #40, and we are in fact seeing the problem you're describing when unexpected but recognized segments are encountered. We're working on a fix that addresses both issues.

[Eric-Cadwell]

Let me know if there's anything I can do or provide to help. The iterator setup can be a bit of a deep dive.

[gap777]

Absolutely! We'd love your help.

Without propery unit tests coverage, it's so easy to break something! Do
you have more test cases you can help us codify in PipeParser unit tests?

Ever use screenhero? What tools do you use for remote collaboration?

Thanks!

Gary

On Wed, May 11, 2016 at 7:37 PM, Eric Steinbrenner <[email protected]

wrote:

Let me know if there's anything I can do or provide to help. The iterator
setup can be a bit of a deep dive.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#51 (comment)

[Eric-Cadwell]

I haven't used screenhero. I haven't had to do much remote collaboration for code project but I do have experience with google's hangouts, gotomeeting, gotoassist, and skype's screen sharing.

We've put most of our unit testing in our integration with nHapi so we can test the parsing into our entity objects and handle taking results and sending them back. I do have some test messages that do have the structures that would cause the unexpected segment issue.

[gap777]

Eric,

Let's continue this in another way. Email me directly g passero at g mail
dot com

Gary

On Wed, May 11, 2016 at 8:09 PM, Eric Steinbrenner <[email protected]

wrote:

I haven't used screenhero. I haven't had to do much remote collaboration
for code project but I do have experience with google's hangouts,
gotomeeting, gotoassist, and skype's screen sharing.

We've put most of our unit testing in our integration with nHapi so we can
test the parsing into our entity objects and handle taking results and
sending them back. I do have some test messages that do have the structures
that would cause the unexpected segment issue.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#51 (comment)

[milkshakeuk]

The PR #200 fixes this.

The following test passes.

[Test]
public void Parse_V251_RDE_O11()
{
    var message =
        "MSH|^~\\&|EXACTDATA||ALL|ALL|20101217181500||RDE^O11^RDE_O11|EF010000000071000000_4|T^T|2.5.1\r"
        + "PID|1||7010566270^^^^DODID~EM010000008000000^^^^MR||ZZEDConner^Dean^J^^Mr.||19810611|MALE||WHITE^^HL70005|^^^^^USA^H||||ENGLISH^^HL70296|SINGLE^^HL70002||EF010000000071000000||||NOTHISPANICORLATINO^^HL70189|||||ACTIVEDUTY^^HL70172\r"
        + "PV1|1|OUTPATIENT|^^^MBCC^^AMBLOC||||1853210951^Pennington^Zachary|||MEDICINEGENERAL|||||||1853210951^Pennington^Zachary|||||||||||||||||||01|||||ACTIVE|||20101217181500|20101217184500||||||V\r"
        + "PV2|||V70.0^General medical examination^I9C|||||||||||||||||||||||||||||||||||||||||N\r"
        + "AL1|1|DRUG^^HL70127|70618^Penicillin^RXNORM|MODERATE^^HL70128|Dry Mouth|20100928\r"
        + "ORC|NW|101217-833651^ExD|||ORDERED\r"
        + "RXE|^^^20101217184500|54569-4888-0^Oseltamivir|1||75 mg||^po bid x 5d||N|10||0||||||||||||||||||||20101217184500\r"
        + "RXR|^Oral^HL70162";

    var parser = new PipeParser();

    var result = parser.Parse(message);

    var rdeO11 = result as NHapi.Model.V251.Message.RDE_O11;

    Assert.IsNotNull(rdeO11);
    Assert.AreEqual("Oral", rdeO11.GetORDER().GetRXR().Route.Text.Value);
    Assert.AreEqual("HL70162", rdeO11.GetORDER().GetRXR().Route.NameOfCodingSystem.Value);
}