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
