search

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

Editor-centered management for Veteran-centered content.
https://prod.cms.va.gov
GNU General Public License v2.0
98 stars 69 forks source link

Create feature toggle to enable switching data source for Cerner widgets ONLY (hardcoded vs. Drupal) #9076

Closed jilladams closed 2 years ago

jilladams commented 2 years ago

Description

The unauthenticated Cerner React Widgets will be the first product to consume the new CMS-driven Cerner facility API. Create a feature toggle so that we can switch between CMS/async and hard-coded/sync APIs in Staging and Prod (independently).

Flag name: pw_ehr_cta_drupal_source_of_truth

Description: Enabling Public Websites-managed EHR CTAs to use Drupal EHR data, including for Cerner cutovers

Additional context

This feature flag will allow us to cut the Public-Websites-managed react widgets for Cerner back and forth between data sources. Other teams who implement against the new API may generate their own feature flags.

Acceptance Criteria

CMS Team

Please check the team(s) that will do this work.

wesrowe commented 2 years ago

@jilladams, I wonder if we should put a little more detail in here about how this issue should be tested? I imagine we could describe a complete testing scenario in Staging. I guess I want to think it through "out loud" so you (or someone else) can spot gaps. I'll pick on Central OH because I know we have users with Columbus affiliation.

Given initial parameters:

And then test "disagreement" cases where the two cutover data sources differ (HC or drupal), and test flipping the data-source flag. And then also test "agreement" cases where the data source flag shouldn't make a difference.

Given hard-coding involves code, maybe you run the scenarios in an order that minimizes code change...

jilladams commented 2 years ago

Chatted with Wes on this -- goal is to test to test both the Drupal setting, and the feature flag functionality, so

Hard coded facility ID isCerner Drupal value Feature toggle (Off = hard coded, On = Drupal) Outcome
false Vista Off > On Behavior in front end doesn't change, user directed to Vista
false Vista On > Off Behavior in front end doesn't change, user directed to Vista
false Converting to Cerner On Test user is directed to Cerner in Staging; directed to Vista in Prod
false Converting to Cerner Off Behavior in front end doesn't change, user directed to Vista
false Cerner On Test user is directed to Cerner
false Cerner Off Test user is directed to Vista
true Cerner Off > On Behavior in front end doesn't change, user directed to Cerner
true Cerner On > Off Behavior in front end doesn't change, user directed to Cerner
true Converting to Cerner Off > On Test user is directed to Cerner in Staging; directed to Vista in Prod. (This is a data mismatch. If hard coded is set to True, then that node should be set to Cerner in prod, but: we should test this state to verify what will happen if someone sets the data this way.)
true Converting to Cerner On > Off Test user is directed to Cerner in Staging & Prod
true Vista On Test user directed to Vista (This is a data mismatch. If hard coded is set to true, Drupal value should be set to Cerner.)
true Vista Off Test user directed to Cerner (This is a data mismatch. If hard coded is set to true, Drupal value should be set to Cerner.)

^ General idea, not definitive truth table, so @ryguyk when you get to this point, if it's helpful to discuss further, holler.

Per Ryan:

The "Converting to Cerner" (cerner_staged) value will be set in production. If we think of the production environment as the source of truth that it is, then setting a value to cerner_staged in production would indicate something along the lines of "From the perspective of the VA ecosystem, this VAMC System is ready to be tested for its Cerner cutover"

Then, that testing would be done in staging. That relationship is possible because staging data is simply a copy of "yesterday's" prod data, roughly. In other words, we won't ever manually adjust this field in staging.

jilladams commented 2 years ago

Feature flag behavior

We'll propose to Dave that we do not modify the feature flag plan above to accommodate apps onboarding to Drupal data at various times. Instead, we'll propose keeping the feature flag as a singular toggle that will control data SOT for all apps at once: either hard coded, or Drupal. We'll request approval when Ryan has final detail re: where data fetch will happen in code / implications for other teams (ETA today/tomorrow).

Background: Dave spitballed modifying the feature flag behavior to 1) unblock launching Drupal SOT for React widgets, and 2) to allow downstream teams to test / implement async data fetch at their convenience. Per discussion with Ryan, he believes he can implement the bulk of the changes required and minimize the impact to other teams, down to a 1-line code change required. With a smaller scope, we'd like to propose a testing / release schedule that allows stakeholder teams to test / verify the code change / behavior, and launch at one time.

Additional context: The modified feature flag approach would be more expensive up front to implement. It also runs the risk of stakeholder teams not adopting the new data model right away, which requires supporting both the hard coded and Drupal paths for a longer period.

Stakeholder comms

With Dave's sign off on the above, we need to notify stakeholder teams of:

  1. Implications of async data / downstream work required (TBD Ryan's last code changes)
  2. Timing for test & launch
  3. The Drupal "Converting to Cerner" testing value for awareness

Launch plan

Will be tracked here https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/public-websites/Cerner-Support/cms-source-of-truth/release-plan.md

Data model / truth table updates

The Drupal EHR field now has values: Cerner, Vista, Converting to Cerner. Converting to Cerner is the testing state, prior to full cutover. Only Drupal Admins, Dave, or Lauren may edit this field; no formal editor-facing Change Management is required.

Stakeholders / current consumers of index.js hard coded path:

Slack thread: https://dsva.slack.com/archives/C0190MTGNUE/p1650395730832549

VAOS

MyVA

Health apartment

Travis Newby = OCTO mobile eng, "Our backend uses a different mechanism (something like cerner_facility_ids in the user object via MPI) to figure out if a Veteran is enrolled in cerner facilities. My understanding is that it's a reliable mechanism, though we should probably have a single authoritative list in vets-api as a backup plan."

To add to release plan

Repos:

Phases that need dates:

  1. Merge / deploy all code
  2. Flip toggle on Staging
  3. Stakeholders make any necessary code changes, test, deploy to prod
  4. Go / no go
  5. Flip prod feature toggle, verify
  6. Bake time
  7. Remove hard coded path / old feature toggles

(Many of the release plan template % and KPI stats don't apply to this release, as this is a binary data backend change, rather than a user testing / new functionality front end feature release. )

jilladams commented 2 years ago

Per refinement, it sounds like we do have a requirement to allow other teams to adopt async, and treat this like an API rev rather than a binary cutover.

Next steps:

allisonlu commented 2 years ago

PR opened, awaiting an approval from one of the code owner groups: https://github.com/department-of-veterans-affairs/vets-api/pull/10064

allisonlu commented 2 years ago

@ryguyk this has been merged into vets-api repo!

https://github.com/department-of-veterans-affairs/vets-api/pull/10064