OET format limitations — two cases where template constraints cannot be preserved

Specifications
1

Hi everyone.

In our workflow, the OET file is the lifeline between the Archetype Designer and the CKM. Over time we have run into a number of issues with the format — some of which we were able to track down and resolve, thanks to the great support from Better and Ocean Health Systems.

However, there are two issues that appear to require attention at the specification level, so I am bringing them here. I will try to explain them as clearly as possible for anyone who may not be familiar with our specific setup.

Issue 1: Parent archetype revision is not recorded

When a template is built using a specialized archetype, the OET file does not record which specific revision of the parent archetype was used. There is no version number or checksum to pin the template to a known state of the parent.

This means that if someone loads the same OET file with a different revision of the parent archetype, the template can change silently — without any warning. Constraints that were applied to elements that exist only in a specific revision may be lost or altered.

Example: A template was built using openEHR-EHR-COMPOSITION.report-result.v1, whose parent openEHR-EHR-COMPOSITION.report.v1 was at revision 1.2.4 at the time. A “Comments” element was added in revision 1.3.1. When the template is later loaded alongside revision 1.3.1, the restrictions on “Comments” are silently dropped.

Proposed solution: The OET format should record the integrity check of each parent archetype used, so that tools can detect mismatches and warn the modeller.

Issue 2: DV_DATE_TIME constraints (e.g. “year only”) are not supported in OET

The OET format does not support date pattern constraints on DV_DATE_TIME fields — for example, restricting a date field to accept only a year (e.g. YYYY). While DV_DURATION constraints are supported, equivalent constraints on DV_DATE_TIME are silently dropped when exporting to OET.

This means a constraint that is visible and correctly applied in the Archetype Designer is lost when the template is exported and re-imported — or shared via a CKM fileset. The OPT (Operational Template) does carry this information, but the OET does not.

Proposed solution: The OET format should be extended to support date pattern constraints on DV_DATE_TIME, consistent with what is already supported for DV_DURATION.

2

I agree with your proposed solution for Issue 1. It may not require any changes to the format itself, just the agreement that the whole specialisation lineage is included in the integrity_checks section. While this will not change the OPT generated from it (the specialised archetype in ADL1.4 has all the information required), it matters when you need the template file set to make any changes in the future.

Without this explicitly recorded, a tool or human can only make some educated guesses about what the original parent archetype may have been.

3

I also agree with your conclusion on the second issue.

This item may be more challenging to address, as it would require a change to the OET schema. However, provided there is agreement on that change, we can certainly explore supporting it within CKM.