Hello Ian and everyone Thank you for your response. (a) and (b) are clear but not towards what the question is really about.
I wouldn't like this to drag on too much so maybe it's better if i implement it the way i understand it and correct any errors afterwards. All the best Athanasios Anastasiou On 20/06/2012 17:14, Ian McNicoll wrote: > 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 >>> >>> >>> >>> >> > > >
