Regarding the role of ITEM_STRUCTURE
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 representsjust one entry (constrained by some C_SINGLE_ATTRIBUTE). But i am a little bit confused for two reasons: a) by what is meant by HISTORYT. HISTORY already implies A list of events with the type of the list being (point or interval)EVENTT which could imply A [single item or table] of ITEM_STRUCTURE OR A [list,tree] of ITEM_STRUCTUREand this is where it gets confusing. Does that mean that all of the following are valid? (with respect to HISTORYT) *) 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 thingFor 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
Regarding the role of ITEM_STRUCTURE
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 representsjust one entry (constrained by some C_SINGLE_ATTRIBUTE). But i am a little bit confused for two reasons: a) by what is meant by HISTORYT. HISTORY already implies A list of events with the type of the list being (point or interval)EVENTT which could imply A [single item or table] of ITEM_STRUCTURE OR A [list,tree] of ITEM_STRUCTUREand this is where it gets confusing. Does that mean that all of the following are valid? (with respect to HISTORYT) *) 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 thingFor 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
Regarding the role of ITEM_STRUCTURE
See openEHR 2.x RM candidates A-3 and A4 here http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model. On 20/06/2012 11:50, Sam Heard 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. * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120620/55bf27dc/attachment.html
An ACTION or INSTRUCTION referencing an AGENT, is it possible?
Hi Pablo, I am just catching up with some of these discussions. Although in theory all OBSERVATIONS must also have associated ACTIONS to record the execution of the process, in practice this is not necessary or the Action will refer to a group of Observations e.g. the Action to a request to Take Vital Signs measurements. Even if this is recorded as part of nursing workflow, it is unlikely that each individual Vital sign will need to have its ACTION recorded. My priority is to ensure that the information required to support the 'real' clinical process is always available to the person reviewing the record. So if device details are important to the clinical interpretation of the record, we should ensure that they are part of the OBSERVATION. The associated ACTION may be important for monitoring care delivery but it rarely affects clinical interpretation. The complexity of healthcare, differing use cases between unplanned and workflowed care, primary data entry vs. messaged summaries, and the presence or absence of a device registry, are always going to make these decisions difficult. It is certainly possible (and cleaner) to have references to external entities rather than them being modelled in-line but it causes other difficulties in complicating archetype visualisation for clinical review and of course, de-referencing for messaging purposes. I do agree that it would be useful if CLUSTER archetypes could be reused between the DEMOGRAPHIC and EHR models. In fact is it quite easy to hack the ADL to change one to another just by reaching the EHR/DEMOGRAPHIC model name in the archetypeID but it would be better if the tools just ignored the model part of the id. Ian On 17 June 2012 17:48, pablo pazos pazospablo at hotmail.com wrote: Hi Gustavo, As Heather pointed out, the solution seems to be to reference the internal structure of a device (or any other demographic archetype) through a CLUSTER. But I think those demographic concepts should be also modelled as complete, separate demographic archetypes, referencing the same internal structure (CLUSTER). This allow us (developers) to create functionalities for searching and processing on demographic archetypes. About the internals of a test, I think most often includes both ACTION and ?OBSERVATION, because an ACTION could be used when you need to record information about the execution itself (being or not a clinical intervention on the patient, e.g. the recording of the device used to make the test should be part of the ACTION not of the OBSERVATION), then the OBSERVATION(s) could hold the information about the test result or information about clinical findings during the test. Then the whole record of a test execution should be recorded into a COMPOSITION that references those ACTION(s) and OBSERVATION(s). The INSTRUCTION of a test could reference to a device that should be used on the test, but during the test maybe another device was used, and that should be part of the ACTION that executes the INSTRUCTION. Does this makes sense to you? Please correct me if I'm wrong. My student detected some oftalmologic concepts that are not in the CKM, maybe I can put you both in contact to collaborate on the modelling of those concepts. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: gbacelar at gmail.com Date: Sun, 17 Jun 2012 10:03:15 +0100 Subject: Re: An ACTION or INSTRUCTION referencing an AGENT, is it possible? To: openehr-clinical at lists.openehr.org Hi Pablo, I'm an ophthalmologist and would be gladful to help. There are some issues about the archetype class and the nature of the test. As it is a study test it must be considered the existence ?of an intervention. If it does not include, so the most appropriate would be to record as an OBSERVATION archetype for the test. If it includes an intervention, then the most appropriate is to record as ACTION. For both situations?use the Device CLUSTER on the CKM to record the device, remembering this archetype is not adequate to record a substance (e.g.?fluorescein). To record the device that should be used for the test?at an INSTRUCTION archetype, also consider the?element Description of Procedure?of Procedure Request?archetype on CKM, which could be used to specify the device. I hope it was helpful. -- Gustavo Bacelar MD + MBA + Med Informatics gustavobacelar.com +351 91 203 2353 +55 71 8831-2860 Skype: gustavobacelar ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org
Regarding the role of ITEM_STRUCTURE
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 EVENTITEM_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_EVENTCLUSTER 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 Heardsam.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
Regarding the role of ITEM_STRUCTURE
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 EVENTITEM_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_EVENTCLUSTER 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 Heardsam.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
Regarding the role of ITEM_STRUCTURE
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 EVENTITEM_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_EVENTCLUSTER 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 Heardsam.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
