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.openehr.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.openehr.org >>> >>> >>> >>> _______________________________________________ >>> openEHR-clinical mailing list >>> >>> openEHR-clinical at lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.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
