We are developing a completely openEHR based Personal Health Environment (PHR). For this we would like to show measured data in a graph containing “good” or “bad”. Mostly one would see some traffic light system, our approach is different but comes to the same principle.
So for this we need to set thresholds that also could be changed afterwards. In the most common BP archetype (and Template) no thresholds are defined, so at what level would we do that?
We are developing a completely openEHR based Personal Health Environment (PHR). For this we would like to show measured data in a graph containing “good” or “bad”. Mostly one would see some traffic light system, our approach is different but comes to the same principle.
So for this we need to set thresholds that also could be changed afterwards. In the most common BP archetype (and Template) no thresholds are defined, so at what level in the archetype would we do that?
This sounds like something you should handle at the application level rather than modeling level to me.
Hi
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
Jussara
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
I completely agree, but that does not “solve” my problem.. :-).
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):
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.
Ah great Thomas, many thanks. Think I need to research this a little..:-), and will come back on it later.
Hi Jan-Marc,
We implemented a similar tool a couple of years ago, the limits and goals were store in the system, not as openEHR artifacts.
Best,
Pablo.
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
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
I think there are various option (like always). One of them is to store the thresholds separately from the RM. This is in fact fairly easy, only afterwards we will not be able to execute some query like give me all patients with thresholds above whatever. Or give me all patients that are above thresholds set by themselves (or the doctor). At least not via AQL, or a single query.
Within the RM provides me series of other complexities. So that would leave me to using decisions Support. But that requires really a huge amount of work for something that looks easy.. 
Dear All,
Thinking of querying, it seems to me that it would be really useful in some contexts (e.g. population screening) to be able to issue a query that not only pulled back everyone above a threshold stated in the query, but that could also not state that, and pull out every record of a result considered at the time to have been over or under the screening threshold then in force, even if it’s since changed (or the record came from another area where a different cut-off was in force at the time)…
Yours,
Matthew
I think the functionality seeked here is a threshold to trigger some action, like an alert. The given example was BP, and as an observation archetype it only records the blood pressure, using constraints to set up only the valid values, which are 0 to maybe up 300.
The ranges are additional information that you can put to help the clinician’s evaluation, but only rules can make the computer take some action.
That is what I meant
Jussara
--------- Mensagem encaminhada ---------
Attached to each numerical value one needs several ranges that apply to the value.
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
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?
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.
Gerard Freriks
+31 620347088 <+31%206%2020347088>
gfrer@luna.nlKattensingel 20
2801 CA Gouda
the NetherlandsHi 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 WHERLeaving 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
In a clinical trial, the protocol may set thresholds for measurements in one version of the protocol, then change the thresholds in a subsequent version of the protocol. Since a decision may be based on a threshold level, the threshold value needs to be retained along with the measurement for each instance under each protocol. So I think you need a new template for each protocol.
An AQL query on the threshold level will therefore need to have a unique name for each threshold ( not a value of the threshold) in order to retrieve the value used across protocols in the decision, for a simple case where the decision algorithm does not change.
Hi Colin,
See responses inline please
I believe that we need a way in standard AQL to call to arbitrary external services, this seems like another use case for that