Dear All, I received this email from Rick Peters before the official AAFP announcement, and have been meaning to forward it to the list ever since, but it was buried in my inbox and other wheels kept squeaking. Hopefully this will clarify some of your questions.
My own questions are now related to, "Will this actually be configured to permit publicly collaborative software development?" As experienced folks know, there is the Mozilla experience of dumping a lot of code out into the open and hoping it will get traction, and then there are the gradualists like Linux and Apache who had the advantage of being able to start small. This is clearly starting out with a functional system, so to ensure practical public development, some structure needs to be in place that we (or at least I) haven't heard about. It is one thing to have good intentions; it is quite another to understand how to structure the code, its repository, leadership structure, discussion groups, bug reporting, features requests, and so on; in order to ensure effective open development. The proof of the pudding, as they say, is in the eating. A great challenge. Enough intro; here's Rick's essay. --------------------------------- I thought it best to ...clarify the genesis, intent, and work to date regarding the open source EHR effort we are putting together under the auspices of the American Academy of Family Physicians and other leading specialty societies in the United States. I am working closely with David Kibbe, MD, Doug Henley, MD, John Swanson, Rosi Sweeney, Todd Dicus, and Tom Robinett of the AAFP to put this project together. We have been very quiet about this project as we have put the pieces together, but think it is important to give you an overview of our efforts so we can put them in perspective to the detailed information and sage advice you have all given us. ...Let me first and foremost assure you that we are not reinventing the wheel here. We are basing our efforts on extensive experience (and frustrations) in the software world, both public domain and commercial, and in the EHR and health care standards arena. I am sure that I know some of you, and vice versa from the time I have spent over the last ten plus years at HL-7, ASTM, ANSI-HISB, WEDI, AMIA, CORBAmed, X12, CEN, and in the first year of ISO TC-215. If you need any background on where I come from regarding standards please feel free to talk with Mary Kratz who has known me for many of my years in the standards world and with whom I share the same hopes and frustrations with standards. I have been at the bleeding-edge of the commercial EHR market for 15 years, and was involved in my first project architecting and building our first EHR in 1984 - an auspicious year not because Orwell's predictions weren't quite true yet, but because I naively thought that this EHR thing was a shoe-in for rapid success. I was sure we would all be using them to practice medicine by the time I finished my residency. Those are painful memories, as I need not remind any of you. The AAFP open-source EHR effort grows out of extensive U.S. and international experience, and is an attempt to overcome the barriers to EHR adoption that seem to crop up everywhere with painful tenacity. One of the key issues in the U.S. is that physicians are most often blamed for the slow adoption of EHRs, which is a patent falsehood, but widely (wildly?) pervasive. The AAFP open source effort is driven by physicians - practicing physicians, and we are in the process of recruiting other leading specialty and sub-specialty societies to join the effort. Practicing physicians have been left out of the process in the U.S., not by any design, but primarily because they practice medicine for a living and assumed that commercial and academic EHR efforts would lead to working solutions. This has sadly not been the case, and U.S. physicians are tired of waiting, and tired of systems designed to 'change' them and their practice of medicine to meet someone's EHR 'model.' We have well established and widely familiar practice patterns and standardized documentation in the U.S. - in other words we have standardized charting, standardized clinical content, and standardized clinical approaches to the practice of medicine whether inpatient of outpatient. Any of us can go from practice to practice or facility to facility in the U.S. with impunity. We have never had an EHR effort that understands this, with virtually every one of them trying to 'standardize' our world in a 'new' way. Practicing physicians in the U.S. have attempted to bring this to the standards organizations, but it is frustrating as they are always told, 'but, no this is far more complex than you think, and as a physician you would never understand this. Trust us and we will take care of it for you.' Physicians, as you well know, are easily offended by this, no matter its veracity, and turn right around and go back to practicing medicine. The trouble is we need them to drive the EHR., not the other way around. The AAFP open source project is designed to do exactly that. ...we are aware of the work to date, highly respectful of it, and willing to work to make all systems interoperable. At the same time, we are technologists and rational to the core. We have a deep understanding of object oriented technology and standards (CORBA, SmallTalk, NextStep, Java, ObjectiveC, C++, and object databases), terminology semantics and syntax (SNOMED, READ, Medcin, GALEN, Medical Language Institute, Arden Syntax, and the host of others), messaging standards (ASTM, HL-7, X12, NCPDP, and the work within CEN/TC 251), and document architectures (SGML, XML, Hl-7's CDA). We have followed the OpenEHR archetype work and CEN's ENV13606 and are willing to be strongly supportive of those efforts. So we understand what is going on, but we are also fiercely practical and need to work towards a real working solution. So... Our approach is complimentary, there is no question of that, but we are taking things a few steps further. What we are doing is taking a very sophisticated, standards-compliant, commercial product which we are obtaining from a U.S. vendor and turning that into an open-source EHR. The technology is state-of-the-art within the context of the larger computer IT industry, not within the somewhat artificial constraints of the health care IT industry. The product we have an agreement to use has a significant number of man years of development behind it and has had millions of dollars invested in it. We are doing the exact opposite of starting over from scratch. The system will be licensed to a new independent 501 C-3 non-profit foundation, which will use professional, commercial development teams to build initial extensions to the system and set-up an open source development infrastructure and process. Input will be coordinated between the participating U.S. specialty societies, with additional participation from leading U.S. IT and systems vendors and academic medical centers. The initial target is community physicians across the participating specialties, but there is very strong interest among academic medical centers and larger integrated health care organizations. The system is designed and implemented to service the disparate needs of individual physicians as well as large integrated health systems. The system and architecture are defined as follows: - the core of the system is a community-based, massively scalable, highly secure, distributed data and middleware architecture that can have any number and variety of end-user interfaces and workflow models attached to it (the AAFP sponsored effort will come out with multiple end-user and workflow options) - all aspects of the system are platform, operating system (Windows, OS-X, UNIX, Linux, and mainframe), and database management system (Oracle, DB2, Sybase, IBM/Informix, MS SQL) independent. ...we do run on Windows - we have to support it as well as a .net approach as our U.S. institutions demand it in many instances. We also run on Linux, and can run a pure Java system, or a browser-based HTML, DHTML, or XML solution) - the entire system uses XML as its document and object description language, and can map to any other system or legacy data through discrete XML/XSL translation - the system terminology, syntax, and semantics are based on structured, object-based XML with discretely tagged mapping (this seamlessly maps to the HL-7 CDA, for example, but is far more detailed and extremely efficient) - the entire system can run n-tier with client-server speed over an ASP infrastructure using simple dial-up (56K or less), or can be configured standalone to run on a single PC or within a LAN, WAN, or VPN - the system exceeds both U.S. and EU security, confidentiality, and privacy regulations and can run securely over the open Internet through a standard ASP (the system uses standard, off-the-shelf security technologies) The system is compliant with standards, but does not unnecessarily internalize them. This is a regret, but a necessity if you are building real-world, low-cost, and performance-based systems. The system, for example can be configured to be CORBA-compliant and use CORBA services (PID, for example), but it is not built using CORBA. The commercial world does not use CORBA for internal architectures for a very rational reason - it is wonderful but it is painfully inefficient with poor performance and very expensive to implement and run. The same holds true for the HL-7 CDA. The AAFP system's XML can map seamlessly to the CDA, but it's XML uses discrete tagged content rather than tag attributes for content. This is done because the system is designed to use open-source standardized XML parsers and tools, which are optimized for tag parsing, not tag attribute parsing. These are just a few examples, but they stem from long and painful industry experience, but also leverage the amazing technologies available in the general computer IT industry, particularly the open-source aspects of that industry. David Kibbe and I would very much like to work with all of you on making the open-source EHR a revolution and a success. We are hopeful and carefully jaded regarding EHRs, a feeling that I am sure you probably share. Our effort is currently U.S. based and will be strongly cross-specialty (specifically not primary care only). We would very much like to work with all of the efforts you have all brought to the table, and would like to keep our solution compliant with all of the work done to date in this arena. We are taking an aggressive and progressive technological approach solely because we have to. We have to get something that works, is highly configurable, and extremely low-cost to physicians right now, not one, two, three, or four years down the road. We will do everything to make this project compliant with, complimentary too, and supportive of all of your efforts and the others you have enumerated. We would like to work directly with all of you, not just beside you. To that end David and I would be very interested in taking this opportunity to open up an international dialogue and cooperative coordination of efforts. Sincerely, Rick Richard M. Peters, Jr., MD [EMAIL PROTECTED]
