Thanks for all the input and feedback. We will quickly put forward a proposed way ahead and see if we can get reasonable consensus.
Ian Heather Sebastian Thomas On 13 October 2014 06:38, Bj?rn N?ss <bna at dips.no> wrote: > 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-bounces at 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 > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141013/9b16a40e/attachment-0001.html>
