Insert New Patient Broken!

anonymous wrote on Monday, January 09, 2012:

I have just discovered that following an upgrade from 4.0.0 (2) to 4.1.0 (5), the add new patient function is somewhat broken. After entering patient data and selecting “Create New Patient”, the following mysql error is displayed:

ERROR: insert failed: INSERT INTO insurance_data SET type = ‘primary’, provider = ‘’, policy_number = ‘’, group_number = ‘’, plan_name = ‘’, subscriber_lname = ‘’, subscriber_mname = ‘’, subscriber_fname = ‘’, subscriber_relationship = ‘’, subscriber_ss = ‘’, subscriber_DOB = ‘0000-00-00’, subscriber_street = ‘’, subscriber_postal_code = ‘’, subscriber_city = ‘’, subscriber_state = ‘FL’, subscriber_country = ‘’, subscriber_phone = ‘’, subscriber_employer = ‘’, subscriber_employer_city = ‘’, subscriber_employer_street = ‘’, subscriber_employer_postal_code = ‘’, subscriber_employer_state = ‘FL’, subscriber_employer_country = ‘’, copay = ‘’, subscriber_sex = ‘’, pid = ‘340’, date = ‘0000-00-00’, accept_assignment = ‘TRUE’, policy_type = ‘’

It seems that the data is being submitted to the database and the patient chart created. I just can’t figure out what’s going on here. Any help would be appreciated!

tmccormi wrote on Monday, January 09, 2012:

Did you run the patch upgrade for SQL after you installed the patch?
see: http://www.open-emr.org/wiki/index.php/OpenEMR_Patches
-Tony

anonymous wrote on Monday, January 09, 2012:

Tony,

I did run the SQL patch. In fact, my first attempt at upgrading was a failure due to the backup command not working. So on my second attempt, I upgraded sequentially from 4.0.0 (2) to 4.1.0 to 4.1.0 (3) to 4.1.0 (5). I ran the SQL patch twice, once for each patch.

I am currently installed on Ubuntu 10.04 LTS. I do recall a previous database error that was a bit more detailed. When attempting to save changes on a feesheet, I received an error stating the “notecodes” field was missing from the billing table. My fix was to manually add the field myself through phpMyAdmin. All was well, until about a week later when I discovered this.

I’m not sure where I can find a more detailed log of the error. The logs in /var/log/mysql are blank. Is there another file available which would help shed a bit more light?

-Frankie

yehster wrote on Monday, January 09, 2012:

Try running the sql statement that fails from mysql on the command line.  That will tell you what is going on.

anonymous wrote on Monday, January 09, 2012:

yehster,

Thank you for the advice. I did as suggested and received the following output:

ERROR 1054 (42S22): Unknown column ‘policy_type’ in ‘field list’

Upon searching the “Search or Add Patient” screen, I do not see a field labeled “policy type”. Obviously the field is not in the insurance_data table either. Perhaps I should just try to add the field to the table and see what happens? Seems like the same issue I had with the “notecodes” field.

Can I assume something went wrong with the SQL patch? And if so, can I run the patch again without concern of any destructive behavior? I would like to avoid reverting back to before the upgrade, which would cause me to lose a week’s worth of data entry.

anonymous wrote on Monday, January 09, 2012:

Update: I ran the SQL patch on a test server and it added a handful of missing fields, including “policy_type”. I suppose I didn’t run the patch after all. I just want to confirm that running the patch at this point will not be destructive in any way before doing the same to my production server…

yehster wrote on Monday, January 09, 2012:

Nothing in the patch “explicitly destroys data”, but we can’t really guarantee that it won’t be “destructive in any way.”  That is why you are encouraged to backup before patching. 

There are people who have upgraded without incident, but there are also certainly cases of people whose systems have had problems after upgrading.  The one case I can think of is that someone ran the sql upgrade scripts multiple times which resulted in duplicate data entries that broke their documents tree. 

anonymous wrote on Monday, January 09, 2012:

Do you recommend any particular method of testing after running the script? Perhaps a resource to which I can compare all of my database tables one by one? Or should I just be extra vigilant in the following days?

Thanks for your input, yehster. It is much appreciated.

yehster wrote on Monday, January 09, 2012:

The method of testing I would recommend is hiring professional support instead of doing it yourself. Wink… wink…

anonymous wrote on Monday, January 09, 2012:

I did reach out for some professional help with some unrelated customization just after posting this thread. I will continue to monitor my test server for any hiccups and await the more experienced advice. I have a hard time keeping my brain from going a million miles a minute when things aren’t running optimally, especially at the start of a busy work day!

Thanks again for your input. :slight_smile:

-Frankie

bradymiller wrote on Tuesday, January 10, 2012:

Also,
To save you some time, note the patches include changes from previous patches. So, patch #5 includes all changes from patches #1,#2,#3, and #4. Also, the sql patch files are designed in a way to skip database updates if they already exist (so, running the sql patch file multiple times should have no negative consequences). However, agree with yehster that backing up before an upgrade/patch is important just in case something goes awry.
-brady

anonymous wrote on Tuesday, January 10, 2012:

So, I figured out where I messed up. It looks like I only ran sql_upgrade and skipped over sql_patch. I ran the patch on my production server this morning and everything looks fine so far. Only time will tell…

tmccormi wrote on Wednesday, January 11, 2012:

habitually using the URL https://……/openemr/admin.php when doing upgrades will save you from this issue as it reports the need to run upgrade and provides the link, then it reports the need to run patch upgrade and provides the link.  If all is well the link is ‘Login’

This is a great tool that Rod wrote!

-Tony