Hi All The HISTORY class is an absolute godsend - could be a bit simpler but really it is one of the reasons openEHR is going ahead. Once people get to use the INSTRUCTION and ACTION classes there will be another leap of understanding. Our recent work with the instruction index is making managing health information in a distributed environment possible.
We have learned a lot over the past few years - but I am a practicing clinician and the following should be read with that in mind! There are two things that we cannot achieve with ADL alone: 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. This would respect the existing data and allow the change of archetypes over time but existing data would remain compatible (except ITEM_SINGLE which is not used). It would mean a change to the RM in the area of data_structure. I do not see any need for Item_Structure and History to inherit from this class and I do not believe this inheritance is used to advantage within the RM. So changing Instruction.activity.description, Observation.History.Event.data, Action.description and evaluation.data to cluster would be the first step. History would be a stand alone locatable class and ITEM Structure inherit from cluster. Functions associated with ITEM_TREE are relevant for CLUSTER and could be subsumed. The functions of ITEM_LIST could also be subsumed although the return value would be ITEM (The ITEM_LIST could provide the constraint of these functions to ELEMENT). The 'as hierarchy' feature becomes the 'items' of CLUSTER. ITEM_TABLE has a lot of features and no data - I believe that it needs some added data around the pivot expression. While this may be considered only a display feature, it is critical to the interpretation. That is my change request and one that will align openEHR and CEN 13606 more deeply with benefit to both. It will make CLUSTER archetypes available as the root for some ENTRIES (what is called embedded in the Archetype Editor) and as further down the tree in others. These will be available for CEN and openEHR. There is one more thing I would advocate for: Calculation of the max and min cardinality of the cluster and not setting it. This is problematic from the point of view of future revision. To illustrate: If I have one mandatory element (1..1) and four optional ones (0..1) then people argue that I could set the cardinality of that list to 1..5. The problem is if next week one of the optional ones becomes 0..* - quite likely with terminologists about. Now the cardinality is wrong and we need a new version. I would argue that we should not set the cardinality of clusters unless we are forcing a choice between two sets - Tom has been looking at a way to do this anyway and if that arrives I would argue that we should not allow cardinality statements in clusters at all. They are redundant. Cheers, Sam Cheers, Sam > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of Erik Sundvall > Sent: Thursday, 11 November 2010 3:26 AM > To: For openEHR technical discussions > Subject: Re: openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc > and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?) > > Hi! > > On Wed, Nov 10, 2010 at 17:26, tom.seabury at nhs.net wrote: > > My simple reading of this is that what are currently trees would > instead be > > expressed as a sparsely populated arrays - is that the point? > > Just to clarify it is has not already been clarified enough by others: > Everything that is currently a tree in openEHR archetypes would most > likely remain a tree. What would change is that the rarely used class > ITEM_TABLE would no longer be needed. The data in an ITEM_TABLE > already today is represented as a cluster internally. > > So, no, what are currently trees won't become sparsely populated > arrays. > > Hope that helps. > > Best regards, > Erik Sundvall > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 > > P.s. to Tom: those PAINFULLY_LONG_CLASSNAME_SUGGESTIONS were only > intended to make a point, not as a final suggestion. openEHR probably > does not need to change anything as long as the potential confusion is > well described in specifications and presentations. (See the post > http://www.openehr.org/mailarchives/openehr-clinical/msg01353.html for > details again.) If CEN/ISO still have problems with the names after > such an explanation then one could assume that they will be the ones > suggesting better alternatives. > > --- warning, irony below this line --- > > I remember the infection around the word "ontology" at a > SemanticMining event where it became the "o-word" :-) Perhaps the > OBSERVATION will meet the same fate? O-ENTRY? And EVALUATION -> > E-ENTRY? > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
