Meaningful Use and Beyond - O'Reilly press - errata

Technical (archive)
1

I read the recently released O’Reilly book “Meaningful Use and Beyond” on Safari books today and found the following errors
and some quite blatantly false statements about OpenEHR.

Firstly is the claim by one of the authors, David Uhlman, that he was CTO of openEHR in 2001

  • a claim which Thomas Beale denies.
David Uhlman is CEO of ClearHealth, Inc., which created and supports ClearHealth, the first and only open source, meaningful use-certified, comprehensive, ambulatory EHR.... David entered health-care in 2001 as CTO for the OpenEHR project. One of the first companies to try com*mercializing open source healthcare systems* *, OpenEHR met face first with the difficult* *realities of bringing proven mainstream* *technologies into the complicated and some-* *times nonsensical world of healthcare.*

Secondly, a nonsensical statement about openEHR in the book…
p.161

OpenGALEN and OpenEHR are both attempts to promote open source ontology con-
cepts. Both of the projects have been maturing but some view these as unnecessary
additions or alternatives to SNOMED+UMLS. However, they are available under open
source licensing terms might make them a better alternative to SNOMED for certain
jurisdictions.

And this, p163…

OpenEHR is a controversial approach to applying knowledge engineering principles
to the entire EHR, including things like the user interfaces. You might think of Open-
EHR as an ontology for EHR software design. Many health informaticists disagree on
the usefulness of OpenEHR. Some believe that HL7 RIM, given its comprehensive
nature, is the highest level to which formal clinical knowledge managing needs to go.

I’m beginning to lose all respect for O’Reilly press. It’s been all downhill since the camel book.

Cheers
Michael Osborne

2

It would be interesting to see what US-based list members think of what Michael has quoted below. Is openEHR really seen as ‘controversial’ in the US? (Controversy can be good - at least it means debate).

The quote below about David Uhlman being CTO of openEHR in 2001 is certainly incorrect - I imagine it is supposed to read ‘OpenEMR’, going by what I see here in Wikipedia (in any case, openEHR has never had a ‘CTO’ position). That’s a surprisingly bad fault in O’Reilly editing; worse, the author page for David Uhlman on the O’Reilly website repeats the same error. This review on the same website seems to confirm a complete lack of review or editing of the original manuscript. O’Reilly obviously is missing basic mechanisms for quality control.

But the more interesting question is: are the opinions in this book about openEHR representative of a US view?

  • thomas
3

Crowdsourcing = Errata submission perhaps here

http://oreilly.com/catalog/errata.csp?isbn=0636920020110

Of the reviews I read there was reference to ‘rushed’ missing chapters, and poor proof reading.

Tom Seabury

4

For the most part, I find that people who write negative remarks most often know little about the subject. I for one have never viewed openEHR as controversial. I think openEHR is competitive as is HL7, IHE and most other organizations. Some of the competition is based on our belief that we are right; some on protection of our history and proprietary interests. Actually, much of our life is based on competition, and I don’t think it is a bad thing. Pot-shots and misstatements like in this book are actually a sign of success for openEHR. Don’t sweat it.

5

Comparing openEHR with SNOMED is plain wrong. Yes, part of the openEHR standard is an ontology of concepts, but this are high level concepts to model generic information structures, in the other hand SNOMED models fine grain concepts, with almost no structure. Certainly here is a place to collaboration since fine grain concepts could be use onside the generic model structures. So, here is no competition, is realy a good collaboration ground.

Cheers,
Pablo.

Secondly, a nonsensical statement about openEHR in the book…
p.161

OpenGALEN and OpenEHR are both attempts to promote open source ontology con-
cepts. Both of the projects have been maturing but some view these as unnecessary
additions or alternatives to SNOMED+UMLS. However, they are available under open
source licensing terms might make them a better alternative to SNOMED for certain
jurisdictions.

And this, p163…

OpenEHR is a controversial approach to applying knowledge engineering principles
to the entire EHR, including things like the user interfaces. You might think of Open-
EHR as an ontology for EHR software design. Many health informaticists disagree on
the usefulness of OpenEHR. Some believe that HL7 RIM, given its comprehensive
nature, is the highest level to which formal clinical knowledge managing needs to go.

I’m beginning to lose all respect for O’Reilly press. It’s been all downhill since the camel book.

Cheers
Michael Osborne

6

I think we should strengthen arguments that Pablo proposed as promoters of openEHR in the U.S., with scientific arguments and constructive criticism openEHR initiative is and will be very competitive.

Regards.

Carlos.

Carlos Luis Parra Calderon

Hospital Universitario Virgen del Rocío

7

I agree with Dr. Ed Hammond. I think that Uhlman point of view, is not totally wrong or right. Yes, as a software architect designing a EHR you know that the concept of separating the framework from data structure, urges a completely different design and OpenEHR abstracted it in a nice way. It can be considered as a best known practice to bridge ontology (or ontology like constructs like SNOMED CT) to real database and application design while it is impacted by RDBMS concepts and can be more enhanced by Object Oriented or Graph Theory thinking. OpenEHR IM is more clear, more coherent and integrated than HL7 RIM, yet it needs redesign for better abstraction and less exceptions. I think that those can not be considered as misstatement, but criticism that may lead us to new enhancements.

8

Considering the incorrect reference to openEHR in the author’s CTO position, without knowing conext of were it is done, perhaps all references were intended to be to openEMR?

Heath

9

Hi, Fred Trotter here, one of the two authors of the book in question. I wrote the portion covering OpenEHR, so I believe your complaints will ultimately come to rest with me.

Generally however, let me put forward a note on how we are thinking at O’Reilly . This book has been very popular, and we are pretty happy with it. But it important to understand who this book is targeted to. We intended the book to be focused towards O’Reilly’s primary readership, which is IT professionals and programmers. People who have no health IT experience. We have been pleased that clinical types have enjoyed it, but we were not aiming at them. We are also not currently selling the book in book stores. It is available only on the web and it has been overwhelmingly a e-book seller. This is the trend generally at O’Reilly and has been changing how we think about book publishing. I hope that give a little context here.

With that in mind, we wrote the book very quickly and with an aim at overviewing everything that an IT generalist needs to know about health IT. That means we intended it to be a mile wide and an inch thick. That inch needs to right however, and we will be fixing all of the real errors that we find. O’Reilly has realized that book publishing in the e-book era is alot more like software publishing than anything Gutenberg might have envisioned. We use software tools for revisioning, for tracking errata (bugs) for making changes and for pushing those changes out automatically to our readers. We also use what amounts to a free beta release process where we put the manuscript online for free for people to comment on in its pre-production state. Our book had the dubious honor of receiving more feedback during this process than any other O’Reilly book before us. Why? because doing a comprehensive book on health IT is extraordinarily difficult. We are covering lots and lots of technology issues that have deeply specialized medical-technical hybrid experts working on them and those experts, with all due respect to those of you in academia, are mostly disconnected from the boots on the ground programmers (which both David and I are) who have been actually implementing widely used systems for years. We took a tremendous amount of productive criticism from both sides of that river and we hope the book was made better for it.

Firstly is the claim by one of the authors, David Uhlman, that he was CTO
of openEHR in 2001

  • a claim which Thomas Beale denies.

Those less likely to believe that we would make outragous resume claims are quite correct. After much debate late in the book, David and I decided to go exclusively with the term EHR, rather than EMR. We believe (and we argue in the book) that the industry uses these terms interchangeably (whether or not they are right to is another question), but ONC had been clear…
http://www.healthit.gov/buzz-blog/electronic-health-and-medical-records/emr-vs-ehr-difference/

that they were focused on EHR systems, based on their reasoning that EHR systems were intended to be interoperable and EMRs were not. (of course that entirely depends on your definition of the two acronyms). We decided to bow to the ONC position on the term and replace all mentions of the term EMR with the term EHR. This decision came very late in the editing process and I decided to do a find and replace on the text. Obviously I made a mistake and replaced Davids OpenEMR experience with OpenEHR.

In short, this mistake is a typo. Thanks for pointing it out to us.

I also state in the book:
OpenGALEN and OpenEHR are both attempts to promote open source ontology con-
cepts. Both of the projects have been maturing but some view these as unnecessary
additions or alternatives to SNOMED+UMLS. However, they are available under open
source licensing terms might make them a better alternative to SNOMED for certain
jurisdictions.

Then I wrote:
OpenEHR is a controversial approach to applying knowledge engineering principles
to the entire EHR, including things like the user interfaces. You might think of Open-
EHR as an ontology for EHR software design. Many health informaticists disagree on
the usefulness of OpenEHR. Some believe that HL7 RIM, given its comprehensive
nature, is the highest level to which formal clinical knowledge managing needs to go.

Now, these are complex statements about OpenEHR. I am sure I might have gotten some of the details about OpenEHR wrong here. If I have done that, then please help correct me. I am all ears.

Still, I find it interesting how you can claim that they are “blatantly false statements” and/or “Pot-shots and misstatements” about OpenEHR. These are just asides regarding OpenEHR. They need to be correct, and if they are not we are happy to fix them. But OpenEHR at this stage, only deserves a few paragraphs of coverage in a generalist focused Health IT book. I am not convinced that OpenEHR is a relevant technology, and I believe David’s assessment would be even more dour.

Here is the bottom line reality: the Open Source EHR space has matured dramatically in the last 10 years. There are handful of projects that I know of that have literally hundreds of installations worldwide: the VistA variants, OpenMRS, OpenEMR, and ClearHealth. There are some other important projects that have potential, like Tolven, that I know of, but they simply have not garnered hundreds of installations.

I would be very happy to be proven wrong here, but as far as I know, there is no Open Source EHR that has been installed at even over 100 sites that has been based on the OpenEHR. I do not really care about proprietary land, because there are literally hundreds of different ways to architect an EHR system that are implemented by proprietary vendors. Again, please correct me if I am wrong, but I believe that means that the vast majority of EHR installations do not use OpenEHR. Frankly only a substantial fraction of those know anything about SNOMED/UMLS/RIM.

Please do not reply to me and tell me “but we are using OpenEHR in my hospital/clinic/school” that is great for you but that is not anything like wide-scale adoption. I know that OpenEHR has made inroads to several of the national systems, and that is really great. It is what earned OpenEHR a mention in the book at all. But nationalized EHR systems are a the perfect place to have “standardization for the sake of itself”, which means that while OpenEHR is being used successfully, there is no compelling reason why they could not just have gone with some other solution. As far as I am concerned, the nationalized systems that have adopted OpenEHR really count as a handful of really enormous installations.

I respect that you all have worked hard on this and I respect the careful thinking that you all seem to be doing, but OpenEHR is the kind of standard that is only really helpful if everyone is doing it. I do not see that kind of adoption happening. OpenEHR seems to be, in my eyes and in they eyes of on the ground Health IT implementors as a solution looking for a problem.

With that in mind I challenge you to find any health IT book, aimed at the US market, by a major publisher that even mentions OpenEHR. I know you guys are working hard and I know you have managed to convince some impressive technologists to your way of thinking (most notably Tim Cook). I do not see other books on meaningful use, or health IT in the US covering you -at all-. I am doing this to hedge my bets. I know I could be totally wrong about where OpenEHR is heading. Guessing what the future holds is pretty difficult.

At this point my mental summary for OpenEHR is one of the many “technically right but will never be adopted” technology ideas. I cannot write a book which is intended to warn IT people about all of the fruitless investments that they should expect to see all over the place in Health IT and give OpenEHR a free pass because I know and like some of the founders. Is OpenEHR a relevant technology or an interesting foot note? It is my job to make that technical decision and then include the results in the book. Right now, OpenEHR made the cut to get a mention in the book, but not the cut for me to say “hey this is a good idea”.

With that in mind, I would be happy to have factual corrections regarding OpenEHR which we can include in the next update to the book. I would also be happy to have someone on this list convince me that I am wrong about my assessment of OpenEHR. It is difficult because I see so much of what I have concerns about already mirrored on the OpenEHR list:

http://www.openehr.org/mailarchives/openehr-implementers/msg00880.html

Again, you do not need to convince me that you are “right” about the OpenEHR designs, you need to convince me that OpenEHR is “relevant”. Being right, sadly, has little to do with adoption. For instance, I am typing on a QWERTY keyboard right now, but I am convinced that this lady is technically right: http://workawesome.com/productivity/dvorak-keyboard-layout/

I am just convinced that she is relevant.

-FT

10

Hi Fred,

I think you are missing the point. The key thing we are working on in openEHR is interoperability, not open source. Open source health applications have historically not made any difference to interoperability, intelligent computing or anything else - they are the same as closed source systems that don’t do any of these things. This is not to say that they aren’t better quality software / solutions in other ways - some are very nice. But in general they have the same proprietary data formats and service interfaces as commercial solutions (making such definitions openly available doesn’t change anything).

Solving interoperability and intelligence in e-health (as for other domains) is very hard indeed, and solutions based on simple approaches only have marginal benefit. What matters to clinical people and actual health delivery is interoperability, regardless of closed or open source: open standardised (= widely agreed) information models, service interfaces and knowledge formalisms. Of course open source, done the right way does have a lot to offer, and can make the economics better, but it doesn’t specifically address the interoperability problem.

What I think you will see in the future is intelligent health computing platforms based on openEHR, or something like it (as you noted, Tolven also does not have much penetration today, but it also is a sophisticated solution that takes semantic interoperability seriously). See the CIMI forum to get some idea of the international backing for knowledge-driven architecture. Without these kind of model-driven architectures, semantic interoperability will remain a dream, as will any serious industry around decision support, business intelligence and data-based medical research, and any other application wanting to use computable patient-centred health data. Because of the time it has taken to mature the openEHR - and other related, and even competing - health computing platforms, solutions based on these platforms are only just starting to make serious inroads.

I have no problem with your view of openEHR in terms of limited penetration (today), but what I think would be a little more positive would be for the open source sector to actually take part in solving interoperability, rather than continuing to add to the problem. There are real synergies to be explored. Much of the new work in openEHR and related architectures is coming out open source. It would be great if existing open source health application developers were to get involved - e.g. by working with us and others (e.g. HL7 HSSP, IHE etc) on e-health service models. We on the other hand have a lot to learn about e-health applications.

Finally, I would guess that e-health is about 10% of the way to a truly useful full-featured intelligent and open e-health platform of the future. That means that books like yours should potentially be educating readers on the likely future, not the status quo.

  • thomas
(attachments)

OceanInformaticsl.JPG

11

Hi Fred,

Being neither part of the target audience of your book, nor an openEHR
user/implementer, allow me to focus on one the factual core statements
that was objected to:

OpenEHR is a [..] approach to applying knowledge engineering principles
to the entire EHR [..]. You might think of Open-EHR as an ontology for EHR software design.

This perception (whether true or not) will probably resonate with the
EHR&Interoperabilily community that I'm usually dealing with. The
perception is that openEHR is about systems architecture and systems
development, whereas that's less true for its "predecessor", the EN/ISO
13606 standard.

However, as Thomas points out, to state that openEHRs primary focus on
software design wouldn't do it justice: that's a means to an end. The
raison d'etre is achieving interoperability.

TTYL,

-Rene

12

Allow me to introduce my two cents.

For my personal point of view, the raison d'etre is the low costs
involved with software design and change-design.

To say it short, just create an archetype (and a GUI or other means of
data-entry) and you are in business, when working in niches, this is a
strong advantage.

Then, when breaking out of the niche, when connecting to other systems,
or devices, it is easy to write a layer to adapt to the
data-constellations which are offered or wanted.
When interoperability comes to it, via templates it is possible to come
to all sort of message-formats or message-standards, the software-logic
needed is less complicated then when in legacy-systems.

I have some experience in working with message-layers for legacy. Very
often, one has to forget all good habits of software-development.
Many legacy systems have become ugly in software-code. That is why
changes in legacy are often very expensive to implement and that is why,
often, errors occur.

OpenEHR offers a healthy base on which it is possible to keep your
future software-extensions simple and clean. This is because, it happens
all in the archetypes (and GUI's or other means of data-entry), not in
the kernel. It is important to realize that the kernel-specifications
have hardly changed for almost ten years. Compare this with a
legacy-system where changes hack deep into all layers of code, even to
the heart, the database-model.

regards
Bert Verhees

13

Hi Fred,

If your target audience for the book is IT professionals and programmers, you’d probabily like to be accurate in your statements. Since you’ve asked for corrections, let me try to explain what does not look right here.
Let’s take a look at the following excerpts shall we?

OpenGALEN and OpenEHR are both attempts to promote open source ontology con-
cepts. Both of the projects have been maturing but some view these as unnecessary
additions or alternatives to SNOMED+UMLS. However, they are available under open
source licensing terms might make them a better alternative to SNOMED for certain
jurisdictions.

First of all, what is “open source ontology concepts”?
openEHR has links to ontologies, but even with the extensive use of the term ontology, I would not call openEHR an ontology based specification. It is more of an information model, quite similar to HL7 V3 in some ways. So I think you’re classifying openEHR in the wrong way, putting it next to OpenGalen.

Second: what do you mean by open source?
openEHR is a specification, just like HL7. If what you are referring to computer software licensing when you use the term open source, then you are not talking about openEHR specification. You’re addressing the implementation(s) of the specification, which means you’re talking about actual software. If that is not the case, I don’t understand what the term “open source ontolology concepts” that defines both OpenGalen and openEHR according to your words actually means.

Third: Who are the parties who view these as unnecessary alternatives to SNOMED+UMLS (both are efforts close to ontology approach btw) If you can’t name them fine. But what aspects of openEHR and OpenGalen are unnecessary extensions? Again, you’re talking about ontology/terminology focused initiatives. As a professional in this domain, I’d see openEHR much closer to HL7 then UMLS or SNOMED

So in my opinion, these statements are positioning openEHR at the wrong spot in health IT, hence they are not correct.

Now to the next part:

OpenEHR is a controversial approach to applying knowledge engineering principles
to the entire EHR, including things like the user interfaces. You might think of Open-
EHR as an ontology for EHR software design. Many health informaticists disagree on
the usefulness of OpenEHR. Some believe that HL7 RIM, given its comprehensive
nature, is the highest level to which formal clinical knowledge managing needs to go.

There is nothing in the openEHR specification related to user interfaces. There are bits that are likely to become relevant to UI related implementation tasks, and this may have been mentioned at a fews spots (though I’m not sure), but openEHR specification does not offer or describe an approach to apply knowledge engineering to UI.
Again, you classify openEHR as an ontologic approach, then comes the next bit: “Many health informaticists disagree on the usefulness of openEHR”.
Again, you don’t give links or references to more detailed discussions of these many health informaticists, but could you at least mention the factors that diminish openEHR’s usefulness for your readers who are going to make decisions based on the information you’re giving them in your book?
Should the professionals reading your book take HL7 RIM as a more comprehensive IM than openEHR RM? Do you mean that openEHR’s knowledge management level is too high? Compositions, EHR etc are too abstract?
If so, I’d like to know why? Not because I’m trying to defend openEHR, but because I’d like a comprehensive, justified analysis before arriving technical conclusions, which you seem to be doing here (the conclusion, not the analysis).

For your information: the rest of your message after the parts I’ve discussed above is not really relevant to the critism you’ve received. You’ve put some effort into explaining why openEHR can’t be considered as a widely adopted standard, but that is not the reason you’re being critized, the correctness of statements about openEHR is what readers are disagreeing with you, not openEHR’s adoption.
Honestly, your long bits read as: “be happy that you’ve been mentioned in a book published by a big publisher, because you’re never going to make it” Please try to see that what is expected from you is your statements to be correct and as precise as possible when you’re addressing people about a technical topic. You’re not asked to dedicate a chapter to openEHR, you’re asked to do it properly even if you write a single sentence about it.

By all means, please do correct my mistakes, and put the corrections in your next edition, which would deliver something useful for everyone.

Kind regards
Seref

14

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.

Very confusing, and I have yet to see something compelling that can be done in OpenEHR that cannot be done with HL7 RIM.

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?

15

Op 18-02-2012 1:26, fred trotter schreef:

Very confusing, and I have yet to see something compelling that can be
done in OpenEHR that cannot be done with HL7 RIM.

It is not that I want to interfere between you and Thomas. I am happy to
leave the interoperability discussion with you.

Just want to exercise my mind with following statement.
OpenEHR is a system-specification, you can simulate a HL7 v3 RIM machine
on an OpenEHR kernel.
And also you can simulate a EN13606 machine on an OpenEHR-kernel.
And also, in the Netherlands we invented OranjeHIS (long time ago, but
still working to get it implemented), which is a datamodel for GP-systems.
You can use an OpenEHR-kernel to simulate this datamodel.

Not that you should do that, but it might be possible, but maybe you run
against some detail-problems and you will need some software-logic to
overcome them.
Maybe even, adjust the Reference Model.

Regards
Bert Verhees

16

First of all, what is “open source ontology concepts”?
openEHR has links to ontologies, but even with the extensive use of the term ontology, I would not call openEHR an ontology based specification. It is more of an information model, quite similar to HL7 V3 in some ways. So I think you’re classifying openEHR in the wrong way, putting it next to OpenGalen.

I will correct the mistake of putting it next to OpenGalen. It literally is just “next” to OpenGalen without an intention to imply that they are similar in any way.

Moreover, I am using ontology in the losest and most general way here. I suppose I should start strictly delineating between the notions of “model” and “ontology” but in reality openEHR is a good example of why that might not be such a good idea. It has some parallels with HL7 RIM and some parallels with SNOMED.

Second: what do you mean by open source?
openEHR is a specification, just like HL7. If what you are referring to computer software licensing when you use the term open source, then you are not talking about openEHR specification.

Open Source licenses can and frequently do apply to anything, including specifications, data, software sourcecode, images, 3d models, etc etc. As I understand it, the OpenEHR specification is licensed under FOSS licenses. (am I wrong about that?) and that in my mind is a significant advantage. HL7 is a proprietary ontology that can be expensive.

You’re addressing the implementation(s) of the specification, which means you’re talking about actual software. If that is not the case, I don’t understand what the term “open source ontolology concepts” that defines both OpenGalen and openEHR according to your words actually means.

Third: Who are the parties who view these as unnecessary alternatives to SNOMED+UMLS (both are efforts close to ontology approach btw) If you can’t name them fine.

In all honesty almost every standards person I discuss this with is either A. clearly affiliated with the OpenEHR project or B. either disinterested or unaware of OpenEHR. Granted it is still a small sample size, probably only 20 people total, but it is certainly bigger than most of my readers ability to get access to real experts to sample…

But what aspects of openEHR and OpenGalen are unnecessary extensions? Again, you’re talking about ontology/terminology focused initiatives. As a professional in this domain, I’d see openEHR much closer to HL7 then UMLS or SNOMED

So in my opinion, these statements are positioning openEHR at the wrong spot in health IT, hence they are not correct.

I can see that my positioning is incorrect, and that much, at least will be corrected…

Now to the next part:

OpenEHR is a controversial approach to applying knowledge engineering principles
to the entire EHR, including things like the user interfaces. You might think of Open-
EHR as an ontology for EHR software design. Many health informaticists disagree on
the usefulness of OpenEHR. Some believe that HL7 RIM, given its comprehensive
nature, is the highest level to which formal clinical knowledge managing needs to go.

There is nothing in the openEHR specification related to user interfaces. There are bits that are likely to become relevant to UI related implementation tasks, and this may have been mentioned at a fews spots (though I’m not sure), but openEHR specification does not offer or describe an approach to apply knowledge engineering to UI.

I think any “model” has to have some kind of reasonable expectation, either explicit or not, that a UI would have certain inclusions and exclusions. My understanding previously was that OpenEHR went much further in making these requirements explicit. Am I wrong about this? It was once presented to me as a benefit of OpenEHR vs others.

Again, you classify openEHR as an ontologic approach, then comes the next bit: “Many health informaticists disagree on the usefulness of openEHR”.
Again, you don’t give links or references to more detailed discussions of these many health informaticists, but could you at least mention the factors that diminish openEHR’s usefulness for your readers who are going to make decisions based on the information you’re giving them in your book?

The whole point here is that the thing that diminishes the usefulness of OpenEHR the most is its lack of adoption. (I am aware of the catch 22 here. I am unwilling to promote the technology to potential adopters, because I feel that it is not adopted)

Should the professionals reading your book take HL7 RIM as a more comprehensive IM than openEHR RM?

No, but it does seem to be more relevant.

Do you mean that openEHR’s knowledge management level is too high? Compositions, EHR etc are too abstract?
If so, I’d like to know why? Not because I’m trying to defend openEHR, but because I’d like a comprehensive, justified analysis before arriving technical conclusions, which you seem to be doing here (the conclusion, not the analysis).

I am doing a cursory technology analysis that asks one question: “Who is using this, to solve what problem?” The only answer that I can see is “not enough users” and “using it for something that HL7/SNOMED could do instead”

For your information: the rest of your message after the parts I’ve discussed above is not really relevant to the critism you’ve received. You’ve put some effort into explaining why openEHR can’t be considered as a widely adopted standard, but that is not the reason you’re being critized, the correctness of statements about openEHR is what readers are disagreeing with you, not openEHR’s adoption.

I understand that, and I am largely accepting the specific criticisms that have been made. But you have to understand that openEHR, and anything else covered in the book, must undergo a relevance check… the brevity that OpenEHR received was due to fact that I have trouble seeing its relevance. That brevity caused the “errors” that you are seeing. I have two options. If I think that the project is just the loser of a format war, then I just say “OpenEHR is an alternative to HL7 v3/RIM. It is cool cause it is Open Source, but nobody uses it. Heres a link http://openehr.org”

Or I can expand the section and ensure that it is right…

Honestly, your long bits read as: “be happy that you’ve been mentioned in a book published by a big publisher, because you’re never going to make it”

I did not mean for my comments to be taken that way. Instead it was intended to be taken as “hey we are trying to give you all a fair shake, unlike other publishers, could you please give us a break?”

17

Hi Fred, some comments between your lines.

Hope we can help you to get the v2.0 of the book soon :smiley:

18

Fred,

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

  • 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.

  • actual models of content (archetypes & templates), defined using this formalism, e.g. these ones on openEHR.org, and these ones 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 based on the archetypes

  • standard service interface definitions, e.g. these EHR services (being standardised into one ultimately)

The architecture overview 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) (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
19

(please, no flame wars, below I am just trying to explain my point of view to Fred;-)

There is no need to worry about a flame war. I am certainly dubious, but I take what you guys are doing and saying very seriously.
It seems like you are taking a totally different approach to semantic interoperability than I generally favor.

My view is that semantic interoperability is simply a problem we do not have yet. It is the problem that we get after we have interoperability of any kind. This is why I focus on things like the Direct Project (http://directproject.org) which solve only the connectivity issues. In my view once data is being exchanged on a massive scale, the political tensions that the absence of “true meaning” creates will quickly lead to the resolution of these types of problems.

The OpenEHR notion, on the other hand, is to create a core substrate within the EHR design itself which facilitates interoperability automatically. (is that right? I am trying to digest what you are saying here). Trying to solve the same problem on the “front side” as it were.

Given that there is no way to tell which approach is right, there is no reason why I should be biased against OpenEHR, which is taking an approach that others generally are not.

If that is the right core value proposition (and for God’s sake tell me now if I am getting this wrong) then I can re-write the OpenEHR accordingly.

Regards,
-FT

20

Hi Fred,

The OpenEHR notion, on the other hand, is to create a core substrate within the EHR design itself which facilitates interoperability automatically. (is that right? I am trying to digest what you are saying here). Trying to solve the same problem on the “front side” as it were.

I think that’s more acurated, but “substrate” is a little ambiguous here, I rather say that openEHR propose a generic standarized architecture based on the dual model (separate software from custom domain concepts). That architecture enables/simplifies interoperability later because the information to be interchanged between systems is formally defined (by archetypes: http://www.openehr.org/knowledge/). So any communication protocol and data format could be used for interoperability, and systems could interchange not only data, but the information definition too.

The key here is that within an openEHR based system, other standards like HL7, DICOM, SNOMED, MeSH, UMLS, ICD10, … could be implemented to, each one for it’s own task.

Hope that helps.