We are investigating whether CDRs support versioning or auditing for OPTs, for example who uploaded or replaced a template and when; similar to how VERSIONED_OBJECT works for compositions.
This seems relevant when a template is overwritten and the new version causes problems with existing compositions, requiring access to the previous version. It could also be important for troubleshooting, auditing, and production data governance.
I could not find anything about OPT versioning in the openEHR specifications.
Better provides a proprietary mechanism: overwritten OPTs are “retired”, only the latest version remains active, and an /admin/rest/v1/templates API supports retiring and unretiring templates. It also exposes basic version data such as upload and retirement timestamps and the OPT XML.
EHRbase provides an administrative template API at /rest/admin/template, according to its documentation, but as far as I can tell it supports updating and deleting templates without keeping a version or audit history.
Without a common CDR-level mechanism, applications need to implement their own template governance and versioning service. Some application-level governance is likely necessary anyway, but basic template versioning still seems like a core CDR capability that applications should be able to rely on, particularly as a fallback when something goes wrong in the application or when templates are modified by third-party actors.
My questions are:
- Does EHRbase or HIP provide an OPT versioning or audit mechanism that I have overlooked?
- Is OPT versioning intentionally out of scope for the openEHR specifications, or is it simply a gap that has not yet been addressed?