Yes, this is also my understanding and I agree this is the way to go. Best regards, Bostjan
On 25 Jan 2017, at 16:05, Bjørn Næss <b...@dips.no<mailto:b...@dips.no>> wrote: 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<tel:+47%2093%2043%2029%2010> Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På vegne av David Moner Sendt: onsdag 25. januar 2017 14.24 Til: For openEHR technical discussions <openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>> Emne: Re: ELEMENT.null_reason proposal 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 <i...@freshehr.com<mailto:i...@freshehr.com>>: 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<tel:+44%207752%20097859> office +44 (0)1536 414994<tel:+44%201536%20414994> skype: ianmcnicoll email: i...@freshehr.com<mailto:i...@freshehr.com> twitter: @ianmcnicoll [https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ] Co-Chair, openEHR Foundation ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org> Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 25 January 2017 at 11:54, Diego Boscá <yamp...@gmail.com<mailto:yamp...@gmail.com>> 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 <thomas.be...@openehr.org<mailto: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<mailto: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<mailto: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<mailto:openEHR-technical@lists.openehr.org> 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.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 openEHR-technical@lists.openehr.org<mailto: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
