Returning to the topic of a rules language for CDISC ODM.
Well, I spent about 5 minutes reading about RuleM. That was sufficient… Enough said, not worth investigating.
However, ARDEN, despite its relatively quiet times in the past few years does still seem to offer some hope. It offers a relatively structured syntax, that is not overly complex, and, with a few extensions that have already been hinted at by some of the supporters, it could be made to work for ODM.
So – how would ARDEN be bolt onto ODM.
One approach that is common for edit check languages is the edit check execution by reference. Rather than bolting an edit check onto each field, with references to other fields, you simply attach a list of edit checks to a study, and, the references inside the syntax determine when the edit checks actually fire. So, for example, an edit check on Age might check that the Date of Birth is X years greater than the Date of . X is a constant, but Date of Birth and Date of Screening may appear on separate forms. So, the ARDEN edit check syntax should exist at the study level.
Instances
In the perfect world, the edit checks would not be specifically associated with a visit/form/field combination Instead, you might associate the visit with a Table/Field combination, and have the edit check fire by reference whenever the field is used in a Visit/Form/Field. This approach assurance maximum re-use. However, the flat ODM format is not about re-use. It is about representation for a particular study implementation. The re-use part can occur before it gets rollout out into a ODM Metadata definition. What this means to the syntax is that it doesn’t greatly mater if the same edit check appears many times across the study for the same form/field combinations.
Wildcards
Despite the potentially for edit checks repeating when forms repeat, a requirement exists to handle wildcard references. For example; Visit Date on any Form. The dot notation such as *.*.VSDTC would mean any Form and any ItemSet