New Result Interface

The root XML element NIResult contains the following XML elements that are being explained later in this document:

XML attributes of NIResult

Example:

A caseObject represents a set of information that can be considered as an object with attributes. This can be a medical disorder, a pursuit, a benefit, an assured person or a policy holder.

The following subtypes of caseObject exist: application, person, tariff, disorder, disorderConsolidated, pursuit, foreignTravel, drug, doctor, occupationalHazard.

These elements have been introduced only for readability of the interface. From their content they are identical in most aspects to the generic caseObject. Real caseObjects have the 2 additional attributes typeId/typeIdName that describe the type of the caseObject.

All caseObjects contain the following XML elements:

Example:
The XML below has the following structure (caseAttributes were omitted):

Explanation: the caseObject of type tariff contains a caseObject of type disorderConsolidated and two caseRisks. The disorderConsolidated element contains a caseObject of type disorder and no caseRisk. The element disorder contains one caseRisk.

XML:

The XML element caseRisk can contain caseResult elements.

The caseRisk element of the Result interface has the following attributes:

Example:

The XML element caseResult can contain the following XML elements that are described in the following subchapters:

caseResults contain an assessment result, like a loading, a declinature, an exclusion, etc. Details to such a result are described in its resultAttributes. In addition there can be explanations, which describes the reason for this result. Missing answers from the client, which are important for the assessment, are being described as a missingInfo element.

Thus a caseResult element contains any number and combination of the abovenamed 3 XML elements. The number of allowed resultAttributes depends on the type of the result (ResultType; see resultTypeId below).

The caseResult XML element can have the following attributes:

Example:

A missingInfo element refers to a question that is crucial for the assessment, but has not been answered by the customer. The missingInfo contains no further XML elements. It has the following attributes:

As the missingInfo element appears inside of the hierarchy, it should be clear to which object, benefit and person it belongs.

Section Example for caseRisk, caseResult, missingInfo and explanation shows a XML example in which a missingInfo appears.

An explanation is basically a text explaining more in detail why or how the current result has been created. They are identical to the Explanation in the Result interface. An explanation contains no further elements, and its attributes are:

Every caseObject contains at least one caseAttribute. caseAttributes contain the answers from the client, about him/herself, a disorder, a pursuit, etc. They describe the object (caseObject) in which they are located. resultAttributes describe a result (a caseResult). resultAttributes are created during the assessment of the application.

Both XML elements wrap a value, which can be a number, a text, a selection, a date, etc.

The elements caseAttribute and resultAttribute have several XML attributes, which can appear depending on whether it is a caseAttribute or a resultAttribute. The possible values are listed further down. First a list of all possible XML attributes:

Always present are typeId and typeIdName. Depending on the existing attributes a parsing and the display of a value has to happen.

A value can be:
a text, a number, a selection value, a date, a period of time, a reference to another CaseObject, or a list of values. A list can contain values of all types; e.g. a list of numbers, or a list of selection values..

Text:

Example:

Reference to a caseObject

Example:

A number

Example:

Hypertonia (complex numerical value)

Example:

Date

This value type will currently not appear in a NIResult. We include it here for completeness reasons.

Examples, in which part of the date are unknown:

Period of time

This value type will currently not appear in a NIResult. We include it here for completeness reasons. the following 3 attributes do not have to all be there.

Example:

A selection value

The XML attribute come from the DBRefValue, as it is defined in the input interface. The diverse combinations of attributes are explained in detail in the input interface documentation.

Examples:

Lists

A caseAttribute that contains a list of values (all of the same type) has no further attributes (other than the 2 mandatory ones) and contains its list-values as further caseAttributes.

A resultAttribute that contains a list of values (all of the same type) has no further attributes (other than the 2 mandatory ones) and contains its list-values as further resultAttributes.

Examples:

Empty list:

The overall result of an assessment can be found at 2 places in the NIResult:

In COMPASS risks are being propagated bottom-up. I.e. for a specific risk X the result will mostly be equal or worse than the worst result of the sub-risks. Or in other words: When the overall result is refer, we can assume with a high probability that a sub-risk has also been assessed as refer (and none as decline).

The attribute resultLevelId="0", "3", "5", "2" or "6" means that the policy should not be issued without further action.

When this attribute is "1", "4" or "7", we can assume that all sub-risks are also standard or that there are only insignificant risks that can be waived (e.g. a small loading of 10%).

When the overall result is not standard a more detailed analysis should follow:

a) Check assessments for each benefit or for each involved person: it could be that one benefit is not accepted, but all others are fine. See Result for a person and Result for a benefit for the detailed result for a person or a benefit.

b) Should the overall resultLevelIdName be offer, it is important to search for the reason, so that an offer can be made to the customer

c) Should the resultLevelIdName be request information, it is recommended to check what is missing, so that the customer can be told what is still missing (mostly additional documents, or missing answers)

In every situation it is important to know the details, and to study the result by assured person and/or by benefit. This is being described in the following chapters.

An application (application) can contain several assured persons (1..N person elements). There are 3 types of persons, which are differentiated by the attribute type:

Each AP can have 1 or more benefits (1..N tariff elements). The tariff element contains the assessment result for the benefit, and is handled in the next chapter.

A person element has always two attributes (caseAttributes) that describe the person:

and

A person element has an attribute ResultLevel (technically: resultLevelId and resultlevelIdName). This value corresponds to the worst ResultLevel of the sub-risks.

Sub-risks are the following:
- one risk per benefit (see Result for a benefit)
- caseRisks, which are direct child elements to person:
here there are two special risks:
- AP risk: the benefit-independent risk of the AP (only for persons that are AP)
- PH risk: the benefit-independent risk of the PH (only for persons that are PH)
- risks, which are in further caseObjects that are direct child elements of person

In any case, existing caseRisks should be analysed. See Analysing a caseRisk.

Should the ResultLevel of a person be standard, no detailed analysis is required, and the person result including all benefits can be considered as standard.

The tariff element contains all details about the assessment for one benefit.

For the identification of the benefit the tariff contains the following attributes (caseAttributes):

and

A tariff element is merged from the original elements Benefit and EventPayment found in the Result interface. This is possible, as there is a 1:1 relation between Benefit and EventPayment (see Restrictions of the new result interface).

As such the tariff element has inherited two CaseRisks from the Benefit risk and from the Event risk. Example:

The caseRisk with the Benefit risk is always present, and reflects in its ResultLevel a rough classification of the benefit assessment. When this ResultLevel is standard, a detailed analysis of the tariff element is not required.

Should the Event risk be different from the Benefit risk, the Event risk caseRisk is also present in the NIResult.

Furthermore the tariff element can contain diverse caseObjects (including the derived types disorder, drug, foreignTravel, pursuit, etc.), with their caseRisks.

The context for a caseRisk is given by the hierarchy of parent caseObjects.

Example: a caseRisk in a pursuit element contains the assessment for the current pursuit, benefit and person found in the upper hierarchy.

To analyse a caseRisk means evaluating its attributes and all included instances of caseResult.

The attributes worth mentioning are riskText and riskTypeIdName, which are identical as in the Result interface. Those attributes contain information about the risk (see Result Interface) in which the results were created (e.g. in the risk over-/underweight). In addition each caseResult has to be analysed:

Every caseObject is of a specific type. Certain types have been singled out, and they have got their own XML elements (e.g. pursuit, disorder, person, … ; see Terminology). Those CaseObjects that are not one of the special sub-types have two XML attributes typeId and typeIdName, which describe the exact type:

Example:

In most situations these caseObject elements are in the NIResult, because they have produced a non-standard result. As such it is important to look for the caseRisk in the caseObject, and process it.

Each CaseObject (and each sub-CaseObject) contains at least one attribute which describes it. For example: