Help! Problem with School/Work Note form

penguin8r wrote on Friday, August 14, 2009:

Anyone else have a problem using the School/Work note form?
It creates the notes just fine, but later on if you try to run a report for a patient who has previously had a School/Work note created for them, you get this error spammed across the top of your report:


Warning: include_once(/var/www/openemr/interface/forms/has been under my care from ___ ___/___ ___/___ ___ to ___ ___/___ ___/___ ___ and is able to return to work on ___ ___/___ ___/___ ___. Nature of illness or injury: _____________________________________________________ ____restrictions ____light work PE ____ may take ____ may not take Comments: ________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Dr. _____________________________________________________________/report.php) [function.include-once]: failed to open stream: No such file or directory in /var/www/openemr/interface/patient_file/report/custom_report.php on line 103

Warning: include_once() [function.include]: Failed opening ‘/var/www/openemr/interface/forms/has been under my care from ___ ___/___ ___/___ ___ to ___ ___/___ ___/___ ___ and is able to return to work on ___ ___/___ ___/___ ___. Nature of illness or injury: _____________________________________________________ ____restrictions ____light work PE ____ may take ____ may not take Comments: ________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Dr. _____________________________________________________________/report.php’ for inclusion (include_path=’.:/usr/share/php:/usr/share/pear’) in /var/www/openemr/interface/patient_file/report/custom_report.php on line 103

So, I went back & recopied custom_report.php from the original OpenEMR source, still the same error, started sampling random patients, & discoverd that the error does indeed only happen if the patient has a Work/School note in their encounter history.

I’ve been trying to trace the error back to it’s source thru the code, but I just can’t find anything that seems to be wrong.

Now, here’s the really scary part, whatever that note form is doing, it breaks the patient record so that you can no longer view any of the patient’s encounters.  So basically, using the Work/School note form renders the patient’s record useless.

Anyone else seen this happen or have any ideas for how to fix/repair?

penguin8r wrote on Friday, August 14, 2009:

Update:  It seems this is caused by a bizarre interaction with something in CAMOS, still investigating where the glitch could be.

jesran wrote on Friday, August 14, 2009:

This looks very odd to me

(include_path=’.:/usr/share/php:/usr/share/pear’)

because:
1) ":" is a reserved character in UNIX filenames

2) /usr/share is there twice

I hope that helps get to source of the problem…

Gerald Neale, RN

drbowen wrote on Friday, August 14, 2009:

The work/note school actually cam out of my office.  The person responsible has been gone for about 5 years.   He won’t be able to help.

I don’t use CAMOS and the problem doesn’t appear to happen in our 3.0.1 when not using CAMOS.

As far as I know OpenEMR does not use PEAR at all.

(include_path=’.:/usr/share/php:/usr/share/pear’)

What happens if this line in commented out?

Sam Bowen, MD

penguin8r wrote on Friday, August 14, 2009:

I didn’t think OpenEMR had any need for pear either, I’m still trying to figure out where that include_path is actually coming from so I can see if that’s part of the problem.
I’ve done some more looking thru patients on the system, this isn’t a problem with all the patients that have Work/School notes as part of their record, it’s only a few of them, probably 10% or less in fact.
It all seems to come back to certain CAMOS forms in their records, but the inaccessible encounters is what I’m really worried about.  I can live with bugs in the Patient Report output, but not having access to the patients’ records is a major problem.

cfapress wrote on Monday, August 17, 2009:

The most interesting part of the PHP error is the first:
"
Warning: include_once(/var/www/openemr/interface/forms/has been under my care from ___ ___/___ ___/___ ___ to ___ ___/___ ___/___ ___ and is able to return to work on ___ ___/___ ___/___ ___. Nature of illness or injury: _____________________________________________________ ____restrictions ____light work PE ____ may take ____ may not take Comments: ________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Dr. _____________________________________________________________/report.php)
"

It seems that PHP is looking for a file with a very unusual name. I suggest looking at the ‘registry’ table to see what forms have been added to your system. Look at their file paths.

I don’t see how CAMOS would meddle with the school note stuff.

Jason

penguin8r wrote on Monday, August 17, 2009:

I don’t see how CAMOS would meddle with other forms data either.  I have seen a couple of interesting MySQL errors pop up in these patients’ reports associated with CAMOS forms that are part of their record, & that’s what made me wonder.  The staff at this office have been making heavy use of CAMOS (they use it more than anyone else I know of that’s using OpenEMR) , & creating a lot of their own forms with it, it just made me wonder if in typical end-user fashion they found a way to break something or cause some sort of bizarre form interaction that no one could have anticipated.  If/when I find the solution I’ll post here in case this should happen to anyone else.

penguin8r wrote on Monday, August 17, 2009:

Hmm, curiouser & curiouser, when you open an affected patient record, & click on Encounters, the clinical display shows up with this:

==

8-09-08         16 YO WM HERE TODAY WITH C/O SORE THROAT, RUNNY NOSE, AND CHEST CONGESTION X1 WEEK
Vitals
Work/School Note
SOAP
    **************                         2008-09-08
2008-07-29         15 YO WM HERE TODAY FOR SCHOOL SPORTS PHYSICAL. OU-20/20 OS-20/15 OD-20/15
Vitals
Well Child Visit
    *************                         2008-07-29
2008-07-29         Document: ********** IMMUNIZATION.PDF (Categories)     
2008-04-30         15 Y/O WF HERE TODAY C/O A COUGH, SORE THROAT. SAYS HE WAS RUNNING A FEVER THIS A.M.
Vitals
SOAP
    *******                         2008-04-30
2008-04-21         15 YO WM HERE TODAY WITH C/O RUNNY NOSE AND COUGH SINCE FRI.
Vitals

ERROR: query failed: select * from form_has been under my care from ___ ___/___ ___/___ ___ to ___ ___/___ ___/___ ___ and is able to return on ___ ___/___ ___/___ ___. Nature or illness or injury: _____restrictions _____ light work PE ____may take ______ may not take Comments: Dr. where id = 1

Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘under my care from ___ ___/___ ___/___ ___ to ___ ___/___ ___/___ ___ and is abl’ at line 1

==

The asterisks are where I edited out names, but it seems that somehow some information from the database tables for the encounters has gotten mixed up in the MySQL db or something.  Unless it’s just a random accident resulting from botched data entry by the end users?
So strange, I’ve never seen anything remotely like this in nearly 4 years of working with OpenEMR.

bradymiller wrote on Monday, August 17, 2009:

hey,

This error coming from this line in the openemr/interface/patient_file/history/encounters.php file:
$frow = sqlQuery(“select * from form_” . $enc[‘formdir’] . " where id = " . $enc[‘form_id’]);

Somehow it seems that in the ‘forms’ table, the ‘formdir’ column was inserted with the data that should be going to the ‘form_note’ table ‘message’ column.

To do this, it seems the bug must be somewhere in the openemr/interface/forms/note/save.php file . Hopefully not a global problem with the formUpdate function in library/api.inc file. Or perhaps CAMOS forms associated with same encounter does something to throw it off.

-brady

bradymiller wrote on Monday, August 17, 2009:

Disregard the CAMOS suggestion, since no CAMOS form in above encounter.

bradymiller wrote on Monday, August 17, 2009:

hey,

Some more digging in openemr/interface/forms/note/save.php file . The ‘forms’ table entry for the form is initially created with addForm() function from openemr/library/forms.inc, and the label “note” for ‘formdir’ is hard-coded in the fucntion call, so no clue how your got the message inserted here. Have you changed this line at all; otherwise I can’t see how else the ‘formdir’ column in the ‘forms’ table can be modified after it’s created.

-brady

penguin8r wrote on Tuesday, August 18, 2009:

Brady,
   thanks a million for looking at this, I haven’t modified any of the code in there, so unless a file got corrupted somehow it should all be as it was when extracted from the tarball.  Are there files/directories that I should try re-copying from source to see if it makes any difference in this error?  I’m still pulling my hair out trying to figure out if this is a persistent system problem, corrupt data, or some kind of obscure data-entry error.

penguin8r wrote on Tuesday, August 18, 2009:

Not sure if this makes any difference, but the encounter display error happens only in Clinical View, not in Billing View.  I’ve found other patients with this display error, & there is no CAMOS associated with the encounter causing the display error, so I’m almost 100% certain it’s not a CAMOS side effect now.

penguin8r wrote on Tuesday, August 18, 2009:

To make things just a little more mysterious, I cannot figure out where this:

has been under my care from ___ ___/___ ___/___ ___ to ___ ___/___ ___/___ ___ and is able to return on ___ ___/___ ___/___ ___. Nature or illness or injury: _____restrictions _____ light work PE ____may take ______ may not take Comments:

text is coming from.  I have searched thru the entire openemr directory, can’t find this text string anywhere.  Just bizarre, I have to wonder if the office staff cut & pasted something & managed to insert something into the db that never should have been there?

drbowen wrote on Wednesday, August 19, 2009:

This text is not in the work note / school note that is on my system.  Maybe somebody customized the form?

Try toggling on / off magic quotes.

Sam Bowen, MD

bradymiller wrote on Wednesday, August 19, 2009:

This text is not part of openemr, likely a template your group is pasting in I’m guessing.

It only happens in clinical view, because this is where the following sql query is run:
$frow = sqlQuery(“select * from form_” . $enc[‘formdir’] . " where id = " . $enc[‘form_id’]);

$enc[‘formdir’] pulls data from the ‘formdir’ column in the ‘forms’ table which somehow got populated with your above text, instead of the word ‘note’. I can’t figure out out this was done, since the save.php script for this form hard-codes the word ‘note’ when it calls the addForm() function. Check your mysql database and see if this is the case. Maybe your users have access to the database and somehow inserted it???

If this is indeed the case, then should be straghtforward to fix database by issuing a mysql command to change the ‘formdir’ = ‘note’ in table ‘forms’ where ‘form_name’ = ‘Work/School Note’ . I’m assuming that the form contents (found in ‘message’ column of form_note table) are ok.

-brady

penguin8r wrote on Thursday, August 20, 2009:

OK guys, thanks for all the help, I’m going to write this one off as some kind of user data entry error, it’s like there was a phantom form saved on some of these patients that was causing the problem.  By deleting the form the error went away.  The funny part is that before & after deleting the form, I checked the database, nothing changed in the db.  Not sure how non-existent data can cause an error, but there’s no other explanation.  It might have been a bug from the last system upgrade too, but I’m not going to spend any more time trying to figure it out unless it becomes a real problem somehow.

Brady, you were on exactly the right track, that’s where I ended up looking too, & the totally inexplicable part of all this was that there wasn’t any text stored in the ‘message’ field in the note table.

So the data didn’t exist, but somehow it caused an error, & it was capable of being deleted, after which the error no longer occurs, even though it didn’t exist in the first place according to the DB.  My brain is now in a pretzel shape & I have a headache.

Thanks again for all the advice, you guys rock.