Ed, I am not engaging in HL7-bashing. I am critiquing specific aspects of HL7v3 that don't work well and cause widespread problems. Anyone should presumably be allowed to do that, otherwise how do we make progress? I would argue that critiques of this sort do help - we received lots of objections about openEHR from all kinds of places over the years and it helps.
The negatives of HL7v3 need to be exposed and explained, because they are getting in the way of interoperability and progress. HL7v2 is used extremely widely. HL7v3 is not, and there are reasons for that. I am trying to explain them, because ISO 21090 suffers from the same problems, and is about to create the same problems as the RIM: a very complex standard that is hard to use, has to be 'profiled' for use, and will be profiled in numerous different ways, largely preventing the interoperability (and in many cases, even implementability) it should have enabled. I think this is important. It is not about any perfect standard; any standard that at least followed basic modelling good practice is worth contemplating and working together on. But standards that don't follow basic, accepted modelling principles will just cause problems. There can be no common pathway when one of the modelling approaches is this subtractive modelling approach of HL7, it is only possible when all the candidates are at least doing proper modelling. Then we can talk about which one to agree on. My only interests are in doing the engineering we need to do in this sector. If I sound biased, it is because I do not see HL7 helping, and worse, it is not listening, not even about basic modelling practices. So the sector continues to suffer and make limited progress. I wish HL7 would adopt recognised modelling practices, because then we could make very fast progress. - thomas On 25/11/2010 15:22, William E Hammond wrote: > I have to admit that I am tired of the HL7 bashing, most specifically by > Thomas. In my opinion, it serves no purpose. I would hope Thomas would > spend his energy in a positive direction, not by bashing HL&. Further, > quoting a blog from someone who has problems with HL7 does not make his > case nor help the situation. Regardless of what Thomas says, HL7 is used > by thousands of people. About 90% of the hospitals in the US use v2. > Further, the UK, Canada and Australia use v2. One reason that v3 is not > adopted in the US is the success of v2. > > I think archetypes and/or DCM are important. Rather than working toward a > common pathway to mutually promote both HL& and openEHR, we have spent a > lot of energy of the negatives of HL7. n > If I became the one source of standards, I think I could make the perfect > standard. Of course, no one else would think so. As openEHR expands it > use, it will get (and has gotten) pusgback from persons who think it does > do what they want it to do. Then openEHR can say tough luck or they can > change to accommodate. Now you are in the world of HL7. > > What I have argued for a long time is that we, all of use in the standards > arena, are an invisible minority. When it is convenient and in the best > interest of governments or large companies, they will make their own > standards. I would like to see us follow some of the good advice in this > discussion and move forward - quickly and competently. > > So I'd love to see an e-mail that simply does not serve to bash HL7. We > need to undersatnd the differences and why, but we also need to understand > what we have in common. > > I believe that Graham Grieve is the most organizally unbiased person I > know. He is biased by what he thinks is correct. I think he make an > honest attempt to deal with some of the issues relating to data elements > and reach a compromise between openEHr and HL7 data elements. > Unfortunately, it seems that even this approach has not led to success. > > I have kept the e-mail thread, and would like to make some sense of it. > That trail also is important because it exposes the various philosophies > and differences. I may ask for permission from the participants of the > discussion to share their comments with a broader audience. The purpose of > the article would be to understand where we are and wht we differ and > perhaps enable a solution. > > W. Ed Hammond, Ph.D. > Director, Duke Center for Health Informatics > > > > Thomas Beale > <thomas.beale at oce > aninformatics.com To > > For openEHR technical discussions > Sent by:<openehr-technical at openehr.org> > openehr-technical cc > -bounces at openehr. > org Subject > HL7 modelling approach > > 11/25/2010 05:07 > AM > > > Please respond to > For openEHR > technical > discussions > <openehr-technica > l at openehr.org> > > > > > > > > Some of the things I mentioned in the last post on good modelling > practice, and the problems in HL7 due to not using them are mentioned > here in by Bill Hogan MD, who is Director of Medical Vocabulary/Ontology > Services, Pittsburgh Medical Centre. See > http://hl7-watch.blogspot.com/2010/11/demographics-hl7-vs-reality-part-1.html > > > - thomas beale > > _______________________________________________ > 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 > -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS, British Computer Society <http://www.bcs.org.uk/> Health IT blog <http://www.wolandscat.net/> * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101125/6f6027e8/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101125/6f6027e8/attachment.jpg>
