Sorry if this is the wrong forum for posting this message. It seemed at little bit more obscure than the posts in the other forums.
I had thought that I might have caused my own problems with some custom forms that I use. I’ve been able to reproduce the problem on a new copy of 5.0.1 freshly installed on an equally new virtual machine running Ubuntu 18.04 Server that has never seen either my MySQL data or my openemr files, so now I’m reasonably confident that the problem has arisen with the release of the 5.0.1 version (and the preceding development version). Also, I can duplicate the problem while logged into the OpenEMR demo machine so now I’m even more confident that this is a program bug rather than something I’ve caused myself. It was not present with 5.0.0 (or any of its earlier patches). Let me explain.
First problem: Unlike versions up to and including 5.0.0, more than one Miscellaneous Billing Options form cannot be completed per patient per visit. As a practical measure this may not be a problem as it is unlikely that different such forms would be needed for the same visit but it is nevertheless a change in behavior and it is not consistent with how the other visit-oriented forms work. This may or may not have something to do with the second problem, which is more important.
Second problem: Misc Billing Option forms don’t consistently show up in the encounter summary page. For example, if a “regular” Review of Systems form is completed immediately prior to completing a Misc Billing Option form then the results of the MBO form show up in the encounter summary page as they should. If a Review of Systems Checks form is completed prior to the MBO form, however, then the MBO form doesn’t show up in the encounter page. The data is saved to form_misc_billing_options as evidenced by the fact that it appears if one tries to open up another MBO form for the same encounter however it appears to be saved in the wrong place and to over-write a previous patient’s data (decidedly not good).
First, a recommendation. Then I’ll tackle what I’ve done to illustrate the problem.
To identify whether or not you have a problem:
Run from the mysql prompt: mysql> SELECT fmbo.id, fmbo.pid, pd.fname, pd.lname FROM form_misc_billing_options fmbo INNER JOIN patient_data pd ON pd.pid = fmbo.pid WHERE fmbo.id < [max_fmbo_id_#_on_last_backup_before_you_upgraded] AND fmbo.date > ‘YYYY-MM-DD’; (where YYYY-MM-DD is the date-time that you upgraded) - this should identify the form_misc_billing_options id’s of the fmbo records that have overwritten your previous data. This should work on your real data as it has been entered spread out over time. It probably won’t work on the following test situation without modification however. If you haven’t previously backed up your data you’ll have nothing to go back to and it won’t help and you’ll be out of luck.
So far I’ve been able to figure out how to reproduce the problem but I can’t figure out the deficient code and therefore prevent it from happening again. Once can either create a test server (I use a virtual machine for these experiments) or at least gain a sense of the problem on the OpenEMR demo servers. Unfortunately you can’t directly access the MySQL data on the demo servers so it’s harder to tell what’s going on there. I prefer my virtual server in that I can directly access the data from the MySQL command line and thereby see how and when the records are created and which ones are in error.
Create example/test situation: Clean installation of 5.0.1 on Ubuntu 18.04 server running PHP v7.2, MySQL 5.7.22. Log in and set up some arbitrary patients (the alphabetical Doe family - Albert, Barbara, Charlie, Danny, Eloise, Frank and so forth) containing the bare minimum required information (first and last name, birthdate and gender) to create a patient entity. Give them all appointments and log them in as having arrived (this makes things easier if you have to run multiple tests). Dump the database so that it can be recreated easily.
Now try a few examples:
First open up Albert’s visit. Create a Review of Systems (ROS) entry and save it. Then create a Mixed Billing Options (MBO) entry and save it. If you try to create an additional MBO entry the form will open pre-populated with the previous data and you will merely be updating the previous entry rather than creating a new one but at least the existence of both forms shows up appropriately in the Encounter Summary page.
Next open Barbara’s visit. Create and save a ROS entry for good measure, then create and save a ROSC (Review of Systems Checks) entry (the forms should be present on a default installation). So far everything should show up in the Encounter Summary appropriately. Finally, as your staff might do when getting ready to bill the next day, create and save a MBO entry. Examine the Encounter Summary page and you will see that the MBO entry is not visibly displayed there. However, if you attempt to create and save another MBO form by clicking on the Misc Billing Options link a tab will open with your previous data already on it, so you know it must have been saved somewhere. Most importantly, if you now open MySQL directly and inspect the contents of the form_misc_billing_options table you will see that the original entry for Albert has now been overwritten by Barbara’s new data. YOUR PREVIOUS DATA IS GONE, which can be confirmed by returning to Albert’s visit where you will notice that the previous MBO information is no longer present (NOT GOOD).
Try a few more examples for good measure. What seems to be happening is that if Misc Billing Options are created and saved immediately after creating and saving certain other forms (Review of Systems Checks, Observation(?), etc.) then the MBO data is treated as an update rather than a new entry and is overwritten into the form_misc_billing_options.id record that matches the id number of the form that was entered previously (or something like that).
So far I’ve been able to patch my data by manually working within the MySQL database. I re-enter good data into the overwritten fmbo records and append new data onto the end of the fmbo table. I also have to set up appropriate records in the forms table linking the billing options to the particular visit. Obviously, this is somewhat labor intensive and prone to errors if not done carefully. More importantly, if one wasn’t aware of this one would be blithely losing data as they were entering it. My sense is that the problem lies somewhere within the save.php file in openemr/interface/forms/misc_billing_options. I’ve been unable to locate where, however, and it really should be fixed by someone more talented than I.
Any ideas? I’d appreciate even being pointed in the right direction.