36C77619R0003-017.docx

ATTACHMENT 16

Healthcare Identity Management Team Tips Sheet

Definitions

1. The Master Patient Index (MPI) is a national database located at the Austin Automation Center (AAC). The Master Patient Index/Patient Demographics (MPI/PD) package was released on 4/30/1999 and completed on 3/9/01. The Healthcare Identity Management (HC IdM) staff was organized in November 2001.

2. A national Integration Control Number (ICN) is a unique enterprise wide identifier starting with either 100 or 101 which is assigned to a patient’s record when the patient is added to the Master Patient Index (MPI). ICNs link patients to their records across VA systems to allow sites to see remote patient data (via Remote Data View button in CPRS GUI) and complete Inter-facility consults.

3. A local ICN is assigned by the local VAMC until the patient can be assigned a national ICN. This should only occur in instances of connectivity issues between the VistA site(s) and the MPI. The local ICN can be identified because the VAMC station number makes up the first three digits.

4. The Coordinating Master of Record (CMOR) is the local VistA site that acted as the authoritative source for the patient’s demographic data until the Primary View functionality was implemented in 2007.

5. The HC IdM Toolkit is an intranet application used to facilitate improved identity management data quality for the VA. The IdM TK interacts with Person Services (PS) and with the MPI in Austin, TX. It is a primary tool used by the Healthcare Identity Management (HC IdM) staff for identifying, managing, and resolving exceptions

Acronyms

6.

Note: More Acronyms are found in the Acronyms list listed on the Shared drive.

MPI Information

7. Always be sure to halt a session before closing the window or it might lock that session.

8. The five identifying key fields are Name, SSN, DOB, Sex and Mother’s Maiden Name. These 5 fields plus the MBI are synched (updated) at the associated TFs (correlations) when an update is made to the PV. Always make sure the PV as well as the associated/shared TFs (correlations) have the correct FULL name (always try to get the full middle name), correct SSN, DOB, Sex and Mother’s Maiden Name.

9. Middle name, prefix and suffix do not have to match for automatic matching to occur on the MPI. For automatic matching to occur on the MPI, the site’s patient data has to match the PV’s data exactly on the following fields: Last Name, First Name, SSN and Sex. The DOB or Mother’s Maiden Name does not have to be an exact match. These are the current business rules for automatic matching and could change in the future.

Data Resolution Journal

10. DMT Cases - If more than one SSN is involved in a case, be sure to answer “YES” to the question about adding another ICN to the case and include all associated ICNs.

11. If there has been a case logged in the past for the same patient/SSN/ICN and you are working with that particular patient, reopen that case instead of logging a new case and change the case worker’s name to yourself. You should always enter your information below the <<AUTO NOTE>> and NOT above it when you open or reopen a case.

12. If you see the following statement when working on a case, it means that there is more than one case on the MPI for that ICN and they need to be combined into one case: (See Outlook message from Carol Turner dated 1/3/05, Subject: Question – found on Share Drive under folder Instructions, Guidelines, and Tips\Informational Mail Messages/Msg #1)

<<THIS ICN IS CURRENTLY CHECKED OUT>>

MPI Development Team

13. For assistance with problems involving the MPI software functionality (menu options, etc.) in the MPI, such as locked sessions, access codes, option not working correctly, etc., log a Remedy ticket.

Category = Applications-VistA Type = Master Patient Index Austin 1.0 Item = (Chose: Clear Lock from Exception, Clear Lock from RJC, General, or Remove CE Flag from ESR correlation.

For Assistance with problems involving MPI performance including outages should be reported in Remedy with the following C/T/I:

Category = Applications-VistA Type = Master Patient Index 1.0 Item = Unable to Connect/Unresponsive Slowness Records not Linking Unable to View Remote Data

FHIE – Austin (200)

14. When you see Austin (200) listed as a TF, this means that the patient has DoD data. If there is more than one ICN on the MPI for the same patient with Austin (200) listed as a TF, use the DUP option to resolve the duplicate. The record that you do not wish to retain (FROM Record) will be deactivated automatically. If the FROM Record on the MPI has Austin (200) listed as a TF and the TO Record on the MPI does not have Austin (200) listed as a TF, using the DUP option will resolve the duplicate on the MPI, deactivate the FROM Record ICN and move the Austin (200) TF from the FROM Record to the To (Retained) Record. Once the DUP functionality has completed use the CHK option to confirm that there are no pending messages, verify all updates at the site(s) via running an RDAT/DDAT and verify all updates on the MPI via running a PDAT and EDAT. Additional information regarding Austin (200) is available via the “Creating a RESOLUTION JOURNAL CASE and documenting notes’ document.

15. In the case of Multiple Births, it is not necessary to advise Station 200 (Austin) as they do not populate the MBI field on their records. (See Outlook message from Randall Baylis dated 12/29/04, Subject: Twins - found on Share Drive under folder Instructions, Guidelines, and Tips\Informational Mail Messages/Msg #2)

16. Gender is not required on Austin (Station 200) records. (See Outlook message from Jimmie Sue Sivley dated 5/5/05, Subject: Austin (200) entry - found on Share Drive under folder Instructions, Guidelines, and Tips\Informational Mail Messages/Msg #3)

17. The time frame for DoD matching with the MPI was real time to approximately 60-90 days after Veteran’s discharge from active duty, however this has been shortened and should be available upon discharge once the DoD record is correlated with the ICN. The name (first and last), SSN and DOB have to be an exact match at this time, however perhaps when CHDR is deployed (possibly September) there may be some variances allowed (i.e. Bill for William, Bob for Robert, etc.). (This is per phone conversation with David Seitz on 6/21/05.)

Resolving Duplicates

18. If there is a discrepancy with the patient’s DOB and one or more of the sites have the same DOB as SHARE, VBA-IBBA and/or HINQ, then it is presumed to be the correct DOB. HEC does not always display the correct DOB. For a list of the specific demographic data fields in HEC’s system that is verified/validated with the SSA, please refer to: (Outlook message from Jimmie Sue Sivley, dated 10/08/03, Subject: Validation with SSA - found on Share Drive under folder Instructions, Guidelines, and Tips\Informational Mail Messages/Msg #4), and the HEC document for enumerating the SSN with the SSA… it’s called Enumeration Verification System (EVS) User Package with SSN Match for Federal/State Agencies.

19. Be sure to check for any outstanding CMOR Change requests (via running an RDAT) for the patient before you try to un-link a TF from an ICN (via the MP option). The status will show PENDING if there is still action to be taken. Have the site approve or disapprove the CMOR change request first and this should take care of the issue. (See example Outlook message dated 7/15/04 from Chris Chesney, Subject: CMOR Request and Mismatches - found on Share Drive under folder Instructions, Guidelines, and Tips\Informational Mail Messages/Msg #5). This note is no longer pertinent as the CMOR functionality has been replaced by the Primary View, but is being retained for historical purposes at this time.

20. Always check for messaging updates (via running PDATs, EDATs and RDATs) at the site and on the MPI after you use an option under the ‘UPD - Update MPI/PD Data’ menu. When using several UPD options, always verify that messaging has been updated at the site(s) and on the MPI for each option before using another UPD option… you can use the CHK - Check Status of Remote Update Request option to check for Message Types A19, A24, A43, and M05.

21. Prior to using the DUP option to link/merge duplicate records on the MPI, check to see if the patient has a valid Mother’s Maiden Name. If so, be sure to check after the DUP option is used to verify the MMN data was retained. If not, use the OVR option to add the MMN data to the PV.

22. Different cultures use different name formats for their names. (See Outlook messages dated 5/13/04 from Sara Temlitz and Diana Carby, Subject: Format for Spanish names - found on Share Drive under folder Instructions, Guidelines, and Tips\Informational Mail Messages/Msg #6a, Msg #6b and Msg #6c).

23. MPI message types and associated options/descriptions:

24. If a site has a pseudo SSN, the SSN will show as UNKNOWN on the MPI. Running an RDAT can be used to see the complete pseudo SSN at the site. You will need to obtain the pseudo SSN if you are reporting to HEC that a record has been assigned a pseudo SSN which previously had a “valid” SSN.

25. If there are not enough required fields populated to make an entry permanent (as defined in the business rules), the national ICN will be assigned an ID State of TEMPORARY. Once the required fields are populated with the correct data, the ID State will be re-evaluated. If all required fields are populated with the complete data, the ICN will be re-evaluated and assigned an ID State of PERMANENT. Records with an ID State of TEMPORARY can only be viewed by the CMOR site using the Display Only Query. If a site is not the CMOR site for the Temporary entry, they will not be able to view the patient’s data using the Display Only Query. A record with an ID State of TEMPORARY is not available for matching until the record is updated with the required fields to make it PERMANENT. Only patients with an ID State of PERMANENT are available for matching. If there is a duplicate on the MPI and one ICN has an ID State of PERMANENT and the other ICN has an ID State of TEMPORARY, the TEMPORARY ICN (From Record) can be linked to the PERMANENT ICN (To Record), however a PERMANENT ICN (From Record) cannot be linked to a TEMPORARY ICN (To Record). A duplicate on the MPI where both ICNs are TEMPORARY cannot be linked via the DUP option.

Information for VistA Sites

26. Site POCs need to use “quotation marks” around the patient’s entire name if they are entering a new patient that has the same name as an existing patient in their system, after they have thoroughly verified it is not the same patient.

27. If the SSN is unknown, the site POC can enter a P at the prompt and the system will automatically assign a pseudo SSN based on the patient’s 3 initials in first-middle-last name order as well as the patient’s DOB. (See Outlook message dated 6/18/04 from Jimmie Sue Sivley, Subject: Pseudo SSN Assignment - found on Share Drive under folder Instructions, Guidelines, and Tips\Informational Mail Messages/Msg #7.)

28. When site A makes a request to be the CMOR, site B has 14 days to act upon the request, or it will happen automatically. If site A is the CMOR and they push the CMOR to site B, this is automatic and site B does not have to do anything. This note is no longer pertinent as the CMOR functionality has been replaced by the Primary View, but is being retained for historical purposes at this time.

29. Sites may request any of the following Class III routines that will identify Local ICNs, patients that are missing sex data and patients having a missing/imprecise DOB. If you get a request from a site regarding this, you can forward the following routine(s) to the site that are contained in the following message:

30. Duplicate records in a site’s system can be merged (via Duplicate Record Merge software) even if they both have a national ICN. Patch RG*1*29 which was released on 12/12/03 allowed this. Per Cindy Heuer, PIMS Team, if the veteran is an inpatient when the duplicate records are discovered, the older record should be assigned a pseudo SSN, the current record should have the correct SSN and site should hold off on merging the records until the veteran is discharged. (See Exchange message from Bert Bias dated 10/4/06, Subject: Do NOT merge records for Inpatients – found on Share Drive under folder Instructions, Guidelines, and Tips\Informational Mail Messages/Msg #11.)

31. Sites can have a unique SSN in their system only once. If a site has a duplicate record for a patient, either one of the records has an incorrect SSN or pseudo SSN or the SSN cross-reference has not been set on one of the records.

32. An asterisk (*) next to a potential match entry at a site means that the ICN is already attached to another patient’s record at that same site… this could be the primary ICN for the patient or the ICN in history. If there is an asterisk (*) next to a potential match entry for a site other than the site attempting to SPI, this means that the record at the site has been attached to the other ICN at some point in history. (For example, see Forum message #39802004 from Martha Bisanar.) (Also see Exchange message from Chris Chesney dated 9/7/2004, Subject: Attempting to initialize patient to MPI and getting Multiple ICNs Exception - found on Share Drive under folder Instructions, Guidelines, and Tips\Informational Mail Messages/Msg #8.)

33. Witness Protection Program - It is quite irregular for an individual to present to their local facility requesting this status, as typically the new facility where the veteran has been relocated should never be made aware that the veteran is in the Witness Protection Program. The US Marshall’s Office is supposed to coordinate with VACO (currently the VACO contact with the US Marshall’s Office is Kevin Doyle) when a veteran is to be placed in the Federal Witness Protection Program. The administrations are then responsible for adding the new identity, obtaining the old paper records and adding a new eligibility status for the patient. Gail Graham is the person in charge of this program on the VHA side. Once she receives the notice from the US Marshall’s Office advising of a veteran’s participation in this program, the request is made for the old paper records to be sent to her so they can be locked up and retained in Central Office. The veteran is issued the new identification to include a new DD-214 and advised to seek medical care from the VAMC located in the new home of record where an entirely new entry and new chart should be set up with the new identity that cannot be linked to the prior information in any manner. If the facility changes the information on the old record instead of creating a new entry, the audit information will need to be purged. If necessary to send messages regarding Witness Protection, please use the abbreviation WITSEC in the subject line and not the full title. (This was learned recently because an exception was generated when the site changed the name on the current record instead of creating a new entry because the patient came to the facility and informed the site that he was in this program.)

34. PMR Allowances – Sites are allowed to have a certain number of unprocessed PMRs in their Exception Handler based on the number of patients in their database:

35. Test Patient Records – Patch DG*5.3*72 was released on 2/8/1996 to support the requirement that SSNs on test patient records contain 5 leading zeros.

Error Codes/Messages

36. The following are Inter-facility Consult error codes that are related to the MPI/ICN:

Error 201 – Unknown patient at Consulting Site Error 202 – Local or missing ICN at Reporting Site

37. For a sample of the message to send to the IRM POC at a site when you receive an error message regarding the HFS Directory when trying to run and display RDAT/DDAT or RAUD/DAUD, See Outlook message date 6/9/05 from Diana Carby, Subject: UNABLE TO ACCESS HFS DIRECTORY USER$:[TEMP] FILE VAFC34399.DAT – found on Share Drive under folder Instructions, Guidelines, and Tips\Informational Mail Messages/Msg#10.)

Following is an example of an error message the IMDQ Team receives occasionally from a site when trying to retrieve remote data via RDAT/DDAT or RAUD/DAUD:

ERROR: UNABLE TO ACCESS HFS DIRECTORY USER$:[TEMP] FILE VAFC34399.DAT PLEASE CHECK DIRECTORY WRITE PRIVILEGES.

HEC

38. If errors (incorrect patient data, eligibility/enrollment/means test errors, etc.) are discovered in HEC’s database when working on a Patient Identity Change exception, MPI duplicate case, mismatch, etc., forward the issue and patient information via PKI encryption to the VHA HEC DQ Support mail group. Be sure to use the Excel spreadsheet template provided by HEC staff located at \\Vhaistfpc4\imdq team\Instructions, Guidelines, and Tips\HEC INFO. The HEC staff will have to query the affected sites for data updates to get the correct patient data updated in their system (for example, see NOIS # ISB-1204-31722).

39. If errors are found at HEC with Date of Death information or patient record shows a death entry and the patient is still alive, forward the issue and patient information via PKI encryption to the VHA HEC Alert mail group or through the website at https://vhahecweb2.vha.med.va.gov/hecalert.

40. Contacts at HEC: Gary Phifer, Ed Boyer or Venis Whitfield.Debra Ringer, Leonard Parker, Crystal Vincent, Kenneth Johnson, and Dee Tyner (Privacy Officer).

41. If sensitive patient data needs to be sent to HEC staff via Exchange and you are unable to use PKI then you can send the station number and the DFN for the record at that station without encryption and the HEC Staff should be able to locate/update the record.

42. HEC has specific business rules for validating SSNs with the SSA. (See Outlook message dated 7/8/04 from Jimmie Sue Sivley, Subject: Validation with SSA - found on Share Drive under folder Instructions, Guidelines, and Tips\Informational Mail Messages/Msg #9.)

Workload Priority

43. Following is the order of priority for cases that employees work on… please note the following prioritized duties with #1 being your highest/first priority:

a) Inter-facility Consults (IFCs) and/or Remote Data Views (RDVs) take priority over everything else as these impact clinicians.

b) Requests from MHV staff reporting problems preventing patients from requesting refills online.

c) Requests (via FORUM/Outlook/Telephone, etc.) from sites regarding potential duplicates on the MPI.

d) All other requests (via FORUM/Outlook, Telephone, etc.) from sites that may not necessarily involve a potential duplicate on the MPI.

e) Working off the 750 Potential Duplicate-Add patient Toolkit Task in your spare time.

f) Miscellaneous projects, etc. (unless priority is otherwise specified by Management staff)

Exceptions

a. Potential ID Change Exceptions (#239)

b. Potential Mismatch Exceptions (#257)

c. HEC Requests

d. Other MPI Exceptions

e. TK Tasks (#750)

Email

a. IFC or Remote Data requests

b. MHV requests

c. All other email requests

d. HEC requests as time permits

e. TK Tasks(#750)

Group C

a. Continue with 2-3 staff being assigned to assist with email each month unless a large number of testers are needed for UAT. Usually, those UATs are known about in advance and can be planned for accordingly.

b. UAT or Special Projects as needed/assigned.

c. If it is your month to assist with email, that will be your priority unless UAT requires more staff than available with the remainder of Group C.

d. HEC Requests

e. TK Tasks (#750)

After new employees are completely comfortable with working the above, we will then discuss the possibility of working on exceptions generated to the MPI.

Updated: 8/24/2012 (In-Progress-Georgann Cox)