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.
The payload only contains changes to an existing policy, such as new enrollments (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
Policy Enrollment Product
Address (only for addresses with the default address type)
Marital Status
Bank Account Numbers
Assigned Providers
Person Covered Services
Contract Alignments
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. List of Time Period - Example
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: Consider a list, such as:

Table 3. List of Time Period - 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 4. 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

Canceled not in Effect Indicator

For the time-valid elements with canceled not in effect indicator, that is, Policy Enrollment Medicare Periods and Policy Enrollment Medicare Part D Late Enrollment Penalty:

Inactive records (canceled not in effect set to true) are always excluded from the time validity checks; that is, new time-valid records are not created, and existing inactive records are not updated in case of overlapping time periods.
Only one record is allowed with the same functional key combination, one active and one inactive record with the same functional key fields, which also includes the start date.
It is impossible to change a canceled record back to active; that is, to change the canceled not in effect set from true to false with the Policies In Patch.
When a matching record is received as part of the request payload, that is, with the same start date and the same functional key excluding the canceled not in effect indicator):
- The system identifies if any existing record with the same unique functional identifier exists.
  - If only one active record is identified (with canceled not in effect = false), In that case, the existing record is updated, and the current record is marked as inactive in case the canceled not in effect flag is true as part of the incoming update request.
  - If only one inactive record is identified in the system (with canceled not in effect = true):
    
    If the request payload record has canceled not in effect = false (an active record), a new active record is created in the system.
    
    If the request payload record has canceled not in effect = true (an inactive record), the existing canceled record is updated.
  - If both active and inactive records with the same functional key already exist in the system (including the start date):
    
    If the request payload record has canceled not in effect = false (an active record), update the existing active record.
    
    If the request payload record has canceled not in effect = true (an inactive record). In that case, the existing inactive record is removed, and the current active record is updated and marked inactive.

The existing patch behavior remains the same for the active overlapping records.
Similar patch behavior applies to Policy Enrollment Medicare Part D Creditable Coverage records, excluding the time-valid check.

Patch on Policy Enrollment Product

The patch on a Policy Enrollment Product, a time-valid resource, considers additional logic to check Restrict Concurrent Products flag on the Enrollment Process Category before applying the time-valid patch behavior.

When an update is received for a Policy Enrollment Product, the system checks for a match using Enrollment Product Code:

If a match is found, apply the Time-Valid list behavior for the Policy Enrollment Product.
If a match is not found, the system checks for the Product Category on the Enrollment Product.
- If there is no Product Category on Enrollment Product, the system adds the Enrollment Product as a new entry to the Policy Enrollment Product list.
- If there is a Product Category, then the system checks the value of Restrict Concurrent Products? flag:
  - If the value of the Restrict Concurrent Products flag is NO, the system adds the enrollment product as a new entry.
  - If the value of the Restrict Concurrent Products flag is YES, the system checks if there are any other active enrollment products with the same Product Category available on the Policy Enrollment Product list:
    
    If available, then apply the Time-Valid list behavior for the Policy Enrollment Product based on the dates on the payload.
    
    Otherwise, add the Enrollment Product as a new entry to the Policy Enrollment Product list.

Flow Diagram

The following table explains the expected behavior when a patch request has updated dates for policy enrollment product.

Updates Existing Product Code Different product code with the same product category where the Restrict Concurrent Products? flag is set as Yes Different product code with the same product category where the Restrict Concurrent Products? flag is set as No Different product code with different product category

Updates	Existing Product Code	Different product code with the same product category where the `Restrict Concurrent Products?` flag is set as `Yes`	Different product code with the same product category where the `Restrict Concurrent Products?` flag is set as `No`	Different product code with different product category
Matching Start Date	Update or add the Policy Enrollment Product	Apply the Time Valid behavior for the Policy enrollment product	Update or add the Policy Enrollment Product	Update or add the Policy Enrollment Product
Overlapping time period	Apply the Time Valid behavior for the Policy enrollment product	Apply the Time Valid behavior for the Policy enrollment product	Update or add the Policy Enrollment Product	Update or add the Policy Enrollment Product

Matching Start Date

Update or add the Policy Enrollment Product

Apply the Time Valid behavior for the Policy enrollment product

Update or add the Policy Enrollment Product

Overlapping time period

Apply the Time Valid behavior for the Policy enrollment product

Update or add the Policy Enrollment Product

Time Valid Behavior for Policy Enrollment Product

Use cases

In each of the following example use cases, D1, D2, D3, D4, D5, and D6 represent the different time durations of the same policy enrollment product or for a different policy enrollment product code with the same product category, where the Restrict Concurrent Products? flag is set to Yes.
In case the new dates overlap with the start date of an already existing product, the system automatically sets CNIF = True for the existing product.

Use Case: 1

Mr. John has a policy and is currently enrolled in a policy enrollment product (PEP) and received an update through the patch payload.

Outcome:: D3 is added as a new entry with a D3 start date.

Use Case: 2

Mr. John has a policy and is currently enrolled in a policy enrollment product (PEP). John received an update for the same or different policy enrollment product with the same product category and Restrict Concurrent Products is set to Yes.

Outcome:: D2 is updated and end-dated with a D3 start date minus (-) 1, and a new entry is started with a D3 start date.

Use Case: 3

Mr. John has a policy and is currently enrolled in a policy enrollment product (PEP). John received an update for a different policy enrollment product with the same product category, and Restrict Concurrent Products is set to Yes.

Outcome:

D2 is updated and end-dated with D4 start date minus (-) 1.
D4 is added as a new entry with the new start date.
D3 entry is marked as CNIF = True.

Use Case: 4

Mr. John has a policy and is currently enrolled in a policy enrollment product (PEP). John received an update for the same or different policy enrollment product with the same product category, and Restrict Concurrent Products is set to Yes.

Outcome:

D2 is updated and split by end dated with D4 start date minus (-) 1.
D4 is inserted with the new start date and end date.
D3 remains as-is, as the payload has no overlap with D3.

Use Case: 5

Outcome:

D2 is updated and split by end dated with D4 start date minus (-) 1.
D4 is inserted with the new start date and end date.
D3 is made CNIF = True.
D5 is added with the new start date.

Use Case: 5.1

Update for the same policy enrollment product.

Outcome:

D2 is updated and split by end dated with D4 start date minus (-) 1.
D4 is inserted with the new start date and end date.
D3 is updated as the enrollment product code and start date is match.

Use Case: 6

Outcome:

D2 is updated and end-dated with D4 start date minus (-) 1.
D4 is added with the new start date and end date.
D3 entry is marked as CNIF = True.

Use Case: 7

Outcome:

D2 is updated and split by end dated with D4 start date minus (-) 1.
D3 entry is marked as CNIF = True.
D4 is added with the new start date and end date.
D5 is added with the new start date.

Use Case: 8

Mr. John has a policy and is currently enrolled in a policy enrollment product (PEP). John received an update for a different policy enrollment product with the same product category.

Outcome:

D2 entry is marked as CNIF = True.
D4 is added as a new entry.

Use Case: 8.1

John received an update for the same policy enrollment product that matches the start date.

Outcome:: D2 is updated with D4 end date.

Use Case (Special Case): 9

Mr. John has a policy and is currently enrolled in a policy enrollment product (PEP). John received an update for the same policy enrollment product with a matching start date.

Current records:

Table 5. Current Entries
Record	CNIF	Start Date
PEP-1	True	01-JAN-2020
PEP-1	False	01-JAN-2020

Received an update payload through PolicyIn Patch or Update Request:

Table 6. PolicyIn Patch Payload
Record	CNIF	Start Date
PEP-1	True	01-JAN-2020

Outcome:

Delete the entry Record-1 from the current entries.
Update Record-2 with the updates on the incoming payload.

Table 7. After Applying Patch

Record CNIF Start Date

PEP-1

True

01-JAN-2020

Online Request Message

The following HTTP PUT request enables external systems to create and update Policies. Each request message contains the details of a single policy.

{apiurl}/policies

Set the header parameter patch to true to invoke 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.

PUT http://[hostName]:[portNumber]/[api-context-root]/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. See Data File Sets 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.

Upload the file containing the update transaction as a Data File Set. See 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>

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

A user authorization configuration requires access to this feature. The relevant access restriction is Policy In IP.