Lately, we have noticed this undesirable behaviour:
A user (a doctor) creates an encounter and tries to enter data in an empty encounter form. Then the user attempts to save this form.
However, the system no longer stores all of the data entered in the form. It only stores a small part of the data entered. This means:
If an encounter form has 10 fields and the user fills out all of them, only data entered in 1 or 2 fields will “stick”. The rest? It’s like it was never entered.
The only workaround this problem is to go to save the form, then edit it and enter the data.
Oddly enough, while it affects all of the forms, it doesn’t affect our demo. So, reproducing this bug is tricky.
To make things even worse, we haven’t found any errors logged in our LAMP and WAMP setups whatsoever. Neither does the browser’s console produce any warnings.
This is a major issue that affects OpenEMR’s reliability very negatively. This bug affects release 4.1.0, and I have reasons to believe that, since others were unable to reproduce it, locate its cause and fix it, it also affects newer versions.
The user creates a new encounter. In the encounter summary, what the user entered does not show up - only a blank encounter.
In the database and the encounter list everything seems to have been stored properly - yet, nothing appears in the encoutner’s form.
When the user clicks on “Edit”, a blank form appears - the previously stored data simply does not appear.
Also, when an LBF form is completed, the following problem appears:
Let’s say the user fills out two fields in it. In the lbf_data table, the forms.form_id in one record is linked correctly, while in the other it is linked incorrectly.
It is clear that something strange is happening with the id’s in the database. What makes this situation even more strange is that this behavior continues, even if we drop the database and import a database that works fine on another server with an identical setup.
Dunno. 4.1.0 is pretty old now. Tell us your operating system and versions of PHP and MySQL, perhaps that would inspire some thoughts. Also indicate if any customizations were done.
Have yet to see either problems in 4.1.0, 4.1.1 or 4.1.2.
If it cannot be replicated in your demo, it’s a pain; but is it truly a bug?
By definition the 2 server setups are highly unlikely to be identical, if the results are so radically different. Some divergence must have occurred, unbeknownst to the programmer.
4.1.0 is missing the bug fixes for “ID creation” where by encounter numbers would sometimes be 'out of order" or reused. Sound very much like you are experiencing that bug.
I don’t think we ever truly figured out why/when that bug was occurring, but subsequent fixes which went into 4.1.1 and later seem to have addressed the problem completely now.
There were never any log indications that this was a problem with debugging/analysis one could see a form getting created with one ID, but a different ID being used to save it, or to attach to an encounter.
Your best bet is probably to upgrade. The code could probably be back-ported to 4.1.0 but that won’t be a simple task.
For what it is worth: OpenEMR has a good memory. Not always nice to have.
When deleting parts or whole table contents openEMR sometimes remember ID’s of other tables and enters the last encountered ID for new registration in other tables. Sometimes very hard to find the disorganizer. You need a kind of concortionist mind to unravel the cause of disorganization. There are easy tables to correct and very complicated tables to unravel.
If you are not too deep into a new setup of OpenEMR it is quickest to start all over with a new install. Or take the long and winding road of connecting every table with the correct counter ID for every involved row…
We’re in the process of reinstalling the whole affair, but I fear it could all be a veritable timebomb until the client faces this bug; we came across it while testing before delivery, and I guess we’re lucky to have caught it at this stage. I don’t even want to think what might have happened if the application was already operational for a few months or a few years.
I’ll keep the “I don’t think we ever truly figured out why/when that bug was occurring, but subsequent fixes which went into 4.1.1 and later seem to have addressed the problem completely now” paragraph.
This does not indicate, in any way whatsoever, that the bug has been fixed. What is the case is that the bug plagued 4.1.0, no one was able to locate the cause, and no code was written with this specific bug in mind.
That said, I’m not sure at all that the problem has been addressed. What seems to be the case, at least to my eyes, is that there have been no new reports of this bug’s occurrence in 4.1.1 or later, but this does not exclude the possibility of it appearing again.
This was a tough bug that involved the logging engine and the generation of GenID in sql table, which had several fixes. Most recent fix is here(2 years ago):
Since that fix, there has been no reports of this bug.