Sam,
By way of a friendly amendment, I would say that the Information Model of Null
should include both the type of Null and separately the reason for it being
Null as separate attributes (employing an Ontology of Null). I agree that Null
should be part of the Information Model explicitly rather than a datatype. For
Example:
Null
Unknown
Not available
Not evaluated
Insufficient Information
Result out of Valid Range
Testing yielded no value
Reason_for_Null
Lost the Sample
Specimen destroyed
Sample Hemolyzed
Sample Lipemic
Sample too long in transport
Specimen Clotted
Machine Error
Human Error
Etc.
Warm regards,
Peter
Peter L. Elkin, MD
Professor of Medicine
Director, Laboratory of Biomedical Informatics
Department of Internal Medicine
Mayo Clinic, College of Medicine
Mayo Clinic, Rochester
(507) 284-1551
Fax: (507) 284-5370
-----Original Message-----
From: owner-openehr-technical at openehr.org
[mailto:[email protected]] On Behalf Of Sam Heard
Sent: Saturday, April 09, 2005 5:56 PM
To: openehr-technical at openehr.org
Subject: Re: Flavour of null
Dear All
OK, I was just checking to see where the detailed reason for a result
being NULL should be and am happy to build this into the laboratory
archetype in the way Graham suggests, and to leave the generic Flavour
of NULL as Tom thinks.
Cheers, Sam
> Grahame Grieve wrote:
>
>> Hi Sam
>>
>> I've discussed this particular case at HL7 before, but I don't
>> remember whether any answer was agreed. But to me, this case
>> needs to be coded - there's a fairly small set of reasons why
>> the laboratory would report that an answer was not available,
>> and the reasons themselves may have meaning
>>
>> I advance this small hierarchical vocab:
>>
>> + NS - not suitable
>> + HM - haemolysed
>> + HM1
>> + HM2 { rating for how haemolysed
>> + HM3 { ? maybe a seperate element
>> + HM4
>> + LP - lipeamic
>> + LP1
>> + LP2 { rating for how lipaemic
>> + LP3 { ? maybe a seperate element
>> + LP4
>> + WP - wrong preservative
>> + INS - insufficient sample
>> + ERR - handling error
>> + AGE - too long to deliver to lab or other delivery problem
>> + LACC - laboratory accident
>> + FAIL - specimen could not be analysed for
>> technical reasons that were not accidental
>>
>> I may have missed some heam and micro specific reasons - I
>> worked in the core lab.
>>
>> Some Australian laboratories are reporting meaningless
>> numbers and then reporting the error as a comment, rather
>> than reporting a null value - so they can be paid. In spite
>> of my strong clinical objection to this practice, this
>> suggests that this isn't a null-flavour issue, and indeed,
>> for lipaemic samples, except for a few analytes, I used to
>> report the numbers and just note that the numbers were
>> lower because of the volume effects.
>>
>> So I think that this is a "laboratory quality indicator"
>> that is a separate element to the actual value, since
>> there is various cases where you'd want to report both - and
>> I think this is worth modelling in the base pathology result
>> archetype.
>
> I agree 100% - I don't see this as a flavour of null problem, because
> flavour of null is/should be about:
> - inability to provide a value to the computer system at runtime. A
> possible value set I have proposed in the past:
>
> * *no information*: No information provided; nothing can be inferred
> as to the reason why, including whether there might be a possible
> applicable value or not
> * *not available* (unknown): A possible value exists but is not
> provided (ask user)
> * *masked*: The value has not been provided due to privacy settings
> (settable by extract / message serialiser)
> * *not applicable*: No valid value exists for this data item in this
> context (should be knowable by application)
>
> This value set works for all contexts, is independent of setting, and (I
> believe) should be settable by software. I have my doubts as to whether
> there is any milage in having the first two distinct.
>
> In any case, this idea of null value is only partly the same as the use
> case here. In the lab situation, some information items are not
> available, so you could set the null flavour to "not available", but the
> actual reasons for this are specific to the setting and the test.
> Clearly we cannot have a single vocabulary for flavour-of-null which
> rolls in the value sets of all the possible flavours-of-null for all
> settings, tests etc, such as the one Grahame has used above.
>
> One solution initially appears to be to allow the flavour of null
> vocabulary itself to be settable (i.e. that in archetypes you could set
> a different flavour of null vocabulary depending on the field), but this
> is flawed, since we still want a generic flavour of null value (e.g. one
> of the 4 above), so that querying can work properly. So we either need
> two flavour of null values for each value field - one generic, one
> specific to setting & context - which seems somewhat excessive, or we
> need to regard the specific "flavour of null" as something else,
> probably something like a lab quality indicator as Grahame suggests. I
> agree that pathology archetypes should probably include such indicators
> explicitly in their model of data.
>
> - thomas beale
>
>>
>> Grahame
>>
>> Sam Heard wrote:
>>
>>> Dear All
>>>
>>> A reminder on why flavour of null is at the ELEMENT level: it allows
>>> a composition with mandatory data to be saved even if the data is not
>>> available, or allows a reason to be stated for data that is missing.
>>> It also allows us to deal with the HL7 flavour of null on the data
>>> types.
>>>
>>> I am concerned that the flavour of null is set to DV_CODED_TEXT and
>>> not DV_TEXT (ie. it has to be coded from a terminology). I agree that
>>> some systems will want things coded for safety in some situations,
>>> but I believe that this should be handled through archetypes and
>>> templates.
>>>
>>> Laboratories will want to use this for all sorts of reasons, one
>>> clear example is when an electrolyte sample has haemolysed - and they
>>> cannot give a potassium reading (they do not want to omit it!)
>>>
>>> So I want to propose that the flavour of null is set to DV_TEXT.
>>>
>>> Cheers
>>> Sam Heard
>>> -
>>> If you have any questions about using this list,
>>> please send a message to d.lloyd at openehr.org
>>
>
>
> --
> ___________________________________________________________________________________
> Research Fellow, University College London (http://www.chime.ucl.ac.uk)
> Chair Architectural Review Board, openEHR (http://www.openEHR.org)
> CTO Ocean Informatics (http://www.OceanInformatics.biz)
>
> - 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
