SYNTAX INDEPENDENT COMPONENTS

Implementation Related Components (*)

Home
Filters Filters help developers to determine what policy types, risk objects and guarantees can be expected for a given domain and vice versa.
So, you, as a user, can see which domains apply for some risk object (or for some guarantee, or for some policy type).
And next, you can see which guarantees are present in such domain...
Choose a Risk Object, Guarantee or Policy Type, and view the Domains which apply...
Select a Risk Object
and/or Select a Guarantee
and/or Select a Policy Type

And/Or View Guarantees, Risk Objects or Policy Types by Domain
Select Domain
Show Guarantees
 Yes / No
Show Risk Objects
 Yes / No
Show Policy Types
 Yes / No

Include all definitions :  
Yes No
Choose your language :  
FR NL
Here are some views per Domain of the ...
What are ...
Risk Object
Guarantee
Policy Type
Domain
A risk object specifies a person or an item subject of cover in an insurance contract.
The values come from the UN/Edifact Data Element X052.
A guarantee specifies protection provided by insurance against losses caused by perils as defined in the policy. A guarantee can consist of subguarantees and/or covers. Stating premium is mandatory on guarantee level.
The values come from the UN/Edifact Data Element X058.
A policy type indicates to what group a policy belongs. It specifies what the policy is about and what covers can be expected. The policy type also helps to determine which department within the insurers organisation will be dealing with the policy.
The values come from the Syntax Independent Code List A502.

A domain specifies the information that is deemed to be exchanged and how it is to be structured according to policy type, risk object and guarantee.
The values come from the Telebib2 UN/Edifact Data Element X916.

(*) : Implementation Related Components :
- Filters : current implementations ignore subguarantees, and domains are simply not part of the syntax independent components;
- Message Content Inventories : messages implemented are subsets of the greater potential offered by the syntax independent components.
These are 2 arguments in favour of the distinction to be made between Syntax Independent Components and Implementation Related Components.

Filters, continued ...

The usage of these filters has now made clear that:
- certain Risk Objects (types) can be present within multiple Domains,
- certain Guarantees (types) can be present within multiple Domains.

A MultiDomainPolicy :
is a Policy containing one or multiple Risk Objects which do not necessarily adhere to a same unique Domain,
and/or containing one or multiple Guarantees which do not necessarily adhere to a same unique Domain

In terms of Domains touched, Policies can be sorted from less (none) complexity to more complexity.
A SingleDomainPolicy contains only Risk Objects and Guarantees which all adhere to the same unique Domain.
A MultiDomainPolicy, containing Risk Objects from a same unique Domain only, and Guarantees adhering to distinct Domains.
A MultiDomainPolicy, containing Risk Objects from distinct Domains, and Guarantees adhering to distinct Domains.

When looking at all this from the Clients' perspective, it might be logical to work another way around.
Which is the Risk Object (type)?
Which are the Guarantees applicable to such Risk Object? (Hence i need a Filter from Risk Objects towards Guarantees.)
Which of these (Guarantees applicable) are the Guarantees the Client is interested in?
Which are the Products offering these Guarantees? (Hence I need a Filter from Products towards Guarantees, which will here be used in the opposite direction.)
Which of these (Products offered) is the Product the Client is interested in?
And now the big question; what is the next question I need an answer to?
Is it : Which is the Domain this Product adheres to? (Hence I need a Filter from Domains towards Products, which will here be used in the opposite direction.)
Or is it : Which is the party/instance/service who will deliver me this Product?
...