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:
|
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
-
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:
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:
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:
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.
PUT http://<host>:<port>/<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. 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.
-
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>
-
Perform the file-based request:
POST http://<host>:<port>/<context-root>/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.