Applicable Doc. 5B - IAM Playbook - VAMPI.pdf
PDF 277 KB Posted
- Attached to
- DF01--IAM Recompete Task Order (VA-24-00001896)
- Solicitation number
- 36C10B24Q0109
About this file
This document provides an overview of the VA Master Person Index (MPI) identity management service. The MPI is the primary system for assigning and maintaining unique person identifiers across the Department of Veterans Affairs. It currently holds over 40 million identity records.
The MPI service offers several functions including searching for identities, adding new identities, merging duplicate identities, updating identity information, and retrieving corresponding identifiers. It provides interfaces for applications to integrate including a web service using SOAP/HL7v3, a RESTful API using FHIR, and an HL7 v2.4 interface. The service also includes a user interface for privileged users to manage identities.
The document outlines various integration patterns for applications including an enterprise pattern where systems correlate with the MPI and share identity information, an aggregate pattern where systems only retrieve data from the MPI, and decentralized patterns where systems receive but do not store the MPI identifier. It provides details on the service operations and interfaces available to applications based on the chosen integration pattern.
View the file
Other files
Show all 34
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Last modified at 10/17/2023 11:23 AM by DeAntonio, Damien M. (Green Threads) (he/him/his)
IAM Playbook Home
VA MPI Playbook This (and all IAM playbooks) playbook is a collaborative and continuously improved wiki/document. The purpose of the wiki/document is to provide as much useful technical information to integrating partners, if there is information that you feel is missing please let us know and we can add it or even give you contributor rights to add the information yourself!
Applications interested in using any of the IAM services should submit a service request (SR) using the Information Technology Request Portal (ITRP) to start the process.
Overview The VA Master Person Index (MPI), formerly known as the Master Veteran Index (MVI) and the Master Patient Index (MPI), is the primary system for assigning and maintaining unique person identifiers and provides enterprise-wide identity management. VA MPI is the authoritative identity service within VA, establishing, maintaining and synchronizing identities for all VA persons of interest (e.g.
Veterans, beneficiaries, dependents, employees, contractors, health professional trainees). VA MPI currently holds over 40 million unique person identity entries.
A gateway in VistA establishes connectivity between VA Medical Center (VAMC) systems and patient registration processes and links to the MPI for message processing and patient identification. The MPI has been created to support maintenance of a unique person identifier (ICN) and a single master index of all Veterans Health Administration (VHA) patients and to allow messaging of patient information among the institutional partners [i.e., VHA, Veterans Benefits Administration (VBA), Board of Veterans Appeals (BVA), National Cemetery Service (NCS), and Department of Defense (DoD).] MPI creates an index that uniquely identifies each person known by the VA, identifies the sites where a patient is receiving care as well as correlations to other major VBA and NCA systems.
Reference Links VA MPI Service Description Document VA MPI HL7 Interface Specification VA MPI FHIR Specification
The following table lists the detailed functions offered by the MPI service.
Function Description Supporting Interfaces
Search/Retrieve Person (Attended or unattended) (Returning Corresponding IDs) (Orchestrated (not for Attended))
FindCandidate (PRPA_IN201305UV02), this operation allows the consuming application to query the MVI for the person identity based on a set of submitted identity traits or correlated identifier using a) Attended Search, b) Unattended search, c) Retrieval, d) Register Interest.
Returning Corresponding IDs includes the Get Corresponding IDs results as described below.
Orchestrated (for Retrieves or Unattended Searches only), If VA MPI does not have an identifier for one of the systems not fully correlated with VA MPI (e.g., DoD, Corporate, BIRLS), VA MPI will perform an extended search into the uncorrelated data stores. The process results in person information from the uncorrelated data store being returned to the consuming application. The process also creates a new Integration Control Number (ICN), or uses an existing ICN to establish a correlation with the uncorrelated data store when appropriate.
MVI WS Interface MVI REST Interface (Not for Unattended Search)
Search for Person (Attended in Unattended Mode)
FindCandidate (PRPA_IN201305UV02): Alternative use: This Search is initiated using at least the minimum traits outlined in the unattended search scenarios matrix. Search Attended in Unattended mode gives more flexibility to the Claims process and should reduce the number of Manual Selections and Manual Resolutions
MVI WS Interface MVI REST Interface
Add Person (Add Correlation) Add Person (PRPA_IN201301UV02), this operation allows the MVI consumer to request the creation of a new person identity record.
a. Add Correlation
b. Add Person (implicit add with the search)
c. Add Person (explicit with no search)
d. Proxy Add Person
i) VHA Patient,
ii) VBA Claimant, Veteran Claimant, or Non-Veteran Claimant,
e. Add Person (Add Relationship); to VA MPI and VBA CORP and BIRLS.
MVI WS Interface MVI REST Interface (future)
Get Corresponding IDs GetCorrespondingIDs (PRPA_IN201309UV02), this operation allows the consuming application to submit an identifier to the MVI and receive back all identifiers associated with the submitted identifier.
MVI WS Interface MVI REST Interface (future)
Page Rating
Categories No categories were selected
IAM Playbooks
VAMPI
https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/_layouts/listform.aspx?PageType=4&ListId={FC3D90CA-C60C-44F7-9901-1C022384F074}&ID=39 https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/IAM%20Playbook%20Home.aspx https://dvagov.sharepoint.com/sites/CMDM-RP/SitePages/What-is-ITRP-.aspx https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Documents/MPI/VA_MPI_Service_Description.pdf https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Documents/MPI/mpif_1_0is.doc https://ps.dev.iam.va.gov/iam/mpi/fhir/r4/ javascript:;
javascript:;
javascript:;
javascript:;
javascript:;
https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Pages/IAM%20Playbook%20Home.aspx
Function Description Supporting Interfaces
Merge Person MergePerson (PRPA_IN201304UV02), this operation supports merging of two local Source IDs, Resolution of duplicate Source IDs, moving or mismatch Id from one ICN to another. a. Link Resolution of Duplicate Records. Move Mismatch Records. Merge Resolution of local Duplicate Record
MVI WS Interface MVI REST Interface (future)
Update Person Update Person (PRPA_IN201302UV02), this operation allows the consuming application to update the person identity record. This operation is also used to unlink a correlation from and to an ICN. Unlink:
Unlink a Correlated ID.
Update Person (Update Relationship); to VA MPI and VBA CORP and BIRLS.
MVI WS Interface MVI REST Interface (future)
Integration Patterns The table below defines the VA MPI Integration Patterns.
Integration Pattern Name
Description Business Characteristics
Technical Characteristics
Properties Pattern Options Service Operations Consumed
Enterprise Integration Pattern
The Enterprise Integration Pattern:
Primary pattern Supports person related data sharing across the enterprise Allows disparate systems within the VA to retrieve and share information with other enterprise or external systems
The VA Business rules governs whether the partner:
Retrieves information from other
VA
LOBs/external partners.
And/or
Shares information with other VA LOBs/external partners.
The Integrated System
Correlates to the VA
MPI.
Interacts with the VA MPI for identity information when there is a need to communicate outside its system boundary.
Can be a centralized system that does not store identity traits.
Calls the VA MPI Service for all person searches.
External systems needing information from the integrated system must call the VA MPI to obtain the person identifier for the integrated system.
The VA Business rules govern whether:
The integrated system's correlation synchronizes with the VA MPI Primary View.
Identity updates received from the integrated system update the VA MPI Primary View.
Person Lookups can be performed in the local application/system or at the enterprise (searching the VA MPI) depending on business need. Should this be a bullet?
The integrated system may:
If a business need is defined, to keep the system updated such that it would bring disparate records together, and manage them over time, then the ICN shall be stored within the integrated system (Example: VHA VistA), and the Integrated system shall subscribe to and implement VA MPI ICN maintenance notifications, If there is NO such business need defined (as above), there is no SHALL requirement to store ICN within the integrated system (Example: NCA
BOSS/AMAS),
If the VA Business has determined a need to add new persons to the enterprise, the integrated system, in the absense of an existing identity, shall create a new ICN, otherwise only a new correlation shall be created..
Receive Identity trait updates from the VA MPI, and VA MPI tracks the acceptance and/or rejection of submitted identity trait updates
Available Service Operations:
FindCandidate Update Person GetCorrespondingIDs Add Person [Implicit Add with Search] Add Person [Explicit Add with No Search] Merge Person Merge Person Notification [Link] (future) Merge Person Notification [Move] (future) Proxy Add Person [to VistA]
Aggregate The Aggregate Pattern:
Is similar to the Enterprise Pattern except there is no need to receive identity
The business process requires the integrated system to only:
Retrieve information from other
VA
The integrated system:
Does not correlate to
VA MPI
Interacts with VA MPI for identity information when there is a need to Retrieve information from other VA LOBs or external partners.
The integrated system:
Does not establish a correlation with the VA MPI Does not create new ICNs to the
VA MPI.
Person Lookups can be performed in the local
The integrated system:
Does not subscribe to ICN maintenance messages.
May create a local person identifier based on a business or technical need.
Available Service Operations:
GetCorrespondingIDs Find Candidates updates from
VA MPI.
Conforms to a pull model Used mostly by User Interface or Call Center applications.
LOBs/external partners.
application/system or at the enterprise (searching the VA
MPI),
depending on business need.
Decentralized Pure
The Decentralized Pure Pattern:
A system integrated with a Decentralized Pattern supports management of its internal assets for a confined business process.
The two types of Decentralized business patterns are:
Pure Hybrid.
The supported business process:
Is a continuation of a business process started in another system which is correlated to the VA
MPI.
Does not need the integrated system to retrieve or to share information with other lines of business.
The integrated system receives and stores the VA MPI correlated person identifier from the upstream system.
The integrated system:
Does not establish a correlation with the VA MPI.
Does not communicate directly with the
VA MPI.
Only communicates directly (point to point) with the system that is correlated with the
VA MPI.
N/A N/A
Decentralized Hybrid
The supported business process:
Is a continuation of a business process started in another system that is correlated to the VA MPI.
DOES need the integrated system to retrieve information from other LOBs as a continuation to the business process.
The integrated system:
Receives and stores the VA MPI correlated person identifier from the upstream system Can use the VA MPI ICN as a trait, depending on the business/architecture need.
The integrated system:
Does not establish a correlation with the VA MPI.
Primarily performs local searches, but has the flexibility to search the VA MPI based on business need.
The integrated system:
DOES NOT store the ICN as a trait of the VA MPI Correlated Identifier.
DOES store ICN as a trait of the VA MPI Correlated identifier.
If the system stores the ICN, then the integrated system:
Will subscribe to and process the same VA MPI ICN notifications as the upstream system that is correlated to VA MPI.
Will be responsible for accurately responding to VA MPI ICN notifications based on a successful/unsuccessful processing of the event in its system.
Notes
The IdM business is notified when the VA MPI sends an update message and the hybrid system sends back an unsuccessful response.
The integrated system is seen as a "Site Association" by the IdM business owners
Available Service Operations:
GetCorrespondingIDs Search Retrieve with Corresponding IDs Retrieve with Orchestration Retrieve with Register Interest
NOTE: For a consumer that does not register an interest in the correlated identifier, that business owner of that consuming system accepts the risk the data becoming stale, due to not receiving updates and trait changes applied to the correlated record.
or as an extension of the VA MPI Correlated person Identifier.
Repository Pattern
Repository systems store data for an external system as part of that external system’s business process.
Repository systems store data for an external system as part of that external system’s business process.
When gathering data about an individual, the consumer looks for all VA MPI-correlated iden�fiers related to the iden�fier provided by the external system.
The list of identifiers may be obtained in one of the following ways:
The external system provides the consumer with a single identifier.
The consumer (repository system) calls VA MPI's Get Corresponding IDs service to obtain the VA MPI correlated identifier(s) of the record in the repository.
As part of an upstream process, the external system may have already obtained the list of identifiers from VA MPI, and have the capability to submit multiple identifiers. In this case the consumer searches internally using the identifiers provided and not interact with VA MPI.
Available Service Operations:
GetCorrespondingIDs
Interfaces The VA MPI service provides both user and application interfaces. The Identity Management Toolkit (IdM TK) user interface enables privlege users to manage VA identities. The VA MPI service provides an application interface for the creation, modification, or retrieval of identity information. The user and application interfaces provided by MPI are identified below.
Application Interfaces
The VA MPI integration pattern is summarized in the following table.
Pattern What does it do?
VA MPI Web Service Interface
The VA MPI exposes web services to applications to add, update and retrieve identity information. The web services are implemented using SOAP HL7v3. Refer to MPI Service Description document for details on the service.
VA MPI
REST Interface
The VA MPI exposes a HL7 Fast Healthcare Interoperability Resources (FHIR) based API to applications to add, update and retrieve identity information. Refer to the MPI FHIR specification for details on the service
VA MPI MLLP
Interface
The VA MPI exposes a Miminal Lower Level Protocol (MLLP) HL7 v2.4 interface. Refer to the VA MPI HL7 Interface Specification for details on the service.
User Interfaces
The Identity Management Toolkit (IdM TK) user interface allows for privlege users to manage VA identities.
Pattern What does it do?
Identity Management Toolkit User Interface
Provides a UI for privlege user management of VA identities. This includes resolving duplicates, correcting data, reviewing potential mismatches and more.
National Institute File Update Process
1. iPM completes template
Current template [Last Updated April 2023]: Facility Identifier Request Template.pdf Confirm uniqueness of Name and SenderID to Station Number Confirm station number follows format (3 digits followed by 4 alpha characters; 7 max) https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Documents/MPI/VA_MPI_Service_Description.pdf https://ps.dev.iam.va.gov/iam/mpi/fhir/r4/ https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Documents/MPI/mpif_1_0is.doc https://dvagov.sharepoint.com/sites/OITEPMOIAM/playbooks/Documents/Facility%20Identifier%20Request%20Template.pdf
Confirm length of name meets requirements (min 3, max 30) iPM sends completed form to Chad Oglesbee for approval
CC Development Group: Danny Reed, Chris Chesney, Cory Chin, Patrick Kiboti, and Deanna Wolford CC VA Leadership Support: Giselle Hernandez-Bethea and Laurie A. Wolfschlag
2. After Approval, iPM sends form to the VAFSC CAO Program Office VAFSCCAOProgramOffice@va.gov (POC is Evelyn Page <Evelyn.Paige2@va.gov> and is included in the DL.)
3. Evelyn reformats the request and forwards to Danny for approval
4. After approval, Evelyn sends the form to VAFSC Station Numbering VAFSCStationNumbering@va.gov for national distribution
5. VAFSC contacts the Development Group
The Development Group is comprised of the staff CC'd when the initial form is routed for approval Development Group verifies change has been deployed to production (table updated correctly and pushed to VA MPI) Development Group sends confirmation message that request has been processed mailto:VAFSCCAOProgramOffice@va.gov mailto:Evelyn.Paige2@va.gov mailto:VAFSCStationNumbering@va.gov
File details come from the government source that posted it. Updated .