Re: ELEMENT.null_reason proposal

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 > 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

ELEMENT.null_reason proposal

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

Re: ELEMENT.null_reason proposal

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

Re: ELEMENT.null_reason proposal

Diego, I think this is the same as * extending the current openEHR null_flavour code set, and making it hierarchical OR * allowing other local code-sets to be used in that slot. o if these codes were understood as proper local extensions of the openEHR code-set, i.e. any new

Re: ELEMENT.null_reason proposal

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,

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 : > Hi Diego, > > That's a pretty good