| Oracle® Healthcare Master Person Index Data Manager User's Guide Release 3.0 E62301-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Healthcare Master Person Index Data Manager User's Guide Release 3.0 E62301-01 |
|
|
PDF · Mobi · ePub |
This chapter introduces you to the Master Index Data Manager maintenance tasks that include adding, editing, and deleting information, finding duplicate profiles, merging and unmerging profiles and records, and deactivating profiles and records. It also provides procedures on how to use the MIDM to perform these tasks and keep your master person index database accurate. It includes the following sections:
Object 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 information, detecting and fixing profiles that are potential duplicates of each other, merging and unmerging object profiles or source records, and deactivating object profiles or source records that are no longer active.
The following sections provide additional information to help you understand data maintenance tasks for the master person index application.
When you add a new object profile to the master person 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 master person index application 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. For more information, see Assumed Matches.
You can merge object profiles that represent the same object, and merge source records within the same object profiles or between different object profiles. The source records you merge must be from the same source system. While merging, you can specify which fields from each record to retain in the final merged source record. After an object profile merge, all information from all source records involved in the merge is stored in the surviving profile. You may need to review the final merge result profile to determine which source records must be deactivated or merged (if any).
After an object profile merge, the SBR for the surviving profile is determined by the survivor calculator, taking into account all source records involved in the merge. If you merge profiles that have duplicate child objects (for example, each profile has an Office address), and the union survivor calculator is used, the most recently modified of the two child objects is stored in the SBR. After a source record merge, the SBRs for both object profiles are determined by the survivor calculator if both profiles are still active.
You can perform an object profile merge on two to four object profiles. The non-surviving profiles are the profiles that are not retained after the merge. These profiles are also referred to as merged profiles. The surviving profile is retained after the merge. This profile is also referred to as the main profile. During an object profile merge, the source records in the non-surviving profiles are transferred to the surviving profile, and the non-surviving profiles are given a status of Merged. The SBR for the surviving object profile is recalculated based on the existing source records for that profile along with the newly merged source 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 are merged in error. You can specify which profile to retain during a merge and select fields from the non-surviving source record to be retained in the surviving source record.
You can merge source records together only if they originated from the same external system. The source records can belong to the same object profile or different profiles. When the merge includes different object profiles, the profile from which the source record is merged is called the merge from profile. The object profile into which the source records are merged is called the merge to profile. If you merge the only active source record in one object profile into a source record in a different object profile, the merge from profile is deactivated (since there are no active source records remaining, it is not possible to create the SBR). During a source record merge, you can select fields from the non-surviving source record to be retained in the surviving source record.
If you merge object profiles or source records in error, you can unmerge the profiles or records, moving the information back into the original object profiles or source records. Any modifications that are made to the surviving object profile or source record after the merge are retained after the profiles or records are unmerged. If a source record merge caused a merge from object profile to be deactivated, unmerging the source records reactivates that profile.
If you add a new object profile and the master person index application determines that the object you are adding already exists in the database, the master person index application assumes the profiles are a match and updates the existing object 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. You can view assumed match transactions on the MIDM and reverse the match if needed. Reversing an assumed match creates a new object profile from the record that caused the assumed match and reverts the profile that is updated by the assumed match to its previous state.
Potential duplicates are object profiles that possibly represent the same object. If you add a new object, and the master person index application determines that the object might already exist in the database, the 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 object information is entered from various sources, an object profile may have several potential duplicates. In this case, it is important to identify the potential duplicates and to determine whether the profiles represent the same object.
The Duplicate Records function lets you locate any profiles that are similar enough that they could represent the same object. You can compare potential duplicate profiles side-by-side or tabular format to determine if they represent the same object. Once you have determined whether the profiles are duplicates, you can use one of the following methods to correct the potential duplicate listing.
If you conclude that the profiles represent the same object, you need to determine which EUID to retain and then merge the profiles. For a description of the merge process, see Merging Profiles on the MIDM.
If you conclude that two potential duplicate profiles do not represent the same object, you can mark the profiles as being resolved. Performing 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 or Resolve Until Recalculation - This type of resolution lets the profiles be listed as potential duplicates again if one of the profiles is updated. After its potential duplicates are re-evaluated, 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 let the pair be listed as duplicates after any future updates to either record. This is a permanent resolution.
Every time a source record is updated, the survivor calculator determines whether the new information must be populated into the SBR. This includes updates from the MIDM and from local systems. When you update information in an object profile, you update the source record, which initiates the survivor calculator. The MIDM provides two methods to override the survivor calculator for the SBR. You can update the SBR directly and lock that field for editing, or you can link the value of an SBR field to the value of a source record field.
You can use MIDM to link the value of a specific source record field to the same field in the SBR. When you link an SBR and source record field, the value of the SBR field is always the same as the field in that source record. If the field value is subsequently updated in the source record, the changes are shown in the SBR. The link icon (for example, the open link) also appears in the system record The field values remain the same until the link is removed, at which point the survivor calculator immediately recalculates the best value for the field based on the source records in the profile. You can only link SBR and source record fields in the parent object and only if you have explicit security permissions to do so.
When you update an SBR field directly, the link icon to the database must be closed for you to add your changes. After you make changes, open the link icon to prevent an SBR field from being updated by any source record changes or by the survivor calculator. When a field has an open link, the survivor calculator immediately recalculates the best value for that field based on the source records in the profile.
Note:
Use this capability cautiously, since fields updated in the SBR cannot be overwritten by new information from local systems until you close the link icon, which lets you overwrite the information. You can only update an SBR and overwrite parent object fields, only if you have explicit security permissions to do so.Note:
A closed link indicates an unlinked field that can be linked. An open link indicates a linked field that can be unlinked.If you have the same object profile open for editing as another MIDM user, only the user who commits their changes first can 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. 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.
Once an object profile is added to the master person index application, you can modify information about that object, update the SBR of the object, add or delete source records to or from the profile, or change the status of a source record or object profile. If you make any of these modifications, the survivor calculator determines what changes, if any, must be made to the SBR. You can only modify the SBR directly if you have access permission to do so.
Perform any of the following tasks to update profile information:
If the information for an object profile changes, you can update the information in either the SBR or the affected source record. If you update the source record, the survivor calculator determines what changes, if any, must be made to the SBR. You must have overwrite permissions to update the SBR directly. If you know the local ID and system of the source record you want to modify, you can access the source record directly, as described in Modifying Information Directly in a Source Record.
Perform any of the following tasks to modify information in an object profile:
The Record Details page has an edit mode, where you can modify field values in the displayed object profile.
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to modify on the Record Details page.
Click Edit EUID.
To update the SBR, perform the following:
For each field in the parent object you want to modify, click the padlock icon to the left of the field to modify, and then modify the value of the field.
Click Update parent_object under the fields you modified (where, parent_object is the name of the parent object.
Note:
You can only modify SBR fields directly if you have permissions to do so.To update a source record, modify the parent object fields in any of the displayed system objects.
After modifying information, click Update parent_object (where, parent_object is the name of the parent object).
Click Save at the bottom of the page, and click OK on the information dialog box that appears.
The page refreshes and if you have modified a source record, the SBR is recalculated based on the new information.
If additional information becomes available about an object, you need to add a new child object to the object profile. For example, if additional address information becomes available, you need to add a new address record to the affected source record. You cannot add a child object to the SBR.
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to modify on the Record Details page.
Click Edit EUID.
Click View child_type in the column containing the source record you want to modify.
For example, to add an address record, select View Addresses.
In the empty field, enter the new information for the child object.
Below the updated record, click Save child_type.
Scroll to the bottom of the page and click Save.
Click OK on the information dialog box that appears.
The page refreshes and the SBR is recalculated based on the new information.
If information about a child object changes, you may need to modify information for an existing child object. You cannot modify information in child object in the SBR.
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to modify on the Record Details page.
Click Edit EUID.
In the source record you want to modify, click View child_type, where child_type is the name of the child object type you want to modify. For example, to modify an address record, select View Addresses.
Empty child object fields appear along with a list of existing child objects of the selected type.
In the child object list, click the pencil icon next to the child object you want to modify.
The field values for the selected child object are populated into the child object fields.
Modify any fields for the child object.
Below the updated record, click Save child_type.
Scroll to the bottom of the page and click Save.
Click OK on the information dialog box that appears.
The page refreshes and if you have modified a source record, the SBR is recalculated based on the new information.
If a child object is entered incorrectly or becomes obsolete, you can delete the object from the affected object profile. Child objects cannot be deleted from the SBR. Deleting a child object cannot be undone.
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to modify on the Record Details page.
Click Edit EUID.
Click View child_type in the source record you want to modify, where child_type is the name of the child object type you want to delete. For example, to delete an address record, select View Addresses.
Empty child object fields appear along with a list of existing child objects of the selected type.
In the child object list, click the delete (X) icon next to the child object you want to modify.
Scroll to the bottom of the page and click Save.
Click OK on the information dialog box that appears.
The page refreshes and if you have modified a source record, the SBR is recalculated based on the new information.
If the object information for a specific source record changes, you can update the information by accessing either the object profile or the affected source record. If you update the source record, the survivor calculator determines what changes, if any, must be made to the SBR. This section describes how to modify information by accessing the source record directly. For information about modifying an object profile, see Modifying Information in an Object Profile.
Perform any of the following tasks to modify information in a source record directly:
If parent object for a particular source record changes, you can update the source record directly on the Source Record page.
In the MIDM tabbed headings, click Source Record.
If necessary, click the View/Edit subtab.
In the System drop-down list, select the name of the system for the source record you want to modify.
In the Local ID field, enter the local ID for the record you want to modify.
Click Search.
If a matching source record is found, it appears on the Source Record page in the view mode.
Click Edit.
Modify the parent object fields in the upper portion of the page.
Scroll to the bottom of the page and click Save.
Click OK on the information dialog box that appears.
The page refreshes and if you have modified a source record, the SBR is recalculated based on the new information.
If additional information becomes available about an object, you need to add a new child object to a source record. For example, if additional address information becomes available, you need to add a new address record to the affected source record.
In the MIDM tabbed headings, click Source Record.
If necessary, click the View/Edit subtab.
In the System drop-down list, select the name of the system for the source record you want to modify.
In the Local ID field, enter the local ID for the record you want to modify.
Click Search.
If a matching source record is found, it appears on the Source Record page in the view mode.
Click Edit.
Click View child_type, where child_type is the name of the type of child you want to add.
The child object section expands to display empty fields for the object.
Enter information into the empty child object fields.
Click Save child_type.
After adding information, click Save at the bottom of the page.
Click OK on the information dialog box that appears.
The page refreshes and if you have modified a source record, the SBR is recalculated based on the new information.
If information about an object changes, you may need to modify information for an existing child object. You can make those changes on the Source Record page.
In the MIDM tabbed headings, click Source Record.
If necessary, click the View/Edit subtab.
In the System drop-down list, select the name of the system for the source record you want to modify.
In the Local ID field, enter the local ID for the record you want to modify.
Click Search.
If a matching record is found, it appears on the Source Record page in the view mode.
Click Edit.
Click View child_type, where child_type is the name of the type of child you want to modify.
The child object section expands to display empty fields for the object along with a list of existing child objects.
Click the pencil icon next to the child object you want to modify.
The child object fields are populated with the values from the child object you selected.
Modify any of the child object fields.
Click Update child_type.
After modifying information, click Save.
Click OK on the information dialog box that appears.
The page refreshes and if you have modified a source record, the SBR is recalculated based on the new information.
If a child object is entered incorrectly or becomes obsolete, you can delete the object from the affected source record. Deleting a child object cannot be undone.
In the MIDM tabbed headings, click Source Record.
If necessary, click the View/Edit subtab.
In the System drop-down list, select the name of the system for the source record you want to modify.
In the Local ID field, enter the local ID for the record you want to modify.
Click Search.
If a matching record is found, it appears on the Source Record page in the view mode.
Click Edit.
Click View child_type (where, child_type is the name of the type of child you want to delete).
The child object section expands to display a list of existing child objects.
Click the delete (X) icon next to the child object you want to modify.
After modifying information, click Save, and then click OK on the information dialog box that appears.
The page refreshes and the SBR of the object profile is recalculated based on the new information.
Locking an SBR field for overwrite ensures that the value for that field is not recalculated by the survivor calculator each time the object profile is updated. If you determine that a value in the SBR is the most accurate data and must not be updated, you can lock the field, and no updates can be made to that SBR field by the survivor calculator until it is unlocked. If you unlock a locked field, the value of that field is automatically recalculated by the survivor calculator once the unlock action is committed. Parent and child object fields can be locked.
When you lock a field in an SBR, that field can only be updated through the MIDM by a user who has overwrite permissions. Locking a field in the SBR removes the survivor calculator from the update process for that field, and any updates made to or by source records will not update the locked fields in the SBR. You can lock fields in the parent and child objects.
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile containing the field you want to lock on the Record Details page.
Click Edit EUID.
Scroll to the SBR field you want to lock. Parent and child object fields can be locked.
If necessary, change the value of the field to be locked.
Click the padlock icon to the left of the field.
Note:
A closed padlock indicates an unlocked field that can be locked. An open padlock indicates a locked field that can be unlocked.Click OK on both dialog boxes that appear.
Click Save at the bottom of the page, and then click OK on the confirmation dialog box.
The field is now locked and cannot be edited by updates to source records until the lock is removed. The link icon is also removed since a locked field cannot be linked to a source record field.
Once you unlock a field for overwrite in an SBR, the SBR is recalculated by the survivor calculator, and the field can be updated by changes made to source records.
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile containing the field you want to unlock on the Record Details page.
Click Edit EUID.
Scroll to the SBR field you want to unlock.
Click the unlocked padlock icon to the left of the field.
Note:
A closed padlock indicates an unlocked field that can be locked. An open padlock indicates a locked field that can be unlocked.On both dialog boxes that appear, click OK.
Click Save at the bottom of the page, and then click OK on the confirmation dialog box.
The field is now unlocked and can be edited by updates to source records. The link icon appears next to the field indicating that the field can be linked to a source record field.
Linking an SBR field to a field in a source record ensures that the value for that field is not recalculated by the survivor calculator each time the object profile is updated. If you determine that a value in a specific source system is the most accurate data and must always be used in the SBR, you can link the field values and override the survivor calculator's version of the SBR.
If you unlink a linked field, the value of that field is automatically recalculated by the survivor calculator once the unlink action is performed. You can link field values from the parent and child objects.
When you link a field in an SBR to a field in one of the profile's source records, the value of the field is always equal to the value of the field in the source record, even when the source record field is updated. Linking a field in the SBR to a source record removes the survivor calculator from the update process for that field. Any updates made to or by other source records in the profile will not update the linked field in the SBR. Use linking if the field value from a specific source record is most accurate and current value. You cannot link an SBR field if it is locked for editing.
Linked fields in an object profile are indicated by the link icons to the left of the fields in the source record. All other fields have the link icon in the SBR.
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile containing the field you want to link on the Record Details page.
Click Edit EUID.
Scroll to the SBR field you want to link.
Click the chain-link icon to the far left of the field.
A pop-up window appears where you can specify the source record to link.
Note:
A closed link indicates an unlinked field that can be linked. An open link indicates a linked field that can be unlinked.On the pop-up window, select the source system code and the local ID of the source record to which you want to link the selected field.
Click OK on the dialog boxes that appear.
Click Save and then click OK on the confirmation dialog box.
The link icon moves from the SBR field to the source record field and the link icon is removed (because a field cannot be both linked and unlinked). The SBR field is now linked and can only be edited by updates to the source record to which it is linked.
Once you unlink a field in the SBR from the corresponding field in the source record, the SBR is recalculated by the survivor calculator, and the field can be updated by changes made to other source records. An SBR with no fields linked are indicated by all link icons next to the SBR fields (in the column below the red arrow).
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile containing the field you want to unlink on the Record Details page.
Click Edit EUID.
Scroll to the field you want to unlink.
Click the chain-link icon to the left of the field in the source object.
Click OK on both dialog boxes that appear.
Click Save at the bottom of the page, and then click OK on the confirmation dialog box that appears.
The icon is moved from the source record field to the SBR field that is no longer linked. The SBR is recalculated by the survivor calculator.
If an object has local IDs in addition to those already recorded in the master person index application, you can add the local IDs to the object's profile by adding a source record to the profile.
To add a local ID to an object profile, you need to specify information such as, the system that assigned the local ID, certain parent object information, and the local ID itself. When you add a source record to an object profile, the survivor calculator determines what changes, if any, must be made to the SBR.
You cannot add a new local ID and system pair to an object profile if that same local ID and system pair already exists in another object profile.
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to modify on the Record Details page.
Click Edit EUID.
At the bottom of the page, click Add SO.
A new column appears to the right of the existing records to add the new source record.
Enter the system and local ID for the new source record, and then click Validate.
If no existing record matches the system and local ID you entered, and the local ID is of a valid format, a validation succeeded message appears.
Enter information in the parent object fields.
For each child object to add, perform the following:
Click Add child_type in the column containing the new source record.
For example, to add an address record, select Add Addresses.
Enter the new information for the child object.
Below the child object you updated, click Save child_type.
Scroll to the bottom of the column and click Save.
Click OK on the dialog box that appears.
At the bottom of the page, click Save.
Click OK on the dialog box that appears.
The page refreshes and the SBR is recalculated based on the new information.
Note:
You only need to enter required fields to save the new source record. Required fields are indicated by an asterisk (*).You can delete a source record from an object profile by performing one of the following:
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to modify on the Record Details page.
Click Edit EUID or 
.
At the top-right corner of the column for the source record that you want to delete, click 
.
The Confirmation dialog box appears.
Click OK on the dialog boxes that appear.
In the tabbed headings, click Source Record.
Click the View/Edit subtab if it is not already selected.
In the System drop-down list, select the system from which the source record originated.
In the Local ID field, enter the local ID number for the source record you want to view.
Note:
If the Local ID field allows alphabetic characters, the search is case-sensitive.Click Search.
If the local ID is found, the source record fields appear in the view mode.
Click Delete.
If an object profile or source record is no longer active, you can either delete the profile or deactivate it. Once you deactivate a record, you can reactivate it if needed. Deactivating an object profile removes the potential duplicate listings for that profile. If you deactivate a source record, the survivor calculator determines what changes, if any, must be made to the SBR.
Deactivated profiles cannot be modified, and in some cases, cannot be viewed. If you deactivate a profile in error, you can reactivate it if needed.
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to deactivate on the Record Details page.
Click Deactivate.
The profile is deactivated in the database and the EUID appears on the MIDM screen.
If an existing local ID for an object becomes obsolete, you can deactivate the source record with that local ID for the object profile. An object profile must have at least one active local ID. If you deactivate an object's last active source record, the entire profile is deactivated. When you deactivate a source record from an object profile, the survivor calculator determines what changes, if any, must be made to the SBR.
You can deactivate a source record from the Record Details page, where you can view the source record within the context of its profile.
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile containing the source record you want to deactivate on the Record Details page.
Click Edit EUID.
Below the source record you want to deactivate, click Deactivate.
Click OK on the information dialog box that appears.
The page refreshes and the SBR for the object profile containing the source record is recalculated based on the new information.
Once an object profile or source record is deactivated, you can reactivate it if needed. Reactivating a profile causes the potential duplicates for the profile to be recalculated. Reactivating a source record causes the SBR to be recalculated.
If an object profile is deactivated in error or becomes active again, you can reactivate that profile. Reactivating a profile returns the profile to its status before it was deactivated.
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile you want to reactivate on the Record Details page.
Click Activate.
Click OK on the information dialog box that appears.
The profile is reactivated in the database.
If a source record was deactivated in error or is no longer active, you can reactivate the source record. You can activate the source record from the Record Details page, where you can view the source record within the context of its profile.
Using one of the search methods described in Searching for Object Profiles on the MIDM, display the object profile containing the source record you want to deactivate on the Record Details page.
Click Edit EUID.
Below the source record you want to deactivate, click Activate.
Click OK on the information dialog box that appears.
The page refreshes and the SBR for the object profile containing the source record is recalculated based on the new information.
The Duplicate Records function of the MIDM lets you view any object profiles that are marked as potential duplicates of each other by the master person index application. You can search and view potential duplicate profiles on the MIDM, and then fix the potential duplication by either merging or resolving the two profiles. You can view potential duplicates that are resolved, but not those that are merged.
Perform any of the following tasks to monitor and fix potential duplicate profiles.
Potential duplicate profiles are determined based on the matching probability weight that indicates how closely two profiles match. You can find and compare potential duplicate profiles using the MIDM Duplicate Record function.
Obtain information about the object whose potential duplicates you want to view such as, a system in which they are registered, or the login ID of the user who created the object profile.
In the MIDM tabbed headings, click Duplicate Records.
The Duplicate Records basic search page appears.
Perform one of the following:
To search by date range only, enter the date range in the basic search fields, and then click Search.
To search by system only, select the system code from the drop-down list, and then click Search.
This provides all the potential duplicate records that are generated by the selected source system.
To use additional criteria for the search, select Advanced Search from the Search Type field, enter your search criteria, and then click Search.
For more information about advanced search fields, see About Duplicate Records Search Fields on the MIDM.
The Duplicate Records results list appears with key information for each potential duplicate record displayed.
In the results list, compare the displayed information to determine whether you want to view a detailed comparison of the potential duplicate profiles.
You can configure the result list in the tabular format.
To view a detailed comparison for a set of potential duplicate profiles, click Preview to the right of the profiles.
To view the source records associated with any of the displayed profiles, click .
To return to the duplicate record comparison view, again click .
To view a transaction history for a displayed profile, click 
.
To return to the comparison page, again click .
To mark a profile as not duplicate of the main profile, see Resolving Potential Duplicate Profiles on the MIDM.
To merge two or more profiles, see Merging Potential Duplicate Profiles.
To start a new search for potential duplicate records, click Advanced Search at the top of the page.
The fields located on the Duplicate Records search page lets you specify information about the potential duplicate profiles you want to view.
Table 6-1 Duplicate Records Search Fields
| Field Name | Description |
|---|---|
|
EUID |
The enterprise-wide unique identification number of one of the profiles you want to view. |
|
System |
The external system with which the object profile that caused the potential duplicate flag is associated. |
|
Local ID |
The local ID associated with the object profile in the specified system. The name of this field may be different for your implementation. |
|
Create Date From |
The start create date for the profiles you want to view. The query is performed for transactions that are created between the Create Date From (and Create Time From) and the To Create Date (and To Create Time). |
|
To Create Date |
The end create date for the profiles you want to view. |
|
Create Time From |
The start create time for the profiles you want to view (using 24-hour notation). If no time is entered, the default value is 00:01 (12:01 AM). |
|
To Create Time |
The end create time for the profiles you want to view (using 24-hour notation). If no time is entered, the default value is 24:00. |
|
Status |
The potential duplicate status of the profiles you want to view. The values for this field are Unresolved, Resolved, or Permanently Resolved. |
There are two types of merges in master person index, a EUID merge and an Local ID merge.
A EUID merge is performed between two enterprise objects, EUID1 and EUID2. This type of merge is MPI wide, which means that it is directed by knowledge that is only known outside the given hospital or clinic. For example,
Hospital 1 has a patient named John Smith (Local ID 123456) and Hospital 2 has a patient named John Smyth (Local ID 147258). In the MPI database, these records are given EUIDs as follows:
John Smith (Hospital 1; Local ID 123456) is assigned EUID1 0000000128
John Smyth (Hospital 2; Local ID 147258) is assigned EUID2 0000012457
In theory, these hospitals do not know anything about the other patients, and the MPI evaluates them and recommends one of the following:
The patients are two different people as described in this example.
Their demographics are close enough that a human needs to evaluate them (potential duplicate).
The first record is updated with information from the second record as an assumed match. In this example, this is not the case since the records are given different EUIDs.
If a human has decided that these patients are the same person, at the MPI level, a merge of EUID1 may be made into EUID2. This information is broadcast to the two hospitals to know the set of medical records that is common to their patient, but the merge remains with the MPI.
The processing for this merge at the MPI level is:
EUID1 receives a status of Merged.
The system record from EUID1 is transferred to EUID2, leaving EUID1 without a system object
EUID2 (0000012457) now have two active system records:
Local ID 147258
Local ID 123456
A local ID merge can have different origins, but is focused within a single hospital, and has more than one scenario as follows:
Jane Doe checks into the hospital with a Local ID 963852. The information is sent to the MPI and EUID is assigned:
Jane Doe (Local ID 963852) is assigned EUID3/0000065412
After marriage, Jane Doe changes her name to Jane Brown. She checks into the same hospital with the Local ID 333555. The information is sent to the MPI and an EUID is assigned:
Jane Brown (Local ID 333555) is assigned EUID4/0000005623
The hospital discovers that these two Local IDs (963852 and 333555) belong to the same patient. They combine the records into a single file with a single local ID (for example, 333555) and notify the MPI. At the MPI level, a local ID merge is triggered by two Local IDs that are identified by the hospital.
The processing for this merge at the MPI level is as follows:
Local ID 963852 and Local ID 333555 are sent to the MPI and EUID3 and EUID4 are identified.
A Local ID merge is performed.
The Local ID from EUID3 is transferred to EUID4.
EUID3/0000065412 is deactivated.
The Local ID from EUID3 (963852) is deactivated.
EUID4/0000005623 now has two system records:
Local ID 333555 (active)
Local ID 963852 (deactivated)
Note:
The MIDM performs field level selections as to which data remains from the merge. For OHMPI, all data will come from one record.The second scenario is similar, but arises from a different set of inputs.
Paul Black checks into the hospital with a Local ID 444999. The information is sent to the MPI and an EUID is assigned:
Paul Black (Local ID 444999) is assigned EUID5/0000226541
Paul Black checks into the hospital again, with a different Local ID (222777), but is identified with the same MPI EUID5/0000226541. This results in the following EUID5 record:
EUID5/0000226541
Local ID 222777 (active)
Local ID 444999 (active)
The hospital consolidates the two Local IDs (222777 and 444999) that belong to the same patient. They combine the records into a single file with a single Local ID (for example, 222777) and notify the MPI. At the MPI level, this is a straight Local ID merge identified by the hospital.
The processing for this merge at the MPI level follows:
Local ID 444999 and Local ID 222777 are sent to the MPI and EUID5 is identified.
A Local ID merge is performed.
The Local ID 444999 is deactivated.
EUID5 now has two system records:
EUID5/0000226541:
Local ID 222777 (active)
Local ID 444999 (deactivated)
Note:
The MIDM performs field level selections as to which data remains from the merge. For OHMPI, all data comes from one record.When you compare potential duplicate profiles, you may find that the object profiles represent the same entity, or that a source record from one profile belongs to the other profile. You can perform either an object profile merge or a source record merge to correct this. When you merge profiles, the SBR of the surviving profile is automatically recalculated based on the source records involved in the merge. You can combine up to four profiles.
This section only describes object profile merges. For more information about merging object profiles, see Combining Object Information on the MIDM. To learn how to merge source records, see Merging Source Records on the MIDM.
Perform a search for potential duplicates on the Duplicate Records page as described in Finding Potential Duplicate Profiles on the MIDM.
To view a detailed comparison for a set of potential duplicate profiles, click Preview to the right of the profiles.
On the Duplicate Records comparison page, determine which of the displayed profiles you want to keep, and then click the EUID of that profile.
Click the EUIDs of any other associated profile you want to merge into the profile you selected above.
Each profile changes color to indicate it is selected.
Under the far right column, click Preview.
The merge preview profile appears, which lets you view the profile as it appears after the merge.
Compare the field values in the profiles to be merged to determine which values to populate into the kept profile. Click any values you want to keep.
Note:
Selecting a value to keep in the merge result profile creates a link from the SBR to the source record field that populated the field.For example, if the first name field from Record A is populated from Source Record 1, and you merge Record A into Record B, and select the first name value from Record A, a link is created from the first name field in the resulting SBR to the first name field in Source Record 1. For more information on linking SBR fields to source record fields, see Overriding the SBR of the Survivor Calculator.
Review the merge preview profile and click Merge to finalize the merge.
On the confirmation dialog box that appears, click OK.
The surviving profile appears.
Review the surviving object profile to determine whether to merge any source records or deactivate.
When you compare two potential duplicate profiles and determine that they do not represent the same object, you can resolve the two profiles to flag the profiles as not being potential duplicates. There are two types of resolution.
Resolve - Removes a potential duplicate flag, but if one of the resolved profiles is updated, the records might be listed as potential duplicates again.
Resolve Permanently - Flags the two profiles as being permanently resolved regardless of whether one of the resolved profiles is updated.
If the fields on the Duplicate Records search results list are sufficient to determine that two profiles do not represent the same object, you can resolve the profiles from the search results list.
Perform a search for potential duplicates on the Duplicate Records page as described in Finding Potential Duplicate Profiles on the MIDM, and display the results list.
The results list displays key identification fields that provide enough information to determine whether the profiles must be resolved.
Scroll through the results until you see the profiles you want to resolve.
To resolve the duplicate profile from the Main EUID (the profile in the far left column), click 
.
On the confirmation dialog box that appears, perform one of the following:
To flag the potential duplicate profiles as resolved but still allow the potential duplicate listing to be reinstated in the future, select Resolve Until Recalculation.
To flag the potential duplicate profiles as resolved and never allow the potential duplicate listing to be reinstated, click Resolve Permanently.
On the confirmation dialog box, click OK.
The status of the potential duplicate entry is changed to Resolved and the profiles are no longer regarded as potential duplicates of one another.
Repeat this for each duplicate profile you want to resolve from the main profile.
If you resolve a profile in error, click 
in the results list to mark it as a potential duplicate again.
If you want to view detailed information about two profiles to determine whether they are a match, view them on the Duplicate Records comparison screen before you resolve them.
Display a set of potential duplicates on the Duplicate Records comparison page as described in Finding Potential Duplicate Profiles on the MIDM.
To resolve the duplicate profile from the Main EUID (the profile in the far left column), click .
On the confirmation dialog box that appears, perform one of the following:
To flag the potential duplicate profiles as resolved but still allow the potential duplicate listing to be reinstated in the future, select Resolve Until Recalculation.
To flag the potential duplicate profiles as resolved and never allow the potential duplicate listing to be reinstated, click Resolve Permanently.
On the confirmation dialog box, click OK.
The status of the potential duplicate entry is changed to Resolved and the profiles are no longer possible duplicates of one another.
Repeat this for each duplicate profile you want to resolve from the main profile.
If you resolve a profile in error, click in the results list to mark it as a potential duplicate again.
If two profiles are resolved and flagged as not potential duplicates in error, you can undo the resolve transaction, and mark them as potential duplicates. You can perform this from either the results list or the comparison page.
If the fields on the Duplicate Records search results list are sufficient to determine that a resolve transaction is performed in error, you can unresolve the profiles in the search results list.
Perform a search for potential duplicates on the Duplicate Records page as described in Finding Potential Duplicate Profiles on the MIDM, and display the results list.
The results list displays key identification fields that provide enough information to determine whether the profiles must be unresolved.
Scroll through the results until you see the profiles you want to unresolve.
To mark the profile as duplicate with the Main EUID (the profile in the far left column), click .
The status of the potential duplicate entry is changed from Resolved and the profiles are again potential duplicates of one another.
If you want to view detailed information about two profiles to determine whether they must be unresolved, view them on the Duplicate Records comparison screen.
Display a set of potential duplicates on the Duplicate Records comparison page as described in Finding Potential Duplicate Profiles on the MIDM.
To mark the profile as duplicate with the Main EUID (the profile in the far left column), click .
On the confirmation dialog box, click OK.
The status of the potential duplicate entry is changed from Resolved and the profiles are again possible duplicates of one another.
The Assumed Matches function of the MIDM lets you view any object profiles that are automatically updated by the master person index application as a result of an assumed match. You can use MIDM to search for assumed matches originating from the same source system. You can reverse the assumed match, if necessary. The following sections provide instructions for finding profiles updated by an assumed match and then reversing the update if necessary.
Perform the following tasks to work with profiles that are automatically matched.
You can find object profiles that are updated by an assumed match using the Assumed Matches function of the MIDM. When you search for assumed matches, you can select an object profile to view from a results list to determine whether the assumed match is done correctly.
Obtain information about the object profile you want to view such as, their EUID, a system in which they are registered, or the login ID of the user who added the record that caused the update.
In the tabbed headings, select Assumed Matches.
The Assumed Matches search page appears.
Enter the search criteria. For more information, see About Assumed Matches Search Fields.
Click Search.
The Assumed Match Result page appears. For more information, see About Assumed Match Results Fields on the MIDM.
In the Results list, click the EUID of the assumed match profile you want to view.
The Assumed Matches page appears with the assumed match profile displayed.
To view a transaction history of the profile, click .
To view the transaction details, click 
.
To undo the assumed match transaction, follow the instructions provided in Reversing an Assumed Match on the MIDM.
The fields located on the Assumed Matches search page lets you specify information about the assumed match profiles you want to view.
Table 6-2 Assumed Matches Search Fields
| Field Name | Description |
|---|---|
|
EUID |
The enterprise-wide unique identification number of the profile you want to view. |
|
System |
The external system with which the object profile that caused the assumed match is associated. |
|
Local ID |
The local ID associated with the object profile in the specified system. The name of this field might be different for your implementation. |
|
Create Date From |
A start create date for the profiles you want to view. The query is performed for transactions that are created between the Create Date From (and Create Time From) and the To Create Date (and To Create Time). |
|
To Create Date |
The end create date for the profiles you want to view. |
|
Create Time From |
The start create time for the profiles you want to view (using 24-hour notation). If no time is entered, the default value is 00:01 (12:01 AM). |
|
To Create Time |
The end create time for the profiles you want to view (using 24-hour notation). If no time is entered, the default value is 24:00. |
The fields located in the assumed match results list identify an assumed match transaction to display on the Assumed Matches comparison page. The fields described in the following table always appear in the results list, but the list can be configured to include additional fields.
Table 6-3 Assumed Match Results Fields
| Field Name | Description |
|---|---|
|
ID |
The assumed match ID of the transaction that caused the assumed match. |
|
EUID |
The enterprise-wide unique identification number of the object profile that is updated by the assumed match. |
|
Weight |
The matching probability weight between the updated profile and the record that caused the assumed match. |
|
System |
The system with which the record that caused the assumed match is associated. |
|
Local ID |
The local ID in the above system for the record that caused the assumed match. The name of this field may be different for your implementation. |
|
Create User |
The login ID of the user who added the profile that created the assumed match. |
|
Create Date |
The date and time the transaction that caused the assumed match occurred. |
If you find that an assumed match is made in error, you can reverse the assumed match. This process returns the updated object profile to its status before the assumed match update, creates a new object profile for the record that caused the assumed match, and recalculates the SBR for the existing profile.
View the assumed match profile as described in Finding Assumed Matches on the MIDM.
Click Undo Match.
A confirmation dialog box appears, providing the EUID number of the new profile that is created as a result of reversing the match.
On the confirmation dialog box, click OK.
The assumed match is reversed, the updated profile is returned to its state before the assumed match, and a new object profile is created for the source record that caused the assumed match. Any changes that are made after the assumed match but before reversing the assumed match are retained.
On the information dialog box, click OK to view the newly created profile.
When you determine that two or more profiles represent the same object, you can merge the profiles to form one profile that contains the object's most current information. You can also merge source records within one profile or from one profile to another. The resulting profile of a profile level merge is called the Merge Result Record. The SBR for the surviving profile is automatically recalculated based on the source records involved in the merge. In a source record merge, the SBRs for all affected profiles are automatically recalculated based on the resulting source records in each profile.
You can display the object profiles to merge using the Search or the Duplicate Records function. This section describes how to merge records using the Search function. For information about merging records using the Duplicate Records function, see Merging Potential Duplicate Profiles.
You can merge profiles from either the Duplicate Records or the Record Details page. The following sections provide instructions for merging profiles or source records from the Record Details or Source Record page. For information about merging profiles from the Duplicate Records page, see Merging Potential Duplicate Profiles.
When you merge object profiles, all source records associated with the non-surviving object profiles are transferred to the surviving object profile. The non-surviving profiles are given a status of merged and are no longer active. The SBR of the surviving profile is recalculated based on the new source records that are added to the profile due to the merge. After merging profiles, review the source records in the active profile to determine whether any of them must be deactivated or merged.
Note:
Use caution when merging more than two object profiles as the entire merge process cannot be reversed.Perform a search for the object profiles you want to merge using any of the search procedures described in Searching for Object Profiles on the MIDM.
In the results list, select the check boxes to the left of the profiles you want to merge.
You can select from two to four profiles.
Click Compare.
The Comparison page appears.
Determine which of the displayed profiles you want to keep, and then click the EUID of that profile.
Determine which of the displayed profiles you want to merge into the profile you selected, and then click their EUIDs.
Click Preview.
The merge preview profile appears so you can review the results of the merge before finalizing it.
Note:
If you merge more than two profiles, you can only unmerge the last two profiles that are merged (as determined by the master person index application). Before proceeding, make sure that the profiles must be merged.Compare the highlighted field values to determine which to keep in the final profile. Select each value you want to keep in the merge preview profile.
Selecting a value to keep in the merge result profile creates a link from the SBR to the source record field that populated the field. For example, if the first name field from Record A is populated from Source Record 1, and you merge Record A into Record B, and select the first name value from Record A, a link is created from the first name field in the resulting SBR to the first name field in Source Record 1. For more information on linking SBR fields to source record fields, see Overriding the SBR of the Survivor Calculator.
Click Merge.
Click OK on the confirmation dialog box that appears.
Review the surviving profile of the merge to ensure no source records need to be deactivated or merged.
You can merge source records from one object profile to a source record from another object profile, or you can merge source records within one profile, as long as both source records originated from the same system. You can also specify which (if any) information to save from the non-surviving source record. When you merge source records, the non-surviving source record is transferred into the object profile of the surviving source record and is given a status of merged. The SBRs of the surviving profiles are automatically recalculated.
In the tabbed headings, select Source Record.
Click the Merge subtab.
In the Source Record search fields, select the source system for the records.
Enter two local IDs for the source records you want to merge and then click View Records.
The source record comparison page appears.
Determine which source records you want to merge and click their local IDs.
Click View EUID for the record you want to view to examine the profiles of the source records. After viewing a profile, click Back to return to the Source Record page.
Click Keep Local ID#, where # is the heading number of the source record you want to retain after the merge.
The merge preview record appears.
Compare the highlighted fields in the source records to determine which value you want to keep. Click a highlighted value to add it to the merge preview record.
At the bottom of the page, click Merge.
On the confirmation dialog box that appears, click OK.
After you merge two source records, the surviving source record is updated, and the non-surviving source records are transferred to the merge to profile and are marked as merged. The SBRs for the object profiles involved in the merge are recalculated. If a merge from profile no longer has any source records, it is deactivated.
The following sections provide instructions for unmerging profiles and source records.
If object profiles are merged in error, the profiles can easily be separated by unmerging the profiles. When you unmerge object profiles, the information is returned to the original profiles, the source records are returned to their original profiles, and any changes made after the merge are retained. Any source records that are added while the profiles are merged are associated with the profile that was active at the time. After you unmerge object profiles, verify that the source records are distributed correctly in the resulting records.
In the MIDM tabbed headings, click Transactions.
Perform a search for the object profiles to unmerge.
For information about the search fields on this page, see About Transaction History Search Fields on the MIDM.
Select a transaction to unmerge from the search results list.
Note:
This must be an EUID merge transaction.Review the two displayed profiles to verify that they are unmerged.
Note:
If you are unmerging profiles that are merged in a transaction that included three or four profiles, only the last two profiles merged are unmerged. The remaining profiles cannot be unmerged.Click Preview Unmerge.
A preview of the unmerged record appears.
Verify the preview and click Unmerge.
On the confirmation dialog box that appears, click OK.
If two source records are merged in error, the records can be separated by unmerging the two source records. When source records are unmerged, the source record that is inactive is reactivated. If the source record is merged from a different object profile, it is returned to its original profile. The SBR is recalculated for all affected object profiles. Any changes made to the surviving source record following the merge are retained after the unmerge transaction.
Perform a search for the transaction to unmerge.
For information about the search fields on this page, see About Transaction History Search Fields on the MIDM.
Select a transaction to unmerge from the search results list.
Note:
This must be a system object merge transaction.Review the displayed system records and profiles to verify the system records must be unmerged.
Note:
If you are unmerging system records that are merged in a transaction that included three or four records, only the last two system records that are merged are unmerged. The remaining records cannot be unmerged.Click Preview Unmerge.
A preview of the unmerged record appears.
Verify the preview and click Unmerge.
To preview the source records involved in the transaction, click .
On the confirmation dialog box that appears, click OK.
|
 Copyright © 2011, 2015, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
