# VHA Unrecognized Veterans technical solutioning
## Steps we know we'll ultimately need to take
- [ ] External partner concensus on proposed approach
- [ ] VHA ART engineering concensus on proposed approach
- [ ] VHA ART business concensus on proposed approach
- [ ] Appeals leadership concensus
- [ ] OIT concensus
- [ ] VHA concensus
## Action items
* Capture and compare the object formatting of veteran records from the respective possible sources as well as current record returns from BGS/corpDB
## General open questions
* How are we going to be handling retrieving veteran records from a new resource?
* Could this be accomplished with a migration to the existing veterans table or would we perhaps require an additional table
* How are we going to be handling the possibility of potential multiple record returns?
* Ultimately, what we're looking for are 1:1 fields on the objects that correlate to our existing veteran [table](https://github.com/department-of-veterans-affairs/caseflow/blob/master/db/schema.rb#L1827-L1845)
* That said, at the very least we are aware of the *possibility* that we may need to begin utilizing ICN as an identifier (which could potentially be accomplished in a migration)
* Would we need to modify every existing veteran record with this or could we instead approach it by allowing a null/no default value and populating those records in an iterative fashion
* At the same time, we believe that we can accomplish a successful implementation without usage of ICN at least through Veteran API as we should be able to search those records by file number
## Integration Options
### VA Profile
- Rebrand of Vet360
- Queries MPI and CorpDB to get any data that would be relevant to Caseflow
### MPI (connect_mpi gem)
* How are the current MPI endpoints being utilized?

connect_mpi:
- Is a wrapper for the Savon gem that abstracts the configuration process
- Gem `nokogiri` is used to generate the XML used in SOAP requests
- Provides a single method: search_people_info
- search_people_info takes in params from Caseflow, then builds a partial XML request based on what params were provided
- That partial XML is passed to build_request_xml which then creates the full XML body for the SOAP request
- Savon parses the SOAP return from MPI into an object that is processed to get the response data
- response[:envelope][:body], then [:prpa_in201306_uv02][:control_act_process] to get the veteran data
- The only parameters that are **always** provided in the search_people_info request are first/middle/last name; SSN, DOB, gender, address, telephone are all optional in the gem
- New methods could be added to the gem as classes
- MPI::Base is the base class
- PersonWebService inherits from Base
- New methods would likely be contained in their own class also inheriting from Base
### Veteran API:
Multiple API endpoints provided for searching:
- /api/v1/veteran
- Uses a VeteranRequest object for searching (provide Identifier Type (FileNumber or Participant ID) and value)
- Returns a VeteranResponse object wrapping a status message and Veteran object
- /api/v1/veteran/search
- Uses a SearchQuery object (containing search type and veteran's identifying information to search)
- Returns a VeteranResponse object wrapping a status message and Veteran object
- /api/v1/veteran:search
- Uses a SearchQuery object (containing search type and veteran's identifying information to search)
- Returns a VeteranResponseList object wrapping a status message, token, and array of Veteran objects
- /api/v1/veteran/basicInfo
- Uses a VeteranRequest object for searching
- Returns a VeteranBasicInfoResponse wrapping a message and VeteranBasicInfo object

/veteran/search and /veteran:search both reference MVI in their description; does this refer to MVI/MPI (Master Veteran Index was a previous name for MPI)?

Appears to use JSON Web Tokens in HTTP Headers for authorization; not sure how this would work for us

Several references in the API docs to ICNs (Internal Control Number) used by MPI; implies that this API goes to MPI?

Veteran objects contain:

VeteranBasicInfo objects contain:

Misc:
https://github.com/department-of-veterans-affairs/bip-veteran-api/blob/33e8a58a5620628ad4ccd0d81fa3b184f43c0aea/bip-veteran-api/src/main/java/gov/va/bip/cfapi/veteran/data/VetRecordDataServiceImpl.java#L490
- one search method that appears to go through a default service, then CorpDB, then birls (idk what that is)
- default service looks to be BGS, https://github.com/department-of-veterans-affairs/bip-veteran-api/blob/33e8a58a5620628ad4ccd0d81fa3b184f43c0aea/bip-veteran-api/src/main/java/gov/va/bip/cfapi/veteran/client/VetRecordServiceGatewayImpl.java#LL175C40-L175C40
- BIRLS looks like it comes from BGS as well but may be a different object/information, https://github.com/department-of-veterans-affairs/bip-veteran-api/blob/1382c5e0bfb3d9bf163267390205e57045306c4a/bip-veteran-api/src/main/java/gov/va/bip/cfapi/veteran/client/VetRecordServiceGatewayImpl.java#L3
### Open Questions
* **Potential gem creation**: does it make sense to create a gem for our integration?
* if we need to do auth with user ids & station ids it might not make sense to utilize a gem
* **CorpDB record creation**: We know from speaking with David Hamilton that creating veteran records retrieved from MPI via Veteran API is indeed not only a possibility but something already in place for VBMS users. However, we need to continue to look into what all would be required from a Caseflow perspective in order to allow our users to have access to this same ability
* One potential avenue of approach is looking into existing CSEM roles (spcifically "BVA Admin") to see if having that role on users would allow them to establish those records
* David also mentioned potential changes on the Veteran API side which would essentially determine if the API was being accessed from Caseflow with a particular user type, it would allow for the record creation
* Is the record creation process in corpDB from MPI synchronous or async? The answer likely will impact our implementation as if that corpDB record is NOT immediately created and accessible we would likely need to account for that in some fashion