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 <mailto: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 >> <mailto: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 >> <mailto: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 >> <mailto: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.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 >> <mailto: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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141005/81e02f8f/attachment-0001.html>
