VA Forms Audit

[tbaker1026]

Problem Statement

• The VA currently has over 400 Veteran-facing forms, only a fraction of which have been digitized. The 21st Century IDEA (Act) requires VA to create user-friendly and accessible digital versions of all forms.

• Forms Required To Be Digital Not later than 2 years after the enactment of this Act, the head of each executive agency shall ensure that any paper-based form that is related to serving the public is made available in a digital format that meets the requirements described in section 3(a).”

How might we?

User centered:

• Given that many VA forms are only available via PDF or PDF print-out, how might we reduce the number of PDFs that a Veteran might encounter in their interaction with the VA so they can have a streamlined and more accessible interaction, reducing the number of steps, context switches, and repeated identical inputs across multiple forms?

Org centered:

• Given that many VA forms are only available via PDF or PDF print-out, how might we reduce the time and effort that it takes to digitize a VA form onto va.gov so that we can enable teams to move common and simple forms onto va.gov with as little friction and ongoing costs as possible?

How might we quickly minimize the number of PDFs a Veteran might encounter in their interaction with the VA?

• I left this deliberately open to both interactions on VA.gov and interactions in person at a health facility. It’s obviously easier to measure forms downloaded via analytics for va.gov. However, that might not be the same forms that Veterans are asked to fill out when visiting a health facility and that might be the more common interaction and thus a higher volume of form submissions from Veterans to the VA. I’m wondering if there is an opportunity to build from the pre-check-in experience an interaction whereby medical forms you might be required to fill out during your visit can be filled out in advance?
• We also should mix the quantitative measurement with a qualitative approach. For example, all of the Apply links in the Welcome Kit open a PDF that provides a link to apply online except for one: The PDF for applying for burial instead directs the user to 4 forms. This might not be the strongest example but there may be an argument to be made to plug gaps like this. To get to these we may want to solicit input from VFS teams on what forms they would suggest we go after that are perhaps on their radar but that they haven’t been able to get to.

How might we quickly extract the questions asked in fillable PDF forms so that we might group them into similar sections?

• It’s worth looking into automating the identification of which PDFs are fillable and which are not. Then for fillable PDFs automating the collection of questions within the form.
• Once we have groups of questions identified we can determine which could use existing endpoints, and which we’d need to build.
• We could also potentially start to build “composed components”, essentially sub-sections of forms. This is something we hope to get to in the Design System. For example, a “component” that collects Service Dates. To borrow from Brad Frost’s parlance, these are molecules, as opposed to the atoms of form elements (text-input, checkbox, etc.). If we put these molecules into the Design System they can get approved once via the CollabCycle and then our team, and subsequent teams, could potentially breeze through the process or, if we’re able to stick solely to those molecules, go through a lighter weight version of CollabCycle. We could also potentially ask VFS Teams to test some of these molecules for us to distribute the load. Note: This might help with the “middle bucket” of forms that have more complexity than a few fields but are not complex enough, or don’t have enough volume, to warrant a full VFS Team.

How might we use existing commercial or open source solutions?

• Some Program Offices are already using DocuSign. Chris and Jeff agreed that we need to evaluate commercial software and determine if the experience is acceptable or not (we are collectively under the impression that it is not). A heuristic evaluation may be enough or if we can reference research with Veterans, even better.
• We also agreed that we all lean towards building something ourselves rather than creating a dependency on a commercial product.
• That said, we should start in divergent thinking mode. If there is a way to use a commercial tool (Jotform, Google Forms, Airtable, et. al.) and hook that up to an existing VA back-end tool or configure it to support a back-end process workflow and that allows us to digitize some significant chunk of forms then we should entertain that notion (even given the usual procurement and ATO challenges).

How might we build a pipeline to generate a form schema from a PDF so that we might automatically build most of a form flow that would require only minimal review and tweaking?

• How much structure can we extract from a PDF? For example, if the PDF is already divided into sections can we translate that directly into a JSON file defining the form which could retain that structure turning those sections into form pages? Can we then leverage the Forms System Core to generate a form flow from that config file that leverages our standard form components (Progress bar, button pairs, revised Review page design)?
• This level of automation seems like a reasonable place to start with simple forms and then we can learn what can, and cannot be automated, and build a bit of an assembly line process around that to get through the initial category of simple forms.

Hypothesis or Bet

If we audit the forms and categorize them, we can make recommendations on how to streamline the process of digitizing forms. Also by coming up with a repeatable process to digitize forms, we can provide guidance for other teams to replicate to make digitizing forms more efficient

We will know we're done when

• When we have piloted and identified one or more solutions that provide a mechanism for the VA to digitize the most forms with a significant positive impact on the Veteran experience.
• This is a typical USDS impact statement: The greatest impact to those most in need.
• In this case, we want to lean towards creating a mechanism that allows VA to digitize the most forms (i.e. “solve for volume”), with a significant positive impact on the Veteran experience
• We also want to create a mechanism for digitization and then determine how efficiently we can make that mechanism.
• However, we can’t dwell on one mechanism to the detriment of the other categories. A solution that works for one category of forms, for example, very simple forms that may only consist of text and a digital signature, may not work for another category (or at least not without modification).

Audit The first step is an audit of all digital and non-digitized forms. One potential audit strategy might be to break the work into the following phases:

Phase 1 - Data gathering Define characteristics or attributes of forms which we’ll track Start with the forms DB, pull that into a new DB (could just be airtable), add meta-data DB has: “…detailed form metadata including the number of pages, related forms, benefit categories, language, and more”

Potential attributes

• Volume. How many forms submitted over a set period of time (year?)
• Impact. Impact to individual Vets.
• 5,000 submissions to a form that allows wheelchair users to get around their house - that has less volume but is highly impactful.
• Length.Number of pages
• Number of sections
• Number of fields and questions
• Profile overlap. Do we have it already? Overlap with data provided via user Profile
• Data sensitivity. Sensitivity of the type of data being collected (level of PII, health data)
• Benefit categories. There is a “related to” field in Find a form; VHA, VBA, VACO, housing assistance, pension, disability, education & training, etc.)
• If VHA, which medical field (i.e. Dentistry, Radiology, etc.)
• Veteran facing or internal?
• 603 Veteran facing forms right now - not all VFS, in the Forms database
• Questions. Each question should get captured and categorized at some point for some of the forms.
• Certainly, any form we were considering digitizing would need this level of analysis.
• Related forms (this is in Forms DB)

Phase 2 - Grouping

• Group by attribute combinations, we determine to create a prioritized bucket or category. Potential groupings:
• Volume
• Impact
• Affinity - Greatest number of similar forms within the category.
• Design level of difficulty. High-touch (i.e requires a VFS Team ala our current solution) thru low-touch (a form that perhaps only requires text and a digital signature).

Phase 3 - Analysis

• This would be a pre-selection phase where we get into the nitty-gritty details of how a select few forms would be handled on the back-end. We’d take a few forms in each category and determine how far away we are from being able to support the submission of that form.
• We may initially map what we’d need to do to support the happy path versus the full set of options for a form. In other words, a partial digitization with the rest going into a queue for this team or other teams.
• We also need to consider how the user arrives at this form and what that experience might be like in different contexts.
• After this, it’s onto prototyping and piloting potential solutions.

Known Blockers/Dependencies

• Stakeholder buy in, contributions to digitize forms ensuring legal concerns are met while still trying to update to modern, accessibility-first standards.
• The unknown of existing backend systems to submit form data
• PDF Field data not consistent to easily automate parsing of the data
• Complex forms (multiple signatures, supporting documentation, calculations, etc), the forms library is not able to handle some of the complexities and would require additional development or solutions.
• Providing a way for Program offices to handle changes to forms after the initial digitization

Projected Launch Date

• Complete a full audit of PDF forms, with metadata and questions extracted and categorized, by end of January 2023.
• Reduce by 50% the total number of PDF forms by Dec 2023.
• We should set a realistic target once we’re further along in the audit.
• Reduce estimated burden hours by 3 million hours before May 20, 2023.
• This would require digitizing the top 20 most download forms and through that effort achieving a modest 10% reduction in burden hours.
• DHS, via the Hysen Memo, is shooting for a 12% reduction, or 20 million hours, by the same date.
• Ideally we’d prove that putting the form online reduces the un-estimated burden of having to download the form, (fill it out), mail it in, and potentially repeat that process. Thus perhaps we can estimate a greater overall burden reduction.

[annekerr49]

@tbaker1026 - We are having a monthly status meeting to discuss Development issues next week. I see that Create an Epic to add to the DE Product Board is closed. Can you tell me when the item was delivered? Can you give me a status update on the VA Forms Audit/Digitize issue?

[humancompanion-usds]

The "Create an Epic to add to the DE Product Board" was literally a task to create this issue. I apologize that there are not issues attached. There should be. I will ask the team to fix that.

The audit is complete though we are still working out how we're going to present the categories (i.e. how specific we want to be outside of the team). We have a presentation to ChrisJ on 12/15 at 1:05pm to go over the audit. We'll have draft recommendations at that time.

Next up is finishing the recommendations, which may involve additional discovery tasks and then moving onto executing those recommendations.

[annekerr49]

@tbaker - thank you very much.

[annekerr49]

@tbaker1026 Hi Tricia do you have any estimate at which milestone this item will be completed ?

[tbaker1026]

The Audit is complete, we are finalizing our recommendations and audit findings. Will close out this issue once that is complete.

[tbaker1026]

Here is a summary of the audit findings

[tbaker1026]

The audit is complete