METHOD OF PERSONALIZING, INDIVIDUALIZING, AND AUTOMATING THE MANAGEMENT OF HEALTHCARE FRAUD-WASTE-ABUSE TO UNIQUE INDIVIDUAL HEALTHCARE PROVIDERS
A method of preventing healthcare fraud-waste-abuse uses artificial intelligence machines to limit financial losses. Healthcare payment request claims are analyzed by predictive models and their behavioral details are compared to running profiles unique to each healthcare provider submitting the claims. A decision results that the instant healthcare payment request claim is or is not fraudulent-wasteful-abusive. If it is, a second analysis of a group behavioral in which the healthcare provider is clustered using unsupervised learning algorithms and compared to a running profile unique to each group of healthcare providers submitting the claims. An overriding decision results if the instant healthcare payment request claim is or is not fraudulent-wasteful-abusive according to group behavior.
Latest Brighterion, Inc. Patents:
- METHOD OF PERSONALIZING, INDIVIDUALIZING, AND AUTOMATING THE MANAGEMENT OF HEALTHCARE FRAUD-WASTE-ABUSE TO UNIQUE INDIVIDUAL HEALTHCARE PROVIDERS
- ADDRESSABLE SMART AGENT DATA TECHNOLOGY TO DETECT UNAUTHORIZED TRANSACTION ACTIVITY
- METHOD OF AUTOMATING DATA SCIENCE SERVICES
- Artificial intelligence fraud management solution
- Artificial intelligence for context classifier
The present invention relates to methods of preventing healthcare fraud-waste-abuse and more specifically to employing artificial intelligence machines to limit financial losses and detecting unwarranted reimbursements.
BackgroundHealthcare fraud, waste, and abuse have blossomed in recent years because deep pockets like the Government and large insurance companies are now more than ever paying all the bills.
Insurance Companies and Government quite obviously try to control fraud, waste, and abuse, but their third party, after-the-fact status to medical treatments makes them less able and less effective in controlling this kind of fraud. Hospitals, clinics, pharmaceutical companies, and other healthcare providers in general have stepped in to exploit these inadequacies. Costs, as a direct result have spiraled beyond all reason.
Medicare fraud is legally defined to include knowingly and willfully executing, or attempting to execute, a scheme or ploy to defraud the Medicare program, or obtaining information by means of false pretenses, deception, or misrepresentation in order to receive inappropriate payment from the Medicare program. The most frequent kinds of fraud are false statements and misrepresentations of entitlement or payment under the Medicare program.
The Centers for Medicare & Medicaid Services (CMMS) defines the kind of fraud they fight as “the intentional deception or misrepresentation that the individual knows to be false or does not believe to be true, and the individual makes knowing that the deception could result in some unauthorized benefit to himself or herself or some other person.”
Presumably, the vast majority of government contractors who provide goods and services to the government are honest, as are most vendors serving private purchasers. Nevertheless, even a small fraction amounts to a substantial level fraud is directed at the Government, and thereby all of us.
The particular kinds of healthcare fraud we all suffer from includes:
-
- Upcoding, which is the reporting of inappropriate diagnoses or procedures to increase profits;
- Billing for services not actually furnished;
- Duplicate billings for the same services or supplies;
- Misrepresenting dates and misdescribing services furnished or misidentifying the beneficiaries;
- Billing for non-covered or non-chargeable services as if they were covered and chargeable items;
- Misallocating costs on reports, such as including costs of non-covered services, supplies, or equipment in allowable costs;
- Providers colluding with employees, independent contractors, suppliers, and others to overcharge the program through various devices (commissions, fee splitting) to siphon-off or conceal illegal profits;
- Billing Medicare for costs not actually sustained or which arose from non-program activities, other enterprises, or personal expenses;
- Repeatedly including unallowable cost items on a provider's cost report (except for purposes of establishing a basis for appeal);
- Manipulating measurements to obtain bonus payments, such as increasing the square footage of their outpatient areas on paper;
- Amounts paid to owners or administrators that have been determined to be excessive in prior cost report settlements;
- Days that have been improperly reported and would result in an overpayment if not adjusted;
- Depreciation methods not approved by Medicare;
- Altering claim forms to obtain a higher payment amount;
- Billing twice for the same service or item;
- Billing separately for services that should be included in a single service fee;
- Misrepresenting the diagnosis to justify payment;
- Continuing to bill for services or items no longer medically necessary;
- Billing for rental equipment after date of return
- Billing “non-covered” services or items as “covered” services;
- Ordering unnecessary lab tests;
- Using another person's Medicare card to obtain;
- Waiving co-insurance or deductible;
- Billing for home health care services for patients who do not meet the requirement of “homebound” status;
- Billing social activities as psychotherapy;
- Billing group services as individual services for each patient in the group;
- Number of day stays in hospital and Discharge and readmission to same hospital;
- Diagnosis-related group analysis and payment window.
Physicians or other healthcare practitioners are obvious cradles of healthcare fraud, but healthcare fraud wrongdoers also include:
-
- Suppliers of durable medical equipment;
- An employee of a physician or supplier;
- An employee of the companies that manage Medicare billing;
- A billing service;
- A beneficiary; and
- Other people and businesses in a position to bill a Medicare program or to benefit from the Medicare billing.
Better methods to combat fraud, waste and abuse, information are not limited to that included in the claims. The most useful kinds of supplemental information include non-claims based utilization data or actual clinical data from an EMR, and Pharmacy claims or transactions.
Improvements in detecting waste and abuse in healthcare will require a different approach, a comprehensive rethinking of the waste and abuse crisis. Waste, fraud, and leakage in the industry is the major problem. Illegal activity, while significant in absolute numbers, is trivial when compared to $2.8T in annual healthcare spending. Solutions must focus on the breadth of leakage. For example, a simple excessive billing of preventive visits (Evaluation and Management claims) results in $20-$30 additional billed per visit. With one billion primary care physician visits each year, that kind of leakage is larger than the entire fraud recoveries for the market in a single year.
Almost all conventional analytic solutions, operate within extremely rigid boundaries, even those that propose to be non-hypothesis based. They are either designed or tuned to look at various scenarios in such a way that they will only catch a limited range of leakage problems. When something truly surprising happens, or variation occurs that is not anticipated, these models prove to be worthless.
Working solutions require a new approach, new algorithms and models that are not already trained or constrained within the boundaries of known scenarios. Technology that is designed to aggregate scenarios to get at large leakage issues easily and identify systemic issues that plague the system. Highly trained “eyes” are needed on the data output that can process raw data rapidly and efficiently.
SUMMARY OF THE INVENTIONBriefly, a method embodiment of the present invention of preventing healthcare fraud-waste-abuse uses artificial intelligence machines to limit financial losses. Healthcare payment request claims are analyzed by predictive models and their behavioral details are compared to running profiles unique to each healthcare provider submitting the claims. A decision results that the healthcare payment request claim is or is not fraudulent-wasteful-abusive. If it is, a second analysis of a group behavioral in which the healthcare provider is clustered is compared to a running profile unique to each group of healthcare providers submitting the claims. An overriding decision results if the instant healthcare payment request claim is not fraudulent-wasteful-abusive according to group behavior.
The above and still further objects, features, and advantages of the present invention will become apparent upon consideration of the following detailed description of specific embodiments thereof, especially when taken in conjunction with the accompanying drawings.
Method embodiments of the present invention leverage artificial intelligence machines in the prevention of healthcare fraud-waste-abuse by individual and groups of providers submitting payment claims. My earlier U.S. patent application Ser. No. 14/517,872, filed Oct. 19, 2014, titled, HEALTHCARE FRAUD PROTECTION AND MANAGEMENT, is incorporated in full herein by reference.
I describe a data cleanup method in my U.S. patent application Ser. No. 14/935,742, DATA CLEAN-UP METHOD FOR IMPROVING PREDICTIVE MODEL TRAINING, filed Nov. 9, 2015, that would be useful in harmonizing and trimming away irrelevant, excess, and useless information received in these data records. I also describe a data enrichment method in my U.S. patent application Ser. No. 14/941,586, METHOD OF OPERATING ARTIFICIAL INTELLIGENCE MACHINES TO IMPROVE PREDICTIVE MODEL TRAINING AND PERFORMANCE, filed Nov. 14, 2015, that describes how the healthcare payment request claim data, non-claim based utilization data, actual clinical data, and pharmacy claim or transaction data records can be usefully combined to improve the performance of predictive models and smart agent profiling. Both such United States patent applications are parents to this continuation-in-part application that also continues-in-part from the HEALTHCARE FRAUD PROTECTION AND MANAGEMENT patent application.
A key descriptive attribute in widespread use in the healthcare field is the Diagnosis Related Group (DRG) code. This 3-digit code helps to organize diagnoses and procedures into clinically cohesive groups that demonstrate similar consumption of hospital resources. It is a rough form of fuzzification that can help artificial intelligence machines deal with unimportant nuances in data through a sort of clustering of statistical information. In general, fuzzification is a process of transforming crisp values into grades of membership, e.g., infants 0-1, toddlers 2-5, children 6-12, teenagers 13-19, and adults 20+. The healthcare attributes that properly contribute to a particular DRG classification are well understood. Odd value or simply odd, abnormal attributes that coexist in a healthcare payment claim with a proffered DRG are symptomatic of fraud. So when a predictive model like a decision tree or a case-based reasoning classifies a different DRG that the proffered one, then fraud is a likely culprit.
The healthcare providers are correlated in a step 104 to particular ones of the incoming healthcare payment request claims with the processor and an algorithm that generates and maintains a unique smart agent profile in the computer memory storage device for each healthcare provider. An example of this correlation is represented in
A healthcare provider profile uniquely associated with an healthcare provider is accessed in a step 106 with the processor and an algorithm that compares the unique smart agent profile to an instant incoming healthcare payment request claim.
Particular ones of the incoming healthcare payment request claims are classified in a step 108 according to a fraud-waste-abuse criteria with the processor and an algorithm that includes a predictive model trained on an accumulation of supervised and unsupervised healthcare payment request claims previously submitted by essentially the same healthcare providers. And particular ones of the incoming healthcare payment request claims are classified in a step 110 with the processor and an algorithm that applies a unique individual behavior criteria based on a comparison of an individual's past behaviors extracted and recorded in their unique healthcare provider profile and an instant behavior evident in the instant incoming healthcare payment request claim stored in the computer memory storage device.
A decision is issued in a step 112 with the processor and an algorithm that decides an instant healthcare payment request claim is fraudulent-wasteful-abusive or not-fraudulent-wasteful-abusive based on a combination of a fraud-waste-abuse criteria classification and a unique individual behavior criteria classification stored in the computer memory storage device.
A unique healthcare provider profile of each healthcare provider stored in the computer memory storage device is updated with the decision in a step 114.
Steps 102-114 are then repeated as more incoming healthcare payment request claim records are received. If a step 116 decides the process is done, e.g., the instant payment request claim was judged non-fraudulent.
Deviant individual behaviors judged as fraudulent-wasteful-abusive may nevertheless be non-fraudulent-wasteful-abusive even though an individual behavioral analysis classifies an instant incoming healthcare payment request claim that way. If clustering identifies the individual as belonging to a group, and the instant behavior is consistent with behavior profiles maintained for that group, then the instant incoming healthcare payment request claim may be more properly classified with a decision that it is non-fraudulent. In order to implement this, the method continues with more steps.
Clusters of healthcare providers that share a group behavior are identified in a step 118.
Groups of healthcare providers are associated to particular ones of the incoming healthcare payment request claims in a step 120.
A healthcare provider profile uniquely associated with a group of healthcare providers is accessed in a step 122 and compared to an instant incoming healthcare payment request claim.
Particular ones of the incoming healthcare payment request claims are classified in a step 124 according to a group-behavior criteria and based on a comparison of past behaviors extracted and recorded in their unique healthcare provider profile and an instant behavior evident in the instant incoming healthcare payment request claim.
An overriding decision is issued in a step 126 with the processor and an algorithm that decides an instant healthcare payment request claim is fraudulent-wasteful-abusive or not-fraudulent-wasteful-abusive based on a combination of a fraud-waste-abuse criteria classification and a group behavior criteria classification stored in the computer memory storage device.
A unique healthcare provider profile of each group of healthcare providers stored in the computer memory storage device is updated with the overriding decision in a step 128.
Step 210 represents an opportunity for a fraudulent coding, e.g., one that does not comport with the symptoms recorded in step 202 and the diagnostic test results in step 208. Any prescriptions needed are written in a step 212. A procedure code is entered in a step 214. Step 214 represents another opportunity for fraudulent coding, e.g., a procedure that does not comport with the diagnostic code recorded in step 210. A step 216 represents an encoding by the healthcare provider of the payment claim. These represent the many payment claims received by step 102 in
The data enrichment algorithm 408 is more fully described in my recent U.S. patent application Ser. No. 14/941,586, filed Nov. 9, 2015, and titled, METHOD OF OPERATING ARTIFICIAL INTELLIGENCE MACHINES TO IMPROVE PREDICTIVE MODEL TRAINING AND PERFORMANCE. Such application is incorporated herein, in full, by reference. The non-claim data 410 represents facts already known about the healthcare provider submitting the payment claim record and/or details related to other claim attributes.
An enriched data 412 results that is used by a processor with an algorithm 414 that builds decision trees, case-based reasoning logic, smart agent profiles (for every healthcare provider and payment claim attribute), and other predictive models as detailed in the two patent applications just mentioned.
Instructions 416, 418, and 420, respectively describe how to structure run-phase data cleaning, data enrichment, and predictive models.
In a run-phase, as represented more fully in
Step 102 in
Each Claim includes data fields for five-digit diagnosis codes and four-digit procedure codes.
Detection of up-coding fraud includes analyzing symptoms and test results. Detecting upcoding fraud is done with a processor and an algorithm that tests each primary diagnosis for cause-and-effect.
Below are some examples of DRGs upcoding:
DRG 475 (respiratory system diagnosis with ventilator support) vs. DRG 127 (heart failure and shock)
Principle diagnosis of respiratory failure (518.81) with a secondary diagnosis of congestive heart failure (428.0) and a procedure code of 96.70, 96.71 or 96.72 (continuous mechanical ventilation).
The hospital bills the respiratory failure as the principal diagnosis but the respiratory failure was due to the patient's congestive heart failure, which by coding guidelines should have been the principal diagnosis
DRG 287 (skin grafts and wound debridement for endocrine, nutritional and metabolic disorders) vs. DRG 294 (diabetes, age greater than 35) or DRG 295 (diabetes, age 0-35)
Principal diagnosis of diabetes mellitus (250.xx) with a principal procedure of excisional debridement of wound, infection or burn (86.22).
The hospital bills for the excisional debridement of a wound (86.22) when, in fact, a non-excisional debridement (86.28) was performed on the patient. This changes the DRG to 294 or 295 (depending on the age of the patient).
DRG 297 (nutritional and miscellaneous metabolic disorders, age greater than 17) and 320 (kidney and urinary tract infections, age greater than 17) vs. DRG 383 (other antepartum diagnoses with medical complications)
-
- Non-primary diagnosis of pregnancy (V222).
- The hospital bills for dehydration, urinary tract infection or other disorder when, in fact, the primary diagnosis is complications of pregnancy.
DRG 182 (esophagitis, gastroenteritis and miscellaneous digestive disorders, age greater than 17) vs. DRG 383 (other antepartum diagnoses with medical complications)
Non-primary diagnosis of V222 (pregnancy) and a length of stay one day or less. - The hospital bills for gastroenteritis or other disorder when, in fact, the primary diagnosis is complications of pregnancy.
- DRG 416 (septicemia, age greater than 17) and 417 (septicemia, age 0-17) and if:
- The reimbursement amount is between $Amount1 and $Amount2 and is X times the total charge;
For example, a learning database of historical data has 46,933 records and a testing database has 56,976 Records. The first database includes one extra attribute which is used for learning the correct class.
The DRG (Diagnostic Related Group) class attribute is the output that defines what the model will predict. The others attributes are its inputs: they are used to create the model.
Record Example
Each field or attribute in a data record is represented by a corresponding smart-agent. Each smart-agent representing a field will build what-is-normal (normality) and what-is-abnormal (abnormality) metrics regarding other smart-agents.
Apparatus for creating smart-agents is supervised or unsupervised. When supervised, an expert provides information about each domain. Each numeric field is characterized by a list of intervals of normal values, and each symbolic field is characterized by a list of normal values. It is possible for a field to have only one interval. If there are no intervals for an attribute, the system apparatus can skip testing the validity of its values, e.g., when an event occurs.
As an example, a doctor (expert) can give the temperature of the human body as within an interval [35° C.: 41° C.], and the hair colors can be {black, blond, red}.
1) For each field “a” of a Table:
-
- i) Retrieve all the distinct values and their cardinalities and create a list “La” of couples (vai, nai);
- ii) Analyze the intermediate list “La” to create the list of intervals of normal values Ia with this method:
- (a) If “a” is a symbolic attribute, copy each member of “La” into Ia when nai is superior to a threshold Θmin;
- (b) If “a” is a numeric attribute:
- 1. Order the list “La” starting with the smallest values “va”;
- 2. While La is not empty;
- i. Remove the first element ea=(va1, na1) of “La”
- ii. Create an interval with this element: I′=[va1, va1]
- iii. While it is possible, enlarge this interval with the first elements of “La” and remove them from “La”: I′=[va1, vak]. The loop stops before the size of the interval vak-va1 becomes greater than a threshold Θdist.
- (c) given: na′=na1+ . . . +nak
- (d) If na′ is superior to a threshold Θmin, Ia=I′ otherwise, Ia=Ø;
- iii) If Ia is not empty, save the relation (a, Ia).
An unsupervised learning process uses the following algorithm:
Θmin represents the minimum number of elements an interval must include. This means that an interval will only be take into account if it encapsulates enough values, so its values will be considered normal because frequent;
the system apparatus defines two parameters that is modified:
the maximum number of intervals for each attribute nmax; the minimum frequency of values in each interval fImin; Θmin is computed with the following method:
Θmin=fImin*number of records in the table.
Θdist represents the maximum width of an interval. This prevents the system apparatus from regrouping some numeric values that are too disparate. For an attribute a, let's call mina the smallest value of a on the whole table and maxa the biggest one. Then:
Θdist=(maxa−mina)/nmax
For example, consider a numeric attribute of temperature with the following values:
The first step is to sort and group the values into “La”:
Then the system apparatus creates the intervals of normal values:
Consider fImin=10% and nmax=5 then Θmin=1.4 and Θdist=(85−64)/5=4.2
-
- Ia={[64, 68] [69, 72] [75] [80, 83]}
The interval [85, 85] was removed because its cardinality (1) is smaller than Θmin.
- Ia={[64, 68] [69, 72] [75] [80, 83]}
When a new event occurs, the values of each field are verified with the intervals of the normal values it created, or that were fixed by an expert. It checks that at least: one interval exists. If not, the field is not verified. If true, the value inside is tested against the intervals, otherwise a warning is generated for the field.
During creation, dependencies between two fields are expressed as follows:
When the field 1 is equal to the value v1, then the field 2 takes the value v2 in significant frequency p.
Example: when species is human the body temperature is 37.2° C. with a 99.5% accuracy.
Given cT is the number of records in the whole database. For each attribute X in the table:
Retrieve the list of distinct values for X with the cardinality of each value:
-
- Lx={(x1, cx1), . . . (xi, cxi), . . . (xn, cxn)}
For each distinct value xi in the list:
Verify if the value is typical enough: (cxi/cT)>Θx?
- Lx={(x1, cx1), . . . (xi, cxi), . . . (xn, cxn)}
If true, for each attribute Y in the table, Y≠X
Retrieve the list of distinct values for Y with the cardinality of each value:
-
- Ly={(y1, cy1), . . . (yj, cyj), . . . (yn, cyn)}
For each value yj;
- Ly={(y1, cy1), . . . (yj, cyj), . . . (yn, cyn)}
Retrieve the number of records cij where (X=xi) and (Y=yj). If the relation is significant, save it: if (cij/cxi)>Θxy then save the relation [(X=xi)⇒(Y=yj)] with the cardinalities cxi, cyj and cij.
The accuracy of this relation is given by the quotient (cij/cxi)
Verify the coherence of all the relations: for each relation
[(X=xi)⇒(Y=yj)] (1)
Search if there is a relation
[(Y=yj)⇒(X=xk)] (2)
If xi≠xk remove both relations (1) and (2) from the model otherwise it will trigger a warning at each event since (1) and (2) cannot both be true.
To find all the dependencies, the system apparatus analyses a database with the following algorithm:
The default value for Θx is 1%: the system apparatus will only consider the significant value of each attribute.
The default value for Θxy is 85%: the system apparatus will only consider the significant relations found.
A relation is defined by: (Att1=v1)⇒(Att2=v2) (eq).
All the relations are stored in a tree made with four levels of hash tables, e.g., to increase the speed of the system apparatus. A first level is a hash of the attribute's name (Att1 in eq); a second level is a hash for each attribute the values that imply some correlations (v1 in eq); a third level is a hash of the names of the attributes with correlations (Att2 in eq) to the first attribute; a fourth and last level has values of the second attribute that are correlated (v2 in eq).
Each leaf represents a relation. At each leaf, the system apparatus stores the cardinalities cxi, cyj and cij. This will allow the system apparatus to incrementally update the relations during its lifetime. Also it gives:
-
- the accuracy of a relation: cij/cxi;
- the prevalence of a relation: cij/cT;
- the expected predictability of a relation: cyj;/cT
Consider an example with two attributes, A and B:
There are ten records: cT=10.
Consider all the possible relations:
With the defaults values for Θx and Θxy, for each possible relation, the first test (cxi/cT)>Θx is successful (since Θx=1%) but the relations (1) and (7) would be rejected (since Θxy=85%).
Then the system apparatus verifies the coherence of each remaining relation with an algorithm:
(A=2)⇒(B=1) is coherent with (B=1)⇒(A=2);
(A=3)⇒(B=2) is not coherent since there is no more relation (B=2)⇒ . . . ;
(B=4)⇒(A=1) is not coherent since there is no more relation (A=1)⇒ . . . ;
(B=3)⇒(A=1) is not coherent since there is no more relation (A=1)⇒ . . . ;
(B=1)⇒(A=2) is coherent with (A=2)⇒(B=1).
The system apparatus classifies the normality/abnormality of each new event in real-time during live production and detection.
For each event couple attribute/value (X, xi):
Looking in the model for all the relations starting by [(X=xi)⇒ . . . ]
-
- For all the other couple attribute/value (Y, yj), Y≠X, of the event:
- Look in the model for a relation [(X=xi)⇒(Y=v)];
- If yj≠v then trigger a warning “[(X=xi)⇒(Y=yj)] not respected”.
The system apparatus incrementally learns with new events:
Increment cT by the number or records in the new table T.
For each relation [(X=xi)⇒(Y=yj)] previously created:
-
- Retrieve its parameters: cxi, cyj and cij
- Increment cxi by the number of records in T where X=xi;
- Increment cyj by the number of records in T where Y=yj;
- Increment cij by the number of records in T where [(X=xi)⇒(Y=yj)];
- Verify if the relation is still significant:
- If (cxi/cT)<Θx, remove this relation;
If (cij/cxi)<Θxy, remove this relation.
- If (cxi/cT)<Θx, remove this relation;
In general, a process for fraud-waste-abuse protection comprises training a variety of real-time, risk-scoring fraud-waste-abuse models with training data selected for each from a common transaction history that then specialize each member in its overview of a selected vertical claim processing financial transactional channel. The variety of real-time, risk-scoring fraud-waste-abuse models is arranged after the training into a parallel arrangement so that all receive a mixed channel flow of real-time claim data or authorization requests. The parallel arrangement of diversity trained real-time, risk-scoring fraud-waste-abuse models is hosted on a network server platform for real-time risk scoring of the mixed channel flow of real-time claim data or authorization requests. Risk thresholds are updated without delay for particular healthcare providers, and other healthcare providers in every one of the parallel arrangement of diversity trained real-time, risk-scoring fraud-waste-abuse models when any one of them detects a suspicious or outright fraudulent-wasteful-abusive claim data or authorization request for the healthcare provider.
Such process for fraud-waste-abuse protection can further comprise steps for building a population of real-time and a long-term and a recursive profile for each the healthcare provider in each the real-time, risk-scoring fraud-waste-abuse models. Then during real-time use, maintaining and updating the real-time, long-term, and recursive profiles for each healthcare provider in each and all of the real-time, risk-scoring fraud-waste-abuse models with newly arriving data.
Incremental learning technologies are embedded in the machine algorithms and smart-agent technology. These are continually re-trained with at least one processor and an algorithm that machine-learns from any false positives and negatives that occur to avoid repeating classification errors. Any data mining logic incrementally changes its decision trees by creating a new link or updates any existing links and weights, and any neural networks update a weight matrix, and any case-based reasoning logic update a generic case or creates a new one, and any corresponding smart-agents update their profiles by adjusting a normal/abnormal threshold stored in a memory storage device.
Although particular embodiments of the present invention have been described and illustrated, such is not intended to limit the invention. Modifications and changes will no doubt become apparent to those skilled in the art, and it is intended that the invention only be limited by the scope of the appended claims.
Claims
1. A computer-implemented method for healthcare fraud detection, comprising, via one or more processors:
- receiving a plurality of healthcare payment requests corresponding to a plurality of healthcare providers;
- matching the plurality of healthcare payment requests to corresponding ones of a plurality of predictive models, each of the plurality of predictive models including— a classification model configured based on historical payment request data for a group of the plurality of healthcare providers, a smart agent having a profile comprising a representation of historical data of the corresponding healthcare provider, and
- for each of the healthcare payment requests— comparing the contents of at least one data field of the healthcare payment request against the profile of the corresponding smart agent and, based at least in part on the comparison, generating a first output, processing the contents of at least one data field of the healthcare payment request via the corresponding classification model to generate a second output, analyzing the first output and the second output to generate a decision on the healthcare payment request.
2. The computer-implemented method of claim 1, wherein analyzing the first output and the second output and generating the decision for a first of the plurality of healthcare payment requests includes—
- determining that the first output meets a first criteria indicating fraud or abuse,
- determining that the second output meets a second criteria indicating acceptable behavior within the corresponding classification model group,
- issuing an approval decision for the first of the plurality of healthcare payment requests, wherein the determination of the second output overrides the determination of the first output.
3. The computer-implemented method of claim 2, wherein each of the classification models includes a profile configured based on the historical payment request data for the corresponding group of the plurality of healthcare providers.
4. The computer-implemented method of claim 3, further comprising updating, via the one or more processors and for the first of the plurality of healthcare payment requests, the profile of the corresponding classification model to reflect the second output.
5. The computer-implemented method of claim 2, wherein generating the first output for the first healthcare payment request further includes—
- matching the first healthcare payment request to a treatment model,
- determining, using the matched treatment model, whether a diagnostic code matches one or both of an expected prescription and procedure code corresponding to the first healthcare payment request,
- the determination that the first output for the first healthcare payment request meets the first criteria indicating fraud or abuse depending at least in part on determining that the diagnostic code corresponding to the healthcare payment request does not match one or both of the corresponding expected prescription and procedure code.
6. The computer-implemented method of claim 5, wherein generating the first output for the first healthcare payment request further includes—
- matching the first healthcare payment request to a diagnosis model,
- determining, using the matched diagnosis model, that symptoms data and one or both of an expected diagnostic test and diagnostic test results corresponding to the first healthcare payment request are as expected.
7. The computer-implemented method of claim 1, wherein analyzing the first output and the second output and generating the decision for a first of the plurality of healthcare payment requests includes—
- determining that the first output does not meet a first criteria indicating fraud or abuse,
- issuing an approval decision for the first of the plurality of healthcare payment requests.
8. At least one network server for healthcare fraud detection, the at least one network server comprising:
- one or more processors;
- non-transitory computer-readable storage media having computer-executable instructions stored thereon, wherein when executed by the one or more processors the computer-readable instructions cause the one or more processors to— receive a plurality of healthcare payment requests corresponding to a plurality of healthcare providers; match the plurality of healthcare payment requests to corresponding ones of a plurality of predictive models, each of the plurality of predictive models including— a classification model configured based on historical payment request data for a group of the plurality of healthcare providers, a smart agent having a profile comprising a representation of historical data of the corresponding healthcare provider, and for each of the healthcare payment requests— compare the contents of at least one data field of the healthcare payment request against the profile of the corresponding smart agent and, based at least in part on the comparison, generating a first output, process the contents of at least one data field of the healthcare payment request via the corresponding classification model to generate a second output, analyze the first output and the second output to generate a decision on the healthcare payment request.
9. The at least one network server of claim 8, wherein analyzing the first output and the second output and generating the decision for a first of the plurality of healthcare payment requests includes—
- determining that the first output meets a first criteria indicating fraud or abuse,
- determining that the second output meets a second criteria indicating acceptable behavior within the corresponding classification model group,
- issuing an approval decision for the first of the plurality of healthcare payment requests, wherein the determination of the second output overrides the determination of the first output.
10. The at least one network server of claim 9, wherein each of the classification models includes a profile configured based on the historical payment request data for the corresponding group of the plurality of healthcare providers.
11. The at least one network server of claim 10, wherein, when executed by the one or more processors, the computer-readable instructions further cause the one or more processors to update, for the first of the plurality of healthcare payment requests, the profile of the corresponding classification model to reflect the second output.
12. The at least one network server of claim 9, wherein, when executed by the one or more processors, the computer-readable instructions further cause the one or more processors to perform the following in connection with generating the first output for the first healthcare payment request—
- match the first healthcare payment request to a treatment model,
- determine, using the matched treatment model, whether a diagnostic code matches one or both of an expected prescription and procedure code corresponding to the first healthcare payment request,
- the determination that the first output for the first healthcare payment request meets the first criteria indicating fraud or abuse depending at least in part on determining that the diagnostic code corresponding to the healthcare payment request does not match one or both of the corresponding expected prescription and procedure code.
13. The at least one network server of claim 12, wherein, when executed by the one or more processors, the computer-readable instructions further cause the one or more processors to perform the following in connection with generating the first output for the first healthcare payment request—
- match the first healthcare payment request to a diagnosis model,
- determine, using the matched diagnosis model, that symptoms data and one or both of an expected diagnostic test and diagnostic test results corresponding to the first healthcare payment request are as expected.
14. The at least one network server of claim 8, wherein analyzing the first output and the second output and generating the decision for a first of the plurality of healthcare payment requests includes—
- determining that the first output does not meet a first criteria indicating fraud or abuse,
- issuing an approval decision for the first of the plurality of healthcare payment requests.
15. Non-transitory computer-readable storage media having computer-executable instructions for healthcare fraud detection, wherein when executed by at least one processor the computer-readable instructions cause the at least one processor to:
- receive a plurality of healthcare payment requests corresponding to a plurality of healthcare providers;
- match the plurality of healthcare payment requests to corresponding ones of a plurality of predictive models, each of the plurality of predictive models including— a classification model configured based on historical payment request data for a group of the plurality of healthcare providers, a smart agent having a profile comprising a representation of historical data of the corresponding healthcare provider, and
- for each of the healthcare payment requests— compare the contents of at least one data field of the healthcare payment request against the profile of the corresponding smart agent and, based at least in part on the comparison, generating a first output, process the contents of at least one data field of the healthcare payment request via the corresponding classification model to generate a second output, analyze the first output and the second output to generate a decision on the healthcare payment request.
16. The computer-readable storage media of claim 15, wherein analyzing the first output and the second output and generating the decision for a first of the plurality of healthcare payment requests includes—
- determining that the first output meets a first criteria indicating fraud or abuse,
- determining that the second output meets a second criteria indicating acceptable behavior within the corresponding classification model group,
- issuing an approval decision for the first of the plurality of healthcare payment requests, wherein the determination of the second output overrides the determination of the first output.
17. The computer-readable storage media of claim 16, wherein each of the classification models includes a profile configured based on the historical payment request data for the corresponding group of the plurality of healthcare providers.
18. The computer-readable storage media of claim 16, wherein, when executed by the at least one processor, the computer-readable instructions further cause the at least one processor to perform the following in connection with generating the first output for the first healthcare payment request—
- match the first healthcare payment request to a treatment model,
- determine, using the matched treatment model, whether a diagnostic code matches one or both of an expected prescription and procedure code corresponding to the first healthcare payment request,
- the determination that the first output for the first healthcare payment request meets the first criteria indicating fraud or abuse depending at least in part on determining that the diagnostic code corresponding to the healthcare payment request does not match one or both of the corresponding expected prescription and procedure code.
19. The computer-readable storage media of claim 18, wherein, when executed by the at least one processor, the computer-readable instructions further cause the at least one processor to perform the following in connection with generating the first output for the first healthcare payment request—
- match the first healthcare payment request to a diagnosis model,
- determine, using the matched diagnosis model, that symptoms data and one or both of an expected diagnostic test and diagnostic test results corresponding to the first healthcare payment request are as expected.
20. The computer-readable storage media of claim 15, wherein, when executed by the at least one processor, the computer-readable instructions further cause the at least one processor to—
- receive an additional healthcare payment request corresponding to one of the plurality of healthcare providers,
- match the additional healthcare payment request to a corresponding one of the plurality of predictive models,
- compare the contents of at least one data field of the additional healthcare payment request against the profile of the corresponding smart agent and, based at least in part on the comparison, generate a first output,
- determine that the first output does not meet a first criteria indicating fraud or abuse,
- issue an approval decision for the additional healthcare payment request based on the determination that the first output does not meet the first criteria indicating fraud or abuse.
Type: Application
Filed: Nov 7, 2019
Publication Date: Apr 9, 2020
Patent Grant number: 11080793
Applicant: Brighterion, Inc. (Purchase, NY)
Inventor: Akli Adjaoute (Mill Valley, CA)
Application Number: 16/677,458