When do i use null flavours and when the archetype absence?

[SevKohler (Severin Kohler)]

I guess null flavours are more for representing stuff that was missed out by an ETL e.g. mapping from HL7?
And exclusions when e.g. filling out an Anamnesis ?

[pablo (Pablo Pazos)]

There are technical cases and clinical cases. I can think of clinical cases where some question couldn’t be answered, for instance, the patient is unconscious and a certain action should take place, like an emergency surgery, and the clinicians can’t get consent from the patient, let’s say the consent is the missing data, so it could be recorded that the null_flavour for the consent is “patient unconscious”.

So in general, null_flavour is to say “why” there is missing data on this ELEMENT, and where a totally missing ELEMENT might get to ambiguous information, like is this ELEMENT not present because someone forgot to fill that in or because they couldn’t, etc. Also consider what would happen if the ELEMENT is required by the template but there is no data for ELEMENT.value, null_flavour could help recording the context of the missing data and the ELEMENT will be valid. Compliance-wise don’t think it’s valid to have an ELEMENT with null value and null null_flavour.

[ian.mcnicoll]

Our practice is largely to use null_flavours for technical integration gaps. We would always try to predict at least the possibility of a no information situation, like a ‘patient unconscious’ situation and build in the use of an Exclusion archetype to handle this. Another reason why in general, we keep mandation light-weight, or even in the UI layer.

For lots of Observations , ‘unknown’ is a valid response , and we found it is just very clunky for developers to switch from True/false as a value to null for 'unknown or ‘not valid’ etc. Better to archetype these ‘nullish’ responses explicitly.

There is/was a JIRA ticket from Koray Atalag some years ago suggesting we have another look at this area but it is really hard to come up with something that is clean and easy for borh devs and clinicians.

So, yes … in general, this fits what we do

I guess null flavours are more for representing stuff that was missed out by an ETL e.g. mapping from HL7?
And exclusions when e.g. filling out an Anamnesis ?

[ian.mcnicoll]

Also this …

Uncertain, unknown and no information

Clinical data is hard to get right. One problem is to handle the unknown and/or uncertain semantic. I assume you all have met the challenge to model a value list of yes no uncertain unknown not applicable Norway is currently implementing a screening program for colorectal cancer. There will be #fhir messages with the data and extensively use of #snomed-ct. DIPS is developing #openehr models (templates and archetypes) to be used within our systems. We need to map these value sets into openehr …

I don’t much like what we are doing but I suspect the alternatives are worse!!

[birger.haarbrandt]

Hi all,

I’m actually a bit confused as well. @ian.mcnicoll mentioned the following:

We would always try to predict at least the possibility of a no information situation, like a ‘patient unconscious’ situation and build in the use of an Exclusion archetype to handle this.

To my understanding, an exclusion archetype is a clinical statement that we can for example rule out a certain diagnosis: “The patient does not have diabetes 2” and not, that this information was not available.

What adds to my confusion is that the Absence of Information archetype (Evaluation Archetype: Absence of information [openEHR Clinical Knowledge Manager]) states

• Equivalent statements about exclusion are used to indicate that it is known that there is no relevant health information in the health record or extract - for example, EVALUATION.exclusion_adverse stating that the patient does not have a known allergy to penicillin or EVALUATION.exclusion_problem_diagnosis stating that the patient is not diabetic; and;
• In this context, the EVALUATION.absence could be used to record that there is no health information available about penicillin allergy or the diagnosis of diabetes - it is not known if it is present or excluded, but there is no information that can be provided.

which makes sense but then later also says

This archetype has been designed specifically to avoid the need to use of flags to express negation about any entry within the health record.

To my understanding, the exclusion archetypes are the substitute for such flags (which I like as I don’t consider these flags as used in CDA as clinically safe…). Maybe somebody could help clarify if my understanding is correct.

I would also add to the discussion that the Absence archetype can be used to “replace” an entry inside a composition whereas I don’t think we can use a null_flavour for such purpose as it only exists on the element level.

[pablo (Pablo Pazos)]

I agree with your definition of an exclusion archetype, and don’t think it has anything to do with the element.null_flavour

Also agree on the clinical statement (exclusion) vs. single data field (element) semantic difference.

[ian.mcnicoll]

Yes - I mis-spoke - the Absence archetype is the appropriate one in this situation, not Exclusion

Clinical Knowledge Manager

[SevKohler (Severin Kohler)]

Just for consistency:
@yampeku, recommended to me to use null flavour for absence until i need to represent more semantic to an null flavour. I hope i recited this correctly

[heather.leslie]

From the clinician/designer’s point of view:
The absence and exclusion archetypes have been intentionally designed for clinical recording purposes - that is, when we need record explicit statements about there being no information or excluding specific clinical conditions/meds/adverse reactions etc within the health record as part of our accurate record keeping, decision-making or data exchange with others.

The two main use cases include:

• Persistent lists. In a new patient’s record the Problem list could (?should) contain an explicit statement that there is no information about the past/current problems/diagnoses UNTIL the clinician asks the question to the patient. Then they can add either an explicit global exclusion to state that there are no significant past diagnoses OR add an instance of the Problem/Diagnosis archetype for each known diagnosis. Exclusions need to be revised or removed as known presence records of problems or diagnoses are added.
• Data exchange - for example transfer of care which needs all information to be explicitly stated eg known diagnoses, known exclusion of any diagnoses, or an absence of any information about the presence or exclusion of diagnoses because the patient is unconscious & no one has had a chance to find out yet. An empty Problem list container is dangerously ambiguous and the receiver has no idea if there are no known problems or we don’t know if there are problems or not .

Absence should be considered a temporary state and used by a clinician or clinical system as a prompt to find out the actual situation.

It is a clinical safety issue. Explicit statements of known presence (EVAL.problem_diagnosis, EVAL.medication_summary or ACTION.medication, EVAL.adverse_reaction etc); known exclusion (EVALUATION.exclusion_global and EVALUATION.exclusion_specific) and known absence (AKA no idea but we need to find out) (EVAL.absence)

Please also note that the current EVAL class of the Exclusions should probably be changed to an OBS. See CR - 956 and CR-957