Supplemental Claims | Weekly Check-In

[saderagsdale]

How to use this ticket

This is a daily checklist for monitoring the health of our release. Tasks for this ticket should be completed first thing at the beginning of each day, and reported to the internal team and key stakeholders. Below are the metrics used to gauge the health of the release. See these links for details on the release or rollback plan, and incident monitoring plan.

Links to the dashboard(s) showing "success criteria" metrics

• Google Analytics
• Domo (pending link from the platform team)
• Grafana - Claims and Appeals
• Grafana - Supplemental Claims
• Sentry

User experience metrics

Abandonment rate <20%
Contact Center calls due to inability to complete the form caused by technical error <2 calls

Error rate metrics

Green: "everything is going smooth" - < 0.1%
Yellow: "we should give this a look" - 0.1% - 0.5%
Red: "stop everything, we need to check this out" - > 0.5%
Evidence "gate check" metrics (thresholds will be higher - LH is used to a higher error rate through the Benefits Intake API):

Green: "everything is going smooth" - < 2.5%
Yellow: "we should give this a look" - 2.5% - 4%
Red: "stop everything, we need to check this out" - > 4% (edited)

---

Tasks

• Engineering: Post the FE and BE error metrics for the previous day, including the type of error and intervention needed.
• Product: Reach out to Kimberley Daniels for an update on Contact Center calls in #vsp-contact-center-support
• Product: Craft an update with input from engineering, share with Matt Self, Alejandro M, and LH Banana Peels team.
• Product: At the end of the 5-day observation period, get buy-in from Matt Self, Alejandro M, and LH Banana Peels team before increasing the release.
• Product: Communicate any changes in the release plan to the stakeholders above and update the release plan.

[dorseypa1]

Hi, I need access to the Dashboard Product Details related to this request. Thank you

[saderagsdale]

@saderagsdale add domo link and error page

[saderagsdale]

Backend Evidence Error Summaries
Upstream status: Errors: Batch Submitted with all blank Images.;
description: PDF was all blank pages (2)
occurrences: 1
resubmitted: no
mitigation plan: No further action taken, the veteran uploaded a PDF with 2 blank pages. DataDimensions strips out blank pages. If it does that, and then there are no pages left, it returns this error.
Non-string values for keys: zipCode
Description: Upload metadata zipCode was null
occurrences: 1
resubmitted: yes
mitigation plan: PR is in that will use the frontend submitted zip code as a backup, if the user’s info coming back from MPI has null (missing) zip code.
Maximum page size exceeded. Limit is 21 in x 21 in.
Description: PDF exceeded 21x21 dimensions
occurrences: 2
resubmitted: not yet, but working on it
mitigation plan: Lighthouse has removed their 21x21 check, this reduces the frequency of dimensional errors. Now, files up to 78x101 can go though. That is the limit of the NEXT downstream system (doma/datadimension). They are looking into if these can be removed, but very very very small % of evidence is exceeding this size. We have not hit another evidence submission dimensional error since lighthouse removed their 21x21 check, as most files that are over 21x21 are only slightly over, and still under the datadimension’s higher limit
pdfinfo exited with status 1 and message Syntax Error: Couldn’t find trailer dictionary\n\nSyntax Error: Couldn’t find trailer dictionary\n\nSyntax Error: Couldn’t read xref table\n
Description: Corrupt PDF file. Could not open it on any system in any way.
occurrences: 1
resubmitted: no
mitigation plan: No plan to do anything with this. The veteran uploaded this file in a corrupt state.
pdfinfo exited with status 1 and message Command Line Error: Incorrect password\n
Description: Lighthouse reports file has a password
occurrences: 1
resubmitted: no
mitigation plan: Investigating. This is not supposed to be able to happen. No PDF with a password should be able to get to Lighthouse. Our frontend prompts for the password and the backend should remove it before passing along.

[kylesoskin]

reformatted version of my above comment posted by @saderagsdale

==
Backend Evidence Error Summaries****

1. Upstream status: Errors: Batch Submitted with all blank Images.;

   1. description: PDF was all blank pages (2)
   2. occurrences: 1
   3. resubmitted: no
   4. mitigation plan: no further action taken, the veteran uploaded a PDF with 2 blank pages. DataDimensions strips out blank pages. If it does that, and then there are no pages left, it returns this error. There is not really anything else to do here in my opinion

2. Non-string values for keys: zipCode

   1. Description: Upload metadata zipCode was null
   2. occurrences: 1
   3. resubmitted: yes
   4. mitigation plan: PR is in that will use the frontend submitted zip code as a backup, if the user’s info coming back from MPI has null (missing) zip code. 

3. Maximum page size exceeded. Limit is 21 in x 21 in.

   1. Description: PDF exceeded 21x21 dimensions
   2. occurrences: 2
   3. resubmitted: not yet, but working on it
   4. mitigation plan: Lighthouse has removed their 21x21 check, this reduces the frequency of dimensional errors. Now, files up to 78x101 can go though. That is the limit of the NEXT downstream system (doma/datadimension). They are looking into if these can be removed, but very very very small % of evidence is exceeding this size. We have not hit another evidence submission dimensional error since lighthouse removed their 21x21 check, as most files that are over 21x21 are only slightly over, and still under the datadimension’s higher limit

4. pdfinfo exited with status 1 and message Syntax Error: Couldn't find trailer dictionary\n\\nSyntax Error: Couldn't find trailer dictionary\n\\nSyntax Error: Couldn't read xref table\n

   1. Description: Corrupt PDF file. Could not open it on any system in any way.
   2. occurrences: 1
   3. resubmitted: no
   4. mitigation plan: No plan to do anything with this. The file is corrupt in some way we are unsure of. I am not sure if we should do anything here with this to try and resolve? The veteran uploaded this file in a corrupt state, so… not much I can think of to do

5. pdfinfo exited with status 1 and message Command Line Error: Incorrect password\n

   1. Description: Lighthouse reports file has a password
   2. occurrences: 1
   3. resubmitted: no
   4. mitigation plan: still in progress/investigating. This is NOT supposed to be able to happen. No PDF with a password should be able to get to Lighthouse. Our frontend prompts for the password and the backend should remove it before passing along. So, still need to dig further on this one for an explanation. 

[saderagsdale]

Heather will schedule a reminder for Monday mornings. Should be done sending weekly updates in mid-June.