Select Benefit Specifications for Ancillary Lines
This flow is specifically for lines that are flagged as possible candidates to be an ancillary line to an adjudication case.
![Select Benefit Specifications for Ancillary Lines](../_images/select-benefit-specifications-for-ancillary-lines-1.gif)
This flow starts with the results of the initial benefit specification selection. Refer section 'Select Eligible Benefit Specifications' for details.
The flow in its entirety is executed per claim in the sense that the claim only moves to the validate selection step when all lines in the claim have traversed this flow. Each claim line is evaluated as long as no fatal message already exists at the beginning of this flow; as a consequence, a claim line already having a fatal message at the beginning of the flow cannot be attached to a adjudication case.
Recognize Ancillary Lines
If the claim line meets all the conditions set by at least one of the ancillary recognition rules, then the line is recognized as an ancillary line to the case. An adjudication case detail is created, linking the claim line to the existing adjudication case. If the adjudication case was created by another claim, the system also checks if the adjudication case is not voided: the system does not add ancillary lines to voided adjudication cases.
If an "Ancillary claim line recognition message" is specified in the case definition, this message is attached to the claim line.
If the case does not have an end date yet, the 'end date' dynamic function specified by the case definition is triggered, with the newly added ancillary line serving as input. The case end date is updated with the outcome of the function (which may also be null).
If the primary claim line is denied through one or more fatal messages (case created internally) - which could be product independent or product dependent for the same product as the one in question from the product benefit specification - OR is indicated as denied (case created externally, through the Case Integration Point), then the inherit message is attached to the claim line.
If the provider group scope inheritance is set in the case definition, then the provider group scope should be inherited from the primary claim line. A provider group scope inheritance of
-
IN means that if the primary line is IN then the ancillary line is also IN
-
OUT means that if the primary line is OUT then the ancillary line is also OUT
-
EITHER means that if the primary line is IN then the ancillary line is also IN and if the primary line is OUT then the ancillary line is also OUT
The provider group scope of the primary claim line is evaluated as follows:
-
if the case was sent in through the Case IP, then the provider group scope of the primary claim line was also sent in
-
if the case was created during claims processing, then the provider group scope of the primary line will be assessed as IN if the 'process as in' indicator of the primary claim line was checked. Otherwise, the provider group scope of the primary claim line will assessed as the product provider group scope of the primary claim line during processing; this is stored on the adjudication case detail of the primary line.
Whenever a claim line is included in a case as either primary or ancillary, the claim line start date must lie between the case start date and end date. Failing to meet this condition results in the following product specific message:
Code | Sev | Internal message |
---|---|---|
CLA-FL-BENS-005 |
Fatal |
The start date of the claim line should lie between the start date and the end date of the case ({'case.startDate'} - {'case.endDate'}). |
Refine Selection
Now that it has been determined whether or not the processed claim line belongs to a case, the remaining eligible coverage benefit specifications are filtered on the case definition:
If the claim line does not belong to a case, all coverage benefit specifications that specify a case definition are removed from the selection.
If the claim line does belong to one (or more) cases the coverage benefit specifications that refer to another case definition, i.e., a case definition that did not result in the claim line being attached to its case, are removed. Coverage benefit specifications without a case definition are retained in the selection.
The remaining product benefit specifications are filtered further on whether or not the claim line benefits provider is in or out of scope of the product provider groups and benefits specification provider groups. This happens in the same way as explained in the previous chapter. Because an ancillary claim line can inherit the provider group status from the adjudication case, this evaluation can not be placed earlier in the flow. See the appendix with a case recognition scenario for further clarification.