Hi Tom, Thanks for the update, really good news. Did you by any chance come across any discussions regarding the formalism for specifications? Are we still talking about XSD here?
On Sun, Sep 18, 2011 at 12:37 PM, 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 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
