Healthcare Payment Network

Abstract

A system is disclosed which allows gives the Provider the ability to safely and securely transfer funds via a counterparty enabled “pull” from the Payer's account to the Provider's account for payments made by ACH or VCN. The system is based upon a token embedded in the remittance to claim (pull) the funds and sent to the provider and a trusted party used for transferring funds from the payer's account to the provider's account. The provider is thus able to “pull” funds from the provider by using the token embedded in the remittance advice. The token is provided to a trusted party who transfers the funds relating to the token. The use of the token and the change of process flow requiring the provider to pull the funds instead of having the funds pushed into their account eliminates any mismatch between the claim and the payment for the claim.

Claims

1. A system for reconciling remittances for health care services with an originating claim, the system comprising: a healthcare provider system for generating healthcare electronic claim forms for healthcare services and items provided to patients, said electronic claim form configured to be transmitted to a payer over an electronic network to be received by a payer; a healthcare payer system for receiving said electronic claim forms from said payer, said healthcare payer system configured to adjudicate said claim forms and issue remittance advice and payment to said providers, wherein said healthcare payer system is configured to generate tokens and embed said tokens into said remittance advice and send said remittance advice to said healthcare provider and embed said tokens into electronic payment instructions to a trusted party, wherein said trusted party is configured to transfer funds to said healthcare provider's account upon request of said healthcare provider matching the token provided by said healthcare provider.

2. The system as recited in claim 1, wherein said electronic payment advice includes a virtual card number (VCN) funds transfer.

3. The system as recited in claim 1, wherein said electronic payment advice includes a payment instruction for an automated clearing house (ACH) funds transfer.

4. The system as recited in claim 1, wherein said token is generated by a third party.

5. The system as recited in claim 1, wherein said remittance advice is generated by a third party.

6. The system as recited in claim 1, wherein said third party generates said token and embeds it into said remittance advice.

7. The system as recited in claim 1, wherein the trusted party is the payer's bank.

Description

DESCRIPTION OF THE DRAWING

[0107] These and other advantages of the present system will be readily understood with reference to the following specification and attached drawing wherein:

[0108] FIG. 1 is an exemplary flowchart of the process from initial healthcare service through receipt and reconciliation of payment.

[0109] FIG. 2 illustrates an exemplary method of embedding a token within an 835 remittance to be paid.

[0110] FIG. 3 illustrates an exemplary method of transmitting the 835 with Embedded Token.

[0111] FIG. 4 is an exemplary diagram that illustrates How Merchants Take Control of Funding with Trusted Counter Parties.

[0112] FIG. 5 is an exemplary diagram that illustrates how counter parties are used in the System to authorize and settle payment.

[0113] FIGS. 6A-6G illustrate an exemplary diagram of an electronic 835 EDI message illustrating data fields, data elements, and data requirements with a sample trace number embedded in field TRN segment in accordance with the invention.

[0114] FIGS. 6H-6M illustrate an exemplary diagram of an 837 EDI message illustrating data fields, data elements and data requirements.

DETAILED DESCRIPTION

[0115] The present system relates to a healthcare payment network for facilitating reconciliation of a remittance with an originating claim. The core of the idea is to modify the systems and the processes to generate a unique (reusable or recyclable) token for each payment from a given Payer. In one implementation, the token is a 16-digit numeric VCN or 15 digit numeric ACH Trace Number which would be generated using current solutions which operate with card payment networks (e.g. Visa, MasterCard, American Express) or ACH networks. The VCN or ACH Trace Number will serve as a token to match the 835 to the payment for reference and reconciliation purposes and it will also be used to authorize payment using the respective payment network. Automated Clearing House (ACH) is an electronic network for financial transactions that processes large volumes of credit and debit transactions in batches.

[0116] In the system in accordance with the invention, a card payment or ACH network, gives the Provider the ability to safely and securely transfer funds via a counterparty enabled “pull” from the Payer's account to the Provider's account. Furthermore, because they use a token which has been embedded in the remittance to claim (pull) the funds, there is never a mismatch between the token the Payer has embedded when the remittance is generated and the funds that are being deposited. This squarely addresses the status quo limitation that push ACH payments create when both the Remittance and Funds transfer are unilaterally initiated by the payer, and the linking trace number information is disjointed as described in FIG. 1. In the current system, the Provider is unable to link and reconcile both the 835 and ACH payment.

[0117] The ability to generate unique Tokens is a current capability of the major payment networks. Visa, MasterCard and American Express (“the Card Networks”) have created algorithms by which credit and debit card numbers that operate within their networks are generated, and the ACH system has developed algorithms by which member banks generate trace numbers that operate within the ACH framework.

[0118] The Card Networks have enlisted banks, who serve as issuers of debit and credit cards to both individuals and business entities, into their ecosystems. Each bank is assigned an identifier that is typically located within the first 4-6 digits (BIN number) of the card numbers generated. Each remaining digit within the string of the collective VCN is governed by a rule set of how it is assigned. Examples of card issuers include: Chase, Citibank, Wells Fargo, US Bank. One of Chase's BIN numbers with Visa is 4226.

[0119] The ACH network has enlisted participant banks, who serve as originators (ODFI—Originating Depository Financial Institution), and receivers (RDFI—Receiving Depository Financial Institution). Chase, Citibank, Wells Fargo and US Bank are also both ODFI's and RDFI's in the ACH Network. The ACH network has defined a 15-digit numeric algorithm to create trace numbers, and have dictated the rules by which a trace number is applied to an ACH transaction and reflected in banking registers.

[0120] Banks typically leverage the service of Issuing Card Processors (e.g. TSYS, First Data) or card management platform Providers (e.g. AOC), to both generate and maintain the inventory of cards and their associated numbers (tokens). In the ACH system, Banks either service and process their own transactions or enlist the services of 3.sup.rd Party ACH Transmitters. In either case, readily available solutions exist like those offered by SunGard, which creates ACH transmission files known as NACHA files (National Automated Clearinghouse Association), or payment validation files known as Positive pay files. ACH transactions usually assign 15-digit numeric trace numbers to each fund transmission.

[0121] Banks also leverage Issuing Card Processors to connect to the Card Networks, while assigning an available balance which each card can be authorized against (known as credit line, fund availability or Open to Buy). The balance is either a reflection of the funds on deposit with the bank (debit cards), or the credit line assigned to the card holder by the banks underwriting unit. In the ACH system, banks leverage ACH Operators (central clearing facilities), which are usually either the Federal Reserve or The Clearing House). The ACH system works off a good fund model which means that the money to be transmitted is on deposit with or is readily available to the ODFI before a transaction is initiated.

[0122] As this infrastructure is in place and operational on a major scale, it would be used. This capability is not being applied effectively to the healthcare payment system for the objectives described above, as all current manifestations are either manual, or have a flow of funds that is incompatible with effective reconciliation and linkage.

Embed the Unique Token into an Unused Data Field in the 835

[0123] Currently, the electronic 835 (as compared with the physical EOP) does not consistently, reliably or adequately carry meaningful linkage to the electronic payment (virtual card, ACH or wire) directly. It does carry the patient number [and other identifying information such as patient name, date of service, services rendered] which is used when the Provider is reconciling payment and remittance information manually. This is one of the reasons checks, and the current deployment of virtual cards are printed out and attached to the EOP's which are sent physically to the Provider.

[0124] The HIPAA 835 remittance has several payment related segments, which can house the token information (either the 16-digit numeric VCN or 15 digit numeric ACH trace number), or alternatively can be imbedded within reserved payment segments of the standardized 835 remittances (specifically the TRN segments of the 835). See FIG. 6A which illustrates an exemplary 835.

[0125] The only relevance of where the number is placed within the 835, is that of identification by the receiving Provider PMS or HIS, which will need to extract the token for authorization. This placement can either be pre-defined or chosen on a Payer by Payer basis. The specific segment of the 835, where the token is embedded is identified to the various PMS and HIS platform providers (or the healthcare Providers themselves) either via bulletin, public disclosure, header record identifier within the 835 itself, or by a mandate from the 835-governing committee. The only pre-requisite is that the placement and format of the token follow a constant rule set, which can be systemically coded to for extraction and authorization submission. Currently, it is expected that the token will placed in either the TRN, TRN01, TRN02 or TRN03 segments of the 835 layout. An example of a 16 digit VCN token is 4147658963256532 or a 15 digit ACH token trace number is 542387496125634

[0126] In one implementation, the token would either be via VCN or ACH Trace Number. The Payer may either obtain a license from a bank to self-generate tokens within a prescribed range and in compliance with the Bank's card issuing or ACH trace number algorithms; or systemically pull card numbers [tokens] from the Bank's card management platform (e.g. AOC) or ACH Trace Numbers from 3.sup.rd Party ACH solution providers (e.g. SunGard); or obtain an inventory of virtual card numbers [tokens] from the Bank which is refreshed from time to time. The VCN or ACH token would be transcribed and embedded in one of the 835 TRN segments.

[0127] In one implementation, one of a number of Remittance and Payment Solution Providers (“RPSP”s e.g. Echo, VPay, RedCard) may oversee the obtaining, issuance and embedding of Tokens into the 835 on an outsourced basis (on behalf of industry Payers). For this, the RPSP would either obtain a license from the Bank to self-generate tokens within a prescribed range and in compliance with The Bank's algorithms; systemically pull tokens from the Bank's token management platform (e.g. AOC) and/or issuing processor (e.g. TSYS); or obtain an inventory of tokens for this effort from the Bank, refreshing this inventory from time to time.

[0128] Many Payer systems assign a payment reference ID upon claim adjudication (e.g. a check number 1234) and so it may be necessary to maintain a cross reference database of check numbers to newly assigned Tokens to ensure proper and effective reconciliation within the Payer's accounting processes.

Modify the Payer's Claims & Payment System(s) to Carry the Embedded Token

[0129] In one implementation, each Payer may modify its claims system to embed the Token together with the other data elements located in the 835-electronic remittance. This is not a difficult task as, and, if requested, the systems platform company can perform this relatively minor modification on behalf of its clients.

[0130] Alternatively, the Payer can follow their current processes as they do today, and generate the 835-remittance advice. They can forward the 835 on their own or at the direction of the receiving healthcare Provider to an RPSP who will insert the VCN or ACH token into the appropriate TRN segment of the 835. If convenient and/or required by the Payer, the RPSP can also maintain a cross reference database of Payer Payment ID's to Tokens generated.

[0131] Another benefit of this process would be to get the entire payer community on a common disbursement structure that eliminates the customized nature of proprietary banking relationships that creates the disjointed structure of many to many relationships.

Provision an “Open to Buy”

[0132] For VCNs the Payer or their RPSP transmits an available amount associated with each token id to the Issuer (e.g. Chase) and/or their designated Issuer Processor (e.g. TSYS). For ACH transactions, the Payer or their RPSP transmits an available amount associated with each token id to their bank or ACH payment services provider. The available amount is equal to the amount to be paid per the corresponding 835 remittance, and usually reflected in the BPR02 segment of the 835. Within the Issuer's system, this is known as an Open to Buy, and will serve as the authorization amount limit when the VCN is entered for authorization by the Provider's system. For an ACH, this is known as the Amount, and typically located within the 30.sup.th to 39.sup.th field positions of the NACHA file. If a positive pay file is used, the amount will be placed in any field mutually agreed to between the two parties.

[0133] FIG. 2 shows the process of embedding a token within an 835 remittance to be paid and the provisioning of an Open to Buy [0134] a. Status Quo: Expanding on box (f) of FIG. 1, the Payers system adjudicates the claim submitted by the Provider as they do today [0135] i. The payer's system creates an 835-remittance file [0136] b. Modification of Payer System to Generate Token [0137] i. The payer modifies their adjudication system, such that when an 835 remittance is created, the TRN segment is populated with either a 16 digit VCN token or a 15 digit ACH trace number [0138] ii. For an ACH token, the payer takes the trace number and 835 payment amount and submits it to their bank via electronic file. Two examples of this file are a NACHA file or a Positive Pay file. In this case, the NACHA file is not used to transmit funds from the Payer's bank, however it will be used at a subsequent step to validate that a debiting ACH transaction is valid. A debiting ACH is originated by the customer of the RDFI and pulls funds from the account of the ODFI customer (the Payer). A Positive Pay file can be any utilized electronic readable file, and serves as a payment inventory validation tool. It contains all transaction amounts and associated identifiers (e.g. Trace numbers or tokens) which a buyer considers to be valid, which a bank uses to validate against every transaction which is presented for payment. [0139] iii. For a VCN token, the payer takes the trace number and 835 payment amount and submits it to their bank card issuer or bank card processor via electronic file. [0140] iv. For both the ACH and VCN, the transmission of the token and amount by the Payer creates the “Open to Buy” in the bank system or the bank issuer/processor system. In a subsequent step of the process, these Open to Buy's will be used to validate the legitimacy of the transaction, and initiate the transfer of funds. [0141] c. Using Card Management or 3rd Party ACH Solution Providers [0142] i. The payer modifies their adjudication system, such that when an 835 remittance is being created, a VCN or ACH token is requested from an external solution provider, which will be placed in the TRN segment of the 835. [0143] ii. For a VCN token, the payer system will request a VCN from a card management platform or solution provider such as AOC [0144] iii. For an ACH token, the payer system will request an ACH trace number from a 3rd party ACH solution provider such as SunGard. [0145] iv. When the tokens are provided by either the VCN or ACH provider, it is embedded in the TRN segment of the 835 by the Payer [0146] v. For a VCN token, the payer takes the trace number and 835 payment amount and submits it to their bank card issuer or bank card processor via electronic file. [0147] vi. For both the ACH and VCN, the transmission of the token and amount by the Payer creates the “Open to Buy” in the bank system or the bank issuer/processor system. In a subsequent step of the process, these Open to Buy's will be used to validate the legitimacy of the transaction, and initiate the transfer of funds. [0148] d. Using an RPSP to Generate & Embed Token [0149] i. The payer generates the 835 file as they do today, and forwards it to an RPSP. In some cases, the services of an RPSP are used to create the actual 835 in a HIPAA compliant format. In this case, the file created by the payer adjudication system is similar to an 835, in that it is in electronic form and contains the data elements necessary to create an 835, however it is not compliant with the specific standards of HIPAA (usually a violation of format or content rules makes it non-compliant). [0150] ii. The RPSP modifies their current remittance file system, such that when an 835 remittance is created or received, the TRN segment is populated with either a 16 digit VCN token or a 15 digit ACH trace number [0151] iii. The RPSP may also create a cross reference table of the token embedded in the 835 with the Payers existing payment reference number if it is included in the file they received from the Payer. The purpose of this process is to provide the Payer with the ability to match the token with the payment reference number in their systems for customer service or reconciliation purposes. [0152] iv. For an ACH token, the RPSP takes the trace number and 835 payment amount and submits it to their (or the Payer's) bank via electronic file. An example of this file can be a NACHA file or a Positive Pay file. The NACHA file is not used to transmit funds from the Payer's bank, however it will be used at a subsequent step to validate that a debiting ACH transaction is valid. A debiting ACH is originated by the customer of the RDFI and pulls funds from the account of the ODFI customer (the Payer). [0153] v. For a VCN token, the RPSP takes the trace number and 835 payment amount and submits it to their (or the Payer's) bank card issuer or bank card processor via electronic file. [0154] vi. For both the ACH and VCN, the transmission of the token and amount by the Payer creates the “Open to Buy” in the bank system or the bank issuer/processor system. In a subsequent step of the process, these Open to Buy's will be used to validate the legitimacy of the transaction, and initiate the transfer of funds. [0155] e. Using a Card Management or 3rd Party ACH Solution & an RPSP to Embed Token [0156] i. The payer generates the 835 file as they do today, and forwards it to an RPSP. In some cases, the services of an RPSP are used to create the actual 835 in a HIPAA compliant format. In this case, the file created by the payer adjudication system is similar to an 835, in that it is in electronic form and contains the data elements necessary to create an 835, however it is not compliant with the specific standards of HIPAA (usually a violation of format or content rules makes it non-compliant). [0157] ii. The RPSP modifies their current process, such that when an 835 remittance is received or being created, a VCN or ACH token is requested from an external solution provider, which will be placed in the TRN segment of the 835. [0158] iii. For a VCN token, the RPSP will request a VCN from a card management platform or solution provider such as AOC [0159] iv. For an ACH token, the RPSP will request an ACH trace number from a 3rd party ACH solution provider such as SunGard. [0160] v. When the tokens are provided by either the VCN or ACH provider, it is embedded in the TRN segment of the 835 by the RPSP [0161] vi. The RPSP may also create a cross reference table of the token embedded in the 835 with the Payers existing payment reference number if it is included in the file they received from the Payer. The purpose of this process is provide the Payer with the ability to match the token with the payment reference number in their systems for customer service or reconciliation purposes. [0162] vii. For an ACH token, the RPSP takes the trace number and 835 payment amount and submits it to their (or the Payer's) bank via electronic file. An example of this file can be a NACHA file or a Positive Pay file. The NACHA file is not used to transmit funds from the Payer's bank, however it will be used at a subsequent step to validate that a debiting ACH transaction is valid. A debiting ACH is originated by the customer of the RDFI and pulls funds from the account of the ODFI customer (the Payer). [0163] viii. For a VCN token, the RPSP takes the trace number and 835 payment amount and submits it to their (or the Payer's) bank card issuer or bank card processor via electronic file. [0164] ix. For both the ACH and VCN, the transmission of the token and amount by the Payer creates the “Open to Buy” in the bank system or the bank issuer/processor system. In a subsequent step of the process, these Open to Buy's will be used to validate the legitimacy of the transaction, and initiate the transfer of funds.

[0165] f.

Transmit the 835 with the Embedded Token

[0166] Once a token has been embedded in the 835, and an open to buy or available amount is provisioned, the Payer transmits the 835 to the PMS/HIS directly, or via an intermediary clearinghouse (e.g. Change Healthcare, Relay Health) who maintains direct connections between the myriad of 3.sup.rd party payers and the Nation's medical Providers.

[0167] 835s are standard HIPAA messages, and as such almost all Provider PMS' are configured to electronically receive the remittances, extract the relevant data elements, and post them automatically to the appropriate patient accounts at a line item or claim level. For example, platforms such as Athena Health, eClinicalWorks, and EPIC routinely electronically receive 835 remittances on behalf of their Provider customers and users; parse the data fields of the 835; map the 835 data fields to the appropriate fields within their system's that generally correlate to the Provider's patient account fields; and extract the data to post within the corresponding fields of the patient account.

[0168] In a subsequent step, the system will modify the current 835 posting process performed by the Provider or the Provider's PMS/HIS platform to extract the embedded token, payment amount and other identifying information for submission and authorization via the Card Payment Networks or the ACH payment network. Prior to this, it is important to understand the introduction of counterparties within the system. FIG. 3 shows the transmission of the 835 with the embedded Token. [0169] a. The token embedded 835 is generated as exemplified in FIG. 2 and is ready for transmission directly to the provider via the already established file transfer protocol [0170] i. In one example the Payer transmits the 835 directly to the Provider [0171] ii. In another example, an RPSP on behalf of a Payer transmits the 835 directly to the Provider [0172] iii. In another instance, the embedded 835 is generated by either the Payer or the RPSP, but is transmitted to a healthcare clearinghouse for subsequent transmission to the Provider via the already established file transfer protocol [0173] b. The 835-remittance file is received into the Provider's PMS or HIS technology platform, and the data elements are parsed. There are over 100+ data elements, which map into over 10 data segments. Segments include: [0174] i. Interchange Control Loop segment; [0175] ii. Payee Identification Loop Segment; or [0176] iii. Transaction Set Loop Segment. This is the segment which houses the embedded Token in one example [0177] c. The parsed data is posted to the patient account [0178] i. Provider's typically use Practice Management Systems where the parsed data will be posted [0179] ii. Hospital's typically use Hospital Information Systems where the parsed data will be posted. [0180] d. The token, payment amount and other identifying information is extracted from the posted 835 remittances, and prepared for submission to the counterparty for payment

Utilizing Trusted Counterparties

[0181] Introduce trusted counter parties (e.g. the card payment network, issuers, merchant acquirers, payment services providers, ACH service providers) to enable Providers to initiate the payment, rather than have Payers push funds directly to Provider bank accounts. The uniqueness of this concept is that it allows the Provider to initiate the funds transfer, when they are ready to receive payment, and following a process which specifically links the funds received to the remittance and patient account it belongs to. It also allows a provider to reconcile the patient account based on the received 835, and resolve any issues before funds are accepted and applied to the patient account.

[0182] In a generic sense, a counterparty based payment system allows unrelated or untrusted entities to transfer funds amongst each other while mitigating the risks of fraud, theft, or unauthorized payments. With card payment networks, there are two counterparties; and a centralized payment network that provides the fund settlement and governance for the transactions that take place over their network. One of the two counterparties are the merchant acquirer, who represents the merchant in the card payment system. The merchant acquirer validates that the merchant is a real and bona fide business to any buyer who wants to use a debit or credit card to make a purchase. The merchant acquirer also provides the merchant with the Point of Sale (POS) device or electronic connectivity (via API) to the card payment network. When a merchant takes a card for payment, the details of the card (e.g. card number) are transmitted to the Merchant Acquirer via POS or API connection, along with the amount to be authorized for payment. Acting as the agent of the Merchant, the Merchant Acquirer submits the card details and payment amount over the card payment network (e.g. MasterCard or Visa) for transaction authorization and subsequent fund settlement if approved. Conversely, the second counterparty, the Issuer (or the Issuer Processor) connect to the Payment Network and represent the buyer in the system. The Issuer provides the buyer with a payment card, which is used with Merchants to secure payment for goods and services. The Issuer's system authorizes a card number and amount submitted for payment by the Merchant Acquirer (via the payment network), provided the card number is valid, and the amount requested for authorization is within the limits available to the buyer (either by credit line or actual cash balance). If the Issuer provides an approval message to the Merchant Acquirer via the payment network, then the Issuer has guaranteed payment to the Merchant on behalf of the buyer. Of particular importance, the only entity that has access to the Merchant bank account is the Merchant Acquirer. Similarly, the only entity that has access to the Buyer bank account is the Issuer (or Issuer Processor). As such, the Merchant is able to receive payment without providing their banking details to the buyer, and the buyer is able to make payment without providing their banking details to the merchant. Furthermore, with this counterparty system, the merchant is able to link the payment request in real-time against the specific purchase which derived it. With today's card networks, transaction authorizations and transaction approvals typically take place in under 6 seconds. This process addresses the primary limitations of ACH processes that push payments by buyers to merchants directly into their bank accounts. It eliminates the need to provide the buyer with merchant bank account information, and it eliminates the need for the merchant to sort through all the deposits in their bank account across multiple days to confirm that monies have been pushed from the buyer account to the merchant account.

[0183] A similar counterparty system can exist for ACH transactions. There are two broad types of ACH transactions: a push or credit ACH transaction that is initiated by the buyer in a commercial setting; a pull or debit ACH transaction that is initiated by the merchant in a commercial setting. In today's process, the benefit of pushing an ACH for the buyer is that it protects against unfettered or unauthorized access to their bank accounts. When payments are due they initiate an ACH transfer from their account to the merchant account. The weakness of this model for Merchants is that they don't know the precise time when the funds will be received, they have to search their bank accounts to confirm that the funds were in fact sent, and they need to link each transfer to the purchase which it belongs to, in order to settle the account receivable. Conversely, the benefit of pulling an ACH in today's process for the merchant is that they are certain that the fund transfer was processed, they can initiate the transfer specifically against the account receivable, and they will know the precise timing of funding based on the relationship they have established with their bank. The weakness of the pull model for Buyers is that it provides unfettered access to their bank accounts, and will not inherently link to their account payable which it is settling without significant follow-up reconciliation activities. The limitations of either a Push or Pull ACH can be remedied with the introduction of a trusted counterparty, who can stand in on behalf of the merchants and/or the buyers. In this case, the buyer can supply the trusted counterparty with an ACH trace number (token) and amount which is authorized to be paid to the Merchant. The buyer would also transfer the funds to the Counterparty which will be used to settle the payment, or will provide the counterparty with the ability to debit their account for the necessary funds when the merchant requests payment. The trace number and payment amount can be provided to the counterparty via any file format, including a NACHA file or positive pay file. The buyer would then transmit a remittance to the buyer with the information related to the invoice it would like to pay (the accounts payable invoice), with an embedded ACH trace number (token) and amount it wishes to pay. When the merchant receives the buyer's remittance, it can extract the trace number (token) along with corresponding payment amount and submit it with its own account deposit details to the counterparty for authorization and fund settlement. When the counterparty validates that the trace number is accurate and corresponds to the amount authorized by the buyer, the counterparty transfers the funds which have been advanced to it by the buyer, or transfers the funds directly from the buyers account to the merchant account.

[0184] FIG. 4 describes how counter parties work with card payment networks and ACH transactions [0185] a. Buyer creates remittances with embedded VCN token as described in FIG. 2, and transmits to Merchant via existing transmission mediums (e.g. US mail, file transfer protocol, email). [0186] b. Buyer also sends notification to card issuer (and/or card processor) of the VCN issued, and the associated amount linked to the VCN via standard electronic file (e.g. file transfer protocol, EDI transmission). Notification establishes the Open to Buy as described in FIG. 2. [0187] c. Merchant receives the remittance, and extracts the VCN, authorization amount (may include other identifying information). [0188] d. VCN, amount (and other information) is submitted to merchant acquirer via point of sale terminal or API or other standard method for authorization. [0189] e. Merchant Acquirer submits VCN and Amount to Issuer (and/or Issuer Processor) via the Card Payment Network. [0190] i. Card Payment Network transmits VCN and amount to Issuer (and/or Issuer Processor)—box (b) for authorization. [0191] ii. Issuer (and/or Issuer Processor—box (b)) validates VCN and amount against Open to Buy which was established from Buyer Notification. [0192] iii. Issuer (and/or Issuer Processor) confirms transaction with an approval code that is transmitted back to Card Payment Network [0193] iv. Card payment network transmits approval to merchant acquirer [0194] v. Merchant acquirer notifies merchant of approval via approval code. [0195] f. Issuer moves funds from Buyer's funding account associated with authorization to Issuer's (and/or Issuer Processor's) card payment clearing account which they own [0196] i. Card payment network debits Issuer's clearing account [0197] ii. Card payment network credits Merchant Acquirers clearing account [0198] g. Merchant Acquirer moves funds from clearing account to Merchant's bank account

[0199] ACH Process [0200] a. Buyer creates remittances with embedded ACH Trace Number (token) as described in FIG. 2, and transmits to merchant via existing transmission mediums (e.g. US mail, file transfer protocol, email) [0201] b. Buyer also sends notification to their ACH counterparty (which is typically their bank) which includes the ACH Trace # and associated amount linked to the Trace #. Notification can be provided via NACHA file or Positive Pay file (as examples). [0202] c. Merchant receives the remittance, and extracts the Trace #, authorization amount (may include other identifying information). [0203] d. Trace #, amount (and other information) is submitted to merchant counterparty (usually their bank) via point of sale terminal or API or other standard method for data transmission. Data transmission may be via NACHA file or Positive Pay file. [0204] i. Merchant counterparty submits Trace # and Amount to Buyer's counterparty for validation and approval [0205] ii. Approval is provided by Buyer's counterparty if Trace # and Amount match information provided by Buyer in NACHA file or Positive Pay file. [0206] e. Upon approval, Buyer's counterparty initiates a credit ACH via the Automated Clearinghouse to move funds from the Buyer's Bank Account to the Merchant's Bank Account; or [0207] f. Upon approval, Merchant's counterparty initiates a debit ACH via the Automated Clearinghouse to move funds from the Buyer's Bank account to the Merchant's Bank account [0208] iii. Utilizing this method, the Buyer's counterparty still acts as a gatekeeper of access to the Buyer's bank account. Only authorized transactions will be allowed to be debited from the bank account. [0209] g. In an alternative instance, boxes (b) and (d) can be replaced with a common counterparty, e.g. a recognized and trusted counterparty that both Buyer and Merchant are comfortably using. Such entities include Chase Manhattan Bank, Bank of America, Discover Financial Network, etc. [0210] iv. In this case, the Common counterparty is in receipt of the NACHA or Positive Pay file provided by the Buyer and establishes the open to buy [0211] v. The merchant submits the Trace Number and Amount to the Common counterparty for validation against the open to buy [0212] vi. Upon confirmation that the transaction is valid, the Common counterparty initiates an ACH Debit from the Buyer's account and credits the Merchant Account via the Automated Clearinghouse.

Utilizing Trusted Counterparties in the System

[0213] In the system, if a VCN is used as the token, then the Provider (acting as the merchant) leverages the services of a merchant acquirer to authorize and settle the payment for the 835. Merchant Acquirers exist today, and service merchants across the globe who accept credit and debit cards for payment. Examples of Merchant Acquirers include Vantiv, Chase Paymenech, First Data Merchant Services, and Elavon. The Provider receives the 835 remittance that includes the VCN (token) and payment amount along with other claim identifying information. In one example, the Provider or their PMS/HIS solution provider extracts the VCN from the TRN segment(s) along with the payment amount in the BPR segment(s) and submits them together to the Merchant Acquirer for authorization. The submission can take place via manually entry into a POS terminal, electronically via API connection with the Merchant Acquirer, or through any other means agreed upon between the parties. The Merchant Acquirer submits the VCN and amount for authorization through the card payment network, for authorization against the Issuer (and/or Issuer Processor's) open to buy which was initially provisioned at the start of The System process. When the VCN and amount is received by the Issuer, matched against the provisioned open to buy, the Issuer returns an approval code indicating that the transaction is valid and payment is authorized. The approval code is transmitted by the Issuer through the card payment network to the Merchant Acquirer. The Merchant Acquirer provides confirmation to the Provider (merchant) that the transaction is valid and has been authorized for payment settlement. Confirmation can take the form of an approval formatted as such: Approved 1234. Finally, and following current processes today, the card payment network debits the funds associated with the token which has been authorized from the Issuer's clearing account, and credits the same amount to the Merchant Acquirer's clearing account. The Merchant Acquirer transfers the same amount from their clearing account to the Provider's bank account based on already negotiated settlement terms in terms of timing of deposit.

[0214] The uniqueness of the VCN authorization model is that the Provider has a specific token which always links to the deposited payment in their bank account. Furthermore, they have been provided with an approval code which confirms that the exact amount of the payment requested has been approved. In this model, and unlike the current process, the Provider is in full control of the funding transaction, which includes: knowing the amount to be paid, knowing the timing of when funds will be deposited, knowing exactly which remittance the fund deposit links to (via common token).

[0215] In the system, if a ACH trace number is used as the token, then the Provider (acting as the merchant) leverages the services of a merchant counterparty (usually their bank) to authorize and settle the payment for the 835. Merchant counter parties exist today, and service merchants across the globe who initiate and receive ACH payment transactions. Examples of Merchant counter parties include Chase, Bank of America, Citibank. The Provider receives the 835 remittance that includes the ACH Trace Number (token) and payment amount along with other claim identifying information. In one example, the Provider or their PMS/HIS solution provider extracts the ACH Trace Number from the TRN segment(s) along with the payment amount in the BPR segment(s) and submits them together to their Merchant Counterparty. The submission to the Merchant counterparty can (amongst other methods) happen via electronic file transfer in the NACHA or positive pay file formats, and transmits, electronically via API connection or any other predefined and agreed upon electronic file transfer protocol. The merchant counterparty submits the trace number and amount for authorization to the healthcare payer's (the entity that created the 835, also known as the buyer) counterparty to validate against the originally provisioned open to buy at the start of The System process. When the Trace Number and amount is received by the Payer's counterparty, matched against the provisioned open to buy, the Payer counterparty returns an approval code indicating that the transaction is valid and payment is authorized. The approval code is transmitted directly to the Provider's counterparty. The Provider's counter provides confirmation to the Provider (merchant) that the transaction is valid and has been authorized for payment settlement. Confirmation can take the form of an approval formatted as such: Approved 1234. Finally, and following current ACH processes today, the counter parties settle payment by moving the funds from the Payer's bank account to the Provider's bank account. In the case of a debit ACH, the Provider's counterparty initiates a debit ACH transaction through the Automated clearinghouse. In the case of a credit ACH, the Payer's counterparty initiates the transfer from the Payer's bank account to the Provider's account through the automated clearinghouse. The Automated Clearinghouse knows which banks are participating and which bank is the source of funds based on the first few digits (5) of the Trace Number which is a bank identifier within their Trace Number schema. The number of digits within the Trace Number that identifies the originating bank is an example, and is established by the ACH network. Whatever the requirement is, it can be deployed in this system.

[0216] The uniqueness of the ACH trace number authorization model is that the healthcare Provider receives an 835-remittance advice from a payer which has an embedded token generated by the payer which links the 835 to the deposited payment in the provider's bank account. Furthermore, they have been provided with an approval code which confirms that the exact amount of the payment requested has been approved. In this model, and unlike the current process, the Provider is in full control of the funding transaction, which includes: knowing the amount to be paid, knowing the timing of when funds will be deposited, knowing exactly which remittance the fund deposit links to (via common token).

[0217] FIG. 5 shows how counter parties are used in the system to authorize and settle payment [0218] a. Payer creates remittances with embedded VCN token as described in FIG. 2, and transmits to Provider via existing transmission mediums (e.g. US mail, file transfer protocol, email). Claims, i.e. 835 forms, are received from healthcare providers by payer's computer system by way of an electronic data exchange network. Once the claim is adjudicated, an 835 remittance is generated by payer's computer system in a manner known in the art. In accordance with one aspect of the invention a trace or token is embedded in the 835 before it is sent to the healthcare provider and payer's counterparty for payment. The trace or token links ACH and VCN payments to specific 835 remittances. The token may be generated by Payer's computer system or a third party as discussed above. [0219] b. Payer also sends notification to card issuer (and/or card processor) of the VCN issued, and the associated amount linked to the VCN via standard electronic file (e.g. file transfer protocol, EDI transmission). Notification establishes the Open to Buy as described in FIG. 2. Notification is transmitted via communication network, internet, or other electronic protocol. [0220] c. Provider receives the remittance, and extracts the VCN, authorization amount (may include other identifying information). The provider's PMS or HIS which receives the remittance is typically accessed via a computer with memory, and the 835 data is loaded into the PMS or HIS database. [0221] d. VCN, amount (and other information) is submitted to merchant acquirer via a physical point of sale terminal or API or other standard method for authorization in a known manner. [0222] e. Merchant Acquirer submits VCN and Amount to Issuer (and/or Issuer Processor) via the Card Payment Network. The Merchant Acquirer's transmission may be by secure telecommunications connection, virtual private network, internet connection or other telecommunication tool commonly used in the industry. Hardware used to support such connections include servers, routers, hubs and other computer systems. [0223] i. Card Payment Network transmits VCN and amount to Issuer (and/or Issuer Processor)—box (b) for authorization. [0224] ii. Issuer (and/or Issuer Processor—box (b)) validates VCN and amount against Open to Buy which was established from Payer Notification. Issuer systems typically include mainframe computers with memory and a database. Issuer systems are connected to the card payment network via telecommunications equipment and protocols typically utilized in the industry (hubs, routers, switches, Ethernet/Coaxial/Copper cables) [0225] iii. Issuer (and/or Issuer Processor) confirms transaction with an approval code that is transmitted back to Card Payment Network [0226] iv. Card payment network transmits approval to merchant acquirer [0227] v. Merchant acquirer notifies Provider of approval via approval code. [0228] f. Issuer moves funds from Payer's funding account associated with authorization to Issuer's (and/or Issuer Processor's) card payment clearing account which they own [0229] i. Card payment network debits Issuer's clearing account [0230] ii. Card payment network credits Merchant Acquirers clearing account [0231] g. Merchant Acquirer moves funds from clearing account to Provider's bank account

[0232] ACH Process [0233] a. Payer creates remittances with embedded ACH Trace Number (token) as described in FIG. 2, and transmits to Provider via existing transmission mediums (e.g. US mail, file transfer protocol, email). Typically, the remittances are transmitted electronically by way of payer's computer system and communication network in a known manner over an EDI network. [0234] b. Payer also sends notification electronically to their ACH counterparty (which is typically their bank) which includes the ACH Trace # and associated amount linked to the Trace #. Notification can be provided via NACHA file or Positive Pay file (as examples). [0235] c. Healthcare Provider receives the 835 remittance within their PMS and/or HIS over an EDI network for example, and extracts the Trace #, authorization amount (may include other identifying information) in a known manner. [0236] d. Trace #, amount (and other information) is submitted to Provider counterparty (usually their bank) via point of sale terminal or API or other standard method for data transmission. Data transmission may be via NACHA file or Positive Pay file. [0237] i. Provider counterparty submits Trace # and Amount to Payer's counterparty for validation and approval. Counterparty systems include both computer systems and communications systems. [0238] ii. Approval is provided by Payer's counterparty if Trace # and Amount match information provided by Payer in NACHA file or Positive Pay file. [0239] e. Upon approval, Payer's counterparty initiates a credit ACH via the Automated Clearinghouse to move funds from the Payer's Bank Account to the Provider's Bank Account; or [0240] f. Upon approval, Provider's counterparty initiates a debit ACH via the Automated Clearinghouse to move funds from the Payer's Bank account to the Provider's Bank account [0241] g. Utilizing this method, the Payer's counterparty still acts as a gatekeeper of access to the Payer's bank account. Only authorized transactions will be allowed to be debited from the bank account. [0242] iii. In an alternative instance, boxes (b) and (d) can be replaced with a common counterparty, e.g. a recognized and trusted counterparty that both Payer and Provider are comfortably using. Such entities include Chase Manhattan Bank, Bank of America, Discover Financial Network, etc. [0243] iv. In this case, the Common counterparty is in receipt of the NACHA or Positive Pay file provided by the Payer and establishes the open to buy [0244] v. The Provider submits the Trace Number and Amount to the Common counterparty for validation against the open to buy [0245] vi. Upon confirmation that the transaction is valid, the Common counterparty initiates an ACH Debit from the Payer's account and credits the Provider Account via the Automated Clearinghouse.

A Mechanism to Charge for the System

[0246] The Card Payment Networks and/or Payment Services providers not only provision the standards that govern tokenized transactions and the communication networks through which transactions are authorized and settled; they also have an embedded platform to administer any pricing structure established by the system participants.

[0247] For example, the participants may establish that the value delivered by this process is worth 50 basis points of the amount settled on the token. The participants may also agree that the 50 basis points will be split equally amongst: the issuer, the merchant acquirer, the card payment network, the PMS platform provider and the Issuer Processor. To fund the 50 basis points, both the Payer and the Provider might agree to fund 10 bps and 40 bps respectively. For a $250 transaction, the settlement may resemble the following: [0248] $250.00 is authorized [0249] The Card Network debits the Issuer account for $249.75 [0250] The Issuer debits the Payer's account for $250.25 [0251] The Issuer transfers $0.25 to the Issuer Processor [0252] The Card Network transfers $249.50 to the Merchant Acquirer [0253] The Merchant Acquirer transfers $249.00 to the Provider's bank account [0254] The Merchant Acquirer transfers $0.25 to the PMS platform account The same framework would apply to a Payment Services Provider over the ACH network

Benefits of the System

[0255] There are many benefits of the system, including: [0256] The elimination of paper and the associated costs and environmental impacts [0257] The reduction of work-effort associated with manual data entry and transaction reconciliation [0258] The guarantee of funding & settlement to the Provider [0259] The guaranteed linkage of funds to the remittance to which it belongs [0260] Faster receipt and application of cash [0261] Complete and electronically efficient reconciliation of the remittance transaction to the financial settlement

[0262] While the cost savings associated with the elimination of paper are well documented, and the efficiencies promised by electronic transaction processing are formidable, status quo processing of claims payments absent the system neither eliminate the paper, nor deploy the electronic process efficiently. Configuring a process or work-flow that allows detailed remittance data to post electronically, payments to be submitted for authorization and approval in real time, while ensuring the Provider's PMS is in full control of the funding transaction, and informed of funding settlement without human intervention delivers the promised operational and administrative savings of healthcare claims processing automation.

[0263] Obviously, many modifications and variations of the present system are possible in light of the above teachings. Thus, it is to be understood that, within the scope of the appended claims, the invention may be practiced otherwise than as specifically described above.

[0264] What is claimed and desired to be secured by a Letters Patent of the United States is: