I promised yesterday to write more about the AAFP's Open EMR project. Several e-mails this morning have reminded me that I still need to do so. The AAFP board will, I gather, be voting on this today. So we'll see what they decide.
The NAPCI leadership is talking about how this project is problematic because AAFP would be forging ahead with their own project – rather than involving the other allies of NAPCI. NAPCI includes leaders from Internal Medicine, and Pediatrics, as well as folks from AHRQ, STFM, AAFP, and NAPCRG.
A common goal is to enhance the availability of electronic resources to physicians. It is now clear that electronic records in some form can enhance both efficiency and quality.
But poorly implemented technology enhances neither. The very high cost of most electronic medical records system precluded their adoption in most small practices. The complexity of the installation and support is intimidating for both large and small practices, and the return on investment is simply unclear.
I know rather few of the details of the AAFP proposal, and most of what is circulating about the listservs is hearsay. I do know that the proposal is to develop the product as open-source. Open Source can mean many things. So I'm not sure which license is contemplated. Many are saying that there is no way that an open source electronic medical record can "make it." I disagree. An EMR that is open source could be quite successful, so long as the project is well coordinated. Being managed by one organization is hard enough. The trouble with many open source projects is that they are developed by many people with very strong technical skills and very poor user-interface skills. It takes a well-managed project team to focus on functional requirements (what a program does) and the user interface (what the users see to make the program DO what it DOES).
There are many commercial examples of bad UI, so I won't kick a dead horse here. My point is that the management of the project – not the "openness" of the code – is what is likely to determine the success.
The concept of the AAFP project is that the application is developed and provided to physicians at a low or minimal cost — then support is provided for a reasonable fee by other companies. Ideally, there will be many vendors who will compete with each other to provide support and additional functionality (interfaces, custom modules, etc) for a fee.
I do think that it's a model that could work — whether it's the AAFP's project or another. Though it would be a shame to see more than one such project undertaken at the same time.
With NAPCI involved with the AAFP project, I think it's possible that there could be federal support for a project like this — even NLM or SBIR grant funding.
Even if the AAFP board doesn't support this, we could all capture some of the enthusiasm for the effort, and push it forward together. At the very least, David Kibbe deserves kudos for pulling together a clear proposal to the AAFP board. While one may be critical of him for not involving the other specialties (yet), he's moving forward toward a goal that we all agree is a good one.
