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
