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, the user has the option to include certain types of linked reference data. These options apply across the entire migration set, for example if the user opts to include providers, then all providers 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 1000 providers, but only 600 of them are linked to the configuration in the payload, then only the 600 linked providers are migrated.
| Reference Data | Automatically Includes |
|---|---|
diagnoses |
access restriction diagnosis setting |
procedures |
access restriction procedure setting |
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 a provider has a specialty (top level item) that has not been explicitly added to the migration set, then the configuration migration function will still add the specialty (to ensure a successful migration for that provider).
Including Configuration Items
The bottom region on the page shows which configuration items are available for migration. This area allows a user to quickly include all records for a particular top level item or even all records for all top level items, that is, a full configuration migration, through selection check boxes. Alternatively, a user can add or remove individual records of specific items to and from the set by clicking on the pencil icon. The icon opens a dialog for that specific item that allows the user to browse, select and deselect the available items on the environment.
Per top level configuration item, the user has the option to exclude specific dependent items. For example, the user has the option to migrate process steps with or without the dependent event rules. Migrating with the event rules means that the event rules are also part of the migration payload; without means all references to event rules are migrated, but the event rule itself is not included in the payload. For this option to work, the event rule must be present on the target environment prior to the migration.
The intended user for this page is the configuration expert, that is 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 migration 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 access restriction grant data access group |
- |
address type |
- |
- |
authorization form |
line of business |
- |
basket |
basket detail currency |
- |
boilerplate text |
line of business |
- |
country |
- |
dynamic logic |
country region |
country |
- |
currency |
- |
- |
diagnosis group |
diagnosis group detail |
- |
dynamic field usage (displayed as usage in the UI) |
dynamic logic field flex code system message |
- |
dynamic logic |
dynamic logic reference sheet message |
reference sheet |
flex code group |
flex code detail |
- |
flex code system |
dynamic logic field flex code flex code field usage flex code set detail flex code system message |
- |
HTTP link |
- |
dynamic logic |
insurable entity type |
- |
- |
line of business |
insurable entity type line of business insurable entity type |
- |
message |
- |
- |
message group |
message group detail |
message |
pend reason |
- |
dynamic logic |
prefix |
- |
- |
process step |
access restriction brand rule step callout rule event rule pend rule validation rule |
authorization form diagnosis group dynamic logic message message group pend reason procedure group service type |
procedure group |
procedure group detail |
- |
product |
brand currency funding arrangement product family product line |
- |
reference sheet |
dynamic field usage[1] reference sheet line |
- |
service type |
- |
- |
specialty |
- |
- |
title |
- |
- |
unfinalize reason |
- |
- |
Optional Excludes
Configuration rules in Oracle Health Insurance Authorizations 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.
Process step A refers to pend rule B. In this context, pend rule B is a dependent item to the process step A and dynamic logic C is a dependent item to the pend rule B; if process step A is selected for migration, all referenced pend rules and dynamic logic items are part of that migration as well, including pend rule B and dynamic logic C.
Because dynamic logic is also a top level item, the user can alternatively choose to migrate process step A without migrating dynamic logic C as well. This alternate approach requires that dynamic logic C is already present on the target environment. This allows the user to have separate configuration tracks, for example, the updates to the process steps using dynamic logic C can be migrated before migrating the updates to the dynamic logic 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.