I believe so. We are still testing but the upgrade went somewhat better than expected for being introduced on a Monday morning. We will obviously need to do training on all the new features that were introduced.
Most of the annoyances have to do with pieces that were "upgraded".
On the "Past Encounters and Documents":
1) ALL of the result query documents have to load before you can proceed. We have getting a sizable database and it takes awhile for the query to run. The query has to look back at five years x 150K encounters and some times returns 70-80 encounters if the patient has been coming to the office for
awhile. This slow down means waiting an extra twenty seconds before the practitioner/viewer can proceed. This action occurs hundreds of times per day for my entire staff. This wastes a lot of time.
2) What we need is the practitioner who saw the patient. The query result previously returned all the users who had entered a form. This was useful. Now it only shows the assistant who did the "Encounter" and not the practitioner who saw the patient.
3) At the end of this very long query where 60-70 office visits are returned, the results of ALL the office visits start showing up. This is nice but we really don’t need all of the last five years visits listed here. This helps slow this query a lot. Usually we need only the the last visit, waiting for five years of progress notes to load is a real drag on interest, usability, and performance (for the practitioner). Also, after you get this really long, “war and Peace” version, there are NO DATES at all on any of the visits.
4) We really miss the "Comprehensive Patient Report" option. When we really do want the last five years of office visits this was a great feature. This made for very rapid full text searches of the patients medical visits. This was very useful to look up specific drugs for when they got stopped and why.
"Past Encounters and Documents" with a "Comprehensive Patient Report" was much more efficient before "the improvement".
Having the "Patient Notes and Authorizations" screen return all the query result is a useful feature since the goal is to keep this list as short as possible. This query is quick even with a large database.
Queries that take too long should be looked at closely to see if indexes are being used properly. It may be that a new index should be defined.
Also I have seen (and fixed) one or two cases where something was looked up by encounter ID, and the pid, while known, was not included in the WHERE clause; this was a mistake because the relevant index was pid/encounter.
That’s a very involved page. Several queries grabbing documents, encounters, notes, and information in notes. Agree with Rod that first thing to do is ensure the queries (and indexes/keys) are efficient. A quick perusal of the queries doesn’t show anything obvious, but I’d recommend trying the mysql EXPLAIN command on the queries in mysql commandline (here’s an awesome walk through that I used to optimize the translation tables): http://hackmysql.com/case4
There’s also possibly simply a html rendering issues. Kind of wonder what happens if you simply comment out the tooltip stuff that places the entire note in the hovering stuff.
This page could also be optimized with filters (dates, providers, type notes, type docs, etc.), which would be very useful and make the rendering more efficient. Also could be paginated.
I’d definitely put this in the ‘feature requests’ in the tracker to remind a developer (or yourself) to start figuring out how to make this page work more efficiently.
I have been wanting to upgrade but haven’t been comfortable with the process. Initially, I had a fresh install of OpenEMR 2.9.0. I am using this version but want to move to 4.0 eventually when it is finally released. Can anyone direct me as to how to do this upgrade? I am thinking that I may have to move to 3.0.1 first, then 3.2.0 then 4.0. Am I right so far?
Upgrade can only be done consecutively (3.0.1, 3.2.0 & then 4.0).
I recently upgraded to 4.0 from version 3.0.1. I just unpacked the 4.0 directory, copied relevant files, and then ran SQL and ACL upgrade, and all was good. I did not have to move from 3.2 and then to 4.0. The sql_upgrade.php and acl_upgrade.php took care of everything very nicely.
Direct upgrades from as far back as 2.6.0 are supposed to work and there should be no need for intermediate upgrades. I don’t know how well that’s been tested, but I’d certainly try it first. If you are currently using sql-ledger then you’ll also need to run the conversion script for that.
The only non-trivial step will be breaking the 3.0 barrier. This is because you need to deal with php-gacl (embedded post 3.0) and with sql-ledger conversion. So, the main two questions are:
1) Are you using sql-ledger?
2) Are you using php-gacl?
For an example upgrade to post-3.0 that was running php-gacl and sql-ledger check out the upgrade steps for the OpenEMR Appliance here: http://bradymd.com/appliance/update3/