2006/5/17, Thomas Beale <Thomas.Beale at oceaninformatics.biz>: > > Sam Heard wrote: > > Mattias > > > > This is a good discussion with some issues that need to be taken > > further. The problem I face as a clinician is that tables in medicine > > are often presented with the same data types across the row - and with > > the values in the first column as column headings. This is a standard > > pivot table in Excel or Access and is a common data presentation issue > > - which SQL can perform. > I don't have a problem with the rotate idea - if clinical people want it > and it makes sense, then it is needed. But - most likely need add an > attribute to the reference model. Here's the problem if we don't: > - archetypes only constraint data that is created > - whether a table is rotated or not becomes important at display / > interpretation time of the _data_, not the archetype. > - so any mention of the rotate attribute in the archetype must lead to > some flag being set in the data in order to get the behaviour at runtime > > The only way out of this is that we take the line that the archetype > must always be available at the time the data are used, in whatever > circumstance. Technically it isn't hard to engineer this in nice > controlled OO environments, but consider that the data might be > processed into various kinds of good-quality or not-so-good quality XML, > HTML, PDF, other custom formats, where the corresponding archetypes > might not be easily available or needed. I would guess that many > applications should be able to process e.g. path results as openEHR > structures without needing to look up the archetype. So my conclusion is > that we should always ensure that the data can stand alone and remain > meanggul.
I cannot agree more with that, so the best thing to do is probably to include the attribute into the RM class if there is a need for a rotated attribute. However, at this point I don't see that there is a huge need for it since the data could always be presented in a pivot table but then some might disagree with me, I'm not the clinician here. Now - in the case of reflexes, visual acuity and other tabular data, one > (presumably) could argue that the data are perfectly comprehensible even > with no 'is_rotated" flag set; others might argue the opposite. I > personally don't see a problem with including a flag in the RM > ITEM_TABLE class, but we need to do it now. > > > > I do not believe it is possible to determine from data alone when it > > is appropriate to rotate a table for presentation. This is why I have > > pushed to have it in the editor. I think a lot of clinicians will find > > it difficult to accept information in unrotated form as it is not how > > they do it now for many situations. There are many situations where > > this is not the case as well. > > > > I agree that the right thing to do is put this in ADL if we want to - > > we could just say we leave it to the display - but I think this will > > mean clinicians find it hard to build the tables they need. We can > > experiment some more with this as it is an ADL issue rather than a > > reference model issue. I would suggest that you ignore it if you like > > for the moment (with the result of frustrating the clinicians) or take > > the attribute as it is and agree to put it into ADL. > do you mean the reference model Sam - it can't be "put into ADL" unless > we create a C_ITEM_TABLE type, which I don't think we should have to > do.... There should probably be enough to use the attribute in the ITEM_TABLE. What I don't see at this point is if the most common way to display table data is pivot tables, then will there ever be cases when the data must explicitly be shown in an unrotated form? But what about the other problem Mattias pointed out - we don't have an > attribute "key-columns" in ITEM_TABLE either. Previously we specified > that if there was a "(key)" in the name string of a column, it would be > a key column, but this is open to abuse by buggy software. The > alternative is to add another attribute into ITEM_TABLE that contains a > list of key column indexes or names. But I would like to be sure that > this feature is really needed in table archetypes...is it? If one thinks about an ordinary SQL query to some database that contains an inventory of for example some equipment, then there might occur several records of the same name and therefore these must be separately identifiable with unique keys in order to get the specific equipment from the database. Then what options are there in ADL? If we know that an ITEM_TABLE always has some column that is uniqe then that should be mentioned as the key so that the process of creating the RM data will not allow creation of data that don't have uniqe identifiers. It might even be the case that there have to exist several keys but not as long as there isn't a need for column headers with the same name. Regards, Mattias - thomas > > -- > > ___________________________________________________________________________________ > CTO Ocean Informatics (http://www.OceanInformatics.biz) > Research Fellow, University College London (http://www.chime.ucl.ac.uk) > Chair Architectural Review Board, openEHR (http://www.openEHR.org) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060517/66c3cccd/attachment.html>
