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, e.g., 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
Before calling out, the system checks for appropriate enrollment data that is complete and not yet expired. If found, the enrollment information is used and the flow moves to the next step in the claims flow (Claim Classification). If not, the system will call out with a request to get the enrollment information. The parameters on which existing enrollment data is fetched are as follows:
-
Claim code
-
The serviced person’s code or serviced object’s code
-
Start date: 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
-
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 defined in the properties file using property 'ohi.processing.enrollment.cacheexpiry'. 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), (2) policy family codes and (3) policy waiting period start dates.
Request Enrollment Data
OHI Claims communicates with the enrollment system of record though the enrollment request integration point. OHI Claims sends synchronous enrollment requests per serviced person/object 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, i.e., it is not required to provide any further context such as the brand or payer. Consequently, in a situation where a health care payer organization has set up multiple brands and payers in OHI Claims, if a person or object is enrolled twice on identical products for the same line of business, but under two different brands, the enrollment interface provides no means to distinguish between the two products. It is the responsibility of the enrollment system to prevent redundant insurance.
-
Line of business code
OHI Claims expects the enrollment information for the specified line of business.
-
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 in the ohi-claims properties file. If disabled, the claim skips ahead towards the level 2: Claim Classification flow. 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* 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 |
* A message is attached to any claim line (within the claim that triggered the enrollment request) that specifies the requested serviced person or object
In addition, this integration point can return product independent fatal messages in the context of ill defined dynamic field or dynamic record elements, e.g., 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, e.g., 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 Waiting Period Start Date
Policy Product
To determine the benefits for a serviced person or object, OHI 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 OHI Claims. In turn, OHI 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 e.g., 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 implementation guide for process rules.
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
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
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 withing the requested time period.
The family codes are stored as follows:
Policy Family
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. |
Policy Waiting Period Start Date
This list of dates indicates as of when a member has had access to a particular service option (benefit). It is possible that these dates are earlier than the start of the current enrollment product or even the current payer. This information is used for the evaluation of waiting periods.
The waiting period start dates are stored as follows:
Policy Waiting Period Start Date
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. |
service option service code |
Identifies the service option to which the member has access. |
coverage level |
Identifies the level of coverage of the service option. |
start date |
The date as of when the person has had access to the service option. |
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, i.e., 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, e.g., 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, e.g., notifying OHI Claims that the product is registered but not yet fully approved. The severity of the message is determined by OHI 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.
-
OHI Claims stores to which product a message belongs, i.e., 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.
Derivation Rules
A derivation rule sets the value of certain fields on a claim, bill or claim line. At this point in the flow, only derivation rules are executed for which the "step" field has the value "end enrollment".
Derivation rules in this step are not evaluated 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.
The end enrollment derivation rules are evaluated in the following order: claim line first, bill second, claim (header) last. The rationale behind this sequence is that end enrollment derivation rules at the claim level thus can use results from end enrollment derivation rules at the bill and claim line level. If multiple derivation rules exist for the same level, they are executed in order of the configured sequence (sequence null is evaluated last).