search

department-of-veterans-affairs / va.gov-team

Public resources for building on and in support of VA.gov. Visit complete Knowledge Hub:
https://depo-platform-documentation.scrollhelp.site/index.html
281 stars 198 forks source link

"No MHV access" route guard: Evaluate path forward for each app and PR #84911

Closed wesrowe closed 2 months ago

wesrowe commented 3 months ago

Description

User story

As a Cartography team member, I want to understand in light of the recent analysis whether or not each of the apps in the MHV space needs us to provide a "No MHV access" alert, so that we can make sure we're delivering an improved UX to Veterans.

As a Cartography team member, I want to evaluate each route-guard pull request in light of the recent analysis, so that we can get closure on each of them in separate tickets.

Notes

Supply reordering-specific notes:

PR list from 77237

My Health Tool Pages

  1. Add mhv route guard to after visit summary - Needs route guard based on AVS API facility count
  2. Add mhv route guard to medications - MERGED
  3. Add medical records mhv route guard - MERGED
  4. Add mhv route guard to Secure Messaging - Needs route guard based on MHV SM API which validates presence of messaging in user services
  5. Add mhv route guard to supply re-ordering - Needs route guard based on ROES / DLC facility count
  6. Add route guard component and unit test and copy for NoHealthAlert - MERGED
  7. Appointments - Needs route guard based on VAOS enrollment status
  8. 1010 EZR - Needs route guard based on form Enrollment Status

Acceptance criteria

sterkenburgsara commented 3 months ago

UPDATE: Learned that the AVS has its own API with looser logic than the MHV-API (similar to VAOS)

~Can we double-check this? The After-visit summary is a type of care summaries & notes (Medical records) which does rely on the MHV-API. Right now, the only tool in Phase 1 that can cross-link to the AVS is Appointments, but it doesn't actually rest on the VAOS API.~

~Is the rationale different than what I wrote above? Can you explain why the route guard logic needs updating?~

// cc @jzucadi @wesrowe

jzucadi commented 3 months ago

Doc on what health tools under /my-health` use for their backend data, which health tools can use facility count, and the next steps for creating a route guard for each of the remaining my health tool pages

https://github.com/department-of-veterans-affairs/va.gov-team-sensitive/blob/master/teams/mhv-landing-page/mhv-tool-page-route-guard-next-steps.md

jzucadi commented 3 months ago

Two of the My Health tools actually rely on the MHV data from vets-api using the mhvAccountState property, and those two PRs have been approved and can now be merged.

Those PRS are for:

  1. Medications
  2. Medical Records
radavis commented 3 months ago

Authorization rules for MHV Health Tools: https://github.com/department-of-veterans-affairs/va.gov-team-sensitive/pull/1715

radavis commented 3 months ago

The MHV Authorization document has been moved into the va.gov-team repository: https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/health-care/digital-health-modernization/engineering/mhv-authorization.md

radavis commented 3 months ago

Here a are some suggestions on how to approach gating access to the remaining health tools.

Health Tools

  1. avs
  2. mhv-medications -- route guarded
  3. mhv-medical-records -- route guarded
  4. mhv-secure-messaging
  5. supply reorder -- on hold until path/URL changes
  6. mhv-landing-page -- where all the alerts are being displayed
  7. vaos
  8. ezr

avs

Within the <Avs /> container, add the verify prop to <RequriedLoginView />.

Since this is an "After Visit Summary" and the user is providing an id referencing a specific after visit summary, is redirecting to /my-health even necessary? How would they get an AVS id without being registered at a facility (aka, being a VA patient)?

mhv-secure-messaging

Within the container, add the verify prop to <RequiredLoginView />, and change the argument to window.location.replace() to /my-health.

// src/applications/mhv-secure-messaging/containers/App.jsx

{user.login.currentlyLoggedIn &&                            // if authenticated and
!userServices.includes(backendServices.MESSAGING) ? (       // no authorization
  window.location.replace('/health-care/secure-messaging')  // then, redirect

vaos

Within <EnrolledRoute />, wait for /data/cms/vamc-ehr.json, and state.user.profile.loading === false. Check patient facilities and redirect to /my-health when user has no associated facilities (i.e. - !hasRegisteredSystems).

ezr

Authorization for the 10-10EZR is different than all other health tools. Recommend showing the link on the landing page and letting the app determine authorization.

wesrowe commented 3 months ago

At end of sprint, ACs/actions outstanding:

dcloud commented 2 months ago

After review with UXers

While reviewing Richard's proposed tickets for next steps, Sara and I considered how a future where vets-api's backend services feature could enable us to be granular in detailing which tools/pages are available (on the landing page).

That said, Richard's tickets reflect reasonable next steps to take in partnership with tool teams.

Next steps

Review with @batemapf and @wesrowe

dcloud commented 2 months ago

After talking further with @radavis and @wesrowe and following up with Oleksii regarding SM, we have narrowed down the remaining work to:

Closed tickets

AVS

The AVS ticket was closed after a discussion with Adrian Rollet:

Via slack with Adrian Rollett we determined that there is no probable way for an unverified user to reach the AVS app. Closing as a no-op.

Appointments

The Appointments ticket was closed because Appointments already shows an appropriate alert to users who don't have access, and their alert is well-suited to their tool's access requirements and remediation steps.

dcloud commented 2 months ago

@wesrowe Given we've figured out a path forward for each tool and PR, and Richard created the SM ticket we need, I think this is safe to close

wesrowe commented 2 months ago

Thanks! Closing.