RE: Archetype publication question - implications for implementers

[Heather Leslie]

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 when the next change comes along? Specialise the 
specialisation? Rinse, wash, repeat?

I don't think this solves the broader issue that we need to accept and 
acknowledge - that archetypes WILL change as medicine changes, as our 
understanding changes and when we get things wrong! As a community of 
clinicians and implementers, we do need to develop strategies to minimise the 
flow on effects to implementers but ensure that we are heading towards high 
quality, correct archetypes. It is a tension that we need to balance.

There is no doubt that publication of a v2 would have had maximal impact on all 
implementers. We have successfully avoided that.

This v1 revision does have an impact, but I believe that we have corrected the 
issue while creating minimal change in the archetype. Note that most (maybe 
nearly all) implementers don't use Tilt; so most won't need to do anything to 
their local systems. Paths won't change for querying etc. The query for 
specific units may need to be managed, but it is manageable and negotiable.

It will impact those who want to share Tilt data from different revisions of 
the archetype. But that was always going to be the case when anyone uses 
slightly different revisions of an archetype. The revision needs to be part of 
the info transfer and then the differences will need to be negotiated somehow.

Remember that the archetype revision number and build UID are now in the latest 
archetype metadata downloadable from CKM to facilitate implementers having a 
finer level of control over the versioning.

This may be the first time we discuss how to manage this kind of change in the 
list, but it won't be the last and there will almost certainly be more with a 
lot more impact.

I know it will irritate some when I say that archetyping the actual clinical 
content that clinicians need and use in practice is often more art than 
science, but let me reassure you that we are 'science-ing the hell' out of the 
clinical knowledge governance process as much as we can. It is really complex, 
and the more we understand it, the more we realise how complex this area is.

This is our job. Implementers need strategies to align the mismatches that will 
occur. Publication per se is a very coarse way to manage interoperability and 
will not solve our problems. The alignment needs to be done at a finer level of 
control. This is not a new problem. It is one we are just realising as we 
implement and start to share - we were always going to have to have this 
conversation and solve this problem. It was just a matter of when.

Regards

Heather

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Monday, 19 October 2015 8:46 PM
To: For openEHR technical discussions 
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 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 problem; existing vendor 
implementations can remain unchanged or they can choose to update the units if 
they please. The MD5 changes, but all paths etc are identical. A minimal 
disruption approach, if you like - thanks Heath.

And what happens if a new implementation sends data to an old implementation? 
Since the archetype identifier has not changed the receiver will use its own 
archetype to validate the received data, and if it includes the 'deg' unit it 
will just fail the validation. Breaking revisions are not only about changing 
the archetype structure, but also about generating a different set of possible 
instances.

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype publication question - implications for implementers

[David Moner]

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 choose to
> update the units if they please. The MD5 changes, but all paths etc are
> identical. A minimal disruption approach, if you like – thanks Heath.
>

And what happens if a new implementation sends data to an old
implementation? Since the archetype identifier has not changed the receiver
will use its own archetype to validate the received data, and if it
includes the 'deg' unit it will just fail the validation. Breaking
revisions are not only about changing the archetype structure, but also
about generating a different set of possible instances.


-- 
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-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype publication question - implications for implementers

[Thomas Beale]

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 problem;
existing vendor implementations can remain unchanged or they can
choose to update the units if they please. The MD5 changes, but
all paths etc are identical. A minimal disruption approach, if you
like – thanks Heath.


And what happens if a new implementation sends data to an old 
implementation? Since the archetype identifier has not changed the 
receiver will use its own archetype to validate the received data, and 
if it includes the 'deg' unit it will just fail the validation. 
Breaking revisions are not only about changing the archetype 
structure, but also about generating a different set of possible 
instances.



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

[Thomas Beale]

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 problem: in both v2 and CDA, HL7 specified a single 
units field on the assumption that implementers could somehow square 
the circle and have a single units that satisfies human and computer 
readability. This is not possible. Hence the mess we are in.






___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype publication question - implications for implementers

[Ian McNicoll]

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 mild/ moderate/severe/ =>
mild/moderate/severe/fatal

This is considered a non-breaking change since existing data is not
invalidated but could cause exactly the same kind of potential mismatch
between systems using different minor revisions of the same archetype.

Revision changes can only guarantee that existing data is unaffected but
cannot ensure that mis-matches occur between disparate systems using
different profiles on the same archetype. This can happen even with
existing archetypes e.g the temperature archetype which allows variations
of unit. In practice we need to use some form of templating or profiling to
resolve these kind of potential variances in real systems and data
exchanges.

The good thing in your scenario is that the recipient system would through
a validation error, alerting the recipient that an unexpected unit was
being sent.

I don't think there is a problem here. We expect similar variance issues to
arise in other circumstances.

Ian


Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 19 October 2015 at 11:45, Thomas Beale  wrote:

>
> Hence my earlier proposal...
>
> On 19/10/2015 09:18, David Moner wrote:
>
>
>
> 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 choose to
>> update the units if they please. The MD5 changes, but all paths etc are
>> identical. A minimal disruption approach, if you like – thanks Heath.
>>
>
> And what happens if a new implementation sends data to an old
> implementation? Since the archetype identifier has not changed the receiver
> will use its own archetype to validate the received data, and if it
> includes the 'deg' unit it will just fail the validation. Breaking
> revisions are not only about changing the archetype structure, but also
> about generating a different set of possible instances.
>
>
>
> ___
> openEHR-clinical mailing list
> openehr-clini...@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org