Hi David, On 16/12/2011 18:48, David Moner wrote: > > >> I suspect this is an intentional difference between current 13606 and >> openEHR; to faithfully capture the current (incompatible) situation >> versus aiming to change the current situation. Can those different >> goals really meet in one RM or do we need two standardized RMs? >> http://dilbert.com/strips/comic/2011-08-02/ > > I should perhaps point out that openEHR has a perfectly usable > generic Entry type > > <http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html> > that does the same as 13606 Entry. This Entry type is designed for > weakly structured data. > > > It is not exactly the same as what I was proposing. The GENERIC_ENTRY > as is now only complicates de model by creating a standalone branch.
do you mean in the inheritance tree? Well, that's true, but that's normal object modelling... > Instead of that, I would prefer to look for a solution where the ENTRY > class is directly instantiable. Thus, an implementer can choose to use > it if the lower OBSERVATION, INSTRUCTION, etc. classes do not > accommodate his needs. Moreover, it would be easy to cast an ENTRY > instance into any of its descendants when needed. I think this is looking at it from too low a level. The structures of ENTRY, OBSERVATION, INSTRUCTION etc are quite different. The ENTRY concept in openEHR does not on its own define a meaningful object; the structure of the data have to be defined in specific subclasses. The descendants (today) are: ADMIN_ENTRY, OBSERVATION, EVALUATION, INSTRUCTION, ACTION and GENERIC_ENTRY. So GENERIC_ENTRY is just one of the sibling possibilities for representing data. (I realise that it's a bit annoying that we use 'ENTRY' as the abstract parent type, whereas 13606 uses it as the name of the concrete type, but I can't see any easy way around that). I think this is a normal modelling outcome. I can't see how in openEHR, the ENTRY class could do its main job, which is to define the common attributes (we can think of them as meta-data attributes) of all ENTRY types, and also have some kind of commitment to data, which would then be somehow redefined to other specific data structures somehow - casting only works when the physical data don't change, but are interpreted differently (and anyway, casting should always be avoided - it means the software is potentially violating the type system). The normal OO approach is that a parent class such as ENTRY stays abstract, and its children exhaustively define the possibility space. However, what I can imagine is a function on ENTRY, something like 'as_standard_representation: CLUSTER', which /generates /a standardised CLUSTER/ELEMENT hierarchy of the 13606 variety (complete with logical data structure markers to indicate the intention of lists, tables etc). This would allow the openEHR model to stick to normal OO modelling conventions, but also have a fully formally defined transform to the simple CLUSTER/ELEMENT structure from each of its ENTRY subtypes. Calling this function during a traversal of a COMPOSITION would enable something very close to a 13606 COMPOSITION to be generated. As I mentioned in another post, I think a greater challenge is dealing with the differences in the base classes - my notes on this so far are here <http://www.openehr.org/wiki/display/spec/openEHR+%7E+13606+2012+revision+-+alignment+proposals>. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111216/02eabe28/attachment.html>
