If different versions of the OpenEHR (or any other model) are available on an application they should be used as different RM, because usually the changes in the reference model can make newly created archetypes (1.0.2 in your example) not to parse with older RM parsers (1.0.1) The currently specification of archetype id can handle this already perfectly. An archetype like "openEHR-EHR-INSTRUCTION.medication.v1" will turn into "openEHR-EHR1_0_2-INSTRUCTION.medication.v1" (and using underscores is only because currently the parser won't allow dots on the id) If dots were allowed you could rewrite this as "openEHR-EHR1.0.2-INSTRUCTION.medication.v1" as opposite to "openEHR-EHR1.0.1-INSTRUCTION.medication.v1" that would only parse with 1.0.1 parser
Regards 2009/2/9 Tim Cook <timothywayne.cook at gmail.com>: > Okay, > > Maybe the subject line is a little melodramatic. :-) > > But we do have a situation and a good bit of this email (along with your > consultations) will be placed as a Problem Report (PR) on the > openEHR.org website. > > My point of view is that we have a multi-level modeling environment and > therefore we have a multi-level problem solving environment. It must > ALL work together. Archetype designers and application developers. > > I'll be a bit shallow in this email and will not look up specific > instances. But there are place(s) within the RM where the RM version is > recorded. > > The archetype tools should record this information in the archetype > saying that this version of THIS archetype was built against a specific > openEHR RM version. > > There are VERY specific guidelines as to what and what does not > constitute various archetype version changes. Maybe/maybe not these > should be reviewed in reference to RM versions? > > Since we all have very good crystal balls..... > We can see a future where at RM version 2.5 there are significant > differences to RM version 1.0.2. > > However; we have Mary in rural Montana USA, a patient a Dr. Jones's > office (believing strongly in future proof) and she moves to a new city; > let's say Atlanta, GA. Where Dr. Brown (ALSO! believing strongly in > future proof) has been on top of things and is now at RM version 2.5. > > Well, Dr. Brown gets Mary's record from Dr. Jones and discovers that > some of the archetypes that were built 15 years ago in 1.0.2 RM just > simply do not display or worse yet cause unknown type errors and his > application(s) crashes. > > Future Proof? Hardly!!!!! > > Doesn't seem much different from the migrating SQL data base schema > problem does it? > > > So I believe that we as a community should take multiple courses. I > want to emphasize that we should take THEM ALL! > > First: an archetype tool developer MUST record the RM that an archetype > was built against. > > Let's say RM=['1.0.1'] > > (okay so I apologize for my Python syntax, but it's easy to read). > > Second: An archetype is edited (whether it's version changes or not) > against a tool using RM 1.0.2. > > The RM = is now RM=['1.0.1,'1.0.2] > > At some point this archetype has now been validated against 2 RM > versions. It should work with both RM versions and the consumer > (application developer knows it). > > > Third: The application developer has a choice to make. Either read the > list and support backwards compatibility based on the last known RM > version or simply be NON-FUTURE-PROOF and reject the data. > > > At the very least, the archetype contains the information needed to let > the application know what it expects in order to be rendered and > processed. > > So in essence, I TOTALLY disagree with Tom's statement: > > >> > I don't mind including the release number of >> > openEHR when the archetype was first released, but I don't see how it >> > can be useful information. >> > >> > > > Sorry Tom; if it's put in a list, I can see EVERY reason why it is useful > information. > > The openEHR documentation is VERY VERY VERY good. There is no reason that an > implementer could possibly accommodate multiple RM versions. > > Regards, > Tim > > > On Sun, 2009-02-08 at 11:03 +0000, Thomas Beale wrote: >> Sam Heard wrote: >> > Hi All >> > >> > I would suggest that we have a very strong backwardly compatible notion on >> > each reference model and do not do anything that would invalidate current >> > archetypes in RM 1.x >> > >> > This would mean that we only had to record the highest level version that >> > an >> > archetype was compatible with in the archetype RM 1.0 and leave it at that. >> > >> > I am sure people working in the environment would like such an approach. >> > >> > It means we have two rules: >> > All archetypes of the same version are compatible semantically >> > All archetypes work with the reference model version (1,2 etc) and go on >> > being compatible. >> > >> > Cheers, Sam >> > >> *I still have not see a solution to the basic problem that if we record >> a compatibility release(s) _inside_ the archetype, then whenever a new >> release of openEHR comes out, thousands of archetypes would be updated >> to reflect the new release number. If this is not done, then those >> archetypes will over time look as if they stopped being compatible with >> later releases of openEHR. Making the modification means that every >> archetype in every local repository would have to be modified this way, >> as well as in central places like CKM. And it means that we are now >> re-issuing archetypes when no update is needed to the content. I can't >> see how this can work. I don't mind including the release number of >> openEHR when the archetype was first released, but I don't see how it >> can be useful information. >> >> - thomas beale >> >> >> * >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- > Timothy Cook, MSc > Health Informatics Research & Development Services > LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook > Skype ID == timothy.cook > ************************************************************** > *You may get my Public GPG key from popular keyservers or * > *from this link http://timothywayne.cook.googlepages.com/home* > ************************************************************** > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- Diego Bosc? Tom?s <diebosto at fis.upv.es> <yampeku at gmail.com> Grupo IBIME Instituto ITACA - Universidad Polit?cnica de Valencia Acceso B Edificio 8G Camino Vera s/n 46022 VALENCIA (Spain) tel: +34 963 875 277 http://ibime.upv.es
