hi Tom Much to say (sadly)
Firstly I would like to point out that in V3, nullFlavor does not convey the notion that the data is missing - just that it could not properly be represented in the form expected. Missing is one reason why. You could well argue that it's mis-named, and I have done so, but for legacy reasons it won't be changed now. > 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 /open/EHR, 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 okay, I understand your comment now. In OpenEHR, the fact that the data item is a question that the patient may refuse to answer must be explicitly modeled. So we compare the Hl7 approach, where the infrastructure provides this as an option everywhere, so it may be used in places where it is not appropriate, and openEHR, which only provides it where explicitly modeled, so it may not be used in some places where it is appropriate. The only thing I'd say to this is that this seems like a use-case thing rather than a definitive information model thing. I should not be assuming a particular work process when designing an archetype - that's a template thing. Isn't it? I could make a similar comment about the HL7 way too - it's fine for the underlying model to provide ASKU everywhere, but you need to be able to restrict this in practice when you do get to process-driven work flow analysis (templates again), and Hl7 hasn't provided a framework for this. In general, HL7 assumes that nullness and conformance are linked, but it's increasingly clear that this is a problem. > 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. really, then, this is another parallel case of the above - pros and cons of providing this stuff implicitly or explicitly > 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. actually the real notion in the HL7 use case is that the receiver may derive the value from a mix of the information provided and other information they have in context (such as patient body mass), rather than simply using the value provided. Again, this is a question of whether such things should be provided by the infrastructure or explicitly modeled. (In this case, Hl7 provides extremely explicit use-case control over how this is done) > 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? even for the simple case where a value may be measured or derived, I think this is significant. I used to do Lipid analysis. If other lipids were normal, we'd calculate LDL-Cholesterol, otherwise we'd actually measure it. Around the cut-off we used our discretion, but we were required to report whether we calculated or measured the value - but since the value was usually interchangable, we used the same code to report it. > 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? Personally I think this is esoteric to the point of being ridiculous. The notion is that if the first system didn't try, it's worth the second system doing so, and that if the first did, maybe the second shouldn't. My personal opinion is that this is bunkum. I tried to put a counter proposal where systems would self rate their coding proficiency using some ordinal scale, but this didn't fly! So I was unable to persuade the committee to reject this notion, and frankly, if someone else wants to make this distinction, why should I stop them, just because I'm going to ignore it? > 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? I think this is a valid use case - how would I represent this in openEHR? > 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. I think that some of the implications for how OpenEHR chooses to handle this are under-appreciated by archetype designers. Grahame
