Introduction

Oracle Health Insurance provides a facility to express certain behaviour in an object-oriented language. These modules (code snippets) are invoked at particular predetermined moments, to attach Dynamic Logic modules. The language in which Dynamic Logic modules are written is Groovy. Groovy is a language which is closely related to Java. This manual will not elaborate on the programming language itself. There are many books and online resources available for this purpose, such as the official Groovy Language Documentation.

Testing

Dynamic Logic modules can be tested in an IDE (such as Eclipse), or on a web page (such as Groovy web console). However, it can be difficult to emulate the complete application’s behaviour in a stand-alone editor. Therefore, a full test should always take place during the application’s regular process.

For reference, and to support development/testing, the system can generate Groovy stub/mock classes for all of the application’s entities. This can be done from the View Objects page.

Subtypes

Three types of Dynamic Logic are distinguished: validations, conditions and functions. A validation operates on a single value and returns a boolean. A condition operates on one or more objects and returns a boolean. Finally, a function operates on one or more objects and may or may not return a value. These three types are explained in subsequent chapters.

All types of dynamic logic can embed a call to an external service. This call out is also explained in a separate chapter.

Signature

Each dynamic logic adheres to a specific signature. The signature describes both the functional usage (i.e. what is its purpose and when is it invoked?), and the technical usage (i.e. which input objects are available and what is the expected return value?). The following is a list of all existing signatures per type.

The following validation signatures exist:

  • Bank Account

  • Field

The following condition signatures exist:

  • Ancillary Inclusion Rule

  • Benefit Specification (Other)

  • Case Definition

  • Claim Callout Rule

  • Claim Event Rule (Claim)

  • Claim Event Rule (Claim Line)

  • Claim Transaction Event Rule (Claim)

  • Claim Transaction Event Rule (Claim Line)

  • Classification Scheme (Claim)

  • Classification Scheme (Detail)

  • Classification Scheme Detail (Authorization)

  • Classification Scheme Detail (Claim Line)

  • Combination Check (Condition)

  • Country

  • Diagnosis

  • Dynamic Check (Claim)

  • Dynamic Check (Claim Line)

  • Dynamic Field Usage (Allowed)

  • Dynamic Field Usage (Mandatory)

  • Eligibility Callout Rule

  • Eligibility Validation Rule

  • Episode

  • Episode Criteria

  • External Intervention Rule (Bill)

  • External Intervention Rule (Claim)

  • External Intervention Rule (Claim Line)

  • Fee Schedule

  • Geographic Region

  • HTTP Link

  • Pricing Rule (Other)

  • Procedure

  • Process Field Derivation Rule (Claim) (Condition)

  • Process Field Derivation Rule (Claim Line) (Condition)

  • Product Category

  • Provider Category

  • Provider Pricing Clause (Other)

  • Transaction Scenario

The following function signatures exist:

  • Adjustment Rule

  • Advice Response Definition

  • Aggregation Level

  • Authorization Matching*

  • Authorization Detail Matching*

  • Benefits Rounding

  • Callout Definition (Request Message)

  • Callout Definition (Response Message)

  • Case Definition (End Date) *

  • Case Definition (Start Date)

  • Claim Code Generation

  • Claim Event Rule (Claim Fields)

  • Claim Event Rule (Claim Line Fields)

  • Claim Line Code Generation

  • Claim Transaction Event Rule (Claim Fields)

  • Claim Transaction Event Rule (Request Message)

  • Combination Adjustment Rule

  • Combination Check *

  • Country Format

  • Coverage Label

  • Create Invoice

  • Create Invoice Line

  • Create Accounting Detail

  • Currency Conversion (Benefit)

  • Currency Conversion (Authorization)

  • Currency Conversion (Payment)

  • Derivation Rule (Bill)

  • Derivation Rule (Claim)

  • Derivation Rule (Claim Line)

  • Eligibility Callout Rule

  • Eligibility Validation Rule

  • Eligibility Response Definition

  • Episode (End Date) *

  • Episode (New Line)

  • Episode (Start Date)

  • Extension

  • Fee Schedule Line Duplicity

  • Fee Schedule Line Priority

  • HTTP Link

  • Name Format (Person)

  • Name Format (Individual Provider)

  • Payment Function

  • Pend Reason (Bill Fields)

  • Pend Reason (Claim Fields)

  • Pend Reason (Claim Line Fields)

  • Post Benefits Regime

  • Pricing Dynamic Field Rule (Bill)

  • Pricing Dynamic Field Rule (Claim)

  • Pricing Dynamic Field Rule (Claim Line)

  • Process Field Derivation Rule (Claim)

  • Process Field Derivation Rule (Claim Line)

  • Provider Code Generation

  • Provider Matching *

  • Relation Matching *

  • Replacement Rule

  • Reservation Line Matching

  • Reusable Code

  • Transaction Scenario (Bill)

  • Transaction Scenario (Claim)

  • Transaction Scenario (Claim Line)

  • Transaction Scenario (Financial Transaction)

  • Transaction Scenario (Financial Transaction Detail)

  • Transaction Scenario (Financial Transaction Change)

  • Transfer Claim Transaction (Bill)

  • Transfer Claim Transaction (Claim)

  • Transfer Claim Transaction (Claim Line)

  • URL Composition

For the functions marked with an asterisk a null is allowed as return value.

In-built Time Out

Writing Dynamic Logic incorrectly can impact performance and stability of the system. One of those specific implications concerns how to manage long-running processes or resource hogging by mal-formed units of dynamic logic. The framework plugs-in a TimedInterrupt in every dynamic logic. The value of the timeout is governed by two properties:

Property Name Data Type Default Value Description

ohi.dynamiclogic.timeout

integer

300

The global maximum time a unit of dynamic logic can run before the process monitor will interrupt the thread. The value is in seconds, and the default is 300 seconds.

ohi.dynamiclogic.timeout.<CODE>

integer

N/A

This is a dynamic property. <CODE> matches the code of the unit of dynamic logic, and will override the default time out for that unit of dynamic logic.

If the timeout expires, the system interrupts the dynamic logic and throws a timeout exception with code OHI-DYLO-008 and message "Dynamic Logic with code {code} timed out on line number {line number}: {exception message}"

Please note that when the dynamic logic timeout property is added/updated, the dynamic logic(s) need to be recompiled for the property change to take effect. This can be done by using the "Invalidate Dynamic Logic Integration Point" explained in the Developer Guide.

Considerations When Writing Dynamic Logic

Writing Dynamic Logic incorrectly can impact performance and stability of the system. This depends on the place where the logic is used. Is the logic only called in a background process, it may not be bad if the logic takes a few seconds to complete. If the logic is however used in UI pages, for example a dynamic field display condition, where it is called many times, a few seconds is not acceptable.

So when writing Dynamic Logic, make sure to:

  1. Understand the use case where the logic is going to be used to judge what is and is not acceptable.

  2. Avoid costly operations. Costly operations are :

    1. Logic that results in a database query. A database query involved network communication and processing on another machine, so this is the most expensive operation in general. Note that a domain method like policy.policyEnrollmentList() may result in a database query as well.

    2. Extensive looping over large number or objects.

  3. Carefully assess the impact of the logic on system performance and stability. This can be done by running a performance test with and without the new/changed logic in place.

  4. Test the script (in a test environment) with "timing.dynamicLogic" switched on (see below).

Enable Time Logging of Dynamic Logic Execution

This can be enabled using the log level "trace" for the logger "timing.dynamicLogic":

1

<logger name="timing.dynamicLogic" level="trace" />

Each dynamic logic execution will now be written to the application log files.

12

2018-08-02 12:05:02,234 …​ TRACE timing.dynamicLogic - NAFMDFLT 0.042289 ms2018-08-02 12:05:02,280 …​ TRACE timing.dynamicLogic - ORGDYNREC1 0.267327 ms
Only enable this in test or development environments, as this will impact performance.
See the Operations Guide for details about logging configuration