Admin Functions

Overview

Current admin functions: updatePackage , submitNOSO, and submitSplitSpa

Actions we can perform with these: update id, update fields, soft delete package, create a NOSO, create a split spa.

These functions are located in lib/lambda in the codebase.

The basics

1. Open up AWS Web Access, if this is your first time I suggest testing out on DEV before going to VAL. A quick refresh: Log into Kion > Select Projects > all Projects > Choose your environment

   

   Select 'macplatform-developer-admin'

   

   Select 'Web Acces'

   

2. Once you are in locate Lambda in the services on the AWS console. If you don’t see it in your recents you also can search for it.

4. Then you will need to search for your desired function. The naming convention goes as follows: mako-<branch-name>-api-<function-name> If I want to use submitNOSO on the main branch I would search: mako-main-api-submitNOSO

3. Once you click into the function you will then need to scroll down to the tabs “Code, Test,…” and click on the test tab.

4. You can create your own template or on the main & val branches there are saved events you can use as a starting point. (Further down there are examples if you want to reference those and then come back)

5. Once you are sure your JSON is how it should be, you run that yellow/orange Test button and you are good to go! 🙂  You should be able to see a change on the branch you are working on if it worked as expected.

Example JSONs

UpdatePackage

Delete

{
   "body": {
    "packageId": "MD-9276.R00.01",
    "action": "delete",
    "changeMade": "<SPA ID> deleted",
    "changeReason": "This package deletion was made per authorization from <CMS person who authorized this> because <reason>. "
   }
}

Recover The package you want to recover + "-del" at the end of it.

{
   "body": {
    "packageId": "MD-9276.R00.01-del",
    "action": "recover",
    "changeMade": "<SPA ID> package was recovered",
    "changeReason": "This <package ID> recovery was made per authorization from <CMS person who authorized this> because <reason>. "
   }
}

UpdateId

{
   "body": {
     "packageId": "MD-25-6738",
     "action": "update-id",
     "updatedId": "MD-25-6739",
     "changeMade": "SPA ID changed from <OLD ID> to <NEW ID>",
     "changeReason": "This package ID change was made per authorization from <CMS person who authorized this> because <reason>. (obviously if the change is something other than package ID, then the change reason should say so. "
   }
}

UpdateFields

Warning

If you are updating one of the following fields, you much use the epoch timestamp in milliseconds or there will be a silent failure.

• approvedEffectiveDate
• changedDate
• finalDispositionDate
• proposedDate
• statusDate
• submissionDate

{
   "body": {
     "packageId": "OH-1234.R12.60",
     "action": "update-values",
     "updatedFields": {
      "title": "new title"
     },
     "changeMade": "Example change made text",
     "changeReason": "Example change reason text"
   }
}

SubmitSplitSpa

If original package to be split exists in OneMAC

{
   "body": {
     "packageId": "MD-25-9999",
     "changeMade": "<insert Package ID> was manually added to OneMAC.",
     "changeReason": "This package was added to OneMAC per authorization from <CMS person who authorized this>. Package was split from SPA <original package ID>."
   }
}

If split package already exists in SEAtool (ex. MD-25-1235-A) and needs to be created in OneMAC. First you need to send a update "delete" message ine ONEMAC for example: MD-25-1235-A prior to sending this payload request:

{ 
  "body": {
    "packageId": "MD-25-1235",
    "newPackageIdSuffix": "A",
    "changeMade": "<insert Package ID> was manually added to OneMAC.",
    "changeReason": "This package was added to OneMAC per authorization from <CMS person who authorized this>. Package was split from SPA <original package ID>.",
    "status": "Submitted",
    "submitterEmail": "[george@example.com](mailto:george@example.com)",
    "submitterName": "George Harrison",
    "submissionDate": "06/26/2025 11:00:00 AM",
    "proposedDate": "06/26/2025"
  }
}

Note: Only should be used with Medicaid SPA's. This function will programmatically append the next letter in the alphabet to the id.

SubmitNOSO

Waiver

{
   "body": {
     "id": "MD-2333.R00.00",
     "authority": "1915(b)",
     "status": "Submitted",
     "submitterEmail": "[george@example.com](mailto:george@example.com)",
     "submitterName": "George Harrison",
     "submissionDate": "01/01/2025 11:00:00 AM",
     "proposedDate": "02/20/2025",
     "adminChangeType": "NOSO",
     "mockEvent": "capitated-initial",
     "changeMade": "<insert Package ID> was manually added to OneMAC. Contact your CPOC to verify the initial submission documents.",
     "changeReason": "This package was added to OneMAC per authorization from <CMS person who authorized this>. <SPA/Waiver> originally submitted through <email/MACPro/WMS/MMDL/etc>."
    }
}

AppK

{
   "body": {
    "id": "CO-3434.R00.01",
    "authority": "1915(c)",
    "status": "Submitted",
    "submitterEmail": "[george@example.com](mailto:george@example.com)",
    "submitterName": "George Harrison",
    "submissionDate": "01/01/2025 11:00:00 AM",
    "proposedDate": "02/20/2025",
    "adminChangeType": "NOSO",
    "mockEvent": "app-k",
    "changeMade": "<insert Package ID> was manually added to OneMAC. Contact your CPOC to verify the initial submission documents.",
    "changeReason": "This package was added to OneMAC per authorization from <CMS person who authorized this>. <SPA/Waiver> originally submitted through <email/MACPro/WMS/MMDL/etc>."
    }
}

CHIP SPA

{
   "body": {
    "id": "CO-25-1234",
    "authority": "CHIP SPA",
    "status": "Submitted",
    "submitterEmail": "[george@example.com](mailto:george@example.com)",
    "submitterName": "George Harrison",
    "submissionDate": "01/01/2025 11:00:00 AM",
    "proposedDate": "02/20/2025",
    "adminChangeType": "NOSO",
    "mockEvent": "new-chip-submission",
    "changeMade": "<insert Package ID> was manually added to OneMAC. Contact your CPOC to verify the initial submission documents.",
    "changeReason": "This package was added to OneMAC per authorization from <CMS person who authorized this>. <SPA/Waiver> originally submitted through <email/MACPro/WMS/MMDL/etc>."
    }
}

Medicaid

{
   "body": {
    "id": "CO-34-1234",
    "authority": "Medicaid SPA",
    "status": "Submitted",
    "submitterEmail": "[george@example.com](mailto:george@example.com)",
    "submitterName": "George Harrison",
    "submissionDate": "01/01/2025 11:00:00 AM",
    "proposedDate": "02/20/2025",
    "adminChangeType": "NOSO",
    "mockEvent": "new-medicaid-submission",
    "changeMade": "<insert Package ID> was manually added to OneMAC. Contact your CPOC to verify the initial submission documents.",
    "changeReason": "This package was added to OneMAC per authorization from <CMS person who authorized this>. <SPA/Waiver> originally submitted through <email/MACPro/WMS/MMDL/etc>."
    }
}

MMDL

{
   "body": {
    "id": "CO-25-1234",
    "authority": "CHIP SPA",
    "status": "Submitted",
    "submitterEmail": "[george@example.com](mailto:george@example.com)",
    "submitterName": "George Harrison",
    "submissionDate": "01/01/2025 11:00:00 AM",
     "proposedDate": "02/20/2025",
    "adminChangeType": "NOSO",
    "mockEvent": "new-chip-submission",
    "changeMade": "<insert Package ID> was manually added to OneMAC. Contact your CPOC to verify the initial submission documents.",
    "changeReason": "This package was added to OneMAC per authorization from <CMS person who authorized this>. <SPA/Waiver> originally submitted through <email/MACPro/WMS/MMDL/etc>."
    }
}

Not Showing Up? Errors? and Other Problems….

Not Showing Up

Likely there was an error along the way that prevented the package from appearing, or making the admin change. The first place to look is in the green or red box that says Executing function: ...

The next place to look is in that “logs” portion. Sometimes the error messages are too long to be displayed in this small box.

If you aren’t seeing any errors here, but your package still isn’t looking how you expect the next place you can go is looking at the log groups from sink main & sink change log. From the previous page click on “Log Groups” on the top left hand corner.

Or you can search “Cloud Watch” then click on “Log Groups”

Then search for your branch using the following format: mako-<branch>-data-sinkMain and mako-<branch>-data-sinkChangelog (In this example I am using main branch).

Then starting from the latest you can click to view each log stream. I am sorry there is not a better way that I know of at the moment but if you just ran the function, it should be near the top.

An error will look something like this, though it may depend on what you are working with. Hopefully that can give you some insight into what could be going wrong.

Note: A NOSO that is successful will still return a 404 in openSearch because the function checks if the package already exists. So that error can be ignored.

What is a NOSO and Split Spa?

NOSO

NOSO stands for "not originally submitted in OneMAC". This is the case when a package is submitted in SEATool or MMDL before it is in OneMAC so we want to run this admin function to manually create a package to match.

Currently (2/18/2025) OneMAC we read from SEATool and we update current packages to match what is in SEATool, but if a package is not created in OneMAC it will not appear on our dashboard. So after running submitNOSO for the NOSO package, OneMAC will then update it to match what is also on SEATool. At this time we do not read from MMDL, so any data we would like to transfer over has to inputted manually.

Split Spa

Split Spa's are another type of NOSO. Split SPA's only happen with Medicaid SPAS. From my (Andie's) understanding split spa's occur when the SPA itself becomes too large or one part is approved and other part is waiting. Like splitting up a large ticket, they want to keep the same ID but track the different progress.

• Additional information "Certain "Reviewable Units" (RUs) in the package should be split off from the package and submitted separately. This is usually needed because some portion of the package is ready to go and should not be held up by other RUs for which there are issues, or because it is too complicated to handle all the RUs as one package. When the package is split, the new package created must retain the same original submission date, if there is one. The new package must be manually added in Mako."