I have been thinking a little about archetype specialization and versioning and how do those two relate. I don’t know how it is being solved right now, but seems like a big issue for the future. Take the following scenario:
We have an archetype (e.g. ‘openEHR-EHR-Evaluation.problem.v1’) and a specialization of that archetype (e.g. ‘openEHR-EHR-Evaluation.problem-diagnosis.v1’). Now we generate a new version of the parent archetype (creating a ‘openEHR-EHR-Evaluation.problem.v2’).
If we create a specialization of ‘openEHR-EHR-Evaluation.problem.v2’, what identifier should it have?
How can we distinguish which is the parent of archetype mentioned above (‘openEHR-EHR-Evaluation.problem.v1’ or ‘openEHR-EHR-Evaluation.problem.v2’) using only the identifier information? (I know that parent information is inside the archetype)
If both parent versions of the concept are valid and you generate new specializations from them, how is this handled?
The answer is that you cannot determine which version of the parent is
being used from the archetypeID, and that can only be determined from
other metadata in the archetype. V2 refers to the specialisation not
the parent, although of course a version change in the parent would
force a version change in the specialisation, though not vice-versa.
Proposals for the next update to archetype identifiers, which will
include namespaces, will almost certainly drop the requirement to
carry the archetype lineage in the archetypeID at all, so that there
is no need to carry the names of any parents. The RM will have to
change to allow the lineage to be carried along with the archetypeID,
to support querying. We explored various alternative naming schemes
but it just gets horribly complex once you try to add parent versions
and namespaces to the archetypeID.
We have to maintain a backwardly compatible revision process that allows all data from previous instances of the (same version of the) archetype to be compatible with the future revision (either of the specialisation or the parent). This is formally tested in CKM. This greatly simplifies the versioning and maintenance.
The inclusion of differential archetypes for specialisation in ADL 1.5 allows revision of the parent without updating the specialised child. This takes away much of the maintenance associated with revision.
Versions are NOT backwardly compatible - so in the example the specialised archetype would be version 2. The issue is if the specialisation is versioned and not the parent. It will be necessary to use a different name in the current scheme. We are finding that using a different name for radically different archetypes is sometimes a better alternative to versioning as people may want to increment one in current use.
Thomas and others are proposing compatibility records in the data (as is used by CDA). The alternative is to have meaningless IDs that are reconciled using a source of truth (like CKM). This does require that all archetypes are registered in a CKM like environment that is formally part of the openEHR ecosystem. I think we will likely end up somewhere like that.
Having some pressure to limit the number of archetypes out there - encouraging alignment - in these early days is very helpful. After all, we are seeking interoperability and it does mean we have to put in the effort to get people using the same concepts.