Creating a Migration Set
Migration sets are assembled through a dedicated user interface page. This page allows the user to select the top-level migration items that should be included in the set, and provides options on which dependent items to exclude.
The page is divided into two sections. The upper region shows the created configuration sets. Per set, a user has the option to include certain types of linked reference data. These options apply across the entire migration set, e.g., if the user opts to include agents, then all agents that are linked to one or more items in the data set are included.
Including Reference Data
The reference data inclusion option is restricted to records that are linked to the migrated configuration payload. For example, if the source environment has 100 agents, but only 60 of them are linked to the configuration in the payload, then only the 60 linked agents are migrated.
Reference Data | Automatically Includes |
---|---|
agents |
agent address |
brokers |
broker address |
providers |
individual provider:
organization provider:
|
If a migration set includes linked reference data, it also automatically includes any setup configuration that is required; there is no option to exclude the supporting configuration. For example, if an agent resides in a country (top level item) that has not been explicitly added to the migration set, then the configuration migration function will still add the country (to ensure a successful migration for that agent).
Including Configuration Items
The bottom region on the page shows which configuration items are included in the selected configuration set. This area allows a user to quickly include all products with or without the dependent products. Migrating with the products means that the products are also part of the migration payload; migrating without means all references to products are migrated, but the product itself is not included in the payload. For this option to work, the product must be present on the target environment prior to the migration.
The intended user for this page is the configuration expert, i.e., the same user that has made the configuration changes. This is the person who knows which changes are ready for migration, and which are not. It is important to note that creating and saving a migration set in this page does not make the igration set available for other environments to import; this is a separate step controlled through another page and most likely another user.
Below is the comprehensive list of configuration items that can be included, per individual record, in a configuration migration data set. Each entry mentions which dependent items are auto-included and which dependent items can be excluded as an option.
Top-Level Item | Automatically Includes | Optional Excludes |
---|---|---|
access role |
access restriction |
- |
activity type |
dynamic field usage [1]. |
- |
address type |
- |
- |
add-on |
add-on detail |
product |
boilerplate text |
- |
- |
brand |
- |
- |
bulk update definition |
- |
dynamic logic |
calculation period |
- |
- |
callout rule |
- |
dynamic logic |
capitation contract |
- |
- |
change event rule |
- |
dynamic logic |
collection method |
- |
- |
connector configuration |
dynamic logic |
dynamic logic |
country |
bank account validation |
dynamic logic |
country region |
country |
- |
currency |
- |
- |
covered service tier |
- |
- |
dynamic field usage (displayed as usage in the UI) |
dynamic logic |
- |
dynamic logic |
dynamic logic reference sheet |
reference sheet |
enrollment product |
add-on premium schedule |
add-on |
enrollment product type |
enrollment product category |
- |
enrollment type |
- |
- |
enrollment response definition |
- |
dynamic logic |
fee definition |
- |
dynamic logic |
fee schedule |
currency |
dynamic logic |
flex code group |
flex code detail |
- |
flex code system |
dynamic logic |
flex code group |
floor plan |
- |
|
gender identity |
- |
|
group client |
add-on |
collection method |
HTTP link |
- |
dynamic logic |
insurable class |
- |
- |
insurable entity type |
- |
- |
line of business |
insurable entity type |
- |
message |
- |
- |
message group |
message group detail |
message |
output definition |
- |
dynamic logic |
parameter alias |
- |
- |
pend reason |
- |
- |
pend rule |
brand |
dynamic logic |
policy account definition |
- |
- |
policy account transaction type |
- |
- |
prefix |
- |
- |
premium schedule |
currency |
dynamic logic |
premium tier |
enrollment type |
|
process step [2] |
access restriction |
callout rule |
product |
- |
- |
product covered service |
- |
- |
provider assignment type |
- |
- |
provider group |
provider group affiliation |
- |
reference sheet |
dynamic field usage [3] |
- |
schedule definition |
adjustment rule |
add-on |
specialty |
- |
- |
title |
- |
- |
user sequence [4] |
- |
- |
validation rule [5] |
- |
dynamic logic |
waiver reason |
- |
- |
Optional Excludes
Configuration rules in OHI Enterprise Policy Administration are hierarchical in nature; complex configuration rules are a composite of more basic configuration rules. For example, a process step is a composite of any combination of callout, event, pend and validation rules. In turn, the pend rule is a composite of dynamic logic and message group (and more) as well.
To assist the user in assembling a migration payload, the migration function automatically determines what other configuration is required to successfully install the selected configuration item on the target environment. The exclude options allow the user to carve out configuration records from that automatic inclusion. Consider the following example to clarify.
Enrollment product A refers to premium schedule B. In this context, premium schedule B is a dependent item to enrollment product A. If enrollment product A is selected for migration, the user has the option to include the referenced premium schedule as part of that migration as well.
Because an enrollment product is also a top-level item, the user can alternatively choose to migrate enrollment product A without migrating premium schedules as well. This alternate approach requires that premium schedule B is already present on the target environment. This allows the user to have separate configuration tracks, e.g., the updates to the enrollment product using premium schedule B can be migrated before migrating the updates to premium schedules itself.
Dynamic Field and Record Usages
Configuration items can be extended with dynamic fields and records. If an extended item is included in the payload, the dynamic field and record values and the related dynamic field usages are automatically included as well. The target environment requires the dynamic field usages in order to know where it can find and update the dynamic field values.