At the HL7 meeting last week in San Diego, Grahame Grieve presented something called Resources for Healthcare <http://www.healthintersections.com.au/rfh/introduction.htm> (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 <http://www.healthintersections.com.au/?p=610> 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 <http://www.healthintersections.com.au/rfh/datatypes.htm>. 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: 1. They use orthodox object modelling rather than the subtractive modelling / profiling approach used to date HL7. 2. 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. 3. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110918/487d753c/attachment.html>
