Re: ELEMENT.null_reason proposal

[Boštjan Lah]

Yes, this is also my understanding and I agree this is the way to go.

Best regards,
Bostjan

On 25 Jan 2017, at 16:05, Bjørn Næss <b...@dips.no<mailto:b...@dips.no>> wrote:

That seems to be my understanding of Thomas’ suggestion – and I think that is 
the way to go. Then we will have a small set of “classes of null flavours” , 
and the detailed and local description can be added to the second field . The 
second field may then be of type DV_TEXT to allow both unstructured and coded 
values.

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010>

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av David Moner
Sendt: onsdag 25. januar 2017 14.24
Til: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Emne: Re: ELEMENT.null_reason proposal

So, if I understand well, the idea is to add an attribute for representing 
clinical reasons for a null flavor, maintaining the current null_flavor for 
technical reasons only. Is that right?

2017-01-25 13:34 GMT+01:00 Ian McNicoll 
<i...@freshehr.com<mailto:i...@freshehr.com>>:
Hi Diego,

That's a pretty good suggestion, although in that case we are really abandoning 
the idea of the current fixed base set of 'technical' null-flavours and 
allowing them to be replaced by local terms, while I was suggesting something 
more like the ISM_TRANSITION setup where archetype-specific 'clinical overlays' 
can be provided via the archetyped careflow_steps but are always associated 
with the underlying state_machine and current_status attribute.

Ian


Dr Ian McNicoll
mobile +44 (0)775 209 7859<tel:+44%207752%20097859>
office +44 (0)1536 414994<tel:+44%201536%20414994>
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

[https://docs.google.com/uc?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 25 January 2017 at 11:54, Diego Boscá 
<yamp...@gmail.com<mailto:yamp...@gmail.com>> wrote:
If null_flavour is a DV_CODED_TEXT, what stops anyone to create an
specialized archetype (directly from an rm class) that has the texts
(+ codes) needed in a given country/use case?
This probably should work even if set of null_flavour codes is fixed.
I don't know if this would be enough, but in theory it provides a
workaround for all issues (except the cluster one)

2017-01-25 12:33 GMT+01:00 Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>>:
>
> Silje has just pinged me again on the question of whether we should have an
> ELEMENT.null-reason or similar attribute to accommodate specific reasons for
> null_flavour being set. There are 3 PRs on this as follows:
>
> SPECPR-41 - Enable content specific flavours of null to be specified per
> archetype
> SPECPR-62 - Add a 'reason for null' text attribute in the Reference model
> SPECPR-119 - CLUSTER also needs a Null_flavour
> SPECPR-151 - Add an attribute to ELEMENT to record 'null reason'
>
> These are all reporting the same problem. (The last one can probably be
> closed as a direct duplicate of SPECPR-62). Having re-read the comments on
> all, my inclination is to propose the simple addition of an attribute
> null_reason: DV_TEXT[0..1] to the ELEMENT class. This would be optional and
> will not invalidate any existing data, but on the downside it will be a data
> field that will often be emtpy (i.e. Void, or 'null' in the Java/C sense).
>
> What would the general reaction to proposing this change be?
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org<mailto: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<mailto: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<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_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

Re: ELEMENT.null_reason proposal

[David Moner]

So, if I understand well, the idea is to add an attribute for representing
clinical reasons for a null flavor, maintaining the current null_flavor for
technical reasons only. Is that right?

2017-01-25 13:34 GMT+01:00 Ian McNicoll :

> Hi Diego,
>
> That's a pretty good suggestion, although in that case we are really
> abandoning the idea of the current fixed base set of 'technical'
> null-flavours and allowing them to be replaced by local terms, while I was
> suggesting something more like the ISM_TRANSITION setup where
> archetype-specific 'clinical overlays' can be provided via the archetyped
> careflow_steps but are always associated with the underlying state_machine
> and current_status attribute.
>
> Ian
>
>
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859 <+44%207752%20097859>
> office +44 (0)1536 414994 <+44%201536%20414994>
> 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 25 January 2017 at 11:54, Diego Boscá  wrote:
>
>> If null_flavour is a DV_CODED_TEXT, what stops anyone to create an
>> specialized archetype (directly from an rm class) that has the texts
>> (+ codes) needed in a given country/use case?
>> This probably should work even if set of null_flavour codes is fixed.
>> I don't know if this would be enough, but in theory it provides a
>> workaround for all issues (except the cluster one)
>>
>> 2017-01-25 12:33 GMT+01:00 Thomas Beale :
>> >
>> > Silje has just pinged me again on the question of whether we should
>> have an
>> > ELEMENT.null-reason or similar attribute to accommodate specific
>> reasons for
>> > null_flavour being set. There are 3 PRs on this as follows:
>> >
>> > SPECPR-41 - Enable content specific flavours of null to be specified per
>> > archetype
>> > SPECPR-62 - Add a 'reason for null' text attribute in the Reference
>> model
>> > SPECPR-119 - CLUSTER also needs a Null_flavour
>> > SPECPR-151 - Add an attribute to ELEMENT to record 'null reason'
>> >
>> > These are all reporting the same problem. (The last one can probably be
>> > closed as a direct duplicate of SPECPR-62). Having re-read the comments
>> on
>> > all, my inclination is to propose the simple addition of an attribute
>> > null_reason: DV_TEXT[0..1] to the ELEMENT class. This would be optional
>> and
>> > will not invalidate any existing data, but on the downside it will be a
>> data
>> > field that will often be emtpy (i.e. Void, or 'null' in the Java/C
>> sense).
>> >
>> > What would the general reaction to proposing this change be?
>> >
>> > - 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
>



-- 
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: ELEMENT.null_reason proposal

[Thomas Beale]

Diego,

I think this is the same as

 * extending the current openEHR null_flavour code set, and making it
   hierarchical OR
 * allowing other local code-sets to be used in that slot.
 o if these codes were understood as proper local extensions of the
   openEHR code-set, i.e. any new code asserted an IS-A
   relationship to one of the 4 existing openEHR null codes, then
   it would work properly. But we have no way to do that.

The first I think gets into the place HL7 is with this field - you can 
never design a terminology for 'null flavour reason' that works for 
everyone.


The second has the problem that the field becomes non-interoperable - 
today, applications can assume one of 4 known values; if any code set 
can be used, this assumption will break. Unless the 'extension' idea 
could be achieved somehow, which would be kind of nice.


Whenever I think through this problem I come back to the idea of a 
second field, which is more or less the design concept, as Ian says, or 
the state machine state + careflow step in ACTIONs.


- thomas

On 25/01/2017 11:54, Diego Boscá wrote:

If null_flavour is a DV_CODED_TEXT, what stops anyone to create an
specialized archetype (directly from an rm class) that has the texts
(+ codes) needed in a given country/use case?
This probably should work even if set of null_flavour codes is fixed.
I don't know if this would be enough, but in theory it provides a
workaround for all issues (except the cluster one)



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

Re: ELEMENT.null_reason proposal

[Ian McNicoll]

Hi Diego,

That's a pretty good suggestion, although in that case we are really
abandoning the idea of the current fixed base set of 'technical'
null-flavours and allowing them to be replaced by local terms, while I was
suggesting something more like the ISM_TRANSITION setup where
archetype-specific 'clinical overlays' can be provided via the archetyped
careflow_steps but are always associated with the underlying state_machine
and current_status attribute.

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 25 January 2017 at 11:54, Diego Boscá  wrote:

> If null_flavour is a DV_CODED_TEXT, what stops anyone to create an
> specialized archetype (directly from an rm class) that has the texts
> (+ codes) needed in a given country/use case?
> This probably should work even if set of null_flavour codes is fixed.
> I don't know if this would be enough, but in theory it provides a
> workaround for all issues (except the cluster one)
>
> 2017-01-25 12:33 GMT+01:00 Thomas Beale :
> >
> > Silje has just pinged me again on the question of whether we should have
> an
> > ELEMENT.null-reason or similar attribute to accommodate specific reasons
> for
> > null_flavour being set. There are 3 PRs on this as follows:
> >
> > SPECPR-41 - Enable content specific flavours of null to be specified per
> > archetype
> > SPECPR-62 - Add a 'reason for null' text attribute in the Reference model
> > SPECPR-119 - CLUSTER also needs a Null_flavour
> > SPECPR-151 - Add an attribute to ELEMENT to record 'null reason'
> >
> > These are all reporting the same problem. (The last one can probably be
> > closed as a direct duplicate of SPECPR-62). Having re-read the comments
> on
> > all, my inclination is to propose the simple addition of an attribute
> > null_reason: DV_TEXT[0..1] to the ELEMENT class. This would be optional
> and
> > will not invalidate any existing data, but on the downside it will be a
> data
> > field that will often be emtpy (i.e. Void, or 'null' in the Java/C
> sense).
> >
> > What would the general reaction to proposing this change be?
> >
> > - 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: ELEMENT.null_reason proposal

[Ian McNicoll]

Hi Thomas,

I agree that we should go ahead with this ASAP. However it might be worth a
slight pause to think about the wider problem in handling 'clinical nulls'.

To summarise, 'null flavours' have limited value in a great deal of
clinical models because the standard set of null flavours, although
expressing the 'reason for null' from a technical perspective 'not
appropriate', 'unavailable' etc is not clinician/context friendly enough
for actual use-cases.

I think there is strong parallel here with the need to overlay the
technical state machine current_state attribute with archetype_specific
careflow_steps as per SPECPR-41
 .

Now we will probably always need extra free text as per SPECPR-62/151 but
if we are thinking about this, I suggest putting a little effort into
progressing ( or ditching) those other PRs.

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 25 January 2017 at 11:33, Thomas Beale  wrote:

>
> Silje has just pinged me again on the question of whether we should have
> an ELEMENT.null-reason or similar attribute to accommodate specific reasons
> for null_flavour being set. There are 3 PRs on this as follows:
>
>- SPECPR-41  - Enable
>content specific flavours of null to be specified per archetype
>- SPECPR-62  - Add a
>'reason for null' text attribute in the Reference model
>- SPECPR-119  -
>CLUSTER also needs a Null_flavour
>- SPECPR-151  - Add
>an attribute to ELEMENT to record 'null reason'
>
> These are all reporting the same problem. (The last one can probably be
> closed as a direct duplicate of SPECPR-62). Having re-read the comments on
> all, my inclination is to propose the simple addition of an attribute 
> null_reason:
> DV_TEXT[0..1] to the ELEMENT class
> .
> This would be optional and will not invalidate any existing data, but on
> the downside it will be a data field that will often be emtpy (i.e. Void,
> or 'null' in the Java/C sense).
>
> What would the general reaction to proposing this change be?
>
> - 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

ELEMENT.null_reason proposal

[Thomas Beale]

Silje has just pinged me again on the question of whether we should have 
an ELEMENT.null-reason or similar attribute to accommodate specific 
reasons for null_flavour being set. There are 3 PRs on this as follows:


 * SPECPR-41  - Enable
   content specific flavours of null to be specified per archetype
 * SPECPR-62  - Add a
   'reason for null' text attribute in the Reference model
 * SPECPR-119  -
   CLUSTER also needs a Null_flavour
 * SPECPR-151  - Add
   an attribute to ELEMENT to record 'null reason'

These are all reporting the same problem. (The last one can probably be 
closed as a direct duplicate of SPECPR-62). Having re-read the comments 
on all, my inclination is to propose the simple addition of an attribute 
null_reason: DV_TEXT[0..1] to the ELEMENT class 
. 
This would be optional and will not invalidate any existing data, but on 
the downside it will be a data field that will often be emtpy (i.e. 
Void, or 'null' in the Java/C sense).


What would the general reaction to proposing this change be?

- thomas


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