This specification provides the definition of the Insurance policy administration message (IPPOAD) to be used in Electronic Data Interchange (EDI) between trading partners involved in administration, commerce and transport.
1.1 Functional definition
The Insurance policy administration message is exchanged between insurers, insurance intermediaries, clients and third parties for the purpose of policy administration. It covers the administration of a policy from initial placing, through adjustment and renewal to cancellation as well as providing policy declarations to third parties.
1.2 Field of application
The Insurance policy administration message may be used for both national and international applications. It is based on universal practice related to administration, commerce and transport, and is not dependent on the type of business or industry.
The message should contain information relating to a single insurance contract (which may be a single policy or a group of policies under one contract number), although this contract may have more than one insurer (co-insurance).
The message may contain many business transactions but all must relate to a single contract.
The message is used for all transaction types in either dialogue (request for and provision of policy details) or notification (after the event) processing.
The structure of IPPOAD is based upon the insurance sub-working group insurance underwriting data model. The major entities in the data model form the core segment groups. These groups are for the policy contract (triggered by the Insurance cover description segment), parties (triggered by the Party name segment), insurance objects (triggered by the Risk object description segment), and events and activities (triggered by the Event segment) and are positioned at the top level in the message structure.
When processing a policy transaction a series of input 'components' associated with the major entities are processed.
For example, when the insurance object is a premises then information on its construction is required, when the object is a vehicle then information on its security devices is required.
As a result of the transaction a series of output 'components' is derived, for example, covers and premiums. These input and output components are carried in a group of segments triggered by component details, where a coded qualifier identifies the type of component. The component details component group is positioned hierarchically below each of the major entity groups in the message.
Below each of the component groups a group of segments, triggered by premium calculation component, is positioned. The premium calculation component groups provide details of the components used to calculate the premiums and derive the covers for the main entities, for example, loadings, discounts, excesses, endorsements, conditions.
Other top level groups that complete the message structure are triggered by the sequence details segment - to provide details of the insurance history (previous policies) for the risk and the payment terms segment - to provide payment details.
Although the major entities are linked hierarchically to their input and output components and the premium calculation components there is also a requirement to link the entities relationally across the message structure, for example, parties (drivers) to objects (vehicles). To achieve the links each group has an Identity segment positioned as the first segment inside the group that contains a unique identification number.
These identification numbers may then appear inside other groups as 'foreign keys' to provide the relational links. They may also be used to provide 'parent child' relationships; for example, a parent object of a premises may contain a child object of a freezer.
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 1.
3. TERMS AND DEFINITIONS
3.1 Standard terms and definitions
See UNTDID, Part 4, Chapter 2.3 UN/ECE UNSM - General Introduction, Section 2.
4. MESSAGE DEFINITION
4.1 Data segment clarification
This section should be read in conjunction with the segment table which indicates mandatory, conditional and repeating requirements.