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 Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: i...@freshehr.com twitter: @ianmcnicoll Co-Chair, openEHR Foundation ian.mcnic...@openehr.org Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 25 January 2017 at 11:33, Thomas Beale <thomas.be...@openehr.org> wrote: > > 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 > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
