# ELEMENT.null\_reason proposal **URL:** \ **Category:** Technical (archive)\ **Created:** [25 January 2017 11:33 UTC](https://discourse.openehr.org/t/element-null-reason-proposal/15470 "2017-01-25T11:33:40Z")\ **Posts on this page:** 8\ **Page:** 1

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\ **Post date:** [25 January 2017 11:33 UTC](https://discourse.openehr.org/t/element-null-reason-proposal/15470/1 "2017-01-25T11:33:40Z")

Silje has just pinged me again on the question of whether we should have an ELEMENT.null-reason or similar attribute to accommodate specific reasons for null\_flavour being set. There are 3 PRs on this as follows: - [SPECPR-41](https://openehr.atlassian.net/browse/SPECPR-41) - Enable content specific flavours of null to be specified per archetype - [SPECPR-62](https://openehr.atlassian.net/browse/SPECPR-62) - Add a ‘reason for null’ text attribute in the Reference model - [SPECPR-119](https://openehr.atlassian.net/browse/SPECPR-119) - CLUSTER also needs a Null\_flavour - [SPECPR-151](https://openehr.atlassian.net/browse/SPECPR-151) - Add an attribute to ELEMENT to record ‘null reason’ These are all reporting the same problem. (The last one can probably be closed as a direct duplicate of SPECPR-62). Having re-read the comments on all, my inclination is to propose the simple addition of an attribute `null_reason: DV_TEXT[0..1]` to the [ELEMENT class](http://www.openehr.org/releases/RM/latest/docs/data_structures/data_structures.html#_element_class). This would be optional and will not invalidate any existing data, but on the downside it will be a data field that will often be emtpy (i.e. Void, or ‘null’ in the Java/C sense). What would the general reaction to proposing this change be? - thomas ---

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\ **Post date:** [25 January 2017 11:52 UTC](https://discourse.openehr.org/t/element-null-reason-proposal/15470/2 "2017-01-25T11:52:43Z")

Hi Thomas, I agree that we should go ahead with this ASAP. However it might be worth a slight pause to think about the wider problem in handling ‘clinical nulls’. To summarise, ‘null flavours’ have limited value in a great deal of clinical models because the standard set of null flavours, although expressing the ‘reason for null’ from a technical perspective ‘not appropriate’, ‘unavailable’ etc is not clinician/context friendly enough for actual use-cases. I think there is strong parallel here with the need to overlay the technical state machine current\_state attribute with archetype\_specific careflow\_steps as per [SPECPR-41](https://openehr.atlassian.net/browse/SPECPR-41) . Now we will probably always need extra free text as per SPECPR-62/151 but if we are thinking about this, I suggest putting a little effort into progressing ( or ditching) those other PRs. Ian ---

**Author:** ![yampeku](https://discourse.openehr.org/user_avatar/discourse.openehr.org/yampeku/32/25_2.png) [@yampeku](https://discourse.openehr.org/u/yampeku)\ **Post date:** [25 January 2017 11:54 UTC](https://discourse.openehr.org/t/element-null-reason-proposal/15470/3 "2017-01-25T11:54:01Z")

If null\_flavour is a DV\_CODED\_TEXT, what stops anyone to create an specialized archetype (directly from an rm class) that has the texts (+ codes) needed in a given country/use case? This probably should work even if set of null\_flavour codes is fixed. I don't know if this would be enough, but in theory it provides a workaround for all issues (except the cluster one) ---

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\ **Post date:** [25 January 2017 12:34 UTC](https://discourse.openehr.org/t/element-null-reason-proposal/15470/4 "2017-01-25T12:34:58Z")

Hi Diego, That’s a pretty good suggestion, although in that case we are really abandoning the idea of the current fixed base set of ‘technical’ null-flavours and allowing them to be replaced by local terms, while I was suggesting something more like the ISM\_TRANSITION setup where archetype-specific ‘clinical overlays’ can be provided via the archetyped careflow\_steps but are always associated with the underlying state\_machine and current\_status attribute. Ian ---

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\ **Post date:** [25 January 2017 12:49 UTC](https://discourse.openehr.org/t/element-null-reason-proposal/15470/5 "2017-01-25T12:49:20Z")

Diego, I think this is the same as - extending the current openEHR null\_flavour code set, and making it hierarchical OR - allowing other local code-sets to be used in that slot. - if these codes were understood as proper local extensions of the openEHR code-set, i.e. any new code asserted an IS-A relationship to one of the 4 existing openEHR null codes, then it would work properly. But we have no way to do that. The first I think gets into the place HL7 is with this field - you can never design a terminology for ‘null flavour reason’ that works for everyone. The second has the problem that the field becomes non-interoperable - today, applications can assume one of 4 known values; if any code set can be used, this assumption will break. Unless the ‘extension’ idea could be achieved somehow, which would be kind of nice. Whenever I think through this problem I come back to the idea of a second field, which is more or less the design concept, as Ian says, or the state machine state + careflow step in ACTIONs. - thomas ---

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\ **Post date:** [25 January 2017 13:23 UTC](https://discourse.openehr.org/t/element-null-reason-proposal/15470/6 "2017-01-25T13:23:48Z")

So, if I understand well, the idea is to add an attribute for representing clinical reasons for a null flavor, maintaining the current null\_flavor for technical reasons only. Is that right? ---

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\ **Post date:** [25 January 2017 15:05 UTC](https://discourse.openehr.org/t/element-null-reason-proposal/15470/7 "2017-01-25T15:05:35Z")

That seems to be my understanding of Thomas’ suggestion – and I think that is the way to go. Then we will have a small set of “classes of null flavours” , and the detailed and local description can be added to the second field . The second field may then be of type DV\_TEXT to allow both unstructured and coded values. Vennlig hilsen Bjørn Næss Produktansvarlig DIPS ASA Mobil +47 93 43 29 10 ---

**Author:** ![Bostjan\_Lah](https://discourse.openehr.org/user_avatar/discourse.openehr.org/bostjan_lah/32/2818_2.png) [@Bostjan\_Lah](https://discourse.openehr.org/u/Bostjan_Lah)\ **Post date:** [25 January 2017 15:07 UTC](https://discourse.openehr.org/t/element-null-reason-proposal/15470/8 "2017-01-25T15:07:40Z")

Yes, this is also my understanding and I agree this is the way to go. Best regards, Bostjan That seems to be my understanding of Thomas’ suggestion – and I think that is the way to go. Then we will have a small set of “classes of null flavours” , and the detailed and local description can be added to the second field . The second field may then be of type DV\_TEXT to allow both unstructured and coded values. Vennlig hilsen Bjørn Næss Produktansvarlig DIPS ASA Mobil +47 93 43 29 10\