openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hi Eric I would always use CLUSTER rather than ITEM for the data and other features in other classes. The alternative is to have far more versions of archetypes as if you allow element at this point you have to version when cluster is necessary (which you could argue it always will be at some time in the future). Cheers, Sam -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Monday, 15 November 2010 6:20 PM To: For openEHR technical discussions Subject: openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?) 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 detailspoints to a DATA_STRUCTURE (see also http://www.openehr.org/uml/release- 1.0.1/Printable/Printable101.html#_9_0_76d0249_1109068473559_951109_458 9 ) 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
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hi Zam! :-) I was merely trying to keep most of the same semantic power in the change suggestion as when the abstract ITEM_STRUCTURE (that subsumed ITEM_SINGLE, ITEM_TREE etc) was used rather than ITEM_TREE in various places in the RM model. But you might be completely correct that it would be better to point to CLUSTER rather than it's abstract superclass ITEM in some or perhaps even all places in the model where ITEM_STRUCTURE is used today. I guess other people on the list will have additional good ideas about this. Did you have any more info (or link) regarding the pivot semantics/requirements by the way? Best regards, Erik(!) Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 On Mon, Nov 15, 2010 at 22:29, Sam Heard sam.heard at oceaninformatics.com wrote: Hi Eric I would always use CLUSTER rather than ITEM for the data and other features in other classes. The alternative is to have far more versions of archetypes as if you allow element at this point you have to version when cluster is necessary (which you could argue it always will be at some time in the future). Cheers, Sam
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
On 13/11/2010 00:07, pablo pazos wrote: Hi, I would also concur with your statements about the ENTRY sub types, as Sam mentioned we have built an INSTRUCTION index that tracks the current state/care flow step of instructions and their associated ACTIONs providing efficient access to this information. This complexity may be tackled with a good Service Model ,when it's completed. I think that we are looking too much at the model to solve all our problems, but we have a Service Model in draft status that can help to solve issues on the using of the model. * * this is a good point actually. The general idea for things like the Instruction Index is to make it a combination of specific openEHR structures, and rules for using those structures (e.g. about where/when LINKs have to be created etc). To make this properly useful, the structures and rules should be mostly hidden, and instead a business service exposed, specific to this function, which we can think of as 'care plans'. There are other services/APIs that can be defined for specific business purposes as well, which enable the application programmer to easily create and interrogate complex underlying data. Hopefully we will see a draft description of the Instruction Index, and some ideas for APIs like 'care plan' and so on. It would be very interesting to see other service models in this area. - thomas beale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101115/d3748a1f/attachment.html
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
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 detailspoints 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
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hi Erik, Interestingly, this is the same proposal I put to Thomas about 8 years ago and I go the same response. I do understand his rationale for making a table a class rather than an attribute with additional conformance statements to ensure a table is represented consistently, but we know how well implementation guides get followed by developers. In addition we would be missing the functions on the class that which make it more pertinent. My concern at this point is that we do already have patient data being collected using openEHR and collapsing the ITEM_STRUCTURE would be a breaking change, I think it would need to be a 1.1 or 2.0 change if it was going to happen. Having said that, looking at the requirements from the clinicians it seems that the need for TABLE is actually at the ITEM level rather than the DATA_STRUCTURE level and Sam's proposal of extending CLUSTER for TABLE and LIST (although I would suggest inheriting from the abstract ITEM) would not be quite as bad as we can simulate the same levels of structure for legacy data (although the class names would still be different unless we included all of the ITEM_STRUCTURE types as a type of ITEM to retain backward compatibility). I would also concur with your statements about the ENTRY sub types, as Sam mentioned we have built an INSTRUCTION index that tracks the current state/care flow step of instructions and their associated ACTIONs providing efficient access to this information. The effort required to implement this would have been much greater if these classes were not specifically modelled. I guess as openEHR penetrates the market, the more likely CEN 13606 would be updated with these enhancements. To be honest I think this is the right standards process, standardising of implementations that are known to work in practice. I am sure we will learn more and improve the ENTRY subclasses further before they go into the CEN standard, then the standard will be more useful. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Wednesday, 10 November 2010 11:16 PM To: For openEHR technical discussions Subject: openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?) Hello again! Here comes a more complete version of the mail I happened to send unfinished this morning. I hope you don't mind me breaking out a side thread with concrete harmonisation suggestions. First an openEHR change request (CR), then an ISO 13606 change request. 1. item_structure (openEHR CR) Regarding ITEM_TABLE (and the other classes in the openEHR item_structure package) there was a change request from Sam that went pretty unnoticed by a while ago, see: http://www.openehr.org/mailarchives/openehr-technical/msg04994.html I'm not saying we should go exactly by the letter in Sam's CR, but somehow skipping the things currently in item_structure package in openEHR could simplify understanding and slightly reduce implementation complexity. (It might also shorten paths in object traversal (and thus storage depth) one step - a possible performance gain in some implementations.) Probably letting the data attribute of openEHR ENTRY subtypes point straight to ITEM (or possibly CLUSTER) would be best. If something should be suggested to be shown in a GUI as a table, list (or other non-tree formalism) it might be possible to define using any of the following... a) ...a GUI directive/hint in archetype annotations similar to the directives shown by Koray Altag at Medinfo 2010, see slide 30 and onwards in http://www.openehr.org/wiki/download/attachments/5996988/3_GastrOS_Atalag.pd f b) ...a new attribute in the CLUSTER or ITEM class (with accompanying controlled vocabulary). c) ...some other way I have not thought of Suggestion a) means the directive/hint might not be available in instance data, only in the archetype, that might be bad for safety reasons. If b) is chosen, then that new attribute could of course be archetyped if you want the information in the archetype as Andrew suggests. Shortcuts to UML diagrams for comparison: CEN/ISO: http://www.chime.ucl.ac.uk/resources/CEN/EN13606-1/13606-1Diagramsv3e.pdf openEHR: http://www.imt.liu.se/~erisu/2008/openEHR-tour/print/openEHR-RM-1.0.1-may23- 17.54.gif I'd suggest that this change, after refinement and discussion with openEHR implementers followed by successful prototype implementation, be introduced as soon as possible before there is too much real patient data stored using the present item_structure package. Perhaps it can be introduced at the same time as ADL 1.5 and enhancements of the LINK class which anyway will require code changes. 2. OBSERVATION et. al. (ISO 13606 CR) == I can understand the CEN/ISO-urge for simplification of the openEHR ENTRY package if the main intention of the standard
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
On 11/11/2010 23:14, Heath Frankel wrote: Hi Erik, Interestingly, this is the same proposal I put to Thomas about 8 years ago and I go the same response. I do understand his rationale for making a table a class rather than an attribute with additional conformance statements to ensure a table is represented consistently, but we know how well implementation guides get followed by developers. In addition we would be missing the functions on the class that which make it more pertinent. My concern at this point is that we do already have patient data being collected using openEHR and collapsing the ITEM_STRUCTURE would be a breaking change, I think it would need to be a 1.1 or 2.0 change if it was going to happen. probably 2.0. The nice thing is, even if it is a breaking change, the data migration of older data (or equivalent on-the-fly processing) would be very simple. Having said that, looking at the requirements from the clinicians it seems that the need for TABLE is actually at the ITEM level rather than the DATA_STRUCTURE level and Sam's proposal of extending CLUSTER for TABLE and LIST (although I would suggest inheriting from the abstract ITEM) would not be quite as bad as we can simulate the same levels of structure for legacy data (although the class names would still be different unless we included all of the ITEM_STRUCTURE types as a type of ITEM to retain backward compatibility). I would also concur with your statements about the ENTRY sub types, as Sam mentioned we have built an INSTRUCTION index that tracks the current state/care flow step of instructions and their associated ACTIONs providing efficient access to this information. The effort required to implement this would have been much greater if these classes were not specifically modelled. I guess as openEHR penetrates the market, the more likely CEN 13606 would be updated with these enhancements. To be honest I think this is the right standards process, standardising of implementations that are known to work in practice. I am sure we will learn more and improve the ENTRY subclasses further before they go into the CEN standard, then the standard will be more useful. exactly! - thomas * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101112/04d04985/attachment.html
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hi, I would also concur with your statements about the ENTRY sub types, as Sam mentioned we have built an INSTRUCTION index that tracks the current state/care flow step of instructions and their associated ACTIONs providing efficient access to this information. This complexity may be tackled with a good Service Model ,when it's completed. I think that we are looking too much at the model to solve all our problems, but we have a Service Model in draft status that can help to solve issues on the using of the model. The effort required to implement this would have been much greater if these classes were not specifically modelled. Obs., Eval., Inst. Act. are a great ontologic division of the clinical information, with them it'seasy to understand and easy to map to real concepts, I doubt that removing them from the model can help in any way. If these classes weren't modelled, we have to model them in all of our implementations, that's a waste of good modelling. just a couple of opinions. Kind regards, Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101112/619f5ade/attachment.html
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
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
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
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hi! I hope you don't mind breaking out a side thread with a concrete harmonisation sugestion. First an openEHR change request, then an ISO 13606 change request. 1. Regarding ITEM_TABLE (and the other classes in the openEHR item_structure package) there was a change request from Sam that went pretty unnoticed by a while ago, see: http://www.openehr.org/mailarchives/openehr-technical/msg04994.html I'm not saying we should go exactly by the letter in Sam's CR, but somehow skipping the things currently in item_structure package in openEHR could simplify understanding and slightly reduce implementetion complexity. It would also shorten paths (and thus storage depth) one step - a possible performance gain. Probably letting the data atribute of openEHR ENTRY subtypes point straight to ITEM (or possibly CLUSTER) would be best. If something should be suggested to be shown in a GUI as a table, list (or other non-tree formalism) it might be possible to define using either... a) a GUI directive/hint in archetype annotations similar to the directives shown by Koray Altag at Medinfo 2010, see slide 30 and onwards in http://www.openehr.org/wiki/download/attachments/5996988/3_GastrOS_Atalag.pdf b) a new attribute in the CLUSTER or ITEM class c) ...some other way i have not thought of Suggestion a means the hint might not be available in instance data, only in the archetype, that Shortcuts to UML diagrams for comparison: CEN/ISO: http://www.chime.ucl.ac.uk/resources/CEN/EN13606-1/13606-1Diagramsv3e.pdf openEHR: http://www.imt.liu.se/~erisu/2008/openEHR-tour/print/openEHR-RM-1.0.1-may23-17.54.gif Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/http://www.imt.liu.se/%7Eerisu/ Tel: +46-13-286733 On Tue, Nov 9, 2010 at 03:25, Andrew McIntyre andrew at medical-objects.com.au wrote: Hello Hugh, I don't have an objection to openEHR as such, but I think there is significant semantics hardwired into the model and that hardwiring makes openEHR archetypes difficult to use in other models, so I prefer a simpler, more generic reference model. In reality the Observation status of an entry should have a terminological definition rather than an explicit attribute of the model and by declaring the eg TABLE cluster you are actually removing the knowledge from the terminology and moving it to the model. This means the archetype does not have the information. To function as a DCM the archetype should have that knowledge embedded in it so that it can be represented in a specific way in another model. You could declare a cluster that is marked, by terminology binding as a table structure and that would allow any model to represent it using its own table convention. Its partially a question of drawing the line between the terminology and the model, and openEHR extends a lot further into the terminology realm than eg EN-13606. Our own archetypes in HL7 V2 can use openEHR archetypes, but as some of the semantics are embedded in the class names and attribute names and not the archetypes the information semantics are dependant on knowledge of the openEHR reference model, rather than the structure and terminology in the archetype. I think things like data and state should have terminology binding behind them if they are important and in openEHR they do not. I guess its what I would call semantic attributes. Semantic attributes only work when you use a shared reference model. In fact a true DCM format would have even less semantics than 13606, but EN 13606-2 happens to be the most generic model available, which is why we prefer it. I guess there is a spectrum with OWL at one end and openEHR/RMIMs at the other. I am not sure that everyone is ready to use owl just yet, but a reference model between owl and en 13606 is where I see DCMs as being best placed. The ISO DCM is using UML which I think allows 2 much freedom, probably even more than OWL. Its constrained by using UML templates which is in reality a non obvious way of defining a reference model, but there is no compulsion to use those templates which creates 2 many degrees of freedom in my view. So I guess I am wanting a DCM format, and want that format to look more like owl than anything, but I don't think that owl is practical for 95% of modellers (including me atm) so I have picked the most generic model I can find, which in EN 13606. In response to Eric's comments, I think its much easier to go from a generic model to a (or many) specific ones, especially if the generic model uses terminology to define things like Table. Its not straight forward to go from openEHR to EN 13606 as you have to do something with the semantic attributes. Last time I checked I was not walking away from any process, but attempting to engage. I appreciate that Nehta in Australia have had tooling problems and I guess if you only have A$160,000 a day to spend over a decade its hard to develop your own tools??? The
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Oops, I intended to push the save-button, not the send-button on that last message. Now we'll just have to make a fire, shovel some snow, milk our goats, say good morning to cat and chickens, fix a leaking car tire, get kids to school and myself and my wife to work before I can continue writing. Sorry about spamming the list. // Erik On Wed, Nov 10, 2010 at 05:56, Erik Sundvall erik.sundvall at liu.se wrote: I hope you don't mind breaking out a side thread with a concrete harmonisation suggestion... -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101110/4dc262e8/attachment.html
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Hello again! Here comes a more complete version of the mail I happened to send unfinished this morning. I hope you don't mind me breaking out a side thread with concrete harmonisation suggestions. First an openEHR change request (CR), then an ISO 13606 change request. 1. item_structure (openEHR CR) Regarding ITEM_TABLE (and the other classes in the openEHR item_structure package) there was a change request from Sam that went pretty unnoticed by a while ago, see: http://www.openehr.org/mailarchives/openehr-technical/msg04994.html I'm not saying we should go exactly by the letter in Sam's CR, but somehow skipping the things currently in item_structure package in openEHR could simplify understanding and slightly reduce implementation complexity. (It might also shorten paths in object traversal (and thus storage depth) one step - a possible performance gain in some implementations.) Probably letting the data attribute of openEHR ENTRY subtypes point straight to ITEM (or possibly CLUSTER) would be best. If something should be suggested to be shown in a GUI as a table, list (or other non-tree formalism) it might be possible to define using any of the following... a) ...a GUI directive/hint in archetype annotations similar to the directives shown by Koray Altag at Medinfo 2010, see slide 30 and onwards in http://www.openehr.org/wiki/download/attachments/5996988/3_GastrOS_Atalag.pdf b) ...a new attribute in the CLUSTER or ITEM class (with accompanying controlled vocabulary). c) ...some other way I have not thought of Suggestion a) means the directive/hint might not be available in instance data, only in the archetype, that might be bad for safety reasons. If b) is chosen, then that new attribute could of course be archetyped if you want the information in the archetype as Andrew suggests. Shortcuts to UML diagrams for comparison: CEN/ISO: http://www.chime.ucl.ac.uk/resources/CEN/EN13606-1/13606-1Diagramsv3e.pdf openEHR: http://www.imt.liu.se/~erisu/2008/openEHR-tour/print/openEHR-RM-1.0.1-may23-17.54.gif http://www.imt.liu.se/~erisu/2008/openEHR-tour/print/openEHR-RM-1.0.1-may23-17.54.gifI'd suggest that this change, after refinement and discussion with openEHR implementers followed by successful prototype implementation, be introduced as soon as possible before there is too much real patient data stored using the present item_structure package. Perhaps it can be introduced at the same time as ADL 1.5 and enhancements of the LINK class which anyway will require code changes. 2. OBSERVATION et. al. (ISO 13606 CR) == I can understand the CEN/ISO-urge for simplification of the openEHR ENTRY package *if* the main intention of the standard is to extract and exchange data from legacy systems where there is no intention to harmonize the semantics of data capture in the originating systems. A typical scenario would be Let's agree on an exchange message format for this particular use case and then everybody can do their best to map their internals to the agreed format (a fully reasonable scenario in many situations by the way). But, if that was the intention, then the whole openEHR-ish archetype approach seems to be overkill. Why not just go for a simple usecase-specific XML-schema or HL7 v2? *If* on the other hand the CEN/ISO intention was (or becomes) wider to also encompass the intention to *harmonize the semantics at the point of data capture*, then the openEHR ENTRY subtypes really do make sense. The point of them is to have consistency and efficient technical implementation for some common usecases. The technical class names (especially OBSERVATION vs. EVALUATION) have often been confusing people (e.g. from a philosophical, ontological or phenomenology perspective). This has been discussed earlier, see: http://www.openehr.org/mailarchives/openehr-clinical/msg01353.html and followups, e.g. Heathers reply at http://www.openehr.org/mailarchives/openehr-clinical/msg01364.html So, to get you to focus on the *technical structure* and it's consequences rather than thoughts like what is really an observation and why sholuld that be in the RM instead of the archetype. Let's temporarily in this post rename OBSERVATION to CARE_ENTRY_SUPPORTING_STRUCTURED_TIMING (as s described in the msg01353http://www.openehr.org/mailarchives/openehr-clinical/msg01353.html-link above). Sending patients between health care organisations with different EHR structure is just one usecase where an archetyped approach is useful, and I guess that is what CEN was somehow targeting. Other (according to me at least as interesting) usecases for path-enabled archetyped health records is the possibility to with a small effort reuse e.g.: - decision support rules - clever GUIs - overviews - epidemiology queries I research patient overviews where time is one very important visualization facet, and it really helps if there is a common way of expressing the semantics of time series using the class
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
I cannot claim to be an implementer of openEHR but I am still interested to understand the proposed use of Tables. Can anyone point me to a place where this is already explained with examples, the abstract discussion is a little hard to follow. My simple reading of this is that what are currently trees would instead be expressed as a sparsely populated arrays - is that the point? Tom Seabury NHS Data Standards Products From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-boun...@openehr.org] On Behalf Of Erik Sundvall Sent: 10 November 2010 16:16 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?) Tom, did I really express myself in such an unclear way or did you not read properly? Or did you respond to the wrong thread somehow? Perhaps i misinterpret your tone and arguments so please clarify if you have problems with the following: 1. tables, clusters etc I did not suggest that we should avoid having a single fixed way of defining table structures in openEHR. I suggested using a new attribute to indicate if a cluster is conceptually/graphically to interpreted as a table, list etc. instead of using separate classes for this purpose. Of course we need strict definitions of allowed values for this attribute (an enumeration or a list in the openEHR terminology, just as in other parts of openEHR presently). Of course specifications should include exactly how to interpret the clusters as rows and columns. Ian and Sam indicate that this would also have the benefit of allowing tables anywhere in a cluster hierarchy instead of only at top level. Do you have any objection against this provided that it is introduced in a well defined manner as described in the previous paragraph? Your argumentation sounds like somebody suggested that tables are not needed in openEHR at all or that they should be defined in random different ways. 2. Observations etc. I suggested that ISO 13606 gets extended with the openEHR ENTRY subclasses. Here I did not suggest changes to openEHR. (Even though I tried to say the class names can be confusing if you for some reason strongly believe that a technical class name only can be used for exactly what your own perception of that English word means.) Perhaps your OBSERVATION examples are just your way of expressing that you support my idea and why it is important to have the ENTRY subclasses to encourage consistency. The part about automatically converting openEHR ENTRY subclass structures to 13606, was definitely not a suggestion to remove them from openEHR. Instead it was more of an enquiry if it was at all possible in a non-destructive way. If it is, then openEHR archetype modeling, queries etc could after auto-conversion be used somewhat safely in a setting where you only have 13606 available. Best regards, Erik Sundvall erik.sundvall at liu.semailto:erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 This message may contain confidential information. If you are not the intended recipient please inform the sender that you have received the message in error before deleting it. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Thank you for your co-operation. NHSmail is the secure email and directory service available for all NHS staff in England and Scotland NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSI recipients NHSmail provides an email address for your career in the NHS and can be accessed anywhere For more information and to find out how you can switch, visit www.connectingforhealth.nhs.uk/nhsmail -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101110/26243600/attachment.html
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
On 10/11/2010 16:16, Erik Sundvall wrote: Tom, did I really express myself in such an unclear way or did you not read properly? Or did you respond to the wrong thread somehow? Perhaps i misinterpret your tone and arguments so please clarify if you have problems with the following: Apologies - I responded after reading the first version of your post, which had no point 2, but I was also trying to respond to more general criticisms (other people have said get rid of tables etc), not specifically just your post. ;-) (It took me a while to write that post, and I did not see your final version in time - seems we are in fierce agreement ;-) your point about the class names is of course a good one. We chose names that came from the ontological analysis, which some people will disagree with (or agree with, but hate our choice of names!). But in the end, the meaning (and therefore arguably the best name) of a class comes from its intentional definition, and nothing else. So your painful class name proves exactly this point. I would of course argue for a /shorter/ name, but going on your approach, Observation could be named in 13606 as something like 'DataHistory' or so. Personally, I would rather stick with 'Observation', because intuitively most people get the fact that it is about data in the past, and they generally immediately understand why it has a time-series structure. But I accept that this is only one way of seeing this, and would not be religious about it. 'Evaluation' as it turns out is an even more contentious name; we originally proposed 'Assessment', 'Opinion' and other similar names. Sticking with your theory, it possibly should be called 'AnythingYouLike', 'GenericEntry' or somesuch, but the problem going down this road is that it then obscures the link between the ontological model (I mean the problem-solving model of doing healthcare, that gives rise to categories like Observation, Evaluation, Instruction, Action, and all other similar models, like G-EPJ, the Swedish process model and so on) and the information model, and it makes it harder (in my view) for newcomers to know which Entry class to use for what. For those unaware, we started the openEHR/13606 mapping here http://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. - t 1. tables, clusters etc I did not suggest that we should avoid having a single fixed way of defining table structures in openEHR. I suggested using a new attribute to indicate if a cluster is conceptually/graphically to interpreted as a table, list etc. instead of using separate classes for this purpose. Of course we need strict definitions of allowed values for this attribute (an enumeration or a list in the openEHR terminology, just as in other parts of openEHR presently). Of course specifications should include exactly how to interpret the clusters as rows and columns. Ian and Sam indicate that this would also have the benefit of allowing tables anywhere in a cluster hierarchy instead of only at top level. Do you have any objection against this provided that it is introduced in a well defined manner as described in the previous paragraph? Your argumentation sounds like somebody suggested that tables are not needed in openEHR at all or that they should be defined in random different ways. 2. Observations etc. I suggested that ISO 13606 gets extended with the openEHR ENTRY subclasses. Here I did not suggest changes to openEHR. (Even though I tried to say the class names can be confusing if you for some reason strongly believe that a technical class name only can be used for exactly what your own perception of that English word means.) Perhaps your OBSERVATION examples are just your way of expressing that you support my idea and why it is important to have the ENTRY subclasses to encourage consistency. The part about automatically converting openEHR ENTRY subclass structures to 13606, was definitely not a suggestion to remove them from openEHR. Instead it was more of an enquiry if it was at all possible in a non-destructive way. If it is, then openEHR archetype modeling, queries etc could after auto-conversion be used somewhat safely in a setting where you only have 13606 available. Best regards, Erik Sundvall erik.sundvall at liu.se mailto:erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ http://www.imt.liu.se/%7Eerisu/ Tel: +46-13-286733 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics http://www.oceaninformatics.com/* Chair Architectural Review
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Audiogram, reflexes and vision results are sometimes recorded and displayed in two-column tables in clinical settings. There is an audiogram Observation archetype on CKM at Audiogram result http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.44 - this does not use a table structure, instead it just models the result of one ear and then allows multiples of that, tagged with 'side'. It would require the software to figure out how to tabulate this (not too hard obviously, but the point is that the data representation might be some other structure that is also logically a two-column table, so the software either has to be aware of all such possible structures, or else some kind of GUI directive like Erik suggested needs to be used. openEHR doesn't have such a thing at present). - t On 10/11/2010 16:26, Seabury Tom (NHS Connecting for Health) wrote: I cannot claim to be an implementer of openEHR but I am still interested to understand the proposed use of Tables. Can anyone point me to a place where this is already explained with examples, the abstract discussion is a little hard to follow. My simple reading of this is that what are currently trees would instead be expressed as a sparsely populated arrays -- is that the point? * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101110/fff061be/attachment.html
openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)
Just for info the only current example of a CKM archetype which uses ITEM_TABLE is Tendon and Babinski reflexes http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.256_1 and the Audiogram example in Thomas's link shows exactly why ITEM_TABLE in an archetype root is unhelpful, since it needs a number of other non-lateralised statements, such as Normal statements, clinical description, multimedia etc. Having the Findings cluster expressed as a table would make perfect sense, although it would also have to support layering of detail below that, which might make tabular representation difficult in all cases. Ian Dr Ian McNicoll office / fax? +44(0)1536 414994 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical analyst,?Ocean Informatics openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care SG Group www.phcsg.org On 10 November 2010 17:04, Thomas Beale thomas.beale at oceaninformatics.com wrote: Audiogram, reflexes and vision results are sometimes recorded and displayed in two-column tables in clinical settings. There is an audiogram Observation archetype on CKM at Audiogram result - this does not use a table structure, instead it just models the result of one ear and then allows multiples of that, tagged with 'side'. It would require the software to figure out how to tabulate this (not too hard obviously, but the point is that the data representation might be some other structure that is also logically a two-column table, so the software either has to be aware of all such possible structures, or else some kind of GUI directive like Erik suggested needs to be used. openEHR doesn't have such a thing at present). - t On 10/11/2010 16:26, Seabury Tom (NHS Connecting for Health) wrote: I cannot claim to be an implementer of openEHR but I am still interested to understand the proposed use of Tables. Can anyone point me to a place where this is already explained with examples, the abstract discussion is a little hard to follow. My simple reading of this is that what are currently trees would instead be expressed as a sparsely populated arrays ? is that the point? ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
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?
