Migration Behavior

The migration function creates, updates and deletes configuration. To do this, the migration function has to recognize the same configuration item across environments. Finding the existing counterpart of a configuration item in the migration payload is referred to as matching.

Matching top level items is a two-pass process. The first pass attempts to match the universally unique identifier (UUID) of the item in the migration set to an existing item on the target environment. The UUID is a system generated key, that is assigned to each configuration item upon creation, unless created through a migration. If the item is created through a migration the UUID of the item in the migration payload is adopted. This ensures that the UUID for the same configuration item is the same across all environments, as long as the migration function is the only means of creating new configuration items on target environments. If the function succeeds in finding an existing configuration item with the same UUID, then that item is updated.

If the UUID match fails, the second pass attempts to match on a functional key. For most configuration items the "Code" field is the functional key. This means that if the item in the migration payload has the same code as an item in the target environment then it is considered a match. Some configuration items have a more elaborate functional key, because they do not have a code, for example, an assigned premium schedule. For these items the secondary match is based on a combination of functional attributes.

The reason for the two-pass approach is that neither UUID matching, nor functional key matching is foolproof; matching exclusively on UUID fails if the same configuration already exists on the target environment (inserted by means other than migration), matching exclusively on the functional key fails when (part of) the key is updated on either environment. The two-pass approach counters these drawbacks - it gives robustness against updates of key fields and the ability to identify the same configuration items across environments.

Some functional keys comprise language dependent fields. The functional keys in the migration set are the keys in context of the default language on the source environment. Upon import, language dependent functional keys are interpreted in context of the default language of the target environment.

If neither the UUID nor the functional key matches, the migration import function inserts the configuration item on the target environment. If matched successfully, then all functional attributes of the existing item are updated with the value provided in the migration payload. Any existing detail matched with a detail in the migration set is updated. Details in the migration payload that do not exist on the target environment are inserted.

If the migration set does not specify an inclusion date, then any existing detail that is not matched, is deleted.

Because most details are matched on UUID alone, updates to those details that have not been created by a prior migration follow a replacement pattern (that is as opposed to an 'update' pattern). This is illustrated in scenario 1; the classification scheme detail referring to DYNA3 has been keyed in on both the source and target environment.

If an item (top level or detail) is matched on functional key then the existing item adopts the UUID in the migration payload.

Configuration Linked to Operational Data

If an item (top level or detail) is matched on functional key then the existing item adopts the UUID in the migration payload.

Items Matched on UUID and Functional Key

The following items are matched on both UUID and functional key.

Table 1. Items Matched on UUID and Functional Key

Access restriction Access role Add on Address type Assigned provider group label Bank Bank account validation Boilerplate text Brand Bulk update definition Business event definition Notification definition Business event rule Calculation period Callout rule Capitation contract Change event rule Collection Method Country Country region Connector Configuration Covered service tier Currency Data access group Dynamic logic Enrollment product Enrollment product category

Enrollment product type Enrollment response definition Enrollment type Excluded attribute Fee definition Fee schedule Field Flex code group Flex code system Floorplan Floorplan tag detail Gender identity Group account Group client Group client billing account Group client validation rule Insurable class Insurable entity type Insurance type Line of business Marital status type Message Medicare disenrollment reasons Medicare SEP reasons Medicare OEC SEP codes Never in force reason

Output definition Organization Parameter alias Pend reason Pend rule Policy account definition Policy account transaction type Policy identifier type Policy validation rule Prefix Premium schedule Premium schedule type Premium tier Process flow Product Provider assignment type Provider group Reference sheet Relation link type Reinsurance treaty Reinsurance treaty type Schedule definition Specialty Title User sequence Waiver reason

Most top level items have a single attribute that is the designated functional key, that is the code, name or start date of the item.

The following items are matched on both their UUID and functional key as well, but are exceptional in that they use a set of attributes serving as a composite functional key, rather than a single field.

Table 2. Matched on Both their UUID and Functional Key

Item	Functional Key
Activity type	Code and level
Bill receiver	Premium bill allocation, dynamic logic, and group client billing account
Broker Agent Switch Rule	Group account and start date
Default time period	Display name
Dynamic field usage	Usage name and table
Enrollment product add-on	Enrollment product and add-on
Enrollment product adjustment	Enrollment product, schedule definition, and start date
Enrollment product premium schedule	Enrollment product, premium schedule, and start date
Enrollment product provider group	Enrollment product, provider group, assigned provider group label, and start date
Enrollment product time period	Enrollment product and display name
Exchange rate	Currency from, currency to, context and start date
Excluded attribute	Subject
Flex code	Key value and flex code definition
Flex code field usage	Column name and flex code definition
Flex code set detail	Flex code set and flex code definition
Floorplan Tag Detail	Tag and Floorplan
Group account adjustment	Group account, enrollment product category, schedule definition, and start date
Group account broker agent	Group account, enrollment product category, and start date
Group account collection setting	Group account and start date
Group account premium schedule	Group account, enrollment product category, premium schedule and start date
Group account product	Group account and enrollment product
Group account product adjustment	Group account product, schedule definition, and start date
Group account product premium schedule	Group account product, premium schedule, and start date
Group account product provider group	Group account product, provider group, assigned provider group label, and start date
Group account time period	Group account and display name
Parameter set	Activity type and code
Group client adjustment	Group client, enrollment product category, enrollment product, schedule definition, and start date
Group client broker agent	Group client, enrollment product category, and start date
Group client collection setting	Group client and start date
Group client premium schedule	Group client, enrollment product category, enrollment product, premium schedule, and start date
Group commission rate	Group client, group account, enrollment product category, enrollment product, broker, agent, and start date
Medicare Plan Listing	CMS contract number, plan benefit package ID, segment ID, and start date
Medicare Plan CSNP Condition	Medicare plan listing and CSNP condition
Premium bill allocation	Group client, group account, insurable class, schedule definition, premium schedule type, enrollment product, enrollment product category, add-on, and start date
Process Step	Process flow, display name, and subtype
Product Covered Service	Product, covered service tier, covered service type, service code, and start date
Provider group affiliation	Provider group, provider, and start date
Reference sheet line [1]	Reference sheet, key, and start date
Reinsurance exclusion	Reinsurance setting, premium schedule type, and schedule definition
Reinsurance setting	Enrollment product type, organization, alias code, and start date
Schedule dimension	Schedule definition and field name

Items Matched on UUID Alone

The following objects are always integral to another object and cannot exist standalone. These are typically intersection objects without a functional key - they are matched only on UUID.

Table 3. Items Matched on UUID Alone

Access restriction grant Add-on detail Adjustment rule Adjustment sequence Agent address Broker address Default adjustment value Dynamic logic reference sheet Enrollment product adjustment value Enrollment product account definition Enrollment product detail Fee schedule line Group account add-on

Group account product adjustment value Group account available product Group account available product add-on Group account insurable class Line of business insurable entity type Parameter domain Parameter domain value Premium schedule line Premium tier enrollment type Rule step Schedule dimension value Surcharge rule

Items Matched on Functional Key Alone

The following items cannot be added to a migration set but may be referenced by items that can be. These items never match on UUID because they are seeded or because they are not considered configuration.

Table 4. Items Matched on Functional Key Alone

Item
Language Signature

The following items are matched on functional key alone as well, but are exceptional in that they use a set of attributes serving as a composite functional key, rather than a single field.

Item	Functional Key
Address	Relation (organization), type, and start date
Bank account number	Relation (organization), account number, bank, and start date

Delete by Omission

The following configuration items depend on top level items - they cannot exist by themselves. The configuration import function treats these just like other attributes on the top level item; if not present in the payload, that means these items have been removed on the source environment and therefore can be deleted in the target environment as well.

Note that the 'High Volume' configuration items (see Building a Configuration Migration Set) are not deleted on the target environment if the configuration set specifies an inclusion date. The reason is that the target environment is not able to distinguish between records that are omitted from the set because they are deleted or because they have not been updated since the inclusion date.

Table 5. Delete by Omission

Access restriction grant Address Add-on detail Adjustment rule Agent address Bank account number Bank account validation Bill receiver Broker address Broker agent switch rule Default adjustment value Enrollment product account definition Enrollment product add-on Enrollment product adjustment Enrollment product adjustment value Enrollment product detail Enrollment product premium schedule Enrollment product provider group Enrollment product time period Fee schedule line Flex code Flex code field usage Floorplan tag details Group account Group account add-on Group account adjustment Group account available product Group account available product add-on Group account broker agent Group account collection setting Group account insurable class Group account premium schedule Group account product

Group account product adjustment Group account product adjustment value Group account product premium schedule Group account product provider group Group account time period Group client adjustment Group client billing account Group client broker agent Group client collection setting Group client premium schedule Group commission rate Macro Definition Medicare plan CSNP conditions Medicare disenrollment reasons Medicare SEP seasons Medicare OEC SEP codes Parameter set Parameter domain Parameter domain value Premium bill allocation Premium schedule line Premium tier enrollment type Product covered service Provider group affiliation Reference sheet line Reinsurance exclusion Reinsurance setting Reinsurance treaty reinsurer Reinsurance treaty premium scope Reinsurance treaty benefit scope Reinsurance treaty enrollment scope Rule step Schedule dimension Schedule dimension value Surcharge rule

Switching Off Delete by Omission

The ‘delete by omission’ behavior is enabled by default. The user can override this behavior either when creating a new migration set in the source environment or when importing a migration set in the target environment. This behavior applies across all entities in the migration set; either all dependent items are deleted by omission or none of them are.

If the user overrides the behavior upon generation of the migration set, then the payload is marked so that the target system knows not to delete by omission. If the user specifies the desired delete behavior upon importing a migration set, then the import ignores the whatever instructions are included in the payload.

To clarify this feature, consider the image above. The default system behavior removes item 7870 but if the user disables the ‘delete by omission’ feature then item 7870 remains unaffected.

Exclude Options

The Exclude option allows the user to carve out a specific group of dependent items within the context of the top level item. This carve out applies to the top level item itself as well as to all dependent items, dependents of those dependent items, and so on.

Example

If the user chooses to exclude dynamic logic within the context of the top level item 'process steps' then the payload will not contain the dynamic logic records referenced by the event rules included as dependent items of the process step.

Exclude options apply only within the top level object that they belong to. To clarify, consider a scenario where the payload contains two schedule definitions. The first schedule definition (S1) has not been excluded as a dependent of a premium schedule and is therefore subject to all other exclude options specified for premium schedules. So if dynamic logic is excluded within the context of premium schedules, none of the dynamic logic records used by S1 are in the payload. The second schedule definition (S2) was selected as a top level item with none of the exclude options checked. Therefore, the payload includes all dynamic logic records that are used by S2.

Multiple Languages

It is possible to install an Oracle Health Insurance application with multiple languages. A configuration item will have a representation for each of the installed languages. When creating a migration set, each of those representations is automatically included; there are no options to exclude a particular language.

In the scenario where the source and target environment do not have the same languages installed, the following happens upon importing the migration set: the configuration item representations of any language that is not installed on the target environment are ignored; the existing configuration items representations of a language that is not in the migration set is left untouched.

For example, suppose the target environment supports both Spanish and English and the source environment supports only English. In this scenario, only the English language specific fields will be updated on the target environment.

Business Rules

Business rules protect the configuration consistency and remain active during migration. When a piece of configuration is updated, it will automatically be re-validated against its business rules. Because some business rules are controlled by set-up, it is possible for configuration to be out of sync with its governing business rules. In other words, changing a business rule does not automatically re-validate existing data. If a source environment has such inconsistencies, a migration may lead to unexpected business rule violations.

For example, consider the scenario where - on the source environment - a new mandatory dynamic text field is added to the messages table (OHI_MESSAGES). When this new field is set up, none of the existing messages will have a value; the existing messages are in conflict with the new set-up. It is only when updating an existing message or add a new message that the system requires the user to enter a value for the mandatory dynamic field. When the existing messages are migrated, they will run into that same violation on the target environment.

Oracle Health Insurance Specific Configuration

Oracle Health Insurance specific configuration is seeded configuration that cannot be removed or inserted by the users of the application. It is possible to update specific fields on Oracle Health Insurance specific configuration, so for that reason Oracle Health Insurance specific configuration can be included in the migration payload. The migration import function never inserts or deletes Oracle Health Insurance specific configuration. Messages are the primary example of Oracle Health Insurance specific configuration.

Default Indicators

Some configuration item have a default indicator, meaning that within its context - the configuration item is applicable unless specifically specified otherwise. Examples are the default country (when creating a new address), and the default bank account validation (when creating a new bank account. The default indicator is always complemented by a system rule that make sure that there is only a single default item of its kind, e.g., there can be only one default country. Such a system rule applies across the set of configuration items, rather than on a single item. For this reason, configuration settings like the default indicator cannot be updated through the configuration migration function.

---

1. If the reference sheet record definition does not specify any key fields, the reference sheet lines belonging to that reference sheet are not matched on composite functional key, but only on UUID.