OPT Versioning on CDRs, esp. EHRbase

Thaks Borut,

I agree with your comments that minor and patch changes do not need any original compositions to be updated. The logic should be identical to that applied for archetypes - if a path that was valid an iny existing compositions changes or is deleted, that is a major version change and requires specific handling.

I agree it id a challenge for impleneters but is not unique to openEHR - we see the same challenges in FHIR and even in SNOMED when internal relationships need to be updated.

This was also part of @Sam disacussion at EghrCon25 on how to minmise the burden, particualrly as you say, that in many cases, the breaking change is not operationally relevent as the paths being altered were never in the original template.

I’ll come back on this (maybe we should strip this out into a separate topic) as I think it is an important area. I have had an idea about aliasing archetypeIds (part of the ADL2 transition challenge), which may actually help here too.

Could you maybe copy that part of your response into a new topic and I’ll jump in there?

@vidi42 - this is really good news and very much in line with the new SEC guidance/spec on using the HRID (ADL2) pattern to identify ADL1.4 templates - basically what Ehrbase is now doing but with the addition of a namespace. All of the CDR vendors and tooling vendors are signed up to support this change which is just going through final SEC review, so hopefully tooling will make this fairly use to setup before long, though it remains optional

e.g. com.medblocks::template_test_name.v2.0.1