Learning About Patient EDM Maintenance Tasks

Patient profile maintenance involves a number of tasks you can perform to ensure that your database contains the most current and accurate information. These tasks include editing, adding, and deleting patient information, detecting and fixing profiles that are potential duplicates of each other, merging and unmerging patient profiles or system records, and deactivating patient profiles or system records that are no longer active.

The following topics provide additional information to help you understand data maintenance tasks for Oracle Java CAPS Master Patient Index.

• Matching Probability Weights

• Merging Profiles on the Patient EDM

• Assumed Matches

• Potential Duplicates

• Handling Potential Duplicates

• Patient EDM Update Tips

Matching Probability Weights

When you add a new patient profile to master index application, the new profile is automatically checked for any similarities to profiles that already exist in the database. Matching probability weights between existing profiles and the new profile are then calculated using matching algorithm logic. This weight indicates how closely two profiles match each other. If the matching probability weight for two profiles is above a specific number (defined in the Oracle Java CAPS Master Patient Index configuration files), the profiles are considered to be potential duplicates. If the weight between two profiles is high enough, they are assumed to be a match and the existing profile is updated with the new information.

Merging Profiles on the Patient EDM

You can merge patient profiles that are found to represent the same patient and you can merge system records between patient profiles. During a system record merge, you can specify which fields from each record to retain in the final, merged system record. After a patient profile merge, all information from all the system records involved in the merge is stored in the surviving profile. You might need to review the final merge result profile to determine which, if any, system records should be deactivated.

The SBR for the surviving profile is determined by the survivor calculator, taking into account all system records involved in the merge. If you merge two profiles that have duplicate child objects (for example, each profile has an Office address) and the union survivor calculator is used, then the most recently modified of the two child objects is stored in the SBR.

Surviving and Non-surviving Profiles

When you perform a patient profile merge, you are working with two patient profiles. The non-surviving profile is the profile that is not retained after the merge. The surviving profile is retained after the merge. During a patient profile merge, the system records in the non-surviving profile are transferred to the surviving profile, and the non-surviving profile is given a status of “Merged”. The SBR for the surviving patient profile is recalculated based on the existing system records for that profile along with the newly merged system records. The EUID of the surviving profile is always retained. The information that is discarded during a merge is stored in the transaction table, making it possible to restore the profiles to their original EUIDs if they were merged in error.

System Record Merges

You can merge two system records together only if they originated from the same external system. The system records can belong to the same patient profile or each can belong to a different profile. When the merge includes two different patient profiles, the profile from which the system record is merged is called the merge from profile; the patient profile into which the system record is merged is called the merge to profile. If you merge the only active system record in one patient profile into a system record in a different patient profile, the merge from profile is deactivated (since there are no active system records remaining, there is nothing from which to create the SBR). During a system record merge, you can select fields from the non-surviving system record to be retained in the surviving system record.

Undoing a Merge

If you merge two patient profiles or system records in error, you can unmerge the profiles or records, moving the information back into the original patient profiles or system records. Any modifications that were made to the surviving patient profile or system record after the merge are retained after the profiles or records are unmerged. If a system record merge caused the “merge from” patient profile to be deactivated, unmerging the system records reactivates that profile.

Assumed Matches

If you add a new patient profile and the master index application determines that the patient you are adding already exists in the database, the master index application assumes the profiles are a match and updates the existing patient profile. This is known as an assumed match. An assumed match only occurs when the probability of a match between the new profile and the existing profile is above the match threshold specified by your system administrator.

Potential Duplicates

Potential duplicates are two patient profiles that possibly represent the same patient. If you add a new patient and the master index application determines that the patient you are adding might already exist in the database, the two profiles are listed as potential duplicates of one another. Profiles are listed as potential duplicates if the probability of a match between the two profiles is above the duplicate threshold but below the match threshold. Because patient information is entered from various sources, a patient profile might have several potential duplicates. In this case, it is important to identify the potential duplicates and to determine whether the profiles represent the same patient.

Handling Potential Duplicates

The Matching Review function allows you to locate any profiles that are similar enough that they could represent the same patient. You can compare potential duplicate profiles side-by-side to determine if they do represent the same patient. Once you have determined whether the profiles are duplicates, you can use one of the following methods to correct the potential duplicate listing.

Merge

If you conclude that the profiles represent the same patient, you need to determine which EUID to retain and then merge the profiles. For a description of the merge process, see Merging Patient Profiles.

Resolve

If you conclude that two potential duplicate profiles do not represent the same patient, you can mark the profiles as being resolved. Doing this does not change any information for either profile, but it flags them as not being potential duplicates of one another. There are two methods of resolving potential duplicates.

• Resolve – This type of resolution allows the profiles to be listed as potential duplicates again if one of the profiles is updated and, after its potential duplicates are reevaluated, the profiles still have a matching weight above the duplicate threshold.

• Resolve Permanently – This type of resolution marks the profiles as not being duplicates, and does not allow the pair to be listed as duplicates after any future updates to either record. This is a permanent resolution.

Patient EDM Update Tips

There are special circumstances for updating patient profiles, such as cases where two users update the same profile at the same time, or when updating the SBR rather than updating a system record.

Concurrent Users

If you have the same patient profile open for editing as another Patient EDM user, only the user who commits their changes first will be able to save their changes. If you try to commit changes after the first user clicks Commit, an error message appears and you will be unable to commit your changes. In order to update the profile with your changes, you must reload the profile by performing a search for that profile. You can then edit the profile and commit your changes.

Updating the SBR and Updating System Records

Every time a system record is updated, the survivor calculator determines whether the new information should be populated into the SBR. This includes updates from the Patient EDM and from local systems. Typically, when you update information in a patient profile, you update the system record, which kicks off the survivor calculator. However, the Patient EDM also allows you update the SBR directly, overriding the survivor calculator's version of the SBR.

When you update an SBR field, the overwrite check box is automatically selected so you can save the changes to the database. You can also select the overwrite check box to lock a value in an SBR field and prevent it from being updated by any system record changes or by the survivor calculator until the overwrite check box is cleared. When a field is unlocked, the survivor calculator immediately recalculates the best value for that field based on the system records in the profile.

If a field in a child object, such as an Address or Phone object, is locked, then the key field (in this case, Address Type or Phone Type), is automatically locked. When you add a child object (such as a telephone number or address) directly to the SBR, all fields in that object are automatically locked and cannot be overwritten by the survivor calculator. If you unlock all the fields in that object, it is removed from the SBR by the survivor calculator.

Use this capability cautiously, since fields updated in the SBR cannot be overwritten by new information from local systems until the overwrite check box is cleared. You can only update an SBR and select or clear the overwrite check box if you have explicit security permissions to do so.

VIP Updates

In order to view or modify the fields that are masked by a profile’s VIP status, you must have VIP access permissions. If you do not have VIP access permissions, you cannot add or update a child object, such as an address or telephone number, that contains fields affected by the VIP mask.