Fred,
On 18/02/2012 00:26, fred trotter wrote:
> Thomas,
> This is quit usable critique and I will certainly draw
> from it in future revisions of the work.
>
> You make the argument that OpenEHR is primarily for interoperability,
> and I can accept that fundamental argument. It is difficult to swallow
> however, when I hear the HL7 v3 wonks talking about how HL7 RIM is the
> solution to semantic interoperability. Are they confused or are you
> confused, because you are saying basically the same thing. From my
> perspective as in implementer it looks awefully like a blueray vs
> HDDVD war and it looks like OpenEHR is losing. But at the same time I
> keep hearing that HL7 RIM is "compatible" with and might be "merged"
> with HL7 RIM.
(please, no flame wars, below I am just trying to explain _my_ point of
view to Fred;-)
well there is an age-old debate there... Put it this way: we did not use
the HL7 RIM because the RIM + refinement method used in HL7 doesn't do
what we think is needed, which is the following:
* a single reference model
<http://www.openehr.org/releases/1.0.2/roadmap.html> for all data -
the openEHR RM. This is about 100 classes, including data types.
Data from any openEHR system anywhere can interoperate with another
openEHR-enabled system
o HL7 RIM is not a model of data, it is a model from which other
concrete message & doc schemas are derived by the refinement
method; people are now trying to use the RIM directly for this
purpose, but it isn't easy, because it was not designed for that
* a defined formalism in which models of content that control
configurations of RM instances - the archetype language and object
model <http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633>.
* actual models of content (archetypes & templates), defined using
this formalism, e.g. these ones <http://www.openehr.org/knowledge/>
on openEHR.org, and these ones <http://dcm.nehta.org.au/ckm/> in use
by the Australia government.
* A toolchain for making these archetypes, and also generating
downstream artefacts for direct programmer use
* a portable query language
<http://www.openehr.org/wiki/display/spec/Archetype+Query+Language+Description>
based on the archetypes
* standard service interface definitions, e.g. these EHR services
<http://www.openehr.org/wiki/display/spec/EHR+Service+Specification>
(being standardised into one ultimately)
The architecture overview
<http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/overviewTOC.html>
gives a pretty good picture of how it all fits together in openEHR.
>
> Very confusing, and I have yet to see something compelling that can be
> done in OpenEHR that cannot be done with HL7 RIM.
see above.
>
> Having said that, HL7 RIM is a proprietary ontology/model and OpenEHR,
> is not. That gives OpenEHR some usefulness even as an alternative
> model. Is that where I should see the value? Here is an information
> model that delivers semantic interoperability but is not proprietary?
Well, although HL7 technically does charge for use of the standard, I
would not call it proprietary - it is easy enough to obtain online at
HL7.org. The substantive differences from our point of view are mainly
in the difficulty of using the HL7 RIM because of the way it was
designed, which differs from normal object-oriented modelling practices.
If you want to compare something in HL7 to the openEHR reference model,
the CDA is closer. HL7 are now working on a newer simplified modelling
approach called Fast Health Interoperability Resources (FHIR)
<http://www.healthintersections.com.au/fhir/introduction.htm> (and also
on CDA release 3 I think).
Although I have a lot of technical problems with the HL7v3 approach, one
thing I can say is that they did conceive of the problem to be solved
and its solution at an appropriate level of complexity. I think they got
some technical detals wrong, and I think this is agreed in HL7 now,
hence the FHIR activity.
The bottom line is: the hard work on the openEHR interoperability
'stack' has been done - we have a decent modelling formalism
(internationally accepted - by ISO & CIMI), reference model (of course,
still evolving a bit), query language and emerging service models. The
current priority is to standardise the downstream products for
programmers, generated from templates. These are XSDs and APIs. There
have been versions running in production for about 3 years now, and they
need to be described in specifications. These last artefact types close
the circle between clinician-designed archetypes & terminology, to
developer artefacts, enabling truly semantically enabled applications to
be built by normal developers. The overall ecosystem is a platform
concept, not a silo concept, and very well suited to specialist groups
building small (and large) open source components and apps (and even
back-ends).
That's the 'sell'. It has taken some time, but all the proof is there
now; all that is needed is some further building out of tools, creating
the final specifications.
hope this clarifies
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120218/e8bffaf8/attachment.html>
