2006/5/16, Sam Heard <sam.heard at oceaninformatics.biz>: > > Mattias > > Quick response.. > > 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? > > Well, we do not think it is only a matter of display - although it could > be seen as such. If the attribute is not present then it is not possible to > determine whether to display it as a pivot or not. The property of > DV_QUANTITY is only in the archetype as well and determines valid units - it > is a similar sort of issue. >
Hi again Sam, I wouldn't mind to ignore and not save this attribute until the different display modes are supported in the Java archetype editor. A missing rotated attribute should probably not cause errors for the Ocean archetype editor? 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. > > Well, each row is a set of elements (as a cluster) - the table is a > special case in that each cluster can only have elements (invariant). Each > row is a cluster - which is in effect the definition of each column. So you > need a list of clusters to get rows. > So then I guess the ADL is constructed according to how the first table looks like in your example above (since pivot should not affect the structure)? In that case I believe that the ITEM_TABLEs that are created by the Ocean editor aren't following the specifications, since no matter how many rows (e.g. left, right) you add, they will only be contained within one cluster only. There is accordingly no way to create an ITEM_TABLE that has more than one cluster under the rows attribute. Furthermore, each row that is added should create a cluster that has an at-code with its name and in the pivot display mode the clusters names will be the column headings. Right? Hope we can sort this out. Regards, Mattias PS. You forgot my question about key columns. See below. 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. > > We can take this a lot further with time and more power in the archetype > editor. Cheers, Sam > > > 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* > > > > > > > > -- > 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/8fad5d09/attachment.html>
