Re: Setting thresholds

[GF]

I agree this ‘definition’ problem is outside of the scope of this list.
But since you misused terms, I reacted.

In your example in words:
- Observation 'Serum sodium = X’,  'Normal associated and stored Normal range 
for adult males:: Lower=A, Higher=B 
- Evaluation 1 'X is abnormal and lower than Lower bound A’
- Evaluation 2 'Patient System has a state of  Hyponatrenomy’
- Evaluation 3 ‘Patient System has problem item on the Problem list Y’
- Evaluation 4 ‘Patient System has risk to have as possible diagnosis Z1, Z2, 
Z3’
- …
-…
-  Evaluation N ‘Patient has diagnosis Z4’

I agree that just one single Observation is not enough to safely diagnose the 
patient.
More is needed than that.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Mar 2018, at 17:29, Bakke, Silje Ljosland 
>  wrote:
> 
> We’re getting into territory that maybe doesn’t belong in the technical list 
> anymore, but anyway. <>
>  
> I suspect this may be a disagreement in choice of words. I’m talking about 
> the difference between observational and evaluative statements. The lab 
> result is observational and what I called “diagnosis” is evaluative. The 
> point I was trying to make is that these are different in nature, whether we 
> choose to call the evaluative statement “problem” or “diagnosis”. The 
> S-sodium lab result by itself doesn’t necessarily mean that the patient 
> actually had a real hyponatremia, though I see that my previous statement 
> could be interpreted as such. Maybe the patient had simultaneous 
> hyperlipidemia or hyperproteinemia? The assessment of the larger picture is 
> of course what leads to the evaluative statement.
>  
> The overall point I was trying to make was that you can’t expect to be able 
> to computationally draw conclusions about the health of a patient based only 
> on reference ranges for single observational statements; you also need a 
> human (or perhaps in the future a machine?) to assess a larger picture.
>  
> I wish you all a nice weekend! J
>  
> Regards,
> Silje
>  

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

RE: Setting thresholds

[Bakke, Silje Ljosland]

We’re getting into territory that maybe doesn’t belong in the technical list 
anymore, but anyway.

I suspect this may be a disagreement in choice of words. I’m talking about the 
difference between observational and evaluative statements. The lab result is 
observational and what I called “diagnosis” is evaluative. The point I was 
trying to make is that these are different in nature, whether we choose to call 
the evaluative statement “problem” or “diagnosis”. The S-sodium lab result by 
itself doesn’t necessarily mean that the patient actually had a real 
hyponatremia, though I see that my previous statement could be interpreted as 
such. Maybe the patient had simultaneous hyperlipidemia or hyperproteinemia? 
The assessment of the larger picture is of course what leads to the evaluative 
statement.

The overall point I was trying to make was that you can’t expect to be able to 
computationally draw conclusions about the health of a patient based only on 
reference ranges for single observational statements; you also need a human (or 
perhaps in the future a machine?) to assess a larger picture.

I wish you all a nice weekend! ☺

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of GF
Sent: Friday, March 2, 2018 4:19 PM
To: Thomas Beale 
Subject: Re: Setting thresholds

I agree with Karsten.

Diagnosis (in my terms) is a statement as the result of an Evaluation process 
about the Patient System.
Measurement is the result of an Observation process about the Patient System 
using materials of the Patient System as source.
Evaluation is the result of an Evaluation process that indicates that the 
result is ‘normal’, ‘elevated’, ‘low’, ‘abnormal’, ‘risk of’, etc.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands


On 2 Mar 2018, at 15:22, Karsten Hilbert 
> wrote:

On Fri, Mar 02, 2018 at 01:48:40PM +, Bakke, Silje Ljosland wrote:


A doctor making and recording a conclusion that a
measurement of some kind is too high or too low, IS a
diagnosis.

Uhm, no.


their conclusion would be recorded as a diagnosis of hyponatremia.

While most doctors will do that it is wrong.

Hyponatremia is not a diagnosis. It is just a
supposedly-clever way of saying what the lab already said. It
is intended to make non-doctors think we doctors are in
control of the situation.

At best, it is an unresolved problem. All in all it is a
_finding_, or observation, notably out-of-range :-)

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

___
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: Setting thresholds

[GF]

I agree with Karsten.

Diagnosis (in my terms) is a statement as the result of an Evaluation process 
about the Patient System.
Measurement is the result of an Observation process about the Patient System 
using materials of the Patient System as source.
Evaluation is the result of an Evaluation process that indicates that the 
result is ‘normal’, ‘elevated’, ‘low’, ‘abnormal’, ‘risk of’, etc.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Mar 2018, at 15:22, Karsten Hilbert  wrote:
> 
> On Fri, Mar 02, 2018 at 01:48:40PM +, Bakke, Silje Ljosland wrote:
> 
>> A doctor making and recording a conclusion that a
>> measurement of some kind is too high or too low, IS a
>> diagnosis.
> 
> Uhm, no.
> 
>> their conclusion would be recorded as a diagnosis of hyponatremia.
> 
> While most doctors will do that it is wrong.
> 
> Hyponatremia is not a diagnosis. It is just a
> supposedly-clever way of saying what the lab already said. It
> is intended to make non-doctors think we doctors are in
> control of the situation.
> 
> At best, it is an unresolved problem. All in all it is a
> _finding_, or observation, notably out-of-range :-)
> 
> Karsten
> -- 
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> ___
> 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: Setting thresholds

[Jan-Marc Verlinden]

But I do think it is a clinical status, at least similar to a diagnosis.
For me it is more like a score for BMI or ACQ (asthma Control
Questionnaire). And for that you can also store the value in the
observation.
-- 

Regards, Jan-Marc
Mobile: +31 6 53785650
www.medrecord.io
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[Karsten Hilbert]

On Fri, Mar 02, 2018 at 01:48:40PM +, Bakke, Silje Ljosland wrote:

> A doctor making and recording a conclusion that a
> measurement of some kind is too high or too low, IS a
> diagnosis.

Uhm, no.

> their conclusion would be recorded as a diagnosis of hyponatremia.

While most doctors will do that it is wrong.

Hyponatremia is not a diagnosis. It is just a
supposedly-clever way of saying what the lab already said. It
is intended to make non-doctors think we doctors are in
control of the situation.

At best, it is an unresolved problem. All in all it is a
_finding_, or observation, notably out-of-range :-)

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

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

Re: Setting thresholds

[Jan-Marc Verlinden]

Completely agree.. :-)
-- 

Regards, Jan-Marc
Mobile: +31 6 53785650
www.medrecord.io
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Setting thresholds

[Bakke, Silje Ljosland]

You're right, I missed the "have HAD". The correct query would of course be 
"all patients with an EVALUATION.problem_diagnosis with one of a defined set of 
codes for ‘hypertension’".

A doctor making and recording a conclusion that a measurement of some kind is 
too high or too low, IS a diagnosis. A similar example using lab results would 
be a measured serum sodium level of 105 mmol/L, with the attached (from the 
lab) reference range of 115-160 mmol/L. The fact that the measurement is 
outside the reference range is an indication to the doctor that something is 
wrong, but their conclusion would be recorded as a diagnosis of hyponatremia. 
When the patient at a later point is better and a subsequent sodium result is 
back within the reference range, the hyponatremia diagnosis would be set as 
resolved.

Regards,
Silje


-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Karsten Hilbert
Sent: Friday, March 2, 2018 2:29 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Setting thresholds

On Fri, Mar 02, 2018 at 01:18:03PM +, Bakke, Silje Ljosland wrote:

> A query for “all patients that have had high BP according to the 
> doctor” would the way I see this be a query for “all patients with an 
> EVALUATION.problem_diagnosis with one of a defined set of codes for 
> ‘hypertension’ and no resolution date”.

It would not be.

Because the two assertions are not equivalent.

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

___
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: Setting thresholds

[Karsten Hilbert]

On Fri, Mar 02, 2018 at 01:18:03PM +, Bakke, Silje Ljosland wrote:

> A query for “all patients that have had high BP according
> to the doctor” would the way I see this be a query for “all
> patients with an EVALUATION.problem_diagnosis with one of a
> defined set of codes for ‘hypertension’ and no resolution
> date”.

It would not be.

Because the two assertions are not equivalent.

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

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

Re: Setting thresholds

[Jan-Marc Verlinden]

Uhhh, no in this case I do not agree... :-)

I think we have measurements over time:
2 Oktober 2015 with values 60 and 115. And also the conclusion of the
doctor that 60 was too low.
1 september 2016 with values  60 and 115. And also the conclusion of the
doctor that everything is just fine
Etc...

So in fact the thresholds have changed here. But the similar usecase is our
storage of thresholds in the Graph. If I change these thresholds I would
like to be able to query on the changed thresholds.

I believe your suggestion is different from this as your evaluation query
will be: give me all data within the ranges xx.
-- 

Regards, Jan-Marc
Mobile: +31 6 53785650
www.medrecord.io
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[Jan-Marc Verlinden]

Dear Silje,

I agree with you, but also with most of the other comments. The thing is
that there is a difference between the desired (optimal) solution ans
something the user is able to work with, without spending way too much..
:-).

So in fact I choose for your No 1, but I think the desired model would be
to store these (changing) threshold inside the EHR. This is because I think
these threshold will provide the semantics behind the numbers. In fact I
think it is similar to the "sitting" or "standing" in the famous BP
measurement, only in this case it is more like: I as a doctor consider this
value too high or too low.

Which is, again in my opinion, quite different from clinical decision
support.
-- 

Regards, Jan-Marc
Mobile: +31 6 53785650
www.medrecord.io
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Setting thresholds

[Bakke, Silje Ljosland]

This sounds like a sensible and pragmatic solution. ☺

A query for “all patients that have had high BP according to the doctor” would 
the way I see this be a query for “all patients with an 
EVALUATION.problem_diagnosis with one of a defined set of codes for 
‘hypertension’ and no resolution date”.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Jan-Marc Verlinden
Sent: Friday, March 2, 2018 2:09 PM
To: For openEHR technical discussions 
Subject: Re: Setting thresholds

This ended up being quite some discussion.. :-)

We choose for the option to show the thresholds in the Graph, and do it 
handcrafted/hardcoded. So we will not be able to query on the semantics of the 
data, in this sense: give me all patients that has had high BP according to the 
doctor. We will only be able to query on defined thresholds (by Snomed or 
whatever..).

It is what it is.. :-)

For this usecase there is absolutely no need to make it more difficult than 
just this. Maybe for other usecases there would be another optimum, but for now 
I would like to keep it KISS.
--

Regards, Jan-Marc
Mobile: +31 6 53785650
www.medrecord.io
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[Jan-Marc Verlinden]

This ended up being quite some discussion.. :-)

We choose for the option to show the thresholds in the Graph, and do it
handcrafted/hardcoded. So we will not be able to query on the semantics of
the data, in this sense: give me all patients that has had high BP
according to the doctor. We will only be able to query on defined
thresholds (by Snomed or whatever..).

It is what it is.. :-)

For this usecase there is absolutely no need to make it more difficult than
just this. Maybe for other usecases there would be another optimum, but for
now I would like to keep it KISS.
-- 

Regards, Jan-Marc
Mobile: +31 6 53785650
www.medrecord.io
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Setting thresholds

[Bakke, Silje Ljosland]

Jean-Marc specified that thresholds would need to be able to be "changed 
afterwards" (I assume after the data was committed to the EHR), which to me 
implies that their problem was closer to my item 1) below.

Regards,
Silje

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Karsten Hilbert
Sent: Friday, March 2, 2018 12:13 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Setting thresholds

On Fri, Mar 02, 2018 at 10:55:47AM +, Bakke, Silje Ljosland wrote:

> I've hesitated to participate in this discussion, but I think I have a couple 
> of points to add now, as I think there are two different problems being 
> discussed here:
> 
> 1.   The original problem, which in my opinion is how and where to store 
> reference ranges for clinical observations such as for instance blood 
> pressure. These reference ranges are often based on clinical research, and 
> may change with time as new research emerges. In my opinion these shouldn't 
> be stored with the original observation data, but can (when needed) be stored 
> with any interpretation where the data is used to reach a conclusion, for 
> example a symptom, diagnosis or even just an instruction. The reference 
> ranges that are current at any point in time however, should be stored and 
> accessed from a knowledge base outside the EHR, as they don't relate to the 
> data of a specific patient. However, that knowledge base may well be linked 
> to specific archetypes and archetype elements to facilitate its usage, for 
> example to the systolic, diastolic and position elements of the blood 
> pressure archetype, if the reference ranges vary based on the position of the 
> patient at the time of measurement.
> 
> 2.   The problem of reference ranges that are intricately bound to 
> specific observations and their methods, such as lab results. These should 
> be, and are commonly, stored with the observations in the EHR because the 
> details of analytic method and other factors that affect them are far too 
> complex to include in the EHR data. The RM attributes "normal_range" and 
> "other_reference_ranges" (and "normal_status") of the Quantity data type are 
> well suited for these reference ranges.

That about wraps it up.

Except that I was of the impression that the original question was more about 
2) rather than 1).

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

___
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: Setting thresholds

[GF]

Imo

Past data including past references are in the EHR.
The present is elsewhere as a service in the EHR-system.

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 2 Mar 2018, at 09:47, Diego Boscá  wrote:
> 
> Not sure if I fully understand/agree. As knowledge advances, past data could 
> be seen under a new light (e.g. some medication was given to a set of 
> patients and now we know it has a contraindication with another medication) 
> and we could get different results each time we run the query, which is 
> exactly what we want

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

Re: Setting thresholds

[Karsten Hilbert]

On Fri, Mar 02, 2018 at 10:55:47AM +, Bakke, Silje Ljosland wrote:

> I've hesitated to participate in this discussion, but I think I have a couple 
> of points to add now, as I think there are two different problems being 
> discussed here:
> 
> 1.   The original problem, which in my opinion is how and where to store 
> reference ranges for clinical observations such as for instance blood 
> pressure. These reference ranges are often based on clinical research, and 
> may change with time as new research emerges. In my opinion these shouldn't 
> be stored with the original observation data, but can (when needed) be stored 
> with any interpretation where the data is used to reach a conclusion, for 
> example a symptom, diagnosis or even just an instruction. The reference 
> ranges that are current at any point in time however, should be stored and 
> accessed from a knowledge base outside the EHR, as they don't relate to the 
> data of a specific patient. However, that knowledge base may well be linked 
> to specific archetypes and archetype elements to facilitate its usage, for 
> example to the systolic, diastolic and position elements of the blood 
> pressure archetype, if the reference ranges vary based on the position of the 
> patient at the time of measurement.
> 
> 2.   The problem of reference ranges that are intricately bound to 
> specific observations and their methods, such as lab results. These should 
> be, and are commonly, stored with the observations in the EHR because the 
> details of analytic method and other factors that affect them are far too 
> complex to include in the EHR data. The RM attributes "normal_range" and 
> "other_reference_ranges" (and "normal_status") of the Quantity data type are 
> well suited for these reference ranges.

That about wraps it up.

Except that I was of the impression that the original
question was more about 2) rather than 1).

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

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

RE: Setting thresholds

[Bakke, Silje Ljosland]

I've hesitated to participate in this discussion, but I think I have a couple 
of points to add now, as I think there are two different problems being 
discussed here:

1.   The original problem, which in my opinion is how and where to store 
reference ranges for clinical observations such as for instance blood pressure. 
These reference ranges are often based on clinical research, and may change 
with time as new research emerges. In my opinion these shouldn't be stored with 
the original observation data, but can (when needed) be stored with any 
interpretation where the data is used to reach a conclusion, for example a 
symptom, diagnosis or even just an instruction. The reference ranges that are 
current at any point in time however, should be stored and accessed from a 
knowledge base outside the EHR, as they don't relate to the data of a specific 
patient. However, that knowledge base may well be linked to specific archetypes 
and archetype elements to facilitate its usage, for example to the systolic, 
diastolic and position elements of the blood pressure archetype, if the 
reference ranges vary based on the position of the patient at the time of 
measurement.

2.   The problem of reference ranges that are intricately bound to specific 
observations and their methods, such as lab results. These should be, and are 
commonly, stored with the observations in the EHR because the details of 
analytic method and other factors that affect them are far too complex to 
include in the EHR data. The RM attributes "normal_range" and 
"other_reference_ranges" (and "normal_status") of the Quantity data type are 
well suited for these reference ranges.


Regards,
Silje


-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Karsten Hilbert
Sent: Friday, March 2, 2018 11:28 AM
To: openehr-technical@lists.openehr.org
Subject: Re: Setting thresholds



On Fri, Mar 02, 2018 at 10:07:24AM +0100, David Moner wrote:



> You are talking about a future reuse or validation of the data. But

> what it was discused here is how to define the reference ranges for

> any data to take an action at the moment of data registry. And, as

> Gerard said, those references must be stored for future interpretation

> of the data. Thus, I'm of the opinion that ideally this should be

> stored together with the archetype/templates as it is part of the domain 
> knowledge at that moment.



The ranges will be different across labs and across types of measurement due to 
"precision available", "reagants used", "technology applied", and a variety of 
other ugly real-world factors. Even for the very same LOINC from the very same 
lab.



I don't think this knowledge should (or can) live in the archetype but rather 
be stored with the data and/or the interpretation of the data.



Karsten

--

GPG key ID E4071346 @ eu.pool.sks-keyservers.net

E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



___

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: Setting thresholds

[Karsten Hilbert]

On Fri, Mar 02, 2018 at 04:33:32AM -0600, William Archibald wrote:

> > The ranges will be different across labs and across types of
> > measurement due to "precision available", "reagants used",
> > "technology applied", and a variety of other ugly real-world
> > factors. Even for the very same LOINC from the very same lab.
> >
> > I don't think this knowledge should (or can) live in the
> > archetype but rather be stored with the data and/or the
> > interpretation of the data.
> 
> On one hand - I agree with you whole-heartedly. On the other, it seems as
> if you are saying that ultimately the real world is so complex (and has so
> many options) that reducing it all to a normalized/modeled/semantic basis
> is a fool's errand? Too many ugly "real-world factors" to ever be able to
> model in detail? (This may be true - but I am simply asking if that is what
> you are intending to declare.)

I am not attempting to declare that (though I see how it can
be thought to be so :)

I am only arguing this particular issue ATM.

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

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

Re: Setting thresholds

[Karsten Hilbert]

On Fri, Mar 02, 2018 at 11:23:09AM +0100, Karsten Hilbert wrote:

> > Not sure if I fully understand/agree. As knowledge advances, past data
> > could be seen under a new light (e.g. some medication was given to a set of
> > patients and now we know it has a contraindication with another medication)
> > and we could get different results each time we run the query, which is
> > exactly what we want
> 
> Sure, but, for medico-legal reasons past data must be
> see-able under then-applied rules/constraints/ranges

And not only "then-applicable", btw.

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

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

Re: Setting thresholds

[William Archibald]

On Fri, Mar 2, 2018 at 4:27 AM, Karsten Hilbert 
wrote:

> On Fri, Mar 02, 2018 at 10:07:24AM +0100, David Moner wrote:
>
> > You are talking about a future reuse or validation of the data. But what
> it
> > was discused here is how to define the reference ranges for any data to
> > take an action at the moment of data registry. And, as Gerard said, those
> > references must be stored for future interpretation of the data. Thus,
> I'm
> > of the opinion that ideally this should be stored together with the
> > archetype/templates as it is part of the domain knowledge at that moment.
>
> The ranges will be different across labs and across types of
> measurement due to "precision available", "reagants used",
> "technology applied", and a variety of other ugly real-world
> factors. Even for the very same LOINC from the very same lab.
>
> I don't think this knowledge should (or can) live in the
> archetype but rather be stored with the data and/or the
> interpretation of the data.
>

On one hand - I agree with you whole-heartedly. On the other, it seems as
if you are saying that ultimately the real world is so complex (and has so
many options) that reducing it all to a normalized/modeled/semantic basis
is a fool's errand? Too many ugly "real-world factors" to ever be able to
model in detail? (This may be true - but I am simply asking if that is what
you are intending to declare.)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[Karsten Hilbert]

On Fri, Mar 02, 2018 at 10:07:24AM +0100, David Moner wrote:

> You are talking about a future reuse or validation of the data. But what it
> was discused here is how to define the reference ranges for any data to
> take an action at the moment of data registry. And, as Gerard said, those
> references must be stored for future interpretation of the data. Thus, I'm
> of the opinion that ideally this should be stored together with the
> archetype/templates as it is part of the domain knowledge at that moment.

The ranges will be different across labs and across types of
measurement due to "precision available", "reagants used",
"technology applied", and a variety of other ugly real-world
factors. Even for the very same LOINC from the very same lab.

I don't think this knowledge should (or can) live in the
archetype but rather be stored with the data and/or the
interpretation of the data.

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

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

Re: Setting thresholds

[Diego Boscá]

Sure thing, see my example :)

2018-03-02 11:23 GMT+01:00 Karsten Hilbert :

> On Fri, Mar 02, 2018 at 09:47:12AM +0100, Diego Boscá wrote:
>
> > Not sure if I fully understand/agree. As knowledge advances, past data
> > could be seen under a new light (e.g. some medication was given to a set
> of
> > patients and now we know it has a contraindication with another
> medication)
> > and we could get different results each time we run the query, which is
> > exactly what we want
>
> Sure, but, for medico-legal reasons past data must be
> see-able under then-applied rules/constraints/ranges
> as well.
>
> Karsten
> --
> GPG key ID E4071346 @ eu.pool.sks-keyservers.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[Karsten Hilbert]

On Fri, Mar 02, 2018 at 09:47:12AM +0100, Diego Boscá wrote:

> Not sure if I fully understand/agree. As knowledge advances, past data
> could be seen under a new light (e.g. some medication was given to a set of
> patients and now we know it has a contraindication with another medication)
> and we could get different results each time we run the query, which is
> exactly what we want

Sure, but, for medico-legal reasons past data must be
see-able under then-applied rules/constraints/ranges
as well.

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

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

Re: Setting thresholds

[Diego Boscá]

Coming back to this, I agree that we can end with differing
implementations, but probably the challenge is to define the syntax of AQL
in a way that no different interpretations appear. Maybe I can propose a
simple example (not sure if 100% correct, but you get the idea)

/*NAMESPACE*/

ns snomedquery="http://someservice.org/test/;

let 
$diagnosis="data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value"

SELECT
obs/$diagnosis, $ehrUid
FROM
EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION
[openEHR-EHR-COMPOSITION.encounter.v1]
CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.problem-diagnosis.v1]
WHERE
   NOT 
snomedquery:in(obs/$diagnosis,"http://snomed.info/sct?fhir_vs=refset/mydiagrefset;)


This could be used for validation (and could be created automatically from
archetypes).
Even if we end up needing to know the range in the moment the measure was
taken we could use something similar

ns bioportal="http://bioportal.org/operations/;

let 
$timeOfMeasurement=c1/context/other_context/items[at0006]/items[at0013]/value
let 
$systolic_bp="data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude"

...


...

WHERE NOT 
bioportal:rangechecker($systolic_bp,$sex,$age,$race,$timeOfMeasurement)

I understand your concerns, but I think it falls into the same use case of
templates: Archetypes should have general use, but templates for your
organization probably haven't. Another example I can think of is mappings
to SNOMED-CT on archetypes: If you aren't in an IHTSDO member country you
can potentially end with constraints that you are unable to use/verify.

By the way, I don't know if I'm mistaken, but if we define the ranges on
the archetype I believe that currently AQL cannot access values in the
archetype definition, and probably the alternative of sending the ranges
with the data maybe is a little overkill.

2018-03-01 15:57 GMT+01:00 Seref Arikan :

> Hi Tom,
>
> On Thu, Mar 1, 2018 at 2:33 PM, Thomas Beale 
> wrote:
>
>>
>> On 01/03/2018 11:05, Seref Arikan wrote:
>>
>>> Hi Diego,
>>>
>>> I'd like to hear how you'd address the requirement via a call to an
>>> external service.
>>>
>>>
>> I don't think it should be that complicated - after all, a call out to a
>> terminology service is already a call out to a service; terminology is just
>> one kind of reference knowledge that a query language / engine needs to get
>> at; we can assume that a units service (as Bert and others were discussing
>> earlier), lab results reference ranges, drug DB and so on may all be needed
>> by the query service.
>>
>
> In case I gave the wrong impression: my question above was not meant to
> sound like I thought this would be a difficult thing. Reading it again, I
> can see that it may be interpreted as 'I'd like to see you try', which was
> not the intention. I genuinely wanted to  know how Diego would like to use
> AQL to address this specific requirement.
>
>>
>> So I think it mainly comes down to the syntax and programming model of
>> talking out to such interfaces. We might potentially assume that they are
>> all based on a common ontology meta-model of some kind (e.g. based on BFO,
>> RO, IAO etc) in which case a common underlying style could be established.
>
>
> The way I see it, your suggestion may pave the way to the can of worms I
> mentioned earlier, so I'll give up on my efforts to not to hijack this
> thread :)
>
> Re extending AQL for calls to external services: I'd be inclined to keep
> the syntax in the scope of the AQL specification and leave the programming
> model out of scope.
>
> I think AQL needs to support procedural extensions as an umbrella concept,
> which, then, can be used for a number of things, some of which may be calls
> to external knowledge services.
>
> There is a lot more than calling out to external terminology services that
> can be accomplished with procedural extensions: they could turn AQL into
> the ultimate clinical data query language, which is the upside.
>
> But there is a downside as well: things may get complicated from a
> standardisation point of view.  Once calls to external services become part
> of syntax, AQL's vendor/implementation independent nature will be harder to
> preserve, as vendors start doing useful and no doubt clever things with
> calls to external services. Aql's behaviour is already slightly different
> across vendors, so if vendor X implements a smart feature using an external
> service and that service is available only in my vendor X's implementation,
> behaviour interoperability provided by AQL would be damaged.
>
> I think the upsides are worth adding this support but downsides will need
> careful management, probably based on profiles/levels etc.
>
>>
>>
>> - thomas
>>
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> 

Re: Setting thresholds

[David Moner]

You are talking about a future reuse or validation of the data. But what it
was discused here is how to define the reference ranges for any data to
take an action at the moment of data registry. And, as Gerard said, those
references must be stored for future interpretation of the data. Thus, I'm
of the opinion that ideally this should be stored together with the
archetype/templates as it is part of the domain knowledge at that moment.
If it changes, the archetype version might also change as usual. For simple
rules, problably the current rules that can be added to the archetypes
could be enough. But if they are complex and we need to implement them in
an external service, then we have to maintain them functional in the
future. It is exactly the same as with terminologies: they evolve, but we
should mantain past version to interpret old data.

BTW, for our beloved Blood Pressure archetype this has just happened. BP is
still the best example for everything :D
http://www.acc.org/latest-in-cardiology/articles/2017/11/08/11/47/mon-5pm-bp-guideline-aha-2017

2018-03-02 9:47 GMT+01:00 Diego Boscá :

> Not sure if I fully understand/agree. As knowledge advances, past data
> could be seen under a new light (e.g. some medication was given to a set of
> patients and now we know it has a contraindication with another medication)
> and we could get different results each time we run the query, which is
> exactly what we want
>
> 2018-03-02 2:55 GMT+01:00 Colin Sutton :
>
>> There is a risk that the external service could provide different answers
>> at different times, if the external service is updated for technical or
>> clinical reasons (e.g. knowledge improvements)
>> Shouldn't the result of the query to the external service be made at the
>> time of the source event, not in AQL.
>> —
>> Colin
>> > On 1 Mar 2018, at 10:31 pm, Bert Verhees  wrote:
>> >
>> > On 01-03-18 12:01, Diego Boscá wrote:
>> >> I believe that we need a way in standard AQL to call to arbitrary
>> external services, this seems like another use case for that \
>> >
>> > I agree!
>> >
>> > ___
>> > openEHR-technical mailing list
>> > openEHR-technical@lists.openehr.org
>> > http://scanmail.trustwave.com/?c=13000=oeSX2qbCWwprcB5eNMB
>> 27oRdY2Loky0QJHUrFju91A=http%3a%2f%2flists%2eopenehr%
>> 2eorg%2fmailman%2flistinfo%2fopenehr-technical%5flists%2eopenehr%2eorg
>>
>>
>> 
>> #
>> Scanned by the Trustwave Secure Email Gateway - Trustwave's comprehensive
>> email content security solution.
>> 
>> #
>>
>> 
>> IMPORTANT NOTICE: This e-mail and any attachment to it are intended only
>> to be read or used by the named addressee. It is confidential and may
>> contain legally privileged information. No confidentiality or privilege is
>> waived or lost by any mistaken transmission to you. The CTC is not
>> responsible for any unauthorised alterations to this e-mail or attachment
>> to it. Views expressed in this message are those of the individual sender,
>> and are not necessarily the views of the CTC. If you receive this e-mail in
>> error, please immediately delete it and notify the sender. You must not
>> disclose, copy or use any part of this e-mail if you are not the intended
>> recipient.
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
>
> [image: VeraTech for Health SL] 
>
> [image: Twitter]   [image: LinkedIn]
>  [image: Maps]
> 
>
> Diego Boscá Tomás / Senior developer
> diebo...@veratech.es
> yamp...@gmail.com
>
> VeraTech for Health SL
> +34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
> <+34%20627%2001%2050%2023>
> www.veratech.es
>
> Su dirección de correo electrónico junto a sus datos personales forman
> parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
> cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
> Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
> rectificación, cancelación y, en su caso oposición, enviando una solicitud
> por escrito a verat...@veratech.es.
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner

Re: Setting thresholds

[Diego Boscá]

Not sure if I fully understand/agree. As knowledge advances, past data
could be seen under a new light (e.g. some medication was given to a set of
patients and now we know it has a contraindication with another medication)
and we could get different results each time we run the query, which is
exactly what we want

2018-03-02 2:55 GMT+01:00 Colin Sutton :

> There is a risk that the external service could provide different answers
> at different times, if the external service is updated for technical or
> clinical reasons (e.g. knowledge improvements)
> Shouldn't the result of the query to the external service be made at the
> time of the source event, not in AQL.
> —
> Colin
> > On 1 Mar 2018, at 10:31 pm, Bert Verhees  wrote:
> >
> > On 01-03-18 12:01, Diego Boscá wrote:
> >> I believe that we need a way in standard AQL to call to arbitrary
> external services, this seems like another use case for that \
> >
> > I agree!
> >
> > ___
> > openEHR-technical mailing list
> > openEHR-technical@lists.openehr.org
> > http://scanmail.trustwave.com/?c=13000=oeSX2qbCWwprcB5eNMB27oRdY2Loky
> 0QJHUrFju91A=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%
> 2fopenehr-technical%5flists%2eopenehr%2eorg
>
>
> 
> #
> Scanned by the Trustwave Secure Email Gateway - Trustwave's comprehensive
> email content security solution.
> 
> #
>
> 
> IMPORTANT NOTICE: This e-mail and any attachment to it are intended only
> to be read or used by the named addressee. It is confidential and may
> contain legally privileged information. No confidentiality or privilege is
> waived or lost by any mistaken transmission to you. The CTC is not
> responsible for any unauthorised alterations to this e-mail or attachment
> to it. Views expressed in this message are those of the individual sender,
> and are not necessarily the views of the CTC. If you receive this e-mail in
> error, please immediately delete it and notify the sender. You must not
> disclose, copy or use any part of this e-mail if you are not the intended
> recipient.
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 <+34%20961%2007%2018%2063> / +34 627015023
<+34%20627%2001%2050%2023>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Setting thresholds

[GF]

Thomas,

yes, agree.
But we need more ontologies informing archetypes, classifications and 
/terminologies about other topics such as defined in the ISO Continuity of Care 
standard, …

Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 1 Mar 2018, at 16:24, Thomas Beale  wrote:
> 
> 
> Sorry - didn't mean to be cryptic.
> BFO = basic formal ontology - probably best mainstream reference is the book, 
> see here on Amazon 
> 
> RO = relations ontology - an ontology of possible relationships between 
> upper-level biomedical entities, including part-of, develops-from etc. OBO 
> ref .
> IAO = Information Artefact Ontology. OBO ref 
> .
> 
> I'm not saying that the concrete representation of reference data has to be 
> an ontology (e.g. as produced by Protege), but reference information 
> ('knowledge') is unavoidably based on an ontological viewpoint in the same 
> way that the contents of SNOMED CT are (should be). Drug data for example 
> takes the form of facts about drugs such as constituents, interactions; units 
> information is /should be based on an ontology of measurement concepts (which 
> is not very well represented in OBO right now - as far as I can determine, 
> people think it should be in IAO, but I think that is incorrect. Practically, 
> UCUM serves pretty well.)
> 
> - thomas

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