I am reading 1.0.2 IM and it says CARE_ENTRY, not GENERIC_ENTRY. which one is the good one? By the way, both ENTRY and CARE_ENTRY are abstract in openEHR. I don't think you could only make ENTRY non-abstract without making CARE_ENTRY non-abstract too (I think it has no sense to inherit an abstract class from non abstract). Looking at CARE_ENTRY, I don't really get why ADMIN_ENTRY is not able to inherit from it. 'protocol' attribute meaning changes according to the instantiated class (as the pdf says, describes 'how' was arrived the information) and it is optional, as 'guideline_id'. Why don't make ADMIN_ENTRY as a child of CARE_ENTRY as protocol could be also used (why not using it for stating how was the ADMIN_ENTRY information arrived? or what where the social/legal requirements to led to this entry). 'guideline_id' could be used to state if this ADMIN_ENTRY was a result from a clinical guide step (I can be wrong at this one, but that's what I understand from the specifications). And the specifications say that this one is only used 'if relevant', so it isn't always used anyway.
If you do this you can remove CARE_ENTRY and focus on the ENTRY itself :) 2011/12/16 Thomas Beale <thomas.beale at oceaninformatics.com>: > > 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 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. > > - thomas > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
