Messages

A message signifies a piece of process information. As such, messages can be attached to a number of operational business entities, for example, claims, policies, and products, throughout the various Oracle Health Insurance applications.

Consider the following examples:

  • In Oracle Health Insurance Claims Adjudication and Pricing, a message can be attached to a claim to signify that the claim has been denied

  • In Oracle Health Insurance Product Definition a message can be attached to a product to signify that the product is in violation of a business rule

  • In Oracle Health Insurance Enterprise Policy Administration a message can be denied to a policy to indicate the policy is missing information for the insured person or object

Messages are attached to an operational business entity in a number of ways, including through system logic, configured business rules and through the user interface.

A message has one of two levels of severity: 'fatal' or 'informative'. The meaning of the severity 'Fatal' varies per component. For example, in Claims, a claim line with a fatal message attached will result in a denial, while in Oracle Health Insurance Product Definition, product with a fatal message will not be able to become accepted and publishable. Informative messages behave the same across components; they are meant to inform the user without any impact to the regular processing flow.

Messages often serve as a trigger for user intervention. To clarify, consider the following scenario for Claims:

A payer wants to manually adjudicate any claim line which is a suspected duplicate of another claim line. When the system processes a claim line, it searches for a duplicate line. If it finds one, then it attaches a message to the processed claim line, explaining that it found a duplicate claim line. This message, in turn, is one of the configured criteria for manual adjudication. As a result the system pends the claim for manual adjudication.

Message

A message has the following attributes:

Table 1. Message
Field Description

Code

The unique code for this message.

Text

The message text as presented internally, for example, on a user interface page

Alternative External Text

The message text as presented in external output for the person or object

External Code

The message code as presented in external output

External Text For Provider

The message text as presented in external output for the provider

Remarks

Remarks regarding the message. This could be an instruction. #

# Severity

The severity of the message.

The allowed values are: (I)nformative, (F)atal and (D)eny (Claims only).

Deny messages can be overturned without reprocessing the claim. Like Informative messages, Deny messages do not prevent any processing step from running.

In the Set Claim and Claim Line Status step in Adjudication, Deny messages are treated as follows:

- If the Overturn field is set to false, the message is treated as a fatal message.

- If the Overturn field is set to true, the message is treated as an informative message.

System Specific?

System messages that are part of the installation are set to (Y)es. User configured messages are set to (N)o

Active?

Non-active messages can not be attached (anymore) to operational records, nor to configuration rules.

Mark?

If checked, this messages is considered to be marked. There is no system logic that considers this field

Suppress Logging In UI?

Suppressed messages are stored (as usual) but are not displayed in the user interface

Suppress Logging In Ext?

Suppressed messages are not included in outgoing integration point xml messages

Priority

Some pages only show one message, for example, the claim line search results page. For these pages, the priority determines which message is shown.

Messages can be attached to the following entities: Claim, Bill, Claim Line and Authorization.

Message Group

Some Oracle Health Insurance applications allow the user to configure groups of messages. The primary purpose of a message group is support a concise configuration of pend rule. For example, a user can create a single message group called ENROLLMENT that includes all messages that should trigger user intervention because of the person’s or product’s enrollment status.

Table 2. Message Group
Field Description

Code

The unique code for this message group.

Description

The description of this message group.

Access Restriction

The access restriction restricting access to messages in this message group.

Table 3. Messages are Included in Groups in the Following Intersection
Field Description

Message Group

The group to which the specified message belongs.

Message

The message that belongs to the specified group.

Setting up Messages

System-Specific versus Custom Messages

Messages that are system specific can only be generated by system logic. It is not possible for a user to:

  • Set the System Specific? indicator on any message.

  • Refer to a system specific message in the configuration setup. An exception to this are criteria for manual adjudication.

  • Update the Text of a system specific message in a system specific language like Oracle Health Insurance English (as opposed to regular English).

  • Update the severity of a system specific message.

  • Update the active indicator of a system specific message.

  • Update the priority of a system specific message (it is always null).

Messages that are not system specific are referred to as custom messages. Custom messages are not part of the seed data, that is, they have to set up by the user. Note that custom messages can be detached from a claim, bill or claim line through the Claims user interface, while system specific messages cannot.

System specific messages follow the following code format: <ApplCode>_<EntityAlias>_<seqnr>, where the application code is always a three-letter code and the entity alias always a four letter code. For example an actual system specific message is:

Table 4. System-Specific versus Custom Messages
Code Sev Text

CLA_CLAI_005

F

The claim form cannot be updated.

It is strongly recommended that custom message codes follow a different format, as to prevent a conflict between identical codes in future deliveries of Oracle Health Insurance that may introduce new messages.

It is possible to set up dynamic field usages on the message table. These fields are also available on system specific messages, and their value(s) can be freely inserted removed and updated.

Customizing System-Specific Messages

The User Interface 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 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 Oracle Health Insurance 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" end up in "partys". Either translate the plurals first or put spaces in front and at the end of the terms: " person " to " party ".

Marking a Message

The purpose of marking a message is to allow flexibility in the setup of the manual adjudication criteria. Instead of setting up one rule for each message that should be manually adjudicated, a single adjudication rule can be setup that triggers depending on whether one of the messages (attached to a claim) is marked. An added convenience is that, when a system administrator sets up a new message that should be manually adjudicated, only the message needs to be marked: no new manual adjudication rule is required.

Message Severity

The severity of a message informs Claims whether a claim should pay or deny once a claim is finalized. Note that any message, regardless of the severity or whether it is system specific, can trigger a manual adjudication rule.

Messages that are attached to authorizations serve only to inform users through the user interface on the status of that authorizations. These messages have no impact on the claims processing flow, regardless of severity.

Message Text and Placeholders

The message text can contain up to 10 placeholders. A placeholder is a part of the message text that cannot be determined during setup time. The actual values are derived when the message is generated. Consider the following example:

A system specific message has the following setup:

Table 5. Message Text and Placeholders
Code Sev Text

CUST-001

F

This claim line is an exact duplicate of claim {0}, line {1}.

Suppose claim line is checked for duplicates. {claimsComponent} finds a claim with the code C232 that has a claim line with code 23 that is an exact duplicate. {claimsComponent} knows that placeholder {0} should be the claim code and place holder {1} should be the claim line code. The messages that is then attached to the claim line that is checked, reads: "This claim line is an exact duplicate of claim C232, line 23."

In this scenario {claimsComponent} contains fixed logic that knows how to populate the message placeholders. Because the meaning and values of message placeholders are defined and derived differently depending on the way a message is attached, a more elaborate explanation is given in the next section.

A message is not required to use all available run-time values. In the event that a message text specifies a placeholder for which no run-time value is available when the message is generated, the message text simply displays an empty placeholder (that is as the message text appears during setup time).

The actual run-time value that a placeholder represents is identical for all text attributes (internal, external for provider and external for person or object). Placeholder values are not multi-lingual: a placeholder value does not change when the system language is changed.

The maximum length of each parameter is 60 characters. Longer values are truncated to 60 characters; if this happens, a warning is written to the O/S log file.

Formatting

At run-time, the placeholders are replaced by specific values. These are formatted and subsequently the formatted strings are inserted at the appropriate places.

The formatting is done in a locale-specific manner. Formatting values can be influenced by adding type information and formatting styles.

For example, the following message:

"At \{1,time} on \{1,date}, claim \{2} was processed and it was determined that \{0/amount including currency} will be paid to claimant \{3}."

given the following list of values (in the order that matches the identifiers for the parameters in the message):

  1. 100 $

  2. The current date, for example: November 10, 2010; 12:30 PM

  3. 123

  4. John Smith

using a US locale will be translated into:

"At 12:30 PM on Nov 10, 2010, claim 123 was processed and it was determined
that $100.00 will be paid to claimant John Smith."

If no type information or formatting style is specified, Claims uses locale-based defaults when appropriate. In the previous example, the date style was not specified. In that case, the locale-specific default date format is used. Other examples for formatting dates are listed in the following table:

Table 6. Formatting
Style Output

{1}, that is, no style

11/10/10 12:30 PM

\{1, date, long}

November 10, 2010

{claimsComponent} relies on formatting options of the Java programming language. For more detailed information see the technical documentation on message formatting and the Java tutorial pages on the subject.

Translating Messages

The message can be changed at will and may be translated in different languages. When translating messages, do not change the identifiers for the placeholders (these are "factory settings"). The following example is valid:

"Claim \{2} was processed at \{1,time} on \{1,date} and it was determined that
claimant \{3} will receive \{0/amount including currency}."

Attaching Messages and Populating Placeholders

The event of attaching a message to a claim, bill or claim line can be either driven by configurable or non-configurable processing logic within Claims. Additionally, a message can be attached through a number of integration points, or manually in the user interface. Messages on authorizations are only attached through the authorization integration point.

System-Specific Messages

Claims specifies which messages are attached due to non-configurable logic. These messages are part of the seed data of Claims. Consider the following examples of attaching a message driven by non-configurable logic:

During the processing of a claim line no coverage can be found. As a result, a fatal message is attached to the claim line, explaining that no coverage exists.

During the callout to the enrollment system, the enrollment replies that the serviced person or object is unknown. As a result, a fatal message is attached to the claim line, explaining that the person or object is unknown to the enrollment system.

The available run-time values and how they are distributed over the placeholders is determined by fixed internal logic of Claims. Note that, once attached, system specific messages cannot be removed from the claim, bill or claim lines, through the user interface.

Configurable Rules

A system administrator determines which custom messages are attached as a result of configurable rules. Consider the following scenarios:

The system administrator sets up a combination rule that detects duplicate claim lines. Part of that setup is specifying which message is applied to a claim line in case of a positive result.

The system administrator sets up a cover withhold rule. Part of that setup is (the option of) specifying which message is attached to a claim line if the cover withhold rule is applied.

The available run-time values and how they are distributed over the placeholders (0 through 9) is determined by fixed internal logic of Claims. This may be different per area in the setup, for example, different run time values are available for a combination rule message and cover withhold rule messages. In turn, the custom message setup determines how (and if) to make use of these available placeholders. Consider the following scenario:

A user intends to create a custom message that is attached to a claim line whenever that claim lines has an exact duplicate. Claims requires that this message is referred to in the setup of the combination rule that specifies this duplicate check.

Claims specifies that the following run-time values are available for combination rule messages:

  1. The code of the claim to which the detected claim line belongs

  2. The code of the detected claim line

The system administrator sets up a message with the text: "This claim line is an exact duplicate of claim {0}, line {1}." and refers to this message in the combination rule setup. A less elaborate but equally valid message text would be: "This line has an exact duplicate." in which no use is made of the available run-time values.

Generation through an Integration Point

It is possible that a custom message is attached through an integration point.

Consider the following scenarios.

Before a claim is imported into Claims, an upstream component in the claims processing flow detects something particular about the claim and needs to communicate that information to Oracle Health Insurance Claims, as it may affect the applied benefits and adjudication. More specifically, a pricing component detects that a claim line should be denied because it is included in a case rate associated with another claim line. This is resolved by attaching a fatal message to the claim line in the Claims in message sent to Oracle Health Insurance Claims.

At a certain point in the Claims processing flow, Claims sends out request for payment status information to another component. In the event that the other component has payment status information that possibly affects the claim adjudication, that component is expected to generate a response that contains a message, explaining the payment status of the person or object. Once Claims processes that response, that message is attached to all the claim lines for that person or object.

The available run-time values and how they are distributed over the placeholders is specified in the incoming integration point message. Consider the following fragment of an incoming enrollment data response:

<enrollmentDataResponse>
   ...
   <message
      code="OHI-002"
      parameter0="HP678678"
      parameter1="R. Johnson"
      parameter2="BestBuy"
   />
   ...
</enrollmentDateResponse>

The setup for message OHI-002:

Table 7. Generation through an Integration Point
Code Sev Text

OHI-002

F

The subscription status for person {0} ({1}) for product {2} is not yet final.

As a result, the message that is attached to the claim reads: "The subscription status for person HP678678 (R. Johnson) for the BestBuy product is not yet final."

Manual Attachment

Last, it is possible to attach a custom message in the Claims page. The most common scenario is that a message is attached to persist the outcome of manual adjudication. Consider the following scenarios.

A claim has been filtered for manual adjudication on account of a unusually high claimed amount. The operator that adjudicates the claim suspects fraud and manually attaches a fatal message that articulates the suspect fraud.

Once the operator is done, the claim is picked up again by the automated processing flow and is denied due to the attached fatal message.

It is not possible to populate run-time values in manually attached messages. If the message that is attached contains placeholders, they will not be replaced by values.