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 that is still not clear and if you don't mind i'd like to ask a bit more specifically about: a) Is an ITEM_STRUCTURE static? (I think that it's static but i would like to verify that because, as described in the previous message i can't decide just from the specification) In other words, when you specify an ITEM_STRUCTURE in the archetype editor then you simply denote that you would like your set of defined ITEMs (elements, quantities, counts, etc) to be _interpreted_ as a LIST, TABLE, TREE but that data structure itself will not have to expand (at run time) necessarily to a list, table or tree (Is that correct?). b)HISTORY holds a list of EVENT<ITEM_STRUCTURE> (parametrising the data attribute here). This particular list COULD BE dynamic (Is that correct?). In the visual acuity example provided by Ian earlier: That would be a HISTORY of 1 POINT_EVENT<CLUSTER> to describe the visual acuity of the subject that was obtained during a regular check-up session in some point in their lifetime. But, if you wanted to measure some drug uptake (or other transient parameter) you would have a repeating POINT_EVENT that could expand indefinitely (because a substance uptake is different for every person). (Correct?) (Thomas thank you very much for that link, it came later as i was writing this message, i will have a close look at it) All the best Athanasios Anastasiou On 20/06/2012 15:47, Ian McNicoll wrote: > 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 to be good consensus that it would be better to replace > ITEM_STRUCTURE with CLUSTER in the next generation of the RM. There > will definitely still be aspects of the archetyped structures inside > that CLUSTER (via a child CLUSTER ) that are best represented as > simple lists or as Tables, but this is best done by applying some sort > of design constraint on the cluster, rather than using a separate > Table class. > > e.g. for a possible Visual Acuity archetype > > data > Cluster Laterality" (As Table pattern with row names carried as > Run-time name constraints Left eye, Right eye , Both eyes) > Element "Low level acuity" > Element "Snellen" > Element "ETDRS" > Element "Measurement distance" > Element "Mode" > Element "Correction" > > This lets express a tabular structure at a much more granular level > than with ITEM_STRUCTURE sub-classes which in th example above would > have to apply to the whole data structure > > In summary, you can safely assume that we will only be modelling with > ITEM_TREE for the forseeable future. > > Ian > > > > On 20 June 2012 11:50, Sam Heard<sam.heard at oceaninformatics.com> wrote: >> 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 clusters >> to provide the Information structure of an addressable table. >> >> There is a place for ITEM_LIST and ITEM_TABLE but the other issue is these >> constraints might be brought to bear at any point in an information >> hierarchy. >> >> I have proposed in version 2 of the RM that we make these specialisations of >> CLUSTER as a constraint statement. That would ensure backward compatibility. >> >> Cheers, Sam >> >> >> On 16/06/2012 1:25 AM, Athanasios Anastasiou wrote: >>> >>> Hello everyone >>> >>> I am sending this email to clarify the role of ITEM_STRUCTURE in >>> relation to other structures (such as HISTORY and EVENT) both from the >>> point of view of EHR semantics as well as the computational view. >>> >>> My "problem" in one line is that i can't understand if ITEM_STRUCTURE >>> are there to ensure that their content is interpreted properly >>> semantically or they really "do what they mean" (i.e. they represent >>> tables, lists, trees that have to be populated as such). >>> >>> A related question is also this one: >>> >>> Is it possible that a C_MULTIPLE_ATTRIBUTE constraint pointing to an >>> ITEM_LIST will have upper_unbounded=True? >>> >>> If yes, then ITEM_LIST would have to be dynamically expanding (and this >>> complicates things a little bit but...that's life)...If no, then the >>> contents of ITEM_LIST can be considered static (yay!) and you only need >>> to know that this is an ITEM_LIST for interpretation purposes (which of >>> course is KEY when you come across an ITEM_TREE) >>> >>> This will help me in two points: >>> a) Clarify the role of ITEM_STRUCTURE and use it properly in archetypes >>> and templates >>> b) Be able to assign widgets properly (and later read data off them) >>> when constructing a GUI. >>> >>> A few more notes are available at the end of this message >>> >>> All the best >>> Athanasios Anastasiou >>> >>> >>> >>> What i understand but would like to verify is that ITEM_STRUCTURE do >>> what they say they do, i.e an ITEM_LIST represents a dynamic list >>> (constrained by some C_MULTIPLE_ATTRIBUTE) and an ITEM_SINGLE >>> represents....just one entry (constrained by some C_SINGLE_ATTRIBUTE). >>> >>> But i am a little bit confused for two reasons: >>> >>> a) by what is meant by HISTORY<T>. >>> >>> HISTORY already implies "A list of events" with the type of the list >>> being (point or interval)EVENT<T> which could imply "A [single item or >>> table] of ITEM_STRUCTURE" OR "A [list,tree] of ITEM_STRUCTURE"....and >>> this is where it gets confusing. >>> >>> Does that mean that all of the following are valid? (with respect to >>> HISTORY<T>) >>> >>> *) a dynamic list of events containing dynamic lists of item structure >>> (the history.events can expand and so can the item structures held by >>> events) >>> >>> *N1) a dynamic list of events containing static lists of item structure >>> (events can expand, but each event is supposed to simply contain a list >>> of items that is actually fixed in size). >>> >>> (dynamic and static expanded for the following lines as well) >>> *) A list of trees >>> *) a list of tables >>> *) a list of single values (this is the most intuitive thing....For >>> example, a time series represented as a history of point events of >>> single_value...) >>> >>> >>> b) by the explanation given in the specs >>> With reference to (*N1) above: >>> The example that is given in the spec for ITEM_LIST is that of "parts of >>> an address". This is what leads me to believe that ITEM_LIST is not >>> supposed to be a dynamic list but just something THAT IS TO BE >>> INTERPRETED AS A LIST but from a computational point of view is just a >>> list. I really do hope this makes sense. (I have gone through section 6 >>> in "data_structures.pdf" and that again points to ITEM_STRUCTURE being >>> used for interpretation rather than "definition" :-/) >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > >
