US20070203834A1 - System for invoice record management and asset-backed commercial paper program management - Google Patents

System for invoice record management and asset-backed commercial paper program management Download PDF

Info

Publication number
US20070203834A1
US20070203834A1 US11/786,716 US78671607A US2007203834A1 US 20070203834 A1 US20070203834 A1 US 20070203834A1 US 78671607 A US78671607 A US 78671607A US 2007203834 A1 US2007203834 A1 US 2007203834A1
Authority
US
United States
Prior art keywords
records
pool
record
accounts receivable
receivable
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/786,716
Inventor
Richard Field
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US11/786,716 priority Critical patent/US20070203834A1/en
Publication of US20070203834A1 publication Critical patent/US20070203834A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06Asset management; Financial planning or analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08Insurance
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms

Definitions

  • the present invention pertains generally to information management systems and more particularly to information management systems for use in obtaining and storing invoice records and in using these records to facilitate the creation or issuance of commercial paper backed by the receivables of medical providers or other receivable sellers, or for other purposes.
  • Asset-backed commercial paper programs (also known as “conduits”) take illiquid assets and bundle these assets into a segregated pool against which highly liquid money-market instruments can be issued.
  • the cash collected on the underlying assets in the pool is the source of repayment of principal and interest on these instruments.
  • the underlying assets are the receivables of business entities and the market instrument that is issued is commercial paper.
  • Asset-backed commercial paper programs use a financial “vehicle” called a special purpose entity (SPE) to issue commercial paper.
  • SPE special purpose entity
  • the program provides a service basically similar to that offered by a factoring company (also known as a “factor”), in that the SPE finances the receivables of corporate clients. In other respects, however, the SPE differs from a factoring company.
  • a factor assumes the role of a credit department for its clients to evaluate the credit-worthiness of the client's customers. While it finances a client's receivables by purchasing them, the SPE does not perform a credit evaluation of each obligor associated with the receivables in the pool as a factor would, but relies instead on an actuarial review of the past performance of the client's portfolio of receivables. With an SPE, the corporate client usually performs the servicing function, whereas in a factoring arrangement, the factor generally services the receivables. Asset-backed commercial paper programs are ongoing activities. The SPE continually purchases new receivables and usually “rolls over” the outstanding commercial paper.
  • FIG. 1 shows the structure and cash flows of a conventional prior art paper program 10 .
  • the program sponsor 26 reviews the receivables. The review covers the credit origination standards of the company 14 originating the receivables and current and historical quality and performance of this portfolio.
  • the asset backed commercial paper program uses an SPE 12 to acquire legal title to receivables directly from a company 14 participating in the program. To obtain funding, the SPE 12 issues commercial paper to an investment bank 16 . The investment bank 16 sells the commercial paper to investors 18 . The commercial paper is ultimately repaid by the SPE 12 from the cash flow of the underlying pools of receivables.
  • the rating agencies require that the entire amount of outstanding commercial paper be covered by liquidity and credit enhancements before the program can receive the highest investment rating. These enhancements are provided by credit enhancer 20 and liquidity provider 22 .
  • Employees of the investment banking firm 16 generally own the equity of the SPE.
  • the owner 24 of the SPE 12 receives dividends.
  • a program sponsor 26 such as a bank receives a fee.
  • Health care receivables differ in several important ways from other types of receivables that have been securitized to date.
  • Health care providers by delivering various forms of medical services, are the originators of health care receivables (also known as medical claims).
  • the bill for the services rendered may be payable entirely by the patient, entirely by some form of insurance, or partially by the patient and partially by insurance.
  • the insurance payors and the patient are the obligors on the receivable.
  • the insured portion of a health care receivable may be payable by a government program (such as Medicare), a Blue Cross/Blue Shield insurance company, a private insurance company, or a Health Maintenance Organization (HMO).
  • HMO Health Maintenance Organization
  • the face amount of the medical claim may have limited relevance to the amount the health care provider can reasonably expect to collect.
  • the reimbursement procedures for medical services are complicated. For example, Medicare might be willing to pay only a fraction of the amount billed based either on their system of diagnostic-related groups (DRGs), the use of a resource-based value scale (RBVs), or on allowable costs incurred.
  • DRGs diagnostic-related groups
  • RBVs resource-based value scale
  • Blue Cross/Blue Shield or a private insurance company might limit the amount paid to a percentage of the provider's fees and charges, or an estimate of the reasonable and customary charge for the procedure in the locality in which the medical service was rendered
  • an HMO may pay on a per diem rate or on a fixed-ee-per-person basis (capitated payment).
  • Claims paid by Medicare are also subject to the requirement that they are directly payable to the health care provider.
  • a consequence of the direct payment requirement is that Medicare payments paid to a bankrupt provider/seller might be trapped by the Bankruptcy Code's automatic stay. This risk could be reduced in a commercial paper program by making the provider set up a “bankruptcy-remote” subsidiary through which all Medicare claims are billed. The conduit can then lend money to the bankruptcy-remote subsidiary and take a senior secured position against the subsidiary's assets.
  • the present invention provides an information system to facilitate securitization of medical receivables.
  • the invention is applicable to other types of receivables as well.
  • the present invention provides a system for processing electronic medical claim records originating in one or more health care provider accounting systems, with each accounting system executing at least in part on a provider computer system at a provider location.
  • Each claim record includes (i) a date field specifying a date for the claim, and (ii) a financial data portion specifying a fee charged for services rendered to a patient.
  • the system includes means for searching the claim records and identifying records that have a date specified in the date field that is within a predetermined period.
  • the system further includes means for creating an electronic periodic pool record corresponding to all of the claim records within the period.
  • the system also includes means for recording a pool advance amount in a field of the electronic periodic pool record representing an amount to be advanced against a value of the periodic pool of claims.
  • a system for processing electronic invoice records originating in one or more goods or services provider accounting systems wherein each accounting system executes at least in part on a provider computer system at a provider location.
  • Each record includes (i) a date field specifying a date for the invoice, and (ii) a financial data portion specifying a fee charged for goods or services rendered to a customer.
  • the system includes means for searching the invoice records and identifying records that have a date within a desired range to identify a pool of invoice records representing a corresponding pool of invoices, and means for creating an electronic periodic pool record corresponding to the pool of invoice records.
  • the system further includes means for recording a pool advance amount in the electronic periodic pool record representing an amount to be advanced against a value of the pool of invoices.
  • a central processing system receiving claim or invoice records and processing those records for transmittal to a commercial paper conduit, for reconciling the records of the provider and the conduit, and for generating various reports revealing important characteristics of the performance of asset pools and the payors on those pools.
  • FIG. 1 illustrates a prior-art commercial paper program.
  • FIG. 2 illustrates an overview of a fiat exemplary embodiment of the information management system of the present invention.
  • FIG. 3 is a simplified illustration of the sources of information used by the information management system 30 of the present invention.
  • FIG. 4 is a simplified diagram showing information flow in the system of the present invention.
  • FIG. 5 illustrates the hardware configuration of the system of the present invention.
  • FIGS. 6 and 7 illustrate the software and data maintained on a receivable seller's sentinel system according to the present invention.
  • FIG. 8 illustrates the software maintained on an SPE's sentinel system according to the present invention.
  • FIGS. 9 and 10 illustrate the software and data maintained on the computer system located at the central processing location.
  • FIG. 11 illustrates the life cycle of a medical claim.
  • FIGS. 12A and 12B illustrate the fields of a typical medical claim record in a provider's accounting system.
  • FIG. 13 illustrates the formats for export of data from a computer system.
  • FIG. 14 illustrates the flow of claims through a provider's accounting system.
  • FIG. 15 illustrates the movement of claims through a provider's sentinel.
  • FIG. 16 illustrates the updating of claim data in a provider's sentinel.
  • FIG. 17 illustrates the data fields of the current financial and recently collected tables.
  • FIG. 18 illustrates the statistical analysis of historical claim data.
  • FIG. 19 illustrates a plot of a collection histogram.
  • FIG. 20 illustrates the creation of a daily pool record from medical claims.
  • FIG. 21 illustrates the formation of a daily pool and updating.
  • FIG. 22 illustrates the calculated fields of a daily pool record.
  • FIGS. 23A and 23B illustrate a master file to be transferred from a provider sentinel to the computer system at the central location.
  • FIG. 24 illustrates the determination of payor concentration.
  • FIG. 25 illustrates a collection tracking flowchart for daily pools.
  • FIG. 26 illustrates a plot of actual vs. expected collections for a pool.
  • FIG. 27 illustrates the downloading of data from a SPE computer system to the computer system at the central location.
  • FIG. 28 illustrates the data downloaded from a SPE computer system.
  • FIG. 29 illustrates the data fields maintained for the contact management system.
  • FIG. 30 illustrates the consolidation of data from several different provider locations into a consolidated daily pool at the central location.
  • FIG. 31 illustrates the fields of the payor credit table.
  • FIG. 32 illustrates the inputting of contractual data at the central location computer system.
  • FIGS. 33A and 33B illustrate the fields of a record in the trade ticket table.
  • FIG. 34 illustrates the input procedure for commercial paper data.
  • FIG. 35 illustrates the determination of daily interest expense by SPE from commercial paper.
  • FIG. 36 illustrates the total fee expense calculation.
  • FIGS. 37, 38 , 39 and 40 illustrate advance, collection, interest expense and third party fee reconciliation, respectively.
  • FIG. 41 illustrates the fields to be tracked for a balance sheet for a pool.
  • FIG. 42 illustrates allocation of SPE daily interest expense.
  • FIG. 43 illustrates daily pool fee expense calculation.
  • FIG. 44 illustrates the net receivable update.
  • FIG. 45 illustrates the payables update.
  • FIG. 46 illustrates the creation of a financial accounting report from a plurality of daily pool records.
  • FIG. 47 illustrates an asset/liability management model.
  • FIG. 48 illustrates the creation of a provider concentration report.
  • FIG. 49 illustrates the creation of a credit quality and type report.
  • FIG. 50 illustrates the determination of savings from matching a peers best collection pattern.
  • FIG. 51 illustrates the determination of the potential for improving revenue.
  • FIGS. 52A and 52B illustrate the input data, functions and output data for the system 30 at the seller's location.
  • FIG. 53 illustrates the input data, functions and output data for the system 30 at the SPE's location.
  • FIGS. 54A, 54B , 54 C and 54 D illustrate the input data, functions and output data for the system 30 at the central location.
  • FIG. 55 illustrates an alternate embodiment of the present invention using an EDI system.
  • the present invention provides an information management system 30 that supports access of a healthcare provider or other receivable seller 31 to the commercial paper market 32 through “selling” their claims to asset-backed commercial paper programs 33 (also known as “conduits”).
  • the present invention captures, manipulates, and reports all of the data necessary to support the receivable seller's participation in an asset backed commercial paper program.
  • the information management system captures and manipulates data from four sources: the receivable seller's accounting system 36 , the SPE's operating agent's accounting system 38 , the SPE's commercial paper dealer 34 , and the contract 33 between the SPE and the receivable seller 31 .
  • the information management system generates reports for the receivable seller and the SPE's operating agent.
  • Historic and current claims billing and payment data is obtained from claim records on the receivable sellers accounting system 36 (executing on the seller's mainframe or other computing system 46 ) at the sellers location 40 .
  • Data on advances, interest expense, third party fee expense, collections, settlement payments and dividends is obtained from the SPE's accounting system 38 (executing on SPE's mainframe or other computing system 66 ) at the SPE's operating agent location 60 .
  • Commercial paper information including trade date, settlement date, maturity date, par amount and discount rate are obtained from the SPE's commercial paper dealer and stored at the central location 50 .
  • the contract 33 between the SPE and the receivable seller 31 provides data on advance rates against specific types of claims and financial intermediary fees. This data is input and updated at the central location 50 and downloaded to the seller's location 40 .
  • the system processes the data in two places: at the receivable seller's location 40 and at the central location 50 .
  • the historical data is used to generate statistical data showing both the amount and timing of collections.
  • This information is forwarded to the SPE's operating agent at location 60 where it is used to establish advance rates for the various payors of the receivable seller's claims.
  • the current claims data is divided into trackable periodic units so as to be able to reconcile advances, collections, interest expense, third party fees and cash settlements between programs 33 and receivable sellers 31 .
  • expected collections on the claims in the unit are projected over time.
  • Realized collections are compared with expected collections to show the collection performance of each periodic unit.
  • the realized collections are also used to generate statistical data showing the amount and timing of collections for comparison with the historical data. All of the periodic unit data is forwarded to the central location for further processing.
  • the computer system 51 at the central location 50 uses either the actual detail or the claims detail summarized in the periodic units to perform reconciliations with the data reported by the SPE, to prepare financial statements for the individual receivable sellers 31 , to generate SPE required concentration and collection performance information and to produce comparisons between receivable sellers.
  • the central location 50 reports periodically the results of the reconciliation, the financial statements, the receivable seller specific tracking information, and the peer comparisons to the receivable seller.
  • the central location 50 also reports periodically the results of the reconciliation and the SPE required information to the SPE.
  • the information management system can handle claims from multiple receivable sellers and their corresponding accounting systems as well as multiple commercial paper programs.
  • the first exemplary embodiment of the invention is adapted for providers of healthcare who wish to sell receivables into a commercial paper program.
  • the periodic units are daily. It shall be understood, however, that the system is readily adaptable to providers of other services or goods who have accounts receivables available to sell to a commercial paper program.
  • the hardware configuration at each healthcare provider's location 40 includes a personal computer or workstation acting as a remote sentinel system 42 .
  • the currently preferred system 42 uses an Intel processor system, the “Microsoft Windows for Workgroups” operating environment, a database program comprising a runtime version of Microsoft's “Access” database program, Tools & Technologies' Data Junction program for capturing and translating data between various computer platforms, and International Software's Remote OfficeTM computer communication program.
  • Sentinel system 42 preferably has two one-gigabyte hard drives and an internal fax/modem. The second one-gigabyte hard drive mirrors the first drive and serves as a backup.
  • the sentinel system 42 is connected to the provider's local area network 44 , and can download claim records and other information directly from the provider's mainframe or other computing facility 46 , which executes the accounting system 36 .
  • the sentinel system 42 sends summary data to the central location 50 .
  • the software 43 executing on the sentinel computer 42 at the provider location 40 performs a variety of functions: capturing data from the provider's accounting system ( 43 a ), generating statistical information ( 43 b ); consolidating and updating outstanding claims into daily pools ( 43 c ), creating pools from new claims submitted by the provider ( 43 d ); calculating statistics for use in determining whether the collections on outstanding and new claims have changed enough from the analysis on which the advance rates are based to merit a revision of the advance rates ( 43 e ); contrasting payor payment performance by timing of payment; analyzing revenue by service by payor ( 43 f ); and transmitting to and receiving from the central location 50 summary data and reports ( 43 g ).
  • FIG. 7 illustrates the various tables and files of data 45 maintained in files on sentinel system 42 , to be described in more detail below.
  • system 30 can accommodate and contemplates a plurality of either SPE or provider locations connected to the central location via sentinel systems. Furthermore, the same provider may supply information to the central location 50 from more than one location 40 .
  • the preferred system configuration also includes a personal computer or workstation acting as a remote sentinel 62 in each SPE location 60 .
  • This location 60 will typically be a bank which acts as the operating agent of the SPE.
  • the sentinel system 62 preferably includes an Intel processor, the Microsoft “Windows for Workgroups” operating environment, a program comprising a runtime version of Microsoft's “Access” database program, the Data JunctionTM data capture program from Tools & Technologies, Inc. of Texas, USA, and the Remote OfficeTM remote control communication program from International Software, Inc. of Minnesota USA
  • the sentinel system 62 preferably includes two five-hundred-megabyte hard drives and an internal fax/modem. The second hard drive mirrors the first drive and serves as a backup in case the first drive fails.
  • the sentinel system 62 is interfaced to the bank's local area network 64 and can obtain information directly from the bank's mainframe or other computing facility 66 .
  • the sentinel sends summary data to central location 50 , which processes this data and generates reports. Reports, including information generated at the provider, are transmitted back to the individual SPE's operating agent.
  • the software 63 executing on the sentinel computer 62 at the SPE location 60 performs a variety of functions: capturing and storing data from the SPE's accounting system ( 63 a ), transmitting to and receiving from the central location 50 summary data ( 63 b ); and reporting program information to the SPE ( 63 c ).
  • the central location 50 processes data received from the sentinels 42 and 62 and generates all reports. The reports are transferred back to both the individual providers and the SPE's operating agents. Data from the commercial paper dealer and the contract are entered into the system 30 at the central location 50 .
  • the computer system 51 at central location 50 preferably has three types of computers.
  • An input/output computer 52 is preferably an Intel processor, with the Microsoft “Windows for Workgroups” operating environment, and a database application developed using Microsoft's “Access” database program. In addition, it preferably has one five-hundred-megabyte hard drive, a fax/modem, a remote control communication software package, preferably International Software's Remote OfficeTM, and a virus-screening package.
  • the I/O computer 52 During the time when the I/O computer 52 is communicating with other offsite computers, it is disconnected from the local area network 54 . After the I/O computer 52 has received all of the incoming data, it transfers the data to primary file server 56 for processing.
  • the primary file server 56 processes the data and transfers back reports to the computer 52 to transmit to the provider's sentinel system 42 or the SPE's sentinel system 62 .
  • Primary file server computer 56 preferably includes an Intel processor, the Microsoft “Windows for Workgroups” operating environment, a database program comprising a routine version of the Microsoft “Access” database program, and a statistics application developed using Microsoft's “Excel” spreadsheet program, It also has a one-gigabyte hard drive.
  • a second file server 58 is provided to back-up the primary file server 56 .
  • a laser printer is connected to network 54 .
  • workstations 59 are provided, which preferably include an Intel processor, Microsoft “Windows for Workgroups” operating environment and the Microsoft “Office Suite” programs. Workstations 59 preferably include five-hundred-megabyte hard drives.
  • Local area network 54 preferably utilizes the Novell network environment and is a token-ring configuration.
  • software 53 executing on the computer system 51 at the central location 50 has several functions: it receives the data from the provider and SPE sentinels 42 and 62 ( 53 a and 53 b ); it captures the data from the SPE's commercial paper dealer ( 53 c ) and the contract between SPE and provider ( 53 d ); it reconciles all of the detail and summary level data ( 53 e ); it reports a credit scoring index based on each provider's payor effectiveness index and the credit rating for the payor ( 53 l ); it generates the financial accounting statements ( 53 f ) for the individual providers by tracking daily pools ( 53 g ); it creates asset/liability management reports to monitor and control interest rate and liquidity risk ( 53 m ); it reports financial statements to individual providers ( 53 h ) and concentration and tracking statistics to SPE's ( 53 i ); it calculates performance statistics ( 53 j ), and it includes a contact management system ( 53 k ).
  • FIG. 10 receives the data from the provider and SPE sentinels
  • FIG. 11 shows the typical flow of a patient claim from origination through payment as experienced by the provider.
  • the claim begins with the assignment of a unique identification number to the patient.
  • the provider verifies that the services to be performed are covered by the patient's insurance, and the services are performed.
  • the billing department consolidates the charges for all services performed in the provider's accounting system and submits the claim to the payor.
  • the payor accepts the claim or, depending on the quality of the provider's insurance verification process, rejects the claim outright citing contractual issues or rejects specific line items in the claim.
  • FIGS. 12A and 12B illustrate typical data fields found in electronic claims records stored or originating in a provider accounting system 36 .
  • Claim records exported from accounting system 36 to sentinel system 42 preferably include substantially all the date fields illustrated in FIGS. 12A and 12B .
  • Mainframe software 110 (including, but not limited to, the accounting software executing on the mainframe) generates and manipulates these export files. Regardless of what export file language is used, the export file is accompanied by an export specification that defines what data items are in each field in the data file.
  • the file is downloaded to the sentinel 42 over the network 44 where it is captured by the sentinel system 42 using the Tools & Technologies' Data JunctionTM program.
  • the same file exporting technique is used to export data from an SPE's mainframe 66 . If a single provider tracks receivables at geographically separate locations, the system 30 employs sentinel systems 42 at each provider site 40 .
  • FIG. 14 depicts how data moves through a provider's accounting system.
  • Data is initially input into the system through several sub-accounting systems ( 36 a ).
  • Subsystems 36 a each represent, for example, a point of data input at the provider. For example, x-rays are charged for through the radiology sub-accounting system.
  • Accounting system 36 aggregates all of the information for each patient off of the sub-accounting system 36 a . This information is then stored in an electronic claim record on the computer and put onto the billing form appropriate for each third party payor involved with a specific patient. If the claim is not eligible for payment by an approved-payor, the payor field in the claim record is set to “ineligible” or the like.
  • the data can be extracted from the accounting system 36 in a batch mode.
  • the mainframe software 110 is programmed to both write this data to an export file and notify the sentinel computer system 42 of the update.
  • the sentinel system 42 then reads the export file.
  • the export file is a standardized format so that all sentinels 42 receive the provider electronic claim recorded in the same format.
  • the export data software of mainframe software 110 is thus configured to convert data from the provider's accounting system format to the standardized export format.
  • the software on sentinel 42 can convert the exported records to a standardized format upon receipt of the export file.
  • the mainframe software 110 generates an update to the export file every time an entry is made into one of the subaccounting systems 36 a feeding data into the main accounting system 36 .
  • the sentinel computer 42 reads the update and generates a claim record.
  • the claim records received in the export file are used to update and create new records in claim data tables maintained on sentinel 42 .
  • FIG. 7 which shows the tables stored on sentinel 42 , there are four tables which reflect this division: current financial table 45 c , current clinical table 45 d , recently collected table 45 b and archive table 45 a.
  • FIG. 15 shows how software 43 moves a claim between these four tables from the time it is originated to the time it is collected to the time it is statistically analyzed and permanently stored.
  • the sentinel 42 stores closed claim records in an archive table 45 a ( FIG. 7 ). If the claim status of the record is open, the financial and clinical portions are stored in a current financial record and a current clinical record, in tables 45 c and 45 d , respectively, maintained on sentinel 42 's mass storage device. If it is not an initial download, that is the provider is actively selling claims to an SPE, and the claim status is open, the claim is processed into the current financial and current clinical tables.
  • the claim is closed, it is stored in the recently collected table 45 b .
  • collection statistics on the claims in the recently collected table are generated for comparison with the collection statistics used to support the advance amounts. After this comparison, the claims are moved from the recently collected table 45 b to the archive table 45 a.
  • FIG. 16 shows in more detail how the current financial and clinical claims database tables 45 c and 45 d , respectively are created and updated. Records in table 45 c hold the financial data associated with medical claims. Records in table 45 d hold the clinical data associated with medical claims. Thus, each claim has a financial record and a clinical record associated with it.
  • FIG. 17 shows the data fields of the records in both the current financial and recently collected tables 45 c and 45 d respectively. The data for these fields is taken from the exported records ( FIGS. 12A and 12B ) from the provider's accounting system software 36 . Each claim represented in a claim record has a claim status field. This field tells whether the record represents a new claim or an update to an existing claim.
  • new corresponding financial and clinical records are created and appended to the end of the current financial and clinical tables 45 c and 45 d , respectively. If it is an update to an existing claim, the financial data portion of the claim is compared with the financial data portion of the existing claim as stored in the corresponding record of the current financial table 45 c . If the financial portion does not change, then the updated clinical portion of the record is used to replace or overwrite the existing data in the record in the current clinical table 45 d . If, upon comparison with the financial record, the amount billed doesn't change, then a new sub-record is created in the current financial table 45 c reflecting the change in the financial portion of the claim.
  • the second step in setting up a provider to use the information management system 30 is to analyze the provider's claim history. This analysis produces two different types of statistics: net collectible value and a collection histogram.
  • the payor through revision of the percentage or change in the estimate.
  • the provider by changing billing practices. There are a variety of payment practices that can be grouped under the fee schedule heading. These include payment for specific services, negotiated bid, per diem or fixed reimbursement systems. Payments under fee schedules are highly predictable because they have been pre-arranged. Usually these payment vary by diagnosis related group. Another type of payment method is the use of a capitated payment. Under this payment mechanism, the provider receives a fixed fee (capitated payment) once a month. While this payment is highly predictable, its allocation across claims is arbitrary. For purposes of a commercial paper program, it is this once-a-month payment that must be secured against. All of these different payment methods make generating a statistical analysis more complicated. Regardless of payment method, it is essential that the period selected for generating claim statistics must have payments made under the same method as payments in the future are to be made.
  • the statistical analysis of the historical claims data is preferably performed on eighteen to twenty-four months of historic collection data. This analysis begins with the calculation of the collection rate on a claim by claim basis.
  • the collection rate on an individual claim equals the amount paid on the claim divided by the amount billed on the claim.
  • net collectible value statistics are generated by examining the individual claim's collection rates on all claims in the archive table 45 a .
  • the individual collection rates are then summarized in statistics at four different level of inquiry: at the provider level; at the individual payor level; at the individual payor by diagnosis level; and at the individual payor by diagnosis by length of stay level.
  • FIG. 18 shows how a provider's historic collection data is analyzed using software 43 executing on sentinel system 42 .
  • the average net collectible value statistics are used to answer the question of if the provider has a claim against payor x of $y, how much will the provider get paid.
  • the standard deviation shows how much the collection rate for individual claims varies from the average collection rate for all claims. The smaller the standard deviation, the higher the percentage of the average collection rate the commercial paper program can fund.
  • a collection histogram answers the question of “When does the provider get paid?”
  • the histogram is generated by first calculating the collection period for already paid claims.
  • the collection period is the date the claim was paid minus the date the claim was billed.
  • the amount paid is then summed. This result is then divided by the total dollar amount collected by the provider to create a histogram showing the percentage collected by days from billing.
  • the collection histogram can also be calculated for individual payors. This is done by first calculating the collection period for already paid claims. For each collection period, the amount paid is then summed by payor. This result is then divided by the total dollar amount paid by each payor to create a series of histograms showing the percentage collected from a specific payor by days from billing.
  • the statistics are stored in collection histogram table 45 o on sentinel system 42 . An example of a plotted collection histogram is shown in FIG. 19 .
  • Software 43 uses the information calculated in both the collection rate analysis and the collection histogram creation is used to construct a payor effectiveness index.
  • an individual payor's effectiveness equals the average collection rate for the payor times the cumulative percentage of the payor's collection histogram for a specific time period divided by the average collection rate for the provider times the cumulative percentage of the provider's collection histogram for the same specific time.
  • the index number is calculated by multiplying the individual payor's effectiveness by one hundred.
  • the payor effectiveness data is saved in a payor effectiveness table 45 n .
  • the payor's effectiveness index is then reported to both the provider and the commercial paper program sponsor.
  • the report to the provider also includes two size indices.
  • the amount paid index is calculated by dividing the total amount paid by a payor by the total amount paid by all payors and then multiplying by one hundred.
  • the amount billed index is calculated by dividing the total amount billed to the payor by the total amount billed to all payors and then multiplying by one hundred.
  • the next step in bringing in a provider into the information management system 30 is the consolidation or updating of current outstanding claims and the capturing of new claims in trackable periodic units.
  • the sentinel system 42 creates daily pools out of the provider's claims data.
  • FIG. 20 illustrates generally how claim records having the same date are used to form each daily pool record.
  • new or updated claims have their financial data added to a current financial table 45 c .
  • FIG. 21 illustrates how software 43 forms this data into daily pools. All claims in a “daily pool” share the same date billed. Prior to forming the pool, the healthcare provider must select the commercial paper program that the pool is to go in to. The result of this choice determines which contractual advance rates are to be used.
  • FIG. 22 the current financial table 45 c is reviewed, and if a claim is new, the software calculates the amount advanced, the expected collections, the expected uncollectible, and the equity. These new fields are added to the claim record, and the record is added to the current financial table 45 c.
  • a daily pool record is created for each pool and stored in new daily pool table 45 g maintained on sentinel system 42 and shown in more detail in FIG. 12A .
  • new pools the sums for amount billed, amount advanced, expected uncollectible, expected collection, and equity are calculated from the claims in the pool, or obtained from claim records.
  • the expected collection pattern for the daily pool is determined by multiplying the total expected collections by the collection histogram for the pool. This data is stored in expected collection table 45 k.
  • Software 43 of the sentinel system 42 tracks changes in existing daily pools.
  • the software sums all of the changes that have occurred to the pool since the previous day. This involves calculating totals for the changes in the amount paid, contractual reductions, usual and customary reduction, and amount written-off fields from the previous day's balance.
  • Realized uncollectible is calculated for each existing daily pool by adding contractual reductions, usual and customary reduction and amount written-off.
  • the amount paid and the calculated realized uncollectible are saved in changes to existing daily pool table 45 h.
  • the total amount paid by individual payor is calculated by summing the change in amount paid for all claims by individual payor. This data is stored in the daily payor collection table 45 q.
  • FIG. 24 illustrates how software 43 calculates the percentage concentration for any payor and how compliance with the commercial paper program's restrictions is enforced.
  • the first step in calculating payor concentration is to calculate the total amount advanced to each specific payor in the current financial table 45 c . This amount is then divided by the total amount advanced to all payors. The result is the percentage exposure to each payor.
  • the commercial paper progam's maximum guidelines is then subtracted from the percentage exposure. If the results of this subtraction are greater than zero, then this payor has exceeded its limit. Where the results of the subtraction are greater than zero, the difference is multiplied by the total amount advanced to determine the amount disallowed for over concentration. The total amount of disallowance is then summed. This disallowance is stored in compliance table 45 j.
  • FIG. 25 shows how software 43 tracks collections by pool. Collections are tracked by comparing actual collections for a daily pool (as determined from financial claim records) with expected collections for that pool. The starting point for this comparison is the expected collection pattern for the pool as previously determined (see FIGS. 18 and 19 ). The expected amount collected from day of billing is then calculated by running a cumulative sun on the expected collection pattern. The total amount paid on each daily pool is then subtracted from the expected amount collected for the appropriate day from billing. The results are saved in the collection performance tracking table 45 l . The difference between expected and actual collections is also graphed and displayed or printed on sentinel system 42 by days since initial billing to be used by the provider. FIG. 26 illustrates this graphical display of actual vs. expected collections.
  • Another major requirement of a commercial paper program is that the provider engage in periodic tests to see whether the performance statistics on recently collected claims are statistically the same as the performance statistics used when the latest contractual advance rates were established.
  • the collection rates in this table are periodically statistically analyzed by software 43 .
  • the statistics are saved in the current performance statistic table 45 e.
  • Payor performance can also be measured by how quickly the payor pays on the claims.
  • a matrix can be calculated which shows all the payors for a given provider and their average days to payment. This matrix is calculated by finding the day from billing on the collection histograms for individual payors where it is estimated that fifty percent of the receivable will be collected. This day from billing is then shown for all payors.
  • Another payment analysis would be to look at the days from billing by procedure. This would involve calculating collection histograms for individual payors by procedure and then finding the day where fifty percent of the receivables have been paid. This data is saved in collection time table 45 r.
  • the line item information in a provider claim record can be used to create a revenue analysis by service by payor. This analysis involves determining how much each payor pays for a specific service. Each claim has the line item detail to show what amount was billed for a specific service and how much was paid by the payor. The revenue analysis would calculate an average payment for each service for each payor. These averages per payor could then be compared for a specific service. This type of data would be useful for subsequent negotiations with the payors. The results of these analyses are stored in revenue analysis table 45 s.
  • the sentinel system 42 transmits data to the central location daily.
  • FIGS. 23A and 23B show all of the data included in the master file 45 m that are to be transmitted daily.
  • the master file 45 m is updated daily and stored on system 42 before being transmitted.
  • the new daily pool data includes a record for the new pool formed on the day of transmission, including the date billed, amount billed, amount advanced, expected uncollectible, expected collections, and equity.
  • the expected collection histogram data contains a histogram showing the expected collection pattern for the pool.
  • the changes to existing daily pool data contains for each existing pool a record which specifies the date billed, the amount paid today, and the realized uncollectible.
  • the prior performance statistics data and the current performance statistics data contain the data for, respectively, both the archive table and the recently collected table.
  • This data includes the average collection rate, standard deviation, sum of all collection rates, sum of all collection rates squared, and the count of number of claims in the analysis.
  • the compliance data includes the total concentration disallowance.
  • the collection performance tracking data contains the graphical information which shows the difference between expected and actual collections by day from billing.
  • the daily payor collection data includes data on the amount billed by payor and the amount paid by payor.
  • the payor effectiveness data contains the payor effectiveness index.
  • the sentinel 42 receives summary data back from the central location 50 .
  • This data includes periodic updates to both the advance rates for the various conduits that the provider has contracts with as well as conduit specified payor limits.
  • the daily data received includes financial statements (balance sheet, income statement, and cash flow statement) and a collection reconciliation report showing differences between what the provider reported as amount paid and what the conduit reported as amount paid.
  • financial statements balance sheet, income statement, and cash flow statement
  • a collection reconciliation report showing differences between what the provider reported as amount paid and what the conduit reported as amount paid.
  • provider personnel can access these reports as well as a collection tracking report by payor at any time during the day.
  • the sentinel system 62 at the SPE's operating agent location 60 has two primary functions: capture commercial paper program data generated by the operating agent for transmission to the central location 50 and providing access to the operating agent for several reports generated at the central location.
  • the commercial paper program's data is also downloaded into a local sentinel 62 from the operating agent's computing system 66 before being transmitted to the central location 50 .
  • FIG. 27 shows how software 63 takes each day's records from the SPE and records them in a SPE table maintained on the sentinel system 62 for transmission to the central location 50 .
  • FIG. 28 shows the data fields captured from the SPE's mainframe 66 . This data can be downloaded as illustrated in FIG. 13 in a variety of file languages including, either ASCII or DBF.
  • the data from the SPE is already in summary form.
  • the reason that the SPE reports summary data is a function of how the data is obtained or generated by the SPE. For example, daily collection data is obtained by looking at cash receipts from individual payors made on the provider's behalf in the SPE's bank account.
  • individual provider interest expense is calculated by determining the daily interest expense for the SPE and then charging the provider for the amount of this interest expense which corresponds to the percentage of the amount advanced to the provider divided by total advances from the SPE.
  • One of the primary functions of the information management system 30 is to reconcile the summary level data from the SPE with the detail level data at the individual provider level.
  • software 53 executing on the computer system 51 at the central location 50 has several functions: it receives the data from the provider and SPE sentinels 42 and 62 ( 53 a and 53 b ); it captures the data from the SPE's commercial paper dealer ( 53 c ) and the contract between SPE and provider ( 53 d ); it reconciles all of the detail and summary level data ( 53 e ); it reports a credit scoring index based on each provider's payor effectiveness index and the credit rating for the payor ( 53 l ); it generates the financial accounting statements ( 53 g ) for the individual providers by tracking daily pools ( 53 g ); it creates asset/liability management reports to monitor and control interest rate and liquidity risk ( 53 m ); it reports financial statements ( 53 f ) to individual providers and concentration and tracking statistics ( 53 i ) to SPE's; it calculates performance statistics ( 53 j ), and it includes a contact management system ( 53 k ). As also noted above, FIG. 9 , software 53 executing on the computer
  • the contact management system executing on the central location computer system 51 keeps track of all of the parties who act as a source of information to the management information system 30 .
  • the contact system uses the data fields as shown in FIG. 29 for each SPE, provider, and commercial paper dealer.
  • four separate files 55 a , 55 b , 55 c and 55 d are set up to keep a record of the SPE/conduit, providers, commercial paper dealers, and payors respectively.
  • the file server 56 receives information from both the provider and the SPE's locations. This data is electronically transmitted from the sentinels 42 and 62 at each location. The data is received by I/O computer 52 which scans it for viruses. If no viruses are detected, this information is then passed over the network 54 to the file server 56 . The data is sent in electronic preassigned tables in an “mdb” file (Microsoft Database) with a specific provider designation on the file. The file server attaches the data in each of the preassigned tables for use in additional analyses. The preassigned tables are shown in FIG. 10 .
  • the data in the files 43 m is consolidated by central location software before further processing, as generally illustrated in FIG. 30 .
  • This consolidation is accomplished by software 53 by tracking each location separately and combining all of a provider's data together as it is needed for different calculations and reports. For example, to reconcile the amount the SPE says it advanced to the provider with the amount the provider's detail data shows should have been advanced, all of the advance amounts reported in the new daily pool table from the different locations need to be added together.
  • the file server tracks the credit rating on each individual payor's claim paying ability.
  • the payor credit table ( 55 t ) contains the data fields shown in FIG. 31 .
  • software 53 tracks the information embodied in the contract between the commercial paper program and the provider.
  • the rate at which the SPE is to advance money against receivables of specific payors is documented. This is kept track of in a table 55 o called advance rates, which also includes a provider and payor ID field.
  • the contract also documents the fees that the various financial intermediaries involved in the SPE can charge. Financial intermediaries may include banks, monoline insurers, commercial paper dealers, operating agents and SPE sponsors. This information is tracked in a table 55 p called third party fees. It also includes a provider and SPE ID field.
  • the contract specifies the maximum percentage an individual payor can represent of the claims sold to the SPE by a provider. These percentages are maintained in a table 55 q called payor limit.
  • the payor limit table 55 q also includes SPE and provider ID fields.
  • the last source of data is the commercial paper dealer.
  • This data is captured in the form of a trade ticket which is entered into a computer at the central location. As the trade ticket is entered into the computer, several additional data fields are calculated.
  • FIG. 33 shows the initially entered fields and the calculated fields.
  • FIG. 34 shows how the commercial paper information is entered using software 53 and stored in table 55 e and 55 u .
  • the commercial paper dealer is called.
  • the commercial paper trade tickets, the source of the information for table 55 e , and daily federal composite rates for various maturities, the source of the information for table 55 u are input.
  • Commercial paper variables are calculated and entered in the commercial paper table 55 e .
  • the records for each trade are entered into the daily transaction journal in the commercial paper database table 55 e .
  • the commercial paper position review and commercial paper issuance spread are recorded and reported.
  • the data from the commercial paper table 55 e is used to create daily interest expense for each SPE or conduit, as shown in FIG. 35 . This is done by summing by SPE the daily interest expense for each piece of commercial paper that has not yet mated in the conduit. If the maturity date for a commercial paper instrument is greater than or equal to the day's date, the daily interest expense by SPE is added to the sum of daily interest expense. The results are saved in the detail based daily interest expense table 55 v.
  • FIG. 36 illustrates the total fee expense calculation performed by software 53 .
  • Daily SPE fees by provider by SPE are determined by summing the financial intermediary fees (from third party fees table 55 p ) by provider by SPE and dividing by 365.
  • SPE Fee expenses equal the daily SPE fee by provider by SPE times the total advances payable to the SPE from the provider in the balance sheet.
  • the total SPE fees by conduit are equal to the sum of each provider's SPE fee expenses for that conduit. The results are saved in the detail based third party fee file 55 w.
  • Reconciliations are performed using software 53 .
  • the amount the SPEs report they advanced, stored in SPE table 55 j is compared with the amount that the provider claim detail shows they should have advanced as stored in downloaded daily pool records.
  • the funding gap equals the advance amount from the new daily pool record sent over by the provider sentinel 42 minus the total concentration disallowance from the payor concentration data sent over by the provider sentinel system 42 minus the reported advance from the daily advance data sent over by the SPE sentinel 62 .
  • the funding gap calculation is saved in a reconciliation table 55 r.
  • the amount the SPEs report they collected as specified in SPE table 55 j is compared with the amount that the provider claim detail shows they should have collected.
  • the collection gap equals the amount paid by payor in the daily payor collection data sent over in the master file 45 m (and stored in file 55 h on the system 51 ) by the provider sentinel system 42 minus the amount received from payor in the payments received data ( FIG. 28 ) sent over by the SPE sentinel system 62 .
  • the collection gap is saved in the reconciliation table 55 r.
  • the amount the SPEs report for daily interest expense is compared with the amount of daily interest expense calculated from the commercial paper table 55 e .
  • the interest expense gap equals the interest expense calculated from the commercial paper table 55 e minus interest expense as reported in the interest expense records ( FIG. 28 ) sent over by the SPE sentinel 62 .
  • the interest expense gap is saved in the reconciliation table 55 r.
  • the amount the SPEs report for daily financial intermediary (third party) fee expense is compared with the amount of daily fee expense calculated from the fee table 55 p and the daily pool balance sheets 55 k .
  • the third party fee gap equals the difference in these fees.
  • the third party fee gap is saved in the reconciliation table 55 r.
  • Software 53 does not make any adjustments for gaps uncovered when the reconciliation analysis is performed. No adjustments are made because each of these gaps should be eliminated by the responsible party within a twenty-four hour period. For example, an underadvance by the SPE yesterday can be cured by advancing more today.
  • software 53 uses I/O computer 52 , software 53 transmits the results of the reconciliation analysis stored in table 55 r to the provider sentinel 42 and the SPE sentinel 62 so that they can be reviewed.
  • the preparation of the financial accounting statements and reports involves tracking twelve data fields for each pool.
  • FIG. 41 shows these fields.
  • the financial statements for each pool are prepared daily in accordance with generally accepted accounting principals.
  • the income statement is prepared reflecting accrual accounting.
  • the financial accounting for each pool begins with the appending of data from the new daily pool data ( FIGS. 12A and 12B ) sent over by the provider sentinel 42 to the balance sheet data 55 k stored on the file server 56 .
  • interest expense and fee expense are calculated on the amount in advance payable and retained earnings and the balance sheet data 55 k is updated.
  • Software 53 looks into the changes in existing pools data sent over by the provider sentinel 42 in master file 43 m to see if there have been any collections or realized uncollectibles. If there have been, then the accounts receivable and bad debt accounts are updated in the balance sheet data 55 k . If there have been collections, then the amount of interest, fees and advances paid is calculated. The interest, fees and advance payable are then updated on the balance sheet data 55 k .
  • the process of calculating expenses, cash flow and updated balance sheets is repeated every day for the pool until the pool is closed.
  • FIGS. 42 and 36 show how interest expense and fee expense are calculated for each pool by software 53 .
  • Interest expense is calculated for each daily pool by first calculating the total of the advance payable in the balance sheet data 55 k for all the pools in a SPE. Each pool's advance payable is then divided by the total advance payable in the SPE to calculate that pool's percentage share of the interest expense. The pool's daily interest expense is then calculated by multiplying the pool's percentage share of the SPE's daily interest expense by the SPE's daily interest expense. The results are stored in the income statement data 55 l.
  • the daily financial intermediary (third party) fee expense equals the advance payable from the balance sheet data 55 k times the total of the financial intermediary fees in the contract file 182 divided by 365.
  • SPE fees for provider equal the sum of all financial intermediary fees for provider divided by 365.
  • the SPE fee expense equals the sun of the SPE fees for provider times the total advance payable to provider from the balance sheet. The results are stored in the income statement data 55 l.
  • FIG. 44 shows how accounts receivable and bad debt are updated daily for each pool.
  • the opening accounts receivable balance for each daily pool is set equal to the amount billed by the provider for the pool date.
  • the balance is reduced each day by the amount paid and the amount of the realized uncollectible for the pool.
  • the opening bad debt balance for each daily pool is set equal to the expected uncollectible amount for the pool.
  • the balance is reduced each day by the amount of the realized uncollectible for the pool.
  • the results are stored in the balance sheet data 55 k.
  • FIG. 45 shows how the accounts payable, namely advance payable, interest payable and fees payable, are updated for each daily pool balance sheet by software 53 .
  • the initial balance in the advance payable account is set equal to the amount advanced.
  • an interest expense and a fee expense are calculated.
  • the interest expense is added to interest payable on the balance sheet to create the new interest payable amount and interest paid on the cash flow statement is set equal to zero.
  • the fee expense is added to fees payable on the balance sheet to create the new fees payable amount and the fee paid on the cash flow statement is set equal to zero.
  • the collections are used to pay down accounts in the following order: interest, fees, and then advances. If the amount collected is less than today's interest expense plus the interest payable on the balance sheet, then the total amount collected is applied to interest and the new interest payable amount becomes the difference between today's interest expense plus the interest payable on the balance sheet and the amount collected. Interest paid on the cash flow statement equals the amount collected and fee paid is set equal to zero. If the amount collected is greater than or equal to that day's interest expense plus the balance in the interest payable account, then an amount equal to the interest expense plus the interest payable is used to pay off these accounts. Interest paid on the cash flow statement equals the day's interest expense plus the balance in the interest payable account.
  • Fee paid in the cash flow statement equals the excess. If the excess is greater than or equal to today's fee expense plus the balance in the fee payable account, then an amount equal to today's fee expense plus the balance in the fee payable account is used to pay off these accounts. Fee paid in the cash flow statement equals today's fee expense plus the balance in the fee payable account. If there is any remaining cash, the cash is used to pay down the advance payable account to the point where either all of the cash has been used or all of the advance payable has been paid off. The advance paid in the cash flow statement equals the reduction in the advance payable.
  • the accounting entries for each daily pool After the accounting entries for each daily pool have been created, they are used in a conventional accounting package to create financial statements for both the daily pools and the providers, as generally illustrated in FIG. 46 .
  • the financial statements are recorded in a file and transmitted back to the sentinel 42 where they are reported daily to the provider and form the basis for the provider being able to audit its participation in a commercial paper program. Included with the financial statements is a settlement analysis. This analysis looks at how much cash should be paid to the provider each day. Cash paid to provider equals cash collected the previous day less interest paid less fees paid less advances paid plus new advances.
  • the average net collectible value at the time the advance rates are set will be in the prior performance statistics table sent over by the sentinel. Changes which require a downward revision in the advance rates are detected by comparing the average net collectible value of the recently collected claims with the difference between the average net collectible value of the performance statistics supporting the current advance rates and one standard deviation from the performance statistics supporting the current advance rates. If the average net collectible value of the recently collected claims is less than or equal to the difference, then a downward revision of the advance rates is triggered.
  • the spreadsheet looks to capture changes which require an upward revision in the advance rates by comparing the average net collectible value of the recently collected claims with the sum of the average net collectible value of the performance statistics supporting the current advance rates and one standard deviation from the performance statistics supporting the current advance rates. If the average net collectible value of the recently collected claims is greater than or equal to the sum, then an upward revision of the advance rates is triggered. If the change in the average net collectible value does not exceed the trigger levels, then the advance rates remain at their present level.
  • a t-test can be used to construct a confidence interval around the average net collectible value rate. The average net collectible value rate from the recently collected data is then compared with the confidence interval to see if it falls within the confidence interval.
  • An F-test can be used to determine a confidence interval for testing changes in the standard deviation. The standard deviation of the net collectible value rate from the recently collected data is then compared with the confidence interval to see if it falls within the confidence interval.
  • a chi-squared test can be used to determine a confidence interval for testing changes in the standard deviation. The standard deviation of the net collectible value rate from the recently collected data is then compared with the confidence interval to see if it falls within the confidence interval.
  • the statistics in the prior performance statistics file are recalculated to update them for the inclusion of the recently collected claims. If the results of the tests indicate a change in the performance statistics for the recently collected records, then, after the advance rates have been changed, the statistics of the recently collected table 45 b are stored in the prior performance statistics table 45 e . Regardless of the outcome of the tests, both the provider and SPE are transmitted the results using I/O computer 52 .
  • FIG. 47 shows the asset/liability management model executed by software 53 for a commercial paper program.
  • the goal of asset/liability management is to control the provider' exposure to changes in the interest rate on, and liquidity of, commercial paper. This control is achieved by proactively managing the commercial paper being issued by the various conduits. Proactive management allows a provider to specify the funding strategy that they would like to support their receivables.
  • the first step is to estimate the cash collections on each of the daily pools. These estimates are the expected collections calculated as described above and transmitted by the provider sentinel 42 to the central location.
  • the expected collection date is calculated by adding the days from billing to the pool date.
  • the model then sums the expected collection for each daily pool by the expected collection date to generate estimated collection.
  • the second step is to estimate the cash settlement amount for each of the daily pools. This estimate begins by calculating the expected percentage collected histogram. This histogram equals the cumulative sum of the collection histograms. Next, the percentage advance for each daily pool is calculated. Percentage advance equals the advance amount divided by the difference between amount billed and expected uncollectible. Next, an estimate of the interest and fee expenses for the life of the pool is made. The estimated percent expenses is shown here as five percent but can be changed. Settlement date equals the date on the expected percentage collection histogram where the percentage collected equals or is greater than the sum of the percentage advance plus the estimated expenses. Estimated daily pool settlement amount equals the daily pool equity minus the result of multiplying the advance amount by the estimated percent expenses.
  • Total daily settlements equals the sum by day of the estimated daily pool settlement amounts for all providers in the conduit.
  • An estimate of daily cash flow can now be created.
  • Estimated daily cash flow equals estimated collections minus total paper minus total daily settlements.
  • Cumulative estimated cash flow equals the cumulative sum of estimated daily cash flow.
  • the estimated cumulative cash flow calculated in the asset/liability management is the starting point for helping a provider with its cash flow management.
  • a provider concentration report looks at the concentration of providers in any given conduit. When rating agencies review their credit rating on a specific SPE, they look for diversification in the SPE's exposure to providers.
  • FIG. 48 depicts how the provider concentration is calculated. For each individual provider in a SPE, the total advance payable to the provider from the balance sheet data 55 k are divided by the total advance payable made by the SPE. The resulting percentage represents the concentration that an individual provider is to the SPE.
  • a payor exposure report looks at the payors grouped by either credit rating or type of payor.
  • FIG. 49 depicts how these two exposure analysis are calculated by software 53 . Both exposures are calculated by first determining the concentration of each individual payor in the SPE. This is found by adding up the percentage concentration of each individual payor at each provider from the payor concentration data sent by the provider sentinel 42 and dividing this sum by the number of providers in the SPE. Exposure by credit quality is then calculated by summing the percentage of each individual payor in the SPE by the credit rating of the payor. Exposure by type of payor is calculated by summing the percentage of each individual payor in the SPE by the type of payor it is. Reports generated by software 53 are stored in an output file for transmission to the provider sentinel system 42 and the SPE sentinel system 62 .
  • the system also generates a credit scoring report.
  • the sentinel system 42 periodically sends the payor effectiveness index to the central location 50 .
  • This index measures how much of the amount billed was collected and how quickly the collection occurred.
  • the credit scoring reports shows this index next to the credit quality of the payor's claims paying ability index.
  • the credit quality index ranges from 0.1 to 1 with 0.1 being payors whose claims paying ability is deemed doubtful by the credit rating agencies and 1 being payors whose claims paying ability is deemed extremely strong by the credit rating agencies.
  • Additional reports generated for providers include a peer group comparison report which shows how the provider compared with its peers in the timing of its collections and the net collectability of its claims. These reports are used to illustrate the savings available to the provider from better management of its collections.
  • FIG. 50 shows how software 53 determines the interest savings available to the provider from collecting its receivables as quickly as its best performing peer. The best performing peer is identified as that provider which has the highest percentage of its receivables collected in ninety days. This provider's collection histogram is then compared with the provider's collection histogram to show the percentage collection difference by day over the 90 day period. Each day's difference is then multiplied by the provider's average receivables balance.
  • FIG. 51 shows the earnings available to the provider from collecting the same average amount for each diagnosis by payor as its best performing peer as determined by software 53 .
  • the best performing peer is identified for each payor as that peer which has the highest average amount paid for each diagnosis by payor.
  • This provider's average amount paid is then subtracted from each of the best performing peer average amount paid. This difference represents the potential for increased income.
  • the results of these reports are stored in a file for transmission to the provider location or for printing.
  • FIGS. 52A, 52B , 53 and 54 A-D summarize the origin, transfer and transformation of data moving through system 30 .
  • FIGS. 52A and 52B illustrate the input data, functions and output data for the system 30 at the seller's location.
  • FIG. 53 illustrates the input data, functions and output data for the system 30 at the SPE's location.
  • FIGS. 54A, 54B , 54 C and 54 D illustrate the input data, functions and output data for the system 30 at the central location.
  • the claims information is put into a standardized format.
  • One use of the data in this database is for tracking and controlling the provider's participation in a financing program.
  • This data can be analyzed to create valuable information for a variety of participants in the medical industry. For example, the data can be sorted through to generate statistics on supply usage at a given provider by diagnosis. The results of this analysis allows a provider to measure its profit margin if it is receiving capitated payments from the payors and enters into a capitated supply agreement with its suppliers.
  • the data could be aggregated across providers to analyze how drug usage patterns influence the cost of treating a specific diagnosis. Pharmaceutical companies are interested in the data from this analysis to show the benefit of their drugs in treating illnesses.
  • software 53 includes the capability to perform these functions.
  • the system 30 ′ of the present invention is set up to capture claim records from an electronic claims processor.
  • This claims processor otherwise known as an electronic data interchange agent, has terminals or computer systems 46 ′ at the offices or locations 40 ′ of physicians, clinics, rural hospitals, regional hospitals or even urban center hospitals.
  • the electronic data interchange (EDI) agent's computer system 46 ′′ receives claim data from these terminals or computer systems 46 ′ and electronically conveys it to the appropriate payor, such as an insurance company or Medicare or Medicaid.
  • the claims data from the EDI computer system 46 ′′ is transferred to a sentinel system 42 ′, where it can be processed on a provider by provider basis and summarized as described above with respect to sentinel system 42 for transmission to the computer system 51 at the central location 50 .
  • Reports can be transmitted by the central location computer system 51 directly back to computer systems 46 ′ at the locations 40 ′ using modem transmission.
  • the system 30 of the present invention is readily adaptable to provide processing for any form of accounts receivable.
  • the system can process any form of invoice representing an account receivable, such as attorneys' fees or invoices generated by an industrial supplier.
  • the invention is in no way limited to servicing medical providers or medical claims.
  • the preferred embodiments of the present invention pool claims or invoices without regard to the payor of the obligations provided that the payors for the claims or invoices are approved. It is contemplated, however, the selection of accounts receivable for each pool may be done not only on the basis of periodic units, but can also be formed or optimized according to payor. For example, certain pools may have payors which historically pay more quickly than average or a higher percentage of a billed amount that average. This optimization may be accomplished using linear programming, regression analysis or other standard statistical techniques.
  • the sentinel system 42 is independent of the provider's computer system. It shall be understood, however, that the sentinel software 43 and files and tables 45 can be adapted to execute on the provider's computer system 46 , thus eliminating the need for sentinel system 42 . However, system 42 is preferred because it avoids the necessity to adapt software 43 and files and tables 45 to each different hardware and software configuration of provider computer systems 46 . Similarly, the SPE sentinel software 63 and files can be adapted to execute on the SPE computer system 66 .
  • the central location is remotely located from the SPE and provider or receivable seller. It shall be understood, however, that the central location system 51 can be located at the location of a receivable seller or an SPE. Furthermore, the central location software 53 and files 55 can be adapted to execute and b stored on a provider or SPE computer system.

Abstract

A computerized system that will allow healthcare providers to access the commercial paper market by “selling” their patient claims to asset backed commercial paper conduits. The system generates the statistical information on the historic collection experience of the provider's claims required by both the rating agencies and the sponsors of the conduits. This statistical information has two pieces: the net collectible value matrix showing the percentage of the claim actually paid by individual payers; and a collection histogram showing the timing of the payers payments from the date of initial billing. The system also generates the accounting detail necessary for controlling and auditing the provider's participation in the commercial paper conduit program. The system tracks “periodic pools” of claims so as to be able to reconcile advances, collections, interest expense, third party fees and cash settlements between conduits and providers. This statistical information has two pieces: the net collectible value matrix showing both the percentage of the claim actually paid by individual payors and the standard deviation of this percentage; and a collection histogram showing the timing of the payors' payments from the date of initial billing.

Description

    TECHNICAL FIELD OF THE INVENTION
  • The present invention pertains generally to information management systems and more particularly to information management systems for use in obtaining and storing invoice records and in using these records to facilitate the creation or issuance of commercial paper backed by the receivables of medical providers or other receivable sellers, or for other purposes.
  • BACKGROUND OF THE INVENTION
  • Asset-backed commercial paper programs (also known as “conduits”) take illiquid assets and bundle these assets into a segregated pool against which highly liquid money-market instruments can be issued. The cash collected on the underlying assets in the pool is the source of repayment of principal and interest on these instruments. In these programs, the underlying assets are the receivables of business entities and the market instrument that is issued is commercial paper. Asset-backed commercial paper programs use a financial “vehicle” called a special purpose entity (SPE) to issue commercial paper. The program provides a service basically similar to that offered by a factoring company (also known as a “factor”), in that the SPE finances the receivables of corporate clients. In other respects, however, the SPE differs from a factoring company. Typically, a factor assumes the role of a credit department for its clients to evaluate the credit-worthiness of the client's customers. While it finances a client's receivables by purchasing them, the SPE does not perform a credit evaluation of each obligor associated with the receivables in the pool as a factor would, but relies instead on an actuarial review of the past performance of the client's portfolio of receivables. With an SPE, the corporate client usually performs the servicing function, whereas in a factoring arrangement, the factor generally services the receivables. Asset-backed commercial paper programs are ongoing activities. The SPE continually purchases new receivables and usually “rolls over” the outstanding commercial paper.
  • FIG. 1 shows the structure and cash flows of a conventional prior art paper program 10. Prior to acquiring the receivables, the program sponsor 26 reviews the receivables. The review covers the credit origination standards of the company 14 originating the receivables and current and historical quality and performance of this portfolio. The asset backed commercial paper program uses an SPE 12 to acquire legal title to receivables directly from a company 14 participating in the program. To obtain funding, the SPE 12 issues commercial paper to an investment bank 16. The investment bank 16 sells the commercial paper to investors 18. The commercial paper is ultimately repaid by the SPE 12 from the cash flow of the underlying pools of receivables. The rating agencies require that the entire amount of outstanding commercial paper be covered by liquidity and credit enhancements before the program can receive the highest investment rating. These enhancements are provided by credit enhancer 20 and liquidity provider 22. Employees of the investment banking firm 16 generally own the equity of the SPE. The owner 24 of the SPE 12 receives dividends. A program sponsor 26 such as a bank receives a fee.
  • Health care receivables differ in several important ways from other types of receivables that have been securitized to date. Health care providers, by delivering various forms of medical services, are the originators of health care receivables (also known as medical claims). The bill for the services rendered may be payable entirely by the patient, entirely by some form of insurance, or partially by the patient and partially by insurance. The insurance payors and the patient are the obligors on the receivable. The insured portion of a health care receivable may be payable by a government program (such as Medicare), a Blue Cross/Blue Shield insurance company, a private insurance company, or a Health Maintenance Organization (HMO).
  • Unlike most other types of receivables, the face amount of the medical claim may have limited relevance to the amount the health care provider can reasonably expect to collect. The reimbursement procedures for medical services are complicated. For example, Medicare might be willing to pay only a fraction of the amount billed based either on their system of diagnostic-related groups (DRGs), the use of a resource-based value scale (RBVs), or on allowable costs incurred. Similarly, Blue Cross/Blue Shield or a private insurance company might limit the amount paid to a percentage of the provider's fees and charges, or an estimate of the reasonable and customary charge for the procedure in the locality in which the medical service was rendered Finally, an HMO may pay on a per diem rate or on a fixed-ee-per-person basis (capitated payment).
  • Claims paid by Medicare are also subject to the requirement that they are directly payable to the health care provider. A consequence of the direct payment requirement is that Medicare payments paid to a bankrupt provider/seller might be trapped by the Bankruptcy Code's automatic stay. This risk could be reduced in a commercial paper program by making the provider set up a “bankruptcy-remote” subsidiary through which all Medicare claims are billed. The conduit can then lend money to the bankruptcy-remote subsidiary and take a senior secured position against the subsidiary's assets.
  • As described below, the present invention provides an information system to facilitate securitization of medical receivables. The invention is applicable to other types of receivables as well.
  • SUMMARY OF THE INVENTION
  • According to one embodiment, the present invention provides a system for processing electronic medical claim records originating in one or more health care provider accounting systems, with each accounting system executing at least in part on a provider computer system at a provider location. Each claim record includes (i) a date field specifying a date for the claim, and (ii) a financial data portion specifying a fee charged for services rendered to a patient. The system includes means for searching the claim records and identifying records that have a date specified in the date field that is within a predetermined period. The system further includes means for creating an electronic periodic pool record corresponding to all of the claim records within the period. The system also includes means for recording a pool advance amount in a field of the electronic periodic pool record representing an amount to be advanced against a value of the periodic pool of claims.
  • According to another embodiment of the present invention, there is provided a system for processing electronic invoice records originating in one or more goods or services provider accounting systems wherein each accounting system executes at least in part on a provider computer system at a provider location. Each record includes (i) a date field specifying a date for the invoice, and (ii) a financial data portion specifying a fee charged for goods or services rendered to a customer. The system includes means for searching the invoice records and identifying records that have a date within a desired range to identify a pool of invoice records representing a corresponding pool of invoices, and means for creating an electronic periodic pool record corresponding to the pool of invoice records. The system further includes means for recording a pool advance amount in the electronic periodic pool record representing an amount to be advanced against a value of the pool of invoices.
  • According to various other embodiments of the invention there is provided a central processing system receiving claim or invoice records and processing those records for transmittal to a commercial paper conduit, for reconciling the records of the provider and the conduit, and for generating various reports revealing important characteristics of the performance of asset pools and the payors on those pools.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 illustrates a prior-art commercial paper program.
  • FIG. 2 illustrates an overview of a fiat exemplary embodiment of the information management system of the present invention.
  • FIG. 3 is a simplified illustration of the sources of information used by the information management system 30 of the present invention.
  • FIG. 4 is a simplified diagram showing information flow in the system of the present invention.
  • FIG. 5 illustrates the hardware configuration of the system of the present invention.
  • FIGS. 6 and 7 illustrate the software and data maintained on a receivable seller's sentinel system according to the present invention.
  • FIG. 8 illustrates the software maintained on an SPE's sentinel system according to the present invention.
  • FIGS. 9 and 10 illustrate the software and data maintained on the computer system located at the central processing location.
  • FIG. 11 illustrates the life cycle of a medical claim.
  • FIGS. 12A and 12B illustrate the fields of a typical medical claim record in a provider's accounting system.
  • FIG. 13 illustrates the formats for export of data from a computer system.
  • FIG. 14 illustrates the flow of claims through a provider's accounting system.
  • FIG. 15 illustrates the movement of claims through a provider's sentinel.
  • FIG. 16 illustrates the updating of claim data in a provider's sentinel.
  • FIG. 17 illustrates the data fields of the current financial and recently collected tables.
  • FIG. 18 illustrates the statistical analysis of historical claim data.
  • FIG. 19 illustrates a plot of a collection histogram.
  • FIG. 20 illustrates the creation of a daily pool record from medical claims.
  • FIG. 21 illustrates the formation of a daily pool and updating.
  • FIG. 22 illustrates the calculated fields of a daily pool record.
  • FIGS. 23A and 23B illustrate a master file to be transferred from a provider sentinel to the computer system at the central location.
  • FIG. 24 illustrates the determination of payor concentration.
  • FIG. 25 illustrates a collection tracking flowchart for daily pools.
  • FIG. 26 illustrates a plot of actual vs. expected collections for a pool.
  • FIG. 27 illustrates the downloading of data from a SPE computer system to the computer system at the central location.
  • FIG. 28 illustrates the data downloaded from a SPE computer system.
  • FIG. 29 illustrates the data fields maintained for the contact management system.
  • FIG. 30 illustrates the consolidation of data from several different provider locations into a consolidated daily pool at the central location.
  • FIG. 31 illustrates the fields of the payor credit table.
  • FIG. 32 illustrates the inputting of contractual data at the central location computer system.
  • FIGS. 33A and 33B illustrate the fields of a record in the trade ticket table.
  • FIG. 34 illustrates the input procedure for commercial paper data.
  • FIG. 35 illustrates the determination of daily interest expense by SPE from commercial paper.
  • FIG. 36 illustrates the total fee expense calculation.
  • FIGS. 37, 38, 39 and 40 illustrate advance, collection, interest expense and third party fee reconciliation, respectively.
  • FIG. 41 illustrates the fields to be tracked for a balance sheet for a pool.
  • FIG. 42 illustrates allocation of SPE daily interest expense.
  • FIG. 43 illustrates daily pool fee expense calculation.
  • FIG. 44 illustrates the net receivable update.
  • FIG. 45 illustrates the payables update.
  • FIG. 46 illustrates the creation of a financial accounting report from a plurality of daily pool records.
  • FIG. 47 illustrates an asset/liability management model.
  • FIG. 48 illustrates the creation of a provider concentration report.
  • FIG. 49 illustrates the creation of a credit quality and type report.
  • FIG. 50 illustrates the determination of savings from matching a peers best collection pattern.
  • FIG. 51 illustrates the determination of the potential for improving revenue.
  • FIGS. 52A and 52B illustrate the input data, functions and output data for the system 30 at the seller's location.
  • FIG. 53 illustrates the input data, functions and output data for the system 30 at the SPE's location.
  • FIGS. 54A, 54B, 54C and 54D illustrate the input data, functions and output data for the system 30 at the central location.
  • FIG. 55 illustrates an alternate embodiment of the present invention using an EDI system.
  • DETAILED DESCRIPTION OF THE INVENTION
  • In the following detailed description of the preferred embodiment, reference is made to the accompanying drawings which form a part hereof and in which is shown, by way of illustration, an exemplary embodiment in which the invention may be practiced This embodiment is described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that structural or logical changes may be made without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims. As used herein, the terms “file” and “table” are equivalent.
  • Overview
  • As shown in FIGS. 2, 3, 4, and 5, the present invention provides an information management system 30 that supports access of a healthcare provider or other receivable seller 31 to the commercial paper market 32 through “selling” their claims to asset-backed commercial paper programs 33 (also known as “conduits”). The present invention captures, manipulates, and reports all of the data necessary to support the receivable seller's participation in an asset backed commercial paper program.
  • The information management system captures and manipulates data from four sources: the receivable seller's accounting system 36, the SPE's operating agent's accounting system 38, the SPE's commercial paper dealer 34, and the contract 33 between the SPE and the receivable seller 31. The information management system generates reports for the receivable seller and the SPE's operating agent.
  • Data flows into the system in three places: at the receivable seller's location 40, at the SPE's operating agent location 60 and at a central location 50. Historic and current claims billing and payment data is obtained from claim records on the receivable sellers accounting system 36 (executing on the seller's mainframe or other computing system 46) at the sellers location 40. Data on advances, interest expense, third party fee expense, collections, settlement payments and dividends is obtained from the SPE's accounting system 38 (executing on SPE's mainframe or other computing system 66) at the SPE's operating agent location 60. Commercial paper information including trade date, settlement date, maturity date, par amount and discount rate are obtained from the SPE's commercial paper dealer and stored at the central location 50. The contract 33 between the SPE and the receivable seller 31 provides data on advance rates against specific types of claims and financial intermediary fees. This data is input and updated at the central location 50 and downloaded to the seller's location 40.
  • The system processes the data in two places: at the receivable seller's location 40 and at the central location 50. At the receivable seller's place, the historical data is used to generate statistical data showing both the amount and timing of collections. This information is forwarded to the SPE's operating agent at location 60 where it is used to establish advance rates for the various payors of the receivable seller's claims. On an ongoing basis, the current claims data is divided into trackable periodic units so as to be able to reconcile advances, collections, interest expense, third party fees and cash settlements between programs 33 and receivable sellers 31. When a periodic unit is formed, expected collections on the claims in the unit are projected over time. As the claims in the unit are paid off, this information is also gathered Realized collections are compared with expected collections to show the collection performance of each periodic unit. The realized collections are also used to generate statistical data showing the amount and timing of collections for comparison with the historical data. All of the periodic unit data is forwarded to the central location for further processing.
  • The computer system 51 at the central location 50 uses either the actual detail or the claims detail summarized in the periodic units to perform reconciliations with the data reported by the SPE, to prepare financial statements for the individual receivable sellers 31, to generate SPE required concentration and collection performance information and to produce comparisons between receivable sellers. The central location 50 reports periodically the results of the reconciliation, the financial statements, the receivable seller specific tracking information, and the peer comparisons to the receivable seller. The central location 50 also reports periodically the results of the reconciliation and the SPE required information to the SPE.
  • The information management system can handle claims from multiple receivable sellers and their corresponding accounting systems as well as multiple commercial paper programs.
  • First Exemplary Embodiment
  • As described in detail below, the first exemplary embodiment of the invention is adapted for providers of healthcare who wish to sell receivables into a commercial paper program. In this embodiment, the periodic units are daily. It shall be understood, however, that the system is readily adaptable to providers of other services or goods who have accounts receivables available to sell to a commercial paper program.
  • System Configuration Provider Location
  • As shown in FIG. 5, which illustrates the first exemplary embodiment of system 30, the hardware configuration at each healthcare provider's location 40 includes a personal computer or workstation acting as a remote sentinel system 42. The currently preferred system 42 uses an Intel processor system, the “Microsoft Windows for Workgroups” operating environment, a database program comprising a runtime version of Microsoft's “Access” database program, Tools & Technologies' Data Junction program for capturing and translating data between various computer platforms, and International Software's Remote Office™ computer communication program. Sentinel system 42 preferably has two one-gigabyte hard drives and an internal fax/modem. The second one-gigabyte hard drive mirrors the first drive and serves as a backup. The sentinel system 42 is connected to the provider's local area network 44, and can download claim records and other information directly from the provider's mainframe or other computing facility 46, which executes the accounting system 36. The sentinel system 42 sends summary data to the central location 50.
  • As illustrated in FIG. 6, the software 43 executing on the sentinel computer 42 at the provider location 40 performs a variety of functions: capturing data from the provider's accounting system (43 a), generating statistical information (43 b); consolidating and updating outstanding claims into daily pools (43 c), creating pools from new claims submitted by the provider (43 d); calculating statistics for use in determining whether the collections on outstanding and new claims have changed enough from the analysis on which the advance rates are based to merit a revision of the advance rates (43 e); contrasting payor payment performance by timing of payment; analyzing revenue by service by payor (43 f); and transmitting to and receiving from the central location 50 summary data and reports (43 g). FIG. 7 illustrates the various tables and files of data 45 maintained in files on sentinel system 42, to be described in more detail below.
  • Although only one provider location 40 and SPE location 60 is shown in FIG. 5 for brevity, system 30 can accommodate and contemplates a plurality of either SPE or provider locations connected to the central location via sentinel systems. Furthermore, the same provider may supply information to the central location 50 from more than one location 40.
  • SPE Location
  • The preferred system configuration also includes a personal computer or workstation acting as a remote sentinel 62 in each SPE location 60. This location 60 will typically be a bank which acts as the operating agent of the SPE. The sentinel system 62 preferably includes an Intel processor, the Microsoft “Windows for Workgroups” operating environment, a program comprising a runtime version of Microsoft's “Access” database program, the Data Junction™ data capture program from Tools & Technologies, Inc. of Texas, USA, and the Remote Office™ remote control communication program from International Software, Inc. of Minnesota USA The sentinel system 62 preferably includes two five-hundred-megabyte hard drives and an internal fax/modem. The second hard drive mirrors the first drive and serves as a backup in case the first drive fails. The sentinel system 62 is interfaced to the bank's local area network 64 and can obtain information directly from the bank's mainframe or other computing facility 66. The sentinel sends summary data to central location 50, which processes this data and generates reports. Reports, including information generated at the provider, are transmitted back to the individual SPE's operating agent.
  • As illustrated in FIG. 8, the software 63 executing on the sentinel computer 62 at the SPE location 60 performs a variety of functions: capturing and storing data from the SPE's accounting system (63 a), transmitting to and receiving from the central location 50 summary data (63 b); and reporting program information to the SPE (63 c).
  • Central Location
  • The central location 50 processes data received from the sentinels 42 and 62 and generates all reports. The reports are transferred back to both the individual providers and the SPE's operating agents. Data from the commercial paper dealer and the contract are entered into the system 30 at the central location 50. The computer system 51 at central location 50 preferably has three types of computers. An input/output computer 52 is preferably an Intel processor, with the Microsoft “Windows for Workgroups” operating environment, and a database application developed using Microsoft's “Access” database program. In addition, it preferably has one five-hundred-megabyte hard drive, a fax/modem, a remote control communication software package, preferably International Software's Remote Office™, and a virus-screening package. During the time when the I/O computer 52 is communicating with other offsite computers, it is disconnected from the local area network 54. After the I/O computer 52 has received all of the incoming data, it transfers the data to primary file server 56 for processing. The primary file server 56 processes the data and transfers back reports to the computer 52 to transmit to the provider's sentinel system 42 or the SPE's sentinel system 62. Primary file server computer 56 preferably includes an Intel processor, the Microsoft “Windows for Workgroups” operating environment, a database program comprising a routine version of the Microsoft “Access” database program, and a statistics application developed using Microsoft's “Excel” spreadsheet program, It also has a one-gigabyte hard drive. A second file server 58 is provided to back-up the primary file server 56. It has the same configuration as the primary file server 56 with the addition of a tape backup unit, and receives the same information as the primary file server 56. A laser printer is connected to network 54. Finally, workstations 59 are provided, which preferably include an Intel processor, Microsoft “Windows for Workgroups” operating environment and the Microsoft “Office Suite” programs. Workstations 59 preferably include five-hundred-megabyte hard drives. Local area network 54 preferably utilizes the Novell network environment and is a token-ring configuration. Although only one provider location 40 and SPE location 60 are illustrated, the system may, and is contemplated to, include a plurality of locations 40 and 60 interfaced to I/O computer 52 through multiple corresponding sentinels 42 and 62.
  • As illustrated in FIG. 9 and to be explained in more detail below, software 53 executing on the computer system 51 at the central location 50 has several functions: it receives the data from the provider and SPE sentinels 42 and 62 (53 a and 53 b); it captures the data from the SPE's commercial paper dealer (53 c) and the contract between SPE and provider (53 d); it reconciles all of the detail and summary level data (53 e); it reports a credit scoring index based on each provider's payor effectiveness index and the credit rating for the payor (53 l); it generates the financial accounting statements (53 f) for the individual providers by tracking daily pools (53 g); it creates asset/liability management reports to monitor and control interest rate and liquidity risk (53 m); it reports financial statements to individual providers (53 h) and concentration and tracking statistics to SPE's (53 i); it calculates performance statistics (53 j), and it includes a contact management system (53 k). FIG. 10 illumes various tables and files 55 maintained on the file serve 56 at the central location 50, to be described below.
  • Provider Sentinel Functions Capturing Claim Data
  • The first steps in implementing a commercial paper program, both in setting up the program and in running it on a day-to-day basis, is capturing claim data from the provider's accounting system 36. FIG. 11 shows the typical flow of a patient claim from origination through payment as experienced by the provider. The claim begins with the assignment of a unique identification number to the patient. The provider then verifies that the services to be performed are covered by the patient's insurance, and the services are performed. The billing department consolidates the charges for all services performed in the provider's accounting system and submits the claim to the payor. The payor accepts the claim or, depending on the quality of the provider's insurance verification process, rejects the claim outright citing contractual issues or rejects specific line items in the claim. If the claim is rejected, it goes back to the billing department where, if appropriate, it is modified for resubmission. After acceptance by the payor, the claim is then discounted for contractual adjustments, and paid. FIGS. 12A and 12B illustrate typical data fields found in electronic claims records stored or originating in a provider accounting system 36. Claim records exported from accounting system 36 to sentinel system 42 preferably include substantially all the date fields illustrated in FIGS. 12A and 12B.
  • FIG. 13 shows data structures for export files that can be used to export claim records or other information from the provider's accounting system 36 across the local a=re network 44 to the sentinel computer 42. Mainframe software 110 (including, but not limited to, the accounting software executing on the mainframe) generates and manipulates these export files. Regardless of what export file language is used, the export file is accompanied by an export specification that defines what data items are in each field in the data file. The file is downloaded to the sentinel 42 over the network 44 where it is captured by the sentinel system 42 using the Tools & Technologies' Data Junction™ program. The same file exporting technique is used to export data from an SPE's mainframe 66. If a single provider tracks receivables at geographically separate locations, the system 30 employs sentinel systems 42 at each provider site 40.
  • FIG. 14 depicts how data moves through a provider's accounting system. Data is initially input into the system through several sub-accounting systems (36 a). Subsystems 36 a each represent, for example, a point of data input at the provider. For example, x-rays are charged for through the radiology sub-accounting system. Accounting system 36 aggregates all of the information for each patient off of the sub-accounting system 36 a. This information is then stored in an electronic claim record on the computer and put onto the billing form appropriate for each third party payor involved with a specific patient. If the claim is not eligible for payment by an approved-payor, the payor field in the claim record is set to “ineligible” or the like. There are two primary places in this flow of information through the accounting system to capture claim data for export by the provide's mainframe 46. First, the data can be extracted from the accounting system 36 in a batch mode. When the accounting system 36 is updated for new claims, payments on existing claims or other changes, the new or updated claims are flagged and the mainframe software 110 is programmed to both write this data to an export file and notify the sentinel computer system 42 of the update. The sentinel system 42 then reads the export file. Preferably, the export file is a standardized format so that all sentinels 42 receive the provider electronic claim recorded in the same format. The export data software of mainframe software 110 is thus configured to convert data from the provider's accounting system format to the standardized export format. Alternatively, the software on sentinel 42 can convert the exported records to a standardized format upon receipt of the export file.
  • Second, as an alternative embodiment, the mainframe software 110 generates an update to the export file every time an entry is made into one of the subaccounting systems 36 a feeding data into the main accounting system 36. The sentinel computer 42 reads the update and generates a claim record. In initial installations of the information management system 30, it is preferred that it capture data that has been generated in a batch mode. As the SPE's gain experience handling medical receivables, there will be a greater inclination to finance the claims as they are being generated. When this occurs, the claims are, if desired, captured directly from the subaccounting systems 36 a at the time they are created.
  • Downloading of Claim Data into Provider Sentinel
  • After the provider's mainframe software 110 has transmitted the claim data to the export file and the sentinel system 42 has read the export file in, the claim records received in the export file are used to update and create new records in claim data tables maintained on sentinel 42. Referring to FIG. 7, which shows the tables stored on sentinel 42, there are four tables which reflect this division: current financial table 45 c, current clinical table 45 d, recently collected table 45 b and archive table 45 a.
  • FIG. 15 shows how software 43 moves a claim between these four tables from the time it is originated to the time it is collected to the time it is statistically analyzed and permanently stored. When a provider's claims are initially loaded on to the sentinel system 42, the sentinel 42 stores closed claim records in an archive table 45 a (FIG. 7). If the claim status of the record is open, the financial and clinical portions are stored in a current financial record and a current clinical record, in tables 45 c and 45 d, respectively, maintained on sentinel 42's mass storage device. If it is not an initial download, that is the provider is actively selling claims to an SPE, and the claim status is open, the claim is processed into the current financial and current clinical tables. If the claim is closed, it is stored in the recently collected table 45 b. Periodically, collection statistics on the claims in the recently collected table are generated for comparison with the collection statistics used to support the advance amounts. After this comparison, the claims are moved from the recently collected table 45 b to the archive table 45 a.
  • FIG. 16 shows in more detail how the current financial and clinical claims database tables 45 c and 45 d, respectively are created and updated. Records in table 45 c hold the financial data associated with medical claims. Records in table 45 d hold the clinical data associated with medical claims. Thus, each claim has a financial record and a clinical record associated with it. FIG. 17 shows the data fields of the records in both the current financial and recently collected tables 45 c and 45 d respectively. The data for these fields is taken from the exported records (FIGS. 12A and 12B) from the provider's accounting system software 36. Each claim represented in a claim record has a claim status field. This field tells whether the record represents a new claim or an update to an existing claim. If it is a new claim, new corresponding financial and clinical records are created and appended to the end of the current financial and clinical tables 45 c and 45 d, respectively. If it is an update to an existing claim, the financial data portion of the claim is compared with the financial data portion of the existing claim as stored in the corresponding record of the current financial table 45 c. If the financial portion does not change, then the updated clinical portion of the record is used to replace or overwrite the existing data in the record in the current clinical table 45 d. If, upon comparison with the financial record, the amount billed doesn't change, then a new sub-record is created in the current financial table 45 c reflecting the change in the financial portion of the claim. If the amount billed increases, then a new claim record is created in the current financial table 45 c reflecting the amount of the increase. If the amount billed decreases, then the amount written-off is increased in the corresponding field of the corresponding record in the current financial table 45 c.
  • Generation of Collection Statistics on Previously Collected Claims
  • The second step in setting up a provider to use the information management system 30 is to analyze the provider's claim history. This analysis produces two different types of statistics: net collectible value and a collection histogram.
  • As noted earlier, there are a variety of payment mechanisms used by the payers. Each of the different payment techniques has a different impact on predicting the net collectible value of a given claim. Payments based on diagnosis related groups (DRGs) tend to be a constant dollar amount for each DRG. This improves predictability by reducing the variation in payment amounts to virtually zero. Like DRG based payments, payments under a resource based value scale also tend to show little variation. This occurs because under this system of payments there are price caps on each of the services the provider performs. Payments made under either a percentage of provider's fees and charges or an estimate of usual and customary fees exhibit a much wider variation. Under both of these methods, both the payor and provider contribute to the variation. The payor through revision of the percentage or change in the estimate. The provider by changing billing practices. There are a variety of payment practices that can be grouped under the fee schedule heading. These include payment for specific services, negotiated bid, per diem or fixed reimbursement systems. Payments under fee schedules are highly predictable because they have been pre-arranged. Usually these payment vary by diagnosis related group. Another type of payment method is the use of a capitated payment. Under this payment mechanism, the provider receives a fixed fee (capitated payment) once a month. While this payment is highly predictable, its allocation across claims is arbitrary. For purposes of a commercial paper program, it is this once-a-month payment that must be secured against. All of these different payment methods make generating a statistical analysis more complicated. Regardless of payment method, it is essential that the period selected for generating claim statistics must have payments made under the same method as payments in the future are to be made.
  • The statistical analysis of the historical claims data is preferably performed on eighteen to twenty-four months of historic collection data. This analysis begins with the calculation of the collection rate on a claim by claim basis. The collection rate on an individual claim equals the amount paid on the claim divided by the amount billed on the claim. Initially, net collectible value statistics are generated by examining the individual claim's collection rates on all claims in the archive table 45 a. The individual collection rates are then summarized in statistics at four different level of inquiry: at the provider level; at the individual payor level; at the individual payor by diagnosis level; and at the individual payor by diagnosis by length of stay level. At each of these levels, an average, a standard deviation, a minimum value, a maximum value, a sum of the collection rates, a sum of the square of the collection rates and a count of the number of claims is calculated. They are saved in a table 45 e called prior performance statistics. FIG. 18 shows how a provider's historic collection data is analyzed using software 43 executing on sentinel system 42.
  • The average net collectible value statistics are used to answer the question of if the provider has a claim against payor x of $y, how much will the provider get paid. The standard deviation shows how much the collection rate for individual claims varies from the average collection rate for all claims. The smaller the standard deviation, the higher the percentage of the average collection rate the commercial paper program can fund.
  • A collection histogram answers the question of “When does the provider get paid?” The histogram is generated by first calculating the collection period for already paid claims. The collection period is the date the claim was paid minus the date the claim was billed. For each collection period, the amount paid is then summed. This result is then divided by the total dollar amount collected by the provider to create a histogram showing the percentage collected by days from billing. The collection histogram can also be calculated for individual payors. This is done by first calculating the collection period for already paid claims. For each collection period, the amount paid is then summed by payor. This result is then divided by the total dollar amount paid by each payor to create a series of histograms showing the percentage collected from a specific payor by days from billing. The statistics are stored in collection histogram table 45 o on sentinel system 42. An example of a plotted collection histogram is shown in FIG. 19.
  • Software 43 uses the information calculated in both the collection rate analysis and the collection histogram creation is used to construct a payor effectiveness index. Within a given provider, an individual payor's effectiveness equals the average collection rate for the payor times the cumulative percentage of the payor's collection histogram for a specific time period divided by the average collection rate for the provider times the cumulative percentage of the provider's collection histogram for the same specific time. The index number is calculated by multiplying the individual payor's effectiveness by one hundred. The payor effectiveness data is saved in a payor effectiveness table 45 n. The payor's effectiveness index is then reported to both the provider and the commercial paper program sponsor. The report to the provider also includes two size indices. The amount paid index is calculated by dividing the total amount paid by a payor by the total amount paid by all payors and then multiplying by one hundred. The amount billed index is calculated by dividing the total amount billed to the payor by the total amount billed to all payors and then multiplying by one hundred.
  • Formation and Updating of Daily Pools
  • The next step in bringing in a provider into the information management system 30 is the consolidation or updating of current outstanding claims and the capturing of new claims in trackable periodic units. For example, for large providers, the sentinel system 42 creates daily pools out of the provider's claims data. FIG. 20 illustrates generally how claim records having the same date are used to form each daily pool record. As described above, new or updated claims have their financial data added to a current financial table 45 c. FIG. 21 illustrates how software 43 forms this data into daily pools. All claims in a “daily pool” share the same date billed. Prior to forming the pool, the healthcare provider must select the commercial paper program that the pool is to go in to. The result of this choice determines which contractual advance rates are to be used. Then, four additional data fields are calculated for each claim. These fields are shown in FIG. 22. As illustrated in FIG. 21, the current financial table 45 c is reviewed, and if a claim is new, the software calculates the amount advanced, the expected collections, the expected uncollectible, and the equity. These new fields are added to the claim record, and the record is added to the current financial table 45 c.
  • A daily pool record is created for each pool and stored in new daily pool table 45 g maintained on sentinel system 42 and shown in more detail in FIG. 12A. For new pools, the sums for amount billed, amount advanced, expected uncollectible, expected collection, and equity are calculated from the claims in the pool, or obtained from claim records. Next the expected collection pattern for the daily pool is determined by multiplying the total expected collections by the collection histogram for the pool. This data is stored in expected collection table 45 k.
  • Software 43 of the sentinel system 42 tracks changes in existing daily pools. The software sums all of the changes that have occurred to the pool since the previous day. This involves calculating totals for the changes in the amount paid, contractual reductions, usual and customary reduction, and amount written-off fields from the previous day's balance. Realized uncollectible is calculated for each existing daily pool by adding contractual reductions, usual and customary reduction and amount written-off. The amount paid and the calculated realized uncollectible are saved in changes to existing daily pool table 45 h.
  • The total amount paid by individual payor is calculated by summing the change in amount paid for all claims by individual payor. This data is stored in the daily payor collection table 45 q.
  • Commercial paper programs set restrictions on the exposure to any credit risk that the program will take on. This exposure is usually handled by limiting the percentage that any credit can be of the total credit extended. When each pool is formed, the credit exposure is recalculated. FIG. 24 illustrates how software 43 calculates the percentage concentration for any payor and how compliance with the commercial paper program's restrictions is enforced. The first step in calculating payor concentration is to calculate the total amount advanced to each specific payor in the current financial table 45 c. This amount is then divided by the total amount advanced to all payors. The result is the percentage exposure to each payor. The commercial paper progam's maximum guidelines is then subtracted from the percentage exposure. If the results of this subtraction are greater than zero, then this payor has exceeded its limit. Where the results of the subtraction are greater than zero, the difference is multiplied by the total amount advanced to determine the amount disallowed for over concentration. The total amount of disallowance is then summed. This disallowance is stored in compliance table 45 j.
  • Performance Tracking
  • One of the major requirements of a commercial paper program is that the provider be able to track the performance of its receivables on an ongoing basis. FIG. 25 shows how software 43 tracks collections by pool. Collections are tracked by comparing actual collections for a daily pool (as determined from financial claim records) with expected collections for that pool. The starting point for this comparison is the expected collection pattern for the pool as previously determined (see FIGS. 18 and 19). The expected amount collected from day of billing is then calculated by running a cumulative sun on the expected collection pattern. The total amount paid on each daily pool is then subtracted from the expected amount collected for the appropriate day from billing. The results are saved in the collection performance tracking table 45 l. The difference between expected and actual collections is also graphed and displayed or printed on sentinel system 42 by days since initial billing to be used by the provider. FIG. 26 illustrates this graphical display of actual vs. expected collections.
  • Calculating Current Performance Statistics
  • Another major requirement of a commercial paper program is that the provider engage in periodic tests to see whether the performance statistics on recently collected claims are statistically the same as the performance statistics used when the latest contractual advance rates were established. After the provider has begun participating in a commercial paper program, as current outstanding claims are paid off, these claims are stored in the recently collected table 45 b. The collection rates in this table are periodically statistically analyzed by software 43. There are seven statistics calculated: an average, a standard deviation, a minimum value, a maximum value, a sum of all the collection rates, a sum of the square of the collection rates, and a count of the number of claims. The statistics are saved in the current performance statistic table 45 e.
  • Payor performance can also be measured by how quickly the payor pays on the claims. A matrix can be calculated which shows all the payors for a given provider and their average days to payment. This matrix is calculated by finding the day from billing on the collection histograms for individual payors where it is estimated that fifty percent of the receivable will be collected. This day from billing is then shown for all payors. Another payment analysis would be to look at the days from billing by procedure. This would involve calculating collection histograms for individual payors by procedure and then finding the day where fifty percent of the receivables have been paid. This data is saved in collection time table 45 r.
  • The line item information in a provider claim record can be used to create a revenue analysis by service by payor. This analysis involves determining how much each payor pays for a specific service. Each claim has the line item detail to show what amount was billed for a specific service and how much was paid by the payor. The revenue analysis would calculate an average payment for each service for each payor. These averages per payor could then be compared for a specific service. This type of data would be useful for subsequent negotiations with the payors. The results of these analyses are stored in revenue analysis table 45 s.
  • Data Transfer Between Sentinel and Central Processing System
  • The sentinel system 42 transmits data to the central location daily. FIGS. 23A and 23B show all of the data included in the master file 45 m that are to be transmitted daily. The master file 45 m is updated daily and stored on system 42 before being transmitted. As shown in FIGS. 23A and 23B, the new daily pool data includes a record for the new pool formed on the day of transmission, including the date billed, amount billed, amount advanced, expected uncollectible, expected collections, and equity. The expected collection histogram data contains a histogram showing the expected collection pattern for the pool. The changes to existing daily pool data contains for each existing pool a record which specifies the date billed, the amount paid today, and the realized uncollectible. The prior performance statistics data and the current performance statistics data contain the data for, respectively, both the archive table and the recently collected table. This data includes the average collection rate, standard deviation, sum of all collection rates, sum of all collection rates squared, and the count of number of claims in the analysis. The compliance data includes the total concentration disallowance. The collection performance tracking data contains the graphical information which shows the difference between expected and actual collections by day from billing. The daily payor collection data includes data on the amount billed by payor and the amount paid by payor. Finally, the payor effectiveness data contains the payor effectiveness index.
  • The sentinel 42 receives summary data back from the central location 50. This data includes periodic updates to both the advance rates for the various conduits that the provider has contracts with as well as conduit specified payor limits. The daily data received includes financial statements (balance sheet, income statement, and cash flow statement) and a collection reconciliation report showing differences between what the provider reported as amount paid and what the conduit reported as amount paid. Using software 43, provider personnel can access these reports as well as a collection tracking report by payor at any time during the day.
  • Sentinel at SPE's Operating Agent Location
  • The sentinel system 62 at the SPE's operating agent location 60 has two primary functions: capture commercial paper program data generated by the operating agent for transmission to the central location 50 and providing access to the operating agent for several reports generated at the central location. The commercial paper program's data is also downloaded into a local sentinel 62 from the operating agent's computing system 66 before being transmitted to the central location 50. FIG. 27 shows how software 63 takes each day's records from the SPE and records them in a SPE table maintained on the sentinel system 62 for transmission to the central location 50. FIG. 28 shows the data fields captured from the SPE's mainframe 66. This data can be downloaded as illustrated in FIG. 13 in a variety of file languages including, either ASCII or DBF.
  • Unlike the provider, the data from the SPE is already in summary form. The reason that the SPE reports summary data is a function of how the data is obtained or generated by the SPE. For example, daily collection data is obtained by looking at cash receipts from individual payors made on the provider's behalf in the SPE's bank account. For another example, individual provider interest expense is calculated by determining the daily interest expense for the SPE and then charging the provider for the amount of this interest expense which corresponds to the percentage of the amount advanced to the provider divided by total advances from the SPE. One of the primary functions of the information management system 30 is to reconcile the summary level data from the SPE with the detail level data at the individual provider level.
  • File Server at Central Location
  • As described generally above with respect to FIG. 9, software 53 executing on the computer system 51 at the central location 50 has several functions: it receives the data from the provider and SPE sentinels 42 and 62 (53 a and 53 b); it captures the data from the SPE's commercial paper dealer (53 c) and the contract between SPE and provider (53 d); it reconciles all of the detail and summary level data (53 e); it reports a credit scoring index based on each provider's payor effectiveness index and the credit rating for the payor (53 l); it generates the financial accounting statements (53 g) for the individual providers by tracking daily pools (53 g); it creates asset/liability management reports to monitor and control interest rate and liquidity risk (53 m); it reports financial statements (53 f) to individual providers and concentration and tracking statistics (53 i) to SPE's; it calculates performance statistics (53 j), and it includes a contact management system (53 k). As also noted above, FIG. 10 illustrates various tables and files 55 maintained on the file serve 56 at the central location 50, to be described below.
  • The contact management system executing on the central location computer system 51 keeps track of all of the parties who act as a source of information to the management information system 30. The contact system uses the data fields as shown in FIG. 29 for each SPE, provider, and commercial paper dealer. As illustrated in FIG. 10, four separate files 55 a, 55 b, 55 c and 55 d are set up to keep a record of the SPE/conduit, providers, commercial paper dealers, and payors respectively.
  • As noted above, the file server 56 receives information from both the provider and the SPE's locations. This data is electronically transmitted from the sentinels 42 and 62 at each location. The data is received by I/O computer 52 which scans it for viruses. If no viruses are detected, this information is then passed over the network 54 to the file server 56. The data is sent in electronic preassigned tables in an “mdb” file (Microsoft Database) with a specific provider designation on the file. The file server attaches the data in each of the preassigned tables for use in additional analyses. The preassigned tables are shown in FIG. 10. If a single provider is transmitting files to the central location 50 from multiple locations 40, the data in the files 43 m is consolidated by central location software before further processing, as generally illustrated in FIG. 30. This consolidation is accomplished by software 53 by tracking each location separately and combining all of a provider's data together as it is needed for different calculations and reports. For example, to reconcile the amount the SPE says it advanced to the provider with the amount the provider's detail data shows should have been advanced, all of the advance amounts reported in the new daily pool table from the different locations need to be added together.
  • There are three types of data that is manually entered into the file server at the central location: payor credit rating related, contract related and commercial paper related. The file server tracks the credit rating on each individual payor's claim paying ability. The payor credit table (55 t) contains the data fields shown in FIG. 31.
  • As illustrated in FIG. 32, software 53 tracks the information embodied in the contract between the commercial paper program and the provider. In the contract the rate at which the SPE is to advance money against receivables of specific payors is documented. This is kept track of in a table 55 o called advance rates, which also includes a provider and payor ID field. The contract also documents the fees that the various financial intermediaries involved in the SPE can charge. Financial intermediaries may include banks, monoline insurers, commercial paper dealers, operating agents and SPE sponsors. This information is tracked in a table 55 p called third party fees. It also includes a provider and SPE ID field. Lastly, the contract specifies the maximum percentage an individual payor can represent of the claims sold to the SPE by a provider. These percentages are maintained in a table 55 q called payor limit. The payor limit table 55 q also includes SPE and provider ID fields.
  • The last source of data is the commercial paper dealer. This data is captured in the form of a trade ticket which is entered into a computer at the central location. As the trade ticket is entered into the computer, several additional data fields are calculated. FIG. 33 shows the initially entered fields and the calculated fields. FIG. 34 shows how the commercial paper information is entered using software 53 and stored in table 55 e and 55 u. The commercial paper dealer is called. The commercial paper trade tickets, the source of the information for table 55 e, and daily federal composite rates for various maturities, the source of the information for table 55 u, are input. Commercial paper variables are calculated and entered in the commercial paper table 55 e. The records for each trade are entered into the daily transaction journal in the commercial paper database table 55 e. The commercial paper position review and commercial paper issuance spread are recorded and reported.
  • After having collected the data from the commercial paper dealer and the contract, software 53 performs any calculation necessary to generate the information needed to run a data reconciliation analysis. The data from the commercial paper table 55 e is used to create daily interest expense for each SPE or conduit, as shown in FIG. 35. This is done by summing by SPE the daily interest expense for each piece of commercial paper that has not yet mated in the conduit. If the maturity date for a commercial paper instrument is greater than or equal to the day's date, the daily interest expense by SPE is added to the sum of daily interest expense. The results are saved in the detail based daily interest expense table 55 v.
  • FIG. 36 illustrates the total fee expense calculation performed by software 53. Daily SPE fees by provider by SPE are determined by summing the financial intermediary fees (from third party fees table 55 p) by provider by SPE and dividing by 365. SPE Fee expenses equal the daily SPE fee by provider by SPE times the total advances payable to the SPE from the provider in the balance sheet. The total SPE fees by conduit are equal to the sum of each provider's SPE fee expenses for that conduit. The results are saved in the detail based third party fee file 55 w.
  • At this point, all of the data that is needed for running reconciliations between various data sources is now available. Reconciliations are performed using software 53. There are four basic types of reconciliations. First, the amount the SPEs report they advanced, stored in SPE table 55 j is compared with the amount that the provider claim detail shows they should have advanced as stored in downloaded daily pool records. As shown in FIG. 37, the funding gap equals the advance amount from the new daily pool record sent over by the provider sentinel 42 minus the total concentration disallowance from the payor concentration data sent over by the provider sentinel system 42 minus the reported advance from the daily advance data sent over by the SPE sentinel 62. The funding gap calculation is saved in a reconciliation table 55 r.
  • Second, as shown in FIG. 38, the amount the SPEs report they collected as specified in SPE table 55 j is compared with the amount that the provider claim detail shows they should have collected. The collection gap equals the amount paid by payor in the daily payor collection data sent over in the master file 45 m (and stored in file 55 h on the system 51) by the provider sentinel system 42 minus the amount received from payor in the payments received data (FIG. 28) sent over by the SPE sentinel system 62. The collection gap is saved in the reconciliation table 55 r.
  • Third, as shown in FIG. 39, the amount the SPEs report for daily interest expense is compared with the amount of daily interest expense calculated from the commercial paper table 55 e. The interest expense gap equals the interest expense calculated from the commercial paper table 55 e minus interest expense as reported in the interest expense records (FIG. 28) sent over by the SPE sentinel 62. The interest expense gap is saved in the reconciliation table 55 r.
  • Fourth, as shown in FIG. 40, the amount the SPEs report for daily financial intermediary (third party) fee expense is compared with the amount of daily fee expense calculated from the fee table 55 p and the daily pool balance sheets 55 k. The third party fee gap equals the difference in these fees. The third party fee gap is saved in the reconciliation table 55 r.
  • Software 53 does not make any adjustments for gaps uncovered when the reconciliation analysis is performed. No adjustments are made because each of these gaps should be eliminated by the responsible party within a twenty-four hour period. For example, an underadvance by the SPE yesterday can be cured by advancing more today. Using I/O computer 52, software 53 transmits the results of the reconciliation analysis stored in table 55 r to the provider sentinel 42 and the SPE sentinel 62 so that they can be reviewed.
  • The preparation of the financial accounting statements and reports involves tracking twelve data fields for each pool. FIG. 41 shows these fields. The financial statements for each pool are prepared daily in accordance with generally accepted accounting principals. The income statement is prepared reflecting accrual accounting.
  • The financial accounting for each pool begins with the appending of data from the new daily pool data (FIGS. 12A and 12B) sent over by the provider sentinel 42 to the balance sheet data 55 k stored on the file server 56. After the pool has been in the balance sheet data 55 k for one day, interest expense and fee expense are calculated on the amount in advance payable and retained earnings and the balance sheet data 55 k is updated. Software 53 then looks into the changes in existing pools data sent over by the provider sentinel 42 in master file 43 m to see if there have been any collections or realized uncollectibles. If there have been, then the accounts receivable and bad debt accounts are updated in the balance sheet data 55 k. If there have been collections, then the amount of interest, fees and advances paid is calculated. The interest, fees and advance payable are then updated on the balance sheet data 55 k. The process of calculating expenses, cash flow and updated balance sheets is repeated every day for the pool until the pool is closed.
  • FIGS. 42 and 36 show how interest expense and fee expense are calculated for each pool by software 53. Interest expense is calculated for each daily pool by first calculating the total of the advance payable in the balance sheet data 55 k for all the pools in a SPE. Each pool's advance payable is then divided by the total advance payable in the SPE to calculate that pool's percentage share of the interest expense. The pool's daily interest expense is then calculated by multiplying the pool's percentage share of the SPE's daily interest expense by the SPE's daily interest expense. The results are stored in the income statement data 55 l.
  • For all pools, the daily financial intermediary (third party) fee expense equals the advance payable from the balance sheet data 55 k times the total of the financial intermediary fees in the contract file 182 divided by 365. SPE fees for provider equal the sum of all financial intermediary fees for provider divided by 365. The SPE fee expense equals the sun of the SPE fees for provider times the total advance payable to provider from the balance sheet. The results are stored in the income statement data 55 l.
  • FIG. 44 shows how accounts receivable and bad debt are updated daily for each pool. The opening accounts receivable balance for each daily pool is set equal to the amount billed by the provider for the pool date. The balance is reduced each day by the amount paid and the amount of the realized uncollectible for the pool. The opening bad debt balance for each daily pool is set equal to the expected uncollectible amount for the pool. The balance is reduced each day by the amount of the realized uncollectible for the pool. The results are stored in the balance sheet data 55 k.
  • FIG. 45 shows how the accounts payable, namely advance payable, interest payable and fees payable, are updated for each daily pool balance sheet by software 53. For each daily pool, the initial balance in the advance payable account is set equal to the amount advanced. For each day that the pool has a balance greater than zero in its advance payable account, an interest expense and a fee expense are calculated. On those days that the pool does not have any collections, the interest expense is added to interest payable on the balance sheet to create the new interest payable amount and interest paid on the cash flow statement is set equal to zero. Also, the fee expense is added to fees payable on the balance sheet to create the new fees payable amount and the fee paid on the cash flow statement is set equal to zero. If the pool has any collections, the collections are used to pay down accounts in the following order: interest, fees, and then advances. If the amount collected is less than today's interest expense plus the interest payable on the balance sheet, then the total amount collected is applied to interest and the new interest payable amount becomes the difference between today's interest expense plus the interest payable on the balance sheet and the amount collected. Interest paid on the cash flow statement equals the amount collected and fee paid is set equal to zero. If the amount collected is greater than or equal to that day's interest expense plus the balance in the interest payable account, then an amount equal to the interest expense plus the interest payable is used to pay off these accounts. Interest paid on the cash flow statement equals the day's interest expense plus the balance in the interest payable account. If the excess is less than today's fee expense plus the balance in the fee payable account, then the new fee payable amount equals today's fee expense plus the balance in the fee payable account minus the excess. Fee paid in the cash flow statement equals the excess. If the excess is greater than or equal to today's fee expense plus the balance in the fee payable account, then an amount equal to today's fee expense plus the balance in the fee payable account is used to pay off these accounts. Fee paid in the cash flow statement equals today's fee expense plus the balance in the fee payable account. If there is any remaining cash, the cash is used to pay down the advance payable account to the point where either all of the cash has been used or all of the advance payable has been paid off. The advance paid in the cash flow statement equals the reduction in the advance payable.
  • After the accounting entries for each daily pool have been created, they are used in a conventional accounting package to create financial statements for both the daily pools and the providers, as generally illustrated in FIG. 46. The financial statements are recorded in a file and transmitted back to the sentinel 42 where they are reported daily to the provider and form the basis for the provider being able to audit its participation in a commercial paper program. Included with the financial statements is a settlement analysis. This analysis looks at how much cash should be paid to the provider each day. Cash paid to provider equals cash collected the previous day less interest paid less fees paid less advances paid plus new advances.
  • Comparing Current and Past Collection Statistics
  • In the contract between the SPE and the provider, there is a definition of how much change in the net collectible value statistics (average and standard deviation) triggers a change in the advance rates. The software 53 at the central location automatically reviews changes in the net collectible value statistics. There are three types of changes: changes which indicate that there should be a downward revision to the advance rates; changes which indicate that there should be an upward revision to the advance rates; and changes which indicate that the advance rate level is still appropriate. The performance statistics from the providers are analyzed for these three types of changes in an Excel spreadsheet. Unless a higher threshold is set by the SPE, the spreadsheet looks to capture changes by comparing the average net collectible value on recently collected claims with the range formed by adding or subtracting one standard deviation from the average net collectible value at the time the advance rates were set. Initially, the average net collectible value at the time the advance rates are set will be in the prior performance statistics table sent over by the sentinel. Changes which require a downward revision in the advance rates are detected by comparing the average net collectible value of the recently collected claims with the difference between the average net collectible value of the performance statistics supporting the current advance rates and one standard deviation from the performance statistics supporting the current advance rates. If the average net collectible value of the recently collected claims is less than or equal to the difference, then a downward revision of the advance rates is triggered. The spreadsheet looks to capture changes which require an upward revision in the advance rates by comparing the average net collectible value of the recently collected claims with the sum of the average net collectible value of the performance statistics supporting the current advance rates and one standard deviation from the performance statistics supporting the current advance rates. If the average net collectible value of the recently collected claims is greater than or equal to the sum, then an upward revision of the advance rates is triggered. If the change in the average net collectible value does not exceed the trigger levels, then the advance rates remain at their present level.
  • There are a variety of additional statistical techniques beyond using the standard deviation to establish a range around the average net collectible value that can be used in determining the trigger levels for adjusting advance rates. A t-test can be used to construct a confidence interval around the average net collectible value rate. The average net collectible value rate from the recently collected data is then compared with the confidence interval to see if it falls within the confidence interval. An F-test can be used to determine a confidence interval for testing changes in the standard deviation. The standard deviation of the net collectible value rate from the recently collected data is then compared with the confidence interval to see if it falls within the confidence interval. A chi-squared test can be used to determine a confidence interval for testing changes in the standard deviation. The standard deviation of the net collectible value rate from the recently collected data is then compared with the confidence interval to see if it falls within the confidence interval.
  • If the results of the tests do not indicate a change in the performance statistics, the statistics in the prior performance statistics file are recalculated to update them for the inclusion of the recently collected claims. If the results of the tests indicate a change in the performance statistics for the recently collected records, then, after the advance rates have been changed, the statistics of the recently collected table 45 b are stored in the prior performance statistics table 45 e. Regardless of the outcome of the tests, both the provider and SPE are transmitted the results using I/O computer 52.
  • Asset/Liability Management
  • FIG. 47 shows the asset/liability management model executed by software 53 for a commercial paper program. The goal of asset/liability management is to control the provider' exposure to changes in the interest rate on, and liquidity of, commercial paper. This control is achieved by proactively managing the commercial paper being issued by the various conduits. Proactive management allows a provider to specify the funding strategy that they would like to support their receivables. The first step is to estimate the cash collections on each of the daily pools. These estimates are the expected collections calculated as described above and transmitted by the provider sentinel 42 to the central location. Next, the expected collection date is calculated by adding the days from billing to the pool date. The model then sums the expected collection for each daily pool by the expected collection date to generate estimated collection. The second step is to estimate the cash settlement amount for each of the daily pools. This estimate begins by calculating the expected percentage collected histogram. This histogram equals the cumulative sum of the collection histograms. Next, the percentage advance for each daily pool is calculated. Percentage advance equals the advance amount divided by the difference between amount billed and expected uncollectible. Next, an estimate of the interest and fee expenses for the life of the pool is made. The estimated percent expenses is shown here as five percent but can be changed. Settlement date equals the date on the expected percentage collection histogram where the percentage collected equals or is greater than the sum of the percentage advance plus the estimated expenses. Estimated daily pool settlement amount equals the daily pool equity minus the result of multiplying the advance amount by the estimated percent expenses. Total daily settlements equals the sum by day of the estimated daily pool settlement amounts for all providers in the conduit. An estimate of daily cash flow can now be created. Estimated daily cash flow equals estimated collections minus total paper minus total daily settlements. Cumulative estimated cash flow equals the cumulative sum of estimated daily cash flow. The estimated cumulative cash flow calculated in the asset/liability management is the starting point for helping a provider with its cash flow management. These figures can be used develop investment and bill payment strategies.
  • There are several other reports generated by software 53 for the SPE. A provider concentration report looks at the concentration of providers in any given conduit. When rating agencies review their credit rating on a specific SPE, they look for diversification in the SPE's exposure to providers. FIG. 48 depicts how the provider concentration is calculated. For each individual provider in a SPE, the total advance payable to the provider from the balance sheet data 55 k are divided by the total advance payable made by the SPE. The resulting percentage represents the concentration that an individual provider is to the SPE.
  • Rating agencies also look at the SPE's exposure to the payors. A payor exposure report looks at the payors grouped by either credit rating or type of payor. FIG. 49 depicts how these two exposure analysis are calculated by software 53. Both exposures are calculated by first determining the concentration of each individual payor in the SPE. This is found by adding up the percentage concentration of each individual payor at each provider from the payor concentration data sent by the provider sentinel 42 and dividing this sum by the number of providers in the SPE. Exposure by credit quality is then calculated by summing the percentage of each individual payor in the SPE by the credit rating of the payor. Exposure by type of payor is calculated by summing the percentage of each individual payor in the SPE by the type of payor it is. Reports generated by software 53 are stored in an output file for transmission to the provider sentinel system 42 and the SPE sentinel system 62.
  • The system also generates a credit scoring report. The sentinel system 42 periodically sends the payor effectiveness index to the central location 50. This index measures how much of the amount billed was collected and how quickly the collection occurred. The credit scoring reports shows this index next to the credit quality of the payor's claims paying ability index. The credit quality index ranges from 0.1 to 1 with 0.1 being payors whose claims paying ability is deemed doubtful by the credit rating agencies and 1 being payors whose claims paying ability is deemed extremely strong by the credit rating agencies.
  • Additional reports generated for providers include a peer group comparison report which shows how the provider compared with its peers in the timing of its collections and the net collectability of its claims. These reports are used to illustrate the savings available to the provider from better management of its collections. FIG. 50 shows how software 53 determines the interest savings available to the provider from collecting its receivables as quickly as its best performing peer. The best performing peer is identified as that provider which has the highest percentage of its receivables collected in ninety days. This provider's collection histogram is then compared with the provider's collection histogram to show the percentage collection difference by day over the 90 day period. Each day's difference is then multiplied by the provider's average receivables balance. The amount is then summed and multiplied by eight percent, a proxy for the average cost of financing this excess receivable balance. The result is the savings available from matching the best performing peer. FIG. 51 shows the earnings available to the provider from collecting the same average amount for each diagnosis by payor as its best performing peer as determined by software 53. The best performing peer is identified for each payor as that peer which has the highest average amount paid for each diagnosis by payor. This provider's average amount paid is then subtracted from each of the best performing peer average amount paid. This difference represents the potential for increased income. The results of these reports are stored in a file for transmission to the provider location or for printing.
  • Summary
  • FIGS. 52A, 52B, 53 and 54A-D summarize the origin, transfer and transformation of data moving through system 30. FIGS. 52A and 52B illustrate the input data, functions and output data for the system 30 at the seller's location. FIG. 53 illustrates the input data, functions and output data for the system 30 at the SPE's location. FIGS. 54A, 54B, 54C and 54D illustrate the input data, functions and output data for the system 30 at the central location.
  • Alternative Uses of Claims Database
  • As the provider downloads claims information to the sentinel at its location, the claims information is put into a standardized format. One use of the data in this database is for tracking and controlling the provider's participation in a financing program. There are several other equally important uses. This data can be analyzed to create valuable information for a variety of participants in the medical industry. For example, the data can be sorted through to generate statistics on supply usage at a given provider by diagnosis. The results of this analysis allows a provider to measure its profit margin if it is receiving capitated payments from the payors and enters into a capitated supply agreement with its suppliers. For another example, the data could be aggregated across providers to analyze how drug usage patterns influence the cost of treating a specific diagnosis. Pharmaceutical companies are interested in the data from this analysis to show the benefit of their drugs in treating illnesses. Preferably, software 53 includes the capability to perform these functions.
  • ALTERNATE EMBODIMENTS Electronic Data Interchange Claims
  • In an alternative embodiment, shown in FIG. 52, the system 30′ of the present invention is set up to capture claim records from an electronic claims processor. This claims processor, otherwise known as an electronic data interchange agent, has terminals or computer systems 46′ at the offices or locations 40′ of physicians, clinics, rural hospitals, regional hospitals or even urban center hospitals. As conventionally operated, the electronic data interchange (EDI) agent's computer system 46″ receives claim data from these terminals or computer systems 46′ and electronically conveys it to the appropriate payor, such as an insurance company or Medicare or Medicaid. According to the alternate embodiment of the invention, the claims data from the EDI computer system 46″ is transferred to a sentinel system 42′, where it can be processed on a provider by provider basis and summarized as described above with respect to sentinel system 42 for transmission to the computer system 51 at the central location 50. Reports can be transmitted by the central location computer system 51 directly back to computer systems 46′ at the locations 40′ using modem transmission.
  • Use of System 30 for Other Accounts Receivables
  • As noted above, the system 30 of the present invention is readily adaptable to provide processing for any form of accounts receivable. Instead of processing medical claims, the system can process any form of invoice representing an account receivable, such as attorneys' fees or invoices generated by an industrial supplier. Thus, it shall be understood that the invention is in no way limited to servicing medical providers or medical claims.
  • Other Periodic Units
  • The preferred embodiments described above implemented a daily period. It shall be understood, however, that any periodic unit can be used to select claims or invoices to be pooled together and processed pursuant to the principles of the present invention.
  • Other Pooling Criteria
  • The preferred embodiments of the present invention pool claims or invoices without regard to the payor of the obligations provided that the payors for the claims or invoices are approved. It is contemplated, however, the selection of accounts receivable for each pool may be done not only on the basis of periodic units, but can also be formed or optimized according to payor. For example, certain pools may have payors which historically pay more quickly than average or a higher percentage of a billed amount that average. This optimization may be accomplished using linear programming, regression analysis or other standard statistical techniques.
  • Sentinel System Alternative Embodiments
  • In the preferred embodiments of the invention, the sentinel system 42 is independent of the provider's computer system. It shall be understood, however, that the sentinel software 43 and files and tables 45 can be adapted to execute on the provider's computer system 46, thus eliminating the need for sentinel system 42. However, system 42 is preferred because it avoids the necessity to adapt software 43 and files and tables 45 to each different hardware and software configuration of provider computer systems 46. Similarly, the SPE sentinel software 63 and files can be adapted to execute on the SPE computer system 66.
  • Central Location Alternative Embodiments
  • In the preferred embodiment, the central location is remotely located from the SPE and provider or receivable seller. It shall be understood, however, that the central location system 51 can be located at the location of a receivable seller or an SPE. Furthermore, the central location software 53 and files 55 can be adapted to execute and b stored on a provider or SPE computer system.
  • CONCLUSION
  • Thus, there has been described above a computerized system for archiving and storing invoice and claims records and for tracking and controlling a medical provider's participation in an asset back commercial paper program. It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims (35)

1-26. (canceled)
27. A method for processing electronic accounts receivable records, each specifying an account receivable recorded in one or more computer systems for a seller of the account receivable, each accounts receivable record including (i) a date field specifying a date for the account receivable, (ii) a financial data portion specifying an amount billed to be paid by a payor, and (iii) a goods or services data portion specifying information about the goods or services provided for the amount billed, comprising:
downloading the accounts receivable records from the seller accounting system and creating an electronic financial record corresponding to each of at least some of the accounts receivable records downloaded from the seller accounting system, the financial records recording a financial data subset of all of the data recorded in a downloaded accounts receivable record, the financial data subset corresponding substantially to financial aspects of the downloaded accounts receivable records, and storing the financial records in a mass storage device located at a location of the seller;
creating an electronic goods or services record corresponding to each of at least some of the accounts receivable records downloaded from the seller computer systems, the electronic goods or services records recording a subset of all of the data recorded in the downloaded accounts receivable records, the data subset corresponding substantially to goods or services aspects of the downloaded accounts receivables records, and storing the goods or services provided record in a mass storage device located at a seller location; and
searching the financial records and identifying records that have a date specified in the date field of the record within a predetermined period to identify a pool of accounts receivable records, with the records specifying a corresponding periodic pool of accounts receivable.
28. A method according to claim 27 further including creating an electronic periodic pool record corresponding to the identified pool of accounts receivable records;
recording a pool advance amount in a field of the electronic periodic pool record representing an amount to be advanced against a value of the periodic pool of accounts receivable; and
electronically transferring the electronic periodic pool record to a one or more processing systems.
29. A method for processing electronic accounts receivable records, each specifying an account receivable recorded in one or more computer systems for a seller of the account receivable, each accounts receivable record including (i) a date field specifying a date for the account receivable, and (ii) a financial data portion specifying an amount billed to be paid by a payor, comprising:
searching the accounts receivable records and identifying records that have a date specified in the date field of the record within a predetermined period to identify a pool of accounts receivable records, with the records a specifying corresponding periodic pool of accounts receivable;
creating an electronic periodic pool record corresponding to the pool of accounts receivable records;
recording a pool advance amount in a field of the electronic periodic pool record representing an amount to be advanced against a value of the periodic pool of accounts receivable;
electronically transferring the electronic periodic pool record to one or more processing systems; and
further wherein each accounts receivable record specifies an amount paid on the account receivable and further including periodically determining an amount paid for the accounts receivable in the corresponding periodic pool by electronically reviewing the amount paid specified in each account receivable record in the periodic pool, and reporting a performance profile for one or more of the periodic pools indicating the collections obtained.
30. A method according to claim 29 further including maintaining an electronic accounting data for each periodic pool represented by a periodic pool record, and for preparing financial statements from the electronic accounting data.
31. A method according to claim 29 further wherein the one or more processing systems are used to preparing reports for a third party advancing money against a periodic pool represented by a periodic pool record, and wherein the reports specify compliance with third party restrictions on advances against periodic pools.
32. A method according to claim 29 further including determining the pool advance amount using the amount billed specified in the financial data portion of the accounts receivable records.
33. A method according to claim 29 further including determining an advance amount for each of the accounts receivable in the pool and using the determined advance amounts to determine the pool advance amount.
34. A method according to claim 33 further including determining the advance amount for each account receivable in the pool based on payor.
35. A method according to claim 29 further wherein there is more than one seller, each of whom may have one or more locations and wherein said electronically transferring is provided at each seller location; and wherein the one or more processing systems are installed at a position remote from at least one of the seller locations.
36. A method according to claim 29 further including electronically transferring an electronic record to a remote location of a third party advancing money against the periodic pool of accounts receivable, the electronic record indicating the value of the periodic pool of accounts receivable.
37. A method according to claim 29 further including recording in each periodic pool record a collection value representing an amount paid on the accounts receivable in the periodic pool record.
38. A method according to claim 37 further including determining the collection value representing an amount paid using the financial data portion of an accounts receivable record and wherein said financial data portion specifies an amount paid.
39. A method according to claim 37 further including receiving an electronic record specifying a payment received value representing an amount of payments received by a third party which has the right to collect payments made on amounts billed in a periodic pool corresponding to a periodic pool record.
40. A method according to claim 39 further including reconciling payment received values to amount paid values from periodic pool records.
41. A method according to claim 29 further including creating an electronic accounts receivable financial record corresponding to each of at least some of the accounts receivable records downloaded from the provider accounting system, the financial records recording a financial data subset of all of the data recorded in a downloaded accounts receivable record, the financial data subset corresponding substantially to financial aspects of the downloaded accounts receivables, and storing the financial accounts receivable in a mass storage device located at a location of the seller.
42. A method according to claim 29 further wherein each accounts receivable record includes a (iii) goods or services data portion specifying information about the goods or services provided for the amount billed, and further wherein the system includes creating an electronic goods or services record corresponding to each of at least some of the accounts receivable records downloaded from the seller accounting system, the records recording a subset of all of the data recorded in a downloaded accounts receivable, the data subset corresponding substantially to goods or services aspects of the downloaded accounts receivables, and storing the goods or services provided record in a mass storage device located at a seller location.
43. A method according to claim 29 further wherein the financial data portion of each account receivable record further specifies a payor for the account receivable.
44. A method according to claim 43 further including looking up the collectibility statistics according to the payors specified in the accounts receivable records.
45. A method according to claim 44 further including reporting the performance of the periodic pools according to which payor is responsible for paying accounts receivable in the periodic pool.
46. A method according to claim 44 including analyzing collection data specified in accounts receivable records to determine current collection statistics and comparing the historical collection statistics with the current collection statistics.
47. A method according to claim 46 further wherein the one or more processing systems includes receiving the master electronic record and for maintaining electronic financial accounting data on each periodic pool.
48. A method according to claim 29 further wherein each accounts receivable record specifies an amount paid on the account receivable and further including periodically determining an amount paid for the accounts receivable in the corresponding periodic pool by electronically reviewing the amount paid specified in each account receivable record in the periodic pool, and reporting a performance profile for one or more of the periodic pools indicating the collections obtained.
49. A method according to claim 29 further including processing historic accounts receivable records specifying payment history to determine collection timing statistics indicating when amounts billed normally get paid.
50. A method for processing electronic accounts receivable records each specifying an account receivable recorded in one or more computer systems for the seller of the account receivable, each accounts receivable record including (i) a date field specifying a date for the account receivable, and (ii) a financial data portion specifying an amount billed to be paid by a payor and an amount paid on the corresponding amount billed, comprising:
searching the accounts receivable records and identifying records that have a date specified in the date field of the record within a predetermined period to identify a periodic pool of account receivables representing a corresponding periodic pool of accounts receivable;
creating a new electronic periodic pool record corresponding to a periodic pool of accounts receivable that have not yet had an amount advanced against them by a third party;
recording a pool advance amount in a field of the new electronic periodic pool record representing an amount to be advanced against a value of the periodic pool of the accounts receivable;
searching the accounts receivable records for records corresponding to periodic pools of accounts receivable other than those corresponding to the new periodic pool record, and for determining a total amount paid for each of the other periodic pools from the accounts receivable records corresponding to the other periodic pools;
transferring a master electronic record to one or more processing systems, the master electronic record including the pool advance amount specified in the new electronic periodic pool record and an amount collected for each of the other periodic pools which showed collections in the accounts receivable records; and
wherein each accounts receivable record specifies an amount paid on the account receivable and further including periodically determining an amount paid for the accounts receivable in the corresponding periodic pool by electronically reviewing the amount paid specified in each account receivable record in the periodic pool, and reporting a performance profile for one or more of the periodic pools indicating the collections obtained.
51. A method according to claim 50 further wherein the one or more processing systems includes receiving collections data from a third party and reconciling collection data from the third party with the collection data for each periodic pool for which financial accounting data is maintained on the one or more processing systems.
52. A method for processing electronic accounts receivable records each specifying an account receivable originating in one or more accounting systems for a seller of the account receivable, each accounts receivable record including (i) a date field specifying a date for the account receivable, and (ii) a financial data portion specifying an amount billed to be paid by a payor and an amount paid on the corresponding amount billed, comprising:
transmitting from the seller's location accounts receivable records to an electronic data interchange system; and
data processing including:
(a) receiving accounts receivable records from the electronic data interchange system and for searching the accounts receivables records and identifying records that have a date specified in the date field of the record within a predetermined period to identify a periodic pool of accounts receivables representing a corresponding periodic pool of accounts receivable;
(b) creating a new electronic periodic pool record corresponding to a periodic pool of accounts receivables that have not yet had an amount advanced against them by a third party;
(c) recording a pool advance amount in a field of the new electronic periodic pool record representing an amount to be advanced against a value of the periodic pool of accounts receivable;
(d) searching the accounts receivable records for records corresponding to periodic pools of accounts receivables other than those corresponding to the new periodic pool record, and for determining a total amount paid for each of the other periodic pools from the accounts receivable records corresponding to the other periodic pools; and
(e) transmitting a master electronic record to one or more processing systems, the master electronic record including the pool advance amount specified in the new electronic periodic pool record and an amount collected for each of the other periodic pools which showed collections in the accounts receivable records.
53. A method for processing electronic medical accounts receivable records, each specifying a receivable recorded in one or more computer systems for a seller of the account receivable, each accounts receivable record storing data including (i) a date field specifying a date for the account receivable, (ii) a financial data portion specifying an amount billed to be paid by a payor, and (iii) a goods or services data portion specifying information about the medical goods or medical services provided for the amount billed, comprising:
reading the data in the accounts receivable records;
using the data read from the accounts receivable records to create one or more electronic pool records, the one or more pool records specifying an amount to be advanced against one or more of the accounts receivables represented in said accounts receivable records;
recording funds received by said seller for said amount to be advanced;
creating an electronic record which records the identity of accounts receivables against which said funds have been advanced; and
wherein each accounts receivable record specifies an amount paid on the account receivable and further including periodically determining an amount paid for the accounts receivable in the corresponding periodic pool by electronically reviewing the amount paid specified in each account receivable record in the periodic pool, and reporting a performance profile for one or more of the periodic pools indicating the collections obtained.
54. A method according to claim 33 further including using the date read from the accounts receivable records to calculate said sum based on a pool of individual accounts receivable having one or more particular dates.
55. A method according to claim 33 further including using the payor read from the accounts receivable records to calculate said sum based on a pool of individual accounts receivable having one or more particular payors.
56. A method according to claim 33 further including extracting the date read from the accounts receivable records to calculate said sum based on a pool of individual accounts receivable having one or more particular ages.
57. A method for processing electronic accounts receivable records, comprising:
one or more computer systems for a seller of an account receivable, the account receivable represented by accounts receivable records, each accounts receivable record specifying the account receivable, each accounts receivable record including (i) a date field specifying a date for the account receivable, (ii) a financial data portion specifying an amount billed to be paid by a payor, and (iii) a goods or services data portion specifying information about the goods or services provided for the amount billed;
downloading the accounts receivable records from the seller accounting system to one or more other computer systems;
the one or more other computer systems including:
creating an electronic financial record corresponding to each of at least some of the accounts receivable records downloaded from the seller accounting system, the financial records recording a financial data subset of the data recorded in a downloaded accounts receivable record, the financial data subset corresponding substantially to financial aspects of the downloaded accounts receivable records;
storing the financial records in a mass storage device located at a location of the seller;
creating all electronic goods or services record corresponding to each of at least some of the accounts receivable records downloaded from the seller computer systems, the electronic goods or services records recording a subset of the data recorded in the downloaded accounts receivable records, the data subset corresponding substantially to goods or services aspects of the downloaded accounts receivable records;
storing the goods or services provided record in a mass storage device located at a seller location;
searching the financial records and identifying records that have a date specified in the date field of the record within a predetermined period to identify a pool of accounts receivable records, with the records specifying a corresponding periodic pool of accounts receivable; and transmitting at least a portion of said pool of accounts receivable records which have been identified to a remote computer system located remotely from the one or more other computer systems.
58. A method for processing electronic accounts receivable records, each specifying an account receivable recorded in one or more computer systems for a seller of the account receivable, each accounts receivable record including (i) a date field specifying a date for the account receivable, and (ii) a financial data portion specifying an amount billed to be paid by a payor, comprising:
searching the accounts receivable records and identifying records that have a date specified in the date field of the record within a predetermined period to identify a pool of accounts receivable records, with the records a specifying corresponding periodic pool of accounts receivable;
creating an electronic periodic pool record corresponding to the pool of accounts receivable records;
recording a pool advance amount in a field of the electronic periodic pool record representing an amount to be advanced against a value of the periodic pool of accounts receivable;
electronically transferring the electronic periodic pool record to a one or more processing systems; and
further wherein the financial data portion of each account receivable record further specifies a payor for the account receivable and the system includes looking up the collectibility statistics according to the payors specified in the accounts receivable records.
59. A method for processing electronic accounts-receivable records each specifying an account receivable recorded in one or more computer systems for the seller of the account receivable, each accounts receivable record including (i) a date field specifying a date for the account receivable, and (ii) a financial data portion specifying an amount billed to be paid by a payor and an amount paid on the corresponding amount billed, comprising:
searching the accounts receivable records and identifying records that have a date specified in the date field of the record within a predetermined period to identify a periodic pool of account receivables representing a corresponding periodic pool of accounts receivable;
creating a new electronic periodic pool record corresponding to a periodic pool of accounts receivable that have not yet had an amount advanced against them by a third party;
recording a pool advance amount in a field of the new electronic periodic pool record representing an amount to be advanced against a value of the periodic pool of the accounts receivable;
searching the accounts receivable records for records corresponding to periodic pools of accounts receivable other than those corresponding to the new periodic pool record, and for determining a total amount paid for each of the other periodic pools from the accounts receivable records corresponding to the other periodic pools;
transferring a master electronic record to a one or more processing systems, the master electronic record including the pool advance amount specified in the new electronic periodic pool record and an amount collected for each of the other periodic pools which showed collections in the accounts receivable records; and
further wherein the financial data portion of each account receivable record further specifies a payor for the account receivable and the system includes looking up the collectibility statistics according to the payors specified in the accounts receivable records.
60. A method for processing electronic medical accounts receivable records, each specifying a receivable recorded in one or more computer systems for a seller of the account receivable, each accounts receivable record storing data including (i) a date field specifying a date for the account receivable, (ii) a financial data portion specifying an amount billed to be paid by a payor, and (iii) a goods or services data portion specifying information about the medical goods or medical services provided for the amount billed, comprising:
reading the data in the accounts receivable records;
using the data read from the accounts receivable records to create one or more electronic pool records, the one or more pool records specifying an amount to be advanced against one or more of the accounts receivables represented in said accounts receivable records;
recording funds received by said seller for said amount to be advanced;
creating an electronic record which records the identity of accounts receivables against which said funds have been advanced; and
further wherein the financial data portion of each account receivable record further specifies a pay or for the account receivable and the system includes looking up the collectibility statistics according to the payors specified in the accounts receivable records.
US11/786,716 1994-11-09 2007-04-12 System for invoice record management and asset-backed commercial paper program management Abandoned US20070203834A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/786,716 US20070203834A1 (en) 1994-11-09 2007-04-12 System for invoice record management and asset-backed commercial paper program management

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US08/336,531 US6073104A (en) 1994-11-09 1994-11-09 System for invoice record management and asset-backed commercial paper program management
US51480700A 2000-02-28 2000-02-28
US10/145,728 US7254555B2 (en) 1994-11-09 2002-05-13 System for invoice record management and asset-backed commercial paper program management
US11/786,716 US20070203834A1 (en) 1994-11-09 2007-04-12 System for invoice record management and asset-backed commercial paper program management

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/145,728 Continuation US7254555B2 (en) 1994-11-09 2002-05-13 System for invoice record management and asset-backed commercial paper program management

Publications (1)

Publication Number Publication Date
US20070203834A1 true US20070203834A1 (en) 2007-08-30

Family

ID=23316525

Family Applications (3)

Application Number Title Priority Date Filing Date
US08/336,531 Expired - Lifetime US6073104A (en) 1994-11-09 1994-11-09 System for invoice record management and asset-backed commercial paper program management
US10/145,728 Expired - Fee Related US7254555B2 (en) 1994-11-09 2002-05-13 System for invoice record management and asset-backed commercial paper program management
US11/786,716 Abandoned US20070203834A1 (en) 1994-11-09 2007-04-12 System for invoice record management and asset-backed commercial paper program management

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US08/336,531 Expired - Lifetime US6073104A (en) 1994-11-09 1994-11-09 System for invoice record management and asset-backed commercial paper program management
US10/145,728 Expired - Fee Related US7254555B2 (en) 1994-11-09 2002-05-13 System for invoice record management and asset-backed commercial paper program management

Country Status (1)

Country Link
US (3) US6073104A (en)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050108067A1 (en) * 2000-01-21 2005-05-19 Quality Care Solutions, Inc. Method of increasing efficiency in a medical claim transaction, and computer program capable of executing same
US20060085311A1 (en) * 2004-10-14 2006-04-20 The Trizetto Group, Inc. System and method for using a first electronic representation of contract terms for generating a second electronic representation of the contract terms
US20070196794A1 (en) * 2006-02-21 2007-08-23 Northstar Capital Markets Services, Inc. Education planning
US20080033750A1 (en) * 2006-06-02 2008-02-07 The Trizetto Group, Inc. Enhanced systems and methods for processing of healthcare information
US20100256985A1 (en) * 2009-04-03 2010-10-07 Robert Nix Methods and apparatus for queue-based cluster analysis
US20110153371A1 (en) * 1999-10-14 2011-06-23 Mark Lesswing Novel Method and Apparatus for Repricing a Reimbursement Claim Against a Contract
US8010445B1 (en) * 2005-06-16 2011-08-30 Decker Jerome L Consolidated commercial paper system and method
US8214230B1 (en) 2000-11-21 2012-07-03 The Trizetto Group, Inc. Health plan management method and apparatus
US20130046662A1 (en) * 2006-07-12 2013-02-21 Crowe Horwath Llp System for analyzing revenue cycles of a facility
US8756075B1 (en) 2011-05-18 2014-06-17 Trizetto Corporation System and method for processing payment bundles
JP2015167000A (en) * 2014-03-04 2015-09-24 株式会社三井住友銀行 Delivery guarantee management automation system, method, and program for electronic recording credit
CN106228439A (en) * 2016-07-22 2016-12-14 李丹 A kind of financial data management method and system
US10296976B1 (en) 2011-09-23 2019-05-21 Cognizant Trizetto Software Group, Inc. System and method for calculating estimated payment based on partial coding data
US10318923B1 (en) 2012-08-01 2019-06-11 Cognizant Trizetto Software Group, Inc. Payment assurance and claim pre-validation

Families Citing this family (211)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9619841B2 (en) 1996-03-28 2017-04-11 Integrated Claims Systems, Llc Systems to assist in the creation, transmission, and processing of health insurance claims
US6003007A (en) 1996-03-28 1999-12-14 Dirienzo; Andrew L. Attachment integrated claims system and operating method therefor
US7318046B1 (en) 1998-03-05 2008-01-08 American Management Systems, Inc. Collector's account payment promise option advisory apparatus and method
WO2000030007A2 (en) 1998-11-13 2000-05-25 The Chase Manhattan Bank System and method for multicurrency and multibank processing over a non-secure network
US7082412B1 (en) * 1998-11-23 2006-07-25 Enet 30, Inc. Electronic factoring
AU2349200A (en) * 1998-11-23 2000-06-19 Julie Borges Electronic factoring
US6532450B1 (en) * 1998-12-09 2003-03-11 American Management Systems, Inc. Financial management system including an offset payment process
AU763571B2 (en) 1998-12-23 2003-07-24 Chase Manhattan Bank, The System and method for integrating trading operations including the generation, processing and tracking of and trade documents
US20050033612A1 (en) * 1999-05-07 2005-02-10 Donovan Edward Joseph Automated claim repricing system
US7068832B1 (en) 1999-05-11 2006-06-27 The Chase Manhattan Bank Lockbox imaging system
US7966234B1 (en) 1999-05-17 2011-06-21 Jpmorgan Chase Bank. N.A. Structured finance performance analytics system
US7006994B1 (en) 1999-07-16 2006-02-28 American Management Systems, Inc. Automated receivables management system
US7693731B1 (en) 1999-09-30 2010-04-06 Computer Sciences Corporation Business process framework for reinsurance
US7359863B1 (en) 1999-09-30 2008-04-15 Computer Sciences Corporation Condition component framework for reinsurance
US7047219B1 (en) * 1999-10-04 2006-05-16 Trade Finance Systems, Inc. Trade finance automation system
US7805365B1 (en) 1999-10-25 2010-09-28 Jpmorgan Chase Bank, N.A. Automated statement presentation, adjustment and payment system and method therefor
WO2001033459A1 (en) * 1999-10-29 2001-05-10 University Healthsystem Consortium Funds flow system for academic health centers
US7003470B1 (en) 1999-10-29 2006-02-21 University Healthsystem Consortium Funds flow system for academic health centers
US6798413B1 (en) * 1999-12-03 2004-09-28 Dcs, Inc. Workflow management system
US7822656B2 (en) 2000-02-15 2010-10-26 Jpmorgan Chase Bank, N.A. International banking system and method
US8768836B1 (en) 2000-02-18 2014-07-01 Jpmorgan Chase Bank, N.A. System and method for electronic deposit of a financial instrument by banking customers from remote locations by use of a digital image
US7313540B1 (en) * 2000-03-08 2007-12-25 Hueler Companies Electronic communication system and method for facilitating financial transaction bidding and reporting processes
US7392210B1 (en) 2000-04-07 2008-06-24 Jpmorgan Chase Bank, N.A. Workflow management system and method
US7194431B1 (en) 2000-05-02 2007-03-20 Ge Corporate Financial Services, Inc. Method and apparatus for managing remittance processing within account receivables
US7249074B1 (en) 2000-05-02 2007-07-24 General Electric Canada Equipment Finance G.P. Method, apparatus and computer program for managing accounting system interfaces
US6847942B1 (en) 2000-05-02 2005-01-25 General Electric Canada Equipment Finance G.P. Method and apparatus for managing credit inquiries within account receivables
US6807533B1 (en) 2000-05-02 2004-10-19 General Electric Canada Equipment Finance G.P. Web-based method and system for managing account receivables
US7447988B2 (en) * 2000-05-10 2008-11-04 Ross Gary E Augmentation system for documentation
US7249095B2 (en) 2000-06-07 2007-07-24 The Chase Manhattan Bank, N.A. System and method for executing deposit transactions over the internet
US7095426B1 (en) * 2000-06-23 2006-08-22 Computer Sciences Corporation Graphical user interface with a hide/show feature for a reference system in an insurance claims processing system
US7343307B1 (en) 2000-06-23 2008-03-11 Computer Sciences Corporation Dynamic help method and system for an insurance claims processing system
US7584125B2 (en) * 2000-06-26 2009-09-01 Jpmorgan Chase Bank, N.A. Electronic check presentment system and method having an item sequence capability
US8468071B2 (en) 2000-08-01 2013-06-18 Jpmorgan Chase Bank, N.A. Processing transactions using a register portion to track transactions
AU2001285422A1 (en) 2000-08-11 2002-02-25 John J. Loy Trade receivable processing method and apparatus
US7206768B1 (en) 2000-08-14 2007-04-17 Jpmorgan Chase Bank, N.A. Electronic multiparty accounts receivable and accounts payable system
US7376616B2 (en) * 2000-08-16 2008-05-20 Robert Alan Neubert Method of maximizing accounts payable discounts
AU2001292555A1 (en) * 2000-08-18 2002-03-04 United States Postal Service Apparatus and methods for the secure transfer of electronic data
US7617146B2 (en) * 2000-09-05 2009-11-10 Primerevenue, Inc. Factoring system and method
US7406427B1 (en) * 2000-09-22 2008-07-29 Accenture Llp Capture highly refined claim evaluation information across multiple web interfaces
US7409355B1 (en) * 2000-09-22 2008-08-05 Accenture Llp Line item data processing
US7392212B2 (en) 2000-09-28 2008-06-24 Jpmorgan Chase Bank, N.A. User-interactive financial vehicle performance prediction, trading and training system and methods
US7181422B1 (en) * 2000-10-20 2007-02-20 Tranquilmoney, Inc. Segregation and management of financial assets by rules
US7313541B2 (en) * 2000-11-03 2007-12-25 Jpmorgan Chase Bank, N.A. System and method for estimating conduit liquidity requirements in asset backed commercial paper
WO2002037386A1 (en) 2000-11-06 2002-05-10 First Usa Bank, N.A. System and method for selectable funding of electronic transactions
US20020069088A1 (en) * 2000-12-01 2002-06-06 Berg Brian F. Methods of providing pharmaceuticals and pharmaceutical services
US8805739B2 (en) 2001-01-30 2014-08-12 Jpmorgan Chase Bank, National Association System and method for electronic bill pay and presentment
WO2002075480A2 (en) * 2001-01-31 2002-09-26 Ge Financial Assurance Holdings, Inc. System and process for securitizing payments to third parties
US7124104B2 (en) * 2001-03-30 2006-10-17 Ge Corporate Financial Services, Inc. Methods and systems for implementing a profitability model
US20030149594A1 (en) * 2001-04-13 2003-08-07 Beazley Donald E. System and method for secure highway for real-time preadjudication and payment of medical claims
US7596526B2 (en) 2001-04-16 2009-09-29 Jpmorgan Chase Bank, N.A. System and method for managing a series of overnight financing trades
AU2002345565A1 (en) * 2001-05-25 2003-02-24 United States Postal Service Image encoding and identification for mail processing
US20020198926A1 (en) * 2001-06-25 2002-12-26 Panter Gene L. Program management system and method
US20030033250A1 (en) * 2001-08-10 2003-02-13 Bob Mayes System and method for automatic terminal management
US20030050795A1 (en) * 2001-09-12 2003-03-13 Baldwin Byron S. Health care debt financing system and method
US7333937B2 (en) * 2001-09-13 2008-02-19 Ads Responsecorp, Inc. Health care financing method
CA2406071C (en) * 2001-10-01 2007-09-04 Honda Canada Inc. Tracking multiple payments
US7822684B2 (en) 2001-10-05 2010-10-26 Jpmorgan Chase Bank, N.A. Personalized bank teller machine
US20030069838A1 (en) * 2001-10-09 2003-04-10 Southern Webtech.Com, Inc. Method and system for monitoring and maintaining lines of credit secured by accounts receivable
US7822679B1 (en) 2001-10-29 2010-10-26 Visa U.S.A. Inc. Method and system for conducting a commercial transaction between a buyer and a seller
WO2003038564A2 (en) * 2001-11-01 2003-05-08 Medunite, Inc. System and method for facilitating the exchange of health care transactional information
US20030105713A1 (en) * 2001-12-03 2003-06-05 Greenwald Joshua D. Special purpose entity for holders of financial instruments
CA2485034C (en) * 2002-05-16 2016-07-12 Ndchealth Corporation Systems and methods for verifying and editing electronically transmitted claim content
US20030220863A1 (en) 2002-05-24 2003-11-27 Don Holm System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US7689482B2 (en) 2002-05-24 2010-03-30 Jp Morgan Chase Bank, N.A. System and method for payer (buyer) defined electronic invoice exchange
US8224723B2 (en) 2002-05-31 2012-07-17 Jpmorgan Chase Bank, N.A. Account opening system, method and computer program product
US8108274B2 (en) * 2002-09-06 2012-01-31 Emergis Inc. Interactive electronic bill payment system
US20030050884A1 (en) * 2002-09-24 2003-03-13 Gary Barnett Securitizing financial assets
US7716068B2 (en) 2002-09-25 2010-05-11 Mckesson Financial Holdings Limited Systems and methods for look-alike sound-alike medication error messaging
US20040073442A1 (en) * 2002-10-11 2004-04-15 Heyns Herman R. Strategic planning and valuation
US20040073477A1 (en) * 2002-10-11 2004-04-15 Heyns Herman R. Shareholder value enhancement
US7930195B2 (en) * 2002-10-11 2011-04-19 Accenture Global Services Limited Strategic management and budgeting tools
US20040073467A1 (en) * 2002-10-11 2004-04-15 Heyns Herman R. Software tools and method for business planning
US7689442B2 (en) 2002-10-31 2010-03-30 Computer Science Corporation Method of generating a graphical display of a business rule with a translation
US7676387B2 (en) 2002-10-31 2010-03-09 Computer Sciences Corporation Graphical display of business rules
US7451148B2 (en) * 2002-10-31 2008-11-11 Computer Sciences Corporation Method of modifying a business rule while tracking the modifications
US7769650B2 (en) 2002-12-03 2010-08-03 Jp Morgan Chase Bank Network-based sub-allocation systems and methods for swaps
JP4306408B2 (en) * 2002-12-12 2009-08-05 セイコーエプソン株式会社 Device management system, printer management system, printer management terminal, terminal program, and device management method
US20040117277A1 (en) * 2002-12-16 2004-06-17 Joseph Tagupa Distributing accounts in a workflow system
US7606721B1 (en) 2003-01-31 2009-10-20 CDR Associates, LLC Patient credit balance account analysis, overpayment reporting and recovery tools
US10311412B1 (en) 2003-03-28 2019-06-04 Jpmorgan Chase Bank, N.A. Method and system for providing bundled electronic payment and remittance advice
US8630947B1 (en) 2003-04-04 2014-01-14 Jpmorgan Chase Bank, N.A. Method and system for providing electronic bill payment and presentment
US7634435B2 (en) 2003-05-13 2009-12-15 Jp Morgan Chase Bank Diversified fixed income product and method for creating and marketing same
US7770184B2 (en) 2003-06-06 2010-08-03 Jp Morgan Chase Bank Integrated trading platform architecture
US7930248B1 (en) * 2003-06-30 2011-04-19 Checkfree Corporation Technique for calculating payee specific time to payment completion
US7970688B2 (en) 2003-07-29 2011-06-28 Jp Morgan Chase Bank Method for pricing a trade
US20050044019A1 (en) * 2003-08-04 2005-02-24 Robert Novick System and method for providing a backstop facility in support of the issuance of extendable asset-backed commercial paper
US20050033668A1 (en) * 2003-08-06 2005-02-10 Garcia Carol Ann System and method for online expense management and validation
US7895064B2 (en) 2003-09-02 2011-02-22 Computer Sciences Corporation Graphical input display in an insurance processing system
US7792717B1 (en) 2003-10-31 2010-09-07 Jpmorgan Chase Bank, N.A. Waterfall prioritized payment processing
US7698019B2 (en) * 2003-11-03 2010-04-13 Tech Pharmacy Services, Inc. System and software of enhanced pharmaceutical operations in long-term care facilities and related methods
US7702577B1 (en) 2003-11-06 2010-04-20 Jp Morgan Chase Bank, N.A. System and method for conversion of initial transaction to final transaction
US20050125346A1 (en) * 2003-12-04 2005-06-09 Winiecki Kurt A. Method and system for calculating and presenting bankruptcy preference payment defenses
US7814003B2 (en) 2003-12-15 2010-10-12 Jp Morgan Chase Billing workflow system for crediting charges to entities creating derivatives exposure
US20060036470A1 (en) * 2004-01-28 2006-02-16 Lee Oaks Systems and methods for providing a pharmacy management analysis report
US7693759B2 (en) * 2004-02-03 2010-04-06 International Business Machines Corporation On demand accrual system and method
US7380707B1 (en) 2004-02-25 2008-06-03 Jpmorgan Chase Bank, N.A. Method and system for credit card reimbursements for health care transactions
DE202005002890U1 (en) * 2004-03-22 2005-07-14 Sap Ag Systems for managing and reporting financial information
US8423447B2 (en) 2004-03-31 2013-04-16 Jp Morgan Chase Bank System and method for allocating nominal and cash amounts to trades in a netted trade
US7430536B1 (en) * 2004-04-01 2008-09-30 Daniel A. Borten System and method for assisting a bank in meeting requirements under the community reinvestment act
US20090043637A1 (en) * 2004-06-01 2009-02-12 Eder Jeffrey Scott Extended value and risk management system
US8554673B2 (en) 2004-06-17 2013-10-08 Jpmorgan Chase Bank, N.A. Methods and systems for discounts management
US8571977B2 (en) 2004-06-17 2013-10-29 Visa International Service Association Method and system for providing seller bank receivable discounting aggregation services
US8121944B2 (en) 2004-06-24 2012-02-21 Jpmorgan Chase Bank, N.A. Method and system for facilitating network transaction processing
US7881995B2 (en) * 2004-07-02 2011-02-01 Capital Tool Company Systems and methods for objective financing of assets
US8290862B2 (en) 2004-07-23 2012-10-16 Jpmorgan Chase Bank, N.A. Method and system for expediting payment delivery
US8290863B2 (en) 2004-07-23 2012-10-16 Jpmorgan Chase Bank, N.A. Method and system for expediting payment delivery
US7693770B2 (en) 2004-08-06 2010-04-06 Jp Morgan Chase & Co. Method and system for creating and marketing employee stock option mirror image warrants
US7904306B2 (en) 2004-09-01 2011-03-08 Search America, Inc. Method and apparatus for assessing credit for healthcare patients
US7711639B2 (en) 2005-01-12 2010-05-04 Visa International Pre-funding system and method
US8688569B1 (en) 2005-03-23 2014-04-01 Jpmorgan Chase Bank, N.A. System and method for post closing and custody services
US7860782B2 (en) 2005-05-24 2010-12-28 Magnum Communications, Limited System and method for defining attributes, decision rules, or both, for remote execution, claim set IV
US8024778B2 (en) * 2005-05-24 2011-09-20 CRIF Corporation System and method for defining attributes, decision rules, or both, for remote execution, claim set I
US8019828B2 (en) * 2005-05-24 2011-09-13 CRIF Corporation System and method for defining attributes, decision rules, or both, for remote execution, claim set III
US8019843B2 (en) * 2005-05-24 2011-09-13 CRIF Corporation System and method for defining attributes, decision rules, or both, for remote execution, claim set II
US8321283B2 (en) * 2005-05-27 2012-11-27 Per-Se Technologies Systems and methods for alerting pharmacies of formulary alternatives
US20060277129A1 (en) * 2005-06-06 2006-12-07 Orbian Corporation System and method of transaction settlement and supply chain financing
US7822682B2 (en) 2005-06-08 2010-10-26 Jpmorgan Chase Bank, N.A. System and method for enhancing supply chain transactions
US7676409B1 (en) 2005-06-20 2010-03-09 Jpmorgan Chase Bank, N.A. Method and system for emulating a private label over an open network
US8589274B2 (en) * 2005-07-08 2013-11-19 Open Market Partners, Inc. System and method for managing healthcare costs
US7567928B1 (en) 2005-09-12 2009-07-28 Jpmorgan Chase Bank, N.A. Total fair value swap
US20070073685A1 (en) * 2005-09-26 2007-03-29 Robert Thibodeau Systems and methods for valuing receivables
US7818238B1 (en) 2005-10-11 2010-10-19 Jpmorgan Chase Bank, N.A. Upside forward with early funding provision
US8301529B1 (en) 2005-11-02 2012-10-30 Jpmorgan Chase Bank, N.A. Method and system for implementing effective governance of transactions between trading partners
US20140039920A1 (en) * 2005-11-22 2014-02-06 Robert J. Nadai Methodology, system and computer program product for generating electronic insurance claims or bills, having optimized insurance claim items in order to maximize reimbursement and to facilitate approval of the claim(s) upon first submission to the insurance carrier
US8560350B2 (en) * 2005-11-22 2013-10-15 Robert J. Nadai Method, system and computer program product for generating an electronic bill having optimized insurance claim items
US20070162303A1 (en) * 2005-12-08 2007-07-12 Ndchealth Corporation Systems and Methods for Shifting Prescription Market Share by Presenting Pricing Differentials for Therapeutic Alternatives
US20070156551A1 (en) * 2005-12-30 2007-07-05 Smith Thomas L Method of creating and utilizing healthcare related commodoties
US7801786B2 (en) * 2005-12-30 2010-09-21 Open Market Partners, Inc. Method of creating and utilizing healthcare related commodoties
US8280794B1 (en) 2006-02-03 2012-10-02 Jpmorgan Chase Bank, National Association Price earnings derivative financial product
US7711636B2 (en) * 2006-03-10 2010-05-04 Experian Information Solutions, Inc. Systems and methods for analyzing data
US7620578B1 (en) 2006-05-01 2009-11-17 Jpmorgan Chase Bank, N.A. Volatility derivative financial product
US7647268B1 (en) 2006-05-04 2010-01-12 Jpmorgan Chase Bank, N.A. System and method for implementing a recurrent bidding process
US7734545B1 (en) 2006-06-14 2010-06-08 Jpmorgan Chase Bank, N.A. Method and system for processing recurring payments
US9811868B1 (en) 2006-08-29 2017-11-07 Jpmorgan Chase Bank, N.A. Systems and methods for integrating a deal process
US11887175B2 (en) 2006-08-31 2024-01-30 Cpl Assets, Llc Automatically determining a personalized set of programs or products including an interactive graphical user interface
US8799148B2 (en) 2006-08-31 2014-08-05 Rohan K. K. Chandran Systems and methods of ranking a plurality of credit card offers
US8036979B1 (en) 2006-10-05 2011-10-11 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US7827096B1 (en) 2006-11-03 2010-11-02 Jp Morgan Chase Bank, N.A. Special maturity ASR recalculated timing
US7916925B2 (en) 2007-02-09 2011-03-29 Jpmorgan Chase Bank, N.A. System and method for generating magnetic ink character recognition (MICR) testing documents
US20080281632A1 (en) * 2007-05-11 2008-11-13 Nobelus, Inc. Predictive billing and collection for medical services
US20080294540A1 (en) 2007-05-25 2008-11-27 Celka Christopher J System and method for automated detection of never-pay data sets
US8010391B2 (en) * 2007-06-29 2011-08-30 Computer Sciences Corporation Claims processing hierarchy for insured
US8000986B2 (en) * 2007-06-04 2011-08-16 Computer Sciences Corporation Claims processing hierarchy for designee
US8010390B2 (en) 2007-06-04 2011-08-30 Computer Sciences Corporation Claims processing of information requirements
US8010389B2 (en) 2007-06-04 2011-08-30 Computer Sciences Corporation Multiple policy claims processing
US8762270B1 (en) 2007-08-10 2014-06-24 Jpmorgan Chase Bank, N.A. System and method for providing supplemental payment or transaction information
US8788281B1 (en) 2007-12-03 2014-07-22 Jp Morgan Chase Bank, N.A. System and method for processing qualified healthcare account related financial transactions
US20090164376A1 (en) * 2007-12-20 2009-06-25 Mckesson Financial Holdings Limited Systems and Methods for Controlled Substance Prescription Monitoring Via Real Time Claims Network
US7766244B1 (en) 2007-12-31 2010-08-03 Jpmorgan Chase Bank, N.A. System and method for processing transactions using a multi-account transactions device
US8622308B1 (en) 2007-12-31 2014-01-07 Jpmorgan Chase Bank, N.A. System and method for processing transactions using a multi-account transactions device
US8219424B2 (en) 2008-01-18 2012-07-10 Computer Sciences Corporation Determining amounts for claims settlement using likelihood values
CA2651167A1 (en) * 2008-01-25 2009-07-25 Standard Medical Acceptance Corporation The securitization of health care receivables
WO2009117518A1 (en) * 2008-03-19 2009-09-24 Experian Information Solutions, Inc. System and method for tracking and analyzing loans involved in asset-backed securities
US8635083B1 (en) 2008-04-02 2014-01-21 Mckesson Financial Holdings Systems and methods for facilitating the establishment of pharmaceutical rebate agreements
US8626525B2 (en) * 2008-06-23 2014-01-07 Mckesson Financial Holdings Systems and methods for real-time monitoring and analysis of prescription claim rejections
US8538777B1 (en) 2008-06-30 2013-09-17 Mckesson Financial Holdings Limited Systems and methods for providing patient medication history
US20090327363A1 (en) * 2008-06-30 2009-12-31 Peter Cullen Systems and methods for processing electronically transmitted healthcare related transactions
US20090326977A1 (en) * 2008-06-30 2009-12-31 Mckesson Financial Holding Limited Systems and Methods for Providing Drug Samples to Patients
US7991689B1 (en) 2008-07-23 2011-08-02 Experian Information Solutions, Inc. Systems and methods for detecting bust out fraud using credit data
US9256904B1 (en) 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US8380601B2 (en) * 2008-08-29 2013-02-19 Jpmorgan Chase Bank, N.A. System for and method of international pooling
US8112355B1 (en) 2008-09-05 2012-02-07 Jpmorgan Chase Bank, N.A. Method and system for buyer centric dispute resolution in electronic payment system
US8412593B1 (en) 2008-10-07 2013-04-02 LowerMyBills.com, Inc. Credit card matching
US8391584B2 (en) 2008-10-20 2013-03-05 Jpmorgan Chase Bank, N.A. Method and system for duplicate check detection
US9092447B1 (en) 2008-10-20 2015-07-28 Jpmorgan Chase Bank, N.A. Method and system for duplicate detection
US8046242B1 (en) 2009-01-22 2011-10-25 Mckesson Financial Holdings Limited Systems and methods for verifying prescription dosages
US20100211416A1 (en) * 2009-02-19 2010-08-19 William Fielding Frank Method and apparatus for healthcare funding exchange
US20100293004A1 (en) * 2009-05-15 2010-11-18 Vernon Jack Nye Payer estimation and identification methods and apparatus
US20100318453A1 (en) * 2009-06-16 2010-12-16 Daniel Paul Francis Business method and system for providing a health security organization for procuring and financing healthcare products and services
US8666775B2 (en) * 2009-06-16 2014-03-04 Daniel Paul Francis Business method and system for providing a health security organization for procuring and financing healthcare products and services
US8224791B2 (en) * 2009-09-11 2012-07-17 Sap Ag Information lifecycle cross-system reconciliation
US8489415B1 (en) 2009-09-30 2013-07-16 Mckesson Financial Holdings Limited Systems and methods for the coordination of benefits in healthcare claim transactions
US20110145164A1 (en) * 2009-12-10 2011-06-16 Lavoie Andre G System and method for facilitating the creation, management, and valuation of securities research
US8788296B1 (en) 2010-01-29 2014-07-22 Mckesson Financial Holdings Systems and methods for providing notifications of availability of generic drugs or products
US8386276B1 (en) 2010-02-11 2013-02-26 Mckesson Financial Holdings Limited Systems and methods for determining prescribing physician activity levels
US8321243B1 (en) 2010-02-15 2012-11-27 Mckesson Financial Holdings Limited Systems and methods for the intelligent coordination of benefits in healthcare transactions
US8738514B2 (en) 2010-02-18 2014-05-27 Jpmorgan Chase Bank, N.A. System and method for providing borrow coverage services to short sell securities
US8352354B2 (en) 2010-02-23 2013-01-08 Jpmorgan Chase Bank, N.A. System and method for optimizing order execution
US9652802B1 (en) 2010-03-24 2017-05-16 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
US8548824B1 (en) 2010-03-26 2013-10-01 Mckesson Financial Holdings Limited Systems and methods for notifying of duplicate product prescriptions
US8447641B1 (en) 2010-03-29 2013-05-21 Jpmorgan Chase Bank, N.A. System and method for automatically enrolling buyers into a network
US8688468B1 (en) 2010-03-30 2014-04-01 Mckesson Financial Holdings Systems and methods for verifying dosages associated with healthcare transactions
US8725613B1 (en) 2010-04-27 2014-05-13 Experian Information Solutions, Inc. Systems and methods for early account score and notification
US8589288B1 (en) 2010-10-01 2013-11-19 Jpmorgan Chase Bank, N.A. System and method for electronic remittance of funds
US8930262B1 (en) 2010-11-02 2015-01-06 Experian Technology Ltd. Systems and methods of assisted strategy design
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
US8543504B1 (en) 2011-03-30 2013-09-24 Jpmorgan Chase Bank, N.A. Systems and methods for automated invoice entry
US8543503B1 (en) 2011-03-30 2013-09-24 Jpmorgan Chase Bank, N.A. Systems and methods for automated invoice entry
US9558519B1 (en) 2011-04-29 2017-01-31 Consumerinfo.Com, Inc. Exposing reporting cycle information
US20120323775A1 (en) * 2011-06-14 2012-12-20 Bank Of America Enhanced searchability of fields associated with online billpay memo data
US8725532B1 (en) 2012-06-29 2014-05-13 Mckesson Financial Holdings Systems and methods for monitoring controlled substance distribution
USD678653S1 (en) 2012-07-19 2013-03-19 Jpmorgan Chase Bank, N.A. Drive-up financial transaction machine
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
US9697263B1 (en) 2013-03-04 2017-07-04 Experian Information Solutions, Inc. Consumer data request fulfillment system
USD690074S1 (en) 2013-03-13 2013-09-17 Jpmorgan Chase Bank, N.A. Financial transaction machine
US9058626B1 (en) 2013-11-13 2015-06-16 Jpmorgan Chase Bank, N.A. System and method for financial services device usage
CA2931257A1 (en) * 2013-12-02 2015-06-11 Finmason, Inc. Systems and methods for financial asset analysis
US10430555B1 (en) 2014-03-13 2019-10-01 Mckesson Corporation Systems and methods for determining and communicating information to a pharmacy indicating patient eligibility for an intervention service
US9836580B2 (en) * 2014-03-21 2017-12-05 Palantir Technologies Inc. Provider portal
US10297344B1 (en) 2014-03-31 2019-05-21 Mckesson Corporation Systems and methods for establishing an individual's longitudinal medication history
US10642957B1 (en) 2014-10-21 2020-05-05 Mckesson Corporation Systems and methods for determining, collecting, and configuring patient intervention screening information from a pharmacy
US10776799B2 (en) * 2015-03-17 2020-09-15 Mp Cloud Technologies, Inc. Software for emergency medical services
US10757154B1 (en) 2015-11-24 2020-08-25 Experian Information Solutions, Inc. Real-time event-based notification system
WO2018144612A1 (en) 2017-01-31 2018-08-09 Experian Information Solutions, Inc. Massive scale heterogeneous data ingestion and user resolution
US10650380B1 (en) 2017-03-31 2020-05-12 Mckesson Corporation System and method for evaluating requests
US10735183B1 (en) 2017-06-30 2020-08-04 Experian Information Solutions, Inc. Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network
US10909267B2 (en) 2017-08-18 2021-02-02 Paypal, Inc. System for account restrictions
US11620403B2 (en) 2019-01-11 2023-04-04 Experian Information Solutions, Inc. Systems and methods for secure data aggregation and computation
US11645344B2 (en) 2019-08-26 2023-05-09 Experian Health, Inc. Entity mapping based on incongruent entity data
BE1028068B1 (en) * 2020-02-17 2021-09-13 Bislink Computerized billing tracking process
CN112232045B (en) * 2020-10-23 2021-08-24 四川大学锦城学院 Automatic enterprise account-reporting management system and management method thereof

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4667292A (en) * 1984-02-16 1987-05-19 Iameter Incorporated Medical reimbursement computer system
US5325290A (en) * 1989-08-14 1994-06-28 Compucom Communications Corp. Billing system with data indexing
US5359509A (en) * 1991-10-31 1994-10-25 United Healthcare Corporation Health care payment adjudication and review system
US5361202A (en) * 1993-06-18 1994-11-01 Hewlett-Packard Company Computer display system and method for facilitating access to patient data records in a medical information system
US5383113A (en) * 1991-07-25 1995-01-17 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS60189575A (en) * 1984-03-09 1985-09-27 Sanyo Electric Co Ltd Data storage system of medical insurance charging computer
US4916611A (en) 1987-06-30 1990-04-10 Northern Group Services, Inc. Insurance administration system with means to allow an employer to directly communicate employee status data to centralized data storage means

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4667292A (en) * 1984-02-16 1987-05-19 Iameter Incorporated Medical reimbursement computer system
US5325290A (en) * 1989-08-14 1994-06-28 Compucom Communications Corp. Billing system with data indexing
US5383113A (en) * 1991-07-25 1995-01-17 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans
US5359509A (en) * 1991-10-31 1994-10-25 United Healthcare Corporation Health care payment adjudication and review system
US5361202A (en) * 1993-06-18 1994-11-01 Hewlett-Packard Company Computer display system and method for facilitating access to patient data records in a medical information system

Cited By (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110153371A1 (en) * 1999-10-14 2011-06-23 Mark Lesswing Novel Method and Apparatus for Repricing a Reimbursement Claim Against a Contract
US8666787B2 (en) 1999-10-14 2014-03-04 Trizetto Corporation Method and apparatus for repricing a reimbursement claim against a contract
US8407071B2 (en) 1999-10-14 2013-03-26 The Trizetto Group, Inc. Method and apparatus for repricing a reimbursement claim against a contract
US8160905B2 (en) 1999-10-14 2012-04-17 The Trizetto Group, Inc. Method and apparatus for repricing a reimbursement claim against a contract
US20110161106A1 (en) * 2000-01-21 2011-06-30 Sherwood Chapman Method of Increasing Efficiency in a Medical Claim Transaction, and Computer Program Capable of Executing Same
US8494876B2 (en) 2000-01-21 2013-07-23 The Trizetto Group, Inc. Method of increasing efficiency in a medical claim transaction, and computer program capable of executing same
US10289804B2 (en) 2000-01-21 2019-05-14 Cognizant Trizetto Software Group, Inc. Method of increasing efficiency in a medical claim transaction, and computer program capable of executing same
US8738402B2 (en) 2000-01-21 2014-05-27 Trizetto Corporation Medical of increasing efficiency in a medical claim transaction, and computer program capable of executing same
US20050108067A1 (en) * 2000-01-21 2005-05-19 Quality Care Solutions, Inc. Method of increasing efficiency in a medical claim transaction, and computer program capable of executing same
US8099302B2 (en) 2000-01-21 2012-01-17 The Trizetto Group, Inc. Method of increasing efficiency in a medical claim transaction, and computer program capable of executing same
US8214230B1 (en) 2000-11-21 2012-07-03 The Trizetto Group, Inc. Health plan management method and apparatus
US9727695B2 (en) 2000-11-21 2017-08-08 Cognizant Trizetto Software Group, Inc. Health plan management method and apparatus
US8706524B2 (en) 2000-11-21 2014-04-22 Trizetto Corporation Health plan management method and apparatus
US8768729B2 (en) 2004-10-14 2014-07-01 Trizetto Corporation System and method for using a first electronic representation of contract terms for generating a second electronic representation of the contract terms
US20060085311A1 (en) * 2004-10-14 2006-04-20 The Trizetto Group, Inc. System and method for using a first electronic representation of contract terms for generating a second electronic representation of the contract terms
US10762570B2 (en) 2004-10-14 2020-09-01 Cognizant Trizetto Software Group, Inc. System and method for using a first electronic representation of contract terms for generating a second electronic representation of the contract terms
US8010445B1 (en) * 2005-06-16 2011-08-30 Decker Jerome L Consolidated commercial paper system and method
US20070196794A1 (en) * 2006-02-21 2007-08-23 Northstar Capital Markets Services, Inc. Education planning
US7680729B2 (en) * 2006-02-21 2010-03-16 Northstar Capital Markets Services, Inc. Education planning
US20080033750A1 (en) * 2006-06-02 2008-02-07 The Trizetto Group, Inc. Enhanced systems and methods for processing of healthcare information
US20130046662A1 (en) * 2006-07-12 2013-02-21 Crowe Horwath Llp System for analyzing revenue cycles of a facility
US8768796B2 (en) * 2006-07-12 2014-07-01 Crowe Horwath Llp System for analyzing revenue cycles of a facility
US8756071B2 (en) 2009-04-03 2014-06-17 Athenahealth, Inc. Methods and apparatus for queue-based cluster analysis
US20100256985A1 (en) * 2009-04-03 2010-10-07 Robert Nix Methods and apparatus for queue-based cluster analysis
US20100257074A1 (en) * 2009-04-03 2010-10-07 Joseph Hendrickson Methods and apparatus for early remittance issue detection
US8756075B1 (en) 2011-05-18 2014-06-17 Trizetto Corporation System and method for processing payment bundles
US10262374B2 (en) 2011-05-18 2019-04-16 Cognizant Trizetto Software Group, Inc. System and method for processing payment bundles
US10937106B2 (en) 2011-05-18 2021-03-02 Cognizant Trizetto Software Group, Inc. System and method for processing payment bundles
US10296976B1 (en) 2011-09-23 2019-05-21 Cognizant Trizetto Software Group, Inc. System and method for calculating estimated payment based on partial coding data
US10318923B1 (en) 2012-08-01 2019-06-11 Cognizant Trizetto Software Group, Inc. Payment assurance and claim pre-validation
US10733567B2 (en) 2012-08-01 2020-08-04 Cognizant Trizetto Software Group, Inc. Payment assurance and claim pre-validation
JP2015167000A (en) * 2014-03-04 2015-09-24 株式会社三井住友銀行 Delivery guarantee management automation system, method, and program for electronic recording credit
CN106228439A (en) * 2016-07-22 2016-12-14 李丹 A kind of financial data management method and system

Also Published As

Publication number Publication date
US7254555B2 (en) 2007-08-07
US20020133460A1 (en) 2002-09-19
US6073104A (en) 2000-06-06

Similar Documents

Publication Publication Date Title
US7254555B2 (en) System for invoice record management and asset-backed commercial paper program management
US5704044A (en) Computerized healthcare accounts receivable purchasing, collections, securitization and management system
US7194431B1 (en) Method and apparatus for managing remittance processing within account receivables
AU2001256575B2 (en) Method and apparatus for managing credit inquiries within account receivables
US6456979B1 (en) Method of evaluating a permanent life insurance policy
EP1222596B1 (en) System and method for dividing a remittance and distributing a portion of the funds to multiple investment products
US7249037B2 (en) System for managing a stable value protected investment plan
AU2001258683B2 (en) Method, apparatus and computer program for managing accounting system interfaces
US20040064398A1 (en) Method and system for financing publicly traded companies
US20030050795A1 (en) Health care debt financing system and method
US20090216670A1 (en) Commission management system
AU2001256600B2 (en) Method and apparatus for managing account receivables
US20070067236A1 (en) Method and system for advancing funds
JP2003529129A (en) Trade finance automation system
JPS6316371A (en) Method and apparatus for supplying fund for future debt of uncertain counter value
AU2001252496A1 (en) Method and apparatus for managing remittance processing within account receivables
AU2001258683A1 (en) Method, apparatus and computer program for managing accounting system interfaces
AU2001256600A1 (en) Method and apparatus for managing account receivables
EP0825544A1 (en) Computerized healthcare accounts receivable purchasing, collections, securitization and management system
Rajan et al. Trade Credit: theories and evidence
AU2001252491A1 (en) Method and apparatus for managing accounts receivable claims
OFFICE OF THE INSPECTOR GENERAL (DEPARTMENT OF DEFENSE) ALEXANDRIA VA Medicare-Eligible Retiree Health Care Fund Audited Financial Statements. Fiscal Year 2011
INSPECTOR GENERAL DEPT OF DEFENSE ARLINGTON VA Medicare-Eligible Retiree Health Care Fund Audited Financial Statements. Fiscal Year 2013
KR20070022245A (en) Method and system for advancing funds
Porn et al. Revenue Cycle

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION