VBMS Documents not Available in Caseflow

[araposo-tistatech]

Attorneys and VLJs are indicating that Reader is not pulling all the documents from VBMS when staff is reviewing appeals.

This appears to have begun around April 8th.

Examples provided below:
https://appeals.cf.ds.va.gov/queue/appeals/3314680 - the entirety of this veterans claims file was not showing in Reader. The attorney could not view any documents past October 2018, while VLJ White could see 30 additional documents. Attorney went to VBMS to view documents

https://appeals.cf.ds.va.gov/queue/appeals/3621614 - Case was reviewed by VLJ White and was missing documents. VLJ White went to VBMS to view all documents.

https://appeals.cf.ds.va.gov/queue/appeals/3765285 - Reported on Tuesday, VLJ White did not have IHP available in Reader. IHP was available in VBMS.

https://appeals.cf.ds.va.gov/queue/appeals/dd3c3db8-bb37-4ea1-8166-7863118ce5ff - VLJ LeBoff could not find IHP in Reader, however it was uploaded into VBMS in December 2019.

Acceptance criteria

• Ensure all VBMS documents are loading and displaying in Reader

Background/context

Slack Conversation

Technical notes

Other notes

Resources/other links

[yoomlam]

TLDR: Users have added their own tags to IHP docs in Reader, so problems may have gone away.

DocCount is shown on Case Details page.
Reader’s Total is shown in Reader.
VBMS and VVA counts are shown in eFolder.

Logged-in as myself:

Case	DocCount	Reader’s Total	VBMS docs	VVA docs
3314680	289	289	266	23
3621614	138	138	124	14
3765285	112	112	100 120	12 99
dd3c3db8	149	149	129	20

Logged-in as BVAJWHITE (doesn’t have access to eFolder!): can see same doc counts.

3314680

I can see documents with receipt date after Oct 2018.

3621614

Found IHP doc (with tags "IR Back" and "IR HTN")

3765285

Found IHP doc (with tag "SC-CD, DIC")

dd3c3db8

Has 2 IHP docs (4/8/2020 and 12/3/2019)

Note: No Vet ID shown in Reader!

Logged in as BVAESLEBOFF (doesn't have access to eFolder!), able to see all 149 docs in Reader.

[araposo-tistatech]

@yoomlam Can we explain the discrepancy in the doc count for 3765285 or are the document counts for VBMS & VVA Docs incorrect in the table?

[yoomlam]

@araposo-tistatech I double-checked those numbers and there is no discrepancy. I must have gone to the wrong tab when typing in the numbers.

[yoomlam]

The doc count for Case 3621614 went up by 1 to 139 (125 + 14) due to a new "BVA Decision" document with receipt date of today. At least the counts are consistent between Case Details page, Reader, and eFolder.
Document counts for the other cases have not changed.

[araposo-tistatech]

Issue unable to be replicated, closing.

[araposo-tistatech]

Per the Board, another user has encountered of the document count being different in Caseflow.

In the situation the attorney M. Mahmoudi was working on this appeal, while working the case Reader had the document count at around 311 documents. Upon completion of the decision drafting task and sending the decision to the judge (J. White) for review the judge saw and reviewed 425 documents in Reader.

When the case was routed back to the attorney for a re-write the attorney noticed there were over 100 documents that were not reviewed by him originally on the case.

The Board believes there could be some sort of timing issue when loading the documents, but I do want to note that in the screenshots provided the document count in VBMS was 397 while Readers is 425.

Can we continue looking into this? The Board is concerned this will cause a lack of trust in Caseflow.

[araposo-tistatech]

Could this be a cache issue?

[yoomlam]

Could this be a cache issue?

I don't think so. From what I can tell in the code, only these 2 things are 'cached':

• EFolder document counts are cached (app/services/external_api/efolder_service.rb:8), and it expires in 4 hours (app/services/external_api/efolder_service.rb:33).
• VBMS documents are "cached" (retrieved from VBMS then saved in S3) if it does not already exist in S3 (code). This is triggered when VBMSService fetches the document (code).

Additionally, for a document to be cached, it must first be retrieved. 426 docs were created in Caseflow's DB on these dates:

• [Mon, 23 Mar 2020, 421],
• [Fri, 24 Apr 2020, 2],
• [Sun, 26 Apr 2020, 3]

These docs are created by DocumentFetcher (code) once they have been retrieved. DocumentFetcher uses 2 document_services (EFolderService and VBMSService code) to do retrieval.

[yoomlam]

appeal.treee :id,:status,:created_at,:assigned_at,:updated_at
                                         ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
Appeal 16082 (evidence_submission) ───── │ ID     │ STATUS    │ CREATED_AT              │ ASSIGNED_AT             │ UPDATED_AT              │ CLOSED_AT               │
└── RootTask                             │ 314464 │ on_hold   │ 2019-08-07 15:06:14 UTC │ 2019-08-07 15:06:14 UTC │ 2019-08-07 15:06:14 UTC │                         │
    ├── DistributionTask                 │ 314465 │ completed │ 2019-08-07 15:06:14 UTC │ 2019-10-21 00:30:18 UTC │ 2020-04-14 18:49:46 UTC │ 2020-04-14 18:49:46 UTC │
    │   └── EvidenceSubmissionWindowTask │ 314466 │ completed │ 2019-08-07 15:06:14 UTC │ 2019-08-07 15:06:14 UTC │ 2019-10-21 00:30:18 UTC │ 2019-10-21 00:30:18 UTC │
    ├── JudgeAssignTask                  │ 826685 │ completed │ 2020-04-14 18:49:46 UTC │ 2020-04-14 18:49:46 UTC │ 2020-04-20 11:40:41 UTC │ 2020-04-20 11:40:41 UTC │
    └── JudgeDecisionReviewTask          │ 837873 │ assigned  │ 2020-04-20 11:40:41 UTC │ 2020-05-12 11:53:57 UTC │ 2020-05-12 11:53:57 UTC │                         │
        ├── AttorneyTask                 │ 837874 │ completed │ 2020-04-20 11:40:41 UTC │ 2020-04-20 11:40:41 UTC │ 2020-04-28 09:46:47 UTC │ 2020-04-28 09:46:47 UTC │
        └── AttorneyRewriteTask          │ 863547 │ completed │ 2020-04-29 14:30:06 UTC │ 2020-04-29 14:30:06 UTC │ 2020-05-12 11:53:57 UTC │ 2020-05-12 11:53:57 UTC │
                                         └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Timeline:

• Mar 23: 421 documents were retrieved by Caseflow
• Apr 20 Judge assigns to atty
• Apr 21 Atty starts to view 309 docs on these dates:
  [Tue, 21 Apr 2020 00:00:00 UTC +00:00, 303],
  [Wed, 22 Apr 2020 00:00:00 UTC +00:00, 2],
  [Mon, 27 Apr 2020 00:00:00 UTC +00:00, 4]]
• 5 more documents were retrieved by Caseflow
  [Fri, 24 Apr 2020, 2],
  [Sun, 26 Apr 2020, 3]
• Apr 28 Atty completes AttorneyTask
• Apr 28 Judge views 32 docs
  [[Wed, 29 Apr 2020 00:00:00 UTC +00:00, 22],
  [Tue, 28 Apr 2020 00:00:00 UTC +00:00, 10]]
• Apr 29 Atty assigned AttorneyRewriteTask
• May 6 Atty views 93 docs for the first time on these dates:
  [Wed, 06 May 2020 00:00:00 UTC +00:00, 21],
  [Mon, 11 May 2020 00:00:00 UTC +00:00, 71],
  [Tue, 12 May 2020 00:00:00 UTC +00:00, 1],
• May 12 Atty completed AttorneyRewriteTask

It seems the documents were fetched before the attorney was assigned the case. The Reader UI should have reported at least 421 documents.

[araposo-tistatech]

Posted this to the wrong ticket:

@hschallhorn now that we've opened new tickets, should we close this one out? Also, just a reminder of the following notes from Troy:

1. Logs show March 23 there were 421 documents downloaded but user claims on April 21 that not all documents were in Caseflow. Does Caseflow use what is in Caseflow storage at the time the user views the record in Caseflow to report the number of documents or does it make a call to VBMS at the point in time of user action? If the former, then an incorrect number in Caseflow would have nothing to do with VBMS.

2. I’ve been told that if a document isn’t viewed within 2 weeks of download, it is removed from Caseflow storage. The date of download (March 23) to the date the user tried to view (April 21) is more than two weeks. Is it possible another user viewed the 309 documents within two weeks of April 21, hence those persisted but the others weren’t viewed and removed from storage after 2 weeks (April 4)? And the user failed to hit the refresh button so the missing documents didn’t refresh into Caseflow storage, hence the lower # of docs?

[hschallhorn]

From Yoom:

Something to consider when investigating: the current_user is passed to fetch documents:

caseflow/app/services/document_fetcher.rb

Line 81 in 24ed3d3

doc_struct = document_service.fetch_documents_for(appeal, RequestStore.store[:current_user])

VBMS doesn't use it:

caseflow/app/services/external_api/vbms_service.rb

Line 33 in b3441c2

def self.fetch_documents_for(appeal, _user = nil)

but eFolder does make use of the user:

caseflow/app/services/external_api/efolder_service.rb

Line 35 in d3f2ab6

response = send_efolder_request("/api/v2/document_counts", user, headers)

Questions to consider during investigation:

• What triggers the initial document fetch? Who is the current_user?
• Does the current_user have access to all documents (when eFolder fetcher is used)?

[yoomlam]

Added more notes in Part 3 -- nothing conclusive yet.