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)
2017-01-25 12:33 GMT+01:00 Thomas Beale <thomas.be...@openehr.org>: > > 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 - Enable content specific flavours of null to be specified per > archetype > SPECPR-62 - Add a 'reason for null' text attribute in the Reference model > SPECPR-119 - CLUSTER also needs a Null_flavour > 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. 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
