# Meaningful Use and Beyond - O'Reilly press - errata **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2012-02-12 11:22 UTC **Views:** 1 **Replies:** 24 **URL:** https://discourse.openehr.org/t/meaningful-use-and-beyond-oreilly-press-errata/15150 --- ## Post #1 by @Michael_Osborne 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 --- ## Post #2 by @thomas.beale 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](http://en.wikipedia.org/wiki/ClearHealth) 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](http://www.oreillynet.com/pub/au/4766) on the O'Reilly website repeats the same error. [This review](http://shop.oreilly.com/product/0636920020110.do#PowerReview) 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 --- ## Post #3 by @SEABURY_Tom_NHS_DIGI Crowdsourcing = Errata submission perhaps here [http://oreilly.com/catalog/errata.csp?isbn=0636920020110](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 --- ## Post #4 by @Dr_Ed_Hammond_Ph.D 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. --- ## Post #5 by @pablo 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 --- ## Post #6 by @Carlos_Luis_Parra_Ca 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 --- ## Post #7 by @Abbas_Shojaee 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. --- ## Post #8 by @Heath_Frankel3 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 --- ## Post #9 by @fred_trotter 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/](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](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/](http://workawesome.com/productivity/dvorak-keyboard-layout/) I am just convinced that she is relevant. -FT --- ## Post #10 by @thomas.beale 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](http://informatics.mayo.edu/CIMI/index.php/London_2011) 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](http://www.openehr.org/wiki/display/spec/openEHR+Service+Model). 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 [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #11 by @system 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 --- ## Post #12 by @system 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 --- ## Post #13 by @Seref 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 --- ## Post #14 by @fred_trotter 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? --- ## Post #15 by @system 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 --- ## Post #16 by @fred_trotter > > > > 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](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?" --- ## Post #17 by @pablo Hi Fred, some comments between your lines. Hope we can help you to get the v2.0 of the book soon :D --- ## Post #18 by @thomas.beale 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](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 - 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 --- ## Post #19 by @fred_trotter > (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](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 --- ## Post #20 by @pablo 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. --- ## Post #21 by @system Op 18\-02\-2012 22:24, pablo pazos schreef: > 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\. > Supplementary to what Pablo wrote, I have a real life example\. In the Netherlands, HL7v3 messaging would have become mandatory for every Health\-related\-system, from the kitchen in a health\-institution, a GP\-system, or a medical\-specialist system\. The idea was \(very simply said\) to create a message\-oriented "network" where all these systems should connect\. Every health\-related system was expected to run Hl7v3 messaging on top of it, or the system would be excluded from this "network" and, as a result, possibly also excluded from business in healthcare\. So the pressure was big, and most systems succeeded in producing and reading HL7 messages\. Most systems, of a big variety, architectural, platform, etc, can now implement HL7v3 messaging, an OpenEHR\-system, with all its flexibility can also\. --- ## Post #22 by @thomas.beale Fred, that's pretty much it. We can disagree whether we should solve the sem-interop problem now (us; harder, longer) or later (you; get more going faster), but that's not a real debate - in some places our view makes more sense, in others yours is the practical sensible approach. Our main aim is to enable *intelligent computing* on health data; doing that means semantic interoperability has to be solved. Otherwise, there is no BI, CDS or medical research based on data. My only worry about not taking account of semantic / meaning issues now is that it will cost more later, than if it were included now. I still think that there is synergy to be explored in the coming 12m-2y between the openEHR community and the open source health Apps community (if I can call it that). - thomas --- ## Post #23 by @ian.mcnicoll Hi Fred, Thanks for coming along here\. It has been an interesting discussion\. I just wanted to pick up on one point you made \.\. "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\." Whilst I agree that you need to take one step at a time and get simple connectivity going first, our experience from the UK is that once this is established, the small trickle of demand for semantics grows very quickly\. In the absence of some kind of agile mechanism/ framework to meet this demand and quickly reconcile differences across very different communities and specific use cases, projects and vendors just resort to doing their own thing\. So in the UK, in spite of full connectivity, adherence to syntactic standards, and some local successes with semantic exchange, we have at least 8 different semantically incompatible expressions of 'GP Medication' having to be dealt with by producers/consumers of messages\. Getting this right is extremely difficult but I believe the 'archetype' approach of openEHR/ CIMI and tools like CKM, are the only realistic way of getting a handle on this\. This has much in common with the PCAST idea of 'molecules' \- see Wes Rishel's excellent summary http://blogs.gartner.com/wes_rishel/2011/02/13/pcast-documents-vs-atomic-data-elements/ Regards, Ian Dr Ian McNicoll office \+44 \(0\)1536 414 994 fax \+44 \(0\)1536 516317 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@oceaninformatics\.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www\.openehr\.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www\.phcsg\.org --- ## Post #24 by @Koray_Atalag Hi Fred, Apropos to Tom I’d say openEHR is also equally to do with *software maintainability*; thanks to the dual or multi-level modelling and model driven development. This is my main research area as well as open source software. I agree with Tom’s comments that being open source by itself is not enough (for any software quality aspect I believe) and must be accompanied with open standards. If I was asked to explain openEHR to my mother I’d probably say: ‘*it is about getting information right in healthcare*’. I usually find this statement as the starting point when talking to other audiences such as computer scientists and developers. Perhaps you’ll find useful as well. Cheers, -koray --- ## Post #25 by @tonyshannon Dear all, It's great to see some healthy debate over these issues of openEHR vs "the rest" of open source in healthcare\. I know enough of Fred Trotters writings to know he must be a good guy, raising awareness of open source in healthcare for the common good\. Equally I've been an advocate of openEHR for some years now\. While some of the issues raised may make some uncomfortable there is no value in shooting the messenger here at all and I appreciate this discussion\. So Fred thank you for making the effort to mail this list, honestly admitting some issues with your original article and usefully exposing other key issues here\.\.\. \.\.such as, why many folks \(including ourselves\!\) may not yet easily understand the right place for openEHR in the world\. Fred and Tom have already had a useful exchange which illustrates some of the gap between those who promote open source and openEHR\. That there is any gap in understanding across these niche fields illustrates how early this informatics science is\. We all need to communicate the place of open source and openEHR better\. Please see my related articles here which I hope are a help\. \(Further feedback welcome and I'll make these easier to find from openEHR\.org\) http://frectal.com/book/healthcare-change-the-way-forward/ Healthcare Informatics needs to pursue not just the holy grail of semantic interoperability at an international/ national level, but a better fit with the complexity of healthcare and core clinical processes at the frontline\. Furthermore better usability, scalability and maintainability of locally/nationally developed solutions are all required\. My original involvement in openEHR stemmed from these interests in healthcare improvement and the people process & technology issues within\. As I've looked at the diverse Complex Adaptive System that is healthcare, amidst the many teams I work with I see common patterns in process everywhere\.\.\. such that I believe healthcare needs a generic, clinical process oriented, service oriented architecture platform, which I believe openEHR and its two\-level modelling can offer\. http://frectal.com/book/healthcare-change-the-way-forward/healthcare-openehr%e2%80%99s-potential-to-handle-complexity-diversity/ This complex system & people/process/technology approach is key for me in explaining both the value of openEHR and open source\. On the other hand if we make the case for openEHR as key to semantic interoperability alone, the layman would be rightly confused as semantic interoperability currently has several other champions \(HL7/IHTSDO etc\)\)\. In the past the openEHR archetype & template paradigm has usefully allowed me to design clinical templates for chest pain, abdominal pain, head injury pathways that reuse the same clinical components \(archetypes\)\. Yet I would be the first to accept Freds useful criticism that openEHR designs \(inc my own\) have not yet been usefully/widely implemented at the frontline\. So I've come to the view that there is a key gap between the eHealth standards efforts \(inc\. openEHR et al\) and innovators at the frontline\.\.\.\. which I believe open source and related tooling will be key to bridging\. Which is one of the reasons I've more lately turned to more pragmatic frontline efforts \(such as a local open source clinical portal development\)\. http://frectal.com/2011/10/21/leeds-takes-a-lead/ So I share the view that open source is a key ingredient required in the healthcare ecosystem\. However I'm aware that a myriad of open source efforts may just perpetuate the disconnect in healthcare, i\.e\. open source approaches are not enough to address healthcares problems alone\. Therefore I suggest that open source and openEHR efforts should be compared/aligned/combined where possible\. Therefore the way forward should not be about choosing between pragmatic open source efforts \(eg NHIN Direct/Connect\) and a more purist openEHR way\. We simply need to align the efforts of those tackling frontline challenges with pragmatic open source efforts and the long term goal that openEHR serves\. Such is the approach we are now taking here in Leeds, where we are planning to align our open source clinical portal effort with a small number of clinically useful openEHR archetypes \(ie Adverse Reaction, Diagnosis etc\) within our Service Oriented Architecture plans\. Finally I would not wish to see openEHR explained as a rare and purist aspiration, nor open source as a cheap shortcut \- but both offering key useful elements into the healthcare ecosystem that we are all trying to improve\. Hope that helps, Kind regards, Tony Dr\. Tony Shannon Consultant in Emergency Medicine, Leeds Teaching Hospitals NHS Trust Clinical Lead for Informatics, Leeds Teaching Hospitals NHS Trust Honorary Research Fellow, University College London Director, Frectal Ltd\. \+44\.789\.988 5068 www\.frectal\.com --- **Canonical:** https://discourse.openehr.org/t/meaningful-use-and-beyond-oreilly-press-errata/15150 **Original content:** https://discourse.openehr.org/t/meaningful-use-and-beyond-oreilly-press-errata/15150