We talked about this on multiple occasions...Certain kinds of data have peculiarities about depicting absence. Majority of examples I am aware of pertain to reporting of clinical findings. Simple example would be presence of rash. We can talk about its:
c) positive statement that it is unknown (for whatever reason). I think currently captured by null_flavour on ELEMENT)
We don't have the means to depict absence and hence modellers are either using dedicated data items to capture this causing a lot of repetition and clutter. A related issue happens at Archetype-instance level with the need to use specific EXCLUSION archetypes. While I understand this offers additional capability to capture additional data why data are absent I think the fact that data are absent should be found in the model that describes it and more importantly easily reachable. Currently the only means is to query for existence of these Exclusion archetypes which can be computationally costly.
So in a RM attuned for healthcare data one should expect to capture this at a more basic level - RM!. Essentially I'm talking about things you can talk about their absence. Not all data are like this - for example you cannot talk about absence of a procedure or tumour-grade etc.
My proposal is two-fold:
1) to add an optional Boolean flag to depict absence to ELEMENT Class
2) to add an optional Boolean flag to depict absence of an ENTRY; e.g. Problem/Diagnosis. Note that we can still continue to capture additional data using exclusion archetypes but I think semantically an Entry capturing data about an Observation or Evaluation should include data about its positive absence. In practice in very little cases those exclusion archetype data items will be used.
I think (2) needs further thinking...I think CIMI has this notion of design patterns and clinical finding is one of them - not sure how they handle this though...Tom?
There is a current discussion with the Norwegian modelling crew about just this issue. Various approaches have been discussed.
1. Standard patterns in the archetypes
2. Use of Exclusion archetypes e.g. Absence of Symptom
3. Use of Generic exclusion cluster archetype that can slot in elsewhere.
4. Simple generic negation flag
I think we need to do a bit more thinking about the pros and cons and the somewhat different requirements of e.g negating a diagnosis vs. negating a symptom.
What might be good to think about on the RM side is whether we can add inbuilt negation which is 'query-safe'. I am very uncomfortable about using the simple negation flag approach as it is too easy for people to overlook the flag when querying but I agree that the use of Exclusion archetypes imparts an overhead of complexity that it would be best to avoid.
What I would like to see considered is some kind of construct that would effectively create different paths for negated (or absent) elements.
i.e a positive diagnosis of Diabetes
Problem_diagnosis.v1/data/items[at0005]/value/value = "Diabetes mellitus"
Negated diagnosis of Diabetes
Problem_diagnosis.v1/data/negated[at0005]/value/value = "Diabetes mellitus"
I'm sure other approaches would be more sensible but the aim is to add RM support for negation without the risks introduced by a simple negation flag
Kite flying time?
I also do like the FHIR empty list idea to handle list negations "No known allergies".
Hi Ian, thanks for thoughtful input.
I'd support your negation method at RM level. Do you think we can take this to SPEC meeting or probably need a bit more discussion?
I don't know about FHIR's empty list method - will take a look.
How can you use a boolean flag to indicate absence? What are the data of the Element or Entry? They are not real data, because they don't report anything. So they don't follow the same archetypes used to report existing things. In philosophy, non-existence is understood as a generic statement - if you say 'not exists X', X doesn't refer to anything real. The best that you can do is use a general term. E.g. 'not exists Diabetes'. To do this, different archetypes are most likely needed, and that's the Exclusion archetype idea. This is also closer to real clinical statements.
Hi Tom, I am no longer suggesting such a flag, see Ian's comments.
Also the clinical finding pattern can be recapped as:
1) present (no probs with this)
2) absent (this is positive statement about exclusion)
3) unknown (for whatever reason, I think this is different from (2). Can be null in technical terms but also deliberately not provided, forgotten etc. I think current null_flavour can cover this but not (2).
I think we should treat ENTRY and Element/Cluster/Item cases differently (though the same solution could apply).
Can we assume this one will be Release 1.1.0 or later?