US20200234246A1

US20200234246A1 - Systems and Methods for Benefit Plan Management in Accordance with Captured User Intent

Info

Publication number: US20200234246A1
Application number: US16/746,646
Authority: US
Inventors: Dheeraj MISRA; Sandipan GANGOPADHYAY; Tim BRYAN
Original assignee: GalaxESolutions Inc
Current assignee: GalaxESolutions Inc
Priority date: 2019-01-18
Filing date: 2020-01-17
Publication date: 2020-07-23
Also published as: WO2020150671A1

Abstract

A system for providing end-to-end traceable benefit plans includes an intake engine configured to generate, from input source data, a plurality of benefit plan components having one or more cross-dependencies with respect to each other, wherein the benefit plan components include: data structures reflecting benefit plan aspects and associated rules for implementation with respect to the benefit plan. The system includes an intake dashboard configured to intake the input source data provided by a user via the intake dashboard, the input source data capturing user intent with respect to benefit plan design and/or configuration. The system includes an extractor configured to extract the input source data from source systems, and an assembly module configured to assemble a benefit plan file from the benefit plan components, the benefit plan file associating benefit components with and across workflows and systems. The system includes a claims processing IT environment configured to load the benefit plan file, and to process claims in accordance with the benefit plan file.

Description

This application claims the benefit of U.S. Provisional Application No. 62/794,345, filed on Jan. 18, 2019, the entire contents of which are hereby incorporated by reference.

BACKGROUND ART

A typical benefit management enterprise manages hundreds if not thousands of individual benefit plans, including benefit plans for medical benefits and/or pharmaceutical benefits. These managed benefit plans typically include thousands of groups, millions of members, and hundreds of millions of claims to be processed.
The management of benefit plans also typically involves managing a combination of various disparate components, including data structures for the various aspects of the benefit plans, such as, for example, plan architecture, copays, formularies, networks, accumulators, etc. The intricate interdependencies between these components is usually not documented nor well understood due to the complex nature of the integrations among components.
In addition, in managing benefit plans, it is often necessary to track a large number of process steps as part of the benefit plan management, such as, for example, the process steps for adjudicating claims, including data inputs and data outputs at various steps of the process. Healthcare domains currently utilize either a combination of systems simplistic techniques, such as spreadsheets, emails, and handwritten notes, to capture and manage benefits. The use of such systems and techniques results in multiple challenges. These challenges include: higher costs of managing benefits, reliance on error prone manual work arounds, and a general lack of tracking and maintaining audit friendly information (which may be required for meeting compliance goals). As a consequence, data is often duplicated, and opportunities for the reuse of the benefits components are limited.
An additional consequence of traditional benefit management occurs when errors in adjudicating benefits claims within a claims processing IT environment manifest. Because of the lack of end-to-end traceability at each step of the adjudication processes, it is prohibitively difficult to determine the root cause of the error, as well as its potential effect on the adjudication of other claims. Moreover, if a root cause is eventually identified, it may not be readily foreseeable how changes to the benefit plan components addressing the root cause of the error might affect the adjudication of the changed benefit plan in other respects.
Similar consequences occur when new benefit plans, or changes to existing benefit plans, do not accurately reflect client intent. Because of the large number of components and general lack of end-to-end traceability, it is difficult to determine, once the benefit plan is implemented, the root cause of an inaccuracy, which makes it difficult to make the necessary corrections to align the benefit plan with the client intent.
In order to overcome the above challenges and to efficiently and effectively establish, change and/or otherwise manage benefit plans, the benefit management enterprise should be able to easily and quickly identify cross-dependencies among benefit plan components across the architectural tiers of the benefit plan. Moreover, the benefit plans managed, including new and changed benefit plans, should accurately reflect client intent.
In that regard, a system and method for benefit plan management, particularly in building and maintenance of such benefit plans in accordance with captured user intent, is disclosed herein, which overcomes these and other shortcomings of prior systems and/or methods. Other objects, advantages and novel features of the present invention will become apparent from the following detailed description of one or more preferred embodiments when considered in conjunction with the accompanying drawings. It should be recognized that the one or more examples in the disclosure are non-limiting examples and that the present invention is intended to encompass variations and equivalents of these examples. The disclosure is written for those skilled in the art. Although the disclosure use terminology and acronyms that may not be familiar to the layperson, those skilled in the art will be familiar with the terminology and acronyms used herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example system in accordance with one or more aspects of the disclosure.

FIG. 2 illustrates a diagram of the architecture in accordance with one or more aspects of the disclosure.

FIG. 3 illustrates a flow diagram of an algorithm used by the architecture of FIG. 2 in accordance with one or more aspects of the disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

The disclosure is directed to benefit plan management systems, and more particularly to more efficient management of benefit plans through the building and maintenance of such plans built in accordance with captured user intent and having end-to-end traceability.
A system and method for capturing user intent regarding benefit plan creation and management is described herein. An interactive dashboard is utilized to accurately and automatically generate and assemble benefit components and associated rules for their implementation, which may be accordingly assembled to provide a target benefit plan in accordance with the intent of the user.
A benefit plan file is generated from the benefit components and associated rules according to the captured intent, which benefit file reflects the target benefit plan to be implemented on a target claims processing IT environment. The benefit plan file includes metadata associating benefit components with each other, as well as with and across benefit plan workflows, transitions, conditions, etc., which are also cross-referenced.
Accordingly, in at least one aspect, benefit plans in accordance with the intent of the user may be accurately and automatically built such that there is the ability to perform canonical and customized searches of dependent benefit components, workflows, transitions, conditions, etc., and generate impact reports that can show how desired changes to particular aspects may affect the adjudication of the benefit plan. To that end, manual identification of cross-dependencies and interpretation of data, for instance, may be eliminated.
The present disclosure provides a number of benefits and/or advantages over prior methods of enterprise benefits management. For example, the onboarding of new clients (i.e., employers, health care providers, etc.) to the benefit management system is facilitated by enabling accurate generation of benefit plans automatically in accordance with client intent, which benefit plans may be integrated with downstream benefits management systems, e.g., target claims processing IT environments.
Furthermore, inherent end-to-end traceability is available which may help eliminate the draw-backs of traditional benefits management systems, such as the failure to identify many critical components and dependencies, the duplication of such components, erroneous manual entries and work-arounds, and consistent documentation of the adjudication process. The reuse of benefit components instead of their unnecessary duplication may lead to lower maintenance costs due to a reduction in the number of benefit components that need to be maintained, leading to increased efficiencies in both build and maintenance.
An additional benefit and/or advantage, for example, may be an increased audit readiness, both for internal and external regulatory compliance, such as, for example, CMS directives, due to a reduction in the amount of time spent correlating information with a high degree of accuracy. The end-to-end traceability provided by the benefit plan file intrinsically provides such correlation, which in turn promotes efficiency and reduces errors during auditing.
A further benefit and/or advantage, for example, may be that end-to-end traceability may minimize or even eliminate unintentional impact to the claims adjudication process due to changes to the benefits plan. Impact assessment may drive and enhance the comprehensiveness of benefits plan requirements and design, and provide guidance for targeted regression analysis and test metrics, including an assessment of the risk associated with any proposed change to one or more components of the benefit plan. Test cases may be automatically generated and require only subject matter expert (SME) validation. Automation of quality assurance of claims processing may also be achieved by objectively determining criteria for selecting test claims based on the benefit changes made. Version tracking may likewise be improved.
As used herein, the terms “a” or “an” shall mean one or more than one. The term “plurality” shall mean two or more than two. The term “another” is defined as a second or more. The terms “including” and/or “having” are open ended (e.g., comprising). Reference throughout this document to “one embodiment”, “certain embodiments”, “an embodiment” or similar term means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of such phrases in various places throughout this specification are not necessarily all referring to the same embodiment.
Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner on one or more embodiments without limitation. The term “or” as used herein is to be interpreted as inclusive or meaning any one or any combination.
In accordance with the practices of persons skilled in the art, the invention is described below with reference to operations that are performed by a computer system or a like electronic system. Such operations are sometimes referred to as being computer-executed. It will be appreciated that operations that are symbolically represented include the manipulation by a processor, such as a central processing unit, of electrical signals representing data bits and the maintenance of data bits at memory locations, such as in system memory, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to the data bits.
When implemented in software, the elements of the invention are essentially the code segments to perform the necessary tasks. The code segments can be stored in a processor readable medium. Examples of the processor readable mediums include an electronic circuit, a semiconductor memory device, a read-only memory (ROM), a flash memory or other non-volatile memory, a floppy diskette, a CD-ROM, an optical disk, a hard disk, etc.
In the following detailed description and corresponding figures, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it should be appreciated that the invention may be practiced without such specific details. Additionally, for brevity sake well-known methods, procedures, components, and circuits have not been described in detail.
FIG. 1 illustrates an example system 100 in accordance with one or more aspects of the disclosure. System 100 may include a plurality of computers and/or computing devices, such as, network computer 110, server computer 120, and storage device 130. By way of example only, network computer 110 is connected to network 140 and may include different types of components associated with a computer, such as one or more processors 112, memory 113, instructions 114, data 115, display 116, and an interface 117. The network computer 110 may be mobile (e.g., laptop computer, tablet computer, smartphone, PDA, etc.) or stationary (e.g., desktop computer, etc.). Similarly, server computer 120 may also include one or more processors, memory, interface, and/or display and may be configured to communicate with other computer devices on network 140.
The processor 112 of network computer 110 may instruct the components thereof to perform various tasks based on the processing of information and/or data that may have been previously stored or have been received, such as instructions 114 and/or data 115 stored in memory 113. The processor 112 may be a standard processor, such as a central processing unit (CPU), or may be a dedicated processor, such as an application-specific integrated circuit (ASIC) or a field programmable gate array (FPGA).
Memory 113 stores at least instructions 114 and/or data 115 that can be accessed by processor 112. For example, memory 113 may be hardware capable of storing information accessible by the processor, such as a ROM, RAM, hard-drive, CD-ROM, DVD, write-capable, read-only, etc. The set of instructions may be included in software that can be implemented on the network computer 110 and should be noted that the terms “instructions,” “steps,” “algorithm,” and “programs” may be used interchangeably. Data 115 can be retrieved, manipulated or stored by the processor 112 in accordance with the set of instructions 114 or other sets of executable instructions. The data 115 may be stored as a collection of data.
The display 116 may be any type of device capable of communicating data to a user, such as a liquid-crystal display (“LCD”) screen, a plasma screen, etc. Interface 117 allow a user to communicate with the network computer 110 and may be a physical device (e.g., a port, a keyboard, a mouse, a touch-sensitive screen, microphone, camera, a universal serial bus (USB), CD/DVD drive, zip drive, card reader, etc.) and/or may be virtual (e.g., a graphical user interface “GUI,” etc.).
The server computer 120 (and additional server computers) may be rack mounted on a network equipment rack and/or located, for instance, in a data center. In one example, the server computer 120 may use the network 140 to serve the requests of programs executed on network computer 110 and/or storage device 130.
The storage device 130 illustrated in FIG. 1 may be configured to store large quantities of data and/or information. For example, the storage device 130 may be a collection of storage components, or a mixed collection of storage components, such as ROM, RAM, hard-drives, solid-state drives, removable drives, network storage, virtual memory, cache, registers, etc. The storage device 130 may also be configured so that the network computer 110 and/or server computer 120 may access it via the network 140.
The network 140 may be any type of network, wired or wireless, configured to facilitate the communication and transmission of data, instructions, etc. from one component to another component of the network. For example, the network 140 may be a local area network (LAN) (e.g., Ethernet or other IEEE 802.03 LAN technologies), Wi-Fi (e.g., IEEE 802.11 standards, wide area network (WAN), virtual private network (VPN), global area network (GAN)), any combination thereof, or any other type of network.
It is to be understood that the network configuration illustrated in FIG. 1 serves only as an example and is thus not limited thereto. System 100, for instance, may include numerous other components connected to network 140, include more than one of each network component (as shown by the cascaded blocks), and network 140 may be connected to other networks.
FIG. 2 illustrates one embodiment of an exemplary architecture 200 for benefit plan management. The architecture 200 shown in FIG. 2 includes an intake engine 220, an assembly and design engine 240, and a target claims processing IT environment 260. The intake module 220 includes an extractor 222, an intake dashboard 223, and a design database 224. The assembly and design module 240 includes a builder 242 and a configurer 244. The target claims processing IT environment 260 includes a loader 262 and one or more environment databases 264.
One example of the operation of the system architecture shown in FIG. 2 is as follows.
User intent with respect to the design and configuration of the target benefit plan is determined via the intake module 220, which may be configured to intake source data, as well as benefit components and associated rules utilized in assembling the target benefit plan. The intake dashboard 223 may provide functions enabling the intake module 220 to intake such information, and to determine the user intent. As such, the intake dashboard 223 may be accessible to the user via the GUI through a real-time interactive web portal.
Intake source data reflecting a source benefit plan (i.e., benefit plan data) may be provided to the extractor 222, either directly or via the intake dashboard 223, which extractor 222 may utilize automated parsing and cross-application dependency mapping techniques to identify different benefit components within the source benefit plan and their cross-dependencies, which extracted information is populated into the design database 224. The intake source data may be formatted according to various formats, such as, for example, XML, Excel, Claims System, and Requirements Doc. formats. The intake source data may be provided from a source system, such as, for example, source systems of employer groups and/or internal product design groups. Exemplary automated parsing and cross-application dependency mapping techniques that may be utilized are disclosed, for example, in U.S. application Ser. No. 15/087,786, entitled “System and method for Automated Cross-Application Dependency Mapping,” filed on Mar. 31 2016, the contents of which are incorporated herein by reference in its entirety.
The benefit components populated into the design database 224 include data structures reflecting various aspects of the source benefit plan. For example, benefit components may include plan copays, formularies, networks, accumulators, etc., as well as associated rules for their implementation with respect to the source benefit plan, e.g., workflow call mapping and configuration. The benefit components and their cross-dependencies may also be provided directly to the design database 224 via the intake dashboard 223.
Using the dashboard 223, the user defines and maps the target benefit plan hierarchy, which definitions and mapping are populated to the design database 224. The target benefit plan hierarchy may be defined and mapped through the manual selection and/or entry of benefit plan components. In addition or alternatively thereto, the dashboard 223 may provide a preliminarily defined and mapped target benefit plan, which may be generated based on the intake source data, such as, for example, the intake source data of an template benefit plan.
After the target benefit plan hierarchy is defined and mapped, the dashboard 223 provides to the user one or more questionnaires that are configured to further elicit user intent. Machine learning artificial intelligence may be utilized to design the questionnaire based on the information populated into the design database. The design of the questionnaire may include configurations for tabs or pages, page groups, questions and answers.
User responses to the questionnaires are utilized to configure rules according to which the target benefit plan is to be built, which rules are populated to the design database 224. These rules, for example, may indicate pharmaceutical drug dispensing conditions and/or limitations, etc. The rules are configured by configuring rule categories and loading pre-configured rules and actions. Rules categories may, for example, include: dataset, scenario, templates, record rules, and field rules. Dataset rules may refer to component definitions, such as, for example, Plan, Patient, Pay/Copay, Accumulations, etc. Scenario rules may refer to conditions under which components are called, such as, for example, under Flat Copay or Stepped Copay conditions. Templates rules may refer to definitions for sub-components to be built within the dataset, such as, for example, Patient Pay Schedules with Min/Max, and Patient Pay Schedules without Min/Max. Record rules may refer rules to get data from input. Field rules may refer to rules defined for each field. Machine learning artificial intelligence may be utilized to configure the rules based on the information populated into the design database.
The configured rules are then utilized to configure workflows in accordance with the target benefit plan, which workflows are populated to the design database 224. These workflows, for example, may indicate processing procedures for adjudicating benefits claims, etc. The workflows are configured by configuring activities and steps for the various workflows, workflow transitions and conditions, and workflow roles. Machine learning artificial intelligence may be utilized to configure the workflows based on the information populated into the design database.
The determined user intent with respect to the design and configuration of the target benefit plan, including benefit components and associated rules utilized in assembling the target benefit plan may be exported and assembled into a target benefit plan file in accordance therewith. In this manner, custom target benefit plans having end-to-end traceability, including traceability among and across business, technical and system setup requirements, may be accurately and automatically designed and assembled.
The benefit components populated into the design database 224 are then assembled into a target benefit plan file by the builder 242 in accordance with the various benefit components and associated rules, the benefit plan file reflecting the target benefit plan. The benefit plan file includes data structures and metadata associating benefit components with each other, as well as with and across benefit plan workflows, transitions, conditions, etc., which are also cross-referenced.
In assembling the target benefit plan file, the builder 242 utilizes cross-references between benefit components, in order to avoid the use of duplicative components in building the benefit plan file, and to reuse components for different aspects of the target benefit plan represented by the benefit plan file. To that end, the builder 242 may also create model benefit components from the information in the design database 224, the model benefit components supplanting one or more benefit components.
The builder 242 also utilizes associated mapping rules to configure the benefit components according to the configuration of the target benefit plan. The benefit plan file configuration is provided by a configurer 244, which generates the target benefit plan file configuration from the mapping rules, and provides the benefit plan file configuration to the builder 242. The benefit plan file configuration associates the various benefit components to the target benefit plan workflows, transitions, conditions, etc.
The builder 242 is also provided with a layout reflecting the layout necessary for the target benefit plan file to be successfully loaded into a target claims processing IT environment 260. The builder 242 utilizes the layout to translate the target benefit plan into the benefit plan file having the appropriate layout.
The loader 262 loads the appropriate data from the benefit plan file into relevant associated databases 264 of the target claims processing IT environment 260, which may include databases for plans and plan profiles; copays, drug lists, coverages, DURs, and formularies; client plan ID cross-references; networks and accumulators; and clinical systems. It will be understood, however, that the loading is in accordance with the layout of the target claims processing IT environment 260.
In some embodiments, the target claims processing IT environment 260 is a virtual staging environment via which user interaction with the target benefit plan is possible. The target benefit plan may be accessed by the user through the input/output device, such as a GUI of the network computer 110 and/or the server computer 120, as illustrated in FIG. 1, via a dashboard (not shown). By way of example, interaction with the target benefit plan may include business level review of the benefit plan, testing, editing, generation of summaries, change reports and lists of benefit components. For instance, the target benefit plan may be used to generate service reports for particular end users, customers, and/or consumers, which may be a series of reports on the various aspects of the target benefit plan. These service reports may provide detailed analysis of the various aspects, e.g., components, and their overall impact and/or implications on the target benefit plan. In one example, a service report may be in digital format and may be utilized on one or more GUIs by the end user, customers, and/or consumers.
As described above, FIG. 3 illustrates a flow-diagram 300 of an algorithm used by the architecture of FIG. 2 in accordance with one or more aspects of the disclosure. As shown in FIG. 3, one or more of the foregoing process steps may be iterative in accordance with machine learning artificial intelligence techniques for determining user intent.
At step 301, intake source data reflecting the source benefit plan is provided to the extractor 222, which uses automated parsing and cross-application dependency mapping techniques to identify different benefit components within the source benefit plan and their cross-dependencies, which information is then populated into the design database 224, at step 304. At step 302, the benefit components and their cross-dependencies are provided to the design database 224, and populated therein, at step 305. This step includes the user defining and mapping the target benefit plan hierarchy via the dashboard 223, which definitions and mapping are populated to the design database 224.
At step 303, one or more questionnaires are provided to the user via the dashboard 223, which questionnaires are configured to further elicit user intent. User responses to the questionnaire are gathered at step 304, which responses are populated into the design database 224 at step 305. At step 306, user responses to the questionnaires, as well as information populating the database, are utilized to configure rules according to which the target benefit plan is to be built, which rules are also populated to the design database 224. At step 307, the configured rules are utilized to configure workflows in accordance with the target benefit plan, which workflows are also populated to the design database 224. At step 308, the benefit components populated into the design database 224 are exported, and at step 309, they are assembled into a benefit plan file by the builder 242, in accordance with the various benefit components and associated rules.
At step 310, the loader 262 loads the benefit plan file into the target claims processing IT environment 260. In particular, the loader loads the appropriate data from the benefit plan file into relevant associated databases of the target claims processing IT environment 260, which is then utilized in accordance with the claims adjudication process of the target claims processing IT environment 260. End-to-end traceability of the various components of the benefit plan file is thereby realizable, and the advantages of the invention are achieved.
In accordance with foregoing embodiments, examples, and/or aspects of the invention, all dependencies between benefit components within the target benefit plan are identified. For any benefit component, it is possible to identify all relevant callers across the target benefit plan at any point in time. End-to-end traceability of benefit components across the target benefit plan is therefore provided. A trace may be viewed by starting at any level of the target benefit plan, and the source component that invokes the relevant function, transaction, service, or aspect of the target benefit plan may be identified. The embodiments of the invention therefore provide the ability to search all callers of a particular component across the target benefit plan. In addition, potential orphans and duplicates can be identified.
In a further aspect of the disclosure, as discussed herein, an easy-to-use, intuitive GUI is provided that includes the dashboard that permits a user to view end-to-end traceability of relevant benefit components, functions, transactions, services, or aspects, and to view and navigate between architectural tiers of the target benefit plan (e.g., business processes, workflows and rules, use and/or test cases, component definitions, data elements, etc.). Links may be provided within the GUI that can be clicked by a user in order to navigate directly to the relevant component from a given use case, test case, or business rule, and vice versa.
While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad inventions, and that this inventions not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art.

Claims

1. A system for providing end-to-end traceable benefit plans, the system comprising:

an intake engine configured to generate, from input source data, a plurality of benefit plan components having one or more cross-dependencies with respect to each other, wherein the benefit plan components include: data structures reflecting benefit plan aspects and associated rules for implementation with respect to the benefit plan;

an intake dashboard configured to intake the input source data provided by a user via the intake dashboard, the input source data capturing user intent with respect to benefit plan design and/or configuration;

an extractor configured to extract the input source data from source systems;

an assembly module configured to assemble a benefit plan file from the benefit plan components, the benefit plan file associating benefit components with and across workflows and systems; and

a claims processing IT environment configured to load the benefit plan file, and to process claims in accordance with the benefit plan file.

2. The system of claim 1, wherein the benefit plan is a formulary.

3. The system of claim 1, wherein the input source data includes historical benefit plan data.

4. The system of claim 1, wherein the association of benefit components includes associating benefit components to other components, functions, transactions and/or services called by the benefit component within the benefit plan.

5. The system of claim 1, wherein the claims processing IT environment is a virtual staging environment.

6. The system of claim 1, wherein the claims processing IT environment is configured to provide a report that analyzes benefit plan component impact on and/or implications for the benefit plan.

7. The system of claim 1, wherein the benefit plan components include at least: copays, formularies, networks, accumulators, and associated rules for respective implementation in the benefit plan.

8. The system of claim 1, wherein the assembly module is configured to generate the benefit components from historical benefit components.

9. A method for providing end-to-end traceable benefit plans, the method comprising:

receiving input source data provided by a user via an intake dashboard, the input source data capturing user intent with respect to benefit plan design and/or configuration;

extracting, via an extractor, input source data from source systems;

generating, via an intake engine and from the input source data, a plurality of benefit plan components having one or more cross-dependencies with respect to each other, wherein the benefit plan components include: data structures reflecting benefit plan aspects and associated rules for implementation with respect to the benefit plan;

assembling, via an assembly module, a benefit plan file from the benefit plan components, the benefit plan file associating benefit components with and across workflows and systems; and

loading the benefit plan file into a claims processing IT environment for processing claims in accordance therewith.

10. The method of claim 9, wherein the benefit plan is a formulary.

11. The method of claim 9, wherein the input source data includes historical benefit plan data.

12. The method of claim 9, wherein the association of benefit components includes associating benefit components to other components, functions, transactions and/or services called by the benefit component within the benefit plan.

13. The method of claim 9, wherein the claims processing IT environment is a virtual staging environment.

14. The method of claim 9, wherein the claims processing IT environment is configured to provide a report that analyzes benefit plan component impact on and/or implications for the benefit plan.

15. The method of claim 9, wherein the benefit plan components include at least: copays, formularies, networks, accumulators, and associated rules for respective implementation in the benefit plan.

16. The method of claim 9, wherein the assembly module is configured to generate the benefit components from historical benefit components.