Setting thresholds

Seref Arikan serefarikan at kurumsalteknoloji.com
Wed Feb 28 09:59:43 EST 2018


On Wed, Feb 28, 2018 at 2:35 PM, GF <gfrer at luna.nl> wrote:

>
>
> Gerard   Freriks
> +31 620347088 <+31%206%2020347088>
>   gfrer at luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 28 Feb 2018, at 14:42, Seref Arikan <serefarikan at kurumsalteknoloji.com>
> wrote:
>
> Hi Tom,
>
> The original question is talking about 'threshold's changing in time.
> Would not using reference ranges may make things complicated during
> implementation with the changing threshold requirement?
>
>
> Not when the complete context/epistemology- and thus the actual range-  is
> stored next to the data value.
> What is the complexity?
>
>
 I just explained the complexity in the next two items. Neither your
generic and context independent "not when.."  statement nor your question
makes sense to me, in response to a specific points I made. Care to expand
on your claim in the context of the points I made below?

>
>
>
> First: if the threshold is changing with respect to all instances of a
> particular composition (template_id = 'x') , when the change happens, would
> not you have to update reference ranges of the DV_QUANTITY node in all
> composition instances across all EHRs to express the new threshold? That
> is, if you define high systolic blood pressure using a reference value,
> would not you have to update all blood pressure observations when the
> accepted 'high' value (threshold) changes?
>
> Second: Setting the reference value to express a threshold would make it
> impossible to query above/below threshold sets of composition via AQL
> because it'd require a query that uses the WHERE clause as follows:
> ".... WHERE some/path/node1.value > /some/path/node1.reference_range.value"
> (excuse the mock paths) which, as far as I know is not supported by AQL at
> the moment, not even grammar-wise (I may be out of date on this one)
>
> If you keep the reference value at the application level, all you have to
> do is update it without having to touch the existing instances and use AQL
> to select above/below threshold since you can plug the threshold value
> directly into WHER
>
>
> Leaving epistemological information in the application is. creating
> problems because ranges change overtime and are true in one geo- and
> temporal context only.
>

So? Does this mean what I've written above is incorrect? In what way is it
a response to the points I made? You can keep track of changing reference
ranges by simply associating the range with the template identifier would
give you the exact same information with keeping reference ranges in actual
data instances. If the same reference range does not apply to all instances
of template V1 then it means you can't have a single threshold in the first
place. If you have the same threshold for all instances of template V1 then
why repeat it instead of associating it with the template identifier +
version? Except the case when you'd like to share the data with another
system and you'd like to make sure the reference range is carried over to
that system.
Please expand on your claims based on specific cases, at least in response
to the point I made in the few lines above this one


>
>
> You'd have to
>
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20180228/74e02c4c/attachment.html>


More information about the openEHR-clinical mailing list