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 published Nehta models are in fact > generic, although often are lacking in details. I am not sure where the > "Hippocratic oath" Eric mentions comes into it? > > In the end openEHR is an application architecture and an implementation, > but in becoming concrete, as every one must at some point, its not that > suitable as a DCM format for the reasons above. That is not a criticism of > openEHR, but I think a reality. If the concept of DCM has any future it > needs to not support any model specifically. I think the ISO data types are > in the same boat. They are NOT the HL7 V2 or V3 data types at this stage, > they came into existence before that and hopefully HL7 will move towards > them, but they are a potential shared standard, and as a result no existing > implementation will claim to like them, I think that includes existing EN > 13606 and HL7V3 implementers. Its a question of convergence or war, that's > an age old battle that has been fought many times before, and it usually > ends in either the dark ages or convergence by force. > > Andrew McIntyre > > > > > > Tuesday, November 9, 2010, 10:48:26 AM, you wrote: > > > Hi Andrew > > I'm happy to continue to have this discussion with you. I still am not > sure whether your objection to openEHR is about the fact that the foundation > is not an SDO, or that you think that there is some semantic model in there > that you don't like. If openEHR were part of an SDO would it make your > objections go away? > > As we have discussed before, the changes to openEHR from when it was pretty > congruent with the current 13606 standard have not been about adding in > someone's personal idea of how a health record should be modeled, but about > making it as easy as possible to have one way of modeling things that we > shouldn't have to think about. > > A simple example that I have raised with you before - in openEHR there are > defined ways of representing things like lists, tables and trees. In 13606, > there is only the cluster ie a tree structure. While this is simple, it > means that if I want to represent a table in a 13606 archetype, I need to > make a decision about whether it is represented as a ROW, COLUMN cluster or > a COLUMN, ROW cluster and every archetype may have a different decision > made. How does a computer know which way the decision was made? Yes, I > know that last time I suggested this, you said well it could be just written > down somewhere but obviously that might mean that most of the time it will > be one way and then some of the time it will be another way and is probably > worse! I can't really believe that you think documenting this is better for > computability than making it explicit. > > This same approach extends to the entry types that you don't like. The > only reason these are there are because of explicit, researched reasons to > make it easy to develop computable expressions. Tom has given the examples > of the observation class allowing you to easily represent data values and > patient state within a time series like apgar or 24 hour blood pressure or > postural drop which is also a blood pressure series. Indeed, using a > generic entry model it is possible to define a model to represent these, > however the issue is that there are thousands of ways of representing the > same thing. The openEHR reference model makes the way of representing these > things EXPLICIT so that modelers don't have to keep reinventing things over > and over and so that computers can rely on data being represented in the > same way. > > There is nothing in the openEHR reference model that is there to represent > some kind of Health semantic model. In fact the model is incredibly generic > and is being used exactly as it is in other domains like finance. The > difference between CEN 13606 and openEHR is not some 'openEHR game', its a > pragmatic, engineered attempt to make clinical data more computable. > > And no one is trying to make everyone accept openEHR as the only standard > in town... we think its good and it works in real world situations and we > are happy to defend its value. :) > > regards Hugh > > > > > On 8/11/2010 10:05 PM, Andrew McIntyre wrote: > Hello Hugh, > > As someone who believes in a level playing field I think an international > standard, even if a little flawed is better than waiting forever for > perfection which will never come. I would extend this ISO 13606-2 to enable > sharable archetypes as well. > > At least then we have a situation where everyone has a common point of > reference. I guess everyone is also a little unhappy, but that is better > than the current situation. I think the standards are virtual in any system, > with adapters to the actual implementations, and to expect anything else is > dreaming of a mono culture, usually your own variety of mono culture of > course. > > There are great ideas to be reused from all players, but to expect the > world to accept openEHR as the only standard is unreasonable. We have > actually done a lot of work to enable the use of archetypes in HL7 V2, not > because we thing V2 is the best and most efficient mechanism, but because > its a standard and it has widespread usage and we gain a backward compatible > encoding, which means we can actually use it. (And the data model is > actually transformable into another encoding if desired) > > Similarly we adapt HL7V2 data for use in the Virtual Medical Record (VMR) > and use ISO data types there, not because they are a seamless match for > HL7V2, but because the ISO data types are a standard and we would otherwise > have to ballot a whole new standard. Its planned to constrain out many, or > most of the esoteric base class methods in the ISO data types for the VMR, > but they are still a compliant subset. > > If the openEHR CKM produced ISO archetypes then it would be a lot more > acceptable to many people, as it is standards based. Currently you have to > buy into the whole game of openEHR, which is I think a problem for many. Its > not a criticism of openEHR, but a desire for a neutral agnostic model. You > may defend the Evaluation class to the hilt, but there is no reason that > every other model has to and this is the problem. We need to accept some > level of imperfect abstraction to enable inter-operability, where everyone > has to provide glue to make it concrete. Its then less than optimal for > everyone, which is I guess what "compromise" and "consensus" is all about. I > still think it provides several orders of magnitude of functionality, over > the current reality. Otherwise we are doomed to the "My Model is better than > yours" war until the last man is standing. > > I also lament the lack of real technical input into the standards, but > that's the reality, I am sure in retrospect many "standards" eg http, smtp, > html could have been designed much better, but inter-operability and > pragmatism has trumped perfection and we all live with an imperfect world. > That's why I think we should give the ISO Data types a go. > > Andrew McIntyre > Medical-Objects > > Monday, November 8, 2010, 10:59:45 AM, you wrote: > ________________________________________________ > Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI > Clinical Director > Ocean Informatics Pty Ltd > M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com W: > www.oceaninformatics.com > > > > > *-- > Best regards, > Andrew mailto:andrew at > Medical-Objects.com.au<andrew at Medical-Objects.com.au> > > sent from a real computer* > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101110/9b94887c/attachment.html>
