Hi Pablo, I don't personally particularly agree with this approach either. There are two other approaches that could be used: the COMPOSITION / SECTION / multiple ENTRYs approach, and the CLUSTER-per-analyte approach (an earlier suggestion of Ian's and mine). I am going to build these models as CIMI archetypes as well, and document the results on the wiki as well. Then we can see the outcomes and judge objectively.
- thomas On 14/02/2014 22:48, pablo pazos wrote: > Hi Thomas, > > Overviewing the content on the wiki, IMO panels are an specification > of sections. > > Is very weird from the modeling point of view to have a composite > pattern (ENTRY, COMPOUND_ENTRY, ...) inside a composite pattern > (CONTENT_ITEM, SECTION, ENTRY), is like defining a tree inside a tree > in the model, but the initial model can also model the second, is just > redundant. And IMO it doesn't add semantics to the model. > > It is also stated that "a panel is not a Section; it has specified and > fixed [potential] content", so it could be a templated section maybe > (?). Without that statement, is clear that a collection of > observations is just a SECTION with slots to OBSERVATIONS (archetyped > or templated). > > Also, the name "panel" makes me think of an user interface element, > not a data structure. It would be nice to know why they need this new > composite structure there, and if the requirement comes from > structural needs or from information display needs. > > As I see it, CIMI is mixing SECTIONS and ITEM_STRUCTURES. > > > OT, I tried to get closer to CIMI, but it seems difficult to > participate from outside the EURO zone :( -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140215/2b3313c4/attachment.html>
