Re: Interval events - "change" math function semantics

[Thomas Beale]

On 27/06/2018 18:21, Pablo Pazos wrote:




I'm inclined to have an initial absolute / reference value, then the 
"changes" (deltas, increase, decrease, ...) to be recorded in the same 
HISTORY.data time series. IMO this needs clinical validation, but my 
assumption os if "reference" and "changes" are not recorded together, 
there is missing context for the "change" records that should be 
resolved in software (if the specs don't provide a recommendation), 
and might be an issue for patient safety (also this needs clinical 
validation).


If we can validate that, and agree on a criteria, we might need to add 
a clarification/recommendation on that area to the specs.


It's probably a good idea to do it like this, but it would be good to 
get some input from people workig with operational systems, to see how 
they are using these kinds of math function indicators.


- t


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

Re: Interval events - "change" math function semantics

[Pablo Pazos]

Hi Thomas,

I think I'm missing something:

"...previous measurement is not necessarily in the data set."

>From that ^ I understand the reference value from which the "change" is
measure & recorded is not on the HISTORY time series.

"...one would expect the first value in a HISTORY of EVENTs..."

And that ^ seems to point on the other way. **confused**


I'm inclined to have an initial absolute / reference value, then the
"changes" (deltas, increase, decrease, ...) to be recorded in the same
HISTORY.data time series. IMO this needs clinical validation, but my
assumption os if "reference" and "changes" are not recorded together, there
is missing context for the "change" records that should be resolved in
software (if the specs don't provide a recommendation), and might be an
issue for patient safety (also this needs clinical validation).

If we can validate that, and agree on a criteria, we might need to add a
clarification/recommendation on that area to the specs.


On Wed, Jun 27, 2018 at 7:55 AM, Thomas Beale 
wrote:

>
>
> On 23/06/2018 21:13, Pablo Pazos wrote:
>
> Hi, another question about interval events.
>
> I'm having issues understanding how to use the "change" math functions.
> From the spec http://www.openehr.org/releases/RM/Release-1.0.2/
> docs/data_structures/data_structures.html#_change_data
>
>-
>
>"change": this means that the value recorded is the difference between
>the value now and the value some time previously. It can be positive or
>negative;
>-
>
>"increase": the value recorded for the change is positive. The name
>(i.e. ELEMENT.name) chosen for the item in an archetype carries the
>semantic of positivity e.g. "increase of …​.; rise of…​.; …​.gain" etc;
>-
>
>"decrease": the value recorded for the change is positive. But the
>name chosen for the item carries the semantic of negativity e.g. "decrease
>of …​.; fall of …​.; …​. loss".
>
>
> Since "change", "increase" or "decrease" are based on a previous value,
> shouldn't the record of the change have a link to the previous value that
> served as reference to record the change?
>
>
> it is based on a previous value of the measured datum, but that previous
> measurement is not necessarily in the data set. The use of these codes
> indicates that the difference is being recorded, not the absolute value.
>
>
> I'm not sure in which context a change or increase on some value would be
> useful without the value that change or increase is compared with.
>
>
> Agree; to make it sensible, one would expect the first value in a HISTORY
> of EVENTs to be an absolute instantaneous value, with some or all of the
> other values being differences.
>
>
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Project, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
>  | The Objective Stance
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter 

http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AE constraints offset for POINT_EVENTs

[Pablo Pazos]

On Wed, Jun 27, 2018, 04:56 Thomas Beale  wrote:

>
> On 26/06/2018 18:12, Pablo Pazos wrote:
>
> Thanks David, didn't noticed that discussion!
>
> @Thomas, isn't constraining HISTORY.period a way to define
> POINT_EVENT.offset() for all the events in HISTORY.events?
>
>
> only in a general way and only for Event series that happen to be
> periodic. For example, the Apgar uses only the specific offsets 1 min, 2
> mins, 5 mins and 10 mins.
>

>From the AE it seems not possible to constraint the offset in that way.
Only fixed suggestions can be set. All is defining only periodic point
events. Not sure how defining not constant offsets would be expressed.


> - t
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Project, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
>  | The Objective Stance
> 
> ___
> 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: Interval events - "change" math function semantics

[Thomas Beale]

On 23/06/2018 21:13, Pablo Pazos wrote:

Hi, another question about interval events.

I'm having issues understanding how to use the "change" math 
functions. From the spec 
http://www.openehr.org/releases/RM/Release-1.0.2/docs/data_structures/data_structures.html#_change_data


 *

"change": this means that the value recorded is the difference
between the value now and the value some time previously. It can
be positive or negative;

 *

"increase": the value recorded for the change is positive. The
name (i.e. |ELEMENT|.name) chosen for the item in an archetype
carries the semantic of positivity e.g. "increase of …​.; rise
of…​.; …​.gain" etc;

 *

"decrease": the value recorded for the change is positive. But the
name chosen for the item carries the semantic of negativity e.g.
"decrease of …​.; fall of …​.; …​. loss".


Since "change", "increase" or "decrease" are based on a previous 
value, shouldn't the record of the change have a link to the previous 
value that served as reference to record the change?


it is based on a previous value of the measured datum, but that previous 
measurement is not necessarily in the data set. The use of these codes 
indicates that the difference is being recorded, not the absolute value.




I'm not sure in which context a change or increase on some value would 
be useful without the value that change or increase is compared with.


Agree; to make it sensible, one would expect the first value in a 
HISTORY of EVENTs to be an absolute instantaneous value, with some or 
all of the other values being differences.







--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

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

Re: AE constraints offset for POINT_EVENTs

[Thomas Beale]

On 26/06/2018 18:12, Pablo Pazos wrote:

Thanks David, didn't noticed that discussion!

@Thomas, isn't constraining HISTORY.period a way to define 
POINT_EVENT.offset() for all the events in HISTORY.events?


only in a general way and only for Event series that happen to be 
periodic. For example, the Apgar uses only the specific offsets 1 min, 2 
mins, 5 mins and 10 mins.


- t

--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

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