36C77619R0003-0003011.docx

Toolkit Task Guidelines

Tasks identified above in blue font are not currently active in the Identity Management Toolkit (IdM TK).

Tasks with superscript triangles () were implemented on March 21, 2015 with TK Increment 13 Release 2.

If you work a TK Task Type that is not documented here or does not have enough information to review, work it, and then please add the steps you took to resolve it to this document. Placeholders have been added to the guidelines for each task type.

Tasks with asterisks are to be processed first and in the order designated by their order in the list below. Eventually, the TK will be coded to sort the Tasks based on a predetermined order so that the Tasks designated above with asterisks which have a status of New will be displayed at the top of the list when “List Tasks” is used from the left navigation bar. Until such time, it may be necessary to search for these tasks using their specific type in the search function rather than using the “List Tasks” search unless these have been set up in specific Queues.

· *1239 Potential Catastrophic Edit (PCE) Tasks – These tasks are the most important as they can identify Catastrophic Edits/Merges and are to be worked before any other task.

· *1340 Potential Catastrophic Edit – HC IdM Generated – These tasks are Potential Catastrophic Edits/Merges identified by HC IdM which do not have an open system generated PCE Task.

· *1330 Potential Catastrophic Edit by Non-VistA Site – These tasks are Potential Catastrophic Edits/Merges by Non-VistA sites. After Increment 12 Release 2 was implemented on 9/20/2014, we are probably not receiving any new instances of these since the PCEs from the Department of Defense (DoD) are now being logged as 1360 Tasks.

· *1350 Potential Erroneous Edit – These tasks are Potential Erroneous Edits to non-Patient records and the sending system (i.e., Enrollment System (ES) also known as Enrollment System Redesign (ESR)) can influence Primary View (PV).

· *1360 Potential Source System Erroneous Edit – These tasks are Potential Erroneous Edits to non-Patient records and the sending system (i.e., DoD) cannot influence PV. These were previously logged as 1330 Tasks until 9/20/2014.

· *1310 Potential Mismatch – System – These tasks could identify records which were inappropriately linked and added to the VistA sites Duplicate Record File.

· *1320 Potential Mismatch – HC IdM Generated – These tasks are Potential Mismatches identified by HC IdM which do not have an existing Mismatch Task.

· *1230 Potential Mismatch – These tasks identify records where a correlation from a non-VistA system such as ES, My HealtheVet (MHV), DoD, Veterans Benefits Administration (VBA), etc. has been added to an Integration Control Number (ICN) which has an active entry in the Do Not Link (DNL) file of the Master Veteran Index (MVI) formerly known as the Master Patient Index (MPI).

See the Appendix for summary information on how to process cases involving mismatched records.

Initial Steps for Reviewing/Resolving any Task:

1. After assigning your name to an open Task, the first step is to search for other open Tasks, Requests, Exceptions, Resolution Journal Cases (RJC) or duplicates involving the particular record(s) which do not have a Potential Duplicate Task. If you find any open that are assigned to another team member, reassign the Task to the person actively working with the record(s). The TK will generate an e-mail that can be used to notify them of the assignment.

2. After completion of the first step, continue with the other standard procedures usually undertaken for a data quality issue by reviewing the data on the MVI (i.e., PDAT, EDAT, IAUD, etc.), in the TK (PV, Correlation Compare, Correlation Audits, PV Audit, etc.) and remote data and audits for all correlations. The data should be reviewed for any differences, errors, overwrites, and unusual issues/occurrences.

3. Use resources such as Social Security Administration (SSA), Beneficiary Identification Record Locator Subsystem (BIRLS), etc. to verify as much of the identity information as possible and document the verification along with any other pertinent findings in the Task Notes.

4. There may be instances when a fourth step is needed for determining which course of action to take for the issue being reviewed. In situations where additional information (i.e., clinical data, past or future appointment information, etc.) is needed to assist with the analysis, Compensation and Pension Record Interchange (CAPRI) should be utilized as needed. Search for records in CLEAR only if there is a question about the other verification sources. If not available in other sources, lock identity traits only if the driver’s license is viewable in CLEAR.

5. For some Tasks, it may be necessary to contact the MVI Points of Contact (POCs) at the site(s) for additional information such as confirmation of multiple birth or identity theft occurrences, obtain ID trait verification/documentation, etc. The POC(s) can contact the patients to verify or obtain the needed information. If supporting documentation is received via fax or email from the POC, scan or copy it, and then attach it to the task. HC IdM should not contact the patients directly for information.

If your research of the Task indicates a need for review of the messaging that was received and processed by the MVI or TK, you will need to log a Remedy ticket for the applicable development staff to provide that information. This needs to be done within 5 days of Task creation for the MVI messaging as it is purged after that time. The TK messaging is available for a longer period of time; however, you should log the Remedy ticket as soon as it is determined that messaging review is needed.

If records are marked as DNL via a TK Task, they are added to the DNL file. If it is later determined that a pair of records identified in a DNL file entry should be linked, select the Link Events tab within a task to remove the DNL pair or create a 1370 Manage DNL Entry Task. Previously, when records were added to the DNL file as a result of being set to DNL via a TK Task, the system generated a RJC in the MVI. Since all issues are now being documented in the TK, if you locate any old, unassigned RJCs, assign yourself to the RJC, make a note with a reference to your TK Task stating the RJC is no longer being utilized and resolve the RJC.

All tasks have an OVR Tab which can be used to complete the OVR on any records identified in that task without creating a separate OVR Task. This will add an auto-note to the Task Notes indicating what actions were completed on the OVR Tab.

The records should be reviewed, including remote data and audits, to ensure the expected result has occurred when an action is initiated via a TK Task or MVI Option before proceeding with another Task or Option on the same record. If differences are noted in the data between the MVI and Administrative Data Repository (ADR) on the ADR/MPI PV Compare tab, it will require that you review the data in the MVI before proceeding further.

After completing the initial steps of reviewing a Potential Duplicate Task and the conclusion has been made that records should not be linked or put in the DNL file, the task can be resolved without selecting an action on the Manage Duplicate tab. Make sure notes are pasted including the final PDAT.

There are certain correlations that will not move over to the ADR resulting in differences when the data on the ADR MPI PV Tab is viewed. According to Development, the set of records that we are concerned about are the VAMC system (aka VistA) records, 200ESR, 200N* (NwHIN) and 200MH records. All other records for the most part would be screened from moving to the ADR because they are site associations (references to a relational connection to a VAMC record) and therefore would not have key information needed to establish a record in the ADR data base (these elements are SourceID (i.e. DFN) and at least a last name). An example of these type of records are VIC card, Blind Rehab, HomeTelehealth, Health Data Repository (HDR) and Spinal Cord.

If you see that certain fields did not update after any task is processed that includes syncing of the PV data out to the VistA sites, you will need to look for additional tasks or exceptions that may have been generated as a clue for why the update(s) did not occur. If using the Search Exceptions (SE) option in the Exception Handler of the MVI to look for additional exceptions, be sure to answer YES for it to include those exceptions which are auto-resolved. For example, if the SSN did not update at the site, this may be due to a record at the VistA site already having that same SSN. This will trigger the SSN Field Failure Exception to be generated in the MVI; however, those exceptions are auto-resolved and will only display if you answer YES to include the Postmaster (auto-resolved) exceptions.

All documentation and the final MVI PDAT will be included in the notes of each Task. Click the PDAT button on the Task Notes Tab to preview the current PDAT which can then be saved as a permanent note, eliminating the need to copy/paste the PDAT from the MVI. Notes in the TK automatically include your name and the date as a note header so it is not necessary to include that information when inputting your entries.

All VistA, MHV and ESR correlations must be updated before a Task can be resolved. If the only thing left to complete your Task is for the site to update the name in VistA to show as two middle names, document your contact with the site and resolve the Task.

Check the TK for any new Tasks/Requests and the MVI for any new Exceptions pertaining to the record(s) in your current Task prior to resolving. If any are found, they should be worked before resolving the Task.

For pending local merges, please follow the current process implemented on 6/16/2016 during the Team Call as outlined below:

Open RJC’s, Tasks, and Requests involving local duplicates:

When enterprise duplicate records are resolved, Local Duplicate Requests (6210s) are now being logged in the Sites’ queues and the POCs receive a reminder about them when they log into the TK. After the enterprise duplicates are resolved on the MVI and the PV(s) are updated appropriately via OVR, the Potential Duplicate Tasks can be closed after all the messaging from these actions have updated appropriately in all places. It will no longer be necessary for HC IdM to leave their Potential Duplicate Tasks open with a status of Pending Local Merge or send reminders to the POCs.

Local Duplicates that do NOT require HC IdM Intervention:

1. Inform the requesting site POC that HC IdM does not have the ability to merge local site duplicates. An example blurb to use: These records have been identified as local duplicates at your site. After you have reviewed the local duplicates and determined that both records are the same patient, you can proceed to merge the records without having to contact our team. If you need to verify the SSN, there are a couple of options available to aid in determining the correct SSN. First, you can use the DISPLAY ONLY QUERY option in your MPI/PD PATIENT ADMIN COORDINATOR Menu to view the Primary View on the MVI. Also, whomever has access to the Duplicate Record Merge menu, can see this information if they will view the side-by-side comparison of the records via the VERIFY POTENTIAL DUPLICATES option. Either of these will display if the SSNs are VERIFIED or INVALID on the MVI Primary View. If you are still unable to verify the correct SSN, then log a Request in the TK for our team for review.

1. Create tasks as needed to resolve the duplicates on the MVI.

Local Duplicates that require HC IdM Intervention:

1. Follow the normal work processes as stated in the TK Task Guidelines for working and resolving a 750 Potential Duplicate Task. Note: This includes any Potential Duplicate Requests sent in by HEC.

1. After completion of Step 1, set the Potential Duplicate Request and Pot Dup Task status to Resolved.

Be sure you have completed all necessary steps and documented appropriately before resolving the Task. Once a Task is resolved it cannot be reopened and no further action can be taken on that task.

239 Potential Cat Edit – Migration Description: Update is a potential catastrophic edit. Note: the Correlation was already updated as part of Update Person Correlation.

These tasks were migrated from the MVI where they were reviewed and processed as Potential ID Change Exceptions. Their type is listed as active to allow viewing for historical purposes as all functionality will eventually move from MVI to the TK. However, the individual Task entries have a status of Resolved which prevents any further processing from being done to them in the TK.

500 Deprecating ICN does not exist in ADR Description: The deprecating ICN does not exist in ADR for this attempt to resolve duplicate.

These tasks are not currently active.

510 Surviving ICN does not exist in ADR Description: The surviving ICN does not exist in ADR for this attempt to resolve duplicate.

These tasks are not currently active.

520 Resolve Mismatch request is incomplete Description: Prior (From) or Correct (To) Person ICNs are null in the resolve mismatch message from MPI.

These tasks are not currently active.

530 Prior (From) ICN does not exist Description: The Prior Person (From) ICN does not exist in ADR for this attempt to resolve mismatch.

These tasks are not currently active.

540 Correlation does not exist for Prior (From) ICN Description: The Prior Person (From) ICN correlation does not exist in ADR for the ICN for this attempt to resolve mismatch.

These tasks are not currently active.

550 Correct (To) ICN does not exist Description: The Correct Person (To) ICN does not exist in ADR for this attempt to resolve mismatch.

These tasks are not currently active.

560 Correlation for Correct (To) ICN already exists Description: Correlation for Correct (To) Person ICN already exists.

These tasks are not currently active.

570 Potential duplicate Description: There is a potential duplicate on ADR from NPF add request.

These tasks are not currently active.

580 Potential test patient on attempt to add/update re Permanent ID state Description: Adding/updating a person that has two leading Z for SURNAME and five leading 0 for SSN and there are shared Treating Facilities.

These tasks are not currently active.

590 Five leading 0s for SSN AND there are shared Treating Facilities Description: Adding/updating a person that has five leading 0s for SSN and there are shared treating facilities.

These tasks are not currently active.

600 Two leading Z for SURNAME and SSN does not begin with five 0 Description: Adding/updating a person that has two leading Z for SURNAME and SSN does not begin with five leading 0.

These tasks are not currently active.

610 Resolve Duplicate request is incomplete Description: Deprecating or Surviving ICNs are null in the resolve duplicate message from MPI.

These tasks are not currently active.

620 SURNAME contains Merging Description: Entry with SURNAME containing Merging (the record is in the process of being merged via the Duplicate Record Merge) or Merge (site version of noting FROM record), with an IdState of TEMPORARY when there are Shared Treating Facilities.

These tasks are not currently active.

630 Legacy rules override, setting Id state to PERMANENT Description: Legacy rules override, setting Id state to PERMANENT.

These tasks are not currently active.

640 Two leading Z and shared treatment facilities exist Description: Last Name starts with two leading Z and shared treating facilities exist.

These tasks are not currently active.

650 Add/Update with SURNAME or DOB or GENDER equal to null or DOB has no year Description: Adding or updating a person in ADR and the request has the SURNAME or DOB or GENDER equal to null or DOB has no year.

These tasks are not currently active.

660 Add/Update with imprecise DOB and the SSN is null Description: Adding or updating a person in ADR and the request contains an imprecise DOB and the SSN is null with an IdState of TEMPORARY.

These tasks are not currently active.

670 Three leading "E"s for SURNAME Description: Adding or updating a person in ADR that has three leading "E"s for SURNAME and an IdState of TEMPORARY.

These tasks are not currently active.

680 Updating entry in ADR that is deprecated Description: Adding or updating an entry in ADR that is deprecated from another entry with an IdState of PERMANENT as a result of a mismatch.

These tasks are not currently active.

690 Person data submitted is invalid or incomplete Description: The person data submitted is invalid or incomplete.

These tasks are not currently active.

700 A potential duplicate on ADR from NPF update request has been discovered Description: A potential duplicate on ADR from NPF update request has been discovered These tasks are not currently active.

710 More than 1 exact match is found in ADR, IMDQUSR will return an error Description: More than 1 exact match is found in ADR.

These tasks are not currently active.

720 Person record does not exist in ADR Description: The ICN supplied by the calling application does not exist in ADR. Check MPI to determine if the ICN exists.

These tasks are not currently active.

730 The Source ID (DFN, Station #) supplied by application does not exist in ADR.

Description: A person record does not exist in the ADR for the supplied identifier.

These tasks are not currently active.

740 Multiple active correlations exist Description: Multiple active correlations exist for identifier.

These tasks are not currently active.

750 Potential Duplicate (Subtypes: Add, Add Explicit, Update, HC IdM, Initiate Pot Match, Initiate Match) Description: There is a potential duplicate on ADR from Patient add request.

Potential Duplicate Tasks are logged when the comparison Threshold Score (TS) is not high enough to auto-link the records but falls within the range for a Potential Duplicate. The current auto-linking TS is 13.2 and above and the range to generate the Potential Duplicate Task is 12.0 to 13.1.

Add: These Tasks are created when a new record is added which triggers the algorithm to do a comparison with other records.

Add Explicit (previously identified as 1240): These Tasks are created when a user adds a new record via the Add A Person (AAP) Registration option in ES even though the search results return a match. This action creates duplicates on the MVI which are now an active pair in the DNL file. One ICN will have an ESR Correlation with no VistA site correlation and the other will have an ESR Correlation plus VistA site correlation(s). If the records are verified as duplicates, select the Link Events tab within the task to remove the pair from DNL before proceeding with the link. Once the records are linked by HC IdM, ES will merge the duplicates in their system.

Update (previously identified as 770):

These Tasks are created when the MVI PV of an existing record is updated which triggers the algorithm to do a comparison with other records.

HC IdM Generated (previously identified as 1210):

These Tasks are manually created by HC IdM when multiple records for the same person are identified but an open Potential Duplicate Task does not already exist.

Initiate Match Resolution (previously identified as 1250):

(Information is still being gathered for this group of tasks and will be provided when complete.)

Initiate Potential Match Resolution (previously identified as 1260):

These Tasks were created when the new auto-link TS of 13.2 and above and Potential Duplicate Task range of 12.0 to 13.1 were implemented which triggered the algorithm to do a comparison of all existing records. The comparison TS was not high enough to auto-link but was high enough to be a potential match with one or more records.

· Follow the steps identified at the beginning of this document for all Potential Duplicate Tasks. Upon completion of the initial steps, you should be able to decide about the appropriate action (set one ICN as Permanent and mark the other ICN(s) as Link, Do Not Link or Undetermined) to take for these tasks. When linking records via a Potential Duplicate Task, the traits from the record which was most recently entered by a VistA site should be retained on the permanent ICN. If your review indicates otherwise, seek guidance from a senior team member or SME as this can cause delays in the patient receiving treatment if a recently entered record’s traits are changed. Note: After completing the initial steps and determining that these records should not be linked or put in the DNL file, the task can be resolved without selecting an action in the Manage Duplicate tab. Make sure notes are pasted including the final PDAT.

· Additional tasks should be created as needed to complete the resolution of the potential duplicates.

· As of April 2016, per Danny Reed if anyone contacts you or if there are duplicate DoD correlations and one is shown in TK with an DFN/EDIPI/IEN listed as PI-USVHA (Person Indicator) and the other NI-USDOD (Nation Indicator), a 1270 Unlink Task should be created to unlink the PI-USVHA correlation from the record. After the PI-USVHA correlation has unlinked then a SDM ticket will need to be created for development to delete the PI-USVHA correlation from the ICN. When that is complete, the TK Correlation tab should only have one DoD correlation, the NI-USDOD correlation. If there are two DoD correlations with both being NI-USDOD, those records will be smooshed by DMDC in their system.

· As of April 2016, per Dan Rocha when multiple DoD correlations are on different records but all have the same EDIPI and each DoD hyperlink points to the same ICN, after the ICNs have been linked, create an SDM ticket for the MVI/TK developers. Include all of the ICNs and the EDIPI as well as the TK Task number in the SDM ticket. Development will then manually make some changes to the records. This also applies to records with multiple DoD correlations and DoD has previously merged the records (this is shown when the DoD hyperlinks have the same ICN).

· If you are reviewing a record which has an active 200DOD correlation and there is another 200DOD record identified with a different EDIPI listed as “Other Site Association(s)” under that active 200DOD correlation, according to MVI development it will not cause a problem. Source is mail message from Carol Turner dated 05/06/2016 at 11:39am.

760 Person correlation to be updated does not exist in ADR Description: The correlation does not exist in ADR for the ICN for this attempt to update the correlation in ADR.

These tasks are not currently active.

780 Potential catastrophic edit in ADR (patients) Description: Update is a catastrophic edit. Note: the Correlation was already updated as part of Update Person Correlation.

These tasks are not currently active.

790 Potential erroneous edit in ADR (non-patients) Description: Update is an erroneous edit. Note: The Correlation was already updated as part of Update Person Correlation.

These tasks are not currently active.

810 Active source id not found for surviving ICN Description: Active source id not found for surviving ICN These tasks are not currently active.

820 Surviving/active identifier missing from Merge Command request Description: Surviving/active identifier missing from Merge Command request These tasks are not currently active.

830 Exception attempting to find active/correct correlation in ADR Description: Exception attempting to find active/correct correlation in ADR These tasks are not currently active.

840 Surviving correlation ICN not the same as surviving ICN Description: Surviving correlation ICN not the same as surviving ICN These tasks are not currently active.

850 Exception trying to add/update active/correct correlation in ADR Description: Exception trying to add/update active/correct correlation in ADR These tasks are not currently active.

860 Request incomplete for Merge (prior or correct ICN are null) Description: Request incomplete for Merge (prior or correct ICN are null) These tasks are not currently active.

870 Merge: pid1 and mrg ICNs should be the same, but are not Description: Merge: pid1 and mrg ICNs should be the same, but are not These tasks are not currently active.

880 Surviving correlation ICN not the same as correct ICN Description: Surviving correlation ICN not the same as correct ICN These tasks are not currently active.

999 NON Group Exception Description: NON Group Exception These tasks are not currently active.

1100 Potential Duplicate-Person/Patient Add Description: The person/patient record added from the New Person File has created a potential duplicate on ADR.

These tasks are not currently active.

1110 Potential Duplicate-Person/Patient Update Description: The person/patient record updated from the New Person File has created a potential duplicate on ADR.

These tasks are not currently active.

1120 Potential Duplicate-Patient/Person Add Description: The patient/person record added from the New Person File has created a potential duplicate on ADR.

These tasks are not currently active.

1130 Potential Duplicate-Patient/Person Update Description: The patient/person record updated from the New Person File has created a potential duplicate on ADR.

These tasks are not currently active.

1140 Potential ID Change- Non-patient to Non-patient Description: Potential Identity Change for Non-patient to Non-patient These tasks are not currently active.

1150 Potential ID Change- Non-patient to Patient Description: Potential Identity Change for Non-patient to Patient These tasks are not currently active.

1160 Potential ID Change- Patient to Non-patient Description: Potential Identity Change for Patient to Non-patient These tasks are not currently active.

1200 Request from DoD to Resolve Potential Duplicate Description: A determination to Link or Do Not Link needs to be made about the involved VistA duplicates. Resolve Potential Duplicate and if it is a Do Not Link action contact DoD POC to determine if link was in error.

These tasks are not currently active.

1220 DOD Person ID found (Softmatch), but name or DOB do not match.

Description: DOD Person ID found (Softmatch), but name or DOB do not match. Indicates that name, DOB or both returned in response do not match input.

These tasks are not currently active.

1230 Potential Mismatch Description: User selected a record returned in the search results that is in the DNL File. The User has added a Correlation to this record. Review needed as could be a potential mismatch.

These tasks are generated if a non-VistA correlation such as ESR, MHV, DoD, 200CORP, etc. gets added to an ICN which is associated with an entry in the DNL file. Multiple 1230 tasks may be received for an ICN if more than one of the non-VistA correlations are added to the ICN after the DNL entry. Development has stopped the generation of 1230 Tasks for 200BRLS (VBA BIRLS), 200CORP (VBA CORP), and 742VI (Veterans ID Card System-VHIC). As more is learned about these tasks, we may be able to have Development make additional changes to the current implementation so these tasks are generated more appropriately for our needs.

· Locate the DNLs which are identified on the Link Events Tab and verify the records should remain in the DNL file.

· Review the correlation audits of the non-VistA correlations to determine which one(s) were added just prior to the task being created after the DNL entry was made active.

· If DNL is appropriate and not a true Mismatch:

· Place the following note in the Potential Mismatch Task: This record was placed in DNL on _____. A Potential Mismatch Task was generated when a ______ correlation was added to the record. This is not a true Mismatch. This record will remain in DNL due to (i.e. reason you are keeping records in DNL file). No further action is needed.

· Select “No” for the Task Reason, “Is This a True Mismatch?”

· Paste final PDAT in task (no need to place Authority scores on record). If Authority Scores exist, leave them on the record.

· Resolve

· If DNL is NOT appropriate, a Mismatch has occurred, the newly added correlation is a VistA correlation, or SSN Verification Status is not marked as Verified: Follow normal procedures for processing Potential Mismatches.

· When a MHV Correlation is on one or more of the ICNs involved in a CE, Mismatch, etc. and it triggers an ADT-A43 Move message, MHV automatically deactivates the user(s) account and unlinks the MHV Correlation(s). No action is needed on our side. (Outlook message from Leslie McClure 11/21/2016) See the Appendix for summary information on how to process cases involving mismatched records.

1239 Potential Catastrophic Edit Description: Update is a potential catastrophic edit. Note: the Correlation was already updated as part of Update Person Correlation.

These tasks are generated when “updates” are received for a correlation that contain two or more traits which are different from the traits on the existing correlation on the MVI/TK. Updates is in quotes in the previous sentence because sometimes these updates are not manual edits made by a user from the correlation’s system, but have been found to be as a result of the PV being updated and synced out and the correlation system returns an inappropriate update message rather than an acknowledgement message. An example of this are the PCE Tasks logged for DoD previously because the wrong message type was received from DoD. This issue with DoD has been resolved; however, if this occurrence is noted from other systems, please send an email to the team and log a Remedy ticket for assistance from Development.

· After completing the first step identified at the beginning of this document, click on the Catastrophic Edit tab to determine what ID traits were changed. The Correlation Audit is displayed at the bottom of this tab to allow viewing of the traits that changed.

· Complete step 2 of the initial steps for all tasks to determine if a CE or Cat Merge has occurred. There are several ways for the data to be overwritten in a VistA system. This can happen automatically by the Postmaster via an electronic update from an outside source such as MVI, a manual edit made by an individual at the site, or as a result of a duplicate record merge.

· Note: There is a difference between edits due to erroneous data (i.e., corrections to typos in the fields) versus changes to SSN, name, gender due to legally changing the information so keep that in mind when determining if the updates submitted in a PCE task are corrections or legal changes. This is important in determining the correct action(s) to take in processing the PCE task.

· Complete step 3 of the initial steps for all tasks. Steps 4 and 5 will also be needed for CE/Merge incidents.

· If determined to be a CE/Merge, see the Catastrophic Edit Guidelines (TK Version) on the HC IdM Share Drive for further guidance on resolving the PCE and completing the CE Form in TK.

· If the changes are valid state this in the Task Notes. There are instances where changes to a record are to replace invalid data with valid data. If there is no indication the record belonged to another patient, this would not be considered a CE.

· If determined not to be a CE/Merge, complete the CE task by accepting valid edits and rejecting invalid edits for each field. Lock down the verified traits via OVR as needed. The task can be resolved by notating the information as found in the verification sources and that it does not involve a CE/Merge.

· When the decision is made to retain Patient B’s identity on the overwritten record, which should be rare but does occur due to inpatient status, lots of clinical data, etc., be sure you move or unlink any other correlations that belong to Patient A before you update the PV with Patient B’s traits. Some of the other correlations such as DoD can, in some instances, accept trait updates sent via a MVI PV sync which could result in an erroneous edit by VA to DoD records if the DoD correlation is not unlinked prior to the OVR. Other correlations such as VBA do not currently accept trait updates from MVI sent via a PV sync and this could result in the VBA record being linked to an ICN for a different person after the OVR. Log a SDM ticket for development’s assistance with the moving/unlinking of the VBA correlations. (Outlook message from Carol Turner 10/07/2016)

· When a MHV Correlation is on one or more of the ICNs involved in a CE, Mismatch, etc. and it triggers an ADT-A43 Move message, MHV automatically deactivates the user(s) account and unlinks the MHV Correlation(s). No action is needed on our side. (Outlook message from Leslie McClure 11/21/2016)

The below is from the March 24, 2016 team minutes.

· 200PROV-VA Provisioning System - Potential Catastrophic Edit (Brenda) – Will we continue to receive the PCE Tasks from Provisioning?- (Mike) This is another enumeration activity. They’re enumerating the Paid and PIV database into the MVI. It comes through provisioning and is generating PCE Tasks under certain conditions. There’s a message string where this is being discussed with Danny and T.J. In my ongoing quest to prevent adding more work for the team, I first thought T.J. and his team should clean up the Tasks since they made the mess. At that point, I was mistaken and under the impression that those will only be PIV/PAID efforts and no other correlations will be involved. Since being educated that other correlations are involved, we will need to review the PCE Tasks.

The POCs for ICAM are Thomas J Seaman (T.J.) and Katina Taylor. If we reject the changes, we need to send an email to both POCs and let them know what traits were retained.

Question:

· Can we resolve the Task and then send the POCs an email or do we need to leave the Task open?-

· Just resolve and send an email.

1270 Unlink Correlation Description: A non-VistA correlation needs to have status changed to Unlink.

These tasks are created by HC IdM when they have identified a non-VistA correlation that needs to be unlinked from an ICN and are only available for correlations which are permitted to do the Unlink.

NOTE: The following types of correlations can be Unlinked – 200DOD, 200CH, 200ESR, 200N* (NwHINs), 741 (HAC), 200BOSS, 200AMAS, 200SSA, 200CORP, 200BRLS, 200PROV. It is available for MHV but should not be used for those correlations at this time.

· After completing the initial steps that are needed for this task, you can select Unlink only (if you want to unlink with the possibility of relinking later) or choose Unlink and DNL if you want to unlink the correlation and have an entry added to the DNL file.

1280 Relink Correlation Description: A correlation needs to have status changed from Unlink to Active.

HC IdM can create these tasks to relink a previously unlinked correlation to its original ICN. These are only permitted on those correlations which are allowed to do the Unlink. Currently they should only be used on NwHIN, VBA and DoD correlations. It is also available for MHV but should not be used for those correlations at this time.

· If the previous unlink task also included the DNL, you will need to have the DNL entry inactivated by selecting the Link Events tab within the task to remove the pair from DNL before proceeding with the relink. An error message will be displayed if this step is not taken.

1290 Synchronize Primary View Description: All correlations need to be synchronized to the Primary View.

These tasks are manually created by HC IdM when they have identified differences between the information on the MVI PV and the data at the site(s). If the information on the PV is determined to be the correct data, use the Synchronize PV task to send an update to the sites with the data from the MVI PV.

NOTE: If there are no changes to the Identity Traits, the PV Sync will not be sent to DoD. Do not ask development to update DoD traits.

· After submitting the task, review the correlation(s) remote data and the correlation(s) data in the TK to ensure the information has been updated to match the PV as expected. Updates should be verified in TK by clicking on the ADR/MVI Compare tab. If there is a difference in any of these fields, then the MVI should be reviewed.

· If you see that certain fields did not update after the PV sync task was processed, you will need to look for additional tasks or exceptions that may have been generated as a clue for why the update(s) did not occur. If using the SE option in the Exception Handler of the MVI to look for additional exceptions, be sure to answer YES for it to include those exceptions which are auto-resolved. For example, if the SSN did not update at the site, this may be due to a record at the VistA site already having that same SSN. This will trigger the SSN Field Failure Exception to be generated in the MVI, however, those exceptions are auto-resolved and will only display if you answer YES to include the Postmaster (auto-resolved) exceptions.

1300 Primary View Override Description: Primary View Override of Traits and/or Authority Scores.

These tasks are manually created by HC IdM to correct, update or “lock down” verified data and their applicable Authority Scores (AS) on the MVI PV which will then send an update to the sites with this verified information. Corrections would be for issues like typos which were made by registration staff at the sites. Updates would include instances of trait changes due to marriage, divorce, ID theft, etc. If the traits currently on the PV are correct, they can be “locked down” by assigning an AS within HC IdM range (775-1000) to prevent further overwrites unless HC IdM is contacted. The OVR Task should only be necessary when there is not another open task for the record(s) needing updating since all tasks now have an OVR tab.

· See the document OVR GUIDELINES for specific details about use of OVR such as determining the appropriate AS to assign for each trait based on the source(s) of verification.

· Additional guidance for ID trait entry requirements can be found in the following documents which should be reviewed/consulted as needed: 1) VHA Directive 1906 Data Quality Requirements for Healthcare Identity Management and Master Veteran Index Functions; 2) Identity Management Fact Sheet, Identity Trait Changes, Updated November 2016; 3) Privacy Brief #2, Request for Amendment of Records, July 2015.

· Use the Alias option within the OVR to add, edit or delete any name/SSN alias information known for the person.

(The below information is from a mail message Leslie McClure sent on 11/01/2016.)

VBA (eBenefits/SEP) Requests to Remove Hyphen or Space for DoD Retiree Names – The DoD retiree personnel system does not allow hyphens, spaces, apostrophes or any type of punctuation within the retirees name, so the MVI will need to be modified. The VBA PO will submit a Request stating it involves a DoD retiree personnel system Veteran name issue. They will also attach documentation, from the Veteran, stating they understand/give approval to combine the name. If you receive a Request of this nature, as long as the appropriate Veteran permission document is attached, please make the change as it is causing eBenefits issues.

1310 Potential Mismatch - System Description: The system has identified a correlation that could be a potential mismatch. Review is needed.

If a site sets the status of a pair of records in their Duplicate Record File (#15) as VERIFIED, NOT DUPLICATES, this results in the record pair being added to the DNL file on the MVI and the creation of this task. These entries in the MVI DNL file will be DFN to DFN and contain the name of the site user who set the status of the potential local duplicate records along with the option used.

· HC IdM staff should review the records and determine if you agree with the decision made by the site.

· If you agree with the site’s decision that the records should not be merged, move all existing correlations from the deprecated ICN to a new ICN via actions taken on the Manage Potential Mismatch Tab. Be sure to check the correlations on the other ICN of this pair to ensure that those correlations have not been overwritten and mismatched. If applicable, use OVR on the new ICN to lock down verified data. If determined to be a multiple birth, be sure to set the Multiple Birth Indicator (MBI) to YES on all applicable records.

· If you do not agree with the sites’ determination and feel the records should be merged, contact the site POC and inquire as to why they decided the records should not be merged. If the site then agrees the records warrant another review and possible merging, the site can use the EDIT THE STATUS FIELD OF A DUPLICATE RECORD option to reset the status to Potential Duplicates and complete a further review of the records. When the site uses that option to reset the status, the entry in the DNL file should be inactivated, however, if it does not, select the DNL pair from the Link Events tab within the task to complete this inactivation. Document your findings and proceed with working local duplicates as you normally would.

· Additional tasks such as Potential Duplicate may be needed to resolve the issues.

See the Appendix for summary information on how to process cases involving mismatched records.

1320 Potential Mismatch - HC IdM Generated Description: HC IdM has identified a correlation that needs to be moved.

These tasks are manually created by HC IdM when they identify a correlation that needs to be moved to another ICN. The need to move the correlation may be due to an inappropriate match taking place, an Identity Theft case requiring the imposter’s record be separated from the valid patient’s record, an overwrite occurred which resulted in records from two or more patients being erroneously linked together, etc.

· If you have identified the need to create this task you should have already completed the initial steps identified at the beginning of this document. However, if for some reason you have not completed those, you should do so before proceeding further with this task.

· Additional tasks such as Potential Duplicate may be needed to resolve the issues.

See the Appendix for summary information on how to process cases involving mismatched records.

1330 Potential Catastrophic Edit by Non-VistA Site Description: A non-VistA correlation has triggered a Pot. Cat. Edit because the incoming message was compared to the MVI's correlation traits and 2 or more identity traits were different. This could signify a Potential Cat Edit or Potential Mismatch situation.

It is presumed that the generation of these type Tasks was halted as of 9/20/2014; however, these instructions will remain in place for those which were created prior to that time.

These tasks are from non-VistA sites such as DoD that were changed in June/July 2013 from 1239 tasks due to lack of understanding what actions are necessary and available to resolve them. A majority of the 1330 tasks that were received prior to 11/16/2013, are believed to have been generated after the PV synced out a trait update and instead of DoD sending back an acknowledgement, they were sending an update message as if the edits were done manually in their system. When a PV sync message is sent from the MVI, the correlation trait(s) on the MVI/TK are not updated until the application acknowledgement message is received from the correlation’s system. Because the correlation on the MVI has not yet been updated from the PV sync and the incoming traits are compared to the correlation rather than the PV, it appears to be a CE if two or more of the traits are different.

With the implementation of MPI*1.0*93 on 11/16/2013, the TK should only have 1330 tasks logged for DoD if the incoming edits to the correlation were made in the DoD system. This implementation now identifies updates made in the DoD system as a result of MVI PV update/sync versus edits actually made in the DoD system.

HC IdM is not currently reviewing these tasks received prior to 11/16/2013 as a normal part of our duties. However, if you are working a request or other task and find there is an unresolved 1330 task for the same ICN, assign the task to yourself and complete the usual review, verification and documentation processes for the 1330 task before completing the other tasks/requests.

As noted above, due to some of the earlier PCE tasks being generated erroneously, there may not be any differences between the traits on PV and the traits of the DoD correlation for you to accept or reject.

Note: There is a difference between edits due to erroneous data (i.e., corrections to typos in the fields) versus changes to SSN, name, gender due to legally changing the information so keep that in mind when determining if the updates submitted in a PCE task are corrections or legal changes. This is important in determining the correct action(s) to take in processing the PCE task.

Note: See Potential Duplicate Task 750 section in this document if there are two or more DoD correlations on the record and one has an DFN/EDIPI/IEN listed as PI-USVHA (Person Indicator) and the other NI-USDOD (Nation Indicator).

Per Team Call 7/24/2014, follow the below instructions when the 1330 PCE Task is confirmed by HC IdM as a Cat Edit for a DoD correlation. NOTE: DoD refers to them as Overlays.

· Set the status of the PCE Task (#1330) to CAT EDIT and Submit. Per Danny, the current interactions between MVI and DoD do not include sending a reject message back to DoD like it does when catastrophic edits are rejected on a VistA correlation. Note: Do not request for Development to update DoD traits.

· The implementation of MPI*1.0*93 should have also resolved the issue of trying to set the status of the PCE flag in the 1330 tasks. An error message similar to the following was being received in the TK: An error occurred processing your request: Potential Catastrophic Edit Submitted -1^Unable to begin updating field(s) in correlation for ien # 235656674. Although the error message was received in the TK, per development, the problem was actually on the MVI side after TK sent the status update message. Development had determined the error was received if the DoD Correlation had a POB Country which is why the error was not received for all DoD PCE tasks or any of the VistA PCE tasks. If you receive this error on tasks which are reviewed and processed after 11/16/2013, you will need to log a Remedy ticket for MPI-Austin and ask the Admin Support Specialist to refer so the MVI developers can remove the PCE Flag from the DoD Correlation on the MVI. Be sure to include the full 17 character ICN and if the status should be Cat Edit or Non-Cat Edit. If the issue has not been resolved prior to responding back to the Site POC, be sure to remove the PCE Flag from the DoD Correlation on the PDAT in your response.