This is wonderful news! Now there is a chance to use the word harmonization in a more productive manner :-)
Thank you to Grahame Grieve and others involved! This is too important to leave only to time- and people-constrained physical committee meetings, we probably all need to help out somehow with good technical thinking and some kind of real prototype implementation before any formal decisions are made. - Where are the main online discussion/information hubs where key people discuss this kind of redesign work in the different efforts (HL7, CEN, ISO, openEHR etc)? For openEHR I'd guess this technical mailing-list is the main hub for this (possibly complemented by a "harmonization"-wiki page or two as condensed memory-notes with links to some list messages etc). - How do we best set up communication links between the communities? Is it by joining each others mailing-lists/discussions? Other ways? Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 On Sun, Sep 18, 2011 at 13:37, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > > At the HL7 meeting last week in San Diego, Grahame Grieve presented > something called Resources for Healthcare (RFH), essentially a replacement > model for much of HL7v3, for 'practical use'. The driver was the well-known > over-complexity of HL7v3. According to his report on the reception of RFH at > the HL7 meeting, there appears to be a real appetite for change at HL7, > which is good to see. > > Within RFH, Grahame has proposed a new data types model.? In practical terms > this will presumably mean that implementations directly based on the RIM and > 21090, and particularly the creation of RIM/21090 data instances will see > much reduced use in the future. From the point of view of openEHR and 13606 > this represents some positive possibilities for bridging implementations in > the future, and maybe finally solving the 'logjam' in health informatics > standards. > > Things to note about the RFH data types: > > They use orthodox object modelling rather than the subtractive modelling / > profiling approach used to date HL7. > They define a very lean set of semantics (so far). > > These two together mean that for the first time, HL7 data types (if that is > what RFH data types become) can be extended in the normal OO sense, rather > than having to be 'profiled' (creating N variants, all non-interoperable > with each other). Interoperability can potentially now be found by > connecting to the core definitions, even if it can't directly be found with > more complex extensions of the core types. > > They incorporate a lot of features of the openEHR data types. > > The current openEHR data types are currently more full-featured, and in some > cases probably more complex than they need to be - adjustments may be > possible here (one example: the normal / reference ranges in DvQuantified > should be pulled out into a wrapper type or else added by inheritance to > DvQuantity and possibly DvCount, DvProportion). > > My conclusions at this point: > > building a data conversion interface between openEHR and HL7 of the future > now has a good chance of success, if the RFH data types develop in an > appropriate way > CEN/ISO 13606 should move to the RFH data types, and not use 21090 - doing > so is likely to set up a legacy in the future for 13606 users that HL7 > community is about to leave behind. It will allow 13606 to become much > closer to openEHR, and facilitate the merging of the models into one, which > I think is a necessary future step for both openEHR and 13606. > > If HL7 goes this way, some real convergence finally looks possible, and > people working on openEHR and 13606 need to think about how to go about it. > > - thomas beale >
