-
Notifications
You must be signed in to change notification settings - Fork 19
Power of Attorney (POA)
Power of Attorney (POA) is the legal authority claimants can grant to another person or organization in their Appeals process. The VA has copious documentation on the topic. POA is most often assigned to a Veteran Service Organization (VSO) or private attorney.
This document describes the technical underpinnings of determining POA for a given claimant.
The VBMS veteran identifier. It may be either a SSN or a claim folder number.
Associate the records for all claimants and beneficiaries to a claims folder number. There are two types of claims folder numbers used by the Veterans Benefits Administration (VBA) based on the Veteran’s Social Security number (SSN), or an eight-digit claims folder number assigned through the Beneficiary Identification and Records Locator Subsystem (BIRLS).
The 9-digit number assigned by SSA.
The 8-digit number assigned by VA (BIRLS).
The internal identifier used by BGS to uniquely track entities. Every Veteran, Claimant, Person, Organization, etc, has a unique participant ID.
Given a file number 12345678
and a Caseflow or eFolder Express (EE) user with CSS ID THE_USER
there are multiple pathways to determining POA. Some questions to consider:
- Is the claimant the Veteran?
- Is the Veteran deceased?
- Is the resource
THE_USER
wants to view allowable under POA rules?
In order to illustrate the full logical flow from the BGS perspective, we'll show examples via BGS API calls. Note that both Caseflow and EE have convenient wrapper methods for most of these.
Check the veteran_is_not_claimant
column on the Decision Review.
If the column value is true
then refer to the claimants
table to identify the PID for the claimant.
If the column value is false
then refer to the veterans
table to identify the PID for the claimant.
The resource in question in EE is the efolder itself, so there is no specific claim to check against.
Instead, fetch all the claimant PIDs for all the claims associated with the file number:
> bgs = BGSService.new
> claims = bgs.client.benefit_claims.find_claim_by_file_number(12345678)
> claimant_pids = Array(claims).flatten.map { |claim| claim[:ptcpnt_clmant_id] }.uniq
And compare the Veteran's PID against claimant_pids
to see if there are any that are not the Veteran.
> vet_record = bgs.client.veteran.find_by_file_number(12345678)
> vet_pid = vet_record[:ptcpnt_id]
> [claimant_pids - [vet_pid]].flatten.any?
If the result is true
then the answer is "maybe".
If the result is false
then the answer is "no".
BGS reports this as "date of death".
> vet_record = bgs.client.veteran.find_by_file_number(12345678)
> vet_record[:date_of_death].present?
The VBMS Core POA User Role Access matrix can be a helpful tool for determining the relevant POA rules. Note that the answer to the first two questions will help you determine the specific rules that apply.
Assuming you have answered all three questions, you can correlate whether THE_USER
has a POA relationship with file number 12345678
according to the following logical flow.
You can see all these examples at work in the EE UserAuthorizer tests.
Both Caseflow and EE have a convenience wrapper around the BGS API for this:
> user = User.find_by_css_id 'THE_USER'
> user.participant_id
> poa_orgs = bgs.client.org.find_poas_by_ptcpnt_id(user.participant_id)
> poa_org_pids = poa_orgs.map { |org| org[:ptcpnt_id] }
Is there a POA record for the file number that matches the User's POA organizations?
> fn_poa = bgs.client.claimants.find_poa_by_file_number(12345678)
> poa_org_pid = fn_poa&[:person_org_ptcpnt_id]
> poa_org_pids.include? poa_org_pid
Find any intersection between the User's Org POA PIDs and the claimant's POA Org PIDs.
> claims = bgs.client.benefit_claims.find_claim_by_file_number(12345678)
> claimant_pids = Array(claims).flatten.map { |claim| claim[:ptcpnt_clmant_id] }.uniq
> claimant_poa_org_pids = claimant_pids.map do |claimant_pid|
org_poa = bgs.client.claimants.find_poa_by_participant_id(claimant_pid)
org_poa[:person_org_ptcpnt_id]
end
> poa_org_pids.intersection(claimant_poa_org_pids).any?
- Home
- Acronyms and Glossary
- Caseflow products
- Caseflow Intake
- Caseflow Queue
- Appeals Consumer
- Caseflow Reader
- Caseflow eFolder
- Caseflow Hearings
- Caseflow Certification
- Caseflow APIs
- Appeal Status API
- Caseflow Dispatch
-
CSUM Roles
- System Admin
- VHA Team Management
- Active Record Queries Resource
- External Integrations
- Caseflow Demo
- Caseflow ProdTest
- Background
- Stuck Jobs
- VA Notify
-
Caseflow-Team
- Tier 4
- Bat Team
- Technical Documentation
- Backend Code Patterns
- Backend Working Group
- FACOLS, VACOLS DB Schema
- Asyncable Models
- External Data: where and why
- Data Fetching Scripts
- Caseflow Data Model and Dictionary
- User Access Permissions
- Controller Schemas
- Constants
- Frontend Best Practices
- Accessibility
- How-To
- Debugging Tips
- Adding a Feature Flag with FeatureToggle
- Editing AMA issues
- Editing a decision review
- Fixing task trees
- Investigating and diagnosing issues
- Data and Metric Request Workflow
- Exporting and Importing Appeals
- Explain page for Appeals
- Record associations and Foreign Keys
- Upgrading Ruby
- Stuck Appeals
- Testing Action Mailer Messages Locally
- Re-running Seed Files
- Rake Generator for Legacy Appeals
- Manually running Scheduled Jobs
- System Admin UI
- Caseflow Makefile
- Upgrading Postgresql from v11.7 to v14.8 Locally
- VACOLS VM Trigger Fix M1
- Using SlackService to Send a Job Alert
- Technical Talks