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 Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: [email protected] twitter: @ianmcnicoll Co-Chair, openEHR Foundation [email protected] Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 25 January 2017 at 11:54, Diego Boscá <[email protected]> wrote: > 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 <[email protected]>: > > > > 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 > > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
