#14 Group types returning incorrect RepetitionsUsed counts

[Jason Prell]

While utilizing the API, I ran into a problem with Groups. I am using ORU_R01 messages (in V231) and discovered something odd.

Whenever I would access a ORU_R01_PATIENT group, I would always get back NTERepetitionsUsed of having at least 1, even if there is not a NTE segment present for the patient in the ORU_R01 message.

AbstractGroup.GetAll(string name) and AbstractGroup.currentReps(string name) both call AbstractGroup.GetGroupItem(string name) and will return at least 1 even if there is not a segment with that name in the actual message. All it checks is if the group "could" contain the segment, not checking to see if it is really there.

This is a problem because the properties, such as ORU_R01_PATIENT.NTERepetitionsUsed uses GetAll("NTE") and is returning a count of 1. When I try to use that property in a for loop, for example:

for (int idx1 = 0; idx1 < patientGroup.NTERepetitionsUsed; idx1++)
{
Segment.NTE noteSegment = patientGroup.GetNTE(idx1);

for (int idx2 = 0; idx2 < noteSegment.CommentRepetitionsUsed; idx2++)
{
string noteComment = noteSegment.GetComment(idx2).Value;
...

I wind up entering the loop, creating a NTE segment that doesn't contain anything, rather than not entering the for loop at all when there is not a NTE segment. This is not a problem with AbstractSegment.GetTotalFieldRepetitionsUsed(int number), which is used by NTE.CommentRepetitionsUsed, so no comment gets populated for the NTE segment.

This is a problem because I am trying to import the notes for a patient of an ORU_R01 message and I am getting a note for a patient in every message, most without any information (since there isn't a NTE segment).

I was thinking about how to approach this to fix it, because it doesn't look as simple as changing the index by removing 1 in AbstractGroup.GetStructure(string, int). I feel the problem is with AbstractGroup.GetGroupItem(string) and it needs to be thought out as to make it work like similar to AbstractSegment.

I think it might be a good idea to change the Group types to have the RepetitionsUsed properties call a new GetTotalSegmentRepetitionsUsed method instead of GetAll, e.g. GetAll("NTE"), but there are more extensive changes that might need to be utilized inside that new method.

[David Grinberg]

+1

This is an annoying issue. It makes it very difficult to determine if an optional segment existed in the received message.

I believe that this is caused more by the initial parsing rather than the determination of the count. When the parser (PipeParser) tries to find the segment definition, it calls "GetStructure" which creates the structure, even if the structure is not required.

The effect is that all repeating segments will have a count of at least 1.
However, if there is only one repetition the count will be 1 as well.

There is no way to test for the existence of an optional segment.

I think the better solution here is to change the Parser so that it only creates segments that it needs to.