BTW to provide some details on things that IMO should be part of conformance validation of OPTs 1.4 (maybe as hard rules/invariants or as technical template quality rules):
-
is_integral shouldn’t appear in archetypes or templates where a DV_PROPORTION is used (this is an error in the AE/TD suite)
-
DV_CODED_TEXT constraint code_list can’t be empty if the terminology_id is “local” (this could be valid in the archetype but not in the template)
-
DV_CODED_TEXT constraint ref (acNNNN) should have a constraint_definition entry to be valid in ADL/OPT, and a constraint_binding to be valid in an OPT (without this there is no terminology associated with the DV_CODED_TEXT in the template, which is problematic for some implementations)
-
Interesting: a CONSTRAINT_REF (acNNNN) in ADL is transformed to a C_CODE_REFERENCE in the OPT by the Template Designer, and if there were more than one constraint_binding in the ADL, in the OPT only the first one appears. Worst: the C_CODE_REFERENCE type is not defined in any spec (AOM or AOP 1.4
). I needed to check how I handle this in my own implementation (openEHR-OPT/OperationalTemplateParser.groovy at 24db995e0a5fe7984a14724191c1bb38641dcb46 · ppazos/openEHR-OPT · GitHub) and I manage C_CODE_REFERENCE as a C_CODE_PHRASE with an extra attribute referenceSetUri(not an elegant solution since the types should be specified somewhere in UML not only in a schema openEHR-OPT/OperationalTemplateExtra.xsd at 24db995e0a5fe7984a14724191c1bb38641dcb46 · ppazos/openEHR-OPT · GitHub) -
DV_BOOLEAN constraint C_BOOLEAN shouldn’t have true_valid and false_valid both in false ([SPECPR-376] Add invarianto to C_BOOLEAN: true_valid OR false_valid - openEHR JIRA)
-
C_STRING pattern should comply with some regex flavor ([SPECPR-377] AOM C_STRING.pattern needs clarification on the regular expression language - openEHR JIRA)
-
Missing formal definition of correspondence between the patterns defined in C_DATE/C_TIME/C_DATE_TIME constraints and the values contained in DV_DATE/DV_TIME/DV_DATE_TIME, which are ISO 8601, leaving this area to interpretation of the implementer ([SPECPR-374] Missing information about encoding C_DATE_TIME/C_DATE/C_TIME validity constraints and clarification about supported formats - openEHR JIRA)
These are some points that came out by reviewing different specs from the point of view of creating a conformance specification definition. My concern is, since everything is based on archetypes and templates, the rest of the conformance validation and testing depends in those artifacts, and if there are tiny little details that make these artifacts incompatible between different implementations, we could have tests that pass for one vendor but don’t pass for another.
I know these details might be the 5% of the whole thing and that we have a common view of most of the openEHR platform components and how those should work, is just that in my daily work I need to deal with these little details, make decisions based on those, while trying to be platform independent…