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
> 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 at oce
> aninformatics.com
> To
> > For openEHR technical
> discussions
> Sent by: <openehr-technical at openehr.org>
> openehr-technical
> cc
> -bounces at 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 at 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
> > which there is still a strong following.
> > I think the furture will be different.
> >
> >
> *
> With respect to clinical modelling I hope it will. Along with others, I
> have spent years trying to convince HL7 that single-source modelling
> was
> a good idea and worth pursuing. I hope there are enough results around
> in the various national programmes, commercial products, and
> universities to convince someone. If we can agree on this we can all
> move forward much faster.
>
> - thomas
>
> *
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
