Setting thresholds

Seref Arikan serefarikan at kurumsalteknoloji.com
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
Seref



On Wed, Feb 28, 2018 at 1:42 PM, 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?
>
> 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 openehr.org>
> 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
>> <https://www.openehr.org/releases/trunk/UML/#Diagrams___18_1_83e026d_1433773263789_448306_5573>-
>> 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 <http://www.arssemantica.com>
>> Consultant, ABD Team, Intermountain Healthcare
>> <https://intermountainhealthcare.org/>
>> Management Board, Specifications Program Lead, openEHR Foundation
>> <http://www.openehr.org>
>> Chartered IT Professional Fellow, BCS, British Computer Society
>> <http://www.bcs.org/category/6044>
>> Health IT blog <http://wolandscat.net/> | Culture blog
>> <http://wolandsothercat.net/>
>>
>> _______________________________________________
>> 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/5619035b/attachment-0001.html>


More information about the openEHR-clinical mailing list