Re: Normal range/reference ranges for text data type

[GF]

I agree that they do not fit in a Data Type.
It had better be handled using archetypes.
It is too complex for a DV_Ordinal Data Type

The reason why I wrote what I wrote is that Archetype must do more than the 
bare essentials.
Leaving more to the implicit knowledge of humans or value sets stored in one or 
the other service, or coding system.
I think that one of the functions of archetypes is to define precisely what is 
stored and retreived and transported with the least amount of implicit 
knowledge left for humans.

Gerard


> On 30 Sep 2016, at 10:31, Thomas Beale  wrote:
> 
> 
> 
> On 29/09/2016 13:31, GF wrote:
>> Each entry in the classification needs:
>> - a screen representation (‘+++')
>> - a description (‘moderate')
> 
> in theory these two come from DV_ORDINAL.symbol, which is a DV_CODED_TEXT. 
> That assumes a text value of '+++' and either a description or synonym (or 
> both) of 'moderate'.
> 
>> - an expression defining the inclusion criteria  ('Lower Limit' < ‘Value' < 
>> 'Higher limit'
>> - an expression defining the exclusion criteria ('no diagnosis of xyz')
> 
> these are semantic things and I think have to be outside of the DV_ORDINAL 
> data type definition, which after all just represents a value. Once you add 
> these, it becomes a disease- or test-specific definition. I'm not sure where 
> we would put these things - I think probably in a knowledge base of semantic 
> definitions of different test results. One might argue that SNOMED should 
> provide that, but I'm inclined to think it belongs in a knowledge base of 
> lab-related ranges, labels and other computational elements, like the 
> 'presentation ranking number' and 'value for calculation support' you have 
> below.
> 
>> 
>> And perhaps each entry needs:
>> - Ranking number (‘1')
> 
> DV_ORDINAL.value.
> 
>> - Presentation ranking number (‘4')
>> - Associated value for calculation support (‘100')
>> 
>> To my ideas the Semantic Ordinal, as described, actually is an Archetype 
>> Pattern or a Data Type.
>> 
> 
> did you mean 'of a Data Type'?
> 
> I think the above ideas are all likely to be useful, but they won't all fit 
> inside DV_ORDINAL...
> 
> - thomas

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[Bert Verhees]

On 30-09-16 10:46, GF wrote:

The ERS system needs to be able to represent faithfully that what was shown on 
a screen.
This is what the HcProvider signs off/attests.
See the requirements imposed on ERS systems in ISO 18308.

Therefor I’m of the opinion that the archetype used to store data in, and 
retrieve data from, the database must be able to carry that screen info.
For Clinical Decision Support Systems this screen info is irrelevant.
For legal purposes it is essential.


I do not agree, archetypes are not to be used for screen presentations, 
for that purpose are templates. This was discussed just a few weeks ago 
on this list.


Bert

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[GF]

The ERS system needs to be able to represent faithfully that what was shown on 
a screen.
This is what the HcProvider signs off/attests.
See the requirements imposed on ERS systems in ISO 18308.

Therefor I’m of the opinion that the archetype used to store data in, and 
retrieve data from, the database must be able to carry that screen info.
For Clinical Decision Support Systems this screen info is irrelevant.
For legal purposes it is essential.

HcProviders always will use their own local classifications. They never 
uniformly will use one and the same, all the time.
These local classifications need to be mapped on a standardised internal 
pattern/archetype for classifications. It is this pattern that is stored and 
retrieved annex to the mapping to the local classification.

Gerard


> On 30 Sep 2016, at 10:06, Bert Verhees  wrote:
> 
> On 29-09-16 14:31, GF wrote:
>> Each entry in the classification needs:
>> - a screen representation (‘+++')
>> - a description (‘moderate')
>> - an expression defining the inclusion criteria  ('Lower Limit' < ‘Value' < 
>> 'Higher limit'
>> - an expression defining the exclusion criteria ('no diagnosis of xyz')
>> 
>> And perhaps each entry needs:
>> - Ranking number (‘1')
>> - Presentation ranking number (‘4')
>> - Associated value for calculation support (‘100')
> 
> 
> I don't think screen presentations should be something to consider in 
> archetype-structures. A few weeks ago this was said to me on this list, and I 
> think that is right. Screen presentation-definitions should be something to 
> use in templates for screen presentation. There can also be templates for 
> other purposes, messages, reports, etc.
> 
> Archetypes, except for its original purpose: data-structure-representation, 
> need to be purpose independent. Archetypes are the base to build templates 
> on, and depending of the purpose of the template, the data will be 
> represented in a different way.
> 
> So archetypes need to be as much as possible machine-processable, and if you 
> use all kind of convenient terms to, for example, indicate pain, then you 
> will never be able to datamine (research in the history of a patient, or in a 
> population) in a more generic way, and you will also need that specific 
> archetype.
> 
> Imagine a hospital with 7000 archetypes, it will become nearly impossible to 
> find persons which have pain, what kind of pain and how severe it is.
> 
> Better is to code pain, and I know SCT has good codes for pain (there may be 
> other code-systems too). This makes machine processable searching for pain, 
> kind of pain, severity of pain possible and will improve healthcare for a 
> specific patient or a population.
> 
> Bert
> 
> 
> 
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org


___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[Thomas Beale]

On 29/09/2016 13:31, GF wrote:

Each entry in the classification needs:
- a screen representation (‘+++')
- a description (‘moderate')


in theory these two come from DV_ORDINAL.symbol, which is a 
DV_CODED_TEXT. That assumes a text value of '+++' and either a 
description or synonym (or both) of 'moderate'.


- an expression defining the inclusion criteria  ('Lower Limit' < 
‘Value' < 'Higher limit'

- an expression defining the exclusion criteria ('no diagnosis of xyz')


these are semantic things and I think have to be outside of the 
DV_ORDINAL data type definition, which after all just represents a 
value. Once you add these, it becomes a disease- or test-specific 
definition. I'm not sure where we would put these things - I think 
probably in a knowledge base of semantic definitions of different test 
results. One might argue that SNOMED should provide that, but I'm 
inclined to think it belongs in a knowledge base of lab-related ranges, 
labels and other computational elements, like the 'presentation ranking 
number' and 'value for calculation support' you have below.




And perhaps each entry needs:
- Ranking number (‘1')


DV_ORDINAL.value.


- Presentation ranking number (‘4')
- Associated value for calculation support (‘100')

To my ideas the Semantic Ordinal, as described, actually is an 
Archetype Pattern or a Data Type.




did you mean 'of a Data Type'?

I think the above ideas are all likely to be useful, but they won't all 
fit inside DV_ORDINAL...


- thomas


___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[Bert Verhees]

On 29-09-16 14:31, GF wrote:

Each entry in the classification needs:
- a screen representation (‘+++')
- a description (‘moderate')
- an expression defining the inclusion criteria  ('Lower Limit' < 
‘Value' < 'Higher limit'

- an expression defining the exclusion criteria ('no diagnosis of xyz')

And perhaps each entry needs:
- Ranking number (‘1')
- Presentation ranking number (‘4')
- Associated value for calculation support (‘100')



I don't think screen presentations should be something to consider in 
archetype-structures. A few weeks ago this was said to me on this list, 
and I think that is right. Screen presentation-definitions should be 
something to use in templates for screen presentation. There can also be 
templates for other purposes, messages, reports, etc.


Archetypes, except for its original purpose: 
data-structure-representation, need to be purpose independent. 
Archetypes are the base to build templates on, and depending of the 
purpose of the template, the data will be represented in a different way.


So archetypes need to be as much as possible machine-processable, and if 
you use all kind of convenient terms to, for example, indicate pain, 
then you will never be able to datamine (research in the history of a 
patient, or in a population) in a more generic way, and you will also 
need that specific archetype.


Imagine a hospital with 7000 archetypes, it will become nearly 
impossible to find persons which have pain, what kind of pain and how 
severe it is.


Better is to code pain, and I know SCT has good codes for pain (there 
may be other code-systems too). This makes machine processable searching 
for pain, kind of pain, severity of pain possible and will improve 
healthcare for a specific patient or a population.


Bert



___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[GF]

Each entry in the classification needs:
- a screen representation (‘+++')
- a description (‘moderate')
- an expression defining the inclusion criteria  ('Lower Limit' < ‘Value' < 
'Higher limit'
- an expression defining the exclusion criteria ('no diagnosis of xyz')

And perhaps each entry needs:
- Ranking number (‘1')
- Presentation ranking number (‘4')
- Associated value for calculation support (‘100')

To my ideas the Semantic Ordinal, as described, actually is an Archetype 
Pattern or a Data Type.

Gerard

> On 29 Sep 2016, at 14:09, Thomas Beale  wrote:
> 
> 
> 
> On 29/09/2016 12:58, GF wrote:
>> Is possible to define inclusion and exclusion criteria in the DV-Ordinal?
>> 
> 
> Gerard
> 
> can you explain in more detail what you mean?
> 
> -thomas
> 
> 

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Aw: Re: Normal range/reference ranges for text data type

[Karsten Hilbert]

> Yes. That is how this should work but I'm still not sure exactly what the 
> requirement is.
>
> Can you give a couple of examples of the result values and associated 
> reference ranges?

Assuming I correctly understood the OP I think an example would be:

Blood in urine dipstick:
 reference range: negative/none

Typical results given are: + - neg pos ++ +++  0 none %

Karsten

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[GF]

Is possible to define inclusion and exclusion criteria in the DV-Ordinal?

GF

> On 29 Sep 2016, at 09:00, Bakke, Silje Ljosland 
>  wrote:
> 
> Thanks for your replies everyone!
>  
> Can the Any data type be constrained to DV_ORDINAL and populated with values 
> in template or at run time?
> Regards,
> Silje
>  

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[Ian McNicoll]

Hi Silje

Yes. That is how this should work but I'm still not sure exactly what the
requirement is.

Can you give a couple of examples of the result values and associated
reference ranges?

Ian
On Thu, 29 Sep 2016 at 08:00, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Thanks for your replies everyone!
>
>
>
> Can the Any data type be constrained to DV_ORDINAL and populated with
> values in template or at run time?
>
> Regards,
> *Silje*
>
>
>
> *From:* openEHR-clinical [mailto:
> openehr-clinical-boun...@lists.openehr.org] *On Behalf Of *Thomas Beale
> *Sent:* Wednesday, September 28, 2016 4:44 PM
> *To:* openehr-clinical@lists.openehr.org
> *Subject:* Re: Normal range/reference ranges for text data type
>
>
>
>
>
> Normally this is done with the Ordinal (DV_ORDINAL) data type, which is a
> kind of DV_ORDERED
> <http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_quantity_package>,
> which has normal_range and reference_ranges defined.
>
> - thomas
>
>
>
> On 28/09/2016 14:25, Karsten Hilbert wrote:
>
> On Wed, Sep 28, 2016 at 01:23:00PM +0100, Ian McNicoll wrote:
>
>
>
> If a result is expressed as normal/ abnormal or high/normal/low,
>
> surely the 'normalcy range' is self-defining.
>
>
>
> If there is a need for the lab to assert some kind of textual normalcy
>
> rangeThe 'reference range guidance' element  in the Lab panel
>
> archetype is intended for this purpose and essentially equates to
>
> referenceRange/text in the FHIR Observation.
>
>
>
> I think Silje was asking about a way to define reference
>
> ranges for textual results in a computable fashion.
>
>
>
> Karsten
>
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

RE: Normal range/reference ranges for text data type

[Bakke, Silje Ljosland]

Thanks for your replies everyone!

Can the Any data type be constrained to DV_ORDINAL and populated with values in 
template or at run time?
Regards,
Silje

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Wednesday, September 28, 2016 4:44 PM
To: openehr-clinical@lists.openehr.org
Subject: Re: Normal range/reference ranges for text data type




Normally this is done with the Ordinal (DV_ORDINAL) data type, which is a kind 
of 
DV_ORDERED<http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_quantity_package>,
 which has normal_range and reference_ranges defined.

- thomas

On 28/09/2016 14:25, Karsten Hilbert wrote:

On Wed, Sep 28, 2016 at 01:23:00PM +0100, Ian McNicoll wrote:



If a result is expressed as normal/ abnormal or high/normal/low,

surely the 'normalcy range' is self-defining.



If there is a need for the lab to assert some kind of textual normalcy

rangeThe 'reference range guidance' element  in the Lab panel

archetype is intended for this purpose and essentially equates to

referenceRange/text in the FHIR Observation.



I think Silje was asking about a way to define reference

ranges for textual results in a computable fashion.



Karsten

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[Ian McNicoll]

Thanks Thomas,

Good suggestion.

@karsten. The reference range guidance element could be made computable by
using a coded text and controlled terminology, rather than just plain text.

Ian
On Wed, 28 Sep 2016 at 15:43, Thomas Beale  wrote:

>
> Normally this is done with the Ordinal (DV_ORDINAL) data type, which is a
> kind of DV_ORDERED
> ,
> which has normal_range and reference_ranges defined.
>
> - thomas
>
> On 28/09/2016 14:25, Karsten Hilbert wrote:
>
> On Wed, Sep 28, 2016 at 01:23:00PM +0100, Ian McNicoll wrote:
>
>
> If a result is expressed as normal/ abnormal or high/normal/low,
> surely the 'normalcy range' is self-defining.
>
> If there is a need for the lab to assert some kind of textual normalcy
> rangeThe 'reference range guidance' element  in the Lab panel
> archetype is intended for this purpose and essentially equates to
> referenceRange/text in the FHIR Observation.
>
>
> I think Silje was asking about a way to define reference
> ranges for textual results in a computable fashion.
>
> Karsten
>
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[Thomas Beale]

Normally this is done with the Ordinal (DV_ORDINAL) data type, which is 
a kind of DV_ORDERED 
, 
which has normal_range and reference_ranges defined.


- thomas


On 28/09/2016 14:25, Karsten Hilbert wrote:

On Wed, Sep 28, 2016 at 01:23:00PM +0100, Ian McNicoll wrote:


If a result is expressed as normal/ abnormal or high/normal/low,
surely the 'normalcy range' is self-defining.

If there is a need for the lab to assert some kind of textual normalcy
rangeThe 'reference range guidance' element  in the Lab panel
archetype is intended for this purpose and essentially equates to
referenceRange/text in the FHIR Observation.

I think Silje was asking about a way to define reference
ranges for textual results in a computable fashion.

Karsten


___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[Karsten Hilbert]

On Wed, Sep 28, 2016 at 01:23:00PM +0100, Ian McNicoll wrote:

> If a result is expressed as normal/ abnormal or high/normal/low,
> surely the 'normalcy range' is self-defining.
> 
> If there is a need for the lab to assert some kind of textual normalcy
> rangeThe 'reference range guidance' element  in the Lab panel
> archetype is intended for this purpose and essentially equates to
> referenceRange/text in the FHIR Observation.

I think Silje was asking about a way to define reference
ranges for textual results in a computable fashion.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[Ian McNicoll]

Hi Silje,

This seems a bit odd to me. Do labs normally

If a result is expressed as normal/ abnormal or high/normal/low,
surely the 'normalcy range' is self-defining.

If there is a need for the lab to assert some kind of textual normalcy
rangeThe 'reference range guidance' element  in the Lab panel
archetype is intended for this purpose and essentially equates to
referenceRange/text in the FHIR Observation.

see http://openehr.org/ckm/#showArchetype_1013.1.2192

Does that work?

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 28 September 2016 at 12:56, Karsten Hilbert  wrote:
> On Wed, Sep 28, 2016 at 11:27:18AM +, Bakke, Silje Ljosland wrote:
>
>> We're working on requirements for labs results, and have
>> bumped into a potential problem. Some results are
>> textual/non-quantitative in nature, for example
>> "positive/negative", "+/++/+++",
>> "negative/borderline/positive". These results also need a
>> kind of "normal range" for the receiving system to be able to
>> mark or emphasise it in the UI. The text data type however
>> doesn't have any normal range/reference ranges attributes in
>> the reference model like the quantity, count and ordinal data
>> types do. We can't have several different places where the
>> normality information is kept for different data types, as
>> this would be very complex to handle. How should this be
>> handled?
>
> Often, the lab will provide a field denoting in-rangeness of
> such results. Other than that, a human on the receiving side
> may have to manually set the property when reviewing /
> paraphing the result.
>
> Some programmatic smarts can be added to applications to
> auto-set the property to "not-any-known-normal" where
> "known-normal" consists of a suitably restricted regular
> expression defined per test type.
>
> Karsten
> --
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[Karsten Hilbert]

On Wed, Sep 28, 2016 at 11:27:18AM +, Bakke, Silje Ljosland wrote:

> We're working on requirements for labs results, and have
> bumped into a potential problem. Some results are
> textual/non-quantitative in nature, for example
> "positive/negative", "+/++/+++",
> "negative/borderline/positive". These results also need a
> kind of "normal range" for the receiving system to be able to
> mark or emphasise it in the UI. The text data type however
> doesn't have any normal range/reference ranges attributes in
> the reference model like the quantity, count and ordinal data
> types do. We can't have several different places where the
> normality information is kept for different data types, as
> this would be very complex to handle. How should this be
> handled?

Often, the lab will provide a field denoting in-rangeness of
such results. Other than that, a human on the receiving side
may have to manually set the property when reviewing /
paraphing the result.

Some programmatic smarts can be added to applications to
auto-set the property to "not-any-known-normal" where
"known-normal" consists of a suitably restricted regular
expression defined per test type.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Normal range/reference ranges for text data type

[Diego Boscá]

Hello Silje,

We had a little discussion on the matter in the questions part of the
wiki this year
https://openehr.atlassian.net/wiki/questions/30900242/how-to-model-meta-archetypes

Regards

2016-09-28 13:27 GMT+02:00 Bakke, Silje Ljosland
:
> Hi everyone,
>
>
>
> We’re working on requirements for labs results, and have bumped into a
> potential problem. Some results are textual/non-quantitative in nature, for
> example “positive/negative”, “+/++/+++”, “negative/borderline/positive”.
> These results also need a kind of “normal range” for the receiving system to
> be able to mark or emphasise it in the UI. The text data type however
> doesn’t have any normal range/reference ranges attributes in the reference
> model like the quantity, count and ordinal data types do. We can’t have
> several different places where the normality information is kept for
> different data types, as this would be very complex to handle. How should
> this be handled?
>
>
>
> Kind regards,
> Silje Ljosland Bakke
>
>
>
> Information Architect, RN
>
> Coordinator, National Editorial Board for Archetypes
> National ICT Norway
>
> Tel. +47 40203298
>
> Web: http://arketyper.no / Twitter: @arketyper_no
>
>
>
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org