lessons from Intermountain Health, and starting work on openEHR 2.x
thomas.beale at oceaninformatics.com
Mon Oct 8 03:33:12 EDT 2012
On 05/10/2012 11:13, Gerard Freriks wrote:
> 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
> The scope of 13606 will not be extended to match the scope of openEHR.
No-one is suggesting it will - it is a subset of the three elements I
mentioned below. It would probably be more useful if it were extended,
but I understand that in the Vancouver ISO meeting it was decided
otherwise. So for specifying gateways & EHR data sources, industry will
need openEHR. If we can make it a clean superset of 13606, then that
will help greatly.
>> 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.
It's already very generic. It doesn't need to be more generic in any
substantive way, although it needs:
* the simplification of the ITEM_STRUCTURE part, which is already more
or less worked out
* an easier way to use plain ENTRY as a concrete type, also worked out
Being simpler than that isn't useful to implementers. If some
implementers only want to use the 13606 subset, that's fine.
>> 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.
Then it has solved everything, and we can stop work...
>> 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.
well, speaking as someone who has both worked on 13606 for 5 years, and
also used it, I know in exactly what it defines: an EHR Extract message
(part 1), and an Extract service interface (part 5). EHR Extracts are
what they are: an extract from an EHR / EMR / other similar kind of
patient record system.
The scope of 13606 is exactly about those Extracts (part 1), defining
their possible content (part 2) and moving the extracts around (part 5)
securely (part 4). That's exactly what it should be, I don't know anyone
else who has a problem with that.
>> 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.
it would be very useful to see these projects, are they posted
somewhere? Not having too many implementations is a good thing - it
means there is more room for movement on updating the standard - that's
> Sometimes in relation with HL7 CDA artefacts, sometimes to create
> applications for data entry, sometime integrated with ontological
> In the meantime I sincerely hope that harmonisation is possible
> without making too many unneeded remarks about potential partners.
my remarks are only about obtaining clarity in what we are all doing.
All of the current work in this area (13606, openEHR, other variants)
has to change to a) absorb its own lessons and b) achieve harmonisation.
We need to be clear about scope going forward, that's all.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-clinical