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:
