Database and Documents not in sync after 6.0.0 upgrade

Support
#1

Situation
I just recently upgraded to 6.0.0 and applied Patch 1. Since the upgrade, when I delete a file from the Documents List, the item is removed from the list (i.e., the database), but the actual file remains in the site’s Documents folder. Also, when I use Fax Dispatch to copy a document to the patient’s chart, the file is renamed appropriately in the Documents folder, but the name of the file does not show in the Documents List (only the date and doc_id). I then have to add the name through the Documents List.

OpenEMR Version
I’m using OpenEMR version 6.0.0 (1). I have PHP 7.4 and MariaDB 10.5.8.

Browser:
I’m using: Firefox 86.0.

Operating System
I’m using: Debian Buster

Logs
Pic below shows what happens when I delete an item from Documents List, after the upgrade:
2021-03-20_22-59

Here is a pic of the same action when I used a backup, on version 5.0.2 before the upgrade. When comparing, the “DELETE FROM documents…” seems to be missing, after the upgrade.
2021-03-20_22-56

This pic shows what occurs when I use Fax Dispatch to copy to chart, after the upgrade (name not present):
2021-03-21_08-12

#2

Starting in v6, we no longer store documents to file system by file name but by a hash(or encrypted name) instead. This is for security reasons.
Still @vrjula, this is a bug as you describe the problem and the delete method in controller may have been missed during the change.

Recommend opening a bug issue and one of us will get to fixing it. I just don’t have time right now.

Thanks for taking time to report this issue.

#3

Will do. To clarify then, does the fact that the file is not getting renamed from the Fax Dispatch box have to do with the bug, or is it a separate issue?

#4

File delete is not allowed per ONC.
Fax rename I haven’t a clue and no way to test. Maybe someone else can help here…

#5

Fax/Scan files should not be treated as medical records until attached to a patient. Since these have traditionally resided on the server, developer of that module handled them as “documents”. Now if handling of “documents” is subject to some rules, this can become a problem.

Fax servers receive 10s of spam transmissions every day. Surely they need to be deleted. Many fax/scan files need to be edited before becoming part of medical records.

#6

File delete is not allowed per ONC?

To be clear, the files WERE getting deleted from the patient ID subfolder of the Documents folder before the upgrade. I confirmed this with a backup container I had, with version 5.0.2 installed.

So per ONC, I as an administrator cannot delete files, even if they’re attached to a patient’s folder on the EMR? That seems absurd. There are always times when either I or a staff member uploads something that is a duplicate, erroneous, etc. An administrator should be able to delete that from within the EMR, without having to manually go into the file system, hunt it down, and delete it. Otherwise, all these extraneous files will accumulate.

As to Fax Dispatch, it’s not make or break for me to go rename the file from the controller vs from the Fax Dispatch box itself. But…that renaming field was always there. It didn’t work in the past. Then it was fixed, in version 5 I believe. Now it doesn’t work again. That’s frustrating.

This is the price I’m having to pay for being one of the rare few, it seems, who actually uses the native fax management system. :slight_smile: It really works beautifully, once I customized it to do what it was intended to do. But every time there is an upgrade, something about it breaks. :disappointed:

–Venu

#7

Hi @vrjula ,

Regarding ONC and deletion of things, this is related to audit logging.

There is some “light” reading on this here :slight_smile:
https://www.healthit.gov/test-method/auditable-events-and-tamper-resistance

-brady

#8

Hi @brady.miller,

I read the rule like a lawyer-to-be. :wink:

The issue here is whether original documents should be retained in the system. The rule requires that there merely be an audit log of edits, deletions, etc. That’s fine. If I deleted a document in a patient folder, there should be an audit log that records I did that. It also says, “Conversely, it could include a description of the original data state and provide a link to the modified document.” In the case of deletion, the audit log could record that a document was deleted, and there will be no link since the document was deleted.

Yes, the rule does say, “Demonstrating the ability to view the original document prior to a change or deletion is an acceptable method of meeting the certification requirement.” That would imply that the original document be retained. However the rule also says, “The certification criterion is not prescriptive of how the requirement should be achieved. Demonstrating the ability to view the original document prior to a change or deletion is an acceptable method of meeting the certification requirement, however it is not required during testing.” (Emphasis mine.)

In short, the rule states there should be an audit log of modifications to documents; it then provides examples of how that could be executed but does not prescribe how it must be executed. It even then specifically says the ability to view an original document is not required during testing. I think y’all’s was an “aggressive” reading of this rule. Mine is more to the letter of the rule.

– Venu

P.S. Any lawyers/law professors out there: How did I do? :slight_smile:

#9

Hi @vrjula ,

Here is the clarification in full:

A “pointer to original data state” is a means of identifying original information that has been changed by a user. Similarly, a “pointer to deleted information” is a means of identifying information prior to deletion. A description of a change or deletion is acceptable as long as the type of action is specified and both the original and modified data states are able to be identified. For example, an audit log could include a link to an original document and provide a description of the modified state. Conversely, it could include a description of the original data state and provide a link to the modified document. The certification criterion is not prescriptive of how the requirement should be achieved. Demonstrating the ability to view the original document prior to a change or deletion is an acceptable method of meeting the certification requirement, however it is not required during testing.

So appears the two options are to 1) keep the deleted document or 2) go down the rabbit hole of describing the deleted document :slight_smile:

-brady

#10

@brady.miller,

Avoid the rabbit hole. Option 1 it is.

Frankly, the bigger hit to my workflow has been the document naming not working again from the Fax Dispatch box. Before the upgrade, I could choose the patient, choose what pages I wanted to keep, name the document, date it, and write a message documenting my phone call to the patient about the results, all in one box. Now I have to go back to the controller to name it.

Would it be appropriate for me to report this as an issue on github?

Venu

#11

hi @vrjula ,
Definitely report this on github and I’ll take a look at this (guessing will just require a straightforward fix). The tough thing about that fax module is that is difficult to test, which is why it seems to lag on updates.
-brady

#12

@vrjula, Modify fax dispatch to use standard documents class to fix the issue.