2006/5/16, Sam Heard <sam.heard at oceaninformatics.biz>: > > Mattias > > I looked at this document > http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/rm/data_structures_im.pdf > and it says that ITEM_TABLE.columns attribute has been changed to rows in > the amendment record (CR-000207). However, the change hasn't actually been > commited in the document, so maybe the change was lost somehow... > > rotated is an archetype only attribute which allows rotated tables to be > > displayed - this is like a pivot table in Excel. > > > > Is this attribute documented somewhere? I don't really understand why this > attribute is allowed under ITEM_TABLE when it is not specified for the > actual data structure. > > If a table is rotated it means that the values in one column become > columns headings, with the columns becoming rows. E.g. > > Reflexes: > laterality knee ankle > left ++ +/- > right + + > > When this is rotated it becomes: > left right > knee ++ + > ankle +/- + > > This is called a pivot table and allows rows of the same data type rather > than columns which is the usual. This is more than display although the > semantics are not effected. Infact, all tables in the editor are rotated at > the moment as this is by far the most common way of presenting data in > medicine. >
Thanks for your answer Sam, I have another question about this rotated attribute. Why do we need it when it is only a question of how to display the actual data contents? Shouldn't that be decided by an actual user rather than an attribute? I don't think the ADL contents and underlying structure of an ITEM_TABLE should change even if it were possible to switch between pivot tables and ordinary tables. Now to the important question that I'd been thinking about. The specifications of ITEM_TABLE say that the rows attribute should have a List<CLUSTER> as children but I don't see the point with this. Why do we need several clusters as rows since a table with rows that each have different column headings is impossible to create? If the rows attribute had List<ITEM> as children it would make much more sense. Also, It wouldn't be a bad idea to have rows and column headings as separate attributes instead of having the column headings of the table in the first element under the rows attribute. By the way, I don't think it's usable to show the table data types as columns since that would probably only confuse the user compared to how tree and list are displayed. So for this part I agree with you. Number of key columns is in the new specifications. > > > This allows unique keys and means that the values of the combined keys > have to be unique - if this is not set then there is no restriction on > uniqueness. > Why is this attribute's leaf value an integer? I don't understand this part. Does this mean that if the user creates two rows with the same name, for example "knee" then the uniqueness wouldn't be preserved and then another key column would have to be added... Maybe the table should always have an extra column that contain unique keys (as for the ordinal constraint). Hoping for a quick answer. Cheers, Mattias > This attribute is also missing in the document I mentioned above. By the > way, could you explain this attribute to me? Should the users of an > archetype editor be able to change the existence and/or contents of this > attribute with some GUI component or should it be done automatically > whenever new columns are added that contain actual data (ELEMENTs)? > > Tom will be getting to this I think as I did an edit some time ago..Sam > > > Cheers, > > Mattias > > Hope this is OK. > > > > Cheers, Sam > > > > > > > > Mattias Forss wrote: > > > > Hello, > > > > I'm trying to add support for ITEM_TABLE in the Java Archetype Editor > > and I have looked at the only archetype I've found that contains a data > > structure like this. It is > > openEHR-EHR-OBSERVATION.tendon_babinski_reflexes.v1.adl and it can be > > found here http://oceaninformatics.biz/archetypes/. When I compared the > > attributes for the ITEM_TABLE in the data structures specifications (found > > here > > http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/data_structures_im.pdf > > ) with the ones that existed in the archetype I saw that the attributes > > had nothing in common. Maybe someone can explain to me how the ITEM_TABLE > > look like once and for all :-) > > > > The archetype looks like this: > > > > ITEM_TABLE[at0003] matches { -- structure > > > > //// COMMENT: The attributes below adhere to the ITEM_TABLE that you get > > when you create a table structure in the Ocean Archetype Editor, but I > > haven't seen any of these three attributes specified anywhere. I would be > > glad if anyone could point them out to me. > > > > rotated matches {True} > > number_key_columns matches {|1|} > > rows cardinality matches {0..1; unordered} matches { > > CLUSTER[at0050] occurrences matches {0..2} matches { -- row > > items cardinality matches {7; ordered} matches { > > > > //// COMMENT: This first element has a CODED_TEXT which contains coded > > terms that are represented as columns in the Ocean Archetype Editor. > > > > ELEMENT[at0012] occurrences matches {0..1} matches { -- > > row_head > > value matches { > > CODED_TEXT matches { > > code matches { > > [local:: > > at0011, -- Left > > at0013] -- Right > > } > > } > > } > > } > > > > //// COMMENT: This element and all succeding elements are represented as > > rows in the Ocean Archetype Editor. > > > > ELEMENT[at0004] occurrences matches {0..1} matches { -- > > Biceps > > value matches { > > ORDINAL matches { > > value matches { > > ... > > } > > } > > } > > } > > ------------------------- > > > > > > But in the specification the ITEM_TABLE it looks like this: > > > > CLASS ITEM_TABLE > > Purpose > > Logical table data structure, in which columns are named and ordered. > > Some columns > > may be designated 'key' columns, containing key data for each row, in > > the > > manner of relational tables. This allows row-naming, where each row > > represents > > a body site, a blood antigen etc. All values in a column have the same > > data type. > > Use Used to represent any data which is logically a table of values, > > such as blood > > pressure, most protocols, many blood tests etc. > > MisUse Not used for time-based data, which should be represented with > > the temporal > > class HISTORY. The table may be empty. > > > > Entry type. > > Inherit ITEM_STRUCTURE > > Attributes > > 0..1 columns: List<CLUSTER> > > Physical representation of the table > > as a list of CLUSTERs, each containing > > the data of one column of the > > table. > > > > > > Hope someone can help me. > > > > Regards, > > > > Mattias Forss > > > > > > -- > > Dr. Sam Heard > > MBBS, FRACGP, MRCGP, DRCOG, FACHI > > > > CEO and Clinical Director > > Ocean Informatics Pty. Ltd. > > <http://www.oceaninformatics.biz/>Adjunct Professor, Health > > Informatics, Central Queensland University > > Senior Visiting Research Fellow, CHIME, University College London > > Chair, Standards Australia, EHR Working Group (IT14-9-2) > > *Ph: +61 (0)4 1783 8808* > > *Fx: +61 (0)8 8948 0215* > > > > > > > > -- > Dr. Sam Heard > MBBS, FRACGP, MRCGP, DRCOG, FACHI > > CEO and Clinical Director > Ocean Informatics Pty. Ltd. > <http://www.oceaninformatics.biz/>Adjunct Professor, Health Informatics, > Central Queensland University > Senior Visiting Research Fellow, CHIME, University College London > Chair, Standards Australia, EHR Working Group (IT14-9-2) > *Ph: +61 (0)4 1783 8808* > *Fx: +61 (0)8 8948 0215* > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060516/2b4eef39/attachment.html>
