Thomas Beale wrote: > David Moner wrote: >> >> Hello everybody, >> >> We'd like to make a suggestion related to the Archetype Identifier >> syntax. >> >> At 'The openEHR Archetype System' document we can find the definition >> for a multi-axial archetype identifier. One of its parts is the >> model_name label. We think that it should be necessary to add there >> the model version we are using as basis for defining the archetype. >> This would be the only way to check if the archetype definition >> structure is valid. >> >> For example, we can create an archetype based on open EHR Reference >> Model version 0.95. One of the things that the EHR system has to do >> to validate it is to check if it matches the RM structure. But, what >> happens if the system has information about both openEHR RM version >> 0.95 and version 1.0 in its 'databases'? It will not be able to do >> the correct validation because it doesn't know which version is >> applicable. So we need a way to include the reference model version >> we are using as basis for building the archetype. >> > This is an important point. > > I have to admit that I thought we had an rm_version attribute on the > ARCHETYPE class (see > http://svn.openehr.org/specification/TRUNK/publishing/architecture/am/aom.pdf), > > but I see that we don't. If we did, it would mean that the archetype > could be checked for compatibility with the reference model. > > However, clearly if we wanted an > openEHR-EHR-OBSERVATION.cardiology_exam archetype for Release-1.0 and > for Release-2.0, we would have a problem. Starting from Release 1.0 we > have rules about what can change, and one of them is that changes to > the reference model that are not error corrections can only occur in a > new major release (i.e. Release-2.0, rather than say Release 1.0.1 or > 1.1). > > As long as we stick with that, we are safe for now; we could take the > line that in the front part of the identifier, the "openEHR" in > "openEHR-EHR-OBSERVATION" really means "openEHR-1.0", and when we get > to openEHR-2.0, we will in fact start doing "openEHR2-EHR-OBSERVATION" > and so on in the future. Under this rule, we would only include major > version numbers in the identifier, but not the two minor numbers, i.e. > going to Release 1.3 won't make any difference to archetype ids. > > Not putting the version number in the id for the moment also means > that Release-0.95 and earlier archetypes have to be treated as > "possibly invalid". > > Let's look at this another way: a given archetype might very well > remain valid over a number of releases, e.g. Release-0.95, > Release-1.0, Release-1.2, etc...and even over Release-2.0, Release-3.1 > etc. For example, most/all SECTION archetypes are likely to remain > valid forever. So do we really want to have "openEHR", "openEHR2" etc > all over the place when in fact some/many archetypes might very well > be valid for numerous releases of the RM? > > I wonder if the best approach is to add an attribute to ARCHEYTPE > class like the following: validated_rm_versions: List<String>, i.e. > the list of RM releases that this archetype is valid against (such a > check is not that hard to run when we have done some more work on the > tools). This would mean that you don't know a priori if a given > archetype is guaranteed to work with a given release just from the > name, but you could tell by checking this list. Problem: if it doesn't > work with a certain release, do we then go back to using "openEHR2" > etc? And I have glossed over the fact that even a minor release (e.g. > 1.0.1) could in fact invalidate some existing archetypes, if they > happened to rely on some attribute name or type that was changed. > Maybe another rule could be used: > > - name archetypes just using "openEHR-...." as we do now > - if they fail to validate against a certain Release, e.g. > Release-1.3.2, then create an archetype "openEHR132-...." with the fix > in it > - then when searching for archetypes to use, your system has to look > for archetypes that might override the default one, for a particular > release. > - to help this, we might have an attribute which is the reverse of the > one I mention above, i.e. nonvalidated_rm_versions: List<String> - the > list of releases this archetype won't work for.... > > One final point. We have to remember that in a particular deployment > environment, we will know what release of the RM the software is made > from, and we will have a local archetype repository containing the > (e.g. 65) archetypes actualy in use here (not the 2054 available in > some WHO online library). The only way an archetype can get into your > local repository is for it to be validated against the RM your > software and data are based on. > > there is definitely a problem to be solved here... > > thoughts? > > -thomas > I agree that we need to include a version number in the archetype to indicate the original version of the reference model (RM) that an archetype is created to constrain. This would make it possible to work with archetypes constraining different versions of the reference model (RM) at same time, and handle data created/validated with legacy archetypes/reference model. We could include the RM version number in ArchetypeID as David suggested, but having that information in the archetype header section (just like adl_version) instead of ArchetypeID seems to be better to me because 1) it doesn't require any changes to the current ArchetypeID syntax; 2) it makes it possible to handle archetype changes (adaptations) of different version of RM as versions of the same archetype.
One related issue is ADL parsing and validation. Access to the right version of the RM/AOM is required for the initial ADL parsing and post-parsing validation against a specific version of RM. Without knowing which version of RM to use for validation, it's impossible to know if the archetype, expressed in ADL, is valid or not. Therefore we need to know at least the starting version number of RM which the archetype is built on. The following version numbers which an archetype is compatible with (or not) can be found out by the same logic for post-parsing validation. But, do we really want to work with different version of RM at same runtime system? The issue is not only related to persistence layer, but also related to application logic for querying RM. It will be quite tricky to load different versions of RM and at same time keep the surrounding logic intact. Rong
