lessons from Intermountain Health, and starting work on openEHR 2.x

Gerard Freriks gfrer at luna.nl
Fri Oct 5 06:13:49 EDT 2012

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),


> 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-clinical_lists.openehr.org/attachments/20121005/65054182/attachment.html>

More information about the openEHR-clinical mailing list