ICARM: This is the “softer” form of VCARM – i.e. it is just a piece of information that while there is no corresponding attribute in the model, there is a functional property that is commonly constrained. Typical examples are offset and is_integral. These are frequently constrained. There was a big debate a (longer) while about whether this is correct/good practice or not and I don’t think this has been 100% resolved. For CKM – as well as the Java Archetype Validator - we decided to inform the user, but not report this as a VCARM.
VUI: This is the error type to report that a unit in a DV_QUANTITY are not valid UCUM units as required by the specs.
I believe that you are right that there is no explicit error type named for this in the specs…so while this directly validates the specs, the naming VUI (Validation Unit Invalid) is arbitrary at present.
WLIC: This is just an internal CKM warning to indicate that the licence for the archetype as specified in the ADL differs from the default licence configured in CKM.
Are all of those internal to the CKM?
Is there any plan to document them in some place to have all the rules together?
Maybe there are a lot of internal rules that we don’t know of and would be useful to have them documented. (Maybe a task for the clinical models program?)
· ICARM needs to resolved – either it is ok to constrain any functional property or it is not.
If ok, then this info (not error) can be removed completely. If not ok, ICARM would be VCARMs as well (as it used to be until the discussion started). ICARM / VCARM are implemented as part of the openEHR Java Archetype Validator.
· VUI: I think this should be an official validation error. VUI is implemented as part of the openEHR Java Archetype Validator (actually I am just working on an update for this)
· WLIC: This really only applies to a CKM ecosystem of some sort. Could be documented somewhere, sure, but really this is just a CKM warning message.
only a few rules were specified in ADL/AOM 1.4 - you can see them in the ADL1.4 spec - I think you will find the newer HTML version easier to use. They were not collected in an easy to read list, but I think we could do this easily enough by constructing an index of the relevant paragraph type, and inserting that into the document. I’ll see what is possible in Asciidoctor.
In ADL2, it is the AOM2 spec that provides the validity rule definitions.
I’m not sure what the total set Sebastian uses is, but I suspect it includes some of the AOM2 rules, i.e. those that would have the same meaning for ADL1.4 archetypes.
We should improve how these rules are represented in the specs potentially, and a minor update to the ADL1.4 spec could be used to update the effective rule set for ADL 1.4
I think it would be very useful to have a centralized list of validity rules with a reference to the source (specs, CKM, other specific tool, good practice, local rule, etc.).
As a developer, that would help me to use those rules in software.
And as a clinical modeler I can check those rules while designing an archetype or a template (manually or using a tool).
The spec rules should be on specs (doh!) but I think we might need something more dynamic that we can use to add / maintain rules from all the current sources, like a github repo for rules (can be a page on the openEHR wiki o the wiki on a github repo).