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

To: For openEHR technical discussions <openehr-technical@lists.openehr.org> Cc: openehr-clini...@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 Heather

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

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

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

surely the obvious approach is that the stored field contains the UCUM case-sensitive code, and that applications / services use UCUM tables to render whatever display form is asked for in a client call? (I realise openEHR archetypes are not doing this; they should be...) there's another

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,

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

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

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

RE: Archetype publication question - implications for implementers

...@lists.openehr.org; Openehr-Technical <openehr-technical@lists.openehr.org> 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 the same tim

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

RE: Archetype publication question - implications for implementers

Hi A breaking change should always be new major version. Then the problem is that changing version number introduces a huge cost. The cost is of course to the implementers - and by this I mean vendors, health care providers, national registries, integrations and so on. The whole ecosystem is

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

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 {

RE: Archetype publication question - implications for implementers

penEHR technical discussions <openehr-technical@lists.openehr.org>; For openEHR implementation discussions <openehr-implement...@lists.openehr.org>; For openEHR clinical discussions <openehr-clini...@lists.openehr.org> Subject: Re: Archetype publication question - implications for

RE: Archetype publication question - implications for implementers

inical discussions <openehr-clini...@lists.openehr.org> Cc: For openEHR implementation discussions <openehr-implement...@lists.openehr.org> Subject: RE: Archetype publication question - implications for implementers Hi Ian, I should probably clarify that the versioning mechanism in SNOME

RE: Archetype publication question - implications for implementers

r.org] *On Behalf Of *Mikael Nyström > *Sent:* Thursday, 8 October 2015 4:27 AM > *To:* For openEHR technical discussions < > openehr-technical@lists.openehr.org>; For openEHR clinical discussions < > openehr-clini...@lists.openehr.org> > *Cc:* For openEHR implementation disc

RE: Archetype publication question - implications for implementers

To: For openEHR clinical discussions <openehr-clini...@lists.openehr.org>; For openEHR technical discussions <openehr-technical@lists.openehr.org> Cc: For openEHR implementation discussions <openehr-implement...@lists.openehr.org> Subject: RE: Archetype publication question - implications fo

Re: Archetype publication question - implications for implementers

* 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 > discussions > *Emne:* Re: Arc

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

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

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

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