Hello everybody, Just a little comment. As Sam Heard said in a previous message openEHR reference model will be stable for some years and as consequence it will not be necessary to include the reference model version. But archetypes can be used with other reference models that may not be so stable as openEHR. We think that this issue should be taken into account when deciding whether to include the reference model version somewhere.
regards Dear All I understand that we are in a place where we have some early implementers out there and it will take a little time until we really have it all sorted. But, and I want to stress this, the reference model that we have after the 3 month comment period will be the one we are stuck with for some time. All openEHR archetypes will work with this release 1.0 model for the forseeable future and I think we need to be quite clear that openEHR does not intend to put out different versions of the reference model in the future. It will be many years before there is another release - and in the meantime we can add many features to archetypes to cope with this. Adding an attribute to the archetype model which is filled with '1.0' in the editing environment will mean that we know in future if there is a problem. Cheers, Sam Rong Chen wrote: 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 -- Jose A. Maldonado. Ph. D. Bioengineering, Electronic and Telemedicine Group Escuela Universitaria de Informatica Technical University of Valencia Camino Vera s/n 46022 VALENCIA (Spain) Tel. + 34 96 387 70 07 ext: 75277 e-mail: jamaldo at upvnet.upv.es http://bet.upv.es
