# openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?) **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2010-11-10 04:56 UTC **Views:** 1 **Replies:** 21 **URL:** https://discourse.openehr.org/t/openehr-13606-harmonization-cr-regarding-cluster-table-etc-and-entry-observation-was-iso-21090-data-types-too-complex/12515 --- ## Post #1 by @system 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](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](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](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.gif) Best regards, Erik Sundvall [erik.sundvall@liu.se](mailto:erik.sundvall@liu.se) [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/%7Eerisu/) Tel: +46-13-286733 --- ## Post #2 by @system 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 --- ## Post #3 by @ian.mcnicoll Hi Eric, I thought the original post was pretty complete\!\! I would strongly support this proposal\. In practice we have almost wholly abandoned using anything other than ITEM\_TREE as the top\-level archetype structures, for all the reasons suggested by Sam\. Tables are useful but generally within the body of the archetype,rather than as the top\-level structure\. A good example is neural reflexes, for which a table structure is appropriate but which would be better expressed within a CLUSTER archetype, rather than ENTRY, to cope with variations in Examination recording practice\. We are also finding that the use of embedded archetypes based on ITEM\-TREE is a little cumbersome\. There is considerable value in having child archetypes which can be re\-used in different parent ENTRY archetypes e\.g\. Medication details or Specimen details, but using CLUSTER gives us much more flexibility\. Some kind of simplification around the use of CLUSTER, with the ability to define TABLES within a CLUSTER or ITEM\_TREE would give us some simpler modelling constructs and, as you suggest, flatten the data path\. Ian Dr Ian McNicoll office / fax \+44\(0\)1536 414994 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@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 wHi Eric,ww\.phcsg\.org --- ## Post #4 by @system 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) --- ## Post #5 by @thomas.beale I will offer both some agreement and a counter-opinion. Everyone always wants things 'simpler', and without foresight, it is very easy to make them too simple. Let's take the two cases: ITEM_STRUCTURE data structures, and Observation.data (of type HISTORY). It turns out that the discipline in structures we thought existed in clinical data - Lists, Tables, Trees etc, is less clear in reality, and apparently clinical modellers want to just make everything a tree-like structure. I personally am still somewhat sceptical that this is really true, because in the many tabular, particular bilateral information structures (reflexes, audiogram, much ophthalmology, and so on), throwing out the ability to define a Table structure in the data simply means that tabular structures may get built in different ways be different groups. Internationally standard archetypes can remove this problem partly, but software still has the job of working out how to correctly put the data on the screen and also capture it, in ways familiar to clinical people. But - let's assume that, all things considered, this simplification was to prove useful, and the consequential downstream costs were acceptable. We could in that case make some small simplification of the current models. Now consider the counter-examples: Observation.data, the structure of Action and Instruction. Let's stick with the first one for the moment. As mentioned in previous posts, we chose to define a History data structure in the RM because it is absolutely ubiquitous in observational data, no matter whether it is one or many samples, and no matter what part of medicine or science it comes from. Here are some paths from the Apgar archetype - you can see where they contain 'events[1 minute]', 'events[5 minute]' etc... -- note that everything below shows English language translations of terms /data: HISTORY /data/origin: DV_DATE_TIME /data/duration: DV_DURATION /data/period: DV_DURATION /data/events[1 minute]: EVENT /data/events[1 minute]/offset: DV_DURATION /data/events[1 minute]/data/items[Heart Rate]/value: DV_ORDINAL /data/events[1 minute]/data/items[Respiratory effort]: ELEMENT /data/events[1 minute]/data/items[Respiratory effort]/value: DV_ORDINAL /data/events[1 minute]/data/items[Muscle tone]/value: ELEMENT ... /data/events[2 minute]/data/items[Heart Rate]/value: DV_ORDINAL ... /data/events[5 minute]/data/items[Heart Rate]/value: DV_ORDINAL For an archetype containing Interval_events, e.g. any rolling BPs, temperature etc, you get paths like: /data/events[any event]/offset: DV_DURATION /data/events[any event]/width: DV_DURATION /data/events[any event]/sample_count: Integer /data/events[any event]/math_function: DV_CODED_TEXT -- e.g. value could be a code for 'average' These paths correspond to formal data structures, as you can see [here](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109157527311_729550_7234Report.html). Have a close look at these classes. Everything here can be archetyped. The INTERVAL_EVENT class for example provides attributes for sample width, sample_count (allowing data compression from ICU and other devices), and math_function. In all there are around a dozen formally specified attributes here that would not exist in a simple Entry.data: Cluster model. That's not just 12 things that both archetype specifiers have to invent, but also 12 things implementers have to invent - i.e. find names for, decide on types, and structure (hint: there are not just 12 ways of doing this, but hundreds of millions). History tells us that organisations in the latter group will do this differently every time. Note that it took probably 4 years to get this model into its current form, where it works for everything we can throw at it now. I have to ask - why go back through that pain? Why go to a model that is too simple, only to discover too late a whole raft of problems that this model takes away? If anyone doubts this, just have a go at remodelling 20 or so of the most common Observation archetypes you can find on CKM, in the 13606 model. You can try this in the existing openEHR tools by either using an Evaluation structure (which does happen to be a tree) or the openEHR [Generic_entry type](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html). Any such archetype can be validated and viewed in the [ADL Workbench](http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html) or Archetype Editor. Let's see what would happen to the paths and types if you do this: **Fred's version of Apgar based on Cluster/Element structures:** /data: CLUSTER /data/items: CLUSTER /data/items[origin]: ELEMENT /data/items[origin]/value: DV_DATE_TIME /data/items[duration] -- not defined by Fred /data/items[period]/value: Real -- oops - Fred prefers 'Real' here /data/items[1 minute]: CLUSTER /data/items[1 minute]/time: DV_DATE_TIME -- oh no... Fred wants absolute time points, not offsets /data/items[1 minute]/items: CLUSTER /data/items[1 minute]/items/items[Heart Rate]/value: Integer -- Hm. Fred just wants to use an Integer here /data/items[2 minute]/items/items[Muscle Tone]/value: Integer -- Hm. Fred just wants to use an Integer here **Janes's version of Apgar** **based on Cluster/Element structures****:** /data: CLUSTER /data/items: CLUSTER /data/items[origin]: CLUSTER -- oh no, Jane wants to use a CLUSTER here! /data/items[origin]/value: DV_DATE_TIME /data/items[duration]: Real -- Jane decided on a Real here /data/items[period]/value -- not defined by Jane /data/items[Any time]: CLUSTER -- Jane is not going to control the times at all /data/items[Any time]/timepoint: ELEMENT-- Jane records the time in this new attribute /data/items[Any time]/items: CLUSTER /data/items[Any time]/items/items[Heart Rate]/value **Bob's version of 24h BP** **based on Cluster/Element structures****:** /data/items[4 hour]/items[diastolic]/value: Real -- Bob has collapsed the path here; Fred's software that understood Fred's structure of logical 'history of events' data now won't work on Bob's data. ... X 1,000 other clinical modellers around the world X 1,000 other archetypes X 10,000 software developers around the world. = 10 billion more incompatible combinations than we have today Now consider the internal structures of Instruction and Action ([here](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html)). Consider just the simple fact that Action is a conjunction of 'time' (would anyone argue against this?), 'description' (ditto), and various other details to do with the Instruction state machine. I am not saying that this model is perfectly correct; maybe it needs a 'other_details' attribute as is used elsewhere in openEHR. But again, just do the thought experiment of having nothing but a Cluster/Element structure to work with. You immediately have to a) work out a model of where you will record time and description, b) if you want it to be interoperable, you will have to get into some kind of standards discussion with other people to agree on the same structure and c) you then have to complicate all the tooling software and also downstream software in order for it to 'know' that this particular Cluster/Element structure is really an Action structure, and to diplay it as such. The downstream complications will be quite significant. It is the difference between giving a software developer UML pictures like the above, or .... a completely generic tree structure, which is as good as giving them nothing. In summary: there is a strong argument in my view for avoiding all this modelling and downstream complexity. A challenge to the health informatics community is to actually show how it will be better for modelling and software to just go to a simple Cluster/Element model (or in HL7 terms, Act/Act-relationship). If it can be done and save time and trouble compared to what we have done in openEHR, I will be the first to embrace it. Note: flatter data paths are aesthetically pleasing to humans, but computers don't care about them. They care about *consistent* path structures. - thomas [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #6 by @system 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@liu.se](mailto:erik.sundvall@liu.se) [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/) Tel: +46-13-286733 --- ## Post #7 by @SEABURY_Tom_NHS_DIGI 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 --- ## Post #8 by @thomas.beale > 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 [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #9 by @thomas.beale 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? --- ## Post #10 by @ian.mcnicoll 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@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 --- ## Post #11 by @system Hi\! > 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@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? --- ## Post #12 by @system 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 --- ## Post #13 by @system 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@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com)> --- ## Post #14 by @Tim_Cook2 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 --- ## Post #15 by @thomas.beale > ``` > 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 --- ## Post #16 by @Heath_Frankel3 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 --- ## Post #17 by @thomas.beale > 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 --- ## Post #18 by @pablo 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. --- ## Post #19 by @thomas.beale 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 --- ## Post #20 by @system 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\! > \.\.\. 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 "details"points 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 ones in ITEM\_TABLE can be moved out from the core to some optional utility\-package instead \(if the need for having them standardised remains\)\. If looking outside the item\_structure package this actually already seems to be the case \- there are pretty few methods\. Good\. Best regards, Erik Sundvall erik\.sundvall@liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-286733 P\.s\. Tim, I'd be interested how these changes suggestions, in your wiew, relate to "Keep everything as simple as possible; but no simpler\." that you qoute on the philosophy part of http://www.oship.org/ --- ## Post #21 by @system 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 --- ## Post #22 by @system 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@liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-286733 --- **Canonical:** https://discourse.openehr.org/t/openehr-13606-harmonization-cr-regarding-cluster-table-etc-and-entry-observation-was-iso-21090-data-types-too-complex/12515 **Original content:** https://discourse.openehr.org/t/openehr-13606-harmonization-cr-regarding-cluster-table-etc-and-entry-observation-was-iso-21090-data-types-too-complex/12515