Skip to content

VRO v2 Roadmap

Jump to bottom
Derek Fitchett edited this page Oct 10, 2024 · 44 revisions

iMVP (Integrated MVP)

Background

VRO has developed an MVP (in Dec 2022) and iMVP (in Feb 2023). The keyword is "MVP". VRO needs some TLC:

  • The code works but should not necessarily be used as the basis for new code.
  • New teams/engineers will inevitably copy-and-paste to develop new functionality.
  • VRO code should follow best practice; follow conventions and be consistent (which improves maintainability); be modular with minimal coupling (to help ensure components don't inadvertently affect each other as new features are added); and be scalable to handle high volumes.

So I propose:

  • (Mostly done) We document instructions, set coding conventions, and/or incorporate working example code into the VRO codebase.
  • (In progress) We refactor code for reuse, maintenance, and modularity while keeping existing VRO capabilities functional.

Other context:

  • VRO is one of the first to use the LHDI platform, LH SecRel pipeline, and LH cATO process, which are gradually being developed, expanded, and matured.
  • Contributions to and management of the VRO codebase will change hands over time.
  • Consistent code implies easier debugging and maintenance across domains. Coding conventions help to ensure consistent code.

Workflow Diagram

Legend:

  • light-green box: implemented in v1
  • trapezoid: microservice for External APIs; listens for requests added to an associated RabbitMQ queue
  • rounded box: decision point (consider implementing using Camel Dynamic Routing)
  • "DB" all refer to the same database and "bipClaimsApi` represents the same microservice; they're drawn separately to reduce clutter
  • Also to reduce clutter, the VRO_API_error box represents returning an error code back to the VRO API client.

For details, refer to:

Another workflow digram from Mural

Tasks

(only for single-issue hypertension CFI and presumptives; targeting Dec 31st deployment)

Ordered by priority:

Handling presumptives (NEW claims):

Other tasks:

  • DB metrics
    • claim_stats_Endpoint: Add claim_stats endpoint to API for reporting and monitoring. Other metrics (from Zach):
      1. how many claims are we evaluating programmatically for sufficient evidence?
      2. how many of those claims are deemed to have sufficient evidence?
      3. how many claims deemed to have insufficient evidence lead to an auto-exam?
      4. how many claims that are deemed to have sufficient evidence lead to: a) immediate rating, and b) not an immediate rating (e.g., deferral, manual exam)?
  • Ensure RabbitMQ messages are processed despite microservices failures
  • 🏃 (Ryan, Cameron) Connect VRO non-prod env with other VA non-prod envs
  • 🏃 Clean up codebase; comment out unused dependencies
  • 🏃 (Afsin) Add more automated end-to-end and integration testing
  • 🏃 (OCTO) Document how to update version numbers of VRO, container images, etc.
  • DONE: Persist API request contents for reloading in case of failures
  • Document how to extract microservices into Docker containers and deploy them
  • Document how to debug and modify DB data in prod
  • De-duplicate BP readings between LH and HDR (#1373)

Code improvements tasks

  • Mechanism to ensure microservices are idempotent and following good patterns
  • Document conventions on how requesters handle errors, such as resubmitting the request -- see comment (OBE task: Improve robustness to failures by using retry pattern -- retry logic in Camel)

Additional DevOps tasks

  • DONE: Set up test code coverage and other PR requirement checks. Search jacoco_enforce_violations in the code.
  • DONE: Enable linter and pre-commit hook
  • Set up LHDI monitoring and diagnostics tools, i.e. DataDog monitoring, Prometheus, Grafana, Jaeger
  • Set up DB querying (BI) tools for reporting, e.g., Metabase/Superset
  • Set up DB monitoring tools to detect slow queries, e.g., NewRelic
Clone this wiki locally