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. 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.... 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? - 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)
