Product Export
This chapter describes the function that generates the product export payload. This function is triggered by a user selecting an available data set and clicking the "Build" button in the Outbound Data Sets page. The function can only be triggered if all products in the set have the status Test or Approved. The result of this function is an XML file that is structured as follows:
<productBenefitSpecRequest transactionSourceCode > <countryRegionGroups/> <benefitPriorities/> <benefitSpecifications/> <products/> <replaceProductBenefitSpecifications/> </productBenefitSpecRequest>
The export file contains one or more products, dependent on the selected product export set. All common configuration items are included only once.
Select Benefit Specifications
The first step is to assemble a list of all benefit specifications that are to be included in the export. This list stores the session in which it is invoked, in order to prevent conflicts if multiple exports are initiated at the same time by different users. Envision this list as a table with the following columns:
Benefit Specification List
| Column | Description |
|---|---|
Benefit Specification |
Unique ID for a benefit specification |
Start Date |
The start date used when assembling product benefit specifications |
End Date |
The end date used when assembling product benefit specifications |
Product |
Unique ID for a product |
The list is appended by including all benefit specifications attached to the product. For each product included in the export:
Product > Product Benefit Specification > Benefit > Specification
The start and end date in the list are derived from the product benefit specification.
The resulting assembled list will serve as the starting point for generating the export file. The following sections refer to this list as the USED BENEFIT SPECIFICATIONS list. The next step is to generate the country region groups, as these are prerequisite for generating the executable products.
Building the Payload
Country Region Groups
Select the distinct set of country region groups that are used in a benefit specification in the USED BENEFIT SPECIFICATIONS list.
Note that each benefit specification can specify up to three different country region groups. The resulting list is the distinct set of country regions groups that are included in the export. If the country region group contains no country regions the <countryRegionGroupDetails> element is included without any <countryRegionGroupDetail> elements.
The result is written to the export file as a county region group as follows:
<countryRegionGroups>
<countryRegionGroup
elementId
uuid // UUID of the country region group
code
description
>
<countryRegionGroupDetails>
<countryRegionGroupDetail
countryRegionCode
countryCode
/>
</countryRegionGroupDetails>
</countryRegionGroup>
</countryRegionGroups>
Benefit Priorities
Select the distinct set of benefit priorities that are used in a benefit specification in the USED BENEFIT SPECIFICATIONS list, excluding benefit priorities pointing to a service definition priority with reference only indicator checked.
The resulting list is the distinct set of benefit priorities that are included in the export. The result is written to the export file as a benefit priority as follows:
<benefitPriorities>
<benefitPriority
elementId
uuid // UUID of the benefit priority
code
displayName
priority
/>
</benefitPriorities>
Benefit Specifications
To determine the benefit specifications, select the distinct set of benefit specifications that are listed in the USED BENEFIT SPECIFICATIONS list. The resulting benefit specifications are added to the export set.
If the benefit specification has no benefit specification conditions the <conditions> element is included without any <condition> elements. The same behavior applies to the <locationTypes>, <specialties>, <modifiers> and <providerGroups>.
Any conditions with the signature "Benefit Specification (other)" with their indicator universal set to yes have their code added as a <condition> to each benefit specification. If the condition is already added because it was added as a benefit specification condition it is not added twice.
The attribute servceOptionServiceCode is set to the concatenation of the short codes for the service option and the service out of which the benefit specification is generated.
The result is written to the export file as a benefit specification as follows:
<benefitSpecifications>
<benefitSpecification
elementId
uuid // UUID of the benefit specification
code
description
serviceOptionServiceCode
indActive
subType
claimFormTypeCode
procedureGroupUsage
procedureGroupCode
procedureGroup2Usage
procedureGroup2Code
procedureGroup3Usage
procedureGroup3Code
procedureConditionUsage
procedureConditionCode
diagnosisGroupCode
diagnosisGroupUsage
diagnosisConditionCode
diagnosisTypeCode
employerCountryRegionUsage
providerCountryRegionUsage
personCountryRegionUsage
productProviderGroupScope
specificProviderGroupScope
regimeCode
caseDefinitionCode
gender
ageFrom
ageTo
indAuthorizationMissing
indConsumeAuthorization
priorityCode
locationTypeUsage
modifierUsage
specialtyUsage
>
<countryRegionReferences>
<countryRegionReference reference="employer">
<countryRegion countryCode="" countryRegionCode=""/>
<countryRegionGroup code=""/>
</countryRegionReference>
<countryRegionReference reference="provider">
<countryRegion countryCode="" countryRegionCode=""/>
<countryRegionGroup code=""/>
</countryRegionReference>
<countryRegionReference reference="person">
<countryRegion countryCode="" countryRegionCode=""/>
<countryRegionGroup code=""/>
</countryRegionReference>
</countryRegionReferences>
<conditions>
<condition
code
/>
</conditions>
<providerGroups>
<providerGroup
code
assignmentLabel
/>
</providerGroups>
<locationTypes>
<locationType
code
claimFormTypeCode
/>
</locationTypes>
<modifiers>
<modifier
code
/>
</modifiers>
<specialties>
<specialty
code
/>
</specialties>
<dynamicFields/>
</benefitSpecification>
</benefitSpecifications>
Products
The final part of the export file contains the actual products. This is the selection of the distinct set of products in the USED BENEFIT SPECIFICATIONS list.
The first step is to assemble the <product> element for each product in the selection. This is a straightforward copy of the product as configured in OHI Product Definition, including the product provider groups and product limits.
The result is written to the export file as a product as follows:
<products>
<product
elementId
uuid // UUID of the product
code
description
aggregationLevel
priorityCode
productLineCode
productFamilyCode
fundingArrangementCode
brandCode
currencyCode
buildNumber
>
<productProviderGroups/>
<productLimits/>
<dynamicFields/>
</product>
</products>
Product Benefit Specifications are not listed as a part of a product, but under the <replaceProductBenefitSpecifications> element.
The product provider groups are written to the export file as follows:
<productProviderGroups>
<productProviderGroup
providerGroupCode
assignmentLabel
startDate
endDate
/>
</productProviderGroups>
If the product has no provider groups the <productProviderGroups> element is included without any <productProviderGroup> elements.
The product limits are written to the export file as follows:
<productLimits>
<productLimit
limitCode
renewalReference
renewalPeriodLength
renewalPeriodUnitOfMeasure
carryOverPeriodLength
carryOverPeriodUnitOfMeasure
otherProductsCarryOverPeriodLength
otherProductsCarryOverPeriodUnitOfMeasure
startDate
endDate
>
<dynamicFields/>
</productLimit>
</productLimits>
If the product has no product limits the <productLimits> element is included without any <productLimits> elements.
The export always lists a full set of product benefit specifications but does not list any deleted benefit specifications. Any benefit specifications that are present in the receiving application but not in the list are handled by the receiving application as (to be) deleted benefit specifications. For this purpose the <replaceProductBenefitSpecification> operation is available.
Replace Product Benefit Specifications
The final step is to generate a list of <productBenefitSpecification> elements. The <productBenefitSpecification> elements are grouped by the combination of product code and benefit specification code. For this reason, the list element <replaceProductBenefitSpecifications> is structured to contain two extra levels, that is the <product> and <benefitSpecification> element that envelope the actual <productBenefitSpecification> elements.
The main element is the <replaceProductBenefitSpecifications> element. This means that the receiving application will replace the full list of existing product benefit specifications within the product(s), with the list(s) in this element.
<replaceProductBenefitSpecifications>
<productChange
uuid // UUID of the product
code // code of the product
elementId
>
<benefitSpecification
uuid // UUID of the benefit specification
code // code of the benefit specification
>
<productBenefitSpecification
uuid
startDate
endDate
>
<productBenefitSpecificationLimits>
<productBenefitSpecificationLimit
limitCode
aliasCode
displayName
number
serviceDays
coverWithholdCategoryCode
reachedAction
startDate
endDate
>
<maximumAmount
amount
/>
<dynamicFields/>
</productBenefitSpecificationLimit>
</productBenefitSpecificationLimits>
<productBenefitSpecificationValues>
<productBenefitSpecificationValue
coverWithholdCategoryCode
aliasCode
displayName
percentage
startDate
endDate
>
<coverWithholdAmount
amount
/>
<dynamicFields/>
</productBenefitSpecificationValue>
</productBenefitSpecificationValues>
<productBenefitSpecificationReinsurances>
<productBenefitSpecificationReinsurance
aliasCode
displayName
startDate
endDate
/>
</productBenefitSpecificationReinsurances>
<dynamicFields/>
</productBenefitSpecification>
</benefitSpecification>
</productChange>
</replaceProductBenefitSpecifications>
The USED BENEFIT SPECIFICATIONS list is ordered first on product, then on benefit specification. An iteration starts over all entries in the list:
Whenever an entry specifies another product than the previous, a new <product> element is created. Whenever an entry specifies another benefit specification than the previous, a new <benefitSpecification> element is created. The code attribute is set to the benefit specification code.
Each entry leads to the creation of a new <productBenefitSpecification> element. The start and end date are copied from the entry of the USED BENEFIT SPECIFICATIONS list.
For each <productBenefitSpecification>, zero, one or more <productBenefitSpecificationValue> and <productBenefitSpecificationLimit> sub elements are added. These are direct copies of the product benefit specification value details and product benefit specification limit details of each product benefit specification.