Meaningful Use and Beyond - O'Reilly press - errata
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 -- Fred Trotter http://www.fredtrotter.com ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics http://www.oceaninformatics.com/* Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS, British Computer Society http://www.bcs.org.uk/ Health IT blog http://www.wolandscat.net/ * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/09766f07/attachment.html -- next part -- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/09766f07/attachment.jpg
openEHR - Persistence of Data
Other models I didn't try yet are Object Oriented DBs and Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast for store highly hierarchical structures, but you need to write some ugly queries if you want your data back :D Aren't several major OpenEHR systems using XML or stored blobs on top of a rather minimal DB schema? The problem with ORM systems would ultimately be a rather bloated schema and hard-wired classes to accommodate that schema. Yes, ORM lets you automate the creation of DB data structures and classes, but, once created, they become part of the schema and your DLLs, which is fine until you have many hundreds of them (tables and classes defined in autogenerated code, etc.). Randy Neall Veriquant, L.L.C. On Thu, Feb 16, 2012 at 5:26 PM, pablo pazos pazospablo at hotmail.com wrote: Hi M?rcio, There is no standard persistence model, the persistence mechanism is not in the standard scope. There are many ways of storing openEHR RM instances (archetyped data), the only thing to take into account is that the information to store will be highly hierarchical. Said that, in EHRGen [1] we use a relational model with an Object-Relational Mapping [2] tool (GORM from Grails Framework[3]). The advantage of that is that you have a complete and validated RM instance persisted on the DB, and you can query for complete objects or single data ELEMENTS. I've written ORM tools myself [4] and the main problem is the amount of joins you need to load a complete structure, but in my experience you never load a complete structure for a real time interaction with the user, and you alway can cach? some data. This approach is straight forward, because all you need are the classes of the RM, and you delegate DB stuff to the ORM tool. Other models are viable too, like K/V [5] or EAV [6] approaches (mentioned by Bert). This approaches are fast for saving and loading data, the problem is that you need to have some complex logic above that for constructing a complete RM instance on memory, because K/V is a flat representation of a higly hierarchical tree structure. Other models I didn't try yet are Object Oriented DBs and Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast for store highly hierarchical structures, but you need to write some ugly queries if you want your data back :D Hope that helps. [1] http://code.google.com/p/open-ehr-gen-framework/ [2] http://grails.org/ [3] http://en.wikipedia.org/wiki/Object-relational_mapping [4] http://code.google.com/p/yupp/ [5] http://en.wikipedia.org/wiki/NoSQL [6] http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos http://twitter.com/ppazos -- From: mdckoury at gmail.com Date: Thu, 16 Feb 2012 16:53:19 -0300 Subject: openEHR - Persistence of Data To: openehr-technical at openehr.org Hello guys, i'm starting a research about the persistence model of Archetype data, that stores the information entered by the user of the system. I would like to know if there is a indication of the openEHR standard for what kind of model schema should be used in DataBase, and if there are researchs in this area. Thanks in advance, *M?rcio Costa* B.Sc. in Computer Science @ Cin/UFPE M.Sc. Candidate in Computer Science @ CIn/UFPE MSN: mdckoury at gmail.com ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/54de63ba/attachment.html
Meaningful Use and Beyond - O'Reilly press - errata
On 17-02-12 14:39, Rene Spronk (Ringholm) wrote: 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. 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
openEHR - Persistence of Data
/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/9009309a/attachment.html
openEHR - Persistence of Data
Hi! On Thu, Feb 16, 2012 at 23:26, pablo pazos pazospablo at hotmail.com wrote: Other models I didn't try yet are Object Oriented DBs and Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast for store highly hierarchical structures, but you need to write some ugly queries if you want your data back :D Not necessarily that ugly... we curently auto-convert AQL to XQuery and execute towards an XML database. Those queries are very readable. Then the question is what kind of client system you are aiming at. For some use cases you don't really need to map things back to openEHR-RM-objects, in web browser based GUIs for example you can keep treating the data as documents, document fragments, fragment lists etc. and use DOM manipulations, jQuery or similar approaches for most data manipulation needs. Good luck with your work M?rcio and please keep us informed! Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
openEHR - Persistence of Data
On 17/02/2012 14:50, Randolph Neall wrote: Other models I didn't try yet are Object Oriented DBs and Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast for store highly hierarchical structures, but you need to write some ugly queries if you want your data back :D Aren't several major OpenEHR systems using XML or stored blobs on top of a rather minimal DB schema? Correct - you would not use XML blobs in a system of any serious size and transaction requirements, binary is needed. But blobbing with very smart adaptive indexing works very nicely on relational DBs, where the RDB becomes a smart blob manager. - thomas
Meaningful Use and Beyond - O'Reilly press - errata
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/30ecfb97/attachment.html
openEHR - Persistence of Data
On 17-02-12 16:21, Erik Sundvall wrote: For some use cases you don't really need to map things back to openEHR-RM-objects Hi Erik, the information in this reply you give is very limited. So excuse me if I miss the point. How do you validate incoming data against the archetypes? That is the reason I create an RM-object, for validation-purpose. I don't need it for other purposes. And another question It looks to me that GUI's have a complicated constellation when they need to work with hierarchical and complex-structured XML. Maybe you disagree. I am interested in your solutions. Bert
openEHR - Persistence of Data
-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/68f5d9e3/attachment.html
openEHR - Persistence of Data
Hi Erik, you are right, the uglyness depends on 1. the queries you want to execute and 2. the programmer background. For 1. the common queries like get all records for this patient in this time window, are not that ugly, but more complex queries could be.For 2. for a XML guy, writing xPath based queries is ok, but for a SQL is a pain in the a55. :D I'm hoping to see that paper on AQL-xQuery soon! I totally agree that inside the system maybe you don't need a complete RM structure to handle data instances, but for the service layer (sharing information with other systems) this is a must. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Fri, 17 Feb 2012 16:21:29 +0100 Subject: Re: openEHR - Persistence of Data From: erik.sundvall at liu.se To: openehr-technical at openehr.org Hi! On Thu, Feb 16, 2012 at 23:26, pablo pazos pazospablo at hotmail.com wrote: Other models I didn't try yet are Object Oriented DBs and Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast for store highly hierarchical structures, but you need to write some ugly queries if you want your data back :D Not necessarily that ugly... we curently auto-convert AQL to XQuery and execute towards an XML database. Those queries are very readable. Then the question is what kind of client system you are aiming at. For some use cases you don't really need to map things back to openEHR-RM-objects, in web browser based GUIs for example you can keep treating the data as documents, document fragments, fragment lists etc. and use DOM manipulations, jQuery or similar approaches for most data manipulation needs. Good luck with your work M?rcio and please keep us informed! Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/89e04227/attachment.html
openEHR - Persistence of Data
Do Anyone knows about some papers of persistent storing? att, *M?rcio Costa* B.Sc. in Computer Science @ Cin/UFPE M.Sc. Candidate in Computer Science @ CIn/UFPE MSN: mdckoury at gmail.com Em 17 de fevereiro de 2012 17:59, M?rcio Costa mdckoury at gmail.comescreveu: i would like to thank everyone for the information and attention. i'm trying to do a review about this subject to start my research, but i will do something to analyse the best way to model and persist this kind of data. Best Regards, *M?rcio Costa* B.Sc. in Computer Science @ Cin/UFPE M.Sc. Candidate in Computer Science @ CIn/UFPE MSN: mdckoury at gmail.com 2012/2/17 pablo pazos pazospablo at hotmail.com Hi Erik, you are right, the uglyness depends on 1. the queries you want to execute and 2. the programmer background. For 1. the common queries like get all records for this patient in this time window, are not that ugly, but more complex queries could be. For 2. for a XML guy, writing xPath based queries is ok, but for a SQL is a pain in the a55. :D I'm hoping to see that paper on AQL-xQuery soon! I totally agree that inside the system maybe you don't need a complete RM structure to handle data instances, but for the service layer (sharing information with other systems) this is a must. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos http://twitter.com/ppazos Date: Fri, 17 Feb 2012 16:21:29 +0100 Subject: Re: openEHR - Persistence of Data From: erik.sundvall at liu.se To: openehr-technical at openehr.org Hi! On Thu, Feb 16, 2012 at 23:26, pablo pazos pazospablo at hotmail.com wrote: Other models I didn't try yet are Object Oriented DBs and Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast for store highly hierarchical structures, but you need to write some ugly queries if you want your data back :D Not necessarily that ugly... we curently auto-convert AQL to XQuery and execute towards an XML database. Those queries are very readable. Then the question is what kind of client system you are aiming at. For some use cases you don't really need to map things back to openEHR-RM-objects, in web browser based GUIs for example you can keep treating the data as documents, document fragments, fragment lists etc. and use DOM manipulations, jQuery or similar approaches for most data manipulation needs. Good luck with your work M?rcio and please keep us informed! Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/10fda046/attachment.html
Meaningful Use and Beyond - O'Reilly press - errata
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 -- Fred Trotter http://www.fredtrotter.com ___ openEHR-technical mailing listopenEHR-technical at openehr.orghttp://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- [image: Ocean Informatics] *Thomas Beale Chief Technology Officer, Ocean Informaticshttp://www.oceaninformatics.com/ * Chair Architectural Review Board, *open*EHR Foundationhttp://www.openehr.org/ Honorary Research Fellow, University College Londonhttp://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS, British Computer Societyhttp://www.bcs.org.uk/ Health IT blog http://www.wolandscat.net/ * * ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Fred Trotter http://www.fredtrotter.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/5b744d87/attachment.html
Meaningful Use and Beyond - O'Reilly press - errata
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? 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Fred Trotter http://www.fredtrotter.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/5c51daaa/attachment.html
Meaningful Use and Beyond - O'Reilly press - errata
? 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. I think is a relevant architecture because it defines a new paradigm on EHR development, and that's relevant for the future of EHR development developers. But, is this relevant in terms of adopton today? I rather say no. To say that this is a good idea, you need to have some insight of the standard, and that's a tough job. I could say to you why I think this is a good idea, maybe we can doit by private email. What I have to say is when I present the idea to my students, they see the problems with the current software engineering process and the benefits of the process proposed by openEHR. 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 Guilty as charged, but we are moving forward and working hard to reach wide adoption. Then we had 36 people in our spanish-speakers openEHR group, now we have 80 professionals and students (and growing). And right now I'm planning the second edition of the openEHR course in spanish: http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.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/ Hope that helps :D -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120217/b1ff468e/attachment.html
