Datatype validation using Schematron

1. From the RIMBAA 201010 Cambridge Minutes:
2. The use of data type level Schematron (Alexander Henket, see http://www.ringholm.de/persist/20101004_RIMBAA_Schematron_Instance_validation.ppt for his slides)
   • Nictiz, the Dutch NHIN profiler/enforcer, uses a set of Schematron files to validate the constraints in as documented in the abstract Data Types R1 specification. The constraints are actually those that apply to the Dutch data type flavor, but the mechanism is generally applicable.
   • Lots of implementation guides, 200 schema, 68 interactions - largely hand crafted; parts of which are based on whatever ballot was available at that point in time. And as such there are no MIF specifications to drive the generation of (e.g. Java) classes nor Schematron. The validation tooling is entirely XML-based.
   • Project to validate instance; no validation of workflow aspects or business rules.
     • Use ISO Schematron (xslt2 query binding; XQuery stuff). Cross industry tooling isn't too happy (i.e. they don't support it, e.g. SOAP Sonar) with the ISO Schematron spec.
     • Use "abstract schematron" (irrespective of pattern that it will apply to). Have those for DT R1, CMETs, Message Types. Non-abstract Schematron for interactions, AuthenticationToken (in SOAP header)
     • Their approach supports the full data type specialization hierarchy: the schematron for IVL_TS extends the schematron for IVL which extends the schematron for SXCM which extends the schematron for QTY which in turn extends the schematron for ANY. Based on R2 rules ported back to R1, also checks realm specific constraint rules.
     • Alexander uses Oxygen to illustrate the principle using an interaction example.
     • Future developments: work out strategy for templates.
     • They are in the process of creating CMET/Message type specific schematron files that use the data type schematron and extend them by business-rule validations. This approach has some limitations: schematron doesn't allow pattern-nesting, and creating an MT-schema to MT-schematron transform is a tricky process because of recursion.
   • Kai (see http://www.ringholm.de/persist/20101004_RIMBAA_Dutch_Templates_Schematron_approach.pdf for his slides):
     • Challenge - mapping of 'clinical data sets' to the RIM, requires template mechanism. looked at templates DSTU. Added concepts from DCM. Desire to generate Schematron based on template definitions. COR (new development, a DSL) as simple constraint definition language; generates schematron.