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.
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?
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.
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.
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.
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.
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?
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.
This is one way of doing it and is appropriate in a fixed DB schema. I had
not thought of using the 'flavour of null' approach. Importantly, we can
archetype these so we could put the valid reasons why a result was not
there. It would also mean we could insist that there was a leaf for each
value of a test if that was deemed appropriate.
I had thought of using this for BPs that were not measurable.