An outcomes measurement system I worked on had the same sort of business rules that Thomas describes - we had placeholders for "Patient unable to answer", "Patient declined to answer", etc. It depends on what you're going to do with the data, but in many cases those are distinctly different that a true null value. What I'm calling a "true null" is the situation where we know nothing about that data element. Finding out that the patient doesn't know something, or won't tell you, is a piece of information about that data element, and therefore no longer null. (My only disagreement with the idea of having "null flavors" is that I don't think that these should be called nulls in the first place.) Again, it depends on your business needs, but I tend to think that you generally want to preserve what information you have. Tyson Wright <http://www.hubbertsystems.com/>
________________________________ From: [email protected] on behalf of Thomas Beale Sent: Fri 12/7/2007 3:17 AM To: For openEHR technical discussions Subject: Re: Null Flavours, boolean values in openEHR There has now been some signficant input to the null flavours page on the openEHR wiki. Grahame Grieve, who knows the HL7 approach and use cases very well has provided some useful comments to some questions I raised. It seems germane to bring some of these back to the list. The main aim is not to establish that one or other approach is 'right' or 'wrong' but to establish that openEHR has a reasonable way of dealing with the various use cases. At the outset there is a difference of philosophy between HL7 and openEHR, exemplified by the following comment of Grahame's below. ASKU asked but unknown Information was sought but not found (e.g., patient was asked but didn't know) In openEHR, this is a legitimate response of the patient, and is not a case of missing data. See discussion above. I really don't understand that comment; the patient responded that they didn't know, so the data is missing In HL7, the idea seems to be that if a patient or other source of data was not able to respond to a question then the 'data are missing'. In the openEHR point of view, the physician is making an observation when asking questions, and the responses might be clear, muddled, mixed, or the patient might not be capable of responding. All of these are legitimate 'responses' of the patient in the clinical situation - there is no technical problem with the physician obtaining information, it is just that the information that the patient can supply can includes more than just the answers to direct questions (at least it often includes 'I don't know'). The practical result of this in openEHR is that such possible responses should be allowed in the design of patient questionnaires - it could mean modelling at least a 3-way response, with the third being a coded item indicating various kinds of 'don't know'. This approach restricts the use of such codes to where they make sense - in questionnaire style observations, rather than everywhere (clearly 'asked but unknown' can't apply to an Evaluation, or an Observation made by physical examination, by machine or in the lab - it is quite limited in scope). The consequence of modelling like this - in a way that represents more accurately the clinical reality is that if HL7v3 messages are used to carry the data, are they capable of representing it properly? In general, messages between systems need to be able to represent the information emitted by the system in a correct way. There are a couple of HL7 null flavours that deal with values that were supplied but not in numeric form - QS (sufficient quantity) and TRC (trace). I would argue that these are not null flavours, since the values were supplied (and if were to be re-requested, the same answer would presumably be given) but they just happen to be in a text form. In practical terms I believe that openEHR models both of these cases satisfactorily, and without introducing any special null flavour processing. The DER null flavour is interesting; I don't believe it has anything to do with missing data, but there may be a reason to indicate that a data point was derived from some other data points by calculation rather than directly observed, e.g. in the way of Apgar total, or Barthel index total. In openEHR these relationships can be stated mathematically in the archetypes using invariants, but it is true that we don't have a special marker in the data indicating that an element is 'derived' - the system would have to look in the archetype to find out. The question is: is this really needed - is there a concrete case for clinical data users doing something with such a marker if it were there? Another interesting case is UNC, which according to Grahame (I originally misunderstood) means that a text item should have been coded (e.g. with ICD, Snomed etc) but was not, or could not be when attempted. openEHR does not provide a way to indicate this currently. Is it needed? Who would realistically make use of such an indicator? Is another way of seeing this to mark data as 'coding required', as would happen today where coding is often done as a post-data capture activity? Lastly, the OTH case seems to be trying to handle some kind of software or information system errors - where the value supplied in some circumstance is correct (presumably), but not allowed by the model due to an error in modelling. This might arise in openEHR if someone built an archetype to only allow Quantitative input for a data point, but sometimes only narrative could be provided by the user - e.g. the 'sufficient quantity' case above. Avoiding this in openEHR means being fairly careful in archetype modelling. I will leave it there for now. As I say, the point here is to show that openEHR deals with use cases in a sensible and clear way. - thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 7513 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071207/1e14c308/attachment.dat>
