Andrew Patterson wrote:
>> This is not sensible to have in an archetype - otherwise it would not be
>> there! It is a requirement for templates in use.
>>
>
> I don't understand why it is not sensible to have in an archetype?
> Couldn't it be useful to say that for this particular observation
> we want to explicitly disallow the recording in of state information?
>
> OBSERVATION matches {
> state existence matches {0} matches {*}
> }
>
> Would be an observation that has 'data' but is not
> allowed to contain 'state' information.
>
I cannot imagine a single example where this makes sense....
> what about a DV_MULTIMEDIA value where a thumbnail
> makes no sense so we want to explicitly stop people
> from storing data there
>
> DV_MULTIMEDIA matches {
> media_type matches { "audio/wav" }
> thumbnail existence matches {0} matches {*}
> }
>
I agree that you _may_ not want a thumbnail in some cases/places, but
the problem with putting this prohibition in an archetype is that it
becomes global, and actually prevents the few who might want audio
thumbnails from having them.
> I can accept that there may not be any clinical situations where
> this has been encountered and therefore there are no obvious
> use cases for it - but I don't see why its not sensible
> to be able to state an attribute is not merely optional, but in
> this archetype is disallowed.
>
> If it is indeed not sensible, then the existence grammar in
> ADL can be simplified - currently 0 is allowed - it really should
> just be 0..1 (default) or 1 as the allowable existence ranges.
> (which could all be simplified to a simple 'mandatory' keyword
> and the whole existence bit could be removed!).
>
that is probably true - I will investigate this.
- t
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
