Policy In Integration Point

This web service enables the creation and maintenance of Policies. The web service 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.

This web service does not support the removal or cancellation of a Policy.

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

Online Request Message

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

The system accepts the request in the following format:

<policy
  code=""
  policyIdentifierTypeCode=""
  enrollmentFileName=""
  brandCode=""
  dataAccessGroupCode=""
  insuranceTypeCode=""
  lineOfBusinessCode=""
  policyProcessFlowCode=""
  calculateOnCancellation=""
 >
  <policyholderList>
    <policyholder
      startDate=""
      endDate=""
    />
        <person
         correlationKey=""
        >
    </policyholder>
  </policyholderList>
   <assignedProviderList>
    <assignedProvider
      providerAssignmentTypeCode=""
      startDate=""
      endDate=""
       >
      <provider
        code=""
        flexCodeDefinitionCode=""
      />
    </assignedProvider>
  </assignedProviderList>
  <policyGroupAccountList>
    <policyGroupAccount
      groupAccountCode=""
      startDate=""
      endDate=""
    />
  </policyGroupAccountList>
  <policyBillingAccountList>
    <policyBillingAccount
      code=""
      descr=""
      contactRelationCode=""
      default=""
    />
  </policyBillingAccountList>
  <policyCollectionSettingList>
    <policyCollectionSetting
      advanceLength=""
      advanceUom=""
      startDate=""
      spanReferenceDate=""
      endDate=""
      policyCalculationPeriods=""
      calculationPeriodLength=""
      calculationPeriodUom=""
      collectionMethodCode=""
    />
  </policyCollectionSettingList>
  <policyPremiumBillAllocationList>
    <policyPremiumBillAllocation
      scheduleDefinitionCode=""
      premiumScheduleTypeCode=""
      addOnCode=""
      enrollmentProductCode=""
      enrollmentProductCategoryCode=""
      insurableClassCode=""
      startDate=""
      endDate=""
      active=""
    >
      <policyBillReceiverList>
        <policyBillReceiver
          relationCode=""
          billingAccountCode=""
          percentage=""
        />
      </policyBillReceiverList>
    </policyPremiumBillAllocation>
  </policyPremiumBillAllocationList>
  <policyContractPeriodList>
    <policyContractPeriod
      startDate=""
      referenceDate=""
      endDate=""
    />
  </policyContractPeriodList>
  <policyBrokerAgentList>
    <policyBrokerAgent
      brokerCode=""
      agentCode=""
      startDate=""
      endDate=""
    />
  </policyBrokerAgentList>
  <policyEnrollmentList>
    <policyEnrollment
      enrollmentTypeCode=""
     />
      <!--either of the below-->
      <policyEnrollmentInsurableClassList>
        <policyEnrollmentInsurableClass
           insurableClassCode=""
           startDate=""
           endDate=""
        />
      </policyEnrollmentInsurableClassList>
      <policyEnrollmentProductList>
        <policyEnrollmentProduct
          enrollmentProductCode=""
          commission=""
          commissionAmountInterpretation=""
          commissionNumberOfDays=""
          startDate=""
          endDate=""
          neverInForce=""
          neverInForceReasonCode=""
        />
          <premiumAmount
            currency="">
            {value}
          </premiumAmount>
          <commissionAmount
            currency="">
            {value}
          </commissionAmount>
          <parameterValueList>
            <parameterValue
              parameterAliasCode=""
              percentage=""
              number=""
              serviceDays=""
              startDate=""
              endDate=""
            >
              <parameterAmount
                currency="">
                {value}
              </parameterAmount>
            </parameterValue>
          </parameterValueList>
          <policyAddOnList>
            <policyAddOn
              addOnCode=""
              startDate=""
              endDate="">
            </policyAddOn>
          </policyAddOnList>
        />
      </policyEnrollmentProductList>
    <policyEnrollment/>
  </policyEnrollmentList>
 <policyIdentifierList>
    <policyIdentifier
      policyIdentifierTypeCode=""
      identifier=""
      enabled=""
    />
 </policyIdentifierList>
 <attachedPolicyData
    manual=""
    ignoreBulkUpdate=""
    datePaidTo=""
   />
</policy>

Refer http://[hostName]:[portNumber]/[api-context-root]/policies/create-form for the complete request message including US Medicare Advantage related fields.

Each <policyEnrollment> must specify either an <insurablePerson> or an <insurableObject>. Which of the two depends on the Policy's Insurance Type.

The Insurance Type of the Enrollment Product in the <policyEnrollmentProduct> must match the Policy's Insurance Type.

The system uses the information in the <attachedPolicyData> to update the attached Policy data record.

Only a user with access grant to Date Paid To restriction can update the field datePaidTo on the data.

Submit for Processing

This request enables an external system to save or save-and-submit a Policy. Use of the URI determines how the system processes the request. Use URI:

/policies to Save the Policy but not Submit it.
/policies/submit to Save the Policy and immediately Submit it.

If using the save-and-submit URI, the Policy submits immediately after creation or update. See Process Policy for a more information on the processing flow.

Matching

The Policy Code and Identifier Type determine the creation of a new Policy or updating an existing one.

The system tries to match the data on Policy code first. If no Policy could be found, the system matches on Policy Identifiers.

If the Policy Code or Identifier exists, then the Policy details update as per the data provided in the request.

No Match

If the payload could not be matched to an existing Policy, the system creates a new Policy. If there is no mention of the Policy Code, then the system considers the Policy to be a New Enrollment and generates a Code using the Dynamic Logic Function with the signature Policy Code Generation. Not configuring this, assigns the Policy ID to Policy Code.

If a new Policy is created, identified by a Policy Identifier, the system generates a Policy Code and stores the Policy Identifier.

The existence of multiple Policies with the same Code raises a fatal message. See the "Error Messages" section for more information on this.

Creating Policies

Refer to the concepts in the Developer Guide for details on how values in the request messages work when creating a Policy.

Currency

Specifying a Premium Amount or Commission Amount for a Policy Enrollment Product without the Currency sets the Currency (on the Policy Enrollment Product) to the premium Currency of the corresponding Enrollment Product. Specifying a Parameter Amount for a Parameter Value without the Currency sets the Currency (on the Parameter Value) to the parameter Currency of the corresponding Enrollment Product.

Updating Policies

If a Policy Code exists, then the Policy updates as per the provided data in the request.

Attribute Handling

The "Property Representation and Handling" section in the HTTP API/IP Concepts part of the Developer Guide specifies how single value attributes work when updating a Policy. The "Change Events" section in the Configuration Guide describe how handling of details differs from the standard replacing mechanism as updates to details may require a recalculation of premium, a new output document, or an additional fee.

Details in the request message match with the existing details on specific attributes (see below) instead of replacing the entire list of details when updating a Policy. Existing details update if they match with details in the request (only if there is a change), insert the details in the request that do not match with existing details, and delete the existing details that do not match with details in the request. Not including the list element makes no difference to the current details. Including an empty list element removes all current detail records. This applies to the following list of details:

Policy Identifiers: matched on Policy Identifier Type and Identifier
Policyholders: matched on Person Code and Start Date.
Policy Contract Periods: matched on the Start Date.
Policy Billing Accounts: matched on Code.
Policy Collection Settings: matched on the Start Date.
Policy Premium Bill Allocations: matched on Insurable Class Code, Add-on Code, Schedule Definition Code, Premium Schedule Type Code, Enrollment Product Code, Enrollment Product Category Code, and the Start Date.
Policy Bill Receivers: matched on Policy Premium Bill Allocation, Relation Code, and Billing Account Code (see above).
Policy Brokers Agents: matched on the Start Date.
Policy Group Accounts: matched on Group Account Code and the Start Date.
Policy Insurable Classes: matched on Insurable Class Code and the Start Date.
Policy Enrollments:
- When the Policy Enrollment is for a Person: matched on Person Code or Relation Identifier.
- When the Policy Enrollment is for an Object: matched on Object Code and Object Type.
Policy Enrollment Products:
- When the Policy does not belong to a Group Account: matched on Enrollment Product Code and the Start Date.
- When the Policy belongs to a Group Account: matched on Enrollment Product Code of the related Group Account Product and the Start Date.
Policy Add-on: matched on Policy Enrollment Product (see above), Add-on Code, and the Start Date.
Parameter Values: matched on Policy Enrollment Product (see above), Parameter Alias Code, and the Start Date. If creating or updating a Policy Enrollment Product, the Insurance Type of the Enrollment Product must have a reference to the Insurable Entity Type of the enrolled Person or Object.

A single Insurance Type can refer to multiple Insurable Entity Types.

Currency

The "Creating Policies" section specifies the way for setting the Currency when inserting a new Policy Enrollment Product or Parameter Value.

The Currency (on the Policy Enrollment Product) sets to the premium Currency of the related Enrollment Product when updating an existing Policy Enrollment Product that does not specify a Premium Amount (specifies Premium Amount without the Currency in the request).

The Currency (on the Policy Enrollment Product) sets to the premium Currency of the related Enrollment Product when updating an existing Policy Enrollment Product that specifies a Premium Amount (specifies the Premium Amount without the Currency in the request). Specify an empty <premiumAmount> element in the request to nullify the Premium Amount and the Currency.

The Currency (on the Parameter Value) sets to the premium Currency of the corresponding Enrollment Product when updating an existing Parameter Value for a Parameter Alias of type Amount (specifies parameter Amount without the Currency in the request).

Statuses

Policies can have different statuses. Find the description of the unique statuses of a Policy (including the different status transitions) in the "Policy Statuses" section in the Policies in the Operations guide. What happens after updating a Policy differs per status:

Edit

Removes any Policy messages and Policy Pend Reasons. Note that the Policy Pend History does not resolve Pend Reasons. The Policy updates (see the "Attribute Handling" section for more information) and saves. Using the /policies/submit URI submits the Policy automatically after processing.

In Process

Resolves any technical errors related to the processing flow. Removes any Policy messages and Policy Pend Reasons. Note that the Policy Pend History does not resolve Pend Reasons. The status of the Policy changed to Edit, creating a Policy Status History record for the Edit status. The Policy updates and saves in the Edit status (refer to "Attribute Handling" section for more information). Using the /policies/submit URI submits the Policy automatically after processing.

Pended

Removes any Policy messages. Removes the Policy Pend Reasons. Note that the Policy Pend History does not resolve Pend Reasons. The status of the policy changes to Edit, creating a Policy Status History record for the Edit status. The Policy updates and saves in the Edit status (refer to "Attribute Handling" section). Using the /policies/submit URI submits the Policy automatically after processing.

Pending File Review

Removes any Policy messages. The status of the policy changes to Edit, creating a Policy Status History record for the Edit status. The Policy updates and saves in the Edit status (refer to "Attribute Handling" section). Using the /policies/submit URI submits the Policy automatically after processing.

Approved and Canceled

Creates a new Version of the Policy with the Edit status and creates a Policy Status History record for the Edit status. The new Version is a copy of the current Version including its dynamic fields, dynamic records, and the following details (including their dynamic fields and dynamic records):

Policy Identifiers
Policyholders
Policy Contract Periods
Policy Collection Settings
Policy Premium Bill Allocations
Policy Bill Receivers
Policy Brokers Agents
Policy Group Accounts
Policy Enrollments
- Policy Enrollment Medicare Detail (including all the child entities and details)
Policy Enrollment Products
- Policy Enrollment Product Medicare Detail (including all the child entities and details)
Policy Insurable Classes
Policy Add-on
Parameter Values (belonging to Policy Enrollment Products)

The policy updates and saves in the Edit status (refer to the "Attribute Handling" section). Note that there is no copying of the Policy Billing Accounts because they apply across the Versions of a Policy. Using the /policies/submit URI submits the Policy automatically after processing.

Dynamic Fields and Dynamic Records

There may be dynamic fields and dynamic records with the Policy and its related entities in the implementation of the Oracle Health Insurance application that needs to be interfaced. Refer to the "Property Representation and Handling" section in the HTTP API/IP Concepts part in the Developer Guide for details on how external interfaces can provide values for dynamic fields and dynamic records in request messages and how Oracle Health Insurance application handles them.

The dynamic records and dynamic fields update after matching instead of being deleted and re-inserted, as with other child entities in this integration point. Horizontal dynamic fields match on the name of the dynamic field. Vertical dynamic fields and dynamic records match on the data. If the data is exactly the same, there is no deletion and insertion. If there is a mismatch of data for the same usage name, deletes and inserts data for that usage name.

Insurable Entities

This integration point enrolls a Person and an Object that is new to the system.

Persons

It is important to specify the new Person's details in the request. Refer to the "Person" section in the Relation Integration Point part of the Developer Guide for more details on the element Person.

A relation code or an identifierTypeCode needs to be provided in the Person’s Code to match the system’s existing relations/identifiers.

The system detects a person as new if the specified relation code or an identifierTypeCode does not exist and creates a new person with the provided relation code or identifierTypeCode as a relation person code.

The system also detects a person as a new person if the specified person code is empty in the request. In this case, it generates a person Code using Dynamic Logic Function with the signature Person Code Generation. An ID is assigned to person Code if there is no Dynamic Logic Function with the signature Person Code Generation.

Examples of different use cases:

Use case	Description	Code provided	IdentifierType	Existing system data (IdentifierTypeCode)	Enabled	Result
1	Match on Identifier	1234	SSN	Yes	Yes	Update
2	Match on Identifier	6789	SSN	No	-	Create
3	Match on Relation Code	ABC		Yes		Update
4	Match on Relation Code	XYZ		No	-	Create
5	Match on Identifier	5678	SSN	Yes	No	Create/Verify

Use case

Description

Code provided

IdentifierType

Existing system data (IdentifierTypeCode)

Enabled

Result

Match on Identifier

1234

SSN

Yes

Update

Match on Identifier

6789

SSN

Create

Match on Relation Code

ABC

Yes

Update

Match on Relation Code

XYZ

Create

Match on Identifier

5678

SSN

Yes

Create/Verify

This integration point takes in both Relations and assigned Providers. Uses the enabled identifiers for matching if the Relation or Provider that is sent does not match on the Code. Thus, enabling the system to recognize if it is the same Relation or Provider. The Oracle Health Insurance system stores multiple identifiers of a Relation or a Provider. The identifiers can be of any type. For example, policy enrollment number, social security number, or a driver’s license number, etc. The user needs to have access to the Identifier Type to apply the identifiers during matching.

Update a subset of attributes on an existing Person record by specifying only those attributes in the request message. The "Relation Integration Point" part of the Developer Guide describes the attribute handling for the Person.

A Correlation Key relates to a Member and a Policyholder in the following manner. The Person in the Policyholder element and the Person in the Policy Enrollment element must have the same Person Code in the request if the Policyholder and a Member are the same Person and this Person is new to the system. Use the Correlation Key if leaving the Person Code empty with the purpose of having the system generate them. By adding the same Correlation Key to the Policyholder Person and to the Policy Enrollment Person recognizes them as the same Person. The system will create only one Person who is the Policyholder and a Member of the Policy. If using both Person Code and Correlation Key, then matching the Policyholder and the Member on Person Codes supersedes matching on Correlation Key.

Matching on the Correlation Key is used for a new Person when the request holds no Person Code. The system ignores the Correlation Key for Person Update and is not available for enrollment of Insurable Entities that are not a Person.

Consider the following use cases:

Use Case Person Code of the Policyholder Correlation key on policyholder Person Code on the Policy enrollment Correlation key on the Policy Enrollment Result

Use Case	Person Code of the Policyholder	Correlation key on policyholder	Person Code on the Policy enrollment	Correlation key on the Policy Enrollment	Result
1	Code001	not available	Code001	not available	Creates person with code: `Code001`
2	not available	Key001	not available	Key001	Creates a person with code: `Code123`
3	not available	Key001	not available	Key002	Create persons with code: `Code234` and `Code345`
4	Code001	Key001	Code001	Key002	no new person created

Code001

not available

Code001

not available

Creates person with code: Code001

not available

Key001

not available

Key001

Creates a person with code: Code123

not available

Key001

not available

Key002

Create persons with code: Code234 and Code345

Code001

Key001

Code001

Key002

no new person created

In the first use case, the person code is the same for both the policyholder and the policy enrollment. Neither of the entities has a correlation key. In such a case, the integration point creates a new person with the specified code.
In the second case, the person code is unavailable in both the policyholder and the policy enrollment. The correlation key is the same for both the policyholder and the policy enrollment. In such a case, the integration point creates a person with a new code, say Code123.
In the third case, the person code is unavailable for both the policyholder and the policy enrollment. The correlation keys are different for both entities. In such a case, the integration point creates two new person entities with different person codes.
In the fourth case, the person code is the same for both policyholder and policy enrollment. The correlation keys are different for both policyholder and policy enrollment entities. In such a case, the integration point ignores the correlation key as the person already exists.

Person Updates

Person Update behavior depends on the settings of a system property.

Setting the property with the payload containing Person information creates a copy of the Person with the Person details provided in the request.

Person Updates are not effective immediately, they are only available in the new Policy or Policy Version.

Approval of the Policy updates the active Person details.

Rejection of the Policy or Policy Version rejects the Person Update as well.

The active Person details lock until the new Policy or the Policy Version approves or rejects.

This functionality applies to Policy Enrollments and Policyholders.

Do not use unique dynamic fields on Persons in combination with the Person Copy functionality. Use relation identifiers for alternative unique Person identifiers.

Not setting this property, makes Person Update effective immediately.

Objects

It is important to specify the new Object details in the request. The system detects an Object as a new Object if the specified Object Code in combination with the Entity Type Code does not exist. Leaving the Object Code empty raises a fatal message.

Update a subset of attributes on an existing Object record by specifying only those attributes in the request message. The "Property Representation and Handling" section in the HTTP API/IP Concepts part in the Developer Guide describes the standard for attribute handling for the Object.

Enrollment Files

An enrollment file holds information about policy enrollment data files that were loaded into Oracle Health Insurance Enterprise Policy Administration. It can store the handling dates, the number of policies and enrollments in the file, and identifiers of the loaded policies. See Enrollment Files for information on how the policy In integration point creates and updates enrollment files.

Authorization

This integration point requires a grant for access restriction Policy In IP.

Response Message

The Oracle Health Insurance application creates the response messages in response to request messages it receives from external interfaces. Please refer to the "Response Messages" section in the HTTP API/IP Concepts as part of the Developer Guide for more details.

File Request

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.

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

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

The metadata for the above structure is accessible on the http://[hostName]:[portNumber]/[api-context-root]/writepolicies/payload/definition as Swagger definition.

Rest of this description assumes there is an input Data File Set created with at least one data file with the aforementioned structure. Submit HTTP POST request to http://[hostName]:[portNumber]/[api-context-root]/writepolicies to start the Policy Import process.

Write Policies batch (initiation) request has the following structure:

{
 "dataFileSetCode" : "...",
 "submit" : "...",
 "groupClientCode" : "...",
 "enrollmentFileName" : "...",
 "responseDataFileSetCode" : "..."
 }

The response Data File Set holds the results of the file payload. The responseDataFileSetCode is an optional attribute. The submit flag in the payload determines the processing of the file request:

The Policies Import and Submit when submit flag is true.
The Policies Import but do not Submit if the flag is false.

If there is no enrollment file with the specified enrollmentFileName, then the system creates a new enrollment file with the specified name and a reference to the group client with the groupClientCode.

The submit flag is false by default.
The groupClientCode is only relevant when creating a new enrollment file.
The batch process does not wait for the Submit process to complete, but only triggers it.

File Processing Mechanism

Refer to "Submit For Processing" section above for more specifics of how Policies update.

Authorization

Starting this operation requires a grant for Policies Batch IP access restriction.

File Response

There are several ways to track the progress of the Import process. The typical approach is to subscribe to a notification event.

A pre-configured endpoint receives a notification message. The notification endpoint configures on ohi.activityprocessing.notification.endpoint.POLICY_IMPORT or to a more generic endpoint ohi.activityprocessing.notification.endpoint.

Configuring a notification endpoint on the specific POLICY_IMPORT fetches all the related properties like media type, authentication, etc. based on POLICY_IMPORT, or else uses defaults. Similarly, configuring an endpoint for the notification without the specific Code fetches all other properties on a generic use case code ActivityNotificationClient. Please see section "Outbound RESTful Service Invocations" in Security Guide for the process and more properties.

The chapter "Long Running Operations through REST" in the Developer Guide describes the common notification structure of the notification message.

The response notification includes a Data File Set link of the completed writepolicies request containing messages (fatal or info) for each Policy it imports.

The system responds with HTTP 201 (Created) and a location header for the long-running operation.

The response Data File Set holds data files containing the result of the Policies with the following mock XML structure:

<policiesResponse>
   <resultMessages result="S">
    <resultMessage code="GEN-FILE-006"> The total number of successfully processed records is 4
   </resultMessage>
 </resultMessages>
<resultMessages result="F" elementId="1">
     <resultMessage code="GEN-FIEL-002"> The field flex1 with code fcX and flexCodeDefCode SIMP could not be resolved
    </resultMessage>
 </resultMessages>
</policiesResponse>

NOTE

The <policiesResponse> element contains one or more Policies. A specified Code in the payload identifies each Policy. Uses the element Id if nothing is specified and uses NO_Key when specifying both. Each policy contains one or more messages which relate to that Policy. The response only contains <policy> elements for those Policies for which the system generates error or info messages during processing.

Error Messages

The following error messages that are specific to the Policies interface may return as part of the response messages:

Table 1. Error Messages
Code	Severity	Message
POL-IP-POLI-001	Fatal	Brand code {code} is unknown
POL-IP-POLI-002	Fatal	Data access group code {code} is unknown
POL-IP-POLI-003	Fatal	Group account code {code} is unknown
POL-IP-POLI-005	Fatal	Insurable entity code {code} is unknown and there are not enough attributes specified to create a new {usageName}
POL-IP-POLI-006	Fatal	Enrollment product code {code} is unknown
POL-IP-POLI-007	Fatal	Parameter alias code {code} is unknown
POL-IP-POLI-008	Fatal	Add-on code {code} is unknown
POL-IP-POLI-018	Fatal	Group account with code {code} does not have a group account product with code {code}
POL-IP-POLI-019	Fatal	Multiple policies exist with the same code
POL-IP-POLI-021	Fatal	Broker code {code} is unknown
POL-IP-POLI-022	Fatal	Agent code {code} is unknown
POL-IP-POLI-023	Fatal	Relation code {code} is unknown
POL-IP-POLI-024	Fatal	Insurable entity type code {code} is unknown for the policy’s insurance type with code {code}
POL-IP-POLI-025	Fatal	Insurance type of enrollment product {code} does not match the policy’s insurance type with code {code}
POL-IP-POLI-026	Fatal	Insurance type {code} is unknown
POL-IP-POLI-027	Fatal	Unresolved pend reasons exist and you don’t have the privileges to resolve them
POL-IP-POLI-028	Fatal	Policy in status {status} cannot be submitted
POL-IP-POLI-029	Fatal	Insurable class code {code} is unknown
POL-IP-POLI-030	Fatal	Schedule definition code {code} is unknown
POL-IP-POLI-031	Fatal	Premium schedule type code {code} is unknown
POL-IP-POLI-032	Fatal	Enrollment product category code {code} is unknown
POL-IP-POLI-033	Fatal	Enrollment type code {code} is unknown
POL-IP-POLI-034	Fatal	Billing account code {code} is unknown
POL-IP-POLI-035	Fatal	Collection method code {code} is unknown
POL-IP-POLI-036	Fatal	Process flow code {code} is unknown
POL-IP-POLI-037	Fatal	Policy identifier type code {code} is unknown
POL-IP-POLI-038	Fatal	Group Client code \(code) is unknown
POL-IP-POLI-039	Fatal	Line of business {0} is unknown
POL-IP-POLI-040	Fatal	Never in force reason code {0} is unknown
POL-IP-POLI-041	Fatal	SEP reason code {code} is unknown
POL-IP-POLI-042	Fatal	OEC SEP code {code} is unknown
POL-IP-POLI-043	Fatal	Disenrollment reason code {code} is unknown
POL-IP-POLI-044	Fatal	This version of the policy has been reverted and no longer exists or policy not found
POL-HTTP-010	Fatal	Data file set code {code} is unknown

Apart from the above error messages, the following error messages from Relation interface may return as part of the response messages:

Table 2. Error Messages from Relation interface
Code	Severity	Message
REL-IP-RELA-004	Fatal	Title code {code} is unknown
REL-IP-RELA-006	Fatal	Prefix code {code} is unknown
REL-IP-RELA-008	Fatal	Language code {code} is unknown
REL-IP-RELA-009	Fatal	Country code {code} is unknown
REL-IP-RELA-010	Fatal	Bank code {code} is unknown
REL-IP-RELA-011	Fatal	Bank account validation code {code} is unknown
REL-IP-RELA-012	Fatal	Country region code {code} is unknown
REL-IP-RELA-015	Fatal	Provider identified by code {code} and flex code definition code {code} is unknown
REL-IP-RELA-016	Fatal	Provider assignment type code {code} is unknown
REL-IP-RELA-017	Fatal	Capitation contract code {code} is unknown

In addition, it may return functional business rule messages as well and the standard messages that relate to dynamic fields and dynamic records (refer to the "Response Messages" section in the HTTP API/IP Concepts part of the Developer Guide).

Submit and Apply Registrations (AU Specific)

Trigger the process and apply for registrations immediately after Submit by enabling the Process and Apply Registrations request header parameter on Submit Policy request.

When a Policy is in the Edit status, the user can select from any of:

Submit the Policy for processing without setting the Process and Apply Registrations header parameter (false by default).
Submit the Policy by setting the request header parameter Process and Apply Registrations to true.

A POST request starts the request to Submit the Policy with the URI /policies/submit with the option of setting the following parameter:

header - processandapplyregistrations: true

The Process and Apply Registration requires the following three additional request header parameters to process once it is true:

header - finTransDynLogic: "...",
header - comFinTransDynLogic: "...",
header - disableRevGrouping: true

The registrations apply only if the Policy reaches the Approved status. No registrations apply if the Policy does not reach the Approved status, if it pends.

Response

The Response Messages define this operation for providing HTTP status codes. A successful operation returns HTTP Status 201 together with a resource representation of the Policy. The occurrence of an error returns an appropriate HTTP status code, along with the error details.

This functionality is specific to Australian environment only.