Setting thresholds

Seref Arikan serefarikan at
Wed Feb 28 08:44:34 EST 2018

Sorry, sent the last email accidentally before it was finished. Here is the
end bit:

...  use AQL to select above/below threshold since you can plug the
threshold value directly into WHERE clause

So I'm not sure if reference ranges would help here. Happy to be educated
if I missing something here :)

All the best

On Wed, Feb 28, 2018 at 1:42 PM, Seref Arikan <
serefarikan at> 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?
> 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
> You'd have to
> On Wed, Feb 28, 2018 at 1:17 PM, Thomas Beale <thomas.beale at>
> wrote:
>> Although Jussara is right in terms of reference ranges generally, i.e.
>> what you see in a pathology handbook as ref ranges for male / female /
>> child for say Total Cholesterol or some other analyte, the openEHR
>> Reference Model does allow reference ranges to be carried in DV_QUANTITY (see
>> here on the UML site
>> <>-
>> DV_ORDERED.normal_range and other_reference_ranges). We do this for the
>> same reasons Karsten explicates below.
>> The idea is that the normal range (and other ranges) *specific to the
>> patient type for the current test order* (sex, age, sometimes 'race',
>> e.g. African American cholesterol normal range is +10%) can be written into
>> the data. So, say the patient is a 64 yo female caucasian, and the analyte
>> is 'total cholesterol'. The ref range will be (something like):
>>    - normal range: 159-276 mg/dL or in SI, 4.12-7.15 mmol/L
>> that is just one row from a table of normal ranges keyed by sex, age and
>> with the modifier for African Americans (I have a US path manual, probably
>> it is just 'African' elsewhere).
>> The reference range data is often influenced by other factors depending
>> on what it is, e.g. location, diet, and so on.
>> The point is, that the path lab can help the doc by including the
>> relevant normal range with the measured value, and therefore also generate
>> an 'abnormal' indicator in the result. This is a significant time-saver for
>> doctors, and it also has the effect of writing into the EHR the reference
>> range that was actually used to decide that the patient was abnormal for
>> that analyte and to intervene - i.e. it's the reference knowledge for the
>> assessment.
>> - thomas
>> On 28/02/2018 12:43, Karsten Hilbert wrote:
>> On Wed, Feb 28, 2018 at 12:18:24PM +0000, Jussara Macedo Rötzsch wrote:
>> Ranges  aren’t actually part   of the Information model, they are rules for
>> decision support, and therefore belong to the Application level, like a gdl
>> based CDS
>> In practice there are still needs to store ranges (with the data):
>> 1) path labs will attach ranges to recommended interpretations
>> 	those are best stored "with" the result(-interpretation)
>> 	and, no, it is not sufficient to attach them to the test
>> 	*type* of a measurement
>> 2) ranges applied by a clinician upon which a conclusion
>>    has been made
>> 	those will often end up as textual part of a SOAP note
>> Think of a patient with warfarin monitoring: The lab will cry
>> foul (if not properly informed) but the clinician is happy
>> when the INR is in the therapeutic range.
>> GNUmed "solves" that by allowing to attach both a "nominal"
>> and a "desired" range to each test result.
>> For what that's worth.
>> Karsten
>> --
>> Thomas Beale
>> Principal, Ars Semantica <>
>> Consultant, ABD Team, Intermountain Healthcare
>> <>
>> Management Board, Specifications Program Lead, openEHR Foundation
>> <>
>> Chartered IT Professional Fellow, BCS, British Computer Society
>> <>
>> Health IT blog <> | Culture blog
>> <>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list