Create general rule: For classes with next and previous relationships, the next and previous relationships must establish an ordered list of instances of the class.

[ASL-rmarshall]

Create rule defined for #89

[ASL-rmarshall]

This is the generic equivalent of the specific StudyEpoch rules created for #48, which are based on the checking components identified to determine correct ordering. I'd expect there to be at least two rules to check all the ordering components:

1. to check the components relating directly to the characteristics of the entity that has the previous and next attributes. See #73.
2. to check the components relating to the "parent" entity (usually an instance of StudyDesign). See #117.
3. potentially to check that relationships to previous and next instances are complementary, if this can't be accommodated in either of other two rules. See draft specification currently included in #117.

For all of these checks, I'd expect the logic to be the same as the corresponding StudyEpoch check, but either with additional entities specified in the Scope, or with the relevant entities being identified via a Match Datasets specification.

[ASL-rmarshall]

Not all these rules should be run for EligibilityCriteria because ordering for EligibilityCriteria is within both StudyDesign and category . This may only affect the StudyDesign components.

[ASL-rmarshall]

Checking for complementary nextId/previousId will be simple if references (rel_type = "reference") are available in the (test) data. To avoid having to update the whole test data template, the rel_type column could be added manually. The check would be report where (rel_type equal_to "reference" and (parent_rel equal_to nextId or parent_rel equal_to previousId) and not ((parent_rel equal_to nextId and parent_id equal_to previousId) or (parent_rel equal_to previousId and parent_id equal_to nextId))), with a Scope that Includes all the classes than have both nextId and previousId