Hi A couple of key points:
1) 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. 2) 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. 3) 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. 4) 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. 5) 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. Cheers, Sam On 15/06/2012 12:05 AM, Thomas Beale wrote: > > It needs a bit of updating, but most of the answers are in this doc > <http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf>. > > - thomas > > On 14/06/2012 10:30, Diego Bosc? wrote: >> Hello all, >> >> 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? >> > * > > * > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120618/61edcbcf/attachment-0001.html>
