ADR - Enhanced RAI Response Intake Tracking

[mdial89f]

Architecture Decision Record (ADR)

Enhanced RAI Response Intake Tracking

Status

In Review

Context

The CMS adjudication process for State Plan Amendments (SPAs) and waivers utilizes a Request for Additional Information (RAI) mechanism, pausing the 90-day review timeline until states provide the necessary information. This pause allows states to respond without the pressure of the deadline. CMS employs email notifications for RAI responses through the onemac system, including both its legacy and micro versions. The legacy onemac uses a single "Submitted - Intake Needed" status for all intake types, whereas the micro onemac introduced a separate "Initial Intake Needed" substatus for new submissions and is now implementing an "RAI Response Intake Needed" substatus.

Two main options were considered for implementing this new substatus, with the focus on maintaining the net behavior between the legacy and micro systems, minimizing changes to CMS processes and user workflows, and accommodating the Medicaid and Waivers process where an RAI can be issued, responded to, and retracted multiple times.

Decision

We have tentaively decided to proceed with Option 2 for implementing the "RAI Response Intake Needed" substatus.

Option 1: RAI Response Timestamp Differentiation

• Behavior: Utilizes a timestamp distinction to display the "RAI Response Intake Needed" substatus, which clears upon the next record save in Seatool.
• Assessment:
  • Pros: Unchanged Seatool user experience, same logic as legacy onemac.
  • Cons: Potential premature substatus clearance, continued display of substatus if no changes are saved in Seatool.

Option 2: SinkMain Lambda Indexing (Tenatively Selected)

• Behavior: The sinkMain lambda indexes an raiResponseUpdated field upon an RAI response submission event, displaying the "RAI Response Intake Needed" substatus until the record is next saved in Seatool, at which point the substatus clears.
• Assessment:
  • Pros: Unchanged Seatool user experience, aligns with legacy onemac logic.
  • Cons: Potential for premature substatus clearance, substatus may continue to show if no changes are saved in Seatool despite completed intake.

Rationale

Option 2 was selected due to its ability to more accurately track and clear the "RAI Response Intake Needed" substatus in a way that mirrors the intention behind the CMS adjudication process enhancements. This option provides a clear mechanism for CMS personnel to know when an RAI response has been submitted and requires intake, without significantly altering existing workflows or the Seatool user experience. Additionally, this approach offers a technical solution that respects the complexities of the Medicaid and Waivers process, including multiple submissions and retractions of RAI responses.

Consequences

• The "RAI Response Intake Needed" substatus will now be an integral part of the micro onemac system, facilitating better tracking and management of SPA and waiver adjudications.
• Users can quickly filter the dashboard to get a list of all RAI Response submission needing intake; reports can be generated as well.
• The net behavior of the substatus is the same as legacy.

Future Considerations

CMS may decide to change the substatus text, perhaps from 'RAI Response Intake Needed' to 'RAI Intake Needed' or something similar. If that occurs, it should be a very simple text update.

[mdial89f]

We talked at length about option 1.... which hinges on slightly marking the timestamp in a way that we will know if mako last touched it.
Details regarding option 2 are added.