Delete Feature Planned

OpenEMR Development
1

sunsetsystems wrote on Wednesday, October 19, 2005:

In case anyone wishes to comment, I’m planning to add a feature for deleting specified patients, encounters and issues.

My current plan is to insert a Delete button in the relevant places which appears only if the user has suitable access rights.  When pressed, the button would pop up a new window that asks for confirmation, does the delete, logs the event, and then calls a JavaScript method of the originating page so that it can gracefully exit from wherever it was.

Any comments/questions, speak up now!

– Rod (http://www.sunsetsystems.com/)

2

drbowen wrote on Wednesday, October 19, 2005:

HIPPA requires very tight control of this feature.  Usually the only person who should have this authority is the database administrator.  Logging is mandatory and should include the information being changed or deleted and the administrative reason for the change.

The current log is inadequate for this purpose and would propose having a separate log for just his feature. 

Ideally there should be more than one level of control.  One is the "super-user" level of the database administrator.

The highest level is the database administrator who may make the judgment that certain info should be deleted.  A typical scenario is the unintentional creation of duplicate patients.  This tool will need to include the ability to merge all info into one pid and then delete the unnecessary pid.  Per Rod’s previous suggestion actual deletion is not actually necessary.  It would be sufficient to make the duplicate pid inactive and no longer visible.

The second could be under the control of the database administrator and supervisory level administrators such as the office manager.  The most typical problem that we run into are posting patient A’s information on Patient B’s chart.  A simple tool to change pid B to pid A. 

The lowest level would query tools searching for duplicate information:

pid
phone numbers
social security numbers
address
last name
first name

We have to deal with a fair amount of intentional fraud on the part of patients.  Typically, they will give information that is partially correct, they change their last name but give the same social security number.

One female patient came in and had created five separate accounts using the same first name but five different last names, phone numbers, SSN, and addresses.  We have a billing clerk who recognized and was able to pull all five of the charts.  I had the woman sign her name as the "original signature" on the first chart and it matched exactly.  She gave the name of the same boy friend on all five charts.

It would be nice if this type of duplicate information was always checked at the time of initial registration so that we can catch these people earlier.

This tool only involves being able to query the data for duplicate information.   Changes should probably only be made at one of two higher administrative levels.

Sam Bowen, MD

3

andres_paglayan wrote on Wednesday, October 19, 2005:

Dangerous, but useful,
What about creating a table that stores some sort of raw information about what was deleted from where the records can be reconstructed, just in case.
I am using gacl thanks to the module Rod checked in, it’s great, thanks Rod,
It will be safer if that feature is only available when gacl is on, and if it has to be manualy expliceted in gacl instead of loaded by default, even better.

4

jimbo456 wrote on Wednesday, October 19, 2005:

I would like to see a separate admin page. Not accessed from within Openemr. But accessed like the Sql-Ledger admin.pl You would need to login with a superuser admin. This can be created during the initial install.

Placed inside this page would be any maintenance type tasks such as patient deleted corrections ect.
I would also like to see the phpMyAdmin moved over to this page as well. “Move it and they won’t Click It!”

Jim Proctor

5

drbowen wrote on Wednesday, October 19, 2005:

I agree with Jim Proctor. This would be a safer feature if accessed only from from an administration page. 

The PHPMyAdmin is a powerful tool but also a very dangerous one. It would nice if this feature were also behind an admin login screen.

6

sunsetsystems wrote on Wednesday, October 19, 2005:

Thanks for all the great feedback guys!

I don’t have much of a budget for this, so there’s not enough time to create a user interface for locating and selecting things to be deleted.  That’s the reason for invoking it via “Delete” buttons in existing modules, where the item to be deleted is already chosen.

The new feature wil be almost entirely contained within a single PHP module, the one for the popup window mentioned above.  You can think of this, if you will, as the “administration page”, and the Delete buttons as just a way of getting to that page.  There’s nothing to prevent later creation of a more comprehensive admin page, and invoking the delete popup from that.

Logging is possible using the current log table.  It includes two fields, "comments" and "user_notes" both of which are arbitrarily large and either of which can be used to save all of the information from a deleted row.

– Rod (http://www.sunsetsystems.com/)

7

nahoj1976 wrote on Wednesday, October 19, 2005:

I must agree with Bowen: This is a very dangerous thing!

In Sweden the patient record (electronic or on paper) is by law owned by the patient. I as a doctor am responsible to write the records and I am responsible to what I write but I need an approval from the central authorities to delete anything. The patient can’t either delete anything without approval.

What more is: We (doctors) are obliged to sign any text in a patient record. Until it is signed - or if we ‘forget’ to sign it: a couple of months have passed - it is open and changeable/deleteable but after that point there must be very strict rules on how to delete/change.

And more:
If the patient - or the doctor - think anything is wrong and asks the authorities for approval of deletion the deletion MUST be complete so that the text that you delete can not be found anywhere…

I understand your problem with people that claim they are someone else and the problem of having double pid for one patient. I don’t think there is any easy solution for it though.

Security in computers, I’ve been told, consist of three things:
- Checking that all information that is put in is true.
- Avoiding any double entry since this will create a conflict of which that is the ‘true’ one.
- Check that no data is lost.

I think one could add to this the checking that the person putting the data in is the one he/she claims to be.

My point with this is that in an EMR we need to be able to easily add information - if we put a tough gate between the doctor and the system to check every possible fault noone will use the system.  And double entry of data is common in any patient record; how many times do we ask our patients for their history and how many times do they tell us a different story?

With this in mind it might sound like I think some kind of signing of all records should be added. The problem is that if you want to mainly work with patients there is no way to get this functioning; either you have to reduce the number of patients you see in order to have time to re-read all notes or you adopt a strategy where you sign notes without reading…

There is nothing as sick as the health-system, I think…

8

sunsetsystems wrote on Thursday, October 20, 2005:

So are you making any requests specific to the delete feature?  If nothing else, it could be disabled as an installation option.

– Rod (http://www.sunsetsystems.com/)

9

sunsetsystems wrote on Thursday, October 20, 2005:

OK, I have checked in my code for this.  Several modules have changed, and the main code for the feature is in interface/patient_file/deleter.php.

To use this you must be using phpGACL, or make appropriate changes to acl.inc.  ACO "super" in section "admin" is the relevant permission requirement (this is also new).

– Rod (http://www.sunsetsystems.com/)

10

nahoj1976 wrote on Thursday, October 20, 2005:

I’m too wordy as usual…

The possibility to delete in a ‘clean’ way, is good but ought to be very hard to do. The logging I would prefer would be in the form:
‘pid deleted because …’ or ‘encounters 20050713-20050815 deleted because …’ if you understand what I mean.

11

sunsetsystems wrote on Thursday, October 20, 2005:

OK, that makes sense.  It would be quite simple to add a reason-for-delete text field to the confirmation dialog, and save its value to the log file.

– Rod (http://www.sunsetsystems.com/)

12

ballards wrote on Tuesday, October 25, 2005:

Rod,

Is this feature added yet to 2.7.3? If not, to which release will it be added? I need it …

Thanks,

Peter Walter

13

sunsetsystems wrote on Tuesday, October 25, 2005:

If you mean the delete feature, it’s already in CVS and will be in the rc1 tarball which I’ll be making this week.

If you mean the reason-for-delete feature, feel free to add it!  It’s just a matter of adding a text field to the popup dialog (deleter.php) and making sure its contents are saved to the log table along with everything else.

– Rod (http://www.sunsetsystems.com/)

14

profjake wrote on Tuesday, January 24, 2006:

I want to change the new patient add code so that it checks for duplicate record BEFORE it attempts to add the patient again. To do this, something else more definitive to identify the patient should be added to the form, like DOB and/or social, and force them to enter it.

Thats pretty easy to just add to the code.
But then I need to find the best way to essentially do a "find patient" with the newly entered data and IF a patient is found, notify the user that this patient already exists.

Has anyone already modded the php to do this before I dive into it and "fix" it?

15

sunsetsystems wrote on Tuesday, January 24, 2006:

This sounds like a good idea.

Probably library/patient.inc is the best place to put a low-level routine for lookup by DOB and/or SSN.  I don’t see anything like that already there.

– Rod
www.sunsetsystems.com

16

profjake wrote on Tuesday, January 24, 2006:

Okay so Im gonna take a stab at it, and then email my new code to the DOC.

BTW, this code and the project in general is similar to the OSCommerce Project. It has LOTS of entire modules contributed. I use CREloaded which is a version that has LOTS of prechecked contribs.

I think we could make the OPENemr project work in the same way (in terms of modules, etc…) and Im willing to help.  In fact, some of the oscommerce modules could be slightly changed to be used woth OPENEMR to make a Point of Sale site for the patient to pay their bill via credit card… but that is a subject for another discussion, I suppose… Im just letting you guys know that the new kid is in town and wants to help OPENemr be all it can be.

17

sunsetsystems wrote on Tuesday, January 24, 2006:

Welcome, Kid!  :slight_smile:

– Rod
www.sunsetsystems.com

18

andres_paglayan wrote on Tuesday, January 24, 2006:

you are very much welcome, please fell free to ask if you are hitting some wall, so you don’t waste time “following the wire” trhough the code.