It sound as a very interesting proposal. As you say, profiling ISO 21090 data types leads to several problems of inconsistency and non-interoperability. And in terms of efficiency, our tests using the new data types in LinkEHR are not satisfactory at all.
But my main question is if this initiative has possibilities of achieving an official support from HL7. This is an important question to prepare the future of current norms. This is what the 13606 says about the data types: "It is recognised that, at the time of producing this standard, a new set of health informatics data types is being developed by ISO TC/215. Once this is published, CEN may choose to deprecate TS 14796 in favour of this new standard. In doing so, it will need to provide a mapping correspondence to the new data type standard, and this mapping will also need to be used in order to adopt the new data types alongside EN13606-1." Thus, while no official ISO 21090 profile has been defined and mapped to existing TS 14796 (although there are some proposals), the last ones are still the valid ones for 13606. If there is any possibility for this new proposal of Grahame to succeed, it would be a waste of time to change current data types working with 21090. @Erik: CEN/ISO 13606 discussions take place at the Association forums and wiki, to prepare inputs for the CEN/ISO committee. The data types topic is one of the most important to work on. Web and forums: www.en13606.org Wiki: wiki.en13606.org David 2011/9/18 Thomas Beale <thomas.beale at oceaninformatics.com> > > 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 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110919/1d677134/attachment.html>
