36C77619R0003-0003008.docx

Toolkit (TK) Request PROCEDURES

Toolkit (TK) Request:

1. A Request comes in through the TK

NOTE: ALL HIGH PRIORITY REQUESTS ARE TO BE PICKED UP WITHIN 30 MINUTES.

ALL ROUTINE PRIORITY REQUESTS ARE TO BE PICKED UP WITHIN 2 HOURS.

1. Caseworker proceeds as follows:

Before assigning yourself to a Request, verify that there are no open related RJCs/Exceptions/Tasks/Requests that are already assigned to another Caseworker.

Refer to the end of this document for guidance on 1900 Person Verification Requests.

NOTE: If you receive a request from a POC to make edits to their information, refer them to the Point of Contact Management function in the left navigation bar of TK where they can make the changes to their site’s MVI POC information themselves. When a POC makes an update to their site’s info in POC Management, it will generate a MVI POC Edit Request. Marlene or Kim will pick up the Request and make updates to the POCs’ TK access based on the changes and then send the Request to Matt or Lynn to update the MVI POC mail group if necessary. If the site is unable to make the changes and you make edits to the POC list yourself, DO NOT resolve out the resulting MVI POC Edit Request. You MUST assign the MVI POC Edit Request to Marlene or Kim so that the changes can be populated to the MVI POC mailgroup and the user’s TK profile.

A Read-Only version of the MVI POC List is available for non-MVI POCs who do not have access to the Toolkit at https://mvitk-prod.aac.va.gov:8957/imdquiWeb/pocMgtRead.do.

1. Assign Request

a. Go to Manage Requests.

b. Go to List Requests or Search (Search for all Requests with the status of Submitted, Unassigned and Updated if List Requests total number exceeds 500).

i. IMMEDIATELY assign the Request to yourself.

c. Review Request Details and Request Notes. If supporting documentation was received via fax or email from the MVI POC, scan or copy it, and then attach it to the Request.

NOTE: If the requesting site does not provide the proper documentation for an ID Trait Edit Request, change the Request Status to “Needs More Info”. Then add a statement in the Request Notes explaining sufficient documentation was not provided to make the trait change and attach a copy of the Identity Management Fact Sheet to the request. At that time, there is no need to create an OVR Task. An OVR Task should only be created once sufficient supporting documentation is furnished. (02/23/2017 team call)

d. Go to the Request Tasks tab within the Request to check if there are any related Tasks (i.e., POTENTIAL DUPLICATE, PCE or other tasks – see #4 below).

i. If there is an existing open Task it will be displayed under Other Open Tasks at the bottom of the page. To save an existing Task to your Request:

· Select the Task checkbox.

· Click “Save to Request.”

a. An auto note will populate in the Request Notes that the Task# has been added to the Request.

b. The Request Audit will also indicate the date and time the Task# was added to the Request.

· Select the hyperlink for the saved Task you want to work on under Request Tasks at the bottom of the page.

· On the Notes tab of the Task assign the Task to yourself.

ii. If a related Task is not found (i.e., POTENTIAL DUPLICATE) the Caseworker will create any necessary Tasks within the Request Tasks tab:

· Select the checkboxes for the ICN(s) you want to create a Task for. NOTE: If you need to add another ICN to the Request, you can do so through the Request Notes tab.

· Select the appropriate Task Type.

· Click SUBMIT.

NOTE: Do NOT go outside the Request to create the related Task. Do NOT select the ICN hyperlink within the Task. Go back to the Request and create any Tasks from the Request Tasks tab. This will ensure that the Tasks created for the Request are related to the Request.

a. An auto note will populate in the Request Notes that the Task # was created and added to the Request.

b. The Toolkit will automatically take you to the created Task.

NOTE: As of Increment 12 Release 2, the Override is available via the Override tab in all other Tasks.

When an Identity Trait Edit Request is received for changes the facility could make, first review the PV to be sure there is nothing preventing the update. Do not update the trait(s) unless the sender states they have tried to change the data and included the audit section showing the attempt. If there is no evidence they have tried to make the change, place the paragraphs below in the Request Notes and place it in “Ready for Review” status. Remember HEC, MHV and DoD are unable to update traits so we will continue to make them.

We are seeing an increased number of routine Toolkit Identity Trait Edit correction requests generated by the sites that may be more efficiently handled if completed locally. We would like to provide an important reminder that completing these types of edits locally (i.e. identity trait corrections that are not legal changes/record amendment requests) is beneficial to both the site and the patient by providing a more prompt resolution of corrections to the Veteran's record. It also improves our overall efficiencies by reducing the number of requests generated to HC IdM via Toolkit. Please go ahead and attempt to make the requested edit in your local VistA system. If the edit reverts back, copy and paste the portion of the audit into your Request notes showing you attempted to make the edit. Thanks in advance for your support and if you have any questions or need assistance please contact the Healthcare Identity Management Team via the Identity Management Toolkit.

Per VHA Handbook 1907.01: “An administrative correction is remedial action by administrative personnel with the authority to correct health information previously captured by, or in, error. Administrative corrections include factual and transient data entered in error or inadvertently omitted. Administrative corrections are not initiated by the Veteran.”

When Identity Trait Edit Request received for multiple entries -- We should only change the traits (Name, SSN or Birth Sex) that are specifically requested. If you notice the gender has changed as well as the name on the documentation provided for a transgender name change, we should not change the Birth Sex without the Veteran’s written consent, proper documentation and the site requesting us to do so. Sites should be using the SIGI field now to identify transgender persons and to specify what gender they want to be recognized as. The Birth Sex field controls clinical reminders and lab values and needs to remain as the original birth sex to the extent possible. We are hopeful that sites will begin using the SIGI field instead. (02/08/2018 team mtg)

We receive a lot of name change requests where the DOB will be incorrect in VistA but the correct data will be listed on the legal documentation. In these instances there has not been a legal change, and in an effort to capture the most accurate data, the DOB should be corrected on the record. (02/08/2018 team mtg)

iii. When you create an OVR Task from the Request Tasks tab.

· Document the OVR Task by following the Toolkit Task Details Template located on the SHARE drive.

NOTE: The Toolkit will auto note the DATE/TIME/NAME of the HC IdM Caseworker for any action taken.

· In all other Task NOTES (i.e., DUPLICATE Task notes) enter the following:

“See OVR Task # for case documentation.”

· Resolve the OVR Task (once resolved, the Task cannot be reopened)

2. Go back to the Request and paste your reply into the Request Notes field.

a. Respond as if replying to an email.

NOTE: Do NOT include the final PDAT because the POC can review the updates in the Toolkit. As of Increment 12 Release 2, the PDAT button will enable the POC to retrieve current patient data from the MPI. The Request will NOT include the verification info, etc. It will only include the communication related to the Request.

i. Set Request to “READY FOR REVIEW” for the POC to resolve.

NOTE: Do NOT set the status to “READY FOR REVIEW” until all VistA, MHV and ESR correlations have updated.

ii. If the POC does not resolve the Request after two (2) weeks and it is still in “READY FOR REVIEW” status, the TK will automatically resolve the Request. If the Request is in a status other than “READY FOR REVIEW” for more than two (2) weeks, the Caseworker can mark it as “RESOLVED”. Also if the Submitter has not responded within two (2) weeks of an inquiry, from the Caseworker, for information needed to complete the case, the Request can be marked “RESOLVED”.

3. As of April 2, 2015 and updated July 15, 2016, when Contract Staff is working a Request and determines it to be a Potential CE, Potential Mismatch, Potential Identity Theft or Potential Fraud and/or has an associated Task requiring VA staff intervention the steps below should be followed. Associated Tasks include but are not limited to Task Types: 1230-Potential Mismatch, 1239-Potential CE, 1310-Potential Mismatch-System, 1320-Potential Mismatch-HC IdM Generated, 1330-Potential CE Non-VistA Site, 1340-Potential CE- HC IdM Generated, 1350-Potential Erroneous Edit, and 1360-Potential Source System Erroneous Edit.

a. Enter a note into the request notes field documenting the issue that you have found with the request (e.g. This request appears to involve a Potential CE and requires review by a VA staff member.) (e.g. VA staff, please review 1330 Task #123456 for a Potential CE.) These are only examples. Each scenario could be different. The main point is that we document why we are sending the request over for VA staff review.

b. Mark the request as High Priority.

c. Change to the appropriate Request Type.

d. Un-assign yourself from the request and save.

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

· 1996 Person Verification Tasks/1900 Person Verification Requests (Mike) – There are 1996s which were submitted by the VHIC clerks with no documentation. We can’t do anything without the supporting documentation. The Tasks are just sitting in the queue and are time sensitive and will eventually be purged from the pending card list.

One option to resolve the problem is by contacting the VHIC clerk for the documentation. Mike also suggested resolving the Tasks. It’s not the best solution; the veteran will need to go through the process again.

Questions:

· Should we contact the site for documentation first or just resolve the Task? -If there’s a chance that the site has the documentation, please contact before resolving Task.

· Should we give the site the standard two weeks to provide the documentation before resolving the Task? -Let’s not do another workaround. Let’s be consistent with the two weeks

· A note was added to a 1996 Task. When the note was saved, the HC IdM team member was assigned as the caseworker. Will the VHIC clerk see the note? -No, the VHIC clerk will not get a notification. You will need to call or email the clerk.

Marlene talked with Dan yesterday and the MVI POCs or VHIC will not be able to submit Requests/Tasks for changes without an attachment.

Information updates (Adam):

· Do not enter notes in the Request which accompanies the 1996 Task. VHIC users, who aren’t MVI POCs, do not have access to the Request queue.

· How to process the ID trait edits from VHIC users where no documentation is attached?

· Leave assigned to submitter and contact POC for documentation.

· If a user copies the ICN from Toolkit to paste in the VHIC program, when the user goes to submit the Task an error message might be received.

· They will need to delete the last number from the ICN and re-enter the number. This will remove the space at the end and allow them to proceed in VHIC program.

· Site personnel will not be able to process/submit a 1996 Task if the document field by name is blank even if other document fields for Gender, SSN and/or address have documents selected or not.

· How do you handle 1996 tasks assigned to proofer where a 1900 request was generated and resolved due to address discrepancy? We’re receiving phone calls and emails from VHIC users and POCs on how to proof the Veteran.

· From my experience, they cannot proceed unless the 1996 task is resolved, a new 1996 task is submitted (with documents) and by selecting verify on the left side for all traits.

· When a proofing task is submitted whether LOA remains 1 due to ID trait changes or is proofed to 2, if no changes, a 200IP correlation will automatically be added to the record. Adam suggested if ID Traits edits need to be completed; the 200 IP correlation should be added after the Task is proofed to LOA 2.

· If a 1996 task is proofed to LOA 2 and then another proofing task is entered, the LOA should change from 2 to 1. If this does not occur, log a SDM Incident for development. Per Mike, this is considered a bug or defect and he requested Adam write a CR for the RAD group.

· Adam and Susan reported the following problem to development (Task #1779800):

· If there’s a 200IP correlation already on the record before the 1996 task was proofed, the DOB field (if it has incorrect DOB) does not update Proofing task even if you click verify for correct DOB.

· Solution: Create a 1300 OVR Task to correct the DOB.

· Carol reports there was a known issue with the removal of the DOB but that issue should have been resolved with the deployment on 3/19.

· Extra training was suggested since the VHIC Proofing feature is so confusing.

· There were instances where the VHIC user proofed the patient to LOA 2 and then an ID Trait Edit Request was submitted by the MVI POC. How do we work those Requests? -In this case, tell the MVI POC to enter another 1996 Task and a new card should be generated.

· For 10 days, the process cannot be repeated.

· In that case, ask the MVI POC why is this Request being submitted?

(Carol) Georgann and Jeff performed extensive testing prior to the release. A large number of issues were reported during UAT. There were discussions with development where concerns were articulated. In the end, there was no choice given but to approve the release for production.

(Mike) The VHIC feature was tested until the release. There was no documentation available for the team or the VHIC clerks. During this process we’ve incurred technical and procedural problems. Please report all disconcerting issues and we will try to get answers.

Updated 01/08/03/27/2018 KJW/GC 1 image3.jpeg image2.jpeg