Hi! On Fri, Dec 16, 2011 at 09:32, David Moner <damoca at gmail.com> wrote: > In any case, this generic design is a result of the current scope of 13606: > EHR exchange and not a complete EHR implementation specification.
Thanks for reminding me. I tend to forget that the 13606 purpose never was to make internal system semantics interoperable. It's easy to forget the intentional 13606 focus when usually thinking of mappings and interoperability issues based on examples like the ones on slides 12 and 13 of... http://www.imt.liu.se/~erisu/2011/openEHR-TBMI19-lecture.pdf As you know, if you want to truly bi-directionally share things for which it is impossible to define deterministic conversion algorithms/programs (thus maintaining patient safety in automated conversions), then just defining a standard message- or extract format will be a lost cause (no matter how determined politicians are and no matter how much you pay IT-consultants to try to do the job). Instead the semantics of the end point systems will need to be aligned sooner or later. Anyway it wouldn't hurt if a new or refreshed internationally recognized standard could be used by those vendors and system owners that actually _want_ to agree on the internal clinical semantics of efficiently implementable systems all the way down to some of the technical (e.g. openEHR inspired) details. I think there is now a market for such a standard (or new standard part) helping those that have given up beliefs in mapping of incompatible semantics. > From our > experience, interoperability between legacy systems (standard-based or not) > is much easier using a generic model for exchange. The harsh truth is that > the quality of the data and the design of information structures in existing > EHR systems is quite bad or unclear, thus making really complicated the > process of automatically transforming it to a very specific reference model. > This is not the case when we use 13606. I suspect this is an intentional difference between current 13606 and openEHR; to faithfully capture the current (incompatible) situation versus aiming to change the current situation. Can those different goals really meet in one RM or do we need two standardized RMs? http://dilbert.com/strips/comic/2011-08-02/ A side-track question: Do you feel that the archetyped approach with 13606 really helps in the current mappings/transformations that you work with more than what just using e.g. RDF+OWL would help? Or does the archetype stuff and RM mostly complicate things? > A different thing is if 13606 scope changes during the revision. In that > case, I agree that reducing layers of modelling by introducing specific > classes will make the systems more efficient. Is there an opening for scope-change or not within the formal 13606-revision or would one need to start a completely new standard in order to define a standard for aligning internal EHR system semantics? Could one add a new part (13606 part-6 or 1b?) to the specification containing detailed RM semantics (inspired by openEHR) and at the same time align that new part and a more general "healthcare a-specific" model (a revised 13606 part-1(a)?) in a way that clearly defines a deterministic (and tested) conversion algorithm from "the detailed clinically focused" RM (6 or 1b) to the "healthcare a-specific" RM (1a)? It would be nice to have the different parts "under the same roof", a revised 13606, since they could share an AM based on AOM 1.5. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
