Ed, we are indeed forced to move on, business as usual. Sadly, business as usual in this domain has become an endless painful trip of having to deal with difficult standards, when much better ones could have been built. This email thread has indicated the basis of the 21090 specification being the way it is: politics and design-by-committee. How we could think that was acceptable I just don't know. I happen to think the alternatives are better, and I don't mean openEHR, I just mean doing some clean, clear modelling. If the 21090 standard's scope is really just messaging, as Grahame indicates, then we should in fact produce a new standard that is actually a clean set of data types, and leave 21090 for HL7 users.
Here is a little parable: OMG took over UML about 12 years ago, and then some years later decided to upgrade the specifications to 2.0. They created two massive documents, the 'Infrastructure' and the 'Superstructure'. Very respected experts I have met walked out of these committees due to this insanely over-engineered (committee) work. As a concomitant, XMI 2.0 was also horrible. Yes, some tool-vendors managed to support it, but mostly unreliably, and it is not really their fault. The industry response in the end was to stop fighting with these over-complicated specifications, and create something people could actually work with: Eclipse Modelling Framework, and Ecore. The Ecore model replaces XMI. The latter will be dead in less than 5 years I predict. I happen to think that a clean set of core clinical data types, modelled in a proper object-oriented way, and free of particular context attributes from particular message or other deployment frameworks could be standardised. There was talk of actually doing this seriously about 5y ago. Then politics took over, and we ended up in the mess we are in today. Maybe I am foolish for wanting to make progress, rather than win any races. But I remain interested in implementability, quality, and safety. My apologies for that. - thomas On 07/11/2010 12:56, 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 > * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/36f9258f/attachment.html>
