App K - Brief - writing children vs not

[mdial89f]

App K submission and tracking

CMS Appendix K waivers enable states to modify their Home and Community-Based Services (HCBS) Medicaid waivers during emergencies, ensuring continuity of care for Medicaid participants. These submissions allow the amendment of one to many waivers, so a single Appendix K submission may spawn an unknown number of seatool objects.

Legacy OneMAC System

• Single ID Collection: A single ID is collected for tracking the App K package.
• CMS Personnel Intake Management: Involves opening PDF attachments to retrieve additional waiver control numbers/IDs and creating all related waivers in seatool

OneMAC Micro System

Option 1 (as built):

• Functionality: State users enter IDs for all waivers involved in the App K submission, allowing the system to programmatically create all related waivers.
• Pros:
  • Establishes a clear relationship between all waivers within an App K.
  • Ensures all waivers are created upon submission.
  • Enables operations on waivers within an App K, such as removal or independent adjudication of a removed waiver.
• Cons:
  • Users must input control numbers and possibly titles for each waiver, duplicating information already in attachments.

Option 2

• Functionality: State users submit the ID of one waiver (the "parent"), and CMS personnel handle the creation of other waivers (the "children").
• Pros:
  • Maintains the user experience from the legacy system.
• Cons:
  • The relationship between the parent waiver and its children is not established in the system.
  • Manual creation of child waivers by CMS personnel is error-prone.
  • The system cannot take action on child waivers.
  • There's no programmatic way to reflect changes to child waivers in the system.

Note

Both systems use a single ID (the "parent") to track the App K package, with the other waivers (the "children") not directly associated in the system. The terminology of "parent" and "children" is used for clarity, though all are technically "siblings." Option 1 suggests the possibility of a unique App K identifier to better represent the relationship among waivers, a feature not feasible with Option 2. This approach could lead to a more accurate modeling of the App K waivers' relationships, irrespective of the SEAT tool's current limitations.
Said another way: with Option 1, you have the flexibility to move away from tracking App Ks based on an arbitrary waiver ID in OneMAC, and instead, adopt an App K identifier that encompasses all waivers, without affecting SEAT tool operations.