This wiki has undergone a migration to Confluence found Here
An e-mail thread
Jump to navigation
Jump to search
-----Original Message-----
From: owner-openehr-technical@openehr.org [mailto:owner-openehr-
technical@openehr.org] On Behalf Of Philippe AMELINE
Sent: Sunday, April 10, 2005 10:05 AM
To: openehr-technical@openehr.org
Subject: Re: Flavour of null
Hi to all,
This is fine, and I immediateley start adding these concepts to Odyssee's ontology, with the proper
IS A relationships.
However, I would put the "reasons for null" as childs (and not brothers) of the "flavour of null",
since these reasons may vary depending from the flavour, for example you cannot have "Result out
of Valid Range" because "Lost the Sample". Furthermore, the "flavours of null" and the valid
"reasons for it" are very dependant from the so-qualified information.
For example, if you expect the left ventricular ejection ratio measured from echocardiography
instead of a lab result, you probably will provide specific flavors of null with accurate reasons
for it (for example patient's obesity leading to bad quality exam).In Odyssee, we can do it
with Fils guides.
However, the genuine hard task is in the interface side : where there was just an "edit field"
waiting for a numerical value (and its unit), we must provide the ability to enter descriptive items.
Cheers,
Philippe
Elkin, Peter L., M.D. wrote:
>Very sensible. I agree.
>
>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@openehr.org
>[mailto:owner-openehr-technical@openehr.org] On Behalf Of Thomas Beale
>Sent: Sunday, April 10, 2005 3:46 AM
>To: openehr-technical@openehr.org
>Subject: Re: Flavour of null
>
>Elkin, Peter L., M.D. wrote:
>
>
>
>>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.
>>
>>
>>
>>
>Peter,
>I think if we go that way, we need to recognise that the
>reason_for_null won't be a single vocabulary - it will be many. The
>values you give are all pathology related; but I can imagine a
>vocabulary set that deals with psychiatric interviews (when patients
>may be refusing or failing to provide answers for a whole variety of
>reasons), with general contacts (when a patient just can't remember family history events),
and so on.
>
>Then there is the question of whether the reason_for_null should be a
>second field next to the flavour of null (in openEHR - in ELEMENT), or
>only occur in archetyped information structures where it makes sense
>(on the assumption that there is no reason_for_null vocabulary a lot of
>the time). We are currently working on the latter assumption, but
>someone may be able to prove that it should be otherwise.
>
>I think it all comes down to two things:
>- what is flavour of null/reason for null used for (i.e. what queries
>does it satisfy)
>- what is the generality of any particular solution?
>
>I suspect that the best approach in a better world would be to have a
>more powerful ontology, e.g. one in which many small reason_for_null
>vocabularies have IS-A relationships with more general null terms like
>those in your first list. However, I doubt if this is generally
>available in a practical sense for the time being.
>
>- thomas
>
>
>- thomas
>
>
>
>>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@openehr.org
>>[mailto:owner-openehr-technical@openehr.org] On Behalf Of Sam Heard
>>Sent: Saturday, April 09, 2005 5:56 PM
>>To: openehr-technical@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
