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