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:

Code

The unique code for this boilerplate text

Text Value

The text value for this boilerplate text

Line of Business

The line of business 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 OHI Components - UI Customization Guide for the specifics) or for Line of business specific customization.

Line of Business Specific Boilerplate text

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

For example: if Persons are used in a Health Insurance line of business and in a Life Insurance line of business, 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.

A line of business specific boilerplate text can be created by copying an existing boilerplate text, give the copy a reference to a line of business, update the text to the required value and save the new boilerplate text. Line of business 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 line of business.

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

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

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 line of business dependent.

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

A reference to a line of business can be applied to all not system specific boilerplate text. The system does not restrict what boilerplate text can be made line of business specific. However only the UI pages that use line of business specific boilerplate text will display these texts. All other UI pages and the menu will ignore line of business 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 the OHI Claims. 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 you use 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, so you can derive for which page components they are used.

Generic Menu/Navigation/Button/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"

etc.

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 (e.g. 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 & Example

<Prefix>_<Entity>_TITLE_PLURAL

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

<Prefix>_<Entity>_TITLE_SINGULAR

JET & 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 & 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