Currently, EP Merge does not abort jobs that should have been ineligible from the start. For example, EP Merge will fail in error if the benefit claim type code of the EP400 is anything but 400SUPP. This was noticed in production logs when jobs were failing at the GET_EP400_CLAIM state.
Acceptance Criteria
EP Merge should be updated to include a new ABORTED end state, where any claims that should not be merged due to ineligible criteria:
Pending claim details response is OK but contains no claim details 1
Pending claim details end product code is not populated 1
Pending claim is not open when the request is received 2
EP400 claim details response is OK but contains no claim details 1
🆕 EP400 claim is not open when the request is received before getting claim contentions 2
EP400 claim details end product code is not populated 1
EP400 claim details benefit claim type code is not populated 1
EP400 claim details benefit claim type code is not 400SUPP
EP400 claim does not have any contentions after 60s 3
Pending Ep is no longer open after gathering EP400 contentions 2
🆕 EP 400 is no longer open after gathering EP400 contentions 2
1 - This is unlikely to happen in any deployed environment, but rather a result of not having a good enough mock service to represent actual data.
2 - This is a mechanism to address the race of EP Merge to begin processing vs the claim being closed elsewhere, bottom line = closed claims are not eligible.
3 - This will only happen if there is a 60 second slow down in the time it takes the claim to have populated contentions, if this is the case the slow down will not be detectable by EP Merge or VRO downstream services, bottom line = No contentions on EP400 means claim is not eligible to merge
Summary
Currently, EP Merge does not abort jobs that should have been ineligible from the start. For example, EP Merge will fail in error if the benefit claim type code of the EP400 is anything but
400SUPP. This was noticed in production logs when jobs were failing at theGET_EP400_CLAIMstate.Acceptance Criteria
EP Merge should be updated to include a new ABORTED end state, where any claims that should not be merged due to ineligible criteria:
400SUPP1 - This is unlikely to happen in any deployed environment, but rather a result of not having a good enough mock service to represent actual data. 2 - This is a mechanism to address the race of EP Merge to begin processing vs the claim being closed elsewhere, bottom line = closed claims are not eligible. 3 - This will only happen if there is a 60 second slow down in the time it takes the claim to have populated contentions, if this is the case the slow down will not be detectable by EP Merge or VRO downstream services, bottom line = No contentions on EP400 means claim is not eligible to merge