Patent Application
20170286606
In various industries, businesses often enter into contracts with each other that dictate pricing for the provision of goods and/or services to each other or to third parties. For example, one company (e.g., a service provider) may contractually agree to provide services to a third party (e.g., a consumer) according to a fixed rate schedule, where certain types of services have certain negotiated pricing. Another company (e.g., a payor) may contractually agree to pay for the services rendered by the service provider company to the third party at the negotiated rate. The pricing may vary depending on the contract terms, the third party to whom the goods or services are being rendered, the type of goods or services rendered, and various other factors.
When goods or services are provided in such a scenario, payment must be rendered to the provider according to the terms of the contract between the provider, the payor, and/or the third party recipient of the goods or services. Contracts may vary, and the third party and/or the payor may often require an indication as to the amount that it will be required to pay to the provider for the goods or services rendered.
Accordingly, embodiments of the invention described herein provide improved apparatuses, methods, and computer program products for customized pricing of claims for reimbursement.
In particular, an application for use by a provider and/or a payor is provided that allows the user to define and/or modify a payment methodology for processing claims for reimbursement such that the payment can correspond with a particular contract for payment via a more intuitive and easy-to-use graphical user interface that allows the user to select from a number of predefined code portions. In this way, changes or updates to contract pricing may be more easily accommodated and implemented, and the requestor of payment information for goods or services rendered (e.g., the payor or the recipient) may be able to obtain up-to-date and accurate pricing information before or after the provision of the goods or services.
Accordingly, in some embodiments, a pricing engine core is provided that comprises at least one non-transitory computer-readable storage medium having computer-executable program code portions stored therein. The computer-executable program code portions comprises program code instructions for: receiving claim data comprising details of a claim for reimbursement; accessing a rate schedule, wherein the rate schedule comprises a codified representation of financial terms from a contract used to price the claim, wherein the rate schedule includes product data for one or more products; receiving selection of a product; and determining pricing of the claim for reimbursement based on the rate schedule accessed and the product selected.
Determining pricing of the claim may comprise accessing the product data of the rate schedule, iterating over and executing a list of active service categories based on the product data accessed from the rate schedule, wherein each service category specifies one or more service category criteria, and determining the matching service category of the claim by comparing each service category criteria of a respective service category to the claim data, wherein the matching service category determined further comprises one or more service groups and wherein each service group comprises service group criteria. Determining the pricing may further comprise executing the service group criteria for at least one of the service groups of the service category determined against the claim data to select an appropriate service group for the claim, determining a list of payment methodologies from the service group selected for the claim, and executing at least one of the payment methodologies determined to price the claim for reimbursement. The claim data may, in some cases, further comprise information provided by a payor relevant to the claim for reimbursement.
In some embodiments, a plurality of appropriate service groups may be selected via execution of the service group criteria, and determining the list of payment methodologies may further comprise determining a list of payment methodologies from each service group selected for the claim. Executing at least one of the payment methodologies determined may further comprise executing at least one of the payment methodologies determined for each service group selected to price the claim for reimbursement.
The computer-executable program code portions may, in some embodiments, further comprise program code instructions for compiling executable components of the rate schedule accessed, wherein the compiled code is used to determine pricing of the claim for reimbursement. Additionally or alternatively, the computer-executable program code portions may further comprise program code instructions for outputting to a user a priced claim for reimbursement and an explanation of components of the rate schedule accessed that is used to price the claim. In some cases, the computer-executable program code portions may further comprise program code instructions for outputting to the user an explanation of pricing for each line of the priced claim for reimbursement. Moreover, in some embodiments, the program code instructions for executing at least one of the payment methodologies determined to price the claim for reimbursement may further comprise program code instructions for determining line level pricing within a claim level pricing scheme.
In other embodiments, a computer-implemented method and/or computer program product are provided for developing a rate schedule for pricing claims for reimbursement within a claim pricing software application presented in a graphical user interface. The method and computer program product include providing for display of a first screen comprising an input field within a graphical user interface; receiving input from a user via the input field of the first screen comprising data identifying a rate schedule to be used for pricing a claim; receiving a selection from the user of a product; receiving a selection from the user of a service category of the claim; and providing for display of a second screen comprising an input field within the graphical user interface, wherein the input field of the second screen is configured to receive input from the user of criteria to be associated with the selected service category. The method and computer program product further include receiving selection from the user of a service group for the selected service category; providing for display of a third screen comprising an input field within the graphical user interface based on the service group selected; and receiving input from the user via the input field of the third screen defining a payment methodology of the claims, wherein the input from the user comprises selection of predefined code portions to define a customized payment methodology for pricing the claim and/or user-defined payment methodology.
In some cases, the predefined code portions may comprise portions of predefined domain specific language code that are independently selectable by the user. The predefined code portions may be displayed in a predefined area of the third screen for selection by the user, and selection of a predefined code portion from the predefined area may serve to populate the input field of the third screen with the selected predefined code portion. The predefined code portions may be combinable by the user to create a payment methodology capable of determining line level pricing within a claim level pricing scheme.
In some embodiments, the computer-implemented method and computer program product may further comprise receiving in a library a user-defined payment criterion for defining the payment methodology. The user-defined payment criterion may be stored in a library and may be accessible as a predefined code portion via at least one of the first screen, the second screen, the third screen, or a fourth screen of the graphical user interface for subsequent selections by the user for defining the payment methodology. The service group selected may be associated with a claim level pricing scheme or a line level pricing scheme.
In other embodiments, an apparatus is provided for pricing claims for reimbursement within a claim pricing software application presented in a graphical user interface. The apparatus comprises at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the processor, cause the apparatus to at least provide for display of a first screen comprising an input field within a graphical user interface; receive input from a user via the input field of the first screen comprising data identifying a rate schedule to be used for pricing a claim; receive a selection from the user of a product; receive a selection from the user of a service category of the claim; and provide for display of a second screen comprising an input field within the graphical user interface, wherein the input field of the second screen is configured to receive input from the user of criteria to be associated with the selected service category. The at least one memory and the computer program code are also configured to, with the processor, cause the apparatus to receive selection from the user of a service group for the selected service category; provide for display of a third screen comprising an input field within the graphical user interface based on the service group selected; and receive input from the user via the input field of the third screen defining a payment methodology of the claims, wherein the input from the user comprises selection of predefined code portions to define a customized payment methodology for pricing the claim.
In some cases, the predefined code portions may comprise portions of predefined domain specific language code that are independently selectable by the user. The predefined code portions may be displayed in a predefined area of the third screen for selection by the user, and selection of a predefined code portion from the predefined area may serve to populate the input field of the third screen with the selected predefined code portion. The predefined code portions may be combinable by the user to create a payment methodology capable of determining line level pricing within a claim level pricing scheme.
The at least one memory and the computer program code, in some cases, may be further configured to, with the processor, cause the apparatus to receive, via at least one of the first screen, the second screen, the third screen, or a fourth screen of the graphical user interface, a user-defined payment criterion for defining the payment methodology. The user-defined payment criterion may be stored as a predefined code portion for subsequent selections by the user for defining the payment methodology.
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:
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 invention are shown. Indeed, embodiments of this invention 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. Like reference numerals refer to like elements throughout.
Although the description that follows may include examples in which embodiments of the invention are used in the context of healthcare insurance claims by users at healthcare-related organizations, such as hospitals, pharmacies, and medical insurance companies, it is understood that embodiments of the invention may be applied to software applications used in numerous settings, including for other types of claims for reimbursement and by organizations outside the field of healthcare.
Software applications are generally used to help businesses in every sector carry out their operations. In scenarios where businesses enter into contracts with each other and with consumers, such as with respect to payment schemes for the provision of certain goods and services as described above, software applications may be used to determine pricing of those goods and services according to contracted rates.
In the context of healthcare, as an example, a healthcare provider (e.g., a doctor or hospital system) may enter into a contract with a medical insurance company, under which the medical insurance company (the payor) agrees to reimburse claims made by recipients (e.g., insured individuals) of medical goods or services (collectively, “services”) rendered by the healthcare provider. The terms of the contract may determine what types of services are covered by the contract, the settings in which they may be rendered (e.g., inpatient or outpatient), who may render the services (e.g., which doctors or hospitals), a negotiated price for the services, and so on.
As market and regulatory forces hasten the healthcare industry's journey to value-based care, payors are increasingly being tasked to support a complex, ever-changing mix of fee-for-service (FFS) and value-based reimbursement (VBR) payment models. Conventional software applications, systems, and tools for pricing claims are generally fixed and do not easily accommodate changes in payment methodologies that may occur due to modifications in pricing contracts or reimbursement innovations. Thus, using conventional claim pricing and reimbursement applications, a change in a claim pricing methodology based on a new or modified contract term, for example, may require costly custom configurations that require access to and high-level knowledge of the programming behind the claim pricing and reimbursement tool, and manual claim review and pricing are often necessitated. Such work-arounds and manual processing many times result in payment errors, require re-work, mandate increased staffing requirements, provide limited or no payment transparency, and significantly limit the ability of an organization to efficiently implement and automate new payment methodologies in the market.
As an example, some mainstream conventional claim pricing software applications are limited in their ability to allow a user to create complex service qualifiers that are used to determine claim pricing. Such applications may require complex implementation and pricing setup, and users may be required to access multiple applications to define pricing rules. In some cases, for example, users may need to use pointer IDs and cryptic pricing logic that includes non-intuitive acronyms to code pricing rules. Moreover, there may be limited multi-procedure payment reduction logic involved that is not able to make use of complex service qualifiers. The pricing under such conventional systems may be “canned” pricing that does not allow for the creation of new payment methodologies, and users may be required to upgrade their software (often at a cost) to receive new pricing rules or functionality. Such conventional claim pricing software applications thus provide little or no flexibility with respect to creating fee schedules and pricing tables, as the user has limited or no access to the claim data used in pricing.
Accordingly, embodiments of the present invention provide pricing engines, computer-implemented methods, apparatuses, and computer program products for pricing claims, such as healthcare claims, within a claim pricing application presented in a graphical user interface that address the complexities and limitations of the conventional solutions addressed above. In particular, embodiments of the invention provide a hierarchical structure and design of a rate schedule that is based on representing the financial arrangement outlined in a contract between a healthcare provider and insurance payor in a more straightforward manner that allows for certain elements to be compiled and executed by the pricing engine. Embodiments of the invention thus provide a claim pricing and reimbursement tool that is capable of supporting new complexities and developments in payor-provider relationships by using a rate schedule layout that is tailored to reflect the financial arrangement in a contract and a library of pricing components that can be easily configured by a user based on how the user's organization conducts business. In this way, embodiments of the invention offer the flexibility and scale to meet the ever-changing demands of the market.
As described in greater detail below, embodiments of the computer-implemented methods, apparatuses, and computer program products use intelligent business logic that includes customizable elements such as fee schedules, rate parameters, claim and non-claim data elements, and allow for the invocation of code written in a variety of payment methodology languages that can be used to calculate the contracted amount for reimbursing a claim. The embodiments described herein thus enable payment transparency and accuracy using auditing and validation tools, which offer agility that promotes innovation and automation to scale while reducing the total cost of ownership and increases speed to market of the software application.
In particular, embodiments of the invention described herein conform to the way contracts are structured; provide a mechanism for building out that structure in a user-friendly manner; use domain specific language (DSL) to facilitate claim pricing in the field of healthcare; allow users to create new payment methodologies via the DSL; allow users the ability to compile rate schedules into executable code that makes the pricing of claims more efficient than in conventional systems; allow users to configure the system to use local aliases to represent claim elements; and allow users to load fee schedules in any format, as dictated by the user's rules with support from the DSL.
With reference now to
In some embodiments, the apparatus 10 may comprise at least one processor 20, which may be embodied in a number of different ways. For example, the processor 20 may be a coprocessor, a microprocessor, a controller, or various other processing circuitry including integrated circuits. In some embodiments, the processor 20 may include one or more processing cores configured to perform independently. Additionally or alternatively, the processor 20 may include one or more processors configured in tandem via a bus to enable independent execution of instructions, pipelining and/or multithreading.
The apparatus 10 may further comprise at least one memory 30, and the processor 20 may be configured to execute instructions stored in the memory 30 or that are otherwise accessible to the processor. In embodiments in which the processor is embodied as an executor of software instructions, the instructions may specifically configure the processor to perform the algorithms and/or operations described herein when the instructions are executed. The memory 30, which may include volatile memory, such as volatile Random Access Memory (RAM) and/or non-volatile memory, may store any of a number of pieces of information and data, including software programs, libraries, databases, applications, repositories of data, files, etc. that are used by the apparatus 10 to implement the functions described herein. A memory 30 storing various types of data according to one embodiment is illustrated in
With continued reference to
Referring to
The system of
The software application may be accessed from the server 100 by a user via the respective payor device 120 or provider device 130 at a respective user site (e.g., an insurance claim processing center or a hospital), and the software application may run on the payor device 120 or the provider device 130 or may otherwise generate a user interface that is presented at the respective device such that the user is able to view and interact with data presented at the respective user device. In this regard, the payor device 120 and/or the provider device 130 may be a computer, such as a laptop or a desktop computer, a tablet computer, or any other computing device comprising a display, a processor, and a memory, that a user can interact with to access, view, and manipulate data provided by the software application. For example, the user may, in some cases, access the software application through communication between the user device and the server 100 over the Internet or an intranet, such as via a webpage interface. The server 100 may in turn access data (such as edited rate schedule information) from the database 105 to execute functions requested via the payor and/or provider devices 120, 130.
In some embodiments, the claim pricing and reimbursement software application, as noted above, may comprise a software program (e.g., executable software consisting of compiled code that can run directly from a computer's operating system) that provides a specific group of functions to the user for, in the case of embodiments of the present invention, pricing claims and determining reimbursement amounts to be paid by the payor to a provider for services rendered to a recipient (e.g., a third party consumer of the services). The claim pricing and reimbursement software application may, in some cases, be structured as described in U.S. Pub. No. 2014/0278567 entitled “Determining Reimbursement Amounts Based on Reimbursement Models” and filed on Mar. 15, 2013, which is incorporated by reference herein.
With reference now to
The pricing engine core 160, in turn, may access an appropriate rate schedule 180 based on information provided in the claim data 170 (e.g., a code included in the claim data that identifies the correct rate schedule) for processing the claim. Rate schedules 180 may be described as a structured codified representation of all the financial terms from a contract that are used to price a claim. Each rate schedule 180 may in turn include product data 190 describing a contract product group or line of business typically used to associate a network of providers with a payor, such as an HMO (Health Maintenance Organization), PPO (Preferred Provider Organization), and so on. The rate schedule 180 identified in the claim data 170, which may be one of a plurality of active rate schedules that is available, may include information for a plurality of different products 190, and the appropriate product may be identified as part of the claim data 170, such as through the use of a product identifier in the claim data.
The pricing engine core 160 may use processing logic to determine pricing of the claim described by the claim data 170 based on the product data 190 found in the appropriate rate schedule 180 information that is accessed. A simplified processing logic flow diagram is illustrated in
Each service category 210 identified in the product data 190 may in turn specify multiple service category criteria. Each of the service category criteria may be evaluated against the claim data 170, and in cases in which the criteria match, additional claim data may be accessed and evaluated. In this regard, claim data 170 may be provided as header level fields or as line level fields, depending on whether the claim is to be priced using claim level pricing or line level pricing techniques, as specified by the service group. According to claim level pricing methods, the overall clam is priced based on a single service group match plus any applicable matching carve outs, where carve outs are specific medical services rendered to a member that are contracted for reimbursement separately from other services under certain conditions (e.g., implants, high-cost drugs, etc.). Thus, under claim level pricing, it is not necessary to evaluate individual lines of the claim in order to calculate the price; however, in some embodiments as described below, pricing at the line level is allowed in a claim level pricing calculation according to embodiments of the present invention. According to line level pricing methods, the claim is priced based on a consideration and pricing of each line. Thus, although a line may be priced at $0, each line must nonetheless be priced to consider the overall claim successfully priced.
As service category criteria is evaluated against the claim data 170 (to determine the service category of the claim), if the criteria match, then it is determined whether a claim match date is a header level field. If this is the case and the corresponding claim header date field value is within the Service Category Effective From/Thru range, then the service category is selected and the analysis continues to the service group level. If the claim match data is a line level field and the corresponding claim line date field value is within the Service Category Effective From/Thru range for all lines, the service category is selected and the analysis proceeds to service groups. If no service category is selected for any reason, then the claim is pended.
Next down on the hierarchy of processing logic in
For each claim level service group specified in the selected service category (e.g., a service group that is to be priced using claim level pricing), the service group criteria for that service group is executed against the claim data 170 to identify the appropriate service group for the claim. The execution of the service group criteria may include iterating over each line in the claim and/or evaluating the criteria against the combination of claim header fields and current claim line fields. If the criteria match for the given service group, a list of carve outs that apply to the selected service group is retrieved and processed. The carve outs may be evaluated using line level processing techniques, for example. As such, the service group criteria may be executed within the compiled code (e.g., the compiled rate schedule).
A list of payment methodologies 230 may then be determined from the service group selected for the claim (e.g., where the list of payment methodologies is retrieved from the selected service group). A payment methodology 230 may be described as the payment logic necessary to calculate reimbursement for a specific service as outlined in the contract between the provider and the payor. Examples may include “Per Diem,” “Case Rate,” “Percent of Billed Charges,” etc. Each payment methodology 230 may be executed, such as by stepping through the payment logic of the given payment methodology to price the claim. In some cases, the claim may be priced by assigning a total allowed amount to the claim, whereas alternatively or additionally individual lines of the claim may be assigned a line allowed amount. Any errors encountered while stepping through the payment methodology may serve to pend the claim. The group pricing may thus be calculated as being equal to the total allowed amount plus the sum of all line allowed amounts. Moreover, if carve outs are priced, they would be included in separate groups and added to the overall allowed amount for the claim.
If there are no claim level service groups in the rate schedule that match the claim data, then the claim may be priced using line level pricing. Accordingly, a list of line level service groups may be retrieved from the matching service category, and for each line level service group the service group criteria may be evaluated against all remaining unpriced lines of the claim. For each line of the claim data 170 that matches the service group criteria, the line is tested to ensure that the line is unpriced. If the line is indeed unpriced, the payment methodology 230 for the service group is retrieved and evaluated for the given line (e.g., by stepping through the payment logic for a line and assigning a line allowed amount value). If the line has already been priced by a previous iteration, it would be skipped and the process would continue to the next matched line. The group price would be calculated as equal to the sum of all line allowed amounts priced under the given service group.
Once all line level service groups have been evaluated, if all of the lines have been priced, processing of the claim ends and the overall allowed amount for the claim will be the sum of all group prices. If, however, any unpriced lines of the claim data 170 remain, then those lines and the overall claim would be pended.
Accordingly, as described above with respect to
Each service category 210 may in turn be associated with one or more service groups 220, and each service group may include its own criteria expression defined in the same format as the respective service category 210, although different claim fields may be used. As noted above, a service group 220 may be categorized as a claim level service group, a line level service group, or a carve out. As such, a plurality of appropriate service groups may be selected via execution of the service group criteria, and determining the list of payment methodologies may comprise determining a list of payment methodologies from each service group selected for the claim. At least one of the payment methodologies determined for each service group selected may be executed to price the claim for reimbursement.
In this regard, each service group 220 may include one or more payment methodologies 230, and each payment methodology may include payment criteria written as an executable block of DSL code, as described above. Domain-specific language (DSL) may be defined as an extension of certain basic general purpose language operations and may allow the user to write criteria based on referencing claim fields, code values, fee schedule names and columns that are imported into the system (such as via a user interface configured to receive inputs, as described below with reference to
In this regard, according to some embodiments, a user interface may be provided, as described below with reference to
The processing logic and hierarchy described above with respect to
In order to allow the pricing engine core 160 to process claim data 170 using a rate schedule 180, where the underlying contract or reimbursement methodology has been changed, embodiments of the present invention thus provide a graphical user interface that allows a user to create and/or modify a payment methodology 230 used in the processing logic of the pricing engine core 160. Examples of various screens of a graphical user interface 300 are illustrated in
Accordingly, embodiments of an apparatus for pricing claims for reimbursement within a claim pricing software application presented in a graphical user interface 300 (shown in
The first screen 310 may further include, in some embodiments, an area 330 comprising a listing of products 335 (e.g., insurance products, such as “commercial” versus “Medicare”), and the user may be able to view a listing of service categories 340 under each product, such as by clicking a product-level expand button 350. Each service category 340, in turn, may, in some embodiments, be expanded by clicking a service category-level expand button 360 to provide a list of claim level service groups 370 and carve out service groups 380, shown in
Accordingly, the at least one memory and the computer program code may be configured to, with the processor, cause the apparatus to receive input from the user via the input field 320 of the first screen 310 (
The apparatus may further be caused (via the processor) to provide for display of a third screen 510 comprising an input field 520 within the graphical user interface 300 based on the service group selected 525, as shown in
In some embodiments, the predefined code portions 540 may comprise portions of predefined code that are independently selectable by the user. For example, with reference to
For example, with reference to
In some embodiments, the user may also select claim header or claim line fields for use in creating the payment methodology. For example,
In some embodiments, the predefined code portions 540 may be combinable by the user to create a payment methodology capable of determining line level pricing within a claim level pricing scheme. For example, if a claim level service group 525 is selected by the user, a payment methodology may be created through selection of predefined code portions 540 that considers both claim level pricing and further evaluates individual lines of the claim, using a line-level pricing logic.
In some cases, in addition to receiving the user's selection of a predefined code portion 540 (such as from a list of predefined code portions displayed in a predefined area 570 in
Turning to
With reference to
Turning now to
Other screens and functionality of the graphical user interface may be provided according to embodiments of the present invention to allow the user of the system more flexibility to provide inputs, adjust parameters, and view information regarding claims to be priced for reimbursement, as well as already priced claims. In
Referring now to
Referring now to
In some embodiments, the predefined code portions comprise portions of predefined code that are independently selectable by the user, as described above, to create or modify an existing payment method. The predefined code portions may be displayed in a predefined area of the third screen for selection by the user, and selection of a predefined code portion from the predefined area may serve to populate the input field of the third screen with the selected predefined code portion to create or modify an existing payment method.
In some cases, the predefined code portions may be combinable by the user to create a payment methodology capable of determining line level pricing within a claim level pricing scheme. Moreover, in some embodiments, a user-defined payment criterion may be created and stored (e.g., in a Library) for future selection by the user via at least one of the first screen, the second screen, the third screen, or a fourth screen of the graphical user interface for defining the payment methodology. The user-defined payment criterion may thus be stored as a predefined code portion for subsequent selections by the user for defining the payment methodology.
Example embodiments of the present invention have been described above with reference to block diagrams and flowchart illustrations of methods, apparatuses, and computer program products. In some embodiments, certain ones of the operations above may be modified or further amplified as described below. Furthermore, in some embodiments, additional optional operations may be included. Modifications, additions, or amplifications to the operations above may be performed in any order and in any combination.
It will be understood that each operation, action, step and/or other types of functions shown in the diagrams (
For example, program code instructions associated with
The program code instructions stored on the programmable apparatus may also be stored in a non-transitory computer-readable storage medium that can direct a computer, a processor (such as processor 20) and/or other programmable apparatus to function in a particular manner to thereby generate a particular article of manufacture. The article of manufacture becomes a means for implementing the functions of the actions discussed in connection with, e.g.,
Accordingly, as described above and with respect to the figures, embodiments of the invention provide systems and methods for allowing users to price claims in a more intuitive, user-friendly manner, while still allowing claims to be priced efficiently with respect to processing power. Payment methodologies are written in a domain specific language that allows the user to develop rules for determining how a claim should be reimbursed. This domain specific language supports traditional programming concepts including the definition of temporary variables, mathematical and logical assignment expressions using these temporary variables and claim and claim line elements, flow of control expressions using logical expressions composed of temporary variables and claim and claim line elements, logical operators, and user specified values. The language also supports the invocation of predefined functions for the pricing of the claim without the need for the user to write code that examines multiple claim lines and/or skips lines that have already been priced within the pricing method. These functions are presented to the user via a user interface as described herein that allows the user to insert one of the predefined functions into the payment methodology code. This predefined list is filtered based on the context of the language statement being processed and the prefix of the function being typed by the user.
The domain specific languages thus allow users to utilize user-specific names to represent the claim and claim line elements. Furthermore, the user may specify the value sets (e.g., code values and descriptions) to be used for each of the claim elements, with warning provided when claim elements are used in a logical comparison, if the values used in the comparison are not part of the user specified value set for the user named claim element.
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.
There are numerous elements defined within the DSL offered by the product, best described as Variables and Functions. In addition to these custom elements, there are several standard Groovy operations supported.
Commented Text—Specify a comment using either // or /* */
Define a Variable—Use “def” to define your own variable within the criteria
For Loop—Use “for (e in list) {<statements operating on each element of list>}” to apply a set of logic over multiple elements
If/Else If/Else—Use standard “if”, “else if”, “else” conditional logic to apply certain statements based on matching conditions
And/Or/Not—Use “and”, “or”, “not” as abstraction for the typical operator syntax for this logic In—Use “in” with conditional logic validating the presence of code values for a claim field, allowing the user to specify a single value, list of values, range of values, and wildcarded values.
Switch Statement—Use standard “switch (variable) {case . . . default}” conditional logic to apply certain statements based on matching the given case
Usage: search lines using {condition}
This function allows to search a set of lines based on a condition.
Ex: search AllLines using {LineAllowedAmount>100} will return those lines whose LineAllowedAmount is greater than 100.
Usage: evaluate lines using {payment-block} OR evaluate line using {payment-block}
This function executes the payment-block for given line(s).
Note: If a line is already priced by a different service group than the current service group then that line will be ignored for re-pricing by this function.
Ex: evaluate UnmatchedLines using {LineAllowedAmount=200} will price all unmatched lines with amount of 200.
Usage: lookup columnName1, columnValue1, columnName2, columnValue2 . . . using FeeScheduleName
This function will try to match an active Fee Schedule whose name matches the given FeeScheduleName and whose column names and values matches the given columnName*, columnValue* pairs. At most one columnValue* reference may be a list, for which the lookup will return a row based on the first matching value encountered in the list. It also verifies if the claim match date falls within the Effective and Expiration dates of the Fee Schedule. If matched, it returns the matched Fee Schedule row as Map with columnName as key and columnValue as value.
Usage: sortAsc(lines, {variable1}, {variable2}, {variable3} . . . ) OR sortDesc(lines, {variable1}, {variable2}, {variable3} . . . )
This function returns lines which are sorted by the provided variables either ascending or descending. First variable will be used for sorting and other variables will be used when there are conflicts to sort.
Note: These functions will return empty list if empty lines are provided.
Ex: sortAsc(AllLines, {LineAllowedAmount}, {LineBilledCharges}) will sort all claim lines based on LineAllowedAmount and LineBilledCharges in ascending order.
Usage: groupAsc(lines, {variable1}, {variable2}, {variable3} . . . ) OR groupDesc(lines, {variable1}, {variable2}, {variable3} . . . ) This function groups given lines whose variables has same value and returns a List of grouped lines.
Note: These functions will return empty list if empty lines are provided.
Ex: groupAsc(AllLines, {LineAllowedAmount}, {LineBilledCharges}) will first sort given lines in ascending order and then group lines whose LineAllowedAmount and LineBilledCharges are same.
Usage: sum(lines, {variable})
This function returns the sum of variables for all the lines.
Note: This function returns 0 if empty lines are provided.
Ex: sum(AllLines, {LineAllowedAmount}) will return sum of LineAllowedAmount for all lines.
Usage: count(lines)
This function returns the total number of given lines.
Ex: count(AllLines) will return total number of lines.
Usage: duration(fromDate, toDate, type)
This function returns the duration(number of days or years) between from and to dates. The returned value depends on the given type(“days”, “years”).
Usage: duration(startDate, endDate, startHour, endHour)
This function returns the duration in hours between start and end date/times.
Usage: diagnosisPOA(codeValue, POAValue)
This function returns true if the specified diagnosis code value and POA value are found together within the set of diagnosis/POA codes on the claim header, otherwise it returns false.
Ex: diagnosisPOA(“K9501”,“N”) will return true if the claim header Diagnosis code list has value “K9501” with its POA set to “N” otherwise it will return false.
Usage: round(value, scale, direction)
This function rounds a value to the specified number of decimal places based either on default rounding logic or the specified direction. The optional direction argument can specify to always round up or always round down, otherwise default rounding logic will round up or down to the nearest neighbor or up if both neighbors are equidistant.
This application claims the benefit of U.S. Provisional Application No. 62/316,296 entitled “Apparatuses, Methods, and Computer Program Products for Customized Pricing of Claims for Reimbursement,” filed Mar. 31, 2016, the contents of which are incorporated herein in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62316296 | Mar 2016 | US |
