US20200372467A1

US20200372467A1 - Medical claim database relationship processing

Info

Publication number: US20200372467A1
Application number: US16/988,486
Authority: US
Inventors: Yoram S. Levy
Original assignee: Sunbelt Medical Management LLC
Current assignee: Sunbelt Medical Management LLC
Priority date: 2018-02-07
Filing date: 2020-08-07
Publication date: 2020-11-26
Also published as: US10565660B2; WO2019157199A2; WO2019157199A3; US20190244302A1

Abstract

A method for data processing of remotely collected medical claims billing data collects medical claim data and insurance claim processing data from remote databases over a network system. A plurality of visual dashboards on a computerized graphical user interface of a plurality of user computers are connected to a server for viewing a claims worklist generated from the medical claim data and the insurance claim processing data. At least one claim is requested from the claims worklist using the visual dashboard of the computerized graphical user interface of at least one of the plurality of user computers. An action is executed on the at least one claim using the at least one of the plurality of user computers, wherein the action comprises transmission of claim action data to the at least one remote insurance database using the network system.

Description

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation-in-part bypass application of PCT Patent Application Serial No. PCT/US19/17082 entitled, “Medical Claim Database Relationship Processing” filed Feb. 7, 2019 and claims benefit of U.S. Provisional Application Ser. No. 62/627,483 titled “Systems and Methods for Medical Claim Database Processing,” filed Feb. 7, 2018, the entire disclosures of which are incorporated herein by reference. U.S. patent application Ser. No. 16/270,346, now U.S. Pat. No. 10,565,660, entitled, “Medical Claim Database Relationship Processing” and filed Feb. 7, 2019, also claims benefit of U.S. Provisional Application Ser. No. 62/627,483, the entire disclosures of which are incorporated herein by reference.

FIELD OF THE DISCLOSURE

The present disclosure is generally related to database processing and more particularly is related to processing medical claims across databases for billing.

BACKGROUND OF THE DISCLOSURE

Medical billing in today's age can be complex for numerous reasons, one of which is the use of a multi-payer system where insurance companies are responsible for a portion of the costs for a patient and the patient is responsible for the remainder. When a medical claim or bill is issued, it is frequently coded with the proper medical billing codes and then it is sent to the patient's insurance company for review and processing. If there is an error in the medical coding, or if there is another issue with the bill, the insurance company may deny coverage. When this occurs, the medical office issuing the bill or the patient may need to contact the insurance company and determine why coverage was rejected and find out how to correct the bill. Due to the high volume of medical bills in insurance company processing departments, it can take an undesirable amount of time on the phone with a claims representative of the insurance company to identify the problem and correct it.
Because of the complexity and inefficiencies in this process, medical offices often rely on medical claims management companies to manage their billing and coordinate with the insurance companies for unpaid claims. The medical offices provide the medical claims management companies with their outstanding bills and the medical claims management companies call the insurance companies to identify the reason for the unpaid bill. Due to the high volume of claims, however, the insurance companies often limit the number of medical claims that can be discussed during one phone call. And, in many instances there is a wait time to speak to a representative at the insurance company, so it may only be possible for an employee at the medical claims management company to make 2-4 calls per hour. Thus, there is a practical ceiling of productivity for resolving unpaid medical claims.
Moreover, the inefficiency with this process is further complicated by the fact that medical claims are time sensitive. If the claim is not properly submitted to the insurance company within a certain period of time, commonly 90 days, the insurer can refuse to pay the claim. Similarly, medical claims are naturally for various monetary amounts, and the higher amounts are often more important to process than lower amounts. For example, given a claim for $30 and a claim for $3,000, both of which are nearing the end of the time period for processing, the medical office would certainly desire to process the larger claim first. However, it can be difficult to organize and manage the claims in such a way to handle the most important claims first, namely due to the lack of a management system for instructing the personnel at the medical claims management company which claims to process first.
Thus, for at least these reasons, a heretofore unaddressed need exists in the industry to address the aforementioned deficiencies and inadequacies.

SUMMARY OF THE DISCLOSURE

Embodiments of the present disclosure provide a system for data processing of remotely collected medical claims billing data using a computerized system having a processor and a non-transitory memory. Briefly described, in architecture, one embodiment of the system can be implemented as follows. The system includes a plurality of billing computer devices having a processor and non-transitory computer-readable memory. A server has a processor and non-transitory computer-readable memory, the server being accessible over at least one network system by the plurality of billing computer devices. A relational, subject-oriented database contains multi-field medical claim data, wherein the multi-field medical claim data is electronically collected on the server over at least one electronic network system, the multi-field medical claim data having been submitted to a payer entity, wherein the multi-field medical claim data has at least an external claim identifier. At least one remote insurance database contains multi-field insurance claim processing data, wherein the multi-field insurance claim processing data is electronically collected on the server over the at least one electronic network system, wherein the multi-field insurance claim processing data is correlated to the multi-field medical claim data based on the external claim identifier. A billing management application is running at least partially on the server and accessible by the plurality of billing computer devices, wherein each of the plurality of billing computer devices has a visual dashboard on a computerized graphical user interface which is connected to the server for viewing a claims worklist generated from the collected multi-field medical claim data and the collected multi-field insurance claim processing data, wherein each of the plurality of visual dashboards viewable and interactable by a user, and wherein the billing management application: requests at least one claim from the claims worklist using the visual dashboard of the computerized graphical user interface of at least one of the plurality of user computers; and executes an action on the at least one claim using the at least one of the plurality of user computers, wherein the action comprises transmission of claim action data to the at least one remote insurance database using the at least one electronic network system.
Embodiments of the present disclosure provide a system and method for data processing of remotely collected medical claims billing data using a computerized system having a processor and a non-transitory memory. Briefly described, in architecture, one embodiment of the method, among others, can be implemented as follows. The method includes electronically collecting, on a server, multi-field medical claim data from a relational, subject-oriented database over at least one electronic network system, the multi-field medical claim data having been submitted to a payer entity, wherein the multi-field medical claim data has at least an external claim identifier; electronically collecting, on the server, multi-field insurance claim processing data from at least one remote insurance database over the at least one electronic network system, wherein the multi-field insurance claim processing data is correlated to the multi-field medical claim data based on the external claim identifier; providing a plurality of visual dashboards on a computerized graphical user interface of a plurality of user computers connected to the server for viewing a claims worklist generated from the collected multi-field medical claim data and the collected multi-field insurance claim processing data, each of the plurality of visual dashboards viewable and interactable by a user; requesting at least one claim from the claims worklist using the visual dashboard of the computerized graphical user interface of at least one of the plurality of user computers; and executing an action on the at least one claim using the at least one of the plurality of user computers, wherein the action comprises transmission of claim action data to the at least one remote insurance database using the at least one electronic network system.
Other systems, methods, features, and advantages of the present disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.

FIG. 1A is a box diagram of a system for medical claims billing management, in accordance with a first exemplary embodiment of the present disclosure.

FIG. 1B is a box diagram of a system for medical claims billing management, in accordance with a second exemplary embodiment of the present disclosure.

FIG. 2 is a flow chart showing a method for medical claims billing management using a computerized system, in accordance with a second exemplary embodiment of the present disclosure.

FIG. 3 shows a log-in page for a user of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 4 shows a worklist page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 5 shows a note menu of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 6 shows a skip menu of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 7 shows a worked claims dashboard of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 8 shows a progress dashboard of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 9 shows a management dashboard of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 10 shows a management navigation page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 11 shows a teams page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 12 shows a clients page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 13 shows an EMRs page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 14 shows a provider specialties page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 15A shows a worklists templates page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIGS. 15B-15D show worklist editing menus of the worklists page, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 16 shows a billers' clients page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 17 shows a billers page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 18 shows a saved worklists templates page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 19 shows a filter templates page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 20 shows a priority templates page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 21 shows a technical support page of the billing application, in accordance with the first exemplary embodiment of the present disclosure.

FIG. 22 is a flow chart illustrating an exemplary implementation of the method for medical claims billing management, in accordance with the second exemplary embodiment of the present disclosure.

FIG. 23 is a flow chart illustrating a method for processing relationships in a medical claims database, in accordance with a third exemplary embodiment of the present disclosure.

FIG. 24A is a box diagram of a system for medical claims billing management, in accordance with a fourth exemplary embodiment of the present disclosure.

FIG. 24B is a flowchart diagram of a system for medical claims billing management, in accordance with the fourth exemplary embodiment of the present disclosure.

FIG. 25 is another flow chart diagram of a method for medical claims billing management, in accordance with the fourth exemplary embodiment of the present disclosure.

FIGS. 26-33 are images of the visual interface of the billing management application used by the system for medical claims billing management, in accordance with the fourth exemplary embodiment of the present disclosure.

DETAILED DESCRIPTION

In the following description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown, by way of illustration, various embodiments of the present disclosure. It is understood that other embodiments may be utilized and changes may be made without departing from the scope of the present disclosure.
Many embodiments of the disclosure may take the form of computer-executable instructions, including algorithms executed by a programmable computer. However, the disclosure can be practiced with other computer system configurations as well. Certain aspects of the disclosure can be embodied in a special-purpose computer or data processor that is specifically programmed, configured or constructed to perform one or more of the computer-executable algorithms described below. Accordingly, the term “computer” as generally used herein refers to any data processor and includes Internet appliances, hand-held devices (including palm-top computers, wearable computers, cellular or mobile phones, multi-processor systems, processor-based or programmable consumer electronics, network computers, minicomputers) and the like.
The disclosure also can be practiced in distributed computing environments, where tasks or modules are performed by remote processing devices that are linked through a communications network. Moreover, the disclosure can be practiced in Internet-based or cloud computing environments, where shared resources, software and information may be provided to computers and other devices on demand. In a distributed computing environment, program modules or subroutines may be located in both local and remote memory storage devices. Aspects of the disclosure described below may be stored or distributed on computer-readable media, including magnetic and optically readable and removable computer disks, fixed magnetic disks, floppy disk drive, optical disk drive, magneto-optical disk drive, magnetic tape, hard-disk drive (HDD), solid state drive (SSD), compact flash or non-volatile memory, as well as distributed electronically over networks including the cloud. Data structures and transmissions of data particular to aspects of the disclosure are also encompassed within the scope of the disclosure.
FIG. 1A is a box diagram of a system 100 for medical claims billing management, in accordance with a first exemplary embodiment of the present disclosure. The system 100 includes at least one billing computer device 101, which has a processor and non-transitory computer-readable memory, a relational, subject-oriented electronic medical records (EMR) database 120 of a medical provider containing multi-field medical claim data, and a remote insurance database 130 containing multi-field insurance claim data corresponding to at least a portion of the medical claim data. The system 100 also includes a server 110 having a processor and non-transitory computer-readable memory. The server 110 is accessible over at least one network system by the billing computer device 101, the EMR database 120, and the insurance database 130. A billing management application 112 is hosted at least partially on the server 110. The billing management application 112 collects multi-field medical claim data from the EMR database 120 and retrieves multi-field insurance claim data from the insurance database 130. The billing management application 112 also provides a plurality of dashboards on a computerized graphical user interface for viewing the collected medical claim data and the retrieved insurance claim data, wherein each of the plurality of dashboards provides a prioritization of a handling of a portion of the medical claims data to a medical claim analyst, wherein the medical claim analyst communicates with an insurance provider associated with the portion of the medical claims data according to a schedule determined by the prioritization. Additionally, the billing management application 112 provides at least one manager view dashboard providing workflow data corresponding to the plurality of billing view dashboards. The billing view and management dashboards are discussed in greater detail in FIGS. 3-21.
The billing computer device 101 may be any electronic computer device capable of accessing the billing management application 112 or the EMR database 120, including personal computers, laptop computers, tablets, smartphones, and the like. By way of example, the billing computer device 101 is shown in FIG. 1A as a desktop computer. As also shown in FIG. 1A, the system 100 may include multiple billing computer devices 101 used by users 140 of the billing management application 112. Users 140 may be billers, medical office clients, managers, or administrators.
Multi-field medical claim data may be electronic data encompassing to two or more fields relevant to medical claims. For example, relevant data for a single medical claim may include a patient identifier, such as a name, plan number, or social security number, a claim date, a claim amount or balance, CPT codes, claim status information, medical provider information, insurance payer information, and the like. Each medical claim entry in the EMR database 120 may include a plurality of data fields, thus the medical claim data may be multi-field data. In this disclosure, a medical claim entry containing multiple data fields may be called “medical claim information” or “health-related information,” and any reference therein to “information” may be considered to include the multi-field medical claim data as discussed above. Likewise, multi-field insurance claim data may be electronic data encompassing two or more fields relevant to insurance claims. At least a portion of the fields may correspond to the medical claim data fields. In this disclosure, an insurance claim entry containing multiple data fields may be considered to be “insurance claim information.” In this capacity, any reference to information may be understood to pertain to electronic data.
The EMR database 120 contains an electronic record of health-related information on an individual within a health care organization. The EMR database 120 may be a relational, subject-oriented database or data warehouse system used for providing electronically accessible medical records, and may include components commonly used in databases, such as a power source, processor, computer-readable memory, a network connection, and the like. As a subject-oriented database, the EMR database 120 may be organized and structured around a subject, namely a medical claim or an individual, such as a patient. This database structure may allow multi-field data from one or more medical incidents or claims to be organized in relation to one another. As a relational database, the data stored within the EMR database 120 may be organized by relations according to categories of information. In one example, the EMR database 120 may be a distributed series of databases 120 containing electronic medical claim information. The distributed database may be a homogenous distributed database, having the same management systems across each node in the database. In another example, the billing management application 112 may connect to multiple different EMR databases 120 to provide comprehensive medical claims billing to a variety of clients. The EMR database 120 may also provide a software interface for users 140 to access medical claim information using a billing computer device 101. The billing management application 112 may work together with the EMR database 120 to accomplish the medical claims billing described herein.
Medical claim information may be stored on the EMR database 120. Medical claim information may include a patient's identifying information, medical history, and a record of medical services for which a medical office has submitted medical claims. The record may particularly include the monetary balance of claims, the date when the claim was made, and the insurance provider, or payer, the claim was made to. For example, the monetary balance may include an amount billed by a medical service provider, a negotiated amount agreed upon between a service provider and an insurance provider, or a remaining balance after a partial payment. The claim date may include the date when medical services were provided, the date when the claim was filed, or the date when the claim was updated. The insurance provider may include the name or unique identifier of the insurance provider. Medical claim information may also include a unique identifier for the claim, a patient identifier, a client identifier, a claim status, CPT codes, and other metadata helpful in processing a medical claim. For example, a unique identifier for the claim may be a name or number used as an internal reference in order to identify claims within the system. A patient identifier may be a name, patient number, or other identifying information regarding the patient who received the medical services. A client identifier may be a name, client number, or other identifying information used to identify the medical service provider seeking payment and processing of the medical claim. A claim status may indicate whether a medical claim is being processed, has been skipped, is reaching a particular age, or has a priority based on its monetary value, client, or other factors. CPT codes may refer to current procedural terminology codes used in medical billing to identify medical procedures in a standardized format. Other metadata may include the date when the claim was first processed in the system, the frequency with which the claim has been accessed, and the like.
The insurance database 130 may be any system commonly used for providing electronically accessible medical records, and may include components commonly used in databases, such as a power source, processor, computer-readable memory, a network connection, and the like. The insurance database 130 contains an electronic record of insurance claim information corresponding to at least a portion of the medical claim information. As an example, if an insurance company received a medical claim bill for a service performed by a medical office, the insurance company would keep a record of that medical claim bill in an insurance database 130. The insurance database 130 may also include information about the processing or payment status of the medical claim by the insurance company. For instance, if a medical claim has been completely processed and paid out, the insurance database 130 would include information reflecting that. If a medical claim is awaiting processing, the insurance database 130 would include information reflecting that. If a medical claim cannot be processed further because of an error or a dispute, the insurance database 130 would reflect that. Each insurance company may have one or more insurance databases 130 to store electronic records of insurance claim information.
The server 110 may be any system commonly used for hosting software programs, processing data, and communicating with other devices. The server 110 may include a processor and non-transitory computer-readable memory, along with other components commonly used in server devices. In particular, the server 110 may include a central database that can be used to store information retrieved from EMR databases 120 and insurance databases 130. The server is accessible by the billing computer device 101, the EMR database 120, and the insurance database 130 over at least one network system. The network system may be any interconnected network of the above devices, including over the Internet, Local Area Network (LAN), wireless connections such as WiFi, cellular networks, Bluetooth® and the like, and intranets.
A billing management application 112 (hereinafter “billing application 112”) is hosted at least partially on the server. The billing application 112 may access medical claim information on the EMR database 120 and insurance claim information on the insurance database 130, and copy and consolidate the medical claim information and insurance claim information into a single report or other document. The billing application 112 may access the EMR database 120 and insurance database 130 using the at least one network system and through an appropriate platform. In software, these functions may be performed through multiple software modules.
In one example, automated billing collector modules may be responsible for collecting medical claim information from one or more EMR databases 120 and feeding the information to the server 110. Each EMR database 120 may require a different collector module to interface with the database 120. In another example, the billing application 112 may use an Open Database Connectivity (ODBC) interface or other Application Programming Interface (API) to directly locate and copy the medical claim data in a number of different insurance databases 130. ODBC and API platforms may provide more robust access to a variety of databases. For example, the billing application 112 using an ODBC interface may use an ODBC driver to translate between the billing application 112 and the database management system (DBMS). The ODBC driver may automatically query the EMR database 120 for medical claim information using a standard query language. Other APIs may be directed to particular DBMS or database control protocols in order to query the EMR database 120 and collect data. In one example, the billing application 112 may use a combination of platforms.
In another example, manual billing collector modules may be responsible for collecting medical claim information from reports that were uploaded manually to the EMR database 120. Each EMR database 120 may require a different manual billing collector module to interface with the database 120.
In one example, the billing application 112 may use web scraping to access an EMR database 120 either locally or through a web portal, automatically navigating the database 120 and copying or exporting medical claim information into the database 120. Web scraping may include fetching a web page corresponding to a claim in the EMR database 112 and extracting data from data fields on the page. The data may be parsed to extract relevant claim information or reformatted to a standardized format for use within the system.
In another example, billing observer modules may be responsible for retrieving insurance claim information from one or more insurance databases 130 and feeding the information to the server 110. Each insurance database 130 may require a different billing observer module to interface with the database 130. Similar to the automated billing collector modules, the billing observer modules may access the insurance databases 130 through one or more methods such as web scraping, API, or ODBC interfaces. Relevant information may be copied to the server 110 for later use.
In another example, billing reporter modules may be responsible for reporting insurance claim information from the insurance database 130 to the EMR database 120. Each EMR database 120 may require a different billing reporter module to interface with the database 120. The billing reporter modules may report insurance claim information using API, ODBC, or any other database access and writing methods commonly used.
In another example, a central controller module may coordinate usage and implementation of all of the software modules in the billing application 112. This may include triggering the billing observer modules to obtain new or updated insurance claim information from the insurance databases 130 and triggering the billing reporter modules to report insurance claim information to the appropriate EMR database 120. This may also include triggering the automatic and manual collector modules to periodically query an appropriate EMR database 120 for medical claim information. Additionally, the central controller module may control a graphical user interface (GUI) to provide a platform for a user 140.
The GUI provides an interface for one or more users 140 to perform medical claim billing management using the system 100. In one example, client users 140 may use the GUI to see the status of pending claims. In another example, biller users 140 may use the GUI to sort and process medical claims according to a prioritization schedule determined by the billing application 112. In another example, administrative users 140 may use the GUI to monitor the work of billers processing claims in the system 100.
The billing application 112 may be accessed a number of different ways, including through a web portal, as a software program stored on the billing computer device 101, as a downloadable application, and the like. By way of example in FIG. 1A, the billing application 112 is accessed through a web portal using the Internet.
FIG. 1B is a box diagram of a system 100 for medical claims billing management, in accordance with a second exemplary embodiment of the present disclosure. In FIG. 1B, the billing computer devices 101 are not directly connected to the EMR databases 120, but instead are directly connected to the server 110 and the billing application 112. Users 140 may access the billing application 112 through a web portal, software program, or application on a billing computer device 101, which obtains all of the retrieved and collected medical claim information and insurance claim information stored on the server 110.
Prioritization Schedule
Once the billing application 112 has collected and retrieved the medical claim information and the corresponding insurance claim information, it may develop a prioritization schedule for processing any outstanding claims. The prioritization schedule may allow a client to process outstanding claims in an optimal manner, maximizing the number of claims processed, the dollar amount processed, the number of patients processed, or some combination thereof. In operation, the billing application 112 may prioritize claims according to various algorithms or schedules. For example, the system may have a standard prioritization algorithm which is used. However, the manager view may allow the manager to customize the prioritization by applying different weights to the various measures. For example, the standard algorithm to prioritize claims may be based on the balance outstanding combined with a multiplier based on the age of the claim. However, the manager may adjust the focus on specific aspects of the claims. For example, the manager may want to put even more focus on older claims, as opposed to, for example, claims with a high monetary value. In this instance they could add more weight to the age of the claim so that older claims would appear higher in the prioritized list even if their dollar amount was less than a younger claim.
Operating Example
The following operating examples may illustrate how the billing application 112 is used in implementation.
A client user 140 may use the system 100 to check the status of several claims pending for the client's medical office. The client may log into the billing application 112 using a billing computer device 101, entering identifying information such as the client's name and password, the medical office name, and information regarding the claims the client wants to check. The billing application 112 may authenticate the client and process the claim information using the automated or manual billing collector modules. The billing collector modules may verify that the claims are located in an EMR database 120, collecting any necessary claim information in the process and storing it on the server 110. A billing observer module may use relevant claim information to query an insurance database 130 for insurance claim information corresponding to the medical claim information, retrieving any relevant information, including status information, and storing it on the server 110. A billing reporter module may process the medical claim information and the insurance information together to provide a status update for the client user 140, reporting the status update to the EMR database 120 or via the GUI to the billing computer device 101. The client user 140 may view the status update, annotate particular claims, or use the billing application 112 to pursue certain claims further.
In another example, a biller user 140 may use the system 100 to receive a prioritization schedule for medical claims. The biller may log into the billing application 112 using a billing computer device 101, entering identifying information such as the biller's name and password, a client's name, and information regarding the claims the biller wants to work on. The billing application 112 may authenticate the biller and process the claim information using the automated or manual billing collector modules. The billing collector modules may verify that the claims are located in an EMR database 120, collecting any necessary claim information in the process and storing it on the server 110. A billing observer module may use relevant claim information to query an insurance database 130 for insurance claim information corresponding to the medical claim information, retrieving any relevant information and storing it on the server 110. A billing reporter module may process the medical claim information and the insurance information together, and the billing application 112 may use this information to generate a prioritized worklist for the biller. The biller may view and interact with the worklist using the GUI of the billing application 112. As the biller processes claims, they may be cleared or annotated in the billing application 112.
In another example, a manager or administrator user 140 may use the system 100 to monitor the work progress of one or more billers using the billing application. The manager may log into the billing application 112 using a billing computer device 101, entering identifying information such as the manager's name and password, a client's name, or information regarding the biller the manager wishes to monitor. The billing application 112 may authenticate the manager and direct them to a manager dashboard via the GUI. The manager may navigate through pages on the manager dashboard to monitor work by biller, client, teams of billers, and the like. The manager may create or adjust worklists, assigning tasks to one or more billers. The monitor may additionally view analytic reports regarding productivity and adjust worklists according to those reports.
The GUI of the billing application 112 may be better understood by way of the plurality of dashboards it provides. The plurality of dashboards is discussed in greater detail in FIGS. 3-21.
FIG. 2 is a flow chart 200 showing a method for medical claims billing management using a computerized system having a processor and non-transitory memory. It should be noted that any process descriptions or blocks in flow charts should be understood as representing modules, segments, or steps that include one or more instructions for implementing specific logical functions in the process, and alternate implementations are included within the scope of the present disclosure in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present disclosure.
In step 210, medical claim information is electronically collected from an electronic medical records (EMR) database of a medical provider. In step 220, insurance claim information is electronically retrieved from an insurance database, wherein the insurance claim information corresponds to at least a portion of the medical claim information.
In step 230, a plurality of dashboards is provided on a computerized graphical user interface for viewing the collected medical claim information and the retrieved insurance claim information. The plurality of dashboards comprises at least a plurality of billing view dashboards, each providing a prioritization of a handling of a portion of the medical claims information to a medical claim analyst. The medical claim analyst communicates with an insurance provider associated with the portion of the medical claims information according to a schedule determined by the prioritization. The plurality of dashboards also comprises at least one manager view dashboard providing workflow information corresponding to the plurality of billing view dashboards.
FIGS. 3-21 show graphical user interface views of the plurality of billing view dashboards and the at least one manager view dashboard. It should be understood that these figures represent exemplary implementations of the software dashboards, and that other implementations are included within the scope of this disclosure.
FIG. 3 shows a log-in page 300 for a user of the billing application 112. The log-in page 300 may contain form fields 310, 320 that can be filled in by a user. In one example, the form fields 310 may prompt the user to enter identifying and authenticating information, such as a username, password, company ID, access codes, and the like. In another example, the form fields 320 may prompt the user to prove they are human, such as by entering a CAPTCHA code, checking an “I′m not a robot” box, identifying visual information in images, and the like. In another example, the log-in page 300 may prompt the user to select an aspect of the billing application 112, such as billing view or manager view, they'd like to log in to.
FIG. 4 shows a worklist page 410 of a worklist dashboard 400. A user may access the worklist dashboard 400 by clicking on a worklist button. The worklist dashboard 400 may provide an interface for a medical claim analyst to pursue claims according to a claim prioritization schedule. The worklist may be organized according to medical service provider (also known as the client), patient, insurer, initial claim submission date, claim balance, or any combination thereof. By way of example in FIG. 4, the worklist is organized first by the client, which is shown in box 420. The billing application 112 may create a worklist for each client, which can be displayed on the worklist page 410. Box 430 shows a portion of the worklist page 410 that displays information about a particular patient with outstanding claims. Box 430 may display identifying information about the patient, such as name, date of birth, and the client with which the patient is linked, among others. Box 440 shows a portion of the worklist page 410 that displays insurance claim information associated with medical claim information. By way of example, such information may include the insurance payer name, the EMR claim number, the claim submission date, the claim balance, the status of the claim, a proposed follow-up date for the claim, the last date on which the claim was submitted, and other details regarding the claim.
Multiple claims may be shown in a list within box 440. When multiple claims are shown, box 440 may also show totals or subtotals for the claim balance amounts, the number of claims, and the claims coming due in the near future. Box 440 may also include an “action” column for annotating a particular claim or skipping the claim within the worklist.
FIG. 5 shows a note menu 500 that may be accessed when a user clicks the “Add Note” button under the “action” column in FIG. 4. The note menu 500 may allow a user to enter notes relevant to one or more claims. Such notes may correspond to issues raised during a phone call with the payer, actions to be taken to resolve the issues, and other information as desired. Notes may be linked to one or more claims and saved into the system 100.
FIG. 6. shows a skip menu 600 that may be accessed when a user clicks the “Skip” button under the “action” column in FIG. 4. The skip menu 600 may allow a user to skip work on one or more claims. The user may be able to enter a reason for skipping the claims along with a brief description of the reason. Skipping requests may be linked to one or more claims and saved into the system.
FIG. 7 shows a worked claims dashboard 710 that may be accessed by clicking on the Claims History button 700. The worked claims dashboard 710 may include information about each claim currently in the billing application 112. Such information may include a patient's name, the provider client associated with the patient, the balance processed (also known as worked balance), the number of claims worked, the number of remaining claims, the patient status, the last update of the patient's status, and the like. Multiple claims may be shown in a list, and the list may be organized according to any of the categories of information displayed. The worked claims dashboard 710 may allow a user to quickly assess the status of one or more patients in order to optimally determine which claims to process.
FIG. 8 shows a progress dashboard 810 that may be accessed by clicking on the Progress button 800. The progress dashboard 810 may include information indicating the amount of work progress one or more users has made on processing claims for a list of clients. Such information may include the client's name, a target number of hours of work, the number of hours completed so far, the number of remaining hours, and the like. The target number of hours may be set by the billing application, a manager, or another user. Progress information may be managed by clicking on a “Manage Login” button associated with the client.
FIG. 9 shows a management dashboard 910 that may be accessed by clicking on the Dashboard button 900. The management dashboard 910 may provide information pertaining to the work done by one or more billers processing claims using the billing application 112. For example, the management dashboard 910 may provide information about the claim balances processed by each biller, including individual and total balances. As another example, the management dashboard 910 may provide information about the number of claims completed by each biller, including individual and total numbers. The management dashboard 910 may also provide information about the total number of patients processed, the number of clinics served, progress made toward a target goal, and the like.
FIG. 10 shows a management navigation page 1010 that may be accessed by clicking on the Management button 1000. The management navigation page 1010 may provide a managing user with navigation options to additional management pages within the management dashboard 910. By way of example, FIG. 10 shows a Teams button 1100, a Clients button 1200, an EMRs button 1300, a Provider Specialties button 1400, a Saved Worklists button 1500, a Billers' Clients button 1600, Billers button 1700, and a Saved Worklist Templates button 1800. The buttons 1100-1800 may contain graphic elements, text elements, or a combination of the two. The buttons 1100-1800 lead to the additional management pages discussed in FIGS. 11-21, below.
FIG. 11 shows the teams page 1110 that may be accessed by clicking on the Teams button 1100 shown in FIG. 10. The teams page 1110 may provide information about the billing teams working within the billing application 112. For example, the teams page 1110 may include a list of team numbers, team names, a manager in charge of each team, the date when the team was created, and the like. The teams page 1110 may include an “action” column to allow a managing user to annotate an entry, edit team information, or create a new team entry.
FIG. 12 shows the clients page 1210 that may be accessed by clicking on the Manage Clients button 1200 shown in FIG. 10. The clients page 1210 may provide information about the clients who have worklists within the billing application 112. For example, the clients page 1210 may include a list of clients organized by client number, name, starting date, the billing team assigned to the client, the names of the billing team members, and the like. The clients page 1210 may include an “action” column to allow a managing user to annotate an entry, edit the information, or create a new entry. The clients page 1210 may also include a “filters” column to allow a user to apply filters, reset filters, create a default filter setting, load a default filter, or create additions to the page.
FIG. 13 shows the EMRs page 1310 that may be accessed by clicking on the EMRs button 1300 shown in FIG. 10. The EMRs page 1310 may provide information about one or more electronic medical record databases accessed by the billing application 112. For example, the EMRs page 1310 may include a list of EMR databases with claims, along with the EMR name, an EMR number, contact information for a point of contact with the EMR, and the date the EMR was added to the system. The list of EMR databases may be organized according to any of those categories. The EMRs page 1310 may include an “action” column to allow a managing user to annotate an entry, edit the information, or create a new entry.
FIG. 14 shows the provider specialties page 1410 that may be accessed by clicking on the Provider Specialties button 1400 shown in FIG. 10. The provider specialties page 1410 may provide information about the specialties of the clients with claims in the billing application 112. For example, the provider specialties page 1410 may list common specialties such as orthopedics, neurology, sports medicine, geriatrics, women's health, pediatrics, clinical electrophysiology, cardiovascular/pulmonary, and the like. The provider specialties page 1410 may include an “action” column to allow a managing user to annotate an entry, edit the information, or create a new entry.
FIG. 15A shows the worklists templates page 1510 that may be accessed by clicking on the Worklists Templates button 1500 shown in FIG. 10. The worklists templates page 1510 may provide information about the worklists within the billing application 112. Worklists are a prioritized list of patients for a biller to work through. The contents of a worklist may be displayed one patient at a time within the biller view. The worklist page shown in FIG. 15A is an interface where the manager can make changes to the prioritization schedule. The prioritization may be determined by a user of the manager view dashboard and may be displayed on at least one of the billing view dashboards in accordance with FIGS. 4-8, below. The manager user of the manager view dashboard may use the worklists templates page 1510 to create or edit the prioritization as described below. The system may, automatically or upon command from the user, update the prioritization shown in the billing view dashboard of the billing view user. The prioritization created by the manager user may create a new set of data corresponding to the claim information and insurance information collected and retrieved by the system. The new set of data may be the prioritized data that defines a worklist. In this way, the system may convert non-prioritized data into a standard prioritized dataset viewable by biller users of the system.
FIGS. 15B-D show worklist editing menus 1520 of the worklists templates page 1510 (FIG. 15A), in accordance with the first exemplary embodiment of the present disclosure. The worklist editing menu 1520 may allow a manager to create or edit a worklist according to desired criteria, which may include priority level, payer type priority, client priority, payer category priority, and payer priority, all of which may include a specific constraint type setting. As shown in FIG. 15B, the worklist editing menu 1520 may provide form entry menus, dropdown menus, and the like. By way of example, a manager may enter a worklist name, a priority template to use in the worklist, and a number of priority level settings. As shown in FIG. 15C, characteristic categories can be chosen for the priority level settings. Categories may be selected for high priority, medium priority, and low priority levels. As shown in FIG. 15D, once categories are selected for each of the priority levels, additional filter options may become available. By way of example, if the category “Denials” is designated as high priority, the user may be able to specify a narrower type of denial on which the application can focus, which may include, for example, denials that are new, denials based on electronic medical records (EMR), website denials, or others. If the category “Age” is designated as medium priority, the user may be able to specify an age range to apply the priority over. Categories may allow for further specification regardless of the priority level selected. Returning to FIG. 15B, after the priority level settings have been chosen, the user may select further options such as payer type priority and constraint type, client priority, payer category priority and constraint type, payer priority and constraint type, and the like.
FIG. 16 shows the billers' clients page 1610 that may be accessed by clicking on the Billers' Clients button 1600 shown in FIG. 10. The billers' clients page 1610 may provide information about which clients each biller is working with. By way of example, FIG. 16 shows a list of 7 clients, along with the names of billers working on their claims, the type of worklist the billers are utilizing, the number of patients on the worklist, the number of claims on the worklist, amounts in several categories of accounts receivable, and information on the clients' work as a portion of total work. Other information may also be included. The billers' clients page 1610 may allow a managing user to organize the list by any of these categories.
FIG. 17 shows the billers page 1710 that may be accessed by clicking on the Billers button 1700 shown in FIG. 10. The billers page 1710 may provide information about a particular biller's performance over time. The billers page may include identifying information about the biller, information relating to a target goal and progress toward that goal, and tables and graphs showing work performance over an amount of time, for instance per day, week, or month. A managing user may be able to set and reset target goals for the biller. The billers page 1710 may also allow a managing user to assign additional worklists or individual claims to the biller.
FIG. 18 shows the saved worklists templates page 1810 that may be accessed by clicking on the Saved Worklists Templates button 1800 shown in FIG. 10. The saved worklists templates page 1810 may include navigational buttons 1900, 2000 comprising graphics, text, or a combination thereof. The Filter Templates button 1900 and the Priority Templates button 2000 direct users to additional pages discussed in FIGS. 19-20, below.
FIG. 19 shows the filter templates page 1910 that may be accessed by clicking on the Filter Templates button 1900 shown in FIG. 18. The filter templates page 1910 shows saved filter templates within the system that a manager can access. The filter templates may be used by the manager to create boundaries, such as starting points and ending points, for the prioritization schedule. Filter templates may include filters based on claim age data, claim balance data, payer data, status data, provider data, CPT code data, and action code data. The retrieved insurance claim data may be filtered according to at least one of these data fields. For example, the manager may want the worklist to only contain claims that are greater than a certain age, such as 30 days old. Filtering by claim balance data may include excluding claims with claim balances outside of a desired range from a worklist. For example, claims with claim balances beneath a threshold may be filtered. Filtering by payer data may include excluding claims directed to particular insurance provider payers. Filtering by status data may include excluding claims with a particular status, for example, claims being processed, new claims, and the like. Filtering by provider data may include excluding claims originating from particular medical service providers. Filtering by CPT code data may include excluding particular CPT codes or ranges of codes. As a corollary, filtering by exclusion of claims with particular data field values may be performed by including only claims with particular data field values. Thus, filtering claims by age data may involve removing claims outside of a given age range or including claims within a given age range. Both inclusive and exclusive filtering are contemplated within the scope of this disclosure. The manager may select a filter that narrows the list of total claims down to a smaller list of claims the manager would then like to prioritize. This is discussed in greater detail in the priority examples below. In another example, filter templates may be enacted automatically by the system. For instance, the system may enact a filter template at periodic dates, such as the beginning or the end of fiscal calendars. In one example, the system may monitor the retrieved and collected data and may automatically set filters based on the characteristics of the associated claims. For instance, if a large number of high-value claims are pulled on a particular date, the system may automatically filter out lower value claims when the high-value claims are nearing an unrecoverable age.
FIG. 20 shows the priority templates page 2010 that may be accessed by clicking on the Priority Templates button 2000 shown in FIG. 18. The priority templates page 2010 may display saved priority filters within the system that a manager can access. The priority filters allow the manager to apply priorities to various measures such as balance, claim age, claim status, previous follow-up, and the like. By selecting a high, medium, or low priority, a multiplier may be applied to the claims which causes the claims to move higher or lower on the list accordingly. For example, by choosing claim age as the highest priority, a large multiple is applied to older claims, which makes these claims appear higher on the list even if they have lower balances than newer claims. In another example, by choosing previous follow-up as the highest priority, claims that have not previously been followed-up on will appear higher than other claims of the same value that have been followed-up on. This is discussed in greater detail in the priority examples below.
FIG. 21 shows the technical support page 2110 that may be accessed by clicking on the Technical Support button 2100. The technical support page 2110 may provide error and bug information submitted by users of the billing application 112 to allow managing users and developers to monitor and update the billing application 112. The information may include a support ticket number, the name of the biller who reported the error, the circumstances surrounding the error, and any actions taken to work around the error, among others. The technical support page 2110 may also include an “action” button that allows a user to edit or annotate an existing entry.

PRIORITY EXAMPLES

The following priority examples may illustrate how the filters and priority filters can be implemented to create prioritized worklists. In the priority examples, characteristic categories may be indicated as high priority, medium priority, or low priority. Each priority level corresponds to a multiplier assigned to an aspect of the claim. Low priority categories may receive a small multiplier, such as 1. Medium priority categories may receive a larger multiplier, such as 2. High priority categories may receive a still higher multiplier, such as 3. These values are exemplary and may be different depending on the implementation of the application. The priority examples may also contain high-level examples of code that can be adapted into the application to achieve the priority filters.
At least one multiplier may be applied to at least a portion of the medical claim data. For example, one multiplier may be applied to a claim balance of a medical claim in order to determine a standardized value of the claim. In this way, the standardized monetary value of all claims within a list may be determined, and a biller may work through the list according to a prioritization directed to the highest value claims first. As another example, one multiplier may be applied to a claim age of a medical claim in order to create a standardized age value of the claim. In this way, the standardized value of all claims within a list may be determined, and a biller may work through the list according to a prioritization of the highest value claims first. This may be desirable if a biller is required to process a certain number or type of claims within a particular amount of time. One multiplier may be applied to any of the data fields of the medical claim information in order to create standardized values for these claims relative to a particular field. Additionally, more than one multiplier may be applied to a single data field of a medical claim. In one example, the multipliers may be determined based on different data fields, such as age, provider, and status. The multipliers may then be applied to a single data field, such as claim balance, in order to create a standardized value of the medical claim that can be prioritized as described above. For instance, multipliers may be determined based on a claim's age and medical service provider, then applied to the claim balance to create a standardized monetary value of the claim. This may be done for each claim in a worklist to determine the highest value claims based on a hierarchy of multiple priorities. In one example, every data field corresponding to a claim may be assigned a multiplier, and every multiplier may be applied to one or more data fields in order to determine a standardized value for prioritization. The examples below discuss this in detail.
The prioritization may be determined by a hierarchy of at least one of the data fields corresponding to the medical claim. As an example, where the data fields of a medical claim include claim age, claim balance, payer, status, provider, CPT code, and action code, the data fields may be arranged according to a hierarchy of importance. For instance, claim balance may be of highest importance, followed by claim age, followed by claim status, and so on. The hierarchy may depend on performance metrics desired by the biller. For example, a biller may have a requirement to process a certain monetary value, a certain number of claims, a certain type of claims, and so on. Therefore, the hierarchy may be arranged according to these requirements. The prioritization of claims in a worklist may be determined according to this hierarchy as applied to the multipliers.

Example 1

In the first example, the high priority level is set to a “Denial” category, while the medium and low priority levels are left blank. The application applies a multiplier of 3 to the dollar amount of any claims having a denial status, and then reorganizes the worklist based on the claims with the highest dollar amount.


	IF	“High Priority” = ‘Denial’
		“Medium Priority” = ‘None’
		“Low Priority” = ‘None’

	THEN

Dollar amount of claims with status ‘Denial’ should be multiplied by 3

Example 2

In the second example, the high priority level is set to a “Follow Up” category, while the medium and low priority levels are left blank. The application applies a multiplier of 3 to the dollar amount of any claims having a follow up status, and then reorganizes the worklist based on the claims with the highest dollar amount.


	IF	“High Priority” = ‘Follow Up’
		“Medium Priority” = ‘None’
		“Low Priority” = ‘None’

	THEN

Dollar amount of claims with status ‘Follow Up’ should be multiplied by 3

Example 3

In the third example, the high priority level is set to an “Age” category, while the medium and low priority levels are left blank. The application applies a multiplier to the dollar amount of the claim based on its age; older claims are given a higher multiplier, while newer claims are given a lower multiplier. The application then reorganizes the worklist based on the claims with the highest dollar amount.


	IF	“High Priority” = ‘Age’
		“Medium Priority” = ‘None’
		“Low Priority” = ‘None’

	THEN

Dollar amount of claims should be multiplied as per below age condition:


High	31-60	1.75	used
	61-90	2	used
	91-120	2.25	used
	121 and older	2.5	used

If the manager has also applied an age range filter, the application first checks to determine whether the claim falls in the allowable age range before applying the multiplier. For example, if a filter only allows claims between 61 days and 120 days, then the result would be the following:

	THEN

Dollar amount of claims should be multiplied as per below age condition:


High	31-60	1.75	Not used because of
			filtering condition
	61-90	2	used because of
			filtering condition
	91-120	2.25	used because of
			filtering condition
	121 and older	2.5	Not used because of
			filtering condition

Example 4

In the fourth example, the high priority level is set to a “Denial” category, the medium priority level is set to an “Age” category, and the low priority level is set to a “Follow Up” category. The application first applies a multiplier of 3 to the dollar amount of any claims with a denial status, then applies a variable multiplier to the dollar amount of all claims according to their age, then applies a multiplier of 1.5 to the dollar amount of any claims with a follow up status. This may result in some claims receiving a multiplier for each priority level. The application then reorganizes the worklist based on the claims with the highest dollar amount.


	IF	“High Priority” = ‘Denial’
		“Medium Priority” = ‘Age’
		“Low Priority” = ‘Follow Up’

	THEN

Step 1: dollar amount of claims with status ‘Denial’ should be multiplied by 3
Step 2: dollar amount of claims should be multiplied by the age parameter as mentioned below:


Medium	31-60	1.5	used
	61-90	1.75	used
	91-120	2	used
	121 and older	2.25	used

Note that if there is a claim with status denial, age 95 days and dollar amount of $100, then in the first step as per high priority condition, its dollar amount will become $100*3=$300. In the next step, as per the medium priority condition, its dollar amount will become $300*2=$600.
Step 3: dollar amount of claims with status ‘Follow Up’ should be multiplied by 1.5
If the manager has also applied an age range filter, the application first checks to determine whether the claim falls in the allowable age range before applying the multiplier. For example, if a filter only allows claims between 61 days and 120 days, then the result would be the following:

	THEN


Medium	31-60	1.5	not used
	61-90	1.75	used
	91-120	2	used
	121 and older	2.25	Not used

Note that if there is a claim with denial status, age 95 days and dollar amount of $100, then in the first step as per high priority condition its dollar amount will become $100*3=$300. In the next step, as per the medium priority condition, its dollar amount will become $300*2=$600.
Step 3: dollar amount of claims with status ‘Follow Up’ should be multiplied by 1.5

Example 5

In the fifth example, the high priority level is set to a “Denial” category, the medium priority level is set to a “Follow Up” category, and the low priority level is set to “Age.” The application first applies a multiplier of 3 to the dollar amount of any claims with a denial status, then applies a multiplier of 2 to the dollar amount of any claims with a follow up status, then applies a variable multiplier to the dollar amount of claims based on their age. The application then reorganizes the worklist based on the claims with the highest dollar amount.


	IF	“High Priority” = ‘Denial’
		“Medium Priority” = ‘Follow Up’
		“Low Priority” = ‘Age’

	THEN

Step 1: dollar amount of claims with status ‘Denial’ should be multiplied by 3
Step 2: dollar amount of claims with status ‘Follow Up’ should be multiplied by 2
Step 3: dollar amount of claims should be multiplied by the age parameter as mentioned below:


Low	31-60	1.15	Used
	61-90	1.25	Used
	91-120	1.5	Used
	121 and older	1.75	Used

Note that if there is a claim with status denial, age 95 days and dollar amount of $100 then in the first step as per high priority condition it's dollar amount will become $100*3=$300. In the third step, as per the low priority condition, its dollar amount will become $300*1.5=$450. For example, if there is a claim with status follow up, age 95 days and dollar amount of $100 then in the second step as per medium priority condition it's dollar amount will become $100*2=$200. In the third step, as per the low priority condition, its dollar amount will become $200*1.5=$300.
If the manager has also applied an age range filter, the application first checks to determine whether the claim falls in the allowable age range before applying the multiplier. For example, if a filter only allows claims between 61 days and 120 days, then the result would be the following:


	IF	“High Priority” = ‘Denial’ (or Follow Up)
		“Medium Priority” = ‘Follow Up’ (or Denial)
		“Low Priority” = ‘Age’

	THEN

- Step 1: dollar amount of claims with status ‘Denial’ should be multiplied by 3
- Step 2: dollar amount of claims with status ‘Follow Up’ should be multiplied by 2
- Step 3: dollar amount of claims should be multiplied by the age parameter as mentioned below:


Low	31-60	1.15	Not Used
	61-90	1.25	Used
	91-120	1.5	Used
	121 and older	1.75	Not Used

Note e.g. if there is a claim with status denial, age 95 days and dollar amount of $100 then in the first step as per high priority condition it's dollar amount will become $100*3=$300. In the third step, as per the low priority condition, its dollar amount will become $300*1.5=$450. For example, if there is a claim with status follow up, age 95 days and dollar amount of $100, then in the second step as per medium priority condition it's dollar amount will become $100*2=$200. In the third step, as per the low priority condition, its dollar amount will become $200*1.5=$300.

Example 6

In the sixth example, the high priority level is set to a “Denial” category, the medium priority level is set to a “Follow Up” category, and the low priority level is left blank. The application first applies a multiplier of 3 to the dollar amount of any claims with a denial status, then applies a multiplier of 2 to the dollar amount of any claims with a follow up status. The application then reorganizes the worklist based on the claims with the highest dollar amount.


	IF	“High Priority” = ‘Denial’
		“Medium Priority” = ‘Follow Up’
		“Low Priority” = ‘None’

	THEN

- Step 1: dollar amount of claims with status ‘Denial’ should be multiplied by 3
- Step 2: dollar amount of claims with status ‘Follow Up’ should be multiplied by 2

If the manager has also applied an age range filter, the application first checks to determine whether the claim falls in the allowable age range before applying the multiplier. For example, if a filter only allows claims between 61 days and 120 days, then the result would be the following:

	THEN

- Step 1: dollar amount of claims with status ‘Denial’ and age between 61 days to 120 days should be multiplied by 3
- Step 2: dollar amount of claims with status ‘Follow Up’ and age between 61 days to 120 days should be multiplied by 2

FIG. 22 is a flow chart illustrating an exemplary implementation of the method for medical claims billing management, in accordance with the second exemplary embodiment of the present disclosure. FIG. 22 shows a software implementation of the system and method described relative to FIGS. 1-21 and is exemplary in nature. Other software implementations may be considered within the scope of this disclosure.
Step 2210 includes uploading a claim to a database. The claim may be a dataset containing multi-field data corresponding to a medical service claim for billing. The data fields may include the claim balance value, a unique claim identifier, a patient identifier, a client identifier, an insurance payer identifier, a claim status, CPT codes, a claim date, and similar information. Each claim may have a plurality of data fields making up a single claim. Claims may be uploaded to a relational, subject-oriented database. Claims may also include information corresponding to insurance claims related to the medical service. Claims may be uploaded automatically by a software program, as discussed above.
Step 2220 includes defining a worklist template. This step, along with Steps 2222-2240, may be performed using the manager view dashboards discussed in FIGS. 9-21. The worklist template may be defined by creating a filter, as in Step 2222. The filter may exclude a number of claims from further processing based on the values of data in one or more fields. For example, a filter may exclude claims based on minimum or maximum ages, minimum or maximum claim balances, payer identity, claim status, medical provider, CPT codes, action codes, reasons for skipping, payer filters, or some combination thereof. In one example, a filter may be set to include claims having desired data field values rather than exclude claims. The worklist may also be defined by creating one or more multipliers that can be applied to values in one or more data fields. For example, the age of a claim may be an important consideration in deciding whether its handling is a priority. Claims having older age values may be given higher multipliers than claims having newer age values. More specifically, if a value in a data field, such as claim age, falls within a given range, it may be assigned one multiplier. If the value falls outside of the given range, it may be assigned another multiplier. The multiplier scheme may be determined by a user or by a software algorithm. Filters and multipliers may both be created and applied in any order desired.
Step 2230 includes creating a worklist for one or more billers. The worklist may be an assignment of one or more claims to the one or more billers in a particular order determined according to the worklist template defined in Step 2220. The worklist may consider the initial queryset, which may be all claims uploaded to the database in Step 2210 that are active and in need of processing. The initial queryset may be filtered in Step 2232 by applying the filter or filters created in Step 2222. Claims excluded by the filter are not considered for the remainder of the process, while claims that are included by the filter are further processed. The filtered queryset may be further filtered if, for example, claims are included that have a scheduled follow-up date at a point in the future. This is discussed further in Step 2256. Step 2234 includes annotating the filtered queryset with a new data field corresponding to a standardized value. The standardized value may be determined after the at least one multiplier is applied to the claim. The standardized value may be a value converted from one or more data field values and the at least one multiplier. In one example, the standardized value may represent a monetary value calculated from the claim balance and another field, such as the claim age. In another example, the standardized value may represent an age value calculated from the claim age and another field. Step 2236 includes applying the multiplier. This operation is discussed in detail relative to the priority examples above.
Step 2238 may include saving the worklist. This may include creating an order of the prioritization of all claims in the filtered queryset, for instance, from large to small according to the standardized value. Saving may include electronically recording the worklist in memory, as well as providing real-time access to the worklist to other biller users. The worklist may be updated periodically in Step 2240, wherein steps 2232-2238 may be performed again in order to update any time-sensitive filters or multipliers. As an example, the worklist may be updated daily, hourly, or quarter-hourly, depending on the implementation of the software method.
Step 2250 includes processing the worklist. A biller may access the worklist in Step 2251 after it has been provided and may process claims according to the order given by the worklist. This may be graphically displayed in the plurality of billing view dashboards described in FIGS. 3-8. In one example, a biller may choose a client as in Step 2252, meaning the biller may work on the claims for one client in particular at a time. Once the client has been chosen, the biller may be presented with one open claim to work at a time.
The biller may choose to process the claim in a number of ways. In Step 2253, the biller may work the claim by processing it with the payer insurance provider in an attempt to reach a successful billing result. In Step 2254, the biller may skip the claim and choose to work on another claim. When skipping a claim, the biller may choose to set a date at which to follow-up on the skipped claim, as shown in Step 2256. The follow-up date may indicate a date at which the skipped claim becomes a higher priority to be processed. In Step 2255, the biller may annotate the claim. This may include adding notation or textual descriptions to the metadata of the claim in order to document the biller's attempts to process the claim. For example, the annotation may indicate that the biller was successful, was unsuccessful, spoke with a particular representative, and so on. The biller may include action codes in the notation that indicate the preferred next step for processing the claim, such as electronic processing, telephone calls, escalation, and the like. The biller may work through all or a portion of the claims on the worklist in order to process all of the priority claims according to the standardized value determined by the software.
FIG. 23 is a flow chart illustrating a method for processing relationships in a medical claims database, in accordance with a third exemplary embodiment of the present disclosure.
Step 2310 includes storing multi-field medical claim data and multi-field insurance claim data in a relational electronic database, wherein the insurance claim data corresponds to at least a portion of the medical claim data. The multi-field medical claim data and multi-field insurance claim data may be data corresponding to a claim for medical treatment as described above. The medical and insurance claim data may be stored in a relational electronic database by a software program. The software program may collect and retrieve the medical and insurance claim data from their respective websites or their respective databases as described above using web scraping, ODBC or an API. The medical and insurance claim data may be temporarily stored on the relational database to facilitate processing of the relationships within the multiple tiers, or it may be stored until the claim has been successfully processed.
Step 2320 includes defining a worklist template using at least one filter and at least one multiplier, wherein the at least one filter excludes at least a portion of the medical claim data, and wherein the at least one multiplier defines a weighted value applicable to at least one field of the multi-field medical claim data.
The filter may exclude at least a portion of the medical claim data. For example, the filter may exclude medical claims outside of a desired age range, balance value, or insurance payer. The filter may be used to narrow a list of claims to a smaller list for focused processing. The at least one multiplier may be a numerical value applied to weight at least one field of the multi-field medical claim data. As discussed relative to the priority examples above, the at least one multiplier may be determined based on a hierarchy of data field values and may be applied to one or more data field values of a list of claims.
A worklist template may be further defined using additional numerical processing. For instance, the medical claims corresponding to the medical and insurance claim data may be sorted according to the values of the data in one or more fields. In one example, the medical claims may be sorted according to claim balance, either by largest-to-smallest or smallest-to-largest order. Sorting by smallest-to-largest order may be done by applying a negative multiplier to the claim balances and sorting by largest-to-smallest. In another example, the worklist template may be definable based on a claim data field. The claim data field used to define the worklist template may be toggled by the user in practice, allowing the worklist template to be updateable.
Step 2330 includes converting, by the processor, the medical claim data into standardized values by applying the at least one multiplier to at least one field of the multi-field medical claim data. The processor may apply the at least one multiplier to the filtered list of medical claims by applying the at least one multiplier's numerical value to the numerical value of at least one field for each medical claim in the filtered list. This may create a standardized value of the claim with relation to the at least one field. For example, a multiplier may be applied to the claim balance of each claim in order to determine the standardized monetary value of each claim within the filter list. This may allow a user to process the claims according to a prioritization determined by the standardized value, i.e., by higher value claims first. As another example, a multiplier may be applied to the age of each claim within the filtered list to create a standardized age value of each claim. Multipliers of different weights may be applied to each claim according to a hierarchy determined by the user in order to create a standardized value with which to evaluate and process the medical claims. This may allow the relational claim data across multiple fields of a claim to be reconciled in a single value data point, thereby providing a value based on the relative weights of each data field.
Step 2340 includes assigning a biller worklist based on a hierarchy of the standardized value. After the processor has applied the multiplier to each of the claims and the total number of claims has been filtered, the processor may assign a biller worklist based on a hierarchy of the standardized value of each claim. For example, a standardized balance value may have been created for each claim in the filtered list. The processor may assign a worklist to a biller based on a hierarchical order, such as largest balance to smallest, of each claim. This worklist may create a priority schedule from which a biller may work to process the claims within the filtered list. Multiple standardized balances may be created for each claim in the filtered claim worklist. The claims may be ordered according to the hierarchy. For example, high balance claims may be ordered first, and within that, the oldest claims may be ordered before the newest claims. The hierarchy may be determined by a managing user or by a software algorithm to maximize an aspect of medical claims processing such as monetary value collected, number of claims processed, average processing time, and the like.
FIGS. 24A-33 describe a related embodiment for medical claims relationship processing. FIG. 24A is a box diagram of a system 2400 for medical claims billing management, in accordance with a fourth exemplary embodiment of the present disclosure. The system 2400 includes at least one billing computer device 2401, which has a processor and non-transitory computer-readable memory, a relational, subject-oriented medical claim database 2420 containing multi-field medical claim data, and a remote insurance database 2430 containing multi-field insurance claim data corresponding to at least a portion of the medical claim data. The system 2400 also includes a server 2410 having a processor and non-transitory computer-readable memory. The server 2410 is accessible over at least one network system by the billing computer device 2401, the relational, subject-oriented medical claim database 2420, and the insurance database 2430.
A billing management application 2412 is hosted at least partially on the server 2410. The billing management application 2412 runs at least partially on the server 2410 and is accessible by the plurality of billing computer devices 2401. Each of the plurality of billing computer devices 2401 has a visual dashboard on a computerized graphical user interface which is connected to the server 2410 for viewing a claims worklist generated from the collected multi-field medical claim data and the collected multi-field insurance claim processing data. Each of the plurality of visual dashboards is viewable and interactable by a user, such that the billing management application 2412 can request at least one claim from the claims worklist using the visual dashboard of the computerized graphical user interface of the plurality of billing computer devices 2401. Once a claim is received, the billing management application 2412 may execute an action on the at least one claim using the at least one of the plurality of billing computer devices 2401, wherein the action comprises transmission of claim action data to the at least one remote insurance database 2430 using the at least one electronic network system. It is noted that the billing management application 2412 described relative to FIG. 24A may include many of the features, components, and functions described relative to FIG. 1A and other figures of this disclosure, all of which are considered incorporated with the system 2400 of FIG. 24A.
It is noted that the medical claims relationship processing system 2400 may be used to further enhance the efficiency and accuracy of the medical claims processing described relative to FIGS. 1-23. In particular, the medical claims relationship processing system 2400 may be used to analyze the experience, steps taken, and other historical actions of billers with claims and then provide recommendations based on that analysis to users, for example, to guide a process for resolving other claims by the users based on the historical analysis of previous claims. Moreover, the system 2400 provides a generated worklist with specific recommendations and actions for the users/billers based on analysis of this historical data, such that tailored recommendations, steps, and actions can be provided for a specific claim a user is working on based on the historical experience of other actions similar to that claim. In this way, the system provides a technical improvement to existing worklist-based programs by dynamically tailoring the worklist to recommendations and actions for claim-specific processes on that worklist, whereas conventional systems provide a static worklist with no recommendations, actions, or historical guidance to the user. The end result is an improvement to the computerized medical billing system, since it allows for a higher speed of claim processing, heightened automation during processing, and more accurate claim resolutions.
FIG. 24B is a flowchart diagram 2450 of a system 2400 for medical claims billing management, in accordance with the fourth exemplary embodiment of the present disclosure. In general terms, the medical claims may be first uploaded into the system 2400 or retrieved by the system 2400 over a network connection. The medical claims are uniquely identified by an external claim identifier, such as a claim number or an identifier corresponding to a patient the claim is for. The medical claim is also usually identified by the medical clinic from which the claims originate, e.g., the medical office, hospital, etc. The claims may also have additional information attached to them such as payer identifiers, denial reason codes, and aging dates, or others. Claim payment information is also uploaded into the system 2400, or otherwise retrieved by the system 2400 over a network. This information is correlated with the medical claims data previously uploaded by using the claim and clinic identifiers. At this stage, the claims are determined to be paid or not paid and this information is stored within the system 2400.
The system 2400 then maps payers to a list of canonical payers defined by administrators of the system 2400. Oftentimes, the payers uploaded to the system 2400 initially are not in a standardized form, so mapping includes standardizing the payers by assigning them to a canonical payer using a payer alias. For example, the payers may be identified in different formats, such as “payer 1”, “Payer (AZ) 1”, “Payer One” or other notations of the same payer in the original claim data. To ensure consistency and accuracy in the system 2400, these various forms of the payer identification are standardized by being mapped to a canonical “Payer 1” or another notation, such that the data format is consistent. A list of payer aliases and their corresponding payers may then be created based on this information.
Next, claims worklists may be generated. The claims worklist may be a dynamically-generated list of unresolved medical claims for a particular clinic based on various criteria, including, for example, age of the claim, a particular payer for that claim, the claim balance, whether or not that claim has been worked recently, or others. The claims worklist is provided visually on the display interface of the billing computer of the user, such that the medical biller can visually see the claims worklist and the unresolved medical claims therein. Billers can then request a worklist item for a particular clinic, or in accordance with another criteria, such as for a particular type of claim, for a particular insurance payer, etc. Once selected, the visual interface returns an individual claim from that worklist and presents it to the biller so that the biller can review the claim and take some action to resolve the claim. Images of the visual interface used by the system are depicted in FIGS. 26-33.
The action performed to resolve the claim may vary widely, but it will include transmission of data or information from the system 2400 to the insurance database, where the data or information which aids or attempts to aid in resolving the claim. For example, the action may include submitting additional forms or documents to the insurance payer, submitting clarifications on the claim, submitting the claims with different or corrected medical billing codes, or otherwise performing an action which attempts to resolve the claim. Additionally, the action may include retrieving information from an EMR database, from a medical clinic, or from another source. During or in near proximate time to when the biller performs some action with the claim they have received, the biller may also record a textual note or another, similar type of note which describes the actions they took to resolve or attempt to resolve the claim. This note may be recorded and saved with the claim, such that the note corresponds to the specific claim. For example, the biller may record what additional information was retrieved and submitted, what forms were used, what format the information was submitted in, or any other aspects of the process with the specific claim. Optionally, the medical biller may also add a follow-up date to this claim describing when it should reappear in a worklist, such that after a period of time the claim will reappear in a worklist for follow-up or resubmission.
This recorded information can be useful later on when the claim is approved or denied, since the note with the biller's actions can be used by other billers to understand what was done to process the claim successfully or what actions still did not result in resolution of the claim. At this stage, the billers are also presented with a populated list of suggested actions to take when processing a claim. This populated list of selected actions is based, at least in part, on the historical data of claims which have been processed, such that the populated list can be dynamically keyed to the generated worklist and the specific attributes of the claims thereon. The biller may retrieve prior notes matching the particular claim the biller is currently working. The list of notes may be filtered based on the claim's payer, its denial reasons, and whether the claim that note was attached to was paid, among other aspects of the claim. This list may be searchable by keyword in the note text field, or it may be searchable based on a billing code, or via another method. Thus, the success or failure of previous claim resolutions can be used by billers to help resolve pending claims. Once the claim is processed, the claim is considered to be worked on, and thus is now unavailable until it is reactivated, either by a subsequent claim upload, e.g., from the beginning of the process, or when its follow-up date arrives.
Each of the billers who interact with the populated list may be able to provide a rating of how helpful the prior notes were in resolving the claims. For example, the biller may be able to give a numerical rating, a thumbs-up or thumbs-down rating, or another type of rating which can be used to identify how helpful or successful the note was. Accordingly, future billers can not only see the suggestion action in the populated list, they can also see evidence of how useful or successful that suggested action was for a previous claim. This improvement to the visual interface of the application further helps to aid in the efficiency of resolving claims, since the actions can be suggested based on their ratings of success. Eventually, over a period of time, the suggested actions list is dynamically refined by increasing the visibility of actions with high ratings of success and allowing actions which have low ratings to be left off the suggested actions list.
FIG. 25 is another flow chart diagram of a method for medical claims billing management 2500, in accordance with the fourth exemplary embodiment of the present disclosure. In particular, FIG. 25 further describes the functionality of the medical claim billing system 2400 of FIGS. 24A-24B. As shown at block 2510, multi-field medical claim data is electronically collected on a server from a relational, subject-oriented database over at least one electronic network system. The multi-field medical claim data is data that has been submitted to a payer entity, such as an insurance company. The multi-field medical claim data has at least an external claim identifier, such as an identifier of the claim itself, e.g., a claim number, a medical clinic identifier, a payer identifier, claim payment information, denial reason codes, or another type of identifier.
At block 2520, multi-field insurance claim processing data is electronically collected from at least one remote insurance database over the at least one electronic network system. The multi-field insurance claim processing data is correlated to the multi-field medical claim data based on the external claim identifier. For example, the insurance claim processing data may be correlated to the medical claim data based on the identifier, e.g., the claim number or another identifier, such that the data from both the medical claim and the insurance claim processing can be identified as being related. Once this information is correlated, a claims worklist may be generated, as shown at block 2530.
At block 2540, a claims worklist is displayed on a plurality of visual dashboards on a computerized graphical user interface of a plurality of user computers connected to the server. The visual dashboard allows for viewing a claims worklist generated from the collected multi-field medical claim data and the collected multi-field insurance claim processing data. Each of the visual dashboards are viewable and interactable by a user, such as a medical biller. At block 2550, the medical biller, via the visual dashboard of the billing computer, may request at least one claim from the claims worklist using the visual dashboard of the computerized graphical user interface of at least one of the plurality of medical billing computers. Once the requested claim is received, the medical biller may then review the claim and use the visual dashboard to execute an action on the one claim, as shown at block 2560. The action may include transmission of claim action data to the at least one remote insurance database using the at least one electronic network system. In more detail, the action may include reprocessing the claim, submitting additional information or forms with the claim, requesting more information for the claim, or another claim billing action. The claim is then submitted and processed until it is resolved, as shown at block 2570.
As noted previously, the specific action that the user takes may be selected from a populated list which recommends actions to be taken for a particular claim, as shown at block 2580. This populated list may be displayed on the visual dashboard and is compiled based on historical claim action data. The populated list of claim actions may be correlated to the collected multi-field medical claim data and the collected multi-field insurance claim processing data based on one or more correlation factors, e.g., a characteristic or aspect of the medical claim or insurance claim which overlaps or can be used to provide assistance with claim processing. For example, the correlation factor may be one or more of an identity of a payer a claim of the multi-field medical claim data, a medical clinic originating the medical claim, a medical claim code, a payment denial reason code, or another factor. Concurrent with executing the action, the biller may record textual data describing at least a portion of steps taken during execution of the action, as shown at block 2590. This information may be used within the populated list to provide written steps of the process the biller used when performing the action, which allows the biller to effectively have a guide based on historical claim processing which can be used to best submit similar medical claims. The populated list may be searchable based on keyword, alphanumerical code, e.g., denial or billing code, or with other data. Additionally, the biller may provide a rating of the recommendation related to how helpful or successful it is for a particular claim, as shown at block 2595, as discussed relative to FIG. 24B.
FIGS. 26-33 are images of the visual interface of the billing management application (2412 in FIG. 24A) used by the system for medical claims billing management, in accordance with the fourth exemplary embodiment of the present disclosure. In particular, with reference to FIGS. 26-33 together, the architecture and construction of the billing management application may be understood. The billing management application is a computerized and computer-implemented program which performs the functionalities of the system described herein. The billing management application may be written using Django® web framework with a PostgreSQL database hosted with Amazon® RDS.
There may be two main user roles with the billing management application: the medical billers and the managers who oversee the medical billers. The billing management application presents medical billers with a claims worklist which includes a small subset of information at one time to act on. The claims worklist usually consisting of particular claims or particular patients. At the same time, the billing management application allows the managers to have control over the settings for billers and upload data, such that the managers can oversee the billers and ensure that the billing management application is providing the desired information within the claims worklist to each biller.
The manager workflow may be controlled, at least in part with an object relational mapper (ORM) which is used to manage the database or databases used by the billing management application. This means that database tables may be defined in code and mapped to a database state. For instance, an example of the definition of a ‘Claim’ in this framework may be as follows:
As shown, this framework may define a ‘Claim’ and its attributes that are necessary for subsequent filtering. It may also define the relationship that a Claim has with other database tables with foreign keys, such as the ‘patient’, ‘client’, and/or ‘Payer’. This information is presented on the visual display to the users on the computer display interface, as shown in FIG. 26. Here, as shown, the columns correspond directly to the database fields defined in the framework above (balance, active, patient, client, etc.) as well as calculated columns such as age. The calculated columns may be calculated with the following code:
As can be seen, this code may annotate a collection of database rows—commonly understood as a queryset—with the new field “age” based on the length of time between now and the aging date of the claim.
The electronic health record payer field (identified by ‘ehr_payer’) of the medical claim comes directly from the electronic medical records (EMR) systems, such as those systems present at medical clinics or other facilities with medical records. These EMR systems do not have standardized formats for the EMR data. Thus, the EMR data needs to be manually mapped to a canonical payer. An example of the database tables for payers (canonical payers) and payer aliases is as follows:
When a PayerAlias is saved (as indicated by the ‘save’ function at line 702), the existing claim rows that use this particular alias (‘using_alias=self’ at line 705) need to be updated. This updating process takes place in two general steps. First, there is an operation to find all existing claims that use this alias (line 705) and update them to no longer use the alias (line 706). This process is necessary because if the alias changed (line 692), the particular mapping that this payer alias represents would no longer be valid. Second, there is an operation to find all claims that have an inexact match in the ehr_payer field to this alias (line 708) and update them so that the using_alias field points to this alias (line 709).
Visually, this process may occur over a number of steps, which can be seen visually on the interface of the biller's computer. For example, FIGS. 27-28 illustrate the process of creating a new canonical payer (corresponding to line 768 above), where in FIG. 27 a ‘new payer’ window may be presented for entering the new payer's name, e.g., “American Insurance” as shown. Then, in FIG. 28, this new payer appears in a list relative to the claims which are associated with that payer. In the Examiner of FIG. 28, there are zero claims associated with the exemplary ‘American Insurance’ payer. In FIG. 29, the visual display shows the ability to edit the payer identification field, such that aliases for the payer can be created. Thus, the various formats of the payer name from the various EMR databases can be standardized here to ensure that all claims for one payer are associated with that payer, regardless of nominal differences in the payers name or the format of their name. Next, in FIG. 30, the visual display depicts a table which claims are automatically mapped to a specific payer, i.e., as identified in the ‘Mapped Payer’ column. The table includes additional information about the particular claims, such as the balance of the claim, whether the claim is active or not, the claim number, a CPT code, if any, the client, the client division, the EHR payer, the age of the claim, a follow-up date, a worked-on date, a notation for the person who last added a note, a ‘last action code’ field, and a ‘claim paid’ field.
With this information, to determine if a claim was paid, a list of payment information is uploaded, as shown in FIG. 31. In this example, the payment information uploaded includes a sheet with required and optional headers. The user has the ability to browse for additional files to upload if needed. The user may also be able to run report based on a start and end date. The user's action of uploading this payment information acts to populate a database table within the application, the operation of which is depicted below:
As shown, information that is collected includes references to particular clients (as shown on line 2845), claims (as shown on line 2846), and the amount that was paid (as shown on line 2852). Any claim with a ‘total_amount’ greater than 0 is assumed to be paid. The paid status of a claim is determined with the following code:
For the billers who are using the billing management application, they may be presented with assigned worklists with unresolved claims. A simplistic example of the assigned worklist is depicted in FIG. 32, where the user is presented with a table having a client name, a worklist name, a date the client was last worked, along with targets for the user, such as target hours, target claims, hours worked in a period of time, claims worked in a period of time, and available patients. This worklist not only allows the user to see claim information, but it also provides the biller and management of the biller with insights into performance.
The biller may then be presented with a particular claim or claims to work on from their worklist. For example, as shown in FIG. 33, the biller may be presented with two claims for patient 594. As can be seen, the visual interface presented to the patient includes different sections of the interface having various information. These may include a heading section identifying the client, the patient, and the worklist item. A claim section may show the monetary balance of the claim or claims, and also have an ‘action’ selection feature, a query boxy for determining a follow-up date, and a note text box where the user can record his or her notes, steps, or other information relating to the action. The action code box may include pre-set codes selected by management of the application to organize the specific type of action into categories, whereas the note text box may allow the biller to input textual data about their specific actions in processing the claim.
Additionally, on the right hand of the visual display, the user is presented with the populated list of recommended actions. For example, each action is provided with a summary, a denial reason code, and a suggestion on whether or not this particular action may work for the claim at hand, e.g., as shown on the right-hand column with the check mark. The populated list also includes a ratings indication of how successful or useful a particular action has been for other billers, e.g., as shown on the right-hand column with the ‘thumbs-up’ and ‘thumbs-down’ icons. In use, the biller can either add their own note, filling in the “Note text”, “Action code” and “Followup date” fields, or they can search for an existing note in the populated list on the right. The columns may be sorted by the overall score (up+down votes) on the left and are sortable. The fields in the table can also be searched with the search query box at the top.
Once the notes are saved the following table is updated with the new information, as illustrated by the code below:
If the biller has added a new note a new row will be added in this table, otherwise the ‘used_count’ field will be incremented. The biller can also add a single positive or negative vote for each suggestion which will also update this table. The note is also saved in a separate table that directly ties it to the biller's account (for example, on line 923):
At the same time, the suggestion table may be populated in accordance with the operation in the following code:
It is noted that filtering the suggestion data by both denial reason and payer is possible, as well as claims that are known to have been paid, and ordering by the total score of the suggestion.
It is also noted that the billing management application may be used to monitor the performance of the billers themselves. For example, the billing management application can be used to see how effective or productive billers are, such as by analyzing the number of claims processed in a period of time by a biller, analyzing the percentage of claims that were paid for a particular biller, and comparing these data points to other billers. In this way, the system may be able to help improve performance of the billers overall or assist in resolving billing issues which are caused by lack of knowledge, inexperience, or mistakes.
The process described relative to FIGS. 24A-33 may include interaction with a biller, but it may also be possible to semi-or-fully automate aspects of the medical claim management process. For example, it may be possible for the billing management application to take semi-autonomous action with processing claims, such that the billing management application analyzes the denial reasons for a particular medical claim and sorts them into categorized lists based on characteristics or features of the claims. For example, all claims with a specific medical billing or denial code may be sorted together. Then the categorized list may be presented to a medical biller for handling, which may be accomplished more efficiently since the biller will only be handling claims with similar denial issue. The system may include similar types of semi-automated processes which aid in improving the efficiency of the claim review process or claim submission or re-submission process. It may also be possible for the billing management application to function fully autonomously or near fully autonomously, such as when the billing management application automatically analyzes a medical claim denial, follows a course of action which is prescribed in the historical database, and then performs functions to resolve that claim. For example, the billing management application may be able to automatically analyze a claim with a particular denial code which relates to insufficient data, then identify which data is missing, such as by using recorded notes or previous actions from a populated list of historical interactions, then the application may be able to automatically retrieve that data for the EMR database of the clinic, such as by retrieving the data using a secure network connection, API, or similar communication medium. Then, the application may resubmit the medical claim to the payor and record the actions taken in a database for future reference to. The system may learn via iteration such that it can function without little-to-no human involvement. Semi or fully automated processes may be enacted using various computer programs, including scripts, machine learning, AI, or similar tools.
It should be emphasized that the above-described embodiments of the present disclosure, particularly, any “preferred” embodiments, are merely possible examples of implementations, merely set forth for a clear understanding of the principles of the disclosure. Many variations and modifications may be made to the above-described embodiment(s) of the disclosure without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and the present disclosure and protected by the following claims.

Claims

What is claimed is:

1. A method for data processing of remotely collected medical claims billing data using a computerized system having a processor and a non-transitory memory, the method comprising:

electronically collecting, on a server, multi-field medical claim data from a relational, subject-oriented database over at least one electronic network system, the multi-field medical claim data having been submitted to a payer entity, wherein the multi-field medical claim data has at least an external claim identifier;

electronically collecting, on the server, multi-field insurance claim processing data from at least one remote insurance database over the at least one electronic network system, wherein the multi-field insurance claim processing data is correlated to the multi-field medical claim data based on the external claim identifier;

providing a plurality of visual dashboards on a computerized graphical user interface of a plurality of user computers connected to the server for viewing a claims worklist generated from the collected multi-field medical claim data and the collected multi-field insurance claim processing data, each of the plurality of visual dashboards viewable and interactable by a user;

requesting at least one claim from the claims worklist using the visual dashboard of the computerized graphical user interface of at least one of the plurality of user computers; and

executing an action on the at least one claim using the at least one of the plurality of user computers, wherein the action comprises transmission of claim action data to the at least one remote insurance database using the at least one electronic network system.

2. The method of claim 1, further comprising selecting the action from a populated list of claim actions displayed on the visual dashboard, wherein the populated list of claim actions is based on historical claim action data.

3. The method of claim 2, wherein the populated list of claim actions is correlated to the collected multi-field medical claim data and the collected multi-field insurance claim processing data based on at least one correlation factor, wherein the at least one correlation factor is one or more of: an identity of a payer of a claim of the multi-field medical claim data, a medical clinic originating the medical claim, a medical claim code, or a payment denial reason code.

4. The method of claim 2, wherein executing the action on the at least one claim using the at least one of the plurality of user computers further comprises recording textual data describing at least a portion of steps taken during execution of the action.

5. The method of claim 4, wherein the populated list of claim actions displayed on the visual dashboard is further based on the recorded textual data.

6. The method of claim 2, wherein the populated list is searchable using at least one of:

textual keyword or alphanumerical code.

7. The method of claim 2, wherein after executing the action, a user provides a rating of a selected claim action from the populated list of claim actions.

8. The method of claim 1, wherein the external claim identifier comprises one or more of: a medical clinic originating the multi-field medical claim data; a payer of a claim for the multi-field medical claim data; a payment denial reason code; or an age of the at least one claim.

9. The method of claim 1, wherein a payer is associated with each remote insurance database, wherein an identifier of the payer is standardized and canonically mapped within a database on the server.

10. The method of claim 1, wherein the claims worklist is generated based on one or more of: a medical clinic originating the multi-field medical claim data; an age of the at least one claim; a payer of a claim for the multi-field medical claim data; a monetary claim balance; or a history of work on the at least one claim.

11. A system for data processing of remotely collected medical claims billing data using a computerized system having a processor and a non-transitory memory, the system comprising:

a plurality of billing computer devices having a processor and non-transitory computer-readable memory;

a server having a processor and non-transitory computer-readable memory, the server accessible over at least one network system by the plurality of billing computer devices;

a relational, subject-oriented database containing multi-field medical claim data, wherein the multi-field medical claim data is electronically collected on the server over at least one electronic network system, the multi-field medical claim data having been submitted to a payer entity, wherein the multi-field medical claim data has at least an external claim identifier;

at least one remote insurance database containing multi-field insurance claim processing data, wherein the multi-field insurance claim processing data is electronically collected on the server over the at least one electronic network system, wherein the multi-field insurance claim processing data is correlated to the multi-field medical claim data based on the external claim identifier; and

a billing management application running at least partially on the server and accessible by the plurality of billing computer devices, wherein each of the plurality of billing computer devices has a visual dashboard on a computerized graphical user interface which is connected to the server for viewing a claims worklist generated from the collected multi-field medical claim data and the collected multi-field insurance claim processing data, wherein each of the plurality of visual dashboards viewable and interactable by a user, and wherein the billing management application:

requests at least one claim from the claims worklist using the visual dashboard of the computerized graphical user interface of at least one of the plurality of user computers; and

executes an action on the at least one claim using the at least one of the plurality of user computers, wherein the action comprises transmission of claim action data to the at least one remote insurance database using the at least one electronic network system.

12. The system of claim 11, further wherein the action is selected from a populated list of claim actions displayed on the visual dashboard, wherein the populated list of claim actions is based on historical claim action data.

13. The system of claim 12, wherein the populated list of claim actions is correlated to the collected multi-field medical claim data and the collected multi-field insurance claim processing data based on at least one correlation factor, wherein the at least one correlation factor is one or more of: an identity of a payer of a claim of the multi-field medical claim data, a medical clinic originating the medical claim, a medical claim code, or a payment denial reason code.

14. The system of claim 12, wherein during execution of the action on the at least one claim using the at least one of the plurality of user computers, textual data describing at least a portion of steps taken is recorded.

15. The system of claim 14, wherein the populated list of claim actions displayed on the visual dashboard is further based on the recorded textual data.

16. The system of claim 12, wherein the populated list is searchable using at least one of: textual keyword or alphanumerical code.

17. The system of claim 12, wherein after executing the action, a user provides a rating of a selected claim action from the populated list of claim actions.

18. The system of claim 11, wherein the external claim identifier comprises one or more of: a medical clinic originating the multi-field medical claim data; a payer of a claim for the multi-field medical claim data; a payment denial reason code; or an age of the at least one claim.

19. The system of claim 11, wherein a payer is associated with each remote insurance database, wherein an identifier of the payer is standardized and canonically mapped within a database on the server.

20. The system of claim 11, wherein the claims worklist is generated based on one or more of: a medical clinic originating the multi-field medical claim data; an age of the at least one claim; a payer of a claim for the multi-field medical claim data; a monetary claim balance; or a history of work on the at least one claim.