Hi Andrew I think that the right place to say "for this usage of this archetype I want to explicitly exclude something" is in the template. The archetype should be a representation of a concept that can be used for all conceivable requirements of that concept and then constrained in the template.
Regards Hugh __________________________________ Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI Director and Senior Clinical Consultant Ocean Informatics Pty Ltd M: 0404 033 767 E: hugh.leslie at oceaninformatics.biz Skype: hughleslie > -----Original Message----- > From: openehr-technical-bounces at openehr.org > [mailto:openehr-technical-bounces at openehr.org] On Behalf Of > Andrew Patterson > Sent: Wednesday, 25 October 2006 4:24 PM > To: For openEHR technical discussions > Subject: Re: a zero existence constraint > > > 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. > > 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 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!). > > OBSERVATION matches { > data matches { ... } > state mandatory matches { ... } > } > > Andrew > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
