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 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 > > > > -- ___________________________________________________________________________________ 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
