WO2001004821A1 - Method and apparatus for settling claims between health care providers and third party payers using a smart card id card - Google Patents

Method and apparatus for settling claims between health care providers and third party payers using a smart card id card Download PDF

Info

Publication number
WO2001004821A1
WO2001004821A1 PCT/US2000/019053 US0019053W WO0104821A1 WO 2001004821 A1 WO2001004821 A1 WO 2001004821A1 US 0019053 W US0019053 W US 0019053W WO 0104821 A1 WO0104821 A1 WO 0104821A1
Authority
WO
WIPO (PCT)
Prior art keywords
party
patient
provider
insurance company
services
Prior art date
Application number
PCT/US2000/019053
Other languages
French (fr)
Inventor
Brian F. Hogan
Original Assignee
Hogan Brian F
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hogan Brian F filed Critical Hogan Brian F
Priority to AU59318/00A priority Critical patent/AU5931800A/en
Publication of WO2001004821A1 publication Critical patent/WO2001004821A1/en

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/14Payment architectures specially adapted for billing systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/346Cards serving only as information carrier of service
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance

Definitions

  • the present invention is a business method and apparatus for adjudicating and effecting payment of claims between providers of health care and third party payers utilizing credit card administration.
  • the System connects health care providers, third party payers and credit card processors in a real-time processing mode environment, to provide fully automated adjudication and payment processing of medical claims and tracking of critical claims data.
  • a client or patient seeks services or goods (see line 101) from a health care provider and presents insurance identification.
  • the provider attempts to confirm (see line 102) eligibility (primarily a verification that the policy is in force) of insurance by telephone or fax contact with the client's insurance company as instructed on the client's insurance identification card. If the provider is unable to confirm eligibility of benefits, the provider will likely seek alternate forms of payment for service and the patient must manually seek reimbursement from the insurance company. If the Provider can obtain eligibility for insurance, it must then be determined if other contractual terms will impede reimbursement. If the provider is confident that insurance will reimburse the services, then the provider treats the patient on the strength of the credit provided by the insurance company.
  • the services are then rendered to the client and the provider submits a claim (see line 103) to the client's insurance company by mail .
  • the insurance company will adjudicate the claim and mail a check for the eligible expenses to the provider.
  • the claim reimbursement after adjudication of the claim in the form of a check is typically a partial payment of the submitted claim amount because of, e.g., the deductibles, the co-payments and/or, but not limited to, the fee exceeding the contractual limits of the patient's policy.
  • the provider compares the covered expenses with the original charges, and if necessary, bills the balance (line 104) to the patient/client.
  • the client then reimburses the provider or forces the provider to open a delinquent account.
  • at least 80%, of balance bills subsequently billed to the patient/client remain uncollected.
  • the doctor will ultimately write off this balance, bill a portion, or turn it over to a third party collection agency. This, of course, does not build goodwill for the doctor or in the doctor's community.
  • the communication between the client, the provider, and the insurance company is by telephone or facsimile or by mail.
  • Smart cards incorporate a microprocessor embedded in the card and can interact with a terminal or other electronic reading and writing device.
  • Credit and debit cards for example employ information encoded on a magnetic strip.
  • the smart card, with its microprocessor can provide information about the cardholder as well as the cardholder's account, transaction authorization, or other information, including serving as a traditional credit card or debit card.
  • credit card and/or debit card shall be interchangeable, such that use of the term credit card shall also include and mean a debit card as well.
  • payment card shall include a credit card and/or a debit card or smart card as used herein.
  • the smart card serves at least three purposes; first is to identify the insured/client/patient/certificate holder and provide information and data regarding the patient that allows for confirmation of eligibility by the insurance company. Second, it provides information regarding a line of credit - up to the insurance policy plan maximum for insurable expenses and up to an established line of credit for retail non-insurable expenses (deductibles and co- insurance, or other non- health purchases) . Third, by linking credit card processors with a claim System at an insurance company, it is also possible to achieve immediate claim adjudication and payment in a "paperless" environment.
  • the present invention is a method and apparatus for adjudicating and effecting payment of claims between health care providers and health care third party payers utilizing credit card administration systems.
  • Healthcare providers means doctors, hospitals, drug stores, and parties expecting to submit a claim to an insurance company, for payment for services rendered or goods provided.
  • Third party payers include the insurance company, HMO or a preferred provider organization such as, e.g., Aetna ® , and Blue Cross/Blue Shield ® (Registered trademarks of Aetna Life and Casualty Company, and Blue Cross/Blue Shield Association, respectively) .
  • Immediate claim adjudication means the review and determination of the amount of the payment contemplated by the insurance agreement between the parties, the actual amount further depends on the insurance agreement between the parties since the doctor's bill may be, for example, $125 and pursuant to the agreement between the insurance company and the injured, the injured may pay a fractional amount such as 80%, or the sum may be adjusted by a deductible amount, in which case the case is adjudicated and, thus, "adjudicated” may mean accepting or rejecting the claim in whole or in part by the insurance company.
  • CPT Current Procedural Terminology
  • CPT descriptive terms and identifying codes was first developed and published in 1966 by the American Medical Association. It currently serves a wide variety of important functions. This work of terminology is the most widely accepted medical nomenclature used to report medical procedures and services under public and private health insurance programs. CPT is also used for administrative management purposes such as claims processing and developing guidelines for medical care review.
  • PPO's preferred provider organizations
  • a Preferred Provider Organization makes arrangements for lower fees with a network of health care providers. PPO's give their policyholders a financial incentive to stay within that network. For example, a visit to an in-network doctor might mean the patient has a $10 "co-pay" . If the patient wanted to see an out-of-network doctor, they would have to pay the entire bill up front and then submit the bill to their insurance company for an 80 percent reimbursement. In addition, they might have to pay a deductible if they were to choose to go outside the network, or pay the difference between what the in- network and out-of-network doctors charge.
  • Health care providers will access the System through a connection to the world wide computer network in their office on a computer, including a personal computer, located in the provider's offices and agree to a fixed fee schedule based on Current Procedural Terminology (CPT) codes.
  • CPT Current Procedural Terminology
  • the magnetic strip on the smart card will include policy, certificate holder and plan information.
  • An insured would present the smart card, in lieu of the traditional insurance card, as is standard operating procedure, when seeking health related service.
  • the provider's office administrator can now confirm eligibility by checking that the insured' s policy is paid to date by using the same procedure that any vendor would use to confirm that a line of credit is in good standing. To do so, the insurance company would provide the System with a list of delinquent accounts on a daily basis, or other regular basis. If the policy is valid then the provider will receive an electronic confirmation of eligibility for services. If the policy is delinquent then the default procedure is for the provider to telephone the insurance company to obtain a verbal confirmation or request alternative means of payment.
  • This step requires a link between the provider and the claim system, which is accomplished through the System interface of the present invention. The link would open the certificate holder's file, process the request and record the transaction.
  • the facilitator of these activities can be the realtime System interface on the world wide computer network.
  • the System will attempt to obtain an immediate "approval” from the insurance company's claim system. If the submitted fee agrees with the negotiated CPT code and the procedure is within the insurance policy rules, then in real-time, the claim is "approved” and funds are ultimately transferred to the provider's bank account.
  • a written Explanation of Benefits (EOB) is automatically generated and sent to the provider and patient for their files.
  • the monthly statement from the credit card processor can serve as the EOB to both the provider as a vendor and patient.
  • real-time means that the response to a given situation is generally provided by the System to the requestor e.g. the provider, while the provider is on-line.
  • Real-time is the period that a reasonable person would expect an electronic payment e.g. a retail credit card approval to require. Typically the expectation is one to three minutes but can take longer depending on electronic traffic, modem speed, etc. Exceptions will exist, such as when equipment is down or communications between equipment is slow.
  • realtime is not as exists in the present state of the art. As to the latter, such an example would include that described above in the "Related Art" section, where decisions on eligibility as used in the present system is often not known until payment is received and complete payment of claims takes considerable time, and often months .
  • the claim is manually adjudicated by the insurance company to determine if any benefits are payable by the policy. If benefits are payable, then the insurance company advises both the credit card processor and the insured.
  • the present invention allows health insurers in association with a credit card processor, to issue a combination health care certificate and payment card to plan members, both incorporated in the smart card. It replaces the current insurance identification card (certificate) and it can also be used to settle non- insurable medical expenses or other retail purchases, just as with a traditional credit card.
  • the combined card will be used to access the web- based System of the present invention (that can also be accessed through standard credit card devices) .
  • a provider uses the card to verify identification and assess a patient's "lines of credit" that are secured by health insurance policies and/or personal lines of credit.
  • the System determines the quality of credit risk and assigns a rating to the patient prior to services being rendered.
  • the credit rating is based on information provided by the insurer including, i.e. are premiums paid to date, combined with the availability of the personal line of credit of the insured.
  • the System establishes an interface with both the insurance company' s claim system and the payment card processor's administration system.
  • the coded claim is first directed electronically to the insurance company's claim system.
  • the claim system advises the amount of the expenses that it will reimburse under the terms of the client's policy.
  • the System then electronically forwards the data to the credit card processor to determine if there is sufficient credit in the insurance company's account and the patient's retail credit account to reimburse the provider.
  • the credit card processor would credit the provider's account for services and arrange for reimbursement by insurers. Co-payments or other non- insurable expenses due the provider can either be charged to the combination health care certificate and payment card or paid by the consumer directly. As to the payment by credit card, if there is sufficient credit, then payment is effected. If there is not sufficient credit, the provider is advised to seek alternate payment from the patient.
  • Insurance companies will significantly lower operating costs and will be able to achieve significant reductions in the cost of claims processing by implementing the System of the present invention.
  • the System will provide the insurer with immediate claims data, thereby reducing the "tail" of incurred but not reported claims and the greater predictability of claims, combined with more accurate treatment coding, will allow for more accurate product pricing and more stable earnings.
  • the health insurer will generate new revenue through negotiations with credit card processors for the right to issue the new smart card with the combined purposes. Health insurers will receive payments from the credit card processor for their members who enroll and use their smart card. This relationship with credit card processors thus represents a new revenue source for health insurers. Anecdotal evidence suggests that credit card processors may be willing to pay $50 for each new credit card account.
  • the System will allow physicians to determine who is responsible for payment for medical services in a realtime mode. They will be able to significantly reduce their overhead by reducing paperwork and back office expense associated with filing of claims and collection expenses. This will result in lower account receivables and reduced cost of carrying debit. The physicians will experience better cash flow. By immediately establishing who is financially responsible for services rendered, physicians will be able to reduce doubtful account balances. Office management will be simplified by the enhanced organization of patient and collections data the System offers. Summaries of payment information will be available on the System's web site and provided in a monthly report to the physician. The physician will be able to focus more of his time and energy on providing healthcare to his patients his core business and will be able to increase revenues while reducing expenses.
  • FIG. 1 is a block diagram of the traditional insurance claim relationship between the first party/client/patient, the second party/provider and the third party/insurance company.
  • FIG. 2 is a block diagram of the relationship of the client, the provider, the insurance company and a credit card processor.
  • FIG. 3 is a screen showing a portion of the super bill from the System as seen by a provider.
  • FIG. 4 is a screen showing another portion of the super bill from the System as seen by a provider.
  • FIG. 5 is a screen showing the super bill from the System as seen by a provider.
  • FIG. 6 is a screen used during sign on from the System as seen by a provider.
  • FIG. 7 is another screen used during sign on from the System as seen by a provider.
  • FIG. 8 is another screen used during sign on from the System as seen by a provider.
  • a client 10 seeks services, line 201, or goods from a health care provider 20 and presents a health service card of the present invention (the smart card) .
  • the present invention assumes that client 10 has already qualified and is insured by an insurance company 30, according to their normal underwriting standards.
  • the smart card would normally be obtained by each client patient 10 insured by an insurance company 30 in the System 45.
  • the primary documentary evidence provided by client 10 to the provider 20 is in the form of the smart card, line 201.
  • This smart card information can be entered into the provider's system by numerous ways, by entering the patient's I.D. number from the smart card or swiping the smart card through a magnetic card reader and is communicated to the System 45, line 202.
  • the provider 20 receives a confirmation of the eligibility of client 10, based on information sent and received back from the insurance company 30 along with an authorization from the insurance company 30, lines 203.
  • the insurance company 30 provides the System 45 with a daily list of delinquent accounts, line 204 - if the card is not identified as delinquent, then the provider 20 receives an authorization to provide services according to an agreed upon fee schedule.
  • the credit card processor 40 will also determine the amount of retail credit available in the client's account, line 205, and advises the System accordingly.
  • the patient's/client's benefits, as provided by the insurance company are reviewed prior to providing a confirmation of eligibility by the insurance company which are subject to an agreed upon fee schedule with the client.
  • One of the benefits at this particular step is the minimal amount of time taken between a request by provider 20 to verify eligibility and a return response from the System 45 confirming the eligibility of client 10.
  • the System communicates with the insurance company's records of the client to determine the adjudication of the provider's submitted claim.
  • the adjudication of the provider's submitted claim As an example, if during the visit, two procedures were performed, two codes would be entered with two corresponding fee amounts. Assuming the first procedure,
  • a credit card advice would be printed at the provider's office so that the client can sign the charge slip and accept the charges. Thereafter, the client can either pay the charge immediately to its credit card processor or finance according to the terms of the retail credit card agreement.
  • the entire amount of the submitted claim charge would be paid from the insurance company' s account and the System would advise the provider that the claim has been settled in full by the insurance company and payment effected by the credit card processor on behalf of the insurance company.
  • a confirmation would be signed by the patient which would also show a zero balance. The insurance company and the credit card processor would settle between themselves the
  • the provider would receive funds pursuant to the agreement with the credit card processor, typically within 24-48 hours, as is known and practiced in the art .
  • the credit card processor 40 establishes a retail line of credit with the client 10 in line 208, in addition to the line of credit for insured health
  • the credit card processor monitors the available line of retail credit for each client.
  • the System will determine the extent of retail credit available to any client based on the characteristics of the members/clients 10 belonging to a participating insurance policy of insurance company 30. This will be performed using risk profile analyses.
  • the present method allows for determining a profile based on the group of clients to be provided to the credit card processor in determining the amount of retail credit to be offered to the client and to each client within the insurance company's group. It is anticipated that these determinations may be made by providing the data in the present System of clients to the credit card processor so that the credit card processor can make determinations of credit limits for each group or subgroup of clients. It is further anticipated that in addition to providing healthcare services, that the data contained within the pool of clients as a potential pool of credit card users has value which can be offered for consideration to a credit card processor.
  • the client can also use the smart card for retail credit in any store that accepts retail credit cards. This opens the door to eliminate the client having multiple credit cards, multiple insurance cards, and multiple health I.D. cards used to buy prescription drugs, etc. (prescription drug cards, lab cards, and medical cards.)
  • the insurance company 30 and credit card processor can also use the smart card for retail credit in any store that accepts retail credit cards. This opens the door to eliminate the client having multiple credit cards
  • the insurance company 40 agree to have their systems linked to the System 45.
  • the insurance company and providers agree to use CPT codes, and agree upon fee schedules for services rendered under the policy.
  • the insurance company authorizes the credit card processor via the System 45 to make a payment on their behalf for the services according to the patient's plan, lines 209.
  • the insurance company reimburses the credit card processor pursuant to agreed upon terms the amount the credit card processor paid the provider on its behalf.
  • the credit card processor 40 pays provider 20, line 210, and would balance bill the client 10 for any expenses not covered by the insurance plan, if agreed upon at the settlement conference.
  • the credit card processor benefits by having access to preferred credit card clients 10 that are actively at work for an employer of sufficient size and stability to qualify for insurance e.g. group insurance. There is a low credit risk, people generally will protect their health "safety net" and keep their credit in good standing.
  • the insurance company benefits by having the ability to lock providers into a fixed fee for service arrangement; and reduced claim administration, because of the ability to focus on claim management as opposed to claim processing.
  • Health care providers will benefit because of the immediate payment for services and reduced office administration. Policy holders will benefit because of the ability to manage personal health care expenses and the convenience of carrying only one card e.g. the smart card of the present invention.
  • the present System uses the worldwide computer network as its communication platform.
  • the provider 20 must have a world wide communication network connection
  • the System 45 will be its own Internet Service
  • the System will also be an "Application
  • the provider will not need to install the software on the provider's personal computer for example, but rather the provider will access the software as it is needed via the world wide communication network.
  • the only data stored on the provider's computer is the connection utility which will be provided by the System.
  • the System will run on any computer system that can make an internet connection, but is usually an IBM ® compatible PC.
  • An interface will be used to connect with the insurance and credit card systems.
  • System 45 of the present invention is a combination of programs, data and processes focused on the electronic processing of health claims and the associated payments on behalf of all parties.
  • System 45 The objective of System 45 is to fully process the required transactions, so no further processing is required, this is, once the System has processed a claim, all of the involved parties must be satisfied in their requirements .
  • Claim adjudication under the present invention will be an automated process performed by the insurance company.
  • An improvement in the present invention is that the insurance company will delegate the making of claim payments to the credit card processor thus relieving the insurance company from processing payments to the various providers and clients.
  • the System allows the patient and the doctor to agree and accept the method of financial settlement.
  • the financial processing (payments, accounts payable and receivables) will be handled by the credit card processor utilizing its well documented expertise in efficiently processing large volumes of financial transactions. This relieves the doctor from follow-up with the client and/or the insurance company in order to collect their professional fees for services rendered.
  • the claim adjudication process is initiated when the provider submits the super bill to the insurance company.
  • the insurance company reviews the super bill e.g. CPT codes, along with the particulars of the insured patient along with other additional information from the provider, including the provider's submitted fees in the claim.
  • the insurance company makes a determination of the insurance company's liability and a determination of the patient's liability. If the patient has liability, e.g. the insurance company's policy for the insured patient does not cover in whole or in part the submitted claim e.g. deductibles, co-payments or uninsurable amounts, the System will then look to the availability of credit on the patient's smart card.
  • the System 45 communicates information of the claim adjudication from the insurance company 30 and the credit card processor advising the provider 20 the following: that the claim is accepted; and that the insurance company owes X dollars and the patient owes Y dollars. In making the latter statement that the patient owes Y dollars the System 45 is representing to the provider 20 that the patient's smart card has available credit to settle the obligation of Y dollars.
  • the next stage is the "settling conference” or the Explanation of Benefits (EOB) between patient 10 and provider 20 whereby the patient and provider must agree on the claim adjudication set forth by the insurance company.
  • EOB Explanation of Benefits
  • the patient and provider agree on the amounts owed by the patient and the amount to be paid by the insurance company.
  • the provider notifies the System and the System in real-time mode advises both the insurance company and credit card processor that the patient and provider have accepted the adjudication.
  • the credit card processor effects payment of the amount of X dollars and the amount of Y dollars directly to the provider by normal credit card channels via the established credit card interchanges.
  • the insurance company reimburses the credit card processor the amount of X dollars owed by the insurance company.
  • the patient will ultimately reimburse the credit card processor the amount of Y dollars, e.g. the patient's liability.
  • the patient's liability will be charged to the patient's credit card, and paid as the patient desires and included on the patient's monthly statement for payment to the credit card processor.
  • this transaction happens in real-time mode as it is well known in the present art, for example in the Visa ® and MasterCard ® credit card interchanges, delays of settlement (to the provider) of up to 48 hours are per standard operating procedures of retail credit card transactions.
  • the System will involve five different players in four different physical locations, they are:
  • the client 10 (and its ID card in the form of a smart card) ; the medical facility, provider 20 (clinic, hospital, doctors, etc.); the insurance company 30; the credit card processor 40; and the System interface 45 as the coordination center between the parties.
  • the locations involved will be the medical facility (client and doctors) ; the insurance company; the credit card processor; and the System.
  • the System 45 will make possible that all the physical locations stay at least virtually connected and available as needed for the clinic and client to complete a transaction.
  • the System will be developed as an "asynchronous" system. That is, each step of the process will wait for the prior step to be completed before continuing with the next step, all of this under the automated control of the System.
  • the System can process transactions that may take from seconds to whole hours to complete without failure.
  • the System will save required information from each transaction to be able to justify the final outcome of the result to each party.
  • These connectivity requirements make the worldwide computer network the preferred media for communication.
  • the worldwide computer network can be as secure as required, more than regular credit card point of sale (POS) machines and it also provides the required flexibility and cost savings needed for the process of the volume of transactions anticipated to be handled by the System.
  • POS point of sale
  • the System 45 will work on two separate sets of data, data created by the System while processing transactions and data that pre-exists in the System before a transaction can be processed.
  • Pre-existing data will contain: insurance data; credit data; System 45 tables to reflect the various agreements between the insurance companies and the credit card processor; other data used by the System 45 client software; and medical tables like CPT tables.
  • Transaction Data will include clinic created data, and System created data.
  • the System interface 45 will have two sets of codes, a client code and a processing code. Client codes will be responsible to interact with the clinic/patient side, print the super bill and the final Explanation of Benefits (EOB) .
  • the processing code will receive request for identification of the patient, submit request to insurance company, and submit request to credit card and reply to the clinic.
  • the System 45 is divided into two modules: a back office system, in the form of a worldwide computer network web site will act as the main communicator between the parties and a data repository dedicated to validate and route requests to the insurance company and the credit card processor.
  • the client programs are the user interface used to read the credit card, create a super bill, submit data to and read data from the back office system, it will also interface with future physicians office management programs .
  • the System interfaces with databases stored in the claim administration system at the insurance company and the processing system at the credit card company.
  • a unique client identification number is stored on the magnetic stripe of the smart card. It is also embossed on the smart card. This ID number is used to access the data stored in the insurance company and claim system administrating systems of the credit card processor.
  • Some data may be temporarily stored in the System (range of policy numbers that are either enforce or lapsed, providers participating in the program, etc.), but the data originates at the insurance and credit card companies and it is their responsibility to update.
  • An interface 45i provides an electronic link that allows the System of the present invention to communicate in a compatible computer language to independent systems (the insurance company and credit card processor) .
  • Each interface 45i is unique to the System of the present invention and the system that it connects.
  • the interface is a program stored in a powerful personal computer that is physically connected, by hard wire to the insurance and credit card systems. It is connected to the System Internet Service Provider (ISP) via the world wide computer network.
  • ISP System Internet Service Provider
  • the concept of a super bill is a form which contains the entire patient and payer data before the medical service is provided. It also will contain information on the services rendered and the fees charged. This "form” becomes then an electronic form for the System 45, where it is sent partially to the insurance company for claim adjudication, becoming effectively a "claims form” from the insurance company point of view.
  • the super bill travels to the credit card processor in the form of "credit card charges.”
  • the credit card processor returns an approval code for the transaction (or a denial)
  • this reply is added to the electronic version of the super bill which is received by the System and returned back to the clinic.
  • Once in the clinic it becomes a paper form which is printed as a combined clinic form plus insurance company Explanation of Benefits (EOB) plus a credit card processor voucher.
  • EOB Explanation of Benefits
  • a client will seek services from a Provider (Clinic or Hospital), upon arrival, the client will identify himself with a credit card issued/registered for the purpose .
  • the receptionist will swipe the card to read and transmit information to the System. Then the client program will communicate with the back office system, which will identify the smart card and provide the operator with an option list of patients under the card e.g. spouses or dependents. In order to reduce the risk of bad payments, the
  • This credit rating is a combination of insurance coverage and credit line, the more insurance and more credit line, the lesser the risk or higher the credit rating will be.
  • the System 45 will also create a super bill form to be used by the Doctor as services are provided to the patient .
  • the super bill generated by System 45 will reflect the contractual terms between insurance company 30 and patient 10 and between insurance company 30 and the provider 20.
  • the agreement between the insurance company and the provider will reflect any preferred provider relationships that may exist, e.g. discounted fees for service arrangements, mode or means of payment.
  • the relationship between the provider and the patient would be the terms of the insurance policy, e.g. co-payments, deductibles and exclusions.
  • An electronic version of a super bill, number 408, is shown in Fig. 3 on the top half approximately, and the bottom half in Fig. 4.
  • the super bill 31 has four columns A, B, C and D, each column having the CPT code 31, the description 32 and the fee 33 for that description and code. These codes, descriptions and fees would vary depending on the relationship between the insurance company and the provider and between the insurance company and the patient.
  • the present System is able to take current information from those two relationships and provide, by printing a hard copy of a new super bill each time a patient starts a service at a provider.
  • the super bill can reflect the then current terms between the parties in a real-time mode.
  • the provider's relationship has more accurate data and can be provided to the provider from the insurance company by the System.
  • the super bill will now contain current services provided by the provider that would be covered under the patient's current policy with the insurance company. This will allow, at the time of treatment, current information to both the provider and the patient to determine the desired services and allow the patient and provider to both know their economic risk as to whether those services are covered by the insurance policy. This is not to say that services may be withheld or violate any professional code of ethics of the provider. However, it will make available the economic information and current policy information concerning the providing of these services at the time of performing these services or shortly there before as opposed to a point in time long after the services have been performed as is practiced now in the prior art. Other information contained on the super bill is standard, e.g. the provider's name, the patient's name, etc. and is set forth in Fig. 3 and 4.
  • Fig. 5 is a screen, showing the super bill when it is being filled in after the doctor performed services.
  • column 34 in Fig. 5 shows how the individual line items for each description are selected on the computer electronically.
  • the super bill can be and is preferably completed electronically on the computer screen so that it can be sent electronically from the provider to the insurance company through the System 45.
  • an 800 toll free long distance number will be available to verbally transmit the super bill to the System 45.
  • the super bill now completed by the doctor, will be coded into the client program and submitted to the back office system for processing.
  • the back office program will read the super bill form and create a "case" assigning a unique number, which will be returned to the client program to reference this
  • the client program will receive a message saying that the request is being processed.
  • the back office system While the client program is notified that the transaction is being processed, the back office system will also communicate with the insurance company and submit a claim to the insurance company. The back office system waits for the answer from the insurance company which will provide the amounts accepted and covered under the client's insurance, including information on the insurability, deductibles, co-payments
  • the back office system will communicate with the credit card
  • EOB Explanation of Benefits
  • This Explanation of Benefits (EOB) will include information on the charges to the client's credit card and if there is cash pending to be paid by the client.
  • the client will sign the clinic's copy of the Explanation of Benefits (EOB) and will keep a copy for the client's personal records.
  • the credit card processor will send a statement to the client and one to the insurance company of the transactions for that month.
  • the log-in process, on the provider's computer begins typically with a provider (e.g., a doctor's office) , who will sign into the System interface on the world wide computer network at the System' s web site and clear the provider's password. If the identification is valid, the provider can continue with the process.
  • the System interface will identify the provider from its local database of providers in the System.
  • the System interface will display a working console menu at the provider's computer where all activity will be performed.
  • This console screen Fig. 6 will provide the provider with two main options, first to select a patient 21, that is used when a new person walks into the clinic and, select a super bill 22, used when a patient has been serviced by the doctor and it's time to close and pay the bill.
  • new client means new patient that day, walks into the provider's office
  • the provider will select the option "Select Patient”, which in turn will display a screen to enter the patient data.
  • the System will request the name of the payer and date of expiration of the card, name and date are used to validate the card. It can also use the address verification if needed.
  • a combined security code is created, by combining the client card security code with the provider security code.
  • a request is submitted to the back office system to identify the patient.
  • the data passed by the client program to the back office system in this process is: The provider name, the card number from the patient, and the new combined security code.
  • the console user, the operator, will press "SUBMIT" and the request will go to the back office system for card validation and insurability.
  • the back office system will return a provider number to the client program for the card used. This provider number is defined and given by the credit card processor to the provider and will be stored in the back office system.
  • the back office system will also return to the client program one or more records containing information for the patient or patients under that smart card.
  • the information returned will be: Insurance company ID, Policy Number, Certificate Number, Dependent Number, Relationship within the policy (Primary, Spouse, Child etc) , Payment risk (Combined between credit line and insurance coverage) , Patient Last Name, Patient First name, Patient Middle Initial, Patient social security number, and an Error code, if any.
  • the client program will display the list of patients that are covered under the card used, see Fig. 10.
  • the provider will create a new super bill using the selected patient.
  • the System already requested from the back office system, the primary carrier, if the patient is insured by various carriers, and the order that the carriers will appear in the screen will be from the first to the last carrier.
  • the System will determine which carrier has the priority. In the case a carrier that is not the primary and in the case the policy is in force, the System will not allow the selection of another policy. Also, if the primary carrier's policy is not in force, then the System will allow the use of another policy in the case order established in the back office system for that patient.
  • the working console screen Fig. 7 will display the patient's name 23 in the upper left of the screen.
  • the menu options of the screen will change to reflect the valid options for a selected patient.
  • the provider will select the patient and a super bill format from a library of super bill templates residing in the client programs. Also the provider will mark this session as an "accident" or not, this information is required by the insurance company in order to process the claim.
  • the super bill will contain the patient data and the choice of common CPT codes depending on the template. When a super bill is created from scratch, or when codes are added to it not in the template, that template can be saved for future use .
  • the customized super bill will be used by the doctor to record the medical services rendered.
  • console screen shows two tabs with information for Patient Detail 51 and super bill Detail, see Fig. 7.
  • the patient detail tab shows the basic demographic data of the patient. It also carries the last visit date and next appointment. This is restricted to that particular provider only.
  • the other option, is called Patient super bill 53 which if chosen, will display all of the super bills that client has with that clinic, current and past. This acts like a Patient historical information list.
  • the newly created super bill is printed and is passed to the doctor to treat the patient.
  • the first part of the printed super bill 31, Fig. 3, is the header which includes information about the patient and the doctor.
  • the second portion of the super bill, Fig. 4, the bottom of the super bill, contains space to be completed by the doctor, for the doctor's notes .
  • the super bill will be returned to the provider's operator for processing.
  • the operator will select the option Select super bill 24. This will list all super bills for that clinic in the status "New", which are the ones pending to be completed and processed. Once the super bill is identified, the operator will press the button
  • a new super bill will include a button "Fill Up Super bill” where the various codes (CPT) are selected depending on what treatment the doctor has performed.
  • CPT codes
  • the operator will enter the various CPT codes and the client program will submit the super bill to the back office system for processing.
  • the user can also save the template (Update it), so it can be used in the future.
  • New CPT codes not in the template, but used by the doctor, can be added by creating a code from the table of possible codes residing in the client program.
  • a super bill cannot be modified by the provider after being submitted.
  • the "result" screen of a processed super bill is now completed by the System 45 as the client program will send to the back office System the following information: Provider Number (Clinic number from previous step) ; Smart Card Number; Social security number from the patient; Insurance company; Policy Number; Certificate Number; Dependent Number; and the combined security code.
  • the back office system processes the super bill as follows: initially the transmitted information is validated. If there is an error the System will notify the client program about it. It will also validate that the smart card submitted is recognized as active and participating in the System 45. It will also get the credit rating code (low, medium, high) of the patient, validate that the insurance company is actively participating in the System 45. The back office system will open a case and return to the client program the "case” number. This case number will be used from here on to identify the process and it will appear in the user screen.
  • the client program will use this "case" number to: First submit, one by one, the CPT codes and reference fees (Clinic Fee) .
  • the client program For each code the client program will send to the back office system the case number the CPT Code, the amount (charged) incurred; and the combined security code.
  • the back office system will add each line to the open case queue for later processing.
  • the back office system will start processing of a case
  • the client program will submit a request with the case number and combined security code.
  • the back office system will process the case as follows : (Error codes will be issued in each of the following steps if the back office system finds that some information is not acceptable); validate request; read pending cases queue to see if the case exists; validate that the case has not expired; validate that the case has not been already processed; validate that the Provider ID assigned by the System to the clinic exists and is valid; validate that the merchant number assigned by the credit card processor to the clinic exist; send a "Not Covered" message for each CPT not covered or recognized by the back office system under this policy contract, and prepare a record for each CPT recognized by the insurance contract as: get CPT code from open case queue; get amount incurred from open case; get amount covered from insurance company table (residing in the back office system) ; get co-payment rules from insurance company 30 table and set co-payment to zero; get deductible indicator from insurance company table and set DEDUCTIBLE to zero; set to zero REFUNDED amount; set to spaces
  • Update Dependent claim history record as: add the
  • the process will record the approval code from the credit card processor in the back office system database, create accounts receivable in the back office system database, subtract the credit card processor commission from the transaction, and create a payable to the clinic net of commission charged by the credit card processor.
  • the client program After the "case" is processed, the client program, will request information in a separate menu where all submitted cases has been posted.
  • EOB Explanation of Benefits
  • the Explanation of Benefits will contain: the insurance company credit card number and approval code (if charged) ; the client credit card number and approval code (if charged) ; the total charges by the clinic; the amount covered by insurance company; the amount charged to client card (if approved) ; the amount charged to the insurance company card (If approved) ; cash due by client (if any) ; balance due by insurance company (if insurance company credit was rejected); (case) number; provider ID (clinic) ; policy number; certificate number; dependent number; insurance company; CASE open date; CASE expire date; and insurance company name. Also, in the EOB will be an informational line for each treatment: CPT code; amount incurred; amount covered; amount of deductible; amount of co-pay; amount refunded; insurance company process message; and accept/deny code as set by the insurance company.
  • Additional items in the EOB will be social security of patient; provider name (clinic name); patient last name; patient first name; patient middle initial; credit card processor; credit card processor name; payer (card owner) social security; credit rating; card relationship
  • the client program will print a final combined Explanation of Benefits (EOB) and receipt.
  • EOB Explanation of Benefits
  • a copy will be printed for the client and a copy for the clinic (to be signed by the client) .
  • the EOB will have two main sections, one for the headings and detail CPT codes, and the second with the payment data.
  • the flow of the System is generally as follows: 1. Get request of information from clinic, process the request and return answer. a. Validate provider exists in System from participating providers list (provider) . 1) Validate the card submitted against the list of participating cards (option will be to process charge to validate card) .
  • Update Super Bill Detail Form a. Obtain the Super Bill Template Code. b. Insert new CPT Codes. c . Insert new Headings . 6. Update super bill from queue after process has been completed, submit case number. a. Update the Super Bill Detail from super bill processing queue. b. Update the super bill credit card charges FOR Payer (D) . c . Update the Payer account for new balance due (if Credit Card Processor transaction rejected) . d. Update the super bill credit card charges FOR INSCO (D) . e. Update the payer account for new insurance company balance due (if transaction rejected) . f . Update the super bill FROM THE OPEN_CASE (B) . g. Update the super bill from summary of super bill detail form (E) . h. Change the super bill status to "R" Received.
  • the pending deductible for this dependent is computed. g. Find if there is a co-pay for the refund amount as flat $ amount . h. Accumulate charges payable by the insurance company.

Abstract

A method and apparatus for settling claims and effectuating payment of services for the benefit of a patient (10) that is performed by a doctor and payment is facilitated by an insurance company (30) where the patient (10) requests services from a doctor, and the patient (10) has an insurance smart card which contains information regarding the patient's insurance relationship with the insurance company (30) and the patient's relationship with the doctor, and provides a retail line of credit, and where the doctor communicates information from the patient's smart card to the insurance company (30) which then confirms eligibility of the patient (10) in a real-time mode and provides a predetermined fee schedule between the insurance company (30) and the doctor for the services to be performed and a claim is submitted with the fee schedule to the insurance company (30) and the claim is adjudicated in real-time mode and the claim is settled by authorizing transfer of funds to the doctor and any additional noncovered fees can be charged to the patient's smart card retail credit line.

Description

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE PCT PATENT APPLICATION
Title: Method And Apparatus For Settling Claims
Between Health Care Providers And Third Party Payers Using A Smart Card ID Card
CROSS-REFERENCES TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Applications No. 60/143,448 filed July 13, 1999; and No. 60/168,000 filed Nov. 30, 1999. These provisional applications are incorporated herein by reference .
BACKGROUND OF THE INVENTION
1. Field of the Invention The present invention is a business method and apparatus for adjudicating and effecting payment of claims between providers of health care and third party payers utilizing credit card administration. The System connects health care providers, third party payers and credit card processors in a real-time processing mode environment, to provide fully automated adjudication and payment processing of medical claims and tracking of critical claims data.
2. Description of The Related Art Presently, in the health care industry, total annual health claims processed in the private sector amount to $600 billion. Another $600 billion in Medicaid and Medicare claims are administered by 36 private sector Managed Care Organizations (MCO's) for an approximate total of $1.2 trillion annually in healthcare expenditures. The health care industry is in transition towards consolidation; the industry recognizes the need to reduce operating expenses and more accurately manage claim data in order to increase profitability. MCO's are becoming less vertically integrated - they have outsourced many functions in an effort to become more efficient. The core business of the MCO's includes processing claims, managing medical and other costs, pricing, marketing, and underwriting benefit plan designs. To date, most efforts to incorporate recent technological advances into claims processing have been limited to encouraging the electronic submission of claim data by providers, via electronic data interchange. This would include for example direct wire connection on a private electronic network and batch processing using electronic media. The insurance industry is now investing heavily in information and technology on the world wide computer information network.
The traditional insurance claim process is best shown by referring to Fig. 1. A client or patient seeks services or goods (see line 101) from a health care provider and presents insurance identification. The provider attempts to confirm (see line 102) eligibility (primarily a verification that the policy is in force) of insurance by telephone or fax contact with the client's insurance company as instructed on the client's insurance identification card. If the provider is unable to confirm eligibility of benefits, the provider will likely seek alternate forms of payment for service and the patient must manually seek reimbursement from the insurance company. If the Provider can obtain eligibility for insurance, it must then be determined if other contractual terms will impede reimbursement. If the provider is confident that insurance will reimburse the services, then the provider treats the patient on the strength of the credit provided by the insurance company. The services are then rendered to the client and the provider submits a claim (see line 103) to the client's insurance company by mail . The insurance company will adjudicate the claim and mail a check for the eligible expenses to the provider. The claim reimbursement after adjudication of the claim in the form of a check is typically a partial payment of the submitted claim amount because of, e.g., the deductibles, the co-payments and/or, but not limited to, the fee exceeding the contractual limits of the patient's policy.
The provider compares the covered expenses with the original charges, and if necessary, bills the balance (line 104) to the patient/client. The client then reimburses the provider or forces the provider to open a delinquent account. Presently, it is believed that at least 80%, of balance bills subsequently billed to the patient/client, remain uncollected. Typically, the doctor will ultimately write off this balance, bill a portion, or turn it over to a third party collection agency. This, of course, does not build goodwill for the doctor or in the doctor's community. Furthermore, in the prior art, the communication between the client, the provider, and the insurance company is by telephone or facsimile or by mail.
SUMMARY OF THE INVENTION Traditional insurance ID cards can be replaced with a "smart card" which uses standard credit card technology. Smart cards incorporate a microprocessor embedded in the card and can interact with a terminal or other electronic reading and writing device. Credit and debit cards for example employ information encoded on a magnetic strip. The smart card, with its microprocessor can provide information about the cardholder as well as the cardholder's account, transaction authorization, or other information, including serving as a traditional credit card or debit card.
As used herein this application the terms credit card and/or debit card shall be interchangeable, such that use of the term credit card shall also include and mean a debit card as well. Furthermore, the term payment card shall include a credit card and/or a debit card or smart card as used herein.
The smart card serves at least three purposes; first is to identify the insured/client/patient/certificate holder and provide information and data regarding the patient that allows for confirmation of eligibility by the insurance company. Second, it provides information regarding a line of credit - up to the insurance policy plan maximum for insurable expenses and up to an established line of credit for retail non-insurable expenses (deductibles and co- insurance, or other non- health purchases) . Third, by linking credit card processors with a claim System at an insurance company, it is also possible to achieve immediate claim adjudication and payment in a "paperless" environment.
The present invention is a method and apparatus for adjudicating and effecting payment of claims between health care providers and health care third party payers utilizing credit card administration systems. Healthcare providers means doctors, hospitals, drug stores, and parties expecting to submit a claim to an insurance company, for payment for services rendered or goods provided. Third party payers include the insurance company, HMO or a preferred provider organization such as, e.g., Aetna®, and Blue Cross/Blue Shield® (Registered trademarks of Aetna Life and Casualty Company, and Blue Cross/Blue Shield Association, respectively) . Immediate claim adjudication, as used herein, means the review and determination of the amount of the payment contemplated by the insurance agreement between the parties, the actual amount further depends on the insurance agreement between the parties since the doctor's bill may be, for example, $125 and pursuant to the agreement between the insurance company and the injured, the injured may pay a fractional amount such as 80%, or the sum may be adjusted by a deductible amount, in which case the case is adjudicated and, thus, "adjudicated" may mean accepting or rejecting the claim in whole or in part by the insurance company.
Unique to this approach in the present invention, is an innovative System interface that links credit card administration systems and health insurance claim systems. This System significantly enhances performance of both systems while dramatically reducing administrative costs.
As used herein, Current Procedural Terminology (CPT) , is a listing of descriptive terms and identifying codes for reporting medical services and procedures. The purpose of CPT is to provide a uniform language that accurately describes medical, surgical, and diagnostic services, and thereby serves as an effective means for reliable nationwide communication among physicians, patients, and third parties.
CPT descriptive terms and identifying codes was first developed and published in 1966 by the American Medical Association. It currently serves a wide variety of important functions. This work of terminology is the most widely accepted medical nomenclature used to report medical procedures and services under public and private health insurance programs. CPT is also used for administrative management purposes such as claims processing and developing guidelines for medical care review.
In the insurance industry, health and other insurances are offered under organizations called preferred provider organizations or PPO's.
A Preferred Provider Organization (PPO) makes arrangements for lower fees with a network of health care providers. PPO's give their policyholders a financial incentive to stay within that network. For example, a visit to an in-network doctor might mean the patient has a $10 "co-pay" . If the patient wanted to see an out-of-network doctor, they would have to pay the entire bill up front and then submit the bill to their insurance company for an 80 percent reimbursement. In addition, they might have to pay a deductible if they were to choose to go outside the network, or pay the difference between what the in- network and out-of-network doctors charge.
With a PPO, they can refer themselves to a specialist without getting approval and, as long as it's an in-network provider, enjoy the same "co-pay". Staying within the network means less money coming out of their pocket and less paperwork.
Health care providers will access the System through a connection to the world wide computer network in their office on a computer, including a personal computer, located in the provider's offices and agree to a fixed fee schedule based on Current Procedural Terminology (CPT) codes. Most providers already accept credit cards for payment and participate in a Preferred Provider
Organizations (PPO), facilitating the implementation. The magnetic strip on the smart card will include policy, certificate holder and plan information.
An insured would present the smart card, in lieu of the traditional insurance card, as is standard operating procedure, when seeking health related service. The provider's office administrator can now confirm eligibility by checking that the insured' s policy is paid to date by using the same procedure that any vendor would use to confirm that a line of credit is in good standing. To do so, the insurance company would provide the System with a list of delinquent accounts on a daily basis, or other regular basis. If the policy is valid then the provider will receive an electronic confirmation of eligibility for services. If the policy is delinquent then the default procedure is for the provider to telephone the insurance company to obtain a verbal confirmation or request alternative means of payment.
After services are provided, the administrator would use the card to again access the System, key the appropriate CPT codes for services rendered (which is numeric or alphanumeric) and the corresponding fixed fee. This step requires a link between the provider and the claim system, which is accomplished through the System interface of the present invention. The link would open the certificate holder's file, process the request and record the transaction.
The facilitator of these activities can be the realtime System interface on the world wide computer network. The System will attempt to obtain an immediate "approval" from the insurance company's claim system. If the submitted fee agrees with the negotiated CPT code and the procedure is within the insurance policy rules, then in real-time, the claim is "approved" and funds are ultimately transferred to the provider's bank account. A written Explanation of Benefits (EOB) is automatically generated and sent to the provider and patient for their files. Alternatively, the monthly statement from the credit card processor can serve as the EOB to both the provider as a vendor and patient.
As used herein, real-time means that the response to a given situation is generally provided by the System to the requestor e.g. the provider, while the provider is on-line. Real-time is the period that a reasonable person would expect an electronic payment e.g. a retail credit card approval to require. Typically the expectation is one to three minutes but can take longer depending on electronic traffic, modem speed, etc. Exceptions will exist, such as when equipment is down or communications between equipment is slow. However, realtime is not as exists in the present state of the art. As to the latter, such an example would include that described above in the "Related Art" section, where decisions on eligibility as used in the present system is often not known until payment is received and complete payment of claims takes considerable time, and often months .
If the CPT code does not match the submitted fee, or the procedure is not an insurable expense, then the claim is manually adjudicated by the insurance company to determine if any benefits are payable by the policy. If benefits are payable, then the insurance company advises both the credit card processor and the insured.
The present invention allows health insurers in association with a credit card processor, to issue a combination health care certificate and payment card to plan members, both incorporated in the smart card. It replaces the current insurance identification card (certificate) and it can also be used to settle non- insurable medical expenses or other retail purchases, just as with a traditional credit card.
The combined card will be used to access the web- based System of the present invention (that can also be accessed through standard credit card devices) . At the point of service, a provider uses the card to verify identification and assess a patient's "lines of credit" that are secured by health insurance policies and/or personal lines of credit. The System determines the quality of credit risk and assigns a rating to the patient prior to services being rendered. The credit rating is based on information provided by the insurer including, i.e. are premiums paid to date, combined with the availability of the personal line of credit of the insured.
After service is provided, the doctor submits a claim for immediate approval through the System using industry standard CPT codes. The System establishes an interface with both the insurance company' s claim system and the payment card processor's administration system. The coded claim is first directed electronically to the insurance company's claim system. The claim system advises the amount of the expenses that it will reimburse under the terms of the client's policy. The System then electronically forwards the data to the credit card processor to determine if there is sufficient credit in the insurance company's account and the patient's retail credit account to reimburse the provider.
Leveraging its well -documented comparative advantages in processing large volumes of financial transactions, the credit card processor would credit the provider's account for services and arrange for reimbursement by insurers. Co-payments or other non- insurable expenses due the provider can either be charged to the combination health care certificate and payment card or paid by the consumer directly. As to the payment by credit card, if there is sufficient credit, then payment is effected. If there is not sufficient credit, the provider is advised to seek alternate payment from the patient.
Insurance companies will significantly lower operating costs and will be able to achieve significant reductions in the cost of claims processing by implementing the System of the present invention. The System will provide the insurer with immediate claims data, thereby reducing the "tail" of incurred but not reported claims and the greater predictability of claims, combined with more accurate treatment coding, will allow for more accurate product pricing and more stable earnings. The health insurer will generate new revenue through negotiations with credit card processors for the right to issue the new smart card with the combined purposes. Health insurers will receive payments from the credit card processor for their members who enroll and use their smart card. This relationship with credit card processors thus represents a new revenue source for health insurers. Anecdotal evidence suggests that credit card processors may be willing to pay $50 for each new credit card account. It is anticipated that the insurers would obtain fee reductions from providers in return for the automated, rapid payment of claims. It is not anticipated that there will be a significant expense for the insurer in terms of hardware required to implement the System at the provider's office/facility. Access to the world wide computer network, where the System will reside is nearly universally present in medical facilities, and doctor's or other providers' offices.
The System will allow physicians to determine who is responsible for payment for medical services in a realtime mode. They will be able to significantly reduce their overhead by reducing paperwork and back office expense associated with filing of claims and collection expenses. This will result in lower account receivables and reduced cost of carrying debit. The physicians will experience better cash flow. By immediately establishing who is financially responsible for services rendered, physicians will be able to reduce doubtful account balances. Office management will be simplified by the enhanced organization of patient and collections data the System offers. Summaries of payment information will be available on the System's web site and provided in a monthly report to the physician. The physician will be able to focus more of his time and energy on providing healthcare to his patients his core business and will be able to increase revenues while reducing expenses.
Credit card processors will expand their customer base, fee income, and lower delinquency for cards that are also used to pay for health care treatment. Patients will accept the System because it simplifies the payment process of healthcare claims. Most important, they will know which services their insurer covers at the time of service. They will no longer have to file insurance forms for reimbursement. The System is one that will be perceived as convenient. Patients will have the ability to consolidate their credit card and health insurance accounts, carrying one card, which has multiple uses. DESCRIPTION OF THE DRAWINGS In the drawings that form part of the description of preferred embodiment of this invention and wherein like numbers refer to like structural elements. FIG. 1 is a block diagram of the traditional insurance claim relationship between the first party/client/patient, the second party/provider and the third party/insurance company.
FIG. 2 is a block diagram of the relationship of the client, the provider, the insurance company and a credit card processor.
FIG. 3 is a screen showing a portion of the super bill from the System as seen by a provider.
FIG. 4 is a screen showing another portion of the super bill from the System as seen by a provider.
FIG. 5 is a screen showing the super bill from the System as seen by a provider.
FIG. 6 is a screen used during sign on from the System as seen by a provider. FIG. 7 is another screen used during sign on from the System as seen by a provider.
FIG. 8 is another screen used during sign on from the System as seen by a provider. DETAILED DESCRIPTION OF INVENTION Referring to Fig. 2, a client 10 seeks services, line 201, or goods from a health care provider 20 and presents a health service card of the present invention (the smart card) . The present invention assumes that client 10 has already qualified and is insured by an insurance company 30, according to their normal underwriting standards. The smart card would normally be obtained by each client patient 10 insured by an insurance company 30 in the System 45.
At the point of obtaining the services by provider 20, e.g., by the doctor in the doctor's offices, the primary documentary evidence provided by client 10 to the provider 20 is in the form of the smart card, line 201. This smart card information can be entered into the provider's system by numerous ways, by entering the patient's I.D. number from the smart card or swiping the smart card through a magnetic card reader and is communicated to the System 45, line 202. The provider 20 receives a confirmation of the eligibility of client 10, based on information sent and received back from the insurance company 30 along with an authorization from the insurance company 30, lines 203. The insurance company 30 provides the System 45 with a daily list of delinquent accounts, line 204 - if the card is not identified as delinquent, then the provider 20 receives an authorization to provide services according to an agreed upon fee schedule.
The credit card processor 40 will also determine the amount of retail credit available in the client's account, line 205, and advises the System accordingly.
The patient's/client's benefits, as provided by the insurance company are reviewed prior to providing a confirmation of eligibility by the insurance company which are subject to an agreed upon fee schedule with the client. One of the benefits at this particular step is the minimal amount of time taken between a request by provider 20 to verify eligibility and a return response from the System 45 confirming the eligibility of client 10.
In Fig. 2, when services are rendered to the client, the provider submits a claim, line 206, which is processed by the System for immediate adjudication.
If the submitted fees agree to the CPT codes and the procedure is within the plan rules, then the claim is "approved" .
At this point in time the System communicates with the insurance company's records of the client to determine the adjudication of the provider's submitted claim. As an example, if during the visit, two procedures were performed, two codes would be entered with two corresponding fee amounts. Assuming the first procedure,
(a) was $60 and the second procedure was $100, a total claim request by the provider to the System would have been $160. Concerning the adjudication of the amount of $160, several scenarios can take place. A few would include as follows: (a) the client's deductibles had not been met, in which case the insurance company's data would indicate to the System that the insurance company is not obligated to make the payment and the provider would be immediately advised in order for the provider to collect the amount. In the prior art, the provider would be at risk for non-payment; however, under the present System, the smart card will also be a credit card for a retail line of credit for the client so that the provider can at the point of service, charge to the client, the appropriate amount for the services rendered. Thereafter, a credit card advice would be printed at the provider's office so that the client can sign the charge slip and accept the charges. Thereafter, the client can either pay the charge immediately to its credit card processor or finance according to the terms of the retail credit card agreement. (b) It is possible that the entire amount of the submitted claim charge would be paid from the insurance company' s account and the System would advise the provider that the claim has been settled in full by the insurance company and payment effected by the credit card processor on behalf of the insurance company. A confirmation would be signed by the patient which would also show a zero balance. The insurance company and the credit card processor would settle between themselves the
amount of the charge. The provider would receive funds pursuant to the agreement with the credit card processor, typically within 24-48 hours, as is known and practiced in the art .
(c) Some charges will be settled by the insurance company and the remaining amount will be the responsibility of the client, in which case would represent a combination of the two previously described methods .
If the CPT codes for services rendered not match, the provider must submit the claim to the insurance company for manual adjudication.
The credit card processor 40 establishes a retail line of credit with the client 10 in line 208, in addition to the line of credit for insured health
services guaranteed by the insurance company 30. The credit card processor monitors the available line of retail credit for each client.
In addition, the System will determine the extent of retail credit available to any client based on the characteristics of the members/clients 10 belonging to a participating insurance policy of insurance company 30. This will be performed using risk profile analyses.
The present method allows for determining a profile based on the group of clients to be provided to the credit card processor in determining the amount of retail credit to be offered to the client and to each client within the insurance company's group. It is anticipated that these determinations may be made by providing the data in the present System of clients to the credit card processor so that the credit card processor can make determinations of credit limits for each group or subgroup of clients. It is further anticipated that in addition to providing healthcare services, that the data contained within the pool of clients as a potential pool of credit card users has value which can be offered for consideration to a credit card processor. In addition, as described above for using the retail line of credit in a provider's office, the client can also use the smart card for retail credit in any store that accepts retail credit cards. This opens the door to eliminate the client having multiple credit cards, multiple insurance cards, and multiple health I.D. cards used to buy prescription drugs, etc. (prescription drug cards, lab cards, and medical cards.) The insurance company 30 and credit card processor
40 agree to have their systems linked to the System 45. The insurance company and providers agree to use CPT codes, and agree upon fee schedules for services rendered under the policy. The insurance company authorizes the credit card processor via the System 45 to make a payment on their behalf for the services according to the patient's plan, lines 209. The insurance company, reimburses the credit card processor pursuant to agreed upon terms the amount the credit card processor paid the provider on its behalf. The credit card processor 40 pays provider 20, line 210, and would balance bill the client 10 for any expenses not covered by the insurance plan, if agreed upon at the settlement conference. The credit card processor benefits by having access to preferred credit card clients 10 that are actively at work for an employer of sufficient size and stability to qualify for insurance e.g. group insurance. There is a low credit risk, people generally will protect their health "safety net" and keep their credit in good standing.
The insurance company benefits by having the ability to lock providers into a fixed fee for service arrangement; and reduced claim administration, because of the ability to focus on claim management as opposed to claim processing.
Health care providers will benefit because of the immediate payment for services and reduced office administration. Policy holders will benefit because of the ability to manage personal health care expenses and the convenience of carrying only one card e.g. the smart card of the present invention.
The present System uses the worldwide computer network as its communication platform. The provider 20 must have a world wide communication network connection
(which presently usually requires a telephone line, a modem and a computer) in order to access the System 45.
The faster the modem and computer processor, the faster and better the communication which is fundamental to real time processing.
The System 45 will be its own Internet Service
Provider (ISP) . The System will also be an "Application
Software Provider" as well. The provider will not need to install the software on the provider's personal computer for example, but rather the provider will access the software as it is needed via the world wide communication network. The only data stored on the provider's computer is the connection utility which will be provided by the System.
At the provider's end, the System will run on any computer system that can make an internet connection, but is usually an IBM® compatible PC. An interface will be used to connect with the insurance and credit card systems.
As used herein the System 45 of the present invention is a combination of programs, data and processes focused on the electronic processing of health claims and the associated payments on behalf of all parties.
The objective of System 45 is to fully process the required transactions, so no further processing is required, this is, once the System has processed a claim, all of the involved parties must be satisfied in their requirements .
Claim adjudication under the present invention will be an automated process performed by the insurance company. An improvement in the present invention is that the insurance company will delegate the making of claim payments to the credit card processor thus relieving the insurance company from processing payments to the various providers and clients.
The System allows the patient and the doctor to agree and accept the method of financial settlement. The financial processing (payments, accounts payable and receivables) will be handled by the credit card processor utilizing its well documented expertise in efficiently processing large volumes of financial transactions. This relieves the doctor from follow-up with the client and/or the insurance company in order to collect their professional fees for services rendered.
The claim adjudication process is initiated when the provider submits the super bill to the insurance company. The insurance company reviews the super bill e.g. CPT codes, along with the particulars of the insured patient along with other additional information from the provider, including the provider's submitted fees in the claim. The insurance company makes a determination of the insurance company's liability and a determination of the patient's liability. If the patient has liability, e.g. the insurance company's policy for the insured patient does not cover in whole or in part the submitted claim e.g. deductibles, co-payments or uninsurable amounts, the System will then look to the availability of credit on the patient's smart card. After the claim is adjudicated the System 45 communicates information of the claim adjudication from the insurance company 30 and the credit card processor advising the provider 20 the following: that the claim is accepted; and that the insurance company owes X dollars and the patient owes Y dollars. In making the latter statement that the patient owes Y dollars the System 45 is representing to the provider 20 that the patient's smart card has available credit to settle the obligation of Y dollars.
The next stage is the "settling conference" or the Explanation of Benefits (EOB) between patient 10 and provider 20 whereby the patient and provider must agree on the claim adjudication set forth by the insurance company. There are 3 alternatives. First, the patient and provider agree on the amounts owed by the patient and the amount to be paid by the insurance company. In this event the provider notifies the System and the System in real-time mode advises both the insurance company and credit card processor that the patient and provider have accepted the adjudication. At that time, in real-time mode, the credit card processor effects payment of the amount of X dollars and the amount of Y dollars directly to the provider by normal credit card channels via the established credit card interchanges. Next, the insurance company reimburses the credit card processor the amount of X dollars owed by the insurance company. The patient will ultimately reimburse the credit card processor the amount of Y dollars, e.g. the patient's liability. The patient's liability will be charged to the patient's credit card, and paid as the patient desires and included on the patient's monthly statement for payment to the credit card processor. Though this transaction as heretofore described happens in real-time mode as it is well known in the present art, for example in the Visa® and MasterCard® credit card interchanges, delays of settlement (to the provider) of up to 48 hours are per standard operating procedures of retail credit card transactions. In the event at the time the claim is reviewed by the insurance company for a claim adjudication there is insufficient credit available on the patient's smart card, then the System will communicate with the provider and the patient in a "settlement conference" as heretofore described. However, in this latter situation, the discussions between the patient and the provider would relate to the reasons for the additional liability against the patient. In this "settlement conference," presumably the patient and the provider would resolve the differences in the additional liability by either the patient assuming the liability or settled through alternate means.
In the latter situation where there is not an acceptance by the patient and the provider, then a default process will be instituted whereby the claim is manually submitted by the provider directly to the insurance company as part of an established appeals process .
The System will involve five different players in four different physical locations, they are:
The client 10 (and its ID card in the form of a smart card) ; the medical facility, provider 20 (clinic, hospital, doctors, etc.); the insurance company 30; the credit card processor 40; and the System interface 45 as the coordination center between the parties.
The locations involved will be the medical facility (client and doctors) ; the insurance company; the credit card processor; and the System.
The System 45 will make possible that all the physical locations stay at least virtually connected and available as needed for the clinic and client to complete a transaction.
Due to the different nature of each location, and the time required to process a transaction, the System will be developed as an "asynchronous" system. That is, each step of the process will wait for the prior step to be completed before continuing with the next step, all of this under the automated control of the System.
In this scenario it is advantageous of the present invention that the System can process transactions that may take from seconds to whole hours to complete without failure. The System will save required information from each transaction to be able to justify the final outcome of the result to each party. These connectivity requirements make the worldwide computer network the preferred media for communication. The worldwide computer network can be as secure as required, more than regular credit card point of sale (POS) machines and it also provides the required flexibility and cost savings needed for the process of the volume of transactions anticipated to be handled by the System.
The System 45 will work on two separate sets of data, data created by the System while processing transactions and data that pre-exists in the System before a transaction can be processed.
Pre-existing data will contain: insurance data; credit data; System 45 tables to reflect the various agreements between the insurance companies and the credit card processor; other data used by the System 45 client software; and medical tables like CPT tables.
Transaction Data will include clinic created data, and System created data. The System interface 45 will have two sets of codes, a client code and a processing code. Client codes will be responsible to interact with the clinic/patient side, print the super bill and the final Explanation of Benefits (EOB) . The processing code will receive request for identification of the patient, submit request to insurance company, and submit request to credit card and reply to the clinic.
The System 45 is divided into two modules: a back office system, in the form of a worldwide computer network web site will act as the main communicator between the parties and a data repository dedicated to validate and route requests to the insurance company and the credit card processor.
The client programs, are the user interface used to read the credit card, create a super bill, submit data to and read data from the back office system, it will also interface with future physicians office management programs .
The System interfaces with databases stored in the claim administration system at the insurance company and the processing system at the credit card company. A unique client identification number" is stored on the magnetic stripe of the smart card. It is also embossed on the smart card. This ID number is used to access the data stored in the insurance company and claim system administrating systems of the credit card processor.
Some data may be temporarily stored in the System (range of policy numbers that are either enforce or lapsed, providers participating in the program, etc.), but the data originates at the insurance and credit card companies and it is their responsibility to update.
An interface 45i provides an electronic link that allows the System of the present invention to communicate in a compatible computer language to independent systems (the insurance company and credit card processor) . Each interface 45i is unique to the System of the present invention and the system that it connects. The interface is a program stored in a powerful personal computer that is physically connected, by hard wire to the insurance and credit card systems. It is connected to the System Internet Service Provider (ISP) via the world wide computer network.
As used herein, the concept of a super bill is a form which contains the entire patient and payer data before the medical service is provided. It also will contain information on the services rendered and the fees charged. This "form" becomes then an electronic form for the System 45, where it is sent partially to the insurance company for claim adjudication, becoming effectively a "claims form" from the insurance company point of view.
Once received from the insurance company, the super bill travels to the credit card processor in the form of "credit card charges." Once the credit card processor returns an approval code for the transaction (or a denial) , this reply is added to the electronic version of the super bill which is received by the System and returned back to the clinic. Once in the clinic, it becomes a paper form which is printed as a combined clinic form plus insurance company Explanation of Benefits (EOB) plus a credit card processor voucher. Once signed by the payer it is considered also as a bill and a receipt. A client will seek services from a Provider (Clinic or Hospital), upon arrival, the client will identify himself with a credit card issued/registered for the purpose .
The receptionist will swipe the card to read and transmit information to the System. Then the client program will communicate with the back office system, which will identify the smart card and provide the operator with an option list of patients under the card e.g. spouses or dependents. In order to reduce the risk of bad payments, the
System will compute a combined credit rating, which is a "weighted" code that will indicate the level of risk that the medical services provided might go unpaid. This credit rating is a combination of insurance coverage and credit line, the more insurance and more credit line, the lesser the risk or higher the credit rating will be.
The System 45 will also create a super bill form to be used by the Doctor as services are provided to the patient . The super bill generated by System 45 will reflect the contractual terms between insurance company 30 and patient 10 and between insurance company 30 and the provider 20. The agreement between the insurance company and the provider will reflect any preferred provider relationships that may exist, e.g. discounted fees for service arrangements, mode or means of payment. The relationship between the provider and the patient would be the terms of the insurance policy, e.g. co-payments, deductibles and exclusions. An electronic version of a super bill, number 408, is shown in Fig. 3 on the top half approximately, and the bottom half in Fig. 4. The super bill 31 has four columns A, B, C and D, each column having the CPT code 31, the description 32 and the fee 33 for that description and code. These codes, descriptions and fees would vary depending on the relationship between the insurance company and the provider and between the insurance company and the patient. The present System is able to take current information from those two relationships and provide, by printing a hard copy of a new super bill each time a patient starts a service at a provider. Thus, the super bill can reflect the then current terms between the parties in a real-time mode. With the super bill tailored to each individual patient, the provider's relationship has more accurate data and can be provided to the provider from the insurance company by the System. Specifically, the super bill will now contain current services provided by the provider that would be covered under the patient's current policy with the insurance company. This will allow, at the time of treatment, current information to both the provider and the patient to determine the desired services and allow the patient and provider to both know their economic risk as to whether those services are covered by the insurance policy. This is not to say that services may be withheld or violate any professional code of ethics of the provider. However, it will make available the economic information and current policy information concerning the providing of these services at the time of performing these services or shortly there before as opposed to a point in time long after the services have been performed as is practiced now in the prior art. Other information contained on the super bill is standard, e.g. the provider's name, the patient's name, etc. and is set forth in Fig. 3 and 4.
Fig. 5 is a screen, showing the super bill when it is being filled in after the doctor performed services. In this process column 34 in Fig. 5 shows how the individual line items for each description are selected on the computer electronically. The super bill can be and is preferably completed electronically on the computer screen so that it can be sent electronically from the provider to the insurance company through the System 45.
In the event it is not possible for the provider to send the super bill electronically, an 800 toll free long distance number will be available to verbally transmit the super bill to the System 45. Once the patient has been serviced, the super bill, now completed by the doctor, will be coded into the client program and submitted to the back office system for processing. The back office program will read the super bill form and create a "case" assigning a unique number, which will be returned to the client program to reference this
transaction.
The client program will receive a message saying that the request is being processed.
While the client program is notified that the transaction is being processed, the back office system will also communicate with the insurance company and submit a claim to the insurance company. The back office system waits for the answer from the insurance company which will provide the amounts accepted and covered under the client's insurance, including information on the insurability, deductibles, co-payments
etc . Once the back office system knows which portions of the super bill the insurance company will cover, the back office system will communicate with the credit card
processor for payments.
These payments will be divided into the following: Credit payable by the insurance company to the provider; Debit (receivable) to the insurance company to the credit card processor for the portion accepted under this claim. This debit portion will be billed by the credit card processor to the insurance company under the terms mutually agreed upon by the insurance company and credit processor. This is the portion covered by the insurance company, net of co-pay and deductible; and Debit to the client's credit card for the portion of the bill not covered by the insurance company, plus the amount applied to deductibles, plus the co-payments (if any) .
Once the insurance company and credit card processor transactions are processed, back office system will reply to the client program and the clinic with the results of the process in the form of an Explanation of Benefits (EOB) . This Explanation of Benefits (EOB) will include information on the charges to the client's credit card and if there is cash pending to be paid by the client. The client will sign the clinic's copy of the Explanation of Benefits (EOB) and will keep a copy for the client's personal records.
At the end of the month, the credit card processor will send a statement to the client and one to the insurance company of the transactions for that month. The log-in process, on the provider's computer begins typically with a provider (e.g., a doctor's office) , who will sign into the System interface on the world wide computer network at the System' s web site and clear the provider's password. If the identification is valid, the provider can continue with the process. The System interface will identify the provider from its local database of providers in the System. The System interface will display a working console menu at the provider's computer where all activity will be performed. This console screen Fig. 6 will provide the provider with two main options, first to select a patient 21, that is used when a new person walks into the clinic and, select a super bill 22, used when a patient has been serviced by the doctor and it's time to close and pay the bill.
When a new client, as used herein new client means new patient that day, walks into the provider's office, the provider will select the option "Select Patient", which in turn will display a screen to enter the patient data. As the patient's smart card is swiped or typed if the card is not available, the System will request the name of the payer and date of expiration of the card, name and date are used to validate the card. It can also use the address verification if needed.
A combined security code is created, by combining the client card security code with the provider security code. A request is submitted to the back office system to identify the patient. The data passed by the client program to the back office system in this process is: The provider name, the card number from the patient, and the new combined security code. The console user, the operator, will press "SUBMIT" and the request will go to the back office system for card validation and insurability.
The back office system will return a provider number to the client program for the card used. This provider number is defined and given by the credit card processor to the provider and will be stored in the back office system.
The back office system will also return to the client program one or more records containing information for the patient or patients under that smart card. The information returned will be: Insurance company ID, Policy Number, Certificate Number, Dependent Number, Relationship within the policy (Primary, Spouse, Child etc) , Payment risk (Combined between credit line and insurance coverage) , Patient Last Name, Patient First name, Patient Middle Initial, Patient social security number, and an Error code, if any. The client program will display the list of patients that are covered under the card used, see Fig. 10. The provider will create a new super bill using the selected patient. The System already requested from the back office system, the primary carrier, if the patient is insured by various carriers, and the order that the carriers will appear in the screen will be from the first to the last carrier. The System will determine which carrier has the priority. In the case a carrier that is not the primary and in the case the policy is in force, the System will not allow the selection of another policy. Also, if the primary carrier's policy is not in force, then the System will allow the use of another policy in the case order established in the back office system for that patient.
Once a patient has been selected, the working console screen Fig. 7 will display the patient's name 23 in the upper left of the screen. The menu options of the screen will change to reflect the valid options for a selected patient.
The provider will select the patient and a super bill format from a library of super bill templates residing in the client programs. Also the provider will mark this session as an "accident" or not, this information is required by the insurance company in order to process the claim. The super bill will contain the patient data and the choice of common CPT codes depending on the template. When a super bill is created from scratch, or when codes are added to it not in the template, that template can be saved for future use .
The customized super bill will be used by the doctor to record the medical services rendered.
Once the super bill has been created, the console screen shows two tabs with information for Patient Detail 51 and super bill Detail, see Fig. 7.
The patient detail tab shows the basic demographic data of the patient. It also carries the last visit date and next appointment. This is restricted to that particular provider only. The other option, is called Patient super bill 53 which if chosen, will display all of the super bills that client has with that clinic, current and past. This acts like a Patient historical information list.
If the Tab with super bill Detail 52 is pressed, the System will show current information of the recently created super bill .
The fields for Total incurred 54, Total Covered 55 and Case Number 56 are still empty, this is because a super bill has been created, but not completed and processed. At this point in the process, the normal option to take is to print the blank super bill which will be made available to the doctor to treat the Patient.
The newly created super bill is printed and is passed to the doctor to treat the patient. Two options exist, one to preview the super bill and the other is to obtain a printed copy of it .
The first part of the printed super bill 31, Fig. 3, is the header which includes information about the patient and the doctor. The second portion of the super bill, Fig. 4, the bottom of the super bill, contains space to be completed by the doctor, for the doctor's notes .
Once the patient has been treated or serviced, the super bill will be returned to the provider's operator for processing. The operator will select the option Select super bill 24. This will list all super bills for that clinic in the status "New", which are the ones pending to be completed and processed. Once the super bill is identified, the operator will press the button
Detail 25 to continue with the fill up and processing of it.
The operator, once having selected super bill, presses the option "Fill Up Super bill 54" to get into this screen. The operator will further select "new" case (the Default) and press "Detail" button, this will take the operator to a screen where the super bill will be completed for approval .
A clinic will have on-line access to all of the cases and the "Super bill's" used in the past, this effectively will become a patient's history record.
A new super bill will include a button "Fill Up Super bill" where the various codes (CPT) are selected depending on what treatment the doctor has performed. The operator will enter the various CPT codes and the client program will submit the super bill to the back office system for processing. The user can also save the template (Update it), so it can be used in the future.
New CPT codes not in the template, but used by the doctor, can be added by creating a code from the table of possible codes residing in the client program. A super bill cannot be modified by the provider after being submitted.
Once the super bill information is submitted for processing to the back office system, a case number is shown in the screen and a message stating that the super bill has been received by the System is displayed.
The "result" screen of a processed super bill is now completed by the System 45 as the client program will send to the back office System the following information: Provider Number (Clinic number from previous step) ; Smart Card Number; Social security number from the patient; Insurance company; Policy Number; Certificate Number; Dependent Number; and the combined security code. The back office system processes the super bill as follows: initially the transmitted information is validated. If there is an error the System will notify the client program about it. It will also validate that the smart card submitted is recognized as active and participating in the System 45. It will also get the credit rating code (low, medium, high) of the patient, validate that the insurance company is actively participating in the System 45. The back office system will open a case and return to the client program the "case" number. This case number will be used from here on to identify the process and it will appear in the user screen.
Each case will contain the following information: Provider Number; Policy Number; Certificate Number; Dependent Number; Insurance company; Card Number;
Creation date; and stale date (the later is used to close a case automatically by the back office system after a period of inactivity) .
Once a case is created by the back office system, the client program will use this "case" number to: First submit, one by one, the CPT codes and reference fees (Clinic Fee) .
For each code the client program will send to the back office system the case number the CPT Code, the amount (charged) incurred; and the combined security code. The back office system will add each line to the open case queue for later processing.
Second, the back office system will start processing of a case, the client program will submit a request with the case number and combined security code.
The back office system will process the case as follows : (Error codes will be issued in each of the following steps if the back office system finds that some information is not acceptable); validate request; read pending cases queue to see if the case exists; validate that the case has not expired; validate that the case has not been already processed; validate that the Provider ID assigned by the System to the clinic exists and is valid; validate that the merchant number assigned by the credit card processor to the clinic exist; send a "Not Covered" message for each CPT not covered or recognized by the back office system under this policy contract, and prepare a record for each CPT recognized by the insurance contract as: get CPT code from open case queue; get amount incurred from open case; get amount covered from insurance company table (residing in the back office system) ; get co-payment rules from insurance company 30 table and set co-payment to zero; get deductible indicator from insurance company table and set DEDUCTIBLE to zero; set to zero REFUNDED amount; set to spaces
MESSAGE from insurance company; and set to zero the error code .
The following steps recreate a theoretical insurance company and a theoretical Credit card processor. These steps will vary as the real interfaces with real claims and credit systems are implemented.
Set the COVERED amounts as the minimum between the
INCURRED amount and the amount covered by the insurance company for this CPT. Compute the deductible as the minimum between the
Family Deductible, Individual Deductible and the Amount covered creating the DEDUCTIBLE amount.
Compute the amount PAYABLE as the COVERED -
DEDUCTIBLE amount . Create a claim history record containing: Case
Number; Policy Number; Certificate Number; Dependent
Number; CPT code; Date incurred; Date paid; Amount
Incurred; Amount Covered; Deductible; co-pay amount; and refunded amount . Update Dependent claim history record as: add the
amount incurred to the total claimed; add the amount
covered to total paid; add deductible paid to total
deductible; add the refunded amount to refund total; and
add to co-payment total the amount of co-pay.
Update the certificate record with: add to
deductible the amount of deductible; and compute the
number of family deductibles paid (as deductible/annual
deductible) .
Update pending case CPT record with: payable amount;
co-pay amount; deductible amount; refund amount; message
with "OK..."; and accepted flag with (0=Yes, has been
accepted by insurance company) .
Once each CPT code has been processed, the case will
continue processing to produce the charges to the Credit
Card of the insurance company and the Client as needed.
Charge the Insurance company for the amount refunded
(covered less deductible and co pay) . Skip if the
Insurance company has recognized no refund.
Create charge to the insurance company, read
insurance company account with credit card processor,
create history record of the request, and find insurance
company credit limit. If the credit limit is not enough to cover the claim, the System will record the reject in the back office system database.
If the credit limit is sufficient to cover the claim, the process will record the approval code from the credit card processor in the back office system database, create accounts receivable in the back office system database, subtract the credit card processor commission from the transaction, and create a payable to the clinic net of commission charged by the credit card processor.
Charge the client card for the amount not covered by the insurance, including the co-pay and deductible amounts as follows: Create a charge to the client; read client credit limit; create history record of the request in the back office system database; find if the credit limit of the client is enough to cover its portion of the bill; if the credit line is not enough to cover the bill, record the reject in the back office system database; If the credit line is sufficient to cover the bill; record the approval code from the Credit card processor in the back office system database; Create account receivable in the back office system; Subtract the Credit card processor commission from the transaction total; Create a payable to the Provider (Clinic) net of the Credit card processor commission; update the pending "case" as fully processed adding a processed date to the "case" .
After the "case" is processed, the client program, will request information in a separate menu where all submitted cases has been posted.
The operator will then select the case and request from back office system a final Explanation of Benefits (EOB) which will be printed by the client program and delivered to the provider to be signed by the client/patient. A refresh button will create a status of whether the Claim has been adjusted and the case processed.
The Explanation of Benefits (EOB) will contain: the insurance company credit card number and approval code (if charged) ; the client credit card number and approval code (if charged) ; the total charges by the clinic; the amount covered by insurance company; the amount charged to client card (if approved) ; the amount charged to the insurance company card (If approved) ; cash due by client (if any) ; balance due by insurance company (if insurance company credit was rejected); (case) number; provider ID (clinic) ; policy number; certificate number; dependent number; insurance company; CASE open date; CASE expire date; and insurance company name. Also, in the EOB will be an informational line for each treatment: CPT code; amount incurred; amount covered; amount of deductible; amount of co-pay; amount refunded; insurance company process message; and accept/deny code as set by the insurance company.
Additional items in the EOB will be social security of patient; provider name (clinic name); patient last name; patient first name; patient middle initial; credit card processor; credit card processor name; payer (card owner) social security; credit rating; card relationship
(primary or additional card like spouse) ; payer last name; payer first name; and payer middle initial.
With above-mentioned information, the client program will print a final combined Explanation of Benefits (EOB) and receipt. A copy will be printed for the client and a copy for the clinic (to be signed by the client) . The EOB will have two main sections, one for the headings and detail CPT codes, and the second with the payment data. The flow of the System is generally as follows: 1. Get request of information from clinic, process the request and return answer. a. Validate provider exists in System from participating providers list (provider) . 1) Validate the card submitted against the list of participating cards (option will be to process charge to validate card) .
2) Obtain the Merchant Number for the
Clinic/Card association. b. Get the combined Dependants that are registered for this card. c. Obtain the Credit Rating.
2. Update the System (Clinic) Patient Database, or create if it is new. Do the same if the payer is new, create Payer_Account and Payer_Card. a. Validate existence of Patient. If it is new, create, if not modify if required.
1) Obtain the Patient's identification number.
2) Validate that the Patient's name is
correctly registered and update if there is a difference.
b. Validate existence of Payer. If it is
new, create, if not modify if required.
1) Create a new Payer's Account record.
2) Create a new Payer's identification
number .
3) Create the Payer's Card record.
4) Obtain the Payer's identification number. 5) Validate that the Payer's Card "Name" and "Expire Date" are correctly registered and update if there is a difference.
3. Create a new super bill . a. Obtain the data about the Patient, the
Payer and the Clinic information to create a super bill. b. Insert the data to create a super bill. c. Set the super bill status to "N" New. d. Obtain the super bill number for the new super bill created.
4. Generate a "Super Bill Detail Form" for printing and processing. a. Obtain the Super Bill Template Code. b. Insert the CPT Codes and Headings, in case they have not been already inserted.
5. Update Super Bill Detail Form. a. Obtain the Super Bill Template Code. b. Insert new CPT Codes. c . Insert new Headings . 6. Update super bill from queue after process has been completed, submit case number. a. Update the Super Bill Detail from super bill processing queue. b. Update the super bill credit card charges FOR Payer (D) . c . Update the Payer account for new balance due (if Credit Card Processor transaction rejected) . d. Update the super bill credit card charges FOR INSCO (D) . e. Update the payer account for new insurance company balance due (if transaction rejected) . f . Update the super bill FROM THE OPEN_CASE (B) . g. Update the super bill from summary of super bill detail form (E) . h. Change the super bill status to "R" Received.
7. Present the super bill and its Detail (if present) for printing and update the "Super Bill Status" to (P)rinted, if it applies. a. Present the super bill and its Detail Form for printing. b. Update the "Super Bill Status" if it is currently (R)ecieved, to (P)rinted. c. Print a super bill and Explanation of
Benefit (EOB) .
8. Update the "Selected" status of a "Super Bill Detail Form Element" to " (T) rue" . a. Verify the existence of this super bill detail from element and retrieve its abstract key. 9. Get request to open a new case for processing (step 1 of 3) . a. Validate provider exists in the System participating providers list (provider) . b. Validate the card submitted against the list of participating cards (option will be to process a System Fee charge to validate card) . c. Validate insurance company is participating in the System Plan. Open a new Case and return case number to clinic. d. Open a new "Case" and return Case number to the System.
10. Add CPT plus reference fees from client to case before processing by insurance company (step 2 of 3) . a. Insert into super bill queue the CPT's and
FEE'S.
11. Submit case for processing to insurance company and charges to Credit Cards (step 3 of 3) . a. Send case for processing to insurance company.
1) Insurance company processing.
2) Get provider name. b. Get merchant number for this credit card. c. Eliminate the not covered CPT's and add the charge to client card. d. Process CPT's that exist in insurance company plan. e. Get the lowest between the client reference fee and the Insurance Company CPT payable amount . f. Compute Deductible accumulation to date.
1) If no deductible apply (CPT code) , then skip.
2) Knowing that this CPT is prone to
deductible, the pending deductible for this dependent is computed. g. Find if there is a co-pay for the refund amount as flat $ amount . h. Accumulate charges payable by the insurance company.
1) Update Dependent record for statistics .
2) Update the super bill_queue of
process with all of the computed data.
i. Process required charges and credits for
clinic, insurance company and Client.
1) Charges to insurance company for amounts refunded (EOB) .
2) Submit charges to credit card
processing center for approval. j. Process insurance charge.
1) Find available credit line.
2) Approval number. k. Charges to Client for amounts not covered by insurance company.
1) Submit charges to credit card processing center for approval.
2) Find available credit line.
3) Approval number.
1. Update Case as processed.
12. Obtain a list of super bill by super bill_status and clinic_ID. a. Obtain the Super Bill Template Code.
13. Obtain a list of super bill for specific Patient a. Obtain Super List by patient_ak, clinic_id and super bill_status.
14. Obtain the information about Patient and a super bill detail by a specific super bill number. 15. Obtain a medical procedures for a specific super bill .
16. Obtain the detail for the capture of specific super bill .
17. Obtain a header for the capture of detail for specific super bill. 18. Retrieve the list of super bill Template for a specific clinic.
19. Retrieve parameters for a specific clinic.
20. Update a Case number of super bill when the detail is being created.
21. Update the Status of super bill when the detail has been created and submitted in the capture (filled) of super bill .
Conforming to the provisions of the patent statutes, applicant has provided an explanation of the principle, preferred construction and mode of operation of this invention and has illustrated and described what is now considered to be its best embodiment. It is understood, however, that within the scope of the claimed subject matter that follows, the invention may be practiced otherwise than as specifically illustrated and described.

Claims

What is claimed is:
1. A method for effectuating payment of a service for the benefit of a first party, performed by a second party and facilitated by a third party, comprising: a. a first party requesting a service from a second party, b. a smart card relating to said first party having information about said first party's relationship with said second party; c. said second party communicating information from said first party' s smart card to a third party to verify eligibility of said first party, d. said third party confirming eligibility of said first party in a real-time mode and providing a predetermined fee schedule between said third party and said second party for services for said first party, e. said second party submitting a claim, based on services for said first party, to said third party, f . comparing said submitted claim to said predetermined fee schedules of said third party and information concerning said first party' s relationship with said third party, and g. adjudicating said claim in a real-time mode and settling said claim by said third party authorizing a transfer of funds to said second party when said compared information is within guidelines established by said third party.
2. A method for effectuating payment of a service as set forth in claim 1 above further comprising: a. said third party and said first party have prearranged for approved payments for said services to be effected by a payment card processor, b. said transfer of funds is for less than the full amount of said claim submitted by said second party, and c. said first party elects to charge said balance of said submitted claim to said payment card processor.
3. A method for effectuating payment of a service as set forth in claim 1 above further comprising: a. said transfer of funds is for less than the full amount of said submitted by said second party, and b. said first party elects to pay said second party directly the said balance of said submitted claim.
4. A method for effectuating payment of a service as set forth in claim 1 above further comprising: said third party has a library of super bills which incorporate said fee schedule, descriptive terminology, and identifying codes for reporting for said services, and said super bills are in the form of templates which are updated in real-time by said third party reflecting current relationships between said second party and said third party.
5. A method for effectuating payment of a service as set forth in claim 4 above wherein said second party selects one of said super bill templates from said library and records services performed for said first party on said super bill to be forwarded to said third party for processing .
6. A method for effectuating payment of a service as set forth in claim 5 above wherein said smart card information and information on said super bill is forwarded to said third party from said second party by means of a world wide computer network.
7. A method for effectuating payment of a service as set forth in claim 2 above wherein said third party provides said payment card processor a delinquency report of information about a group of one or more of said first parties that are not eligible for said second party's services .
8. A method for effectuating payment of a service for the benefit of a first party, performed by a second party and facilitated a third party comprising the steps of: a. receiving a request from a first party to perform a service by a second party for said first party; b. a smart card relating to said first party having information about said first party' s relationship with said second party; c. said second party communicating information from said first party's smart card to a third party to verify eligibility of said first party; d. said third party verifying said information received from said first party's smart card, and providing an authorization to said second party to perform said second party's services according to said third party's obligations to said first party; and e. said third party authorizing a transfer of funds to said second party for services performed and billing said first party for matters not covered by said third party's obligations to said first party, relieving said second party from further follow-up with either said first party or said second party to collect said second party's fees for said service performed for said first party.
9. An apparatus for facilitating payment for services of a first party, performed by a second party and facilitated by a third party comprising: a. an internet service provider receiving a request to verify eligibility to perform services on a first party, from a second party; b. a smart card relating to said first party having information about said first party's relationship with a third party; c. means for communicating information about said first party from said first party's smart card to said internet service provider; d. said third party verifying in real-time said information received from said first party's smart card and providing a means for said second party to document said second party's services according to said third party's obligations to said first party; e. means for said third party to authorize payment in real-time to said second party for services performed; and f . means for charging said first party for matters not covered by said third party's obligations to said first party.
PCT/US2000/019053 1999-07-13 2000-07-13 Method and apparatus for settling claims between health care providers and third party payers using a smart card id card WO2001004821A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU59318/00A AU5931800A (en) 1999-07-13 2000-07-13 Method and apparatus for settling claims between health care providers and thirdparty payers using a smart card id card

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US14344899P 1999-07-13 1999-07-13
US60/143,448 1999-07-13
US16800099P 1999-11-30 1999-11-30
US60/168,000 1999-11-30

Publications (1)

Publication Number Publication Date
WO2001004821A1 true WO2001004821A1 (en) 2001-01-18

Family

ID=26841038

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/019053 WO2001004821A1 (en) 1999-07-13 2000-07-13 Method and apparatus for settling claims between health care providers and third party payers using a smart card id card

Country Status (2)

Country Link
AU (1) AU5931800A (en)
WO (1) WO2001004821A1 (en)

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6820059B2 (en) * 2003-04-08 2004-11-16 Richard Glee Wood Method for reducing fraud in government benefit programs using a smart card
US6826535B2 (en) * 2003-04-08 2004-11-30 Richard Glee Wood Method for reducing fraud in healthcare programs using a smart card
US6873959B2 (en) * 2002-11-25 2005-03-29 Richard Glee Wood Method for accelerated provision of funds for social services directly to an individual using a smart card
US7039593B2 (en) * 2002-06-20 2006-05-02 Robert David Sager Payment convergence system and method
US7058585B1 (en) * 2003-05-05 2006-06-06 Richard Glee Wood Cardless method for reducing fraud in healthcare programs
US7783505B2 (en) 2003-12-30 2010-08-24 Hartford Fire Insurance Company System and method for computerized insurance rating
US7921123B2 (en) * 2001-02-20 2011-04-05 Hartford Fire Insurance Company Method and system for processing physician claims over a network
US8090599B2 (en) 2003-12-30 2012-01-03 Hartford Fire Insurance Company Method and system for computerized insurance underwriting
US8346665B2 (en) 2010-04-13 2013-01-01 Enservio, Inc. Dual-activation financial products
US8762278B2 (en) 2010-04-13 2014-06-24 Enservio, Inc. Dual-activation financial products
US8930216B1 (en) 2004-09-01 2015-01-06 Search America, Inc. Method and apparatus for assessing credit for healthcare patients
US8930262B1 (en) 2010-11-02 2015-01-06 Experian Technology Ltd. Systems and methods of assisted strategy design
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
US9251541B2 (en) 2007-05-25 2016-02-02 Experian Information Solutions, Inc. System and method for automated detection of never-pay data sets
US9256904B1 (en) 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US9558519B1 (en) 2011-04-29 2017-01-31 Consumerinfo.Com, Inc. Exposing reporting cycle information
US9563916B1 (en) 2006-10-05 2017-02-07 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US9697263B1 (en) 2013-03-04 2017-07-04 Experian Information Solutions, Inc. Consumer data request fulfillment system
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
US10735183B1 (en) 2017-06-30 2020-08-04 Experian Information Solutions, Inc. Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network
US10757154B1 (en) 2015-11-24 2020-08-25 Experian Information Solutions, Inc. Real-time event-based notification system
US10909617B2 (en) 2010-03-24 2021-02-02 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
US11157997B2 (en) 2006-03-10 2021-10-26 Experian Information Solutions, Inc. Systems and methods for analyzing data
US11227001B2 (en) 2017-01-31 2022-01-18 Experian Information Solutions, Inc. Massive scale heterogeneous data ingestion and user resolution
US11620403B2 (en) 2019-01-11 2023-04-04 Experian Information Solutions, Inc. Systems and methods for secure data aggregation and computation
US11748818B1 (en) * 2018-09-18 2023-09-05 Myndshft Technologies, Inc. System and method for healthcare revenue cycle management
US11887175B2 (en) 2006-08-31 2024-01-30 Cpl Assets, Llc Automatically determining a personalized set of programs or products including an interactive graphical user interface

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4491725A (en) * 1982-09-29 1985-01-01 Pritchard Lawrence E Medical insurance verification and processing system
US4858121A (en) * 1986-12-12 1989-08-15 Medical Payment Systems, Incorporated Medical payment system
US5276311A (en) * 1989-03-01 1994-01-04 Hartmut Hennige Method and device for simplifying the use of a plurality of credit cards, or the like
US5301105A (en) * 1991-04-08 1994-04-05 Desmond D. Cummings All care health management system
US5590038A (en) * 1994-06-20 1996-12-31 Pitroda; Satyan G. Universal electronic transaction card including receipt storage and system and methods of conducting electronic transactions
US5805676A (en) * 1995-05-19 1998-09-08 Pcpi Phone, Inc. Telephone/transaction entry device and system for entering transaction data into databases

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4491725A (en) * 1982-09-29 1985-01-01 Pritchard Lawrence E Medical insurance verification and processing system
US4858121A (en) * 1986-12-12 1989-08-15 Medical Payment Systems, Incorporated Medical payment system
US5276311A (en) * 1989-03-01 1994-01-04 Hartmut Hennige Method and device for simplifying the use of a plurality of credit cards, or the like
US5301105A (en) * 1991-04-08 1994-04-05 Desmond D. Cummings All care health management system
US5590038A (en) * 1994-06-20 1996-12-31 Pitroda; Satyan G. Universal electronic transaction card including receipt storage and system and methods of conducting electronic transactions
US5884271A (en) * 1994-06-20 1999-03-16 Pitroda; Satyan G. Device, system and methods of conducting paperless transactions
US5805676A (en) * 1995-05-19 1998-09-08 Pcpi Phone, Inc. Telephone/transaction entry device and system for entering transaction data into databases
US5987103A (en) * 1995-05-19 1999-11-16 Cyberfone Technologies, Inc. Telephone/transaction entry device and system for entering transaction data into databases

Cited By (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8799313B2 (en) 2001-02-20 2014-08-05 Hartford Fire Insurance Company Method and system for processing medical provider claim data
US7921123B2 (en) * 2001-02-20 2011-04-05 Hartford Fire Insurance Company Method and system for processing physician claims over a network
US7039593B2 (en) * 2002-06-20 2006-05-02 Robert David Sager Payment convergence system and method
US6873959B2 (en) * 2002-11-25 2005-03-29 Richard Glee Wood Method for accelerated provision of funds for social services directly to an individual using a smart card
US6820059B2 (en) * 2003-04-08 2004-11-16 Richard Glee Wood Method for reducing fraud in government benefit programs using a smart card
US6826535B2 (en) * 2003-04-08 2004-11-30 Richard Glee Wood Method for reducing fraud in healthcare programs using a smart card
US7047204B1 (en) * 2003-04-08 2006-05-16 Richard Glee Wood Method for reducing fraud in government programs
US7058585B1 (en) * 2003-05-05 2006-06-06 Richard Glee Wood Cardless method for reducing fraud in healthcare programs
US7783505B2 (en) 2003-12-30 2010-08-24 Hartford Fire Insurance Company System and method for computerized insurance rating
US10650459B2 (en) 2003-12-30 2020-05-12 Hartford Fire Insurance Company Computer system and method for management of user interface data
US8090599B2 (en) 2003-12-30 2012-01-03 Hartford Fire Insurance Company Method and system for computerized insurance underwriting
US8930216B1 (en) 2004-09-01 2015-01-06 Search America, Inc. Method and apparatus for assessing credit for healthcare patients
US11157997B2 (en) 2006-03-10 2021-10-26 Experian Information Solutions, Inc. Systems and methods for analyzing data
US11887175B2 (en) 2006-08-31 2024-01-30 Cpl Assets, Llc Automatically determining a personalized set of programs or products including an interactive graphical user interface
US10963961B1 (en) 2006-10-05 2021-03-30 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US11631129B1 (en) 2006-10-05 2023-04-18 Experian Information Solutions, Inc System and method for generating a finance attribute from tradeline data
US9563916B1 (en) 2006-10-05 2017-02-07 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US10121194B1 (en) 2006-10-05 2018-11-06 Experian Information Solutions, Inc. System and method for generating a finance attribute from tradeline data
US9251541B2 (en) 2007-05-25 2016-02-02 Experian Information Solutions, Inc. System and method for automated detection of never-pay data sets
US9256904B1 (en) 2008-08-14 2016-02-09 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US9489694B2 (en) 2008-08-14 2016-11-08 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US11004147B1 (en) 2008-08-14 2021-05-11 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US10650448B1 (en) 2008-08-14 2020-05-12 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US9792648B1 (en) 2008-08-14 2017-10-17 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US10115155B1 (en) 2008-08-14 2018-10-30 Experian Information Solution, Inc. Multi-bureau credit file freeze and unfreeze
US11636540B1 (en) 2008-08-14 2023-04-25 Experian Information Solutions, Inc. Multi-bureau credit file freeze and unfreeze
US10909617B2 (en) 2010-03-24 2021-02-02 Consumerinfo.Com, Inc. Indirect monitoring and reporting of a user's credit data
US8762278B2 (en) 2010-04-13 2014-06-24 Enservio, Inc. Dual-activation financial products
US8346665B2 (en) 2010-04-13 2013-01-01 Enservio, Inc. Dual-activation financial products
US8694432B2 (en) 2010-04-13 2014-04-08 Enservio, Inc. Dual-activation financial products
US8930262B1 (en) 2010-11-02 2015-01-06 Experian Technology Ltd. Systems and methods of assisted strategy design
US10417704B2 (en) 2010-11-02 2019-09-17 Experian Technology Ltd. Systems and methods of assisted strategy design
US9684905B1 (en) 2010-11-22 2017-06-20 Experian Information Solutions, Inc. Systems and methods for data verification
US9147042B1 (en) 2010-11-22 2015-09-29 Experian Information Solutions, Inc. Systems and methods for data verification
US11861691B1 (en) 2011-04-29 2024-01-02 Consumerinfo.Com, Inc. Exposing reporting cycle information
US9558519B1 (en) 2011-04-29 2017-01-31 Consumerinfo.Com, Inc. Exposing reporting cycle information
US10255598B1 (en) 2012-12-06 2019-04-09 Consumerinfo.Com, Inc. Credit card account data extraction
US9697263B1 (en) 2013-03-04 2017-07-04 Experian Information Solutions, Inc. Consumer data request fulfillment system
US11159593B1 (en) 2015-11-24 2021-10-26 Experian Information Solutions, Inc. Real-time event-based notification system
US11729230B1 (en) 2015-11-24 2023-08-15 Experian Information Solutions, Inc. Real-time event-based notification system
US10757154B1 (en) 2015-11-24 2020-08-25 Experian Information Solutions, Inc. Real-time event-based notification system
US11227001B2 (en) 2017-01-31 2022-01-18 Experian Information Solutions, Inc. Massive scale heterogeneous data ingestion and user resolution
US11681733B2 (en) 2017-01-31 2023-06-20 Experian Information Solutions, Inc. Massive scale heterogeneous data ingestion and user resolution
US11652607B1 (en) 2017-06-30 2023-05-16 Experian Information Solutions, Inc. Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network
US10735183B1 (en) 2017-06-30 2020-08-04 Experian Information Solutions, Inc. Symmetric encryption for private smart contracts among multiple parties in a private peer-to-peer network
US11748818B1 (en) * 2018-09-18 2023-09-05 Myndshft Technologies, Inc. System and method for healthcare revenue cycle management
US11620403B2 (en) 2019-01-11 2023-04-04 Experian Information Solutions, Inc. Systems and methods for secure data aggregation and computation

Also Published As

Publication number Publication date
AU5931800A (en) 2001-01-30

Similar Documents

Publication Publication Date Title
US20050033604A1 (en) Method and apparatus for settling claims between health care providers and third party payers
US10311207B2 (en) Healthcare system and method for right-time claims adjudication and payment
US6012035A (en) System and method for supporting delivery of health care
WO2001004821A1 (en) Method and apparatus for settling claims between health care providers and third party payers using a smart card id card
US7949580B1 (en) Point of service third party financial management vehicle for the healthcare industry
US7743979B2 (en) Method and system for credit card reimbursements for health care transactions
US10417627B2 (en) Healthcare debit card linked to healthcare-related and non-healthcare-related financial accounts
US20140304010A1 (en) Healthcare system and method for real-time claims adjudication and payment
US7197468B1 (en) Method and system for processing transactions involving accounts for reimbursing medical expenses or patient responsible balances with multiple transaction substantiation modes
US7895054B2 (en) Pharmacy personal care account
US20130035964A1 (en) System and method for data processing for term life insurance policies issued before comprehensive underwriting
US20050033609A1 (en) Healthcare system integrated with a healthcare transaction processor, and method for providing healthcare transaction processing services
US20070033070A1 (en) System and method for collecting payments from service recipients
US20030187695A1 (en) ACSAS (automated claims settlement acceleration system)
US20080010096A1 (en) Determination of healthcare coverage using a payment account
US8571897B2 (en) System and method for administering insurance policies issued before comprehensive underwriting
US20040172312A1 (en) Method, system and storage medium for facilitating multi-party transactions
US8639536B2 (en) System and method for application processing and policy administration for insurance policies issued before comprehensive underwriting
US20180018647A1 (en) Method and system for managing consumer-directed accounts
US7529700B1 (en) Single-source multi-conduit apparatuses and methods for adjudicating pretax expenses
US20180218348A1 (en) Point of service third party financial management vehicle for the healthcare industry
US8265956B2 (en) Pharmacy personal care account
JP2004252958A (en) System and method for payment of coinsurance amount in medical insurance such as health insurance
MXPA00008388A (en) Point of service third party financial management vehicle for the healthcare industry

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU BB BR CA JP LC NZ SG TT

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP