That we are very cautious about reference model version changes doesn't mean that any other organization does the same. Look at HL7 v2 & v3 for example ;)
2011/4/8 Thomas Beale <thomas.beale at oceaninformatics.com>: > On 07/04/2011 12:07, David Moner wrote: >> 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. > > I have no problem with a UUID or similar, but I don't think they are > that useful on their own, and they require more tooling support. If you > want to make inferences about what RM class, and what clinical concept > a given archetype is about, and you only have a UUID, you need to know > what / where to lookup. You also have to be able to have rules somewhere > to know when to assign a new UUID, when to treat two different UUIDs as > referring to archetypes that are actually revisions (i.e both compatible > with the same data), when to treat them as versions (not compatible with > the same data). We could potentially make the RM class name and concept > id just new fields in the description. The thing you lose (and maybe it > is worth losing) is that by creating a tuple of a particular subset of > meta-data items, viz: publishing organisation + RM issuer + RM class > name + archetype concept id + archetype version id, this happens to be > the unique key in archetype space (a new revision or new translation on > the other hand is obviously a new artefact, but it is not semantically a > new archetype). To achieve the equivalent with a UUID -based id system > means smarter software and either centralised id management (ISO oids) > or some distributed id system, possibly like DNS. At the moment we can > process the archetype id and directly know the relationship between two > archetypes. I think going down the UUID road will require more agreement > on tools and governance infrastructure. > >> >> 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. > > I don't know what R3 looks like, but if it is a different reference > model, then the ids would be something like > > hl7-cda3-Entry.diagnosis.v1 > > If CDA r3 on the other hand is a clean extension / superset of CDAr2, > then the 'reference model' is really just 'cda', and there is no simple > relationship between particular archetypes and particular releases of > the CDA model. > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
