Hi Eric I would always use CLUSTER rather than ITEM for the data and other features in other classes. The alternative is to have far more versions of archetypes as if you allow element at this point you have to version when cluster is necessary (which you could argue it always will be at some time in the future).
Cheers, Sam > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Erik Sundvall > Sent: Monday, 15 November 2010 6:20 PM > To: For openEHR technical discussions > Subject: openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and > ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?) > > Hi! > > I now noticed that my message with the pencil-modified UML diagram > bounced four days ago because of attachment size. Now it's edited > below to only include link to the image > http://www.imt.liu.se/~erisu/2010/openEHR/RM-pencil.jpg > > After that mail was written Heath indicated that one of Tom's reasons > for keeping e.g. TABLE as a class is that it would introduce rigour > etc. This will only be true for GUIs connected to purely object > oriented RM-implementations using DBC or other mechanisms to implement > what the specs say in the free text and "invariant" sections. The same > functionality might just as well be implemented in a separate > validator analysing the cluster structure before letting it in to the > system. > > Also, in many GUI frameworks there is already built in support for > creating adapters to go between the GUI frameworks' table model and > your own data model - so the extra utility of having all those > TABLE-methods in the RM is questionable. > > I can see the problem with breaking changes in a 1.0.3 release - that > goes against conventions, but I think the change should be included in > discussions regarding the road map to 1.1 since it, as Tom says, is > such an easy conversion in this case. > > Now to the original mail that bounced, Thu, Nov 11, 2010 at 12:41: > > Hi! > > On Thu, Nov 11, 2010 at 08:30, David Moner <damoca at gmail.com> wrote: > > ... University of Murcia. > > An approach for the semantic interoperability of ISO EN 13606 and > OpenEHR > > archetypes. > > David: Thanks for an interesting reference and thanks to the Murcia > team, I hope you don't mind harmonisation suggestions that could make > your conversion research easier ;-) > > Sam: your overall thoughts and intentions I think have gotten through > to us tech-people, but your more detailed remodelling suggestions do > sound a bit confusing. > 1. You are not using correct names for some classes & packages. > 2. If we are looking for simplification, then removing classes must be > more desirable than switching inheritance order. > If you find that my suggestions are missing something, then feel free > to comment (preferably after talking to some software-person if you > have one nearby). Since current patient data is versioned and includes > RM-version it is actually possible to non-backward-compatible changes > in openEHR and keep old data accessible. In practice that complicates > GUIs etc so I'd guess that many deployments that want to upgrade to > the simplified version would import and auto-convert the old > structures to new ones if there is a change like this. > 3. What do you mean by pivot in tables in this case? Is it just that a > table is rotated somehow or is it pivot table as in > http://en.wikipedia.org/wiki/Pivot_table. Is it something that is not > supported in openEHR currently? Is it primarily about GUI or semantics > (or both)? > > All: I ran my UML image through the fast and famous pencil remodelling > tool and [...] put the scanned result at: > http://www.imt.liu.se/~erisu/2010/openEHR/RM-pencil.jpg > > As you (hopefully) can see, six classes are removed and attributes > previously referring to ITEM_STRUCTURE or ITEM_TREE would now instead > refer directly to ITEM. All this hopefully without losing semantic > expressibility power in openEHR data. > > In the class PARTY_RELATIONSHIP in the demographics package, in some > earlier versions of the RM (like the one the diagram is based on) the > attribute "details"points to a DATA_STRUCTURE (see also > http://www.openehr.org/uml/release- > 1.0.1/Printable/Printable101.html#_9_0_76d0249_1109068473559_951109_458 > 9 > ) this seems to have been a mistake rather than a design choice and in > the latest specs it points to ITEM_STRUCTURE instead. I think this > means that the class DATA_STRUCTURE could also be removed if it's > method "as_hierarchy" is pushed down to the HISTORY class instead. > HISTORY and ITEM would then inherit directly from LOCATABLE. Are these > assumptions about DATA_STRUCTURE correct or am I missing something? > > One of the things left to discuss is the name of the new marker > attribute in ITEM (or possibly CLUSTER), probably of type > DV_CODED_TEXT and it's permissible valueset. I assume "list" and > "table" are two permissible values at present. The default for a > CLUSTER if the marker attribute is not used, could be to be > interpreted as a tree. Using an ELEMENT by itself I presume would be > the default way of expressing a what ITEM_SINGLE previously did. > Another way is of course to always use the marker attribute and extend > the set with "single" and "tree". > > If we for some reason in the future would find the need to explicitly > express other structures than single, list, tree and table, by > allowing more marker values, then the change to the RM, querying, > storage etc would be minimal, but GUIs would of course need change. > > Many of the methods (not attributes) in the RM are of limited use in > implementations or parts of implementations (e.g. storage & messaging) > that are more data-centric that object-orientation-centric, so I think > it's generally good if some of the helper methods like the ones in > ITEM_TABLE can be moved out from the core to some optional > utility-package instead (if the need for having them standardised > remains). If looking outside the item_structure package this actually > already seems to be the case - there are pretty few methods. Good. > > Best regards, > Erik Sundvall > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 > > P.s. Tim, I'd be interested how these changes suggestions, in your > wiew, relate to "Keep everything as simple as possible; but no > simpler." that you qoute on the philosophy part of > http://www.oship.org/ > > On Thu, Nov 11, 2010 at 00:22, Sam Heard > <sam.heard at oceaninformatics.com> wrote: > > ... > > 1. Restrict a cluster to a list; and > > 2. Create a consistent representation of tables which have allow > pivots as > > this is the main form required for clinical data (row headings and > column > > headings). > > > > I believe that in the interests of existing data we made > DATA_STRUCTURE > > inherit from CLUSTER - maintain LIST and TABLE as openEHR classes and > > deprecate TREE and SINGLE. This would keep things moving ahead. The > data > > attribute would then be a cluster rather than an item_structure. > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
