[go: up one dir, main page]

WO2001024040A1 - Station internet: poste de travail internet configurable pour analyse de donnees fondee sur des raisons - Google Patents

Station internet: poste de travail internet configurable pour analyse de donnees fondee sur des raisons Download PDF

Info

Publication number
WO2001024040A1
WO2001024040A1 PCT/US2000/026881 US0026881W WO0124040A1 WO 2001024040 A1 WO2001024040 A1 WO 2001024040A1 US 0026881 W US0026881 W US 0026881W WO 0124040 A1 WO0124040 A1 WO 0124040A1
Authority
WO
WIPO (PCT)
Prior art keywords
report
entity
activity
entities
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2000/026881
Other languages
English (en)
Inventor
Craig Nies
Jean De Traversay
Arati S. Deo
Anu K. Pathria
L. Steven Biafore
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
HNC Software Inc
Original Assignee
HNC Software Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/672,142 external-priority patent/US7418431B1/en
Application filed by HNC Software Inc filed Critical HNC Software Inc
Priority to AU78403/00A priority Critical patent/AU7840300A/en
Publication of WO2001024040A1 publication Critical patent/WO2001024040A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

  • WEBSTATION CONFIGURABLE WEB-BASED WORKSTATION FOR REASON DRIVEN DATA ANALYSIS
  • the present invention relates to workstations and user interfaces for data mining generally, and more particularly, for analyzing and manipulating the results of predictive models.
  • Many existing database mining applications are hardcoded, and require customized development by experienced programmers.
  • the present invention overcomes the limitations of existing database mining platforms by providing methods for viewing the results of predictive models with report trees.
  • the predictive model scores entities and ranks them by their score.
  • the report tree includes a number of hyperlinked reports, including a summary level report that summarizes data that contributes to a reason that the entity was included in the scored output.
  • the hyperlinking allow a user to quickly navigate through a complex collection of data, to identify, for example, suspicious or fraudulent activity by an entity.
  • a predictive model may score healthcare providers for the likelihood of fraud based on their reimbursement claims for healthcare services to patients (reimbursements may be requested after the service is provided, at the time is being provided, or prior to the service being provided).
  • the predictive model provides a ranked order listing of providers, and a reason that each provider is included. The reason may be based on some significant aberration in the provider's claims.
  • the report tree allows a user to explore this difference by exploring complex data relationships and underlying individual transactions (e.g. claims), and by statistically comparing the provider's activities with activities of the provider's peers.
  • One aspect of the invention allows the user to dynamically select different peer groups for comparing and contrasting an entity's behavior.
  • a separate feature of the invention is the ability to create web sites on the fly which contain selected reports from a report tree. A user, while investigating an entity via the report tree, and selectively include different reports into a casebook which forms a web site that others can access to very quickly see the reports of interest.
  • Yet another separate feature of the invention is a frame based user interface layout for web pages that includes a main menu frame, a display frame, a context menu frame, and a navigation frame.
  • Fig. 1 is an illustration of an exemplary predictive solution system providing a WebStation interface.
  • Fig. 2 is an illustration of the development and execution phases of a predictive model system.
  • Fig. 3 is an illustration of the deployment environment for a WebStation.
  • Fig. 4 is an example of a report tree.
  • Fig. 5 is a schematic illustration of the report frame layout for the user interface of the WebStation.
  • Fig. 6a is an illustration of a sample 2-By Peer chart layout
  • Fig. 6b is an illustration of a distribution plot.
  • Fig. 7 is a logon screen.
  • Fig. 8 is a user's home page in the WebStation.
  • Fig. 9 is a suspect list page.
  • Fig. 10 is a provider summary page.
  • Fig. 11 is a graphical high-level summary page.
  • Fig. 12 is a patient list page.
  • Fig. 13 is a patient specific claim data page.
  • Fig. 14 shows the use of the filter function in the context of the patient specific claim data page.
  • Fig. 15 shows the use of the sort function in the context of the patient specific claim data page.
  • Fig. 16 illustrates the layout function in the context of the patient specific claim data page.
  • Fig. 17 illustrates the Procedure and/or Diagnosis Groups report.
  • Fig. 18 illustrates the Flip Client Summaries report.
  • Fig. 19 illustrates the Provider Chart report.
  • Fig. 20 illustrates the Client Age Breakdown report.
  • Fig. 21 illustrates the Monthly Activity report.
  • Fig. 22 illustrates the Client Consecutive Visits report.
  • Fig. 23 illustrates the Group Participation report.
  • Fig. 24 illustrates the Dollars Per Claim report.
  • Fig. 25 illustrates the Per Day Activity report.
  • Fig. 26 illustrates the Per Client Volume report.
  • Fig. 27 illustrates the Multiple Physicians Per Day report.
  • Fig. 28 illustrates the relationship of the various case management screens.
  • Fig. 29 illustrates a sample case list.
  • Fig. 30 illustrates a sample new case message screen.
  • Fig. 31 illustrates a sample case summary screen.
  • Fig. 32 illustrates sample find target screen.
  • Fig. 33 illustrates a sample action screen.
  • Fig. 34 illustrates a sample case log screen.
  • Fig. 35 illustrates a sample search screen.
  • Fig. 36 illustrates a sample case list screen.
  • the Analysis WebStation provides a system, method, and software product with a user interface that enables end-users to view, understand, analyze and act upon the results of predictive models. Though the WebStation may also be used with other application areas using various types of transactional data, in this disclosure, an exemplary embodiment for predictive solutions is discussed.
  • the Data Source 1 10 refers to the raw data upon which the predictive decision will be based. This source often consists of transaction data and supporting data such as demographics or master-file data describing individual "entities.” In one embodiment, such as for analysis of healthcare claims, the Data Source 1 10 may contain 2-4 years of historical claims data, provider master-file data and recipient eligibility data. Claims data may typically span all types of covered services including inpatient, outpatient, pharmacy, dental and long-term care data.
  • the Detection System 120 inputs are derived from the Data Source 1 10.
  • the Data Source 1 10 is processed through conventional training methodologies to develop the Detection System 120.
  • the Detection System 120 may include Predictive Models 121 and/or Rules 122.
  • the Detection System 120 is preferably a statistical model (e.g. a neural network, multivariate regression, or the like) or a procedural model (e.g. decision tree, expert system), or even a combination of both.
  • the Predictive Models 121 may be developed using supervised or unsupervised learning techniques.
  • the Predictive Models 121 generate predictive results (usually in the form of a score(s) with associated reasons, and a series of summary reports that will be viewed via the WebStation 150).
  • the target of a Predictive Model 121 or Rule 122 is the entity whose fraud risk is being assessed.
  • a model may generate a fraud score for a healthcare provider, a healthcare provider-group, a licensee, a recipient or any of a number of other "entities.”
  • each Rule searches for patterns of activity that relate to a specific entity.
  • a Target Id takes the form of an Id for the entity being assessed.
  • the Target Id may refer to a provider number, a license number, or a recipient number, or the like.
  • the target may even be a combination-entity such as provider-recipient pair, in which case the two Id numbers are concatenated to form the Target Id.
  • the results of the Detection System 120 are stored in the Results Database 140.
  • This database may also contain pre-computed reports designed to help human reviewers determine the best actions to take in response to identified outputs (e.g. identified fraud patterns).
  • the Database 140 serves as the communications path for delivering detection results generated by the Detection System 120 to the end users via WebStation and optional third-party reporting or visualization tools.
  • the Database 140 provides quick access for end-users and enables execution of complex detection queries in a reasonable amount of time.
  • the Summarized Data Generator 130 transforms the raw data in the data source into summary data to be displayed to end-users by the WebStation 150.
  • the summarized data is stored in a set of data tables in the Database 140.
  • the WebStation 150 provides an interface for end-users to view the predictive results stored in the Database 140 and data from other databases such as raw or summarized data relevant to the end-user.
  • the WebStation 150 is a highly configurable and general-purpose interface, designed to serve as interface for many different predictive applications in many different industries. As further explained below, the user interface features of the WebStation are implemented as web pages with hyperlinks between them for navigation purposes.
  • the WebStation 150 includes a Report Tree module 170, a Case Management module 180, a Configuration File 190, and a WebStation Builder module 195.
  • One embodiment of the interface deployed using the WebStation software is for a healthcare fraud and abuse detection product, hereafter sometimes called "Spyder” or “Spyder Analysis WebStation.”
  • the Data Source 110 contains healthcare claims, provider data, patient demographics and other supporting data.
  • a typical Data Source might contain data for 100,000 providers, 2 million recipients, and several hundred million claim details (where there is one detail for every medical service claimed). The scope of this data further evidences the usefulness of the WebStation for mining the data through the report tree and other features.
  • the Dection System 120 assigns a fraud-risk score to each "entity" (provider, patient, etc.), and generates explanatory reasons for each score.
  • the Summarized Data Generator 130 builds a set of data tables that summarize provider, patient and peer-group activity. (Peer groups are populations of entities that are expected to have similar activity patterns. For example, a provider peer group might contain providers who have the same medical specialty and who deliver services in the same general geographic location.)
  • Spyder's WebStation Database 140 contains the fraud-risk scores and associated reasons for all scored entities, summarized data, WebStation 150 user information (passwords and security information, for example), case-management information (case status and tracking information, for example), and supporting tables, such as tables to associate text descriptions with medical procedure (CPT) codes, diagnosis codes, zip codes and other similar "look-up" data.
  • CPT medical procedure
  • end-users operate a Spyder Analysis WebStation 150 by starting the web-browser on their desktop, navigating to a Spyder URL, and logging in via Spyder's login page. Once logged in, the user navigates from page to page via hyperlinks, as with any web site. Further details of the operation of the Spyder Analysis WebStation are described in Section IV.
  • Spyder is used as a concrete example of the one possible implementation of a WebStation 150.
  • Other examples where the WebStation could be deployed include worker's compensation claimant fraud detection, worker's compensation employer fraud detection, credit-card fraud detection, credit-card profitability and risk prediction, worker's compensation care management triage, healthcare outcomes prediction or any other predictive task.
  • the Development Phase 200 begins with the loading of data extracts 205 onto a hardware platform, into the Data Source 1 10.
  • the Data Preprocessing 210 step transforms the raw data (claims and supporting data, for Spyder) into behavioral profiles (e.g., of providers, patients and other entities for a Spyder-type embodiment). These profiles are the source of model inputs 215.
  • the Development process continues with the execution of the current model 220, generation of suspects 236 and gathering 230 of feedback 235 (assessing the quality of high-scoring suspects). This feedback 235 drives the tuning of the model to ensure that it operates optimally in the customer environment.
  • data extracts 205 are fed to the Detection System 120 where behavioral profiles are computed and the predictive models and/or rules are executed to generate predictive outputs (for Spyder, these are fraud risk scores for each provider and explanatory reasons for each scored provider).
  • the scores and reasons 280 are packaged into a file for loading into the WebStation Database 140.
  • Data extracts 205 also feed into Summarized Data Generator 130 process that computes all of the summary information required to support WebStation operation by end users.
  • the summarized data 270 is also packaged into a file for loading into the WebStation Database 140.
  • the System Database 330 refers to all data sources that are accessed by the WebStation 150. This may be one physical database or several different physical databases, each containing some of the data required by the WebStation 150.
  • the WebStation Server process 150 stands between end users and the System Database 330, accessing and delivering data to meet each user's requests. Users operate the WebStation through a web browser 160 installed on their desktop.
  • the WebStation 150 for a particular predictive application is a software application that is built by a partly automated and partly manual process.
  • the automated part is done by the WebStation Builder process 195, which reads a WebStation Configuration File 190 and generates some of the WebStation software.
  • Section VIII, "WebStation Configuration File” provides a desc ⁇ ption of this process Manual software development then completes the specific WebStation software for each particular predictive application
  • the WebStation 150 includes various different innovations
  • each Predictive Model 121 has a Reason- Driven Report Tree (Report Tree)
  • the Report Tree is a collection of reports, which are graphical and/or tabular views into the data contained in the System Database The reports are organized into a tree, with high-level summarized data near the root, and detailed or "raw" data at the leaves Fig 4 shows a sample Report Tree 400 for a detection model
  • the Report Tree 400 for a model or rule begins with the Suspect List 402 — this is the "root" of the tree Emanating from the root, for each suspect there is one branch 404 for each reason (reasons are explanations of predictive results) the suspect is included in the Suspect List
  • a high- level summary report that displays data in tabular and/or graphical form displaying information related to that reason
  • These reports are preferably pre-defined (and may be pre-computed and stored as separate tables in the Database 140)
  • the Procedure Mix Report displays, for each major group of procedures, the amount of activity that the suspect delivers in that group and the amount delivered by his peers
  • the user can follow links (e g through hyperhnked buttons or other user interface elements) to more detailed reports (moving from the root toward the leaves of the Report Tree) For example, in the Spyder Analysis WebStation, the user can link from the Procedure Mix Report to a Distribution Chart for any of the major procedure groups The user can also link from the Procedure Mix Report to the Patient Summary Table (a table with one row per patient that the suspect provider has treated, summarizing each different patient's past activity) From the Patient Summary Table, the user can link to the Patient Claim Detail Table (which shows the actual procedures delivered for that patient)
  • Patient Summary Table a table with one row per patient that the suspect provider has treated, summarizing each different patient's past activity
  • the WebStation allows users to "move around” on the Report Tree, navigating out to the leaves (most detailed reports) and then going back to the same or different high-level summary reports (closer to the root).
  • the reports in the Report Tree are pre-defined, but the user can modify them through a va ⁇ ety of actions including changing the sort order of data in tables, filtering (executing a sub-query) the data in a table, changing the peer group for data shown in peer-compa ⁇ son tables and other similar actions
  • Each Report Tree 400 has an associated Table Tree in the Database 140, listing the table included in each report node.
  • each table contains pre-computed results and each node in the Report Tree maps to a single table in the Database
  • the Report Tree 400 allows users to easily follow a logical path of reports to develop a deeper understanding of the predictive results. For example, for a Spyder-type environment, the Report Tree 400 helps users review each identified suspect provider without a detailed knowledge of the specific reports that are available. More generally, for each predictive model, this path is defined by the most important score-reasons identified for inclusion of a suspect The reasons determine which part of the tree 400 the user will explore. Along each branch the user is presented with clearly identified links to other summa ⁇ es or detail raw data.
  • Report Tree 400 defines a default sequence of reports for review, the WebStation allows users (who are familiar with the reports that are available) to view any report at any time
  • Section V "Report Tree Example” provides a detailed illustration of an actual Report Tree for one of Spyder's predictive models
  • Section IV "Spyder Analysis WebStation: A Quick Introduction” also desc ⁇ bes a report tree usage in detail.
  • the same Report Tree concept applies to rules when these are used.
  • the content of the reports depends upon the specific content area being analyzed (e.g. fraud and abuse scams) that the rules are designed to detect.
  • rules typically target specific in the lowest level data e.g., claims
  • the Report Trees for rules typically contain fewer levels than those for models The user will typically see one summary report followed by a listing of detailed claims that caused the rule to fire WebStation Frame Layout
  • Viewing data is a central function of the WebStation. It is desirable to present data in a clear, easy to understand and consistent format. To this end, the WebStation follows a specific frame-based layout, with each frame displaying a specific type of information, and enabling users to perform a specific set of functions.
  • Framework is a web browser term with a specific technical definition in the HTML standards. To the user, a frame is a region on the screen, usually rectangular in shape with a clearly shown boundary that their browser treats as a separate region for control, viewing, printing and other functions.
  • the WebStation frame layout is designed to make operation of interface easy and intuitive. When presenting data within the WebStation, three frames are presented and preferably always occupy the same location onscreen.
  • Fig. 26 illustrates the frame layout.
  • the Main Menu Frame 502 provides a quick way for users to move from one part of the user-interface to another. Using the Main Menu Frame 502 the user can move directly to any of the main screens of the user interface. The contents that appear in the Main Menu Frame do not change as the user moves about the interface. The Main Menu Frame appears at the top of the browser window 500.
  • the Context Menu Frame 508 provides functions that make sense given what the user is currently viewing on-screen. For example, when a data table is visible in the Display Frame 504, the Context Menu Frame displays functions like sorting, filtering and changing the table layout. The Context Menu Frame appears (only when needed) at the far left hand side of the browser window.
  • the Display Frame 504 presents information. It is the largest frame, occupying most of the screen. What is shown in the Display Frame depends upon the function that the user is working to accomplish. Sometimes the data frame shows a table of data, sometimes it shows a graphical report, sometimes it shows a form for the user to fill-in and submit. Readability is the primary objective, so special consideration is given to color, font, spacing shading and other graphical methods that make viewing data easier.
  • the Display Frame shows data from a single database table (thus corresponding to a single report in the Report Tree).
  • the way the data looks on-screen is specified by the Display Type.
  • Data Grid Shows data in tabular form.
  • 2-By Peer Chart Shows data as a table of bar-charts comparing individual vs. peer values. The table is defined by up to two "by" variables (such as patient age and sex).
  • Fig. 6a illustrates a sample 2-By Peer Chart.
  • Distribution Plot Shows the histogram (bar-chart) for a variable across the individual's peer-population, with a vertical line indicating where the individual falls in the distribution.
  • Fig. 6b illustrates a sample distribution plot.
  • the Report Tree Navigation Frame 510 shows a recent history of the user's path within the Report Tree 400.
  • the Report Tree Navigation Frame appears only when the user is viewing reports in the Report Tree.
  • Icons 512 appear in this frame representing previously viewed reports in the Report Tree 400. By clicking on any of these icons, the user will go immediately to the associated report in the Report Tree.
  • the Report Tree Navigation Frame is a very narrow frame that appears at the bottom of the browser window.
  • Case management refers to the set of functions required to create, update, understand and track cases. Depending upon the specific predictive application, investigation of a case can span a range of activities from desk-audit (looking more closely at the data relevant to a specific predictive result) to field-investigation (which, for some applications, may include under-cover work, interviews, surveillance etc.).
  • a "case” refers to a suspect that has been deemed appropriate for further review or investigation. This review typically starts out as an internal analysis of the suspect's behavior, but may at some point involve external organizations or become a legal case in a court of law.
  • a case always has a status (open, under investigation, closed as valid, closed as fraud, etc.).
  • a case is created when an identified suspect is first "locked” by an authorized user. Over its lifetime a case may be worked by many different users, but at any given instant, only one user can lock the case. At that instant, case-management functions (changing case status, attaching comments etc.) can only be performed by a user that has locked the case. When a case is locked it is viewable by other users but cannot be locked by another user until it is released by the first user.
  • Each case has a unique Case Id that serves as a label for the case as long as the case is stored in the system.
  • the WebStation allows case management functions to be included "seamlessly" (to the user, it looks like case-management functions are built-into the WebStation).
  • the WebStation Main Menu Frame 502 can include case-management functions (such as "Assign Case” and "Goto Case") and the WebStation knows when a user is in a context to perform these functions. Once the user navigates to a case, they may modify it if they have the proper authorization to do so.
  • the WebStation guarantees that multiple users cannot modify a case at the same time.
  • the Case Management Module preferably provides this integration
  • the Case Management module tracks a variety of information about each case, including reviewer comments, action notes and status changes. Because all case related information is time- stamped the complete history of each case can be reconstructed (who reviewed the case, when they reviewed it, what they thought about the suspect, actions they took and the status they assigned to the suspect)
  • Each case has an associated collection of fraud-risk assessments (one or more model scores and/or query results), summary reports, user comments and status updates that relate to the "entity" that has been identified as a suspect for fraud, abuse or waste.
  • fraud-risk assessments one or more model scores and/or query results
  • summary reports user comments and status updates that relate to the "entity" that has been identified as a suspect for fraud, abuse or waste.
  • entities whose behavior may be analyzed by the Detection System 120. These include providers, recipients, licensees and provider groups Every case relates to some specific entity.
  • the Case Management module 180 provides functionality to:
  • Management users are authorized to perform all functions This includes user-management, management reporting, assigning cases to users, viewing all detection results and reports and all case management functions
  • Internal users are authorized to perform all viewing and case-management functions. • Internal Limited users are allowed to perform all viewing and case- management functions for only those entities (providers, recipients etc.) that appear m their access list.
  • the Case Management Module 180 further provides functional related to the management of queues.
  • a queue is a list of suspects.
  • a queue is defined by a set of entry criteria (conditions that have to be met in order for a suspect to be included in the queue)
  • a queue can serve many different purposes For example, a queue may be defined to include suspects from a limited geographic region Then, a Management user can assign a user to the queue so that investigative work that requires travel to the same region is handled by the same investigator. Similarly, queues can be defined to distribute work across the available staff based upon medical specialty, type of fraud scheme, case status or other criteria
  • queues can be used to implement and track specific fraud and abuse strategies. For example, a queue could be defined to focus on fraud and abuse for high-volume providers. Such a queue would have two c ⁇ te ⁇ a, (fraud-risk score > X AND dollar-volume > Y) Using the Case Management module. Management users define new queues, and modify existing ones
  • An entity is a logical unit that can be characterized by looking at a collection of related data items. Examples of entities include providers, recipients, licensees, provider groups, provider-provider pairs (linked through referrals, for example) and provider-recipient pairs The behavior of each of these entities can be captured by looking at different "slices" of the historical claims data. An entity may be the focus of a fraud detection model or may simply be used to help understand the behavior of another entity (for example, looking at the behavior of the patients a provider has treated in order to better understand the behavior of the provider)
  • the target of a detection model or rule is the entity whose fraud risk is being assessed
  • a model may generate a fraud score for a provider, a provider-group, a licensee, a recipient or any of a number of other "entities"
  • each detection rule searches for patterns of activity that relate to a specific entity
  • Case-management functions are described in Section VII, "Case Management Module Software”, along with illustrative aspects of the case management user interface. Additional case-management concepts (such as the Web Casebook) are described in Section VI, "WebStation Functional Description.” The seamless integration of case management functions is shown in the screenshots described in Section IV, "Spyder Analysis WebStation: A Quick Introduction”.
  • This section provides a quick introduction to the Spyder Analysis WebStation embodiment of the present invention.
  • This embodiment focuses on using the features of a WebStation in a predictive solution for analyzing healthcare fraud and abuse; other applications of the WebStation are certainly possible.
  • the goal is to illustrate the basic functionality and show how a WebStation embodiment can be used to review suspects identified by the Detection System 120.
  • the WebStation is a browser-based application, as such it requires no desk-top software installation beyond a conventional browser, such as Netscape Navigator (version 4.x or higher) or Internet Explorer (version 4.x or higher). Users who access the Internet via one of these browsers should find operating a WebStation 150 fairly intuitive. Like web sites on the Internet, the WebStation 150 uses links on one page to get to other pages. In the WebStation 150, these pages contain information about suspects identified by the Detection System 120, which the Spyder embodiment are models and rules pertaining to healthcare fraud and abuse.
  • the WebStation 150 is designed to help users take the first step in analyzing detection results. Users may or may not be able to pinpoint the specific claims that are inappropriate, abusive or fraudulent, but they should be able to determine whether or not more detailed investigative work is required, or if there is a valid explanation for the suspect's activity. To accomplish this, the WebStation 150 presents suspect lists, and enables users to view a wide array of summary reports describing the suspect. These reports provide insight into the suspect's activity at many different levels of granularity, from high-level summary to claim line-item detail. The claims data, suspect-lists and summary reports that the WebStation presents onscreen are housed in a database 140.
  • FIGs. 7-16 there is shown a sample user session with an embodiment of the WebStation.
  • a WebStation session begins when the user logs on.
  • the logon page (Fig. 7) is the first page presented and requires users to enter their user-ID and password.
  • Each WebStation user has an assigned access-level that determines which functions they can and cannot perform. For example, only a Management-Level user can assign cases to other users, add new users to the system or change the access-level of an existing user.
  • the first page (Fig. 8) that WebStation users see is the primary detection page 800 (sometimes referred to as the "home" page) which lists the detection models 810 and rules 820 that have produced a list of fraud and abuse suspects. Because Spyder suspects can be providers, patients or other "entities,” the predictive models 815 and rules 830 are organized by the type of "entity" they detect.
  • a color-coded bar at the far left of the screen (“Provider Detection” 840) indicates the type of suspect (here "providers") that is being assessed by the detection models and rules.
  • the “Description” button 850 When the user selects the "Description” button 850, a text description of the model or rule is shown. (Rules for patients and other entities are not shown in this example.)
  • the WebStation presents information in "frames." When a user looks at a screen, they will typically be looking at several different frames as described above with respect to Fig. 5.
  • the screen shown in Fig. 8 includes two frames, one (the Display Frame 504) shows the lists of available models and rules, the other (the Main Menu Frame 502) appears as a set of "tabs" 860 at the top of the screen.
  • the WebStation shows these same tabs on all subsequent screens. These tabs operate like a "main menu” allowing users to select the major functions that the WebStation provides, no matter where they currently are within the WebStation. o
  • the WebStation' s "main menu” functions include:
  • suspect list for each predictive model 815 or rule 830.
  • This suspect list forms the "root" of a reason-based report tree, such as illustrated in Fig. 4. As the name suggests, this is a collection of reports, organized into a tree. The suspect list is the root, then, for each category of explanatory reason, there is a different branch.
  • the first report along each branch is a high-level summary that presents an overview of activity related to that branch's reason category. As the user moves down the branch, they can select specific reports to view.
  • the reports near the root are high-level summaries, while the reports near the end of the branches (the "leaves") are very detailed, usually showing detailed claims. Users view a specific suspect list by selecting the name of the model 815 or rule 830 from the WebStation "home" page 800.
  • Fig. 9 illustrates a sample suspect list 900 which would be the root of report tree.
  • the suspect list 900 shown in Fig. 9 includes:
  • the Context Menu frame 508 on the far left, and the Report Tree Navigation Frame 510 at the bottom of the screen.
  • the Context Menu frame 508 enables users to perform a variety of useful functions on the data that appears in the Suspect List. These same functions are available any time the WebStation displays data in tabular form. A closer look at these functions is made later; this section describes how a user can select a suspect to look at, and then drill-down from high-level summary to claims detail for that suspect.
  • the Report Tree Navigator frame 510 at the bottom of the screen displays small icons 512 that represent the report pages that the user has visited. Notice that only one small icon appears in the sample above. This icon represents the suspect-list 900. As the user drills down into additional reports (following a branch of the report tree), additional icons will appear in this frame. If the user wants to "back up" and revisit a previous report, they can do so by clicking on the icon representing that report.
  • a specific Suspect-ID 902 (which is a Provider-ID in this example)
  • the WebStation 150 takes the user to a standard summary for that provider. Notice that the data fields that serve as hyperlinks follow the Internet convention and are shown in color-coded, underlined text.
  • the Provider-ID appears on many different pages within the WebStation, but selecting the Provider-ID always takes the user to the standard summary for that Provider.
  • Fig. 10 illustrates the format of one version of a Provider Summary page 1000.
  • the Provider Summary 1000 includes separate blocks of information about:
  • Identifying information 1002 (provider numbers, license number, name, address etc.)
  • the WebStation 150 takes the user to the high-level summary report that captures the "essence" of that reason.
  • Reasons serve as explanations for model fraud-risk scores. Each suspect has several reasons, which are listed in order of importance. Reasons are different for each model. The example used here is a model that detects fraud and abuse for Dental Providers.
  • a typical detection model will have 10-20 reason categories. Each category has links to a high-level summary report from the Suspect List 900 for that model.
  • Fig. 11 is an example of the type of high-level summary that the WebStation displays when the user selects a reason from the Suspect List.
  • This report is called an "Abnormal Clinical Procedure Mix” report.
  • the WebStation displays a summary (upper charts) of the provider's activity in each of 1 1 different clinical procedure groups. The mix across groups is shown both in terms of dollars paid and number of services.
  • the individual provider is shown as a dot 1110 (here a half-circle because of its placement on the X-axis and on the 100% line), while the provider's peers are shown as 3 diamonds 1125 (connected with a thick line).
  • These three diamonds (which sometimes are so close together that they appear as a single diamond) represent the median (middle diamond), 25th percentile (lower diamond) and 75th percentile (upper diamond)
  • the provider dot 1110 appears with respect to the 3 peer-group diamonds 1125 tells the user where the individual falls with respect to their peer group Thus, in a glance, the user can tell if the provider is doing more or less of a particular type of service than his peers, and can immediately see if the difference is large or small, relates to a single category of services or to several catego ⁇ es, etc
  • the two bar charts at the bottom of the figure show the individual provider's top five CPT codes both in terms of dollars paid and number of services
  • this report 1200 there is one line 1202 per patient (it lists the patients for which the suspect provider has delivered at least one service) Each line indicates the patient's ID 1204, Age 1206 and Gender 1208, as well as specific aggregate measures of the services received by this patient (average dollars per service 1212 and total dollars 1214, and number of services 1216) both from the suspect provider and all other providers (for which there is claims data available) From this report, if the user selects (e g clicks on) the number of services 1210 for a patient or the patient ID, the WebStation takes the user to a list of that patient's claim details Fig 13 illustrates this report 1300
  • the main menu tabs 870-888 as shown in Fig 8 are preferably always shown on-screen, and the navigation icons 740 are always shown in the Report Tree Navigation frame 510 along the bottom of the screen
  • the list of functions are shown in the Context Menu frame 508 at the far left any time data is displayed in tabular form
  • the claim detail page is a good place to show how some of these functions work
  • the user clicks on the desired function (e g Filter 1401) in the Context Menu frame 508 at the far left of the screen Filtering allows users to execute queries that qualify which rows of the current data g ⁇ d should be shown on-screen
  • the desired function e g Filter 1401
  • the user clicks on the desired function (e g Filter 1401) in the Context Menu frame 508 at the far left of the screen Filtering allows users to execute queries that qualify which rows of the current data g ⁇ d should be shown on-screen
  • the user clicks on the desired function (e g Filter 1401) in the Context Menu frame 508 at the far left of the screen Filtering allows users to execute queries that qualify which rows of the current data g ⁇ d should be shown on-screen
  • the user clicks on the desired function (e g Filter 1401) in the Context Menu frame 508 at the far left of the screen Filtering allows users to execute queries that qualify which rows of the
  • the Graph function 1607 allows users to pick which columns of data they would like to use for a plot, and the type of plot they want to view (scatter, pie, line, bar, etc.).
  • the WebStation computes and graphs the selected plot using the data from the selected columns. Sample plots are shown in various ones of Figs. 17-27.
  • This section describes in further detail a sample report tree, as may be generated by the WebStation for analyzing in more detail the relationships of various entities to each other.
  • the illustrated reports are schematic in format and not representative of how they would actually appear on a screen display, though some of portions of the figures illustrate features of such screen displays.
  • the linkages between reports are explicitly illustrated in many cases to show how the user navigates between reports. While this example is specific to a healthcare fraud and abuse implementation of the WebStation and the report tree concept, the report tree may be utilized in many other types of applications, including other types of fraud and abuse systems (e.g., consumer, merchant, Internet, credit card, debit card, etc.), sales and marketing analysis system, or any other application where multiple entities interact with each other in complex data relationships.
  • fraud and abuse systems e.g., consumer, merchant, Internet, credit card, debit card, etc.
  • Procedure and/or Diagnosis Groups (TOS and/or POS) (Fig. 17): This figure shows a group of reports for a reason category that pertains to a break-down of the provider's activity in a particular grouping scheme.
  • the four grouping schemes for the MD/Physician model are - Procedure Code Groups, Diagnosis Code groups, Type of Service (TOS) codes and Place of Service (POS) codes. For a reason corresponding to any of these grouping schemes, the reports in Fig. 17 will show up, with the corresponding groups.
  • the report header 1702 shows the grouping scheme, the provider number 1704 being reviewed and the peer group 1706 that is being used for the provider.
  • the peer group can be changed using a drop-down box 1708 - this will change the set of providers against which this particular provider's statistics are being compared.
  • the percent of the provider's activity (by dollars paid and by number of services) in each group is shown. (These are the top two images titled "DOLLARS PAID" 1710 and "NUMBER OF SERVICES” 1712).
  • For each group in addition to showing the level of the provider's activity in that group (depicted by the dot, e.g.
  • dot 1714 the 25th, 50th and 75th percentile values for percent activity in that group across all providers in the selected peer group is also shown. This is depicted by the 3 horizontal lines across the vertical bar for each group (e.g. bars 1716).
  • the user clicks on the dot showing the provider's level in a particular group this takes the user to a distribution report that is illustrated in the Provider (Yellow Dot) Chart in Fig. 19.
  • the two bottom charts (1718, and 1720) of the Procedure and/or Diagnosis Group report show the top 5 codes in which the provider's activity is concentrated, one by dollars paid and the other by number of services.
  • the bottom of this report contains 3 buttons.
  • the "View Client Summary” button 1722 takes the user to a report showing a summary of the providers' activity (relevant to that grouping scheme) with each of his/her clients (one line per client). For example, for procedure code groups, the number of details in each procedure code group for each client will be shown. Clicking on any one line, will takes the user to the claims corresponding to that client.
  • the "Flip Client Summaries” button 1724 takes the user to the report shown in Fig. 18.
  • the "View Procedures” button takes the user to the Provider (Yellow Dot) Chart report, shown in Fig. 19.
  • the "Pick Flip Set” drop-down 1806 allows the user to select the grouping scheme (e g Procedure, Diagnosis, TOS, or POS) and number ot services or dollars paid for which the user is interested in seeing the activity break-down
  • the bar graph 1808 shows, the level of the provider's activity by the different groups compared to all other providers' activity, for the given client
  • the "Basics” box 1810 shows the basic client summary report (one line per client), off of which a particular client of interest may be selected
  • the box 1812 next to that shows the statistics for the selected client's activity, across the various groups, for selected providers vs other providers
  • Fig 20 This figure shows reports for the reasons corresponding to breakdown of a provider's clients by age groups
  • the top three reports 2004, 2006, 2010 respectively show the breakdown of numbers of clients, number of services and the dollars paid for the selected provider by the different client age groups
  • These charts are similar to the ones described for the Procedure and/or Diagnosis report, where the yellow dot represents level of selected provider's activity and the horizontal lines show the 25th, 50th, 75th percentiles of that activity for the peer group
  • clicking on a yellow dot m a particular age group takes the user to a distribution chart 2016 similar to the one described for Fig 19, the Provider (Yellow Dot) Chart report, except that the chart 2016 will show the dist ⁇ bution of services only for the selected age group
  • the View Client Summary button 2012 once again takes the user to a one-line-per-client report, showing the basic statistics for that client for the selected provider. Clicking on any line, will take the user to the corresponding claims.
  • the View Client Summary 2012 button will take the user to the same report as the corresponding button 2012 on the top chart, except now in a specific age group.
  • the View Breakdown button 2020 will take the user to a Procedure and/or Diagnosis report like Fig. 17, except that the activity shown will correspond to the particular age group that was selected (through the yellow dot).
  • the third box 2022 enables selection of breakdown by different codes/groups.
  • Fig. 21 This report is for reasons corresponding to monthly activity of provider. The breakdown of activity across months is shown for number of clients (2106), number of services (2108) and dollars paid (2110). Again, each yellow dot (e.g., dot 2112) represents level of selected provider's activity and the horizontal lines (e.g. 2113) show the 25th, 50th, 75th percentiles of that activity for the peer group. Like before, clicking on a yellow dot will take the user to a distribution Provider (Yellow Dot) chart as in Fig. 19. The Select Month button 2114 at the bottom of each chart enables selection of a particular month for which the provider's claims, sorted by client are shown. The Show Breakdown button 2116 enables viewing breakdown by different codes/groups, showing Procedure and/or Diagnosis reports similar to ones illustrated in Fig. 17, but for a particular month of activity.
  • Client Consecutive Visits (Fig. 22): This report is for reasons corresponding to the periodic nature of clients' visits for the selected provider.
  • Top left chart 2206 shows the percent of clients who have consecutive monthly visits for 1,2, . . . 12 months, while the bottom left chart 2210 shows the percent of clients who have more than two visits per month consecutively for 1,2, . . . 12 months.
  • each yellow dot (e.g. dot 2213) represents level of selected provider's activity and the horizontal lines show the 25th, 50th, 75th percentiles of that activity for the peer group.
  • clicking on a yellow dot will take the user to a distribution chart 2208 similar to the one described for the Provider Chart in Fig. 19.
  • the user can go down to the corresponding Client Summary report 2214 from these charts and then to the corresponding claims.
  • the buttons 2212 at the bottom of the charts also allow the user to select clients for a particular number of months and then look at their summary and claims reports.
  • Group Participation (Fig. 23): This report is for a reason corresponding to the participation of the provider in a group.
  • the provider's group 2302 is identified and likelihood of peers being in a group 2304 is shown. This report can link to clients' statistics and claims for that particular group 2306.
  • the top chart 2402 is a distribution chart like Provider Chart on in Fig. 19, showing the distribution of average dollars per claim 2406 within the peer group and where the value for the selected provider lies in this distribution (vertical line 2404).
  • the Select Recip Subset 2408 allows selection of a subset of clients by age/gender etc., by which the distribution (chart 2416) may be viewed and the Breakdown button 2410 allows breakdown by different codes/groups (similar reports to the Procedure and/or Diagnosis report, but limited to the selected subset).
  • the distribution chart 2412 shows the distribution of the dollars/claim for this particular provider.
  • the Show Client Summary button 2414 takes the user to a one- line-per-client report sorted (by default) by S/claim. This then leads to the claims corresponding to any selected client.
  • Fig. 25 This report shows distributions of the per-day activity of a provider.
  • the charts 2502 show the different distributions as labeled.
  • the "View Day Summary” 2504 enables viewing the clients/claims 2514 on a particular day.
  • the View Client Summary button 2506 causes the display of a table 2512 with a line per client sorted by average dollars per client-day.
  • the GAB 2508 and "Breakdown" drop-down 2510 enables viewing of the distribution charts by different codes/groups.
  • the client summary leads to the corresponding claim details 2516.
  • Per Client Volume This report shows per-client statistics for a provider. Distributions 2602 of the different quantities for the selected provider are shown (e.g. dollars/client 2602a, number of clients 2602b, number of services per client 2602c, provider's dollars paid per client 2602d, and provider's number of services per client 2602e).
  • the View Client Summary button 2602 takes the user to a report 2606 with a line per client sorted by dollar such that clients with largest dollar volumes are at the top. Clicking on a client in that report 2606 then leads to a report 2608 of the claims for that client.
  • Fig. 27 This report shows the activity of a provider's clients seeing multiple physicians in the same day. Average 2702 and max number of providers 2704 seen by a provider's clients on the same day that they see this particular provider are shown. Again, the "View Client Summary" 2706 takes the user to a report 2710 with a line per client with a column 2714 showing the total number of providers seen by selected client. Clicking on that number takes the user to the claims 2712 for that client for all providers.
  • the report tree has a general structure along the following lines: (1) Suspect List (2) Breakdown of Provider's activity by procedure code groups (3) Distribution chart showing peer activity vs provider (3) Subsetting activity breakdown by age/gender (4) Subsetting distribution by age/gender
  • Suspect list Report This is the root of each hierarchy. It contains a list of all the providers scored by the model, rank-ordered by the model score, and showing the top reasons for each provider. Clicking on any of the reasons takes the user down the branch of reports corresponding to that reason.
  • Provider-Based Report(s) This is the first level in any of the reason branches.
  • a provider-based report uses only the selected provider as the key. This report will show the statistics relevant to the particular reason for the selected provider. Usually the distribution of those statistics for the peer group will also be shown in some form for context. Note that there could be multiple provider-based reports on a given reason branch. For example, the first report may show a coarser level of statistics and the ones leading from it will show finer levels of statistics.
  • Provider/Subset Based Report(s) From a provider-based report, one can drill down to a report that breaks down that provider's activity by a particular subset of clients/claims. Examples of subsets include age/gender, particular codes/groups such as procedure codes, diagnosis groups, etc.
  • a provider/client based report breaks down a provider's activity across all of the clients that the provider has seen.
  • the coarsest level of a provider/client report is one where there is one line for each client and basic activity statistics between the selected provider and that client, pertaining to the reason of interest, are shown. This report can then lead to reports showing more data on the particular provider- client pair's activity.
  • the WebStation 150 provides a robust set of functions for viewing results of the Detection System 120 as report trees and the underlying data in the Database 140.
  • FIG. 8 is illustrative.
  • This summary page 806 preferably includes: a) The date when the model or rule was most recently executed. b) For rules: the target (provider, licensee, recipient, etc.), number of claims, providers, groups, license numbers, recipients and dollars billed. (Note that for some rules, certain summary data may not be applicable). c) For models: the target, score range, number of providers, groups, license numbers or recipients in the top percentile of scores, top decile of scores(to give an idea of the scope of the model).
  • each Predictive Model 121 and Rule 122 From the primary detection screen 800 the user should be able to view a detailed text description of each detection model and rule.
  • This text preferably indicates: a) What the model or rule does (on-line description) b) The target (providers, licensee or recipients) c) The detailed scope (provider sub-specialty, specific fraud scams etc.) d) The data that is required in order to run the model or rule e) When it was first developed f) The history of modifications made.
  • Fig. 15 is illustrative.
  • Report Trees help users navigate through the multitude of possible reports so they can quickly accomplish their objectives. User is able to start with a suspect list and drill-down to view predefined summary and detailed reports that relate to top reasons (Reason-Driven Analysis) or rules (Rule-Driven Analysis). Figs. 17-27 describe examples of each of the reports and identify fields within each (non-leaf) report that link to additional reports. The user is able to initiate this drill-down through the Report Tree 400 either from a suspect list 700, or from the target summary report in the following manner. a) Select from entire list of predefined summary and detailed reports
  • the user is able to select from a list of available reports. This list is presented on-screen in a hierarchical (tree) structure. b) Search for all relevant detection results for a given provider, group, license number or recipient
  • the user can view all suspect list entries for any valid provider, group, license or recipient by specifying the appropriate Target Id.
  • the results identify which model or rule identified the search target as a suspect and includes all of the suspect list fields (score, score date, reasons etc.) c) Search for cases by case-id, provider, group, license number or recipient
  • the Management user can search, by case, provider, group, license number or recipient ID, for all cases that exist for that entity.
  • the resulting list includes entity ID (provider, recipient etc.), case ID, case status, case create date, last activity date. d) View Provider Summary information via Provider Id link
  • This summary includes provider master-file information (name, address, stated specialty etc.) as well as derived summary data (claims volume, dollars billed, etc.).
  • provider master-file information name, address, stated specialty etc.
  • derived summary data claims volume, dollars billed, etc.
  • the user can link to the standard summary data for recipients.
  • This summary includes recipient eligibility file information (name, address, eligibility start/end dates etc.) as well as derived summary data (claims volume, dollars billed, etc.). (Similarly, the user should be able to link to the target summary for other targets such as licensee, etc.) f) View Provider Detailed claims data from the Provider Summary screen
  • Fig. 15 is illustrative, i) Specify and apply constrained filter criteria to on-screen data as it appears in a Data Frame
  • the case-list is specific to each user and includes both cases that have been previously worked and cases newly assigned to the user).
  • Each internal or Management user will have a list of cases that they have worked or that have been newly assigned to them (by a Management user). Users should be able to see a list of these cases with summary information relating to each case: a) Case Id b) Target Id c) Case create date d) Case create User Id e) Last action date f) Last action User Id g) Current Case Status
  • each data row contains: a) Target Id, linked to appropriate summary report b) Score Date c) Score d) Top ⁇ n> reasons, each reason linked to the Reason-Based Report Tree e) Link to score history report
  • each data row contains: a) Target Id, linked to appropriate summary report b) Run Date c) Number of claims d) Number of recipients e) Total dollars at risk f) Link to Rule-Based Report Tree (may be a single claim-level report)
  • An authorized user may assign a case to a system user. This procedure locks the case (to ensure that other Management users cannot concurrently assign the case).
  • the WebStation also offers users additional functions to manage users, integrate with a Case Management Module and customize the way the WebStation displays information to meet each user's needs.
  • the following shows the supported functions, which are easily implemented by those of skill in the art:
  • the Web CaseBook As a case is worked users perform different analyses, some using the Spyder Analysis WebStation, others taking advantage of external analysis tools and investigative processes.
  • One mechanism for documenting a case is the Web CaseBook.
  • the Web CaseBook has a hierarchical (outline) structure, but a single-level list of reports, comments and analyses may be provided. Each item in the list is stored as HTML and is linked to a title-entry in the main page of the CaseBook.
  • the Web CaseBook can be viewed using a web browser.
  • a CaseBook editor is used to help users develop cleaner looking Web CaseBooks.
  • the Web Casebook is a web-site for a particular case. Some users create and modify the Web casebook, while others can only view its content (with components of the Web Casebook viewable depending upon the viewing user's authorization level). Additional tools (outside of the WebStation) may also provide the ability edit, update and view Web Casebooks.
  • the Display Types available for showing data on-screen may be enhanced.
  • New Display Types can be provided for more sophisticated graphics to help users interpret the summary and detailed data needed to understand detection results.
  • Specific new Display Types may include: Pie Charts, Temporal Trend Charts and Scatter Plots.
  • an embodiment may include a user-driven capability to select columns from Data Grid displays and generate graphical plots on-the-fly.
  • an embodiment may include a capability to export specified data in an easily transported format(s).
  • the export function supports standard file formats, such as Microsoft Excel, tab-delimited, and so forth.
  • the Case Management Module 180 provides a number of interconnected screens that are used to review and analyze cases. Fig. 28 shows how these screens relate to each other:
  • Each user has a personal Case-List 2802.
  • An example case list is shown in Fig. 29. Management users build and modify this list by assigning cases to users. Users will begin their session by either going directly to their case-list, or by browsing reports and detailed data using the Analysis WebStation.
  • Case-List 2900 When users elect to view their Case-List 2900, they will see all of their cases, including newly assigned cases. The number of new messages 2902 related to each of their cases will be displayed on their main case-list page. By following the Messages link, the users can read all new messages for the case. A sample of the new messages screen is shown in Fig. 30 The user can also send messages to other users who have authority to access the case. All messages are stored and tracked for inclusion in the case message log.
  • Case-List page 2900 users can elect to go to a case by following its Case Id link 2904. This operation takes the user to the Case Summary page (Fig. 31) for that case and locks the case so that no other user can simultaneously modify the case.
  • the Case Summary page shows an overview of all of the critical aspects of the case. The information blocks Identity 3102, Update Information 3104, Detection Sources 3106, Attached Claims 3108, Linked Cases 31 10, and so forth, group case information into higher-level categories for ease of viewing.
  • Internal actions are actions that the system completes when instructed to do so by an autho ⁇ zed user. Sending a message and changing the case status are examples of internal actions.
  • External actions are actions whose completion requires work to be done outside the system. Interviewing recipients, requesting patient records, visiting provider offices and reaching a settlement with a provider are examples of external actions
  • Fig. 33 illustrates the action screen 3300 for a case, for taking a new action. This page allows the user to select an action from the ACTION drop-down 3302 at the top of the page.
  • the actions include:
  • the bottom part of the screen (which changes, depending upon what the user selected for an action) allows the user to enter the required data, including descriptive comments to clarify the action.
  • the system records the date, time, User ID and other data for all internal actions.
  • users in order to track external actions users must enter information into the system. For example, when a case results in savings (or is far enough along to project savings, recoveries etc.) autho ⁇ zed users can enter projected/actual savings data. This is the case with all external actions as well as "final outcome" information such as legal or disciplinary actions taken against providers, recipients, or other entities.
  • the user may also view the Case Log 3400 for a case, as shown in Fig. 34.
  • This page allows users to view (and operate on using the context menu frame 508) the case log This log lists all events related to the case.
  • the '" ⁇ ''-bubble 3402 in the case status column 3404 provides a longer text description of the "O" case-status. This "bubble-help" facility is used throughout the WebStation for providing longer text descriptions for coded fields.
  • Fig. 35 illustrates the Search page. This pages more flexible search c ⁇ te ⁇ a than the Go To Case page.
  • the WebStation executes a database search from the constructed query on the Database 140 and provides the resulting cases in a Case List, as illustrated in Fig. 36.
  • Case List 3600 is a list of cases that met the specified criteria from a search, and, like all data table pages has a Context Menu Frame 508 to allow further manipulation of the results. Clicking on the CaselD takes the user to the corresponding Case Summary page. 2) Assign Cases Management users have the authority to assign cases to system users. They can do this via two different mechanisms. First, the Management user can select a specific Case Id and associate the case with a list of User Ids. Only the specified users can perform case management functions on the case (Management users have review access to all cases).
  • the queue mechanism is another way to perform an assignment, but it enables users to perform case management functions on all of the cases in the queue.
  • all users assigned to the queue have access to all of the cases in the queue.
  • the queue is a more general way to assign cases to users. Instead of dealing with singles cases, Management users can make assignments based upon categories of cases (embodied in the queue definitions).
  • the focus of case assignment is to control who has authorization to work (or view) cases. This control is placed in the hands of Management users (see User-Type).
  • Case Management users have the ability to understand the current state of the fraud and abuse effort, analyze the effectiveness of the many components that make up the overall effort, and recognize opportunities for improvement.
  • the Case Management module provides a suite of flexible reports to support these process tracking and analysis needs.
  • the subset of cases where the target is a provider can be further analyzed by stated type and specialty, by practice size, practice location, provider clusters etc. Recipient cases can be broken out by recipient age/gender, recipient zip code, recipient cluster, etc.
  • the WebStation 150 assumes the user wants to work with the case for that suspect. (If the user selects Go To Case 850 then the Case Summary 3100 for that suspect is shown on-screen; if the user selects Assign Case 872 the software assumes they want to assign a case for that suspect.)
  • WebStation 150 As a case is worked users perform different analyses, some using the WebStation 150, others taking advantage of external analysis tools and investigative processes.
  • One mechanism for documenting a case is the Web CaseBook. As the case evolves, users can add reports generated within the Analysis WebStation to the Web CaseBook. The end result is a record (in the form of a web site) that includes summary reports, reviewer/ investigator nates, case status updates and other information relating to the case.
  • the Web CaseBook would have a hierarchical (outline) structure, but initially a single-level list of reports, comments and analyses will be provided. Each item in the list is stored as HTML and is linked to a title-entry in the main page of the CaseBook. At any point during the life of a case, the Web CaseBook can be viewed using a web browser. In a future version we will provide a CaseBook editor to help users develop cleaner looking Web CaseBooks that include documents from external sources.
  • the WebStation is a general-purpose software application. It can be configured, using a partly automated and partly manual process, to meet the user-interface needs of any of a wide range of predictive solutions.
  • the WebStation' s flexibility is provided in part by the WebStation Configuration File 190.
  • the configuration file provides a way to generate a large portion of the WebStation application software.
  • the configuration file enables the WebStation Builder 195 process to generate code (software) that displays tabular data in reports within the Report Tree.
  • the WebStation Configuration File 190 contains a description of which data in the System Database 140 is to be shown on-screen, in a tabular report, which reports can be linked to, how the reports are linked to (which data fields are links), how the data appears onscreen (color, font, etc.), the table layout (which fields are visible/hidden, order of fields), and a variety of other details.
  • the high degree of configurability makes the WebStation deployment across a variety of predictive applications far more practical and efficient than custom development using a similar software specification (source code re-use).
  • the WebStation configuration file is used to define the default setup for the WebStation.
  • the WebStation user interface comprises a number of WebStation pages, where a page is a formatted view into the WebStation Database.
  • the WebStation configuration file 190 can also define other global preferences, e.g. the default colors and font sizes, but those options are not discussed in this section.
  • a WebStation configuration tool is used to configure pages for a WebStation, and enforces the syntax and configuration requirements of the WebStation pages as described below.
  • pages for the WebStation may be created in any HTML or even text editor, and are not limited to creation in the configuration tool.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un système, un produit de programme informatique et un procédé permettant d'effectuer une analyse de données fondée sur des raisons dans un système Internet pouvant être configuré pour plusieurs types des données et d'environnements. Ce produit de programme informatique permet de naviguer dans un arbre de rapports comprenant des rapports (170) hiérarchiquement organisés par rapport à des raisons issues d'une analyse de données transactionnelles dans une base de données (140). Une interface basée sur des cadres permet une exploration et une configuration faciles et souples de ces rapports et d'autres caractéristiques. Un fichier de configuration (190) est utilisé pour développer et personnaliser rapidement ce système Internet. L'intégration d'une fonctionnalité de gestion de cas (180) permet de gérer des cas révisés au moyen dudit système.
PCT/US2000/026881 1999-09-30 2000-09-29 Station internet: poste de travail internet configurable pour analyse de donnees fondee sur des raisons Ceased WO2001024040A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU78403/00A AU7840300A (en) 1999-09-30 2000-09-29 Webstation: configurable web-based workstation for reason driven data analysis

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US15722699P 1999-09-30 1999-09-30
US60/157,226 1999-09-30
US09/672,142 2000-09-27
US09/672,142 US7418431B1 (en) 1999-09-30 2000-09-27 Webstation: configurable web-based workstation for reason driven data analysis

Publications (1)

Publication Number Publication Date
WO2001024040A1 true WO2001024040A1 (fr) 2001-04-05

Family

ID=26853925

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/026881 Ceased WO2001024040A1 (fr) 1999-09-30 2000-09-29 Station internet: poste de travail internet configurable pour analyse de donnees fondee sur des raisons

Country Status (2)

Country Link
AU (1) AU7840300A (fr)
WO (1) WO2001024040A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7117215B1 (en) 2001-06-07 2006-10-03 Informatica Corporation Method and apparatus for transporting data for data warehousing applications that incorporates analytic data interface
US7162643B1 (en) 2001-06-15 2007-01-09 Informatica Corporation Method and system for providing transfer of analytic application data over a network
US7254590B2 (en) 2003-12-03 2007-08-07 Informatica Corporation Set-oriented real-time data processing based on transaction boundaries
US7421458B1 (en) 2003-10-16 2008-09-02 Informatica Corporation Querying, versioning, and dynamic deployment of database objects
US7720842B2 (en) 2001-07-16 2010-05-18 Informatica Corporation Value-chained queries in analytic applications
US8191053B2 (en) 2007-04-12 2012-05-29 Ingenix, Inc. Computerized data warehousing
USRE44478E1 (en) 2002-02-22 2013-09-03 Informatica Corporation Method and system for navigating a large amount of data

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5577249A (en) * 1992-07-31 1996-11-19 International Business Machines Corporation Method for finding a reference token sequence in an original token string within a database of token strings using appended non-contiguous substrings
US5852819A (en) * 1997-01-30 1998-12-22 Beller; Stephen E. Flexible, modular electronic element patterning method and apparatus for compiling, processing, transmitting, and reporting data and information
US5864846A (en) * 1996-06-28 1999-01-26 Siemens Corporate Research, Inc. Method for facilitating world wide web searches utilizing a document distribution fusion strategy
US5873082A (en) * 1994-09-01 1999-02-16 Fujitsu Limited List process system for managing and processing lists of data
US5895453A (en) * 1996-08-27 1999-04-20 Sts Systems, Ltd. Method and system for the detection, management and prevention of losses in retail and other environments
US5933822A (en) * 1997-07-22 1999-08-03 Microsoft Corporation Apparatus and methods for an information retrieval system that employs natural language processing of search results to improve overall precision

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5577249A (en) * 1992-07-31 1996-11-19 International Business Machines Corporation Method for finding a reference token sequence in an original token string within a database of token strings using appended non-contiguous substrings
US5873082A (en) * 1994-09-01 1999-02-16 Fujitsu Limited List process system for managing and processing lists of data
US5864846A (en) * 1996-06-28 1999-01-26 Siemens Corporate Research, Inc. Method for facilitating world wide web searches utilizing a document distribution fusion strategy
US5895453A (en) * 1996-08-27 1999-04-20 Sts Systems, Ltd. Method and system for the detection, management and prevention of losses in retail and other environments
US5852819A (en) * 1997-01-30 1998-12-22 Beller; Stephen E. Flexible, modular electronic element patterning method and apparatus for compiling, processing, transmitting, and reporting data and information
US5933822A (en) * 1997-07-22 1999-08-03 Microsoft Corporation Apparatus and methods for an information retrieval system that employs natural language processing of search results to improve overall precision

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7117215B1 (en) 2001-06-07 2006-10-03 Informatica Corporation Method and apparatus for transporting data for data warehousing applications that incorporates analytic data interface
US7162643B1 (en) 2001-06-15 2007-01-09 Informatica Corporation Method and system for providing transfer of analytic application data over a network
US7720842B2 (en) 2001-07-16 2010-05-18 Informatica Corporation Value-chained queries in analytic applications
USRE44478E1 (en) 2002-02-22 2013-09-03 Informatica Corporation Method and system for navigating a large amount of data
US7421458B1 (en) 2003-10-16 2008-09-02 Informatica Corporation Querying, versioning, and dynamic deployment of database objects
US7254590B2 (en) 2003-12-03 2007-08-07 Informatica Corporation Set-oriented real-time data processing based on transaction boundaries
US8191053B2 (en) 2007-04-12 2012-05-29 Ingenix, Inc. Computerized data warehousing

Also Published As

Publication number Publication date
AU7840300A (en) 2001-04-30

Similar Documents

Publication Publication Date Title
US7418431B1 (en) Webstation: configurable web-based workstation for reason driven data analysis
Matignon Data mining using SAS enterprise miner
US8190410B2 (en) System and method for evaluation decision sciences of simulation models
US7778846B2 (en) Sequencing models of healthcare related states
US20040122936A1 (en) Methods and apparatus for collecting, managing and presenting enterprise performance information
US20070083417A1 (en) Real-time collaboration and workflow management for a marketing campaign
US20040177053A1 (en) Method and system for advanced scenario based alert generation and processing
US20030158751A1 (en) Fraud and abuse detection and entity profiling in hierarchical coded payment systems
US20060004612A1 (en) Systems and methods for configuring and processing insurance information
CN101421734A (zh) 用于识别和分析医疗赔付中的模式或者异常的系统和方法
WO2001024040A1 (fr) Station internet: poste de travail internet configurable pour analyse de donnees fondee sur des raisons
US20160239910A1 (en) System and method for preparation of clinical trial budgets
Kongstvedt et al. Using data and provider profiling in medical management
Kongstvedt et al. Using Data and Provider Profiling
KOSE et al. Faculty of Engineering and Natural Sciences, Sabanci University, 34956, Istanbul, Turkey

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP