openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
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
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
You can find here the related work to this problem from our colleagues at the University of Murcia. An approach for the semantic interoperability of ISO EN 13606 and OpenEHR archetypes. Catalina Mart?nez-Costa, Marcos Men?rguez Tortosa, Jesualdo Tom?s Fern?ndez-Breis Journal of Biomedical Informatics 43(5): 736-746 (2010) David 2010/11/10 Thomas Beale thomas.beale at oceaninformatics.com For those unaware, we started the openEHR/13606 mapping herehttp://www.openehr.org/wiki/display/stds/openEHR+to+ISO+13606-1%2C+ISO+21090+mapping, and you can see if you look carefully that there is an initial description of where a purely automated conversion algorithm that Erik is talking about goes. -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2010/edbee82b/attachment.html
Uppercase and lowercase at archetype nodes
David, the AOM certainly doesn't care, you are right about that. Since we treat that as the normative form, we should logically say it is the same as UML, i.e. a guideline for readability. I think the ADL parsers do use this convention at the moment to match class and attribute names more easily, but I imagine this dependency could be removed as well. I will need to investigate on this. - thomas On 11/11/2010 07:21, David Moner wrote: No comments or opinions about this? 2010/11/4 David Moner damoca at upv.es mailto:damoca at upv.es While working with archetypes for different reference models we have faced a problem regarding the uppercase/lowercase rules for naming archetype nodes at ADL. The ADL specifications imposes the following rule: A type name is any identifier with an initial upper case letter, followed by any combination of letters, digits and underscores. A generic type name (including nested forms) additionally may include commas and angle brackets, but no spaces, and must be syntactically correct as per the UML. An attribute name is any identifier with an initial lower case letter, followed by any combination of letters, digits and underscores. Any convention that obeys this rule is allowed (ADL 1.5 draft, page 26). However, at the UML specifications I have only found the following style guidelines: Capitalize the first letter of class names (if the character set supports uppercase) and Begin attribute and operation names with a lowercase letter. But I understand these as style recommendations and not as a mandatory specification since they are accompanied with others such as: Center class name in boldface and Put the class name in italics if the class is abstract. In any case, as we all know, object-oriented programming is not just UML. We can use other modeling tools or programming languages that do not impose the uppercase/lowercase rule. And moreover, at the AOM specifications I cannot find any reference about the fact that the rm_type_name String should begin with uppercase or the rm_attribute_name String with lowercase. For example, all the attributes of the CDISC ODM standard are defined starting with an uppercase. So, from a generic perspective of the dual modeling process, I think that archetypes (or more specifically, ADL) should not impose rules in this aspect. What's your opinion? David * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2010/c88e1651/attachment.html
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
On Thu, 2010-11-11 at 08:52 +0930, Sam Heard wrote: 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! While a lot has been learned. The universe of people actually developing archetypes is rather small when compared to healthcare professionals globally. I believe that Tom will concur that those structures were all included because they make sense from an engineering stand-point. At this point in the evolution, I do not believe that we even know all that we don't know about building knowledge structures. When Albert Einstein said; Make everything as simple as possible, but no simpler. he likely stressed the last phrase. As far as the comment about the ENTRY sub-classes intruding on the ontological space. They do not intrude, that is a point of intersection where one represents knowledge and the other gives it structure. Both are a requirement for interoperability. My 2 cents. --Tim -- *** Timothy Cook, MSc Project Lead - Multi-Level Healthcare Information Modeling http://www.mlhim.org LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook You may get my Public GPG key from popular keyservers or from this link http://timothywayne.cook.googlepages.com/home -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2010/600ba169/attachment.asc
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
On 11/11/2010 12:32, Tim Cook wrote: As far as the comment about the ENTRY sub-classes intruding on the ontological space. They do not intrude, that is a point of intersection where one represents knowledge and the other gives it structure. Both are a requirement for interoperability. well said My 2 cents. --Tim * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/2010/5a266d66/attachment.html
