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
