Product Building Blocks Integration Point
Several entities have their system of record in OHI Claims Adjudication and Pricing but are used as product building blocks in Oracle Health Insurance Product Definition. To synchronize these building blocks between these two applications an integration point is provided. The following building blocks are exported from OHI Claims Adjudication and Pricing and then imported into Oracle Health Insurance Product Definition:
-
Authorization Regimes
-
Brands
-
Case Definitions
-
Claim Form Types
-
Conditions
-
Country Regions
-
Cover Withhold Categories
-
Coverage Regimes
-
Diagnosis Groups
-
Diagnosis Types
-
Limits
-
Location Types
-
Modifiers
-
Post Benefits Regimes
-
Procedure Groups
-
Provider Groups
-
Reservation Regimes
-
Specialties
-
Waiting Period Regimes
Request
This section describes the content of the dataset which is created on the source application in UI. On the target application, UI queries the source application for any datasets available for the target to import and then starts import. Once UI submits a request to start import, the data is imported from source into the target application. The structure of the dataset which is imported is as follows:
<dataset> <transactionSourceCode code="XYZ"/> <executionRank rank="1"> <content><claimFormType/></content> <content><coverWithholdCategory/></content> </executionRank> <executionRank rank="2"> <content><authorizationRegime/></content> <content><brand/></content> <content><caseDefinition/></content> <content><condition/></content> <content><countryRegion/></content> <content><coverageRegime/></content> <content><diagnosisGroup/></content> <content><diagnosisType/></content> <content><limit/></content> <content><locationType/></content> <content><modifier/></content> <content><modifier/></content> <content><procedureGroup/></content> <content><providerGroup/></content> <content><reservationRegime/></content> <content><specialty/></content> <content><waitingPeriodRegime/></content> </executionRank> </dataset>
The <dataset> root element captures one or more <item> elements. Items are ordered using <executionRank> elements, such that dependent items can be processed in the correct order. All items can be one of the building blocks. The type of the building block is referred in the type of the item, which is itself an enumeration of the following values:
-
AUTHORIZATION_REGIME
-
BRAND
-
CASE_DEFINITION
-
CLAIM_FORM_TYPE
-
CONDITION
-
COUNTRY_REGION
-
COVER_WITHHOLD_CATEGORY
-
COVERAGE_REGIME
-
DIAGNOSIS_GROUP
-
DIAGNOSIS_TYPE
-
LIMIT
-
LOCATION_TYPE
-
MODIFIER
-
POST_BENEFITS_REGIME
-
PROCEDURE_GROUP
-
PROVIDER_GROUP
-
RESERVATION_REGIME
-
SPECIALTY
-
WAITING_PERIOD_REGIME
The following part describes for each building block which attributes are present.
Authorization Regime
Authorization regimes are used to indicate specific charge thresholds before an authorization is required, for example, an authorization is only required after the 10th office visit within a calendar year.
<content> <authorizationRegime uuid code description indActive /> ... />
Each element contains a UUID (required), a code (required), a description (required) and an indicator that states if the authorization regime is active (required).
Brand
A brand is a commercial label placed on a product. This section describes the content of the request message that contains brands.
<content> <brand uuid code description indActive
Each <brand> element captures a UUID (required), the code of the brand (required), the description of the brand (required) and an indicator that states if the brand is active (required).
Case Definition
A case definition specifies the criteria by which a new case can be identified as well as closed. A case is essentially a bundling of related claim lines that do not necessarily belong to the same claim. This section describes the content of the request message that contains case definitions.
<content> <caseDefinition uuid code description indActive
Each <caseDefinition> element captures a UUID (required), the code of the case definition (required), the description of the case definition (required) and an indicator that states if the case definition is active (required).
Claim Form Type
Claim form types are used to designate a set of forms that have a common structure. For example, both the claim form 837I and UB04 are of the type "Institutional".
<content> <claimFormType uuid code displayName
Each <claimFormType> element captures a UUID (required), the code of the claims form type (required) and the display name of the claim form type (required) .
Condition
Conditions are a type of user configurable logic where one or more objects are used as input with a result that is either true or false. Three different types of dynamic logic conditions can be attached to a benefit specification. The dynamic logic with the signature 'Benefit specification (Other)' is created and maintained in OHI Claims Adjudication and Pricing. The product building blocks integration point allows the conditions with the signature 'Benefit specification (Other)' to be imported into Oracle Health Insurance Product Definition. This section describes the content of the request message that contains conditions.
<content> <condition uuid code description logic indActive
Each <condition> element captures a UUID (required), the code of the condition (required), the description of the condition (required), the logic that is configured for the condition (required) and an indicator that states if the condition is active (required). The signature is always 'Benefit specification (Other)' for imported conditions.
Country Region
Country regions are officially recognized subdivisions of countries like you can find in geography books such as provinces and states. This section describes the content of the request message that contains country regions.
<content> <countryRegion uuid code countryCode displayCode indActive
Each <countryRegion> element captures a UUID (required), the code of the country region (required), the code of the country (required), the display code of the country region (required) and an indicator that states if the country region is active (required).
Cover Withhold Category
Cover withhold categories consist of labels assigned to covered and not covered amounts. They are used in Oracle Health Insurance Product Definition to create accumulation rules and as a reference for parameter aliases and values.
<content> <coverWithholdCategory uuid code
Each <coverWithholdCategory> element captures a UUID (required) and the code of the cover withhold category (required). When importing cover withhold categories into Product Definition, the display name is set to the code as a default and can be updated through the UI.
Coverage Regime
In OHI Claims Adjudication and Pricing, a coverage regime specifies the extent to which the allowed amount for a claimed health care service is paid for by the health care payer. The system of record for coverage regimes is OHI Claims Adjudication and Pricing. Coverage regimes are imported into Oracle Health Insurance Product Definition as building blocks used when configuring benefits. Oracle Health Insurance Product Definition does not import computation rules and steering features of regimes, only the code, description and active indicator of the regimes and the cover withhold categories used in the coverage regime. The integration point imports coverage regimes and their parameters as well as authorization regimes and waiting period regimes to be used by OHI Product Definition. The parameters map to the distinct set of cover withhold categories under a coverage regime in OHI Claims Adjudication and Pricing.
This section describes the content of the request message that contains coverage regimes.
<content> <coverageRegime uuid code description indActive > <coverageRegimeParameters <coverageRegimeParameter coverWithholdCategoryCode /> ... /> ... />
Each <coverageRegime> element contains a UUID (required), the code of the coverage regime (required), the description of the coverage regime (required), an indicator that states if the coverage regime is active (required) and one <coverageRegimeParameters> element (required).
Each <coverageRegimeParameters> element contains zero, one or more <coverageRegimeParameter> elements, each containing the code of a cover withhold category (required)
If zero <coverageRegimeParameter> elements are present, then the coverage regime does not have any cover withhold rules defined.
For every coverage regime the import also creates the coverage regime parameters. These are records in the COVERAGE REGIME PARAMETER entity referencing the coverage regime and one of the cover withhold categories present in the <coverageRegimeParameters> element.
Diagnosis Group
Diagnosis groups are bundled diagnoses to signify a group that can become part of a specific benefit specification. In Oracle Health Insurance Product Definition a diagnosis group only contains a code and a description as opposed to OHI Claims Adjudication and Pricing where the contents of the diagnosis group are stored (the list of diagnosis group details). This section describes the content of the request message that contains diagnosis groups.
<content> <diagnosisGroup uuid code description
Each <diagnosisGroup> element captures a UUID (required), the code of the diagnosis group (required) and the description of the diagnosis group (required).
Diagnosis Type
Diagnosis types are used to specify the type of diagnoses, as may be specified on claims, claim lines and/or bills.
<content> <diagnosisType uuid code description
Each element contains a UUID (required), a code (required), and a description (required).
Limit
Limits are used in Oracle Health Insurance Product Definition to create accumulation rules and to connect the parameter value for the maximum amount, days or units to that limit.
<content> <limit uuid code description displayName type
Each element contains a UUID (required), a code (required), a description (required), a display name (required) and a type (required).
Location Type
Location types are used to specify the type of facility or place of service in which a particular benefit applies (or does not apply).
<content> <locationType uuid code claimFormTypeCode description indActive
Each <locationType> element captures a UUID (required), the code of the location type (required), the code of the claim form type that is referenced by the location type (optional), the description of the location type (required) and an indicator that states if the location type is active (required).
Modifier
Modifiers are a further specification of a service code and are typically used to recognize a generic service code as belonging to a specific type of care.
<content> <modifier uuid code description indActive
Each <modifier> element captures a UUID (required), the code (required), the description (required) and an indicator that states if the modifier is active (required).
Post Benefits Regime
Post benefits regimes are used to specifiy what cover withhold rules should be applied after the evaluation of waiting period, authorization and coverage regimes.
<content> <postBenefitsRegime uuid code description indActive /> ... />
Each element contains a UUID (required), a code (required), a description (required) and an indicator that states if the post benefits regime is active (required).
Procedure Group
Procedure groups are bundled procedures to signify a group that can become part of a specific benefit specification. In Oracle Health Insurance Product Definition a procedure group only contains a code and a description as opposed to OHI Claims Adjudication and Pricing where the contents of the procedure group are stored (the list of procedure group details). This section describes the content of the request message that contains procedure groups.
<content> <procedureGroup uuid code description
Each <procedureGroup> element captures a UUID (required), the code of the procedure group (required) and the description of the procedure group (required).
Provider Group
Provider groups (or 'Networks' in the U.S.A.) are groups of medical service providers that are used as a part of a product or benefit specification in Oracle Health Insurance Product Definition to signify if a group of providers is eligible for that product or specific benefit specification. In Oracle Health Insurance Product Definition a provider group only contains a code, a description and an active indicator as opposed to OHI Claims Adjudication and Pricing where the contents of the provider group are stored (the list of individual and organization providers associated with the group). This section describes the content of the request message that contains provider groups.
<content> <providerGroup uuid code description indActive
Each <providerGroup> element captures a UUID (required), the code of the provider group (required), the description of the provider group (required) and an indicator that states if the provider group is active (required).
Reservation Regime
Reservation regimes are used to indicate when a reservation is required, for example, a reservation is required for a specific services within a product.
<content> <reservationRegime uuid code description indActive /> ... />
Each element contains a UUID (required), a code (required), a description (required) and an indicator that states if the reservation regime is active (required).
Specialty
Specialties are typically used to recognize a generic service code as belonging to a specific type of care.
<content> <specialty uuid code description indActive
Each <specialty> element captures a UUID (required), the code (required), the description (required) and an indicator that states if the specialty is active (required).
Waiting Period Regime
Waiting period regimes are used to set up qualification periods for specific services withing a product.
<content> <waitingPeriodRegime uuid code description indActive /> ... />
Each element contains a UUID (required), a code (required), a description (required) and an indicator that states if the waiting period regime is active (required).
Processing
Each building block is processed independently. If the UUID of a building block does not exist in the Oracle Health Insurance Product Definition database a new record is created. If the request message contains a UUID that already exists for the same type of building block in the Oracle Health Insurance Product Definition database the record is overwritten.
The integration point does not accommodate the deletion of building blocks. The correct usage of building blocks is to set the active indicator to unchecked in OHI Claims Adjudication and Pricing and to import this into Oracle Health Insurance Product Definition. The absence of a building block in the import that is present in Oracle Health Insurance Product Definition will not lead to any action; the indicator active will not be set in Oracle Health Insurance Product Definition, the element in Oracle Health Insurance Product Definition will not be deleted. And for regimes the IP will not remove any parameter aliases that it no longer uses.
If a building block update is received where the active indicator is set to FALSE any details present are not processed. Only the active indicator and the description are updated and, for example, changes to the coverage regime parameters are not stored in OHI Product Definition. If the building block is reactivated by a subsequent import the attributes and details are processed as normal.
Response
There is no response of this integration point as it is triggered by UI. The result and the error messages (if any) can be viewed in the View Progress page of the import on the UI. This integration point can generate the following messages:
Code | Sev | Message |
---|---|---|
PRD-IP-PRBB-001 |
Fatal |
The coverage regime {0} specifies an unknown cover withhold category {1} |
PRD-IP-PRBB-002 |
Fatal |
The location type {0} specifies an unknown claim form type {1} |
PRD-IP-PRBB-003 |
Fatal |
The country region {0} specifies an unknown country {1} |
If such an entity error occurs during processing, that specific error is passed along as if it originated from the product building blocks integration point. Any errors that occur during the processing are persisted in a log.