Patent Application
20100257074
The present invention relates generally to the processing of entries in a queue, and more specifically relates to identifying a cluster of entries in the queue in order to process the entries in the cluster at the same time.
Lists of records or queues are commonly used to collect and analyze data for a variety of applications. For example, queues may be used to store and track the status of claims issued by a medical services provider. A typical medical services provider, or a third-party acting on behalf of the medical services provider, processes a large volume of claims detailing expenses incurred by patients treated by the medical services provider. Each of these claims includes information and costs associated with one or more procedures or services provided to the patient, and which the medical service provider would like to recover payment. For many patients, payment is recovered by transmitting the claims to the patient's insurance provider or other payer who, in turn, evaluates the charges on the claim and remits the appropriate payment to the medical services provider. Ensuring that this payment process operates smoothly is important to the medical services provider to facilitate payment for the medical service provider's services in a timely manner.
Medical services providers process hundreds or thousands of claims a day. One way to facilitate tracking the status of these claims is to enter the claims as entries in a database which keeps track of, among other things, when the claims were sent and when remittance was received. Due to the large volume of claims being processed, a medical services provider may not receive a response for some claims even though the claims were submitted several weeks or months prior. For each claim in which a response was not received, a communication (e.g., a telephone call) is made to the payer in order to determine why there was no response. If even a relatively small percentage of the claims do not receive a response, the number of follow-up calls required may be quite large, resulting in a process that is both time-consuming and costly for the medical services provider.
Some embodiments of the invention are directed to detection of remittance issues early in a billing cycle to enable a user to determine appropriate actions to correct an underlying cause of the detected remittance issues.
Some embodiments of the invention are directed to a method of detecting remittance issues associated with a plurality of medical billing claims. The method comprises acts of calculating, with at least one processor, an expected open rate for at least one payer based, at least in part, on historical claim billing information collected for a plurality of payers and/or a plurality of providers in a claim billing system; determining an actual open rate for the at least one payer during a predetermined time range based, at least in part on remittance received from claims sent to the at least one payer; identifying at least one bump as a timepoint during the predetermined time range when the actual open rate exceeds the expected open rate; and categorizing the at least one bump as a particular category of remittance issue based, at least in part, on a pattern of remittance during the predetermined time range.
Some embodiments of the invention are directed to at least one computer-readable storage medium encoded with a plurality of instructions, that when executed by a computer, perform a method of detecting remittance issues associated with a plurality of medical billing claims. The method comprises acts of calculating an expected open rate for at least one payer based, at least in part, on historical claim billing information collected for a plurality of payers and/or a plurality of providers in a claim billing system; determining an actual open rate for the at least one payer during a predetermined time range based, at least in part on remittance received from claims sent to the at least one payer; identifying at least one bump as a timepoint during the predetermined time range when the actual open rate exceeds the expected open rate; and categorizing the at least one bump as a particular category of remittance issue based, at least in part, on a pattern of remittance during the predetermined time range.
Some embodiments of the invention are directed to a medical billing claim processing system comprising at least one processor. The at least one processor is programmed to calculate an expected open rate for at least one payer based, at least in part, on historical claim billing information collected for a plurality of payers and/or a plurality of providers in a claim billing system; determine an actual open rate for the at least one payer during a predetermined time range based, at least in part on remittance received from claims sent to the at least one payer; identify at least one bump as a timepoint during the predetermined time range when the actual open rate exceeds the expected open rate; and categorize the at least one bump as a particular category of remittance issue based, at least in part, on a pattern of remittance during the predetermined time range.
It should be appreciated that all combinations of the foregoing concepts and additional concepts discussed in greater detail below (provided such concepts are not mutually inconsistent) are contemplated as being part of the inventive subject matter disclosed herein. In particular, all combinations of claimed subject matter appearing at the end of this disclosure are contemplated as being part of the inventive subject matter disclosed herein.
The accompanying drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component that is illustrated in various figures is represented by a like reference character. For purposes of clarity, not every component may be labeled in every drawing. In the drawings:
The present disclosure generally relates to inventive methods and apparatus for processing entries in a queue, and more specifically to identifying and analyzing clusters of entries in the queue that share common features. A typical medical billing practice processes hundreds or thousands of claims a day by transmitting the claims to a payer such as an insurance company or clearinghouse. The payer usually returns a remittance or denial. However, a certain percentage of the submitted claims do not receive a response from the payer and follow-up, called “claim tracking,” is performed to ensure that the corresponding medical service provider receives proper payment for their services. The status of all submitted claims may be tracked by including information about the claims as entries in an electronic queue such as a database, or in any other suitable electronic format. For each claim that has not received a response after a predetermined amount of time, a follow-up communication to the payer may be initiated to determine the source of the non-response. As the volume of claims processed by a medical billing practice increases, the number of follow-up communications and the length of time before the medical service provider is paid increases.
Applicants have recognized and appreciated that multiple entries in a queue may share common features, and that by grouping the multiple entries together into a cluster, the multiple entries in the cluster may be processed in parallel. For example, if the queue comprises claims for which a response has not been received from a payer, a common root cause relating to why the response has not been received may underlie several of the claims in the queue. Identifying clusters in a queue which may share a common root cause, and addressing the common root cause may obviate the need to follow-up on each of the claims in the queue separately resulting in an efficient problem resolution process.
To this end, some embodiments of the invention are directed to methods and apparatus for identifying candidate clusters of entries (e.g., claims which have not received a response) in a queue that share at least one common feature, and analyzing the candidate clusters to determine a common underlying cause (e.g., why a response has not been received for the claims in the cluster). An exemplary illustration of a method for processing claims in a queue is provided in
After forming a queue of claims in act 102, the claims in the queue are grouped based on shared characteristics in act 104, as described below in more detail. Although some claims may be included in only a single group, other claims may be included in more than one group provided that the claims have shared characteristics with claims in multiple groups. Groups of claims that meet certain criteria are classified as clusters in act 106. In some embodiments, groups may need to comprise a minimum number of claims to be considered a cluster. In addition to a minimum number of claims, other exemplary criteria may also be used when generating clusters and embodiments of the invention are not limited in this respect.
Clusters generated in act 106 are analyzed in act 108 to identify at least one common root cause why the claims have been included in the particular category that is being investigated (e.g., submitted claims without a response). Exemplary ways of analyzing clusters according to some embodiments of the invention are described in more detail below.
After a common root cause has been identified for claims in a cluster, the root cause is addressed to remedy the problem. For example, the common root cause identified in act 108 may be an incorrect pay-to address. In this example, the pay-to address may be corrected in act 110, and the claims in the cluster may be resubmitted to the payer with the corrected pay-to address. It should be appreciated that the common root cause may be addressed by a user with or without directed guidance, or the process may be automated. For example, in some embodiments, options of how to address a root cause issue may be presented to a user and the user may choose from among the options. The options may be presented as a decision tree on a user interface, or in any other suitable way. In other embodiments, software executed on a computer may be used to automatically select an option for addressing the root cause issue without user intervention.
The status of the claims in a cluster that has been analyzed or “worked” is updated in act 112. For example, the status of the claims in a processed cluster may be changed from “Followup” to some other status to indicate that follow-up has been performed on all of the claims in the cluster. Thus, only a limited number of follow-up communications are necessary to process all of the claims in a cluster due to their shared common root cause.
In some embodiments, information about a resolution process for the root cause of a cluster is recorded so future claims having similar attributes may be processed in the same way as the claims in the cluster. The resolution process may be recorded by storing a cluster pattern and the root cause identified for the claims in a cluster for a predetermined amount of time (e.g., one year). By storing this information, new claims that arise during the predetermined amount of time are processed similarly to the claims in the cluster, but new claims that arise outside of this time window are handled differently. It should be appreciated that information about a resolution process may be stored in any suitable manner and for any desired length of time and embodiments of the invention are not limited in this respect.
In some embodiments, claims that do not receive a timely response from a payer are identified, and for each claim that is identified, information that may be useful in determining a common cause is collected. Table 1 illustrates exemplary information that may be collected for each claim that is identified, although other information may also be collected and embodiments of the invention are not limited in this respect.
In some embodiments, determining when a claim should be included in a queue for clustering analysis may be performed by setting an alarm date for each claim that is submitted to a payer. If a response is not received from the payer by the alarm date, the alarm is triggered and the status of the claim is changed to Followup. Alternatively, an alarm may be deactivated if a response is received prior to the alarm date. Alarm dates may be determined based on a number of factors including, but not limited to, historical performance data for a payer, the complexity of the claim, the time of year when the claim is submitted, or any other factors which are related to a billing cycle. Although setting alarms is one example of a process for ensuring that claims are properly tracked, other methods may be used, and embodiments of the invention are not limited in this respect. For example, in some embodiments, claims that do not receive a response from a payer within a fixed amount of time, regardless of the payer's identity, may automatically be transferred to Followup status and may be used in the cluster analysis described above.
After information has been collected on at least some of the claims in the queue to be analyzed, cluster identification methods may be used to identify candidate clusters of claims that might be being processed incorrectly due to a shared root cause or problem.
A cluster identification process 200 in accordance with some embodiments of the invention is illustrated in
As described above, and illustrated as act 202, detailed information is collected for each claim in the queue used for cluster identification. This detailed information may be related to the attributes shown in Table 1 or any other suitable attributes that would assist in categorizing claims into clusters based on a common underlying cause. In some embodiments, detailed information may be stored in a denormalized table in a relational database, although the information may be stored in any other suitable form and embodiments of the invention are not limited in this respect.
After collecting the detailed information for each claim in act 202, the claims are grouped together along dimensions outlined by a set of predefined cluster patterns. The cluster patterns are indicative of a common root cause or problem. Exemplary cluster patterns, to which the embodiments of the invention are not limited, are shown in Table 2. Although only six cluster patterns are illustrated in Table 2, it should be appreciated that any attributes (including those in Table 1 or otherwise) may be combined to define cluster patterns and embodiments of the invention are not limited in this respect.
For each defined cluster pattern, clusters are generated in act 204 based on the claims included in the queue. As described above, a claim may be included in the queue based on numerous criteria including, but not limited to, the claim's current status or if the status of the claim is anticipated to change in the near future. For example, in some embodiments, claims that have been changed to Followup status in the past sixty days may be included in the queue along with claims that are close to their alarm date. By also including claims that are close to their alarm date, these claims are dealt with proactively, rather than waiting until an alarm has been triggered.
In some embodiments, claims in the queue are grouped using the defined cluster patterns in a sequential manner. With reference to Table 2, which defines six cluster patterns, claims may first be grouped according to the attribute “Billing Batch,” and clusters based on this pattern are generated in act 204. After claims are grouped according to the attribute “Billing Batch,” it is determined in act 206 if there are other defined cluster patterns to be analyzed. If there are other defined cluster patterns, another cluster pattern is selected and claims are grouped according to the shared attributes in the new cluster pattern. For example, continuing the example above, claims may be grouped according to the next defined cluster pattern (e.g., Insurance Reporting Category::CSI Result in Table 2) and clusters may be generated based on these shared attributes. In some embodiments, the process continues until all defined cluster patterns have been analyzed, although in other embodiments only a subset of defined cluster patterns may be analyzed, for example, if the number of defined cluster patterns is large. If it is determined in act 206 that no other cluster patterns are to be analyzed, each of the clusters is screened according to predefined criteria to determine if the cluster should be analyzed or discarded.
Applicants have appreciated that it may be useful to only analyze clusters having a minimum number of claims (e.g., 100 claims), or at least to address clusters having a large number of claims first. Thus, in some embodiments, it is determined in act 208 if the number of claims in each cluster exceeds a predetermined threshold value. If the number of claims in the cluster does not exceed the threshold value, the cluster is eliminated in act 210 and it is determined in act 214 if there are more clusters to be screened. If it is determined in act 214 that there are more clusters to be screened, another cluster is selected and it is determined in act 208 if the number of claims in this cluster exceeds the threshold value.
An illustrative example of the above-described thresholding process is as follows: Cluster A generated based on the “Medical Group::Claim Submission Category” cluster pattern has 500 claims. The value of the attribute Medical Group is “ABC Medical Group” and the value of the attribute Claim Submission Category is “123 Submissions.” Cluster B generated based on the same cluster pattern has 5 claims, and has values of Medical Group=“DEF Medical Group” and Claim Submission Category=“456 Submissions.” If the threshold was set at 100 claims, cluster A would survive, but cluster B would be eliminated in act 210 because the number of claims in cluster B is too small to justify investigation through cluster analysis.
Other screening steps in addition to cluster size analysis may be included and embodiments of the invention are not limited in this respect. In some embodiments, clusters may be screened based on whether a pattern characteristic (i.e., cluster pattern and values) is too general to result from a single root cause. For example, a cluster generated based on the cluster pattern “Medical Group::Insurance Reporting Category” that refers to the “Legal” IRC may be eliminated because the “Legal” IRC refers to too wide a variety of insurance companies,” and it is likely that the claims in the cluster do not share the same root cause.
In some embodiments, when a potentially new cluster is identified, it may first be determined whether the potentially new cluster already exists in a database used to store the generated clusters. Determining if the potentially new cluster already exists reduces the possibility of duplicate clusters which may unnecessarily cause the same cluster to be worked multiple times.
In some embodiments, elimination of a cluster in act 210 results in the status of the claims in the cluster remaining unchanged (e.g., the claims in the cluster remain in Followup status), although in other embodiments, clusters that are eliminated may form a claim tracking queue in which each claim in the claim tracking queue is addressed by a follow-up communication in a one-by-one manner.
In some embodiments, claims may be segmented into tiers based on various characteristics, and different groups of users may be responsible for working claims in each tier. For example, claims that are eliminated from the cluster identification process and are placed in a claim tracking queue, may transition from one tier (e.g., the cluster ID tier) to a different tier (e.g., the claim tracking tier) so that ownership of the claims between the two groups is clearly indicated. It should be appreciated that any suitable communication mechanism may be used to communicate the ownership of claims worked by different groups of users, and the aforementioned description of a tier-based system is only one possible implementation.
Once it is determined that all of the clusters have been screened, the remaining clusters are classified as “Active” in act 216 and information about the cluster is added to a cluster database that, among other things, may be used to analyze future claims having similar attributes as described above.
In some embodiments, a relational database is used to store clusters and information about the clusters. Clusters may be stored as records in a clusterrecord table, and general information about the clusters may be entered as a single record in a clustergroup table. For example, the clustergroup table may include information such as the identifier and name of the cluster and whether it is “active cluster” or a “duplicate cluster.” As used herein, the term “duplicate cluster” is used to refer to a cluster which shares a predetermined percentage of claims with another cluster. Detailed information regarding component “key-value” pairs that define the cluster may be stored in a clustergroupvalue table. For example, the clustergroupvalue table may include information stating that the claims in the cluster have a Medical Group ID of 1 and a Claim Submission Category ID of 10. After storing a cluster in the relational database, claims embodied as cluster records in the relational database may be associated with the cluster.
As described above, some claims can belong to more than one cluster. For example, a claim can belong to one cluster generated based on the “Billing Batch” cluster pattern and another cluster generated based on the “Medical Group::Claim Submission Category” cluster pattern. To facilitate querying against clusters generated based on different cluster patterns, in some embodiments in which a relational database is employed, a bridge table may be created, which includes a record that lists the cluster record ID along with the ID of the cluster to which it belongs.
Applicants have recognized that some clusters may have a substantial amount of shared claims between them. Accordingly, in some embodiments, stored clusters may be reviewed for duplicates. Some clusters may be flagged as duplicates if they share a predetermined percentage of claims. In some instances, duplicate clusters may be identical, although in other instances duplicate clusters may only share a majority of their claims. Determining whether claims are duplicates may be performed in any suitable way and embodiments of the invention are not limited in this respect.
After the clusters have been added to the database, in some embodiments, the clusters are scored to determine a likelihood that the claims share a root cause issue. One or more algorithms, described in more detail below, may be used to determine the score for a cluster.
Applicants have recognized that cluster identification techniques according to embodiments of the present invention may also be useful in systems that assist multiple providers to receive payment from multiple payers. Such an system may be used, for example, by a third party who assists medical services providers in collecting payments for claims by submitting the claims to insurance companies or other payers on behalf of the medical services providers. The third party may use information that is gathered across multiple providers and payers to address common root cause issues that may arise in such systems.
To this end, another type of cluster identification analysis 300, for use with some embodiments of the invention is called “early remittance issue detection” and is illustrated in
Empirical survival distributions may be determined based on any suitable information related to a claim billing history of providers and/or payers in a medical claim processing system. For example, claims sent on paper forms typically have significantly longer turn-around times than claims sent electronically (e.g., using ANSI 837 I/P forms), and claims remitted electronically (e.g., using ANSI 835 forms) typically have slightly faster turn-around times when combined with Electronic Funds Transfer (EFT). Based on this information, an upper envelope for acceptable durations for claims to reside at a payer may be determined. Actual claims billed within a predetermined time range (e.g., the last 120 days) may be analyzed to determine if the percentage of claims that have not received remittance (i.e., claims that are “open”) exceeds this upper envelope. The information output from this analysis may be provided via a user interface to a user to facilitate further analysis of specific claims or groups of claims identified by the early remittance detection system.
An exemplary early remittance issue detection process with reference to
In act 304, the information collected in act 302 may be used to calculate cumulative probability distributions for one or more combinations of payer, batch format, remittance format, remittance advice format, and/or other suitable claim information, for which remittance was received based, at least in part, on empirical return times. These cumulative probability distributions are also referred to herein as “expected open rates,” although it should be appreciated that the term “expected open rates” is not limited to a rate that is calculated using any particular statistical method. In act 306, the expected open rates may be compared to actual open rates for claims submitted within a predetermined time range, and instances where the actual open rates exceed the expected open rates may be identified as a bump.
The graph in
After the one or more bumps are identified, each bump may be scored in act 308. It should be appreciated that any suitable technique for scoring bumps may be used and the scoring techniques discussed below are merely non-limiting examples. In some embodiments, a claim volume score, C(B), a dollar amount score, A(B), and a percentage of daily charges score, R(B), may be calculated for each bump, B, according to the following formulas:
C(Bt)=1[{circumflex over (p)}tc>pt]({circumflex over (p)}tc−pt)ct
A(Bt)=1[{circumflex over (p)}ta>pt]({circumflex over (p)}ta−pt)at
R(Bt)=A(Bt)/ADC
where Pt is the expected open rate, {circumflex over (p)}tc is the actual open rate for claims, {circumflex over (p)}ta is the actual open rate for outstanding dollars, ct is the claims in time period t, at is the amount billed in time period t, and ADC is the average daily charge.
Each of these scores may be designed to represent different aspects of remittance situations in order to facilitate early detection of remittance issues. For example, the claim volume score, C(B), relates to high claim volume situations, and tends to apply greater weights to large volume clients. The dollar amount score, A(B), relates to the actual charged amounts, and is designed to capture situations in which a few high dollar claims are outstanding. The percentage of daily charges score, R(B), relates to the size of a bump with respect to the overall charge volume of a client, which tends to reduce at least some of the differences between small volume clients and large volume clients.
In act 310, combinations of bumps may be considered to determine if multiple bumps are near each other and should be grouped. Grouping of bumps based, at least in part, on nearness of the bumps, may be accomplished using any suitable technique and aspects of the invention are not limited in this respect. For example, in some embodiments, bumps that are contiguous or near-contiguous in time may be grouped in act 312 and the process may return to act 308 for recalculation of scores based on the grouped bumps. In other embodiments, the nearness of bumps in act 310 may be determined using other criteria including, but not limited to, grouping based on providers of a same medical group, billing batches of a similar format, and transfertype. The process of grouping bumps may be referred to as “Clustering” and “Tree Pruning.”
After it has been determined in act 310 that there are no other near bumps, the bump or group of bumps may be categorized as an issue in act 314. Categorization of bumps and groups of bumps is described in more detail below. In act 316, it is determined if more bumps are to be categorized. If there are additional bump(s) to be categorized, the process returns to act 308 to calculate score(s) for the additional bump(s). When it has been determined that all of the bumps have been categorized, the process continues to act 318 to determine if one or more scores associated with an issue are above a predetermined threshold value. If it is determined that the score(s) are not above the threshold value, in act 320, the issue is eliminated from consideration. Otherwise, if it is determined in act 318 that the score(s) are above the threshold value, the issue may be stored (e.g., in a queue) for addressing. In act 322, it is determined whether scores for additional issues are to be compared to a predetermined threshold value. If it is determined that additional issues are to be considered, the process returns to act 318 where the score(s) for a new issue are compared to the predetermined threshold value. After scores for all of the issues have been compared to the threshold value, the underlying issues may be addressed in act 324. Although the exemplary process shown in
In some embodiments, the categorization of bumps may be facilitated using at least one user interface configured to display remittance information about claims that have been submitted to one or more payers. An example of a portion of a user interface that may be used in accordance with some embodiments of the invention is illustrated in
The exemplary user interface shown in
In addition to viewing remittance data on a date axis, the exemplary user interface shown in
Although the selection areas 1730 and 1750 may be used to change the remittance information displayed in corresponding graphs 1710, 1720, and 1740, interaction by a user (e.g., mouse click, key press, etc.) with some portions of the graphs themselves may result in changing the displayed remittance information. For example, if a user selects a particular payer displayed in graph 1740, graphs 1710 and 1720 may be updated to reflect the remittance by date for the selected payer. Alternatively, a user may select one of the displayed bars in graph 1710 or graph 1720 corresponding to a particular day, and remittance information displayed in graph 1740 may be restricted to remittance information only for the day that is selected. Thus, the graphs may have the ability to drive each other to enable a quick exploration of the data to facilitate categorization. Although a specific implementation of a user interface for use with some embodiments of the invention has been described, it should be appreciated that any suitable user interface including any types of graphs and/or selection regions may be used and aspects of the invention are not limited in this respect.
Categorizing bumps will now be explained in more detail with reference to
Applicants have also recognized that certain providers that have been receiving remittance for some time may suddenly stop receiving remittance from a particular payer. This behavior is captured by the category “Remittance Cessation.” One possible reason why remittance cessation occurs is due to the provider signing up for Electronic Funds Transfer (EFT) without notifying the payer, although other circumstances may also result in remittance cessation. Bumps may be classified in the Remittance Cessation category if the bumps are contiguous from the current day, but there was remittance received by the provider in the past (unlike the Remittance Never Received category).
An example of remittance information that falls within the Remittance Cessation category is illustrated in
A third category is “Specific Remittance Failure” in which bumps are most commonly related to individual billing batches where 100% of the claims have not received remittance and are currently at the payer. In many of these cases, it is likely that the set of claims never made it into the payer's adjudication system. An example of remittance information that falls within this category is illustrated in
Another type of Specific Remittance Failure relates to “crossover billing events” (e.g., when Medicare forwards claims directly to Medicaid) and is illustrated in
Additionally, because a remittance issue with some crossover claims on day 2412 has been identified, a user may want to examine all claims sent to a particular payer (e.g., Medicaid) on day 2412 to determine if they succeeded or failed on that day. This analysis may be performed by grouping the claims by context as shown in
A fourth category is “General Remittance Failure.” This category comprises all of the bumps that were not categorized into the other categories. Although only four categories have been described, bumps may be categorized using any suitable categories and any suitable techniques and aspects of the invention are not limited in this respect.
In some embodiments, clusters identified via cluster identification process 200 or cluster identification process 300 are scored to indicate how likely it is that the claims share a common root cause. Scoring the clusters facilitates the identification of clusters that have a high likelihood of having a shared root cause issue underlying the claims in the cluster. Thus, clusters with a high score are good candidates for further investigation into the root cause. In some embodiments, clusters with a high score may be given priority so that a follow-up communication with the payer is initiated early in the resolution process. One or more algorithms may be used to determine the score for a cluster, and not all algorithms may be used to score each type of cluster. In some implementations, if multiple algorithms are used to score a cluster, only the highest score is reported, although in other implementations, an average score may be used.
Flow charts for three exemplary scoring algorithms are illustrated in
An alarm score is representative of the percentage of alarms that actually fired for a given cluster pattern. In act 510, the number of possible alarms for a particular cluster pattern is determined. In act 520, the actual number of alarms that were triggered is calculated, and in act 530, the alarm score is calculated by dividing the actual number of alarms by the number of possible alarms and multiplying by 100. For example, suppose in the past sixty days there were 100 claim alarms set to be triggered for a given Medical Group::IRC cluster pattern combination and 90 of these alarms were actually triggered. In this example, a cluster based on this Medical Group and IRC would have an alarm score of 90.
Another type of scoring algorithm relates to claims that are submitted in the same billing batch. Claims submitted in the same billing batch are submitted to the payer at the same time and via the same method. In all likelihood, if one of the claims is on file with the payer, then the other claims in the billing batch should also be on file with the payer.
A process for calculating a billing batch score is illustrated in
Another type of scoring algorithm is based on reviewing payer responses after the status of a claim was changed to Followup. Since clusters are comprised of claims whose status was changed to Followup within a certain time period (e.g., within the past 60 days), in some cases, a payer response will have been obtained after the status of the claim was changed to Followup. For example, remittance may be received by the provider shortly after an alarm date has passed or a follow-up communication with the payer may have resolved the problem.
When working a cluster, after the problem with a claim has been resolved, the reason why the status of a claim was changed may be recorded as a “kickcode.” A process for calculating an exit information score by reviewing these post-Followup responses using information stored as kickcodes is illustrated in
In some embodiments, alarm scores and exit information scores are compared to a threshold value and are only considered valid if the scores are above the threshold value. Although three algorithms are described for scoring clusters, it should be appreciated that other types of scoring algorithms may also be employed and embodiments of the invention are not limited in this respect.
Once the clusters have been identified and scored, the results may be made available as a report to one or more users via a “Cluster Analysis Report” interface. The report allows users to generate a cross practice list of clusters which can then be “drilled into” so that their component claims can be reviewed. In addition to the score, the report comprises other information including: (1) The number of claims in Followup status, (2) The number of claims in Billed status, (3) The number of “worked” claims, and (4) The total claim count. An exemplary interface for a cluster analysis report generated by embodiments of the invention is illustrated in
As described above, Followup status refers to claims where an alarm has been triggered, indicating that the payer should be contacted and Billed status refers to claims where the alarm is set to be triggered in the near future (e.g., within the next five business days). By including both the Billed claims and the Followup claims in the cluster identification process, claims that have not yet triggered alarms may be dealt with proactively before an alarm is triggered.
An analysis process for “working” a cluster in accordance with some embodiments of the invention includes the following steps. First, a list of clusters may be reviewed for clusters with the best combination of “open” (Billed and Followup status) claims with a relatively high score. For example, in the exemplary report shown in
After a cluster has been selected to be worked, information is collected based on the specific cluster pattern which was used to generate the cluster. The information may be automatically collected from other parts of the integrated system or the information may be manually collected by a user, and embodiments of the invention are not limited in this respect. For example, if the cluster was generated based on the “Billing Batch” cluster pattern, then other claims from the same billing batch are reviewed to determine if responses have been received from the payer for those claims. The score of the cluster may be used to estimate the overall processing of the claims in a cluster. If a low number of responses is detected, the user may then review those individual claims to better understand their nature. The payer corresponding to the claims may then be contacted to verify the status of a few other claims in the billing batch.
Similarly, if the cluster was derived from the “Medical Group::Claim Submission Category” cluster pattern, then recent accounts receivable activity related to that pattern may be analyzed. Based on the initial analysis, the user may decide to contact the payer directly to confirm their analysis. For the previously mentioned “Medical Group::Claim Submission Category” cluster, if the user notices that there have been no recent payments, the payer may be contacted to verify the billing address of the medical group.
If it is determined that all claims in a cluster do not share a common root cause, the “Cluster Analysis Report” interface enables users to create subsets of the clusters. The subsets of clusters can then be analyzed in a similar manner as described above for the other clusters. For example, a user may investigate a cluster based on the medical group cluster pattern and after some analysis, determine that a root cause is shared between claims for a single provider in the medical group. A subcluster may be formed of just the claims for the single provider, and the user may then make a determination regarding whether the claims in the subcluster share a root cause. If it is determined that the claims in the subcluster do not share a root cause, the subcluster can be flagged as “Rejected,” or alternatively, the subcluster may not be added to the database. However, if it is determined that the claims in the subcluster may share a root cause, the subcluster is added to the database and is “worked” as described above.
A next step in the cluster resolution process may be to remove claims from the queue after the common cause has been addressed. This may be accomplished by changing the status of the claim to a status that more accurately describes its condition with the payer. In addition, in some embodiments, a note may be appended to the claim which reflects cluster-related findings. For example, suppose it was determined that the claims belonging to a cluster were paid by the payer and that the checks were cashed by the provider. In this example, a duplicate explanation of benefits (EOB) may be requested from the payer, the status of the claims may be updated, and a note reflecting the research may be added.
As described above, one method for changing a claim's status is to add a “kickcode” to it. A kickcode provides a general description of why the claim was moved to a particular status. In the aforementioned example, the claim may be assigned a kickcode “TRAKREMIT” indicating that the check had been cashed by the provider more than thirty days ago. This would change the status of the claims to “Billed” since a response from the payer is expected—in this case, the duplicate EOB. A more cluster-specific note such as “Spoke to John Doe at the payer, the check was cashed on Jan. 1, 2009” may also be added.
Applicants have recognized that in systems in which clusters are worked by a plurality of users in a group, it may be advantageous to automatically assign particular clusters to be worked to particular users in the group. Thus, some embodiments of the invention are directed to automatically assigning a cluster to a user in a group after the cluster is generated according to one or more cluster identification processes. By assigning clusters to particular users, it may be easier to track which clusters are being worked and by whom. Such a system may also help ensure that high-volume clusters do not go unassigned, and that two users do not work duplicate work if they work on similar, but not “duplicate” clusters. It should be appreciated that some or all of the generated clusters may be automatically assigned to a user, whereas other clusters may be assigned manually.
An exemplary workflow for a cluster analysis process that can be used work a cluster generated by the aforementioned cluster identification and generated processes according to some embodiments of the invention, is now described with reference to
The information listed in the report may be linked to additional information that may be helpful in enabling the user to determine a root cause for a cluster. For example,
A user may also learn about a cluster by viewing the individual claims that make up a cluster as shown in
In some instances, a user may specify the “status” of a cluster. For example, a cluster may be marked as “Validated,” “Rejected,” or “Assigned,” to indicate that the cluster has already been worked. By indicating the status of a cluster, users will be alerted to clusters that have already been analyzed and rejected so as not to spend more time reanalyzing such clusters, whereas clusters identified as “Validated” can be quickly processed by a user.
After a user has determined a root cause for the claims in the cluster, all of the claims in the cluster can be processed en masse as illustrated in
In some implementations of the claim processing wizard, notes entered by a first user may be viewable to a second user in a group of users that is working clusters. For example, notes may be made available to users in the group as a portion of a software program executed on one or more computers connected via a network. By making notes accessible to one or more other users in a group of users, common root causes that are identified by one user may be easily shared with other users in the group resulting in increased productivity and improved reporting.
The collection of claims gathered by the claim processing wizard is referred to as a “claimset.” The actions taken against claims in a claimset are taken en masse so that most or all of the claims belonging to a claimset are “kicked” at the same time. In some implementations, the claim processing wizard may accomplish this by adding a “claimnote” to each claim. For example, if claims are still in process with a payer, a claimnote with a “CIP” kickcode may be added to each claim in the claimset.
Depending on the nature of the cluster, claims outside of the cluster, but sharing similar characteristics may also be processed. This process, known as “Reach Into Billed,” may be used when the problem identified by the cluster impacts all claims recently submitted to a payer. For example, if the ID number for a provider is incorrect, then all claims submitted to the payer will be lost (or denied). In this case, any claim recently billed to the payer will need to be resubmitted, not just those whose alarm has already been triggered.
An exemplary interface for a “Reach into Billed” process for analyzing clusters generated according to some embodiments of the invention is shown in
Since clusters are likely to persist over time users may specify how future claims matching the specified cluster pattern should be processed. For example, suppose it is determined that the previously mentioned cluster A is a valid cluster and that all claims for it should be assigned the kickcode “TRAKREMIT.” This information can be recorded and if additional claims enter Followup status that meet the conditions for belonging to cluster A, a user will know that (1) these new claims belong to a “validated” cluster group and (2) they should be assigned a kickcode of TRAKREMIT. In some embodiments, A cluster group may only remain valid for only a limited period of time. For example, if two claims both belong to the same cluster group but they entered Followup status one year apart, the reasons behind their movement into Followup status may be quite different.
Information about a cluster generated according to some embodiments of the invention may be stored using a “Cluster Group Admin” interface as illustrated in
In some implementations of a cluster analysis process, a work report may be generated if the root cause determined for claims in a cluster may need to be handled by a particular user or department. For example, if a cluster has resulted from a bad “Pay-To” address, a report may be generated that can be forwarded to a user who deals with enrollment of payers and providers. Additionally, the group level information included in a work report may also be useful for a user working a cluster, as the group level information provides additional data that may be helpful in determining a root cause for the claims in the cluster. An example of a report generating interface for creating reports for clusters generated in accordance with embodiments of the invention is illustrated in
Having thus described several aspects of some embodiments of this invention, it is to be appreciated that various alterations, modifications, and improvements will readily occur to those skilled in the art.
Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only.
The above-described embodiments of the present invention can be implemented in any of numerous ways. For example, the embodiments may be implemented using hardware, software or a combination thereof. When implemented in software, the software code can be executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers.
Further, it should be appreciated that a computer may be embodied in any of a number of forms, such as a rack-mounted computer, a desktop computer, a laptop computer, or a tablet computer. Additionally, a computer may be embedded in a device not generally regarded as a computer but with suitable processing capabilities, including a Personal Digital Assistant (PDA), a smart phone or any other suitable portable or fixed electronic device.
Also, a computer may have one or more input and output devices. These devices can be used, among other things, to present a user interface. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output. Examples of input devices that can be used for a user interface include keyboards, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computer may receive input information through speech recognition or in other audible format.
Such computers may be interconnected by one or more networks in any suitable form, including as a local area network or a wide area network, such as an enterprise network or the Internet. Such networks may be based on any suitable technology and may operate according to any suitable protocol and may include wireless networks, wired networks or fiber optic networks.
Also, the various methods or processes outlined herein may be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. Additionally, such software may be written using any of a number of suitable programming languages and/or programming or scripting tools, and also may be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine.
In this respect, the invention may be embodied as a non-transitory computer readable medium (or multiple computer readable media) (e.g., a computer memory, one or more floppy discs, compact discs, optical discs, magnetic tapes, flash memories, circuit configurations in Field Programmable Gate Arrays or other semiconductor devices, or other tangible computer storage medium) encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the invention discussed above. The non-transitory computer readable medium or media can be transportable, such that the program or programs stored thereon can be loaded onto one or more different computers or other processors to implement various aspects of the present invention as discussed above.
The terms “program” or “software” are used herein in a generic sense to refer to any type of computer code or set of computer-executable instructions that can be employed to program a computer or other processor to implement various aspects of the present invention as discussed above. Additionally, it should be appreciated that according to one aspect of this embodiment, one or more computer programs that when executed perform methods of the present invention need not reside on a single computer or processor, but may be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the present invention.
Computer-executable instructions may be in many forms, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically the functionality of the program modules may be combined or distributed as desired in various embodiments.
Also, data structures may be stored in computer-readable media in any suitable form. For simplicity of illustration, data structures may be shown to have fields that are related through location in the data structure. Such relationships may likewise be achieved by assigning storage for the fields with locations in a computer-readable medium that conveys relationship between the fields. However, any suitable mechanism may be used to establish a relationship between information in fields of a data structure, including through the use of pointers, tags or other mechanisms that establish relationship between data elements.
Various aspects of the present invention may be used alone, in combination, or in a variety of arrangements not specifically discussed in the embodiments described in the foregoing and is therefore not limited in its application to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiments.
Also, the invention may be embodied as a method, of which an example has been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.
The indefinite articles “a” and “an,” as used herein, unless clearly indicated to the contrary, should be understood to mean “at least one.”
The phrase “and/or,” as used herein, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and/or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and/or” clause, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, a reference to “A and/or B”, when used in conjunction with open-ended language such as “comprising” can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc.
As used herein, “or” should be understood to have the same meaning as “and/or” as defined above. For example, when separating items in a list, “or” or “and/or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as “only one of” or “exactly one of,” or, “consisting of,” will refer to the inclusion of exactly one element of a number or list of elements. In general, the term “or” as used herein shall only be interpreted as indicating exclusive alternatives (i.e. “one or the other but not both”) when preceded by terms of exclusivity, such as “either,” “one of,” “only one of,” or “exactly one of.” “Consisting essentially of,” shall have its ordinary meaning as used in the field of patent law.
As used herein in, the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, “at least one of A and B” (or, equivalently, “at least one of A or B,” or, equivalently “at least one of A and/or B”) can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.
Having thus described several aspects of at least one embodiment of this invention, it is to be appreciated various alterations, modifications, and improvements will readily occur to those skilled in the art. Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only.
This application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Application Ser. No. 61/166,351, entitled “METHODS AND APPARATUS FOR QUEUE-BASED CLUSTER ANALYSIS,” filed on Apr. 3, 2009, which is herein incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61166351 | Apr 2009 | US |
