aperezcrespo wrote on Tuesday, January 30, 2007:
By error a patient was created twice and Information was added to both records (Into one by the Doctor and into the other by the Nurse). Is there any easy way to consolidate patient records?
Thanks
Alfonso
markleeds wrote on Thursday, February 01, 2007:
So far my best solution is to tell the office staff to be more careful and not to let it happen again.
One person here came up with the idea to blank out the name of the unused account so the name will not show up in searches.
drbowen wrote on Thursday, February 01, 2007:
Asking the staff “not to do it again” is a bit disingenious. I have been threatening my staff repeatedly “not to do it again” repeatedly and it just doesn’t work.
The problem comes up in a couple of differnet ways. In the first event, a new patient calls in wanting to schedule an office visit. Only part of the information is taken over the phone. A record is created with enough patient information to set up an appointment.
A few weeks later the new patient shows up. The receptionist asks “have you ever been here before?”. Answer: “No”. The receptionist starts a new electronic record with the same name, same birth date etc.
After that, the staff randomly picks first one record, then the other. Someone finally realizes that there are two records on the same person. Then some highly skilled database administrator has to fix the problem. In my practice this is me. I am the only one that I trust enough and has the skill to fix this problem.
Sometimes, the second patient visit has made an honest error and states “No I have never been here before” because there has been enough time go by that they have truly forgotten.
Sometimes, the patient really does remember and is trying to get narcotics, or avoid payment of their bill by falsifying there information.
A better, more permanent solution, would be to alter the “create a new patient” to screen for duplicate names and warn of possible unintentional duplication. Ideally the demographics page should screen for duplicate birth days, telephone numbers, and social security numbers on persons of the same name.
To actually merge two records your have change from the bad pid to the good pid by systematically going through each of the form tables and running an update query that says:
update form_dictation set pid=‘good_pid’ where pid=‘bad_pid’;
update form_vitals set pid=‘good_pid’ where pid=‘bad_pid’;
I like to record all the forms that I am altering to make sure it works correctly.
Then:
update form_encounter set pid=‘good_pid’ where pid=‘bad_pid’;
And finally:
update forms set pid=‘good_pid’ where pid=‘bad_pid’;
Then I check to make sure all the information has transferred correctly. After verifying nothing is missing I delete the bad_pid from patient_data:
delete from patient_data where pid=‘bad_pid’;
This is a dangerous procedure and you can really screw the database big-time. Rod Roark makes the very valid point that you should never try to delete anything from the database. All that is necessary is to reuse the ‘bad_pid’ for a new patient. To do this you have to set the values in patient_data to null/zero or blank. Otherwise you you the risk of unintentionally corrupting the new patient’s information (old inappropriate values left in the record). This is why I prefer deleting the record.
In the United States, all of this activity should be logged with a valid explanation for why you are fiddling with the database in this fashion. (HIPPA) The current logging is not up to this task. To be legal you should keep a hand written log. It is also probably illegal to delegate this task to a lower level person since they don’t have the authority to view or make these changes.
This problem is not going to go away by telling your staff “not to do it again”.
It would be great if someone (wink wink) created a merginh tool for this purpose that also allowed the database administer to record/log why the change is being made.
I do not enjoy performing this task.
Sam Bowen, MD
aperezcrespo wrote on Thursday, February 01, 2007:
I totally agree, This type of data error can come from so many different sources (User error, carelessness, Patients). In one case the provider has alot of seniors whose memory is not exactly up to speed. Sometimes the waiting room is full and the receptionist is overwhelmed. I agree with the duplicate verification on Social Security and birthdays because those dont change. Phone numbers on the other hand do change and can lead to an incorrect result.
A tool of sorts would be just great but how will it handle the different forms? I’m sure not every site is using exactly the same forms. The tool would have to query the registered forms table and then go off and change the pids.
Well that was my 2 cents…and now I’m broke.
Thanks
Alfonso
drbowen wrote on Thursday, February 01, 2007:
The tool could at least query the existing forms.
The reason I specified the phone number is that patients who are intentionally trying to obfuscate the system will change their date of birth and their social security number but frequently forget to change their phone number.
Also, husbands, brothers, roomates and party buddies that they share share narcotics (and other drugs) with, will frequently list the same phone number and/or address. Its helps recognize patterns of abuse.
Sam Bowen, MD
drbowen wrote on Thursday, February 01, 2007:
Or perhaps the tool could request which tables need to be merged?
sunsetsystems wrote on Friday, February 02, 2007:
I think a merge tool could be created, using the current delete tool as a model. See interface/patient_file/deleter.php. Note that it does extensive logging and handles most forms without any form-specific knowledge.
However I also think the deleter first needs a careful review; it may not be handling all situations properly.
aperezcrespo wrote on Friday, February 02, 2007:
Good one on the phone number Sam, I didnt think of that. Having the tool request which tables need to be merged? If by error two or records exist for a single patient and no has noticed for a while, how would one know which tables to merge? Also after the merge takes place how can the removed PID be reused?
What if the new patient option was removed this way one is forced to do a patient search first. List all matches with some identifing information (Phone number, DOB, SS, and Record number) followed by a Add Patient option at the end of the list. The user would then either select a patient from the list or click on add patient.
I think this would cover Sams patterns and help reduce creating duplicate records.
Alfonso
drbowen wrote on Friday, February 02, 2007:
The tool can be made to merge forms_*, forms, history_data at a minimum. Rod may be aware of others having to do with the Calender and billing.
However, if the practice builds custom forms, a standard set of forms will likely not work. These practices could be given the opportunity to add their practice specific forms so that the actual query(ies) would be customizable by the database administrator to account for this situation.
Sam Bowen
bo2999 wrote on Friday, February 02, 2007:
I agree with Alfonso approach:
"What if the new patient option was removed this way one is forced to do a patient search first. List all matches with some identifing information (Phone number, DOB, SS, and Record number) followed by a Add Patient option at the end of the list. The user would then either select a patient from the list or click on add patient.
I think this would cover Sams patterns and help reduce creating duplicate records."
But instead of removing the new patient option. I think we should introduce a forced "SEARCH and MATCH" option in the "New patient" option that will do a search for existing patient first and list all matches and followed by an "ADD PATIENT" option at the end of the list. This will assure that we do not enter the same patient twice.
Bo,
anonymous wrote on Friday, February 09, 2007:
Now you are attempting to address a training issue. Users are creatures of habit, and by and large, whether the "New Patient" search is forced or not, they will ignore the search, and still just click "Add" at the bottom of the list. Although the forced search idea is an excellent one, since it will make life easier for those of us who actually care to try to prevent that issue. But employees are employees, and most will likely ignore the search page, and go straight for the "ADD" button.
anonymous wrote on Friday, February 09, 2007:
PPS:
A report that is run that can flag POSSIBLE DUPLICATES. (A DUPLICATE report.)
The report should generate a table with which the admin can use a form to say which records should be merged.
Instead of “Deleteing” the PID, there should be a way to flag the PID as a subordinate record that is now permanently attached to this other PID, or BOTH PID’s should be flagged and a NEW PID generated with the merged Data. Records with this flag should no long pull up in the match patient report, as they should now be permanent members of another record…in otherwords only “Master” or Non-Merged records should pull up Patient name and info. Other merged record info should also show up in reports as being merged from another record, and be able to diverge the records should the case be that it was a mistake to merge the records to begin with.
Case in point:
There are 3 people in my city whose birthdays are the same as mine,and have the same First/Last name as me. Other info is different, such as middle name, SS#, address, race, but it would be possible that someone could accidentally merge my record with theirs. (DMV has twice.)
So it is VERY important that if something is merged, that it actually remains under the original PID, and that that PID is some how flagged as a merged record. Having been incharge of writing routines to do such on a Pick type database, I know the headaches, and that it may be necessary to "UNDO" a merge, especially in a medical practice.
If the Database is not set up for this now, it will probably mean at the very least, an additional set of fields. Since this is an SQL database, it means a lot of additional overhead, since EVERY record will need this new merge field.
But my experience shows that the MERGE field is the best method for HIPPA compliance and the ability to UNDO a merge if for some unforseen reason, enough evidence was shown to require merging, then later evidence uncovered something indicating that there were actually two people with the same info, and only different addresses. (Happens more frequently than one would think.)
drbowen wrote on Friday, February 09, 2007:
I don’t think it should be optional at all.
The "add new patient" form should have required, at a minimum, last name, first name, date of birth, SSN, home address and telephone number.
The checks would happen on every "add new patient" without operator intervention. The program will will usually add the new patient but if a duplicate record is found the program should complain duplicate records found and ask for operator intevention.
For duplicate name, date of birth, address, phone number the program should warn about the duplication and ask to "go ahead and add" or correct the problem by re-entering the information.
To my knowledge there is no vaild reason, in the United States, for a duplicate social security number.
There are legitimate reasons that a patient might not have an address (homeless), phone number (homeless), or social security number (infants) so there should be an option to intentionally leave this blank.
Sam Bowen, MD
linuxed wrote on Friday, April 27, 2007:
My $.02
A SSN should not be required.
Why? I don’t need to have it for cash patients, or kids. What if someone doesn’t know it off hand? They should still be able to make an appointment.
But, if it’s not blank, dups could be checked to help find patient thats been entered twice.
Also, I’ve had problems with the case of the name. Someone here likes to use CALL CAPS. So, if the patient is entered as Frank, a person searching for FRANK will not find it and create a new patient.
I’d like an option to always make the search expression lower case.
linuxed