PRE-PAID AND CLOSED LOOP TRANSACTION SYSTEM

Abstract

A method for processing transactions comprising receiving transaction data. Electronically determining whether to process the transaction data as a pre-paid transaction or a closed loop transaction using data processing equipment. Processing the transaction using pre-paid network rules if it is determined that the transaction data defines the pre-paid transaction. Processing the transaction using closed loop transaction rules if it is determined that the transaction data defines the closed loop transaction. Scheduling payment as a function of whether the transaction data was processed as the pre-paid transaction or the closed transaction. Generating an explanation of benefits after the payment is scheduled.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This application is a Divisional of U.S. application Ser. No. 13/764,319, filed by David Bradley Dean on Feb. 11, 2013, entitled “Post-Authorization Transaction Bundling Control,” currently pending; commonly assigned with this application and incorporated herein by reference.

TECHNICAL FIELD

The invention relates to pre-paid and closed loop transaction processing, and more particularly to an apparatus and method for pre-paid and closed loop transaction processing for processing and payment of claims for medical services.

BACKGROUND

Processing of claims for medical services is presently performed in batch mode, and is typically outsourced by insurance companies to third parties that are responsible for printing and mailing checks to medical service providers, and for mailing an explanation of benefits (EOB) to the insured party.

SUMMARY

A method for processing transactions is provided that includes receiving transaction data, such as from one of a plurality of insurance companies. The transaction data is processed electronically to determine whether it is pre-paid transaction data or closed loop transaction data. The transaction is processed using pre-paid network rules if it is determined that the transaction data is for a pre-paid card transaction. The transaction is processed using closed loop transaction rules if it is determined that the transaction data is for a closed loop transaction. Payment is scheduled as a function of whether the transaction data was processed as a pre-paid transaction or a closed transaction. An explanation of benefits is generated, such as for transmission to a patient, after the payment is scheduled.

BRIEF DESCRIPTION

Reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a diagram of a system for a hybrid prepaid and closed loop payment process for health services providers in accordance with an exemplary embodiment of the present invention;

FIG. 2 is a diagram of a system for a prepaid card system in accordance with an exemplary embodiment of the present invention;

FIG. 3 is a diagram of a system for explanation of benefit and payment processing in accordance with an exemplary embodiment of the present invention;

FIG. 4 is a diagram of a system for electronically migrating services from a prepaid card system to a closed loop system in accordance with an exemplary embodiment of the present invention;

FIG. 5 is a flowchart of an algorithm for configuring payment processing in accordance with an exemplary embodiment of the present invention;

FIG. 6 is a flowchart of an algorithm for electronically migrating a health services provider from a prepaid card to a closed loop electronic account and for electronically processing transactions in accordance with an exemplary embodiment of the present invention; and

FIG. 7 is a flow chart of an algorithm for pre-paid and closed loop processing in accordance with an exemplary embodiment of the present invention.

DETAILED DESCRIPTION

In the description that follows, like parts are marked throughout the specification and drawings with the same reference numerals, respectively. The drawing figures might not be to scale and certain components can be shown in generalized or schematic form and identified by commercial designations in the interest of clarity and conciseness.

FIG. 1 is a diagram of a system 100 for a hybrid prepaid and closed loop payment process for health services providers in accordance with an exemplary embodiment of the present invention. System 100 includes insurance services platform 102, which can be implemented in hardware or a suitable combination of hardware and software. As used herein and by way of example and not by limitation, “hardware” can include a combination of discrete components, an integrated circuit, an application-specific integrated circuit, a field programmable gate array, a general purpose processing or server platform, or other suitable hardware. As used herein and by way of example and not by limitation, “software” can include one or more objects, agents, threads, lines of code, subroutines, separate software applications, one or more lines of code or other suitable software structures operating in one or more software applications or on one or more processors, or other suitable software structures. In one exemplary embodiment, software can include one or more lines of code or other suitable software structures operating in a general purpose software application, such as an operating system, and one or more lines of code or other suitable software structures operating in a specific purpose software application.

Insurance services platform 102 is coupled to insurance companies 104A through 104N, health services providers 106A through 106N, patient interfaces 114A through 114N, bank 108, bank 110 and credit card network 112 through a suitable communications medium. Each of these separate system components can be implemented in hardware or a suitable combination of hardware and software, and can be one or more software systems operating on a general purpose processing platform, a server platform, or other suitable platforms. As used herein, a communications medium can include a wire line communications medium, a wireless communications medium, an optical communications medium, an analog communications medium, a digital communications medium, other suitable communications media or a suitable combination of communications media. As used herein, the term “coupled” and its cognate terms such as “couples” or “couple,” can include a physical connection (such as a wire, optical fiber, or a telecommunications medium), a virtual connection (such as through randomly assigned memory locations of a data memory device or a hypertext transfer protocol (HTTP) link), a logical connection (such as through one or more semiconductor devices in an integrated circuit), or other suitable connections. In one exemplary embodiment, a communications medium can be a network or other suitable communications media.

In addition, insurance services platform 102 includes prepaid card system 116, EOB and payment system 118, insurance gateway 120, HSP gateway 122, migrated services system 124, and patient gateway 126. Insurance services platform 102 provides payment for health service providers, a patient interface for insurance service providers, and other suitable functionality. In one exemplary embodiment, insurance services platform 102 can be used to coordinate payments to health service providers for health services provided to patients using a prepaid card instead of checks. In this exemplary embodiment, the use of a prepaid card allows a health services provider to be electronically notified of an available payment by an insurance company or other suitable parties, so that the health services provider can coordinate the transfer of funds using the prepaid card through their existing card services payment provider. In another exemplary embodiment, system 100 can be used for closed loop processing, such as to allow health service providers to obtain payments from insurance companies using the Automated Clearing House (ACH) network or other bank networks. Likewise, migration between the prepaid card functionality and the closed loop system processing functionality is provided by system 100, such as to allow health services providers to migrate from an electronic prepaid card electronic account to an electronic closed loop electronic account. As used herein, an electronic account can be implemented using suitable database tools and interface tools to define a set of data associated with an entity and to allow data to be selectively stored, retrieved and modified in predetermined electronic data fields associated with the electronic account, or other suitable system and processes can also or alternatively be used.

Insurance companies 104A through 104N can be insurance company data processing systems that provide data that is used to generate explanations of benefits, that receive requests from health service providers for authorization to perform health services, that receive requests for payment from health service providers for health care services that have been authorized and provided to insured parties, or that provide other suitable functions. In one exemplary embodiment, insurance companies 104A through 104N can be existing insurance company data processing systems that provide payments and explanations of benefits data in electronic data interchange (EDI) form to third-party processors for paper transaction processing or other suitable transaction processing, as suitably modified to be used in conjunction with system 100. It is also noted that the terms “authorization” and “settlement” can refer to both a health service provider's request for authorization to provide services to a patient and settlement of the charges for those services, as well as authorization and settlement of fund transfers, depending on the context used.

Health services providers 106A through 106N can be one or more data processing systems associated with health service providers such as doctors, doctor practice groups, hospitals, or other health service providers, such as data processing systems that receive patient information, contact insurance companies for authorization, approval, and information such as co-pay amounts, that submit requests for payment of services under a patient's insurance contract with the insurance company, and that perform other suitable functions. In one exemplary embodiment, health services providers 106A through 106N may be configured to interface directly with insurance companies 104A through 104N through various individual gateways with each insurance company, using paper forms, or in other suitable manners, and may also or alternatively interface with insurance services platform 102.

Patient interfaces 114A through 114N allow patients to interface with their insurance companies 104A through 104N and health services providers 106A through 106N through insurance services platform 102. In this manner, patients can receive an explanation of benefits or other suitable data from an insurance company, can receive messaging from health services providers, or can otherwise contact or be contacted by the insurance companies or health service providers as needed.

Bank 108 and bank 110 provide banking functions for closed loop or prepaid card system processing. In one exemplary embodiment, a bank may be required to act as a sponsor in order to access credit card network 112 to provide for prepaid card system 116 functionality. In addition, bank 108 and bank 110 are coupled through the ACH to provide for transfers of funds between electronic accounts at each institution. System 100 allows inter-bank and intra-bank fund transfers to be performed as needed, using the ACH network or in other suitable manners. Different banking account structures can also be implemented using system 100. In one exemplary embodiment, insurance services platform 102 can have a bank account that is used to hold funds in trust for insurance companies 104A through 104N and health services providers 106A through 106N, where money is transferred from the bank account of insurance services platform 102 to bank accounts for insurance companies 104A through 104N and health services providers 106A through 106N as part of a settlement and authorization process. Likewise, insurance services platform 102 can generate paper checks, can use a credit card network such as Visa or MasterCard, or other suitable processes can be used to transfer funds between the bank accounts of the insurance companies, insurance services platform 102 and health services providers.

Prepaid card system 116 allows insurance services platform 102 to issue prepaid cards to health services providers 106A through 106N for each of insurance companies 104A through 104N. In one exemplary embodiment, each health services provider 106A through 106N can receive a single prepaid card which can be funded from any of insurance companies 104A through 104N. In another exemplary embodiment, each insurance company 104A through 104N can provide each health services provider 106A through 106N with a different prepaid card. Other suitable configurations can also or alternatively be used.

EOB and payment system 118 allows insurance companies 104A through 104N to provide explanations of benefits and payment data to insurance services platform 102. EOB and payment system 118 can also determine whether any of health services providers 106A through 106N should receive EOB data and payments, whether patient interfaces 114A through 114N are configured to receive electronic EOB data, and can perform other suitable functions. In one exemplary embodiment, insurance services platform 102 or EOB and payment system 118 can be configured to provide a notice to insurance companies 104A through 104N that the health services provider or patient interface is not available for an explanation of benefits or payment for a claim. In another exemplary embodiment, insurance services platform 102 can contact health services providers 106A through 106N or patient interfaces 114A through 114N in response to receiving EOB and payment data from insurance companies 104A through 104N, or can provide other suitable functions.

Insurance gateway 120 allows insurance companies 104A through 104N to access data stored on insurance services platform 102. In one exemplary embodiment, insurance gateway 120 allows an insurance company to dispute a charge from a health services provider, to communicate with a health services provider, to respond to queries from patients submitted through patient interfaces 114A through 114N, or to provide other suitable services. Insurance gateway 120 also receives EOB data files, EDI data files, or other suitable data files and generates account data for health services providers and patients. In one exemplary embodiment, the EOB data files and EDI data files can include predetermined data fields that are used to identify health services providers, patients and other parties, such as name fields, account number fields, address fields, social security number fields, telephone number fields and other suitable fields. In order to facilitate the creation of either a prepaid services account or a closed loop account, insurance gateway 120 can use these data fields to automatically generate account data is accounts for patients, health service providers or other suitable parties are determined not to exist when the EOB data files, EDI data files or other suitable data files are received from the insurance company.

HSP gateway 122 provides a gateway for health services providers 106A through 106N to interface with insurance services platform 102. In one exemplary embodiment, HSP gateway 122 allows health services providers 106A through 106N to submit claims for authorization or settlement to insurance companies 104A through 104N, can allow health services providers 106A through 106N to request payment from a prepaid card, or can provide other suitable services.

Migrated services system 124 allows health services providers 106A through 106N to migrate from prepaid card system 116 to a closed loop authorization and settlement system. In this exemplary embodiment, a closed loop system allows insurance services platform 102 to handle all payment authorization and settlement processes, such as to allow health services providers 106A through 106N to submit claims to insurance companies 104A through 104N for authorization, to submit claims to insurance companies 104A through 104N for payment after provision of services, to address any questions or disputes that insurance companies 104A through 104N may have with claims submitted by health services providers 106A through 106N, or to provide other suitable functions.

Patient gateway 126 allows patients through patient interfaces 114A through 114N to access explanation of benefits data, payment data, other suitable data. In one exemplary embodiment, patient gateway 126 can allow patients to coordinate a flexible spending program electronic account at bank 108 or bank 110 for payment of co-pays, can allow patients to register for reimbursement of out-of-pocket co-pays paid to health services providers 106A through 106N, can allow health services providers 106A through 106N to receive co-pays from flexible spending electronic accounts for patients through bank 108 or 110, or can provide other suitable functionality.

In operation, system 100 provides an integrated insurance platform or switch to allow health services providers, insurance companies, and patients to interface through a single switch platform. In one exemplary embodiment, system 100 allows health services providers to be initially approached to receive payments using a prepaid card through the credit card network 112 instead of individual checks or groups of checks for processed EOB statements from insurance companies 104A through 104N. In this exemplary embodiment, health services providers 106A through 106N can be provided with an incentive for switching from a paper check system to the prepaid card system, namely, to receive faster payment. Likewise, health services providers 106A through 106N can migrate to a closed loop system that is managed on insurance services platform 102, where bank accounts held by insurance companies 104A through 104N and health services providers 106A through 106N are accessed via the ACH based on rules managed by insurance services platform 102. In this exemplary embodiment, insurance services platform 102 provides closed loop processing in the form of authorization, settlement, and dispute processing, similar to the credit card network 112, but without the additional fees charged by credit card network 112.

FIG. 2 is a diagram of a system 200 for a prepaid card system in accordance with an exemplary embodiment of the present invention. System 200 includes prepaid card system 116 and prepaid cardholder account management 202, authorization and settlement system 204, card management and fulfillment system 206 and reporting system 208, each of which can be implemented in hardware or a suitable combination of hardware and software, and which can be one or more software systems operating on a general purpose processing or server platform.

Prepaid cardholder account management 202 allows prepaid cardholder electronic accounts to be managed by insurance services platform 102 or other suitable systems. In one exemplary embodiment, each health services provider 106A through 106N may receive a prepaid card, and payments made by an insurance company to their prepaid card can be coordinated through prepaid cardholder account management 202. In another exemplary embodiment, prepaid cardholder account management 202 can have electronic accounts for insurance companies 104A through 104N, and can coordinate payments to health services providers 106A through 106N, such as by issuing each of health services providers 106A through 106N a different prepaid card for insurance companies 104A through 104N or in other suitable manners.

Authorization and settlement system 204 allows a health services provider 106A through 106N to use a prepaid card to obtain electronic authorization and settlement of amounts due to the health services provider by the insurance company. In one exemplary embodiment, an insurance company can provide an EDI data file that includes an authorization request for authorization of a payment to a health services provider, or can submit the authorization request in other suitable manners. Authorization and settlement system 204 can extract the authorization request from the EDI data file and can verify that funds are available in the insurance company's account, and can generate a suitable notification such as an authorization number that is inserted into an EDI 835 file if funds are available and transferred from the insurance company's account to a health service provider's account, such as on a daily basis, using an automated clearinghouse process in conjunction with an originating depository financial institution. Authorization and settlement system 204 can generate a notification to the insurance company if funds are unavailable. Health services provider 106A through 106N can receive an electronic notification that a payment has been authorized for one or more claims made for services provided to patients. Authorization and settlement system 204 can transmit the electronic notification, and can then receive electronically-read card-swipe data and other suitable data from the health services provider 106a credit card terminal, such as by using an existing prepaid card over credit card network 112 or in other suitable manners, so as to perform settlement of the transaction. Authorization and settlement system 204 can then transmit an electronic notification of settlement to the insurance company and can perform other suitable processes.

Card management and fulfillment system 206 allows health services providers 106A through 106N to receive new and replacement prepaid cards for electronic payments from insurance companies 104A through 104N. In one exemplary embodiment, card management and fulfillment system 206 can electronically track cards that are issued to health services providers and card processing terminals that are used by health services providers, such as to prevent a card from being used at an unauthorized terminal, and can provide other suitable electronic card management and fulfillment processes.

Reporting system 208 allows an insurance company 104A through 104N or health services providers 106A through 106N to receive electronic reports, such as report files containing data for payments made through an electronic prepaid card system on claims that have been submitted, electronic database correlations to explanations of benefits, or other suitable data.

In operation, system 200 allows a prepaid card to be provided to health services providers, such as using credit card network 112 or in other suitable manners, so that insurance companies 104A through 104N can make electronic payments to health services providers 106A through 106N using a prepaid card instead of a check, in conjunction with an electronic payment network. System 200 thus facilitates payment of health services providers by insurance companies, and electronically coordinates such payments with access to online data regarding such payments to allow the health services providers to readily determine discrepancies in payment amounts or to resolve other problems.

FIG. 3 is a diagram of a system 300 for explanation of benefit and payment processing in accordance with an exemplary embodiment of the present invention. System 300 includes EOB and payment system 118 and EOB batch processing system 302, payment consolidation system 304, HSP and patient data system 306, and EOB to EDI translation system 308, each of which can be implemented in hardware or a suitable combination of hardware and software, and which can be one or more software systems operating on a general purpose processing or server platform.

EOB batch processing system 302 receives electronic data in batch format from insurance companies that is used to generate explanation of benefit statements for patients and health services providers. In one exemplary embodiment, the electronic data can be in a proprietary format that is used by insurance companies with existing service providers that process the data to send out paper statements and checks. In another exemplary embodiment, a standardized data format such as based on the EDI data definitions or other suitable standards can be used. EOB batch processing system 302 can electronically consolidate data for health services providers, patients and other suitable parties.

Payment consolidation system 304 can generate electronic payment data from insurance companies 104A through 104N and can electronically consolidate the payment for each of a plurality of health services providers 106A through 106N. In another exemplary embodiment, payment consolidation system 304 can electronically consolidate all payments from each insurance company 104A through 104N into a single payment, where the payment data is associated with data that can be accessed by a health services provider regarding the payment for each separate service payment.

HSP and patient data system 306 allows a health services provider and patient to electronically access data pertaining to each entity, such as using a web browser graphic user interface over a communications medium. In one exemplary embodiment, HSP and patient data system 306 can allow health services providers to electronically access explanation of benefit data for patients, can allow a patient to electronically access their individual explanation of benefits data, or can perform other suitable functions. For example, HSP and patient data system 306 can send a PDF data file of an explanation of benefits statement to a patient, health services providers can define data fields for customized electronic data reports for a plurality of patients, or other suitable functions can be provided.

EOB to EDI translation system 308 allows electronic explanations of benefits data to be translated to electronic data interchange data formats in accordance with existing electronic data interchange format standards, such as using field definitions that are identified in the electronic data interchange standards. EOB to EDI translation system 308 thus allows individual insurance company proprietary data formats for explanations of benefits to be translated through a centralized switch, and also allows additional data fields to be electronically converted from an EOB format to an EDI format where allowed, such as comment fields or other suitable fields.

In operation, system 300 allows EOB and payment processing to be performed by centralized insurance services platform, so as to facilitate payment of health services providers from a plurality of insurance companies using a prepaid card system, a closed loop system, or in other suitable manners.

FIG. 4 is a diagram of a system 400 for electronically migrating services from a prepaid card system to a closed loop system in accordance with an exemplary embodiment of the present invention. System 400 includes migrated services system 124 and account migration system 402, bank account management system 404, closed loop authorization and settlement 406 and transaction history system 408, each of which can be implemented in hardware or a suitable combination of hardware and software, and which can be one or more software systems operating on general purpose processing server platform.

Account migration system 402 allows an existing prepaid card system electronic account for a health services provider to be migrated to a closed loop electronic account. In one exemplary embodiment, when a health services provider decides to migrate from a prepaid card electronic account to a closed loop electronic account, it may be necessary to deactivate the health services provider's electronic prepaid card account, and to establish automated clearing house or other suitable bank electronic account information for the health services provider to allow the health services provider to be paid electronically by the insurance services platform. For example, inter-bank or intra-bank electronic fund transfers using the ACH can be accomplished if the account data for the insurance company and health services provider bank accounts is known, and if suitable authorization has received. In this exemplary embodiment, the insurance company and health services provider can enter into a contractual agreement with the insurance services platform provider that defines the rights and responsibilities of the parties in regards to authorization and settlement of electronic transactions for health care services.

Bank account management system 404 allows bank electronic accounts for insurance companies 104A through 104N and health services providers 106A through 106N to be centrally managed. In one exemplary embodiment, bank account management system 404 allows prepaid spending electronic accounts or flexible spending electronic accounts to be coordinated with payment of co-pays by patients, electronic reimbursement of co-pays to patients, or other suitable electronic data processing for patients. Bank account management system 404 allows bank electronic accounts associated with insurance companies, health services providers, patients and other suitable entities to be identified and managed, such as to ensure that only authorized payments are made to bank electronic accounts and that authorization is received for transfer of payments from bank electronic accounts.

Closed loop authorization and settlement 406 provides predetermined electronic authorization and settlement processes for claims made by health services providers to insurance companies. In one exemplary embodiment, a health services provider 106A through 106N can contact an insurance company 104A through 104N through insurance services platform 102, or can use existing processes to request authorization of a charge by a patient. Closed loop authorization and settlement 406 can either receive such authorization data electronically from the insurance company or a third party, or can otherwise process the authorization. Likewise, when a health services provider 106A through 106N requests payment for services that have been provided to a patient, insurance companies 104A through 104N can electronically coordinate with the health services provider through closed loop authorization and settlement 406, either by allowing closed loop authorization and settlement 406 to provide all electronic closed loop services, or in combination with data received from third-party sources, such as insurance companies 104A through 104N.

Transaction history system 408 allows transaction history data to be electronically stored for closed loop transactions. In one exemplary embodiment, transaction history system 408 can take the place of electronic transaction data storage by credit card network 112 or other suitable transaction data, can provide consolidated electronic transaction data storage for insurance companies 104A through 104N and health services providers 106A through 106N, or can provide other suitable functions. In this exemplary embodiment, transaction history system 408 eliminates redundancies in electronic data storage systems from insurance companies 104A through 104N and health services providers 106A through 106N.

In operation, system 400 allows health services providers to migrate from an electronic prepaid card system format to an electronic closed loop format, so as to reduce the amount of transaction processing that is required and the associated fees for payments made to health services providers by insurance companies. For example, it is not uncommon for credit card networks 112 to charge fees of several percent of the amount of the transaction for processing of a prepaid card. Likewise, funds that are electronically stored in a prepaid card account may be subject to default or may otherwise be lost or forfeited if a prepaid card is lost or not processed in a timely manner. System 400 provides for a secure electronic environment and cost-effective processing of payments to health services providers by insurance companies.

FIG. 5 is a flowchart of an algorithm 500 for configuring payment processing in accordance with an exemplary embodiment of the present invention. Algorithm 500 can be implemented in software operating on a general purpose processing or server platform so as to convert the general purpose platform into a special purpose machine, or in other suitable embodiments.

Algorithm 500 begins at 502 where an insurance electronic account is configured for prepaid and closed loop account processing. In one exemplary embodiment, an electronic account associated with an insurance company may have a plurality of insurance health services providers that can be paid by an insurance services platform for a plurality of patients, and the payment can be made through a prepaid card, a closed loop system, or in other suitable manners. At 502, the electronic account for the insurance company is configured for handling of such payments, such as to allow the insurance company to electronically submit explanation of benefits data and payment authorization data, and to allow the insurance services platform to make electronic payments to health services providers as authorized by the insurance companies. In one exemplary embodiment, EOB data files, EDI data files or other suitable data files that contain data fields that identify the plurality of health services providers, patients or other suitable parties can be received from insurance companies, and accounts for the health services providers, patients and other suitable parties can be automatically created using these data fields, such as such as name fields, account number fields, address fields, social security number fields, telephone number fields and other suitable fields.

The algorithm then proceeds to 504 where health services providers, patients or other suitable parties are contacted. In one exemplary embodiment, the health services providers, patients or other parties can be contacted electronically, through the mail, directly by insurance companies, on behalf of insurance companies, or in other suitable manners, such as to provide them with account identification and access information, to prompt them to opt in or to opt out of account access, or for other suitable purposes. The algorithm then proceeds to 506.

At 506 it is determined whether the health services provider has opted to receive a prepaid card for electronic payment of reimbursement of payments for claims made by patients or on behalf of patients, such as by electronically prompting a health services provider to make a selection. If it is determined that a prepaid card has been selected by the health services provider, the method proceeds to 508 where the health services provider's electronic account is configured to receive payments through a prepaid card. In one exemplary embodiment, the health services provider can be issued a prepaid card for use with an individual insurance company, for use with any insurance company associated with the insurance services platform, or in other suitable manners. The method then proceeds to 516. Likewise, if it is determined that no prepaid option has been selected 506, the method proceeds to 510.

At 510, is determined whether a closed loop selection has been made, such as by electronically prompting a user to enter data that indicates whether the user has accepted or declined a closed loop option. If it is determined that closed loop processing has not been selected, the algorithm proceeds to 512 where the health services provider is tagged for follow-up, such as by electronically storing data in a calendar tool for alerting a user to contact the health services provider. Otherwise, the method proceeds to 514 where the electronic account for the health services provider is configured to receive closed loop processing. In one exemplary embodiment, the closed loop processing can include configuring ACH automated clearinghouse data for a health services provider's electronic account, and can also include receiving electronic confirmation that a health services provider has agreed to be bound by contractual terms for handling disputes regarding payments or other suitable data.

At 516, it is determined whether a health services provider has made a decision to migrate from a prepaid electronic account to a closed loop electronic account. If it is determined that no such decision has been made, such as if a health services provider responds to a query invitation to migrate with a “no” data entry, the algorithm proceeds to 518 where the health services provider's electronic account is tagged for follow-up in the future, such as by email, personal call, or in other suitable manners. Likewise, if it is determined at 516 that a health services provider does want to migrate their electronic account from a prepaid electronic account to a closed loop electronic account, the algorithm returns to 510.

In operation, algorithm 500 allows an insurance services platform to offer electronic prepaid and closed loop claims and payment processing to health services providers for or on behalf of insurance companies. Algorithm 500 allows the insurance services platform to act as a switch for authorization of claims and services, and to use an existing credit card network 112 or closed loop processing to accomplish electronic payment of health services providers by insurance companies.

FIG. 6 is a flowchart of an algorithm 600 for electronically migrating a health services provider from a prepaid card to a closed loop electronic account and for electronically processing transactions in accordance with an exemplary embodiment of the present invention. Algorithm 600 can be implemented in software operating on a general purpose processing or server platform so as to convert the general purpose platform into a special purpose machine, or in other suitable embodiments.

Algorithm 600 begins at 602 where a prepaid electronic account is closed. In one exemplary embodiment, a card associated with a prepaid electronic account can be deactivated, the master electronic account for the prepaid cards can be updated to reflect that the card has been closed, or other suitable processes can be performed. The algorithm then proceeds to 604.

At 604, automated clearinghouse data is configured for each health services provider bank electronic account. In one exemplary embodiment, when a health services provider migrates from a prepaid electronic account to a closed loop electronic account, the health services provider can provide a bank electronic account routing number and other suitable data to allow payment to be electronically made to the health services provider. Once the automated clearinghouse data for the health services provider bank electronic account is configured, the algorithm proceeds to 606.

At 606, transaction data is received. In one exemplary embodiment, the transaction data can include an electronic request from a health services provider for authorization to provide medical services to a patient, or other suitable data. If it is determined that the transaction is authorized, the algorithm proceeds to 610 where the health services provider is notified of approval. Otherwise, the algorithm proceeds to 614 where the health services provider is electronically notified of the decline. The algorithm can then return to 606, where the health services provider can provide new transaction data, such as to reformat data in required format, to provide new transaction request data, or for suitable functions.

After a health services provider receives approval at 610, the algorithm proceeds to 612 where service confirmation is electronically received, such as by transmitting data to an insurance company or in other suitable manners. Service confirmation data can include information regarding the services that were performed on the patient, identification data for the patient such as electronic biometric data, and other suitable data. The algorithm then proceeds to 616.

At 616, it is electronically determined whether the transaction has settled. In one exemplary embodiment, an insurance company can review the service confirmation data and other suitable data and can determine whether or not the payment should be made for the transaction. If it is determined that the transaction should not be settled, the algorithm proceeds to 618 and the health services provider is electronically notified of the decline. For example, if the electronic biometric data does not match stored electronic biometric data for a patient, the health services provider can be contacted to alert them of potential fraud. The health services provider can then contact the insurance company or otherwise resubmit data to request service confirmation and transaction settlement. Likewise, if it is determined at 616 that the transaction has settled, such as by electronically receiving a confirmation or settlement authorization from an insurance company, the algorithm proceeds to 620.

At 620, funds are transferred to the health services provider's bank electronic account from the insurance company's bank electronic account. In one exemplary embodiment, the transfer of funds can take place once a day in batch form, can be subject to automated clearinghouse rules, can be subject to other contractual provisions agreed to by the parties, or can use other suitable processes. The algorithm then proceeds to 622.

At 622, it is determined whether a transaction has been electronically disputed. In one exemplary embodiment, a health services provider can dispute an amount of payment, an insurance company can dispute whether services have been provided as represented by the health services provider, or other suitable data can be electronically provided to initiate a dispute. If a dispute has not been initiated at 622 the method returns to 606. Otherwise, the algorithm proceeds to 624 whether the parties are notified of the dispute, the status of the dispute and the reason for the dispute. The algorithm then proceeds to 626 where a closed loop dispute resolution process is implemented. In one exemplary embodiment, the parties can be required to agree to closed loop dispute resolution processes to facilitate timely and inexpensive resolution of any disputes regarding whether services were provided, whether payment was made, or other disputes. For example, a patient may contact an insurance company and notify the insurance company that the patient did not receive the services that were provided, such as where the patient's identity has been stolen. In this event, the patient may dispute a charge and dispute resolution processes at 626 may determine that the health services provider did not obtain positive identification of the data or other suitable data.

In operation, algorithm 600 allows a prepaid electronic account to be migrated to a closed loop electronic account and provides for closed loop transaction processing of healthcare claims or health services provided to patients and claims made to insurance companies. Algorithm 600 thus facilities the rapid payment and processing authorization of claims, and can help to prevent fraudulent claim activity.

FIG. 7 is a flow chart of an algorithm 700 for pre-paid and closed loop processing in accordance with an exemplary embodiment of the present invention. Algorithm 700 allows pre-paid and closed loop processing to be combined for processing of health services payments by using common functionality for reporting and payment processing where possible, and separate functionality where needed. Algorithm 700 can be implemented in software operating on a general purpose processing or server platform so as to convert the general purpose platform into a special purpose machine, or in other suitable embodiments.

Algorithm 700 begins at 702, where an electronic transaction is received. In one exemplary embodiment, the transaction can be received from an insurance company, such as where the electronic transaction data includes explanation of benefits data, payment data and other suitable data. In another exemplary embodiment, the electronic transaction can include data from a health services provider and an insurance company, such as a request for authorization to provide services, approval from the insurance company, a request for settlement of services from the health services provider, an explanation of benefits data, payment data and other suitable data from the insurance company, or other suitable data. The algorithm then proceeds to 704.

At 704, it is determined whether pre-paid or closed loop processing is required, such as by electronically determining from the data record that has been received whether the available data fields define a pre-paid or closed loop transaction, by determining whether a transaction type flag defines the transaction as a pre-paid or closed loop transaction, or in other suitable manners. In one exemplary embodiment, the transaction data can be received at a switch that is configured to process pre-paid or closed loop transaction data. If it is determined that pre-paid transaction processing is required, the algorithm proceeds to 706, otherwise the algorithm proceeds to 710.

At 706, the pre-paid transaction data is processed, such as by determining an associated pre-paid account for the health services provider, by configuring a new pre-paid account for a health services provider that does not have an existing pre-paid account, or in other suitable manners. The algorithm then proceeds to 708, where a payment amount is added to the pre-paid card account for the health services provider. In one exemplary embodiment, the health services provider can have a separate pre-paid card account for each different insurance provider, and the payment amount can be added to an available balance on that pre-paid card, such as by transferring funds from a general account for that insurance company to the pre-paid card account for the health services provider. In another exemplary embodiment, the health services provider can have a single pre-paid card account for use with each different insurance provider, and the payment amount can be added to an available balance on that pre-paid card, such as by transferring funds from a separate account for that insurance company to the pre-paid card account for the health services provider. Other suitable processes can also or alternatively be used. The algorithm then proceeds to 714.

At 710, the transaction is processed as a closed loop transaction, such as where the insurance company and the health services provider have both given ACH account access to an insurance services provider, so as to allow the insurance services provider to schedule payments using the ACH network or in other suitable manners. The algorithm then proceeds to 712, where a payment transfer is scheduled. In one exemplary embodiment, the payment transfers can be scheduled on a periodic basis, when an amount of payments reaches a predetermined amount, when a number of transactions reaches a predetermined amount, or in other suitable manners. The algorithm then proceeds to 714.

At 714, payment is electronically reported to the health services provider. In one exemplary embodiment, the report can be made to alert the health services provider that funds have been added to a pre-paid card, that an ACH transfer has been made, or to provide other suitable data. The algorithm then proceeds to 716, where explanation of benefits data is reported to a patient. In one exemplary embodiment, the patient can receive an electronic or paper report that identifies how much the health services provider was paid for each service, services that the health services provider was not paid for, whether a health savings account was used to pay for a co-pay or deductible, or other suitable data. The algorithm then proceeds to 718.

At 718, it is determined whether a dispute has been reported. In one exemplary embodiment, the insurance provider or the patient can electronically dispute a payment to a health services provider, such as when a patient reports that they did not receive the reported services in an explanation of benefits statement. Other suitable data can also be used to initiate a dispute. If it is determined that a dispute has not been reported, the algorithm returns to 702. Otherwise, the algorithm proceeds to 720.

At 720, it is determined whether the disputed transaction was a pre-paid or a closed loop transaction. If it is determined that the disputed transaction was a pre-paid transaction, the algorithm proceeds to 722 where the dispute is processed in accordance with pre-paid card network rules. In one exemplary embodiment, a pre-paid card network such as a VISA or MasterCard pre-paid card may define the conditions under which disputes should be handled, such as the time limit for reporting a dispute, each party's responsibility when a dispute is reported, or other suitable rules. The algorithm then returns to 702.

If it is determined at 720 that the disputed transaction was a closed loop transaction, the algorithm proceeds to 724 where the dispute is processed in accordance with closed loop transaction rules. In one exemplary embodiment, the insurance services provider may define the conditions under which disputes should be handled, such as the time limit for reporting a dispute, each party's responsibility when a dispute is reported, or other suitable rules, and the parties can be required to agree to such rules contractually as a condition to allowing the parties to receive closed loop processing of transactions, such as in exchange for lower transaction processing fees. The algorithm then returns to 702.

In operation, algorithm 700 allows transactions to be processed in a network where the transactions are either pre-paid or closed loop. Algorithm 700 supports either type of transaction processing, so as to allow parties to easily migrate from pre-paid processing to closed loop processing, and for other suitable purposes.

Those skilled in the art to which this application relates will appreciate that other and further additions, deletions, substitutions and modifications may be made to the described embodiments.

Claims

1. A method for processing transactions comprising:

receiving transaction data containing a plurality of data fields;

automatically generating one or more health service provider accounts and one or more patient accounts using the plurality of data fields of the transaction data.

electronically determining whether to process the transaction data as a pre-paid transaction or a closed loop transaction using data processing equipment;

processing the transaction using pre-paid network rules if it is determined that the transaction data defines the pre-paid transaction;

processing the transaction using closed loop transaction rules if it is determined that the transaction data defines the closed loop transaction;

scheduling payment to one of the health service provider accounts as a function of whether the transaction data was processed as the pre-paid transaction or the closed transaction; and

transmitting explanation of benefits data to one of the patient accounts after the payment is scheduled.

2. The method of claim 1 wherein processing the transaction using the pre-paid network rules if it is determined that the transaction data defines the pre-paid transaction further comprises allocating a payment to a pre-paid card of a health services provider that is associated with a single insurance company.

3. The method of claim 2 further comprising notifying the health services provider that the payment has been allocated to the pre-paid card.

4. The method of claim 1 wherein processing the transaction using the pre-paid network rules if it is determined that the transaction data defines the pre-paid transaction further comprises allocating a payment to a pre-paid card of a health services provider that is accessible by any of a plurality of insurance companies.

5. The method of claim 4 further comprising notifying the health services provider that the payment has been allocated to the pre-paid card after a predetermined number of additional payments have been allocated.

6. The method of claim 1 further comprising:

receiving a request to migrate a health service provider account from a pre-paid account to a closed loop account;

closing the pre-paid account; and

opening the closed loop account.

7. The method of claim 6 wherein closing the pre-paid account comprises deactivating a pre-paid card account associated with a single insurance company.

8. The method of claim 6 wherein closing the pre-paid account comprises deactivating a pre-paid card account associated with a plurality of insurance companies.

9. The method of claim 6 wherein opening the closed loop account comprises receiving automated clearinghouse (ACH) bank account data for the health services provider.

10. A system for processing transactions comprising:

an insurance gateway for receiving electronic transaction data using an electronic data processing system;

a pre-paid card system for processing the transaction data if a health services provider associated with the transaction data has a pre-paid card account; and

a closed loop transaction system for processing the transaction data if the health services provider associated with the transaction data has a closed loop account.

11. The system of claim 10 further comprising a migrated services system for migrating the health service provider from the pre-paid account to the closed-loop account.

12. The system of claim 10 wherein the closed loop transaction system comprises a closed loop authorization system for processing an authorization request from the health services provider.

13. The system of claim 10 wherein the closed loop transaction system comprises a closed loop settlement system for processing a settlement request from the health services provider.

14. The system of claim 11 wherein the migrated services system comprises a bank account management system for configuring a health services provider bank account to receive payments using an automated clearinghouse (ACH) network.

15. The system of claim 10 further comprising an authorization and settlement system for performing pre-paid card authorization and settlement in response to the transaction data.

16. The system of claim 10 further comprising a pre-paid cardholder account management system for configuring the pre-paid card account for the health services provider to receive payments from a single insurance provider.

17. The system of claim 10 further comprising a pre-paid cardholder account management system for configuring the pre-paid card account for the health services provider to receive payments from a plurality of insurance providers.

18. The system of claim 11 wherein the migrated services system comprises a transaction history system for storing closed loop transaction data for each of a plurality of closed loop transactions associated with each of a plurality of health services providers.

19. The system of claim 11 wherein the migrated services system comprises an account migration system for closing the pre-paid card account of the health services provider and opening a closed loop processing account for the health services provider.

20. A system for processing transactions comprising:

a plurality of insurance company electronic data processing systems;

a plurality of health services provider systems;

an insurance services platform coupled to the plurality of insurance company electronic data processing systems and the plurality of health services provider systems, the insurance services platform further comprising: a pre-paid card system for processing pre-paid card transactions, the pre-paid card system further comprising: a pre-paid cardholder account management system for managing a plurality of pre-paid cardholder accounts associated with the plurality of health service provider systems; an authorization and settlement system for authorizing and settling pre-paid card transactions associated with the plurality of pre-paid cardholder accounts; a card management and fulfillment system for issuing and managing a plurality of pre-paid cards associated with the plurality of pre-paid cardholder accounts; and a reporting system for generating activity report data associated with transactions for selected pre-paid cardholder accounts; an explanation of benefits (EOB) and payment system for processing explanation of benefits data and payment data, the EOB and payment system further comprising: an EOB batch processing system for receiving batch transaction data from the plurality of insurance company electronic data processing systems and processing the batch transaction data as a function of health services provider data and patient data for each of a plurality of records in the batch transaction data; a payment consolidation system for receiving the processed batch transaction data and consolidating payment data for the plurality of health services providers; a health services provider and patient data system for receiving the processed batch transaction data and providing predetermined specific data associated with the health services providers to the health services providers and providing predetermined specific data associated with a plurality of patients to the patients; and an EOB to electronic data interchange (EDI) translation system translating EOB data in a proprietary format to a standardized EDI data format; a migrated services system for migrating the health services provider systems from pre-paid card accounts to closed loop system accounts, the migrated services system further comprising: an account migration system for closing the pre-paid card account of the health services provider and opening a closed loop processing account for the health services provider; a bank account management system for receiving automated clearinghouse (ACH) data for insurance company bank accounts and health services provider bank accounts and controlling access to the ACH data; a closed loop authorization and settlement system for receiving closed loop transaction authorization request data and closed loop transaction settlement request data and generating closed loop transaction authorization approval data and closed loop transaction settlement approval data; and a transaction history system for storing closed loop transaction data for each of a plurality of closed loop transactions associated with each of a plurality of health services providers; an insurance gateway for receiving electronic transaction data from a plurality of insurance companies using an electronic data processing system; a health services provider gateway for providing electronic transaction data and payment data to a plurality of health services providers; and a patient gateway for providing EOB data to a plurality of patients and to support messaging between the health services providers and the patients;

a plurality of patient interfaces coupled to the insurance services platform for allowing patients to access predetermined EOB data associated with each patient and for allowing messaging between the health services providers and the patients;

a plurality of banks coupled to the insurance services platform, wherein the insurance services platform can access accounts at the plurality of banks using the ACH data and an ACH network; and

a credit card network coupled to the insurance services platform, wherein the insurance services platform can access credit card accounts over the credit card network to support processing of pre-paid card transactions.