CA2654617C

CA2654617C - Revising containerized processing logic for use in insurance claim processing

Info

Publication number: CA2654617C
Application number: CA2654617A
Authority: CA
Inventors: Rob Tholl; Raymond Leung; Clayton Russell
Original assignee: Emergis Inc
Current assignee: Telus Health Solutions Inc
Priority date: 2009-02-18
Filing date: 2009-02-18
Publication date: 2017-11-14
Anticipated expiration: 2029-02-18
Also published as: CA2654617A1

Abstract

A system and method for revising one or more hierarchies of an insurance plan, the insurance plan for use in adjudicating one or more insurance claims. The method and system comprising obtaining one or more claims from a claims queue, the claims queue for storing claims selected for review. The system and method comprising accessing at least one of a set of benefit codes or a set of adjudication rules associated with the insurance plan of the obtained one or more claims, wherein at least some of the set of benefit codes or the set of adjudication rules are structured in a plurality of containers. The system and method comprising reconfiguring selected content of the at least one of a set of benefit codes or the set of adjudication rules in view of identified reasons for review of the one or more claims; and storing the reconfigured at least one of a set of benefit codes or the set of adjudication rules in a memory for subsequent use as at least one of a redeployed version of the insurance plan or a revised said at least one of a set of benefit codes or the set of adjudication rules for use in development of other insurance plans for adjudication of claims other than the one or more claims obtained from the claims queue; wherein the revised insurance plan, once deployed, is adapted for use by an adjudication engine for processing insurance claims received by the adjudication engine.

Description

REVISING CONTAINERIZED PROCESSING LOGIC FOR USE IN INSURANCE
CLAIM PROCESSING
FIELD OF THE INVENTION
[0001] This invention relates to reconfiguration of insurance plan definitions used in insurance claim processing.
BACKGROUND OF THE INVENTION

[0002] It is recognised in the health care industry that in order to service patient population, health care providers, by necessity, have become participants in many networks. This requires the complex management of many fee schedules, rule sets, and service code definitions, a process that is commonly outside of the capabilities of most practice management systems. The process is then left up to the carrier adjudicating the insurance claims, creating further inefficiencies and added costs to health plans. Further, it is recognised that there are many industry efforts in place to reduce cost, as well as constant Federal and State legislative changes, electronic transaction code sets, and privacy and security requirements.
Therefore, health claims processing has become a costly and time consuming endeavour in the current health care industry.

[0003] For example, the current healthcare claims system is the source where inefficiencies contribute in administrative overhead and delays. Furthermore, providers are suffering from bad debt expenses on patient payment amounts. In addition the current medical claims system is fraught with the high potential for errors and omissions resulting in more cost to process claims. Providers realise that the reduction of their Account Receivables balance and reconciliation time is desirable. This reduction can happen through more direct eligibility verification, streamlined management of many network relationships, and faster payment. For payers, a key to more efficient plan management is increasing their membership. This membership increase can happen through a value proposition which includes increasing auto-adjudication rates by reducing rejected claims and eliminating many of the steps required in order to accomplish today's claims administration. There is a need for the implementation of a tool for helping to increase auto-adjudication rates of an adjudication engine in the processing of insurance claims, such that the tool is configured as flexible enough to implement revised plans/benefits and associated adjudication rules and benefit code configurations more rapidly and/or at lower costs than current insurance plan systems, based on errors encountered during the adjudication process.
SUMMARY OF THE INVENTION

[0004] It is an object of the present invention to provide a benefit and rule reconfiguration environment to obviate or mitigate at least some of the above-presented disadvantages.

[0005] There is a need for the implementation of a tool for helping to increase auto-adjudication rates of an adjudication engine in the processing of insurance claims, such that the tool is configured as flexible enough to implement revised plans/benefits and associated adjudication rules and benefit code configurations more rapidly and/or at lower costs than current insurance plan systems, based on errors encountered during the adjudication process.
Contrary to current systems, there is provided a system and method for revising one or more hierarchies of an insurance plan, the insurance plan for use in adjudicating one or more insurance claims. The method and system comprising obtaining one or more claims from a claims queue, the claims queue for storing claims selected for review. The system and method comprising accessing at least one of a set of benefit codes or a set of adjudication rules associated with the insurance plan of the obtained one or more claims, wherein at least some of the set of benefit codes or the set of adjudication rules are structured in a plurality of containers. The system and method comprising reconfiguring selected content of the at least one of a set of benefit codes or the set of adjudication rules in view of identified reasons for review of the one or more claims;
and storing the reconfigured at least one of a set of benefit codes or the set of adjudication rules in a memory for subsequent use as at least one of a redeployed version of the insurance plan or a revised said at least one of a set of benefit codes or the set of adjudication rules for use in development of other insurance plans for adjudication of claims other than the one or more claims obtained from the claims queue; wherein the revised insurance plan, once deployed, is adapted for use by an adjudication engine for processing insurance claims received by the adjudication engine.

[0006] A first aspect provided is method for revising one or more hierarchies of an insurance plan, the insurance plan for use in adjudicating one or more insurance claims, the method comprising the steps of: obtaining one or more claims from a claims queue, the claims queue for storing claims selected for review; accessing at least one of a set of benefit codes or a set of adjudication rules associated with the insurance plan of the obtained one or more claims, wherein at least some of the set of benefit codes or the set of adjudication rules are structured in a plurality of containers; reconfiguring selected content of the at least one of a set of benefit codes or the set of adjudication rules in view of identified reasons for review of the one or more claims; and storing the reconfigured at least one of a set of benefit codes or the set of adjudication rules in a memory for subsequent use as at least one of a redeployed version of the insurance plan or a revised said at least one of a set of benefit codes or the set of adjudication rules for use in development of other insurance plans for adjudication of claims other than the one or more claims obtained from the claims queue; wherein the revised insurance plan, once deployed, is adapted for use by an adjudication engine for processing insurance claims received by the adjudication engine.

[0007] A further aspect provided is system for revising one or more hierarchies of an insurance plan, the insurance plan for use in adjudicating one or more insurance claims, the system comprising: a claims queue for obtaining one or more claims there from, the claims queue for storing claims selected for review; a claims module adapted for accessing at least one of a set of benefit codes or a set of adjudication rules associated with the insurance plan of the obtained one or more claims, wherein at least some of the set of benefit codes or the set of adjudication rules are structured in a plurality of containers; a reconfiguration module adapted for reconfiguring selected content of the at least one of a set of benefit codes or the set of adjudication rules in view of identified reasons for review of the one or more claims; and a deployment module adapted for storing the reconfigured at least one of a set of benefit codes or the set of adjudication rules in a memory for subsequent use as at least one of a redeployed version of the insurance plan or a revised said at least one of a set of benefit codes or the set of adjudication rules for use in development of other insurance plans for adjudication of claims other than the one or more claims obtained from the claims queue; wherein the revised insurance plan, once deployed, is adapted for use by an adjudication engine for processing insurance claims received by the adjudication engine.

[0008] A further aspect provided is a memory for storing data for access by an application program being executed on a data processing system, comprising: a data structure stored in said memory, said data structure including information resident in a database used by said adjudication engine program and including: a set of adjudication rules stored in said memory appropriate to processing a received claim of an adjudication engine, the set of adjudication rules structured in a plurality of containers including a primary rule container and a plurality of secondary rule containers, each of the plurality of secondary rule containers being coupled to the primary rule container by a respective container reference, each of the plurality of secondary rule containers containing one or more adjudication rules adapted for processing the claim content of the received claim, each of the one or more adjudication rules being coupled to their respective secondary container by a respective rule reference, the set of adjudication rules defining a rule hierarchy; wherein processing the content of the received claim with the one or more adjudication rules is facilitated by an execution order defined by the ordering of the container references in the primary rule container.

[0009] A further aspect provided of the data structure is a set of benefit codes stored in said memory appropriate to the received claim, the set of benefit codes structured in a plurality of benefit containers including a primary benefit container and a plurality of secondary benefit containers, each of the plurality of secondary benefit containers being coupled to the primary benefit container by a respective benefit container reference, each of the plurality of secondary benefit containers containing one or more benefit codes adapted for processing the claim content of the received claim, each of the one or more benefit codes being coupled to their respective secondary benefit container by a respective benefit reference, the set of benefit codes defining a benefit hierarchy.

[0010] The application program can be any of the engines, such as a composer engine, a reconfiguration engine, a reconfiguration engine and a plan engine.
BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Exemplary embodiments of the invention will now be described in conjunction with the following drawings, by way of example only, in which:

[0012] Figure 1 is a schematic of a claim processing environment;

[0013] Figure 2 is a block diagram of an exemplary embodiment of the environment of Figure 1;

[0014] Figure 3 is a block diagram of a structured memory of the environment of Figure 1;

[0015] Figure 4 shows an example claim of the environment of Figure 1;

[0016] Figure 5a is example grammar logic of the rule engine of Figure 2;

[0017] Figure 5a is an example parameterized rule using the logic of Figure 5a;

[0018] Figure 6a shows an example embodiment of a rule data structure of Figure 3;

[0019] Figure 6b shows a further embodiment of the rule data structure of Figure 6a;

[0020] Figure 6c shows an example embodiment of a service code data structure of Figure 3;

[0021] Figure 7 is an example interface of the rule engine 20 of Figure 2;

[0022] Figure 8 is another example interface of the rule engine 20 of Figure 2;

[0023] Figure 9 is another example interface of the rule engine 20 of Figure 2;

[0024] Figure 10 is an embodiment of the rule and service code data structure of Figure 3;

[0025] Figure 11 is an example configuration of the rule engine of Figure 2;

[0026] Figure 12a is an example configuration of the rules of Figure 3;

[0027] Figure 12b is an example configuration of the rule blocks of Figure 3;

[0028] Figure 13 shows a block diagram of a computer device for implementing the components of the environment of Figure 1;

[0029] Figure 14 is a flow-chart of steps performed by the adjudication engine of the environment of Figure 2;

[0030] Figure 15 is a flow-chart of steps performed by the composer engine of the environment of Figure 2;

[0031] Figure 16 is a diagram of an example management process for the environment of Figure 1;

[0032] Figure 17 is an example configuration of a modification process of rule and/or benefit hierarchies of the system of Figure 2;

[0033] Figure 18 is an example block diagram of modifications performed by a plan engine of the system of Figure 2;

[0034] Figure 19 is an example block diagram of an embodiment of the plan engine of Figure 18;

[0035] Figure 20 shows an example workflow of the plan engine of Figure 18;

[0036] Figure 21 is a flow chart of steps performed by the plan engine of Figure 2;

[0037] Figure 22 is a block diagram of an example configuration of the engines of Figure 2;

[0038] Figure 23 is an example configuration of engines of Figure 2;

[0039] Figure 24 is an example configuration of a reconfiguration engine of the environment of Figure 2;

[0040] Figure 25 is an example interface provided by the engine of Figure

[0041] Figure 26 is a flow-chart of steps performed by the engine Figure 24; and

[0042] Figures 27-78 are example user screen shots generated by the rule engine of Figure 2.

DETAILED DESCRIPTION OF THE EMBODIMENT(S) System 10

[0043] Referring to Figure 1, shown is the basic workflows involved with an insurance claim 12 (e.g. dental, vision, drug, etc, or a combination thereof). The process starts with a person 14 going to a medical office 15 to get insured services performed (e.g.
dental) and/or for the purchase of insured products (e.g. drugs) . The office 15 submits the electronic claim 12 over a communications network 11 to the recipient's insurance carrier 16. The carrier 16 adjudicates the claim 12 via an adjudication system 18 and returns to the dental office 15 the amount that it will cover the performed services/ purchased products. The Recipient 14 then has to pay the office 15 the difference if there is any. The adjudicated claim 12 is stored in a database 224 and later read into a payment processing system 24. Payment processing 24 can either EFT or generate a cheque to the payee 26 indicated on the claim 12. the carrier 16 also has a carrier database 28 coupled to the database 224, for supplying updates to any carrier/recipient specific information used during the adjudication 18 and/or payment 24 processes.
Further, the carrier 16 can also provide a forms interface 22 for use by the recipient 14 and/or the dental office 15, as desired, in completing the electronic forms of the claim 12 for submission over the network 11 (e.g. intra and/or extranet). The carrier 16 may also share/integrate certain data with the database 224 through an integration server 30.

[0044] Referring to Figure 2, shown is a block diagram of main components of the system 10 of Figure 1. The system 10 has an adjudication engine 40 of the adjudication system 18 that obtains rules 100 and benefits 103a s defined in a deployed plan 42, from the data base 224, for use in adjudication of received claims 12 that reference the plan 42.
A plan manager 44 is used to deploy the plan 42, taking into account customized rules 100 and benefits 103 (see Figure 3) as supplied from a rule engine 200 used to compose and/or otherwise organize the rules 100 into a rule hierarchy 260 and the benefits 103 into a benefit hierarchy 360, further described below. The Plan Manager 44 application lets users create and manage plan 42 coverage templates that are used as the basis of plan administration. Plans 42 are built by combining benefit blocks 326,328 with rules 100 (organized in blocks 226,228) (see Figure 3) and business-specific parameter-value groupings to create a unique coverage specification (e.g. the deployed plan 42 resident in the memory 224). Once a valid plan 42 reaches its Active Date, the plan can be promoted to a production server for access by the plan manager 44.

[0045] A module interface 46 is used by the adjudication engine 40 to load and execute adjudication rules 100 and associated benefits 103, as defined in the deployed plan 42. Through this design, all adjudication rules 100 and associated benefits 103 will fire their respective points in the order of execution (e.g. sequential as listed), as defined in the blocks 226,228,326,328 and/or their relationship models 260,360. The adjudication rules 100 discussed here are the ones attached to the plan 42. For example, the deployed plan 42 consists of elements such as but not limited to: adjudication rules 100 (and their associated block 226,228 configuration via references 227,229); a list of service codes 103 (and their associated block 326,328 configuration via references 327,329); a fee guide for defining the fees payable for services/products accepted in the claim 12 as processed via the adjudication 18 and payment 24 processing (see figure 1);
and a set of fiscal parameters (e.g. co-insurance, maximum and COB)that are used to customize the rules 100 and/or service codes 103 in the deployed plan 42 that is used in claim 12 processing by the adjudication engine 40. Accordingly, it is recognised that the rules 100 and their associated service codes 103 (via the configuration defined in the hierarchies 260,360) provide for the implementation of the deployed plan 42 used in processing the claims 12. For example, the rules 100 are used to determine whether a given service code 103 can be paid by the plan 42, upon review and processing of the claim 12 information by the adjudication engine 40.

[0046] Referring to Figure 3, shown is a further embodiment of the memory 224, including the benefit hierarchy 360 and the rule hierarchy 260, as well as their respective data structures consisting of patent/child (e.g. independent/dependent) blocks 326,328, benefits 103 and blocks 226,228 and rules 100, as further described below. It is recognised that the memory 224 can also include claims information 51, carrier/member/recipient information 49, payment information 57, provider information 59, fee schedules 48, and pended/quality control information 61, as desired.
Claim 12 Concept Overview

[0047] Referring to Figures 1,2, and 4, there are many different definitions of a claim 12 based on the perspective of the viewer. The following example definition and design of the claim 12 is from the perspective of the adjudication engine 40 for use in adjudication processing 18 using the configured rules 100 and/or benefit codes 103 of the plan 42 associated with the claim 12. A claim-item 60 can a procedure or product code (e.g. dental teeth cleaning). There can be multiple procedure codes on a single claim 12. Multiple procedure codes can sometimes be packaged together under 1 procedure code, as desired. The claim description 62 can be a unique combination of: Patient (registered with a specific carrier 231 and associated plan 42); Provider (of the insured service(s)/product(s) of the plan 42; and Service date (a measure of when the insured service(s)/product(s) took place). For example, the claim description 62 can describe a visit and resultant outcome of the patient to the provider. Note that multiple claims in a day (e.g.
service date) are possible. A transaction 64 can be made up of one or more individual claim descriptions and can, for example: be a box of receipts all submitted at once;
extend across multiples patients and providers; possibly represent a single EDI (CDA) claim with multiple service dates; and/or can represent a claim submitted on a periodic frequency (e.g. Labour Force Reentry (LMR) type claims pertaining to retraining/rehabilitation of the patient over an extended period of time).
Adjudication Engine 40

[0048] The adjudication engine 40 of the adjudication system 18 is configured to access or otherwise obtain rules 100 and benefits 103 as defined in a deployed plan 42, from the data base 224, for use in adjudication of received claims 12 that reference the plan 42. As further described below, the rules 100 and benefits 103 are configured as rule and benefit objects in respective hierarchies 260, 360.

[0049] The adjudication engine 40 can have a comparison module 41 configured for comparing the claim date to each of the an effective date and an expiry date of the container references 229, in order to determine if the respective secondary rule container 228 is part of the set of adjudication rules for use in processing the received claim 12, such that the non-matching dates exclude the respective secondary rule container 228 from being included in an execution order as listed in the corresponding primary rule container 226. Further, the adjudication engine 40 can have the comparison module 41configured for comparing the claim date to the effective date and/or a expiry date of the rule references 227, in order to determine if the respective adjudication rules 100 associated with the rule references 227 is/are part of the set of adjudication rules 100 for use in processing the received claim 12, such that the non-matching dates exclude the respective adjudication rule 100 from being included in the execution order of their respective secondary rule container 228.

[0050] Further, the adjudication engine 40 can have the comparison module configured for comparing the claim date to each of the an effective date and an expiry date of the benefit container references 329, in order to determine if the respective secondary benefit container 328 is part of the set of benefit codes 103 for use in processing the received claim 12, such that the non-matching dates exclude the respective secondary benefit container 328 from being included in an execution order as listed in the corresponding primary benefit container 326. Further, the adjudication engine 40 can have the comparison module 41 configured for comparing the claim date to the effective date and/or a expiry date of the benefit references 327, in order to determine if the respective benefit codes 103 associated with the benefit references 327 is/are part of the set of benefit codes 103 for use in processing the received claim 12, such that the non-matching dates exclude the respective benefit codes 103 from being included in the execution order of their respective secondary benefit container 328.

[0051] Accordingly, as further described below, the adjudication engine 40 uses date matching of the references 227,229,327,329 with the claim date, in order to assemble the set of adjudication rules appropriate to the content of the received claim 12. The comparison module 41 may be part of the adjudication engine 41, as shown, and/or may be part of the database 224 or other third party (not shown).

[0052] Referring to Figure 3, the adjudication engine 40 during the adjudication process 18 (see Figure 1) determines that claims 12 that cannot be automatically adjudicated according to the hierarchies 260, 360 as defined in the deployed plan 42 associated with the received claims12. Accodiingly, in the case of error(s) occurring during the adjudication process 18, the adjudication engine 40 makes note of the adjudication error(s) and sends the adjudication interrupted claim 12 to a Pended Claims queue 53. Pended claims 12 are determined by the engine modules and rules, according to the plan 42. Paper claims also has the ability to flag a claim 12 to be pended to the claims queue 53 for an adjudicator to view, via the review engine 50, as further described below.

[0053] Further, fraud claim(s) 12 can also be detected by the engine 40 during adjudication and are flagged as such and sent to the claims queue 53 also for review by the review engine 50. For example, the last step on the engine 40 can decide if the claim 12 has completed adjudication or not. If it is, and the fraud-flag had been set during the adjudication process 18, in view of application of the plan 42 to the contents of the received claim 12 by the adjudication engine 40,the claim 12 can be put into a special state in the claims queue, such that:
the claim 12 is not ready for payment; and the claim12 is not ready for Quality Control, for example.

[0054] As further described below, anti-Fraud determination of claims 12 in the queue 53 can be managed by a screen(s) 102 in the review engine 50. This can be a table driven feature with a custom module in the engine 50 to execute the logic for review and possible revsion/reconfiguration of the claim 12 and/or the hierarchies 260,360 associated with the claim 12. The table data can be updated in real-time, and it is understood that Anti-Fraud can sometimes make mistakes and either miss, or catch too many claims 12, at least initially.
However, based on the potential for revision/reconfiguration of the hierarchies 260,360, via the review engine 50, in view of the analysis of the queued claim 12, it is understood that iterative updates/revisions 54 of the hierarchies 260,360 (e.g. of the plan(s) 42) may provide for increases in auto adjudication levels for the received claims 12, in view of iterative updates/revisions 54 of the hierarchies 260,360 based on claim review (by a claim module 536 ¨ see Figure 24) of the claims 12 submitted to the claims queue 53.
Adjudication Rules 100

[0055] The Rules 100 can be used by the adjudication engine 40 to determine whether a given service code 103 is authorized to be paid by a plan 42 deployed on behalf of the carrier 231 (see Figure 6a).
Rule Grammar

[0056] Reference is next made to Figure 5a and 11, which illustrates the generalized structure of a Rule 100. Each rule 100 is a discrete logical expression that, when evaluated, returns a condition of either "TRUE" or "FALSE". One example of the rule 100 is a logical structure of IF {condition(s)} THEN {action(s)}statement. The defined grammar logic 212 is available to a composer module 202 of the rule engine 200 for use in creating/amending the rules 100 for a new plan 42 and/or for facilitating editing of rules 100 in an existing plan 42 obtained from the memory 224 (see Figure 3). Rules 100 are evaluated by the adjudication engine 40 when claims 12 are submitted by an insured person as will be described below and are used to process claims 12. The complete set of rules 100 in the rules database 224 is the complete set of business logic that will be analysed by the adjudication engine 40 in processing a claim 12. An action or method 104 of the grammar logic 212 can be performed by the adjudication engine 40 if the condition 102 of the rule 100 is "TRUE". The action 104 is not performed if the condition 102 of the rule 100 is "FALSE".

[0057] Conditions 102 of the grammar logic 212 are expressions that result in a true or false answer. The expressions 102 can be comprised of the rule elements described in a Business Object Model (BOM) file. Conditions 102 can be as simple as (OBJ.A = 1). A
rule 100 can also have multiple conditions 102 joined together by logical operators and each condition can be nested with other conditions. An exemplary more complicated rule 100 with several logical operators and nested conditions is the following:
((OBJ1.A+OBJ1.B=2) OR ((OBJ1.D=10) AND (OBJ2.E=OBJ2.F)) OR (OBJ.FUNCTION(A,B) =25

[0058] The elements of the grammar logic 212 that comprise conditions and actions can be specific to the implementation and are described in a Business Object Model (BOM) file. The BOM file is an XML file that provides the rule engine 200 with information on rule elements of the grammar logic 212 available for use creating/editing/deleting the rules 100, such as but not limited to:
= Business objects such as a claim = Attributes associated with business object such as a recipient = Methods associated with each business object such as calculations based on the recipient's claim history = Data types associated with each rule element = Global functions such as those used to manipulate or compare data = Actions such as pay or refuse the claim (or line item of the claim) = Operators for comparisons and arithmetic

[0059] The rules 100 in the BUM have customizable labels and descriptions that the user will see when interacting with the tool. Changes to the BUM are easily implemented by interacting with a rule composer interface (e.g. interface 102 coupled to the composer module 202) and may not require an application code update. The rule composer interface 102 (see Figure 13) is in communication with thr rule engine 200 which performs the functionality upon instruction by the user. The BOM is a system file that may not be normally modified directly by the user without using the rule composer interface 102.

[0060] An example rule 100a is shown in Figures 5a,b. The rule 100a includes an expression 106 and an action 108. When the rule 100a is evaluated by the adjudication engine 40, the adjudication engine 40 will determine whether the expression 106 is in a FALSE
condition or a TRUE condition. If the expression is in the TRUE condition, then the adjudication engine 40 will execute the action 104 specified in the rule 100.
If the expression is in the FALSE condition, then the adjudication engine 40 will take no action.

[0061] In rule 100a, the expression 106 includes a literal value 112, an operator 110 and a parameter value 114. The literal value 112 represents the "StartDate" of the employee submitting the claim 12. It will be appreciated that the literal value 112 of a rule 100 may be any literal value 112 that is available in the database 224. Other literal values 112, for example, may correspond to an employment start date, an employment end date, employment status (e.g. full-time, part-time, contract) or other literal values 112 as will be understood in the art. The literal values 112 may be set to a default value in the rule 100 creation process (via the rules engine 200) and be edited when a rule 100 is attached to the plan 42, as further described below.

[0062] It is recognised that business objects are objects to which information is attached, as utilized by the rule engine 200. A claim 12 (see Figure 1) is an example of a business object.
Attached to the claim 12, as received by the adjudication engine 40 (see Figure 2), is information such as the identity of the claim's recipient and the service for which the claim 12 is being made, as well as the carrier 231 that is responsible (i.e. for providing the configuration of the rules 100 and/or for payment of the claim 12, once adjudicated) for the claim 12.
Business objects provide the context in which the rules 100 would be evaluated during adjudication of the claim 12 by the adjudication engine 40. It is recognised that methods can also be attached to the business objects, in order to perform calculations in the context of the business object or retrieves information about the business object that is not available as an attribute.
It is recognised that the attributes and methods attached to the business object are referenced in the rule(s) 100 using a syntax of the rule grammar of the grammar logic 212, such as objectattribute and object.method syntax respectively.

[0063] Attributes are the pieces of information attached to a business object. The attributes can have values that can be used for comparisons or calculations, depending on the data type, in order to assist in execution of the rules 100 when processing of the received business object (e.g. claim 12) by the adjudication engine 40.

[0064] The methods and functions associated with the business object (e.g. via the rules 100) are used to return a calculated value and/or a true/false logic decision, return a state, and/or perform action(s). Operators are uses when comparing two or more values and/or in joining two or more conditions. The logical operators AND, OR, AND NOT, OR NOT, and NOT of the grammar logic 212 are used in the rules 100, as input through the user via the rules manager 202.
Other operators of the grammar logic 212 can be such as but not limited to:
EQUALS; NOT
EQUALS; etc. An example of a rule 100 in the rule hierarchy 260 is shown in Figure 9.
Rule Blocks 228 and Superblocks 226

[0065] Referring to Figures 2,3, the blocks 226, 228 and rules 100 are used as rule objects in the hierarchy 260, thus providing for multiple instances of the same rule object in any particular rule hierarchy 260 (i.e. specific instances of coupled blocks 226,228 and rules 100) configuration.

[0066] A Rule Block 228 is a logical grouping of Rules 100, such that specific instances of the Rule Blocks 228 have a name and description but may not have any inherent processing logic. A Rule Super Block 226 is a logical grouping of Rule Blocks 228. Rule Super Blocks 226, such that specific instances of the Rule Blocks 226 have a name and description but may not have any inherent processing logic. A name and description in a second language can be supported. The Rule Super Block 226 can be used to define the execution order of the blocks 228 listed/referenced 229 therein (e.g. each referenced block 228 in the list of blocks 228 in the super block 226 is processed in sequential order).

[0067] The organization of adjudication rules 100 is represented by Rule Containers 226, 228 (e.g. Super Blocks and Blocks) and the Rules 100 within them. The adjudication rules 100 and their organization in the hierarchy 260 are stored as data organised via the blocks 226,228 within the database 224. The rule data is then used by the adjudication engine 40 to process claims 12 received. Referring to Figure 6a, the rule hierarchy 260 consists of Carriers 231, Rule Containers 226, 228, and Rules 100. Carrier 231 is the root container for the Rule Hierarchy 260. Rule Objects refer to both Rules 100 and Rule Containers 226,228, such that Rule Super Blocks 226 contain Rule Blocks 228 and Rule Blocks 228 contain Rules 100, for example, as a container relationship structure used to organize and define the rule hierarchy 260.

[0068] The term Rule 100 refers to a specific implementation of the processing logic of a business policy. A Rule Block 226,228 is a logical grouping of Rules 100.
Rules 100 belong to a Rule Block 226,228 by way of a reference 227,229 (also referred to as Rule Inclusions). Rule Objects exist at the specified level in the hierarchy 260 (specific configuration of the blocks 226, 228 and rules 100 through the references 227,229. The Rule Hierarchy 260 is built on references 227 to Rule Objects rather than containing the Rule Objects; where Rule Objects only exist once in the database, regardless of how many times they appear in the Rule Hierarchy 260. For example, a named rule 100 (e.g. an instance of the rule 100) is an example of a rule object that is then referenced 227 in the containers 226,228 of the hierarchy 260. Also, it is recognised that named containers 226,228 (e.g. an instance of the container 226,228) is an example of a rule object that is then referenced 229 in the containers 226,228 of the hierarchy 260. The use of references 227,229 provides for efficient reuse of common Rules 100 and Rule Containers 226,228 in a large Rule Hierarchy 260. When changes are required on a Rule Object, the changes need only be applied to the single instance rather than in multiple copies.

[0069] Referring to Figure 6a, the rules 100 are organized into a collection of primary 226 and secondary 228 containers, also referred to as superblocks 226 and blocks 228. It is recognised that a particular rule 100 may exist only once in the database 224 but can be found in multiple containers 226,228 by one or more references 227,229, such that the reference 227 is a link between a rule 100 and a secondary container 228 and a reference 229 is a link between a secondary container 228 and a primary container 226. Accordingly, rule objects can exist only once in the database 224, regardless of how many times the appear in the rule hierarchy 260, since the rule hierarchy 260 can be built on references to the rule objects rather than containing the rules objects themselves. One advantage in using references 227,229 is that it can allow for reuse of common rules 100 and rule containers 226,228 in a complex rule hierarchy 260, such that when changes/modifications are done on a rule object, the changes/modifications are only applied to the single instance of the rule object rather than to multiple copies of the rule objects.

[0070] It is recognised that the rules 100 linked via references 227 to the secondary containers 228 are also included in the primary containers 226 via the references 229, e.g. a primary container 226 contains all contents of the linked 229 secondary containers 228 (e.g. as a child of the primary container 226) and the contents of the secondary containers 228 are the linked 227 rules 100 (e.g. the rules 100 are children of the secondary containers 228). Hence, the described relationship between the containers 226, 228 and the rules 100 can be such that each rule is a dependent/child of the associated secondary container 228 and each secondary container in turn is a dependent/child of the primary container 226. As well, each primary container 226 is a dependent/child of one or more carriers 231, as shown by example in Figure 6a.
References 227,229, 327,329

[0071] Referring to Figure 12a,b, a Rule Version is a specific implementation of a Rule 100 using the rule grammar. Different implementations may be valid at different points in time in time span 301 ordering of the rules 100 and corresponding blocks 228. A
version date 300 of a rule version determines which implementation is applicable over the history of the Rule 100. A
Rule 100 is a member of a Rule Block 228 by way of the reference 227 and those references can be called Rule Inclusions. The order of Rule Inclusions 227 within a Rule Block 228 determines the order of processing by the adjudication engine 40 of the rules associated via the hierarchy 260 for the particular plan 42 associated (e.g. via a plan ID associated with the patient name of the claim 12) with the received claim 12 for processing (see Figure 3). The chronological dependency of Rule Inclusions 227 for a Rule 100 within a Rule Block 228 is called a Rule Timeline 302.

[0072] A Rule Block 228 is a member of a Rule Super Block 226 by way of the reference 229 and those references can be called Rule Block Inclusions 229.
The order of Rule Block Inclusions 229 within a Rule Super Block 226 can determine the order of processing by the adjudication engine 40. It is recognised that Rule Block Inclusions 229 may or may not have a time dependency.

[0073] Accordingly, rule processing order by the adjudication engine 40 is configured in the hierarchy via the references 227,229. For example, Rule Inclusions 227 can have an effective date and expiry date (e.g. on the timeline 302). These dates specify the start and end of when the Rule 100 is considered to belong to the Rule Block 228. The Rule Inclusions 227 that a claim 12 will encounter during processing depends on a service date of the claim 12, as well as the plan ID for associating the clams 12 with the rules 100 and benefits 103 related to the claims via the corresponding deployed plan 42. Each Rule 100 referenced by the Rule Inclusions 227 may have multiple versions of the logic implementation. The rule version 300 used for a claim 12 can be the most recent one relative to the claim 12 service date. Each version 300 can have a distinct Version Date that specifies the start date of the version 300. The end date of a Rule Version 300 is implied by the start date of the next version, for example or can be independently specified, as desired. Rule Inclusions 227 may or may not point to a specific Rule Version 300, where the version 300 used during claim 12 processing can be determined by the claim 12 date.

[0074] Further, a benefit Version is a specific implementation of a benefit 103. Different implementations may be valid at different points in time in time span 301 ordering of the benefit 103 and corresponding blocks 328. A version date 300 of a benefit version determines which implementation is applicable over the history of the benefit 103. A benefit 103 is a member of a benefit Block 328 by way of the reference 327 and those references can be called benefit Inclusions. The order of benefit Inclusions 327 within the Block 328 can determines the order of processing by the adjudication engine 40 of the benefits associated via the hierarchy 360 (as well as linked to specific rules via links 240 ¨ see Figure 10) for the particular plan 42 associated (e.g.
via a plan ID associated with the patient name of the claim 12) with the received claim 12 for processing (see Figure 3). The chronological dependency of benefit Inclusions 327 for a benefit 103 within a Block 328 is called a Timeline 302.

[0075] A Block 328 is a member of a Super Block 326 by way of the reference 329 and those references can be called Block Inclusions 329. The order of benefit Block Inclusions 329 within a benefit Super Block 326 can determine the order of processing by the adjudication engine 40. It is recognised that Block Inclusions 229 may or may not have a time dependency.

[0076] Accordingly, benefit processing by the adjudication engine 40 is configured in the hierarchy via the references 327,329. For example, Inclusions 327 can have an effective date and expiry date (e.g. on the timeline 302). These dates specify the start and end of when the benefit 103 is considered to belong to the Block 328. The Inclusions 327 that a claim 12 will encounter during processing depends on a service date of the claim 12, as well as the plan ID for associating the clams 12 with the rules 100 and benefits 103 related to the claims 12 via the corresponding deployed plan 42. Each benefit 103 referenced by the Inclusions 327 may have multiple versions of the logic implementation. The benefit version 300 used for a claim 12 can be the most recent one relative to the claim 12 service date. Each benefit version 300 can have a distinct benefit Version Date that specifies the start date of the benefit version 300. The end date of a benefit Version 300 is implied by the start date of the next benefit version, for example or can be independently specified, as desired. Inclusions 327 may or may not point to a specific benefit Version 300, where the benefit version 300 used during claim 12 processing can be determined by the claim 12 date.

[0077] Figure 12a illustrates the Timeline 302 and Version 300 concepts with example rules 100. The definition of Rule A has three versions 300 with Version Dates of 2002/01/01, 2003/07/01 and 2005/01/01. Rule A is included in the example Rule Block 228 from 2002/01/01 to 2004/01/01 and again from 2006/01/01 with no expiry date. Between 2004/01/01 and 2006/01/01 Rule A is not included in the Rule Block 228. The first claim 12 with a date of 2003/01/01 will see the first version 300 of Rule A. The second claim 12 with a date of 2003/10/01 will see the second version 300 of Rule A. The third claim 12 will not see any version 300 of Rule A because the Rule Inclusion 227 is not in effect at that time. Accordingly, the rule inclusion 227 can be used to coordinate which rule 100 at which time is relevant for use in adjudication processing 18 (see Figure 1) based matching the date of the rule inclusion 227 with the claim date.

[0078] When multiple Rule Versions 300 exist for a given Rule Inclusion 227, the appropriate version date can be shown as child nodes under the Rule Inclusion 227. The version 300 dates shown can fall between the start and end of the respective time span 302 dates. For example, a Rule 100 can have multiple versions 300 grouped under different version dates (e.g.
2000/03/22 and 2007/04/08). For each time span 302 the appropriate version dates can be displayed as child nodes of the Rule 100 rule inclusion 227 node of the hierarchy 260 (see Figure 6a).

[0079] Figure 12b illustrates the Timeline 302 and Version 300 concepts with example blocks 228. The definition of block A has three versions 300 with Version Dates of 2002/01/01, 2003/07/01 and 2005/01/01. Block A is included in the example super Block 226 from 2002/01/01 to 2004/01/01 and again from 2006/01/01 with no expiry date.
Between 2004/01/01 and 2006/01/01 block A is not included in the super Rule Block 226. The first claim 12 with a date of 2003/01/01 will see the first version 300 of block A. The second claim 12 with a date of 2003/10/01 will see the second version 300 of block A. The third claim 12 will not see any version 300 of block A because the Inclusion 229 is not in effect at that time. Accordingly, the inclusion 229 can be used to coordinate which block 228 at which time is relevant for use in adjudication processing 18 (see Figure 1) in the corresponding superblock 226, based matching the date of the inclusion 229 with the claim 12 date.

[0080] When multiple Rule Versions 300 exist for a given Inclusion 229, the appropriate version date can be shown as child nodes under the Inclusion 229. The version 300 dates shown can fall between the start and end of the respective time span 302 dates. For example, a block 228 can have multiple versions 300 grouped under different version dates (e.g.
2000/03/22 and 2007/04/08). For each time span 302 the appropriate version dates can be displayed as child nodes of the inclusion 229 node of the hierarchy 260 (see Figure 6a).

[0081] It is recognised that similar use of references 327, 329 for the benefits 103 can be said for Figures 12a,b, whereby the benefit inclusion 327 can be used to coordinate which benefit 103 at which time is relevant for use in adjudication processing 18 (see Figure 1) based matching the date of the benefit inclusion 227 with the claim 12 date. Further, it is recognised that, the inclusion 329 can be used to coordinate which block 328 at which time is relevant for use in adjudication processing 18 (see Figure 1) in the corresponding superblock 326, based matching the date of the inclusion 329 with the claim 12 date.
Benefit Blocks 328 and Superblocks 326

[0082] As mentioned above, the plans 42are built by combining, via links 240 between rules 100 and benefits 103 (see Figure 10), benefit blocks 326,328 with rules 100 and associated rule blocks 226,228 and business-specific parameter-value groupings to create a unique coverage specifications, which are applied to the received claims 12 as processed by the adjudication engine 40, see Figure 3. Once a valid plan 42 reaches its Active Date, the plan 42 can be promoted to a production server (e.g. storage 224) for eventual access by the adjudication engine 40, once deployed in the storage 224 (see Figure 3). Accordingly, the Plan 42 is a grouping of various attributes (e.g. of the hierarchies 260, 360) to assist in determining whether a dental service (or other insured products/services) of the claim 12 is covered and any restrictions on the reimbursement, a result of the adjudication processing 18.

[0083] Referring to Figure 6c, a benefit hierarchy 360 allows users to create unique plan 42 configurations from a shared set of plan and benefit data, as well as to provide for instruction to the adjudication engine 40 in adjudication of the claims 12 that are associated with the respective deployed plan 42. The benefit hierarchy 360 can crosses multiple lines of business such as dental, drug, medical, and vision. Generally, each benefit super-block 326 can contain only blocks 328 of benefits 103 of the same business. However, for reporting purposes users can define super-blocks 326 that cross multiple lines of business. There can be basic elements in the benefit hierarchy 360, such as but not limited to: Benefit-Super-Blocks 326, Benefit-Blocks 328, and Benefits 103, which are linked to one another similarly to the arrangement of the rule blocks 226,228 and rules 100 (see Figures 6a,b), using references 327,329, as further described below.

[0084] Benefit Super-blocks 326 represents a grouping of benefit blocks 328 used to create an overall coverage list for the plan 42, such that the benefit super blocks 326 can be used to define the execution order of the blocks 328 listed/referenced 329 therein (e.g. each referenced block 328 in the list of blocks 328 in the super block 326 is processed (e.g.
in sequential order as listed in the blocks 326). The Super Benefit Block 326 can be identified as an Inclusive or Exclusive grouping, for example. A Super Benefit Block 326 can include an Identifier, a Label Name, a Type and a Description. The Benefit Super-blocks 326 can be the highest object in the hierarchy 360, and are assigned to a plan 42, or as an override to an enrolment hierarchy (not shown). Super-blocks 326 can be assigned to the plan 42 and/or become a plan component. A
super-block 326 can contain any number of benefit blocks 328, via references 329. Benefit blocks 328 can be included or excluded, and are time-lined via the references 329, allowing them to change over time if required. Benefit Super-Blocks 326 can be created in a number of different types, such as but not limited to: Coverage - include or exclude specific benefit blocks 328; Override - include or exclude benefits 103 and override plan coverage;
Fiscal - assign specific Coinsurance, Deductible, and Maximum methods/functions; and Adjudication - assign specific rules 100 (for example, Pricing, COB, etc.) depending on business requirements.

[0085] A Benefit block 328 represents a grouping of other benefit blocks 328 or a logical grouping of benefit/service codes 103. A Benefit Block 326 can include an Identifier, a Label Name, a Type and a Description. These blocks 328 can represent industry-level categorization or carrier-specific groupings. Benefit blocks 328 can be created once and may be referenced by multiple plans 42. Benefit blocks 328 can be time-lined, meaning that a benefit block 328 can contain a different number of benefits 103 over time, as referenced by the references 327, providing for a benefit 103 that is no longer covered to remove itself from the block 328 (and in turn any associated plans 42 will no longer cover the benefit 103).

[0086] Benefits 103 generically refer to a claimable item such as a dental procedure or a pharmacy prescription, for example. A benefit code 103 is a re-usable component. Each benefit 103 can be defined only once, and can have a relationship 327 with multiple blocks 328. Each benefit 103 is defined with attributes such as benefit code, label, and line of business (dental/medical etc.). Most benefit codes 103 can be derived from the CDA
industry standards, for example. Accordingly, benefit objects can exist only once in the database 224, regardless of how many times the appear in the rule hierarchy 360, since the benefit hierarchy 360 can be built on references to the benefit objects rather than containing the benefit objects themselves. One advantage in using references 327,329 is that it can allow for reuse of common benefits 103 and benefit containers 326,328 in a complex benefit hierarchy 360, such that when changes/modifications are done on a benefit object, the changes/modifications are only applied to the single instance of the benefit object rather than to multiple copies of the benefit objects.

[0087] A Benefit Block 326,328 is identified as a Type to indicate what the grouping is supporting. The following are valid types of benefit blocks 326,328, for example but not limited to: Coverage List ¨ groupings to create the coverage list of service codes 103, such that these groupings can be made in benefit blocks 328 that will support the coinsurance structure of a policy; Plan ¨ groupings created to support the fiscal restrictions within a plan 42, for example:
if frequency is to be attached to 'exams', the Plan Specialist will group benefit blocks 326,328 and/or service codes 103 together an create a benefit block label 'exams', which can then allow the Plan Specialist to create a rule 100 using this label to set up parameterized values and structure the frequency as required by the policy of the plan 42; and Adj Logic ¨ groupings created to support the dental (or other insurance types) interaction rules 100 required by the insurance industry (e.g. can be carrier specific, for example).

[0088] Parameterized Values of the benefit codes 103 can be attributes within a plan 42or Rule 100 (e.g. via link 240 ¨ see Figure 10) where the user can enter in a specific value. Benefit Inclusion is a term used to identify that a particular service code 103 or grouping of service codes 103 are additionally being covered outside of the defined plan 42¨
coverage list. Benefit Exclusion is a term used to identify that a particular service code 103 or grouping of service codes 103 are additionally being excluded from coverage outside of the defined plan 42 ¨
coverage list. Plan Components references functionality that is coded in the adjudication engine 42 to perform various functions related to the service codes 103 and rules 100 associated with the plan 42 used to assist in adjudication of the received claim(s) 12.

[0089] The contents of benefit blocks 328 are used to define a list of service codes 103 that are consider as eligible dental (or other insurance types) services for reimbursement. Benefit Block 326,328 labels are concise and make business sense. Benefit blocks 326,328 are intended to be re-used in the benefit hierarchy 360, and can also identify the coinsurance groupings of the covered insured services. Benefit block labels, when re-used for the fiscal coinsurance groupings, can be returned in a claims experience log (not shown).

[0090] As discussed above for use of references 227,229 with rules 100 and rule blocks 226,228, the benefit blocks 326,328 and benefit codes 103 can also use similar references 327,329 to Set Expiry Dates for Benefit(s) 103 in a Block 328, and Set Effective Dates for Benefits 103 in a Block 328. As well, the references 329 can be used to set the respective linked block(s) 328 with the super block(s) 326, thereby facilitating the time dependent and/or version 300 dependent inclusion of the codes 103 in the blocks 328 and/or time dependent and/or version 300 dependent inclusion of the blocks 328 in the superblocks 326, as desired, see Figure 12b.

[0091] Accordingly, it is recognised that a super-block 326 may contain any number of benefit blocks 328. Benefit blocks 328 can be included or excluded and are time-lined 302 using the references 329, thus providing for the contents of the blocks 326 to change over time, if desired. For example, selecting a new expiry date for all selected blocks 328 will provide for the specified blocks 328 (via the reference(s) 329) will no longer be functional in this super block 326 after the expiry date has lapsed. Also, for example, selecting a new effective date for all selected blocks 328 will provide for the specified blocks will not be functional in this super block 326 until the effective date has been reached. Further, benefit super blocks 326 can be interpreted (e.g. sequentially) in the specified order in the hierarchy 360, in ascending order;
benefits 103 that are part of an excluded block 328 are ignored if they are part of a later included block 328, for example.

[0092] It is recognised that the above described benefit hierarchy 360 is used by a plan manager 44 to assemble the rules 100 and benefit codes 103 (as ordered by the blocks 226,228,326,328 and associated references 227,229,327,329 to create a specific plan version 42 that is then stored for use by the adjudication engine 40 in processing the received claims 12 that are associated with the specific plan version 42 as deployed in the memory 224.

Rule Hierarchy 260 and Benefit Hierarchy 360

[0093] As shown in Figure 6a,b, rules 100 are grouped into blocks 228 and superblock 226 for processing by the engine 40 and for visualization by the user when using the rule/benefit composer engine 200. A superblock 226 can be the highest container in the hierarchy 260 (other than the specific carrier 231) such that each of the other blocks 226,228 and rules 100 related to the superblock 226. There may be no limit on the number of blocks 226,228 so a particular rule hierarchy 260 can theoretically have any number of tiers (e.g. having block 226 to block 226 links, block 226 to block 228 links, block 228 to block 228 links, and block 228 to rule 100 links, as well as block 226 to rule 100 links where appropriate). The grouping of rules 100 into blocks 228 and superblocks 226 is dependent on the wishes of the user. As an example, a user of th engine 200 may wish to configure the hierarchy260 to have a superblock 226 for standards set by the Canadian Dental Association and a second superblock 226 for customized business logic for processing claims 12. As another example, a user may wish to have a superblock 226 for different insurance types such as dental, automobile, life insurance as will be appreciated. The superblock 226 node contains child nodes representing a first level of rule blocks 228. The first level of rule blocks 228 may contain additional rule blocks 228 or rules, depending on how many container levels the hierarchy 260 is configured for.

[0094] The rule hierarchy 260 can be both an interactive visual representation (e.g. with the user via the composer engine 200) of the relationship(s) between rule objects, and a data structure in the rules database 224 which describes the relationship between rule objects for use by the adjudication engine 40 in processing of the claims 12. It will be appreciated that each rule object (i.e. superblock 226, blocks 228 and rules 100) may exist only once in the database 224 but is referenced by each other rule objects that it is related to in a parent or child relationship of the hierarchy 260. For example, in a situation where there is only one superblock 226, each other rule object is referenced 229 in the database 224 by the superblock 226.
The reference(s) 227, 229 may be implemented via generic fields in a data record that stores data (for e.g.
attributes) of the blocks 226,228. In another embodiment, a data record of the blocks 226,228 may reference 227,229 a (e.g. dynamic) table that contains references 227, 229 to each of the other rule objects that are in a child relationship with the block. The references 227, 229 to rule objects may be in the form of a globally unique identifier or GUID, or other type of identifier, which is a type of identifier used in the engine 200,40 applications in order to provide a reference number which is unique in any context (hence, "globally"), for example, in defining the internal reference for a type of access point in a set of stored instructions for execution by the computer processor 150 in Figure 13, or for creating unique keys in a database. The reference 227 to a rule 100 can also indicate whether a rule object is a child or parent of another rule object (e.g. rule block 228).

[0095] The benefit hierarchy 360 can be both an interactive visual representation (e.g.
with the user via the composer engine 200) of the relationship(s) between benefit objects, and a data structure in the database 224 which describes the relationship between benefit objects for use by the adjudication engine 40 in processing of the claims 12. It will be appreciated that each benefit object (i.e. superblock 326, blocks 328 and benefit 103) may exist only once in the database 224 but is referenced by each other benefit objects that it is related to in a parent or child relationship of the hierarchy 360. For example, in a situation where there is only one superblock 326, each other benefit object is referenced 329 in the database 224 by the superblock 326. The reference(s) 327, 329 may be implemented via generic fields in a data record that stores data (for e.g. attributes) of the blocks 326,328. In another embodiment, a data record of the blocks 326,328 may reference 327,329 a (e.g. dynamic) table that contains references 327, 329 to each of the other benefit objects that are in a child relationship with the block. The references 327,329 to benefit objects may be in the form of a globally unique identifier or GUID, or other type of identifier, which is a type of identifier used in the engine 200,40 applications in order to provide a reference number which is unique in any context (hence, "globally"), for example, in defining the internal reference for a type of access point in a set of stored instructions for execution by the computer processor 150 in Figure 13, or for creating unique keys in a database. The reference 327 to a benefit 103 can also indicate whether a benefit object is a child or parent of another benefit object (e.g. benefit block 328).

[0096] Figure 6b illustrates the structural data relationship between rule objects. Rule objects refer collectively to superblocks 226, blocks 228 and rules 100. As shown, each rule object may exist once in the rules database 224. It is to be appreciated that the rule objects may exist in a single database 224 or in multiple databases that reference each other. As shown, superblock 226 references two blocks 228a and 228b. Block 228a references rule 2 and 3, and block 228b references rule 1 and rule 3. Superblock 226 also references rules 1, 2 and 3 by its own reference to blocks 228a, 228b. In another embodiment, superblock 226 may directly reference rules 100 in addition to blocks 228a, 228b. Further block 228b refers to block 228c which refers to rule "n".

[0097] When a user interacts with the tool 12 and changes the hierarchical relationship between rule objects, a rule engine 200 implements the change by changing the references in the rules database 224 as is described below. It will be appreciated that if any of the rule objects are moved and/or deleted, the structural relationship depicted in Figure 3b will be altered by the rule engine 200, a new data structure (e.g. rule hierarchy 260) will exist in the rules database 224 or collection of rules databases 224.

[0098] An exemplary rule hierarchy 260 is illustrated in Figure 7. As shown, the rule hierarchy 260 has a superblock 226 entitled 'MSIMed', several blocks 228 and several rules 100.
A user is able to expand the rule hierarchy 260 (e.g. using a hierarchy module 204 of the engine 2000 ¨ see Figure 11) by clicking on the '+' buttons and is able to contract the hierarchy 260 by clicking on the '-' buttons via the interface 102 (see Figure 13). In this way a user is able to precisely focus on a particular rule 100, a block 228 or a superblock 226 as desired. The rule hierarchy 260 can be a graphical tree view that is similar to a folder tree view of a file system as displayed on the display 152, for example. The nodes on the tree view represent the Rule Objects in the rule hierarchy 260 in a parent-child relationship.

[0099] The order in which rules 100 and rule block 228 are evaluated by the adjudication engine 40 can affect the adjudication result of the claims 12. New rules 100 and rule blocks 228 can be placed at the bottom of the hierarchy 260 by default, for example. To rearrange the order of the rules 100 in the hierarchy 260 using the engine 200, a user can drag and drop rule objects wherever desired so that the new rule object is in the target node. When a user moves a rule object, the rule engine 200 instructs component modules (e.g. module 202, 204, 206, 208, 210) of the engine 200 to modify the data relationship between the moved rule objects and to render a new visual rule hierarchy 260 to the screen as is described below.

[00100] One example implementation of the rule hierarchy 260 is where individual rules 100 can only exist at the bottom most rule container 228 level and that rule containers 226,228 that contain a rule object 100 (e.g. via references 227,229) cannot be moved to a different level of the hierarchy 260. These reference limitations, as managed by the Hierarchy manager 204, help to reduce the complexity of maintaining the hierarchy 260 of circular references 227, as desired. It is recognised that there can be a number of hierarchy levels containing secondary containers 228 (i.e. a secondary container references 227 another secondary container 228 which then references 227 the rules 100, e.g. Block 228b references Block 228c which references the rules 100).

[00101] Further, the benefit hierarchy 360 has a superblock 326, several blocks 328 and several benefits 103, for example. A user is able to expand the benefit hierarchy 360 (e.g. using a hierarchy module 204 of the engine 200 ¨ see Figure 11) by clicking on the '+' buttons and is able to contract the hierarchy 360 by clicking on the '-' buttons via the interface 102 (see Figure 13). In this way a user is able to precisely focus on a particular benefit 103, a block 328 or a superblock 326 as desired. The benefit hierarchy 360 can be a graphical tree view that is similar to a folder tree view of a file system as displayed on the display 152, for example. The nodes on the tree view represent the benefit Objects in the benefit hierarchy 260 in a parent-child relationship.

[00102] The order in which benefits 103 and benefit blocks 326,328 are evaluated by the adjudication engine 40 can affect the adjudication result of the claims 12.
New benefits 103 and blocks 328 can be placed at the bottom of the hierarchy 360 by default, for example. To rearrange the order of the benefits 103 in the hierarchy 360 using the engine 200, a user can drag and drop benefit objects wherever desired so that the new benefit object is in the target node.
When a user moves a benefit object, the engine 200 instructs component modules (e.g. module 202, 204, 206, 208, 210) of the engine 200 to modify the data relationship between the moved benefit objects and to render a new visual benefit hierarchy 360 to the screen 152 as is described below.

[00103] One example implementation of the benefit hierarchy 360 is where individual benefits 103 can only exist at the bottom most benefit container 328 level and that benefit containers 326,328 that contain a benefit object 103 (e.g. via references 327,329) cannot be moved to a different level of the hierarchy 360. These reference limitations, as managed by the Hierarchy manager 204, help to reduce the complexity of maintaining the hierarchy 360 of circular references 327, as desired. It is recognised that there can be a number of hierarchy levels containing secondary containers 328 (i.e. a secondary container references 327 another secondary container 328 which then references 327 the benefits 103, e.g. Block 328 references Block 328 which references the benefits 103).
Composer Rule/Benefit Engine 200

[00104] Reference is next made to Figure 11, which illustrates the Engine 200 of the claims processing environment 10. The engine 200 is for, such as but not limited to, creating, editing, organizing and maintaining adjudication rules 100 in a hierarchical relationship 260 and/or creating, editing, organizing and maintaining adjudication benefit codes 103 in a hierarchical relationship 360, as well as links 240 ¨ see Figure 10 ¨between the rules 100 and benefit codes 103 (it is recognised that the links 240 can also be established between the rules 100 and the blocks 326,328 and/or between the benefits 103 and the blocks 226,228, as desired).

[00105] The engine 200 includes a composer module 202 for creating, editing, deleting and saving individual rules 100 and benefits 103, as well as other objects of the hierarchies 260,360. A user of the engine 2000 interacts with the interfaces 102,152 (see Figure 13) to create, edit, delete and save adjudication rules 100 and benefits 103, as well as the relationships (e.g. parent/child) between blocks 226, blocks 228, and rules 100, as well as the relationships (e.g. parent/child) between blocks 326, blocks 328, and benefits 103 ,as well as their execution order as organized by the ordering of the references 227,229,327,329 within the respective blocks 226,228,326,328. The composer module 202 performs functions as dictated by the user via the interface 102 and the composer module 202 saves adjudication rules 100 into the local database 124 in the form of the rules hierarchy 260. The composer module 202 performs functions as dictated by the user via the interface 102 and the composer module 202 saves adjudication benefit codes 100 into the local database 124 in the form of the benefit hierarchy 360. The engine 200 can also use the composer module 202, for example, to transfer completed hierarchies 260,360 to the storage 224 for use in deployment of the plan 42.

[00106] The engine 200 can also includes a compiler 206 for converting rule and benefit statements into an extensible mark-up language such as XML or into machine readable code, for subsequent use in adjudication of the claims 12 by the adjudication engine 40, whereby the links 240 are used to couple the rules 100 with the benefits 103, for benefits 103 associated with specific rules 100 as is known in the art. In an embodiment of the tool, the compiler 206 converts a rule 100 into XML whenever the user interacts with a compile button (not shown) on the user interface 102. XML is a general-purpose specification for creating custom markup languages. It is classified as an extensible language, because it allows the user to define the mark-up elements. XML's purpose is to aid information systems in sharing structured data of the database 224, especially via the Internet, to encode documents, and to serialize data. In another embodiment, the engine 200 interprets a rule 100 statement in real time and renders an error message if the rule does not meet the syntax standards required and enforced by the engine 200.

[00107] It is also recognised that the engine 200 can also be used for, such as but not limited to, creating, editing, organizing and maintaining the benefit codes 103 in the hierarchical relationship 360. The engine 200 includes the composer module 202 for creating, editing, deleting and saving individual rules 100 and/or benefit codes 103. The composer module 202 performs functions as dictated by the user and thrcomposer module 202 saves benefit codes 103, and their configuration, into the database 224. The engine 200 also includes a compiler 206 for converting benefit code 103 statements into an extensible mark-up language such as XML or into machine readable code. In an embodiment of the tool, the compiler 206 converts the codes 103 into XML whenever the user interacts with a compile button (not shown) on the user interface 102. In another embodiment, the engine 200 interprets code 103 statements in real time and renders an error message to the interface 102 if the code statement 103 does not meet the syntax standards required and enforced by the engine 200. . The engine 200 can also use the composer module 202, for example, to transfer completed hierarchies 260,360 to the storage 224 for use in deployment of the plan 42.

[00108] The order in which codes 103 and blocks 328 are evaluated by the adjudication engine 40 can affect the adjudication result of the claims 12. New codes 103 and blocks 328 are placed at the bottom of the hierarchy 360 by default, for example. To rearrange the order, a user can drag and drop code objects (e.g. codes 103, blocks 326, blocks 328) wherever desired so that the new code object is in the target node. When a user moves a code object, the rule engine 200 instructs component modules of the engine 200 to modify the data relationship between the moved code objects and to render a new visual code hierarchy 360 to the screen (e.g. interface 102) as is described below.

[00109] One example implementation of the code hierarchy 360 is where individual codes 103 can only exist at the bottom most code container 328 level and that containers 326,328 that contain a code object 103 (e.g. via references 327,329) cannot be moved to a different level of the hierarchy 360. These reference limitations, as managed by the Hierarchy manager 204, help to reduce the complexity of maintaining the hierarchy 360 of circular references 327, as desired.
It is recognised that there can be a number of hierarchy levels containing secondary containers 328 (i.e. a secondary container references 327 another secondary container 328 which then references 327 the codes 103.

[00110] Accordingly, the engine 200 can be considered a GUI application for defining plans 24, for eventual deployment in the database 224 for specified carrier/patient relationships.
The engine 200 provides for grammar logic 212 to be based on operators, methods, business objects, and their attributes. Data types may be defined and enforced within the grammar logic 212 definitions, so that, for example, a date can only be compared to a date.
The adjudication engine 40 can export its plan 42 configuration to the composer engine 200 (e.g. into the local memory 124) so that the exported plans 42 can be edited by the composer engine 200, for example. As well, the composer engine 200 is configured so that it can export any changed plan 42 definitions (e.g. content and/or configuration of the hierarchies 260,360) back to the database 224 and have those exported items (e.g. plan components, rule sets benefit sets, rule/benefit blocks, and individual rules 100 /benefits 103, as well as links 240 there-between) re-evaluated and compiled into code (e.g. Java byte code) for use by the engine 40 in adjudication of received claims 12 that pertain to the now redeployed plan 42. It is also recognised that the redeployed plan 42 could also be reconfigured by the plan manager 44 (e.g. for specified inclusion/exclusion of blocks 226,228,326,328, rules 100, benefits 103, links 240) by using the edited plan 42 returned/exported by the engine 200 back to the database 224.
Composer Module 202

[00111] The composer module 202 of the rule engine 200 can provide a graphical view of the rule database called a Rule Map of the rule hierarchy 260 (see Figure 7), as well as a benefit map of the code hierarchy 360, not shown. The Rule Map shows the current Rule Organization and active Rules 100 based on the system date. The Rule Map provides access through the Rule Containers 226, 228 to individual Rules 100 for viewing and editing.
Management of the Rule Container hierarchy 260 can be done through drag/drop and cut/paste features on Rule Map via the rule manager 202, and/or through the hierarchy manager 204, further described below.

[00112] The composer module 202 is used to manage the rule inclusions 227 within a Rule Block 228, for example. As described with reference to Figure 12a, the Timeline 302 feature is applicable to the organization of Rules 100 within Rule Blocks 228.
The Timeline 302 keeps track of where and when Rules 100 are included in the Rule Block 228.
This means that a snapshot of the rule data that is in effect at any point in time is available.
The point in time can be in the past or future. This feature is useful for processing claims 12 that have been back dated and for implementing changes that are future dated, as the rule hierarchy 260 provides guidance for instructing the engine 40 in processing claims 12 using appropriate rules 100 and/or benefits 103 where the claim service date matches the effective/expiry date(s) of the associated references 227,229,327,329.

[00113] It is recognised that timelines 302 are not the same as Rule Versions 300, where:
Rule Versions 300 track the history of changes to the definition of a rule 100. Timelines 302 track when and where a Rule 100 is used and do not specify a particular Rule Version 300, for example. However, it is recognised that the timelines 302 can also be used to specify particular rule versions 300, when desired.

[00114] The Rule Map of the hierarchy 260 can show the Rule 100 organization that is in effect at the current time as determined by the clock (or other defined chronological time) of the user interface 102. The Rule Map displays Rule Inclusions 227 depending on their status, for example using color and font style differences/distinctions (e.g. Expired Rule Inclusions 227 can be displayed in grayed type, unreleased Rule Inclusions 227 can be displayed in normal type, and released Rule Inclusions 227 are displayed in bold type).

[00115] The composer module 202 can provide a detailed view and addition/modification of the Rule Inclusions 227 over time. This view can be logically segmented into Time Spans.
Each Time Span can represent a period in which the Inclusions 227 are static.
The boundary between Time Spans represent the point in time where at least one Inclusion 227 changes. Time spans can be calculated in memory by the application and may not necessarily map one for one with records in a Rule-Rule Block table of the hierarchy 260. For example, A
Rule Dependency Map is displayed on each composer module 202 window (displayed in the interface 102) next to the a Text/Tree View of the rule 100. The Dependency Map can show the all Rule Blocks 228 that reference 227 that rule 100 and in turn the Rule Super Blocks 226 that reference 229 the Rule Blocks 228 (see Figure 7 for example). It is recognised that composer module 202 can configure and display to the user (via the interface 102) current and historical views of the Rule Blocks 226,228.

[00116] It is to be appreciated that a rule statement may be referenced by any number of blocks 228 or superblocks 226; however, each rule 100 will only exist once in the rules database 224.
Dependency Manager 208

[00117] The engine 200 includes a Dependency Manager 208 for tracking the relationship between rules 100 and blocks 228 and superblocks 226. The advantage of using references to rules 100 rather than actual copies is the ability to share common rule objects. Changes made to a rules object are automatically picked up by all the references to the rule object. It is appreciated, however, that with the possibility of any number of references to a rule object it may be difficult to keep track of the dependencies. The dependency manager 208 is operable to manage the dependencies of each rule object and to visually display the dependency relationship as a dependency map for the convenience of the user. The dependency map 242 helps a user keep track of rule dependencies by mapping the rule hierarchy 260 from the bottom up. Each rule container (or rule block 226,228) is shown with its parent container and so on up the family tree. An exemplary dependency map 242 is illustrated in Figure 8. As shown, rule 240 is named '00TEST' and is connected to two different rule blocks 228, namely '01.04A
SERVICE RULE
SET' and '03.02A SERVICE RULE SET'. As shown, the dependency map 242 is shown to the left of the rule editor window 244, although it is to be appreciated that the dependency map 242 may be located in any location on the visual interface. As the user edits the rule 246, the user is able to visualize that each reference to the rule 246 will also be modified.

[00118] The engine 200 includes a Dependency Manager 208 for tracking the relationship between benefits 103 and blocks 328 and superblocks 326. The advantage of using references to benefits 103 rather than actual copies is the ability to share common benefit objects. Changes made to a benefits 103 object are automatically picked up by all the references to the rule object.
It is appreciated, however, that with the possibility of any number of references to a benefit object it may be difficult to keep track of the dependencies. The dependency manager 208 is operable to manage the dependencies of each benefit object and to visually display the dependency relationship as a dependency map for the convenience of the user.
The benefit dependency map helps a user keep track of benefit dependencies by mapping the benefit hierarchy 360 from the bottom up. Each benefit container (block 326,328) is shown with its parent container and so on up the family tree.
Search Module 210

[00119] The rule engine 200 also includes a search module 210 for allowing a user to find a particular rule 100(as well as blocks 226,228) in the rules database 224 for editing, deletion or for analysis. When the user interacts with a searching window on the user interface 102, the rule module 202 communicates with the searching module 210 and instructs the searching module to find rules 100 /blocks 226,228 that correspond to the searching criteria pre-entered by the user.
The searching module 210 queries with the rule database 224 with the searching criteria. If one or more rules 100 /blocks 226,228 are returned from the database 224, the searching module renders the results as a list of rules 100 /blocks 226,228 on the visual interface 102. If no rules 100 /blocks 226,228 are returned from the database 224 that match the searching criteria, the searching module 210 notifies the user that no rules 100 /blocks 226,228 were found.

[00120] The rule engine 200 also includes the search module 210 for allowing a user to find a particular benefit 103 (as well as blocks 326,328) in the rules database 224 for editing, deletion or for analysis. When the user interacts with a searching window on the user interface 102, the module 202 communicates with the searching module 210 and instructs the searching module to find benefits 103 /blocks 326,328 that correspond to the searching criteria pre-entered by the user. The searching module 210 queries with the rule database 224 with the searching criteria. If one or more rules benefits 103 /blocks 326,328 are returned from the database 224, the searching module renders the results as a list of benefits 103 /blocks 326,328 on the visual interface 102. If no benefits 103 /blocks 326,328 are returned from the database 224 that match the searching criteria, the searching module 210 notifies the user that no benefits 103 /blocks 326,328 were found.
Hierarchy Module 204

[00121] The rule engine 200 also includes a hierarchy module 204 for managing the child-parent relationships in the rules database 224 and the visual representation of the hierarchy 260 on the interface 102. The rule engine 200 also includes the hierarchy module 204 for managing the child-parent relationships in the database 224 and the visual representation of the hierarchy 360 on the interface 102.

[00122] Users of the tool interact with rule/benefit objects via the interface 102, an example of which is shown in Figure 9. As shown, a user is able to click on the components of a rule object with a mouse cursor. For example, if the user wishes to change parameter '20000101', the user is able to click on the parameter and directly change its value by typing on the keyboard. Once the user is satisfied with the new value, the user can choose to save the rule 100 in the memory 124 associated with the engine 200. The interaction is processed by the module 202 which is operable to save the new rule 100 /benefit 103 object in the rules database 224. Likewise, when a user moves a rule 100 /benefit 103 to another location in the hierarchy 260, 360, the module 202 instructs the hierarchy module 204 to change the references to the rule 100 / benefits 103 in the rules database 224. The dependency module 208 also manages the dependency relationship and renders the new dependency relationship to the visual interface 102 as a dependency map 242 when the user wishes to view the dependency map 242 for a particular rule 100/ benefit 103.

[00123] The dependency module is also adapted for coupling the adjudication rules 100 to the secondary rule container 228 by the rule reference 227 associated with the content of the secondary rule container 228 and is adapted for coupling the secondary rule container 228 to the primary rule container 226 by the container reference 229 associated with the content of the primary rule container 226, such that the adjudication rules 100, the containers 226,228, and the rule and container references 227,229 define the rule hierarchy 260 for representing the set of adjudication rules.
Business Management Process 400

[00124] Referring to Figure 16, shown is an example workflow of the adjudication environment 10, showing the major components of a business management process 400 for facilitating the adjudication of claims 12 submitted by insured products and/or service providers 15 (e.g. dentists, doctors, pharmacies, etc.) on behalf of the patient 14 (e.g. recipient), for example. In addition to the components of the environment 10 of Figure 1, the example management process 400 includes components such as but not limited to: a fee guide maintenance 402 for monitoring updates to fee guides used by the adjudication engine 40, such that the fee guides map prices to service codes 103 (e.g. government and/or carrier 231 specific);
the above mentioned rule and benefit hierarchy 260, 360 creation process implemented by the composer engine 200; a plan creation and/or enrolment process (collectively referred to as a deployment process 404) as implemented by the plan management engine 44 for facilitating deployment of plans 42 to the database 224 using rule and benefit hierarchies 260, 360 created by the composer engine 200, as further described below; a member enrolment and management process 406 for enrolling providers 15, patients 14, patient groupings (e.g.
companies and other organizations), etc.; a provider update process 408 for maintaining relevant provider 15 information; a claims receiving process 410 configured to receive the claims 12 from a variety of provider/patient sources and for distributing the received claims to the adjudication process 18 for processing by the adjudication engine 40 in view of the appropriate deployed plan(s) 42 stored in the memory 224; a claims management process 412 for reviewing by a review engine 50 the performance of the adjudication process 18 (e.g. level of received claims 12 that had specified types of error(s) during the adjudication process 18) and for modifying 414 the deployed plan 42 and potentially the rules creation process (i.e. operation of the composer engine 200) based on the results generated by the review engine 50; and an inquiry process 416 for providing status and other historical process information for the claims 12 (e.g. reports for transacted claims 12 ¨ e.g. EOBs - as well as status for claim transactions in progress). It is recognised that all of the processes of the business management process 400 can be coupled for interaction with one or more memories 224 (e.g. databases), in order to access data required for implementation of the respective process as well as to store the results of the respective process.

[00125] Further, as shown in Figure 1, it is recognised that the components of the business management process 400 can communicate with one another via one or more communication networks 11, including otherwise than as shown. Further, it is recognised that the interactions between the components and/or between the components and the database(s) 224 can be message based (e.g. request ¨ response), such that or each class of message that forms part of the workflow of the process 400 can be defined as a message that carries out the required steps for the process triggered by the workflow. The result of the completion of the workflow in response to the request message can be a synchronous or asynchronous response message returned to the requestor (or forwarded to another recipient as configured/defined/specified).
For example, an application or functional acknowledgement can be returned in response to the request message.
Plan Management Engine 44

[00126] Referring to Figure 17, shown is an example deployment process 420 for implementation by the plan engine 44, for using the hierarchies 260,360 (e.g.
association of defined blocks 226,228,326,328, references 227,229,327,329, rules 100, benefits 130, and links 240) developed by the composer engine 200. The deployment process 420 can be implemented as a Batch/Real-time process for providing the deployed plans 42 to the database 224 for use by the adjudication engine in processing of the received claims 12. Accordingly, newly published/assigned plans 42or changes/modifications to existing plans 42 are replicated to database 224, so the engine 40 can adjudicate accordingly. As discussed above, the deployed plan can consist of a list of, such as but not limited to: Adjudication Rules 100 (embodied in the hierarchy 260), a list of Service Codes 103 (embodied in the hierarchy 360), a Fee Guide and a set of "fiscal" and other type parameters, for example. For example, the plan 42 defines a set of criteria that need to be checked to determine if a particular service code 103 or package code can be carried out (e.g. on a tooth). An example is that a tooth must exist in order for it to be extracted. The criteria are implemented in the rules 100, such that application of the rules 100 via the hierarchy 260 (i.e. by the adjudication engine 40) are used to determine whether a given service code 103 can be paid by the plan 42, in view of the level of detailed claim information (e.g. claim content) submitted in the claim 12.

[00127] It is recognised the role of the composer engine 200 in the environment 10 is to facilitate Adjudication Rules List Creation to define and combine rule 100 into defined rule Blocks 226,228.(e.g. rule hierarchies 260) and Service Code Coverage List Creation to define and combine Service Codes 103 into defined Benefit Blocks 326,328 .(e.g.
benefit hierarchies 360. The role of the plan engine 44 in the environment 10 is to facilitate the assembly of various blocks 226,228,326,328, rules 100, and benefits 103 from the created hierarchies 260,360 (e.g.
used as template hierarchies 260, 360) of the composer engine 200 and then to customize the template hierarchies 260, 360 through modification (e.g. addition, deletion, override, etc.) of the included blocks 226,228,326,328, rules 100, and benefits 103 in the plan hierarchies 260, 360 customized for a specific carrier 231, provider 15, and/or class of recipient 14. This modification can be implemented by a user (e.g. plan administrator) of the plan engine 44 via the specification of parameters and new/changes to the references 227,229,327,329, rules 100, benefits 130, and links 240 of the template hierarchies 260,360 created by the composer engine 200. Once finalized, i.e. the modification of the template hierarchies 260,360 is completed, the plan 42 containing the modified hierarchies 260,360 is stored in the database 224 as the deployed plan 42, for subsequent use by the adjudication engine 40. It is recognised that the functionality and modules of the engines 44,200 can be as shown, combined, and/or further subdivided other than as shown, as desired. It is also recognised that the engines 44, 200 can be hosted on the same or different computer devices 101. For example, the engines 44, 200 could be hosted on a server device 101 for access over the network 11 by a client device 101 of a user of the functionality of the engines 44, 200.

[00128] Further , it is recognised that any impact on Overrides can be determined at the level of the change and lower. For example, for a Member Plan Change ¨ only the overrides at the Member + Recipient level could be impacted. (etc.). The impact on Overrides can be to those override at a lower level that may not include the Plan Assignment. The Level can inherit the Plan Assignment from the level of the Change. For Example: a Plan Assignment change at a Class Level can have an impact on all Member records in the same Class, which do not have a Plan Assignment at the Member Level but do have Plan Overrides Assigned.

[00129] It is also recognised that related Overrides are any overrides using a block label that existed in the 'old' plan'and' in the 'new' plan. Un-related overrides can be any overrides using a block label that existed in the 'old' plan and NOT in the 'new' plan.
Benefit Coverage Overrides may not be identifiable in this process as they are carried over to the New Plan to remain active. The Overrides available for 're-open' can be those that belong to the Old Plan and have the same Expiry Date as the Old Plan Expiry Date.

[00130] It is also recognised that the modification to the blocks 226,228,326,328 content, via the references 227,229,327,329 can be dated to have an override effective and/or expiry date.
Accordingly, these modifications (e.g. as embodied in the references 227,229,327,329) are considered temporary modifications (e.g. overrides) as the configuration of the hierarchy 260,360 will revert back to the pre-modified state when the chronological date is outside of the override effective and/or expiry date. Further, upon accessing the information details of the existing plan 42 and/or template hierarchies 260,360, the plan engine 44 can provide for a display on the interface 102 all current and/or previous overrides and their associated effective/expiry date(s), where available, to the user of the plan engine 44.
Parameter Values 52

[00131] Carriers 231 that want to include or exclude service codes 103 from a plan 42 (e.g. a plan not yet deployed however is loosely defined using the hierarchies 260,360 created by the composer engine 200) can create lists of inclusions and exclusions for use by the plan engine 44 when creating the final plan 42 for deployment. The inclusions and exclusions can become parameters 52 of the deployed plan 42. This can inhibit the need to create new package identifiers for each Carrier 231. A deployed plan 42 contains a number of "fiscal" parameters 52 that determine how the claim 12 will be adjudicated. Items such as co-insurance, maximum and COB are examples of "fiscal" parameters 52. Parameterized Values 52 can be used to minimize hard-coding and maximize component re-use of the rule and benefit objects created by the composer engine 200. Parameterized values 52 can be defined globally but they can be assigned to plan and/or as override parameters 52 in the hierarchies 260,360. It is recognised that literal values 112, operators 110, and parameter values 114, as shown in Figures 5a,5b, are hereafter referred to as parameters 52.

[00132] Example override details (e.g. parameters 52) of the template hierarchies 260,360 can be details such as but not limited to: Elig. Prof. $ - the amount determined to be eligible after plan coverage and rules, but prior to the application of deductibles, coinsurance and maximum;
Lab Elig. $ - the amount determined to be eligible after plan coverage and rules, but prior to the application of deductibles, coinsurance and maximum; Exp. Elig. $ - the amount determined to be eligible after plan coverage and rules, but prior to the application of deductibles, coinsurance and maximum; Ded. Prof $ - the amount of the deductible applied (professional eligible amount, labl eligible amount, and lab2 eligible amount); Coins. % - the percentage at which the claim item was adjudicated; Max $ - the out of pocket amount due to a reduction in payment because a plan maximum was reached; Lab Ben. $ - the amount payable (after deductible, coinsurance and maximum) for the Lab amount portion of the claimed professional fee; Exp. Ben $ - the amount payable (after deductible, coinsurance and maximum) for the Expense amount portion of the claimed professional fee; Benefit Amount - the amount payable (after deductible, coinsurance and maximum) for the Professional amount portion of the of the claimed Professional Benefit amount; Adjudicated Service Code - enables the user to override the adjudicated service code that was used; and the estimated Benefit Amount.
Member Categories 54

[00133] Referring to Figure 18, shown are example Groups / Divisions /
Units or Members for selection by the plan engine 44 in assigning the deployed plans 42 to, as well as modification of some of the Plan Parameters 52 in the deployed plan 42, for the deployment process 404 (see Figure 16). For example, carriers 231 wish to have Plans 42 set up for groups within a company or an organization. Each group can be made up of members and their dependents. Members are be enrolled with the Carrier 231 before they can be assigned a plan 42, or can be dynamically assigned, as desired, such as upon the delivery of the member's first claim 12 to the adjudication process 18. Typically the plan 42 is assigned/deployed to a group;
occasionally the plan 42 is assigned/deployed to a member or dependent.

[00134] The member categories 54 include member types such as but not limited to:
carrier 231; company; department; unit; subscriber; and recipient 14. It is recognized that the modifications implemented by the plan engine 44 can be associated/assigned to each/any of the member category types 54, as desired. For example, the plan engine 44 can modify the template hierarchies 260,360 in order to make deployed plans 42 specific to different individual recipients 14 (e.g. company president, floor supervisor, shop floor worker), such that the various maximums, minimums, services, products, etc. of the deployed plan 42 have customized parameter values 52 and/or blocks 226,228,326,328, and/or references 227,229,327,329, and/or rules 100, and/or benefits 130, and/or links 240 specific to the individual.
It is recognised that this level of customization afforded by use of the template hierarchies 260,360, through modification by the plan engine 44, provides for ease of customization for plan 42 deployment (and redeployment in the case of modifying an existing deployed plan 42). It is also recognised that the use of the containers and references structure of the hierarchies 260,360 provides for reuse of the basic defined rules 100 and benefits 103 through creation of multiple instances and combinations of those instances. Accordingly, the update of rule 100 and/or benefit 103 content/logic is more easily propagated through all of the various deployed plans 42 that use the updated rule 100 and/or benefit 103 (for example done via the composer engine 200 in the event of a government and/or carrier policy change).

[00135]
The Plan engine 44 can create, modify, and/or maintain the plan components that the plan 42 is composed of. Referring to Figure 19, the plan engine 44 can have a number of components to facilitate modification of the hierarchies 260, 360 obtained from the memory 224 (e.g. template hierarchies 260,360 provided by the composer engine 200, a deployed plan having previously configured hierarchies 260,360, etc.). For example, the plan engine 44 has a data module 440 for obtaining the hierarchies 260, 360 (e.g. from the database 224) and for storing them in a local memory 428; a deployment module 438 for deploying the modified hierarchies 260,360 as the deployed plan in the memory 224; a benefit module for accessing the hierarchy 360 and for updating the contents of the associated benefits 103, blocks 326,328 and references 327,329; a rule module 432 for accessing the hierarchy 260 and for updating the contents of the associated rules 100, blocks 226,228 and references 227,229; a parameter module for updating the parameters 52 of the hierarchies 260,360, for example using ranges of predefined parameters 52 stored in a memory 435 (e.g. a series of parameter tables or other data construct associated with various carriers and/or governmental agencies); and an assignment module 430 for assigning the appropriate member categories 54 to elements (e.g. blocks, rules, benefits, etc.) of the hierarchies 260,360. It is shown that the modules 430,432,434 communicate via the module 436 with the contents of the memory 428, however it is recognised that the modules 430,432,434 can communicate directly with the contents of the memory 428, as desired. Once deployed, the plan 42 is available for use by the adjudication engine 40 for processing the received claims 12.

[00136] Each of the plan 42 components references potentially many parameterized values 52 with default values that can be overridden by Plan engine 44 in the act of publishing/deploying the plan 42, including potential override by the Plan Assignment module 436 in the act of assigning the to be deployed plan 42 to one or more specific enrolment entities.
The components of the plan 42 can include components of the hierarchies 260,360 such as but not limited to: Benefit Super Block 326 for Coverage that can be used to determine if a specific benefit 103 is covered under the plan 42 or not; Benefit Super Block 326 for Adjudication Logic that can be used to restrict the allowable choices for parameterized values 52 of type benefit block 328 ¨ adjudication logic, such as those used in predefined interaction rules, where this type of block 326 can be ignored by the adjudication engine 40 and therefore used as a convenience for the Plan Manager and Plan Assignment user interfaces 102 of the plan engine 44 (e.g. if not set, all benefit blocks 326,328 are displayed as plan components for potential modification);
Benefit Super Block 326 for Plan that can be used to restrict the allowable choices for parameterized values 52 of type benefit block ¨ plan, such as those used by coinsurances or frequency rules 100, where this type of block 226 can be ignored by the adjudication engine 40 and therefore used as a convenience for the Plan Manager and Plan Assignment user interfaces 102 of the plan engine 44 (if not set, all benefit blocks 326,328 are displayed as plan components for potential modification); Rule Super Block 226 for Adjudication Logic can be used to select the complete adjudication logic built using Rules Composer engine 200; Rule Super Block 226 for Carrier Specific Adjudication Logic that can be used to select the carrier 231 specific adjudication logic built using Rules Composer engine 200, if any is used;
and/or other blocks 226,228,326,328 and references 227,229,327,329, as desired.
Benefit module 430

[00137] Referring to Figures 19 and 20, this sub-component or perspective within the Plan engine 44 is used to add/delete/modify the grouping of the benefits 103 appropriately into the benefit blocks 328. These blocks 328 are then included and/or excluded together to form the top level benefit super block(s) 326. The block(s) 326for coverage type defines the list of covered benefits 103. The block(s) 326 are used for various purposes depending on its type for coverage, adjudication logic, or plan. The coverage override type defines those benefits 103 that are being included or excluded for the specific benefit override being assigned, e.g.
via the Assignment module 436.Each benefit 103 can be added/modified/deleted, if needed, using the functionality and modules of the composer engine 200 (e.g. using a business grammar that is supported by a rule evaluation adjudication engine module within the adjudication engine 40).

[00138] For example, using the module 430, the user can gain access to plan details, such as but not limited to: Plan Id - Plan Name ¨ Plan Description; Benefit Super Block ¨ Coverage;
Super Benefit Block Id ¨ Benefit Block Name; Benefit Super Block ¨ Plan; Super Benefit Block Id ¨ Benefit Block Name; Benefit Super Block ¨ Adjudication; Super Benefit Block Id ¨
Benefit Block Name; Coverage tab, Provincial Plan information, Consultant Review requirements, and carrier 231 Alternate Coverage information; Pricing information; Year (e.g.
effective/expiry dates of the plan 42; Specialty (e.g. dental, vision, drug, etc.); Province or other regional jurisdiction; Adjudication Rules via the super blocks 226; and/or Fiscal information/parameters 52.

[00139] It is recognised that for each of the accessed plan details on the user interface 102, the module 430 can display the appropriate Super Block ID & Name; and associated appropriate Rule Block ID & Name. It is also recognised that the modification of the hierarchy 360 information would include changes to the references 327,329 of the benefit objects, including changes such as but not limited to: changes in the effective date of the references 327,329;
changes in the expiry date of the references 327,329; changes in the benefit object version associated with the references 327,329; changes to the definition content of the benefit codes 103 and/or the benefit blocks 328; and/or inclusion or exclusion of the references 327,329 in the respective block 326,328, as well as changes to the ordering of the references 327,329 in the respective block 326,328.

[00140] For example, the module 430 can be used to modify benefits 103 within the block 328, add/delete Benefit Code(s) 103 to a Block 328, add/delete Blocks 328 to a super block 326, add/remove Benefit Code(s) 103 from a Block 326, set Expiry Date for Benefit(s) in a Block 328, Set Effective Date for Benefits 103 in a Block 328, set Expiry Date for block(s) 328 listed in a Block 326, Set Effective Date for block(s) 328 listed in a Block 326. It is recognised that, as described above, the inclusion of blocks 328 in blocks 326 and the benefits 103 in blocks 328 is coordinated in the hierarchy 360 via the listing of the references 327,329 in the appropriate blocks 326,328.

[00141] If finished, then the deployment module 438 can be used to save the modified Plan 42 and then the saved plan 42 is deployed to the database 224.
Rule module 432

[00142] Referring to Figures 19 and 20, this sub-component or perspective within the Plan engine 44 is used to add/modify/delete the rules that implement the actual complex business logic within the adjudication engine 40. These rules 100 are then included and/or excluded together and are grouped (via modifications to the references 227) into the rule blocks 228.
These blocks 228 are in turn are then included and/or excluded together and grouped (via modifications to the references 229) into one or more rule super block 226, which can define the complete set of business logic to be evaluated (e.g. including order of execution of the listed blocks 228) when this specific block 226is selected. Each rule 100 can be added/modified/deleted, if needed, using the functionality and modules of the composer engine 200 (e.g. using a business grammar that is supported by a rule evaluation adjudication engine module within the adjudication engine 40).

[00143] For example, using the module 430, the user can gain access to plan details, such as but not limited to: Plan Id - Plan Name ¨ Plan Description; Benefit Super Block¨ Coverage;
Super Benefit Block Id ¨ Benefit Block Name; Benefit Super Block ¨ Plan; Super Benefit Block Id ¨ Benefit Block Name; Benefit Super Block ¨ Adjudication; Super Benefit Block Id ¨
Benefit Block Name; Coverage tab, Provincial Plan information, Consultant Review requirements, and carrier 231 Alternate Coverage information; Pricing information; Year (e.g.
effective/expiry dates of the plan 42; Specialty (e.g. dental, vision, drug, etc.); Province or other regional jurisdiction; Adjudication Rules via the super blocks 226; and/or Fiscal information/parameters 52.

[00144] It is recognised that for each of the accesed plan details on the user interface 102, the module 430 can display the appropriate Super Block ID & Name; and associated appropriate Rule Block ID & Name. It is also recognised that the modification of the hierarchy 260 information would include changes to the references 227,229 of the benefit objects, including changes such as but not limited to: changes in the effective date of the references 227,229;
changes in the expiry date of the references 227,229; changes in the benefit object version associated with the references 227,229; changes to the definition content of the rules 100 and/or the benefit blocks 228 (e.g. selecting specific versions 300 of the rule objects ¨ e.g. rules 100);
and/or inclusion or exclusion of the references 227,229 in the respective block 226,228, as well as changes to the ordering of the references 227,229 in the respective block 226,228.

[00145] For example, the module 432 can be used to modify rules 100 within the block 228, add/delete rules 100 to a Block 228, add/delete Blocks 228 to a super block 226, add/remove rules 100 from a Block 226, set Expiry Date for rules 100 in a Block 228, Set Effective Date for rules 100 in a Block 228, set Expiry Date for block(s) 228 listed in a Block 226, Set Effective Date for block(s) 228 listed in a Block 226, and add/delete versions 300 of the rule objects in the corresponding blocks 226,228. It is recognised that, as described above, the inclusion of blocks 228 in blocks 226 and the rules 100 in blocks 228 is coordinated in the hierarchy 260 via the listing of the references 227,229 in the appropriate blocks 226,228.

[00146] If finished, then the deployment module 438 can be used to save the modified Plan 42 and then the saved plan 42 is deployed to the database 224.
Parameter module 434

[00147] Referring to Figures 19 and 20, this sub-component or perspective within the Plan engine 44 is used to add/delete/modify or otherwise define the parameterized values 52 used within rules 100 and benefits 103, as well as the references 227,229,327,329 where appropriate.
This modification of the parameters 52 provides for a generic set of rules 100/ benefits 103 to be defined (e.g. the template hierarchies 260,360) and then reused with different specific values 52 that are assigned/associated for plan 42 deployment.

[00148] It is recognised that the override of the Effective date of the references 227,229,327,329 may not be prior to the 'inherited' Plan 42 Effective Date and may not be after the Plan 42 Expiry Date. Further, the override Expiry Date may not be prior to the 'inherited' Plan 42 Effective Date and may not be after the Plan 42 Expiry Date.
Accordingly, the created/modified Date Range must be within the Plan 42 Effective and Expiry Date Range.
Assignment module 436

[00149] Referring to Figures 19 and 20, this sub-component or perspective within the Plan engine 44 is used to add/delete/modify (e.g. override values, override references 227,229,327,329, etc.) the member categories 54 that are associated with the plan 42 to be deployed. For example, before the Plan Assignment Process can begin, the User of the plan engine 44 determines at what level the Plan Assignment is to be performed (e.g. Carrier, Group, Division, Unit/Class, Member, Recipient of the categories 54). The User determines which of the existing Base Plans 42 (e.g. template hierarchies 260,360, already deployed plans 42, etc.) are most appropriate to use. The User determines what 'overrides' to the Base Plan are desired.

[00150] For example, depending on whether or not it is a Single Plan Assignment or a Bulk Plan Assignment will determine what path to Select. For example, for a Single Member-Recipient Assignment, the user can perform a Member Enrolment search until the appropriate record is found. Once the record is selected, the user can request Plan Assignment via the module 436 and be presented with the Plan Assignment screen 102 to enter in the details. For a Single Assignment to a record within the Group Hierarchy (Group/Division/Class), the user can perform a Group Enrolment search until the appropriate record is found. Once the record is selected, the user can request the Plan Assignment via the module 436 and be presented with the Plan Assignment screen 102 to enter in the details. For a Bulk Plan Assignment, the User can input the details of the appropriate level desired via the module 436, e.g.
Insurer + Group +
Division, Or Insurer + Group + Class. The user can then be presented with a data entry screen 102, which provides for the user to enter the appropriate Division/Class codes via the module 436. Once the keyed list is complete, the user can select the Plan Assignment screen 102 and enter in the details via the module 436.
Review Engine 50

[00151] Referring to Figure 16, shown is an example claims management process 412 for reviewing by a review engine 50 the performance of the adjudication process 18 (e.g. level of received claims 12 that had specified types of error(s) during the adjudication process 18) and for modifying/revising 414 the deployed plan 42 and potentially the rules creation process (i.e.
operation of the composer engine 200) via updates/revisions 55 (see Figure 22) based on the results generated by the review engine 50. It is recognised that based on the potential for revision/reconfiguration of the hierarchies 260,360, via the review engine 50, in view of the analysis of the queued claim 12, it is understood that iterative updates/revisions 55 of the hierarchies 260,360 (e.g. of the plan(s) 42) may provide for increases in auto adjudication levels for the received claims 12, in view of iterative updates/revisions 55 of the hierarchies 260,360 based on claim review (by a claim module 536 ¨ see Figure 24), of the claims 12 submitted to the claims queue 53.

[00152] Referring to Figure 22, shown is an example interaction of system components, including the engines 44,50,200 with one another and with content (e.g. plans 24 and hierarchies 260,360) in the database 224. It is recognised that the review engine 50 coordinates any updates/revisions 55 to deployed plans 42 and/or to the template hierarchies 260,360 (i.e. those created by the composer engine 200) used in the development of the deployed plans 42.

[00153] It is recognised that the update/revision information/data 55 can be performed directly by the review engine 50, can be sent to the composer engine 200 to facilitate review/updates performed by the composer engine 200, can be sent to the plan engine 200 to facilitate review/updates performed by the plan engine 200, or a combination thereof. Also, it is recognised that the updates and/or revisions 55 can be performed on a claim 12 by claim 12 basis (e.g. using manual overrides specific only to that claim 12 instance), can be performed on the plan 42 itself that is associated with the reviewed claim (e.g. the plan data ¨ including the plan hierarchies 260,360), and/or can be performed on the template hierarchies 260,360 (e.g. those hierarchies 260,360 used to develop the plan 42 under review).

[00154] Referring to Figure 23, shown are example processes 412,414 for implementation by the review engine 50, for facilitating the revision 55 of the hierarchies 260,360 /plan 42 (e.g.

association of defined blocks 226,228,326,328, references 227,229,327,329, rules 100, benefits 130, and links 240 ¨ see Figure 10) developed by the composer engine 200 and/or plan engine 44, in response to analysis of claims 12 forwarded to a claims queue 53 by the adjudication engine 40 (for currently pended claims 12) and/or an administration entity (not shown) that is responsible for quality control/audit procedures of already transacted claims 12 (e.g. no longer in the adjudication process 18). The processes 412,414 can be implemented as Batch or Real-time processes for providing the revised/updated plans 42 and/or template/generic hierarchies 260,360 to the database 224, for use by the adjudication engine 40 in processing of the subsequently received claims 12, for use by the plan engine 44 for making changes (e.g. in the assignment of) the revised plan 42, and/or for use by the composer engine 200 for making changes to the template hierarchies 260,360.

[00155] Accordingly, changes/modifications to existing plans 42 and/or the template hierarchies 260,360 are replicated to database 224, so the engine 40 can adjudicate accordingly with the revised plan 42. As discussed, the revised plan 42 can consist of revised items, such as but not limited to: Adjudication Rules 100 (embodied in the hierarchy 260), a list of Service Codes 103 (embodied in the hierarchy 360), a Fee Guide and a set of "fiscal"
and other type parameters, for example. For example, the revised plan 42 defines a set of criteria that need to be checked to determine if a particular service code 103 or package code can be carried out (e.g. on a tooth). An example is that a tooth must exist in order for it to be extracted. The criteria are implemented in the rules 100, such that application of the rules 100 via the hierarchy 260 (i.e. by the adjudication engine 40) are used to determine whether a given service code 103 (as defined in the hierarchy 360) can be paid by the revised plan 42, in view of the reviewed level of detailed claim information (e.g. claim content) in the reviewed claim 12 or claims 12.

[00156] It is recognised the role of the composer engine 200 in the environment 10 is to facilitate Adjudication Rules List Creation to define and combine rule 100 into defined rule Blocks 226,228.(e.g. rule hierarchies 260) and Service Code Coverage List Creation to define and combine Service Codes 103 into defined Benefit Blocks 326,328 .(e.g.
benefit hierarchies 360, for example for use as template hierarchies 260,360 for use in plan 42 customization and deployment, as described above. Further, the role of the plan engine 44 in the environment 10 is to facilitate the assembly of various blocks 226,228,326,328, rules 100, and benefits 103 from the created hierarchies 260,360 (e.g. used as template hierarchies 260, 360) of the composer engine 200 and then to customize the template hierarchies 260, 360 through modification (e.g.
addition, deletion, override, etc.) of the included blocks 226,228,326,328, rules 100, and benefits 103 in the plan hierarchies 260, 360 customized for a specific carrier 231, provider 15, and/or class of recipient 14. This modification can be implemented by a user (e.g.
plan administrator) of the plan engine 44 via the specification of parameters and new/changes to the references 227,229,327,329, rules 100, benefits 130, and links 240 of the template hierarchies 260,360 created by the composer engine 200. Once finalized, i.e. the modification of the template hierarchies 260,360 is completed, the plan 42 containing the modified hierarchies 260,360 is stored in the database 224 as the deployed plan 42, for subsequent use by the adjudication engine 40. It is recognised that the functionality and modules of the engines 44, 50,200 can be as shown, combined, and/or further subdivided other than as shown, as desired. It is also recognised that the engines 44, 50, 200 can be hosted on the same or different computer devices 101. For example, the engines 44, 50, 200 could be hosted on a server device 101 for access over the network 11 by a client device 101 of a user of the functionality of the engines 44, 50, 200.

[00157] Further, the role of the review engine 50 in the environment 10 is to facilitate the revision 55 of various blocks 226,228,326,328, rules 100, and benefits 103 from the created hierarchies 260,360 (e.g. used as template hierarchies 260, 360, parameterized and deployed in the plan 42 under revision) and then to revise the hierarchies 260, 360 through revision 55 (e.g.
addition, deletion, modification, override, etc.) of the included blocks 226,228,326,328, rules 100, and benefits 103 in the plan hierarchies 260, 360 customized for a specific carrier 231, provider 15, and/or class of recipient 14. This revision 55 of the hierarchies 260,360 is done in view of errors or other deficiencies recognised/identified in claims 12 obtained from the claims queue 53, and can be implemented by a user (e.g. plan/claim administrator) of the review engine 50 via the revision 55 of parameters 52and revisions/changes 55 to the references 227,229,327,329, rules 100, benefits 130, and links 240 of the hierarchies 260,360 of the plan 42 under review.

[00158] Once finalized, i.e. the revision 55 of the hierarchies 260,360 is completed, the revised plan 42 containing the modified hierarchies 260,360 is stored in the database 224 as the revised deployed plan 42, for subsequent use by the adjudication engine 40. It is recognised that the functionality and modules of the engines 44, 50, 200 can be as shown, combined, and/or further subdivided other than as shown, as desired. It is also recognised that the engines 44, 50, 200 can be hosted on the same or different computer devices 101. For example, the engines 44, 50, 200 could be hosted on a server device 101 for access over the network 11 by a client device 101 of a user of the functionality of the engines 44, 50, 200.
Queues 53

[00159] The claims 12 for review can be forwarded to the claims queue 53 by the adjudication engine 40 (for currently pended claims 12) and/or an administration entity (not shown) that is responsible for quality control/audit procedures of already transacted claims 12 (e.g. no longer in the adjudication process 18). There can be 2 types of workflow queues, personal and group (of adjudicator) based queues. When claims 12 are pended by the adjudication engine 40, they are put into group based queues 53. People can be assigned group based queues 53 and can use 'the engine 50 functionality to pull the claim 12 off the general queue 53 for subsequent review. It is also recognised that the engine 50 can be automated to pull any claims 12 off the queue 53 for subsequent analysis/review by the modules of the engine 50, e.g. a personal review.

[00160] The queue 53 can also contain claims 12 submitted due to potential fraud considerations, as identified by the engine 40 and/or other third party entities (not shown) of the environment 10. As further described below, anti-Fraud determination of claims 12 in the queue 53 can be managed by a screen(s) 102 in the review engine 50. This can be a table driven feature with a custom module in the engine 50 to execute the logic for review and possible revision/reconfiguration of the claim 12 and/or the hierarchies 260,360 associated with the claim 12 (e.g. through the modules 536,530,532,534, for example). The table data can be updated in real-time, and it is understood that Anti-Fraud can sometimes make mistakes and either miss, or catch too many claims 12, at least initially. However, based on the potential for revision/reconfiguration of the hierarchies 260,360, via the review engine 50, in view of the analysis of the queued claim 12, it is understood that iterative updates/revisions 55 of the hierarchies 260,360 (e.g. of the plan(s) 42) may provide for increases in auto adjudication levels for the received claims 12, in view of iterative updates/revisions 55 of the hierarchies 260,360 based on claim review (by a claim module 536 ¨ see Figure 24) of the claims 12 submitted to the claims queue 53.

[00161] Further, the contents of the claims queue 53 can also be based on claims 12 submitted to the queue 53 for Quality Control purposes. For example, the environment 10 could be configured to see a certain % of claims 12 touched by each adjudicator and/or the adjudication engine 40. The actual number of claims 12chosen for submission to the claims queue 53 due to QC can be based on some time period.

[00162] It is recognised that the contents of the claim queue 53 can be submitted based on an automated, semi-automated, and/or manual claim selection process. In the case of an automated process, the adjudication engine 40 submits claims 12 to the claims queue 53 based on the mismatch of the claim 12 content processing with the plan 42 content associated with the claim 12. In the case of manual or semi-automated, the workflow of claims submitted to the queue 53 can be managed by an administrator type role (not shown). It is recognised that, based on the potential for revision/reconfiguration of the hierarchies 260,360, via the review engine 50, in view of the analysis of the queued claim 12, it is understood that iterative updates/revisions 55 of the hierarchies 260,360 (e.g. of the plan(s) 42) may provide for increases in auto adjudication levels for the received claims 12, in view of periodic (e.g. as a result of the review of the claims 12 over time from the queue 53) iterative updates/revisions 55 of the hierarchies 260,360 based on claim review (by a claim module 536 ¨ see Figure 24) of the claims 12 submitted to the claims queue 53.
Engine 50 Modules

[00163] The engine 50 can revise/reconfigure (e.g. create, modify, and/or maintain) the plan components that the plan 42 is composed of, in view of the review results of the claim(s) 12 obtained from the claim queue 53. Referring to Figure 24, the engine 50 can have a number of components to facilitate revision of the hierarchies 260, 360 obtained from the memory 224 (e.g.
template hierarchies 260,360 provided by the composer engine 200, a deployed plan having previously configured hierarchies 260,360, etc.). For example, the engine 50 has a claim module 536 for obtaining the claim(s) 12 from the claim queue 53 and for analysing any errors identified in the obtained claim(s) 12. For example, the errors identified in the obtained claim(s) 12 can be one or more error categories such as but not limited to: claims adjudication ¨
review claims 12 pended from the engine 40; quality control ¨ verify accuracy of transacted claims 12 touched by claims adjudicators and/or the engine 40; and/or anti-fraud ¨ review claims flagged as (possibly) fraudulent. The engine 50 can also have a validation module 538 for facilitating validation of the revisions/reconfigurations 55 of the hierarchies 260,360 associated with the claims 12 received from the queue 53. Further, the engine 50 can have a data module 540 for obtaining the hierarchies 260, 360 (e.g. from the database 224) and for storing them in a local memory 528 (for example) for subsequent revision/reconfiguration using the updates 55.

[00164] Further, the engine 50 can have a deployment module 538 for deploying the modified hierarchies 260,360 as the deployed plan in the memory 224, a benefit module 530 for accessing the hierarchy 360 and for updating the contents of the associated benefits 103, blocks 326,328 and references 327,329 based on the generated revisions/reconfigurations 55 of the claims module 536 in view of the analysis of the claim(s) 12 obtained from the queue 53.
Further, the engine 50 can have a rule module 532 for accessing the hierarchy 260 and for updating the contents of the associated rules 100, blocks 226,228 and references 227,229 based on the generated revisions/reconfigurations 55 of the claims module 536 in view of the analysis of the claim(s) 12 obtained from the queue 53. Further, the engine 50 can have a parameter module 534 for updating the parameters 52 of the hierarchies 260,360, for example using ranges of predefined parameters 52 stored in a memory 535 (e.g. a series of parameter tables or other data construct associated with various carriers and/or governmental agencies) based on the generated revisions/reconfigurations 55 of the claims module 536 in view of the analysis of the claim(s) 12 obtained from the queue 53. It is shown that the modules 530,532,534 communicate via the module 538 with the contents of the memory 528, however it is recognised that the modules 530,532,534 can communicate directly with the contents of the memory 528, as desired.
Once deployed, the revised plan 42 is available for use by the adjudication engine 40 for processing the received claims 12 and/or for reprocessing the appropriate claims 12 from the queue 53.

[00165] It is recognised that the modules 530,532,534 can be referred to collectively as reconfiguration modules.

[00166] Each of the plan 42 components references potentially many parameterized values 52 with default values that can be revised by engine 50 in the act of reconfiguring and deploying the revised plan 42. The components of the plan 42 can include components of the hierarchies 260,360 such as but not limited to: Benefit Super Block 326 for Coverage that can be used to determine if a specific benefit 103 is covered under the plan 42 or not;
Benefit Super Block 326 for Adjudication Logic that can be used to restrict the allowable choices for parameterized values 52 of type benefit block 328 ¨ adjudication logic, such as those used in predefined interaction rules, where this type of block 326 can be ignored by the adjudication engine 40 and therefore used as a convenience for the Plan Manager and Plan Assignment user interfaces 102 of the engine 50 (e.g. if not set, all benefit blocks 326,328 are displayed as plan components for potential revision); Benefit Super Block 326 for Plan that can be used to restrict the allowable revision choices for parameterized values 52 of type benefit block ¨ plan, such as those used by coinsurances or frequency rules 100, where this type of block 226 can be ignored by the adjudication engine 40 and therefore used as a convenience for the Plan Manager and Plan Assignment user interfaces 102 of the engine 50 (if not set, all benefit blocks 326,328 are displayed as plan components for potential revision); Rule Super Block 226 for Adjudication Logic can be used to select the complete adjudication logic built using Rules Composer engine 200; Rule Super Block 226 for Carrier Specific Adjudication Logic that can be used to select the carrier 231 specific adjudication logic built using Rules Composer engine 200, if any is used;
and/or other blocks 226,228,326,328 and references 227,229,327,329, as desired.

[00167] It is recognised that the modules 530, 532, 534 can be hosted independently by the review engine 50 and/or can be hosted by the other engine(s) 44, 200 and therefore called by the engine 50, when needed. For example, the review engine 50 can use the functionality of the composer engine 200, when updates/revisions 55 are applied to the rules 100, benefits 103, blocks 227,228,327,328, and/or the references 227,229,327,329, as desired.
Claim Module 536

[00168] The claim module 536 is configured for obtaining the claim(s) 12 from the claim queue 55 and for analysing any errors identified in the obtained claim(s) 12.
For example, the errors identified in the obtained claim(s) 12 can be one or more error categories such as but not limited to: claims adjudication ¨ review claims 12 pended from the engine 40;
quality control ¨
verify accuracy of transacted claims 12 touched by claims adjudicators and/or the engine 40;
and/or anti-fraud ¨ review claims flagged as (possibly) fraudulent. Further, error levels can be communicated to the user via the user interface 102 that describes if there are any problems with the claim 12 (e.g. identified by the adjudication engine 40). Based on the error level of the response (> 0) various revision/reconfiguration actions can be taken by the claim module 536.

[00169] Referring to Figure 25, the claim module 536 provides the details of the Claim(s) 12 (e.g. pended) to the user interface 102. the use of the engine 50 can, for example, review the claim information 550, procedure information 552, associated parameter 52 information 554, as well as any rule 100 and/or benefit 103 information 556 (e.g. any aspect of the hierarchies 260,360 content that is related to the particular information 550,552,554 being reviewed in association with the identified error and/or quality control/anti-fraud reason for the claim 12 being submitted to the claim queue 53.

[00170] For example, view and potential edit ability the following Procedure List 552 can be performed by the user in consultation with the user interface 102, namely:
Actions; Engine Messages ¨ Exemptions; EOB Correspondence; View Eligibility; View Transaction Details; and/
or View Claim Experience. For example, the screen 102 can also display the change list as a summary of the revisions 55, including such as but not limited to; User ¨
identifies who made the data change; Date ¨ identifies what date the change was made; Field ¨
identifies the field of the data change; Old Value 52 or rule 100 or benefit 103 or reference 227,229,327,329 or link 240 ¨
identifies what the Value 52 or rule 100 or benefit 103 or reference 227,229,327,329 or link 240 was before the change; and new Value 52 or rule 100 or benefit 103 or reference 227,229,327,329 or link 240 ¨ identifies what the Value 52 or rule 100 or benefit 103 or reference 227,229,327,329 or link 240 was after the change.

[00171] A claim Actions tab 558, see Figure 25, provides for users of the engine 50 to perform various functions against the current claim 12 under review, as obtained from the queue 53. The available actions 558 can depend on the current user's role and the claim's 12 current state. Saving information on the Actions tab can automatically save changes to the hierarchies 260,360 associated with the reviewed claim 12 (e.g. data concerning Eligibility, Member Eligibility, Pre-determination, and Claim Details, for example). To perform an action on the reviewed claim 12, the user, for example: under services, clicks to select Claim 12; opens the claim 12 on which one wants to perform the action (e.g.
revisions/reconfigurations 55; selects the Actions tab, where the current user's role and the claim's current state can dictate the available actions (e.g. the degree and what ability to implement changes to the claim 12 and/or the associated hierarchies 260,360); clicks to select the appropriate action, and enters/selects any necessary changes (e.g. parameter 52, references 227,229,327,329, etc.); and clicks Save to save the changes as the updates/revisions 55.

[00172] Other revisions/reconfigurations 55 possible are for Merge/Unmerge of Patients 14 in the plan 42. For example, The engine 50 can have a screen dedicated to Merging and Unmerging patients, where: Merge two (or more) patient records are found to actually be the same patient, where merging patients is a matter of choosing one record to use on a go forward basis, expire duplicate records and link back to chosen record accordingly (note, one may need to evaluate and decide if any claims 12 need to be re-processed because of revisions/reconfigurations 55 related to the patient merge/unmerge); and Unmerge where it is found that a previously performed merge was in fact performed in error and the records need to be set back to their original state, involving the steps of update 55 patient record to make it active and unlink merge field and update 55 so that it accurately reflects the products and services performed for that patient (note - identify any claims 12 that may have to be re-adjudicated because of this error situation).
Validation Module 538

[00173] This validation module 538 functionality allows the user to collect the revised/reconfigured claim 12 and/or associated hierarchy 260,360 details and submit them to the adjudication engine 40, for example. The adjudication results 13 are presented back to the user to determine if the changes 55 made resulted in the desired adjudication results.

[00174] The validation module 538 facilitates validation of the revisions/reconfigurations 55 of the hierarchies 260,360 associated with the claims 12 received from the queue 53. For example, the user can save the revisions/reconfigurations 55 done via the modules 530,532,534 and then send the claim(s) 12 for re-adjudication to the engine 40, using the revised plan 42 incorporating the revisions/reconfigurations 55. The user can then verify or otherwise validate that the re-adjudication claim 12 results are desirable and therefore mark or otherwise flag (e.g.
release) the associated revisions/reconfigurations 55 as deployed for subsequent adjudication of other claims 12 (those not in the queue 53), as desired, or can mark or otherwise flag (e.g.
release) the revisions/reconfigurations 55 only for use in re-adjudication of the claims 12 obtained from the queue 53. The adjudication engine 40 will implement the revised plan 42 for the claims 12, as dictated by the marking of the revisions/reconfigurations 55.
Benefit module 530

[00175] Referring to Figure 24, this sub-component or perspective within the engine 50, for example, is used to add/delete/modify the grouping of the benefits 103 appropriately into the benefit blocks 328. These blocks 328 are then included and/or excluded together to form the top level benefit super block(s) 326. The block(s) 326for coverage type defines the list of covered benefits 103. The block(s) 326 are used for various purposes depending on its type for coverage, adjudication logic, or plan. The coverage revision type defines those benefits 103 that are being included or excluded for the specific benefit revision being validated, e.g.
via the validation module 538.Each benefit 103 can be added/modified/deleted, if needed, using the functionality and modules of the engine 50 (e.g. using a business grammar that is supported by a rule evaluation adjudication engine module within the adjudication engine 40).

[00176] For example, using the module 530, the user can gain access to and revise plan details, such as but not limited to: Plan Id - Plan Name ¨ Plan Description;
Benefit Super Block ¨
Coverage; Super Benefit Block Id ¨ Benefit Block Name; Benefit Super Block ¨
Plan; Super Benefit Block Id ¨ Benefit Block Name; Benefit Super Block ¨ Adjudication;
Super Benefit Block Id ¨ Benefit Block Name; Coverage tab, Provincial Plan information, Consultant Review requirements, and carrier 231 Alternate Coverage information; Pricing information; Year (e.g.
effective/expiry dates of the plan 42; Specialty (e.g. dental, vision, drug, etc.); Province or other regional jurisdiction; Adjudication Rules via the super blocks 226; and/or Fiscal information/parameters 52.

[00177] It is recognised that for each of the accessed/revised plan details on the user interface 102, the module 530 can display the appropriate Super Block ID &
Name; and associated appropriate Rule Block ID & Name. It is also recognised that the modification of the hierarchy 360 information would include changes/revisions to the references 327,329 of the benefit objects, including changes/revisions such as but not limited to:
changes in the effective date of the references 327,329; changes in the expiry date of the references 327,329; changes in the benefit object version associated with the references 327,329; changes to the definition content of the benefit codes 103 and/or the benefit blocks 328; and/or inclusion or exclusion of the references 327,329 in the respective block 326,328, as well as changes to the ordering of the references 327,329 in the respective block 326,328.

[00178] For example, the module 530 can be used to revise benefits 103 within the block 328, add/delete Benefit Code(s) 103 to a Block 328, add/delete Blocks 328 to a super block 326, add/remove Benefit Code(s) 103 from a Block 326, set Expiry Date for Benefit(s) in a Block 328, Set Effective Date for Benefits 103 in a Block 328, set Expiry Date for block(s) 328 listed in a Block 326, Set Effective Date for block(s) 328 listed in a Block 326. It is recognised that, as described above, the inclusion of blocks 328 in blocks 326 and the benefits 103 in blocks 328 is coordinated in the hierarchy 360 via the listing of the references 327,329 in the appropriate blocks 326,328.

[00179] If finished, then the deployment module 538 can be used to save the modified Plan 42 and then the revised plan 42 is deployed to the database 224.

[00180] Overrides (e.g. updates/revisions 55) of references 227,229,327,329 content and other content of the hierarchies 260,360, as well as specific rules 100 and/or benefits 103 can be manual (i.e. specific only to the claim 12 or set of claims 12 being reviewed from the queue 53), can be applied to revise the deployed plan 42 so that other claims 12 other than the reviewed claims 12 of the queue 53 will be affected (i.e. their adjudication by the engine 40 will take into account any changes to the hierarchies 260,360 relevant to the other claims 12), and/or can be applied to revise the template hierarchies 260,360 used to develop the plan 42 under review (i.e.
the plan 42 associated with the claim 12 or set of claims 12 being reviewed from the queue 53) so that other plans 42 other than the reviewed plan 42 will be affected (i.e.
claim 12 adjudication by the engine 40 will take into account any changes to the hierarchies 260,360 of the other plans 42).

[00181] It is also recognised that related revisions 55 can be any revisions 55 using a block label that existed in the 'old' plan 'and' in the 'revised' plan. Un-related revisions 55 can be any revisions 55 using a block label that existed in the 'old' plan and NOT
in the 'revised' plan. Benefit Coverage revisions 55 may not be identifiable in this process as they are carried over to the New Plan to remain active. The revisions 55 available for 're-open' can be those that belong to the Old Plan and have the same Expiry Date as the Old Plan Expiry Date.

[00182] It is also recognised that the revisions 55 to the blocks 226,228,326,328 content, via the references 227,229,327,329 can be dated to have an revision effective and/or expiry date.
Accordingly, these revisions 55 (e.g. as embodied in the references 227,229,327,329) can be considered temporary revisions 55 (e.g. overrides) as the configuration of the hierarchy 260,360 will revert back to the pre-revision 55 state when the chronological date is outside of the revision effective and/or expiry date. Further, upon accessing the information details of the reviewed plan 42 and/or template hierarchies 260,360, the engine 50 can provide for a display on the interface 102 all current and/or previous revisions 55 and their associated effective/expiry date(s), where available, to the user of the engine 50.
Rule module 532

[00183] It is recognised that the engine 50 may display Rule/benefit details relevant to the claim 12 obtained from the queue 53. Referring to Figure 24, this sub-component or perspective within the engine 50, for example, is used to revise (e.g. add/modify/delete) the rules 100 that implement the actual complex business logic within the adjudication engine 40.
These rules 100 are then included and/or excluded together and are grouped (via revisions 55 to the references 227) into the rule blocks 228. These blocks 228 are in turn are then included and/or excluded together and grouped (via revisions 55 to the references 229) into one or more rule super block 226, which can define the complete set of business logic to be evaluated (e.g.
including order of execution of the listed blocks 228) when this specific block 226 is selected.
Each rule 100 can be revise (e.g. add/modify/delete), if needed, using the functionality and modules of the engine 50 (e.g. using a business grammar that is supported by a rule evaluation adjudication engine module within the adjudication engine 40).

[00184] For example, using the module 530, the user can gain access to and revise plan details, such as but not limited to: Plan Id - Plan Name ¨ Plan Description;
Benefit Super Block ¨
Coverage; Super Benefit Block Id ¨ Benefit Block Name; Benefit Super Block ¨
Plan; Super Benefit Block Id ¨ Benefit Block Name; Benefit Super Block ¨ Adjudication;
Super Benefit Block Id ¨ Benefit Block Name; Coverage tab, Provincial Plan information, Consultant Review requirements, and carrier 231 Alternate Coverage information; Pricing information; Year (e.g.
effective/expiry dates of the plan 42; Specialty (e.g. dental, vision, drug, etc.); Province or other regional jurisdiction; Adjudication Rules via the super blocks 226; and/or Fiscal information/parameters 52.

[00185] It is recognised that for each of the accessed and revised plan details on the user interface 102, the module 530 can display the appropriate Super Block ID &
Name; and associated appropriate Rule Block ID & Name. It is also recognised that the modification of the hierarchy 260 information would include changes to the references 227,229 of the benefit objects, including changes/revisions such as but not limited to: changes in the effective date of the references 227,229; changes in the expiry date of the references 227,229;
changes in the benefit object version associated with the references 227,229; changes to the definition content of the rules 100 and/or the benefit blocks 228 (e.g. selecting specific versions 300 of the rule objects ¨ e.g. rules 100); and/or inclusion or exclusion of the references 227,229 in the respective block 226,228, as well as changes to the ordering of the references 227,229 in the respective block 226,228.

[00186] For example, the module 532 can be used to revise rules 100 within the block 228, add/delete rules 100 to a Block 228, add/delete Blocks 228 to a super block 226, add/remove rules 100 from a Block 226, set Expiry Date for rules 100 in a Block 228, Set Effective Date for rules 100 in a Block 228, set Expiry Date for block(s) 228 listed in a Block 226, Set Effective Date for block(s) 228 listed in a Block 226, and add/delete versions 300 of the rule objects in the corresponding blocks 226,228. It is recognised that, as described above, the inclusion of blocks 228 in blocks 226 and the rules 100 in blocks 228 is coordinated in the hierarchy 260 via the listing of the references 227,229 in the appropriate blocks 226,228.

[00187] If finished, then the deployment module 438 can be used to save the modified Plan 42 and then the saved plan 42 is deployed to the database 224.
Parameter module 534

[00188] Referring to Figure 24 , this sub-component or perspective within the engine 50, for example, is used to revise (e.g. add/delete/modify) or otherwise redefine the parameterized values 52 used within rules 100 and benefits 103, as well as the references 227,229,327,329 where appropriate. This revision 55 of the parameters 52 provides for a generic set of rules 100/
benefits 103 to be defined (e.g. the template hierarchies 260,360) and then reused with different specific values 52 that are assigned/associated for plan 42 revision, in view of claims 12 obtained from the queue 53.
Example Revisions 55 to Plan 42 Content

[00189] The engine 50 will display on the user interface 102 details of (e.g. parameters 52, claim data, and/or related portions of the hierarchies 260,360): Date of Service; Tooth Code;
Submitted Procedure Code; Tooth Surfaces; Professional Fee Claimed Amount;
Professional Labl Claimed Amount; Professional Lab 2 Claimed Amount; Eligible Fee Claimed Amount;
Eligible Labl Claimed Amount; Eligible Lab 2 Claimed Amount; Deductible;
Coinsurance;
Benefit Fee Claimed Amount; Benefit Labl Claimed Amount; Benefit Lab 2 Claimed Amount;
Adjudicated Procedure Code; Pay as Procedure Code; Claimed Units; Paid Units;
COB$?; and Proc Type.

[00190] As discussed above in relation to the modules 530,532,534, the engine 50 can facilitate revision/reconfiguration 55 to the following example fields (e.g.
associated parameters and structured of the hierarchies 260,360); Date of Service; anatomy/product (e.g. tooth) Code;
Submitted product/Procedure Code; Paid product/Procedure Code; Professional Fee Claimed Amount; Professional Labl Claimed Amount; Professional Lab 2 Claimed Amount;
Electronic Device 101

[00191] Referring to Figure 13, a generic electronic device 101 can include input devices 102, such as a keyboard, microphone, mouse and/or touch screen by which the user interacts with the visual interface 102. It will also be appreciated that the engine 40, 44, 50, 200 resides on an electronic device 101, for example as separate devices 101 for the engine 40 and the engine 200, and/or the engine 44, for example. A processor 150 can co-ordinate through applicable software (e.g. the engines 40, 44, 50, 200) the entry of data and requests into the memory 124,224, 528 and then display the results on a screen 152. A storage medium 46 can also be connected to device 101, wherein software instructions and/or member data is stored for use by the engine 40, 44, 5, 200. As shown, the device 101 also includes a network connection interface 154 for communicating over the network 11 with other components of the environment (see figure 1), e.g. the engine 200 can communicate to the database 224, the engine 40 can communicate with the database 224, the engine 50 can communicate with the database 224, the engine 44 can communicate with the database 224, and the engines 40, 44, 50, 200 can communicate with one another.

[00192] The stored instructions on the memory 124 (for example the modules of the respective engine 40, 44, 50, 200) can comprise code and/or machine readable instructions for implementing predetermined functions/operations including those of an operating system, the engine 40, 44, 50, 200 configuration, or other information processing system, for example, in response to commands or inputs provided by a user of the engine 40, 44, 50, 200. The processor 150 (also referred to as module(s) for specific components of the engines 40, 44, 50, 200) as used herein is a configured device and/or set of machine-readable instructions for performing operations as described by example above.

[00193] As used herein, the processor/modules in general may comprise any one or combination of, hardware, firmware, and/or software. The processor/modules act upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information with respect to an output device. The processor/modules may use or comprise the capabilities of a controller or microprocessor, for example. Accordingly, any of the functionality provided by the systems and processes of FIGS. 1-26 may be implemented in hardware, software or a combination of both. Accordingly, the use of a processor/modules as a device and/or as a set of machine readable instructions is hereafter referred to generically as a processor/module for sake of simplicity.

[00194] It will be understood by a person skilled in the art that the memory 124,224,528 storage described herein is the place where data is held in an electromagnetic or optical form for access by a computer processor. In one embodiment, storage 124,224,528 means the devices and data connected to the computer through input/output operations such as hard disk and tape systems and other forms of storage not including computer memory and other in-computer storage. In a second embodiment, in a more formal usage, storage 124,224,528 is divided into:
(1) primary storage, which holds data in memory (sometimes called random access memory or RAM) and other "built-in" devices such as the processor's Li cache, and (2) secondary storage, which holds data on hard disks, tapes, and other devices requiring input/output operations.
Primary storage can be much faster to access than secondary storage because of the proximity of the storage to the processor or because of the nature of the storage devices.
On the other hand, secondary storage can hold much more data than primary storage. In addition to RAM, primary storage includes read-only memory (ROM) and Li and L2 cache memory. In addition to hard disks, secondary storage includes a range of device types and technologies, including diskettes, Zip drives, redundant array of independent disks (RAID) systems, and holographic storage.
Devices that hold storage are collectively known as storage media.

[00195] Referring to Figure 13, the engines 40, 44, 50, 200 reside on and are implemented by one or more generic electronic devices 101. Generic device 101 may be a server that makes available the engine 40, 44, 50, 200 to the user over the network 11. As known, device 101 may include input devices 102, such as a keyboard, microphone, mouse and/or touch screen by which the user of the engine 40, 44, 50, 200 interacts with the engine 40, 44, 50, 200 via the visual interface 102. A processor 152 can co-ordinate through applicable software the entry of data and requests into the memory 124,224 and then display/present the results on a screen as visual representation 102,152. Further, it is recognised that the visual representation 102,152 (e.g. the hierarchies 260,360) can be presented (as a result of operation of the engine 40, 44, 50, 200 ) to the user on their client (e.g. of the engine 40, 44, 50, 200 implemented on a networked server) electronic device 101 via the network 11. A storage medium 46 can also be connected to device 101, wherein software instructions, applications 14, member data, and other data is stored for use by the engine 40, 44, 50, 200 , for execution by the respective processor(s) 150.

[00196] The software instructions may comprise code and/or machine readable instructions for implementing predetermined functions/operations including those of an operating system, the engine 40, 44, 50, 200 , or other information processing system, for example, in response to commands or inputs provided by a user and/or the provider of the engine 40, 44, 50, 200. The processor 150 (also referred to as module(s) for specific components of the engine 40,44,200) as used herein is a configured device and/or set of machine-readable instructions for performing operations as described by example above. Some or all of the modules of the engine 40, 44, 50, 200 may be distributed across a network as applications or reside on the electronic device 101. As is understood, some or all of the modules of the engine 40, 44, 50, 200 may also be downloadable to the electronic device 101.

[00197] As used throughout, the processor/modules on the device 101 of the engine 40, 44, 50, 200 in general may comprise any one or combination of, hardware, firmware, and/or software. The processor/modules act upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information with respect to an output device.
The processor/modules may use or comprise the capabilities of a controller or microprocessor, for example. Accordingly, any of the functionality provided by the systems and processes of FIGS.
1-26 may be implemented in hardware, software or a combination of both.
Accordingly, the use of a processor/modules as a device and/or as a set of machine readable instructions is referred to generically as a processor/module for sake of simplicity.
Database 224

[00198] A database or tables 224 is a further embodiment of memory as a collection of information that is organized so that it can easily be accessed, managed, and updated. In one view, databases can be classified according to types of content:
bibliographic, full-text, numeric, and images. In computing, databases are sometimes classified according to their organizational approach. As well, a relational database is a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways. A distributed database is one that can be dispersed or replicated among different points in a network. An object-oriented programming database is one that is congruent with the data defined in object classes and subclasses.

[00199] Computer databases 224 typically contain aggregations of data records or files, such as sales transactions, product catalogs and inventories, and customer profiles. Typically, a database manager provides users the capabilities of controlling read/write access, specifying report generation, and analyzing usage. Databases and database managers are prevalent in large mainframe systems, but are also present in smaller distributed workstation and mid-range systems such as the AS/400 and on personal computers. SQL (Structured Query Language) is a standard language for making interactive queries from and updating a database such as IBM's DB2, Microsoft's Access, and database products from Oracle, Sybase, and Computer Associates.

[00200] Memory storage is the electronic holding place for instructions and data that the computer's microprocessor 150 can reach. When the computer 101 is in normal operation, its memory 124,224 usually contains the main parts of the operating system and some or all of the application programs and related data that are being used. Memory is often used as a shorter synonym for random access memory (RAM). This kind of memory is located on one or more microchips that are physically close to the microprocessor in the computer.
Example Operation of the Adjudication Engine 40

[00201] Referring to Figure 14, shown is an example operation 350 of the adjudication engine 40 for processing insurance claims 12 using a set of adjudication rules. At step 352, the adjudication engine 40 receives the claim 12 for processing, the received claim 12 having claim content including a claim date. At step 354, the adjudication engine accesses the set of adjudication rules in the database 224 appropriate to the content of the received claim 12. The set of adjudication rules is structured in a plurality of containers including a primary rule container 226 and a plurality of secondary rule containers 228, each of the plurality of secondary rule containers 228 being coupled to the primary rule container 226 by a respective container reference 229. Each of the plurality of secondary rule containers 228 contains one or more adjudication rules 100 adapted for processing the claim content of the received claim 12, such that each of the one or more adjudication rules 100 is coupled to their respective secondary container 228 by their respective rule reference 227, wherein the set of adjudication rules defines the rule hierarchy 260. At step 356, the adjudication engine 40 processes the content of the received claim 12 with the one or more adjudication rules 100 facilitated by an execution order defined by the ordering of the container references 229 in the primary rule container 226.
At step 358, the result of the processed claim is used to determine subsequent settlement of the received claim 12.

[00202] It is recognised in step 356, the processing of the claim content can include accessing a set of benefit codes 103 appropriate to the received claim 12, such that the set of benefit codes 103nis structured in a plurality of benefit containers including a primary benefit container 326 and a plurality of secondary benefit containers 328. Each of the plurality of secondary benefit containers 328 is coupled to the primary benefit container 326 by their respective benefit container reference 329. Each of the plurality of secondary benefit containers 328 contains one or more benefit codes 103 adapted for processing the claim content of the received claim 12, such that each of the one or more benefit codes 103 is coupled to their respective secondary benefit container 328 by their respective benefit reference 327, wherein the set of benefit codes 103 defines the benefit hierarchy 360.

[00203] It is also recognised that an optional step is 360 is comparing the claim date to the effective date(s) and/or expiry date(s) of the container references 227,229,327,329, in order to determine if the respective secondary rule containers 228 are part of the set of adjudication rules for use in processing the received claim 12, such that the non-matching dates exclude the respective secondary rule container 228 from being included in the execution order. As well, part of the optional step can include comparing the claim date to the effective date(s) and/or expiry date(s) of the container references 227,229,327,329, in order to determine if the respective rules 100 are part of the set of adjudication rules for use in processing the received claim 12, such that the non-matching dates exclude the respective rules 228 from being included in the execution order of their secondary containers 228. It is recognised that similar comparisons can be done for the inclusion/exclusion decision making for the benefit codes 103 and the secondary benefit containers 328, as desired.
Example Operation of the Composer Engine 200

[00204] Referring to Figure 15, shown is an example operation 370 of the composer engine 200 for generating a set of adjudication rules for use in processing an insurance claim, the set of adjudication rules representing the hierarchy 260. At step 372, defining adjudication rule(s) 100. At step 374, defining a secondary rule container 228 and coupling the adjudication rule 100 to the secondary rule container 228 by a rule reference 227 associated with the content of the secondary rule container 228. At step 376, defining a primary rule container 226 and coupling the secondary rule container 228 to the primary rule container 226 by a container reference 229 associated with the content of the primary rule container 226, such that the adjudication rule 100, the containers 226,228, and the rule and container references 227,229 defining the rule hierarchy 260 for representing the set of adjudication rules. At step 378, storing the set of adjudication rules in the memory 124,224; wherein the set of adjudication rules is configured to facilitate the processing of content of the insurance claim 12 with the adjudication rule by an execution order defined by the ordering of the container reference 229 in the primary rule container 226. At step 380, adding parameter values to the adjudication rules. It is recognised that similar steps can be done to the above, in order to include benefit codes in a benefit hierarchy 360 linked 240 to the rules 100, as described by example above.
Example Operation of the Plan Engine 44

[00205] Referring to Figure 21, operation 361 of the plan engine 44 is shown, for modifying benefit coverage including a plurality of benefit codes 103 of an insurance plan 42, such that the insurance plan 42 is for use in adjudicating one or more insurance claims 12 by the adjudication engine 40. At step 362, the engine 44 accesses a set of benefit codes 103 structured in a plurality of benefit containers 326,328 including a primary benefit container 326 and a plurality of secondary benefit containers 328, each of the plurality of secondary benefit containers 328 being coupled to the primary benefit container 326 by a respective benefit container reference 329, each of the plurality of secondary benefit containers 328 containing one or more benefit codes 103 adapted for processing a claim content of the one or more insurance claims 12, each of the one or more benefit codes 103 being coupled to their respective secondary benefit container 328 by a respective benefit reference 327, the set of benefit codes 103 defining a benefit hierarchy 360. At step 364, the engine 44 selects the primary benefit container 326 for inclusion in the insurance plan 42. At step 366, the benefit module modifies the benefit hierarchy 360 by performing at least one of adding an additional benefit container reference 329 to the primary benefit container 326, modifying a container benefit parameter 52 of at least one of the benefit container references 329, or deleting at least one of the existing benefit container references 329. At step 368, the deployment module 438 stores the modified insurance plan 42 in the memory 224; wherein the stored modified insurance plan 42 is adapted for subsequent use in adjunction of appropriate insurance claims 12 received by the adjudication system 18.

[00206] It is recognised that step366 can be substituted instead for accessing a set of adjudication rules structured in a plurality of containers including a primary rule container 226 and a plurality of secondary rule containers 228, each of the plurality of secondary rule containers 228 being coupled to the primary rule container 226 by a respective container reference 229, each of the plurality of secondary rule containers 228 containing one or more adjudication rules 100 adapted for processing the claim content of the received claim 12, each of the one or more adjudication rules 100 being coupled to their respective secondary container 228 by a respective rule reference 227, the set of adjudication rules defining the rule hierarchy 260.

[00207] It is recognised that step366 can be substituted instead for selecting the primary rule container 226 for inclusion in the insurance plan 42, modifying the rule hierarchy 260 by performing at least one of adding an additional rule container reference 229 to the primary rule container 226, modifying a rule container parameter 52 of at least one of the rule container references 229, or deleting at least one of the existing rule container references 229.

[00208] It is recognised that step366 can be substituted instead for modifying the benefit hierarchy 360 by performing at least one of adding an additional benefit reference 327 to at least one of the secondary benefit containers 328, modifying a benefit reference parameter 52 of at least one of the benefit references 327, or deleting at least one of the existing benefit references 327.

[00209] In view of the above, it is recognised that modification of the plan 42 can include any modifications to any of the references 227,229,327,329 (either existing or added or deleted) in any order (i.e. blocks 228,328 content is modified before blocks 226,326 content is modified, blocks 226,228 content is modified before blocks 326,328 content is modified, blocks 326,328 content is modified before blocks 226,228 content is modified, etc.).

Example Operation of the Reconfiguration/Review Engine 50

[00210] Referring to Figure 26, operation 560 of the engine 50 is shown, for revising one or more hierarchies 260,360 of an insurance plan 42, the insurance plan 42for use in adjudicating one or more insurance claims 12. At step 562, obtaining one or more claims 12 from a claims queue 53, the claims queue 53 for storing claims 12 selected for review (e.g.
due to adjudication error(s) , fraud considerations, and/or quality control considerations). At step 564; accessing at least one of a set of benefit codes 103 or a set of adjudication rules 100 associated with the insurance plan 42 of the obtained one or more claims 12, wherein at least some of the set of benefit codes 103 or the set of adjudication rules 100 are structured in a plurality of containers 226,228,326,328. At step 566, reconfiguring selected content of the at least one of a set of benefit codes 103 or the set of adjudication rules 100 in view of identified reasons for review (e.g. due to adjudication error(s) , fraud considerations, and/or quality control considerations) of the one or more claims 12. At step 568 storing the reconfigured at least one of a set of benefit codes 103 or the set of adjudication rules 100 in a memory 224,528 for subsequent use as at least one of a redeployed version of the insurance plan 42 or a revised said at least one of a set of benefit codes 103 or the set of adjudication rules 100 for use in development of other insurance plans 42 for adjudication of claims 12 other than the one or more claims 12 obtained from the claims queue 53, wherein the revised insurance plan 42, once deployed, is adapted for use by an adjudication engine 40 for processing insurance claims 12 received by the adjudication engine 40.

[00211] In view of the above described system 10, it is recognised that the system 10 is not limited to dental type insurance, but other forms of insurance as well.
The features of the system 10 include such as but not limited to: 1) the rule composer 200 creating containerized rule and benefit hierarchies 260,360; 2) the adjudication engine 40 using the containerized data structure 260,360 in claim 12 adjudication; management/assignment of the plans 42, using the containerized rule and benefit hierarchies 260,360 output of the rule composer 200; and 4) leveraging the containerized rule and benefit hierarchies 260,360, in the context of claim adjudication review 412, to revise/update 414 the containerized rule and benefit hierarchies 260,360 of the respective plan 42 for subsequent use by the adjudication engine 40 (i.e. to increase auto adjudication levels). Further, the aspect of the plan manager 44 can be generalized to include the creation of additional components to the hierarchies 260,360.
The composer 200 is used to generate "template" hierarchies 260,360 for use by the plan manager 44 in customization and deployment of the customized hierarchies 260,360 as a plan 42 for use by the adjudication engine 40. The plan manager 44 can also add to (e.g. create) or otherwise amend the "template" hierarchies 260,360 to generate the customized hierarchies 260,360, as needed during the plan management/assignment processes.
Example Implementation of the Reconfiguration/Review Engine 50

[00212]
Referring to the following pages, the engine 50 is referred to as a claim manager, which is used as an application, i.e. a set of instructions stored on a computer readable medium that is executable by a computer processor (see Figure 13). It is also recognised that all example display screens could be configured for display on the user interface 102 of the device(s) 101 associated with use of the engine 50 by the user. The engine 50 is used to reconfigure/revise the configured adjudication rules 100 and benefits 103 in their configured hierarchy 260,360 (e.g. of the deployed plan 42) iv view of the reviewed associated claim 12 or set of claims obtained from the claim queue 53, for use by the adjudication engine 40, see Figure 2. It is recognised that the following example is only meant as one embodiment of a number of possible embodiments of the contents and functionality of the engine 50 and it's modules, as well as any described interaction with other engines (e.g. the rule composer aka the composer engine 200 and the plan engine 44 aka the plan manager).

=

The Claim Manager application allows users to manage dental claim information in a java-based graphical user interface (GUI). Claims enter the system either automatically through electronic data interchange (EDI) or through manual entry outside of Claim Manager.
Access to claim information depends on the user's role and team, and the claim's current ownership and status.
1.1 SYSTEM REQUIREMENTS
Claim Manager is comprised of java applets that are displayed in a web browser (e.g., Internet Explorer). Each functional Claim Manager task opens in a new browser window.
Claim Manager currently supports Internet Explorer v6Ø For Claim Manager to properly function, pop-ups must be allowed; refer to the web browser's documentation for details on allowing pop-ups.
Claim Manager requires Java runtime version 1.5.0_11.
1.2 APPLICATION VERSION
This manual supports Claim Manager version 1-2-1.
Select About from the Help menu to display the application's current build (version). Refer to Figure 27.

Claim Manager's main workspace is comprised of 3 distinct sections. The screen displayed in Figure 28 is a sample of the user management screen; the content of each section is relative to the user's current process:

2.1 WORKSPACE TOP
The top section of Claim Manager lets users select high-level parameters to determine the information displayed in the lower sections.
= Available selections, tabs, fields, and buttons are dependant on the user's current task.
= Tab labels (in this example Read Only Claims and Procedure (R/0)) are dynamic and change according to the type of data selected in the lower sections. For example, if a claim with the status Closed is selected, the tab labels will display Closed Claims and Procedure (RIO) etc.
= The information field (see "Group No. 5651 / Division No..." etc. in Figure 2 below) displays member and recipient attributes whenever a user interacts (edit, review, or audit) with a specific member's claim.
The screen displayed in Figure 29 is a sample of the claim management screen;
the content of each section is relative to the user's current process. In this case, the user could click Next to display the next claim in the user's queue.
2.1.1 SERVICES
The Services menu lets users select from the available functional areas of the Claim Manager application. The list of displayed services depends on the current user's role and permissions (see 3 Roles for details on roles). See 15.1 Selecting A Service for details.
This menu may contain:
Claims: Available to all users.
Claim Search: Available to Super Managers, Managers, Claims Examiner Level 1, Quality Control Level 1, and Auditor Level 1.
Admin: Available to Super Managers, Managers, Claims Examiner Level 1, Quality Control Level 1, and Auditor Level 1. Refer to Figure 30.
2.1.2 FORMS
Each service offers a set of forms (or screens) that allow users to work on specific aspects of the Claim Manager application.
Claims Service: Claims, Transaction Management.
Claim Search Service: Claim Search.
Admin Service: User Management, Team Management, QC Management, Audit Management, and Routing Management. Refer to Figure 31.

2.2 WORKSPACE MIDDLE
The middle section of Claim Manager allows users to review or enter data relevant to the section below.
= Available selections, tabs, fields, and buttons are dependent on the user's current role and task. See 5 Claim Ownership and Re-Assignment for details.
The example in Figure 32 is a sample of the claim management screen; the content of each section is relative to the user's current process and/or the status of the current claim.
2.3 WORKSPACE BOTTOM
The bottom section of Claim Manager displays editable fields, actions, searches, reports, dependant on the current process.
The screen displayed in Figure 33 is a sample of the claim management screen;
the content of each section is relative to the user's current process:

Each user is assigned to a role which specifies the tasks that the user can access in Claim Manager. When users log in to the system, their role automatically determines the information and functions available.
Users can belong to multiple teams; see Section 4 Teams for more information.
Refer to Figure 34.
3.1 SUPER MANAGER
This is an administrative role. Super Managers can:
= Search and view claims.
= Manage and assign all users and teams.
= Set Quality Control and Audit criteria.
= Manage pending queues by re-assignment.
= Add internal notes.
= Manage claim routing for specific insurers.
3.2 MANAGER
This role is mostly administrative. Managers can perform all Level 1 functions within teams to which they are assigned.

Managers can:
= Search and view claims for the teams to which they are assigned.
= Manage and assign relevant users and teams.
= Set Quality Control and Audit criteria.
= Manage pending queues by re-assignment.
= Add internal notes.
= Manage claim routing for specific insurers.
3.3 CLAIMS EXAMINER
Manage claims examiner users and teams, manage pended claims, including changes to existing information and manual pricing overrides.
3.3.1 CLAIMS EXAMINER LEVEL 1 Claims Examiner Manager. Manage pended claims, change existing information, and perform manual overrides; administer users within their teams; view Quality Control and Audit criteria.
3.3.2 CLAIMS EXAMINER LEVEL 2 Manage pended claims, change existing information, and perform manual overrides.
3.3.3 CLAIMS EXAMINER LEVEL 3 Junior Claims Examiner. Manage pended claims, and change existing information.
3.3.4 CLAIMS EXAMINER LEVEL 4 Dental Consultant. Add notes to claims, and re-assign claims to another Claims Examiner.
3.4 AUDITOR
Manage audit users and teams, check and verify flagged claims, and specify Audit criteria. May add notes and include instructions for Claims Examiners.
3.4.1 AUDITOR LEVEL 1 Auditor Manager. Check and verify flagged claims; administer users within their teams; edit Audit criteria; add notes and include instructions for Claims Examiners.
3.4.2 AUDITOR LEVEL 2 Check and verify flagged claims. May add notes and include instructions for Claims Examiners.
3.5 QUALITY CONTROL
Manage quality control users and teams, review a random sampling of claims for accuracy, and specify Quality Control criteria. May add notes and include instructions for Claims Examiners.

3.5.1 QUALITY CONTROL LEVEL 1 Quality Control Manager. Review a random sampling of claims for accuracy;
administer users with in their team; edit Quality Control criteria; add notes and include instructions for Claims Examiners.
3.5.2 QUALITY CONTROL LEVEL 2 Review a random sampling of claims for accuracy. May add notes and include instructions for Claims Examiners.

Within each role, teams (or queues) are assigned specific claims: all members of a team/queue are configured to work from the list of claims. A role may have many teams, but each team can only belong to a single role.
Teams are usually structured by responsibility of work assignment by location.
For example, if there are two claim offices, two teams would be required. Business rules may require additional teams to properly disperse the workload. See 14.5 Routing Management for further details.
Only users with the Super Manager, Manager, Claims Examiner Level 1, Quality Control Level 1, or Auditor Level 1 role can create and manage teams.
= Super Managers can add users to any team; Super Managers cannot be assigned to teams.
= Managers can be assigned to any team.
= Claims Examiners can only be assigned to Claims Examiner teams.
= Quality Control users can only be assigned to Quality Control teams.
= Audit users can only be assigned to Audit teams.
= Managers and Claims Examiners Level 1, Quality Control Level 1 and Auditor Level 1 can alter the users on their teams.

=
CLAIM OWNERSHIP AND RE-ASSIGNMENT
Users take ownership of a claim when they open it for editing, select Next to display the next claim in their queue, or a claim is re-assigned to them.
= Ownership is released when the user perform an action to close or re-assignment the claim.
= Claims that are not associated with the current user's team can only be re-assigned by a user in the Super Manager role. Claims cannot be re-assigned beyond their initial role; for example, a claim assigned to an Audit team can be re-assigned to other Audit teams, but cannot be re-assigned to a Claims Examiner or Quality Control team.
= Claims with a benefit dollar amount greater than the current owner's dollar amount restriction cannot be re-assigned.
Role Create Read Update Delete Super Manager Manager Claims Examiner Quality Control Auditor = Super Manager Can re-assign claims to/from Claims Examiner, Manager, Quality Control, or Auditor teams, and to any specific user within those teams.
= Manager Can re-assign claims from their teams to Claims Examiner, Manager, Quality Control, or Auditor teams, and to any specific user within those teams.
= Claims Examiner Can re-assign claims from their teams to Claims Examiner or Manager, and to any specific user within those teams.
= Quality Control Can re-assign claims from their teams to Claims Examiner, Manager, or Quality Control teams, and to any specific user within those teams. Claims re-assigned to Claims Examiners and Managers must be re-opened for editing by the user to whom they are assigned.
= Auditor Can re-assign claims from their teams to Claims Examiner, Manager, or Auditors teams, and to any specific user within those teams. Claims re-assigned to Claims Examiners and Managers must be re-opened for editing by the user to whom they are assigned.

All claim states can be searched and displayed.
6.1 PENDED
The claim can be edited or managed by users in the appropriate role. The Pended status allows the Re-assign, Hold, Internal Note, Refuse, Reverse, Re-Adj. (Pend), and Re-Adj. (Close) actions. See 8.3 Claim Actions for details.
When users perform actions on a pended claim, the claim is closed and checked against its associated audit or quality control criteria. If the claim matches any predefined audit or quality control criteria, it will have a state of semi closed and will be sent to the appropriate teams for review.
6.2 SEMI-CLOSED
The claim has been adjudicated but was marked for audit or quality control checking based on the pre-defined audit or quality control criteria, and has not yet been released to the payment process.
6.2.1 QUALITY CONTROL OR AUDIT QUEUE
When a claim is in the Quality Control or Audit Team's pending queue it is in a semi-closed state. The user may perform the following actions (see 8.3 Claim Actions for details):
= Re-assign the claim to a Quality Control or Claim Examiner team and any user within that team.
= Hold, to retain ownership and move the claim back into the queue.
= Release/Close, to remove the claim from the pending queue.
= Re-open to a Claim Examiner.
= Add an internal note.
6.2.2 READY FOR PAYMENT
Claims that are ready for payment have been adjudicated (and possibly released) from an Audit or Quality Control pending queue, but have not been released to the Payment process. A claim may be held from the payment process if an associated claim (from the same transaction) is being held in Pending.
= A semi-closed claim is moved to a closed state when it is released/closed from a Quality Control or Audit queue, and is selected by the end-of-day process for release to the Payment process.
6.3 CLOSED
Claim is complete. The Closed status allows the Internal Note, Reverse, and Re-open actions.
See 8.3 Claim Actions for details.
6.4 PAID
The claim has been paid. Users in the role Manager, Claims Examiner Level 1, and Claim Examiner Level 2 may perform the following actions (see 8.3 Claim Actions for details):
= Re-assess or reverse the claim.
= Specify explain codes for the claim.
All users with access to the claim can add notes.

All users assigned a queue can step through their list of claims by clicking Next, making and saving any changes, then clicking Next again to display the next claim in their queue. Claims in the queue are sorted in reverse chronological order: the oldest claim in your queue is opened first.
To open the next claim in your queue:
1. Under Services, click to select Claim.
2. Select the Claims form.
3. Select a team queue from the drop-down list of teams to which you are assigned. The queue selected here will determine the available claims.
4. Click Next. Claim details are displayed.
Depending on the current user's role and the current claim's status, fields may be editable or display only.
See 11.1 Eligibility, 11.2 Member Eligibility, 11.3 Claim Details, 8.3 Claim Actions, 11.4 Predetermination, 11.5, 11.6 Change Log, or 11.7 Claims Experience for details on viewing or modifying claims. Refer to Figure 35.

Access to claim information depends on the user's role and team, and the claim's current ownership and status. Claim searches can be performed via the Claims form or the Claim Search form, depending on the current user's role and process requirements.
8.1 RE-ASSIGNING CLAIMS
This functionality allows users to re-assign a claim within their team. It also allows users in the role of Super Manager, Manager, Claims Examiner Level 1, Quality Control Level 1, and Auditor Level 1 to distribute the work loads amongst the teams by re-assignment.
The re-assignment functionality is available on claims with a status of pended or semi-closed.
Claims can be re-assigned to another team or user's queue. Claims that are not associated with the current user's team can only be re-assigned by a user in the Super Manager role. For re-assignment rules, see 5 Claim Ownership and Re-Assignment.
Claims can be re-assigned via:
= The Claim form. For details on re-assigning claims via the Claim form, see 8.3 Claim Actions.
= The Admin form. For details on re-assigning claims via the Admin form, see 14.1.3 Re-Assigning User Claims.
= The Claim Search form. See 8.3.1 Re-Assign for details.
Only users logged in as a Super Manager, Manager, Claims Examiner Level 1, Quality Control Level 1, or Auditor Level 1 have access to the Claim Search form.
To re-assign a claim via the Claim Search form:
1. Under Services, click to select Claim Search 2. Select the Claim Search tab.
3. Search for the required claim. See 15.2 Searching for an overview of searching; see 9.1 Claim Search Criteria for details on available search criteria.
4. Click to select the desired claim in the search results list.
5. Enter a Queue/Team to which this claim will be re-assigned. See Extended Searches 15.3.2 Team Lookup for details on finding a team.
6. Optionally, enter a User to which this claim will be re-assigned. See Extended Searches 15.3.1 User Lookup for details on finding a user.
7. Click Re-Assign. If the Queue/Team and User entries were valid and the benefit dollar amount exceeds the current user's dollar amount restrictions, the claim is automatically re-assigned and the results list is updated. Refer to Figure 36.
8.2 CLOSING AND RELEASING CLAIMS

Only claims in a Semi-Closed state can be closed and released. See 6 Claim States for details.
Users with the role Super Manager, Manager, and all levels of Quality Control and Auditor have the ability to perform this function.
To re-assign a claim via the Claim Search form:
8. Under Services, click to select Claim Search 9. Select the Claim Search tab.
10. Search for the required claim. See 15.2 Searching for an overview of searching; see 9.1 Claim Search Criteria for details on available search criteria.
11. Click to select the desired claim in the search results list.
12. Click Close/Release.
The claim's status is automatically changed. Click Refresh to update the claim list.
See 14.1.4 Closing and Releasing Claims for details on closing claims via the Admin form.
8.3 CLAIM ACTIONS
The Actions tab allows users to perform various functions against the current claim. The available actions depend on the current user's role and the claim's current state. Saving information on the Actions tab automatically saves changes on Eligibility, Member Eligibility, Pre-determination, and Claim Details tabs.
To perform an action on a claim:
13. Under Services, click to select Claim.
14. Open the claim on which you want to perform the action. See 7 Opening Claims in Your Queue or 9 Searching for Claims for details on opening claims.
15. Select the Actions tab. The current user's role and the claim's current state dictate the available actions.
16. Click to select the appropriate action, and enter/select any necessary parameters.
17. Click Save to save your changes. Refer to Figure 37.
8.3.1 RE-ASSIGN
This functionality allows users to re-assign a claim within their team. Re-assignment also allows users in the role of Super Manager, Manager, Claims Examiner Level 1, Quality Control Level 1, and Auditor Level 1 to distribute work loads among various teams.
= The re-assignment functionality is available on claims with a status of pended or semi-closed.
= Claims can be re-assigned to another team or user's queue. Claims that are not associated with the current user's team can only be re-assigned by a user in the Super Manager role.
Claims cannot be re-assigned beyond their initial role; for example, a claim assigned to a Claims Examiner team can be re-assigned to other Claims Examiner teams, but cannot be re-assigned to an Audit or Quality Control team.
= Claims that are not associated with the current user's team can only be re-assigned by a user in the Super Manager role.
= Claims that exceed the current owner's dollar amount restrictions cannot be re-assigned.
See 5 Claim Ownership and Re-Assignment.
To re-assign a claim:
18. Click to select the Re-Assign action.
19. Enter a Queue/Team to which this claim will be re-assigned. See Extended Searches 15.3.2 Team Lookup for details on finding a team.
20. Optionally, enter a User to which this claim will be re-assigned. See Extended Searches 15.3.1 User Lookup for details on finding a user.
21. Optionally, enter descriptive Note text.
22. Click Save to save your changes.
8.3.2 HOLD
Pended claims can be put on hold for a defined period. This functionality changes the priority of the claim in the pended queue. When a user cannot complete their changes to a claim, they can change the position of the claim in the pending queue by placing it on hold for an specified period. The claim will return to the user's pended queue based on the hold period.
This functionality is available on claims with a status of pended or semi-closed.
To place a claim on hold:
23. Click to select the Hold action.
24. Select a Hold Period from the drop-down list, or specify a Date until which the claim will be on hold. Dates must be entered in the form DD-MMM-YYYY.
25. Optionally, enter explanatory text in the Note field.
26. Click Save to save your changes.
8,0.3 INTERNAL NOTE
This functionality allows users to enter information that they wish to remain with the claim. It can be used to track inquiries against the results, add explanatory text, etc.
All users have access to internal notes.
To add an internal note:
27. Click to select the Internal Note action.
28. Enter explanatory text in the Note field.
29. Click Save to save your changes.

8.3.4 REFUSE
Refuse a pended claim, disregarding adjudication results. Refused claims must include an explanatory Note and Explain Code, and are not part of claims experience.
Refused claims cannot be reversed or re-assessed.
This functionality allows users to change the status of a claim to refuse and clear the claim from the Claim Examiners queue.
A refusal status generates an EOB statement. Typically this action would be supported with a request for a questionnaire to be produced.
To refuse a claim:
30. Click to select the Refuse action.
31. Select an Explain Code if desired.
32. Enter explanatory text in the Note field.
33. Click Save to save your changes.
8.3.5 RELEASE/CLOSE
Only claims in a Semi-Closed state can be released/closed. The claim remains visible in the history.
To release/close a claim:
34. Click to select the Release/Close action.
35. Select an Explain Code if desired.
36. Enter explanatory text in the Note field if desired.
37. Click Save to save your changes.
8.3.6 RE-ASSESS
The application allows a user to re-assess a closed claim or predetermination, disregarding adjudication results. Re-assessed claims must include an explanatory Note and Explain Code.
This functionality allows users to cancel an active claim experience record.
The process updates the original claim with the reversal claim identifier. This action will also create a negative dollar amount against the original claims payee (Provider or Member). A copy of the original claim is placed in the user's pending queue with a new claim identifier. The original claim submit date is retained, so the claim is filtered to the top of the queue. When the user functions the Next button, the re-assess claim is presented and the appropriate changes can be made.
To re-assess a claim:
38. Click to select the Re-assess action.
39. Select an Explain Code for this reversal.
40. Enter explanatory text in the Note field.

41. Click Save to save your changes.
Note: A user can also suppress EOB to withhold the entire EOB package or suppress overpayments in the case when a member has returned the payment for a claim that was originally paid in error.
8.3.7 RE-OPEN
A claim in a semi-closed or closed state can be reopened into a pended state for modifications.
To re-open a closed claim:
42. Click to select the Re-Open action.
43. Specify a Team and User to which the re-opened claim will be assigned.
44. Enter explanatory text in the Note field and/or select an explain code.
45. Click Save to save your changes.
8.3.8 RE-ADJ. (PEND) Re-adjudication (Pended) re-adjudicates a Pended claim and resets its status to Pended. Re-adjudication claims must include an explanatory Note and Explain Code.
This functionality allows the user to modify the claim details and submit it to the adjudication engine. The results are presented back to the user to ensure that the changes made resulted in the desired adjudication results.
To re-adjudicate a Pended claim:
46. Click to select the Re-Adj. (Pend) action.
47. Select an Explain Code if desired.
48. Enter explanatory text in the Note field if desired.
49. Click Save to save your changes.
8.3.9 RE-ADJ. (CLOSE) Re-adjudication (Close) re-adjudicates a Pended claim and sets its state to:
= Semi-closed, if the claim is flagged for audit.
= Closed, if the claim is processed without errors or flags.
= Pended, if the claim has errors that require resolution.
Re-adjudication claims must include an explanatory Note and Explain Code.
This functionality removes the claim from the pended state and confirms it as active claims experience. After the user has modified the claim and reviewed the adjudication results, this action will close the claim and move on to the next claim in the pending queue.

To re-adjudicate a closed claim:
50. Click to select the Re-Adj. (Close) action.
51. Select an Explain Code if desired.
52. Enter explanatory text in the Note field if desired.
53. Click Save to save your changes.
8.3.10 REVERSE
Reverse a pended or closed claim or predetermination, disregarding adjudication results.
Reversing a closed claim results in a same-day reversal; reversing a paid claim or predetermination results in a full claim reversal.
Reversed claims must include an explanatory Note and Explain Code.
This functionality allows users to cancel an active claim experience record.
The process updates the original claim with the reversal claim identifier. This action will also create a negative dollar amount against the original claims payee (Provider or Member).
To reverse a claim:
54. Click to select the Reverse action.
55. Select an Explain Code for this reversal.
56. Enter explanatory text in the Note field.
57. Click Save to save your changes.
Note: A user can also suppress EOB to withhold the entire EOB package or suppress overpayments in the case when a member has returned the payment for a claim that was originally paid in error. Refer to Figure 38.
8.3.11 DELETE OR REFUSE LINE ITEMS
A user can delete or refuse line items prior to the claim being paid or after being paid. In the case of after the claim being previously paid, the Reverse and Reassess action is needed before being able to perform the delete and refuse actions.
To delete or refuse a line item:
58. Open the claim.
59. Select the Procedure tab.
60. Select the Actions tab.
61. Select Refuse or Delete.
62. Select Save.

Note: A user can also unrefuse and undelete if needed.
Note: A user can also add an explanatory note if needed. Refer to Figure 39.

Claim searches can be performed via the Claims form or the Claim Search form, depending on the current user's role and process requirements.
To search for a claim:
63. Under Services, click to select Claim.
64. Select the Claims form.
65. Select a team queue from the drop-down list of teams to which you are assigned. The queue that is selected here will determine the available claims.
66. Select the Claim Search tab. Refer to Figure 40.
The user has various options when entering search criteria such as selecting to display the current user's (Owned By Me) or team's (Current Team) claims, or enter relevant search criteria and click Search. The search results will match all entered criteria; if the search does not contain the required claim, try the search again with less criteria.
9.1 CLAIM SEARCH CRITERIA
If more than one search criteria field is specified, the displayed results will contain only items that match all specified entries. For example, if Member Id. 10098 and Last Name Smith are entered as search criteria, the search may fail even if Member ID 10098 exists but does not have a matching Last Name of Smith.
= Claim Id.
The unique system-generated number that identifies the claim in Claim Manager.
This is the identifier that is provided on the paper claims EOB outputs and Provider Reconciliation Statements. For EDI transaction identifiers, please refer to EHIP
Reference number.
= Claim Type Select the type of claim on which to search: Claim, Predetermination, Prior Day Reversal, Same Day Reversal or COB (Co-ordination of benefits) Claim.
= EHIP Reference The system-generated internal reference number that identifies the transaction to which the claim is associated. This is the identifier that is provided in an EDI
response to the Provider. The Provider is obligated to print a copy for the Member, so the EHIP
Reference number will also be communicated in this format. For paper claims identifiers please refer to Claim Id.
= Reference The external reference number that identifies the transaction to which the claim is associated. This identifier is the external reference number from the incoming claim transaction. In EDI it is commonly referred to as the 'Office Sequence' number, and for Paper Claims it is the identifier generated by the Data Entry application.
= Transaction ID
The unique system-generated number that identifies the transaction in Claim Manager.
= Claim State The claim's current state. Select from Pended, Semi-Closed, or Closed. See 6 Claim States for details.
If no state option is selected, the search returns all claims that meet the other search criteria regardless of the claim's state.
= Group No.
The unique group identification number assigned to identify a policyholder. To search for a specific Group number, click E to open an extended search. See Extended Searches (0 Group) for details.
= Team The team to which the claim is assigned. To search for a specific Team, click I] to open an extended search. See Extended Searches (15.3.2 Team) for details.
= User The User Id. of the person to which the claim is currently assigned. To search for a specific User number, click El to open an extended search. See Extended Searches (15.3.1 User) for details.
= Insurer No.
The number that identifies the insurer associated with the claim. To search for a specific Insurer number, click El to open an extended search. See Extended Searches (15.3.3 Insurer) for details.
= Member No.
The number that identifies a unique plan member. To search for a specific Member Id.
number, click El to open an extended search. See Extended Searches (15.3.6 Member) for details.
= First Name The plan member's first name.
= Last Name The plan member's last name.

= Received Date For a paper claim, the received date is set by the Paper Reimbursement application. For an EDI claim, Received Date is the same as ED! Submitted Date.
= Submit Date Specify a date range on which the claim was submitted. Dates must be entered in the form DD-MMM-YYYY. If only a From date is entered, the To date defaults to the current date.
= Service Date Specify a date range on which the service was performed. Dates must be entered in the form DD-MMM-YYYY. If only a From date is entered, the To date defaults to the current date.
= DE User ¨ The user ID of the person who created a paper claim = Source ¨ Indicates if the source of the claim was paper or electronic.
Refer to Figure 41.
9.2 CLAIM SEARCH RESULTS
Search results contain only items that match all specified search criteria.
= Pended claims older than five (5) days are displayed in red.
= By default, claims are displayed in ascending order by the date on which they were submitted. To sort the search results by another criteria, select from the available options in the Sort By drop-down list and re-perform the search.
Click to select any claim in the search results. Depending on the current user's role and the claim's status, various actions may be performed on the claim; see 8.3 Claim Actions for details.
9.2.1 DISPLAYING ALL CLAIMS IN A TRANSACTION
Each claim is associated with a transaction; electronically submitted transactions usually consist of a single claim, whereas paper-based transactions often contain multiple claims in a single transaction.
To display all claims in the transaction associated with your current claim selection:
67. Click to select the desired claim.
68. Click Claims in Transaction. The search results list displays all claims in the transaction associated with the previously selected claim. If the selected claim is part of an electronic transaction, only that claim will be displayed.
For more information on transactions, see 13 Transaction.
9.2.2 OPENING CLAIMS
To open a claim for display or modification (depending on the current user's role and the claim's status):
69. Click to select the desired claim.
70. Click Open.
71. The claim's detail information automatically populates all fields under all tabs with the claim's information. Depending on the current user's role and the current claim's status, fields may be editable or display only. See 11.1 Eligibility, 11.2 Member Eligibility, 11.3 Claim Details, 8.3 Claim Actions, 11.4 Predetermination, 11.5 Messages, 11.6 Change Log, or 11.7 Claims Experience for details on viewing or modifying claims.
CLAIM SEARCH FORM
The claim search form allows users to search for claims (see 9 Searching for Claims for details) and display claim count details.
10.1 CLAIM COUNTS
To display a count of claims based on Team, User, or Received Date:
72. Under Services, click to select Claim Search.
73. Select the Claims Counts tab.
74. Select to display claims By Team, By User, or By Submit date. Team and User claims are sorted in descending alphabetical order; Received Date claims are sorted in reverse chronological order.
75. Click any claim to select it, and click Drill Down to open the claim in the Claim Search tab to view or modify details. Refer to Figure 42.

The claims form displays information at a claim level.
11.1 ELIGIBILITY
The Eligibility tab displays information that matches the submitted information to the information in GAMA. Available editable fields depend on the user's role and the claim's current status. Changes to information on the Eligibility tab will only be saved when the user performs an action on the claim and saves; see 8.3 Claim Actions for more details.
= Insurer No.
The identification number assigned to a specific insurer for which claims from this member are eligible. See Extended Searches (15.3.3 Insurer) for details on finding an insurer number.
= Group No.
The identification number of the specific group to which claims for this insurer assigned.
See Extended Searches (0 Group) for details on finding a Group number.
= Member No.
The unique identification number of the plan member. See Extended Searches (15.3.6 Member) for details on finding a specific Member Id.

= Recipient Id.
The claim recipient's identification number. See Extended Searches (15.3.7 Recipient) for details on finding a specific Recipient Id.
= CPR Provider Id.
The Central Provider Registry (CPR) identification number. This is the unique identifier generated by the Emergis Central Provider Registry application. It identifies who the servicing Provider is for the claim in view. Upon selecting a CPR Provider Id.
here, the system automatically populates all Office/Provider fields. See Extended Searches (Error!
Reference source not found. Error! Reference source not found.) for details on finding a specific Provider Id.
= Member Outstanding Balance How much money the member owes.
11.2 MEMBER ELIGIBILITY
The Member Eligibility tab contains the submitted information and is available for all claims other than predeterminations. Self-Admin claims are not matched to the information in GAMA;
the information on this tab will be used by the insurer directly.
Claims Examiners may add member eligibility values for self-admin claims as required. None of the Member Eligibility fields are mandatory; rather, they allow the entry of information that was not previously in the system.
If the claim is in a pended state because it failed the `self-admin' eligibility check, a Claims Examiner can change the values to reflect those provided on the paper claim form.
Changes to information on the Member Eligibility tab will only be saved when the user performs an action on the claim and saves; see 8.3 Claim Actions for more details.
11.2.1 MEMBER ELIGIBILITY
= Group No.
The identification number of the specific group from which unassigned claims for this insurer will be routed.
= Division No.
The external identification number of the division.
= Class No.
The external identification number of the class.
= Member No.
The plan member's identification number.
= Effective Date The date on which this member will become active. Dates must be entered in the form DD-MMM-YYYY.
= Expiry Date The date on which this member will become inactive. Dates must be entered in the form DD-MMM-YYYY.

= Family Flag Select the family type for this member: Single, Family, Couple, Single Parent, Dependant Only.
= Card Sequence Version The sequence or version number associated with a card which details the member's plan.
11.2.2 MEMBER DETAILS
= First Name The plan member's first name.
= Middle Name The plan member's middle name.
= Last Name The plan member's last name.
= DOB
The plan member's date of birth. Dates must be entered in the form DD-MMM-YYYY.
= Language The plan member's primary language of communication. Select English or French.
= Address Enter the plan member's address information, including street address(es), City, Province/State, and Postal/Zip Code.
11.2.3 RECIPIENT DETAILS
= First Name The recipient's first name.
= Middle Name The recipient's middle name.
= Last Name The recipient's last name.
= DOB
The plan member's date of birth. Dates must be entered in the form DD-MMM-YYYY.
= Gender The recipient's gender. Select from Male, Female, or Unknown.
= School Name The name of the recipient's school, if the recipient is a student.
= Relationship Code Select the recipient's relationship to the plan member: Member, Spouse, Dependant, Student, Disabled.
= Exception Code Select the recipient eligibility exception code: Student, Disabled, Disabled Student, or N/A (not applicable).
11.3 CLAIM DETAILS

The Claim Details tab displays the submitted and adjudicated results of the claim. If the claim is pended, the details reflect the adjudication results at the time of adjudication. This may not be the same result received when releasing from pending, dependent on whether or not any changes have been made to the Plan, Member coverage, etc.
Available editable fields depend on the user's role and the claim's current status. Changes to information on the Claim Details tab will only be saved when the user performs an action on the claim and saves; see 8.3 Claim Actions for more details.
= Predet. No.
The number provided on the claim transaction indicating that services have already been submitted on a predetermination transaction. This is the EHIP Reference number of a previously adjudicated predetermination transaction.
The process of adjudicating a predetermination will generate a Predet No. to be submitted when the services are performed.
= Initial Lower Enter Y (yes) or N (no) to indicate if the appliance is the first insertion.
= Initial Lower Date If the Initial Lower is set to N, this date will represent when the original appliance was inserted. This value must be entered in the form DD-MMM-YYYY.
= Ortho Flag Enter Y (yes) or N (no) to indicate whether the submitted services were for Orthodontic purposes = Initial Upper Enter Y (yes) or N (no) to indicate if the appliance is the first insertion.
= Initial Upper Date If the Initial Upper is set to N, this date will represent when the original appliance was inserted. This value must be entered in the form DD-MMM-YYYY.
= Materials Forwarded Enter Y (yes) or N (no) to indicate whether or not supporting documentation was sent.
= Man. Pros. Material Enter the appropriate code to indicate what type of material was used for the mandibular service.
= Max. Pros. Material Enter the appropriate code to indicate what type of material was used for the maxillary service.
= Accident Date A date entered indicating the services on the claim were required because of an accident.
This date represents when the accident occurred. This value must be entered in the form DD-MMM-YYYY.
11.4 PREDETERMINATION

The Predetermination tab only appears when a predetermination claim is opened.
This tab displays estimated information that was entered via EDI prior to the pended claim entering the system. Paper-based claims will not display any field information, and can be modified as required.
Available editable fields depend on the user's role and the claim's current status. Changes to information on the Predetermination tab will only be saved when the user performs an action on the claim and saves; see 8.3 Claim Actions for more details.
The following fields represent what values where submitted in the incoming transaction (EDI/Data Entry). These values may have been used in the adjudication process to assist in the determination of the result.
= Est. Treatment Start Date The estimated date on which the claim's treatment will start. This value must be entered in the form DD-MMM-YYYY.
= Treatment Duration The estimated number of months over which the treatment will be delivered.
= Number of Payments The estimated number of payments.
= Payment Mode Select the anticipated payment mode.
= First Exam Fee The fee charged for the first orthodontic examination.
= Diagnostic Phase Fee The fee charged for the diagnostic phase of the examination.
= Initial Payment The amount of the initial payment.
= Payment Amount The anticipated amount of periodic payments.

11.5 MESSAGES
The Messages tab lists all messages (both internal and external) provided during the adjudication process. The messages recorded include those from Rule Composer Actions, if executed. The payment process selects the appropriate messages to display on the Explanation of Benefits.
Messages can be associated with either the claims or procedures.
Each time a claim is re-adjudicated, Claim Manager updates the message list.
Claims Examiners may review, add, or delete messages for claims in a Pended state. Messages for claims in any other state are read-only.
Note: A Claim Examiner could delete an EOB message and use an external note in its place, if the Claim Examiners expertise determines the system determined EOB message is not applicable. Refer to Figure 43.
11.5.1 REVIEWING MESSAGES
Messages with a status of pend-review or pend-fix are displayed with an asterisk (*) in the OA
column, and must be reviewed.
To review a message:
76. Click to select a message containing an asterisk in the OA column. Examine the message, and ensure that any required business processes are completed.
77. Click Review.
11.5.2 ADDING MESSAGES
To add a message to a pended claim:
78. Click to select the message type from the drop-down list.
= Ext-Note This is a free form note entered by the user. It is printed on the EOB
statements generated by the outputs process.
= EOB
This is a template message that is defined by the carrier and can be attached to the claim. It is intended to explain the results of the adjudication logic.
= Question This is a template questionnaire. It is a series of questions selected by the User to request additional information before adjudication can be completed. A
separate page is created in the Outputs process listing all of the questions selected.
79. Based on your initial selection, enter text in the Ext-Note Text field or select from the available Messages.

80. Click Add Message to save your selections and append the message to the claim.
11.5.3 DELETING MESSAGES
Only messages originating from Claim Manager can be deleted.
To delete a message from a claim's message log:
81. Click to select the message in the list.
82. Click Delete.
11.6 CHANGE LOG
The Change Log tab lists all data changes that have occurred since the claim entered the system.
11.7 CLAIMS EXPERIENCE
The Claims Experience tab lists all claims (including closed and semi-closed) associated with the current recipient.
To display a claim from the Claims Experience list:
83. Click to select the desired claim in the list.
84. Click Open. The system automatically displays the claim details and opens the Eligibility tab. The claims form displays information at a claim level. See 11 Claims Form for details.
11.8 PAYEE
The Payee tab enables a user to override the default payee and change the payee to another party by using a list of payees associated with the member. The user can also select an Override checkbox. If the flag is checked then it is used as the final adjudication value, where as if the flag is not checked then it is used as an initial value but can be changed by the rules of adjudication.
The Validate step only checks Canadian addresses by comparing Postal Code, Province and Street Address. To assist the user when searching for an address, the user can search on one of the following combinations:
1. Postal Code Only, 2. City and Address, 3. Province and Address. Refer to Figure 44.
11.9 RECIPIENT ACCUMULATORS

The Recipient Accumulator tab gives the user a view to the accumulators associated with the current recipient. The Recipient Accumulator tab also provides a link for the user (based on permissions) to the Benefit Maintenance screen, where the user can create or update recipient accumulators.
There are three ways to access the Benefit Maintenance Screen:
1. Select Recipient Accumulators from the services menu in the upper left part of the screen.
2. In the Recipient Accumulator tab, select open from the Recipient Accumulator list located on the lower right hand side of the screen.
3. From the Eligibility tab.
Refer to Figure 45.

The Procedures form displays details at a claim item level.
To display procedure information:
85. Find and open a claim. See 7 Opening Claims in Your Queue or 9 Searching for Claims for details on opening claims.
86. Click the Procedure tab. Depending on the current claim's state, this tab may be titled Procedure, Procedure (R/0), or Predetermination Procedure.
All available procedure information associated with this claim is displayed.
Refer to Figure 46.
87. Modify submitted fields as required.
The Data Entry application enforces some validation rules (such as ensuring that the tooth number and tooth surfaces fields contain values). These edits are not repeated by the Claim Manager application users should use this as a guideline of required data.
= Tooth No.
The tooth code submitted. May represent a tooth number, quadrant, or sextant.

= Surface The submitted surface code. Although the system primarily functions on CDA codes this will represent the true submitted service code.
= Submit Service Code The originally submitted service code.
= Claimed Prof. $
The amount claimed for the professional fee.
= Claimed Exp. $
The amount claimed for expense services. This is determined based on the accompanying service code (lab1/2). If the service code submitted in this field is an expense code, then the related fee is considered an expense fee.
= Claimed Lab $
The amount claimed for lab services. This is determined based on the accompanying service code (lab1/2). If the service code submitted in this field is a lab code, then the related fee is considered a lab fee.
= COB $
Represents the accumulative amount of the primary payer's reimbursement for the submitted service, if the claim is a COB.
88. Click Save to save your changes.
12.1 PROCEDURE OVERRIDE DETAILS
The procedure Items tab allows users to enter benefit amounts based on estimated costs. If any of the required fields are not completed, the system display an error prompting for entry.
Claim Manager determines a final Benefit Amount through the following calculation:
((Elig. Prof. ¨ Ded. Prof.) * Coins.%) * Copay) Therefore, the Elig. Prof., Ded. Prof., Coins. %, and Copay are mandatory fields and must contain valid data.
To calculate the benefit amount for a procedure:
89. Click to select the Override Details tab.
90. Enter as many manual override details as available.
= Elig. Prof. $
The amount determined to be eligible after plan coverage and rules, but prior to the application of deductibles, coinsurance and maximum.
= Lab Elig. $
The amount determined to be eligible after plan coverage and rules, but prior to the application of deductibles, coinsurance and maximum.

= Exp. Elig. $
The amount determined to be eligible after plan coverage and rules, but prior to the application of deductibles, coinsurance and maximum.
= Bed. Prof. $
The amount of the deductible applied (professional eligible amount, labl eligible amount, and lab2 eligible amount).
= Coins. %
The percentage at which the claim item was adjudicated.
= Max $
The out of pocket amount due to a reduction in payment because a plan maximum was reached.
= Lab Ben. $
The amount payable (after deductible, coinsurance and maximum) for the Lab amount portion of the claimed professional fee.
= Exp. Ben $
The amount payable (after deductible, coinsurance and maximum) for the Expense amount portion of the claimed professional fee.
= Benefit Amount The amount payable (after deductible, coinsurance and maximum) for the Professional amount portion of the of the claimed Professional Benefit amount.
= Adjudicated Service Code Enables the user to override the adjudicated service code that was used.
91. Click Calculate to determine the estimated Benefit Amount.
12.2 PROCEDURE LIST
To display all procedures associated with the currently open claim:
92. Click to select the Procedure List tab.
All procedures associated with the claim are listed.
93. Click to select a procedure in the displayed list.
94. Depending on the current user's role and the claim's current state, you can click Open to open the procedure for editing or click View to display the procedure details.
12.3 MATCHING PREDETERMINATION CLAIMS
To display all predetermination claims that match the currently open claim:
95. Click to select the Matching Predet. Tab.
All matching predetermination claims are displayed.
96. Click to select a predetermination claim in the displayed list 97. The available options depend on the current user's role and the claim's current state:
= Click Use to associate the predetermination claim with the current claim.
= Click Un-Use to disassociate this predetermination claim from the current claim.
= Click Delete to mark the predetermination claim as inactive.
Refer to Figure 47.
12.4 PROCEDURE MESSAGES
Messages with a status of pend-review or pend-fix are displayed with an asterisk (*) in the OA
column, and must be reviewed.
To review a message:
98. Click to select a message containing an asterisk in the OA column. Examine the message, and ensure that any required business processes are completed.
99. Click Review.
12.4.1 ADDING MESSAGES
To add a message to a current claim item:
100. Click to select the message type from the drop-down list.
= Ext-Note This is a free form note entered by the user. It is printed on the EOB
statements generated by the outputs process.
= EOB
This is a template message that is defined by the carrier and can be attached to the claim. It is intended to explain the results of the adjudication logic.
= Question This is a template questionnaire. It is a series of questions selected by the User to request additional information before adjudication can be completed. A
separate page is created in the Outputs process listing all of the questions selected.
101. Based on your initial selection, enter text in the Ext-Note Text field or select from the available Messages.
102. Click Add Message to save you selections and append the message to the claim.
1 2.4. 2 DELETING MESSAGES
Only messages originating from Claim Manager can be deleted.
To delete a message from a claim's message log:

103. Click to select the message in the list.
104. Click Delete.

Each claim in the system is associated with a transaction; electronically submitted transactions usually consist of a single claim, whereas paper-based transactions often contain multiple claims in a single transaction. Refer to Figure 48.
13.1 TRANSACTION SEARCH
To find and display transaction information:
105. Under Services, click to select Claim.
106. Select the Transaction Management form.
107. Select a team queue from the drop-down list of teams to which you are assigned.
108. Select the Transaction Search tab.
109. Enter relevant search criteria:
= Submit Dt.
Enter the date that the claim was submitted to the Adjudication Engine. This value must be entered in the form DD-MMM-YYYY.
= EHIP Reference The system generated number assigned when a transaction is divided into one or many claims.
= Reference Id.
The number provided by the external submitting source to enable tracking results.
= Transaction Id.
The system generated number that uniquely identifies the transaction.
110. Click to select a transaction in the search results list.
111. Click Open to display transaction details.
13.2 TRANSACTION PAYMENTS
This tab displays the details relevant to when the transaction was selected for release to the payment process. A transaction cannot be released until all claims within the transaction are no longer in a pended state.
13.3 TRANSACTION CLAIM LIST
This tab displays a list of all claims included in the current transaction.
Depending on the current user's role and the claim's current state, you can click Open to open the claim for editing.

13.4 TRANSACTION ACTIONS
The Actions tab allows users to perform various functions against the current transaction. The available actions depend on the current user's role and the transaction's current state.
To perform an action on a transaction:
112. Under Services, select the Transaction Management form.
113. Open the transaction on which you want to perform the action. See 13.1 Transaction Search for details on opening transactions.
114. Select the Actions tab. The current user's role and the claim's current state dictate the available actions.
115. Click to select the appropriate action, and enter/select any necessary parameters.
116. Click Save to save your changes.
Refer to Figure 49.
13.4.1 REVERSE
At the transaction level, EDI and Paper claims can be reversed. Refused claims cannot be reversed.
Reversed claims must include an Explain Code.
To reverse a claim:
117. Click to select the Reverse action.
118. Select an Explain Code for this reversal.
119. Enter explanatory text in the Note field if desired.
120. Click Save to save your changes.
13.4.2 RE-ASSESS
At the transaction level, only EDI claims can be re-assessed. Refused claims cannot be re-assessed.
Re-assessed transactions must include an Explain Code.
To re-assess a transaction:
121. Click to select the Re-Assess action.
122. Select an Explain Code for this re-assessment.
123. Enter explanatory text in the Note field if desired.
124. Click Save to save your changes.

Users assigned the role of Manager or Level 1 (Claims Examiner, Auditor, or Quality Control) can manage user, team, quality control, and audit information for users and teams to which they are assigned. Users in the role of Super Manager can perform administrative tasks for all users and teams.
= Super Managers can create the Manager user roles and assign users to teams.
= The Manager can perform administrative tasks for the users and teams to which they have been assigned by the Super Manager. The Manager may only assign users within their roles (e.g., Claims Examiner teams can be assigned only to the Claims Examiner Level 1 user role, etc).
= Level 1 roles can perform administrative tasks for all users within their teams.
14.1 USER MANAGEMENT
14.1.1 SEARCH USER PROFILES
To display a user's role and name information:
125. Under Services, select Admin.
126. Select the User Management form.
127. Select the User Search tab.
128. Enter relevant search criteria and click Search. The search results will match all entered criteria; if the search does not contain the required user, try the search again with less criteria.
= User The login name of the user.
= First Name The first name of the user.
= Last Name The last name of the user.
= Role Select the user's role. See 3 Roles for details.
= Team The name of the team to which the user is assigned. See 4 Teams for details.
129. Click to select a user in the search results list, and click Open. The User Management fields are automatically populated with the selected user's information.
Refer to Figure 50.
14.1.2 TEAM ASSIGNMENT
Within each role, teams are assigned specific claims in a queue: all members of a team are configured to work from the same queue. A role may have many teams, but each team can only belong to a single role.
To display and modify a user's team assignment:
130. Under Services, select Admin.
131. Select the User Management form.
132. Search for and select a user profile. See 14.1.1 Search User Profiles for details.
133. Select the Assigned Teams tab.
All teams to which the current user has access are displayed. Each user must be assigned a default team membership.
Click to select a team, and click Toggle Membership to change the user's team assignment setting: Y (included), or N (excluded).
Refer to Figure 51.
14.1.3 RE-ASSIGNING USER CLAIMS
All claims are assigned to a team and (optionally) a specific user within a team.
To re-assign a claim:
134. Search for and select the claim.
= All claims assigned to a specific user can be displayed by searching for and selecting the user (see 14.1.1 Search User Profiles), then selecting the User Claims tab.
= To search for a specific claim, select Claim under Services (see 9 Searching for Claims).
135. Specify a team and (optionally) a user to which the claim will be re-assigned. See Extended Searches (15.3.2 Team and 15.3.1 User) for details on finding a team or user.
136. Click Re-Assign.
The claim's assignment is automatically changed. Click Refresh to update the claim list.
Refer to Figure 52.
14.1.4 CLOSING AND RELEASING CLAIMS
Only claims in a Semi-Closed state can be closed and released. Super Managers cannot close or release claims. See 6 Claim States for details.
To close and release a claim:

137. Search for and select the claim.
= All claims assigned to a specific user can be displayed by searching for and selecting the user (see 14.1.1 Search User Profiles), then selecting the User Claims tab.
= To search for a specific claim, select Claim under Services (see 9 Searching for Claims).
138. Click to select a specific claim.
139. Click Close/Release.
The claim's status is automatically changed.
See 8.2 Closing and Releasing Claims for details on closing claims via the Claim Search form.
14.2 TEAM MANAGEMENT
Within each role, teams are assigned specific claims in a queue: all members of a team are configured to work from the same queue. A role may have many teams, but each team can only belong to a single role.
14.2.1 ADD OR MODIFY TEAMS
Only users logged in as Super Manager can add or modify team parameters. Only the Description field can be modified for existing teams.
To add a team:
140. Log in as a Super Manager.
141. Under Services, select Admin.
142. Select the Team Management form.
143. Click Clear to remove existing field details.
144. Enter team parameters:
= Team Enter the name of the team.
= Role Select the team's role: Claims Examiner, Quality Control, or Auditor. See 3 Roles for details on roles.
= Description Enter descriptive text to identify this team's function.
Refer to Figure 53.
145. Click Save to save your changes.
14.2.2 SEARCH AND MODIFY TEAM PROFILES

To display and modify a team details:
146. Under Services, select Admin.
147. Select the Team Management form.
148. Enter relevant search criteria and click Search. The search results will match all entered criteria; if the search does not contain the required team, try the search again with less criteria.
= Team The name of the team to which the user is assigned. See 4 Teams for details.
= Role Select the team's role: Claims Examiner, Quality Control, or Auditor. See 3 Roles for details on roles.
149. Click to select a team in the search results list.
150. Click Open. The Team Management fields are automatically populated with the selected team's information.
14.2.3 TEAM MEMBER ASSIGNMENT
151. Under Services, select Admin.
152. Select the Team Management form.
153. Search for and select the team. See 14.2.2 Search and Modify Team Profiles for details.
154. Select the Team Members tab.
All available users are listed. To search within the list of users, enter relevant search criteria and click Search.
= User The login name of the user.
= First Name The first name of the user.
= Last Name The last name of the user.
155. Click to select a user, and click Toggle Membership to change the user's team assignment setting: Y (included), or N (excluded).
Refer to Figure 54.
14.2.4 RE-ASSIGNING TEAM CLAIMS
All claims are assigned to a team and (optionally) a specific user within a team.

To re-assign a claim:
156. Search for and select the claim.
= All claims assigned to a specific team can be displayed by searching for and selecting the team (see 14.2.2 Search and Modify Team Profiles), and selecting the Team Claims tab.
= To search for a specific claim, select Claim Search under Services (see 9 Searching for Claims).
157. Specify a team and (optionally) a user to which the claim will be re-assigned. The specified team and user must have the necessary permissions to take ownership of the claim.
See Extended Searches (15.3.2 Team and 15.3.1 User) for details on finding a team or user.
158. Click Re-Assign.
The claim's assignment is automatically changed.
Refer to Figure 55.
14.3 QC MANAGEMENT
Quality Control can be performed on claims based on specified criteria. Only managers with the appropriate permissions can view, edit, or define Quality Control parameters.
14.3.1 VIEW QC GROUPS
To display QC group details:
159. Under Services, select Admin.
160. Select the QC Management form.
161. Select the QC Groups tab. All currently defined groups are displayed.
162. Click to select a group from the display list. The selected group's details automatically populate the group information section.
Refer to Figure 56.
14.3.2 DEFINE GROUPS FOR QUALITY CONTROL
To define a group of claims for Quality Control:
163. Under Services, select Admin.
164. Select the QC Management form.

165. Select the QC Groups tab. All currently defined groups are displayed.
166. Click New.
167. Enter or select all mandatory fields (displayed in blue) and any optional fields.
= Group Id.
The identification number of the specific group within Claim Manager that will be Quality Controlled. See Extended Searches (0 Group) for details on finding a Group Id.
= Group No.
The external identification number of the specific group.
= Effective Date The date on which Quality Control will begin for claims assigned to this group. Dates must be entered in the form DD-MMM-YYYY.
= Expiry Date The date on which Quality Control will end for claims assigned to this group Dates must be entered in the form DD-MMM-YYYY.
= Daily %
A percentage of this group's claims that will be Quality Controlled. This percentage specification must be a number between 1 and 100.
= Daily Max.
A maximum count on the number of claims that can be selected for QC
approval. If reached, this field entry supersedes the Daily % entry.
= >Eligible Amt.
The dollar value after which claims will be selected for QC approval.
= >Benefit Amt.
The dollar value after which claims will be selected for QC approval.
= Source.
Indicates if the source of the claim was paper or electronic.
= Queue/Team The team to which this group's claims will be assigned for QC approval. See Extended Searches (15.3.2 Team) for details on finding a Team.
= Reason Select a reason for why the specified claims are being selected for QC
approval: Default, New User, New Group, General, or Other.
= Description Enter text to describe the QC group.
168. Click Save to save your changes and return to the View screen.
14.3.3 EDIT QC GROUPS
To edit a group's details:

169. Under Services, select Admin.
170. Select the QC Management form.
171. Select the QC Groups tab.
172. Click to select a group from the displayed list. The selected group's details automatically populate the group information section.
173. Click Edit.
174. Modify necessary fields. Mandatory fields are displayed in blue. See 14.3.2 Define Groups for Quality Control for field details.
175. Click Save to save your changes and return to the group view screen.
14.3.4 VIEW QC USERS
To display a list of user's under Quality Control:
176. Under Services, select Admin.
177. Select the QC Management form.
178. Select the QC Users tab.
179. Click to select a user from the display list. The selected user's details automatically populate the user information section.
14.3.5 DEFINE USERS FOR QUALITY CONTROL
To define a user for Quality Control:
180. Under Services, select Admin.
181. Select the QC Management form.
182. Select the QC Users tab.
183. Click New.
184. Enter or select all mandatory fields (displayed in blue) and any optional fields.
= User Type Select whether the user is working with electronic Claim Manager claims (CM-User) or with paper-based reimbursement (PR-USER).
= User The login name of the user that will be Quality Controlled. See Extended Searches (15.3.1 User) for details on finding a User Id.
= Effective Date The date on which Quality Control will begin for claims assigned to this user.

Dates must be entered in the form DD-MMM-YYYY.
= Expiry Date The date on which Quality Control will end for claims assigned to this user.
Dates must be entered in the form DD-MMM-YYYY.

= Daily %
A percentage of this user's claims that will be Quality Controlled. This percentage specification must be a number between 1 and 100.
= Daily Max.
A maximum count on the number of claims that can be selected for QC
approval. If reached, this field entry supersedes the Daily % entry.
= >Eligible Amt.
The dollar value after which claims will be selected for QC approval.
= >Benefit Amt.
The dollar value after which claims will be selected for QC approval.
= Source.
Indicates if the source of the claim was paper or electronic.
= Queue/Team The team to which selected claims will be assigned for QC approval. See Extended Searches (15.3.2 Team) for details on finding a Team.
= Reason Select a reason for why the specified claims are being selected for QC
approval: Default, New User, New Group, General, or Other.
= Description Enter text to describe the QC user.
Refer to Figure 57.
185. Click Save to save your changes and return to the View screen.
14.3.6 EDIT QC CRITERIA
To edit a QC user's details:
186. Under Services, select Admin.
187. Select the QC Management form.
188. Select the QC Users tab.
189. Click to select a user from the display list. The selected user's details automatically populate the user information section.
190. Click Edit.
191. Modify necessary fields. Mandatory fields are displayed in blue. See 14.3.5 Define Users for Quality Control for field details.
192. Click Save to save you changes and return to the user view screen.
14.3.7 VIEW QC INSURERS
To display insurers that have been defined for Quality Control:

193. Under Services, select Admin.
194. Select the QC Management form.
195. Select the QC Overall tab.
196. Click to select an insurer from the display list. The selected insurer's Quality Control details automatically populate the Overall information section.
14.3.8 DEFINE INSURERS FOR QUALITY CONTROL
Overall Quality Control ranges and limits can be applied to the claims for a specific insurer.
To define an insurer's claims for Quality Control:
197. Under Services, select Admin.
198. Select the QC Management form.
199. Select the QC Overall tab.
200. Click New.
201. Enter or select all mandatory fields (displayed in blue) and any optional fields.
= Insurer No.
The identification number assigned to insurer for which claims will be Quality Controlled. See Extended Searches (15.3.3 Insurer) for details on finding an insurer number.
= Effective Date The date on which Quality Control will begin for claims assigned to this insurer. Dates must be entered in the form DD-MMM-YYYY.
= Expiry Date The date on which Quality Control will end for claims assigned to this insurer.
Dates must be entered in the form DD-MMM-YYYY.
= Daily %
A percentage of this user's claims that will be Quality Controlled. This percentage specification must be a number between 1 and 100.
= Daily Max.
A maximum count on the number of claims that can be selected for QC
approval. If reached, this field entry supersedes the Daily % entry.
= >Eligible Amt.
The dollar value after which claims will be selected for QC approval.
= <Benefit Amt.
The minimum amount of benefits selected for QC approval.
= >Benefit Amt.
The dollar value after which claims will be selected for QC approval = Source.
Indicates if the source of the claim was paper or electronic.

= Queue/Team The team to which selected claims will be assigned for QC approval. See Extended Searches (15.3.2 Team) for details on finding a Team.
= Reason Select a reason for why the specified claims are being selected for QC
approval: Default, New User, New Group, General, or Other.
= Description Enter text to describe the QC Overall profile.
Refer to Figure 58.
202. Click Save to save your changes and return to the View screen.
14.3.9 EDIT QC CRITERIA
To edit a QC Overall profile's details:
203. Under Services, select Admin.
204. Select the QC Management form.
205. Select the QC Overall tab.
206. Click to select an Overall profile from the display list. The selected insurer's Quality Control details automatically populate the user information section.
207. Click Edit.
208. Modify necessary fields. Mandatory fields are displayed in blue. See 14.3.8 Define Insurers for Quality Control for field details.
209. Click Save to save your changes and return to the user view screen.
14.3.10 DISPLAY QC SUMMARY
To display the results of each day's Quality Control batch runs:
210. Under Services, select Admin.
211. Select the QC Management form.
212. Select the QC Summary tab. All available QC batch information is displayed.

213. To search the list for a specific batch, enter a Run Date (DD-MMM-YYYY) and click Search.
Refer to Figure 59.
14.4 AUDIT MANAGEMENT
Claims can be assigned for audit based on geographic area, provider, and member.

14.4.1 VIEW PROVIDER AREAS
To display all Provider Areas that are currently defined for audit:

214. Under Services, select Admin.

215. Select the Audit Management form.

216. Select the Audit Provider Area tab. All currently defined Provider Areas are displayed.

217. Click to select a Provider Area from the displayed list. The selected area's details automatically populate the Audit Provider Area information section.
14.4.2 DEFINE PROVIDER AREA FOR AUDIT
To define the claims that will be assigned for audit based on a specific area:

218. Under Services, select Admin.

219. Select the Audit Management form.

220. Select the Audit Provider Area tab.

221. Click New.

222. Enter or select all mandatory fields (displayed in blue) and any optional fields.
= Postal Code Enter the postal code for this area. All claims that originate in the specified postal code area will be selected for audit. A full postal code (for example, T2E7N5) limits the area to a specific location, whereas a partial postal code (for example, T2) encompasses all areas within the T2 geographical location.
= Effective Date The date on which auditing will begin for claims originating in this area.
Dates must be entered in the form DD-MMM-YYYY.
= Expiry Date The date on which auditing will end for claims originating in this area. Dates must be entered in the form DD-MMM-YYYY.
= >Claimed Amt.
The dollar value after which claims will be selected for audit.
= Procedures Enter a full procedure code¨or a comma-separated list of full procedure codes¨for which claims in this area will be selected for audit.
= Insurer No.
The identification number assigned to a specific insurer for which claims from this area will be selected for audit. See Extended Searches (15.3.3 Insurer) for details on finding an insurer number.
= Queue/Team The team to which selected claims will be assigned for audit. See Extended Searches (15.3.2 Team) for details on finding a Team.

= Reason Select a reason for why the specified claims are being selected for audit:
Default, New Member, Fraud Suspicion, or Other.
= Description Enter text to describe the audit area profile.
Refer to Figure 60.

223. Click Save to save your changes and display the View screen.
14.4.3 EDIT PROVIDER AREA
To edit an Audit Provider Area's details:

224. Under Services, select Admin.

225. Select the Audit Management form.

226. Select the Audit Provider Area tab.

227. Click to select a Provider Area from the displayed list. The selected area's details automatically populate the Audit Provider Area information section.

228. Click Edit.

229. Modify necessary fields. Mandatory fields are displayed in blue. See 14.4.2 Define Provider Area for Audit for field details.

230. Click Save to save your changes and return to the Audit Provider Area view screen.
14.4.4 VIEW PROVIDERS DEFINED FOR AUDIT
To display details on providers that have been defined for audit:

231. Under Services, select Admin.

232. Select the Audit Management form.

233. Select the Audit Provider tab.

234. Click to select a Provider from the display list. The selected provider's details automatically populate the Audit Provider information section.
14.4.5 DEFINE PROVIDER FOR AUDIT
To define a provider for audit:

235. Under Services, select Admin.

236. Select the Audit Management form.

237. Select the Audit Provider tab.

238. Click New.

239. Enter or select all mandatory fields (displayed in blue) and any optional fields.

= Provider Id.
The unique identification number for the provider from which claims will be selected for audit. See Extended Searches (Error! Reference source not found. Error! Reference source not found.) for details on finding a specific Provider Id.
= Effective Date The date on which auditing will begin for claims from this provider. Dates must be entered in the form DD-MMM-YYYY.
= Expiry Date The date on which auditing will end for claims from this provider. Dates must be entered in the form DD-MMM-YYYY.
= >Claimed Amt.
The dollar value after which claims will be selected for audit.
= Procedures Enter a full procedure code¨or a comma-separated list of full procedure codes¨for which claims in this area will be selected for audit.
= Insurer No.
The identification number assigned to a specific insurer for which claims from this provider will be selected for audit. See Extended Searches (15.3.3 Insurer) for details on finding an insurer number.
= Queue/Team The team to which selected claims will be assigned for audit. See Extended Searches (15.3.2 Team) for details on finding a Team.
= Reason Select a reason for why the specified claims are being selected for audit:
Default, New Member, Fraud Suspicion, or Other.
= Description Enter text to describe the audit area profile.
Refer to Figure 61.

240. Click Save to save your changes and display the View screen.
14.4.6 EDIT PROVIDER'S AUDIT DETAILS
To edit Provider's audit details:

241. Under Services, select Admin.

242. Select the Audit Management form.

243. Select the Audit Provider tab.

244. Click to select a Provider from the displayed list. The selected Provider's details automatically populate the Audit Provider information section.

245. Click Edit.

246. Modify necessary fields. Mandatory fields are displayed in blue. See 14.4.5 Define Provider for Audit for field details.

247. Click Save to save your changes and return to the Audit Provider view screen.
14.4.7 VIEW MEMBERS DEFINED FOR AUDIT
To display details for plan members that have been defined for audit:

248. Under Services, select Admin.

249. Select the Audit Management form.

250. Select the Audit Member tab.

251. Click to select a plan member from the display list. The selected member's details automatically populate the Audit Member information section.
14.4.8 DEFINE MEMBER FOR AUDIT
To define a plan member for audit:

252. Under Services, select Admin.

253. Select the Audit Management form.

254. Select the Audit Member tab.

255. Click New.

256. Enter or select all mandatory fields (displayed in blue) and any optional fields.
= Member Id.
The unique identification number of the plan member for which claims will be selected for audit. See Extended Searches (15.3.6 Member) for details on finding a specific Member Id.
= Effective Date The date on which auditing will begin for claims from this member. Dates must be entered in the form DD-MMM-YYYY.
= Expiry Date The date on which auditing will end for claims from this member. Dates must be entered in the form DD-MMM-YYYY.
= >Claimed Amt.
The dollar value after which claims will be selected for audit.
= Procedures Enter a full procedure code¨or a comma-separated list of full procedure codes¨for which claims in this area will be selected for audit.
= Insurer No.
The identification number assigned to a specific insurer for which claims from this member will be selected for audit. See Extended Searches (15.3.3 Insurer) for details on finding an insurer number.

= Queue/Team The team to which selected claims will be assigned for audit. See Extended Searches (15.3.2 Team) for details on finding a Team.
= Reason Select a reason for why the specified claims are being selected for audit:
Default, New Member, Fraud Suspicion, or Other.
= Description Enter text to describe the audit area profile.
Refer to Figure 62.

257. Click Save to save your changes and display the View screen.
14.4.9 EDIT MEMBER'S AUDIT DETAILS
To edit a member's audit details:

258. Under Services, select Admin.

259. Select the Audit Management form.

260. Select the Audit Member tab.

261. Click to select a plan member from the display list. The selected member's audit details automatically populate the Audit Member information section.

262. Click Edit.

263. Modify necessary fields. Mandatory fields are displayed in blue. See 14.4.8 Define Member for Audit for field details.

264. Click Save to save your changes and return to the view screen.
14.5 ROUTING MANAGEMENT
Routing rules are defined for each insurer to ensure that all claims are properly routed to the correct team. Rules are processed in descending order for each claim: if the claim does not match the first routing rule, it is checked against the next rule etc. until all rules have been processed.
Claim routing information is only available to users in the role of Super Manager, Manager, and Claims Examiner Level 1.
14.5.1 VIEW ROUTING RULES FOR AN INSURER
To display all Routing Rules that are currently defined for an insurer:

265. Under Services, select Admin.

266. Select the Routing Management form.

267. Select an insurer from the drop-down list. All rules for the selected insurer are displayed in the results list.

268. Click to select a rule from the displayed list. The selected rule's details automatically populate the Routing Control section.

Refer to Figure 63.
14.5.2 CHANGING THE RULE PRECEDENCE FOR AN INSURER
To change the order of rule operations for an insurer:

269. Under Services, select Admin.

270. Select the Routing Management form.

271. Select an insurer from the drop-down list. All rules for the selected insurer are displayed in the results list.

272. Click to select a rule from the displayed list.

273. Click the Move Up or Move Down button to move the selected rule to the desired location.

274. Click Delete to remove any unnecessary or erroneous rule.

275. Click Save to save your changes and display the View screen.
14.5.3 DEFINING ROUTING RULES FOR AN INSURER
To define a new routing rule:

276. Under Services, select Admin.

277. Select the Routing Management form.

278. Select an insurer from the drop-down list. All rules for the selected insurer are displayed in the results list.

279. Click New.

280. Enter or select all mandatory fields (displayed in blue) and any optional fields.
= Queue.
The team to which selected claims will be assigned. See Extended Searches (15.3.2 Team) for details on finding a Team.
= Description Enter text to describe the rule.
= Effective Date The date on which this rule will become active. Dates must be entered in the form DD-MMM-YYYY.
= Expiry Date The date on which this rule will become inactive. Dates must be entered in the form DD-MMM-YYYY.
= Group No.
The identification number of the specific group from which unassigned claims for this insurer will be routed. See Extended Searches (0 Group) for details on finding a Group number.

= Div No.
The external identification number of the division from which unassigned claims for this insurer will be routed. See Extended Searches (15.3.4 Division) for details on finding a Division number.
= Class No.
The external identification number of the class from which unassigned claims for this insurer will be routed. See Extended Searches (15.3.5 Class) for details on finding a Class number.
= Provider Province The two-digit province code for the provider from which unassigned claims for this insurer will be routed:
Alberta - AB
British Columbia - BC
Manitoba - MB
New Brunswick - NB
Newfoundland and Labrador - NL
Northwest Territories - NT
Nova Scotia - NS
Nunavut - NU
Ontario - ON
Prince Edward Island - PE
Quebec - QC
Saskatchewan - SK
Yukon - YT
= Member Province The two-digit province code for the member from which unassigned claims for this insurer will be routed.

281. Click Save to save your changes and return to the View screen.

All Claim Manager Users have access to the following core set of functions.
15.1 SELECTING A SERVICE
By default, Claim Manager displays the Claims form upon login. Users can select to display a different form, and/or specify a new default via the Services Menu.
To select a service:

282. Click the Services menu to display a drop-down list of the available services (dependant on the current user's role).

283. Click to select from the list of available services. A new window is opened with the selected forms loaded.
Refer to Figure 64.
15.1.1 SETTING THE DEFAULT FORM
Each user can specify which form will display at login. To specify a new form as the default:

284. Open the form that you want to display as the default initial screen.

285. Select Set current form as the default from the Services menu.
The default form will be displayed upon the user's next login.
15.2 SEARCHING
Regardless of which task a user is performing, the searching function is similar throughout Claim Manager:

286. Enter relevant search criteria.

287. Click Search.

288. Sort results by any of the primary column headings.

289. Click to select an item in the search results.
If more than one search criteria field is specified, the displayed results will contain only items that match all specified entries. For example, if Member Id. 10098 and Last Name Smith are entered as search criteria, the search may fail even if Member ID 10098 exists but does not have a matching Last Name of Smith.
The available search criteria on each search screen is relative to the user's current process. The screen displayed below is a sample of the claim search screen. This example would allow users to enter or select search criteria in any or all of the available fields. The user could then click Search to generate a list of all results that match the specified criteria.
From the search results, a claim can be selected to Open for display or editing.
Refer to Figure 65.
15.2.1 WILDCARDS
By default, there is an implicit wildcard at the beginning and end of entry fields. Searches will display all results that match exactly the entered characters, as well as any that contain the entered characters plus other text. For example, searching on the name Smith would return all instances of Smith, Smithee, Hammersmith, etc. Similarly, entering 1 in a numeric entry field (e.g., Claim Id.) would return all claims that have a 1 anywhere in the Id.
15.3 EXTENDED SEARCHES
Whenever a field displays an associated El, you can click that button to perform a search on that field. A new window is displayed with search criteria fields available to narrow results choice.
Once a selection is made and the Use button is clicked, the system automatically populates the originating screen's field.
15.3.1 USER LOOKUP
This extended search screen allows a user search based on:
= First Name The first name of the user.
= Last Name The last name of the user.
= Team The name of the team to which the user is assigned. See 4 Teams for details.
= Role Select the user's role. See 3 Roles for details.
= User Id.
The login name of the user.
Refer to Figure 66.
15.3.2 TEAM LOOKUP
This extended search screen allows a user search based on:
= Team The name of the team. See 4 Teams for details.

= Role Select the team's role. See 3 Roles for details.
= User Id.
The login name of the user.
Refer to Figure 67.
15.3.3 INSURER LOOKUP
Automatically lists all of the insurers that the current user is allowed to access. If the list contains too many results, the search criteria fields at the top of the screen allow users to search within the results list for specific data.
= Insurer No.
The identification number assigned to a specific insurer.
= Insurer Label The display name of the insurer.
= Insurer Description The textual description of the insurer.
Refer to Figure 68.
Group Lookup Automatically lists all of the groups that the current user is allowed to access. If the list contains too many results, the search criteria fields at the top of the screen allow users to search within the results list for specific data.
= Group No.
The identification number of the specific group within Claim Manager.
= Group Label The display name of the group.
= Insurer No.
The identification number assigned to a specific insurer.
Refer to Figure 69.
15.3.4 DIVISION LOOKUP
Automatically lists all of the divisions that the current user is allowed to access.
= Division No.
The external identification number of the division.

= Division Label The display name of the division.
= Group No.
The identification number of the specific group within Claim Manager.
= Insurer No.
The identification number assigned to a specific insurer.
Refer to Figure 70.
15.3.5 CLASS LOOKUP
Automatically lists all of the classes that the current user is allowed to access.
= Class No.
The external identification number of the class.
= Class Label The display name of the class.
= Group No.
The identification number of the specific group within Claim Manager.
= Insurer No.
The identification number assigned to a specific insurer.
Refer to Figure 71.
15.3.6 MEMBER LOOKUP
Automatically lists all of the members that the current user is allowed to access.
= Recipient Id.
The claim recipient's identification number.
= Member No.
The plan member's identification number.
= Birthday The birth date of the plan member. This value must be entered in the form DD-MMM-YYYY. For example, 24-09-1960.
= Gender Select the plan member's gender: Male, Female, or Unknown.
= First Name The plan member's first name.
= Last Name The plan member's last name.

= Middle Name The plan member's middle name.
= Insurer No.
The identification number assigned to a specific insurer.
Refer to Figure 72.
15.3.7 RECIPIENT LOOKUP
= Recipient Id.
The claim recipient's identification number.
= Member No.
The primary member's identification number.
= Relationship Cd.
Select the recipient's relationship to the primary plan member: Member (cardholder), Spouse, Dependant (child), Student, or Disabled.
= Birthday The birth date of the recipient. This value must be entered in the form DD-MMM-YYYY. For example, 24-09-1960.
= Gender Select the recipient's gender: Male, Female, or Unknown.
= First Name The recipient's first name.
= Last Name The recipient's last name.
= Middle Name The recipient's middle name.
= Insurer No.
The identification number assigned to a specific insurer.
Refer to Figure 73.
15.3.8 EXPLAIN CODE LOOKUP
= Message Prefix Select a message prefix on which to search: audit, QC, auReopen, cAction, cob, qcReopen, quest, reassess, refuse, reject, reopen, or reverse.
= Message Id.
The message identification number.

= Message Type Select a message type on which to search: audit, QC, auReopen, cAction, eob, qcReopen, quest, reassess, refuse, reject, reopen, or reverse.
= Short Text Enter some or all of the short textual description associated with the explain code.
Refer to Figure 74.
15.3.9 PROVIDER LOOKUP
= CPR Provider Id.
The Central Provider Registry (CPR) identification number.
= Provider Role Code The provider's role identification number.
= Provider Role Desc.
The textual description of the provider's role.
= CDA Provider Code The nine-digit Canadian Dental Association provider identification.
= Work Location Id.
The provider's office identification number.
= Ext. Location Id.
The identification number assigned to an office location by an external organization.
Refer to Figure 75.
15.3.10 PAYEE CODE LOOKUP
= Payee Code The entity who is receiving the payment.
Member ID
The number that identifies a unique plan member.
Refer to Figure 76.
15.3.11 ADDRESS LOOKUP
= Payee ID
The identifier of the entity receiving the payment.
Refer to Figure 77.

15.3.12 ADDRESS SEARCH
Line 1 Is the address of the payee, is mandatory and can be used in combination with a city or province in the search criteria.
Line 2 Is the second address line and is not mandatory.
City Is mandatory, if the province is not part of the search criteria.
Province Is mandatory, if the city is not part of the search criteria.
Postal Code Is an optional field that can be used on its own as a search criteria.
Refer to Figure 78.

Claims

Claims What is claimed is:

1. A method for modifying a hierarchy-based insurance plan for validation as a modified insurance plan through iterative revision or reconfiguration of one or more hierarchies of the insurance plan, the insurance plan used for adjudication of one or more insurance claims over the Internet as machine-to-machine interaction involving a computer server operating as a web service and a plurality of provider devices, the method comprising the steps of:
obtaining by a review engine of the web service a claim adjudicated by an adjudication engine of the web service implementing the insurance plan from a claims queue of the web service, the claims queue for storing claims selected as a basis to review identified errors of the adjudication engine when implementing the insurance plan, the claim sent from the adjudication engine to the claims queue when the adjudication engine makes note of the errors when the claim cannot be automatically adjudicated according to the one or more hierarchies, associated with the insurance plan being a set of benefit codes to define a benefit hierarchy and a set of adjudication rules structured to define a rule hierarchy;
selecting by a user via a user interface of the review engine of the web service at least one modification option of the insurance plan from a) a claim by claim basis using an override specific to the claim, b) plan data including the benefit hierarchy or the rule hierarchy associated with the claim, c) a template hierarchy including a template benefit hierarchy used to develop the benefit hierarchy, or d) a template rule hierarchy used to develop the rule hierarchy;
performing by the review engine of the web service modification of the insurance plan using the at least one modification option, as selected, by either implementing a modification as the override, implementing a modification in at least one of the benefit hierarchy or the rule hierarchy, or implementing a modification in at least one of the template benefit hierarchy or the template rule hierarchy for subsequent use as the modified insurance plan containing said iterative revision and reconfiguration of the one or more hierarchies;
re-adjudicating the claim by the adjudication engine of the web service using the modified insurance plan to produce re-adjudicated results of the claim; and validating the modification by the review engine by presenting the re-adjudicated results to the user and receiving indication of acceptability from the user via the user interface;

wherein the modified insurance plan after the validation, once redeployed, is configured for use by the adjudication engine for processing insurance claims subsequently received over the Internet by the adjudication engine external to the claims queue.

2. The method of claim 1, wherein the set of benefit codes are structured in a plurality of benefit containers including a primary benefit container and a plurality of secondary benefit containers, each of the plurality of secondary benefit containers coupled to the primary benefit container by a respective benefit container reference, each of the plurality of secondary benefit containers containing one or more benefit codes configured for processing claim content of the claim, each of the one or more benefit codes coupled to their respective secondary benefit container by a respective benefit reference.

3. The method of claim 1, wherein the set of adjudication rules is structured in a plurality of rule containers including a primary rule container and a plurality of secondary rule containers, each of the plurality of secondary rule containers coupled to the primary rule container by a respective container reference, each of the plurality of secondary rule containers containing one or more adjudication rules configured for processing claim content of the claim, each of the one or more adjudication rules coupled to their respective secondary container by a respective rule reference of the rule references, such that the primary rule container has a list to define an execution order of the corresponding container references of each of the plurality of secondary rule containers referenced by the primary rule container.

4. The method of claim 1 further comprising reconfiguring the benefit hierarchy by performing at least one of: adding an additional benefit container reference to the primary benefit container; modifying a container benefit parameter of at least one of the benefit container references; or deleting at least one of the existing benefit container references.

5. The method of claim 1 further comprising reconfiguring the rule hierarchy by performing at least one of: adding an additional rule container reference to the primary rule container;
modifying a rule container parameter of at least one of the rule container references; or deleting at least one of the existing rule container references.

6. The method of claim 1 further comprising reconfiguring the benefit hierarchy by performing at least one of: adding an additional benefit reference to at least one of the secondary benefit containers; modifying a benefit reference parameter of at least one of the benefit references; or deleting at least one of the existing benefit references.

7. The method of claim 5, wherein at least one of the rule references or the rule container references is defined to include at least one of an effective date or an expiry date, such that modifying inclusion or exclusion of rule objects associated with the rule references in the rule container is determined by the modification to the effective date or the expiry date.

8. The method of claim 7, wherein the rule container reference is said at least one of the effective date or the expiry date.

9. The method of claim 4, wherein reconfiguration of the benefit hierarchy includes a change to a reference of a benefit code selected from the group comprising: a change in an effective date of the reference; a change in an expiry date of the reference;
a change in a benefit object version associated with the reference; a change to a definition content of benefit codes or benefit containers; and a change in an ordering of the references in a respective benefit container.

10. A computer server operating as a web service for modifying a hierarchy-based insurance plan for validation as a modified insurance plan through iterative revision or reconfiguration of one or more hierarchies of the insurance plan, the insurance plan used for adjudication of one or more insurance claims over the Internet as machine-to-machine interaction involving the server and a plurality of provider devices, the server comprising:
a review engine of the web service for obtaining a claim adjudicated by an adjudication engine of the web service implementing the insurance plan from a claims queue of the web service, the claims queue for storing claims selected as a basis to review identified errors of the adjudication engine when implementing the insurance plan, the claim sent from the adjudication engine to the claims queue when the adjudication engine makes note of the errors when the claim cannot be automatically adjudicated according to the one or more hierarchies, associated with the insurance plan being a set of benefit codes structured to define a benefit hierarchy and a set of adjudication rules structured to define a rule hierarchy, the review engine of the web service configured for receiving a selection of a user via a user interface of at least one modification option of the insurance plan from a) a claim by claim basis using an override specific to the claim, b) plan data including the benefit hierarchy or the rule hierarchy associated with the claim; and c) template hierarchy including a template benefit hierarchy used to develop the benefit hierarchy or a template rule hierarchy used to develop the rule hierarchy;
performing modification of the insurance plan using the at least one modification option as selected, by either implementing a modification as the override, implementing a modification in at least one of the benefit hierarchy or the rule hierarchy, or implementing a modification in at least one of the template benefit hierarchy or the template rule hierarchy for subsequent use as the modified insurance plan containing said iterative revision and reconfiguration of one or more hierarchies; and validating the modification by presenting re-adjudicated results to the user and receiving indication of acceptability from the user via the user interface, the re-adjudicated results received from the adjudication engine after re-adjudication of the claims using the modified insurance plan;
wherein the modified insurance plan after the validation, once redeployed, is configured for use by the adjudication engine for processing insurance claims subsequently received over the Internet by the adjudication engine external to the claims queue.

11. The server of claim 10, wherein the set of benefit codes are structured in a plurality of benefit containers including a primary benefit container and a plurality of secondary benefit containers, each of the plurality of secondary benefit containers coupled to the primary benefit container by a respective benefit container reference, each of the plurality of secondary benefit containers containing one or more benefit codes configured for processing claim content of the claim, each of the one or more benefit codes coupled to their respective secondary benefit container by a respective benefit reference.

12. The server of claim 10, wherein the set of adjudication rules is structured in a plurality of rule containers including a primary rule container and a plurality of secondary rule containers, each of the plurality of secondary rule containers coupled to the primary rule container by a respective container reference, each of the plurality of secondary rule containers containing one or more adjudication rules configured for processing claim content of the claim, each of the one or more adjudication rules coupled to their respective secondary container by a respective rule reference of the rule references, such that the primary rule container has a list to define an execution order of the corresponding container references of each of the plurality of secondary rule containers referenced by the primary rule container.

13. The server of claim 10 further comprising reconfiguring the benefit code hierarchy by performing at least one of: adding an additional benefit container reference to the primary benefit container; modifying a container benefit parameter of at least one of the benefit container references; or deleting at least one of the existing benefit container references.

14. The server of claim 10 further comprising reconfiguring the rule hierarchy by performing at least one of: adding an additional rule container reference to the primary rule container;
modifying a rule container parameter of at least one of the rule container references; or deleting at least one of the existing rule container references.

15. The server of claim 10 further comprising reconfiguring the benefit hierarchy by performing at least one of: adding an additional benefit reference to at least one of the secondary benefit containers; modifying a benefit reference parameter of at least one of the benefit references; or deleting at least one of the existing benefit references.

16. The server of claim 14, wherein at least one of the rule references or the rule container references is defined to include at least one of an effective date or an expiry date, such that modifying inclusion or exclusion of rule objects associated with the rule references in the rule container is determined by the modification to the effective date or the expiry date.

17. The server of claim 16, wherein the rule container reference is said at least one of the effective date or the expiry date.

18. The server of claim 13, wherein reconfiguration of the benefit hierarchy includes a change to a reference of a benefit code selected from the group comprising: a change in an effective date of the reference; a change in an expiry date of the reference;
a change in a benefit object version associated with the reference; a change to a definition content of benefit codes or benefit containers; and a change in an ordering of the references in a respective container.

19. The server of claim 10, wherein an execution order of the benefit codes is associated with the ordering of the container references in the primary benefit container.

20. The server of claim 11, wherein an execution order of the adjudication rules is associated with the ordering of the container references in the primary rule container.