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.be...@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@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > clinical_lists.openehr.org >
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
