Have been working on a small security tweak consisting of two options.
1) Number of days an encounter is editable.
2) An ACL limiting members to view but not edit encounters.
Option 1: Simply removes the Edit button from the encounter summary when the number of days set in globals is reached. This applies to everyone except admins.
Option 2: Makes use of an ACL to remove the Edit buttons, the Tabs, and AMC box from the encounter summary screen.
Here are two scenarios:
Option 1
Encounters are editable for two days after which only an admin can edit it. Physicians are allowed to edit for two days only, at which point the encounter is “locked” and only viewable. This is not to say they cannot add additional forms or notes.
Option 2
We want Billing to only see encounter notes but not modify them. Add the ACL to the accounting group.
Option 1 seems like a bad idea to me for any number of reasons.
For example. What happens if an encounter is created on Friday before a three day weekend and the physician needs to make a change after he comes back.
Disabling editing after an arbitrary time seems like it could create a lot of frustration for the user, and I don’t really see the benefit.
Hi,
It is configurable and optional. It is disabled if set to 0 or you can set it any number of days. So if long weekends are a problem you can set it to 4 or 5 or what-ever number of days you need.
Yes one can understand the need to modify records after a few days. (ex notes made on paper records being entered after the encounter). But then each practioner would know what is the appropriate timeframe.
Also (if it is set) only users with administrative rights would be able to edit those notes, thus anyone wishing to modify notes older that what the practice normally allows would require going through the appropiate channels (like the delete opton: Which only shows up for administrator group users).
You haven’t made the case as to why the edit button should be removed after two days. It doesn’t really “lock the encounter.” You could still access the view_form.php page directly even if you didn’t have administrative rights and make changes. The encounter isn’t really “finalized” just be cause a fixed time has passed by. It does really seem like “signing off” if it just happens passively.
Physicians I have been working with requested this to avoid note editing after X number of days. The users in this case were frustrated by the fact that perpetual editing was the norm in OpenEMR. They feel that perpetual note editing may lead to erroneous or malicious modification. Which could lead to HIPAA related legal action.
I was very clear on the following:
ANY number of days (Two was just an example) or you could disable it.
And no it does not lock (Which is why the word lock was in quotes), it merely disables the edit function .
Its a deterrent to the average user. Anyone who really really wants to get at the data will do so. And of course it is open to fine tuning.
Since no Encounter locking functions currently exist in the code, I figured something was better than nothing.
I apologize if what seemed to be a good Idea from my clients point of view, turned out be a bad Idea as per your criteria.
Since no Encounter locking functions currently exist in the code, I figured something was better than nothing. I apologize if what seemed to be a good Idea from my clients point of view, turned out be a bad Idea as per your criteria
. No need to apologize as the problem you are trying to address is real, but if you are going to do it, do it right. It seems highly doubtful that this mechanism would satisfy any HIPAA requirements adequately either. As you’ve implemented it would just be “for show” especially since all of the clinical information in the other forms (which is what matters more for an audit) is still editable. (e.g. did the physician adequately document physical exam findings and ROS to justify a level 5 visit…).
Others may agree with you that “something” is better than nothing (your client for example) but I am still of the opinion that as you’ve implemented it, this mechanism adds extra complexity without any true benefit.
I am curious as to what other forms you are making reference to. From what I see it disables editing on all forms in the encounter including CAMOS and from visit forms on the left menu as well. But it does allow adding new forms/amendments to the encounter.
If you haven’t tested it, I invite you to do so. Not tough to do. It doesn’t require much data to be tested. Just a doctor, a patient, and an encounter with a few forms.
Login as admin and create a doctor
On the left menu select Administration->Globals->Features and set Days to Lock Encounter (which should be called days to disable Encounter editing) to 1 (“one”).
Create a Patient and use minimal information (First Name, Last Name, DOB and Sex).
Logout
Login as the doctor you created.
Locate the patient and create an encounter.
Document the encounter with the usual forms (ROS, SOAP, CAMOS)
You can wait 24 hrs or (as admin) go to phpmyadmin and change the encounter date (date) to the day before the encounter date listed in form_encounter to simulate that the encounter is a day old.
As doctor go to the created encounter summary page and verify that the edit function is missing from each form in the encounter.
I am referring to the links at the top of an encounter under “Administrative” and “Clinical” which lead to standard included forms like the Misc Options for HCFA, SOAP, ROS, I didn’t see any code which disables those links. I see that you removed the edit buttons, but you don’t seem to disable the links provided by interface/patient/encounter/new_form.php
How about if change it to:
'Days to allow form edits"
(or something like that)
Isn’t the top encounter menu to open new forms, where Alfonso’s mod is limiting editing of already created forms. If he has clients using it (ie. deemed useful somewhere), minimal code (only about 3 or so lines), and optional, not really seeing a problem here. To really clean it up, suggest placing the ($interval <$enc_lock || $enc_lock ==0) into a clearly named boolean variable (ie. $showEditButton) at the top under $interval = floor($datediff/(60*60*24)); and then using this boolean within the if statement. This then makes it extremely easy to follow (and excise) if ever replace this functionality with something better.
My issue is more with option number 2 (see my comments on github), where it’s probably better to have aco’s always open access to something rather than use them to close off access. Any thoughts there?