Hi David
While I agree with your sentiment as a technical guy, the fact is that sharing health information will be more important than the application space relatively soon. This is like document sharing now ? you can have the best word processor on the planet but if it doesn?t do word then it isn?t really much use. Things can only change slowly once standardisation creeps in ? so we want to liberate the application from the EHR. Providers and consumers owning the EHR and vendors the application spaces. Cheers, Sam From: [email protected] [mailto:openehr-technical-bounces at openehr.org] On Behalf Of David Moner Sent: Friday, 16 December 2011 10:55 PM To: For openEHR technical discussions Subject: Re: 13606 revisited - list proposal Hi, 2011/12/16 Erik Sundvall <erik.sundvall at liu.se> Hi! 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. I completely agree. But aligned does not mean that the have to be exactly the same. Conversions between models and standards will always be needed. 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. The problem is that a unique solution will never be used by all actors (due to the human nature of divergence). The need of interoperability between different solutions and systems will always exist and then we have to give a solution for this scenario. Best practices maybe will commonly accepted, but no specific solutions probably. > 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/ I talked of this with Thomas last August in Oslo. For me, the ideal solution would be to have a unique model that covers both needs. It should include generic classes such as those of 13606 and inherit from them specific classes for building EHR systems, as those of openEHR. Technically it should be possible to have, for example, a generic COMPOSITION-ENTRY-CLUSTER-ELEMENT structure that can be instantiated, but also a COMPOSITION-OBSERVATION-ITEM_TREE-ELEMENT structure inherited from it. An implementer could choose then to just create instances of the generic classes (e.g. for exchange) or instances of the specific ones, that are compatible (e.g. for operational systems). Note that this is currently not possible since ENTRY is an abstract class in openEHR. 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? It definitely helps. On the one hand because we deal with data transformations and then it is essential to have a clearly defined reference or information model to shape the data that is going to be communicated. And on the other hand, archetypes are the target schema for these data. We will all agree that the dual model is the best way to have together the three basic ingredients of semantic interoperability: the data structure, the concept definition and the binding to terminologies. > 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? I have no idea. I don't know the internal rules of ISO. 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)? >From what I have heard, it is possible to add new part to the standard. David -- 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/20111220/8626d39d/attachment.html>
