PolicyScreen

Policy screen is the foundation of an insurance contract. It is a main screen of OIPA. This screen rule is overridden at the plan level for each product, where it houses product specific information, or at the system level, where it’s used as the basis for creating the Application screen.

This business rule is used to configure the fixed fields of the Policy screen in order to: 

  • Capture the basic information required for the policy like effective date, issue date, issue state, policy number, etc.
  • Perform policy level allocations
  • Define roles, role counts, role percents and client types for roles that are required for a policy
  • Define segment requirements
  • Enable/Disable policy field and state approvals

This business rule is used to configure the fixed fields of the Application screen in order to:

  • Capture basic application information, such as active date, issue date, issue state, application number, etc.
  • Add requirements to the application
  • Add impairments to the application

Policy summary section is added to the Policy Overview Screen to make it consistent with other policy related pages and compatible with prior versions. Now policy summary is displayed with all of the fixed fields presented in the same order and format as they present on the PolicyScreen. This is the default presentation of the policy summary for all policy related pages except the PolicyScreen which retains the current fixed field and dynamic field presentations alone and no summary. In addition, configurability for policy summary will be added so each customer may specify the fixed fields and presentation order they wish.

If the Policy Summary section configuration does not exist in the PolicyScreen business rule, the following fields/values are displayed in the order as stated below:

  • Policy Number
  • Company
  • Plan
  • Plan Date
  • Policy Name
  • Policy Status
PolicyScreen: Elements and Attributes
Element/Tag Parent Element Attribute Definition Element/Attribute Value and Description

<PolicyScreen>

  

 

The opening and closing tag of the business rule.

 
<Filter> <PolicyScreen>  

Optional element:

Allows to restrict access of privileged policies from selected security groups.

  
<Conditions > <PolicyScreen>   Required  
<Conditions > SecurityGroup

Required:

The security group on which the filtering should be applied. Multiple security groups can be added with coma separated values.

  
<Conditions > Type

Optional

 Values: Exclusion

Default: Exclusion
<Conditions > Operator Optional Values: OR|AND

Default: OR
<Condition> <Conditions >   Required  
<Conditions > Fieldname

Required:

The dynamic field name

 Field Name
<Conditions > Value

Required:

The dynamic field value

Field Value
<AllowPlanDateModifications> <PolicyScreen>  

Optional element:

This element defines whether the PlanDate field is disabled after the policy is saved for the first time, or if it enabled/disabled based on the value of the <DisablePolicyFields> element.

 Yes/No

Yes - The PlanDate field will be enabled/disabled based on the policy's status and the value of the <DisablePolicyFields> element.

No - The PlanDate field will be disabled when the policy is saved for the first time.

Note: If set to "Yes," the Plan Date entered by the user will be validated based on two conditions: If <UseStateApproval> is set to "Yes" in the PlanScreen business rule, the Plan will be valid in the selected Issue state provided the PlanDate is between the EffectiveDate and ExpirationDate saved in the AsPlanStateApproval table.

If state approvals are applicable at the segment level, and the <SegmentName> element's APPROVALDATE attribute is set to "PlanDate" on the corresponding SegmentScreen rule, the Plan will be valid in the selected Issue state provided the PlanDate is between the EffectiveDate and ExpirationDate saved in the AsSegmentStateApproval table.

If the PlanDate entered by the user is invalid based on any of the conditions above, an error message will be displayed, and the PlanDate field will be reset to its previous value.

<FixedFields>

 <PolicyScreen>

 

Optional element:

This element allows the fixed fields to have the same configuration capabilities as dynamic

(below the line ) fields: the only exception being the ability to change the fixed field data types.

 

<Fields> 

 <PolicyScreen>

 

Required element:
Allows configuration of dynamic fields.

See Fields.

Note: Icons for PolicySearchScreen and ClientSearchScreen can be configured in the PolicyScreen by using the client datatype, which will be displayed as disabled text boxes with search and people icons, respectively. Searching returns the respective GUIDs.  

 
<PolicySummary> <PolicyScreen>  

Optional:

Allows a customized definition of the Policy Summary that appears at the top of all policy related pages except the Policy Screen. Default behavior when the element is not configured is to present all policy fixed fields in the same order and format as they display on the Policy Screen.

  
<Summary> <PolicyScreen>   The opening and closing tags of the summary section of the Policy Summary.  
<FixedFieldName> <PolicySummary>   Names the fixed field to present. PolicyNumber | PolicyName | StatusCode | PlanDate | Company | Plan | IssueStateCode | Product
<Fields> <PolicySummary/Summary>   Wrapper element of Field Element.  
<Field> <Fields>   Names the fields to be presented.  
<Name> <Field>   Specifies the database column in which the field values are stored.  
<Display> <Field>

BOLD

ITALICS

Optional:

Renders bold or italicized representations of a dynamic field’s contents.

Yes: Field contents will be bold and/or italicized.

No: Contents will not have bold or italicized content.
<Group> <Field>  

Required element if configured under Summary Tag

This is the name of the group (table) that should be used to obtain the value. This is used only where source data may come from multiple tables (i.e., search screens).

 Policy | PolicyField | Math
<Client> <Summary>   Container element for all the client fields.  
<ClientType> <Client>      
  ROLECODE

Required:

Mandatory field when ClientType is used.

 AsCodeRole from ASCode table.
<Fields> <ClientType>      
<Field> <Fields>   Names the fields to be presented.  
<Name> <Field>   Specifies the database column in which the field values are stored.  
<Display> <Field>

BOLD

ITALICS

Optional:

Renders bold or italicized representations of a dynamic field’s contents.

Yes: Field contents will be bold and/or italicized.

No: Contents will not have bold or italicized content.
<Group> <Field>  

Required element if configured under Summary Tag

This is the name of the group (table) that should be used to obtain the value. This is used only where source data may come from multiple tables (i.e., search screens)

 Client | ClientField
<Address> <Summary>   Container element for all the Address fields  
<AddressType> <Address>      
  ROLECODE Required AsCodeRole from AScode table.
  ADDRESSTYPECODE Required Value from the AsCodeAddressRole column of the AsCode table: ‘01’, ‘02’, etc
<Fields> <AddressType>      
<Field> <Fields>   Names the fields to be presented.  
<Name> <Field>   Specifies the database column in which the field values are stored.  
<Display> <Field>

BOLD

ITALICS

Optional:

Renders bold or italicized representations of a dynamic field’s contents.

Yes: Field contents will be bold and/or italicized.

No: Contents will not have bold or italicized content.
<Group> <Field>  

Required element if configured under Summary Tag

This is the name of the group (table) that should be used to obtain the value. This is used only where source data may come from multiple tables (i.e., search screens).

 Address | AddressField
<Role> <Summary>   Container element for all the Role fields  
<RoleType> <Role>      
  ROLECODE

Required:

Mandatory field when RoleType is used.

 AsCodeRole from AScode table
<Fields> <RoleType>      
<Field> <Fields>   Names the fields to be presented.  
<Name> <Field>   Specifies the database column in which the field values are stored.  
<Display> <Field>

BOLD

ITALICS

Optional:

Renders bold or italicized representations of a dynamic field’s contents.

Yes: Field contents will be bold and/or italicized.

No: Contents will not have bold or italicized content.
<Group> <Field>  

Required element if configured under Summary Tag

This is the name of the group (table) that should be used to obtain the value. This is used only where source data may come from multiple tables (i.e., search screens).

 Role | RoleField
<GroupCustomer> <Summary>   Container element for all the GroupCustomer fields  
<GroupCustomerType> <GroupCustomer>      
  ROLECODE

Required:

Mandatory field when GroupCustomerType is used.

 AsCodeRole from AScode table.
<Fields> <GroupCustomerType>      
<Field> <Fields>   Names the fields to be presented.  
<Name> <Field>   Specifies the database column in which the field values are stored.  
<Display> <Field>

BOLD

ITALICS

Optional:

Renders bold or italicized representations of a dynamic field’s contents.

Yes: Field contents will be bold and/or italicized.

No: Contents will not have bold or italicized content.
<Group> <Field>  

Required element if configured under Summary Tag

This is the name of the group (table) that should be used to obtain the value. This is used only where source data may come from multiple tables (i.e., search screens).

 GroupCustomer
<FixedFieldName> <FixedFields>   Required: Names the fixed field to present. Filler may also be presented. Optional: Indicates whether the field will occupy an entire line on the screen

<MultiFields>

 <PolicyScreen>  

Optional element;

Allows configuration of MultiFields in the PolicyScreen See MultiFields element for additional information.

MultiFields enables and allows Policy Screen with multiple sets of dynamic field values.

<Buttons>

<PolicyScreen>

 

Required element:
Allows configuration of buttons.

 

<Button>

 <Buttons>

 

Optional element:
Defines the display of function buttons on the Policy screen.

Required Element value:

Allocate
Activity
Close
New
 PolicyOverview
Save
Values
Withholding
Allows the display of specified buttons on the Policy screen.

<Events>

 <PolicyScreen>

 

See Action Events

 

<ScreenMath>

 <PolicyScreen>  

See ScreenMath Element.

  

<Actions>

 <PolicyScreen>  

See Action Events

  

<SegmentsAllowed>

 <PolicyScreen>

 

Optional element:
Specifies the number of segments that are allowed on the policy.

Required element value:
Integer / *
Number of segments. Allows the user to add only up to specified number of segments to the policy.

Note: The star * symbol indicates that unlimited number of segments can be allowed for a policy.  

<MinimumSegments>

 <PolicyScreen>

 

Optional element:
Specifies the minimum number of segments that MUST be attached to a policy before any activity can be processed.

Optional element value:

Integer
Number of segments. This forces the user to add at least the minimum number of segments prior to processing the policy activities.

Note: This element is required to add activities.

<DisablePolicyFields>

 <PolicyScreen>

 

Optional element:
Specifies when fields on the Policy screen can or cannot be edited, based on policy status. Disables policy fields for the specified policy status if the policy status code matches a code in the DisabledStatus section for the particular policy.
 

Note: When AutomaticPolicyNumber generator is not used, PolicyNumber field should be editable even after saving the policy that allows the entering and editing in that field until another policy event (calculating a coverage, issue of the policy).

 

<DisabledStatus>

 <DisablePolicyFields>

 

Required element:
Indicates which applicable status(es) would trigger the lock-down of editable fields. This element defines policy status codes for the policy fields that will be disabled on the Policy screen.

Required element value:
PolicyStatusCode list
Policy Status Codes from AsCode=>AsCodeStatus

<SegmentCount>

 <PolicyScreen>

 

Optional element:
This element specifies the segment count that will be used only when policy status does not match a code in the DisabledStatus section for the particular policy. When policy status does not match a code in the DisabledStatus section then policy fields will be disabled.

Optional element value: * / +

" * ": Disables policy fields in all conditions.

" + ": Disables policy fields when policy has at least a minimum of one segment in active status.

<AutomaticPolicyNumber>

 <PolicyScreen>

 

Optional element:
Allows generating automatic policy number when a new policy is created as per the format specified in AutomaticPolicyNumber business rule.

Yes: Allows generating automatic policy number when new policy is created.

Optional: If a number is entered, then the value will be considered and recorded. If it is not entered, then the system will automatically generate a policy number.

No:Automatic policy number will not be generated when new policy is created and allows the user to enter the policy number in the PolicyNumber field. If this element is not present default is "No".

<Roles>

 <PolicyScreen>

 

Opening tag for defining roles on the policy.

  

<Role>

 <Roles>

 

 Required and repeatable element:
This element defines the description of the role that will be added to the policy.

Note:

  • A role is a policy-driven position held by a person or entity.

  • Roles can be attached to the policy, when creating a new policy or attach to an existing policy.

  • Each role tag will result in the addition of one or more clients to a specific role on a policy. By having multiple <Role> tags, more than one role can be added to a policy at the same time.

  • The order in which roles are configured in the XML will dictate the order in which the role checkboxes display on the Find Client and New Client tabs of the Policy screen. Roles on these tabs are ordered left to right, top to bottom across three columns. As the presentation of checkboxes or role drop down field is defined in configuration, the same ordering will apply to the drop down list if the field is used.
<Role>

NAME

  

Optional attribute:
RoleName
A short description of the name as per AsCodeRole.
<Role> DISABLEBYPOLICYSTATUS  

Optional attribute:
PolicyStatusCode

Used to prevent disabled roles from being disabled. It is also used to disable role fields, role percents and prevent disabled fields from being added to a policy.
<Role> ALLOWREQUIREMENTS

Controls the 'Add Requirement' button on the Requirement screen. The Requirement screen can be viewed by clicking on the Requirement tab.

Optional attribute:

Yes: The 'Add Requirement' button will display.

No: The 'Add Requirement' button will not display.

<RoleCode>

 <Role>

 

Required element:
Code values of a role that is applicable to this plan.

Required element value:
RoleCode
Role code of the role as per AsCodeRole.

<RoleCount>

 <Role>

 

Optional element:
Specifies number of times a role can be assigned to policy.

Required element value:
Integer or *
Allows the user to assign this type of role only specified number of times to the policy. An asterisk ("*") can be used to indicate that there is no limit to the number of times the role can exist for a policy.

<RolePercent>

 <Role>

 

Required element:
Defines the total percent value that OIPA will validate against when a role is created. OIPA will only accept a role with one or more records, where the total percent value matches <RolePercent>.

Required element value:0-100 or *

An asterisk can be used to indicate that the total percent for the associated role can exceed 100%. Each individual record will still have a maximum of 100%, but the total for multiple records on the same Policy Role will be able to exceed 100%.

<ClientType>

 <Role>

 

Optional element:
Define the client types that can be assigned to the role. Only these client types will be displayed in the Client Type drop-down box in the Client screen, for the specific role.

 

Example:An insured may need to be an individual client type for a particular plan.

Required element value:
ClientTypeCode
A comma-separated list of client type codes from the AsCodeClientType code name.

<Tests>

 <Role>

 

Optional Element:
Allows configuration of test(s) condition. The evaluation of the condition decides whether or not the particular role section can be executed.

 

<Test>

 <Tests>  

Required/Repeatable Element:
Expression used to determine if role should be displayed/allowed for policy.

Expression:
Literal values can be used for the test condition.
<Test>

TYPE

  

Optional attribute: (="Expression")

To indicate the type of the condition.

Example:

<Test TYPE="Expression">
SomeMathVariable=27</Test>

<AllowZeroPercent>

 <Role>

 

Optional element:

Allows Zero percent in Role percent fields.

Required element value:

Yes/No

Yes:Allows user to enter zero percent in the Rolepercent field.

No:When set to "No" then Zero Percent is not allowed. 

Note: If this element is not present then the default is "Yes".

<AllowPercent>

 <Role>

 

Optional element:

Controls the display of the Percent box next to the names of individuals that have been assigned to the specified role.

Required element value:

Yes/No

Yes: When set to "Yes" the Percentage box is displayed next to the name of the individual that has been assigned to the specified role.

No: The percentage box is not displayed next to the name of individuals that have been assigned to the specified role.

Note: If this tag is not present then the default is "Yes".

XML Schema 

<PolicyScreen>
<Summary>
<Fields>
<Field>
<Name></Name>
<Display></Display>
<Group> Math | Literal</Group>
</Field>
..
..
</Fields>
<Client>
<Fields>
<Field>
<Name></Name>
<Display></Display>
<Group> Math | Literal</Group>
</Field>
..
..
 
</Fields>
</Client>
<Address>
<Fields>
<Field>
<Name></Name>
<Display></Display>
<Group> Math | Literal</Group>
</Field>
..
..
 
</Fields>
</Address>
<Role>
<Fields>
<Field>
<Name></Name>
<Display></Display>
<Group> Math | Literal</Group>
</Field>
..
..
 
</Fields>
</Role>
<GroupCustomer>
<Fields>
<Field>
<Name></Name>
<Display></Display>
<Group> Math | Literal</Group>
</Field>
..
..
</Fields>
</GroupCustomer>
</Summary>
<AllowPlanDateModifications>[Yes|No]</AllowPlanDateModifications>
<FixedFields>Please refer to "Fixed Fields"</FixedFields>
<Fields>Please refer to "Fields".</Fields>
<MultiFields RULE="[RuleName]">"[Yes|No]"</MultiFields>
<Buttons>
<Button>"[Allocate|Activity|Values|Withholding|PolicyOverview]"</Button>
</Buttons>
<Events>Please refer to "Events"</Events>
<ScreenMath>
<Math>Please refer to "Math"</Math>
</ScreenMath>
<Actions>Please refer to "Actions"</Actions>
<Roles>
<Role NAME="[RoleName]" DISABLEBYPOLICYSTATUS="[DisableByPolicyStatusList]" EXTERNAL="[Yes|No]" 
ALLOWREQUIREMENTS="[Yes|No]">
<ExternalClientRowRetriever>[client search class loader]</ExternalClientRowRetriever>
<AllowZeroPercent>"[Yes|No]"</AllowZeroPercent>
<AllowPercent>"[Yes|No]"</AllowPercent>
<RoleCode>"[RoleCode1,RoleCode2]"</RoleCode>
<RoleCount>"[Integer|*]"</RoleCount>
<RolePercent>"[0-100|*]"</RolePercent>
<ClientType>"[ClientTypeList]"</ClientType>
<Tests>
<Test>"[Condition]"</Test>
</Tests>
<CustomScreen>[custom screen display class]</CustomScreen>
</Role>
</Roles>
<AutomaticPolicyNumber>"[Yes|Optional|No]"</AutomaticPolicyNumber>
<DisablePolicyFields>
<DisabledStatus>"[DisabledStatusList]"</DisabledStatus>
<SegmentCount>"[*|+]"</SegmentCount>
</DisablePolicyFields>
<MinimumSegments>"[Integer]"</MinimumSegments>
<SegmentsAllowed>"[Integer|*]"</SegmentsAllowed>
<ShadowPolicy>
<AllowShadowButton>
<StatusCode>"[ShadowPolicyStatusCodeList]"</StatusCode>
</AllowShadowButton>
<ShadowStatusCode>"[PolicyShadowStatusCode]"</ShadowStatusCode>
</ShadowPolicy>
</PolicyScreen>

XML Example

<PolicyScreen>

<AllowPlanDateModifications>Yes</AllowPlanDateModifications>
<Fields> 

<Field> 

<Name>SortCompany</Name>

<Display>Company</Display>

<DataType>Combo</DataType>

<Query TYPE="SQL">SELECT FundClassGUID, FundClassName FROM
AsFundClass ORDER BY 2 DESC</Query>

<Disabled>Yes</Disabled>

</Field>

<Field>

<Name>ActiveDate</Name>

<Display>Date 
 Activated</Display>

<DataType>Date</DataType>

<Disabled>Readonly</Disabled>

</Field>

<Field>

<Name>Carrier</Name>

<Display>Carrier Company Name</Display>

<DataType>Combo</DataType>
<Query TYPE="SQL">SELECT ClientGuid, CompanyName FROM
AsClient WHERE TypeCode = '19'</Query>        

</Field>

</Fields>
<PolicySummary>
<FixedFieldName EXPANDED= "Yes | No">[PolicyNumber | PolicyName | StatusCode | PlanDate | Company | Plan | IssueStateCode | Product | Filler]</FixedFieldName>
</PolicySummary>
<Buttons> 

<Button>Save</Button>

<Button>New</Button>

<Button>Close</Button>

</Buttons>

<Roles>

<Role DISABLEBYPOLICYSTATUS="01,02,95">

<RoleCode>01</RoleCode>

<RoleCount>1</RoleCount>

<RolePercent>100</RolePercent>

</Role>

<Role>

<RoleCode>37</RoleCode>

<RoleCount>1</RoleCount>

<RolePercent>100</RolePercent>

</Role>

</Roles>
<SegmentsAllowed>4</SegmentsAllowed>

<MinimumSegments>1</MinimumSegments>

<AutomaticPolicyNumber>Yes</AutomaticPolicyNumber>

</PolicyScreen>

XML Example for Policy Summary

<PolicyScreen>
<Summary>
<Fields>
<Field>
<Name>PolicyNumber</Name>
<Display BOLD="Yes">Policy Number</Display>
<Group>Policy</Group>
</Field>
<Field>
<Name>EffectiveDate</Name>
<Display>Effective Date 123</Display>
<Group>PolicyField</Group>
</Field>
<Field>
<Name>FinalValidationMath:PolicyNameError</Name>
<Display>Math variable</Display>
<Group>Math</Group>
</Field>
</Fields>
<Client>
<ClientType ROLECODE="04">
<Fields>
<Field>
<Name>ClientGUID</Name>
<Display>ClientGUID</Display>
<Group>Client</Group>
</Field>
<Field>
<Name>DynamicField</Name>
<Display>DynamicField</Display>
<Group>ClientField</Group>
</Field>
</Fields>
</ClientType>
</Client>
<Address>
<AddressType ROLECODE="04" ADDRESSTYPECODE="02">
<Fields>
<Field>
<Name>Address</Name>
<Display BOLD="Yes">Address</Display>
</Field>
</Fields>
</AddressType>
<AddressType ROLECODE="04" ADDRESSTYPECODE="01">
<Fields>
<Field>
<Name>AddressLine1</Name>
<Display>Address Line1</Display>
<Group>Address</Group>
</Field>
<Field>
<Name>City</Name>
<Display>City</Display>
<Group>Address</Group>
</Field>
<Field>
<Name>DateField</Name>
<Display BOLD="Yes">Date Field</Display>
<Group>AddressField</Group>
</Field>
</Fields>
</AddressType>
</Address>
<Role>
<RoleType ROLECODE="37">
<Fields>
<Field>
<Name>RoleGUID</Name>
<Display>RoleGUID</Display>
<Group>Role</Group>
</Field>
<Field>
<Name>BillingSelectAddress</Name>
<Display>BillingSelectAddress</Display>
<Group>RoleField</Group>
</Field>
</Fields>
</RoleType>
</Role>
<GroupCustomer>
<GroupCustomerType ROLECODE="02">
<Fields>
<Field>
<Name>CompanyName</Name>
<Display>Company name</Display>
<Group>GroupCustomer</Group>
</Field>
</Fields>
</GroupCustomerType>
</GroupCustomer>
</Summary>
</PolicyScreen>

Group Customer Screen XML Example

Example for Restricting Access of Privileged Policies using Filters

<PolicyScreen>
<Filter>
<Conditions SecurityGroup = "Prototype Super,AlamereTest" Type ="Exclusion"  Operator ="OR|AND">
<Condition  Fieldname ="PrivilegedField1"  Value = "X"></Condition>
<Condition  Fieldname ="PrivilegedField2"  Value = "Y"></Condition>
</Conditions>
</Filter>
</PolicyScreen>