Hello all,
Currently using 2.6.5, which has it’s fair share of problems, and would like to upgrade to 2.8.1. I did an install, and duplicated the DB for 2.6.5, so I would have something to work from, then did the updates to the 2.8.1 with the different sql files in /sql/, which worked ok… Now starts the problems
Most things seem to work very well. You guys have done a good job addressing several main concerns that I have with openemr. But, the big bugaboo now is the Report ability of the patient records. Using the DB I have now, when I go to the reports, there are 2 wierdities.
1) (the biggest) The encounters are _all_ screwed up. I get multiple encounters displayed for each encounter… this seems to be mostly cosmetic, but for example in one chart, I get 91 encounters for 4/11/2006… thats a little onerous. And, it will just make the gum chewers in my office *insane* when they try to use it. I can see no reason for this to happen. If anyone else has seen this, I would sure appreciate the help…
2) the immunizations appear in the Allergies secion. This seems to be because the patient_report.php file queries the ‘lists’ table, and then separates the findings between [allergy, problem, medical_problem, medication, surgery,] but doesn’t include a section for ‘immunization’, and my lists table includes immunizations… I think I can exclude these by modifying patient_report.php to exclude them, but will make upgrade ugly… Or I can just “expire” them when they come up. they still seem to show up in the Immunizations page, as it uses the immunizations table. I guess I could just drop all entries from the lists database of type immunization, but… well, you know…
Any help would be greatly appreciated. Thanks.
PS: has anyone thought of how to solve the sessions problem? Like passing the pid with the session info? Or something?
Re the duplicated encounters, it would be important to know if they are duplicated in the database. If so, then I expect this would also have been the case prior to conversion. It’s not a problem I have seen before; someone needs to investigate the details.
Re immunizations - at some point they were moved from the lists table to their own table. There should be a conversion program somewhere – anyone know about this?
1) No duplicate encounters in the database. I will look at this further, going to do a query with the query string and see what comes out. Maybe it is just a syntax problem, though if that is the case, I am surprised no-one else has thought of it.
2) Session problem: Where opening a new window is death on openemr. You have a nice write up on your site about it. Would be nice to keep the patient and encoutner details in the session data, so you could open a new window to look at an old encoutner, and address all the pertinent stuff without having to worry about saving data to the wrong encounter, or even worse, the wrong patient.
For most people, I think this would not be aproblem, as most people don’t have more than one window open at any given time… I on the otherhand have 4 desktops, with currently 5 Firefox windows, each with at least 3 tabs open.
I realize this is a problem with a large fix. Just wondering if anyone was tackling it.
Just pulled the query as written in the patient_file/report/patient_report.php, and it pulls the result query with many, many duplicates…
I did figure out the problem though. the query as written is not isolating the hits to the form_encounter table to just our pid… so every duplicate encoutner was causing a duplicate hit to the forms table…
so, change
$res = sqlStatement("SELECT forms.encounter, forms.form_id, forms.form_name, " .
"forms.formdir, forms.date AS fdate, form_encounter.date " .
"FROM forms, form_encounter WHERE " .
"forms.pid = ‘$pid’ AND form_encounter.encounter = forms.encounter " .
“ORDER BY form_encounter.date DESC, fdate ASC”);
==================================
To:
$res = sqlStatement("SELECT forms.encounter, forms.form_id, forms.form_name, " .
"forms.formdir, forms.date AS fdate, form_encounter.date " .
"FROM forms, form_encounter WHERE " .
"forms.pid = ‘$pid’ AND form_encounter.pid = ‘$pid’ AND form_encounter.encounter = forms.encounter " .
“ORDER BY form_encounter.date DESC, fdate ASC”);
the returned report seems to poop on iteslf as far as the billable codes being reported also… Again the table query to billing is not being limited to the current pt’s pid…
so, replace:
============
$bres = sqlStatement("SELECT date, code, code_text FROM billing WHERE " .
"encounter = ‘$form_encounter’ AND activity = 1 AND " .
"(code_type = ‘CPT4’ OR code_type = ‘OPCS’) " .
“ORDER BY date”);
==============
with:
$bres = sqlStatement("SELECT date, code, code_text FROM billing WHERE " .
"pid = $pid AND encounter = ‘$form_encounter’ AND activity = 1 AND " .
"(code_type = ‘CPT4’ OR code_type = ‘OPCS’) " .
“ORDER BY date”);
Thanks Michael, I have applied these fixes to CVS. You may find yet more similar cases. It’s a pleasure to have users like yourself who can track these down.
I believe that more recent versions of OpenEMR do not create duplicate encounter numbers, which is probably why others have not been seeing this problem.
Hey Rod,
Are most people using the CVS version? I thought 2.8.1 was the most recent stable. With my user base, and being a physician and the computer support, I really don’t want to buy more problems than I need…
Oh, glad to help wherever I can. :) I am looking at doing some tweeking to the authorizations stuff, so that our nurse practitioner’s stuff can be authed by one of the providers, but I think this will be a bigger fix… We’ll see. As time allows.
I usually install from CVS because my clients generally like the latest features, I know how to fix any problems, and also they usually want some customizations and it’s easier to work with the code from CVS for that.
However most folks are better off with the current stable release.
“so that our nurse practitioner’s stuff can be authed by one of the providers”
One could leave them as "Nonauthorized" and they will pop on the authorized preactitioners list.
Unfortunately this will have the side effect of removing them from the calender as well.
I t would be nice to be able to add certain nonauthorized users to the calender. IE office - practice managers need to be able to schedule appointments (performance reviews, vendors etc.)
There is no conversion tool from the old immunizations table. I just decided there wasn’t enough data there to worry about and started using the new table.
One could write a script to read the comments section of the old table and classify each immunization based on whether certain text patterns are found. This could at least import some of the imunizations into the new table.
