SYNTAX INDEPENDENT COMPONENTS

Implementation Related Components (*)

Home

Filters Filters help developers to determine what policy types, risk objects, guarantees and circumstances can be expected for a given domain and vice versa.
So, you, as a user, can see which domains do apply for some risk object (or for some guarantee, or for some policy type, or for some circumstance).
And next, you can see which guarantees, risk objects, policy types or circumstances are present in such domain...
Note this is not about the message-reception-integration-filter which is something else and which is explained in the BBP (Broker Business Processes).

Choose a Risk Object, Guarantee, Policy Type and/or Circumstance, and for each, view the Domains which apply...
Select a Risk Object
and/or Select a Guarantee
and/or Select a Policy Type
and/or Select a Circumstance

And/or choose a Domain and view the filtered Guarantees, Risk Objects, Policy Types and/or Circumstances
Select Domain
Show Guarantees
Yes / No
Show Risk Objects
Yes / No
Show Policy Types
Yes / No
Show Circumstances
Yes / No

And/or choose a Risk Object and Guarantee, and view the resulting Policy Types
Select a Risk Object
and Select a Guarantee

Include all definitions :  
Yes No
Choose your language :  
NL Nl FR Fr

Here are some views per Domain of the ...

What are ...
Domain

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.
(The Syntax Independent Code List A571 has been added later on and follows the coding of the X916 list - it contains labels which are less addressing our professional users, but which are more client-friendly.)

Policy Type
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.
(The Syntax Independent Code List A572 has been added later on and follows the coding of the A502 list - it contains labels which are less addressing our professional users, but which are more client-friendly.)
Risk Object
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.
(The Syntax Independent Code List A573 has been added later on and follows the coding of the X052 list - it contains labels which are less addressing our professional users, but which are more client-friendly.)
Guarantee
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.
(The Syntax Independent Code List A574 has been added later on and follows the coding of the X058 list - it contains labels which are less addressing our professional users, but which are more client-friendly.)
Circumstance
When some (accidental) event gives rise to some claim, such event may have occurred within or together with given circumstances which can be mitigating, aggravating, exceptional, perturbing,...
The values come from the Syntax Independent Code List C221.
Note the definition of this C221: "... Guarantee and circumstance should be kept separated. They should not be confused. Dixit the (dutch) Vandale:- something that accompanies any act, event, condition: it all depends on the circumstances -. ..."
Note also that what is a guarantee in one contract/claim can easily be a circumstance in another contract/claim. This is what makes it so difficult to come to a good/sound agreement on what the content of our C221 list should be...

(*) : 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?
...