feat(modify rai behavior): Go to PENDING_RAI and leave receivedDate on withdraw #466
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ithdraw, and do not nullify received
…ting data that was directly touched in seatool
mdial89f
added
type: FEAT
mdial89f
requested review from
benjaminpaige,
hannasage,
13bfrancis and
pkim-gswell
pkim-gswell
approved these changes
Mar 26, 2024
hannasage
approved these changes
Mar 26, 2024
| console.log("State withdrawing an RAI Response"); | ||
| if (!document.raiRequestedDate) { | ||
| return response({ | ||
| statusCode: 400, |
There was a problem hiding this comment.
love that we're building in codes and messaging now!
|
🎉 This PR is included in version 1.5.0-val.20 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose
This changeset updates our withdraw rai response ruleset and the actions it takes. For all authorities (Medicaid, CHIP, Waivers), on RAI Response withdraw, we put the record back into PENDING_RAI. We also leave the received date in place, to only be overwritten on a re-response.
Linked Issues to Close
Closes https://qmacbis.atlassian.net/jira/software/c/projects/OY2/boards/261/?selectedIssue=OY2-27600
Approach
Background
Previously, for medicaid and waivers, we had been nullifying the received date on rai response withdraw. This had the convenient effect of showing the RAI with a blank received date, ready for re-response. We felt this was acceptable since all of the info is logged to status memo. Business groups communicated that they would prefer to just write the withdraw date on withdraw, and leave the received date in place. In this scenario, the received date will only be overwritten if/when there is a re-response. This makes that change.
In addition, CHIP submissions had been being put into PENDING on withdraw; we had misunderstood, and thought since CHIP can receive more than one RAI, that upon withdraw a CMS resource would create a new RAI if applicable. That isn't the case, per feedback yesterday. The RAI for which the response was withdrawn should still be available for re-response. CMS may choose to issue a new RAI against the CHIP, if applicable, but that's outside our area of concern. For CHIPs (and all other authorities), records go back to PENDING_RAI on withdraw.
To make logging on response verbose, I had to move the safeParsing of the api payload to the top of the function. This is a pattern used for withdrawing the package, and a good pattern to follow. Along with moving safe parsing to the top to fail fast, I removed some 'throws' in favor of returning response codes, also a pattern put in place for withdraw package.
Summary of updated logic:
Assorted Notes/Considerations/Learning
N/A