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 |
procedures |
access restriction |
payers |
access restriction (payer and brand) |
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 provider pricing clauses with or without the dependent fee schedules. Migrating with the fee schedules means that the fee schedules are also part of the migration payload; without means all references to fee schedules are migrated, but the fee schedule itself is not included in the payload. For this option to work, the fee schedule 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 |
claim form |
activity type |
dynamic field usage(1) |
- |
address type |
- |
- |
advice response definition |
- |
dynamic logic |
authorization form |
- |
- |
authorization regime |
authorization regime period |
dynamic logic |
basket |
basket detail |
- |
benefit specification |
benefit priority |
authorization regime |
boilerplate text |
- |
- |
bundled amount |
bundled amount category |
message |
callout definition (displayed as claim callout rule in the UI) |
claim callout rule |
classification scheme |
case definition |
ancillary inclusion rule |
diagnosis group |
charged amount |
charged amount classification |
dynamic logic |
claim event rule |
claim event rule form |
claim form |
claim form |
claim form type |
flex code system |
claim transaction event rule |
- |
dynamic logic |
classification scheme |
brand |
claim form |
combination check |
combination check claim form |
claim form |
contract reference |
- |
- |
country |
bank account validation |
dynamic logic |
country region |
country |
- |
country region group |
country region group detail |
country region |
coverage regime |
count towards limit |
limit (displayed as adjudication limit in the UI) |
covered service tier |
- |
- |
currency |
- |
- |
derivation rule |
derivation rule form |
claim form |
diagnosis group |
diagnosis group detail |
- |
diagnosis type |
- |
- |
diminishing rate |
currency |
message |
dynamic check |
dynamic check claim form |
claim form |
dynamic field usage (displayed as usage in the UI) |
dynamic logic |
- |
dynamic logic |
dynamic logic reference sheet |
reference sheet |
eligibility response definition |
callout rule |
dynamic logic |
episode definition |
episode category |
diagnosis group |
exchange rate |
currency |
- |
external intervention rule |
brand |
claim form |
fee schedule |
classification |
contract reference |
fee schedule line(4) |
classification |
contract reference |
financial hold type |
- |
- |
flex code group |
flex code group detail |
flex code system |
flex code system |
dynamic logic |
|
floorplan |
floorplan tag details |
|
gender identity |
- |
- |
geographic region |
geographic condition |
dynamic logic |
HTTP link |
- |
dynamic logic |
identifiers type |
access restriction |
|
insurable entity type |
- |
- |
limit (displayed as adjudication limit in the UI) |
limit |
dynamic logic |
line of business |
insurable entity type |
- |
location type |
claim form type |
- |
location type group |
location type group detail |
location type |
message |
- |
- |
message creation scenario |
- |
dynamic logic |
message group |
access restriction |
message |
modifier |
- |
- |
payment function |
reimbursement method type |
dynamic logic |
pend reason |
access restriction |
dynamic logic |
post benefits regime |
cover withhold category |
dynamic logic |
prefix |
- |
- |
pricing option |
- |
- |
pricing template |
pricing section |
pricing option |
procedure group |
procedure group detail |
- |
process field derivation rule |
process field derivation rule form |
claim form |
product |
brand |
authorization regime |
provider assignment type |
- |
- |
provider group |
provider group affiliation |
- |
provider pricing clause(6) |
adjustment execution phase |
bundled amount |
reference sheet |
dynamic field usage(9) |
- |
reservation regime |
coverage label |
dynamic logic |
service type |
- |
- |
settlement reason |
access restriction |
- |
specialty |
- |
- |
tag type |
tag type message |
message |
title |
- |
- |
transaction scenario |
- |
dynamic logic |
transaction source |
transaction source usage |
- |
unfinalize reason |
- |
- |
unfinalize reason group |
unfinalize reason group detail |
unfinalize reason |
waiting period regime |
- |
message |
waiver reason |
- |
- |
(1) An activity type can rely on a single dynamic field usage record that serves as an integral part of the activity type by connecting the parameter sets of the activity type to their definition. This dynamic field usage record is not visible in any user interface page, but is migrated as part of the activity type.
(2) Excluding coverage regimes will automatically exclude limits.
(3) Diminishing rate block amounts and sizes that are linked to a provider pricing clause are not included as dependent items of the diminishing rate. These are dependent items of the provider pricing clause.
(4) There is no checkbox (for adding/removing all items) available for top level item Fee Schedule Line. This top level item is meant for selective migration of fee schedule lines; migrating all fee schedule lines can be done by selecting all fee schedules.
(5) Excluding benefit specifications will automatically exclude the other optional excludes that belong to benefit specifications.
(6) Provider pricing clauses can be created by using drafts. Each clause is linked to the draft from which it is generated. Since the draft clauses are not within the scope of the migration function, the reference to the original draft is not migrated. In addition to the reference, the clause also stores information that identifies the draft clause in two character fields; these fields are migrated.
(7) Diminishing rate block amounts and sizes that are linked to a provider pricing clause are always in cluded as dependent items of the provider pricing clause, even when the provider pricing clause is migrated without the diminishing rate.
(8) Reference sheet lines that are linked to a provider pricing clause and draft provider pricing clause are not included as dependent items of the reference sheet. The reference sheet lines linked to a provider pricing clause are dependent items of that provider pricing clause.
(9) Each reference sheet relies on a single dynamic field usage record that serves as an integral part of the reference sheet by connecting the reference sheet to its definition. This dynamic field usage record is not visible in any user interface page, but is migrated as part of the reference sheet.
(10) The limits referenced by the sub limit are also included
Optional Excludes
Configuration rules in OHI Claims Adjudication are hierarchical in nature; complex configuration rules are a composite of more basic configuration rules. For example, a provider pricing clause is a composite of fee schedule, provider group and procedure group (and more). In turn, the fee schedule is a composite of dynamic logic, messages and procedure groups (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.
Provider pricing clause A refers to fee schedule B. In this context, fee schedule B is a dependent item to the provider pricing clause A; if provider pricing clause A is selected for migration, the user has the option to include all referenced fee schedules as part of that migration as well, including fee schedule B.
Because a fee schedule is also a top level item, the user can alternatively choose to migrate provider pricing clause A without migrating fee schedule B as well. This alternate approach requires that fee schedule B is already present on the target environment. This allows the user to have separate configuration tracks, for examplr, the updates to the provider pricing clauses using fee schedule B can be migrated before migrating the updates to fee schedule 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.