App K submissions - how to handle

[mdial89f]

This discussion will be the space where we talk about requirements, assumptions, technical approach, etc... the output being a recommended technical approach and most of a decision record, finalized after implementation.

---

What's an App K?

CMS Appendix K refers to a specific section of the Medicaid program's Home and Community-Based Services (HCBS) waivers. These waivers allow states to provide services to Medicaid beneficiaries in home or community settings, rather than institutional or nursing home settings.

Appendix K is a provision within these waivers that offers states the flexibility to rapidly adjust their HCBS programs to better respond to emergencies, including public health emergencies like a pandemic.

Appendix K became particularly relevant during the COVID-19 pandemic, as it allowed states to rapidly adapt their Medicaid HCBS programs to the changing needs and challenges posed by the public health crisis. It's a critical tool for ensuring that vulnerable populations continue to receive essential services in times of emergency.

Why do App Ks matter to mako?

Our application must support App Ks. The full lifecycle of an App K is included:

• initial submission
• rai requested by cms
• rai response submitted by state, received by cms
• rai response withdrawn by state
• package withdrawal

What about App Ks warrants a Discussion?

App K support has a few technical hurdles that need to be solved:

• App K's pose a novel challenge to our application, because there is a one to many relationship between submission and seatool packages. That is: a single App K submission spawns a variable (1 -> n) number of child packages.
• The programmatic relationship between parent (app k submission) and children (the 'n' number of packages spawned by that submission) does not exist in seatool. We must maintain that relationship in our own data stores. This is a technical challenge, as we need to determine the best way to store this relationship, but it's worth noting that we have much more flexibility in this area since seatool is uninvolved.
• We don't have screens for how we should view App Ks in app. With the one to many, parent/child relationship between an App K and its children, how we display App Ks in our dashboard and on details screen is expected to be different that other submissions we've done. This is a challenge as we will need to move forward with sensible designs based on the information we have while we work on getting more definitive guidance.

What do we know so far / What do we have for help?

• Onemac legacy currently supports App Ks, so we can look there for screens and design absent all else. Since legacy does not create the child packages spawned by an App K, it won't be helpful in that area.
• We learned that post submission actions taken on an App K submission are always taken against all children, everytime. For instance, if an RAI is issued for an App K submission, that RAI is issued for all underlying children. Think of the App K and its children as one unit, where actions are taken on the group.
• One notable exception to the bullet point above... withdrawing an individual package within an App K submission is sometimes required. So, the capability for individual package withdrawal needs to be present; the rest of the actions will always be against the group.
• The children packages that are spawned each receive a control number, or package number. These are currently supplied by the customer as an entry in their attached app K pdf form. We've gotten guidance from the business that it should be acceptable to require customers to enter the control numbers for each child in form text boxes, so we can easily retrieve their values on submission.

---

---

Here we will detail our design and recommended approach. This section will evolve as the discussion does, and be edited as appropriate.

Design Tenets

• We expect users to supply control numbers for all App K submission children. These control numbers will be entered into text boxes in the initial submission form.
• The values for control numbers supplied in the submission form text boxes will supersede any control numbers in an attachment.

---

[mdial89f]

Hi all, wanted to get this discussion going. The format for these is a WIP, so your patience and feedback are both appreciated.

App K support is something we will tackle in the next sprint or so. We had a great conversation with cms that shed light on what's expected, the biggest technical output being that we can expect users to put control numbers in form text boxes. Second to that, learning that all actions are taken on the app k group as a whole is important (with the exception of allowing individual package withdraw).

We need to determine a few things like how to map and maintain the relationship between parent and child. We need to determine and/or chase down answers around screens. Need to hammer out the fine detail of what the api endpoints do when we click submit.

Discussion, Questions, Comments, Brainstorming... all welcome here.

[mdial89f]

@pkim-gswell @kevinhaube @13bfrancis @Walesango2

[hannasage]

The programmatic relationship between parent (app k submission) and children (the 'n' number of packages spawned by that submission) does not exist in seatool. We must maintain that relationship in our own data stores. This is a technical challenge, as we need to determine the best way to store this relationship, but it's worth noting that we have much more flexibility in this area since seatool is uninvolved.

Are these children going to be pulled in and sinked for Mako, or are we simply trying to keep a reference of their existence for users to manually look up in SEATool?

If the former, I can see a getAppKChildren lambda being of use, maybe taking an array of those control numbers and bulk fetching from an AppK index or the SEATool sink.

There would still be manual requirements for users to associate those control numbers with the AppK, but at least then we're delivering the data in our front-end.

[pkim-gswell]

APP K - technical dive (Jan 26, 2024)

Notes

• User supplies Child Waiver IDs
  • FE validation: Unique?
  • Form Fields

Questions/Concerns

• Order of Magintude
  • Children Limit? (15)
  • How many APP-K/year?
• Still show withdrawn Child under APP-K?
  • Individual package withdrawn takes the package outside of the APP-K control
• APP-K does not originate from Seatool
  • If a child is editted in Seatool, do we handle? How do we handle
  • Will this cause drifts? warnings?
  • Should Child Status change that originate outside of oneMac sever the relationship APP-K.
• Should Dashboard Waivers be filterable by APP-k
• Does CPOC apply to all APP-K children or individual Child?
• Change Logs data duplication for APP-K log vs Child log?
• Show APP-K child on waiver Dashboard?
• UI Wireframes Design?

[pkim-gswell]

Jan 31 PK - MD

• APP-K only originate from new oneMac
  • Implementing

1. Write to waivers to Seatool.
2. Emit event to Kafka
   • new action type (APP-K)
   • each child need reference to parent
   • 2 way reference
3. Withdraw Child APP-K

• Keep reference, but future actions on APP-K do not apply to withdrawn children

4. APP-K Actions

• Can apply any waiver action