CS tooling liaison

This page is for Clinical Statement Tooling Liaison notes:

OWL-RIM based model validator/checker

Use case is, for Clinical Statement: Take an RMIM and check that it conforms to the Clinical Statement DMIM

Generalising - compare any model to any other, and see if A conforms to B. Typically one is an RMIM and one a DMIM, but RMIM to RMIM, CMET to DMIM etc. are all also useful.

Check RMIM is a constraint of a DMIM. Check all classes, attributes, relationships, datatypes, cardinalities, conformance, vocabulary/terminology of RMIM, are allowed in the DMIM. An valid instance of the RMIM would always be an instance of the DMIM. In practice ITS issues, around class/element renaming, mean that an RMIM instance will not necessarily look like an instance of the DMIM, but it may still conform.

Background: The HL7 model development methodology is based on refinement by constraint. Starting from the RIM, other models constrain down, and unroll classes and relationships. In this way the new model is a true subset of the original (but can also be larger, in terms of “unrolled” classes expressed).

Why it’s needed: HL7 models are meant to be built this way, but often in fact are not, due to human error. This means there are often errors in published material where a domains RMIMs or CMETs don’t match the same domains DMIM.

There is no tool that allows one model to be derived from another, except that Visio forces you to conform to the RIM model. In the ideal world it would be possible to start with a DMIM and constrain it directly, thus enforcing compatibility up front. Without such a tool it is left to the modeller to draw a new model that conforms, often starting from scratch. This is error prone, even assuming the person knows the original model well enough to know what the derived model should look like, never mind model it correctly.

In the absence of that tool, a good second best is a tool that checks models are compatible. Ideally this would be built into Visio, so you can compare the current model to another. This then approaches a tool that enforces compatibility when modelling. However it is assumed that an easier first step is for it to be available as a “command line” tool, to run as a QA step after modelling. It would presumably work from the MIF of each model, or the Visio xml. Output would be a textual report of what in the second model is not compatible with the first.

The alternative at the moment is to manually check every class, attribute etc. between the two models. Typically involving creating a large spreadsheet by hand, this is time consuming and error prone, and needs to be repeated when either model changes.