I see DV_ORDERED can optionally have specified normal and other ranges.
While the other ranges are said to be dependant on the measuring context.
normal range it seems to me, coud be defined as allways the same?
I'm thinking about laboratory resullts.
Anyway, is there a way to define this ranges in Archetypes?
Or should a decission support module be responsible for this?
thank you
The normal range is often dependent on patient age and sex and sometimes on
other patient state context
(especially for hormone levels) e.g pregnant, pre/peri/post menopausal, day
of menstrual cycle
etc
Regards
Vince
Dr Vincent McCauley
Thank you Vincent for your help, these are clinical issues I do not master at all as you can see.
In any case, should this information not be included in archetypes?
I understand that ranges depend on context but variables defining this context are probably know before actual information is submited to a system.
thank you again
Vincent McCauley wrote:
Hi Rodrigo,
Rodrigo Filgueira wrote:
I see DV_ORDERED can optionally have specified normal and other ranges.
While the other ranges are said to be dependant on the measuring context.
normal range it seems to me, coud be defined as allways the same?
not sure what you mean here.
I'm thinking about laboratory resullts.
Anyway, is there a way to define this ranges in Archetypes?
technically there is nothing stopping it, but it would almost always be
the wrong thing to do, since the normal range of a Quantity is there to
carry the actual normal range for the particular analyte in question,
for the lab, and for the patient. So if it is serum sodium, the range
will still depend on all of these things, and cannot be archetyped. The
intention is not to use archetypes to standardise these values, but to
provide a place for labs to put the specific normal range values that
applied for each analyte, for the particular patient, and remembering
that each lab has slightly different instrument settings.
Probably what you are looking for is the normal range reference data -
like what you see in a pathology book, or what any physician knows for
all of the main vital signs and other measurable things. We consider
this to be reference information, like terminology, but for quantified
values. While much of it is published in paper form, as far as I know
there is no recognised way to represent quantitative range data in a
standard computable form (i.e. in the way that you can get Snomed or
ICD10 in a computable format). This is needed. But archetypes are not
the place to standardise this - archetypes are about defining content
structures, not domain reference knowledge.
- thomas beale
Hi,
My personal thoughts.
In general the normal range is dependent on the type of lab method and specific lab and valid in a particular context (male, female, old, young, time, etc)
So the information can be provided by the lab only. They know (should know) what all the normal ranges in all relevant contexts are.
Of course for the purpose of providing lab results archetypes will be produced.
In these lab-reporting archetypes there must be a spot where this type of information can be provided.
IT techies think many times that absolute figures are very important.
In general trends provide more useful information than single absolute figures
Gerard
– –
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252 544896
M: +31 653 108732
– work –
Gerard Freriks, arts
TNO ICT
Brassersplein 2
Delft, the Netherlands
T: +31 15 2857105
M: +31 653 108732
Dear All,
Pathologists and laboratory message standards developers have over many years made clear to me that it is always good practice to include the applicable normal range with individual instances of observed values, since those ranges are not fixed across measurement methods, devices, organisations or over time. Published reference ranges in clinical textbooks etc. are only a guide for those tests in which the variation is nowadays quite small.
For this reason, right from Synapses days - a decade ago! - , we have not sought to put reference ranges into the archetype specification, but (as Tom has stated) only to ensure that the archetype caters for the inclusion of reference range instances along with the observed value(s).
With best wishes,
Dipak
Dipak Kalra wrote:
Thank you all for your answers.
It’s clear to me that Archetypes are not the place.
And that openEHR does not offer any particular solution. But since we are developing a system which should provide alerts and messaging for abnormal results and “dangerous” combinations of data values, we need to solve it in some way. Any links or reference material on possible approaches to this issue would be very welcome.
thank you all again
Dipak Kalra wrote:
Rodrigo,
I am jumping in late in the
The DV_QUANTITY (or technically the DV_ORDERED abstract class) data type represents the reference range specified by the lab using the the normal_range relationship. There is also other_reference_ranges to represent all possible reference range differentiated by various patient context such as pregnant female, etc. The normal_range is used for the range that is applicable to this subject.
The is_normal method in DV_ORDERED allows it to compare the actual quantified magnitude with the normal range and return an indicate that it is normal or not. You can use this to raise your alert of abnormal results when is_normal returns false.
The XML schema published with openEHR Release 1 actually went one step further and I believe it is a necessary addition to the reference model. It treats is_normal as an attribute and allows you to optionally specify the value of is_normal rather than it being calculated. This is useful when transforming HL7 Lab data into openEHR and Pathologists seem to not like downstream manipulation and interpretation of raw data in case the original data is mis-interpreted. This has lead to particular best-practice in Australia where lab data provided in atomic form also needs to have a full text report included along with the atomic data which should be used for display and audit purposes.
Even though openEHR support an indicator for is_normal this still stops short of lab data provided in HL7 messages. The abnormal flag in HL7 lab results is coded with values such as L, H, LL, HH, N, A, AA, etc indicating more than not normal but which direction and the degree of abnormality. When transforming this source data into openEHR we loose this additional information about abnormality.
I would suggest that there needs to be an additional attribute on DV_ORDERED that represents this interpretation of abnormality. By providing this new abnormality code attribute the is_normal can remain as a method and additional guidance can be provided for that method to derive its value from the abnormality code attribute value if it exists otherwise compare the quantified magnitude with the normal range.
Regards
Heath
Heath Frankel
Senior Interoperability Consultant
Ocean Informatics
Ground Floor, 64 Hindmarsh Square
Adelaide, SA, 5000
Australia
ph: +61 (0)8 8223 3075
fax: +61 (0)8 8223 2570
mb: +61 (0)412 030 741
email: heath.frankel@oceaninformatics.biz
Heath Frankel wrote:
Rodrigo,
I am jumping in late in the
The DV_QUANTITY (or technically the DV_ORDERED abstract class) data
type represents the reference range specified by the lab using the the
normal_range relationship. There is also other_reference_ranges to
represent all possible reference range differentiated by various
patient context such as pregnant female, etc. The normal_range is
used for the range that is applicable to this subject.The is_normal method in DV_ORDERED allows it to compare the
actual quantified magnitude with the normal range and return an
indicate that it is normal or not. You can use this to raise your
alert of abnormal results when is_normal returns false.The XML schema published with openEHR Release 1 actually went one step
further and I believe it is a necessary addition to the reference
model. It treats is_normal as an attribute and allows you to
optionally specify the value of is_normal rather than it being calculated.
This is useful when transforming HL7 Lab data into openEHR and
Pathologists seem to not like downstream manipulation and
interpretation of raw data in case the original data is
mis-interpreted. This has lead to particular best-practice in
Australia where lab data provided in atomic form also needs to have a
full text report included along with the atomic data which should be
used for display and audit purposes.Even though openEHR support an indicator for is_normal this still
stops short of lab data provided in HL7 messages. The abnormal flag
in HL7 lab results is coded with values such as L, H, LL, HH, N, A,
AA, etc indicating more than not normal but which direction and the
degree of abnormality. When transforming this source data into
openEHR we loose this additional information about abnormality.
Heath,
the obvious question here is: how standardised are these letters and
their meanings? Can we assume that all labs the attach "HH" to a serum
sodium mean that the value is in the same sub-range? If not, this kind
of data is not useful for longitudinal queries into the EHR, since a
query for serum sodium with "HH" normal indicator would not have a
consistent meaning or result.
If standards don't exist for these flags, then they would need to be
created - you can imagine that for the hundreds of pathology tests
possible, defining the subranges corresponding to L, H, LL, etc would be
a huge amount of work! And current normal ranges are getting revised all
the time anyway (people getting taller, heavier, etc).
I take the point that physicians don't in general want to see data from
the lab removed, but I would like to hear from pathologists & physicians
on how they would see this kind of thing being used, standardised, and
working in a longitudinal record whose contents are derived from all
over the place.
- thomas
So, it appears that we have no pathologists on the list to comment on the
standardisation of these codes. I guess all I can suggest is that these are
standard codes as per the HL7 V2.x standard but the interpretation of using
them is unlikely to be but it is just that we are looking the capture and
not loose in the translation from HL7 message to openEHR. Having said that,
in Australia it is common practice by labs to use three levels of
abnormality (i.e. HHH & LLL(.
Would an alternate approach be to include an additional element in the
Archetype to store this abnormality flag rather than including it in the
DV_ORDERED?
Heath
Hi Heath,
Whilst I may not be a pathologist I am a Medical Practitioner and
have at least 10 years experience in developing and marketing pathology
laboratory information systems.
In the Australian context , laboratories have 3 approaches:
1. A single tier approach - define just a normal range
2. A two tier approach (probably the most common)
- Define a critical as well as normal range - the critical range
is usually only set up for a small subset of analytes where
urgent action may be required for grossly abnormal values.
A typical example would be serum potassium where a normal range of 3.5 - 5.5
would be typical and a critical range of > 6.5 would be defined, as above
that level there
is a significant risk of cardiac arrhythmias.
Critical results are usually messaged in HL7 as HHH,LLL
3. A 3 tier approach - Define a mildly abnormal (but possibly not clinically
significant) range messaged as H, L
Define a significantly abnormal range messaged as HH, LL
Define a critical range (requires urgent intervention) messaged as HHH, LLL
What action should flow from even critical results depends on the clinical
context.
A total CPK (marker of muscle damage) flagged as critically elevated will
require different responses
in a patient who has just had an intramuscular injection from that in a
patient with chest pain.
It may be useful to provide specific support for this in OpenEHR so that not
only can the result be flagged as abnormal
but an indication of how abnormal. Care would need to be exercised in using
these flags in decision support and workflow
systems and it may be appropriate to have associated flags to indicate the
clinical significance of the result. This data
would generally not be supplied by the laboratory but rather the attending
physician.
Regards
Vince
Dr Vincent McCauley
Hi,
I’m not a pathologist.
But was a GP.
As GP I’m not interested in an arbitrary classification.
What is minimally necessary are: the value, the units of measurement and the normal range as used in that lab for that measurement at that time.
What is handy (optional) and only for signalling a human reader, and NOT for computer semantic processing, are: a Flag that a value is out of range, and a comment/advice/interpretation provided by the lab.
“Value” is not always a series of digits. It can be an ordinal. It can be text.
Gerard
– –
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
T: +31 252 544896
M: +31 653 108732
2006/9/20, Gerard Freriks <gfrer@luna.nl>:
Hi,
I’m not a pathologist.
But was a GP.As GP I’m not interested in an arbitrary classification.
What is minimally necessary are: the value, the units of measurement and the normal range as used in that lab for that measurement at that time.
What is handy (optional) and only for signalling a human reader, and NOT for computer semantic processing, are: a Flag that a value is out of range, and a comment/advice/interpretation provided by the lab.
What about decision support software?
/Mattias
GNUmed uses two flags to account for that:
technically_abnormal
clinically_relevant
Karsten