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" <[email protected]> To: "'For openEHR technical discussions'" <openehr-technical at openehr.org> 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 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
