Business intake form for Check In Experience

[randomsync]

Your Details

1. Gaurav Gupta ​

2. Business Line health ​

   Notification Details

3. Notification type text/SMS ​

4. Please describe your use case. We'd like to submit a travel claim as part of the check-in process, and would like to send them a text message with the status of the claim submission. ​

5. What actions can the user take based on the notification they receive? They can login to their profile and view the status of their travel claim submission ​

6. What is the desired business outcome? Ability for Veterans to file travel claim conveniently during the online check-in process. ​

7. What system will kick off the notification? Please note the system should be inside the VA or have an ATO. vets-api ​

8. What will trigger the notification? The notification will be triggered when veterans select to submit a travel claim during the online check-in process ​

9. Provide sample content per notification type, if you have it. ​

10. Has a Privacy Officer (PO) seen and approved the content? If not, do you know who your PO is? No. No (i'll check with project lead) ​

11. Would you prefer to provide contact information for the recipients or would you rather VA Notify look this up for you by Veteran ID? If by ID, please let us know what identifier is used in your system. We'd like VA Notify to look this up by ICN ​

12. Do you currently capture communication preferences related to this notification? If so, please describe. We do NOT capture communication preferences. ​

13. What is the anticipated volume of notifications per day, week, month? ​ Based on our current usage, we see about 1500 check-ins per day. We don't have accurate data on what % of those will file travel claim, but can go with the upper bound of 1500/day for now. Also note: this volume will increase in future as more Veterans use the online check-in method.

14. When does this notification need to be in production? We're currently working on the designing/implementation on our side, and are estimating to be ready to test by end of April, with production release right after.

[randomsync]

cc: @mdewey OCTO project lead @loripusey CIE product lead

[mjones-oddball]

@randomsync Intake received and under review.

Questions for you:

1. Do you plan on sending a text to suggest the Veteran can submit a travel expense claim once check in is complete AND status updates after submission - or - only status updates after submission?
2. What are the possible statuses in the expense claim process? (Looking to understand how many texts a Veteran might get on a single claim)
3. Within the status update process, is there ever additional action needed from the Veteran (e.g. more information is needed to process the claim).
4. Was there any consideration into email for this type of notification?
5. Is the end of April a required timeframe tied to a particular milestone/team goal or is that just indicating you'd like it "as soon as possible"?

Info to review: SMS Standard Operating Procedures are here: https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/va-notify/VA%20SOP%20for%20Delivering%20SMS%20Messages%20v1.0.pdf

Your use case falls under prior express consent, but we still would want a preference so that the Veteran could update their choice online or by replying with the applicable opt-out keyword. We work with VA Profile and VA.gov on preferences.

[randomsync]

1. Do you plan on sending a text to suggest the Veteran can submit a travel expense claim once check in is complete AND status updates after submission - or - only status updates after submission?
   As part of the online check-in process, we will only send them one text with the information that the claim has been submitted. We will NOT be sending them claim status updates through text messages.

2. What are the possible statuses in the expense claim process? (Looking to understand how many texts a Veteran might get on a single claim)
   Check-in team is using the BTSSS api to submit the claim. We will only be sending them a text as part of the check-in process once they submit the form. The rest of the interaction/updates are handled by the travel claims service (and I'm not sure whether they send status updates via text or not)

3. Within the status update process, is there ever additional action needed from the Veteran (e.g. more information is needed to process the claim).
   For the travel claims, yes. They may be asked to submit more information, but that's outside the check-in process since we're calling their API to submit the claim.

4. Was there any consideration into email for this type of notification?
   I'll defer to @loripusey / @mdewey for this

5. Is the end of April a required timeframe tied to a particular milestone/team goal or is that just indicating you'd like it "as soon as possible"?
   I'll defer to @loripusey / @mdewey for this

[loripusey]

4. Was there any consideration into email for this type of notification?

Since Patient Check-in is all text-based, no we did not consider email. This is only to let them know that their claim was submitted and we are only going this route because of the Travel API response latency. The Veteran will need to use the Travel Claim portal for further inquiries about the claim.

5. Is the end of April a required timeframe tied to a particular milestone/team goal or is that just indicating you'd like it "as soon as possible"?

We are currently focused on and working on this solution and would like it to be available as soon as possible.

[mjones-oddball]

@loripusey @randomsync Can you talk a little more about the value/desired outcome? I see above you listed Ability for Veterans to file travel claim conveniently during the online check-in process., however, if I'm understanding correctly they are not filing their claim through this text process, but getting a confirmation of a submission done on the website. Is that accurate?

How long after check in is the Veteran able to submit a travel claim? Is there any time limit?

[loripusey]

After the Veteran checks-in and if the Veteran has indicated that they want to submit a travel claim, the application submits a travel claim for them to the Beneficiary Travel Self Service System's API. The API is not quick to respond, so, when the application eventually gets a response from the API, we want to send a text to the Veteran telling them that their claim was submitted and the including the response or error message we get back from the API. I hope that helps.

[bevnobev]

Thanks @loripusey Is there a process flow document/diagram for PCI?

[loripusey]

@benbrasso-agile6 can you attach a user flow for the texting solution?

[benbrasso-agile6]

eCheck-in w Travel WF_2023-03-22_17-41-55.pdf

[mjones-oddball]

@loripusey @randomsync Just a heads up that Shane is out of office through the end of this week. After he's back I'd like to schedule a 30 minute sync with all of us to discuss next steps. I saw in DSVA slack there was mention of using the existing PCI phone number to send these notifications, which is managed by VEText (with VA Notify), so just want to make sure we are all on the same page.

[randomsync]

Hi @mjones-oddball following up on this, when would you be able to schedule this call?

[mjones-oddball]

@randomsync @loripusey @mdewey I met with Shane this week to discuss options and have a couple questions/topics to discuss with you all. Do any of the times below work?

Monday 4/10 - 2:30 pm - 3:00 pm ET Tuesday 4/11 - 10:30 am - 11:00 am ET Wednesday 4/12 - 2:00 pm - 3:00 pm ET

Agenda:

1. Discuss the overall strategy of Travel Reimbursement notifications to understand the user experience between PCI Travel Reimbursement notifications now and other Travel Reimbursement notifications planned for the near future. I want to ensure we plan ahead to avoid duplicate notifications or a disjointed user experience.
2. Sender and opt in/out strategy

CC @bevnobev

[loripusey]

All of the above work for me.

[bevnobev]

@mdewey @randomsync Any preferences on date/time?

[randomsync]

@mdewey @randomsync Any preferences on date/time?

@bevnobev unfortunately, I'm OOO next week Tue - Fri. Available on Monday 11 - 2:30p ET

[bevnobev]

@loripusey are you free Monday from 1:30-2pm ET? If so, I'll set the meeting for then, since it looks like Mark is free at that time

[loripusey]

Yes I am, thanks Beverly.

On Thu, Apr 6, 2023 at 5:48 PM Beverly Nelson @.***> wrote:

@loripusey https://github.com/loripusey are you free Monday from 1:30-2pm ET? If so, I'll set the meeting for then, since it looks like Mark is free at that time

— Reply to this email directly, view it on GitHub https://github.com/department-of-veterans-affairs/va.gov-team/issues/55526#issuecomment-1499666037, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUVJZVUNNDI2MZWXHXWBFMTW742ZPANCNFSM6AAAAAAWC665VM . You are receiving this because you were mentioned.Message ID: @.*** .com>

-- Warmly, Lori Pusey - VFS/Modernized Check-in - Product Manager [Agile Six]

[mjones-oddball]

Thank you all for a great meeting! Summary:

• We are going to move forward with travel reimbursement confirmation being a part of check in using the existing short code that VEText owns/manages with Twilio. There will not be a separate opt in because it will be using the check in opt in method (Veteran initiated messaging) to determine who to text.
• Once BTSSS/Mark is ready to discuss next steps for other travel pay notifications we should be mindful of potential overlap/duplication and work through the best path forward.
• VA Notify can be found in DSVA slack - #va-notify-public as well as email.
• Heads up that I will be OOO 4/17-4/21 but Beverly and other VA Notify team members will be available should you need assistance.
• Next steps - Melanie will sync with VEText (tomorrow) to discuss configuration needs and an open question regarding test users in the lower env and will get back to Lori and Gaurav. Goal would be to provide access to Staging and Production ASAP including sms sender info and api keys.

[loripusey]

Thanks Melanie!

On Mon, Apr 10, 2023 at 2:47 PM Melanie Jones @.***> wrote:

Thank you all for a great meeting! Summary:

• We are going to move forward with travel reimbursement confirmation being a part of check in using the existing short code that VEText owns/manages with Twilio. There will not be a separate opt in because it will be using the check in opt in method (Veteran initiated messaging) to determine who to text.
• Once BTSSS/Mark is ready to discuss next steps for other travel pay notifications we should be mindful of potential overlap/duplication and work through the best path forward.
• VA Notify can be found in DSVA slack - #va-notify-public https://dsva.slack.com/archives/C010R6AUPHT as well as email.
• Heads up that I will be OOO 4/17-4/21 but Beverly and other VA Notify team members will be available should you need assistance.
• Next steps - Melanie will sync with VEText (tomorrow) to discuss configuration needs and an open question regarding test users in the lower env and will get back to Lori and Gaurav. Goal would be to provide access to Staging and Production ASAP including sms sender info and api keys.

— Reply to this email directly, view it on GitHub https://github.com/department-of-veterans-affairs/va.gov-team/issues/55526#issuecomment-1502171514, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUVJZVSRL4ZGCIDTUUR7TZ3XARITZANCNFSM6AAAAAAWC665VM . You are receiving this because you were mentioned.Message ID: @.*** .com>

-- Warmly, Lori Pusey - VFS/Modernized Check-in - Product Manager [Agile Six]

[mjones-oddball]

@loripusey @randomsync Hi, I met with Shane and Beverly this morning to discuss next steps and the questions you had.

1. We have a concern that using ICN in the SMS notification request for VA Notify to look up the phone number could be a risk because there is a chance the phone number used for check in (initiated by the Veteran) could differ from what is on file in VA Profile. a. Can you provide the phone number associated with the patient's check in when making the notification request rather than the ICN?
2. Since this is an additional use case within the existing PCI notification experience and will be using the same sender phone number we want to keep all the SMS configurations under VEText's existing service in the VA Notify Self Service Portal. This means the following: a. VA Notify will provide you with API keys, service_id, template_id, and sms_sender_id in Staging and Production within VEText's service. Please note, these values differ between environments. b. We will start with Staging. Please provide a va.gov email address for whichever technical individual you'd like to receive the API key. This will be sent via encrypted email. c. VA Notify will create and update the content in the travel pay SMS template for you within VEText's service. Step 1 will be a draft template which can be updated once you have approved content. d. For testing in the lower environment you will want to coordinate with VEText on test users. Shane mentioned he had worked with Mark in the past to get some test users set up (not sure if those would be something you could share).

Please note, you can also reach us in DSVA slack in #va-notify-public.

CC @bevnobev @k-macmillan

[mjones-oddball]

@loripusey @randomsync Just a reminder on the above, there are a couple open questions. I will be OOO all next week, but if you need anything please loop in @bevnobev and @k-macmillan so they can assist.

[loripusey]

Thanks @mjones-oddball ; @randomsync has been out most of this week, I'm sure he will address it when he returns.

[kanchanasuriya]

@mjones-oddball Regarding bullet 2.a/b from above, could you please share the staging environment keys/ids to kanchanadevi.suriyamoorthy@va.gov email

[mjones-oddball]

Thank you! @k-macmillan can you please send an API key + staging details over to kanchanadevi.suriyamoorthy@va.gov via encrypted email Monday/Tuesday please?

[randomsync]

Hi @bevnobev @k-macmillan, have a question on this:

VA Notify will provide you with API keys, service_id, template_id, and sms_sender_id in Staging and Production within VEText's service

What does it mean "within VEText's service"? Would we be still calling VANotify's endpoints (using the VaNotify lib in vets-api)?

[bevnobev]

Hi @randomsync a "service" is the way we group templates and API keys within our platform. You will be calling VA Notify's endpoints, but the api-key we give you and the template for the SMS content will live under the "VEText service" within our self serivce UI

[kanchanasuriya]

Thank you! @k-macmillan can you please send an API key + staging details over to kanchanadevi.suriyamoorthy@va.gov via encrypted email Monday/Tuesday please?

@k-macmillan Could you please share the key/details for us to proceed with integration?

[k-macmillan]

@kanchanasuriya API key email sent, along with additional details regarding connecting to us. If there are additional questions please don't hesitate to reach out!

[kanchanasuriya]

@k-macmillan Thanks for sharing the config parameters. By any chance, can we get access to generating template IDs?

Basically, we need 3 template IDs for three different notifications (one with place holder & rest with a generic message). Received one template ID in the email, wondering which use case it belongs to.

[mjones-oddball]

@kanchanasuriya Can you please give me more information about why we need 3 different notifications? I thought this use case was covering one notification use case within the PCI flow that the travel claim was successfully submitted/received. So essentially, a confirmation text. If there are more use cases, VA Notify will need to review/understand more about what you're trying to accomplish.

[kanchanasuriya]

Sure @mjones-oddball, the PDF link attached here gives the use-cases for all three notifications check-in team planning to send.

[randomsync]

@mjones-oddball to expand on that, when we file a travel claim with BTSSS, there are 3 categories of responses we expect:

• success: in this case, we'd like to provide the claim number to the veteran in the text message
• duplicate claim: claim already exists, so we'd like to provide that info to the veteran
• error: any other response/error falls in this category and we'd like to inform the veteran so they can follow up

hence the 3 templates. the pdf above provides the user flow

[mjones-oddball]

@randomsync for the error use case, you're telling the Veteran they can file within 30 days. What happens when they try to file again? Is this a random error or will it continue to error without manual intervention? Just want to make sure whatever direction we give the Veteran will help them successfully submit their claim.

[benbrasso-agile6]

If the API encountered a problem, then they will need to retry via BTSSS (i.e., not via the API).

If there was more than 1 appt found, then they will need to retry via BTSSS (i.e., not via the API). The "1 appt found" is a shortcoming of the BTSSS API MVP. If refiled via BTSSS, it would likely go through manual review by the travel office assistants to ensure they're getting reimbursed the right amount.

[mjones-oddball]

@benbrasso-agile6 Just to confirm, did you mean the "greater than 1 appt found" error? Does that mean if there's more than 1 appt within a 30 day window there's currently an issue processing the claim without manual review? Is it worth sending a specific message about that so the Veteran understands a manual review is happening so they don't keep resubmitting?

[mjones-oddball]

@randomsync @loripusey In the PDF you pointed me to, the sample messaging is too long for a text message. Ideally we should keep these messages under 160 characters each. Once it goes beyond that point 1) it gets harder for the person to read on their phone and 2) it increases the cost as it will break the message down into segments of 153 characters each. At least one of the examples was 3 message segments long. I would suggest cutting down on repeat content like "travel reimbursement claim", the full name of the travel claim site for BTSSS, and URLs if unnecessary. As a note, we may have to include some standard opt out messaging at the end, which I'll work with VEText on.

Here are my current suggestions below. These will still need to be reviewed with your Privacy officer, particularly around including dynamic content like the appointment date and claim number.

Duplicate (does including the claim number here help the Veteran?): A travel reimbursement claim was already submitted for this appointment. Claim number, TC202207000011666. Check the status, http://va.gov/accessva-travel-claim

Error (may change depending on the answer to my question about manual review): We're sorry, something went wrong with your travel reimbursement claim. Try again within 30 days of your appointment, http://va.gov/accessva-travel-claim

Confirmation: We received your travel reimbursement claim for your VA appt on MM/DD/YYYY. Claim number, TC202207000011666. Status updates will be available online.

CC @bevnobev

[benbrasso-agile6]

@benbrasso-agile6 Just to confirm, did you mean the "greater than 1 appt found" error? Does that mean if there's more than 1 appt within a 30 day window there's currently an issue processing the claim without manual review? Is it worth sending a specific message about that so the Veteran understands a manual review is happening so they don't keep resubmitting?

No. Again, not sure why the API was architected this way, but the API will not accept a claim if more than 1 appointment is found in VistA for today's date. So, the Veteran would need to use BTSSS to submit that reimbursement request, which should be accepted just fine.

Sound correct? @randomsync

[benbrasso-agile6]

Duplicate (does including the claim number here help the Veteran?): A travel reimbursement claim was already submitted for this appointment. Claim number, TC202207000011666. Check the status, http://va.gov/accessva-travel-claim

That's not a bad idea. @randomsync do we get that claim number? I'm guessing we don't, but here's to hoping.

[benbrasso-agile6]

This is all great feedback, thank you, @mjones-oddball.

Working within the character constraints, we may try to work in the url into this one. But, we can work on this a bit.

Confirmation: We received your travel reimbursement claim for your VA appt on MM/DD/YYYY. Claim number, TC202207000011666. Status updates will be available online.

[kanchanasuriya]

Duplicate (does including the claim number here help the Veteran?): A travel reimbursement claim was already submitted for this appointment. Claim number, TC202207000011666. Check the status, http://va.gov/accessva-travel-claim

That's not a bad idea. @randomsync do we get that claim number? I'm guessing we don't, but here's to hoping.

You guessed it right, Ben. We don't get the existing claim number for the already existing claim response.

[mjones-oddball]

@benbrasso-agile6 Just to confirm, did you mean the "greater than 1 appt found" error? Does that mean if there's more than 1 appt within a 30 day window there's currently an issue processing the claim without manual review? Is it worth sending a specific message about that so the Veteran understands a manual review is happening so they don't keep resubmitting?

No. Again, not sure why the API was architected this way, but the API will not accept a claim if more than 1 appointment is found in VistA for today's date. So, the Veteran would need to use BTSSS to submit that reimbursement request, which should be accepted just fine.

Sound correct? @randomsync

^ @benbrasso-agile6 Excuse all the questions! I'm still learning about the travel claim process. Does this mean the first time the person submitted the claim it was on a different site than http://va.gov/accessva-travel-claim? Meaning, is it appropriate in my example text to direct them to https://www.va.gov/resources/how-to-file-a-va-travel-reimbursement-claim-online/ to try again? Should it instead direct them to http://va.gov/accessva-travel-claim or another URL?

[benbrasso-agile6]

Oh, no worries about the questions.

Yes. The PDF of the work flow represents the experience when a Veteran "checks in" for their appointment on their smartphone when they arrive at the clinic. The check in experience will collect and submit the needed information for a travel reimbursement claim and submit it to BTSSS (http://va.gov/accessva-travel-claim) using their API. If a Veteran needs to check that status of the that claim, if we were able to submit it, then they can access it on the BTSSS website (http://va.gov/accessva-travel-claim).

There are 2 different resources for Veterans:

When we aren't 100% sure if the Veteran has a BTSSS account set up - https://www.va.gov/resources/how-to-file-a-va-travel-reimbursement-claim-online/

We know they have a a BTSSS account set up because either, 1) the claim went through, or 2) we got a response back from the API that a claim already exists... and, therefore, we can send them directly to the BTSSS log in page - http://va.gov/accessva-travel-claim

[randomsync]

@mjones-oddball while we work through that, can you please:

• update the success template with a placeholder for claim number,
• create 1 more template with the error message so we can test these scenarios?

Also, on that note would we be given UI access to update these templates, or do we continue to work with you/your team for that. Thanks.

[mjones-oddball]

@randomsync for the success message, do you also need a personalisation (dynamic content label) for the appointment date? I will make your additional 2 templates for duplicate and error as well.

You will work with me/VA Notify for template updates. Because the PCI text workflow falls under VEText's configurations I don't have a good way to give you access to update some, but not all templates in their workspace and this was our compromise.

[benbrasso-agile6]

It would always be {today's date}

.... for this initial MVP.

[randomsync]

@randomsync for the success message, do you also need a personalisation (dynamic content label) for the appointment date?

yes, thank you.

[mjones-oddball]

It would always be {today's date}

.... for this initial MVP.

@benbrasso-agile6 I thought the Veteran could submit this claim up to 30 days from the appointment date? Are you all only sending notifications for PCI users who submit the claim same day?

[benbrasso-agile6]

They can, but they have to submit it through BTSSS or visit a travel office at a VA health facility. The PCI application is only accessible when, 1) a Veteran has an appointment at a PCI-enabled clinic, 2) they use PCI on the day of their appointment. Veterans cannot access the check in application outside the window of 45 mins before their appointment start time and 15 mins after the start time.

[mjones-oddball]

@benbrasso-agile6 @randomsync Just want to call out a potential risk. The error scenario means the Veteran has to resubmit outside the PCI app, and at this time, we're saying they won't get another text notification on further claim actions until BTSSS looks into adding notifications in the future. That may be a little confusing for the Veteran. I don't have the answer yet, but I'm trying to think if there's some verbage we can include in the text message to make this clear they are leaving the check in experience. While we understand these are different systems/processes, that's not necessarily clear to our users. Let me know if you have any ideas!

[benbrasso-agile6]

That does make sense, yes. And, we thought including the url in that message (which stays in their text messages) that points to where they need to take the next step was sufficient. (cc @mdewey)

We're open to ideas.