Create rule DDF00027: For classes with next and previous relationships, the next and previous relationships must establish an ordered list of instances of the class (unique nextId and previousId values).

[ASL-rmarshall]

Create generic rule to check for unique values in nextId and previousId as defined for #89

[ASL-rmarshall]

@DianeWold This one is also ready for review. This rule checks for id values used more than once in nextId or previousId (within StudyDesign). It's a generic check that's specified (via Scope) to run for the Activity, EligibilityCriteria, Encounter and StudyEpoch classes.

[DianeWold]

Ran negative data. It found 20 errors, which I think can be accounted for as follows: For StudyEpoch, 4 records in first study design with nextIds that are not unique For StudyEpoch, 2 records for second study design the nextIds that are not unique For StudyEpoch, 2 records for second study design the priorIds that are not unique For Encounter, 3 records in first study design with nextIds that are not unique For Encounter, 2 records in second study design with nextIds that are not unique For Encounter, 2 records in second study design with priorIds that are not unique For Activity, 2 records with nextIds that are not unique For Activity, 2 records with priorIds that are not unique For EligibilityCriteria, 2 records in the first category with nextIds that are not unique. 8+7+4+1 = 20 Positive data returned 4 positives. I assume that is one for each of the datasets. @ASL-rmarshall -- can you confirm I've interpreted the test results properly?

[ASL-rmarshall]

@DianeWold I don't think your results quite tally. Each dataset record with a problem is only reported once, even if it has more than one problem. The 20 reported issues break down like this:

• StudyEpoch: total of 7 records with errors:
  • 2 records for the first study design with non-unique nextId only (rows 1 and 4)
  • 2 records for the first study design with non-unique nextId and previousId (rows 2 and 3)
  • 1 record for the second study design with non-unique nextId only (row 7)
  • 1 record for the second study design with non-unique nextId and previousId (row 8)
  • 1 record for the second study design with non-unique previousId only (row 9)
• Encounter: total of 6 records with errors:
  • 3 records for the first study design with non-unique nextId only (rows 1, 2 and 3)
  • 1 record for the second study design with non-unique nextId only (row 5)
  • 1 record for the second study design with non-unique nextId and previousId (row 6)
  • 1 record for the second study design with non-unique previousId only (row 7)
• Activity: total of 4 records with errors:
  • 2 records with non-unique nextId only (rows 1 and 5)
  • 2 records with non-unique previousId only (rows 2 and 6)
• EligibilityCriteria: total of 3 records with errors:
  • 1 record with non-unique nextId only (row 1)
  • 1 record with non-unique nextId and previousId (row 2)
  • 1 record with non-unique previousId only (row 3)

7 + 6 + 4 + 3 = 20

You're right that the 4 positives is one for each dataset.

[DianeWold]

For StudyEpoch, I counted row 8 twice, when it should only be counted once, though it has two problems. Similar miscount for Encounters. Count for Activities okay. For EligibilityCriteria, I counted errors only within a category, but I see now that the check is within a StudyDesign. That makes sense -- one wouldn't want a criterion twice, even in different categories. Thanks, @ASL-rmarshall , for the detailed help. I now understand the results of both the negative and positive testing, and am moving this issue to Done.

[ASL-rmarshall]

This rule has been updated to only report where rel_type = "definition". Associated test data have been updated and unit tests have been rerun successfully.