Re: Archetype publication question - implications for implementers

As a reminder, the current draft spec on versioning and lifecycle is here, and as usual, comments are welcome

RE: Archetype publication question - implications for implementers

> > > > *From:* openEHR-clinical [mailto: > openehr-clinical-boun...@lists.openehr.org] *On Behalf Of *Gunnar Klein > *Sent:* Tuesday, 20 October 2015 10:26 AM > *To:* For openEHR clinical discussions > > *Subject:* Re: Archetype publication question - implications for >

RE: Archetype publication question - implications for implementers

...@lists.openehr.org] On Behalf Of Gunnar Klein Sent: Tuesday, 20 October 2015 10:26 AM To: For openEHR clinical discussions Subject: Re: Archetype publication question - implications for implementers Dear ckm lovers, My preference is for your option 3. We have to make updates. Nobody is forced to

Re: Archetype publication question - implications for implementers

On 19/10/2015 13:10, Heather Leslie wrote: The versioning rules have been following. This is a use case that is testing them, testing our strategy. Excellent. What does specialisation add to this? We still have a changed MD5, new archetype ID, etc… Aargh. If we specialise, what happens w

Re: Archetype publication question - implications for implementers

Dear ckm lovers, My preference is for your option 3. We have to make updates. Nobody is forced to change anything. Best regards Gunnar Den 2 okt 2015 06:11 skrev "Heather Leslie" < heather.les...@oceaninformatics.com>: > Hi everyone, > > > > I’m seeking community input around a conundrum that h

RE: Archetype publication question - implications for implementers

Monday, 19 October 2015 8:46 PM To: For openEHR technical discussions Cc: openehr-clinical@lists.openehr.org Subject: Re: Archetype publication question - implications for implementers Hence my earlier proposal... On 19/10/2015 09:18, David Moner wrote: 2015-10-16 3:22 GMT+02:00

Re: Archetype publication question - implications for implementers

Hi David, That is clearly a revision change1.0->1.1 but is not a breaking change for data already carried within the system i.e queries for tilt using the degree symbol will still work. This is is not inherently any different from the situation where we can add codes to an internal codelist, e.g

Re: Archetype publication question - implications for implementers

Hence my earlier proposal... On 19/10/2015 09:18, David Moner wrote: 2015-10-16 3:22 GMT+02:00 Heather Leslie >: ·It means that new implementers can use the corrected v1 revision and we don’t have to create a v2 for a relatively trivial p

Re: Archetype publication question - implications for implementers

2015-10-16 3:22 GMT+02:00 Heather Leslie < heather.les...@oceaninformatics.com>: > · It means that new implementers can use the corrected v1 > revision and we don’t have to create a v2 for a relatively trivial problem; > existing vendor implementations can remain unchanged or they can choo

RE: Archetype publication question - implications for implementers

2015 11:05 PM To: openehr-clinical@lists.openehr.org; Openehr-Technical Subject: Re: Archetype publication question - implications for implementers I've skimmed the replies on this thread, and I'm inclined to think everyone could be right. Problem is, they can't all be right at t

Re: Archetype publication question - implications for implementers [ long ]

hi Eric Some comments: * UCUM introduces ambiguity, despite the above claim. > please demonstrate examples. > * UCUM does not provide a single code for each unit - it provides 2 > normative codes, as well as a non-normative display/print rendition and an > ad-hoc name. For each unit, UCUM defi

Re: Archetype publication question - implications for implementers [ long ]

Eric, nice summary of issues. If I can take the liberty of pulling out what I think are your key issues to worry about + recommendations. I bolded my own subset of those ... On 10/10/2015 10:07, Eric Browne wrote: *Notes on UCUM* * UCUM does not supply normative names of units. * Some of

Re: Archetype publication question - implications for implementers

I've skimmed the replies on this thread, and I'm inclined to think everyone could be right. Problem is, they can't all be right at the same time. So considering the issue from a global deployment perspective I had the folllowing idea: * in the archetype library, we should stick to pro

Re: Archetype publication question - implications for implementers [ long ]

Hi Heather et al, Whilst I have followed this thread and agree with many of the observations and conclusions reached so far, I would like to make the following observations, which are restricted to the aspect of the “non-UCUM" unit described in Heather’s original posting. They have more seriou

RE: Archetype publication question - implications for implementers

enEHR implementation discussions ; For openEHR clinical discussions Subject: Re: Archetype publication question - implications for implementers Thanks Ian for explaining the actual proposal. I can't see why you can't add the dv_text to the location of measurement (opening the constraint

RE: Archetype publication question - implications for implementers

Subject: Re: Archetype publication question - implications for implementers Hi Heath, I think the suggested change was from CLUSTER[at1033] occurrences matches {0..1} matches { -- Location items cardinality matches {1

RE: Archetype publication question - implications for implementers

: Archetype publication question - implications for implementers 2015-10-08 1:23 GMT+02:00 Heather Leslie mailto:heather.les...@oceaninformatics.com>>: It was Sebastian’s suggestion about governing at an intra-archetype level that has caught my attention - marking an existing data elem

Re: Archetype publication question - implications for implementers

But then what do we do with current implemented adl 1.4 archetypes? El 8/10/2015 11:56, "Ian McNicoll" escribió: > Hi Heath, > > I think the suggested change was from > > CLUSTER[at1033] occurrences matches {0..1} matches { -- Location > items cardinality matches {1..*; unordered} matches { > ELE

Re: Archetype publication question - implications for implementers

Thanks Ian for explaining the actual proposal. I can't see why you can't add the dv_text to the location of measurement (opening the constraint). Then it just becomes an implementation choice to exclude the specific location inline with the new preferred model. Regards Heath On 8 Oct 2015, at

Re: Archetype publication question - implications for implementers

Hi Heath, I think the suggested change was from CLUSTER[at1033] occurrences matches {0..1} matches { -- Location items cardinality matches {1..*; unordered} matches { ELEMENT[at0014] occurrences matches {0..1} matches { -- Location of measurement value matches { DV_CODED_TEXT matches { defining_c

Re: Archetype publication question - implications for implementers

The existing versioning rules allow adding new concepts and opening constraints such as allowing additional units. These change the md5 hash but does require a version /id change. This is why Sebastian's suggestion technically works, the existing obsolete concept still exists and the new concep

Re: Archetype publication question - implications for implementers

2015-10-08 1:23 GMT+02:00 Heather Leslie < heather.les...@oceaninformatics.com>: > It was Sebastian’s suggestion about governing at an intra-archetype level > that has caught my attention - marking an existing data element as > outdated, and adding a new one as a revision solves the issue of havin

Re: Archetype publication question - implications for implementers

Hi All Taking this part of the change, I do not see any reason not to add a unit (really symbol change only) and mark the old one as deprecated. The data is unchanged and there is no risk to processing whatsoever. The location change is a little more complicated and seems to be due to moving

RE: Archetype publication question - implications for implementers

Sent:* Thursday, 8 October 2015 4:27 AM > *To:* For openEHR technical discussions < > openehr-techni...@lists.openehr.org>; For openEHR clinical discussions < > openehr-clinical@lists.openehr.org> > *Cc:* For openEHR implementation discussions < > openehr-implement...@lists.

RE: Archetype publication question - implications for implementers

openEHR clinical discussions ; For openEHR technical discussions Cc: For openEHR implementation discussions Subject: RE: Archetype publication question - implications for implementers Hi All, It has been an interesting conversation. Many thanks for everyone’s input. However, I think we do have a

RE: Archetype publication question - implications for implementers

discussions Subject: RE: Archetype publication question - implications for implementers Hi Ian, I should probably clarify that the versioning mechanism in SNOMED CT is more than a technical thing. The versioning mechanism also includes guidelines about how to handle the changes in the

RE: Archetype publication question - implications for implementers

:22 To: For openEHR clinical discussions Cc: For openEHR technical discussions; For openEHR implementation discussions Subject: Re: Archetype publication question - implications for implementers Hi Vebjørn, I hope I did not give the impression that I was in any way suggesting that the Norwegian

Re: Archetype publication question - implications for implementers

ivalently. > > > > *Fra:* openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] > *På vegne av* Jussara macedo > *Sendt:* 7. oktober 2015 14:43 > *Til:* For openEHR clinical discussions > *Kopi:* For openEHR technical discussions; For openEHR implementation > disc

Re: Archetype publication question - implications for implementers

Dear all, I agree with Ian that any change at international level should be market driven. From an experience of someone who works with standardization for years and who already led the adoption of standards in Brazil's extensive market, it is worth remembering that standards must reflect a con

Re: Archetype publication question - implications for implementers

Hi all, This is IMO, a very important issue for the openEHR community and many thanks to Heather for providing such a clear exposition of the issues and choices, faced by any community building products and tools based on open-source distribution and governance principles. As such, I do not think

Re: Archetype publication question - implications for implementers

From a governance point of view, I believe it is clear that the v2 route is the cleanest option here. And in a general way I also agree with your concerns, Diego! I think that my suggestion of deprecating old and adding the new elements, can only make sense if we can model the new elements in

Re: Archetype publication question - implications for implementers

Hello, If the archetype introduces incompatible changes with the existing version, then no discussion it is possible: a new v2 has to be published after the proper review rounds. Then the question is what happens to v1. Being purist, v1 should be marked as obsolete (still usable at your own risk)

Re: Archetype publication question - implications for implementers

Would they be alternatives of the data type or just new elements at the same level? I see problems with both: if you create an alternative on data types probably you won't be able to add bindings to it, and if made a another element then you don't have an easy way of telling what corrects (you co

Re: Archetype publication question - implications for implementers

Hi Heather, Instead of removing the incorrect UCUM unit and the old modelling patterns completely, would it be possible to mark these bits as 'deprecated' in some [informal] way in the ontology? This way you could make the desired changes and republish as a minor revision of version 1. For a