Hi Peter, we heard you loud and clear... Not going into detailed discussions I think we have a great methodology to express clinical content - Archetypes. Of course they come with a RM, and I would want to think that it is only at the RM that 13606 and openEHR differ (due to nuances in scoping). As we target the Archetypes to include every possible data item configuration for a clinical concept naturally the RM has to be granular enough to accommodate detailed peculiarities. So if the sole difference between 13606 and openEHR is that of genericity/specifity one would assume ALL stuff expressed in 13606 be represented in openEHR. Conversely there will have to be inevitable loss in fidelity of information passed from one system to another using 13606 (at least between two openEHR systems). The story is different for non-openEHR systems though - in most cases the fidelity provided by 13606 might be more than enough for passing info from one to another.
I hope that the two formalisms don't go separate ways so that the difference become more than just that of scope (and associated RM changes)- This we should avoid. But just for the sake of simplicity I don't think the world needs more than one, essentially same, standard. Unfortunately things don't work this way so best we can do is to ensure Archetype development be consistent between the two formalisms where semantic equivalence should be sought. Nailing the RM relationships will be critical. I wonder if with small tweaks in openEHR RM by enabling generic class use we can actually solve the problem which 13606 is addressing. In that case de jure SDOs can take a snapshot at appropriate points in time from openEHR, for the sake of meeting their process requirements, and this would be a great step towards unity. But unfortunately the moment you model the same clinical concept using generic 13606 ENTRY vs. OBSERVATION or other in openEHR there is no way a machine to safely interpret as same. I think this is also a modelling issue - so if one modeller can represent a clinical concept using a generic type and the other with a specialised one, that means the latter might either have a more stringent requirement or the former doing it wrong. Firmly I don't think there is any difference in terms of information requirements whether the purpose is information exchange or building a fully-fledged EHR system. It is the party (person or machine) who uses this information and acts upon that sets the information requirements - you can't possibly send information over the wire which does not meet those requirements. So I would assume any 13606 modeller to take into account the same requirements too. I often find it difficult to understand how information exchange is seen different from how that information is represented and processed inside. This is one in terms of content - format and detail might different. Lastly if there is a need to pass on a simplified version of clinical information over the wire the Archetype editor can set genericity at that level so that the model meets both needs. Cheers, -koray From: openEHR-technical [mailto:[email protected]] On Behalf Of Linhardt Peter Sent: Monday, 8 October 2012 5:38 a.m. To: For openEHR technical discussions Subject: lessons from Intermountain Health, and starting work on openEHR 2.x Gentlemen Current situation, where CEN 13606 deals on en hadn with communication only, but pays no attention to the EHR data storage, retrieval and OpenEHR concept on other hand leads to some very serious problems in the countries, trying to build eHealth system, based on the future proof concept. Leads to the confusion, regarding the archetypes and the proper tool for their creation, maintenance and interchange, and in the end of day to the lack of interoperability of basic stones of clinic and demographic information Leads to the enormous space for private clinical data concepts, leading to the growing costs of building and maintaining interface between the CEN 136060 health messages and EHR data of providers and national system and creates obsstackels for international interoperability Situation in creation of national helath information system in Slovakia suffers just due the split of ideology on side of OpenEHR and insolved parts of CEN 13 606 And country health sector will pay great costs, when this split ones upon the time will be solved and CEN will be able to provide for national helath system complex Acceptable solution from creation of heaalth reportt by physician, storage in health care data silo, communication between all providers inside of coutnry and on international level upt to creatin of national EHR data warehouse. I hope, Europe/globaly we can agree on single approach for a standard for clinical content, fully supporting generic semantic interoperability, to agree on standard for artefact in order to heve interoperability among archetypes, created/edited in different editors and due archatype based concept of data creation, storage and transport get rid of endless maping, interfacing and data mess. Peter Linhardt National archetype centre at Slovak university of technology Bratislava, Slovakia From: openEHR-technical [mailto:openehr-technical-bounces at lists.openehr.org]<mailto:[mailto:[email protected]]> On Behalf Of Gerard Freriks Sent: Thursday, October 04, 2012 8:21 AM To: For openEHR clinical discussions Cc: For openEHR technical discussions Subject: Re: lessons from Intermountain Health, and starting work on openEHR 2.x Dear Koray, We both agree that the scopes of CEN/ISO 13606 and openEHR differ, as I wrote. The scope of 13606 is about EHR communication. That of openEHR is about the implementation in an EHR system. At present a standard is missing about defining clinical content. It would be nice, certainly, when both 13606 and openEHR can share that standard for clinical content. In several places the EN13606 Association, whose scope is wider than the European context, is actively working towards that goal. This single approach for a standard for clinical content is very important when we want generic semantic interoperability. This is the reason why components for a potential standard on archetype production are developed inside the Association. A standard that defines the intersections with: coding systems, ontologies, other CEN/ISO standards like System of Concepts for Continuity of Care and the Health Information Services Architecture. All resulting in one basic generic pattern, for all artefacts, that by specialisation is able to be used for all kinds of archetypes. A basis pattern that in more detail allows the definition of more nuances than the archetypes we know, so far. A basic pattern that brings features closer to actual use such as negation, semantic ordinals (with inclusion and exclusion criteria), better integration with clinical workflow, ontological reasoning over structure and codes, etc. The EN13606 Association of implementors of the 13606 standard has considerable experience in the production of applications based on this standard. When I look into future needs and developments around the use of coding systems and ontologies, I see state of the art developments among the members of the Association. W3C is a good example. indeed. As far as I know W3C does not prescribes how to implement their standards in systems. This is the responsibility of the industry in all circumstances. Gerard Freriks +31 620347088 gfrer at luna.nl<mailto:gfrer at luna.nl> On 4 Oct 2012, at 02:02, Koray Atalag wrote: Hi Gerard, I think getting the content model is absolutely right - no one can argue But with due respect I disagree with you about the difference. I seriously think standards defining clinical content should converge (not even harmonise). I had the privilege of spending some time with Ed Hammond in NZ and was convinced that this is what is needed. Mappings are different and certainly a blackhole. That said EN13606 Association's mission and role is paramount in terms of contextualising "exchange" within the European context. We chose to use openEHR for defining the Interoperability standards in New Zealand as we are very mindful of the fact that this formalism has been defined and carried on for many years by this group; and it IS naturally the leading edge with proven track in implementation (one of which is my own work). I think W3C is a good example of how important it is to have a single approach in contrast to the situation in health IT. These might sound a bit strong but it is what I believe. I acknowledge lack of organisational capacity and skills in past though. Cheers, -koray -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121007/7db29fd4/attachment-0001.html>
