Abstract:
The system is an advanced, web-enabled, clearinghouse that facilitates efficient and effective claim routing, monitoring and report retrieval. A claim status summary is displayed that links directly to a rejected claim listing, wherein each rejected claim listed is a link to associated detailed claim information. The detailed claim information display has fields to edit the associated detailed claim information. During the editing process, a rules verification is performed against the edited claim information to ensure the edit comply with the known rules for the associated payer. Upon successfully completing the rules verification, the edited claim is submitted to a payer.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This Application claims priority benefit under 35 119(e) to U.S. Provisional Application Ser. No. 60/419,713 filed on Oct. 17, 2002 titled “System and Method for Correcting and Monitoring Status of Claims for Payment for Healthcare Services Rendered to a Patient,” which is hereby incorporated by reference in the entirety and made part hereof. 
     
    
     FIELD OF THE INVENTION 
       [0002]    This invention relates to processing health care claims, and more particularly to electronic filing, correcting, and on-line monitoring of claims for payment for healthcare services rendered to a patient. 
       BACKGROUND OF THE INVENTION 
       [0003]    The majority of healthcare providers (physicians, dentists, etc.) obtain payment for medical services provided to a patient from a payer, which is generally a healthcare organization or insurance company administering a plan for the patient&#39;s employer. The form that is submitted from the healthcare provider to the payer is called a “claim.” A claim is typically filled out by the healthcare provider. The claim should indicate all information required by the payer for payment of the healthcare provider for the service rendered to a patient. A properly completed claim typically identifies the physician that provided the service, a service identification code, the patient, the patient&#39;s group and plan number, payer identification, the amount of the claim, co-payment amount, etc. 
         [0004]    There are two primary methods by which providers may submit claims to the payers:
       1) send the claims on paper using a standard paper form called a HCFA 1500 form; or   2) send the claims electronically.
 
If the provider selects to send the claims electronically, they generally have two options:
   1) a direct method that utilizes a software application provided by a payer that only accepts claims for that payer; or   2) a clearinghouse method that utilizes a software package provided by a clearinghouse that enables a provider to submit claims to multiple payers.
 
Typically, if a provider elects to submit all or a portion of their claims electronically, they will rely on their practice management software (PMS) vendor to facilitate an interface between their electronic connectivity solution and their PMS system. The transportation of claims from the provider&#39;s office to the payer can occur via direct dial up connection using a modem or via the Internet.
       
 
         [0009]    Once the claims are submitted, the payer then checks the claims to ensure that the information contained in the claim is in proper format. For example, certain service identification codes may only be five digits and have certain values uniquely identifying the service provided. In addition, the data is checked to ensure it makes sense in context. For example, an adult male patient visiting an obstetrician for a child wellness visit would cause the payer&#39;s processing system to reject the claim. A male patient should never have need of such obstetric services, and an adult would not properly receive services in connection with a child wellness visit. These checks are implemented by the healthcare payer&#39;s claim processing system are implemented as ‘rules’ embedded in the code of the payer&#39;s claim processing system. In some cases these ‘rules’ are included in the claims submission software application that resides in the providers office, whether the provider is using the direct or clearinghouse method for submitting claims. Payers have a vested interest in improving the quality of the rule edits that reside in front of the payer&#39;s claim processing system. 
         [0010]    By editing the claims at the time of submission, the provider receives notification of any problems with the claim immediately, which enables the provider to correct the claim and resubmit the claim. This process reduces the delays in the payment process, which leads to improved provider relations and results in fewer calls from the provider to the payer&#39;s support center, thereby reducing cost for both the provider and the payer. Furthermore, by editing the claims at the time of submission, the payer avoids the expense of accepting the claim, processing the claim, and facilitating the return of the information required to correct the claim. Accepting claims that will ultimately fail in the payers system generates increased expense for the payer as well as delay in the payment of the claim. However, these edits are not easily changed once embedded in the code to accommodate rule updates, even by skilled programmers familiar with the computer language in which the rules are implemented. 
         [0011]    In addition to rejecting claims for format and contextual errors, payers may also reject claims for reasons related to patient or provider eligibility. In those cases the claim may reject because:
       1) the patient is not covered by the plan or the provider is not registered with the payer;   2) the patient or provider is not properly registered with the payer;   3) services that were rendered by the provider are not covered under the patient&#39;s payer plan;   4) the information identifying the patient or provider was submitted incorrectly; or   5) 5) the claim was filed after the timely filing deadline.
 
Furthermore, claims may reject for reasons related to authorizations. Authorizations are granted by payers to patients seeking access to specialists or providers other than their primary care provider (PCP). If the proper authorization has not been granted by the payer prior to claims submission, the claim may rejected.
       
 
         [0017]    The amount of information available to a provider about the status of their claims once they have sent them can vary dramatically, depending on the payer, the clearinghouse and the method used to submit the claims. In general there are three basic categories for the types of messages that can be returned:
       1) Claim File Acknowledgement—indicates the status of the claim file that was sent by a submitter. This report simply indicates whether or not the file was received and accepted by the payer.   2) Claim Level Acknowledgement—preliminary status that indicates whether or not a claim has passed the first phase of editing. A claim accepted at this point is not a guarantee of payment.   3) Electronic Remittance Advice (ERA)—final report indicating acceptance or denial of the claim. If the claim is accepted, in whole or in part, it will also indicate payment amounts.
 
Even when these reports are available electronically, there is no guarantee that the clearinghouse intermediary will make these reports available to the provider.
       
 
         [0021]    Even when information is available there is little or no consistency in the messages that are returned by the different payers. As an example, a provider could receive a different message for the same claim error from each of the payers to which they submit claims. In many cases the provider must contact the payer to obtain clarification about the exact cause for a claim rejecting. 
         [0022]    Once a claim is submitted from the healthcare provider to the payer, the healthcare provider often has limited information regarding the status of the claims. Therefore, the provider is unaware of problems in the processing of claims that could be remedied to obtain faster payment of the claim. 
         [0023]    What is needed is an all payer, universal system that can ensure that the appropriate format for each particular payer&#39;s requirements, the information contained within the claim conforms to the appropriate content specifications, and checks to determine the patient&#39;s and provider&#39;s ability to receive reimbursement from the payer, when such information is available. If the claim is incorrect, then the claim should be rejected at the time of submission and the provider should receive immediate notification that details the errors. 
         [0024]    Once claims in the correct form are received, the system needs to format the claims according to each payers requirements and transmit the claims. Thereafter, the payer applies its rules and either rejects or accepts the claims. This information should be readily accessible by the provider to determine a claim&#39;s status. The system should enable the provider to use these status indicators to perform summary or detailed queries as to the overall status of their billing and quickly and efficiently identify claims that require attention. Ideally, the system would allow the provider to determine the status of a claim at all stages of its processing and receive proactive reports indicating when claims have either rejected or when important information is delayed. 
       SUMMARY OF THE INVENTION 
       [0025]    The system is an advanced, web-enabled, clearinghouse that facilitates efficient and effective claim routing and report retrieval. Before claims are submitted for payment, the claims are reviewed by an internal claims editor to ensure the claims comply with known rules for that payer. As a claim proceeds through the various stages of the reimbursement cycle, each step of the claim process is captured and recorded. The system discovers new error messages and new verification rules are added to the claims editor. At times, payers provides error messages that are non-user friendly and ambiguous. These error messages make it difficult to determine the reason for a rejection. Supplementing the error code with user friendly and easy to understand messages helps staff identify the true reason for a rejection. In addition, the system performs payer profiling to identify corresponding patterns in how much correspondence to expect and the length of time to receive the associated correspondence. 
         [0026]    Generally speaking, the system receives practice identifying information over the Internet during a log on process. After a successful log into the system, a claim status summary is displayed that links directly to a rejected claim listing. In response to an activation of a rejected claim listing link, the rejected claim listing is displayed wherein each rejected claim listed is a link to associated detailed claim information. The detailed claim information display has fields to edit the associated detailed claim information. 
         [0027]    During the claim submission process, a rules verification is performed on the submitted claims to ensure the claims comply with the known rules for the associated payer. Upon successfully completing the rules verification, the edited claim is submitted to a payer. Rejected claims are identified and displayed for the user so that the errored claims can be corrected using the system 
         [0028]    After submission to the payers, the system may receive claim rejection data. This rejection information is analyzed to determine if the provided rejection code is in the claim management database. If the rejection code is not in the database, it is a new rejection code that the system has not previously encountered. The new rejection code is categorized into a general rejection category. These categories include eligibility errors, duplicate claim errors, provider enrollment errors, coding errors, patient demographic errors, and payer information errors. Categorization of these errors enable a provider to determine where the problems are occurring within their billing system. In addition, a new rejection is analyzed for possible addition of new rules to associate with that payer. Attempting to duplicate the payment rules applied by the payer facilitates rejections by the system at the time of entry of the new claims, and thus, reduces the amount of time need to process a claim and receive payment. 
         [0029]    The system captures every action related to the submission of a claim from a provider to the payer and all of the corresponding reports and messages being returned by the payer to the provider. Whenever any action occurs related to a claim the system records the name of the individual performing the action and the date and time that the action was performed. The system stores all of the aforementioned data related to a claim in a relational database so that a customer or other user can review all aspects of the claims history to identify what caused the claim to reject and where and when the error occurred. The unique cross-referenced data structure enables a provider to view all aspects of the claims life cycle from important and unique perspectives. The system&#39;s ability to organize the data in a standardized format and also allow the data to be viewed in multiple ways enables a provider to efficiently and effectively improve the percentage of claims that are paid by the payers, increase the amount paid per claim and reduce the administrative expenses for both the provider and the payer. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0030]    Benefits and further features of the present invention will be apparent from a detailed description of preferred embodiment thereof taken in conjunction with the following drawings, wherein like elements are referred to with like reference numbers, and wherein: 
           [0031]      FIG. 1  is a functional block diagram illustrating an overview of an exemplary overview of the claim management system. 
           [0032]      FIG. 2  is a functional block diagram illustrating an exemplary software architecture. 
           [0033]      FIG. 3  is a functional block diagram illustrating an exemplary system architecture. 
           [0034]      FIGS. 4A and 4B  are functional block diagrams illustrating exemplary flow charts for claim processing. 
           [0035]      FIG. 5  is a functional block diagram illustrating an exemplary table structure. 
           [0036]      FIG. 6  is a functional block diagram illustrating an exemplary table for entity reference data. 
           [0037]      FIG. 7  is a functional block diagram illustrating an exemplary table for subscriber reference data. 
           [0038]      FIG. 8  is a functional block diagram illustrating an exemplary table for payer reference data. 
           [0039]      FIG. 9  is a functional block diagram illustrating an exemplary table for patient plan reference data. 
           [0040]      FIG. 10  is a screen shot illustrating an exemplary web page for a scoreboard displaying claim statistics by numerical count. 
           [0041]      FIG. 11  is a screen shot illustrating an exemplary web page for a scoreboard displaying claim statistics by dollar value. 
           [0042]      FIG. 12  is a screen shot illustrating an exemplary web page for displaying a claim listing rejected by the claim management system. 
           [0043]      FIG. 13  is a screen shot illustrating an exemplary web page for displaying a claim listing rejected by a payer. 
           [0044]      FIG. 14  is a screen shot illustrating an exemplary web page for displaying an editable HFCA 1500 form. 
           [0045]      FIG. 15  is a screen shot illustrating an exemplary web page for displaying a claim history. 
           [0046]      FIG. 16  is a screen shot illustrating an exemplary web page for displaying an access list. 
           [0047]      FIG. 17  is a screen shot illustrating an exemplary web page for displaying an inbound file report. 
           [0048]      FIG. 18  is a screen shot illustrating an exemplary web page for displaying a rejection by a payer claim listing. 
       
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS 
       [0049]    The present claim management system is designed to provide integrated insurance claim submission, editing, and reporting. The system builds a complete record for each claim and standardizes the data. For that reason, the system captures every action related to the submission of a claim from a provider to a payer and all of the corresponding reports and messages that have been returned by the payer. Furthermore, the system stores this data related to a claim in a relational database. The unique cross-referenced data structure enables the viewing of the claim life cycle from unique perspectives. Each data table is linked such that all displays can directly provide desired information. The system&#39;s ability to organize the data in a standardized linkable format allows the data to be viewed in multiple ways that can vastly improve the percentage of claims that are paid by the payers, increase the amount paid per claim, and reduce the administrative expenses for both the provider and the payer. 
         [0050]    The system provides real time responses to claims submitted by a practice management system. The real time response allows claims to be edited at the time of submission. By processing claims at the time of submission, the provider receives instant notification about the claims. As a result, the provider can correct any claims and immediately resubmit the corrected claims. This process eliminates delays for the provider in the payment process and results in fewer calls to the payer&#39;s support center. Consequently, the present system can dramatically reduce costs associated with claim processing for both the provider and the payer. 
         [0051]    The system operates as an application service provider (ASP). Claims can be uploaded from a practice management system (PMS) or entered directly from a web site. The claim management system (CMS) checks the claims to make sure they are in the appropriate format for the particular payer&#39;s requirements and that the information contained within the claim conforms to the appropriate content specifications if the claim is incorrect, then the claim is rejected at the time of submission and the provider receives immediate notification via an online report which details the errors. At this point the provider has two options: 
         [0052]    1) correct the claims in their PMS and resubmit the claims; or 
         [0053]    2) select the rejected claims and correct the claims on-line. 
         [0000]    Once claims in the correct form are received, the CMS formats the claims according to each payers requirements and transmits the claims to the Payer. 
         [0054]    Thereafter, the payer applies its rules and either rejects or accepts the claims. This information is transmitted back to the CMS, where the information is readily accessible by the provider to determine a claim&#39;s status. 
         [0055]    The CMS reviews and categorizes the thousands of messages being returned by the various payers and assigns them a status based on the assigned rejection categorization. The general rejection categories include selecting from a group consisting of eligibility errors, duplicate claim errors, provider enrollment errors, coding errors, patient demographic errors, and payer information errors. The provider can use these status indicators to perform summary or detailed queries as to the overall status of their claims. In addition, the status summaries can provide a quick and efficient means to identify claims or billing procedures that require attention. 
         [0056]    Additionally, the CMS establishes a profile for each payer that indicates which reports are expected back and when they should be received. In the event that a report is not received within the expected time frame, the CMS notifies the provider of the delay. Hence, the provider receives proactive reports indicating when important information is delayed. 
         [0057]    Lastly, the CMS reviews all of the informational messages being returned from the payers and edits the messages to insure that the provider can determine the problem based on the message being returned from the payer. The CMS will append additional information to the messages, when appropriate, to assist the provider in determining the appropriate corrective action. The provider can use the reporting tools to generate and view reports hierarchically on claim status for claims submitted by a particular physician, a group of physicians in a practice, a specific payer, a type of payer, a patient, a date of service, a message category, a specific error message or a particular office of a multi-office practice. This information allows the provider to quickly and efficiently identify problem areas that need correction. 
         [0058]    Hence, the CMS provides the status of a claim at all stages of its processing and reports indicating when claims have either rejected or when important information is delayed. 
         [0059]    Turning to the figures, in which like numerals indicate like elements throughout the several figures,  FIG. 1  provides an overview of the claims management system (CMS)  10 . A practice management system (PMS)  20  residing on a client site computer network system  12  maintains the practice records. The client system  12  interacts with the CMS  10  to process the practice insurance claims. 
         [0060]    As shown in step A 1 , the PMS  20  uploads a claim batch file over a global computer network to a web server  14  within the CMS  10 . The uploaded files are stored using the Internet File System (IFS) schema in the CMS database as shown in step A 2 . In the next step A 3 , a production server  18  processes the claim batch files. The claims are parsed from the incoming EDI claim and set into standard ANSI ASC X12 Health Care Claim transaction set. During this processing, the system  10  ensures that the information contained within the claims conforms to the appropriate content specifications and all required information is provided. The processed claims are stored using the MGMT schema in the CMS database as shown in step A 4 . If a claim is incorrect, then the claim is rejected at the time of submission. As shown in step B 1 , a report is immediately created using the REPORT schema. All known rejections are categorized by the CMS  10  and an easy to read description is attached as part of a report. If the rejection is a new rejection, personnel associated with the CMS  10 , review the rejection to categorize the rejection and determine a readable explanation of the rejection. After receiving a rejection, generated reports will automatically provide the readable explanation of the rejection and a category determination for the rejection. Sorting rejection and status messages by categories enables a client to quickly determine where problems exist in their system. As shown by step B 2 , the web server  14  immediately generates the rejection report and displays the online report to the client system  12  as shown in step B 3  via the browser  22 . At this point, the provider can correct the claims in their PMS  20  and resubmit a batch claim or select correct the claims online. 
         [0061]    A provider at a client system  12  can access the CMS  10  by using a well-known browser application  22  such as INTERNET EXPLORER 5.5 available from Microsoft Corporation. The client system  12  can correct claims, view reports, and even submit new claims online using the browser application  22 . 
         [0062]    As shown in step C 1 , the client system  12  accesses the web server  14  within the CMS  10  using a commercially available web browser  22 . After logging into the CMS  10 , in step C 2 , web screens are accessed from the WEB repository and presented to the client system  12 . The on-line web screens enable the provider to enter new claims, edit rejected claims, and request various reports. All data provided by the web pages are linked so that a user has the ability to drill down to the information desired without the necessity of loading specific screens to view the desired information. In step C 3 , new edits are processed using MGMT schema in real time by the production server  18 . Instant feedback is provided to the client system  12 . Each edit is stored using the MGMT schema to provide a complete claim history as shown in step A 4 . 
         [0063]    Upon acceptance by the CMS, a translator  16  formats the claims into the payers format as provided in step D 1 . The translator  16  transmits the properly formatted claims over a global network to the payer computer network system  20  as shown in step D 2 . The payer system  20  applies its rules and either accepts or rejects the claims. The claim status is transmitted across a global computer network to the CMS web server  14  as shown in step D 3 . In step D 4 , the translator  16  formats the transmitted file data from the proprietary format of the payer into the standardized format utilized by the CMS  10 . As shown in step D 6 , rejections are loaded into the CMS database using the MGMT schema. If claims are accepted, the accepted claim data is loaded into the CMS database using the ERA schema as illustrated by step D 5 . Accepted claims using the ERA schema are delivered to the web server  14  as provided in step D 7  and provided to the client system  12  as shown in step E 1 . 
         [0064]    The provider can access the CMS  10  at any time to view the current claim status, view summaries and reports, edit claims, or enter claims. Because all data tables are linked using a relational database, a provider can easily determine a claim status by activating a link to the claim status without the necessity of requesting a specific web page. As a result, any claim can be easily located and directly edited. Furthermore, categorizing claims into basic rejection categories allows a provider to easily determine what problems are being experienced in the claim processing system. Knowing the number and types of problems experienced with the claim processing system will enable a provider to make corrections to their practice procedures to reduce problem occurrences. 
         [0065]      FIG. 2  discloses a logical software architecture of the CMS  10  constructed in accordance with an embodiment of the present invention. As will be understood in the art, the system is constructed utilizing Internet-enabled computer systems with computer programs designed to carry out the functions described herein. The computer programs are executed on computer systems constructed as described in reference to  FIG. 3 . Although the disclosed embodiments are generally described in reference to Internet-accessible computers, those skilled in the art will recognize that the present invention can be implemented in conjunction with other program modules for other types of computers. 
         [0066]    The disclosed embodiment of the present invention is implemented in a distributed computing environment such as the Internet. In a distributed computer environment, program modules may be physically located in different local and remote memory storage devices. Execution of the program modules may occur locally in a stand-alone manner or remotely in a client/server manner. By way of illustration and not limitation, distributed computing environments include local area networks (LAN) of an office, enterprise-wide area networks (WAN), and the global Internet (wired or wireless connections). Accordingly, it will be understood that the terms computer, operating system, and application program include all types of computers and the program modules designed to be implemented by the computers. 
         [0067]    The discussion of methods that follows, especially in the flow charts, is represented largely in terms of processes and symbolic representations of operations by conventional computer components, including a central processing unit (CPU), memory storage devices for the CPU, connected display devices, and input devices. Furthermore, these processes and operations may utilize conventional computer components in a heterogeneous distributed computing environment, including remote file servers, remote computer servers, and remote memory storage devices. Each of these conventional distributed computing components is accessible by the CPU via a communication network. 
         [0068]    The processes and operations performed by the computer include the manipulation of signals by a CPU, or remote server such as an Internet web site, and the maintenance of these signals within data structures reside in one or more of the local or remote memory storage devices. Such data structures impose a physical organization upon the collection of data stored within a memory storage device and represent specific electrical, optical, magnetic, or similar elements. These symbolic representations are the means used by those skilled in the art of computer programming and computer construction to effectively convey teachings and discoveries to others skilled in the art. 
         [0069]    For the purposes of this discussion, a process is understood to include a sequence of computer-executed steps leading to a concrete, useful, and tangible result, namely, the effecting of an integrated claim management system. 
         [0070]    These steps generally require manipulations of quantities such as claim amounts, remittance data, service dates, identifiers of claims, patients, providers, billers, and payers, and other related transactional information. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, or otherwise manipulated. It is conventional for those skilled in the art to refer to these signals as bits, bytes, words, values, elements, symbols, characters, terms, numbers, points, records, objects, images, files or the like. It should be kept in mind, however, that these and similar terms should be associated with appropriate quantities for computer operations, and that these terms are merely conventional labels applied to quantities that exist within and during operation of the computer. 
         [0071]    It should also be understood that manipulations within the computer are often referred to in terms such as displaying, deciding, storing, adding, comparing, moving, comprises, at a minimum, a processor  54 , memory  24 , and an interface unit  58  all coupled together via a bus  56 . 
         [0072]    The processor (or a plurality of central processing units)  54  executes the software modules  26 - 34 . The memory device  24  coupled to the bus  56  stores information and instructions to be executed by processor  54 . An operating system  52  provides a platform for the execution of application modules. A business administration module  26  is operable for processing access rights for the client systems  12  to the CMS  10 . A claims submission module  28  is operable for processing batch claim files transmitted submitted by practice management software  20  on the client systems  12  to the CMS  10 . A HCFA 1500 module  30  is operable for detail claim viewing, claim editing and submitting claims online. A report module  32  is operable for generating reports. A service module  34  is operable to provide links to other services related to claim processing that a provider may desire. These modules execute the various functions of the CMS as will be described in greater detail in connection with the figures that follow. 
         [0073]    The aforementioned modules interact with the CMS database  80  to perform their functions. Tables within the CMS database  80  are divided into schemas based upon functionality. The practice management reference schema (REF)  48  is used to store current active practice management information including information related to entities, patients, insurance plans, subscribers, and profiles. The claims management schema (MGMT)  38  is used to process data related to claim editing. The associated tables contain information in connection with complaints, encounters, claims, and services rendered. The claim revision repository (REPOSITORY)  36  stores any changes made to REF  48  or MGMT  38  data. The repository captures claim history data. The remittance advice schema (ERA)  46  is used to process payer responses to submitted claims to the payer for payment. The report schema (REPORT)  40  is used as a basis to generate any reports. WEB schema  44  processes the CMS web screen used to interface with the client systems. Claim batches submitted by legacy practice systems are stored and managed by the Internet claim files (IFS)  42  schema. The translator account schema (ECS)  50  is used to translate proprietary EDI files. The data described in the foregoing tables are functionally linked such that web pages viewed by the client system  12  links to desired claim information. 
         [0074]    The foregoing software architecture is executed on a computing device  18  that operates in a network environment. Operating network of the CMS  10  is illustrated in reference to  FIG. 3 . 
         [0075]      FIG. 3  illustrates an exemplary system network for the CMS  10 . The CMS  10  operates as an application service provider (ASP) over a global computer network  99  such as the Internet. The hardware devices described in reference to  FIG. 3  are well-known in the art and are commercially available. 
         [0076]    An intrusion detection system (IDS)  60 ′ inspects all inbound and outbound network activity and identifies suspicious patterns that may indicate a network or system attack from someone attempting to break into or compromise a system. All messages entering or leaving the intranet pass through a firewall  62 , which examines each message and blocks those that do not meet the specified security criteria. Another IDS  60 ″ monitors traffic within the intranet for suspicious activity. An IDS management console  78  analyzes the information provided by the IDS monitors  60  and presents this information to a network administrator. 
         [0077]    A web server  68  receives and transmits all Internet  99  communications. The web server  68  provides the CMS web pages to requesting client systems  12 . Exemplary web utilized by the CMS  10  pages are illustrated in reference to  FIGS. 10 through 18 . These web pages allow a provider to submit or edit claims, view claim statistics, or view other reports, as will be discussed in reference to the associated web pages. The data presented by the web pages are linked such that specific claim information can be obtained by activating a link from the current web page without 
         [0078]    At this point the user can select to perform several actions through the application. The user can elect to correct rejected claims that are displayed in the summary status, Step G 12 , by clicking on the number indicator representing the number of claims in error, which in turn generates a list of the rejected claims, Step G 14 . The user can then select any of the claims from the list, Step G 16 , which in turn generates a new view showing the selected claim in detail, Step G 18 , as well as showing the entire list of claims from the previous view. The user can then use various tools to determine the appropriate action to be taken to correct and resubmit, Step G 20 , the claim. 
         [0079]    As part of the resubmission process the claim is checked against known generic and specific format and content requirements, known as edits, Step G 22 , to insure that the claim has been prepared correctly. If the claim passes the edits successfully then the YES branch of Step G 22  is followed to Step G 24 . If the claim fails the edits then the NO branch of Step G 22  is followed to Step G 26  at which point the rejection is categorized and can then be displayed and made available for displaying via the Status Summary Display, Step G 14 , and through the Report Module, Step G 52 . 
         [0080]    To submit a claim file, the user would login to the application, Step  010 , and then submit a batch of claims, Step G 40 . The batch would then be processed, Step G 46 , to determine that the claims were in the appropriate formats and loaded into the database, Step G 48 . If the batch was rejected the NO branch of Step G 48  would be followed to Step G 40  so that the file could be resubmitted. 
         [0081]    Returning to Step G 22 , Following the YES branch to Step G 24  indicates that claims accepted for processing are in turn submitted to the Payers. If the payer accepts the claim batch then follow the YES branch from G 28  to G 32  to determine if the claims passed the Payers Edits. If the claims fail the payers edits then follow the No branch from G 28  to G 30  where the reason for the batch failure is investigated and resolved, at which point the file is resubmitted via Step G 28 . 
         [0082]    If the claims pass the Payers claims edits Follow the Yes Branch to G 34  indicating that a Remittance Advice will be returned to the user with detail indicating payment status for the claims. If the claim is denied on the Remittance advice then the follow the NO branch from Step G 36  to Step G 60  where the rejection reason is categorized and made available for displaying via the Status Summary Display, Step G 14 , and through the Report Module, Step G 52 . If the claim is paid then follow the YES branch from Step G 36  to Step G 38  indicating the claim is paid. 
         [0083]    Returning to the Step G 10 , after the user has logged into the application they can follow Step G 50  to develop reports in order to analyze claim rejections by multiple criteria such as provider, facility, reason code, payer, patient, etc. This is accomplished by selecting the report module Step G 52  and then utilizing report filters Step  054  to build reports. 
         [0084]    Once the selected claim is dispatched correctly a second claim is displayed from the error list for review. If the claim electing to display the or perform other activities such as submitting a batch of claims, Step G 40 , run reports, Step G 50 , or manage account privileges G 56 . 
         [0085]    For illustrative purposes lets assume that the user selects to perform all of these functions in which the claim submission module determines if a batch file processing request has been submitted by a PMS. 
         [0086]    Turn now to  FIG. 4   b , if a batch request has been submitted, the YES branch of step F 10  is followed to step F 12 . If a batch request has not been submitted, the NO branch of step F 10  is followed to step F 18 , in which web server application determines if a client system has logged into the CMS. 
         [0087]    In step F 12 , the batch claim file is processed. The proprietary EDI format is converted into a format utilized by the database engine. The PMS data is checked to ensure that the PMS authorized to use the CMS. The claims are then analyzed for format and eligibility errors. The claims are checked against standard rules and specific rules of the associated payer. For example, certain service code identification codes have only five digits and have certain values representing the service provided. More specifically, a male patient would be ineligible for obstetric services and an adult would be ineligible for pediatric services. Rejection data by a provider system is analyzed to determine if new rules should be incorporated. 
         [0088]    After applying the rules in step F 12  to the submitted claims, the claims are either accepted or rejected by the CMS in step F 14 . If the claims are rejected, the NO branch of step F 14  is followed to step F 16 . If the claims are accepted, the YES branch of step F 14  is followed to step F 42 , in which the claims are processed for submission to the payer. 
         [0089]    In step F 16 , the report module generates a report for the submitted file and provides the status of the claims and written description for all rejections. This report is transmitted over the Internet to the PMS that submitted the batch claim file. Step F 16  is followed to step F 10 , in which the system awaits another batch claim file submission. 
         [0090]    The NO branch of step F 10  is followed by step F 18 , in which the system determines if a client system has successfully logged into the CMS. If no successful login has been accomplished, the NO branch of step F 18  is followed to step F 10  awaiting a batch file submission or a successful login to the CMS. If a client system successfully logs into the CMS, the YES branch of step F 18  is followed to step F 20 , in which the CMS determines if a new claim submission is being dynamically requested. If a new claim submission has not been requested, the NO branch of step F 20  is followed to step F 26 , in which a status summary web page (“the scoreboard”) is displayed to the user. If a new claim submission has been requested, the Yes branch of step F 20  is followed to step F 22 . 
         [0091]    In step F 22 , the system generates an electronic HCFA 1500 form web page. This form is an electronic simulation of the well known standardized paper claim submission form used in the industry. This web page is illustrated in detail in reference to  FIG. 14 . The web page has data fields for the user to input the requested data or to edit the existing data. In step F 24 , the inputted data is checked against the general submission rules and any specific rules for that particular payer. Following the NO branch of step  24  to step F 22 , any input data that is not acceptable is immediately rejected and reported to the user, who can edit the information at that time. Upon proper input of all required information, the Yes branch of step F 24  is followed to step F 42 , in which the claim is processed for submission to the payer. 
         [0092]    If a new claim is not being submitted, the NO branch of step F 20  is followed to step F 26 . In step F 26 , the system provides a status summary web page (“scoreboard”) to the user. This status summary web page provides an overview of the current status of all submitted claims by that office. A detailed description of the scoreboard is provided in reference to  FIG. 10 . The scoreboard has links to other reports and links directly rejected claims listing for editing rejected claims. Step F 26  is followed by step F 28 , in which the system determines if the rejected claims listing link has been activated. 
         [0093]    If the rejected claims listing link is not activated, the NO branch of step F 28  is followed to step F 30 , in which the system determines if another report is requested. If no additional report is requested, the NO branch of step F 30  is followed to step F 18 , in which the system awaits another request. 
         [0094]    If another report is requested, step F 30  is followed by step F 32  in which the requested report is displayed. Exemplary reports are illustrated in reference to  FIGS. 10-18 . Step F 32  is followed by step F 28 , in which the system awaits another request by the user. 
         [0095]    If the rejected claims listing link is activated, the YES branch of step F 28  is followed to step F 34 , in which the system displays a listing of rejected claims. An exemplary web page providing a rejected claims listing is shown in reference to FIG.  12 . Each rejected claim listing is linked such that activation of a link presents a HFCA form 1500 for editing. Step F 34  is flowed by step F 36 , in which the system determines if a rejected claim is chosen for editing. 
         [0096]    If a rejected claim link is not activated, the NO branch of step F 36  is followed to step F 238 , in which the system awaits another request by the user. If a rejected claim link is activated, the YES branch of step F 36  is followed to step F 38 , in which the system displays a HFCA 1500 form web page for editing of the claim. Step F 38  is followed by step F 40 , in which the system analyzes the claim edits against the claim rules to determine if the claims are acceptable to submit to the payer. If the claim edits are rejected by the CMS, the NO branch of step F 40  is followed to step F 38 , in which the reason for the rejection is displayed and the claim detail web page is requesting additional edit input. If the claim edits are accepted, the YES branch of step F 40  is followed to step F 42 . 
         [0097]    In step  42 , the system transmits the claims to the payer for payment. The translator formats the data into the data format required by that particular payer. The file is then electronically transmitted over the Internet to the IP address of the payer file server. 
         [0098]    Step F 42  is followed by step F 44 , in which the CMS determines if the payer system accepts the file. If the file is formatted improperly for that payer, the payer system will reject the file. In which case the NO branch of step F 44  is followed to step, in which the reason for the rejection is determined. The analysis of the rejected file is typically accomplished manually. The translator code is then updated to conform to the standards currently required by the payer system. Step F 46  is followed by step F 48 , in which the file is reformatted and resubmitted t the payer system. Step F 48  is followed by step F 44 , in which the CMS determines if the claim file has been accepted by the payer system. 
         [0099]    If the payer system accepts the file for claim processing, the YES branch of step F 44  is followed to step F 50 , in which the CMS determines if the claim has passed a substantive review by the payer system. 
         [0100]    If the claims have passed, the YES branch of step F 50  is followed to step F 54 , in which the remittance is processed. The claim and status data is updated to reflect the payment. Step  54  is followed by step F 10 , in which the system awaits additional requests by a user. 
         [0101]    If the claims have not passed, the NO branch of step F 50  is followed to step F 52 , in which the rejection is categorized. If the rejection is a new rejection that has not been previously categorized, the claim rejection is manually analyzed. The rejection is placed into a broad rejection category and an easily readable description is attached to the claim rejection. Categorizing claims into broad rejection categories facilitate providers in determining where problems, are occurring in the claim processing system. Attaching an understandable description to the rejection facilitates provider with claim rejection edits. Step F 52  is followed by step F 54  in which the claim data is updated to reflect the rejection. Step F 54  is followed by step F 16  in which a report is transmitted to the PMS. The report includes the claim rejection, the attached rejection description, and the rejection category. Step F 16  is followed by step F 10 , in which the system awaits further requests by a user. 
         [0102]    The described data flow format describes merely an exemplary data flow process. Those skilled in the art will recognize that many variations of the above data flow can be used to accomplish the claim processing. The information used in the claim processing is stored in the CMS database 
         [0103]    Turning now to  FIG. 5 , the exemplary table structure illustrates the claim data model within the CMS. As previously discussed, tables within the CMS database have been divided into separate schemas based on functionality. Many of the tables defined within the database contain a set of common columns used for auditing and partioning purposes. These common fields include a customer_entity, record_state, modified_by, timestamp, map_code, revision_no, day, and year. The customer_entity is a unique value that has been assigned to every customer group within the database. The record_state is a single byte character that indicates the current state of the record within the table. The modified_by field tracks which user altered information on the record. The timestamp records when the record was last modified. The map_code identifies the method the record was added to a table. The revision no allows the database to hold prior versions of the record. The day and year fields indicate the day and year the record was created. These fields should never contain null values. 
         [0104]    Table suffixes are used to help the developer understand the function of the table. There are currently four different table suffixes used. A profile table (_Profile) contains information relating to an entity that is relatively static but is specific to the entity type. A settings or parameter table (_Settings and _Parameters) contains information about an entity which changes often. As the application grows, new settings can easily be added without any database structure changes occurring by inserting new records into the table. Log(_Log) tables indicate a need to track the progression of an object through the database. For example, a claim status will change as it is moved within the system hence a claim_log table. The current status will always be in the “ref” or “mgmt” table while the running history will be maintained in the “repository” table. Statistic tables (_Statistics) provide consolidated information (or metadata) about an object or entity. Unlike most other tables, statistical tables do not keep a revision history. Also it is assumed that internal processes maintain these tables so the column “modified_by” does not exist. 
         [0105]      FIG. 5  is a table structure for a claim data model. The data model illustrates tables that store information directly for the processing of claims. Other data tables (not shown) store auxiliary information for the processing of claims. The table structure illustrates the interlinking of the tables by common record columns. 
         [0000]    
       
         
               
               
             
           
               
                   
               
             
             
               
                 40-49 
                 Response from payer codes (These are not the payer&#39;s response 
               
               
                   
                 codes but rather internal codes defined by CMS) 
               
               
                 50-59 
                 Other Filing Codes 
               
               
                 60-69 
                 Outbound formatting codes 
               
               
                 70-79 
                 Not Used 
               
               
                 80-89 
                 Not Used 
               
               
                 90-99 
                 Final Claim Status 
               
               
                   
               
             
          
         
       
     
       Specific Claim Status Codes: 
     20#1 CLAIM BEING ENTERED 
     20#2 CLAIM UPDATED 
     20#5 CLAIM SUBMITTED TO CMS READY FOR EDITS 
       [0106]    20#10 EDITING claim 
       20#11 CLAIM FAILED EDIT PROCESS 
     20#12 CLAIM ACCEPTED READY TO SEND TO PAYER 
     20#13 RESUBMIT CLAIM TO PAYER 
     20#14 CLAIM CANCELLED BY SUBMITTER 
     20#15 CLAIM TRANSFERRED TO OUTBOUND STAGING AREA 
     20#20 TRANSMITTING CLAIM TO PAYER 
     20#21 CLAIM TRANSMITTED TO PAYER BY PAPER 
     20#22 CLAIM TRANSMITTED TO PAYER ELECTRONICALLY 
     20#40 PAYER ACKNOWELDGED RECEIPT 
     20#41 PAYER REPORT RECEIVED 
     20#42 REMITTANCE ADVICED RECEIVED 
     20#43 CLAIM REJECTED BY PAYER 
     20#44 CLAIM ACCEPTED BY PAYER 
     20#45 CLAIM PAYED BY PAYER 
     20#46 CLAIM DENIED BY PAYER 
     20#51 SECONDARY FILING AVAILABLE 
     20#52 TERTIARY FILING AVAILABLE 
     20#53 PATIENT FILING AVAILABLE 
     20#54 PATIENT BILLED 
     20#60 TRANSLATING CLAIM FOR PAYER 
     20#61 CLAIM WRITTEN TO OUTBOUND FILE 
     20#99 CLAIM FILING COMPLETED 
     20#91 WRITTEN OFF 
     20#92 COLLECTIONS 
     20#98 CLAIM CORRUPTED 
       [0107]    The example below illustrates the codes that may exist for a claim that has gone through the system. For simplicity only the relevant columns from tables have been shown.
 
cms_mgmt.claim_log
 
         [0000]                                            TIMESTAMP   CLAIM_ID   REVISION_NO   STATUS   COMMENTS                   08-JUN-01   123456   16   20#99   Claim filing complete                    
cms_repository.claim_log
 
         [0000]                                                                  TIMESTAMP   CLAIM_ID   REVISION_NO   STATUS   COMMENTS                                01-JUN-01   123456   1   20#1   Claim is being direct entered by                       customer       01-JUN-01   123456   2   20#1   Claim is being direct entered by                       customer       01-JUN-01   123456   3   20#5   Claim has been submitted to CMS       01-JUN-01   123456   4   20#10   Claim going through edit process       01-JUN-01   123456   5   20#11   Claim failed Edit process       03-JUN-01   123456   6   20#5   Claim fixed by customer ready                       for edit       03-JUN-01   123456   7   20#10   Claim going through edit process       03-JUN-01   123456   8   20#12   Claim passed edits       04-JUN-01   123456   9   20#60   Claim being translated for payer       04-JUN-01   123456   10   20#61   Claim written to outbound file       04-JUN-01   123456   11   20#20   Claim being sent to payer       04-JUN-01   123456   12   20#22   Claim was transmitted                       electronically       04-JUN-01   123456   13   20#40   Payer sent acknowledgement                       receipt       07-JUN-01   123456   14   20#41   Payer sent report       08-JUN-01   123456   15   20#42   Payer sent RA       08-JUN-01   123456   16   20#99   Claim filing complete               Submit Date = Timestamp of first occurrence of 20#5       Transmission Date = Timestamp of last occurrence of 20#22 or 20#23       Payer Acknowledgement = Timestamp of last occurrence of 20#40       Payer Report = Timestamp of last occurrence of 20#41       RA Received = Timestamp of last occurrence of 20#42            
In this example
 
         [0000]    
       
         
               
               
               
               
               
               
             
           
               
                   
               
               
                 CLAIM 
                 SUBMIT_DATE 
                 TRANSMISSION 
                 ACKNOWLEDGEMENT 
                 PAYER_REPORT 
                 RA 
               
               
                   
               
             
             
               
                 123456 
                 01-JUN-01 
                 04-JUN-01 
                 04-JUN-01 
                 07-JUN-01 
                 08-JUN-01 
               
               
                   
               
             
          
         
       
     
         [0108]    Related to the claim log, the MGMT.FILING_LOG table T 30  maintains a log of the of the claim filing. Filing log status codes are used to keep track of the filing process at a claim level. For claims that are submitted only once, this information is duplicated information that could be found in the claim log table. However for multiple filings of the same claim to different payers this information is unique. The code list has been assigned the “code_type” value of “21”. 
         [0109]    There are a limited number of acceptable claim filing status codes. These codes should not be confused with payer codes sent back with responses. These codes are internal generic codes used to help control processing flow: 
       21#1 READY TO SEND 
     21#2 CLAIM SENT WAITING FOR PAYER RESPONSE 
     21#3 RECEIVED PAYER RESPONSE 
     21#4 RECEIVED REMITTANCE ADVICE 
     21#5 PAYER FILING COMPLETE 
       [0110]    The example below illustrates the codes that may exist for a claim that has gone through the system. For simplicity only the relevant columns from tables have been shown. 
         [0000]    cms_mgmt.filing_log 
         [0000]                                                TIMESTAMP   CLAIM_ID   REVISION_NO   PAYER   STATUS   COMMENTS                   08-JUN-01   123456   5   5   21#5   Claim filing complete                    
cms_repository.filing_log
 
         [0000]                                                TIMESTAMP   CLAIM_ID   REVISION_NO   PAYER   STATUS   COMMENTS                   03-JUN-01   123456   1   5   21#1   Claim appears once edits       are passed       04-JUN-01   123456   2   5   21#2   Claim sent to payer       07-JUN-01   123456   3   5   21#3   Payer sent report       08-JUN-01   123456   4   5   21#4   Payer sent RA       08-JUN-01   123456   5   5   21#5   Claim filing complete                    
Had a second filing occurred for this claim, the secondary payer would have been added to the filing log and the process would be repeated. Notice in this example that payer (3) does not return payer responses or RA so those statuses were intentionally skipped.
 
cms_mgmt.filing_log
 
         [0000]                                                TIMESTAMP   CLAIM_ID   REVISION_NO   PAYER   STATUS   COMMENTS                   08-JUN-01   123456   8   3   21#5   Claim filing complete                    
cms_repository.filing_log
 
         [0000]                                                TIMESTAMP   CLAIM_ID   REVISION_NO   PAYER   STATUS   COMMENTS                   03-JUN-01   123456   1   5   21#1   Claim appears once edits       are passed       04-JUN-01   123456   2   5   21#2   Claim sent to payer       07-JUN-01   123456   3   5   21#3   Payer sent report       08-JUN-01   123456   4   5   21#4   Payer sent RA       08-JUN-01   123456   5   5   21#5   Claim filing complete       09-JUN-01   123456   6   3   21#1   New Payer secondary       filing of claim       09-JUN-01   123456   7   3   21#2   Claim sent to payer       09-JUN-01   123456   8   3   21#5   Claim filing complete                    
The MGMT.ENCOUNTERS table T 24  maintains specific information about the encounter for the claim being processed. The MGMT.COMPLAINTS table T 18  maintains specific information on patient complaints about the claim being processed. The MGMT.DATE SEGMENT table T 34  maintains date information for the encounter. The MGMT.SERVICES table T 32  maintains specific information about the services rendered by a provider for the claim being processed.
 
         [0111]    The table structure illustrated in  FIG. 5  provides the framework for storing data concerning a claim submitted by a provider. Selected tables within the claim data model claim structure are presented in reference to  FIGS. 6-9 . This data is processed by the CMS in accordance with the flow process previously outlined. 
         [0112]      FIGS. 6-9  illustrate selected tables discussed in reference to the claim data model described in  FIG. 5 . 
         [0113]      FIG. 6  illustrates a REF.ENTITY table T 10  that maintains a revision history of all defined entities with the CMS. The records associated with the table are listing in the Column Name column C 10 . The data type column C 12  provides the data type and size for the stored information within the database. The Nullable column C 14  indicates whether the associated field can be a null character. The Description column C 16  provides a written description of the record. 
         [0114]      FIG. 7  illustrates a REF.SUBSCRIBER_PAYER table T 12  that maintains specific subscriber information related to a specific payer. The records associated with the table are listing in the Column Name column C 18 . The data type column C 20  provides the data type and size for the stored information within the database. The Nullable column C 22  indicates whether the associated field can be a null character. The Description column C 24  provides a written description of the record. 
         [0115]      FIG. 8  illustrates a REF.PAYER_PROVIDER table T 14  that maintains specific payer information related to a provider. The records associated with the table are listing in the Column Name column C 26 . The data type column C 28  provides the data type and size for the stored information within the database. The Nullable column C 30  indicates whether the associated field can be a null character. The Description column C 32  provides a written description of the record. 
         [0116]      FIG. 9  illustrates a REF.PATIENTS_PLAN table T 16  that maintains specific information related to a patient&#39;s insurance plan The records associated with the table are listing in the Column Name column C 34 . The data type column C 36  provides the data type and size for the stored information within the database. The Nullable column C 38  indicates whether the associated field can be a null character. The Description column C 40  provides a written description of the record. 
         [0117]    Turning to  FIG. 10 , the screen shot illustrates an Internet web page W 100  displayed by the CMS in response to a user successfully completing the login phase into the CMS. The scoreboard web page W 100  displays the statistical information about the claims filed by the practice. Interactive web pages are well known in the art. 
         [0118]    A menu bar W 112  provides active links to various modules offered by the CMS. The Home button W 114  generates a scoreboard page W 100  for display to the requestor. The Business Admin button W 116  links to web pages that allow practice administers to set permissions for users within their practice to access or change information within the CMS. The Claim Submission button W 118  links to web pages that enable a user to submit new claim. The Report Menu button W 122  links to a web page that enable the user to select desired reports. The Services button W 122  links to a web page that provides links to services offered by other providers or to relevant information sources. The Support button W 126  links to web page that offers technical support information and support personnel contact information. display a detailed view of that claim on a HCFA 1500 web page that is illustrated in reference to  FIG. 14 . 
         [0119]    Turning to  FIG. 14 , the screen shot illustrates an Internet web page W 500  displayed by the CMS in response to a user activating a Claim ID link W 306  or W 404 . The web page W 500  present a HFCA 1500 form. The claim input fields provide the user the ability to correct and resubmit the claim. Once a claim has been corrected and resubmitted, the next rejected claim is automatically loaded into the form for correction. Claim Status Display box W 502  displays the current status of the claim. While the Claim Progress box W 504  displays information about the progress of the claim, listing the date and time that action occurred related to the claim. A History link W 506  links to a web page that display the entire claim history as illustrated in reference to  FIG. 15 . 
         [0120]    Turning to  FIG. 15 , the screen shot illustrates an Internet web page W 600  displayed by the CMS in response to a user activating the History link W 506 . The web page W 600  displays the history related to that claim in the History box W 602 . The date and time, a description of the action, and the person performing the action are displayed. Each edit or change in claim information has been recorded and is displayed. Rejection messages are displayed in red for highlight. An Access Log, link W 604  displays a web page listing of every access to information related to the claim as illustrated in reference  FIG. 16 . 
         [0121]    Turning to  FIG. 16  the screen shot illustrates an Internet web page W 700  displayed by the CMS in response to a user activating the Access link W 604 . The web page W 700  displays an Access List W 702  listing the names of all individuals who have accessed the claims. Limited access indication is used when the claim was included on a list but no clinical data was displayed. 
         [0122]    Turning to  FIG. 17 , the screen shot illustrates an In-Bound File Report W 802 . The Internet web page W 800  is displayed by the CMS in response to all claims having passed the CMS edits and indicates the status of the submitted claims. If any claims are rejected by the payer, those claims would be listed in the rejected box and highlighted in red. 
         [0123]    Turning to  FIG. 18 , the screen shot illustrates an Internet web page W 900  displayed by the CMS in response to a user activating the Count link. Activating any Claim ID link W 902  would generate and display the HFCA form web page illustrated in reference to  FIG. 14  to allow claim editing. 
         [0124]    In view of the foregoing, it will be appreciated that the present system provides an improved practice management claim processing system. It should be understood that the foregoing relates only to the exemplary embodiments of the present invention, and that numerous changes may be made therein without departing from the spirit and scope of the invention as defined by the following claims. Accordingly, it is the claims set forth below, and not merely the foregoing illustrations, which are intended to define the exclusive rights of the invention.