Closed aprocik1 closed 5 months ago
@oddball-lindsay, I reviewed the updates to Form 21-22a authorization screens. I left comments in the Figma file with draft content recommendations. Those recommendations are dependent on the answers to the questions below.
Questions about the content:
Questions about the design:
Content:
I think we need to better define what records are being released. It seems like OGC SMEs said that they're not only medical records. Can you clarify what "overall access to all records" means?
From stakeholder review, we clarified that signing the 21-22 and 21-22a forms authorizes access to any/all of the Veterans records. This is called out in the block of text above the signature field, where it says "I authorize VA to release any and all of my records...". So this is what we are referring to by "overall access to all records".
The specific medical authorization for those four conditions come up because SECTION 7332, TITLE 38 U.S.C. requires additional authorization for these types of records. Any records outside of these four conditions fall in the "any and all of my records" bucket.
The legalese in the accordions says, "...I authorize to disclose all of the Veteran's records..." Is it always true that the Veteran's records are being released? Or would a non-Veteran claimant's records ever be released? For example, what should the legalese say if a dependent spouse is completing Form 21-22a to appoint their own accredited attorney?
With OGC in the discussion, it sounded like there are concerns with messing with the legalese in any way and we should leave it as-is on the form in the accordion expansion.
That said, we still can lean on our friendly copy outside of that accordion to help users understand what records are in play. I think we can lean on the authorization logic from stakeholders, with the idea that:
Design:
Does the second screen only appear if someone selects "yes" on the first screen? No, we've determined these screens are for separate access.
- The first/left screen with "Do you authorize the [attorney or claims agent]’s team to access your records?" is authorizing any staff associated with the rep's POA code to have direct, digital access to VBMS.
- The second/right screen with "Do you authorize [attorney or claims agent]’s administrative staff to request your records?" is authorizing any additional staff the ability to contact the VA and obtain records through non-digital means (email perhaps). The representative may forget who on their staff is attached to their POA code and could put redundant names here that are covered in
#1
. But this is intended to be additional access authorization, albeit in a more manual manner of retrieval, for any add'l staff that doesn't have that POA code association.Does the "if yes" component at the bottom of the second screen only appear if someone selects yes? Or is it a static component? Up for discussion, we hadn't talked too much about this behavior. Do you have a preference? I'm guessing it might be better on the accessibility front to have this be a static component, but that's just a guess!
Thanks, @oddball-lindsay!
Content follow up notes
Design follow up notes
Drafts for review
Great qs @aprocik1 and I don't have a confident answer for any of these. I'm going to message the stakeholder group to confirm and will cc you!
One clarification actually -- for the contradiction in the legalese for non-Veteran claimants seeking help with non-survivor benefits, @aprocik1 what legalese are you referring to?
@oddball-lindsay, I was referring to the legalese in this Figma file. However, I'm now seeing that file doesn't match the legalese on the PDF form. I've corrected the content variations where the contradiction occurs below based on the PDF form.
The legalese in Form 21-22a, questions 19a and 19b says this:
I authorize VA to disclose all my records...
That legalese works for these scenarios:
But that legalese doesn't work for these scenarios:
That's because of the authorization logic from stakeholders. They've told us that non-Veteran claimants seeking help on behalf of a Veteran and non-Veteran claimants seeking help with survivor benefits both authorize access to the Veteran's records. That means the legalese needs to say this:
I authorize VA to disclose all the Veteran's records...
If OGC doesn't want us to the change the legalese, then we'll be presenting a contradiction between the plain language in the question and the legalese in the accordion.
Got it, thank you @aprocik1! I'll reach out today to clarify this piece
@aprocik1 while that clarification is out for feedback, here's some answers to the other questions
Let me know if "VA records" holds the same meaning as "any and all records" in the drafts for review below.
Confirmed that VA records holds the same meaning and is appropriate to move forward with
Let me know if I've captured the nuance of "access" v. "request access" in the drafts for review below.
Update needed here! After speaking with Jonathan, the end goal of both authorizations is to disclose records. The only difference is the means of access -- 19a (screen 1) is digital access, mostly VBMS but he mentioned there may be some other digital records that also come into play. 19b (screen 2) is non-digital access. Jonathan mentioned he's not sure if "digital" or "electronic" makes more sense, I'll let you make that call :).
Typically the attorney/agent should guide the user on how to complete these authorizations, especially for the 19b names. Sharing this in case it's something we want to consider for the landing page, similar to how we have the mention of asking a VSO Rep which organization is best to appoint. Unsure if that'd be helpful or information overload up front 🤔
What happens if someone answers "yes," but doesn't enter any names in the "if yes" component? Does that result in the same outcome as someone who answers "no"? Depending on how this authorization works, I wonder if we forgo a yes / no question entirely. This screen may just need to become a prompt to enter the names of people connected to the accredited representative who can request access to records.
For 19b (screen 2) the names should be required. So while the form has both a checkbox and a free text field for names, there is the assumption that names will be entered if the box is checked. Interesting idea to forgo the yes / no and just focus on the names, I could see that making sense! I wonder if we'd need to make it clear that not entering names = not authorizing non-digital access. cc @mtri for this particular piece, as there are design considerations here
@oddball-lindsay, thanks for following up on these questions. I've included 2 drafts for you and @mtri to review below.
After we align on one of these drafts and clarify the authorization logic / legalese contradiction, I can finalize the other content variations.
Drafts for review
@aprocik1 given Jenny's reply the thread advising us to stay closer to the form language I wonder if we could do "VA's information technology systems" instead of "VA's online system"?
The form language is "access to VA information technology (IT) systems in accordance with 38 CFR 1.600 to 1.603" but the policy feels like overkill for the friendly language.
Design wise, I like that the 2-screen option is slimmer however it feels like a requirement to enter team member names and I worry that users may not understand on Screen 2 that they can proceed without including anyone.
The latest update around the contradictions I have is a direct message from Jonathan saying that he thinks that the claimants files are within the Veteran's eFolder, but he's not totally sure. I'll need to confirm that; just wanted to let you know that this is still on my radar and I am aware of the timing implications of this open q.
@oddball-lindsay, thanks for tracking down this clarification. And great catch on the requirements for 19b!
Here are the updated drafts of all 3 variations with 3 screens each:
Thanks so much @aprocik1! From Jenny's last message and some recent direct messages from Jonathan, it seems like they are trying to tell us that while yes, the Veteran's records may be referenced in these survivor and fiduciary/incompetent scenarios, the veterans records are connected to the claimants records in VBMS and therefore "my records" is all encompassing.
I'll kick off an email to the group to share my interpretation, which is pointing to content variation 1
being appropriate for all scenarios.
Thanks, @oddball-lindsay. I think we still need these 2 content variations:
Let me know what you think of these drafts:
P.S. Code
in the legalese denotes a change in the legalese depending on if a non-Veteran claimant is authorizing a Veteran's information (only applicable for content variation 2).
P.P.S. Based on this clarification from SMEs, we don't need to distingish between non-Veteran claimants seeking help with non-survivor benefits and non-Veteran claimants seeking help with survivor benefits. I've updated my recommendation for the authorization screen content and logic in this ticket.
Thanks for all of this @aprocik1 🙏
This upcoming design review is our final round so I am trying to get as close to stakeholder needs as possible so that we can minimize feedback and get into development. I'm open to presenting the two variations to the stakeholders to get their feedback on the Veteran name call out, but have a feeling they may push for content variation 1 for all scenarios. If not, great, but I want to be prepared for that outcome.
A couple of requests for these screens:
Let me know what you think about these requests!
@oddball-lindsay, I want to confirm I understand your request around content variation 1 and the legalese.
If we use content variation 1 for all scenarios, a non-Veteran claimant appointing a representative on behalf of a Veteran will be presented with this content on screen 1:
Based on the authorization logic from SMEs, we know that content is inaccuracate. A non-Veteran claimant needs to authorize access to the Veteran's records -- not their own records.
You're requesting that we use content variation 1 for all scenarios, despite that inaccuracy. Is that right?
(If we forgo using content variation 2, we could simplify the authorization entry screens in this ticket, since there would be no need to ask why someone is appointing a representative.)
@oddball-lindsay and @mtri: Here's an update following our meeting earlier today: Lindsay will confirm with SMEs that we can move forward with only using content variation 1 for all scenarios. That means we can remove this question entirely from the form flow:
Why are you appointing an accredited representative?
Here's the updated Appoint tool source of truth. Find the most recent content for all the authorization screens on pages 17-22.
Update: The product team confirmed that SMEs are okay with only using content variation 1 for all scenarios. Here's the updated Appoint tool source of truth. Find the most recent content for all the authorization screens on pages 17-22.
Request
Criteria