Dear Thomas, I agree with your general approach, but you miss two important things.
1. If openEHR spreads, you cannot expect that all implementations will be always up-to-date. That means that just upgrading the version number of the archetype will not be enough for a system to automatically differentiate the right version for the RM version they have implemented. If we just say "Ok, but since that information will be at the archetype header we don't need it at the identifier", we can also say the same for the concept, the RM class, the RM and the organisation. At the end, we will find that we don't need a semantic id, as Erik said, and that a UUID, OID or whatever is enough for identifying archetypes. 2. Archetypes are not only for openEHR. We must always have in mind that other reference models can be used with their own life-cycle that could be not so fine-grained as in openEHR. For example, we are now creating HL7 CDA R2 archetypes but during this year it is expected CDA R3 to be approved. How will we differentiate archetypes of R2 from archetypes of R3? Once again, R2 will still be used for many years and updating the version number isn't enough. Finally, I also agree that is not the same to talk about "RM version of an archetype" than to talk about "archetype validity regarding a RM", but one should not exclude the other. David 2011/4/7 Thomas Beale <thomas.beale at oceaninformatics.com> > On 05/04/2011 19:16, David Moner wrote: > > Hello, > > I like that approach regarding namespaces, it will be needed sooner than > later. > > Related to archetype identifiers there is another problem still to be > solved. How they deal with RM evolutions? Current openEHR RM release is > 1.0.2 but it can change in the future. Nowhere at archetypes is said which > RM version was used to define them. This information should go, at least, at > the archetype header, but probably should also be represented at the > archetype id. Otherwise we will not be able to differentiate between an > archetype for one version of the RM and the same archetype (modified if it > is the case) for a different one. > > > It should go in the archetype, that is for sure - but it should be > understood only as 'the RM version used when this archetype was authored / > quality assured etc' - rather than 'the RM version for which this archetype > is valid'. The reason is easy to understand: for some particular archetype, > authored at RM 1.0.2 let's say, it may be valid for many RM revisions after > that, even RM 2.x, and not only that, it might be perfectly valid for prior > revisions e.g. 1.0, 1.0.1, even 0.95 - it can depend a lot on what parts of > the RM the archetype happens to use. This is the reason I argued against > including the RM version in the archetype id, because it doesn't tell us > anything about validity. (We had a long discussion about this on the > technical list last year or 2009 I forget which). > > Now.. if the RM changes, let's say to 2.0.0, then we might assume that > there are one or two breaking changes, and that a few archetypes could > break. The only way I can see to deal with this is: > > - we stick with the rule that minor RM change numbers never break > archetypes (or indeed existing data), i..e 1.0.1 -> 1.0.2 -> 1.0.3 etc is > guaranteed safe > - we say that a major RM version change, i.e. 2.x, 3.x etc that > includes breaking changes there has to be a validity test run on all > archetypes. > - any that don't pass, i.e. are compromised by the change need to be > marked in some way, maybe a header field with the meaning 'valid up to > RM > release xxx' or so. > - such archetypes would themselves then have to be versioned > (xxxx.v1 => xxxx.v2) > > It should be remembered that we can undertake many innovations and 'fixes' > that don't break anything on the RM, and therefore don't require a major > release. So openEHR 2.x, 3.x etc are likely to be extremely rare events. > > - thomas > > > > > -- > [image: Ocean Informatics] *Thomas Beale > Chief Technology Officer, Ocean Informatics<http://www.oceaninformatics.com/> > * > > Chair Architectural Review Board, *open*EHR > Foundation<http://www.openehr.org/> > Honorary Research Fellow, University College > London<http://www.chime.ucl.ac.uk/> > Chartered IT Professional Fellow, BCS, British Computer > Society<http://www.bcs.org.uk/> > Health IT blog <http://www.wolandscat.net/> > * > * > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110407/e2124891/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110407/e2124891/attachment.jpg>
