Confidence indicator [was Flavour of null]
Hi Koray, Don't you think that "Null" is not a singularity (I mean an isolated point), but the extreme value of a linear cursor we could name "validity" or "confidence". To give a matter of fact example, I could say that : I can provide a value without any comment : I am confident in the quality level of the measurement process I can provide a value saying that an average (or poor) level of quality must be noticed when using this information I can decide not to provide a value and explain why This is close from error bars in scientific papers ; I don't mean you must provide a calculated accuracy level (it is usually not possible), but that when an information was not obtained with the usual level of precision, it should always be noticed. For example, some calculated values use measured value power 3 - you can imagine how errors are raised at a high level. So, maybe we should always provide room for a validity indicator (that would become the list of reasons for null when "flavours of null" replace the asked value). Cheers, Philippe >So my proposal in short is: >1) Examine the possible data values to be expected in a particular field: If >can be solved with a simple True/False then assign a bit. >2) If not then employ the "Essential Flavours of Null" which should appear >as a separate Data Type I believe >3) If extra contextual information is needed at the time of design or will >probably be needed in future (This requires a careful study by taking into >consideration all viewpoints: legal, epidemiological and etc.) then assign >"Knowledge-Enabled Contextual Archetype Plug-Ins" and provide mappings to >the essential ones. > >That is my "simple" solution proposal that I had been deeply thinking on for >some years! > >Best regards, > >Dr. Koray Atalag >METU Informatics Institute >Ph.D. Candidate on Information Systems > > > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
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 at openehr.org [mailto:owner-openehr-technical
>at openehr.org] 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 propo
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 at openehr.org [mailto:owner-openehr-technical >at openehr.org] On Behalf Of Thomas Beale >Sent: Sunday, April 10, 2005 3:46 AM >To: openehr-technical at 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 at openehr.org [mailto:owner-openehr-technical >>at openehr.org] 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 themselv
Flavour of null
Dear All, I had been pretty busy with an ambitious EU FP6 Project Proposal which is related with my thesis work as most of you are also aware of: CEREBRUS which we were not able to finish till the deadline at March 22. But we decided to move on and wait for next calls and look for other opportunities of funding/support. Even the proposal activity is Open Source and at SF.NET: http://cerebrus-fp6.sourceforge.net All these messages about "Flavours of Null" are indeed very useful solution proposals I think pointing out to the very fact that the "Null" is not that "easy" entity to handle...Apart from examples in clinical LAB and quality measures (I think in US CLIA 88 regulations) there are many other contexts that is paradigm is a real problem: such as the Bethesda System 2001 in cervical smear reporting. I had been working on this since 2001 and in fact developed many working information systems (Freely available as opensource from SF.NET: http://sourceforge.net/projects/pathos-web/ ) I think we should not add too many meanings/information/pre-information/contextual information to a single entity, and we had better separate the levels of: A) data B) information C) knowledge in approaching the problem of "NULL"... In order to make "sensible", really "implementable" and "user-friendly" systems in mind, the approach to the problem has to be restated as below and possibly be formulated in a methodology and solved as with my proposal: Problem statement and intial analysis from a historical perspective: 1) From a computational point of view: We should evaluate if if makes any "sense" to a computational/information system whether all the additional "contextual/information/knowledge" level attributes are of any use or change the "result/response" expected from it; i.e. The current "digital" or I should say "binary" computers do not understand at the lowest level the null. It is either "present/positive/one" or "absent/negative/zero". That is why in all early programming and database systems the data type "boolean/bit" is modelled and it is very useful for many systems in many domains. 2) As the informatics science is evolved, the real systems had to incorporate "empty/null" aspects of data...Then two bits are appended to incorporate this "more than 1 bit" of information and in many cases it is not needed and 1 bit is lost for nothing; more memory, more storage and etc. Even the Y2K problem originated from such an approach. This is str?ngly related with "Fuzzy Systems" and there is vast amount of research and solutions as far as I know. I think at the end we will probably need to change the very architecture of our computer systems and storage techologies so as to handle this: 3 state and continous/near analogue processors and storage schemes. 3) In complex domains such as clinical medicine, then we are also adding the "Flavours of Null" and now considering to incorporate into the very heart of our models: the Data Types...If this happens then we will be spending a whole lot of our memory/storage and eventually processing performance of our "next-generation" systems as the Americans did with their cars back at the 60s... Methodology: 1) Analyse the data values expected to be encountered: if it is mostly 0/1, Yes/No, True/False, Positive/Negative then do not bother with flavours of Null and use the "good-old" technique and spend 1 bit. 2) If there is a need to put more information to the value (information/context) Then start with the "essential" flavours of null - the true natural features, not the ones we the human kind created to make this complex world even more complicated! These are in fact the "context and domain" free aspects of being "Null" or "Empty" as Grahame Grieve pointed out in his nice and useful message: * *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 can be further discussed and improved in a more "ICT philosophical" way I believe... 3) Put all the "non-essential" and "contextual" components via a "contextual archetype-component" as in the solution for "protocols" and employ the "knowledge" aspects; meaning which information is appropriate in that particular situation/context. So this is a Knowledge Enabled Contextual Plug-In or Add-On approach as I just propose in this beautiful Sunday morning! But they all should map to the "essential" information entities as given in Methodology 2. I would recomment that you all examine by heart how openSDE approaches this problem in its newer version developed by Erasmus team;
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.
Flavour of null
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 at openehr.org
[mailto:owner-openehr-techni...@openehr.org] On Behalf Of Thomas Beale
Sent: Sunday, April 10, 2005 3:46 AM
To: openehr-technical at 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 at openehr.org [mailto:owner-openehr-technical
>at openehr.org] 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 eff
