# OET format limitations — two cases where template constraints cannot be preserved
**URL:** https://discourse.openehr.org/t/oet-format-limitations-two-cases-where-template-constraints-cannot-be-preserved/17160
**Category:** Specifications
**Created:** [28 July 2026 06:51 UTC](https://discourse.openehr.org/t/oet-format-limitations-two-cases-where-template-constraints-cannot-be-preserved/17160 "2026-07-28T06:51:29Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Martin\_Koch](https://discourse.openehr.org/u/Martin_Koch)
#### Post date: [28 July 2026 06:51 UTC](https://discourse.openehr.org/t/oet-format-limitations-two-cases-where-template-constraints-cannot-be-preserved/17160/1 "2026-07-28T06:51:29Z")
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`.
---
### Author:  [@sebastian.garde](https://discourse.openehr.org/u/sebastian.garde)
#### Post date: [28 July 2026 08:37 UTC](https://discourse.openehr.org/t/oet-format-limitations-two-cases-where-template-constraints-cannot-be-preserved/17160/2 "2026-07-28T08:37:58Z")
> [@Martin\_Koch](#):
>
> **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.
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.
---
### Author:  [@sebastian.garde](https://discourse.openehr.org/u/sebastian.garde)
#### Post date: [29 July 2026 10:21 UTC](https://discourse.openehr.org/t/oet-format-limitations-two-cases-where-template-constraints-cannot-be-preserved/17160/3 "2026-07-29T10:21:01Z")
> [@Martin\_Koch](#):
>
> **Issue 2: DV\_DATE\_TIME constraints (e.g. “year only”) are not supported in OET**
>
> **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`.
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.