Boilerplate Text

This entity specifies a 'fixed' text item, used in the user interface. Examples are field labels, menu labels, headers. These boilerplate texts can be translated into new languages and/or adapted to conform to customer specific business terminology.

A Boilerplate Text has the following attributes:

Table 1. Boilerplate Text
Code The unique code for this boilerplate text

Text Value

The text value for this boilerplate text

Insurance Type [1]

The insurance type to which this text applies

Boilerplate texts are seeded upon installation, but the text value can be changed. The use of boilerplate text entries, that is where the text appears on a page, is controlled by the system. A set of naming conventions for the Code value is used to clarify the usage in Oracle Health Insurance. See sections below.

It is also possible to add additional boilerplate text for user interface customization (see the Oracle Health Insurance applications - Installation Guide for the specifics) or for Insurance Type specific customization.

Insurance Type Specific Boilerplate Text

A boilerplate text can be customized for a specific insurance type. This allows the user interface to reflect the commonly used terminology within an insurance type even if multiple insurance types are configured in the system. The system determines the insurance type based on the contents of the page. This means that the labels in the user interface for an object in one specific insurance type can differ from the labels in that same UI when displaying that same object for a different insurance type.

For example: if Persons are used in a Health Insurance insurance type and in a Life Insurance insurance type, a UI label for Persons may be different when a person is displayed in the context of Health Insurance from when a person is displayed in the same page but now in the context of a Life Insurance.

An insurance type specific boilerplate text can be created by copying an existing boilerplate text, give the copy a reference to an insurance type, update the text to the required value and save the new boilerplate text. Insurance type specific boilerplate text does not necessarily include the full set of boilerplate text, where a language specific boilerplate text does. It is possible to have only one or a few boilerplate texts for a specific insurance type.

An insurance type specific boilerplate text can have translations. If the generic boilerplate texts is available in the system in two languages, creating an insurance type specific boilerplate text will probably (but not necessarily) require two new copies of the boilerplate text, one for each language.

An insurance type can refer to more than one insurable entity type. This means that the system applies the boilerplate text that is specific for a certain insurance type to all insurable entity types in that insurance type.

The display name of dynamic fields or the display name of dynamic field usages in a dynamic record is not boilerplate text. These display names are not insurance type dependent.

Insurance type specific boilerplate text is used only in a restricted number of UI pages. In those UI pages that use insurance type specific boilerplate text, the system will first search if a boilerplate text for the specific item for the specific insurance type exists. If such a boilerplate text does not exist it will display the not-insurance type specific text.

A reference to an insurance type can be applied to all not system specific boilerplate text. The system does not restrict what boilerplate text can be made insurance type specific. However only the UI pages that use insurance type specific boilerplate text will display these texts. All other UI pages and the menu will ignore insurance type specific boilerplate text.

Examples

The UI can be customized by changing the fixed texts used in the Messages and Boilerplate Text (fixed labels in the User Interface, like page headers, field labels, button labels, etc.).

They can be changed using the Boilerplate, Messages, and Bulk Translation pages within Oracle Health Insurance. The changes are effective immediately, for users running in the language in which the changes were made.

The language in which the changes are made, cannot be a System Specific language like System English. The texts can only be changed in other languages like regular English.

When using the Bulk Translation page for boilerplate and messages (FN0031), all occurrences of the exact same term will be translated in the "Term To". So plurals will be translated too. Like if a boilerplate contains "person" and this needs to be replaced by "party", "persons" turns into "partys". Either translate the plurals first or put spaces in front and at the end of the terms: " person " to " party ".

The following sections explain the naming conventions for the boilerplate text code, to derive for which page components they are used.

Generic Menu, Navigation, Button, or Hint Keys

Boilerplate texts used throughout the whole Oracle Health Insurance application use the prefix 'GEN_' for ADF applications, or 'G_' for JET applications, followed by an explanatory key:

Examples:

  • GEN_ACTION = "Action"

  • GEN_NO_ROWS_FOUND="No rows found."

  • G_APPLY_AND_NEXT="Apply and Next"

Menu Keys

Menu keys are used for (sub)menu titles in ADF (in JET applications, generic boilerplates are used for menu’s).

MENU_TITLE_TOP_<logical name>

MENU_TITLE_SUB_<logical name>

Examples:

  • MENU_TITLE_TOP_REFERENCEDATA = "Reference Data"

  • MENU_TITLE_SUB_PROCESSRULES= "Process Rules"

Domain Keys

Domain Keys are used in drop-down lists. The code of the boilerplate starts with the prefix 'DOMAIN', followed by the Domain Name and the Domain Value:

DOMAIN_<Domain Name>_<Domain Value> = "<Domain Meaning>"

Examples:

  • DOMAIN_GENDER_M = "Male"

  • DOMAIN_GENDER_F = "Female"

Subtype domains use the convention DOMAIN_<Entity>SUBTYPE_<4 letter abbreviation. A subtype domain is used when different subtypes of a supertype can be handled in one page. For example, in the Relations page, both Organizations and Persons are shown.

Examples:

  • DOMAIN_RELATIONSUBTYPE_PERS = "Person"

  • DOMAIN_RELATIONSUBTYPE_ORGA = "Organization"

Entity-Specific Keys

Entity related keys are prefixed with the 3 letter subsystem abbreviation that is also used for the corresponding database table, and the entity name in uppercase (for example, COD_FLEXCODE, or PAS_SEGMENTGROUP). That way they are grouped together with other entities in the same subsystem. Table below summarizes the different types of entity specific keys.

Convention Usage and Example

<Prefix>_<Entity>_TITLE_PLURAL

JET and ADF: For headings of multi-row data blocks within a page.
Example:
COD_FIELD_TITLE_PLURAL

<Prefix>_<Entity>_TITLE_SINGULAR

JET and ADF: For headings of single-row data blocks within a page.
Example:
PAS_BRAND_TITLE_SINGULAR

<Prefix>_<Entity>_TITLE_<FunctionCode>

ADF-only: In menu labels.
Example:
COD_FIELD_CO0001

<Prefix>_<Entity>_TITLE_LOV

ADF-only: In List-of-values
Example:
COD_FIELD_TITLE_LOV

<Prefix>_<Entity>_TITLE_BREADCRUMB

ADF-only: For breadcrumb labels of the page. (A breadcrumb is created when navigating to another page using a deeplink).
Example:
COD_FIELD_TITLE_BREADCRUMB

<Prefix>_<Entity>_TITLE_REGION_<Region>

ADF-only: For region titles.
Example:
REL_COUNTRY_TITLE_REGION_VALIDATIONITEMS

<Prefix>_<Entity>_TITLE_<logical name>

ADF-only: For any other titles related to the entity.
Example:
CLA_CLAIMLINE_TITLE_APPLIEDBENEFITRULES

<Prefix>_<Entity>_DELETE_WARNING

ADF-only: For delete warning. A delete warning is shown in a popup before the actual delete.
Example:
COD_FIELD_DELETE_WARNING

<Prefix>_<Entity>_BUTTON_<logical name>

ADF-only: For command buttons specific to an entity.
Example:
COD_CUSTOMLOGIC_BUTTON_CHECKLOGIC

Item Generic Keys

For items that occur in all/many pages, a generic key is applied for all entities that have such an item.

See table below for conventions used:

Key Usage

GEN_FIELD_STARTDATE

Start date.

GEN_FIELD_ENDDATE

End date.

GEN_FIELD_ACTIVE

Active checkbox.

GEN_FIELD_SUBTYPE

Subtype discriminator.

Item-Specific Keys

An item specific key is created for each individual item on a page following the convention: <Prefix>_<Entity>_FIELD_<Field>_<SUFFIX>. In case the field of the entity points to another entity, a field of the other entity is added: <Prefix>_<Entity1>_FIELD_<FieldToEntity2>_<Field>_<SUFFIX>

<SUFFIX> is used to distinguish between different places an item can occur. See table below:

Suffix Usage

DEFAULT

Default suffix (JET and ADF)

DEFAULT_FROM

Default suffix used for a search from field. (ADF-only)

DEFAULT_TO

Default suffix used for a search from field. (ADF-only)

TABLE

Suffix used for a deviating label in a table layout. (ADF-only)

FORM

Suffix used for a deviating label in a form layout. (ADF-only)

SEARCH

Suffix used for a deviating label in a search layout. (ADF-only)

SEARCH_FROM

Suffix used for a deviating label of a from field in a search layout. (ADF-only)

SEARCH_TO

Suffix used for a deviating label of a to field in a search layout. (ADF-only)

Examples:

  • PAS_PRODUCT_FIELD_CODE_DEFAULT="Code"

  • CLA_CLAIMFORM_FIELD_CODE_DEFAULT_TO = "Code To"

  • CLA_CLAIM_FIELD_CLAIMFORM_CODE_DEFAULT = "Claim Form"

  • REL_PERSON_FIELD_ADDRESSLIST_DEFAULT = "Addresses"

Module-Specific Keys

(JET-only)Boilerplates needed for specific pages/modules that are not an entity title / attribute / domain boilerplate.

Examples:

  • M_CLAIMS_ prefix for the JET Claims search and edit pages, including subpages

    • M_CLAIMS_LINKTOTASKSWITHERRORS

  • M_REPROCESS_ prefix for the JET Reprocess Claim pages

    • M_REPROCESS_COUNT_BUTTON

1. Applicable for Claims, Policies and Authorizations applications.