Ed,
In an attempt to "close the gap", I have penned an article indicating how
HL7 might make use of openEHR archetypes to overcome some of the inherent
shortcomings of RIM based modelling for CDA document entries.
You can read it at:
http://www.openehr.org/wiki/display/stds/openEHR+Archetypes+for+HL7+CDA+Documents
Interested in your thoughts about how this could be progressed.
regards,
Eric Browne
Ed Hammond wrote:
Thanks Eric. I'll take a look when I get a chance (soon I hope) and give
you my comments.
Ed
"Eric Browne"
<eric.browne@mont
agesystems.com.au To
> "For openEHR technical discussions"
Sent by: <openehr-technical@openehr.org>
openehr-technical cc
-bounces@openehr.
org Subject
HL7 and openEHR. was Re: Please
respond by Nov. 5th: Known
11/06/2008 07:12 Free/Open Source EHR/EMR
PM Deployment Count.
Please respond to
For openEHR
technical
discussions
<openehr-technica
l@openehr.org>
Ed,
In an attempt to "close the gap", I have penned an article indicating how
HL7 might make use of openEHR archetypes to overcome some of the inherent
shortcomings of RIM based modelling for CDA document entries.
You can read it at:
http://www.openehr.org/wiki/display/stds/openEHR+Archetypes+for+HL7+CDA
+Documents
Interested in your thoughts about how this could be progressed.
regards,
Eric Browne
Ed Hammond wrote:
Thanks. I agree that things are moving ahead. I wish we could remove
some
of the animosity (maybe I am reading it worng) towards HL7 (not from
you),
and close the gap between the two efforts.
best Regards.
Ed
Thomas Beale
<thomas.beale@oce
aninformatics.com
To
> For openEHR technical discussions
Sent by: <openehr-technical@openehr.org>
openehr-technical
cc
-bounces@openehr.
org
Subject
There is no HL7. It is an organization with many members. Most people who
believe that HL7 is just message-centric are outside people, plus, I admit,
some are in HL7. In my opinion, the CDA, and certainly level 3, are
templates/archetypes in compositiopn. I further believe that the CDA will
adopt clinical statements. On the other hand, I find that messaging still
has its place.
Given that, I think openEHR has excellent archetypes that have intellectual
value. In my opinion, there is considerable interest in archetypes in HL7.
I particularly believe the board is committed to this direction. We
certainly have several persons on the board that are strongly committed to
that direction. Thinking HL7 as only message-centric is coupled with v2 of
which there is still a strong following.
I think the furture will be different.
Ed
Thomas Beale
<thomas.beale@oce
aninformatics.com To
> For openEHR technical discussions
Sent by: <openehr-technical@openehr.org>
openehr-technical cc
-bounces@openehr.
org Subject
Re: Please respond by Nov. 5th:
Known Free/Open Source
11/06/2008 05:20 EHR/EMR Deployment Count.
PM
Please respond to
For openEHR
technical
discussions
<openehr-technica
l@openehr.org>
William E Hammond wrote:
Thanks. I agree that things are moving ahead. I wish we could remove
some
of the animosity (maybe I am reading it worng) towards HL7 (not from
you),
and close the gap between the two efforts.
best Regards.
*Ed,
I think think the biggest problem with respect to HL7 is the
message-centric approach to clinical content modelling. I really don't
understand why HL7 doesn't want to use archetypes and templates, to
express clinical and related content. It works and is 'good enough' for
now, and most importantly, it supports reusability - i.e. it is a
single-source modelling framework. In HL7 it is very difficult to reuse
an RMIM for a display screen, a data capture form, as a basis for
generating a piece of code, and as a source of any number of XML-based
outputs, including messages (these are now working in production), also
PDF and HTML variants. Let alone as a basis for writing re-usable
queries and expressing Snomed data bindings. The querying is working in
real systems now, and we are working in earnest with IHTSDO on the
Snomed side of things. It's not perfect of course, and more work is
required in areas like representation of process (e.g. care plans), but
the reuse capability is very high.
Now, groups of clinicians working on archetypes and Snomed have already
expressed the desire not to have to rebuild what they create in HL7
messages or CDA templates or any other concrete technology. Nor do we
want to have to write queries that are specific to each of these forms,
or define more than one kind of Snomed binding.
- thomas
Hi Ed
I think that there is a sense of ‘competition’ from both sides of the fence unfortunately as people push their ideas and people who are passionate about what they are doing work towards a common goal of ubiquitous interoperability. I think that openEHR people have had to push very hard to get to where we are at the moment with very limited resources and so at times the passion may come across as animosity. On the other hand, there has been a lot of opposition in the past to openEHR from many in the HL7 community. There are positive things that come out of this I think as challenging the status quo can lead to better outcomes and rigorous, open minded debate is a good thing.
I think that as long as we all have open minds and are willing to look out of the box, then we should be able to move things forward. We are certainly seeing many jurisdictions in the world moving strongly towards openEHR for clinical modelling and the logical record architecture.
For your interest, apart from the systems that Tom has already mentioned, we are starting to see vendors moving to openEHR for their clinical repositories. In Australia alone, there are at least 6 system vendors that are building systems based on openEHR repositories and interestingly, not all of these are using Ocean tools either. We are also working with a large research database for the Cancer Council in Victoria, Australia to bring 18 years of longitudinal data into an openEHR repository to future proof it.
regards Hugh
William E Hammond wrote:
Ed:
> On the other hand, I find that messaging still has its place
Yes. HL7 is not just interested in clinical records and logical record
architecture but also in capturing healthcare processes, both
administrative and clinical. "messages" is simply the way that we
describe the agreed processes. Increasingly, we will be migrating to a
services-based language to describe the processes.
Hugh:
well put.
We will need to search for a productive way forward so that
instead of looking across the technical gulf at each others
strengths and trying to decide whether to critise, we can
actually share strengths.
Grahame
Hugh Leslie wrote:
William E Hammond wrote:
Of course, it depends on the definition of singlesource modeling. HL7 is
pursuing a course that uses a common process but multiple expert groups to
create the clinical content. I also think we still do not know how far to
take templates/architypes. For example, I think developing a template for
a general physical examination will never be used by the diverse clinical
community.
The real question is how will openEhr and HL7 work together. We we compete
with a tension in each contact, will we work separately with redundancy and
mapping from one group to another, or will we find a process that permits
use to work jointly. I personally think the clinical content of templates
is by far the most valuable component of this work. We could live with
mapping - although in my opinion, this is not the best result.
There are many variables and we obviously need a dedicated commitment to
making something work. Perhaps ISO is the vehicle for that interaction.
Both groups seem to be moving ahead with success in both groups. Maybe
that is what will be for the moment. I don't know if an unbiased
discussion is possible, because the players for both sides think we are
doing it the correct way. And there is also that thing called momentum.
I read and remember your comments on groups developing standards earlier
inthe year. Ideally we will be able to choose a course of action designed
to produce the best results.
Thanks for the exchange.
Ed Hammond
Thomas Beale
<thomas.beale@oce
aninformatics.com To
> For openEHR technical discussions
Sent by: <openehr-technical@openehr.org>
openehr-technical cc
-bounces@openehr.
org Subject
Re: Please respond by Nov.
5th: Known Free/Open
11/07/2008 01:33 Source EHR/EMR Deployment
PM Count.
Please respond to
For openEHR
technical
discussions
<openehr-technica
l@openehr.org>
William E Hammond wrote:
There is no HL7. It is an organization with many members. Most people
who
believe that HL7 is just message-centric are outside people, plus, I
admit,
some are in HL7. In my opinion, the CDA, and certainly level 3, are
templates/archetypes in compositiopn. I further believe that the CDA
will
adopt clinical statements. On the other hand, I find that messaging
still
has its place.
Given that, I think openEHR has excellent archetypes that have
intellectual
value. In my opinion, there is considerable interest in archetypes in
HL7.
I particularly believe the board is committed to this direction. We
certainly have several persons on the board that are strongly committed
to
that direction. Thinking HL7 as only message-centric is coupled with v2
of
Dear Ed,
Good to hear from you. It is important that we get a formal solution in this
space and that it works for clinicians. I know there is a push from everyone
to get things working and I attended the DCM group from the outset and over
a few years. This was set up to be outside HL7 by HL7 participants to try
and get some progress and is now within the HL7 space. I know you are making
mighty efforts to get the clinicians involved within HL7.
Obviously the openEHR community have been at this a long time and have
targeted the formal expression of clinical content for EHRs from the outset.
We are a smaller group but now have a number of countries going in this
direction. Some have considerable experience in HL7 version 3, so we can
assume that what we are doing is at least complementary. It is the general
belief that the openEHR archetypes developed can be used to constrain HL7
version 2 and version 3 messages, although the choice of how to represent
the clinical content in the HL7 domain has to be hand crafted if the
intended use of all the codes is to be respected. I do not believe that the
situation will be any different if another formalism is chosen for DCM (ie -
then models will have to be hand crafted in HL7 and openEHR).
There is one key reason for using openEHR, and it addresses the issue when
you say that 'no-one will use a single template for physical examination'.
It is the ability to reuse the archetypes in as many templates as necessary
without creating new semantic expressions. It is worth looking at the two
approaches:
openEHR HL7 v3 HL7 CDA
1. Information model openEHR RM HL7 RIM CDA r2
(Schema)
2. Semantic commitment Archetypes Message Template
(Meaning)
3. For purpose Template Template
Compound templates (For purpose)
While the HL7 methodology has a number of layers, they are used differently
in v3 and CDA. Also, in the message environment a different schema is used
for each message. The result is that we need a different transform for the
different paradigms. This is not a problem but it does mean work.
A further advantage we are seeing with openEHR is its much smaller
terminology footprint. Much of the semantics is captured in the archetypes
themselves. While this does lead to a hue and cry from the terminology
space, it is in fact much more straightforward to express meaning with
relationships and descriptions in a single artefact. If is often very
difficult to determine what is the appropriate SNOMED code for something
that clinicians can easily understand. SNOMED's definitional relationships
may be ontologically correct but they are often not clinically meaningful).
Obviously as the library of archetypes grows we need to keep a tight grip on
the relationships of these semantic expressions. We are doing this with a
web based controlled authoring environment:
http://openehr.org/knowledge (beta testing environment - no link from site)
This is not being pushed at the moment, but the tools we are using allow
jurisdictions to subscribe to a set of archetypes they want to use or
specialise locally. They can add locally specific archetypes if necessary,
remembering that if we do not share archetypes then we do not have
interoperability. We do want to move away from the (carbon heavy) 3 monthly
meeting cycle to get this work done.
I have made many approaches to HL7 and yourself over the years and offered
to bring this work to that community. I absolutely understand why that might
be difficult in the US context. The other problem is that openEHR is a
specification for a standard EHR service (not a clinical application) which
may be installed within EHR systems or simply expressed as an interface.
This does go a little against the ethos of the messaging community.
The detailed clinical modelling work should, in my opinion, use an HL7 or an
openEHR formalism, rather than a new one. I do not have a problem with UML
or Word or Excel to get ideas down - but we need a formal expression that
can be used by EHR vendors to produce information in a standard manner. If
HL7 has a suitable technology for this purpose then openEHR can transform
from that space for use within openEHR based systems. I would ask you to
consider the converse if it is difficult with HL7 tools, as we will all make
a lot more progress if we are aligned. The only requirement I have is that
it does not involve reading paper specs or UML and hand crafting the output.
I look forward to working with the clinical community in whatever direction
this takes. I have always promised to pack up and go home when there is a
means of sharing data that works. I am interested also in getting to the
point that a hospital can keep its data and health records and swap clinical
systems when appropriate! The EHR service.
William Goosens has approached Dipak and myself and will approach the
openEHR Foundation about the ISO initiative. If the remit is correct, this
could be a useful initiative. Meanwhile we will get the formal models out
there for scrutiny and try and maximise clinical participation. We would
love the clinicians in the US to feel they could participate and feel
confident that the models can be transformed to message and document
specifications.
There is a lot to be done.
Cheers, Sam