Andrew, I agree that there can be value in producing lower common denominator artefacts for short term implementation gains. I don't, however, see why we can't aim to gain agreement on more specifically defined artefacts as the basis for clinical models, and then, as you suggest, provide adapters for actual implementations, particularly if the cost in doing so is minimal - it is simply a matter of automatically processing from the richer openEHR specification to the simpler ISO 13606. The difference essentially boils down to collapsing archetypes defined according to openEHR's richer ENTRY subclasses of OBSERVATION, EVALUATION, INSTRUCTION and ACTION into archetypes based on the simpler 13606 ENTRY class.
As for HL7 V2, I cannot understand why the manifestation of ENTRY types is a relevant issue here. Are you suggesting that if ISO 13606 were balloted today, based on today's openEHR richer ENTRY subclasses that it would substantially change the way archetyped data could be carried in V2, to the point where you could not entertain supporting it? Or conversely that you would be happy to adopt it because it were a "standard". Or are you merely suggesting that if Australia, for example, were to develop/adopt/"compromise" on a set of archetypes based on the openEHR model rather than ISO13606 that one company - Medical Objects - might have to undertake modifications to their product suite? I have to confess that neither my technical skills, nor my clinical knowledge may be sufficient to allow me to form a strong view on the detailed merits of the attributes of openEHR's ENTRY subclasses, other than it seems patently obvious that one needs (somehow) to distinguish between INSTRUCTIONS, ACTIONS and OBSERVATIONS/EVALUATIONS in the openEHR sense of their meanings. To dismiss these differences in favour of some ISO standard, and walk away from the whole process, at least for clinical modelling purposes, seems akin to throwing the baby out with the bath water. And wouldn't that run counter to the Hippocratic oath? - eric On 2010-11-08, at 9:35 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: > > > Hi Ed > > I too appreciate your willingness to take part in these discussions. > > I think that rather than fire broadsides, we need to see where we can > usefully meet. I have been attending the HL7 WGMs over the last 18 months to > try to get more of an understanding of how we can usefully work together and > I am coming to the conclusion that there is a place where openEHR and HL7 can > usefully work together without having to compromise everyone's principles. > > HL7 has been working on ways of trying to develop reuseable clinical content > - through clinical statements, templates, cmets, DAMs etc etc and now looking > at 'DCMs'. One of the things that openEHR undeniably does well is the > ability to define clinical content in a clinician friendly way through > Archetypes but in a way that is also computable. The Clinical Knowledge > Manager has enabled hundreds of clinicians and informaticians to work on the > clinical content through a web 2.0 approach. > > Now - while these artefacts are openEHR artefacts, because they are rich and > computable, they can be used to transform into RIM based artefacts and > instances. With some more work, I am sure that these could be a useful > source of governed clinical content for the HL7 work. I believe that this is > the only sensible approach going forward with the DCM idea inside HL7 and > avoids reinventing the wheel. > > I am sure that this is technically possible, but the main issue here is the > political one - we need to move beyond the personal issues and disinformation > on both sides to have any chance of succeeding. > > regards Hugh > > On 7/11/2010 11:56 PM, William E Hammond wrote: > It is not clear to me that Tom's remarks help either. HL7 had data types > very early. That is not the point. The issue is is there anything in the > future we can agree and work togwether. Unfortunately, I have come to the > conclusion we cannot not, and as a result we shall let the market make > those decisions at a price all of us pay. HL7 v4 is in even less use than > v3 at this time. I would say in the US, v2 is a huge success. If we play > mine is bigger than yours we all lose. I agree with Graham. Let's move on > to another topic. It's business as usual. > > David I would hope you and others like you could help us resolve some of > the issues. Maybe the differences in approach, philosopy and organization > prevent working together. No one argues that HL7 is perfect - far from it. > But that is a result of the fact that those standards are produced in an > open process in which decisions are made by many. As a result, HL7 > standards usually include something that someone does not like. However, I > think the alternatives are worse. > > My prediction is that we need to be concerned that the world will move > forward without either organization playing a significant role. Technology > changes are already refocusing on what is important. > > I'd love to see us pick a point in the future and work together to produce > useful standards. I actually extend this conversation to all of today's > SDOs. HL7 meets in Sidney in January. That provides an opportunity to > discuss some of these issues - perhaps with our members and not just the > leaders of the organizations. > > Last post. > > Ed > > W. Ed Hammond, Ph.D. > Director, Duke Center for Health Informatics > > > > David > <dneilsen at bigpond > .net.au> To > Sent by: For openEHR technical discussions > openehr-technical <openehr-technical at openehr.org> > -bounces at openehr. cc > org > Subject > Re: ISO 21090 data types too > 11/07/2010 07:37 complex? > AM > > > Please respond to > For openEHR > technical > discussions > <openehr-technica > l at openehr.org> > > > > > > > I don't know if anyone in this group falls into this category. Often it is > not possible for those who want to participate to be able to do so. This > may be because of time constraints (they get paid to do a job, not attend > standards meetings) or they or the organisation that they work for cannot > come up with a) affiliation fees b) numerous plane tickets c) many nights > in expensive accommodation. It has been my observation that only those > with the freedom and the resources to attend meetings get their ideas > seriously considered. > > This sort of comment from William is not helpful in any genuine discussion > of standards. > > regards > David Neilsen > > > On 7/11/2010 6:14 PM, Williamtfgoossen at cs.com wrote: > ISO 21090 is a true ISO standard.. > > It does include a lot of OpenEHR data type specs, except where > OpenEHR decided to go their own way. > > And in the HL7 space some are working on implementing the ISO 21090 > standard in the HL7 models, which is quite a task, not impossible, > but a lot of work. > > ISO 21090 is based on HL7 input yes, but it is definitely not an HL7 > standard. > > In particular the Coded Ordinal as in ISO 21090 meets the clinical > and research requirement of allowing both computations and code and > display text use for the semantics. That is not present in most HL7 > v3 standards and will cause some upgrading of most messages. > > It (ISO 21090) could have been "more" an OpenEHR standard if OpenEHR > had more cooperated in this space instead of reinventing again their > own data types. > > > > Met vriendelijke groet, > > Results 4 Care b.v. > > dr. William TF Goossen > directeur > > De Stinse 15 > 3823 VM Amersfoort > email: wgoossen at results4care.nl > telefoon +31 (0)654614458 > > fax +31 (0)33 2570169 > Kamer van Koophandel nummer: 32133713 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > _______________________________________________ > openEHR-technical mailing listopenEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > -- > ________________________________________________ > 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 > > sent from a real computer > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
