I also agree on this. It is a good idea to decide the versioning from Archetype to Archetype. If there are no need for breaking changes in the Archetype then the version should not be altered.
If some of the archetypes from a clinical point of view must be changed in a not backward compatible way then the Archetype should be either a) moved to a new version (v2) or b) if the changes are very large moved to a completely new Archetype. As many have said it is use at own risk when using Archetypes that is not approved. Said that , I think it is important to show that openEHR Archetypes is a safe choice for the long term. This is why we should not change naming and versioning without very good reasons. +1 for the proposal from Marand v/ Bostjan :-) Vennlig hilsen Bj?rn N?ss Product Owner DIPS ASA Mobil?+47 93 43 29 10 -----Original Message----- From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Heath Frankel Sent: 13. oktober 2014 00:11 To: For openEHR technical discussions Cc: For openEHR technical discussions; For openEHR clinical discussions Subject: Re: Archetype Naming proposals - do we need V0? I completely agree with this, The number one priority is that all existing clinical data using archetypes published in CKM for the last 2-5 years is not Invalidated by this process. I understand that it was use at your own risk but surely vendors that have taken the risk to be early adopters get some support by the foundation. I think we need to keep all archetypes in CKM as they are unless there is evidence that no one is using a particular archetype. They must be treated with the same status of published as new ones, they have passed the test of time and more importantly the test of implementation. I see no problem with starting with v2 for the next iteration. Regards Heath > On 7 Oct 2014, at 2:02 am, "Bo?tjan Lah" <Bostjan.Lah at marand.si> wrote: > > Hi everybody, > > sorry for not jumping in this earlier... > > We (Marand) are looking at this from a vendor point of view much like > Sebastian from Code24. We have quite a bit of existing data, apps with AQLs, > etc. > > Now if I understood everything correctly we have two ways: > - existing archetypes would initially change from v1 to v0.* something > and once published would become v1.0.0 > - existing archetypes would initially change from v1 to > v1.0.0-unstable (or -alpha - to be decided) and once published would > become v1.0.0 > > I have no problem with either style and think both would work equally well. > > But this is not the only change - we would also add namespace to ids so final > (published) full archetype id would be: > org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.0 > which includes namespace as well as new full version number. > > So this makes change anyway much larger and needs to be tackled no matter if > versions in CKM now go to v0 or to v1*-alpha. > Even though archetype id will in fact not change in ADL1.4, other_details > will carry all the rest and we can already start using it. > > The question is - does it make sense to start using it while our whole stack > is still on ADL1.4 as it affects quite a few things: > - existing stored RM data > - RM paths - this might be in AQLs or other tools that use such paths > > I would think this is too much hassle and would probably change to new > versioning only when we also support ADL2. > > The only danger I see with this is that we'd suddenly have existing archetype > ids in the system with openEHR-EHR-OBSERVATION.lab_test.v1 which in CKM might > be completely different due to them going though the release process (back to > v0* or v1...-unstable) and finally becoming > org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.0. > This case would indeed be solved by releasing them as v2.0.0 instead of > v1.0.0 - perhaps this can be on case-by-case basis - I assume not all > archetypes in the sprint will change in an incompatible way? > > Best regards, > -- > Bostjan Lah > Marand d.o.o. > >> On 5 Oct 2014, at 21:03, Sebastian Iancu <sebastian at code24.nl> wrote: >> >> On 10/3/2014 5:40 PM, Ian McNicoll wrote: >> >> Hi Ian, >> >>> Hi Sebastian, >>> >>> Many thanks for your input. Your contribution is particularly important as >>> Code24 is, as you say, one of the early pioneers of managing openEHR data >>> and related artefacts. >>> >>> You have raised an important and very real issue, but I agree with >>> Sebastian Garde that the .V0 question itself, is actually not what is going >>> to potentially cause you a problem. >>> >>> Firstly I would defend what has been done in CKM to date as being >>> completely in line with the specs and with the revisioning rules (which >>> actually have worked extremely well for published archetypes). It has >>> always been clear that any archetypes not marked as 'published' must be >>> considered unstable and cannot be guaranteed to follow the numbering rules. >>> I understand why you might take a view that 'anything that appears in CKM >>> is de-facto published' but that is not, and never will be the case. CKM is >>> first and foremost a clinical review environment which will always contain >>> a mix of draft, published, re-draft and re-publshed archetypes. >>> >>> Having said all that, none of us are happy that it has take so long to get >>> to a stage where we could get sufficient resource to properly fund >>> editorial resource to take many archetypes through to publication though >>> thankfully, through the Industry Sprint that point has now arrived. I am >>> also familiar with and have sympathy for the issue you have raised which I >>> will try to elucidate here, as I agree with Sebastian that it is a separate >>> issue from V0. >>> >>> Your current situation is that you have used .v1 archetypes in your >>> production system, even though they are marked as 'draft' in the metadata >>> and by definition will have unstable structures leading to a situation >>> where ongoing draft development and eventual publication of the draft v1 >>> archetype may well break existing query paths in your patient data and in >>> related code and querying statements. Although you can differentiate the >>> draft from published archetypes in the archetypes themselves, there is no >>> way that you can tell whether the instantiation of problem_diagnosis.v1 in >>> patient data refers to the published version or to the previous draft >>> version (and this may well include a breaking change). >>> >>> The problem essentially is not that the archetypes themselves are >>> mis-labelled but that the archetypeId carried in data is not sufficient to >>> disambiguate a draft archetype from a published archetype. >>> >>> This is a situation that was discussed on the lists a couple of years ago >>> around the import of the NHHTA lab archetype where it was recognised that >>> calling it lab_test.v1, been though it had many structural changes was >>> going to cause problems for a number of vendors who had used the original >>> draft lab_test.v1 in their applications. >>> >>> We asked the vendor community for their response and the message we got was >>> that "by using draft archetypes we recognised that this might happen" and >>> that we should keep the archetype at v1. >>> >>> I should add that this is not purely an issue for V0/V1 archetypes. When a >>> published v1 archetype goes back into draft we will face the same issue, >>> and for v2 and v3 etc. If vendors are going to use draft archetype in >>> systems and in tooling (and they will) we need to be able to clearly >>> identify unstable archetypes inside patient data and query statements, and >>> not just in the archetypes. Vendors who do this need to understand that >>> such an archetype is unstable and will break the rules but at least it is >>> unambiguously identified in the patient data and any queries. >>> >>> This obviously comes back to the main discussion about the use of -unstable >>> in the Semver proposals and I will try to explain our thinking in response >>> to others who have made alternative suggestions. It turns out to be >>> very,very tricky, and I don't think it is an accident that we have come >>> back to Semver as the basis for a solution. >>> >>> So the issue you raised is real and significant, and will be faced >>> by any vendor who is using a v1 draft archetype in an operational >>> system. Adopting the new naming/numbering system will solve the >>> problem going forward but the question remains about how to >>> ameliorate the problem now >> Yes, that's what I wanted to hear: that regression or renaming CKM >> archetypes is potentially problematic for vendors already implementing >> openEHR in their systems. This topic is not only about archetypes (on CKM or >> not) but also about (existing) data using them. >> >>> There are, I think, three approaches: >>> >>> 1. Implementors accept that the use of draft archetypes was that 'own risk' >>> and that they will have to manage the transition from draft to published, >>> which will entail making changes to program code or query statements which >>> refer to draft archetypes. i.e. rename lab_test.v1 to lab_test.v1-unstable >>> or lab_test.v0. This is clearly a major pain (as Sebastian has said) but >>> vendors we have spoken to so far have indicate that they are prepared to do >>> this. Note that it will not have to be done as a batch, only when the >>> system need to use each published v1 archetype, rather than the draft >>> version. >> Indeed using 'draft' archetype is a risk we take and we'll find solutions >> when their are published. My objection was only against having v0 after we >> already had v1 - it is not logical. >> >>> >>> 2. Implementers rely on the new metadata that will be introduced when we >>> publish archetypes from now on. This will include the original namespace >>> and an optional Unique ID which can be used internally in the place of the >>> current archetypeId. >>> >>> So the draft archetypeId reference in the data would be left unchanged as: >>> openEHR-EHR-OBSERVATION.lab_test.v1 >>> >>> and any data captured using the published archetype would be >>> labelled in the data (and any associated queries) as >>> >>> org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.0 >> sounds good >>> >>> or >>> >>> 123453446rhtytyyu.1.0.0 if you prefer >>> >>> >>> When this published v1 archetype needs to go back into review it >>> gets labelled as >>> >>> org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.1-unstable+build. >>> e34dgtj67856 >>> >>> or using the uid - >>> 123rhturytu55634567.v.1.0.1-unstable+build.e34dgtj67856 >>> >>> It is up to vendors to decide just how much of that mouthful to record in >>> data and queries but if you are going to use unstable archetypes in data >>> that is the only unequivocal method of knowing exactly which specific >>> version of the archetype you are dealing with. >>> >>> I doubt that carrying the build is really necessary but knowing that this >>> is v1.0.1-unstable is important, and resolves the problem that we all face >>> right now. >> agree too >>> >>> 3. The final option is that in CKM publication we bend the rules and go >>> straight from V1 drafts to V2. We have discussed this as an editorial team >>> and are not keen on the idea because it is a bit confusing for our clinical >>> reviewer audience. >> For me this options would be the 'normal' one. As I said, I cannot think in >> terms of draft=0 and publish=1, so why is so much resistance against v>1?! I >> can imagine the 'confusion', but I guess is a matter of 'getting accustomed >> to'; and again ... how will they feel when they will have to re-publish an >> archetype and that will become version 2.0.0 according to semver? >> >> >>> If I was implementor I would go for option 2. At some point very soon I am >>> going to have to get to grips with the need to identify namespaced and >>> unstable archetypes in data. I don't have to upgrade to the new published >>> archetypes right away, or as a bulk process but when I do so it makes sense >>> at that point to be able to handle the kind of extended archetype naming >>> that is proposed. >> At first sight it sounds good, but I have to investigate a bit more to get a >> final position about this. >> It is still not very clear for me if you want rm1.0.2 adl1.4 to be able to >> coop with new ecosystem, or all these are intended to be used only by future >> specification releases. >> >>> >>> Sorry that this was a bit of a tome. This ends up being a pretty >>> complicated subject and part of the reason it took so long to figure out! >>> >>> We really need feedback. Everyone feel free to pitch in and argue!! >>> >>> >>> Ian >>> >>> Dr Ian McNicol >>> mobile +44 (0)775 209 7859 >>> office +44 (0)1536 414994 >>> skype: ianmcnicoll >>> email: ian at freshehr.com >>> twitter: @ianmcnicoll >>> >>> Director, freshEHR Clinical Informatics Director, openEHR Foundation >>> Hon. Senior Research Associate, CHIME, UCL >>> >>>> On 3 Oct 2014, at 10:03, David Moner <damoca at gmail.com> wrote: >>>> >>>> I like your reasoning Bert. >>>> >>>> 2014-10-03 10:15 GMT+02:00 Bert Verhees <bert.verhees at rosa.nl>: >>>> On 03-10-14 01:36, Bert Verhees wrote: >>>> org.openehr:openehr-ehr-composition.something:1.0.0 >>>> >>>> It seems wise to me to not regard the version-indication as a part of the >>>> archetypeId, the same for the namespace. >>>> >>>> The archetypeId is to indicate what the conceptual contents of the >>>> archetype is about. >>>> The version does not changes this, so it should not be part of the >>>> archetypeId, the same for the namespace. >>>> >>>> This idea justifies the use of the colon between namespace and archetypeId >>>> and between version and archetypeId. >>>> It also makes the use of the "v" before the version unnecessary. >>>> >>>> "V" is a language-specific indication, "v" stands for "version", and >>>> "version" is an English/Latin term. >>>> In Danish they say "udgave", in Russian it is "??????", in Hebrew: "????", >>>> in Arabic: "????", in Maori: "putanga" and in Chinese: "??" >>>> >>>> Wonderful tool, Google translate ;-) >>>> >>>> Bert >>>> >>>> >>>> >>>> _______________________________________________ >>>> openEHR-clinical mailing list >>>> openEHR-clinical at lists.openehr.org >>>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.op >>>> enehr.org >>>> >>>> >>>> >>>> -- >>>> David Moner Cano >>>> Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA >>>> http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner >>>> >>>> Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, >>>> Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) >>>> _______________________________________________ >>>> openEHR-clinical mailing list >>>> openEHR-clinical at lists.openehr.org >>>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.op >>>> enehr.org >>> >>> >>> >>> _______________________________________________ >>> openEHR-clinical mailing list >>> >>> openEHR-clinical at lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.ope >>> nehr.org >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.ope >> nehr.org > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open > ehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
