Attached Data Integration Point
The purpose of this integration point is to allow external systems to create or modify additional information related to the policy without affecting its status or reprocessing the policy. This information is referred to as 'Attached Data'. The attached data for a policy resides in the entity 'Attached Policy Data'. This entity can be extended to have dynamic fields and dynamic records.
The information that is written to attached policy data is the process information related to enrollment that may play a role in the finalization of a policy, but the information lifecycle of the attached data has no (retro)active consequences to premium calculations and or output. This information does not introduce the need for reprocessing the policy. Without the existence of attached policy data, adding information to an approved policy would lead to the creation of a new policy version and the need for reprocessing. This integration point supports:
-
Fetch Attached Data - The external system can request for existing attached data of a policy through this request.
-
Update Attached Data - The external system can modify attached data of a policy through this request.
Fetch Attached Data
An external system can fetch attached data of a policy by posting a request to the URL: http://{base URL}/api/policies/{code}/attachedData. Here, {code} is the code of the policy whose attached data is requested by the external system.
The system sends the dynamic fields and dynamic records associated to the entity 'Attached Policy Data' in the response:
<attachedPolicyData
indIgnoreBulkUpdate=""
datePaidTo=""
lastProcessedMessageActivityID=""
>
<!--single value non time valid dynamic fields-->
<{dynamic field}
...
</{dynamic field}>
<!--multi value non time valid dynamic fields -->
<{dynamic field}>
<value>{value}</value>
</{dynamic field}>
...
<!-- multi value non time valid dynamic records -->
<{dynamic record}>
<record
{fields}
...
/>
</{dynamic record}>
...
<!-- single value non time valid dynamic records -->
<{dynamic record}
{field}
...
/>
...
</attachedPolicyData>In a case of an error (e.g. the policy code is unknown, multiple policies with the same code exist), the response will be as specified in the section "Indicating Failure" of Response Messages in the chapter 'HTTP API Integration Points' of the Common Features book.
<Last Processed Message ActivityID> This field gets stamped at the time a message is created. Whether or not the id gets stamped depends on the connector configuration
Update Attached Data
The external system can send a request to modify attached data of a policy to the URL: http://{base URL}/api/policies/{code}/attachedData.
The update request has the following structure:
<attachedPolicyData
indIgnoreBulkUpdate=""
datePaidTo=""
lastProcessedMessageActivityID=""
>
<!--single value non time valid dynamic fields-->
{dynamic field}
...
>
<!--multi value non time valid dynamic fields -->
<{dynamic field}>
<value>{value}</value>
</{dynamic field}>
...
<!-- multi value non time valid dynamic records -->
<{dynamic record}>
<record
{fields}
...
/>
</{dynamic record}>
...
<!-- single value non time valid dynamic records -->
<{dynamic record}
{field}
...
/>
...
</attachedPolicyData>The external system is not required to send all the dynamic records in the update request. The {dynamic record} element or {dynamic field} which is not specified in the request message is not updated. For details on how external system can provide values for dynamic fields and dynamic records in request messages and how they are handled by the OHI Policies, refer to the concepts in the Integration Guide.
Only a user with access grant to Date Paid To restriction can update the field 'datePaidTo' on the attached date.
In a case of an error (e.g. the policy code is unknown), the response will be as specified in the section "Indicating Failure" of Response Messages in the chapter 'HTTP API Integration Points' of the Common Features book.
Example: Updating Attached Data for 'Correspondence Tracking'
Suppose a record definition 'Correspondence Tracking' consisting of the following fields is created:
-
Code
-
Type
-
Remarks
-
Date Sent
-
Date Received
It is then attached to the entity 'Attached Policy Data'.
Let’s suppose one correspondence letter for required medical assessment has been sent out for policy '1234'. In that case, the following information can be registered through the attached data integration point.
Code |
Type |
Remarks |
Date Sent |
Date Received |
1A3/AXDD |
LETTERS |
Medical assessment required |
09-12-2015 |
- |
To register such an information, the external system sends the following request message to 'Update Attached Data'
<attachedPolicyData>
<correspondenceTracking>
<record
code="1A3/AXDD"
type="LETTERS"
reference="Medical assessment required"
sentDate="2015-12-09"
/>
</correspondenceTracking>
</attachedPolicyData>If a reminder letter is sent out later, then the attached data can be updated by sending the following request message:
<attachedPolicyData>
<correspondenceTracking>
<record
code="1A3/AXDD "
type="LETTERS"
reference="Medical assessment required"
sentDate="2015-12-09"
/>
<record
code="2A5/AXDD "
type="LETTERS"
reference="Reminder medical assessment required"
sentDate="2015-12-19"
/>
</correspondenceTracking>
</attachedPolicyData>Suppose an external system wants to update a dynamic field 'Medical Assessment Date' defined on Attached Policy Data and also wants to update the correspondence tracking with the details of the received medical assessment form. This can be done by sending the following update attached data message:
<attachedPolicyData
medicalAssessmentdate='2015-12-28'
>
<correspondenceTracking>
<record
code="1A3/AXDD "
type="LETTERS"
reference="Medical assessment required"
sentDate="2015-12-09"
/>
<record
code="2A5/AXDD"
type="LETTERS"
reference="Reminder medical assessment required"
sentDate="2015-12-19"
/>
<record
code="2A5/AXRR"
type="FORM"
reference="Medical assessment complete"
receivedDate="2016-01-02"
/>
</correspondenceTracking>
</attachedPolicyData>