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

• Waiting period start dates

• 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, e.g., for the person or object, the products and messages, in the response message have to match the identifiers as they are known in OHI Claims. Note that these are not proprietary identifiers; these identifiers are typically specified through the corresponding integration points by the system of record into OHI Claims.

Enrollment Request

The structure of the enrollment request will be as follows:

GET {uri}/{operation}?insurableEntityType={usageName}&insurableEntityCode={code}&lineOfBusinessCode={code}&startDate={date}&endDate={date}

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", which matches the location of the Enrollment Status Response Integration Point in OHI Policies. So, when OHI Claims is used in combination with OHI Policies, only the former URI property has to be set, to the context root of the OHI Policies application. The attribute insurableEntityCode is the serviced person’s or insurable object’s code in the claim line.

For each claim, OHI 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 OHI Policies, the response structure that should be returned by OHI 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 section of the guide

<enrollment>
  <families>
    <family
      code=""
      startDate=""
      endDate=""
    />
    ...
  </families>
  <waitingPeriodStartDates>
    <waitingPeriodStartDate
      serviceOptionServiceCode=""
      coverageLevel=""
      startDate=""
    />
    ...
  </waitingPeriodStartDates>
  <products>
    <product
      code=""
      employerCode=""
      startDate=""
      endDate=""
      contractDate=""
      contractEndDate=""
      factor=""
      coverageLevel=""
    >
      <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, OHI 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 OHI 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 the OHI application, refer to the concepts in the Integration Guide.