My apologies if this question has been answered already, I could not find any related information either here on the forums or in the OpenEMR documentation.
The question is this: How does one go about restoring a single patient encounter that someone foolishly deleted from the system? We don’t give anyone permission to delete anything, but someone went ahead & logged in as an admin & deleted an encounter while attempting to delete a scanned note attached to an encounter.
I have backup copies of the OpenEMR database from the night before, but I don’t want to restore the whole DB, just the one encounter that was stupidly deleted.
Is there any feasible way to do this, or is it impossible? The only thing I could think of was to restore the DB on a temp system & try to track down the encounter there, then export the relevant DB entries & re-import (or maybe recreate) them on the working system. Could this work, or is there no way to restore the encounter now that the deletion has taken place?
Side note, when something is “deleted & logged” in OpenEMR, where is it logged & is there a way to view that information?
I don’t want to sound trite or trivial but exactly what did they do to “delete” the encounter?
Do you know the "pid" of the patient whose information was deleted?
Are you running binary logging?
You could use "mysqlbinlog" to open the binary log that contains the deleted data and recover just the portion you need.
The command syntax is described as:
shell> mysqlbinlog [options] log_file …
You could open the binary log file and search for the using the "find" function.
shell> mysqlbinlog binlog.0000003
For instance if the "pid" was 1256. You could search the binary log for "1256" and skip down to that "pid" and keep "find next" until you find where the data was inserted into the database. Mysqlbinlog opens the binary log so that you can read it in plain text and then you can just "cut and paste" to reinsert into OpenEMR.
Depending on what exactly was deleted you may need to recover the "form_encounter", the "form_vitals" and any other forms that were involved will need to be recreated.
Maybe you could restore the backup DB on the same system side by side with your existing DB and restore the deleted records. There are at least several records in different tables that you will have to copy over by pid and encounter.
Be careful and back up everything important before doing anything.
Thanks guys! I did find the deletion log in OpenEMR & hopefully can use that to recreate the data. Oddly enough I had never really spent much time looking at the log search functions in Admin, very useful.
I do have the PID & we know exactly what was deleted & when so it turned out not to be too difficult to find, it’s just the recreation/re-insertion of the data that’s a PITA.
All of our systems have a nightly backup to tape drive as well as a mysql dump to a separate folder on the filesystem, so I’m confident that the relevant data can be tracked down eventually.
We allowed an office manager to have access to a special account with Administrator permissions in case they needed to delete something, after explaining to her that it was only to be used when absolutely necessary & preferably to ask before doing anything.
Of course, human behavior being what it is, the user ran amok in the system rather than asking a simple question before clicking on the the first visible Delete link.
And no, that system does not currently have binary logging running but I will definitely be looking into it after seeing what a hassle this has become, it would also seem that permitting end users to have any kind of Administrative system access should not be allowed in the future.
As a computer science professor used to tell us every day in our old RPG programming classes, “There is no such thing as idiot-proof!”
Any further suggestions will be more than welcome. I would like to write up some type of guidelines for this procedure to add to future OpenEMR system documentation.
It is usually technically simpler to reassign information by updating the pid number on the information. This is usually much less dangerous than actually deleting the item. It also saves time because the information does not need to be reentered.
For instance if the scanned data was assigned to the wrong patient. Just run an update query to change the bad pid to the correct one.
The database administrator should be the only person with delete privileges. This definitely needs to be logged with the reason for the deletion also recorded.
If the information was inappropriate and should not be in the database to start with, you need to point your finger at the practitioner who uploaded the data in the first place.
In practice the only thing that I ever delete, is a duplicated patient in the patient_data table. This avoids confusion and inappropriate recording of data on the wrong chart. To do this you have to make sure that the abnormal patient record is completely empty first.
It is still easier (and safer) to just change the name of the wrong duplicated patient to something like "Wrong" "Chart". This way every one in the office will recognize that the chart should not be used. This has been discussed is previous posts.
What you have is that your office manager has committed a major HIPPA violation. If you are the owner you are legally responsible and you could face federal charges.
Do you really want your office manager to have this kind of authority over your life?