Pathology requirements TEXTURAL RESULTS TO QUANTITIES
Thomas My approach to this, which is expressed in the editor, is to standardise only on the base and maximum values of the ordinal. The terms that are used are not an issue and standardisation is really way beyond scope when people use all sorts of terms for this purpose. Apgar is a classic - 0,1,2 is quite clear - how these points are described varies enormously - but that is OK. Nurses may want something different than doctors - for example. It is the tightly defined context that is important and the fact that it is ordered. This does allow comparisons and normal values to be determined. So, Urinalysis - NORMAL can be something that an archetype can express. Blood = 0, Protein = 0 ... You are always worried about the non-standardisation but we do not need it in this world to make interoperability a reality - ordinal values are, on the whole, too gross for a great deal of concern. Reflex of +/- can be normal if the person is healthy and the finding is consistent. Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Thomas Beale Sent: Friday, 24 October 2003 6:22 PM To: Openehr-Technical Subject: Re: Pathology requirements TEXTURAL RESULTS TO QUANTITIES Tim Churches wrote: Sam Heard sam.heard at bigpond.com wrote: TEXTURAL RESULTS TO QUANTITIES ?TEXTUAL? This raises the general issue of how mixed categorical/ordinal/scalar quantities are handled eg (made up example) haematuria: Trace-x RBC/ml - Gross haematuria. Conceivably some use might be made of the numbers, as opposed to the ordinal categorical extrema? The current DV_ORDINAL data type consists of an integer value representing the ordinal position in a range of values, and a symbol, which is the symbol given to that position. Ordinals are treated as being comparable ( operator is defined) but not quantified (the magnitude is unknown). We currently think that the correct way to express the symbol is as a term in a vocabulary (maybe subsetted). This means that each set of symbols comes from its own micro-vocabulary, and even if the same symbols (like trace, +, ++) are used for unrelated things, they cannot get mixed up in comparisons. Examles: pain: Value Symbol 1+ 2++ 3+++ reflex Value Symbol 1+ 2++ 3+++ haemolysed blood in urinalysis 1 ?neg? 2 ?trace? 3 ?small? 4 ?moderate? 5 ?large? OR - haemolysed blood in urinalysis (unit=cells/ml) 1 ?neg? 2 ?trace (10) 3 ?small (25) 4 ?moderate (80) 5 ?large (200) I am not sure if we need more sophistication to deal with this. The main problem I see is the lack of vocabularies, and/or non-standardisation of them. I guess LOINC has the kinds of values we want, but how to specify the correct subsets? - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
FW: Re: Pathology requirements TEXTURAL RESULTS TO QUANTITIES
-Original Message- From: Sam Heard [mailto:sam.he...@bigpond.com] Sent: Friday, 24 October 2003 11:00 AM To: Tim Churches Subject: RE: Re: Pathology requirements TEXTURAL RESULTS TO QUANTITIES Tim As we seek to achieve automatic processing of some of the data in the EHR there will be clear efficiencies in changing some conventions. For instance, RBC/HPF = 0 is very easy to understand. They are not usually 'seen' anyway any more so why pretend. What I was getting at is when a numeric response is there - but wrong - and a textural entry replaces the quantity - as in 'haemolysed'. I am proposing that the archetype node to do this is not the same as the quantity - so it would replace it. It would then not come back in queries looking for K+ levels. Tom and I have thought about ranges as fuzzy quantities e.g. 100 or 0.5 - these are possible in all analytes in practice but rarely met. Thanks, Sam -Original Message- From: owner-openehr-technical at openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Tim Churches Sent: Thursday, 23 October 2003 4:55 PM To: Tim Churches Cc: Sam Heard; Openehr-Technical Subject: Re: Re: Pathology requirements TEXTURAL RESULTS TO QUANTITIES Tim Churches tchur at optushome.com.au wrote: Sam Heard sam.heard at bigpond.com wrote: TEXTURAL RESULTS TO QUANTITIES ?TEXTUAL? This raises the general issue of how mixed categorical/ordinal/scalar quantities are handled eg (made up example) haematuria: Trace-x RBC/ml - Gross haematuria. Sorry, brain-fade. I meant x RBC/HPF (per high power field) or similar. This is an example of a sampled result i.e. a random sample of portions of a specimen are examined and a mean is reported. The mean is quantitative, but is just a point estimate of the central tendency of an underlying probability density function. Thus it may have a std dev or confidence intervals associated with it. Also, in this circumstance zero doesn't really mean zero and is generally not reported as such: if no RBC were seen in any HPF, then it will be reported as No RBC seen, not as mean RBC/HPF = 0. Generalising this, scalars which parameterise a probability distribution are different from scalars which are precise quantities - or are they? Hmmm. Tim C Conceivably some use might be made of the numbers, as opposed to the ordinal categorical extrema? Tim C - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TEXTURAL RESULTS TO QUANTITIES
I think the fact that some results are a mean calculated by a human is a red-herring. In fact nearly all numerical analyte values from automated machines are a mean of a number of estimates - part of the internal quality control is that the standard deviation of these estimates is acceptable - this is just hidden under the hood. Some systems certainly record a value of 0, instead of, or in a addition to, zero RBC per HPF. How many HPF's are examined and acceptable values for the SD when done manually are all part of the analysis technique used and not generally stored in the patients paper record, let alone EHR. Regards Vince Vincent McCauley MB BS, Ph.D - Original Message - From: Tim Churches tc...@optushome.com.au To: Tim Churches tchur at optushome.com.au Cc: Sam Heard sam.heard at bigpond.com; Openehr-Technical openehr-technical at openehr.org Sent: Thursday, October 23, 2003 17:25 Subject: Re: Re: Pathology requirements TEXTURAL RESULTS TO QUANTITIES Tim Churches tchur at optushome.com.au wrote: Sam Heard sam.heard at bigpond.com wrote: TEXTURAL RESULTS TO QUANTITIES ?TEXTUAL? This raises the general issue of how mixed categorical/ordinal/scalar quantities are handled eg (made up example) haematuria: Trace-x RBC/ml - Gross haematuria. Sorry, brain-fade. I meant x RBC/HPF (per high power field) or similar. This is an example of a sampled result i.e. a random sample of portions of a specimen are examined and a mean is reported. The mean is quantitative, but is just a point estimate of the central tendency of an underlying probability density function. Thus it may have a std dev or confidence intervals associated with it. Also, in this circumstance zero doesn't really mean zero and is generally not reported as such: if no RBC were seen in any HPF, then it will be reported as No RBC seen, not as mean RBC/HPF = 0. Generalising this, scalars which parameterise a probability distribution are different from scalars which are precise quantities - or are they? Hmmm. Tim C Conceivably some use might be made of the numbers, as opposed to the ordinal categorical extrema? Tim C - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TEXTURAL RESULTS TO QUANTITIES
Tim Churches wrote: Sam Heard sam.heard at bigpond.com wrote: TEXTURAL RESULTS TO QUANTITIES ?TEXTUAL? This raises the general issue of how mixed categorical/ordinal/scalar quantities are handled eg (made up example) haematuria: Trace-x RBC/ml - Gross haematuria. Conceivably some use might be made of the numbers, as opposed to the ordinal categorical extrema? The current DV_ORDINAL data type consists of an integer value representing the ordinal position in a range of values, and a symbol, which is the symbol given to that position. Ordinals are treated as being comparable ( operator is defined) but not quantified (the magnitude is unknown). We currently think that the correct way to express the symbol is as a term in a vocabulary (maybe subsetted). This means that each set of symbols comes from its own micro-vocabulary, and even if the same symbols (like trace, +, ++) are used for unrelated things, they cannot get mixed up in comparisons. Examles: pain: Value Symbol 1+ 2++ 3+++ reflex Value Symbol 1+ 2++ 3+++ haemolysed blood in urinalysis 1 ?neg? 2 ?trace? 3 ?small? 4 ?moderate? 5 ?large? OR - haemolysed blood in urinalysis (unit=cells/ml) 1 ?neg? 2 ?trace (10) 3 ?small (25) 4 ?moderate (80) 5 ?large (200) I am not sure if we need more sophistication to deal with this. The main problem I see is the lack of vocabularies, and/or non-standardisation of them. I guess LOINC has the kinds of values we want, but how to specify the correct subsets? - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Pathology requirements TEXTURAL RESULTS TO QUANTITIES
TEXTURAL RESULTS TO QUANTITIES The result of this analysis is that sometimes a single leaf in a tree will be reported as haemolysed rather than its numeric value - example: the results of an electrolyte measurement might have safe results for all analytes apart from potassium - the result will be 'haemolysed'. This can occur in haematology and other situations - reporting is required for medicolegal and billing purposes. This presents a problem. We have a number of possibilities at our fingertips - perhaps the most important being the ability to mark something as unsafe for automatic processing. At the moment, I believe, this is limited to the ENTRY. If we take the CDA line of structured data and display - this would mean the display said haemolysed, the data would say 9.5 mmol/L but it would be marked as unsafe for automatic processing. The query would have to check the automatic processing flag - but this will be necessary anyway - but it will lead to a differential between the view provided in the display and the query. My belief is that results that are incorrect should not be there if at all possible - so I would like to see a means of being able to put the potassium in as haemolysed. This would mean a generic node with an ID that could have a textural term data type in biochemistry - and still have the text and even the LOINC code attached - but have a different nodeID so it would not be returned in the query - unless you were just searching on LOINC codes independent of the archetype. This will look a little clunky in the archetype itself and I will need to discuss the technical issues with Thomas. Cheers, Sam Dr Sam Heard Ocean Informatics, openEHR Co-Chair, EHR-SIG, HL7 Chair EHR IT-14-9-2, Standards Australia Hon. Senior Research Fellow, UCL, London 105 Rapid Creek Rd Rapid Creek NT 0810 Ph: +61 417 838 808 sam.heard at bigpond.com www.openEHR.org www.HL7.org __ - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
