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> > > 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
