Policy In Patch Integration Point

This web service supports the creation and maintenance of policies. It accepts either an online request for a single policy or a data file for a set of policies. To process a file with policies, start by uploading the data file using the Data File Set web service.

We recommend uploading files with sizes under 20 MB. Larger files impact the stability of the system.

The processing and request format is the same as for the regular Policy In Integration Point, with the following differences:

  • The Policy In Patch Integration Point (or IP) treats list items in the request differently. In Policy In Integration Point, the system replaces the complete list. Policy In Patch Integration Point updates existing list items and creates new list items.

  • There is no delete by omission. If an existing element is not included in a list, the element is not deleted. Including an empty list, remove all items.

  • This behavior applies to sub-resources, dynamic records, and dynamic fields.

  • The list behavior also applies to Person details.

  • Address matching is only done for the default address type. Matching is on Address Type and Start Date.

To check if a time-valid dynamic record exists, the application:

  • checks the field that you define as key and the start date

  • If no key field is available, checks the start date

Use this Integration Point in situations where the payload does not contain all details of a policy. Typical use cases are:

  • Details of the same policy are in separate files. For example, a one-month file that includes only coverage details for the employee. And a second-month file that includes only coverage details for dependents.

  • Only changes to an existing policy are present in the payload. Examples are new enrollments (such as newborns) or address changes.

Time-Valid Lists

When the payload has a new entry for a time-valid subresource, dynamic field, or dynamic record; the application constructs a new time valid-list. The application merges the existing list with the information in the payload.

The following elements follow this functionality:

  • Policyholder

  • Policy Group Account

  • Address (only for addresses with the default address type)

  • Marital Status

  • Parameter Values (per parameter alias code)

  • Collection Settings

  • Contract Periods

  • Policy Broker / Agents

  • Policy Premium Bill Allocation

  • Policy Enrollment Insurable Class

  • Policy Enrollment Medicare Comprehensive Addiction and Recovery (CARA) Status

  • Policy Enrollment Medicare Part D Late Enrollment Penalty

  • Policy Enrollment Medicare Part D Low Income Subsidy

  • Policy Enrollment Medicare Periods

  • Policy Enrollment Product Medicare Other Insurance Details

  • Policy Enrollment Product Medicare IC Model Status

  • Policy Enrollment Product Medicare Part D 4Rx data

  • Policy Enrollment Product Medicare Premium Payment Options

  • Time valid dynamic fields

  • Single value dynamic records

  • Multi value dynamic records where a key field is defined

End Date in the Payload

When the payload includes an end date, the integration point creates a new record. The integration point adds the new record between existing periods, adjusting the start and end dates of the affected periods.

Example

The following example explains how the integration point processes a payload with a record having an end date:

Consider a list, such as:

Table 1. End Date in the Payload
Identifier Start Date End Date

A

1-JAN-2020

31-DEC-2020

B

1-JAN-2021

30-APR-2021

C

1-MAY-2021

31-JUL-2021

D

1-AUG-2021

31-DEC-2021

E

1-JAN-2022

You enter a payload with identifier F and time validity: 1-MAR-2021 to 31-AUG-2021.

The integration point merges this new period with the existing list. This impacts periods of other identifiers, such as: B, C, and D. This results in a new list with the following time periods:

Table 2. End Date in the Payload: Example
Identifier Start Date End Date

A

1-JAN-2020

31-DEC-2020

B

1-JAN-2021

28-FEB-2021

F

1-MAR-2021

31-AUG-2021

D

1-SEP-2021

31-DEC-2021

E

1-JAN-2022

Does Not Include an End Date

When the payload does not include an end date, the integration point creates a new record and end-dates all previous records.

Example

.Example

Identifier Start Date End Date

A

1-JAN-2020

31-DEC-2020

B

1-JAN-2021

31-DEC-2021

C

1-JAN-2022

You enter a payload with an identifier D having a time validity starting from 1-JAN-2023.

This results in the following list:

Table 3. Does Not Include an End Date
Identifier Start Date End Date

A

1-JAN-2020

31-DEC-2020

B

1-JAN-2021

31-DEC-2021

C

1-JAN-2022

31-DEC-2022

D

1-JAN-2023

Online Request Message

The HTTP PUT request to: http://[hostName]:[portNumber]/[api-context-root]/policies enable external systems to create and update Policies. Each request message contains the details of a single policy.

Set the header parameter patch to true for invoking the Policy In Patch Integration Point. An HTTP request without the header parameter starts the Policy In Integration Point.

Example

Adding Policy Enrollment Product for a single member on an existing policy with two members. Both members already have Policy Enrollment Product CO_HDHP.

[source,text,subs="verbatim,attributes"

PUT {apiurl}/policies/submit

<policy code="POL001">
    <policyEnrollmentList>
        <policyEnrollment>
            <person code="PH001"/>
            <policyEnrollmentProductList>
                <policyEnrollmentProduct startDate="2017-11-01" enrollmentProductCode="CO_PPO"/>
            </policyEnrollmentProductList>
        </policyEnrollment>
    </policyEnrollmentList>
</policy>

Content-Type: application/xml
Accept: */*
patch: true

The request adds a new Policy Enrollment Product CO_PPO to member PH001 without removing the existing Policy Enrollment Product CO_HDHP.

File Request

Like the Policy In Integration Point, the Policy In Patch supports file-based requests. This request enables the handling of multiple policies in one go. Because this service supports requests with significant volume, it relies on the Data File Set web service to import the policy payload into the application before it reads and processes the data. Refer to Data File Set Integration Point for more information about how to create a Data File Set.

The patch body parameter in the request body controls whether the Policy In Patch Integration Point or the Policy In Integration Point is started. Set the patch to true to start the Policy In Patch Integration Point. The default value for the flag is false.

Each of the data files has <policies> as its root element. This data file has the following structure:

<policies>
   <policy
     code=""
     policyIdentifierTypeCode=""
     elementId=""
   >
</policies>

Example

Adding Policy Enrollment Product to a single member with an existing policy with two members.

  1. Upload the file containing the update transaction as a Data File Set. Refer to the Data File Set Integration Point for details. In this example, the Data File Set has a code 2042. The file contains the following data:

    <policies>
   <policy code="POL001">
      <policyEnrollmentList>
         <policyEnrollment>
            <person code="PH001" />
            <policyEnrollmentProductList>
               <policyEnrollmentProduct startDate="2017-11-01" enrollmentProductCode="CO_PPO" />
            </policyEnrollmentProductList>
         </policyEnrollment>
      </policyEnrollmentList>
   </policy>
</policies>

  2. Perform the file-based request:

    POST {apiurl}/writepolicies

{
"dataFileSetCode": "2042",
"submit": "true",
"patch": "true"
}

Content-Type: application/json
Accept: */*

The request adds the Policy Enrollment Product CO_PPO to member PH001 without removing the existing Policy Enrollment Product CO_HDHP.

Authorization

This Integration Point requires a grant for access restriction Policy In IP.