See below. On 4 Oct 2012, at 18:07, Thomas Beale wrote: > On 03/10/2012 23:26, Gerard Freriks wrote: >>> I just care about getting one model.... >> >> In the case of 13606 one good model that describes a generic interface for >> EHR communication, also, for communication with other proprietary EHR >> solutions. >> In the case of openEHR one good model that describes one particular >> implementation of an EHR-system. >> >> This difference is something the EN1366 Association cares about. >> > > well except that the above is a misunderstanding of openEHR, so if the 13606 > association works on that basis they will miss the opportunity to get > harmonisation.
Whatever openEHR aspires to be, it is clear that the scope of 13606 is EHR Communication in general. It has been made clear that, in the renewal process of the 13606 EHR Communication standard, EHR-system implementation specifics are out of bounds. The scope of 13606 will not be extended to match the scope of openEHR. > openEHR is a model for an open EHR (it's in the name ;-), and includes three > kinds of semantics: > core semantics that apply for any use of health information - messages, EHR > systems, documents etc > semantics that describe accessing EHR information in repositories - any > repository Accessing data in repositories is definitely out of scope for 13606 in this round of updating. > semantics that describe EHR information in an Extract from one system to > another - any kind of system If openEHR is serious about its scope, to be a general receiver of health data, then its Reference Model must become much more generic than it is now, The 13606 Reference Model is very generic just to serve this important requirement that it must be able to deal with all systems. > These are used to specify the interfaces of EHR systems, EHR gateways (that > sit next to existing EMR systems), and EHR Extracts. The openEHR architecture > describes the externally shareable information semantics, not the internal > implementation. The implementations are the business of vendors, and are all > different. In other words, openEHR is an interoperability description of the > system - how the information and services look from the outside. > > Insofar as 13606 has been used (uptake by industry vendors appears very low > as far as we can tell), Hm? > it has been used to build either EHR systems or gateways, rarely messages, > which is what it designed for. This seems a fair indication that what the > sector wants is a specification for the interoperability interface of the > systems and gateways required to even connect a healthcare enterprise to the > outside world - and additionally, a specification for making EHR Extracts in > these systems. 13606 based interfacing systems have proven to be capable of extracting data from any feeder system, transform it into the 13606 format, and into any other structured format. And do this in matter of days. We do not need openEHR to do that. > > A specification only for EHR Extracts is not that useful, what the sector > clearly wants are specifications of the interoperability interface of > systems, as well as messages they might create. That's the opportunity here > for us working on these standards. All this is within the scope of 13606. It is misleading to suggest that the scope of 13606 is just messaging. EHR Extracts are about interoperability of data objects in general. > > 13606 needs to be updated a priori, and has lessons from use waiting to be > implemented; openEHR has lessons from the last 5 years of use which will lead > to changes, so there is scope for change and harmonisation. I think the > community here, and also the stakeholders are interested in practical > proposals for a new set of standards that actually address needs. I'm happy to announce that there is a wealth of implementation experience not only in the world of openEHR. There is a wealth of experiences in deploying the 13606 EHR communication standard in hospitals, research, regions. Sometimes in relation with HL7 CDA artefacts, sometimes to create applications for data entry, sometime integrated with ontological applications. In the meantime I sincerely hope that harmonisation is possible without making too many unneeded remarks about potential partners. > > - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121005/65054182/attachment.html>
