Policy selection and eligibility module
Once the member receiving services has been uniquely identified, SCE will identify the appropriate policy to adjudicate against by selecting the policy submitted on the claim, by applying ranking from a membership system or by systematically identifying the correct policy. The SCE provides the SMP module to perform this task.
Policy searchOnce the SCE has identified the member receiving services or the subscriber who is the transplant recipient or under whose policy a newborn claim is being adjudicated, the SCE performs the following steps to select the appropriate policy for adjudication or apply appropriate event codes when necessary.
Policy searchThe SCE will look for policies for the member or subscriber based on the dates of service on the claim, expanded by the Policy selection look back period and the effective and end dates on the policy. The Policy selection look back period is defined in the Policy selection and eligibility configuration screen.
If no policies are found for the appropriate plan type, the SCE will raise event code SMP-0001 (Policy Not Found). The plan types are defined as:
- Medical – When the claim form type is I (institutional) or P (professional)
- Dental – When the claim form type is D (dental)
Note: examiners with appropriate access can manually select a policy during the member selection event resolution. These manual choices will override the SCE policy search and ranking.
Check eligibilityThe policies returned from the search are then validated for eligibility. Eligibility is validated by comparing the policy effective and end dates to the dates of service on the claim. If the claim covers at least part of the policy effective dates, that policy is available for ranking and adjudication.
If a no active policies are identified, the following event codes will be applied:
- SMP-0002 – The subscriber on the claim is not eligible, and assigned when the relationship code on the claim is “18” – Self
- SMP-0003 – The patient on the claim is not eligible, and assigned when the relationship code on the claim is any value other than “18”
If multiple policies are found, the ranking needs to be applied before eligibility can be performed. Eligibility edits may also be applied after ranking the multiple policies or splitting the claim or claim line. These eligibility edits are detailed in the following sections.
Policy rankingWhen multiple policies are identified, the SCE has 3 options to choose from when selecting the appropriate policy:
- External ranking – If the membership system provides policy ranks, that ranking is applied to policy selection and the highest ranked policy is selected. When a policy is selected based on the rank from eligibility system, the system adds the audit message “Policy ranked using external eligibility system” to the audit trail.
- Submitted policy - If ranking is not received from the membership system, and the “Submitted policy” is enabled on the “Select policy category” setting in the Policy selection and eligibility system settings, the SCE will adjudicate the claim against the submitted policy and add the appropriate audit message.
- Highest ranked policy – If “Highest ranked policy” is enabled on the “Select policy category” setting in the Policy selection and eligibility system settings, the policies will be ranked by the SCE using the RankPolicies decision table and the appropriate audit message will be added.
The rank policies decision table allows policy rankings to be defined based on Contract type and Line of business. The decision table further allows the application of a differentiator like the birthday rule when more than one policy has the same rank. The ranking decision table can be extended to add other criteria to be utilized in ranking. The table returns the rank and a differentiator if required.
The BirthdayRule method, provided by the SCE, is used to determine when a plan is primary or secondary for a dependent child when covered by both parents' benefit plan. The parent whose birthday (month and day only) falls first in a calendar year is the parent who would be considered as the parent with the primary coverage for the dependent. While calculating the birthday rule, SCE would be considering only the dates and months of birth for considering the policy to be picked for adjudication. The policy with the person having oldest DOB will be considered for adjudication as per the birthday rule.
Once the policy is selected, updates to the claim may be required. Based on the policy chosen, the associated contract, payer, plan, subscriber, relationship code, etc. will be updated on the claim. Adjudication will be based on the information from the selected policy. Audit messages are reported to track the changes from the submitted policy are displayed in the claim history. For example, if the submitted policy is different from the adjudicated one, an audit message is reported which states “The submitted policy is X and the adjudicated policy is Y".
Validate policiesThis step in the policy selection and eligibility module is to validate the information on the claim against the selected policy.
The SCE performs a series of validations, verifying the payer demographics on the policy selected against the information supplied on the claim. In addition to validating the key demographic information on the payer, the SCE also looks to see if the contract or plan submitted on the claim are found in the system.
The following validations are performed between the claim and the selected policy:
- Contract not found - The contract associated with the submitted policy is not found in the system. Event code SMP-0013 is raised on the claim.
- Plan not found - The plan submitted on the claim is not associated with the policy stored in the system. Event code SMP-0014 is raised on the claim.
- Relationship code mismatch – The relationship code submitted on the claim does not match the relationship code associated with the member record for that policy in the system. Event code SMP-0006 is raised on the claim.
- Payer city mismatch – The payer city submitted on the claim does not match the payer city stored in the system. Event code SMP-0007 is raised on the claim.
- Payer state mismatch – The payer state submitted on the claim does not match the payer state stored in the system. Event code SMP-0008 is raised on the claim.
- Payer ZIP code mismatch – The payer ZIP code submitted on the claim does not match the payer ZIP code stored in the system. Event code SMP-0009 is raised on the claim.
- Payer address mismatch – The payer address submitted on the claim does not match the payer address stored in the system. Event code SMP-0010 is raised on the claim.
- Payer name mismatch – The payer name submitted on the claim does not match the payer name stored in the system. Event code SMP-0011 is raised on the claim.
- Payer ID mismatch – The payer ID submitted on the claim does not match the payer ID stored in the system. Event code SMP-0012 is raised on the claim.
The policy selection and eligibility module is also used to split claims based on specific member eligibility scenarios. In the instance that the member policy is terminated, and the claim or line needs to be split to support adjudication against the covered period., the SCE can split the claims or lines based on the appropriate policy effective and end dates. The member split models use the standard split claims criteria and bypass models to include or exclude the claims for split. Information on the split rules applied, the criteria, bypass rules, claims display and subsequent processing can be found in the Split Claims section of business edits.
To enable the splitting of claims based on the member policy period, the criterion “Member plan termination” needs to be set to True on the SplitClaimsCriteria table.
If this is switched on, the claim will split into two claims, one where the member has coverage and the other where the member does not. If this flag is switched off, the SCE will automatically split any lines based on the policy effective and end dates. The advantage of splitting the claim and not the line, is that when the split claims are reprocessed, the claim associated with the non-covered portion of the policy may subsequently match to another effective policy for adjudication.
When the claim is split, one claim will contain all the service lines that are covered and the other will contain the service lines that are not covered by the policy. If any service lines span the policy coverage period, they will also be split, so that the covered dates will be on the covered claim and the non-covered dates will be on the non-covered claim.
If split claim is enabled, the original claim will be assigned action code ASOC – automatic split original claim and the status of the claim will be Resolved-Split. The new split claims will then be adjudicated, and the claim not covered by this policy would set either event code SMP-0002 or SMP-0003 (subscriber or patient ineligible). If the non-covered claim matches a different effective policy, this will be assigned, and the event codes subsequently not applied.
If the split claim is not enabled, and claim lines contain dates of service overlapping the policy dates, these lines will be split into new lines, one containing the dates of service covered by the policy and the other containing the dates not covered by the policy. The lines not covered by the policy are assigned either SMP-0004 (subscriber ineligible on dates of service) or SMP-0005 (patient ineligible on dates of service), depending upon the relationship code on the claim. Claims with the relationship code of 18 (self) is assigned SMP-0004 and claims with any other relationship code are assigned SMP-0005.
The table below, provides an example where the policy overlaps the dates of service on the claim and the split claim configuration is switched on.
Policy | Effective Date | End Date |
HMO | 1/1/2018 | 10/30/2018 |
Claim | DOS | Expected Results |
Line 1 | 10/20/2018-10/22/2018 | |
Line 2 | 10/25/2018-10/27/2018 | |
Line 3 | 11/1/2018-11/2/2018 | |
Line 4 | 10/28/2018-10/29/2018 |
The table below, shows a similar situation, but in this case, the claim lines are also split as they overlap the policy dates.
Policy | Effective Date | End Date |
HMO | 1/1/2018 | 10/30/2018 |
Claim | DOS | Expected Results |
Line 1 | 10/20/2018-10/22/2018 | |
Line 2 | 10/25/2018-11/5/20/18 | |
Line 3 | 11/1/2018-11/2/2018 | |
Line 4 | 10/28/2018-10/29/2018 |
The table below, shows the same scenario, but in this situation, the claims split configuration is not enabled and only the lines are split.
Policy | Effective Date | End Date |
HMO | 1/1/2018 | 10/30/2018 |
Claim | DOS | Expected Results |
Line 1 | 10/20/2018-10/22/2018 | |
Line 2 | 10/25/2018-11/5/20/18 | |
Line 3 | 11/1/2018-11/2/2018 | |
Line 4 | 10/28/2018-10/29/2018 |
Audit messages for the activities associated with the splitting of the claims or lines are documented in the claims audit log. Claim lines which are split are assigned action code SP-102 – claim line is a split claim line. Claims which are split are assigned action code SPC5 – claim split based on member plan termination date.
Policy selection and eligibility event codesEvent code | Name | Description |
SMP-0001 | Policy not found | The information submitted on the claim does not match any policy stored in the system for this member. |
SMP-0002 | Subscriber ineligible | The subscriber has no active coverage for the dates of service. |
SMP-0003 | Patient ineligible | The patient has no active coverage for the dates of service. |
SMP-0004 | Subscriber ineligible on DOS | The subscriber has no active coverage for the DOS (date of service) billed on the claim line. |
SMP-0005 | Patient ineligible on DOS | The patient has no active coverage for the DOS (date of service) billed on the claim line. |
SMP-0006 | Relationship code mismatch | The relationship code submitted on the claim does not match the relationship code on the member record stored in the system. |
SMP-0007 | Payer city mismatch | The payer city submitted on the claim does not match the payer city stored in the system. |
SMP-0008 | Payer state mismatch | The payer state submitted on the claim does not match the payer state stored in the system. |
SMP-0009 | Payer ZIP code mismatch | The payer ZIP code submitted on the claim does not match the payer ZIP stored in the system. |
SMP-0010 | Payer address mismatch | The payer address submitted on the claim does not match the payer address stored in the system. |
SMP-0011 | Payer name mismatch | The payer name submitted on the claim does not match the payer associated with the policy stored in the system. |
SMP-0012 | Payer ID mismatch | The payer ID submitted on the claim does not match the payer associated with the policy stored in the system. |
SMP-0013 | Contract not found | The contract associated with the submitted policy is not found in the system. |
SMP-0014 | Plan not found | The plan submitted on the claim is not associated with the policy stored in the system. |
SCE is delivered with several event codes related to policy selection and eligibility. They are raised in varying situations, but typically when a record is not found or there is a discrepancy between the data in the system of record and the data on the claim.
Action codes raised during adjudication are leveraged to suppress some of these event codes in certain circumstances, as the change in data is intentional. The action codes detailed below can be used to override any of the event codes in the list above.
If the values submitted on the claim differ from those used during adjudication, action code SMP-01 (Selected policy for adjudication differs from the submitted policy) is raised. If the changes include a change to the subscriber, Action code SUBCHG (Subscriber Change) is raised.
Previous topic Member validation module Next topic Provider match