department-of-veterans-affairs / abd-vro Goto Github PK

We’d like to know where we can get information on:

• What conditions Vets have claimed in the past,
• What they were rated, and
• What that information looks like from those data sources

Yoom’s comment on the sprint planning notes page:

As part of the Form526Submission record, there is a treatments JSON entry that is related to this data.

This ticket is for Sprint Xingu and Y.

Some links

• https://www.baeldung.com/spring-mvc-annotations
• https://www.baeldung.com/spring-boot-annotations
• https://github.com/yoomlam/camelapp#camel-routes

There are more comprehensive tutorials online.

Identify and document at a high level what we think the migration steps would be, noting open questions/assumptions/potential risks

Add Camel to our VRO codebase. This also involves setting up a RabbitMQ container.
This is needed for Amida folks to start contributing.

Refer to https://github.com/yoomlam/camelapp

Activities include

• Remove PII / PHI from notes and transcripts
• delete all recordings [including those that are saved in the Teams chats]
• delete all files (including transcripts) that are not saved within the hypertension RRD Team space

IBM expects to have the handshake / connectivity test endpoint available in the first week of May; we will need to participate in testing it at that point

To obtain your bearer token, use the following command:

-header 'Content-Type: application/x-www-form-urlencoded' \
-data-urlencode 'grant_type=client_credentials' \
-data-urlencode 'scope=openid' \
-data-urlencode 'client_id=va_gov_test' \
-data-urlencode 'client_secret=82665781-77c1-4a98-8960-af077b918955'

CURL_PARAM="-header 'Authorization: Bearer $BEARERTOKENHERE'"
API_URL='https://viccs-api-dev.ibm-intelligent-automation.com/api'

The tokens expire in 5 minutes. After obtaining a bearer token, pass that as a header for any of the APIs like so:

curl --location --request GET "$API_URL/healthCheck" $CURL_PARAM

Handshake:

curl $API_URL/healthCheck $CURL_PARAM

pcInsertAnnotOnlyCollection: (Request_EXTRACTED_Data)

 -H 'Content-Type: application/json' \
 -d '{"vtrnFileId":"000000000", "vtrnFirstName":"Ray", "vtrnLastName":"Chu", "conditions":["ASTHMA"],"startDate":"01/01/2021", "endDate":"02/02/2022"}'

pcCheckCollectionStatus: (Query_EXTRACTED_Data_Status)

 -H 'Content-Type: application/json' \
 -d '{"collectionsIds":[239],"collectionsId":239}'

pcQueryCollectionAnnots: (Return_EXTRACTED_Data)

 -H 'Content-Type: application/json' \
 -d '{"collectionsId":"239"}'

• Conduct 4 interviews with RVSRs
• Decide if we want to interview coaches
• Data preparation (notes)

Discussion Guide

Notes and recordings folder (Teams/Sharepoint)

Analyze, synthesize, and write up research with 4 RVSRs. See issue #22 for part 1.

Analysis mural

Report in notion

Add (Ruby) PDF generator v1 (given all pdf contents as request parameters)

Assumption: we're moving internal documentation to Sharepoint ✅

Potential next steps:

• Confirm we can access Sharepoint easily on our Macs/non-GFEs ✅
  I know we need a PIV card and PIV card reader to set up access the first time
  After that, do we still need to have our PIV card connected? no.
• Ask team to purchase PIV card reader and expense it? 🔖
• Confirm if we are going to use the Sharepoint space/group that Zach created? Decided to create a new one ✅
  I noticed random emails getting sent to the test rrd group he created, so may need to look at that.
• Draft information architecture? Decided to create folders as needed and re-organized later ✅
  Set up a MVP framework that we can experiment with
• Create + communicate migration plan 🔖
  Start by migrating the most relevant documentation like the Presumptives brief and related notes and use Sharepoint for that "Epic" moving forward (so migrate things epic by epic)
• Set milestones 🔖

Background

Work with Andrew Gray and Alejandro Mediaflores to get in touch with a VSO Liason. This person will help us recruit 3 people who work at VSOs for interviews.

Links

Doing research with VSOs: meeting with Melinda Bernardo Cuerda

Meeting with Melinda Bernardo Cuerda about VSO research (depricate)

Open questions

Acceptance criteria

Interviews are scheduled

Activities may include

• work with the folks mentioned above
• figure out how to support them in recruitment and get them what they need
• Define what our ‘ask’ is (who we want to talk to, how many, from which VSOs (likely in collaboration with Andrew and/or Alejandro)
• [ ]

Out of scope

Comments from Notion:

Amy (4/25/22)
Kim Matt Yoom Shannon we can use this task to track asthma claim shadowing (with Boise RVSRs) and bug fixing (as needed) unless you think it’s easier to track design & eng work separately

Side question @shannon Ford, are you all using the design or design research tag?

Shannon (4/25/22)
Amy It depends on the task - if it is research focused, then we use design research but if it is design only (i.e., sketching PDF concepts, QA for a PDF implementation), then design

Yoom (5/5/22)
Found a problem during EVSS submission: https://www.notion.so/Dashboard-RRD-Health-Evidence-24d77d9988a546c3b19a3c73e7ced29b?p=0b0660ea73c6440082950787d8d8f4d0

Yoom (5/17/22)
Since @allthesignals is the POC for “Monitor #rrd-tracking”, I assigned this to him. He also has access to the PDFs in S3.

low-priority refactoring task

LighthouseMedicationRequestData creates a Struct and returns a hash with with_indifferent_access, while LighthouseObservationData does not. Let’s make them consistent so we can follow a pattern for future transforms of external data.

Onboarding items tracking here:
Message in Slack

Capture some notes here:

• We don't need to notify LHDI about new team members unless those team members want access to LHDI's DataDog (generally for Devops to monitor our application), in which case we can ask Steven Bair (LHDI).
• In order for new team members to commit code to https://github.com/department-of-veterans-affairs/abd-rrd, they'll have to be added to https://github.com/orgs/department-of-veterans-affairs/teams/va-abd-amida/members or the parent team, which requires them to be in the VA GitHub org.
• Access to LHDI documentation requires they be in the VA GitHub org.
• Remind new members that https://github.com/department-of-veterans-affairs/Virtual-Regional-Office is not the correct repo to use.

Slack thread: https://dsva.slack.com/archives/C01BVF2A3V0/p1653455052802869

Hi all -- In response to the request for sharing big context things before you need to react to them, the next step on the presumptive work is to keep pushing our hypotheses forward and break them down into smaller bets, anticipated learnings, and then score them to pick where we'll start.

But since there's a lot going on and a lot we haven't discussed as a full team, we're going to take Kim's suggestion to split into teams and have a couple of mini workshopping sessions. Amy and I are still working on tidying this format tomorrow morning, but wanted to share the in-progress place where we'll conduct these workshopping sessions.

(We pulled that work back into Mural rather than the draft brief because during yesterday's sync we were feeling the need to diagram. And that felt fair. Sorry for the whiplash. We'll re-translate into document form if needed, after the workshopping activities outlined below.)

Goals

• Build a shared understanding of the approaches/first slices we could take to reduce claim processing time and VBA backlog burden
• Identify first steps we can take to achieve/learn X (baby milestones!)

How and when we'll work
Wednesday 5/25 (smaller team) + Thursday 5/26 (adding stakeholders):

• Split into 3 groups - teams penciled in for each bet. Feel free to respond to this thread if you feel strongly about being on a different team.
• Briefly review the bets/features/ideas for all of the 3 general approaches
• For your assigned approach, review/diagram the hypotheses. Split them, group them, draw them, discuss them.
• Name assumptions about how these things will reduce claim processing time
• Identify "first steps" we can take and what we will learn from them
• Identify open questions we still have

If needed, teams can choose to schedule additional coworking times or assign tasks/thinking to complete asynchronously.

Next Wednesday 6/1 (all)

• Regroup and share out with the other teams
• Do a RICE exercise to assess the reach, impact, confidence, and effort of each hypothesis/bet (at the "2A" level, not the main 3 approaches)
• Prioritize/decide on the first milestones based on the RICE 🍚

Note: it's likely that we'll take on hypotheses from each of the 3 approaches. think: 2A, then 3B, etc. so the grouping is somewhat arbitrary to break down the work to define them. We don't need to go with only one.

SubmitUploads retried several times -- why didn’t we get more Slack notifications?

• Hypotheses
  • The exception is not being raised from within a with_tracking block, which calls retryable_error_handler. This raises another exception instead of sending the Slack notification (both in base job and disability compensation job)

Notes (WIP)

• If a Form526Submission is successful, it submits the form to EVSS, saves the claim ID, and calls send_rrd_completed_notification to alert Slack if applicable

• In settings.yml the disability_compensation_form submit_timeout is set to 355 (~6 minutes)

• If the error is a Common::Client::Errors::ClientError and has a status of 503, then it raises a EVSS::DisabilityCompensationForm::ServiceUnavailableException

• EVSS::DisabilityCompensationForm::ServiceUnavailableException is rescued in SubmitForm526’s perform method, which calls the retryable_error_handler

• This first calls Form526JobStatusTracker retryable_error_handler which updates the job, logging, metrics, and re-raises the error

  • The error is rescued again as a EVSS::DisabilityCompensationForm::ServiceException which is mapped to evss.external_service_unavailable.
  • This calls retry_form526_error_handler! which checks if the error is retryable. It will be retryable as long as the message doesn’t have text 'EP Code is not valid’

• Form526 is set to retry 15 times with exponential backoff, which takes ~36 hours

• SubmitUploads is set to retry 14 times, ~ 1 day

  • RapidReadyForDecision DisabilityCompensationJob is set to retry 8 times (4.5 hours)
  • Calls retryable_error_handler - this re-raises the error if there’s a status_job_title (if raised within with_tracking block), which would re-raise the error before calling send_fast_track_engineer_email_for_testing meaning this wouldn’t get called
  • send_fast_track_engineer_email_for_testing is only called if not within with_tracking block

• with_tracking tries the job (job_try) and raises the exception again or says it’s successful

• We got a "Processed" notification b/c EVSS submission was successful. However some subsequent processing perform_ancillary_jobs (which includes submit_uploads and cleanup) are not complete.

• when a job is exhausted, job_exhausted is called

  • It will update the status of the Form526JobStatus to exhausted
  • If there are more BIRLS IDs to try, it will try again with one that hasn’t been used yet

• Rapid Ready for Decision (RRD) Job Errored is in base job and disability compensation job

• Retryable:

  • pif_in_use
  • external_service_unavailable and not EP Code is not valid

EVSS503:
<<: *external_defaults
title: Service Unavailable
code: 'EVSS503'
detail: 'The server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay'
status: 503

In support of Zach’s new role as OIT lead for Automated Benefits Delivery, identify any technical redflags in the new ABD vision and its technical implications.

• https://dsva.slack.com/archives/C01BVF2A3V0/p1651768252728769?thread_ts=1651609188.860109&cid=C01BVF2A3V0
• individual slides
• Timeline: https://dsva.slack.com/archives/C01BVF2A3V0/p1651778030413479?thread_ts=1651774005.173629&cid=C01BVF2A3V0

Welcome Automated Benefits Delivery to the Lighthouse DI Platform. You've all been successfully onboarded! When you all get a chance, please confirm your access to the cluster and namespaces by running through the following getting-started guide.

Once confirmed, you're free to deploy your applications onto DI, Here are some additional helpful documentation that can help you get started:
Home
Support
Roadmap
Available Services

The best place to reach our team is at the #team-honeybadgers-support Lighthouse Slack channel.

We mentioned in our meeting this morning that we would send over a few pieces of information:
Persistent Volumes:https://animated-carnival-57b3e7f5.pages.github.io/kubernetes/persistent-volumes/
SecRel Pipeline:https://github.com/department-of-veterans-affairs/lighthouse-tornado-secrel-pipeline

Context

In order to better understand how we can effectively serve veterans who will be newly eligible for presumptive claims due to the PACT Act, we want to interview veterans directly to better understand their perspective.

Links

• Mural for timeline and thoughts on learning goals
• OCTO Research and design guidelines
• VA Recruitment Tracker - copy

Activities may include

• Write research plan and conversation guide (in progress)
• recruit someone for the pilot session (and schedule it)
• Decide on time windows for interviews
• Coordinate with va.gov benefits team (new!)
• submit research plan to research repo

Out of scope

• work with Perigean on recruiting
• conduct interviews and synthesis

See procedure for manually collecting statistics: https://dsva.slack.com/archives/C01BVF2A3V0/p1651671896266909

Make queries less taxing on the DB by querying short time spans (like daily).

Consider automating this so we can get a daily report, but it's not straight-forward since RRD code is only triggered by Veteran's claim submissions.

https://dsva.slack.com/archives/C031RRFCHV1/p1653317122934169

Sally (5/11/22)

For claims that did not get established in EVSS, we need a way to undo the RRD steps that were executed. This is so that the claim can be re-submitted for establishment through the non-RRD process.

This would include removing the RRD metadata from the form-submission, removing the PDF, and any other changes to the submission specific to the RRD process performed for this claim.

Undoing RRD on a claim should be called manually and should only be for claims that were not established in EVSS.

https://github.com/department-of-veterans-affairs/abd-rrd/projects?type=beta

Current:

• When RRD checks EVSS for pending EPs and there’s no response, the claim will ramp off after 11 retries.

Desired:

• In the scenario above, RRD assumes there’s no pending EP and continues with RRD processing after 11 retries.

Assumption:

• Assuming the issue is rare, it would be better to proceed assuming there is no pending EP — because there is a chance of RRD-ing the claim and that benefit is greater than the risk of letting through an occasional EP400.
• Questions
  • Can we establish a RRD claim through EVSS if there is a pending EP? Or would the EVSS request fail? Current hypothesis is that we won’t be able to establish it
  • If we do RRD and it fails at EVSS, we can use the undo RRD code, and offramp reason of “EP exists”

Slack thread: https://dsva.slack.com/archives/C03296QM2GG/p1650992933290119?thread_ts=1650987048.270949&cid=C03296QM2GG

Options:

• Sharepoint
• etc.
• etc.

When the eFolder endpoints are built, the Mail Automation team may need us to participate in some manual testing to verify the endpoints are functioning. TBD on testing timeline and ask from MAS; the endpoints are scheduled to ship to production on May 16.

Review and understand the groovy and java files in the CamelApp.

• https://scoutapm.com/blog/java-for-rubyists
• https://www.guru99.com/groovy-tutorial.html
• Gradle uses Groovy https://www.tutorialspoint.com/gradle/index.htm

Ask questions.

After this task, the next task (for next sprint) will either be to understand Spring or Camel.

• https://www.baeldung.com/spring-mvc-annotations
• https://www.baeldung.com/spring-boot-annotations
• https://github.com/yoomlam/camelapp#camel-routes

Context:

• https://dsva.slack.com/archives/C01BVF2A3V0/p1653413668866069
• https://dsva.slack.com/archives/C01BVF2A3V0/p1653455052802869

Background

Other people, particularly the Lighthouse team, has done a fair amount of previous research on supplemental claims. This ticket covers reviewing that research and pulling some (very scrappy) insights or threads for further inquiry.

Open questions

Documents

• LH supplemental claim product brief
• 20211123 Supplemental claim discovery -- VSOs: Research report
  • VSOs will use a supplemental claim to reopen the timer on filing an appeal. VSOs perceive the Board to be more likely to give a favorable ruling.
  • Some mentions of a veteran not remembering filing a claim in the past, not having the previous denial, or not knowing which form to use.
  • Older veterans don't always trust digital submissions. Sometimes will want to submit the same claim both digitally and via paper, just in case.
  • Some VSOs like to submit PMRs themselves so they can ensure that the right evidence is in the file, rather than have the VA request those directly. This may have implications for what we can OCR from the eFolder.
  • VSOs sometimes use the Stakeholder Enterprise Portal (SEP) to submit a supplemental claim but that portal doesn't specifically handle 0995s. These end up getting labeled as 'correspondence.'
  • VSRs receive claims that are submitted on the wrong form, so those claims have to be canceled and the veteran has to file again on the right form. Sometimes that prompts the veteran to seek the help of the VSO.
• 20210928 Supplemental Claim Discovery - VA
  Administrators: Research Report
  • One of the biggest errors that claims assistants see is with missing or invalid signatures. When this happens they send a notice to the veteran and add a 30 day hold on the claim.
  • The 5103 checkbox on the form can waive the requirement that the VA send the POA notice to the veteran. Skipping this step can save 30 days processing time, but not all veterans or VSOs are aware of this. This is different from the 526ez.
  • Missing 4142/4142A forms can delay processing.
  • Recent changes meant that ITFs count for supplemental claims, but not all adjudicators are aware of it (or were at the time of this study). (Note: This was also true of VSOs)
  • supplemental claims are often submitted without additional evidence. This creates a lot of low- or no-value-add work on the part of the VA. (Note: could these be claims that are intended to reopen the appeals window?)
  • this is particularly true if the claim has already been denied many multiples of times in the past. This means it takes the R-VSR a lot of time to review the evidence and build the evidence list just to deny the claim.
  • the issue of a veteran submitting multiple single issue claims happens with supplemental claims as well, which creates more back end headaches. This is compounded with many of those issues have been denied multiple times already.
  • documents come in with incorrect file names, which then adjudicators have to correct. a supplemental claim form could be hiding out as a different type of document.
  • VSRs and RVSRs will edit the contention names in Caseflow.
• 20220131 Supplemental Claim Discovery - Veterans:
  Research Report
  • Veterans don't understand what it means to say that they have or have not received the duty to notify form, which is a yes/no question on the supplemental form (not on the 526 form). Checking 'no' means more time processing the claim.
  • Non veteran claimants have their own set of challenges, not fully explored in this research.
  • Veterans don't understand what counts as 'new and material' evidence to support their supplemental claim.
• Supplemental claims high level workflow diagram
• Lighthouse Mural of AMA processes
• Mural of supplemental claims high level workflow
• Supplemental Claims 101

Lighthouse specific research

Below links are from VSO Research aggregation

• 2019 10 VSO Appeals (HLR) Discovery
• VSOs COVID effects
• VSO Appeals (NODs) Discovery
• Previous mistakes in decisions are hard to correct. VSO reps try not to include specific dates or issues in appeals because they see those as potentially leading to a negative outcome for the veteran.
• VSOs don't like it when veterans use ebenefits to manage their claim because 'they mess it up'
• Many people at a VSO will work on an appeal – it's a team effort. Authentication and permissions to various software does not support this.
• Appeals statuses (and claims statuses) aren't particularly descriptive or useful. VSOs will call the Board to find someone who can give an update (cost for the VA and the VSO)
• another example of a veteran forgetting that they had an appeal in process and so they submitted a new appeal on the same thing
• VSOs POA Experience
• Representatives do not get notified when access to VBMS has been turned on or when they lose power of attorney, which happens often.
• Representatives main goal is to get their claims in front of the right adjudicator quickly, and they will use the systems available to accomplish this goal

VA.gov research

• Find/appoint Rep functionality BROKEN LINK
• 526 Self Service Claims for Increase BROKEN LINK
• VSO Journey Map - Disability Comp Claim

Other

• CSRA Profile readout Note: well worth reading!

Distills findings into the following seven principles. Has sacrificial concept sketches that are good idea fodder.

1. GIVE ME ACCESS
Facilitate my effective use of VA services by giving me tools that are accessible and useable, regardless of my age or ability.
5. CONNECT ME
Introduce me to people that can grow my knowledge of VA services and link me to services I am entitled to.
2. ENABLE ME
Provide me with personal and actionable information to reduce the burden I feel and allow me to positively engage with VA.
6. HELP ME
Direct me to specific answers to my questions, accurate information, and helpful people to talk to.
3. SECURE ME
Show me that you're keeping my personal information secure.
7. SUPPORT ME
Guide me through my VA experiences in a way that is as relevant as possible to me and my family.
4. RESPECT ME
Show that you know and value me by giving me relevant advice based on my personal experiences and information.

Out of scope

As the first step towards being able to pass claims to the Mail Automation System for processing, we need to be able to detect single issue claims for increase submitted via [va.gov](http://va.gov) for the following contentions:

• prostate cancer (diagnostic code: 7528)
• sleep apnea (diagnostic code: 6847)
• rhinitis (diagnostic code: 6522)
• sinusitus (diagnostic codes: 6510, 6511, 6512, 6513, 6514)

Code should be added to detect these, and added to an alert to the #rrd-to-mas-tracking slack channel to confirm that we’re successful.

Email address: [[email protected]](mailto:[email protected])

We would probably want to turn off those notifications relatively quickly after verifying that it’s working, since we won’t be doing the RRD processing and tracking of these claims.

Put behind flippers to turn off notifications in case there are too many

Background

Links

2022-04 Prostate cancer discovery research

Open questions

Acceptance criteria

Activities may include

• team synthesis

Out of scope