-
Notifications
You must be signed in to change notification settings - Fork 19
HLR DTA Error
Do not run if the following as occurred during the claim process; Reassign to Tier 2 for the EU to process a 930.
Based on the training documents and information in the VA knowledge repository, the procedures to correct these EPs would be to establish a 930 for correction control. This can be done by the end user directly. EP 930s should be created if:
• An EP has missing or incorrectly named contentions.
• An EP has been cleared or cancelled by mistake.
• An EP contains an incorrect or missing decision.
This SOP can be used to fix EP Establishment issues.
The VA has a duty to assist veterans with collecting evidence. If the VA is found negligent in this process with a Higher Level Review, the appeal must be auto-cested into a 040 disposition to continue processing. The HLR DTA EP bucket addresses situations in which there was an issue auto-cesting a 040 disposition from a 030 Higher Level Review. The Disposition Denied sub bucket addresses issues that can be resolved by changing the disposition of a claim from 'Denied' to 'DTA Error.' The No Decision Issues sub bucket addresses issues that can be resolved by adding the proper decision issues to the 030.
To resolve this issue we first look at the VA Form 20-0999 to determine the proper contentions to remand. We then run a series of manual steps that pass in the claim id associated with the ticket. A 040 will ultimately be auto-cested and the appeal can continue processing.
VBMS Initial Search
- Search in VBMS by claim id and click ‘Open claim.’ This should open a 030 Higher Level Review.
- If it does not open into a 030 Higher Level Review, we have the wrong claim id to run the remediation steps. Exit the SOP and check with your team lead to locate the correct claim id. There may not be a 030 HLR established for the claim.
- In the top right-hand corner, click on ‘Claims’ and check 'Include Inactive'. You should not see any 040 claims listed above the 030 claim.
- If you do see a 040 or 041 showing above the 030 in the veteran’s claim, with the same contentions, pause the SOP and check with your team lead before proceeding. This means there is already a 040 established, potentially for the contentions that were needed. This ticket may have already been solved, or it may have been established with the wrong contentions.
- If you see a 930 or 931 showing above the 030 in the veteran’s claim, with the same contentions, pause the SOP and check with your team lead before proceeding. This 930 may have reset the process for the 030. This would require the EU to process the 930 to establish the desired EP.
- In the top right-hand corner, next to claims, click ‘Documents.’ Scroll down to find the most recent document with ‘VA Form 20-0999' in the title. The ‘Date of Return’ in the 0999 form should match or be close to the Suspense Date on the 030 HLR. If it doesn’t match on the most recent 0999 form, look back further in Documents to see if you can find the right one.
- If there is no 0999 form with matching dates in the veteran’s documents, we cannot currently resolve this ticket. Exit the SOP
- Open the document and scroll to ‘Section 1: The Higher Level Review being returned relates to the following issues.’ Take note of the issues in a notepad (can be multiple).
- Now we need to contention match between what was found in the 0999 form. Scroll through the contentions on the 030 you just pulled up and identify the one that (roughly) matches the text from the 0999.
- For example, if the issue in 0999 was a left knee tear, the contention should say something about a left knee tear
- If nothing matches, we cannot currently resolve this ticket. Exit the SOP
- Scroll to the right on the identified matching contention to the ‘CaseFlow Disposition’ column.
- If the CaseFlow Disposition is listed as ‘DTA Error – xx,' follow the below steps titled DTA Error – xx.
- If the CaseFlow Disposition is listed as ‘Denied,’ follow the below steps titled Disposition Denied (skipping the DTA Error – xx steps)
Caseflow EP Status
- Open the claim in Caseflow. The URL to Caseflow cases should be in the SNOW ticket description and/or the Triage form.
- Ensure the claim date in Caseflow matches the claim date in VBMS.
- Check the EP status under the last column for the claim that matches.
- If the status does not show "Cleared", click the claim (blue URL) to load further details.
- Once the page loads, look under each contention for the status. If the status shows: "Cleared, waiting for decision.", we cannot process the SOP. Note: This page can take time to load.
- Notate the SNOW ticket that the EP status: "Cleared, waiting for decision" shows for the contentions and proceed with Tier 4 escalation procedures.
DTA Error – xx / Difference of Opinion
These steps only solve HLR DTA EP tickets that have a Disposition of DTA Error – xx and need to be remanded to autocest the 040.
Before running the steps you should have the following information in a notepad:
- Claim id
- List of issues from 0999 form
Run the following commands in the AWS production instance you opened:
- Connect to Rails
sudo su -
source /opt/caseflow-certification/caseflow-certification_env.sh; cd /opt/caseflow-certification/src; bin/rails c
RequestStore[:current_user] = User.system_user
- Set the claim id
claim_id = <claim id>
- Get End Product Establishment from Claim ID
epe = EndProductEstablishment.find_by(reference_id: claim_id)
If the console returns nil, then there is no EPE associated with the claim id.
We cannot currently resolve this ticket. **Exit the steps**
- Get Decision Issues
dis = epe.source.decision_issues
- Verify the claim has decision issues
dis.count
If dis.count returns 0, there are no decision issues associated with the EPE
and we need to create them.
Click [here](bookmark://No_Decision_Issues) to be taken to the No Decision
Issues resolution. Do not come back to these steps, as the ticket will be
resolved with the No Decision Issues steps.
- Remand the supplemental claim
epe.source.create_remand_supplemental_claims!
The call to remand the supplemental claim should have a lot of console output and should end with text that looks like “#<SupplementalClaim id: XXXXXXX, veteran_file_number: "XXXXXXXXX" …...” If this is the case, the manual steps are complete and you are ready to move on to the confirmation steps below.
Disposition Denied These steps only solve HLR DTA EP tickets that have a Disposition of Denied. Before running the steps you should have the following information in a notepad:
- Claim id
- List of issues from 0999 form
Run the following commands in the AWS production instance you opened:
- Connect to Rails
sudo su -
source /opt/caseflow-certification/caseflow-certification_env.sh; cd /opt/caseflow-certification/src; bin/rails c
RequestStore[:current_user] = User.system_user
- Set the claim id
claim_id = <claim id>
- Get End Product Establishment from Claim ID
epe = EndProductEstablishment.find_by(reference_id: claim_id)
If the console returns nil, then there is no EPE associated with the claim id.
We cannot currently resolve this ticket. **Exit the steps**
- Get Decision Issues
dis = epe.source.decision_issues
- Verify the claim has decision issues
dis.count
If dis.count returns 0, there are no decision issues associated with the EPE
and we need to create them. Skip to **No Decision Issues** section.
- Look at the description of the decision issues to identify the decision issue matching the contention/issue from the 0999 form. The disposition should say Denied.
pp dis
You should be able to identify the decision issue from the text in the 0999
form. The description of the decision issue should be similar (if the issue in
0999 was a left knee tear, the description should say something about a left
knee tear). Take note of the decision issue that matches the issue identified
in the 0999 form. For example, if the first decision issue had it, that’s
dis[0]. If the second one, then dis[1]. Third means dis[2] and so on. Write
dis[x] down in a notepad, replacing the x with the number correlating to the
correct decision issue.
- Update the disposition of the identified decision issue and remand dis[x].update!(disposition: "DTA Error") replace the x Starts at 0
epe.source.create_remand_supplemental_claims!
The call to remand the supplemental claim should have a lot of console output and should end with text that looks like “[#<SupplementalClaim id: XXXXXXX, veteran_file_number: "XXXXXXXXX" …...” If this is the case, the manual steps are complete and you are ready to move on to the confirmation steps below.
Claim ID:
claim_id = "insert claim id"
epe = EndProductEstablishment.find_by(reference_id: claim_id)
dis = epe.source.decision_issues
dis.count
RETURNS 0
v = epe.veteran
rais = v.ratings.map(&:issues).flatten
rais.count
pp rais[0]
rai = rais.select{|x| x.reference_id == ""}
new_di = DecisionIssue.create(
disposition: "DTA Error",
description: rai[0].decision_text,
participant_id: rai[0].participant_id,
decision_review_type: "HigherLevelReview",
decision_review_id: epe.source.id,
benefit_type: rai[0].benefit_type,
diagnostic_code: rai[0].diagnostic_code,
end_product_last_action_date:
epe.source.end_product_establishments.first.result.last_action_date
)
new_di.save!
***If you get the error ActiveRecord::RecordInvalid (Validation failed:
End product last action date can't be blank) run the following commands in console. (We just need to create the decision issue by sourcing the EP last action date elsewhere)***
new_di = DecisionIssue.create(
disposition: "DTA Error",
description: rai[0].decision_text,
participant_id: rai[0].participant_id,
decision_review_type: "HigherLevelReview"
decision_review_id: epe.source.id,
benefit_type: rai[0].benefit_type,
diagnostic_code: rai[0].diagnostic_code,
end_product_last_action_date: epe.last_action_date
)
OR
new_di=DecisionIssue.create(
disposition: "Difference of Opinion",
description: rai[0].decision_text,
participant_id: rai[0].participant_id,
decision_review_type: "HigherLevelReview",
decision_review_id: epe.source.id,
benefit_type: rai[0].benefit_type,
diagnostic_code: rai[0].diagnostic_code,
end_product_last_action_date:
epe.source.end_product_establishments.first.result.last_action_date
)
Now save and you should not get an error:
new_di.save!
dis.count
dis[*x*].update!(disposition: "DTA Error")
epe.source.create_remand_supplemental_claims!
- 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
- 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