probably did really intend only a
POINT_EVENT, so in some cases, the type constraint should be made.
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120621/ad7195cf
Hi Thomas / Diego,
As far as the published archetypes are concerned we will have thought
fairly carefully about if and when to constrain EVENT to Point or
Interval, and this is definitely something that should be applied at
template level in most cases but, as ever, we have to be careful not
to
Hello Ian and everyone
Thank you for your response. (a) and (b) are clear but not towards what
the question is really about.
I wouldn't like this to drag on too much so maybe it's better if i
implement it the way i understand it and correct any errors afterwards.
All the best
Athanasios
Hi Thomas Ian,
I see what you mean, and I agree that in its current form
ITEM_STRUCTURE has no sense to be put and not restricted. Maybe there
are other cases where this is still valid (restrict the ENTRY class in
its current form I would say that it has no sense either, but maybe
CARE_ENTRY
://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120621/0f8ef466/attachment.html
unconstrained, then any ENTRY can go there...
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120621/b85a0d36/attachment-0001.html
attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120621/b47aee39/attachment.html
--
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120621/8923b267/attachment.html
8 matches
Mail list logo
