Gathering Enrollment Data

In this step of the flow, the application sends out a request for the member’s enrollment information. The application requires this enrollment information to adjudicate the claim. The purpose of this call out is to retrieve:

• Products Information (including the applicable parameter values and provider groups) on which the serviced person or object is enrolled; this information drives the benefit selection

• Family Identifiers to which the serviced person or object belong; this information is required for family level limits

• Dates that are required to evaluated waiting periods for specific benefits

The enrollment information in the response is persisted, but is replaced as soon as there is a new call out, for example when the claim is processed a second time. Note that the application also includes a feature to purge the persisted enrollment information.

Note that locked claim lines and replaced claim lines are ignored during this step.

Fetch Existing Enrollment Data

The system calls out for enrollment data either if there is no enrollment data available or if the available data has expired. If the system does not call out, then the next step in the flow are the end enrollment derivation rules. Otherwise, the system calls out with a request for current enrollment information. This request inlcudes the following parameters:

• Claim code

• The serviced person’s code

• Start date: the start date is the earliest date of all the claim line start ates and claim line pricing input dates; an unspecified date (like a pricing input date being null) doesn’t impact the start date of the request

• End date: the end date is the latest date of all the claim line end dates and claim line pricing input dates; an unspecified date (like a claim line end date being null) doesn’t impact the end date of the request

If the data is present, then it is checked if it is not expired. This is done by checking if the time elapsed between now and when the existing enrollment data was received is less than the cache expiry time in theproperty 'ohi.processing.enrollment.cacheexpiry'. Refer to Property Management for more information on setting a property. This property has a value of 5 minutes by default.

Remove Existing Enrollment Messages

All claim line messages that originate from a previous enrollment call out are discarded.

Remove Enrollment Data

If there is existing enrollment data and it has expired then this data will be discarded. Specifically the following information is discarded: (1) policy products (including policy product parameters and policy product provider groups) and (2) policy family codes.

Request Enrollment Data

Claims communicates with the enrollment system of record though the enrollment request integration point. Claims sends synchronous enrollment requests per Serviced Person per Claim.

The request contains five attributes:

• The Insurable Entity Type Code

• The Insurable Entity’s Code i.e Code of the serviced Person or object

The enrollment interface presumes that providing only the serviced entity’s unique code will suffice in order to get a correct response, that is, it is not required to provide any further context such as the brand or payer. A person or object can have multiple brands and payers in Claims. There can be situation where a person or an object is enrolled on two identical products of different brands but same insurance type. In such a case, the enrollment interface provides no means to distinguish between the two products. It is the responsibility of the enrollment system to prevent redundant insurance.

Insurance Type Code

Claims expects the enrollment information for the specified insurance type.

The Start Date of the Period for Which Enrollment Information is Requested

The start date is the earliest date of all the claim line start dates and claim line pricing input dates; an unspecified date (like a pricing input date being null) doesn’t impact the start date of the request.

The End Date of the Period for Which Enrollment Information is Requested

The end date is the latest date of all the claim line end dates and claim line pricing input dates; an unspecified date (like a claim line end date being null) doesn’t impact the end date of the request.

Requests are not sent out if a fatal message of origin SANITY CHECKS exists that is attached to the claim. The enrollment request is not sent out for a specific person or object, if all claim lines for that person or object have a product independent fatal message of origin SANITY CHECKS (either on the line or bill).

This integration point can be disabled by setting a property. If disabled, the claim skips ahead towards the level 2: Claim Classification flow. Refer to Property Management for more information. The ability to disable this integration point is intended for implementations in which the enrollment information is not required to process claims.

Receive Enrollment Data

Once the request(s) for a single claim is/are sent out, the system expects a response for every sent out request. In the event that no response(s) is/are received, the claim pends with a technical error. These claims are accessible and can be resubmitted for processing in the "View Technical Errors" page once the interface has been restored.

Once the enrollment request(s) has/have been responded to, the content of this/these response(s) is validated. The following situations result in a fatal message on the claim line(s):

• The product code is unknown

• The employer code is unknown

• The message code is unknown

• The message product code, which is mandatory, is not among the response’s policy products

• The currency code is unknown

• The provider group code is unknown

• For a certain period within the start and end date of the claim, a product is specified but no family code is specified

• More than one family code is specified for a certain time period

• The dynamic field name, flex code definition or value is unknown

The following product independent fatal error messages are attached^[1] as a result of one of the situations described above:

Code	Sev	Text
CLA-IP-ENRO-010	Fatal	The product code {code} is unknown
CLA-IP-ENRO-016	Fatal	The employer code {code} is unknown
CLA-IP-ENRO-005	Fatal	No more than one family code may be specified at any time
CLA-IP-ENRO-006	Fatal	The message code {code} is unknown
CLA-IP-ENRO-009	Fatal	A family code must be provided for each day that the person or object is subscribed to a product
CLA-IP-ENRO-020	Fatal	The product {code} for message {code} is not one of the provided policy products
CLA-IP-ENRO-021	Fatal	The provider group code {code} is unknown

In addition, this integration point can return product independent fatal messages in the context of ill defined dynamic field or dynamic record elements, for example the dynamic field name specified in the response does not match with a dynamic field usage on the POLICY PRODUCTS table. An unknown currency code will also lead to a product independent fatal message. These errors will also be attached to the claim line. Other errors such as database constraint violations will lead to a technically errored task.

Storing Enrollment Data

The enrollment information is persisted so that it remains available until it’s either overwritten or removed due to the claim being reprocessed or due to a purge. Note that the enrollment data is not stored when the payload leads to a fatal message, for example due to an unknown code in the payload.

The enrollment information is stored in the form of the following entities:

• Policy Product

• Policy Product Parameter

• Policy Product Provider Group

• Policy Family

Policy Product

To determine the benefits for a serviced person or object, Claims needs to know to what products it is subscribed to. The response message contains the code for the product, which is expected to match the product code as setup in Claims. In turn, Claims derives the applicable benefits for that product.

A serviced person or object can have multiple products at any given point in time. Each product in the response specifies a startDate and possibly an endDate.

The subscriptionDate (contractDate) and subscriptionEndDate (contractEndDate) specify the dates on which the subscription on that product started and ended. These dates are used to determine limits that apply per contract year, rather than for example, per calendar year.

For example, if the request message specified a period from 2008-01-01 to 2008-12-31 and that serviced person’s contract for a particular product started on 2006-05-01 and ended on 2009-04-30, then the replied <product> would ideally contain startDate 2008-01-01, endDate 2008-12-31, subscriptionDate (contractDate) 2006-05-01 and subscriptionEndDate (contractEndDate) 2009-04-30.

The following information is persisted for each product included in the enrollment response:

Policy Product

Field	Description
claim	The claim that triggered the enrollment request.
insurable entity	The person or object (insurable entity) that is the subject of the enrollment request.
product	The product to for which the person or object is enrolled.
start date	First day that the information in this entity is valid.
end date	Last day that the information in this entity is valid.
subscription date	First day of the person’s or object’s subscription contract for this product.
subscription end date	Last day of the person’s or object’s subscription contract for this product.
employer	The organization to which the serviced person’s or object’s enrollment is linked to. This could be serviced person’s employer, policy holder’s employer etc
factor	The prorated factor that indicates which part of a time period the person or object is enrolled for the product.
coverage level	Indicates the general level of coverage provided by this product. Used to evaluate waiting periods.

This entity is extensible with dynamic fields and records. The response message can specify the values for the dynamic fields or records on this table. It is possible to 'copy' the values for these dynamic fields to the claim by setting up a derivation rule, in order to make sure they persist. "Derivation Rules" are described in the Process Rules chapter of the Configuration Guide.

Policy Product Parameter

It is possible for copayment, coinsurance, limit and reinsurance values to be included in the enrollment response payload. If so, these parameters are applied to the claim line in case a product benefit specification parameter is applied with a matching alias code, overriding any value that may be specified on the product benefit specification parameter itself. The parameters that belong to a policy product are stored as follows:

Policy Product Parameter Table

Field	Description
policy product	The policy product.
alias code	The alias code of the parameter.
amount	The value (amount) of the parameter.
currency	The currency of the amount.
percentage	The value (percentage) of the parameter.
number	The value (number) of the parameter.
service days	The value (service days) of the parameter.

Policy Product Provider Group

It is possible for provider groups to be included in the enrollment response payload. These provider groups can then be used as the core network of a product when determining network status in the claims flow. The provider groups that belong to a policy product are stored as follows:

Policy Product Provider Group Table

Field	Description
policy product	The policy product.
assignment label	The qualifying label for the assignment of the provider group.
provider group	The provider group.
start date	First day that the information in this entity is valid.
end date	Last day that the information in this entity is valid.

Policy Family

The application relies on external systems to tell it on which products a member is enrolled. Consequently it does not store information on which member are considered to be part of the same family. To support family limits the system keeps track which family a service member belongs to assign any health care consumption to that family.

The application requires that a serviced member has exactly one and only one family code at any given point in time. The family code may change over time, but the system requires that the response specifies a family code for every day within the requested time period.

The family codes are stored as follows:

Policy Family Table

Field	Description
claim	The claim that triggered the enrollment request.
insurable entity	The person or object (insurable entity) that is the subject of the enrollment request
family code	Reference to the family, used to keep track of family limits.
start date	First day that the information in this entity is valid.
end date	Last day that the information in this entity is valid.

Attach Messages

The enrollment (product specific) messages returned in the enrollment response are attached to each and every claim line of the specified person or object, on the condition that the start/end date of the corresponding <product> element overlaps with the start/end date of the claim line. These messages are stored directly on the claim lines and not as part of the enrollment response payload.

Note that it is only after the benefits have been applied, that is, when it is known which product(s) actually provide(s) the benefit, that it is determined which of those product specific messages are relevant and which can be discarded.

If a message code is passed along in the response, the (fatal/informative) message represented by that code will be associated with the claim line which it affects. Once the claim line is further processed, the attached message is taken into account, for example, it may lead to mandatory manual adjudication or even automatic denial.

A message in an enrollment response is meant to reflect something about the status of the product, for example, notifying Claims that the product is registered but not yet fully approved. The severity of the message is determined by Claims. Note that:

• Up to 10 parameters are supported per message. These 10 parameters are used to populate the respective placeholders in the actual message text.

• A message applies during the entire validity period of the associated product.

• Messages are optional.

• Claims stores to which product a message belongs, that is, messages attached to claim lines are product specific.

• Multiple messages may refer to the same product.

Evaluate Brand and Payer

A claim specifies either a brand or a payer code. Only policy products that belong to the specified brand or payer are eligible for benefit calculation. To this end, each policy product is evaluated:

If the claim specifies a brand code and the policy product does not belong to that brand, then the following product specific message is attached to each claim line that specifies that person or object:

Code	Sev	Text
CLA-IP-ENRO-014	Fatal	The product {code} does not belong to the brand specified by the claim

If the claim specifies a payer code and the policy product does not belong to the payer that uses that payer code, then the following product specific message is attached to each claim line that specifies that person or object:

Code	Sev	Text
CLA-IP-ENRO-015	Fatal	The product {code} does not belong to the payer specified by the claim

It is possible that either this message, or the message related to brand, is attached to a claim line multiple times, each time for another policy product.

End Enrollment Derivation Rules

A derivation rule can update a claim or claim line. At this point in the flow, only derivation rules with step end enrollment are applied.

Derivation rules in this step are not applied if a product independent fatal message (of origin MANUAL, EXTERNAL, SANITY CHECKS, PRE PRICING) exists that is attached to the same (or higher) level as specified by the derivation rule.

First, the claim line level end enrollment derivation rules are applied, followed by claim header level derivation rules. Per level, the derivation rules are applied in order of their specified sequence, with rules that have no sequence being applied last.

---

1. A message is attached to any claim line (within the claim that triggered the enrollment request) that specifies the requested serviced person or object