Hi Anthanasios
I think time has shown that this is probably an area of over engineering
in openEHR. All archetypes are now ITEM_TREE and could be clusters.
If we think of these as providing constraint on an underlying cluster -
ITEM_LIST is a cluster of ELEMENTs and ITEM_TABLE sets up a set of
Hi Athanasios,
Just to back up what Sam has said, experience has shown that it is
best practice to model every top-level archetype structure as
ITEM_TREE to allow for maximum flexibility to develop the model in the
future without breaking backward compatibility, and as Sam has said
there appears
.
*
*
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120620/55bf27dc/attachment.html
Hi Pablo,
I am just catching up with some of these discussions.
Although in theory all OBSERVATIONS must also have associated ACTIONS
to record the execution of the process, in practice this is not
necessary or the Action will refer to a group of Observations e.g. the
Action to a request to Take
Hello everyone
Thank you very much for your responses Sam Ian, they were helpful. In
any case the changes you describe do not seem to be reducing the
flexibility of the model. This definitely also helped me in clarifying
the use of ITEM_TABLE.
There is another part to that question though
Hi Athanasios,
a) The very first thing you have to do is to decide on the structure
and this is static. The archetyped definition sits within a sub-class
of item structure. So if I am creating a new Observation archetype and
want to add elements to 'data' I first have to decide which structure
to
So you have to select the ITEM_STRUCTURE class but you don't have to
select the EVENT class? (most CKM archetypes have now EVENT and not
INTERVAL_EVENT or POINT_EVENT)
I think it should be allowed/forbidden following only one criteria.
2012/6/20 Ian McNicoll Ian.McNicoll at oceaninformatics.com
7 matches
Mail list logo
