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 use. In practice we always now use ITEM_TREE.
b) EVENT actually holds 2 ITEM_STRUCTUREs, one for 'data' , and one for 'state', each of which are statically defined by the archetype. Basically any time you see ITEM_STRUCTURE, you can assume that part of the archetype is going to define the content within this structure. It is a lot easier to look at EVALUATION as an example as the containing classes are simpler. This has two ITEM_STRUCTUREs 'item' and 'protocol' . If you look at the Adverse Reaction archetype you will see that these are separately defined in the archetype. Ian On 20 June 2012 16:50, Athanasios Anastasiou <athanasios.anastasiou at plymouth.ac.uk> wrote: > 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 >> >> >> >> > -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK Director openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org
