Providers forced to camouflage in mediocrity.
EDITOR’S NOTE: This the first in a series of articles that explores the use of algorithms in the auditing of medical claims.
The Centers for Medicare & Medicaid Services (CMS) has pioneered the use of computer algorithms for detection of fraud. These efforts leverage technologies such as Monte Carlo computational sampling, Markov chain discrete step methods, linear analysis (least squares fitting), structured virtual construct (Dempster-Shafer) formalism, link and social network analysis (also popular in locating terrorists), Bayesian belief networks, probable graph models, conditional linear Gaussian models, neural computational logic systems (neural networks) and artificial intelligence.
These tools are the caviar, buttered toast, creme fraiche, chives, lemon wedges, red onion, and crumbled hard-boiled eggs of mathematical statistics. And they can catch crooks.
One important way CMS stimulates innovation is by providing giant data sets that can be used as raw input into any fraud-catching model that one might be testing. All personally identifiable information, of course, has been stripped out of the files (see data.cms.gov for more details.)
Three Levels of Fraud Detection
We can divide up these computerized techniques into three classes. These are distinguished by the type of computerized analytical tools used.
Level 1 – Claims-Based Systems
First, there are “claims-based” systems that analyze the information found on individual claims and then check to see that it is not obviously wrong.
In many cases, this amounts to a simple check against external databases, such as the excluded provider list, federal investigation database, compromised provider and beneficiary identification numbers, and compromised contractor information. Information about the patient can be checked against various identity services as well, such as credit records, address records (is the address real?), or Social Security numbers.
Claims can also be filtered through a number of rule checks. For example, if a Medicare claim is filed, a duplicate claim should not be filed for Medicaid. Provider rules check to see that what is charged in the claim is actually the service provided. Although this first level is more or less straightforward, it presents a formidable systems design and programming challenge to make it work.
Level 2 – Process-Based Systems
Second, there are “process-based” systems that evaluate how the claim fits into a broader patter of treatment for the patient. For example, the co-morbidity principle recognizes that chronic conditions may appear together in predictable constellations. Conditional probability distribution techniques identify the probability of any particular sequence of procedures, e.g., what the most likely next procedure is. This would flag a procedure that should not be there, such as an initial visit that follows a few weeks after a previous initial visit.
These process-based systems rely heavily on statistical analysis. Much work must be done to understand factors such as the number of procedures per beneficiary, number of drugs prescribed, and costs per patient. Linear programming can make empirical estimates of expected procedure times or total treatment durations. It is possible to know the total number of procedures by type, according to medical specialty. For example, if a provider is giving 30 vaccinations per day, is that reasonable, or a red flag? Of course every patient is different, but here the theory is that there are “standard treatments,” and these can be understood statistically – and as a result, any provider giving treatment outside of standard care can be identified.
These techniques are used to identify providers that are outside of the range of their peers. It is common for an auditor to justify their audit based on the assessment that the provider is an outlier.
Can this commonly used approach discriminate against a specialized provider? What if they “over-perform” simply because they are working hard? After all, are there not many possible explanations, apart from fraud, why a highly specialized provider would bill a comparatively larger number of patients per day? Perhaps there is a mortgage to pay off.
What we need to ask is why it is believed that a provider that is providing more services than its peers is any more likely to be committing fraud than their peers, who studiously remain within the statistical range of the pack? Why is this alone treated as the judicially non-reviewable “probable cause” needed to launch a detailed audit?
In any case, once the audit is on, then we are at the next level.
Level 3 – Documentation-Based Analysis
The third level is less automated. Here, the audit devolves into subjective assessments by coding “experts” employed by the auditors. Artificial intelligence and other computerized methods of examining claims have not reached the level of being able to “read” the patient notes and determine if a solid case for treatment was made. It is true that various statistical methods have experimented with determining the likelihood of any particular word or phrase appearing in connection with a specific procedure. Some research has shown that it is possible to identify the use of “low-probability” words or phrases that do not belong in notes regarding a given procedure. But none of this takes out the human element. That is left to the human reviewer.
It is at this level that the most contentious and destructive aspects of “recovery auditing” is found. Much conflict is little more than a battle of opinions. The provider thinks the notes and records are sufficient; the auditor thinks they are not. In many cases, the auditor does not understand the specialized terminology in the notes, and certainly is not trained in providing the service being audited. And neither is the administrative law judge, who comes into the picture around five years later.
EDITOR’S NOTE: Part I of this series has explored the side of auditors and the automated tools they employ to reduce fraud. In Part II, Roche will explore how providers can band together and create their own automated tools to mitigate the corrosive effects of the auditing deluge.