Me encanta tambien que tenemos amigos en Espana. Ogi Pishev Ocean Informatics
----- Original Message ----- From: ""Parra Caldern, Carlos Luis"" <carlos.parra.sspa at juntadeandalucia.es> To: <openehr-technical at openehr.org> Sent: Tuesday, February 21, 2006 9:25 PM Subject: RE: Suggestion about the Multi-axial Archetype Indentifier > Jos? Alberto. > > Me encanta que en estas listas de distribucin aparezca gente con los pies > en el suelo y que desarrollan en el mundo real. > > Carlos Luis Parra Caldern > Coordinador de Proyectos > Servicio de Tecnolog?as de la Informacin > Hospitales Universitarios "Virgen del Roc?o" > +34 670940392 > -----Mensaje original----- > De: Jose Alberto Maldonado [mailto:jamaldo at upvnet.upv.es] > Enviado el: lunes, 20 de febrero de 2006 17:42 > Para: openehr-technical at openehr.org > Asunto: Re: Suggestion about the Multi-axial Archetype Indentifier > > 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.pd > f), > 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 > >
