Normal and other ranges

[Rodrigo Filgueira]

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

Normal and other ranges

[Vincent McCauley]

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

- Original Message - 
From: "Rodrigo Filgueira" 
To: ; 
Sent: Sunday, August 27, 2006 6:19 AM
Subject: Normal and other ranges


> 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
>
>

Normal and other ranges

[Rodrigo Filgueira]

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:

>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
>
>- Original Message - 
>From: "Rodrigo Filgueira" 
>To: ; 
>Sent: Sunday, August 27, 2006 6:19 AM
>Subject: Normal and other ranges
>
>
>  
>
>>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
>>
>>
>>
>>
>
>
>___
>openEHR-technical mailing list
>openEHR-technical at openehr.org
>http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>  
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060828/b7c3e9fd/attachment.html>

Normal and other ranges

[Thomas Beale]

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
> Or should a decission support module be responsible for this?
>
> thank you
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>   


-- 
___
CTO Ocean Informatics (http://www.OceanInformatics.biz)
Research Fellow, University College London (http://www.chime.ucl.ac.uk)
Chair Architectural Review Board, openEHR (http://www.openEHR.org)

Normal and other ranges

[Gerard Freriks]

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

Gerard.Freriks at TNO.nl





On 31-aug-2006, at 19:20, Thomas Beale wrote:

>>
> 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

-- next part --
An HTML attachment was scrubbed...
URL: 

Normal and other ranges

[Hans J Haase]

Dipak Kalra wrote:
> 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
> 
> Dr Dipak Kalra
> Clinical Senior Lecturer in Health Informatics
> CHIME, University College London
> Holborn Union Building, Highgate Hill, London N19 5LW
> Direct Line: +44-20-7288-3362
> Fax: +44-20-7288-3322
> Web site: http://www.chime.ucl.ac.uk 
> 
> 
> 

Normal and other ranges

[Rodrigo Filgueira]

An HTML attachment was scrubbed...
URL: 

Normal and other ranges

[Heath Frankel]

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:  <mailto:heath.frankel at oceaninformatics.biz>
heath.frankel at oceaninformatics.biz 


  _  

From: owner-openehr-techni...@openehr.org
[mailto:owner-openehr-technical at openehr.org] On Behalf Of Rodrigo Filgueira
Sent: Thursday, 7 September 2006 5:19 AM
To: openehr-technical at openehr.org
Subject: Re: Normal and other ranges


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:


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

Dr Dipak Kalra
Clinical Senior Lecturer in Health Informatics
CHIME, University College London
Holborn Union Building, Highgate Hill, London N19 5LW
Direct Line: +44-20-7288-3362
Fax: +44-20-7288-3322
Web site:  <http://www.chime.ucl.ac.uk/> http://www.chime.ucl.ac.uk





  _  


___

openEHR-technical mailing list

openEHR-technical at openehr.org

http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

  

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060907/0d8fb7f1/attachment.html>

Normal and other ranges

[Thomas Beale]

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

Normal and other ranges

[Heath Frankel]

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 

-Original Message-
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Sunday, 10 September 2006 12:32 AM
To: For openEHR technical discussions
Subject: Re: Normal and other ranges

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


___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Normal and other ranges

[Vincent McCauley]

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

- Original Message - 
From: "Heath Frankel" 
To: "'For openEHR technical discussions'" 
Sent: Wednesday, September 20, 2006 8:27 AM
Subject: RE: Normal and other ranges


> 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
>
> -Original Message-
> From: openehr-technical-bounces at openehr.org
> [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
> Sent: Sunday, 10 September 2006 12:32 AM
> To: For openEHR technical discussions
> Subject: Re: Normal and other ranges
>
> 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 

Normal and other ranges

[Gerard Freriks]

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



On 20-sep-2006, at 0:27, Heath Frankel wrote:

> 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?

-- next part --
An HTML attachment was scrubbed...
URL: 

Normal and other ranges

[Mattias Forss]

2006/9/20, Gerard Freriks :
>
> 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

"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
>
>
>
>
> On 20-sep-2006, at 0:27, Heath Frankel wrote:
>
> 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?
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

Normal and other ranges

[Karsten Hilbert]

On Wed, Sep 20, 2006 at 11:08:10AM +1000, Vincent McCauley wrote:

> 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.

GNUmed uses two flags to account for that:

technically_abnormal
clinically_relevant


Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Normal and other ranges

[Dipak Kalra]

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

Dr Dipak Kalra
Clinical Senior Lecturer in Health Informatics
CHIME, University College London
Holborn Union Building, Highgate Hill, London N19 5LW
Direct Line: +44-20-7288-3362
Fax: +44-20-7288-3322
Web site: http://www.chime.ucl.ac.uk



-- next part --
An HTML attachment was scrubbed...
URL: