The modules are the smallest element of the orchestration flow. These are the key pieces of functionality that organizes a key business capability. For example, benefit determination and third-party liability editing. The SCE provides a series of modules for specific out-of-the-box functionality that can be implemented. The modules provided by the SCE are all prefixed with an “S” identifier. Proprietary modules can also be created in the application for use in the SCE. The list of supplied modules is defined below. Each of these can be added as necessary to sequences to support orchestrations:
|Claim adjustment processing and validation
|Authorization matching and adjudication
|Claim business audits
|Multiple claim or multi-line editing against historical claims or the current claim
|Matches the claim to an appropriate benefit
|Claim business edits
|Single claim or line business edits and core action codes
|Benefit limit accumulator processing
|Benefit limit calculations and accumulator processing
|Coverages, accumulators and payments
|Liability calculations based on benefit coverage and accumulator use.
|Payment reductions based on claim submitted COB
|SCE adaptor for ClaimsXten integration and processing
|Episode of care identification and linking
|Event code review
|Reviews event codes assigned on the claim for disposition, routing, and next steps
|Finalizes the claim and performs any remaining calculations
|Finalizes the pricing on the claim and applies any COB adjustments
|Incentives and surcharges
|Applies any provider incentives or regulatory surcharges
|Legacy member match and eligibility module. Performs member lookup, checks eligibility, and validates member related data
|Matches the subscriber and/or patient on the claim to a member in the system
|Policy selection and eligibility
|Selects the appropriate policy for adjudication and validates member eligibility
|Validates patient and/or subscriber information on the claim against the matched member record
|Identifies if an authorization is required, matches, and processes the claim against an authorization
|Matches the provider on the claim to the provider records and validates the provider details
|Prices the lines on the claim based on the submitted codes
|Updates the claim and any supporting accumulators based on the final status
|Applies random audit event codes to the claim based on the audit configuration
|Selects the appropriate ratesheet ID based on the provider’s contract
|Applies the generic system configured automatic split claims logic.
|Locks the claims from subscribers from processing in parallel to ensure accumulators are in sync
|SCE adaptor to integrate to NetworX pricer
|Applies COB / TPL edits to the claim
|Process validation edits
|Performs key field validations to the claim
|Performs the winning price logic to select the appropriate price for adjudication
New modules can be easily added to the list by selecting Add module. This then presents the Add module screen displaying the fields needed for the module. On selecting Submit, the new module is added to the list for subsequent addition to sequences. The fields are:
|Brief name or description of the module. This description is used by the application whenever there is a reference required for the module being processed, for example, Claim Audit.
|Key assigned to this module. This identifier is stored for references to the module and is used as a lookup value for the module. It lets you modify the description without worrying about the reference to the module. Once you assign and use it, you should not modify it. This identifier is also used in assigning event codes
|Collection rule associated with the module. Select the process from a drop-down list of available collections. This is the rule that the module executes.
|Process type *
|The type of module (Stub, Pega, and External) as it relates to the application
|Indicator that defines whether a measurement should be captured for this module. This allows specific module measurement if the global measurement is off in the system settings.
|Indicator that defines whether any audit information should be reported for this module. This allows specific module audits to be logged if the global audit is off in the system settings.
|Indicator that defines whether to always bypass processing of this module. This is a useful feature during the testing of new modules
|Module bypass table
|Bypass table used for configuring information that can cause the module to be bypassed for specific claims
|A collection rule that can be used to initialize any values pre-run or perform any pre-run logic.
|A collection rule that can be used to finalize any values post-run or add any extensions to the module for client driven processing.
|Module next step
|A collection rule that is executed on completion of the module.
Note: fields with an * Asterix are required.Modifying & deleting modules
Existing modules can be modified by selecting the gear icon next to the module in the list. This will then open the Edit module screen enabling easy modification of the configuration.
Modules can be deleted by selecting the trash can icon next to the module in the list. Modules can only be deleted if they are not referenced in an existing sequence. A warning message is displayed when this occurs.