Standardizing Validation Check Definitions in the ODM

In a recent post I explained my attitude toward CDISC ODM Vendor Extensions (Summary: necessary evil, we should always push for improvements to the base standard) in the comments EDC Consultant notes :

The largest chunk of time spent when building an EDC study is typically the edit
check building. A typical study might have 500 edit checks. A proportion might
be handled by field attributes such as 'Required'. However, that still leaves a
chunk of edit check development work.

and:

Eventually, new standards for things like edit check logic will evolve. The most successful vendors will be in the strongest position to push their own
vendor extensions 'provided' they are open

My emphasis there.

EDC Consultant is right on the money. If Sponsors want to use the ODM to pursue a write-once-run-anywhere approach to EDC study development then a machine and human readable standard for validation checks will have to be developed. At the moment, the ODM allows the logic of any check more complex than GT/LT/EQ to be declared in an XML CDATA section (i.e. free text).

The question in my mind is...

How should a validation check be defined?

The requirements I see are:

1. Must be human readable.
2. Must be (easily) machine readable.
3. Must reference the study data in a vendor neutral way
4. Must provide for extension via some equivalent of function calls (e.g. AgeInYears, DaysBetween)

People see the combination of Machine Readable and Human Readable and think XML. I shudder. Although XML technologies can be used to perform validations (see this example) the challenge isn't to validate an ODM XML file containing patient data, it is to document the logic of a validation check in a way that can be translated into (and maybe back from) whatever mechanism a vendor uses to validate data in their eClinical system. Technologies I have seen to do this are : VBScript, JavaScript, Java, SQL, C#, XML-based private languages and full homegrown programming languages. I think if it is able to parse a logical expression it has probably been used to write validation checks by someone, somewhere.

Given that CDISC is a committee and given that the people who have most input into the standards are XML-oriented I fully expect we'll have some kind of XML language. That could be appropriate if it allows the validation check to be checked against the schema but a pity if it's just using XML because parsers for it are readily available and nobody wants to put in the effort to define a real language and provide parsers for it.

If offered a choice I'd rather define logic like:

Visit2.VDate < Visit1.VDate

than:

<comparator type="LT">
  <datavalue field="VDate" event="visit2"/>
  <datavalue field="VDate" event="visit1"/>
</comparator>

The XML equivalents are easier to parse but so verbose. A moderately complex check can easily turn to 20 lines of angle-parenthesis madness.

One problem is that the way you specify data validations for a study are dependent on the structure of the underlying data (i.e. vendor database/storage architecture). In one system you might be able to specify a validation check that says "Any place you see a pulse field, check the chronologically previous visit (if any) and compare the pulse value you find there. If it's 20% or more different, fire a warning" in another that might be 5 different checks, each testing pulse in visit 5 vs pulse in visit 4, pulse in visit 4 vs pulse in visit 3 and so on. Another system might not need this kind of validation check at all, placing dates into timelines which provide automatic checks.

Conclusion

I like the idea of a standard way of specifying validation checks. Creating a specification that is expressive enough to support the different requirements of validation checks in different systems is going to be difficult. An XML-based tag-soup is almost certain to be offered because it has the lowest barriers to entry (nobody has to fire up Lex/Yacc and struggle with EBNF) and would integrate well with the existing ODM structure.