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?
2017-01-25 13:34 GMT+01:00 Ian McNicoll <[email protected]>: > 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 <+44%207752%20097859> > office +44 (0)1536 414994 <+44%201536%20414994> > 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 > -- David Moner Cano Grupo de Informática Biomédica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Politécnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta Valencia – 46022 (España)
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
