drbowen wrote on Sunday, May 04, 2008:
Dear Jeff,
I don’t think you are going to start any flame wars here. As a group we try to be as tolerant and open as possible.
***
Is the OpenEMR developer community at large interested in a PostgreSQL based back end?
***
The short answer is yes.
One of the design principles we as a group are "supposed to be following" is database independence. So the idea of using PostgreSQL as a back-end is part of our stated objectives.
I personally feel that PostgreSQL has a lot of advantages security wise and additional SQL database features in terms of using stored procedures and the ability to roll back transactions. I know that MySQL is developing these features but MySQL is not nearly as sophisticated from the database back end. PostgreSQL has a many years head start on MySQL along these lines.
My concern has been to push for an easier installation of OpenEMR. Having to install and maintain two database back ends is and always will be problematic. There are pros and cons to both databases of course.
MySQL: the fastest FOSS database, relatively easy to install and to maintain. SQL back end is not as robust as more full featured databases. This of course will no affect end users very much but make a big difference to developers. Under our current system it requires the installation and maintenance of two separate databases for all the functionality that OpenEMR is capable of.
PostgreSQL: Older, more mature, greater number of database back end features, May be faster under a load. The tests I have seen on the past indicate the MySQL is faster but only under relatively light server loads. As the the system is loaded and starts hitting more than 30 requests per second PostgreSQL actually starts substantially outperforming MySQL. This will not matter as much for offices with less than 30 total users but as OpenEMR starts growing into larger offices it will become an issue. PostgreSQL is some what more difficult to install and is not as easy for the novice to intermediate level admin. The biggest plus is that it immediately solves the two database problem. Using PostgreSQL for everything would overall simplify installation and maintenance of OpenEMR.
***
I know some of the developers are working on integrating more billing functionality into OpenEMR, but I believe that is aimed more at insurance and patient portion collections (if I’m wrong, please let me know!).
***
The guidance committee (OSMS) several years set out as a basic goal to maintain backwards compatibility with all current users. There are a number of people who are already using OpenEMR coordinated with SQL-Ledger for there billing and general accounting. These is a feature that we intend to continue to support.
There is a large group in the United States who will want tighter integration of OpenEMR with the accounts receivables and practice management. I (as in me personally) would like OpenEMR to have the accounts receivables and practice management to be done entirely from within OpenEMR.
Most accountants have their own pet general accounting program. Many of those general accounting programs in use are not opwn source and go by the names of QuickBooks, PeachTree among others. As a future goal we would like to see OpenEMR have the ability to export financial data to all of the major general accounting program to include SQL-Ledger, QuickBooks, and PeachTree.
Part of the "weak link" between OpenEMR is "FreeB". FreeB is the first FOSS application capable of
generating electronic claims and prints paper claims on a HCFA 1500 in the United States. The creator of FreeB, Fred Trotter, has given up on further development on FreeB. Currently FreeB is looked at as a stop gap until something better can be put in its place.
When this occurs, the integration of OpenEMR with SQL-Ledger will be faster and tighter. Of course bringing the accounts receivables and practice management inside OpenEMR with make this faster and tighter still. The goal is to do this without breaking the integration with SQL-Ledger. Point-of-sale should be easier after this integration occurs. It will just mean that the functions important to collecting money from insurance companies will not be needed in this type of business.
***
Were OpenEMR to move to PostgreSQL, I would hope that a tighter integration to SQL-Ledger would be possible as building those functions into OpenEMR seem like a fool’s errand.Is this the kind of thing that you could dump the existing database and import it into PostgreSQL and try it out to see where it breaks down?
***
Tighter integration with PostgreSQL will happen. A fool’s errand? No, certainly not.
Dieter Simader, the writer and maintainer of SQL-Ledger, has no interest whatsoever in a medical practice management or medical accounts receivables and these will never be seen in the stock version of SQL-Ledger.
As stated above, there will be plenty of users who like SQL-Ledger and will depend heavily on its functionality. There are of medical practices in the United States that will not use OpenEMR without this integration of OpenEMR, accounts receivables and practice management.
Sincerely,
Sam Bowen, MD
I do not want to spend alot of time learning more about Mysql.