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 < serefari...@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.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-clini...@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_ >> lists.openehr.org >> > >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
