Enrollment Integration Point
This chapter describes the behavior of the enrollment interface. At this point in the flow the application sends out a request for enrollment information, expecting a response that holds the member enrollment information that is required to proceed with adjudicating a claim for that member.
| The enrollment interface expects the payload to be in XML format. |
The request message includes the unique identifier for the serviced person or object as well as the time-span for which enrollment information is required. The response payload includes the following information:
-
The person or object and period in the request message
-
Family
-
Products
-
Messages within the context of a product
-
Parameter values within the context of a product
-
Provider groups within the context of a product
-
Dynamic fields (and records) within the context of the product
The identifiers in the response message, for example for the person, the object, the product or the message, have to match the identifiers as they are known in Claims. Note that these are not proprietary identifiers; these identifiers are typically specified through the corresponding integration points by the system of record into Claims.
Enrollment Request
The structure of the enrollment request is as follows:
POST {uri}/{operation}
<enrollmentRequest endDate="2021-07-29" insurableEntityCode="PC0011_4_1_1_1_RELA_001" insurableEntityType="servicedMember" startDate="2021-07-29" insuranceTypeCode="HEALTH_INSURANCE"/>
The above {uri} part should be configured using the property "ohi.enrollment.server.uri", and the {operation} part with the property "ohi.enrollment.server.status.operation". The latter operation property has a default value of "api/enrollments/search", which matches the location of the enrollment status response integration point in Policies. So, when Claims is used in combination with Policies, only the former URI property has to be set to the context root of the Policies application.
The parameter insurableEntityCode holds the serviced person’s or insurable object’s code in the claim line.
The parameter insuranceTypeCode holds the insurance type code from the claim’s claimform. [1]
For each claim, Claims determines the time period for which enrollment information is required. This is the period that starts on the earliest start date (over all lines for the person or object ) and ends on the latest start or end date (over all lines for the person or object). Empty end dates are ignored for this purpose, because for these lines the start date is assumed to be the end date as well. As a consequence, a request always contains both a start date and end date. Note that locked claim lines and replaced claim lines are ignored. Also note that price input dates are also evaluated when determining the time period (see Gathering Enrollment Data for more information).
|
When communicating with Policies, the response structure that should be returned by Policies can be specified in the system properties. The way that the Enrollment client needs to authenticate with the REST resource can also be configured. Refer to the Installation Guide for more details. |
For example, suppose the following claims lines exist on a claim:
| Serviced Person or Object | Start Date | End Date |
|---|---|---|
Person A |
01-Jan-2015 |
|
Person A |
03-Jan-2015 |
05-Jan-2015 |
Then, for Person A the start date will be '01-Jan-2015' and end date will be '05-Jan-2015'.
Enrollment Response
The block below contains the response message in pseudo code. Three consecutive decimal points indicate the possibility of multiple iterations
The response elements and their processing details is explained in the Gathering Enrollment Data.
<enrollment>
<families>
<family
code=""
startDate=""
endDate=""
/>
...
</families>
<products>
<product
code=""
employerCode=""
startDate=""
endDate=""
contractDate=""
contractEndDate=""
factor=""
indSuspended="N"
>
<parameters>
<parameter
aliasCode=""
percentage=""
number=""
serviceDays=""
>
<parameterAmount
currency="">
{value}
</parameterAmount>
</parameter>
...
</parameters>
<providerGroups>
<providerGroup
assignmentLabel=""
providerGroupCode=""
startDate=""
endDate=""
/>
...
</providerGroups>
</product>
...
</products>
<messages>
<message
code=""
productCode=""
value0=""
(through)
value9=""
/>
...
</messages>
</enrollment>
The response message has a number of time valid elements. Note that the time validity can extend beyond the service period of the claim that triggered the request.
In the event that there are no <product> elements available for the person/object for the requested time period, Claims expects HTTP Response code 204 (No Content).
If a parameter amount for a parameter is specified without the currency, the currency (on the parameter) is set to the default currency.
Dynamic Fields and Records
A given implementation of Claims could have dynamic fields and dynamic records added to the policy product entity that need to be interfaced. For details on how external interfaces can provide values for dynamic fields and dynamic records in request messages and how they are handled by Oracle Health Insurance application, refer to the concepts in the Developer Guide.