For the case where an attribute is constrained to '0'
existence i.e.
state existence matches {0} .....
what should follow as the rest of the attribute
constraint? Technically, the rest of the definition
is superfluous as we have already stated that the
attribute must not exist, but the
'matches' clause needs to exist in the grammar. Should
it be matched to *, or should it be empty?
state existence matches {0} matches {*}
or
state existence matches {0} matches {}
(I'm not sure the grammar allows this)
For the case where an attribute is constrained to '0'
existence i.e.
state existence matches {0} .....
what should follow as the rest of the attribute
constraint? Technically, the rest of the definition
is superfluous as we have already stated that the
attribute must not exist, but the
'matches' clause needs to exist in the grammar. Should
it be matched to *, or should it be empty?
state existence matches {0} matches {*}
or
state existence matches {0} matches {}
(I'm not sure the grammar allows this)
we certainly have not allowed for it yet; indeed, no-one has ever wanted
to do it in an archetype, it has only come up as a need in templates
(which simply quote path names and then add an existence constraint).
Possible responses that come to mind:
- in openEHR we try never to include a feature that is not justified by
at least one known use case. So we should try to find a real use case
before doing anything.
- there is in fact already a way to do this: by adding an invariant to
an archetype of the form
not exists (/path/to/some/attribute/that/we/dont/want)
- if we had to add more syntax to the cADL part of ADL, I would probably
opt for the second proposal above.
But....a credible use case needs to be found first.
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
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 { ... }
}
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.
How about specialised archetypes? Wouldn't there be occasions when a
parent archetype has some attribute, which a child (specialisation) of
that archetype don't want to deal with?
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.
I haven't seen any template specification, hence I tend to think
of things in terms of how I would do them in an archetype.
Personally, I think there will be cases where the very existence
of an attribute makes no sense in any conceivable requirement
of that concept - or needs to be explicitly denied to prevent misuse
of the archetype.. just looking briefly at the OBSERVATION
RM, it has comments saying that 'state' data should be
stored either per event, or per observation - but not both. Surely
the choice of which strategy is being used would be made by
constraining out the existence of the 'other' state attribute?
If zero existence constraints are not to be used in archetypes then
the section dealing with them in ADL should be updated.
In particular, page 48
"Existence is shown using the same constraint language as the rest of
the archetype definition. Existence constraints can take the values
{0}, {0..0}, {0..1}, {1}, or {1..1}. The first two of these constraints
may not seem initially obvious, but may be reasonable in
some cases: they say that an attribute must not be present
in the particular situation modelled by the archetype. The default existence
constraint, if none is shown, is {1..1}."
On a related note, whilst I understand the general concept of
a template in openehr I am yet to see any spec of what
they look like.. are there any specs out there?
I should also note that after I had posted my initial query
about existence constraints last month I found a section in the ADL spec
that actually deals with this
section 4.3.5 "Any" constraints
"however, it also provides an opportunity to specify an existence constraint
which might be narrower than that in the information model."
So my interpretation would be that the correct syntax
for a zero existence constraint would be therefore
Ocean has a quite sophisticated template designer which is still in Beta,
but which currently allows you to build templates from multiple archetypes
and then constrain nodes further. It also allows you to drag and drop nodes
onto a form designer where they become the appropriate windows controls and
also to map templates to other data. The form designer allows you to
produce code and to compile and build executables.
Currently the templates are serialized as xml by this tool, however openEHR
is working on the release of a TDL which is based on ADL. Not sure when
this will be available.
I should also note that after I had posted my initial query
about existence constraints last month I found a section in the ADL spec
that actually deals with this
section 4.3.5 “Any” constraints
“however, it also provides an opportunity to specify an existence constraint
which might be narrower than that in the information model.”
So my interpretation would be that the correct syntax
for a zero existence constraint would be therefore
attribute existence matches {0} matches {*}
Hi Andrew
It’s valid only if the attribute is optional in the containing class from the reference model.
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
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!).
I am inclined to agree with you. The specialisation instance is a good example, as it will not break the parent’s by having the attribute but setting existence to 0.
Cheers, Sam