Patent Application
20130262149
Generally, claims payment systems are very complex. Claims systems often process a high volume of claims in accordance with dynamic medical policies, payment policies, contract terms, and benefit plans. Updating and changing multi-line claim rules enforcing such policies, plans, and terms can require a significant amount of time, effort, and expense. Thus, a need exists for a more efficient and cost-effective manner for handling updates and changes to multi-line claim rules.
In general, embodiments of the present invention provide systems, methods, apparatus, and computer program products for processing a claim.
In accordance with one aspect, a method for processing a claim is provided. In one embodiment, the method comprises (1) processing a current claim line in accordance (a) with a first claims processing rule and (b) a first support claim line; (2) determining whether an entry exists in a table for the first claims processing rule, wherein the entry for the first claims processing rule indicates whether to (a) create a case for the current claim line or (b) consider the current claim line further for creating a case when the current claim line and a support claim line satisfy the requirements for the first claims processing rule; (3) after determining that an entry exists in the table for the first claims processing rule, determining whether the current claim line and the first support claim line satisfy the requirements of the entry for the first claims processing rule; and (4) after determining that the current claim line and the first support claim line satisfy the requirements of the entry for the first claims processing rule, at least one of (a) creating a case for the current claim line or (b) considering the current claim line further for creating a case based at least in part on the first support claim line.
In accordance with another aspect, a computer program product for processing a claim is provided. The computer program product may comprise at least one computer-readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising executable portions configured to (1) process a current claim line in accordance (a) with a first claims processing rule and (b) a first support claim line; (2) determine whether an entry exists in a table for the first claims processing rule, wherein the entry for the first claims processing rule indicates whether to (a) create a case for the current claim line or (b) consider the current claim line further for creating a case when the current claim line and a support claim line satisfy the requirements for the first claims processing rule; (3) after determining that an entry exists in the table for the first claims processing rule, determine whether the current claim line and the first support claim line satisfy the requirements of the entry for the first claims processing rule; and (4) after determining that the current claim line and the first support claim line satisfy the requirements of the entry for the first claims processing rule, at least one of (a) create a case for the current claim line or (b) consider the current claim line further for creating a case based at least in part on the first support claim line.
In accordance with yet another aspect, an apparatus comprising at least one processor and at least one memory including computer program code is provided. In one embodiment, the at least one memory and the computer program code may be configured to, with the processor, cause the apparatus to at least (1) process a current claim line in accordance (a) with a first claims processing rule and (b) a first support claim line; (2) determine whether an entry exists in a table for the first claims processing rule, wherein the entry for the first claims processing rule indicates whether to (a) create a case for the current claim line or (b) consider the current claim line further for creating a case when the current claim line and a support claim line satisfy the requirements for the first claims processing rule; (3) after determining that an entry exists in the table for the first claims processing rule, determine whether the current claim line and the first support claim line satisfy the requirements of the entry for the first claims processing rule; and (4) after determining that the current claim line and the first support claim line satisfy the requirements of the entry for the first claims processing rule, at least one of (a) create a case for the current claim line or (b) consider the current claim line further for creating a case based at least in part on the first support claim line.
Having thus described the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
Various embodiments of the present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the inventions are shown. Indeed, these inventions may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. The term “or” is used herein in both the alternative and conjunctive sense, unless otherwise indicated. The terms “illustrative” and “exemplary” are used to be examples with no indication of quality level. Like numbers refer to like elements throughout.
As should be appreciated, various embodiments may be implemented in various ways, including as methods, apparatus, systems, or computer program products. Accordingly, various embodiments may take the form of an entirely hardware embodiment or an embodiment in which a processor is programmed to perform certain steps. Furthermore, various implementations may take the form of a computer program product on a computer-readable storage medium having computer-readable program instructions embodied in the storage medium. Any suitable computer-readable storage medium may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.
Various embodiments are described below with reference to block diagrams and flowchart illustrations of methods, apparatus, systems, and computer program products. It should be understood that each block of the block diagrams and flowchart illustrations, respectively, may be implemented in part by computer program instructions, e.g., as logical steps or operations executing on a processor in a computing system. These computer program instructions may be loaded onto a computer, such as a special purpose computer or other programmable data processing apparatus to produce a specifically-configured machine, such that the instructions which execute on the computer or other programmable data processing apparatus implement the functions specified in the flowchart block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including computer-readable instructions for implementing the functionality specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide operations for implementing the functions specified in the flowchart block or blocks.
Accordingly, blocks of the block diagrams and flowchart illustrations support various combinations for performing the specified functions, combinations of operations for performing the specified functions, and program instructions for performing the specified functions. It should also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or operations, or combinations of special purpose hardware and computer instructions.
As will be understood from
In an exemplary embodiment, the processor 205 may be configured to execute instructions stored in memory or otherwise accessible to the processor 205. As such, whether configured by hardware or software methods, or by a combination thereof, the processor 205 may represent an entity capable of performing operations according to embodiments of the present invention when configured accordingly. For example, as discussed in more detail below, the claims system 100 may be configured, among other things, to process and analyze claims. A display/input device 264 for receiving and displaying data may also be included in (or in communication with) the claims system 100. This display device/input device 264 may be, for example, a keyboard or pointing device that is used in combination with a monitor (e.g., an electronic screen/display). The display/input device 264 may be a touchscreen that can detect the presence and location of a touch within the display area. The claims system 100 may further include transitory and non-transitory memory 263, which may include both random access memory (RAM) 267 and read only memory (ROM) 265. The claims system's ROM 265 may be used to store a basic input/output system (BIOS) 226 containing the basic routines that help to transfer information to the different elements within the claims system 100.
In addition, in one embodiment, the claims system 100 may include at least one storage device 268, such as a hard disk drive, a CD drive, and/or an optical disk drive for storing information on various computer-readable media. The storage device(s) 268 and its associated computer-readable media may provide nonvolatile storage. The computer-readable media described above could be replaced by any other type of computer-readable media, such as embedded or removable multimedia memory cards (MMCs), secure digital (SD) memory cards, Memory Sticks, electrically erasable programmable read-only memory (EEPROM), flash memory, hard disk, and/or the like. Additionally, each of these storage devices 268 may be connected to the system bus 261 by an appropriate interface.
Furthermore, a number of executable instructions, applications, scripts, program modules, and/or the like may be stored by the various storage devices 268 and/or within RAM 267. Such executable instructions, applications, scripts, program modules, and/or the like may include an operating system 280, a receiving module 270, a processing module 260, and an inclusions module 250. As discussed in more detail below, these executable instructions, applications, program modules, and/or the like may control certain aspects of the operation of the claims system 100 with the assistance of the processor 205 and operating system 280 (and be selectively enabled and/or disabled)—although their functionality need not be modularized. In addition to the program modules, the claims system 100 may store or be in communication with one or more databases, such as database 240 storing claims processing rules and/or claims.
Also located within the claims system 100, in one embodiment, is a network interface 274 for interfacing with various computing entities, including a print computing entity. This communication may be via the same or different wired or wireless networks (or a combination of wired and wireless networks). For instance, the communication may be executed using a wired data transmission protocol, such as fiber distributed data interface (FDDI), digital subscriber line (DSL), Ethernet, asynchronous transfer mode (ATM), frame relay, data over cable service interface specification (DOCSIS), or any other wired transmission protocol. Similarly, the claims system 100 may be configured to communicate via wireless external communication networks using any of a variety of protocols, such as 802.11, general packet radio service (GPRS), Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA2000), CDMA2000 1X (1xRTT), Wideband Code Division Multiple Access (WCDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Evolution-Data Optimized (EVDO), High Speed Packet Access (HSPA), High-Speed Downlink Packet Access (HSDPA), IEEE 802.11 (Wi-Fi), 802.16 (WiMAX), ultra wideband (UWB), infrared (IR) protocols, Bluetooth™ protocols, wireless universal serial bus (USB) protocols, and/or any other wireless protocol.
It will be appreciated that one or more of the claims system's 100 components may be located remotely from other claims system 100 components. Furthermore, one or more of the components may be combined and additional components performing functions described herein may be included in the claims system 100.
Embodiments of the present invention may involve the use of one or more customer computing entities 110. Generally, the term “computing entity” may refer to, for example, any computer, computing device, mobile phone, desktop, tablet, notebook or laptop, database management system, distributed system, server, blade, gateway, switch, processing device, or combination of processing devices adapted to perform the functions described herein. Further, the customer computing entity may refer to a computing entity associated with a doctor, a hospital, a pharmacy, an insurance provider, a care manager, and/or other healthcare-related entities or professionals.
As will be recognized, the customer computing entity 110 may include components similar to those described with regard to the claims system 100. For example, the customer computing entity 110 may comprise: (1) a processor that communicates with other elements via a system interface or bus; (2) a display device/input device; (3) memory including both ROM and RAM; (4) a storage device; and (5) a network interface. Similarly, a customer computing entity 110 may comprise executable instructions, applications, scripts, program modules, and/or the like. As will be recognized, these architectures are provided for exemplary purposes only and are not limited to the various embodiments.
Reference will now be made to
In one embodiment, the process may begin at Block 300 of
In one embodiment, each claim may include a claim header. An exemplary claim header is shown in
In one embodiment, in addition to a claim header, a claim may have one or more lines (see
In one embodiment, after receiving a claim, the claims system 100 can process the lines of the claim in accordance with various claims processing rules. As will be recognized, claims processing rules may be executable instructions or computer program code stored in memory that can be executed and applied to claim lines by the claims system 100 (e.g., via the processing module 260) for pricing claims, scoring claims, auditing claims, bundling claims, and/or the like. Claims processing rules may also be for enforcing various policies, guidelines, requirements, contractual terms, and/or the like. For instance, claims processing rules can be used to enforce provisions of a provider's contract, contracted payment/reimbursement amounts, covered services and equipment of a benefit plan, copays, age limits, deductibles, and/or the like. Thus, there may be a set of claims processing rules for each benefit plan, for each provider, for certain services and/or equipment, for certain line procedure codes, combinations thereof, and/or the like.
In one embodiment, each claims processing rule can be set to “ON” or “OFF” (e.g., the ON or OFF can be used to indicate whether a rule is set to execute or not). Further, each claims processing rule may define a firing order (e.g., execution or processing order). The firing order may define the order or sequence in which the claims processing rule should fire or be executed by the claims system 100. For instance, each claims processing rule in
In one embodiment, the claims system 100 may process the claim on a line-by-line basis. When a line of a claim is being processed in accordance with a claims processing rule, it is considered as being the “current claim line.” Certain claim lines are to be processed without reference to other claim lines. Any line considered in combination with the current claim line is considered a “support claim line.” The history definition of a claims processing rule can define how the current claim line being processed should be considered. For instance, the history definition of a claims processing rule can define that one or more support claim lines should be used from the same claim, a different claim for the same date of service, a different claim for a different of service, and/or the like. Thus, support claim lines can be from the same claim or different claims. In a particular embodiment, the present invention is for processing a current claim in in consideration with one or more support claim lines. Continuing with the above example, as shown in
In one embodiment, the rules specification may also define whether the claim should reference certain tables in a dictionary (see
Further, as part of processing a line of a claim (Block 305 of
In one embodiment, creating/generating a case for a given line may stop the processing of a claim such that additional claims processing rules would not be applied to the current claim line or other lines of the claim. In another embodiment, creating/generating a case for a given line might not stop the processing of the claim depending on the configuration; rather, it may allow for additional claims processing rules to be applied to the current claim line or other lines of the claim. If a claim is processed in accordance with all applicable claims processing rules without generating or creating a case, the claim is considered “cleared,” and the claims system 100 can create/generate a recommendation to pay/reimburse the claim as submitted.
In one embodiment, if the logic of a claims processing rule is not operating as desired (e.g., denying or modifying lines that should be cleared), updates or changes to the appropriate claims processing rules may be necessary (and/or new claims processing rules may need to be created/generated). Similarly, when policies, guidelines, requirements, or contractual terms being enforced by claims processing rules are changed, changes to the claims processing rules may also be necessary. Such updates or changes to claims processing rules may require new or revised executable instructions or computer program code that carry out the revisions, changes, or updates to the corresponding rule. This may require both a significant amount of time and resources—including creating/generating new or revised executable instructions or computer program code, updating a claims processing rule's specification, creating/generating test scenarios for the changes, reviewing and confirming the request with the client, and/or scheduling implementation of the rule once quality assurance steps are completed and approved. For instance, assume the UNBUN_PAIRS rule needed to be changed to only deny line procedure code 11000 from being paid/reimbursed when submitted with line procedure code 99215 for non-Medicare claims. To cause the claims system 100 to create/generate (or consider further for creating/generating) a case when processing non-Medicare claims and prevent the claims system 100 from creating/generating a case for Medicare claims, the executable instructions or computer program code carrying out the UNBUN_PAIRS rule would normally need to be revised to accommodate the change.
Embodiments of the present invention, however, include a new data-driven approach for implementing revisions, changes, updates, and/or the like to claims processing rules. To do so, the processing module 260 and/or the claims processing rules can be updated to reference specific tables when processing multi-line claims. In one embodiment, the processing module 260 and/or the claims processing rule can be updated to reference an inclusions table to determine whether the current claim line should create/generate a case or be considered further for creating/generating a case—even though the existing executable instructions or computer program code carrying out the rule may indicate that a case should not be created/generated. In another embodiment, the processing module 260 and/or the claims processing rule can be updated to reference an exclusions table to determine whether the current claim line should be excluded from creating/generating a case—even though the existing executable instructions or computer program code carrying out the rule may indicate that a case should be created/generated. And in yet another embodiment, the processing module 260 and/or the claims processing rule can be updated to reference a decision table to determine how to handle the current claim line (e.g., whether to create/generate a case or to exclude a case from being created/generated).
In an exemplary inclusion embodiment, the claims system 100 (e.g., via the inclusions module 250) can create/generate an inclusions table (e.g., COMPARE_INCLUSIONS table) as a table in the dictionary (see
In an exemplary exclusion embodiment, the claims system 100 can create/generate an exclusions table (e.g., COMPARE_EXCLUSIONS table) as a table in the dictionary. Similar to the COMPARE_INCLUSIONS table, the COMPARE_EXCLUSIONS table can be used to define circumstances in which cases should not be created/generated even though a claims processing rule would ordinarily do so. The COMPARE_EXCLUSIONS table can the define field positions, the field names, the field types, the key values, the field sizes, and/or the like. The keys allow each rule to have 1-n exclusions per rule. The first field (Key1) can be a unique number assigned to each row. The second field (Key2) can be the name of the rule associated with the corresponding entry. These two keys allow the claims system 100 to reference the table when executing a claims processing rule to determine whether any entries exist in the table for a given rule. In one embodiment, the third, fifth, seventh, and ninth fields (Lookup1, Lookup3, Lookup5, and Lookup7) can be data fields or name fields. And the fourth, sixth, eighth, and tenth fields (Lookup2, Lookup4, Lookup6, and Lookup8) can be the exclusion requirement(s) for the corresponding claims processing rule. Additional fields may also be used, such as date ranges, member restrictions, and/or the like.
As will be recognized, either an exclusions table (exclude with equals) or an inclusions table (include with not equals) can be used to accomplish a similar objective. For instance, as shown in
In an exemplary decision embodiment, the claims system can create/generate a decision table (e.g., COMPARE_DECISIONS table) as a table in the dictionary. The COMPARE_DECISIONS table can be used to define circumstances in which cases should either (1) not be created/generated even though a claims processing rule would ordinarily do so or (2) be created/generated (or considered further for creating/generating cases) even though a claims processing rule would not ordinarily do so. The COMPARE_DECISIONS table can define field positions, the field names, the field types, the key values, the field sizes, and/or the like. The keys allow each rule to have 1-n decisions per rule. The first field (Key1) can be a unique number assigned to each row. The second field (Key2) can be the name of the rule associated with the corresponding entry. These two keys allow the claims system 100 to reference the table when executing a claims processing rule to determine whether any entries exist in the table for a given rule. In one embodiment, the third, fifth, seventh, and ninth fields (Lookup1, Lookup3, Lookup5, and Lookup7) can be data fields or name fields. And the fourth, sixth, eighth, and tenth fields (Lookup2, Lookup4, Lookup6, and Lookup8) can be the decision requirement(s) for the corresponding claims processing rule. Additional fields may also be used, such as a decision field that can be populated with a “1” or “2,” for instance. Thus, if a current claim line and any support claim line satisfy the requirements of an entry in the COMPARE_DECISIONS table, the claims system 100 can determine how to handle the lines based on the decision field value. For instance, if the decision field is populated with a “1” or a value that represents “exclude,” then the claims system 100 can exclude a case from being created/generated for the current line and the corresponding support line(s) or exclude the line further to determine whether to create/generate a case—as described above and below with regard to the COMPARE_EXCLUSIONS table. Similarly, if the decision field is populated with a “2” or a value that represents “include,” then the claims system 100 can create/generate a case for the current line and the corresponding support line(s) or consider the line further to determine whether to create/generate a case—as described above with regard to the COMPARE_INCLUSIONS table. Similarly, if the decision field is populated with another value other than the one for include or exclude, then the claims system 100 can determine how to act upon that claim line/support line combination.
As also shown in these figures, this particular entry requires three lookups. The first lookup (Lookup1) requires access to a line procedure code in the claim (Line_ProcCode). The inclusion requirement for this lookup (Lookup2) requires that the current claim line procedure code be line procedure code 11000: C;VAL;=;11000. The second lookup (Lookup3) also requires access to a line procedure code in the claim (Line_ProcCode). The inclusion requirement for this lookup (Lookup4) requires that a support claim line's Line_ProcCode being considered with the current claim line be line procedure code 99215: S;VAL;=;99215. And the third lookup (Lookup5) requires access to the current claim line's line of business for the claim (Claim_LineofBusiness). The inclusion requirement for this lookup (Lookup6) requires that the line of business for the current claim be non-Medicare: C;VAL;!=;MCARE. Thus, this entry will be to create/generate (or consider further for creating/generating) a case when the current claim line with line procedure codes 11000 and Claim LineofBusiness code note equal to (!=) MCARE (Medicare Member) and the support claim line with procedure code 99215 when considered together when being processed in accordance with the UNBUN_PAIRS rule. The various entries in the table can be used to create any number and types of inclusions to adapt to various needs and circumstances, where at least one entry is for the current claim line and one entry is for a support line or the entry is for both lines.
In operation, after the claims system 100 receives a claim, the claims system 100 can process the claim on a line-by-line basis—one claims processing rule at a time (Block 305 of
Continuing with the above inclusions example, the claims system 100 can process the claim submitted with four lines using distinct line procedure codes: line procedure code 99215; line procedure code 11000; line procedure code 73590; and line procedure code A6542. In the appropriate firing order, the claims system 100 can reach the UNBUN_PAIRS claims processing rule and apply it to the claim. As part of applying the rule, the claims system 100 can reference the COMPARE_INCLUSIONS table to determine if there are any entries for UNBUN_PAIRS rule. In this example, there are nine entries for UNBUN_PAIRS rule: (1) Key1: 1 and Key2: UNBUN_PAIRS; (2) Key1: 2 and Key2: UNBUN_PAIRS; (3) Key1: 3 and Key2: UNBUN_PAIRS; (4) Key1: 4 and Key2: UNBUN_PAIRS; (5) Key1: 6 and Key2: UNBUN_PAIRS; (6) Key1: 7 and Key2: UNBUN_PAIRS; (7) Key1: 8 and Key2: UNBUN_PAIRS; (8) Key1: 9 and Key2: UNBUN_PAIRS; and (9) Key1: 10 and Key2: UNBUN_PAIRS.
Then, the claims system 100 can determine whether the claims lines satisfy the requirements of any of these entries—starting with the first entry in the table and working its way down the entries in Key1 order. For each entry, the claims system 100 can evaluate the first line of the claim (line procedure code 99215) as being the current claim line and use the appropriate support claim lines defined by the UNBUN_PAIRS rule. Because the UNBUN_PAIRS rule only examines lines from the same member on the same date of service from the same provider, the claims system 100 could potentially evaluate each line of the claim against every other line. In this example, the claims system 100 would first evaluate line procedure code 99215 as the current claim line and line procedure code 11000 as the support claim line. If the requirements for the first entry are met, the claims system 100 creates/generates (or considers further for creating/generating) a case for the combination of lines. If the requirements for the entry are not met by the lines, the claims system 100 would then evaluate the two lines in accordance with the next relevant entry in the table Key1=“2” and work its way down.
If the requirements for the nine relevant entries are not met, the claims system 100 would then evaluate line procedure code 11000 as the current claim line and every other line in turn as a support claim line. Thus, in this iteration, the claims system 100 would evaluate line procedure code 11000 as the current claim line and line procedure code 99215 as the support claim line. The claims system 100 would then determine whether the lines satisfy the requirements of the first entry (Key1: 1 and Key2: UNBUN_PAIRS). In this case, the current claim line (line procedure code 11000) would satisfy the first requirement: C;VAL;=;11000. Further, the support claim line (line procedure code 99215) would satisfy the second requirement: C;VAL;=;99215. Thus, if this were a non-Medicare claim (C;VAL;!=;MCARE), the claims system 100 would create/generate a case or consider further for creating/generating a case for this combination of lines. If this were a Medicare claim with the Claim_LineOfBusiness value equal to MCARE, then it would not match the entry in the COMPARE_INCLUSION table and it could either create/generate a case or be considered further for creating/generating a case. If performed as a preprocessing step, the claims system 100 can then continue applying the UNBUN_PAIRS rule.
In various embodiments, the described techniques and approaches can provide for an inexpensive, responsive, and precise way for customizing claims processing rules through a data-driven method. In various embodiments, this allows changes to claims processing rules to be updated in an efficient manner. As will be recognized, other approaches and techniques can be used to adapt to various needs and circumstance. For example, similar processes could be used for implementing an exclusions table (e.g., COMPARE_EXCLUSIONS table) and/or a decision table (e.g., COMPARE_DECISIONS table).
Many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the inventions are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
This application is a continuation-in-part of U.S. patent application Ser. No. 13/435,119, filed on Mar. 30, 2012, which is hereby incorporated herein in its entirety by reference.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13435119 | Mar 2012 | US |
| Child | 13444153 | US |
