36C77619R0003-018.docm

ATTACHMENT 17

MVI Exception Processing

A ALL

206 Could Not Create VTQ 208 Application Error 209 Required Field(s) Missing/Invalid/Incomplete 212 TF Update Failed ****219 Missing ICN 224 Missing/Unable to get Logical Link 225 Have Subscribers 226 Not CMOR

234 MPI EXCEPTION

***235 Synchronization Failure 238 Potential Test Patient Issue *239 Potential Identity Change 240 Temporary/Deactivated ICN in site MERGE pair 241 Potential erroneous assignment of ID State 246 SSN Anomaly 252 SSN or SSN Verification Status Conflict 253 Primary View Issue 254 Application ACK not Received from PSIM 256 PSIM Synchronization Issues **257 Potential Mismatch Found on MPI 258 Potential Match Found not logged in PSIM 260 CHDR Exception 261 Missing Assigning Authority and/or Source ID Type

*Exceptions with asterisks are to be processed first.

The first step to take for any exception is to search for any other new/open exceptions (this includes both MPI and Toolkit [TK]), MPI duplicates that do not have an exception, and Resolution Journal Cases (RJC) that involve the particular record unless otherwise noted in this document. If you find an open case/exception, you can assign the exception to the person actively working the open case. Please send that person an e-mail, notifying them of the assignment.

If you find exceptions in the Exception Handler that do not have an ICN listed you should notify MPI Development via Remedy ticket within 5 days of receipt of the exception. After 5 days the messaging is no longer available and they will not be able to locate the ICN.

Unless you have a RJC or otherwise noted in this document, your verification sources and PDAT(s) are to be added to your exception. Also include the date and your full name in the exception unless otherwise noted in this document.

If you have an open RJC, prior to resolving, check the Exception Handler and TK for any exceptions pertaining to your RJC. If there are exceptions, they are to be worked prior to resolving your RJC.

NOTE: It is not necessary to wait until the HDR correlation moves from the deactivated ICN before resolving cases/exceptions if that is all that is pending. Per information from MPI Development on 8/10/2011, the MPI is no longer communicating with HDR (by design), however there is something in the code that allows the messaging to be built with no mechanism in place to receive an acknowledgment back from HDR. Development does routine cleanups (usually daily) of these which is why it may take a day or two for the correlation to move. The HDR correlations will be removed from the MPI at some point but we do not have a time line for when that will occur. 10/1/12 UPDATE: Development is trying to find a time that they can run the job to remove HDR correlations from the MPI. They have to work around other maintenance and downtimes. After this job completes, if you see an HDR correlation showing on a record, you can use the BC option to remove it.

*239 Potential Identity Change Exceptions – These exceptions are the most important as they can be catastrophic edits/merges and are to be worked before any other exception.

**257 Potential Mismatch Found on MPI – These exceptions are the second most important as they are site duplicates that have been marked as Not Verified Dups by the site and are next in line to be worked after Potential Identity Change Exceptions.

***235 Synchronization Failure – These exceptions will indicate an issue with an institution file. The issue will generate exceptions until the issue is resolved. Assign the exception to yourself, log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

****219 Missing ICN - All exceptions of this type must be reviewed within 5 days of the exception being generated. The HL7 messages which contains the patient ID information referenced in the exception is purged after 5 days. See specific instructions below.

206 - Could Not Create VTQ

EXCEPTION TEXT: DFN = 1234567 Problem with building VTQ was invalid

· Please note, this type is not showing on our listing in the MPI, as they are not common exceptions that we should see.

· Per Chris Chesney, these exceptions indicate that this DFN no longer exists at the site and needs to have the cross reference cleaned up. Her team can contact the site to provide the specifics on how to clean up. Below is listed the instructions sent to S. Texas 9/14/10:

D ^%G Global ^DPT(671378120,0 <confirm doesn't exist Global ^DPT("AICNL",1,671378120 <if there kill the x-ref as long as entry above doesn't exist Global ^DPT("AMPIMIS",671378120 <if there kill the x-ref as long as entry above doesn't exist

· Assign the exception to yourself, log a Remedy ticket (Applications-VistA/MPI Austin/General), instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

208 - Application Error

· Assign the exception to yourself, log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

209 - Required Field(s) Missing/Invalid/Incomplete

· Research the SSN value to determine if HC IdM can resolve - If HC IdM cannot resolve: log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

Note: See the “Currently Auto-Resolved (10/1/12)” section at the end of these guidelines for a list of 209 exceptions which are currently auto-resolved.

210 - Patient DFN Failed

EXCEPTION TEXT: SSN xref does not exist for patient DFN #XXX for SSN XXXXXXXXX. This SSN appears to exist for a different patient.

1. Please note, this type is not showing on our listing in the MPI, as they are not common exceptions that we should see. 6/18/13-Per Chris Chesney a remedy ticket should be logged for these to determine why they were generated and how to process them.

212 - TF Update Failed EXCEPTION TEXT: Update of XXX Failed at XXX due to ICN NOT IN DATABASE

· The problem is that the record was sent to the MPI and assigned a national ICN but the national ICN never made it back to the site (site still has a local ICN).

· Run an EDAT to obtain the DFN at the site.

· Then run an RDAT/DDAT via the DFN and see what the ICN is at the site.

· If site has a national ICN, no action necessary. Timing issue.

· If site has a local ICN, use the “UPD –Update Remote ICN option to get the data updated so both the site and the MPI have a national ICN.

· Use the CHK option to make sure the messaging has processed and if so, run an RDAT/DDAT to make sure the data at the site matches the data on the MPI (has same ICN, CMOR, TF list, etc.).

· If you receive the error: “Invalid DFN/ICN passed into RPC” when attempting to run an RDAT/DDAT and RAUD/DAUD on the Primary View’s Permanent or Temporary ICN and DFN, this is likely a stub record that was deleted in the local VistA system after a national ICN was assigned. Check to see if there was another record created for the patient at that facility around the same time.

· Use the RE option on the stub record’s ICN. If this does not deactivate the stub ICN and remove the TF correlation, log a Remedy ticket for MPI Development to resolve the issue.

EXAMPLE RESOLUTION-

The RDAT/DDAT shows the national ICN that matches the EDAT. This is apparently a timing issue. Exception marked as processed with no action necessary.

EXAMPLE RESOLUTION-

This ICN has been deactivated. Permanent ICN is 100XXXXXXX. The RDAT/DDAT shows the national ICN that matches the EDAT for 100XXXXXXX. Exception marked as processed with no action necessary.

EXAMPLE RESOLUTION-

Attempted to run RDAT/DDAT and RAUD/DAUD on the ICN and DFN. Received error: “Invalid ICN/DFN passed into RPC.” Primary View ICN and DFN do not exist at the site. The valid record for this patient is under ICN 100XXXXXXX. Used the RE option to deactivate stub record ICN 100XXXXXXX. I verified all updates completed in TK & MPI and no TFs remain.

EXCEPTION TEXT: Edit of XXX Failed at XXX due to The record is currently locked

· What appears to be happening is the record is locked when the HL7 message is received and cannot be edited in the site database.

· Run the EDAT and if necessary, the RDAT/DDAT to check the TF list at the site that reported the issue and see if all is in sync. If it isn't use the BC option to retrigger the TF broadcast message.

EXAMPLE RESOLUTION-

Verified via the EDAT and RDAT/DDAT that all data is in sync and TFs are listed. Exception marked as processed with no action necessary.

EXAMPLE RESOLUTION-

TFs not in sync so used [option name] to update list.

EXCEPTION TEXT: Can’t find TF Correlation does not exist.

1. A message was sent to the MPI and the record no longer had the TF listed due to a previous merge.

1. Run EDAT and review for discrepancies in the key fields as well as the Inactive Status and Inactivation Date. The DFN above the Inactivation Date is the DFN that has been deactivated.

1. Run an RDAT/DDAT via the DFN and verify there are no longer any TFs listed and the record is deactivated. Verify that the site involved has a Permanent ICN/DFN.

EXAMPLE RESOLUTION-

This ICN has been deactivated via local exception processing. All site data is in synch with the MPI. Exception marked as processed with no action necessary.

EXCEPTION TEXT: Treating Facility Add failed for DFN: XXXXX, Treating Facility: XXXXX

1. After review of the ICN’s, the findings should show that there was previously a site duplicate. There should be a PERMANENT and DEACTIVATED ICN on the MPI. The ICN listed in the exception is the Primary ICN.

1. Review of the PDAT/EDAT/DDAT shows 200PS - AUSTIN PSIM listed as a correlation on the PDAT and EDAT; however, the DDAT does not list 200PS - AUSTIN PSIM as a correlation.

1. Use the BC option to broadcast an update.

EXAMPLE RESOLUTION-

DDAT did not show 200PS - AUSTIN PSIM as a correlation for this ICN. Used the BC option to update the site correlations on the DDAT. All site data is in synch with the MPI. Exception marked as processed.

EXCEPTION TEXT: Add of 200 Failed at XXX DUE TO File #391.91 does not contain a field .08

1. Per Chris Chesney, 10/16/12, 391.91 is the VistA TREATING FACILITY file and Field .08 is the ROI SIGNED INDICATOR field which was introduced with Patch DG*5.3*837. Most likely, something occurred during the patch installation which prompted the exception. If the HC IdM Team receives a similar exception in the future, log a Remedy ticket for assistance so that Development can look at it to ensure that the site does not have a Data Dictionary file issue.

219 - Missing ICN All exceptions of this type must be reviewed within 5 days of the exception being generated. The HL7 messages which contains the patient ID information referenced in the exception is purged after 5 days:

Scroll through the entire list daily checking for any exceptions with No ICN that is unassigned to another team member. If found:

1. Review exception.

1. Look for either the patient name, SSN or DFN of the record at the reporting site in the exception text.

1. If not applicable look for a note that has been added to the exception that provides the DFN for the record at the reporting site.

1. If you are unable to determine the patient record that the exception pertains to by any of the above means, log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Provide the exception tracking number and request DFN be added to the note section of the exception.

221 - Missing Site/CMOR

EXCEPTION TEXT: Unable to update CMOR to for DFN=333333

1. Please note, this type is not showing on our listing in the MPI, as they are not common exceptions that we should see. 11/6/12-Development will track those submitted to them via Remedy tickets to determine if coding changes are required to cease these exceptions from coming in to our Exception Handler.

1. Assign the exception to yourself

· Verify is this DFN is active or inactive at the site. You may check, using DFN, via CAPRI or via RDAT/DDAT.

· (info added 2/14/13-Chris C.) If you find the record is a deactivated FROM record of a local merge, resolve the exception stating “Timing Issue”.

· If the record is not a deactivated FROM record of a local merge, log a Remedy ticket. Enter “Exception 221-Missing Site/CMOR” into summary, and ask support to refer the ticket to DEV-MPI so they may triage and track these exceptions.

· Follow the Remedy ticket to resolution.

· Resolve the Exception at the time Development provides their answer/action with the information included in the Exception notes.

· Remedy ticket 858610 was logged for receiving these exceptions from AUSTIN INFORMATION TECH. Per Chris C, there is nothing HC IdM can do with these so she will be resolving them.

224 - Missing/Unable to get Logical Link

· See auto-resolved listing at the end of this Guideline

225- Have Subscribers

· Assign the exception to yourself, log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

226 - Not CMOR

· Assign the exception to yourself, log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

234 – MPI

All exceptions from TELEHEALTH HEALTH HERO, TELEHEALTH VITERION, and TELEHEALTH VITEL NET:

· The ICNs listed in these exceptions are currently deactivated or were involved in a merge or link with another ICN on the MPI immediately prior to the exception being generated. Remedy ticket #458676 was logged. DEV-MPI and George Blankenship, Telehealth POC, could not find a problem with the Telehealth records.

· Review the PDAT/EDAT/DDAT for the deactivated and retained records. If the Telehealth correlation is now listed under the Prime ICN and all data appears to be correct, you can mark the exception as processed.

· Per Chris Chesney (8/16/12): The Telehealth Heath Hero correlations do not always have data due to the nature of the site association. There is no need for the data as it would just match the site that it was created from. No further action is required.

· Per Danny on the Exceptions Migration call 12/3/12, all issues with Home Telehealth records should be directed to George Blankenship.

EXAMPLE RESOLUTION-

ICN XXXXXXXXX was linked to ICN XXXXXXXXXX. Verified via the EDAT and RDAT/DDAT that the Telehealth correlation is listed under the Prime ICN and all data is correct. This is apparently a timing issue.

EXCEPTION TEXT: Primary View Initialized and different ICN returned from site than queried – Query ICN=XXXXXXXXXX

· These exceptions will indicate that after a query of a particular ICN was done a different ICN was returned. After review of the ICN’s the findings should show that the ICNs were previously duplicates on the MPI.

· Review both ICNs listed via PDAT/EDAT. There should be a PERMANENT and DEACTIVATED ICN on the MPI.

· Review RDAT/DDAT to ensure that each site has the appropriate number of TFs.

· Review RAUD/DAUD to verify data belongs to appropriate person.

EXAMPLE RESOLUTION-

This ICN has been deactivated. All site data is in synch with the MPI. Exception marked as processed with no action necessary.

EXCEPTION TEXT: Unable to update ICN XXXXXXXXXX with ID STA#XXXXXXXVXXXXXX and Type USVHA because ICN XXXXXXXXXX already has this ID, type and location for ICN XXXXXXXXXXVXXXXXX.

· After review of the ICNs, the findings should show that the ICNs were previously duplicates on the MPI. Research will show that the ICNs were linked, deactivating one of the ICNs listed in the exception text.

· Review both ICNs listed via PDAT/EDAT. There should be a PERMANENT and DEACTIVATED ICN on the MPI.

· Review RDAT/DDAT to ensure that each site has the appropriate number of TFs.

EXAMPLE RESOLUTION-

This ICN has been deactivated via [option name]. All site data is in synch with the MVI. Exception marked as processed with no action necessary.

EXCEPTION TEXT: Unable to update OTHER ID XXXXXXXXXXVXXXXXX for ICN XXXXXXXXXXVXXXXXX due to Unable to update ICN XXXXXXXXXXVXXXXXX with ID XXXXXXXXXXVXXXXXXX and Type USVHA because ICN XXXXXXXXX already has this ID, type and location

· Run ICNs using EDAT to see if specified site has site duplicates.

· If one ICN is not deactivated, check TK for exception and if one exists, link so that records are added to site’s File #15 for merge. Note, you will need to log a RJC.

· If one ICN is already deactivated, you will also need to check TK for an exception. If an exception exists, log an RJC.

EXAMPLE RESOLUTION-

Site has duplicate records and ICN XXXXXXXXXVXXXXXX has been added to site’s File #15 for merge and there is not a TK exception.

EXAMPLE RESOLUTION-

Site has duplicate records and ICN XXXXXXXXXVXXXXXX has been added to site’s File #15 for merge and the TK exception #XXXXXX has been resolved. See RJC #XXXX-XXXXX.

EXCEPTION TEXT: The new record ‘+9,644007,’for file #2.01 lacks a .01 field This indicates there are a number of values (9 in this case) trying to update in VistA. Confirm that all alias names made it to the site’s VistA and Primary View. If so, mark the exception as processed. If they didn’t all make it, use the SYNCH option to synch all PV alias names to the correlations.

EXAMPLE RESOLUTION-

The text indicates there were 9 values that it was trying to update in VistA. Confirm that all 9 made it to VistA [site name] and show on the Primary View. Used the TK OVR to "clean up" any repeated alias names.

EXCEPTION TEXT: A31 had different ICN than current ICN for this correlation. Please checkout.

This means the ICN has changed, probably due to linking to another ICN.

· Verify the data matches between the site, the MPI and the TK. If not, correct any discrepancies.

EXAMPLE RESOLUTION-

Verified all data matches. Exception marked as processed with no action necessary.

EXAMPLE RESOLUTION-Verified data does not match and used [option name] to update record.

EXCEPTION TEXT: Task not complete, record not added to DUPLICATE RECORD file while trying to add DFN1 XXXXXX & DFN2 XXXXXX to file 15 at site XXX These exceptions may indicate that linking didn’t add the records to the site’s File 15.

· Run RDAT/DDAT using DNF(s) to see if one record has been deactivated. You can also run RAUD/DAUD using deactivated DFN to see if you can acquire the ICN to pull up the EDAT to see if merge is pending or has already taken place.

· If one of the DFNs has not been deactivated, create OVR task to update data on one of the records to try and trigger an auto-link and/or look in Toolkit to see if there is an exception (will need to open an RJC if working a TK exception). If these actions do not work, you will need to open an RJC and have the site manually add the records into File #15. Make a note of the RJC # in your exception then resolve.

· Note, if this type of exception involves any 200 Correlations, it should be auto-resolved. If any are received for 200 Correlations, Assign the exception to yourself, log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

EXAMPLE RESOLUTION-

Created and resolved OVR task to deactivate ICN XXXXXXXXXX, DFN XXXXXX. Records should now be in [site’s name] File #15 for merge.

EXAMPLE RESOLUTION-

Resolved TK exception which deactivated ICN XXXXXXXXX, DFN XXXXXX. Records should now be in [site’s name] File #15 for merge.

EXCEPTION TEXT: ICN NOT IN DATABASE ICN#XXXXXXXXXXVXXXXXX

· Run RDAT/DDAT and RAUD/DAUD. Compare with information on MPI via EDAT. This may show there was a messaging issue in the past and now there is an ICN that has a non-VistA instance (i.e., Austin 200-AITC) as the only correlation. It may be necessary to log a Remedy ticket and have development move the correlation to the permanent ICN.

EXAMPLE RESOLUTION-

Verified ICN is correct on all records. Exception marked as processed with no action necessary.

EXAMPLE RESOLUTION-

ICN was not correct on all records so used [option name] to move correlation and deactivate ICN XXXXXXXX.

EXAMPLE RESOLUTION-

ICN was not correct on all records and was unable to update using the CSYN/PLIN option(s). Remedy ticket #XXXXXX was logged and the issue has been resolved.

EXCEPTION TEXT: The entry does not exist.

· This appears to be an issue with the TF not being added to the record.

· Run the EDAT and RDAT/DDAT to see if the TF is listed.

· If the facility is not listed use the BC option to update list.

EXAMPLE RESOLUTION-

Verified all TFs are listed. Exception marked as processed with no action necessary.

EXAMPLE RESOLUTION-

Used [option name] to update the TF list.

EXCEPTION TEXT: Pseudo SSN Reason field failure

· At some point there was a pseudo SSN and pseudo SSN reason; however, when the record was updated with the correct SSN, the pseudo reason remained.

· Run the EDAT, RDAT/DDAT , and RAUD/DAUD to see if this is indeed a pseudo SSN issue.

· Use the OVR option to remove the pseudo SSN reason.

EXAMPLE RESOLUTION-

Verified the pseudo SSN reason was not on the record.

EXAMPLE RESOLUTION-

Used [option name] to remove the pseudo SSN reason.

EXCEPTION TEXT: Alert: Merged the following ICNs : [XXXXXXXXXXVXXX

· A TF is alerting that a merge took place.

· Run the EDAT of the ICN shown to verify the merge took place and no TFs are listed.

· Run the Primary ICN’s EDAT, RDAT/DDAT, and if applicable the RAUD/DAUD to verify the facility is on the TFs list.

EXAMPLE RESOLUTION-

Verified merge and that the facility is located on the retained records TFs list. Exception marked as processed with no action necessary.

EXAMPLE RESOLUTION-

Used [option name] to update the TFs list.

EXAMPLE RESOLUTION-

TF still remained on the deactivated ICN. Remedy ticket #XXXXXX was logged and TF has been removed and retained record has all TF listed.

EXCEPTION TEXT: No patient DFN.

· This may be due to a past record mismatch.

· Check for exceptions to find the Veterans involved.

· Run RAUD/DAUD to verify records were mismatched at some point.

· Verify data is correct on both records.

EXAMPLE RESOLUTION-

Verified this was a past record mismatch and both records are currently correct. See RJC # XXXX-XXXXX.

EXCEPTION TEXT: Unable to link record XXXXXX at SITE=XXX on MPI due to unknown SourceID on MPI

· This may be due to resolution of a duplicate or merge.

· Run the EDAT of the ICN shown to verify the duplicate or merge took place and no TFs are listed.

· If there is still a TF listed, try using the MPI options to remove the facility. If they facility does not remove, log a Remedy ticket for assistance.

· If no TFs are listed, run the Primary ICN’s EDAT, RDAT/DDAT, and if applicable the RAUD/DAUD to verify the facility is on the TFs list.

EXAMPLE RESOLUTION-

This ICN has been deactivated via [option name]. All site data is in synch with the MPI. Exception marked as processed with no action necessary.

EXAMPLE RESOLUTION-

TF still remained on the deactivated ICN. Remedy ticket #XXXXXX was logged and TF has been removed and retained record has all TF listed.

EXCEPTION TEXT: Missing Required Fields to delete OTHER ID: ID= TYPE= USVHA LOC= 562 for ICN XXXXXXXXXXVXXXXXX

· This may be due to resolution of a duplicate or merge.

· Research should show that the ICNs were linked, deactivating the ICN listed in the exception.

· Review both ICNs listed via PDAT/EDAT. There should be a PERMANENT and DEACTIVATED ICN on the MPI.

· Review RDAT/DDAT to ensure that each site has the appropriate number of TFs and required key fields are correct.

EXAMPLE RESOLUTION-

This ICN has been deactivated via [option name]. All site data is in synch with the MPI. Exception marked as processed with no action necessary.

EXCEPTION TEXT: Unable to Update record to 985.5 for SourceID/SourceSystem XXXXX/XXX due to Unable to update fields(s) in correlation for ien # XXXXXX

· This appears to be a timing issue as record appears correct. Note, this is an older exception, so if any newer exceptions are found issue may require additional steps.

EXAMPLE RESOLUTION-

Timing issue as record appears correct. Exception marked as processed with no action necessary.

EXCEPTION TEXT: First or Second IEN input parameter invalid while trying to add DFN1 XXXXXX & DFN2 XXXXXX to file 15 at site XXX

· This appears to be local site duplicates on the MPI; however, when sent to File 15, one of the DFNs did not exist locally due to being a stub record.

· Verify one record is stub by using the DFN to try and access the RDAT/DDAT and RAUD/DAUD. If it is a stub, you will receive a -1^Invalid DFN passed into RPC error.

· Review records both records using the ICN to verify they have auto-linked. One ICN should be deactivated and show no TFs.

· Note, TK should not have two same site Active correlations on the Permanent ICN. If TK does have two same site Active correlations, per Chris Chesney log a Remedy ticket for MPI support first.

EXAMPLE RESOLUTION-

Verified stub record, ICN XXXXXXXXXX, DFN XXXXX has auto-linked to Primary ICN XXXXXXXXXX, DFN XXXXX. Remedy ticket # was logged to deactivate DFN XXXXX on TK.

EXCEPTION TEXT: DFN XXXXX does not exist

· The DFN is a stub record and has been auto-linked.

· Verify record is a stub by using the DFN to try and access the RDAT/DDAT and RAUD/DAUD. If it is a stub, you will receive a -1^Invalid DFN passed into RPC error.

· Stub record ICN should be deactivated and show no TFs.

· Note: TK should not have two same site Active correlations on the Permanent ICN. If TK does have two same site Active correlations, per Chris Chesney log a Remedy ticket for MPI support first.

EXAMPLE RESOLUTION-

Verified stub record, ICN XXXXXXXXXX, DFN XXXXX has auto-linked to Primary ICN XXXXXXXXXX, DFN XXXXX. Remedy ticket # was logged to deactivate DFN XXXXX on TK.

EXCEPTION TEXT: Unable to add station # 200HD due to No correlation created for ICN #XXXXXXXXXXVXXXXXX (local ICN) at Station 200HD in MPI FACILITY ASSOCIATION (#985.5) file

1. This appears to be an issue with Station 200HD - HDR not being added to the record.

1. Run Test RDAT/DDAT using the Local ICN as shown on the exception (the National ICN and SSN are not shown). The National ICN and SSN should be shown on the Test DDAT.

1. Use the National ICN to run the EDAT and RDAT/DDAT to see if Station 200HD - HDR is listed.

1. If the identifying fields are not locked, verify the information and use the OVR option.

1. If the facility is not listed use the BC option to update list.

EXAMPLE RESOLUTION-

Verified Station 200HD - HDR is listed. Exception marked as processed with no action necessary.

EXAMPLE RESOLUTION-

Used [option name] to update the TF list.

EXCEPTION TEXT: Correlation NOT FOUND: gov.va.med.person.idmgmt.QualifiedIdentifierImpl@XXXXXXX

· Exceptions from Austin PSIM involving 200NKP-NHIN EXC KAISER PERMANENTE: These exceptions were likely generated due to NHIN changing the Oracle ID (OID) Assigning Authority and creating a new record. If an active NHIN correlation is present on the MPI and TK, no action is necessary.

EXAMPLE RESOLUTION-

The exception was generated due to NHIN changing the Oracle ID Assigning Authority and creating a new record. There is an active NHIN correlation on the MPI and TK. No action necessary.

EXCEPTION TEXT: Unable to add record to MPI ASSIGNING AUTHORITY file 985.55 at MPI. SOURCEID: NI . Invalid input parameter. Assigning Authority value missing.

· Assign the exception to yourself, log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes

EXCEPTION TEXT: Can't get lock on MPI Veteran/Client file for ICN XXXXXXXXX

· Log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

EXCEPTION TEXT: Can't get lock on MPI Veteran/Client file for ICN XXXXXXXXX however the record is NOT a previous duplicate.

· Log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

EXCEPTION TEXT: Unable to add record to VAFC ASSIGNING AUTHORITY file 391.92 at VistA.

SOURCEID: NI . Bad Handle SOURCEID: NI . Invalid input parameter. Invalid SOURCEID value passed in.

· Assign the exception to yourself, log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

EXCEPTION TEXT: StationId PROHIBITED for UNLINK function Per Chris Chesney (3-16-11): This indicates that a station has attempted to be unlinked and unlink isn't an allowable action. Only Austin MHV and NHIN can unlink.

· Exceptions from Austin PSIM involving a 200MH-AUSTIN MHV unlink: A MHV correlation is displayed in the Unlink History on the MPI PV, but is still displayed as Active in the Toolkit. PSIM Development had to correct the parameter to allow MHV correlations to unlink in Toolkit. In order to do this, the Unlink option had to be activated in the Toolkit. However, HC IdM staff should NOT use this option on these correlations! The Increment 6, February 2012, release will stop these exceptions and the MHV correlation will show as unlinked in the TK and the MPI. No action is necessary at this time.

· Exceptions from Austin PSIM involving a 200NKP-NHIN EXC KAISER PERMANENTE unlink:

· If the record displays both an active and unlinked 200NKP correlation in the TK and the active 200NKP correlation is correctly listed on the MPI, the exception was likely generated due to NHIN changing the Oracle ID (OID) Assigning Authority and creating a new record. No action necessary at this time.

· If the record displays two 200NKP correlations in the TK with the status of unlinked but the EDAT still shows one as an active correlation, then log a Remedy ticket. There is a cross reference issue which caused the correlation to remain on the ICN.

EXAMPLE RESOLUTION-

Remedy ticket #xxxxxx was logged due to having two unlinked correlations for 200NKP in TK but an active one on the EDAT remained. The active correlation has been removed from the EDAT and the PDAT and EDAT now reflects the unlink history.

The exception was generated due to NHIN changing the OID Assigning Authority and creating a new record. No action necessary.

EXCEPTION TEXT: java.langNullPointerException

· Review EDAT, RDAT/DDAT, RAUD/DAUD and TK to check for any discrepancies. Compare MPI Primary View with TK to ensure they match.

· If after review no discrepancies are found, no further action is necessary

· If after review discrepancies are found, the CSYN and/or PLIN option may be used to sync TK with MPI Primary View.

EXAMPLE RESOLUTION-

Per Danny Reed (06-26-12): The java.lang.NullPointerException is an indicator that something went wrong between the two MVI systems (MPI and PSIM). MPI stored the data and transaction and sent it to PSIM to store for TK viewing; however, something was missing to prevent the storing for viewing that record in TK.

After review of the EDAT, RDAT/DDAT, RAUD/DAUD and TK, I have verified that there are no discrepancies and TK matches MPI Primary View. No further action necessary.

EXAMPLE RESOLUTION-

Per Danny Reed (06-26-12): The java.lang.NullPointerException is an indicator that something went wrong between the two MVI systems (MPI and PSIM). MPI stored the data and transaction and sent it to PSIM to store for TK viewing; however, something was missing to prevent the storing for viewing that record in TK.

After review of the EDAT, RDAT/DDAT, RAUD/DAUD and TK, I have verified that there are discrepancies. TK does not match MPI Primary View. The CSYN and/or PLIN option (was or were) used to sync TK with MPI Primary View. This exception has been marked as resolved.

Site Rec'd From: SURGERY QUALITY WORKFLOW MGMT (SQWM) EXCEPTION TEXT: AE due to 0 timeouts, AE due to 1 timeouts, AE from fanout 000, AE from fanout 001

A Remedy ticket will need to be logged for MVI Development to auto-resolve any Exceptions received from (SQWM). Please review these records carefully prior to logging the Remedy Ticket to insure no Catastrophic Edits have occurred.

235 - Synchronization Failure

· These exceptions will indicate an issue with an institution file. The issue will continue to generate exceptions until the issue is resolved. Log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

238 - Potential Test Patient Issue

· Log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

239 - Potential Identity Change EXCEPTION TEXT: X identity traits modified. File 985.5 has been updated, No further broadcasting will occur.

· Review the exception and auto-notes found in the Add/Edit Notes to determine what id traits where changed.

· Review EDAT and RDAT/DDAT of all record correlations to see if there are data discrepancies.

· Run an RAUD/DAUD for all record correlations to review all the data that was changed/overwritten and to see if this is a Catastrophic Edit (CE)/Merge. There are several ways for the data to be overwritten. This can happen automatically by the Postmaster, by an individual at the site, or as a result of a duplicate record merge.

· Verify patient demographic data via BIRLS, VIS, SHARE, CAPRI, etc. This information will need to be notated in the exception if it is verified not a CE/Merge

· If changes are valid also state this in the exception notes. **Please note** 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 and/or if the previous data cannot be verified by our resources, this would not be considered a CE.

· If determined to be a CE/Merge, see the Catastrophic Edit Guidelines on the HC IdM Share Drive for further guidance. Note, the exception can be resolved once you have opened a RJC and made the notation that this is a CE/Merge and to see RJC XXXX-XXXXX. Complete the Potential Cat Review (PC) accepting valid edits and rejecting invalid edits for each field.

· If determined not to be a CE/Merge, the exception can be resolved by notating the information as found in the verification sources and that it does not involve a CE/Merge. Complete the Potential Cat Review (PC) accepting valid edits and rejecting invalid edits for each field.

· Make sure you document everything you do in the exception notes and/or the RJC notes.

240 - Temporary/Deactivated ICN in site MERGE pair

· Log a Remedy ticket, instructing the SUP Admin 2 team to release the ticket to development. Mark the exception resolved referencing the Remedy # in the notes.

241 - Potential erroneous assignment of ID State EXCEPTION TEXT: ICN has been deactivated, BUT update message received from site

· These exceptions may indicate that the ICN was previously on a site duplicate which was linked using the record merge, deactivating the ICN listed.

· Review ICN listed via EDAT. There should be a PERMANENT and DEACTIVATED ICN.

MPI and Toolkit ID States differ:

· Record shows a permanent status on the MPI but Toolkit ADR is deactivated.

· Run EDAT to check the ID State and verify there are no duplicates.

· View the Primary View tab and the ADR MPI PV Compare tab to verify if the ID State matches the MPI.

· If the ID State matches, no action is necessary as it was a timing issue.

· If the ID States do not match, log a Remedy ticket for assistance in updating the erroneous ID State.

EXAMPLE RESOLUTION-

This ICN has been deactivated. Permanent ICN is 100XXXXXXX. Verified Toolkit and MPI ID States are the same. No action necessary.

EXAMPLE RESOLUTION-

MPI and Toolkit ID States differ. Logged Remedy Ticket #XXXXX for resolution.

ID State is deactivated with no treating facilities listed; however, record is viewable at the site:

· The record’s ID State is deactivated on the MPI but you are able to run and view the RDAT/DDAT and RAUD/DAUD.

· Run EDAT to check the ID State and to verify there are no duplicates.

· Run RDAT/DDAT and RAUD/DAUD using the ICN and site name, from exception, to see if they are viewable.

· If record is not viewable, no action necessary.

· If record is viewable and appears to be active at the site level, log a Remedy ticket for assistance in why the record is deactivated on the MPI but active at the site.

EXAMPLE RESOLUTION-

ID State is deactivated and record is not viewable via RDAT/DDAT and RAUD/DAUD. No action necessary.

EXAMPLE RESOLUTION-

ID State is deactivated; however, RDAT/DDAT and RAUD/DAUD are viewable. Logged Remedy ticket #XXXXX for resolution.

EXCEPTION TEXT: Can't change ID state from Permanent to Temporary

· These exceptions appear to be generated when a site attempts to update a record that has a Permanent status and the incoming data attempts to change it to Temporary.

· Verify the ID Status matches on the MPI, Toolkit, and at the site.

· Verify the Primary View demographic data using our verification sources.

· If the Primary View data is correct, lock down all verified data and resolve the exception.

· If the Primary View data is incorrect, update and lock down the data accordingly and resolve the exception.

EXAMPLE RESOLUTION - Primary View data was [correct or incorrect]. Data has been locked down and the reevaluated ID State is [permanent or temporary]. No further action is necessary.

EXAMPLE RESOLUTION - The MPI, Toolkit, and/or Site ID States differ. Logged Remedy Ticket #XXXXX for resolution.

Note: Once you have locked down the data, the MPI re-evaluates the record status and updates the ID State according to the MPI business rules.

246 - SSN Anomaly

252 - SSN or SSN Verification Status Conflict EXCEPTION TEXT: ESR sent the same SSN but changed the status from verified to NEW RECORD EXCEPTION TEXT: ESR sent INVALID for the verification status but PV already had Verified EXCEPTION TEXT: ESR sent the same SSN but changed the status from verified to RESEND TO SSA

· These exceptions appear to be generated when the ESR Correlation SSN or SSN Verification Status is updated and conflicts with the SSN or SSN Verification Status currently shown on the PV.

· Verify the SSN and demographic data shown on the PV using our verification sources.

· If the PV data is correct, lock down all verified data and resolve the exception.

· If the PV data is incorrect, update and lock down the data accordingly and resolve the exception.

EXAMPLE RESOLUTION- PV SSN or SSN Verification Status as well as demographic data has been verified and locked down. NOTE: Paste all of your verification and finalized PDAT in the exception.

EXAMPLE RESOLUTION- PV SSN or SSN Verification Status was incorrect and has been updated accordingly and locked down as well as the demographic data. NOTE: Paste all of your verification and finalized PDAT in the exception.

NOTE: 10/1/12 - The PV data is currently being synched to the ESR Correlation.

253 – Primary View Issue EXCEPTION TEXT: Had trouble updating the correlation data (corien=xxxxxxxx: Unable to update field(s) in correlation for ien # xxxxxxxx.

The notes within these exceptions will vary. They will indicate discrepancies within certain fields within the patients record i.e.: MMN, POB City, POB State, City, ZIP, DOB, Claim Number.

· If the notes indicate a discrepancy in the MMN, DOB, Claim Number, Address or POB fields-compare the RDAT/DDAT to the EDAT. Correct the field by adding the correct data or removing the invalid data. POB, Address and Claim Number fields are maintained by the site and they will have to be contacted to correct the local record.

Note for POB: States “The value '`' for field PLACE OF BIRTH STATE in file MPI FACILITY ASSOCIATION is not valid.” 5/29/13: Per Chris Chesney, the VistA sites have 'FOREIGNCOUNTRY' as the value for FG as the POB State but MPI is looking for ‘FOREIGN COUNTRY’. This will require a patch that will be in i11. Chris has made a temporary fix to stop the exceptions from generating starting on 5/29. Resolve with no action necessary by HC IdM.

Note for Address Fields: The Address field should meet the standards below in order to be vailid.

1) STREET ADDRESS [LINE1]: Must be between 3-35 characters.

2) STREET ADDRESS [LINE 2] and [LINE 3]: Must be between 3-30 characters.

3) CITY ADDRESS: Must be between 3-28 characters.

Note for Address Fields from ESR: There is a formatting issue coming from ESR. These exceptions are generated because the addresses coming in are exceeding the 35 characters allowed in MPI DD for address line 1. When VistA set the 35 character limit, no clean-up was done of all ESR records to assure address line 1 didn’t exceed 35. Per Laurie Sheppard, she has entered a CCR for ESR developers to resolve this formatting issue on their end. This in turn should cease the exceptions from generating on the MPI Exception Handler.

Note for Phone Number field from ESR: States “The value ‘000-0000Cxxxxx-xxx’ for field PHONE NUMBER in file MPI FACILITY ASSOCIATION is not valid”. There is a formatting issue coming from ESR. Laurie Sheppard (ESR)has entered a CCR to not allow alpha characters in phone number…..she is adding to the CCR to change the formatting of mask to remove the space before the “x” and change the lower case x to an upper case X. This is to be in compliance with HL7 standards. This in turn should cease the exceptions from generating on the MPI Exception Handler. HC IdM has requested these exceptions be removed from our exception handler by development. We have also asked that these be auto-resolved in the future, since HC IdM has no means to correct ESR data and we are not the “owners” of the address field. Laurie (ESR) has confirmed that they have no need for us to save these exceptions anywhere for future use.

MPI Developers stated that they aren't going to be able to auto-resolve these at this time. HC IdM is instructed to resolve them as they appear on the exception handler. This is being looked at as part of the migration of the MPI exceptions to Toolkit.

Assign the exception to yourself, log a Remedy ticket for each of these to be relayed to PSIM DEV for resolution and mark Exception as resolved after data is corrected by PSIM staff.

Note for DOB field from ESR: States “The value 'XXXXXX' for field DATE OF BIRTH in file MPI FACILITY ASSOCIATION is not valid.” ESR has an incorrect or imprecise DOB. If ESR shows the correct data, no action is necessary. If the ESR DOB is incorrect, use the OVR or SYNC task to update the data from the PV. I9 included enhancements so the PV updates will synch to the ESR correlation, regardless of the SSN verification status.

Note for RACE INFORMATION field: Assign the exception to yourself and log a Remedy ticket for the RACE INFORMATION subfield pointing to a deactivated value. Reference ticket #471830. Notate your ticket number in the exception. After confirmation the ICN has been fixed, the exception can be resolved.

Note for “Help is being requested from the Validator utility”: These exceptions appear to be generated when a command prompt (i.e. “?”, “??”) is entered into a field of the PV erroneously. The IEN showing is not the patient IEN/DFN but is referring to the IEN in the correlation file in 985.5. The Help message is coming from FileMan because of the “?” in the field value which is causing FileMan to think this is a request for help.

· Compare the PDAT, EDAT, RDAT, and RAUD. The date of the exception should reflect an update in the Audit for the same date. If the data can be verified and the OVR option allows access to the field with erroneous data, please correct. If the erroneous data appears in the Address field, contact the site POC to have the data corrected.

· Verify the SSN and demographic data shown on the PV using our verification sources.

Verify the data has been corrected via the OVR option or the Site POC and resolve the exception.

EXCEPTION TEXT: 1; Exception is from ESR and states 1 in the Exception Text.

EXCEPTION TEXT: 2; Exception is from ESR and states 2 in the Exception Text.

For Exception Text 1 – 01/11/13 – Per Chris Chesney, these occur when we try to log an entry in the reject data file from ESR and the authority score for ESR is -1 to stop them from updating based upon the rule, but the file does not allow for the -1 value and logs the error. There is a fix in I9 for this by changing the file rule to allow the negative values.

For Exception Text 2 – 01/14/13 – Per Chris Chesney, it is the same issue for 1 for 2, just depends on the field being updated in the file, there is a score field and a difference field. Continue to resolve until I9 is released and then we'll stop getting them.

Assign to yourself, paste above paragraphs into notes, and resolve them with no action from HC IdM on the particular record.

EXCEPTION TEXT: No TF entry for xxx(station#) for ICN xxxxxxxxxxVxxxxxx These exceptions may indicate that the correlations are not synched with the ICN on the MPI or Toolkit. Compare PDAT to RDAT/DDAT and ensure the Treating Facility list is correct. Compare the DDAT to EDAT. Verify the EDAT lists the current DFN under the active correlation. There may be an inactive correlation listed under Other Site Associations. This DFN should not be the same. View Correlations tab in Toolkit and ensure there aren’t two active correlations for the site. If the correlations match, use the BC option to broadcast an update to all TF to ensure the Date Last Treated field is properly updated.

EXAMPLE RESOLUTION-

EDAT showed the deactivated DFN under the active correlation and there are two active correlations for the same site in Toolkit. Remedy ticket #xxxxxx was logged to update the DFN for the site on the EDAT. Once the EDAT was corrected then PSIM automatically updated the TK. Verified the TK and EDAT now reflect the correct DFNs and correlations.

EXAMPLE RESOLUTION-

PDAT didn’t show site as Correlation for this ICN. I couldn’t pull RDAT/DDAT, nor RAUD/DAUD by ICN, nor SSN for this site – “invalid ICN passed into RPC” returned upon attempt. CAPRI showed this record at site with this ICN. Duplicate was discovered on the MPI. When I linked these ICNs, everything was back in synch.

Used the BC option to broadcast an update to all TF to ensure the Date Last Treated field is properly updated.

EXAMPLE RESOLUTION-

PDAT didn’t show site as a Correlation for this ICN, however, RDAT/DDAT for the site indicates the ICN is on the record at the site. Used RE option to update MPI with the site’s correlation data.

EXAMPLE RESOLUTION-

PDAT shows site as a correlation; however, the correlation is not known at ADR in the TK. Used PLIN option to send a link message to PSIM for the ICN/Correlation.

EXAMPLE RESOLUTION-

PDAT, EDAT or RDAT/DDAT didn’t show site as a Correlation for this ICN. Ran the TEST option and then the RE option to update MPI and TK with the site’s correlation data.

EXAMPLE RESOLUTION-

PDAT, EDAT and RDAT/DDAT shows site as a Correlation for this ICN. Exception is marked as processed with no action necessary.

EXCEPTION TEXT: Exception is from MHV and states “No TF entry for 200MH for ICN XXXXXXXXX” or “Can't find TF Correlation does not exist.”

· 5/22/13: Verify that the record now has an active MHV correlation and is correct. For records that do not have a MHV correlation, you will need to send the ICNs to your designated SME so they can be reported to Dustin Williams at MHV for manual correlation. The SME will respond back when the records have been linked. If the record now has a MHV correlation, you can mark the exception as Resolved with no action necessary. The problem causing these should be fixed sometime in June 2013.

EXCEPTION TEXT: Trouble trying to update Primary View data in file 985: Unable to update field(s) in primary view for ICN XXXXXXXXXX.

· Review the exception and auto-notes found in the Add/Edit Notes to determine what data is not updating.

· Review EDAT, RDAT/DDAT, and RAUD/DAUD to verify site data is invalid or valid per MPI business rules.

· If site data is invalid or valid, update and lock down the Primary View and resolve exception.

EXAMPLE RESOLUTION-

Site data was [invalid or valid]. OVR option used to update the Primary View as well as lock it down.

EXCEPTION TEXT: Exception is from ESR and states “Trouble trying to update Primary View data in file 985: Unable to update field(s) in primary view for ICN XXXXXXXXXX.”

· If the notes state: The value '-1' for field XXXXX PRIMARY VIEW SCORE in file MPI VETERAN/CLIENT is not valid.

· On 1/22/13- Per Chris Chesney, these occur when we try to log an entry in the reject data file from ESR and the authority score for ESR is -1 to stop them from updating based upon the rule, but the file does not allow for the -1 value and logs the error. There is a fix in I9 for this by changing the file rule to allow the negative values.

Assign to yourself, paste above paragraph into notes, and resolve them with no action from HC IdM on the particular record.

At this time, VIC exceptions located in this field type are manually resolved by C. Link on a daily basis. (9/27/12- per development, these exceptions are not auto-resolve candidates)

EXCEPTION TEXT: Can't find TF Correlation does not exist.

· After review of the ICN’s the findings should show that the…