I want to pick up on a few points here... On 08/11/2010 11:05, 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.
I don't know of anyone who is saying that. The people who are saying that kind of thing are the ones trying to (and succeeding) getting their favourite model turned into an HL7, ISO, ASTM, CEN or other de jure standard; indeed, doing this is precisely about 'expecting the world to accept XXX as the only standard [in its scope]'. openEHR is just an 'offer' to the world. > 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. are you sure? How do you know? > > If the openEHR CKM produced ISO archetypes then it would be a lot more > acceptable to many people, well, all the archetypes in CKM are ISO-compliant, i.e. they comply to ISO13606-2. Even the next generation of archetypes, compliant to ADL/AOM 1.5 will be backward compatible to this specification. But I suppose what you really mean is that the archetypes should be based on a neutral reference model 13606 ENTRY class. Firstly, nothing is stopping that: the type GENERIC_ENTRY <http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html> has been in the openEHR RM for years - and it is wrapped in a more comprehensive context and versioning model than 13606. Secondly, like HL7, 13606 was conceived and designed as a highest common denominator for information transport between heterogeneous systems, not representation of clinical information. But the real question I have in my mind whenever I hear this objection is: just why are classes like OBSERVATION and EVALUATION etc unacceptable? I have been asking HL7 since 2003 or so to show a clean model of any of the following in RIM or CDA structures: * 2 or 3 sample Apgar * standard 3 sample GTT (glucose tolerance test) with patient state * ICU vital sign time series The same challenge extends to 13606 or any other model with no structure in its Entry or clinical statement class. This challenge has never been answered by these standards. And that is because representing data values and patient state within a time series is very hard, without any support from the underlying model. To do it in an Entry structure, you really have to go through contortions. But more to the point, 1000 vendors downloading and implementing the standard will all do that in 1000 different ways. The model of History of Events in openEHR was revised a number of times in order to properly address the needs of even very typical medical data. So I really want to know: which people are demanding to have a more difficult way to model time-based information like Apgar, GTT and vital signs? Or if they have an easier way of doing it, let's see it. > 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. well as I mention above, it is already there, and has been for years. I don't think this is really the problem. > 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. well I would only defend its use for what it is used for. But CDA has 9 Entry level classes of its own (a very strange collection of semantics, it has to be said, with even stranger compositional rules) that CDA, by its standards status, claims to be the one true way of representing health information. People in love with CDA presumably defend those classes to the hilt and hope one day that the whole world will use them. But the evidence from trying to model typical clinical information structures as archetypes clearly shows that the openEHR OBSERVATION class (to stick with this example) is better adapted to observational data than its RIM equivalents. This is for one reason only: /we adapted them directly to the challenge of real clinical data/. Are there even better adaptions possible? Undoubtedly, I can even see a few improvements myself. I think any models of structured clinical statements need to address the challenge of real clinical data in a direct and formal way. Until then, most of their claims are unverifiable. > 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. well I cling to the hope that we are emotionally mature enough to be uninterested in mine/yours comparisons, and instead be interested in solving the problem in an evidence-based way. This means accepting that models be compared by verifiable, formalisable challenges. If it can be shown that the openEHR OBSERVATION class makes it objectively easier (e.g. in a 'blind tool test' by 50 clinicians) to model BP time series, Apgar, GTT, etc etc, than to do it with a neutral ENTRY type like in 13606, then this should count for something. If it showed it was in fact harder, it would be just as valid - we would really learn something then. But at least we would be doing science and progressing. Currently in the standards arena, there is very little science going on, just hand-waving. > > 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. well we are forced to anyway, since they are now apparently the one true standard for clinical data types. Oops.... until profiled according to your own needs into your own version of the standard.... - thomas > > Andrew McIntyre > Medical-Objects > * > * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/614370e8/attachment.html>
