Re: DV_PROPORTION vs DV_QUANTITY for %

[Ian McNicoll]

Simple answer - loads of real data - pulse_oximetry and Oxygen levels will
have been recorded hundreds of thousands if not millions of times in
patient data - and Proportion *is* the correct datatype for O2 levels.

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 Mon, 7 Jan 2019 at 17:56, Thomas Beale  wrote:

> one thing to note: DV_PROPORTION is a more complex data structure. I
> would be tempted to try to determine what use has been made of this
> archetype so far - i.e. in creating real data. If no real data has been
> created, then it could in theory be changed.
>
> - thomas
>
> On 07/01/2019 12:11, Ian McNicoll wrote:
> > Hi Silje,
> >
> > As you say, I think this a case of emerging clarity (or less fog of
> > confusion!!) as the various use-cases emerge. As the primary author of
> > both these archetypes, in retrospect I would probably keep
> > inspired_oxygen as DV_PROPORTION and change pulse_oximetry to
> > DV_QUANTITY but!!! I do not see any good argument for changing these
> > now. We have to expect some degree of inconsistency, and live with it,
> > to avoid unnecessary breaking changes.
> >
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: DV_PROPORTION vs DV_QUANTITY for %

[Thomas Beale]

one thing to note: DV_PROPORTION is a more complex data structure. I 
would be tempted to try to determine what use has been made of this 
archetype so far - i.e. in creating real data. If no real data has been 
created, then it could in theory be changed.


- thomas

On 07/01/2019 12:11, Ian McNicoll wrote:

Hi Silje,

As you say, I think this a case of emerging clarity (or less fog of 
confusion!!) as the various use-cases emerge. As the primary author of 
both these archetypes, in retrospect I would probably keep 
inspired_oxygen as DV_PROPORTION and change pulse_oximetry to 
DV_QUANTITY but!!! I do not see any good argument for changing these 
now. We have to expect some degree of inconsistency, and live with it, 
to avoid unnecessary breaking changes.





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

RE: Syntax for including archetypes in SLOTs, regardless of version

[Bakke, Silje Ljosland]

Amen.

So, do we have a conclusion that toolmakers can reference? Can we document this 
somewhere in the specs or elsewhere?

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Heather Leslie
Sent: Wednesday, December 19, 2018 7:22 AM
To: For openEHR technical discussions 
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Hi everyone,

In our modelling, it is safe to assume that the latest version of an archetype 
is the best candidate on offer for anyone using an archetype and filling a SLOT 
for the first time. Options for use of previous versions may be useful for 
implementers who have older versions in their current systems and don’t want 
two different versions or to update all their systems to the latest version.

I totally agree that from a governance point of view SLOT inclusions won’t need 
to specify a version in 99% of cases. However in some situations it 
theoretically may be appropriate to fix a version in place in a specific SLOT. 
In fact I can’t think of a use case YET where we need to specify a certain 
version, but no doubt this will occur at some time in the near future.

In all our modelling it seems that as soon as we limit our options one way or 
another we discover a use case that breaks our most recently made rule! 
Murphy’s law?

So we want to have our cake and eat it too – default to any or all versions of 
an archetype, with the option to specify one (or maybe even multiple) if needs 
be. Same theory applies to exclusions in a SLOT as well.

The governance overheads of currently specifying v0 and/or v1 and/or v2  will 
only increase as time goes on and at present as CKAs we have people upset that 
v0 is specifically included but that archetype has subsequently been published 
as v1. They want to see v1 specifically included. They don’t understand the 
theory behind it, not unreasonably, that as long as no archetypes (and 
versions) are excluded in a specific way, even if the SLOT suggests a v0 as an 
inclusion, it technically doesn’t stop a v1 being inserted in there. So the 
inclusion of all versions also has an important design guidance function as 
well. Newbies may not understand that if an archetype of the appropriate class 
is no actively excluded, then any or all of the archetypes of that class are 
technically valid for adding into a template.

Regards

Heather

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Bakke, Silje Ljosland
Sent: Wednesday, 19 December 2018 1:15 AM
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Thanks Thomas,

The idea here is that we (likely in 99% of the cases) do want to include any 
version of the archetype, so the .v[0-2] variant isn’t relevant. The reason for 
this is that even though an archetype will have breaking changes from one major 
version to the next, the clinical concept will stay the same (or it should have 
a completely new ID). We don’t generally include archetypes based on their 
specific content at the time of inclusion, but on the clinical concept they 
represent.

If leaving the version part out completely is the correct way to leave 
versioning open when including archetypes, the CKM will need to change 
behaviours regarding this, since it currently rejects any archetype that does 
this:
[cid:image001.jpg@01D4A69F.B91D67F0]

Regards,
Silje

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Thomas Beale
Sent: Tuesday, December 18, 2018 1:30 PM
To: 
openehr-technical@lists.openehr.org
Subject: Re: Syntax for including archetypes in SLOTs, regardless of version


Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.

is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically different 
archetypes - i.e. they contain some breaking change. So whether allowing any 
major version of an archetype in a slot is a good default probably needs to be 
thought about carefully.

- thomas
On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:
Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body 

Re: DV_PROPORTION vs DV_QUANTITY for %

[Ian McNicoll]

Hi Silje,

As you say, I think this a case of emerging clarity (or less fog of
confusion!!) as the various use-cases emerge. As the primary author of
both these archetypes, in retrospect I would probably keep inspired_oxygen
as DV_PROPORTION and change pulse_oximetry to DV_QUANTITY but!!! I do not
see any good argument for changing these now. We have to expect some degree
of inconsistency, and live with it, to avoid unnecessary breaking changes.

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 Mon, 7 Jan 2019 at 12:02, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> I think maybe actual modelling practice should be taken into account here.
> Since these guidelines haven't been available, several important
> percentages in published archetypes have been modelled as DV_PROPORTION:
> openEHR-EHR-CLUSTER.inspired_oxygen.v1
> https://ckm.openehr.org/ckm/#showArchetype_1013.1.393
> openEHR-EHR-OBSERVATION.pulse_oximetry.v1
> https://ckm.openehr.org/ckm/#showArchetype_1013.1.3084
>
> The way I understand the arguments here, there isn't a good one for
> changing these data types and going to v2 for these archetypes?
>
> Regards,
> Silje
>
> -Original Message-
> From: openEHR-technical  On
> Behalf Of Thomas Beale
> Sent: Saturday, January 5, 2019 3:36 PM
> To: openehr-technical@lists.openehr.org
> Subject: Re: DV_PROPORTION vs DV_QUANTITY for %
>
>
> On 05/01/2019 12:56, Ian McNicoll wrote:
> > There is a very clear use-case for having it there - O2 levels
> > variably and equivalently described a FiO2 which is a unitary
> > proportion or percent.
> >
> > I think we need to keep it for that reason if no other.
>
> So in that case we need to upgrade the documentation for when to choose a
> DV_QUANTITY percent, and when a DV_PROPORTION %.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: DV_PROPORTION vs DV_QUANTITY for %

[Bakke, Silje Ljosland]

I think maybe actual modelling practice should be taken into account here. 
Since these guidelines haven't been available, several important percentages in 
published archetypes have been modelled as DV_PROPORTION:
openEHR-EHR-CLUSTER.inspired_oxygen.v1 
https://ckm.openehr.org/ckm/#showArchetype_1013.1.393 
openEHR-EHR-OBSERVATION.pulse_oximetry.v1 
https://ckm.openehr.org/ckm/#showArchetype_1013.1.3084 

The way I understand the arguments here, there isn't a good one for changing 
these data types and going to v2 for these archetypes?

Regards,
Silje

-Original Message-
From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Saturday, January 5, 2019 3:36 PM
To: openehr-technical@lists.openehr.org
Subject: Re: DV_PROPORTION vs DV_QUANTITY for %


On 05/01/2019 12:56, Ian McNicoll wrote:
> There is a very clear use-case for having it there - O2 levels 
> variably and equivalently described a FiO2 which is a unitary 
> proportion or percent.
>
> I think we need to keep it for that reason if no other.

So in that case we need to upgrade the documentation for when to choose a 
DV_QUANTITY percent, and when a DV_PROPORTION %.

- thomas



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