Patent Application
20150019451
Making decisions regarding an applicant's eligibility and entitlement for social benefits is a core part of all social benefits programs. The decisions are usually supported by a set of program rules regarding eligibility and entitlement. A case worker usually makes the decision after collecting data and applying the rules. The data is often received from an application form filled out by an applicant. Some of the data may need investigation by the case worker, such as performing an assessment at the applicant's home, calling an employer to obtain additional data about a job or salary, or requesting a doctor's statement about a type and severity of an illness.
A computer implemented method including populating a data structure, stored on a computer readable storage device, with data for use in determining eligibility for benefits from a benefits program, wherein the data structure comprises a hierarchical structure of entity types including top entity types and child entity types, wherein each child entity instances contain data related to a parent top entity type, performing a verification check on a entity instance data using evidence related to the entity instance data, making a decision regarding eligibility for benefits based on the verified data in the data structure and rules for the benefits program, and storing the data from the data structure utilized in the decision, including the evidence used in the verification check.
A computer readable storage device having instructions for causing a computer to execute a method, the method comprising, populating a data structure, stored on a computer readable storage device, with data for use in determining eligibility for benefits from a benefits program, performing a verification check on the data using evidence related to the data, making a decision regarding eligibility for benefits based on the verified data and rules for the benefits program, and storing the data utilized in the decision, including the evidence used in the verification check.
A data structure stored on a computer readable storage device, the data structure comprising, data for use in determining applicant eligibility for benefits from a benefits program, wherein the data is arranged in a hierarchical structure of entity types including top entity types and child entity types, wherein each child entity instance contains data related to a parent top entity type, and verification data usable in verifying the data, wherein the data in the data structure comprises all data relied upon to determine eligibility and benefits under the benefits program.
In the following description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific embodiments which may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that structural, logical and electrical changes may be made without departing from the scope of the present invention. The following description of example embodiments is, therefore, not to be taken in a limited sense, and the scope of the present invention is defined by the appended claims.
The functions or algorithms described herein may be implemented in software or a combination of software and human implemented procedures in one embodiment. The software may consist of computer executable instructions stored on computer readable media such as memory or other type of storage devices. Further, such functions correspond to modules, which are software, hardware, firmware or any combination thereof. Multiple functions may be performed in one or more modules as desired, and the embodiments described are merely examples. The software may be executed on a digital signal processor, ASIC, microprocessor, or other type of processor operating on a computer system, such as a personal computer, server or other computer system.
A system and method are used to make decisions regarding benefits under a benefits program. A decision basis data structure is used to store the data relied upon to make the decision. The data saved in the decision basis data structure may be relied upon to look back in time to see what the data was when the decision to grant or deny particular benefits under a benefits program was made. This can be quite useful, as data may change over time. Salary information, dependent information, marital status, and other information may change, making it difficult to recreate the information used to make a decision or to calculate an amount of a benefit. In various embodiments, a verification check on the data may be made using evidence related to the data. A decision regarding eligibility for benefits may be based on the verified data and rules for the benefits program. The decision basis may include the data utilized in the decision, as well as the evidence used in the verification check.
At a transaction level 140 web forms 145 are received in one embodiment corresponding to applications for benefits indicated at 150, 155, each having corresponding application costs. The applications contain information that further populates the decision basis 135, and is also evaluated pursuant to a corresponding service plan, two of which are indicated at 160, 165. Different people may have different benefits plans, each with its own corresponding set of rules. Information is also checked for eligibility and entitlement at 170 in accordance with the rules of the plan under which an application is to be processed.
The data which shall be used as the basis for the rules evaluation and finally as the basis for any final decision on eligibility or entitlements can originate from many different sources. Very often, this data is received via the application form for a social benefit or program. The data might partially be received from external sources like the tax authority (for income data), the citizen register (for address and family relations information), or others. Some data might need some ‘investigation’ activities by the caseworkers 130 or other involved parties, e.g. performing an assessment at the client's home, calling the employer to achieve additional data about the client's job, or requesting a doctor's statement about the type and severeness of illness of a client.
Sometimes, the caseworker needs to overrule/overwrite some data which was received from other sources in order to get the right interpretation (or the intended result) for this particular case situation. For example, the ‘official’ size of the client's flat like officially received from a ‘flat register’ or other source of information such as a listing service, might need to be adjusted by the caseworker for the use within this specific case.
Data management in one embodiment focuses on a more centralized data concept which tries to avoid duplicative data and therefore minimizes fraud. In these concepts, the data is expected to be re-used across several business areas, programs and cases, depending on the type of data.
Entity types can be arranged in hierarchical structures. At 215, a benefit program is shown having a decision basis (DBA) type 220. Multiple top entity types 225, 226, 227 are illustrated as coupled to respective child entity types 230, 231, 232, 233, 234, 235. The child entity types contain detail information with respect to the parent entity type. An example could be that salary information is a detail of a working relation. An instance of an entity type is called an entity. An example could be the concrete working relation to employer X. The root entity (type) of a hierarchy is also called a top entity (type).
Each parent entity can have zero to n child entities of the same child entity type. An example could be that one working relation could have zero to many salary information assigned. The data structure of a decision basis type is defined by assigning a set of those entity type hierarchies.
In addition to the working version 330, there is an active version 340 of the decision basis. Just active data may be used by the SSP processes 335. The working version of the DBA 325 is used to set up rules for data collection, changes, and updates, completeness checking to ensure there is sufficient data for a benefits decision and calculation, eligibility determination, entitlement determination, entitlement calculation. After the creation of a decision basis it can be initially filled. Entering of new data at 336 or changing existing data is done on the working version 330 of the decision basis. New or changed data is first checked at 337 to be consistent by rules of the program. Entities could be relevant for a verification at 338 and if verified, an activation step 339 results in activation of the active version 340. If no verification is needed, activation is separated from verification.
In one embodiment, all SSPs of a flow share the same DBA 325, the one the first SSP 335 was assigned to. The first SSP 335 of all flows that share the same DBA creates the DBA and triggers the initial data collection. The SSP process steps eligibility determination, entitlement determination and entitlement calculation just use active data in their rules. New DBA data is entered via the working version 330 and passes the DBA processing to reach the active version 340.
In one embodiment, consistency of the data is a precondition for verification. Verification is a precondition for activation. Verification may be automatically executed top down. If a parent node is not verified, a child node of that parent is not verified. Similarly, if a parent node is not activated, a child note of that parent is also not activated.
Verification information is generated at 420 and in various embodiments, may include a list of verification entries, such as verification date and time, user ID, name of vender, verification text, a flag indicating a source of the information is original, reliability of the source or evidence, evidence valid from—to, and a link. Some of the verification information is optional, such as the validity period of the information and the link.
The link to evidence is indicated as coupled to an evidence source 425, such as a document or system object for example. The verification process 400 utilizes the verification information 420, and may also gather the evidence 425, in order to apply verification rules which may be derived from the program being administered. Two or more items may be compared in order to determine the truth or correctness of a piece of information provided in the application for benefits in one embodiment.
In one embodiment, evidence 425 in the broadest sense includes everything that is used to determine or demonstrate the truth of an assertion. Giving or procuring evidence is the process of using those things that are either presumed to be true, or were themselves proven via evidence to demonstrate an assertion's truth.
User interface 500 provides a user interface for working with decision base processing logic. A working relation screen provides the ability to select consistency checking 510 and verification checking at 520. Fields are included for showing a source type, data source, employer, start date, and end dates. In a decision basis explorer 525 portion of interface 500, fields are provided for entity ID, description, identifier, working state, consistency verification, activation, change ID, business relationship, lock status, etc. Further detail regarding the working relation is illustrated at 530, including the various levels of consistency checking desired at 515 and a verification check menu 535.
Some entities of a decision basis might be verified first before they should be used in a decision making process (SSP). For example, if the salary information would lead to a high payment, the salary information needs to be verified first to check if it is true. Sometimes it is possible to do this check automatically, such as by checking salary against a tax register. Sometimes the check is done manually utilizing caseworker judgment. The automatic and manual versification could also be triggered deep, such as for the selected entity and all entities below.
A rule category is illustrated at 740. The rule category allows a user to define rules for the verification check.
In one embodiment, a completeness check is also provided. The completeness check help a caseworker to identify missing information regarding eligibility determination, entitlement determination or entitlement calculation for a given program administration. During the design time of a decision basis, a corresponding model defines which entities are mandatory and which are optional per usage. In one embodiment, there are three standard usages available, eligibility determination, entitlement determination, and entitlement calculation. A customer may define models specifying which data is mandatory or optional for each such usage.
The decision basis explorer portion 815 includes an entity ID, description, identifier, working state 817, consistency, verification files, activation, change ID, business relations and lock status to name a few example fields. The working state 817 is new for new and not active entities. Active entities get the status active. If an existing active entity is overwritten, the status gets changed to modified until it gets activated again.
The details area 820 displays the details of the entity which is selected in the decision basis explorer 815. If no line is selected, all assignment blocks for the tope entity types are displayed.
The decision basis may be navigated to from multiple different user interface screens while working on one or more cases. For example,
Computer-readable instructions stored on a computer-readable medium are executable by the processing unit 1002 of the computer 1000. A hard drive, CD-ROM, and RAM are some examples of articles including a non-transitory computer-readable medium. For example, a computer program 1018 capable of providing a generic technique to perform access control check for data access and/or for doing an operation on one of the servers in a component object model (COM) based system may be included on a CD-ROM and loaded from the CD-ROM to a hard drive. The computer-readable instructions allow computer 1000 to provide generic access controls in a COM based computer network system having multiple users and servers.
1. A computer implemented method comprising:
2. The method of example 1 and further comprising checking the data in the data structure for a minimum set of data specified for making the decision.
3. The method of any of examples 1-2 and further comprising performing a consistency check on the data in the data structure.
4. The method of example 3 and further comprising checking the data in the data structure for a minimum set of data specified by the benefits program for making the decision.
5. The method of any of examples 1-4 wherein the data used to populate the data structure is obtained from an application for benefits under the benefits program.
6. The method of example 5 wherein the evidence used to verify the entity instance data is obtained from an external source.
7. The method of any of examples 1-6 and further comprising providing an interface to a benefits administrator to facilitate changing the decision made by the computer.
8. The method of any of examples 1-7 wherein the verification check is performed on data from multiple entity instances identified by benefits program rules.
9. A computer readable storage device having instructions for causing a computer to execute a method, the method comprising:
10. The computer readable storage device of example 9 wherein the method further comprises the data for a minimum set of data specified for making the decision.
11. The computer readable storage device of any of examples 9-10 wherein the method further comprises performing a consistency check on the data in the data structure.
12. The computer readable storage device of example 11 wherein the method further comprises checking the data in the data structure for a minimum set of data specified by the benefits program for making the decision.
13. The computer readable storage device of any of examples 9-12 wherein the data used to populate the data structure is obtained from an application for benefits under the benefits program.
14. The computer readable storage device of example 13 wherein the evidence used to verify the child entity instance data is obtained from an external source.
15. The computer readable storage device of example 14 wherein the evidence comprises salary information obtained from an employer of an applicant applying for benefits.
16. The computer readable storage device of any of examples 9-15 wherein the method further comprises providing an interface to a benefits administrator to facilitate changing the decision made by the computer.
17. The computer readable storage device of any of examples 9-16 wherein the verification check is performed on data from multiple child entity instances identified by benefits program rules.
18. A data structure stored on a computer readable storage device, the data structure comprising:
19. The data structure of example 18 wherein the verification data comprises personal information of the applicant obtained from an external source.
20. The data structure of example 19 wherein the data comprises a minimum set of data specified by the benefits program for determining applicant eligibility. Although a few embodiments have been described in detail above, other modifications are possible. For example, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. Other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Other embodiments may be within the scope of the following claims.
