US20140297304A1 - Determination of healthcare coverage using a payment account - Google Patents
Determination of healthcare coverage using a payment account Download PDFInfo
- Publication number
- US20140297304A1 US20140297304A1 US14/231,115 US201414231115A US2014297304A1 US 20140297304 A1 US20140297304 A1 US 20140297304A1 US 201414231115 A US201414231115 A US 201414231115A US 2014297304 A1 US2014297304 A1 US 2014297304A1
- Authority
- US
- United States
- Prior art keywords
- healthcare
- patient
- insured
- account
- insurance
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G06F19/328—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/405—Establishing or using transaction specific rules
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
Definitions
- ID cards which contain information such as patient name, employer plan number, type of insurance coverage, and applicable co-pay amounts. These ID cards are useful to healthcare providers such as doctors.
- ID cards are useful, they do not convey information regarding the current status of insurance coverage. For example, the cardholder may no longer be employed by the company that originally provided insurance coverage, so that the cardholder's insurance coverage may no longer be valid. To deal with this issue, healthcare providers use different means to check the current eligibility status of patients.
- Some providers fax and/or make telephone calls to a customer service center operated by the cardholder's insurance carrier to determine if the cardholder is eligible for a particular type of healthcare service. Such methods, however, may be time consuming for the provider's office staff and are expensive for insurance carriers.
- POS terminals require either a dedicated POS terminal or separate connections to the eligibility service provider.
- POS terminals require either a dedicated POS terminal or separate connections to the eligibility service provider.
- Such systems require the use of specialized POS terminals and specialized connections between the service provider and the carrier. Since specialized equipment is required, widespread acceptance of such systems has not been achieved.
- Some companies e.g., United Health Group and MasterCard have developed electronic eligibility verification using a POS terminal and a payment authorization transaction over an existing payment network, where the transaction amount is used to equate to a particular service type (e.g., $0.01 is an office visit).
- This approach has created problems for the provider's office and the provider's financial institution, because these transactions are indistinguishable from a true payment transaction and may be inadvertently processed as real payment transactions.
- Some healthcare clearing houses e.g.; WebMD
- insurance companies have developed Internet-based systems to permit provider offices to access eligibility information electronically, but this typically requires relatively expensive PC equipment and PC-trained office staff. As noted above, if specialized equipment is required, widespread acceptance is unlikely.
- HIPAA Health Insurance Portability and Accountability Act
- EDI electronic data interchange
- HIPAA also defines rules to ensure that all medical records, medical billing, and patient accounts meet certain consistent standards with regard to documentation, handling and privacy. Any healthcare provider that electronically stores, processes or transmits medical records is required to be fully HIPAA compliant as of April 2006.
- the patient data is for the insured rather than an imposter. Fraudulent presentation of insurance credentials is becoming more and more of an issue. It would be useful to verify the holder of the card is the actual person entitled to insurance coverage. Similarly, it would be useful to ensure that the insurance card itself is valid.
- Implementations are directed to facilitating communication in a healthcare environment.
- One implementation is directed to a method comprising: receiving patient information at a POS terminal operated by a healthcare provider; creating a non-financial authorization request message which relates to healthcare using payment card and patient information; sending the authorization request message to an acquirer processor, wherein the acquirer processor sends the authorization request message to a transaction processing system such as a payment processing system, and wherein the authorization request message is evaluated (e.g., by an insurance carrier) in view of information from a healthcare processor; and receiving a response message in response to the authorization request message.
- Another implementation is directed to a computer readable medium comprising: code for receiving patient information at a terminal operated by a healthcare provider; code for creating a non-financial authorization request message which relates to healthcare using the patient information; code for sending the authorization request message to an acquirer processor, wherein the acquirer processor sends the authorization request message to a transaction processing system, and wherein the authorization request message is evaluated (e.g., by an insurance carrier) in view of information from a healthcare processor or an issuer processor; and code for receiving a response message in response to the authorization request message.
- Another implementation is directed to a method comprising: receiving patient information comprising a patient identification number at a terminal operated by a healthcare provider, wherein the patient information is stored in a portable consumer device in the form of a card; creating a non-financial authorization request message, which relates to healthcare using the patient information, wherein creating the authorization request message comprises adding data to a data field to indicate that the authorization request message relates to a non-financial transaction; sending the authorization request message to an acquirer processor, wherein the acquirer processor sends the authorization request message to a transaction processing system, an issuer processor, and (optionally) then a healthcare processor; and receiving a response message from the healthcare processor, via the issuer processor, the transaction processing system, and the acquirer processor.
- a transmission addressed to a payment processing system is formed.
- the transmission may include an identifier of an account, associated with an insured, within the payment processing system (e.g., a Flexible Spending Account); a description of a healthcare related commodity (e.g., a good and/or service) for rendering to the patient deriving healthcare insurance through the insured; and a request for a specification of financial responsibility of the insured for the described said healthcare related commodity (e.g., inquiry for data regarding the patient's insurance coverage eligibility and/or the monetary responsibility value of the insured for healthcare related commodity rendered to a patient).
- a healthcare provider such as a doctor or a pharmacy, may render the healthcare related commodity.
- a response to the request may be received from the addressed payment processing system.
- the reply may include the requested specification of financial responsibility.
- a first transmission addressed to a payment processing system is received, the first transmission including: an identifier of an account, associated with an insured, within the payment processing system; a description of a healthcare related commodity for rendering to a patient deriving healthcare insurance through the insured; and a request for a specification of financial responsibility of the insured for the described said healthcare related commodity.
- An insurance account identifier is determined and is based at least in part on the identifier of the account, wherein the insurance account identifier is associated with both the insured and the insurance carrier of the insured.
- a second transmission addressed to the insurance carrier is formed. The second transmission may include the insurance account identifier; the description of the healthcare related commodity; and the request for the specification of financial responsibility.
- a reply to the request from the addressed insurance carrier is received and may include the specification of financial responsibility.
- a third transmission addressed to the healthcare provider is formed, the third transmission including at least part of the reply.
- an amount is received in return for a submission of an account in a payment system associated with an insured.
- the submission makes a request for a healthcare related commodity for rendering to a patient deriving healthcare insurance through the insured.
- the amount that is received is the amount that is owed by the insured for the healthcare related commodity for rendering to the patient. That is, the amount is owed for a good or service that has been or will be rendered to the patient.
- FIG. 1 shows a block diagram of an exemplary system for implementing a process for determining healthcare coverage using a payment account
- FIG. 2( a ) shows a flowchart for an exemplary process for determining healthcare coverage using a payment account which may be implemented in the exemplary system of FIG. 1 ;
- FIG. 2( b ) shows a flowchart for an exemplary process for verification of using a health care account
- FIGS. 3( a )- 3 ( d ) show flowcharts illustrating respective exemplary processes of or relating to a determination of healthcare coverage using a payment account which may be implemented in the exemplary system of FIG. 1 ;
- FIG. 4 depicts a table illustrating, for an exemplary model system, activities prior to the rendering of a healthcare related commodity to a patient and activities at a point of care terminal;
- FIG. 5 depicts a table illustrating, for the exemplary model system of FIG. 4 , exemplary activities at a point of care terminal and exemplary activities after the rendering of the healthcare related commodity to the patient;
- FIG. 6 depicts a table illustrating exemplary key components of the exemplary model system of FIG. 4 ;
- FIG. 7 depicts a table illustrating, for the exemplary model system of FIG. 4 , corresponding value propositions each of an exemplary third party healthcare information processor role and an exemplary transaction processor role;
- FIG. 8 shows a flowchart illustrating an exemplary process flow, which may be implemented in the exemplary system of FIG. 1 , for the determination of an eligibility request for the rendering of a healthcare related commodity to a patient;
- FIG. 9 shows a flowchart illustrating an exemplary process flow, which may be implemented in conjunction with the exemplary process flow of FIG. 8 , for an 835 claim payment;
- FIG. 10 shows a flowchart illustrating an exemplary data and process flow, which may be implemented in the exemplary system of FIG. 4 , for the determination of an eligibility request for the rendering of a healthcare related commodity by a healthcare provider to a patient associated with an insured of a insurance carrier;
- FIG. 11 shows a block diagram depicting an exemplary data and process flow, which may be implemented in the exemplary data and process flow of FIG. 11 , and illustrating interrelationships between a healthcare provider, an insurance carrier, and a sponsoring organization;
- FIG. 12 shows a block diagram of an exemplary payment system in which the exemplary system depicted in FIG. 1 may be implemented.
- FIGS. 13 a and 13 b shows an illustration of a portable computing device.
- Implementations of the invention solve the problems of conventional health information systems by enabling healthcare providers to electronically check the eligibility status of patients via simple POS terminals connecting over existing payment system networks using an eligibility-specific information transaction, not a payment authorization transaction.
- Specialized equipment is not required in implementations of the invention, so widespread acceptance is much more likely than systems that require the use of specialized hardware and/or communications equipment.
- Implementations of the invention send non-financial healthcare related messages through an existing financial network. As the messages are not financial in nature, the acquirers, the providers and the insurance carriers will not confuse financial transaction messages passing through the network with the non-financial healthcare related messages.
- a patient's eligibility to status regarding healthcare insurance coverage for healthcare related good or service may be determined.
- the healthcare related good or service may be provided by a healthcare provider, and the eligibility determination may be made by an adjudication entity such as an insurance carrier.
- an adjudication entity such as an insurance carrier.
- healthcare providers include doctors, dentists, eye care specialists, hospitals, laboratories, stores that sell healthcare related goods, injury clinics, a chiropractor, an entity that having at least one of a good and a service that is covered by the insurance plan, a provider of a healthcare service for compensation by the healthcare insurance of the insured, a provider of healthcare goods for compensation by the healthcare insurance of the insured and a combination thereof.
- eligibility responses include a basic eligibility response, a basic eligibility with co-pay response, and an enhanced eligibility response. Each of these types of eligibility responses is described in further detail below.
- the basic eligibility response message includes information regarding whether the patient is eligible for healthcare coverage. For example, a basic eligibility response may simply be a “Yes/No” type of response.
- the basic eligibility with co-pay response provides more information than the basic eligibility response.
- the healthcare insurance carrier may provide information regarding a required co-pay amount. This helps to avoid problems when the patient does not remember or know the appropriate co-pay amount associated with the desired healthcare related good or service. In this case, both the eligibility status and co-pay amount are returned to the provider and/or the patient in a response message.
- An enhanced eligibility response may also have more information than the basic eligibility response. For example, to support new trends in consumer-driven healthcare, healthcare insurance carriers may provide additional information regarding the plan type, plan contracted service amount, family or individual coverage, deductibles, co-insurance, co-pay amounts, etc. Examples of enhanced eligibility responses are provided below.
- a patient may swipe a payment card or health card at a healthcare provider's POS terminal. If a payment card is used, the card numbers are standard payment system card numbers issued in conformance with payment system standards.
- the transaction may be formatted by or at the POS terminal using the acquirer's-defined transaction type format for information transactions.
- a processing code may be entered (manually or automatically) into the POS terminal to indicate that the transaction is a non-financial eligibility request transaction.
- the created authorization request message is then forwarded to the provider's acquirer processor, through an International Standards Organization (ISO) payment transaction system (e.g., Visanet), and to a designated issuer processor.
- ISO International Standards Organization
- the transmissions between the various entities in the system may be completed in HIPAA-compliant manner (Health Insurance Portability and Accountability Act of 1996), both in format of the message and security requirements.
- the issuer or its designated processor, identifies the transaction as a healthcare eligibility verification request. It then converts the patient's card number into the health insurance carrier's identification number for that individual.
- the issuer processor may then optionally forward the authorization request message (e.g., an eligibility authorization request message) to a healthcare processor.
- the healthcare processor determines if the patient is eligible or not for healthcare insurance coverage.
- the insurance carrier or an entity designated by the insurance carrier who operates the healthcare processor checks the current eligibility status for the individual's identification number and responds with a status of “Yes,” currently eligible for healthcare insurance coverage or “No,” not currently eligible. Alternatively, if there is a more complicated eligibility issue to be resolved, then the healthcare provider may be requested to contact the insurance carrier. Additional information, such as the co-pay amount, may also be included in a response message.
- the healthcare or issuer processor transmits the response message including the eligibility determination back to the provider's POS terminal.
- the response message may be returned through the same path that the authorization request message (e.g., eligibility authorization request message) traveled, using appropriate message formats at each point in the process.
- the POS terminal receives the response message, the eligibility response information is then printed by the POS terminal and/or displayed at the POS terminal.
- FIG. 1 shows a block diagram for a healthcare system according to an implementation of the invention.
- the system includes a provider terminal 20 that is operated by a healthcare provider.
- the terminal 20 may be a POS (point of sale) terminal like those that are presently available to interact with ordinary payment cards.
- POS point of sale
- FIG. 1 one terminal 20 and one provider are described for simplicity of illustration. It is understood that there may be many more terminals and many more providers in implementations of the invention.
- the terminal 20 may interact with portable consumer device 12 .
- portable consumer devices include credit cards, debit cards, prepaid cards, healthcare insurance cards, smartcards, radio frequency identification (RFID) devices, driver's licenses, personal digital assistants, ATM cards, security badges, access badges, stored value cards, pagers, secure electronic account files, electronic token based account files, and the like.
- RFID radio frequency identification
- the terminal 20 and the portable consumer device 12 may be facilitated using any suitable optical, magnetic, electromagnetic, or electronic mechanism.
- the portable consumer device 12 is in the form of a card and has a magnetic stripe.
- the portable consumer device 12 may be stored electronically on a portable computing device, such as a smart phone, a portable media player, a flash drive or other form of electronic storage that may be accessed in a secure way.
- the portable consumer device 12 may store or display information such as BINs (bank identification numbers), card account number, patient name, patient healthcare number, birth date, card expiration date, employer name, employer/group policy number, dependent names/numbers, co-payment amounts, etc.
- the data is stored in a secure manner such that only authorized users may access the potentially sensitive data stored on the portable consumer device 12 .
- the terminal 20 may be in communication with an acquirer processor 22 , which may be operated by an acquiring financial institution or by a third party processor on behalf of the acquiring financial institution.
- the acquiring financial institution may also process transactions for other merchants or sellers.
- the acquirer processor 22 is used to conduct ordinary financial transactions, and thus may be in communication with other merchants or sellers and processors.
- the acquirer processor 22 may communicate with an issuer processor 26 via a transaction processing system 24 .
- the transaction processing system 24 may be primarily used for processing financial transactions. It may facilitate transactions that occur between the acquirer processor 22 and the issuer processor 26 .
- the transaction processing system 24 may be operated by an organization such as a credit or debit card company.
- the issuer processor 26 may be operated by an issuing financial institution such as a buyer bank, or another third party processor on behalf of the card issuer.
- a buyer (not shown) may interact with the issuer processor 26 .
- the buyer may or may not be a healthcare consumer.
- non-healthcare related buyers and sellers may use the same system as healthcare related buyers (e.g., patients) and sellers (e.g., service providers such as doctors).
- the issuer processor 26 may further be in communication with a healthcare processor 27 , which may be operated by an entity such as an insurance carrier or a third party processor that it designates.
- a healthcare database 29 may be in communication with the healthcare processor 27 .
- the healthcare database 29 may store information such as patient information, provider information, insurance plan information, service code information, etc.
- the healthcare database may be operated by the issuer processor or a third party processor on behalf of the issuer.
- each processor may be embodied by any suitable combination of hardware and/or software.
- each processor includes at least a server computer.
- a server computer is a powerful computer or cluster of computers that behaves as a single computer which services the requests of one or more client computers.
- the server computer may be a mainframe computer, a minicomputer, or a minicomputer cluster.
- the server computer may include one or more database servers and one or more Web servers.
- Software for performing any of the functions of the processors (or any of the functions described herein) may be embodied by computer code stored on a computer readable medium, which may store data using suitable electrical, electroptical, optical, or magnetic data storage mechanism.
- the computer code may be written in any suitable programming language including C, C++, Pascal, etc.
- the system shown in FIG. 1 may be implemented using existing private networks or specialized communication networks (e.g., the Internet).
- the communication links may also include wired or wireless links.
- FIG. 2 More specific methods according to an implementation of the invention may be described with reference to FIG. 2 , while also referring to FIG. 1 .
- patient identification information may be received at a provider terminal 20 (step 30 ( a )).
- the patient may use a portable consumer device 12 to provide patient identification information or other information to the provider terminal 20 .
- the POS terminal transaction may be originated like any other payment card transaction.
- the patient may have a payment (credit, debit or prepaid/stored value) or healthcare card with a magnetic stripe.
- the magnetic striped card is swiped through a card reader in the provider's terminal 20 .
- patient identification information include credit, debit, or prepaid/stored value card numbers, health identification numbers, birth date, dependent names/numbers, social security numbers, drivers license numbers, etc.
- wireless transactions may also be used to communicate the patient identification information.
- the relevant patient identification information may be communicated in a secure wireless manner from a portable computing device 1300 ( FIG. 13 ) belonging to a user such as a smart phone or a smart watch to a payment reading device.
- the patient identify information may be stored in a virtual wallet and may be accessed by the providers terminal.
- a user may have patient information for a plurality of family members (Grandma, spouse, children, grand-children, etc.) stored on the portable computing device and the patient information for the specific patient may be accessed and communicated.
- the validity of the portable consumer device 12 may be tested in a variety of ways. In some cases, the holder of an portable consumer device 12 may not be entitled to services as the portable consumer device 12 may be stolen or borrowed. If the portable consumer device 12 is a traditional card with a security chip, the card may be inserted into a reader where the security chip may be verified such as using an exchange of keys or a cryptographic algorithm stored in the chip. In yet another embodiment, a security hologram may be review to ensure the portable consumer device 12 is legitimate. Further, the portable consumer device 12 may have a photo of the card holder and the photo may be compared to the card holder to verify the holder is the proper user of the portable consumer device 12 .
- a fingerprint at the point of serviced may be matched to a stored fingerprint.
- a portable computing device 1300 may have a fingerprint reader 1310 and related software to compare a fingerprint at the point of presence to the stored fingerprint.
- the service provider may have a separate fingerprint reader to obtain the fingerprint which is compared to a known fingerprint for the patient to ensure the current user is entitled to healthcare.
- an image capturing device 1330 may be part of a computing device.
- An image of the user may be obtained by the computing device (either from the portable computing device or another computing device) and compared to a known image of acceptable users of the health care account.
- the image may be of a face.
- the image may be more specific such as of a retina. Of course, other images are possible and are contemplated.
- a user voice may be captured through a microphone 1340 and compared to a previously created voice sample. The comparison may be locally such as through an application on a portable computing device or the voice sample may be communicated to the network to be verified remotely.
- a user may be required to state a predetermined word or phrase that is known only to the user.
- a user of the health care account may be requested to provide verifying data to ensure the user is entitled to use the health care account.
- a user may be asked to provide a code, an answer to one or more preset questions or a PIN that is verified, either locally or through the computing network.
- the user may be required to answer preselected questions with predetermined answers using an input such as the input display 1320 (touch display) on a portable computing device.
- the portable computing device 1300 may have a processor 1350 which may be physically configured according to computer executable instructions.
- the portable computing device 1300 may also have a memory 1355 that may be physically configured to store the computer executable instructions and may assist the processor 1350 .
- the portable computing device 1300 may also have an input/output circuit 1360 which may assist in receiving inputs and providing outputs to users along with a sound circuit 1365 and a video circuit 1370 .
- the various elements of the portable computing device 1300 may be combined into a single chip or circuit or may be separated such that unneeded elements may be turned off to save power.
- the transaction may stop.
- the user may wish to communicate directly with the insurance carrier if the user believes there has been a mistake in denied the use of insurance. If the user is verified as having rights to use the insurance represented on the portable consumer device 12 , the approval process may continue.
- the provider Before or after the patient identification information is provided to the provider terminal 20 , the provider (or the patient) may provide healthcare service information to the terminal 20 .
- a processing code may be entered (manually or automatically) into the POS terminal to indicate that the transaction is a non-financial eligibility transaction. For example, a processing code for a healthcare related, non-financial message might be indicated as “39” (or any other code), while a processing code for purchasing a good or service might be indicated by the code “00”.
- service codes may be entered into the terminal 20 .
- provider staff may follow specified procedures, including entry of the healthcare-defined service type codes. These codes may be entered into the terminal 20 manually (e.g., by using input keys) or may be entered automatically.
- healthcare goods information e.g., SKU numbers
- Standard codes may be used for services or diagnoses.
- International Classification of Diseases propagated by the World Health Organization in Geneva, Switzerland (ICD-10) may be an appropriate manner of communicated the service.
- ICD-10 International Classification of Diseases propagated by the World Health Organization in Geneva, Switzerland
- a sample diagnosis code may be listed below:
- an authorization request message (e.g., an eligibility authorization request message) may then be formatted at the terminal 20 (step 30 ( c )).
- the authorization request message may be formatted in a format specified by the acquirer or as an International Standards Organization (ISO) type, non-financial, information message.
- the authorization request message may be an ISO 8583 type message, such as a standard (VisaNet) authorization request message. Information that may be included in the authorization request message is shown in the following table.
- data such as eligibility data associated with the patient may be added to a discretionary data field in the authorization request message.
- a discretionary data field is a field that may contain any particular information desired, for example, by an issuer. Additionally, discretionary data fields may be present in various data “tracks” that are present in many commercial credit and debit cards. Such data formats are defined by ANSI (American National Standards Institute).
- the authorization request message may then be communicated from the terminal 20 to the acquirer processor 22 (step 30 ( d )).
- the acquirer processor 22 may then communicate the authorization request message to the transaction processing system 24 (e.g., VisaNet) (or “TPS”) (step 30 ( e )).
- the transaction processing system 24 e.g., VisaNet
- TPS Transaction Processing system
- the transaction processing system 24 (e.g., VisaNet) then communicates the authorization request message to the designated issuer processor 26 (step 30 ( f )).
- a bank identification number (BIN), which is the first six digits of the card number, may be used to facilitate routing to the issuer, or its designated processor 26 .
- the issuer processor 26 may use a number of data fields to identify an eligibility request (processing code and BIN) and may convert the card number (e.g., a payment card number) to the insurance carrier's identification number for that patient (step 30 ( g )).
- the re-formatted message may then be communicated to the healthcare processor 27 (step 30 ( h )), which may be operated by an issuer processor or an insurance carrier, other payor, or other designated third party processor.
- the message format between the issuer processor 26 and healthcare processor 29 may be any mutually agreed format.
- the authorization request message may be evaluated in view of information from the healthcare processor 27 .
- the eligibility determination may be made by the healthcare processor 27 or with information that is provided by the healthcare processor 27 .
- the healthcare processor 27 may check the current eligibility status for the patient (step 30 ( i )).
- Patient data may be stored in the healthcare information database 29 and the healthcare processor 27 may contact the healthcare database 29 to determine if the patient is eligible for the requested healthcare-related good or service.
- the healthcare processor 27 may then generate and sends a “yes” or “no” response back to the terminal 20 , patient and provider. If approved and if applicable, the healthcare processor 27 may also forward the required co-pay for that service type code for the patient's plan coverage. More specific descriptions of eligibility determination processes performed by the healthcare processor 27 are provided below.
- Any suitable response message format may be used.
- the data to be transmitted from the healthcare processor 27 back to the terminal 20 may be formatted in a standard ISO type authorization response at some point in the process.
- An exemplary authorization response may include the following:
- Data Element Description Length Card Number The card number assigned by the 16 (Numeric). issuing financial institution. Healthcare A medical license number of provider. 9 (Numeric) Provider ID Service A healthcare-defined standard code 5 (Alpha-. Type for healthcare treatment. numeric) Code Carrier An identification number that 6 (Numeric). ID identifies the health insurance carrier or payer. Approval or Healthcare-defined codes for 2 (Alpha- Reject approvals and rejections of Numeric) Reason Code eligibility inquiries (see below). Co-Pay The amount of the co-pay, if 10 (Numeric) Amount applicable. Carrier Carrier defined comments or Up to 200 Comments information. (Alpha- numeric).
- the response message may be communicated from the issuer processor 26 to the terminal 20 along the path through which the authorization request message was transmitted.
- the healthcare processor 27 may communicate the response message to the issuer processor 26 (step 30 ( j )).
- the issuer processor 26 may convert the insurance carrier's identification number back to the patient's card number (e.g., payment card number) and may map the approval code and co-pay amounts into the designated fields of the authorization response message (step 30 ( k )).
- the authorization response message may then be communicated to the transaction processing system 24 (step 30 ( 1 )), and the transaction processing system 24 may communicate the authorization request message to the acquirer processor 22 (step 30 ( m )).
- the acquirer processor 22 then communicates the response message to the originating terminal 20 (step 30 ( n )).
- the terminal 20 may display or print out the response message. If the response indicates an approval, the terminal 20 may print a receipt that shows the co-pay information and any additional text returned by the healthcare processor 27 . If the eligibility status cannot be confirmed, a decline response will be displayed on the receipt and additional manual verification procedures may be needed.
- Implementations of the invention are not limited to the steps shown in FIG. 2 .
- the eligibility determination need not be performed by the healthcare processor 27 .
- carrier and patient information may be sent from the healthcare processor 27 to the issuer processor 26 , the transaction processing system 24 , and/or the acquirer processor 22 .
- the issuer processor 26 , the transaction processing system 24 , and/or the acquirer processor 22 could then make the eligibility determination based on information received from the healthcare processor 27 .
- FIG. 2( b ) is a sample a flowchart of sample steps in determining eligibility to using a health care account.
- a portable consumer device 12 may be presented and read by a device at the point of service.
- account data may be retrieved from the portable consumer device 12 .
- a request for verification data may be presented.
- the verification data may take a variety of forms and the verification may occur locally or through the network.
- the verification data may be received.
- the verification data may vary and there may be a variety of acceptable verification data.
- the determination may be made whether the verification data is acceptable.
- the verification determination may be made locally or through the network. Further, the verification may depend on the type of verification data received.
- the acceptance or denial of the verification data may be communicated.
- a card holder may present a portable consumer device 12 such as a card to a service provider.
- the portable consumer device 12 may have a chip and the card holder may be requested to insert the portable consumer device 12 into a card reader with chip reading capabilities and type in a personal identification number (PIN). If the PIN is acceptable, an approval may be noted and the user may continue through the blocks in FIGS. 3( a )- 3 ( d ).
- PIN personal identification number
- a portable consumer device 12 holder may present a portable consumer device 12 to a service provider in the form of a virtual card in an electronic wallet on a smart phone.
- the virtual card holder may use a fingerprint reader to verify that the virtual card holder is authorized to use the virtual card in the electronic wallet. If the fingerprint is accepted, the virtual card data in the virtual wallet may be communicated to the service provider. If the fingerprint is not accepted, a rejection may be communicated to the virtual card holder.
- a user may have a traditional type credit card as the portable consumer device 12 .
- a user may input a PIN that is communicated through the network to the insurance company. If the PIN is correct, a positive signal will be returned through the payment network and if the PIN is not correct, a negative signal will be returned through the payment network.
- an out of band communication may be made to the account owner.
- Out of band may be considered another communication channel.
- a SMS message may be sent over a cellular network or an email may be communicated through the Internet.
- the out of band message may contain a pin or other code that may be needed to complete the verification.
- a tone may be communicated that must be played for the point of sale terminal for verification.
- the tone may be received by the point of sale terminal, may be converted to digital signals which may be communicated over the financial payment network to the insured for verification.
- an image may be communicated to the user of a portable computing device and the image need to be displayed to the card reader. The card reader may capture the image, communicate a digital version of the image through the financial payment network to be verified.
- the message may simply be a notice that the account has been accessed and if the access is improper, to contact an authority. If the access is expected, the account holder may have to do nothing. If the access is not expected, an account holder may have to call the insurance company to stop the transaction.
- FIGS. 3( a ) to 3 ( d ) show a flowchart illustrating steps in a more complicated eligibility determination process that may be performed by the healthcare processor 27 (or other entity).
- the healthcare processor 27 extracts patient identification information from the authorization request message (step 40 ( a )), and then determines whether or not the carrier participates (step 40 ( b )).
- the patient identification information in the authorization request message is compared to patient identification data in the healthcare information database 29 .
- decision step 40 ( c ) if the patient identification information is matched to appropriate information in the healthcare database 29 , then the transaction proceeds to the next step 40 ( c ).
- step 40 ( e ) if the patient information cannot be matched to information in the healthcare database 29 , then the transaction is rejected.
- a response message with a reject reason code (e.g., “code 90 : invalid/missing payor ID”) is created by the healthcare processor 27 .
- the healthcare processor 27 determines what type of plan covers the patient (step 40 ( d )). If the patient has an indemnity plan type, then the process proceeds to the indemnity insurance plan subroutine A. If the patient has a POS (point of service) plan type, then the process proceeds to the POS insurance plan subroutine B. If the patient has an HMO or PPO plan type, then the process proceeds to the HMO/PPO insurance plan subroutine C.
- POS point of service
- FIG. 3( b ) shows a subroutine that is applicable if the patient is covered under an indemnity insurance plan.
- the healthcare processor 27 determines if the patient is eligible for service (step 40 ( g )). If the patient is not covered, then the transaction is rejected by the healthcare processor 27 . If the patient is covered, the healthcare processor 27 approves of the transaction (step 40 ( h )).
- FIG. 3( c ) shows a subroutine that is applicable if the patient is covered under a POS insurance plan.
- the healthcare processor 27 determines if the patient is eligible for the healthcare related good or service (step 40 ( j )). If the patient is not eligible, the transaction is rejected (step 40 ( n )). If the patient is eligible, then the healthcare processor 27 determines if the provider is in the patient's network (step 40 ( k )). If the patient is not eligible, then the healthcare processor 27 determines an “out of network” co-pay amount (step 40 ( o )), and the transaction is approved (step 40 ( p )). If the provider is in the patient's network, then the “in network” co-pay amount is determined (step 40 ( 1 )), and the transaction is approved (step 40 ( m )).
- FIG. 3( d ) shows a subroutine that is applicable if the patient is covered under an HMO or PPO plan type.
- the healthcare processor 27 determines if the provider is part of the provider group (step 40 ( q )). If the provider is not part of the HMO/PPO provider group, then the transaction is rejected and a message indicating that the patient is not covered is sent from the healthcare processor 27 back to the provider's terminal 20 .
- the healthcare processor 27 determines if the patient is eligible for the service performed (step 40 ( r )). If not, then the transaction is rejected and a message indicating that the patient is not covered is sent from the healthcare processor 27 back to the provider's terminal 20 .
- the healthcare processor 27 determines if the patient is covered by the service (step 40 ( s )). If not, then the healthcare processor 27 seeks authorization to cover the service (step 40 ( x )). If the patient is eligible, then the patient's co-pay amount is determined and the transaction is approved (step 40 ( u )).
- the healthcare provider potentially faces a more complicated situation in knowing how much to collect from the patient at the time of the visit.
- the following data elements may be added in the authorization response message:
- Coverage A code indicating the level of 3 (Alpha- Level Code coverage being provided for the numeric) patient, such as “employee only”, family”, etc. Contracted The contracted amount for the 12 (Numeric) Service service type code which the Amount provider has agreed to accept. Remaining The remaining amount of the 12 (Numeric) Deductible deductible which the insured Amount individual has to meet before the carrier will reimburse the provider.
- Information such as this may assist a provider in knowing a contracted amount to charge for services under the patient's healthcare plan, and whether to collect from the patient, because the deductible amount has not been met and/or collect any co-pay amounts.
- the account associated with a payment processing system may be used to determine eligibility, co-payment, and adjudicated financial responsibility of an insured (e.g., a person responsible for payments to a healthcare provider under an insurance plan of the insurance carrier).
- the payment processing system may include an issuer such as the issuer processor 26 , an acquirer such as acquirer processor 22 , a transaction handler such as the transaction processing system, and the insured. See text in the section entitled “Payment Processing System” in the later part of this application for a detailed discussion of the payment processing system.
- account associated with the payment processing system may be used to transfer clinical information and concierge services to provide quality healthcare information and services.
- FIG. 4 depicts a table illustrating, for an exemplary model system, activities prior to the rendering of a healthcare related commodity (e.g., a good or service for rendering to a patient deriving healthcare insurance through the insured) to a patient and activities at a point of care terminal.
- the insured such as the patient, may receive a portable consumer device such as a flexible spending account, from the payment transaction system.
- the portable consumer device may be authenticated at this stage.
- the insured may log on to a secure website to set privacy settings for medical records of the insured, or other persons covered by the insured's insurance plan.
- the insured may also access the website to gain medical information such as information about a medical condition given symptoms of the medical condition.
- the insured may also access concierge type services from the payment transaction system including receiving refers for healthcare providers.
- the insurer may use the account associated with the payment processing system to determine eligibility for the patient, determine the amount of co-payment the insured may be responsible for, determine the insured's monetary responsibility for healthcare related commodities rendered to the patient, and/or transfer basic medical records of the patient each of which may occur in real time.
- the phrase ‘real time’ may be understood to mean the duration of time that is needed to derive an amount owed by the insured for goods and/or services rendered to the patient.
- the ‘real time period’ may be relatively short, such as about thirty seconds or less, of even the time period that the patient is at the facility of the healthcare provider.
- the reasons for the visit may be entered into the patient's medical records.
- the determination of the insured's monetary responsibility for healthcare related commodities rendered to the patient may occurs chronologically proximal to the rendering of the healthcare related commodity to the patient.
- FIG. 5 depicts a table illustrating, for the exemplary model system of FIG. 4 , exemplary activities at a point of care terminal and exemplary activities after the rendering of the healthcare related commodity to the patient.
- the insured may swipe a bank card having an identifier of the account (e.g., account number) within the payment processing system at a terminal at the Point of Care (POC).
- POC Point of Care
- a description of a healthcare related commodity for rendering to a patient deriving healthcare insurance through the insured may be uploaded into records maintained at the payment processing system.
- a transmission may be formed that is addressed to the acquirer of the healthcare provider.
- the transmission may include information such as the insured's account number within the payment processing system, the description of a healthcare related commodity for rendering to a patient deriving healthcare insurance through the insured, and a request for a specification of financial responsibility of the insured for the described healthcare related commodity.
- the request for the specification of financial responsibility of the insured may be an eligibility request, such as a request for eligibility indication for the patient as to insurance coverage through the insured for the described healthcare related commodity rendering the patient.
- the eligibility indication may include an indicia signifying that the patient is eligible for insurance coverage through the insured for the described healthcare related commodity; an indicia signifying that the patient is ineligible for insurance coverage through the insured for the described healthcare related commodity; and an indicia signifying that the patient is partially eligible for insurance coverage through the insured for the described said healthcare related commodity for rendering to the patient.
- a request to determine if a child's flu shot is eligible to be covered by the insurance carrier of the insured that is the father of the child.
- the indicia may be that the child is eligible for coverage.
- the healthcare provider may receive a reply to the request from the addressed payment processing system.
- the acquirer of the healthcare provider may forward the request to the payment transaction system.
- the payment transaction system may use an algorithm to convert the identifier of the account within the payment processing system to an insurance account identifier that is associated with both the insured and an insurance carrier.
- the payment transaction system may form a transmission addressed to an insurance carrier that includes the insurance account identifier, the description of the healthcare related commodity for rendering to the patient deriving healthcare insurance through the insured; and the request for the specification of financial responsibility of the insured for the described said healthcare related commodity (e.g., “how much is the adjudicated monetary responsibility of the insured for prescription medication.”).
- the payment transaction system may receive a reply to the transmission from the addressed insurance carrier including the specification of financial responsibility of the insured for the described said healthcare related commodity (e.g., $15 U.S. co-pay is due).
- the payment transaction system may form a transmission to the healthcare provider including at least part of the reply, such as a co-pay amount due, the adjudicated claim information based upon contracted rates, the identifier of the account within the payment processing system, the insurance account identifier, or a combination thereof.
- the healthcare provider may then bill the patient for the amount of that the insured is responsible for.
- the insured may choose to use the same account associated with the payment processing system. Such a choice may be made to make the payment by swiping the insured's portable consumer device issued to same by an issuer. Thereafter, the information gathered by the swiping of the portable consumer device is submitted as a financial authorization request to the payment processing system.
- the payment may be for at least a portion of the financial responsibility of the insured for the described healthcare related commodity.
- the payment may be for a transaction with a healthcare provider of the healthcare related commodity for rendering to the patient.
- the provider of the healthcare related commodity may communicate the transaction to the acquirer.
- the acquirer may communicate the transaction to the payment transaction processor (e.g., the transaction handler).
- the payment transaction processor may communicate the transaction to the issuer and the issuer may communicate the transaction to the insured for payment.
- the healthcare provider may be a pharmacy.
- the insured may swipe the portable consumer device at the POC of the pharmacy.
- the request may include an identifier for the pharmacy and the identifier of the account associated with the payment processing system.
- a doctor's prescription for a diagnosed medical condition of the patient may have been previously uploaded into the patient's records maintained at the payment processing system.
- the reply to the request may include: the identifier for the account associated with the insured, the prescription, and the insured's responsible portion toward the payment for the prescribed medication.
- the insured may use the concierge service to complain of bad healthcare related commodities rendered to the patient.
- the payment transaction system may also facilitate the transfer of payment from the insurance carrier to the healthcare provider through such systems as the Visa ePay system.
- the Visa ePay system® is a fully automated, electronic payment delivery system that links financial institutions (e.g., acquirers and issuers), payment originators, billers, and credit counseling agencies such that online bill payments remain electronic from entry to posting.
- FIG. 6 a table illustrating exemplary key components of the exemplary model system of FIG. 4 is depicted.
- FIG. 7 a table illustrating, for the exemplary model system of FIG. 4 , corresponding value propositions each of an exemplary third party healthcare information processor role and an exemplary transaction processor role is depicted.
- Components include advantages such as real-time access to information, greater efficiency in payments, risk management, and access to “quality” services through the concierge services.
- Roles include a description of what the payment transaction system, such as Visa, may process and a description of what a third party healthcare information processor, such as the Patient Safety Institute (PSI), may process.
- PSI Patient Safety Institute
- FIG. 8 a flowchart illustrates an exemplary process flow, where the process may be implemented in the exemplary system of FIG. 1 , for the determination of an eligibility request for the rendering of a healthcare related commodity to a patient. See United State's HIPAA, infra, regarding HIPAA standards.
- the provider may submit an eligibility request (HIPAA 270).
- the eligibility request may contain include information such as an identifier of the insured's account within the payment processing system, the description of a healthcare related commodity rendered to a patient covered by an insurance plan of the insured (e.g., “flu shot” or code 98 denoting “Physician Office Visit”), and specification of financial responsibility of the insured for the described said healthcare related commodity (e.g., “is the patient covered within the insured's insurance plan”).
- the acquirer may receive the eligibility request directly, such as through a virtual point of service (POS) connection.
- POS point of service
- the virtual POS may be have a split dial connection at the healthcare provider's facility such that one line of the split dial is dedicated to the encrypted transmission of healthcare related data.
- a third party such as PSI, may receive the eligibility request from the healthcare provider and forward at least part of the eligibility request to the acquirer.
- the eligibility request is routed to the appropriate insurance carrier, for example, through the payment transaction system.
- Step 3 of FIG. 8 may entail the involvement of additional third party processors to assist with the routing of the eligibility request.
- the insurance carrier validates whether the patient is eligible under the insurance plan of the insured to be at least partially covered for the healthcare related commodity rendered to the patient. For example, a child of the insured may be listed under the insured's Humana Health Maintenance Organization (HMO) plan. The child has a rhinoplasty at a hospital. Once the insurance carrier receives the eligibility request from the payment transaction system, the insurance carrier may determine that the child is part of the Humana HMO plan, however, the rhinoplasty was an esthetic operation, the payment of which is not covered by the Humana HMO plan.
- HMO Humana Health Maintenance Organization
- FIG. 9 a flowchart illustrating an exemplary process flow, which may be implemented in conjunction with the exemplary process flow of FIG. 8 , for an 835 claim payment is shown.
- a payer such as the insurance carrier, may pay the healthcare provider through an electronic payment delivery system such as the Visa ePay system®.
- the payer remits the response to the eligibility request to the electronic payment delivery system for healthcare related commodities rendered.
- the electronic payment delivery system may create files containing the insurance carrier payments to the healthcare provider and make a ‘healthcare claim advise’ available to the healthcare provider.
- the electronic payment delivery system may transfer funds from an insurance carrier's bank (e.g., insurance carrier's acquirer) account to a healthcare provider's bank (e.g. insurance carrier's acquirer) account and route the created files to pay the healthcare provider's bank for the services rendered.
- an insurance carrier's bank e.g., insurance carrier's acquirer
- a healthcare provider's bank e.g. insurance carrier's acquirer
- the communications may be in the form of electronic transmissions.
- the electronic transmission may include Electronic Protected Health Information (EPHI), which is may be governed by industry standards such as the American Health Insurance Portability and Accountability Act of 1996 (HIPAA).
- EPHI Electronic Protected Health Information
- the transmissions may occur via the payment processing system, such as a credit card payment processing system.
- the payment of the patient financial responsibility may also occur via the payment processing system such as through the transmission of the transaction data (e.g., account number, account holder name, transaction cost, tax).
- a terminal at the POS may be used to send and receive the electronic transmissions.
- the terminal at the POS may have a split dial such that portions of the transmission may be sent to different addresses.
- the transmissions including the patient eligibility data, the patient financial responsibility data, and/or the transaction data for the payment of the patient financial responsibility may occur in real time such that the patient is physically present at the health care provider's facility as the transmissions occur (e.g., a period less than one hour) or a waiting period equivalent to the time the patient entered a facility of the healthcare provider and the time the healthcare provider renders the healthcare related commodity to the patient.
- the patient may use a portable consumer device to provide patient identification information or other information to the POS terminal.
- the patient may have a payment (credit, debit or prepaid/stored value) or healthcare card with a magnetic stripe that has information about an account such as a credit card, a debit card, a saving account, a checking account, a stored value card account, a gift card account, a money market fund, a trust account, a Flexible Spending Account, a Managed Savings Account, a Dependent Care Reimbursement Account, a Health Care Reimbursement Account, Health Reimbursement Account, and a combination thereof.
- the magnetic striped card may be swiped through a card reader in the provider's POS terminal. The patient information may then be sent to the insurance carrier via the payment processing system.
- the electronic transmissions may include at least part of the patient information, such as the information obtained from the portable consumer device.
- the transmission including patient financial responsibility data may have the patient name and patient insurance account number.
- the patient information may be encrypted, hashed, a code may be used to determine other patient information such as by using a “look-up” table.
- patient information such as a patient's credit card account number, may be included in the patient financial responsibility data transmission.
- the recipient of the transmission, or a third party may utilize the patient's credit card account number to determine the patient's health insurance account number given access to a database that links the patient's credit card account number to the patient's health insurance account number.
- step 1 upon patient check-in and authentication, the healthcare provider submits an eligibility request to the patient's insurance carrier.
- This request may be in the HIPAA 270 code format, and may include unique identifiers of the individual being treated, the health care provider, the health plan, and the employer, for example.
- the healthcare provider may capture a 270 message in a virtual POS terminal, which may be in-house or hosted by an external processor, and route this message to its Acquirer.
- 270 Message may be routed to the appropriate insurance carrier through the payment processing system (e.g., VisaNet), which may (or may not) involve additional third party processors.
- the payment processing system e.g., VisaNet
- the Insurance carrier may validate patient eligibility, and route eligibility status message back to healthcare provider in the HIPAA 271 code format, for example.
- healthcare provider may submit claims request to insurance carrier in the HIPAA 837 message format, for example.
- the transaction may follow the same route as the 270 message format.
- a message such as a ‘835 message’, may be sent back to the healthcare provider confirming the patient responsibility.
- the 835 message may be transmitted before the patient leaves the health care provider's office and the provider may bill and collect from the patient; alternatively, or in combination, for example if the claim cannot be auto adjudicated, the health care provider may collect the co-payment for the service rendered.
- HIPAA Health Insurance Portability and Accountability Act of 1996
- HIPAA Privacy Rule mandates the protection and privacy of all health information. This rule specifically defines the authorized uses and disclosures of “individually-identifiable” health information.
- HIPAA Security Rule mandates the security of electronic medical records (EMR). Unlike the Privacy Rule, which provides broader protection for all formats that health information make take, such as print or electronic information, the Security Rule addresses the technical aspects of protecting electronic health information.
- FIG. 11 shows a block diagram depicting an exemplary data and process flow, which may be implemented in the exemplary data and process flow of FIG. 10 , and illustrating interrelationships between a healthcare provider, an insurance carrier, and a sponsoring organization is shown.
- Health Care Eligibility/Coverage/Benefit transactions are designed so that healthcare providers may determine whether an Information Source organization (payer, employer, Health Maintenance Organization “HMO”, etc) has a particular subscriber and/or dependent(s).
- the data available through these transaction sets may be used to verify an individual's eligibility or benefits:
- Health Care Eligibility/Coverage/Benefit Inquiry (270) transmits data from a submitter (information receiver) to an information source organization;
- Health Care Eligibility/Coverage/Benefit Information (271) transmits data from an information source organization to an information receiver.
- Eligibility or Coverage/Benefit Information Eligibility/Coverage/Benefit Information
- Source Source identifies the payer, maintainer, or Subscriber source of the eligibility or benefit information
- Dependent Eligibility/Coverage/Benefit Information Eligibility or Benefit Inquiry (Question) Receiver identifies the provider who Subscriber receives the eligibility or benefit information
- Dependent Subscriber identifies the employee or Eligibility or benefit Inquiry (Question) group member, or patient who is covered Eligibility or benefit Inquiry (Question) for insurance and to whom, or on behalf of whom, the insurer agrees to pay benefits
- Dependent identifies the person who is affiliated with the subscriber (spouse, child, etc.)
- the corresponding 271 response may follow the same structure displayed above, with the Eligibility or Benefit Information replacing the Eligibility or Benefit Inquiry.
- the HIPAA Health Care Claim: Professional Transaction (837) is used for submitting professional claims and/or encounters to payers for payment.
- the transaction originates with the health care provider or the health care provider's designated agent or with payers in an encounter reporting situation. Information is sent to permit the destination payer to begin to adjudicate the claim.
- the Health Care Claim: Professional Transaction (837) coordinates with a variety of other transactions including, but not limited to Remittance Advice (835). It was designed specifically to address issues concerning the handling of coordination of benefits (COB) in a totally EDI environment, particularly COB transactions involving Medicare and Medicaid.
- COB coordination of benefits
- One 837 may contain many claims from different providers all sent to one payer.
- the Health Care Claim Payment/Advice (835) transaction set is designed for the payment of claims and transfer of remittance information. It may be used to make the payment, send an Explanation of Benefits (EOB) remittance advice, or both.
- EOB Explanation of Benefits
- the 835 provides detailed payment information including, if applicable, the reasons why the total original charges were not paid in full. Note that insurance carriers may pay claims and send remittance advice in different ways (i.e., together or separately) and through different channels (i.e., directly to the provider or through financial institutions).
- a transaction such as a payment transaction, may include participation from different entities that are a component of the payment processing system as illustrated in FIG. 12 .
- the payment processing system may include an issuer, a transaction handler, such as a credit card company, an acquirer, a merchant, such as a health care provider, or a consumer such as an insured having insurance coverage through which a patient receive healthcare benefits.
- the acquirer and the issuer may communicate through the transaction handler.
- the merchant may utilize at least one POS terminal that may communicate with the acquirer, the transaction handler, or the issuer. Thus, the POS terminal is in operative communication with the payment processing system.
- a transaction begins with the consumer presenting a portable consumer device to the merchant to initiate an exchange for a good or service.
- the portable consumer device may include a payment card, a gift card, a smartcard, a smart media, a payroll card, a health care card, a wrist band, a machine readable medium containing account information, a keychain device such as the SPEEDPASS commercially available from ExxonMobil Corporation or a supermarket discount card, a cellular phone, personal digital assistant, a pager, a security card, an access card, a wireless terminal, or a transponder.
- the portable consumer device may include a volatile or non-volatile memory to store information such as the account number or an account holder's name.
- the Merchant may use the POS terminal to obtain account information, such as an account number, from the portable consumer device.
- the portable consumer device may interface with the POS terminal using a mechanism including any suitable electrical, magnetic, or optical interfacing system such as a contactless system using radio frequency or magnetic field recognition system or contact system such as a magnetic stripe reader.
- the POS terminal sends a transaction authorization request to the issuer of the portable consumer device.
- the portable consumer device may communicate with the issuer, the transaction handler, or the acquirer.
- the Merchant may also use a portable computing device 1300 such as a smart phone of the user as illustrated in FIGS. 13 a and 13 b .
- a portable computing device 1300 such as a smart phone of the user as illustrated in FIGS. 13 a and 13 b .
- verification may be enabled through the portable computing device, such as using a fingerprint reader, receiving an out of band verification message, using the image capture device, etc.
- the portable computing device 1300 may also have a virtual wallet that is accessed and used as part of the transaction.
- the issuer may authorize the transaction using the transaction handler.
- the transaction handler may also clear the transaction.
- Authorization includes the issuer, or the transaction handler on behalf of the issuer, authorizing the transaction in connection with the issuer instructions such as through the use of business rules.
- the business rules could include instructions or guidelines from the transaction handler, the consumer, merchant, the acquirer, the issuer, a financial institution, or combinations thereof.
- the transaction handler may maintain a log or history of authorized transactions. Once approved, merchant will record the authorization, allowing the consumer to receive the good or service.
- the Merchant may, at discrete periods, such as the end of the day, submit a list of authorized transactions to the acquirer or other components of the payment processing system.
- the transaction handler may compare the submitted authorized transaction list with its own log of authorized transactions. If a match is found, the transaction handler may route authorization transaction amount requests from the corresponding acquirer to the corresponding issuer involved in each transaction. Once the acquirer receives the payment of the authorized transaction amount from the issuer, it may forward the payment to merchant less any transaction costs, such as fees. If the transaction involves a debit or pre-paid card, the acquirer may choose not to wait for the initial payment prior to paying the merchant.
- the acquirer may initiate the clearing and settling process, which may result in payment to the acquirer for the amount of the transaction.
- the acquirer may request from the transaction handler that the transaction be cleared and settled. Clearing includes the exchange of financial information between the issuer and the acquirer and settlement includes the exchange of funds.
- the transaction handler may provide services in connection with settlement of the transaction.
- the settlement of a transaction includes depositing an amount of the transaction settlement from a settlement house, such as a settlement bank, which the transaction handler typically chooses, into a clearinghouse, such as a clearing bank, that the acquirer typically chooses.
- the issuer deposits the same from a clearinghouse, such as a clearing bank, which the issuer typically chooses into the settlement house.
- a typical transaction involves various entities to request, authorize, and fulfill processing the transaction.
- Implementations may be embodied as one or more of a method, a system, a device, and a computer program; where each method, system, device, and a computer program may include software and/or hardware components. Implementations are described using block diagrams and flowcharts to illustrate means for performing the described functions of the method, system, device, and computer program.
- the computer program may include a computer-readable storage medium having computer-readable program code means embodied in the storage medium.
- the system may include a host system including a processor for processing data, a memory in communication with the processor for storing the data, an input digitizer in communication with the memory and the processor for inputting the data into the memory; and an application program stored in the memory and accessible by the processor for directing processing of the data by the processor.
- the application program may be configured to perform a method.
- the system may include various integrated circuit components, such as microprocessors, controllers, memory elements, processing elements, logic elements, and look-up tables.
- steps of a method, process, or algorithm described in connection with the implementations disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two.
- the various steps or acts in a method or process may be performed in the order shown or may be performed in another order. Additionally, one or more process steps may be omitted or one or more process steps may be added to the processes. An additional step, block, or action may be added in the beginning, end, or intervening existing elements of such processes.
Abstract
Healthcare insurance coverage is determined using an account within a payment processing system. A transmission addressed to the payment processing system is formed including an account number of an account associated with the payment processing system, a description of a healthcare related commodity rendered to a patient deriving healthcare insurance through an insured, and request for a specification of financial responsibility of the insured for the described said healthcare related commodity. A transmission is received from the payment processing system including the requested specification of financial responsibility.
Description
- This application is a continuation-in-part and claims priority to U.S. patent application Ser. No. 14/017,652 filed Sep. 4, 2013, by Patterson, which claims priority to U.S. patent application Ser. No. 12/648,054 (now U.S. Pat. No. 8,560,446) filed Dec. 28, 2009, by Patterson, titled “Product Level Payment Network Acquired Transaction Authorization,” which claims priority to U.S. patent application Ser. No. 11/230,761 (now U.S. Pat. No. 7,650,308), by Patterson, et al, filed Sep. 20, 2005, titled “Auto-Substantiation For Over-The-Counter Transactions”, which claims priority to three provisionals: 60/641,597 titled “Auto Adjudication For Over-The-Counter Transactions” by Nguyen filed Jan. 4, 2005; 60/641,483 entitled “Method and System for Determining Healthcare Eligibility” by Patterson filed Jan. 4, 2005; and 60/641,464 entitled “Method and System for Determining Healthcare Eligibility” by Nguyen filed Jan. 4, 2005, all of which are incorporated by reference.
- Insurance companies typically provide their customers with health identification (ID) cards, which contain information such as patient name, employer plan number, type of insurance coverage, and applicable co-pay amounts. These ID cards are useful to healthcare providers such as doctors.
- While ID cards are useful, they do not convey information regarding the current status of insurance coverage. For example, the cardholder may no longer be employed by the company that originally provided insurance coverage, so that the cardholder's insurance coverage may no longer be valid. To deal with this issue, healthcare providers use different means to check the current eligibility status of patients.
- Some providers fax and/or make telephone calls to a customer service center operated by the cardholder's insurance carrier to determine if the cardholder is eligible for a particular type of healthcare service. Such methods, however, may be time consuming for the provider's office staff and are expensive for insurance carriers.
- Some companies (e.g., SpotCheck and ProxyMed) have developed electronic eligibility verification systems using point-of-sale (POS) terminals. The POS terminals require either a dedicated POS terminal or separate connections to the eligibility service provider. Such systems require the use of specialized POS terminals and specialized connections between the service provider and the carrier. Since specialized equipment is required, widespread acceptance of such systems has not been achieved.
- Some companies (e.g., United Health Group and MasterCard) have developed electronic eligibility verification using a POS terminal and a payment authorization transaction over an existing payment network, where the transaction amount is used to equate to a particular service type (e.g., $0.01 is an office visit). This approach has created problems for the provider's office and the provider's financial institution, because these transactions are indistinguishable from a true payment transaction and may be inadvertently processed as real payment transactions.
- Some healthcare clearing houses (e.g.; WebMD) and insurance companies have developed Internet-based systems to permit provider offices to access eligibility information electronically, but this typically requires relatively expensive PC equipment and PC-trained office staff. As noted above, if specialized equipment is required, widespread acceptance is unlikely.
- Moreover, the flow of payments and information between healthcare providers and insurance carriers has traditionally been inefficient and substantially error-prone because of structural and other factors, and many opportunities exist for optimization. Another challenge lies in latency of the patient payment collection process. Providers typically do not bill patients until submitted claims have been processed and adjudicated by the patient's insurance carrier—a process which may take several weeks to complete. As a result, an average of 42% of total provider revenue may be tied-up in accounts receivables, of which a significant share may exceed one hundred and twenty (120) days. This is expected to exacerbate over the next few years with the drive toward consumer driven health plans.
- The patient collection process may be conducted electronically; however, industry standards may confine both the format and the content of electronic transmissions containing healthcare related information. The United States' Health Insurance Portability and Accountability Act (HIPAA) is an example of a standard in the industry that may govern the form of electronic transmissions dealing with health care information. The primary goal of HIPAA is to simplify and enhance electronic data interchange (EDI) between providers and insurance carriers, and thereby drive efficiencies in their overall dialogue. To protect the privacy rights of patients, HIPAA also defines rules to ensure that all medical records, medical billing, and patient accounts meet certain consistent standards with regard to documentation, handling and privacy. Any healthcare provider that electronically stores, processes or transmits medical records is required to be fully HIPAA compliant as of April 2006.
- It would be useful to develop solutions that may facilitate an electronic dialogue between healthcare providers and insurance carriers based on HIPAA standards. It would also be useful if the solutions take into consideration scalability and interoperability.
- Insurance carriers and healthcare providers differ fundamentally in levels of consolidation. There are about 800,000 physicians in the USA, most of which work in small practice groups (less than 4 MDs), and about 5,800 registered hospitals. Although the number of insurance carriers approximate 20,000, the top 20 cover 70% of all U.S. enrollees. Collectively, these entities account for an estimated 2 billion eligibility transactions and 900 million claims transactions each year.
- It also would be useful that the patient data is for the insured rather than an imposter. Fraudulent presentation of insurance credentials is becoming more and more of an issue. It would be useful to verify the holder of the card is the actual person entitled to insurance coverage. Similarly, it would be useful to ensure that the insurance card itself is valid.
- Implementations are directed to facilitating communication in a healthcare environment. One implementation is directed to a method comprising: receiving patient information at a POS terminal operated by a healthcare provider; creating a non-financial authorization request message which relates to healthcare using payment card and patient information; sending the authorization request message to an acquirer processor, wherein the acquirer processor sends the authorization request message to a transaction processing system such as a payment processing system, and wherein the authorization request message is evaluated (e.g., by an insurance carrier) in view of information from a healthcare processor; and receiving a response message in response to the authorization request message.
- Another implementation is directed to a computer readable medium comprising: code for receiving patient information at a terminal operated by a healthcare provider; code for creating a non-financial authorization request message which relates to healthcare using the patient information; code for sending the authorization request message to an acquirer processor, wherein the acquirer processor sends the authorization request message to a transaction processing system, and wherein the authorization request message is evaluated (e.g., by an insurance carrier) in view of information from a healthcare processor or an issuer processor; and code for receiving a response message in response to the authorization request message.
- Another implementation is directed to a method comprising: receiving patient information comprising a patient identification number at a terminal operated by a healthcare provider, wherein the patient information is stored in a portable consumer device in the form of a card; creating a non-financial authorization request message, which relates to healthcare using the patient information, wherein creating the authorization request message comprises adding data to a data field to indicate that the authorization request message relates to a non-financial transaction; sending the authorization request message to an acquirer processor, wherein the acquirer processor sends the authorization request message to a transaction processing system, an issuer processor, and (optionally) then a healthcare processor; and receiving a response message from the healthcare processor, via the issuer processor, the transaction processing system, and the acquirer processor.
- In another implementation, a transmission addressed to a payment processing system is formed. The transmission may include an identifier of an account, associated with an insured, within the payment processing system (e.g., a Flexible Spending Account); a description of a healthcare related commodity (e.g., a good and/or service) for rendering to the patient deriving healthcare insurance through the insured; and a request for a specification of financial responsibility of the insured for the described said healthcare related commodity (e.g., inquiry for data regarding the patient's insurance coverage eligibility and/or the monetary responsibility value of the insured for healthcare related commodity rendered to a patient). A healthcare provider, such as a doctor or a pharmacy, may render the healthcare related commodity. A response to the request may be received from the addressed payment processing system. The reply may include the requested specification of financial responsibility.
- In another implementation, a first transmission addressed to a payment processing system is received, the first transmission including: an identifier of an account, associated with an insured, within the payment processing system; a description of a healthcare related commodity for rendering to a patient deriving healthcare insurance through the insured; and a request for a specification of financial responsibility of the insured for the described said healthcare related commodity. An insurance account identifier is determined and is based at least in part on the identifier of the account, wherein the insurance account identifier is associated with both the insured and the insurance carrier of the insured. A second transmission addressed to the insurance carrier is formed. The second transmission may include the insurance account identifier; the description of the healthcare related commodity; and the request for the specification of financial responsibility. A reply to the request from the addressed insurance carrier is received and may include the specification of financial responsibility. A third transmission addressed to the healthcare provider is formed, the third transmission including at least part of the reply.
- In yet another embodiment, an amount is received in return for a submission of an account in a payment system associated with an insured. The submission makes a request for a healthcare related commodity for rendering to a patient deriving healthcare insurance through the insured. The amount that is received is the amount that is owed by the insured for the healthcare related commodity for rendering to the patient. That is, the amount is owed for a good or service that has been or will be rendered to the patient.
-
FIG. 1 shows a block diagram of an exemplary system for implementing a process for determining healthcare coverage using a payment account; -
FIG. 2( a) shows a flowchart for an exemplary process for determining healthcare coverage using a payment account which may be implemented in the exemplary system ofFIG. 1 ; -
FIG. 2( b) shows a flowchart for an exemplary process for verification of using a health care account, -
FIGS. 3( a)-3(d) show flowcharts illustrating respective exemplary processes of or relating to a determination of healthcare coverage using a payment account which may be implemented in the exemplary system ofFIG. 1 ; -
FIG. 4 depicts a table illustrating, for an exemplary model system, activities prior to the rendering of a healthcare related commodity to a patient and activities at a point of care terminal; -
FIG. 5 depicts a table illustrating, for the exemplary model system ofFIG. 4 , exemplary activities at a point of care terminal and exemplary activities after the rendering of the healthcare related commodity to the patient; -
FIG. 6 depicts a table illustrating exemplary key components of the exemplary model system ofFIG. 4 ; -
FIG. 7 depicts a table illustrating, for the exemplary model system ofFIG. 4 , corresponding value propositions each of an exemplary third party healthcare information processor role and an exemplary transaction processor role; -
FIG. 8 shows a flowchart illustrating an exemplary process flow, which may be implemented in the exemplary system ofFIG. 1 , for the determination of an eligibility request for the rendering of a healthcare related commodity to a patient; -
FIG. 9 shows a flowchart illustrating an exemplary process flow, which may be implemented in conjunction with the exemplary process flow ofFIG. 8 , for an 835 claim payment; -
FIG. 10 shows a flowchart illustrating an exemplary data and process flow, which may be implemented in the exemplary system ofFIG. 4 , for the determination of an eligibility request for the rendering of a healthcare related commodity by a healthcare provider to a patient associated with an insured of a insurance carrier; -
FIG. 11 shows a block diagram depicting an exemplary data and process flow, which may be implemented in the exemplary data and process flow ofFIG. 11 , and illustrating interrelationships between a healthcare provider, an insurance carrier, and a sponsoring organization; -
FIG. 12 shows a block diagram of an exemplary payment system in which the exemplary system depicted inFIG. 1 may be implemented; and -
FIGS. 13 a and 13 b shows an illustration of a portable computing device. - Implementations of the invention solve the problems of conventional health information systems by enabling healthcare providers to electronically check the eligibility status of patients via simple POS terminals connecting over existing payment system networks using an eligibility-specific information transaction, not a payment authorization transaction. Specialized equipment is not required in implementations of the invention, so widespread acceptance is much more likely than systems that require the use of specialized hardware and/or communications equipment.
- Implementations of the invention send non-financial healthcare related messages through an existing financial network. As the messages are not financial in nature, the acquirers, the providers and the insurance carriers will not confuse financial transaction messages passing through the network with the non-financial healthcare related messages. These and other advantages provided by implementations of the invention are apparent from the following descriptions of implementations of the invention.
- In implementations of the invention, a patient's eligibility to status regarding healthcare insurance coverage for healthcare related good or service may be determined. The healthcare related good or service may be provided by a healthcare provider, and the eligibility determination may be made by an adjudication entity such as an insurance carrier. Examples of healthcare providers include doctors, dentists, eye care specialists, hospitals, laboratories, stores that sell healthcare related goods, injury clinics, a chiropractor, an entity that having at least one of a good and a service that is covered by the insurance plan, a provider of a healthcare service for compensation by the healthcare insurance of the insured, a provider of healthcare goods for compensation by the healthcare insurance of the insured and a combination thereof.
- Several types of eligibility responses are possible in implementations of the invention. These include a basic eligibility response, a basic eligibility with co-pay response, and an enhanced eligibility response. Each of these types of eligibility responses is described in further detail below.
- Basic Eligibility Response: The basic eligibility response message includes information regarding whether the patient is eligible for healthcare coverage. For example, a basic eligibility response may simply be a “Yes/No” type of response.
- Basic Eligibility with Co-Pay Response: The basic eligibility with co-pay response provides more information than the basic eligibility response. For example, in addition to a basic eligibility response message, the healthcare insurance carrier may provide information regarding a required co-pay amount. This helps to avoid problems when the patient does not remember or know the appropriate co-pay amount associated with the desired healthcare related good or service. In this case, both the eligibility status and co-pay amount are returned to the provider and/or the patient in a response message.
- Enhanced Eligibility Response: An enhanced eligibility response may also have more information than the basic eligibility response. For example, to support new trends in consumer-driven healthcare, healthcare insurance carriers may provide additional information regarding the plan type, plan contracted service amount, family or individual coverage, deductibles, co-insurance, co-pay amounts, etc. Examples of enhanced eligibility responses are provided below.
- In an illustrative implementation of the invention, a patient may swipe a payment card or health card at a healthcare provider's POS terminal. If a payment card is used, the card numbers are standard payment system card numbers issued in conformance with payment system standards.
- The transaction may be formatted by or at the POS terminal using the acquirer's-defined transaction type format for information transactions. A processing code may be entered (manually or automatically) into the POS terminal to indicate that the transaction is a non-financial eligibility request transaction. The created authorization request message is then forwarded to the provider's acquirer processor, through an International Standards Organization (ISO) payment transaction system (e.g., Visanet), and to a designated issuer processor. The transmissions between the various entities in the system may be completed in HIPAA-compliant manner (Health Insurance Portability and Accountability Act of 1996), both in format of the message and security requirements.
- The issuer, or its designated processor, identifies the transaction as a healthcare eligibility verification request. It then converts the patient's card number into the health insurance carrier's identification number for that individual. The issuer processor may then optionally forward the authorization request message (e.g., an eligibility authorization request message) to a healthcare processor.
- The healthcare processor then determines if the patient is eligible or not for healthcare insurance coverage. The insurance carrier (or an entity designated by the insurance carrier) who operates the healthcare processor checks the current eligibility status for the individual's identification number and responds with a status of “Yes,” currently eligible for healthcare insurance coverage or “No,” not currently eligible. Alternatively, if there is a more complicated eligibility issue to be resolved, then the healthcare provider may be requested to contact the insurance carrier. Additional information, such as the co-pay amount, may also be included in a response message.
- Once a response message is created, the healthcare or issuer processor transmits the response message including the eligibility determination back to the provider's POS terminal. The response message may be returned through the same path that the authorization request message (e.g., eligibility authorization request message) traveled, using appropriate message formats at each point in the process. Once the POS terminal receives the response message, the eligibility response information is then printed by the POS terminal and/or displayed at the POS terminal.
-
FIG. 1 shows a block diagram for a healthcare system according to an implementation of the invention. The system includes aprovider terminal 20 that is operated by a healthcare provider. The terminal 20 may be a POS (point of sale) terminal like those that are presently available to interact with ordinary payment cards. InFIG. 1 , oneterminal 20 and one provider are described for simplicity of illustration. It is understood that there may be many more terminals and many more providers in implementations of the invention. - The terminal 20 may interact with
portable consumer device 12. Examples of portable consumer devices include credit cards, debit cards, prepaid cards, healthcare insurance cards, smartcards, radio frequency identification (RFID) devices, driver's licenses, personal digital assistants, ATM cards, security badges, access badges, stored value cards, pagers, secure electronic account files, electronic token based account files, and the like. Interaction between the terminal 20 and theportable consumer device 12 may be facilitated using any suitable optical, magnetic, electromagnetic, or electronic mechanism. In some implementations, theportable consumer device 12 is in the form of a card and has a magnetic stripe. In other embodiments, theportable consumer device 12 may be stored electronically on a portable computing device, such as a smart phone, a portable media player, a flash drive or other form of electronic storage that may be accessed in a secure way. - The
portable consumer device 12 may store or display information such as BINs (bank identification numbers), card account number, patient name, patient healthcare number, birth date, card expiration date, employer name, employer/group policy number, dependent names/numbers, co-payment amounts, etc. In some embodiments, the data is stored in a secure manner such that only authorized users may access the potentially sensitive data stored on theportable consumer device 12. - The terminal 20 may be in communication with an
acquirer processor 22, which may be operated by an acquiring financial institution or by a third party processor on behalf of the acquiring financial institution. The acquiring financial institution may also process transactions for other merchants or sellers. Theacquirer processor 22 is used to conduct ordinary financial transactions, and thus may be in communication with other merchants or sellers and processors. - The
acquirer processor 22 may communicate with anissuer processor 26 via atransaction processing system 24. Thetransaction processing system 24 may be primarily used for processing financial transactions. It may facilitate transactions that occur between theacquirer processor 22 and theissuer processor 26. Thetransaction processing system 24 may be operated by an organization such as a credit or debit card company. - The
issuer processor 26 may be operated by an issuing financial institution such as a buyer bank, or another third party processor on behalf of the card issuer. A buyer (not shown) may interact with theissuer processor 26. The buyer may or may not be a healthcare consumer. In implementations of the invention, non-healthcare related buyers and sellers may use the same system as healthcare related buyers (e.g., patients) and sellers (e.g., service providers such as doctors). - The
issuer processor 26 may further be in communication with ahealthcare processor 27, which may be operated by an entity such as an insurance carrier or a third party processor that it designates. Ahealthcare database 29 may be in communication with thehealthcare processor 27. Thehealthcare database 29 may store information such as patient information, provider information, insurance plan information, service code information, etc. Alternatively, the healthcare database may be operated by the issuer processor or a third party processor on behalf of the issuer. - The various processors shown in
FIG. 1 (e.g., acquirer processor 22) may be embodied by any suitable combination of hardware and/or software. Typically, each processor includes at least a server computer. A server computer is a powerful computer or cluster of computers that behaves as a single computer which services the requests of one or more client computers. The server computer may be a mainframe computer, a minicomputer, or a minicomputer cluster. For example, the server computer may include one or more database servers and one or more Web servers. Software for performing any of the functions of the processors (or any of the functions described herein) may be embodied by computer code stored on a computer readable medium, which may store data using suitable electrical, electroptical, optical, or magnetic data storage mechanism. The computer code may be written in any suitable programming language including C, C++, Pascal, etc. - Also, the system shown in
FIG. 1 may be implemented using existing private networks or specialized communication networks (e.g., the Internet). The communication links may also include wired or wireless links. - More specific methods according to an implementation of the invention may be described with reference to
FIG. 2 , while also referring toFIG. 1 . - First, patient identification information may be received at a provider terminal 20 (step 30(a)). In some implementations, the patient may use a
portable consumer device 12 to provide patient identification information or other information to theprovider terminal 20. For example, the POS terminal transaction may be originated like any other payment card transaction. The patient may have a payment (credit, debit or prepaid/stored value) or healthcare card with a magnetic stripe. The magnetic striped card is swiped through a card reader in the provider'sterminal 20. Examples of patient identification information include credit, debit, or prepaid/stored value card numbers, health identification numbers, birth date, dependent names/numbers, social security numbers, drivers license numbers, etc. - Similarly, wireless transactions may also be used to communicate the patient identification information. As an example, the relevant patient identification information may be communicated in a secure wireless manner from a portable computing device 1300 (
FIG. 13 ) belonging to a user such as a smart phone or a smart watch to a payment reading device. In addition, the patient identify information may be stored in a virtual wallet and may be accessed by the providers terminal. Similarly, a user may have patient information for a plurality of family members (Grandma, spouse, children, grand-children, etc.) stored on the portable computing device and the patient information for the specific patient may be accessed and communicated. - The validity of the
portable consumer device 12 may be tested in a variety of ways. In some cases, the holder of anportable consumer device 12 may not be entitled to services as theportable consumer device 12 may be stolen or borrowed. If theportable consumer device 12 is a traditional card with a security chip, the card may be inserted into a reader where the security chip may be verified such as using an exchange of keys or a cryptographic algorithm stored in the chip. In yet another embodiment, a security hologram may be review to ensure theportable consumer device 12 is legitimate. Further, theportable consumer device 12 may have a photo of the card holder and the photo may be compared to the card holder to verify the holder is the proper user of theportable consumer device 12. - If the
portable consumer device 12 is in the form of an electronic file, additional measures may be available to ensure the patient is entitled to the healthcare listed in the patient identification information. In one embodiment, a fingerprint at the point of serviced may be matched to a stored fingerprint. In some embodiments, aportable computing device 1300 may have afingerprint reader 1310 and related software to compare a fingerprint at the point of presence to the stored fingerprint. In other embodiments, the service provider may have a separate fingerprint reader to obtain the fingerprint which is compared to a known fingerprint for the patient to ensure the current user is entitled to healthcare. - In yet another embodiment, an
image capturing device 1330 may be part of a computing device. An image of the user may be obtained by the computing device (either from the portable computing device or another computing device) and compared to a known image of acceptable users of the health care account. In some embodiments, the image may be of a face. In other embodiments, the image may be more specific such as of a retina. Of course, other images are possible and are contemplated. - In another embodiment, a user voice may be captured through a
microphone 1340 and compared to a previously created voice sample. The comparison may be locally such as through an application on a portable computing device or the voice sample may be communicated to the network to be verified remotely. In some additional embodiments, a user may be required to state a predetermined word or phrase that is known only to the user. - In yet another embodiment, a user of the health care account may be requested to provide verifying data to ensure the user is entitled to use the health care account. In a simple embodiment, a user may be asked to provide a code, an answer to one or more preset questions or a PIN that is verified, either locally or through the computing network. In an additional embodiment, the user may be required to answer preselected questions with predetermined answers using an input such as the input display 1320 (touch display) on a portable computing device.
- Referring briefly to
FIG. 13 b, theportable computing device 1300 may have aprocessor 1350 which may be physically configured according to computer executable instructions. Theportable computing device 1300 may also have amemory 1355 that may be physically configured to store the computer executable instructions and may assist theprocessor 1350. Theportable computing device 1300 may also have an input/output circuit 1360 which may assist in receiving inputs and providing outputs to users along with asound circuit 1365 and avideo circuit 1370. The various elements of theportable computing device 1300 may be combined into a single chip or circuit or may be separated such that unneeded elements may be turned off to save power. - If the user cannot be verified as being authorized to use the insurance account, the transaction may stop. The user may wish to communicate directly with the insurance carrier if the user believes there has been a mistake in denied the use of insurance. If the user is verified as having rights to use the insurance represented on the
portable consumer device 12, the approval process may continue. - Before or after the patient identification information is provided to the
provider terminal 20, the provider (or the patient) may provide healthcare service information to the terminal 20. A processing code may be entered (manually or automatically) into the POS terminal to indicate that the transaction is a non-financial eligibility transaction. For example, a processing code for a healthcare related, non-financial message might be indicated as “39” (or any other code), while a processing code for purchasing a good or service might be indicated by the code “00”. - In another example, service codes may be entered into the terminal 20. For example, provider staff may follow specified procedures, including entry of the healthcare-defined service type codes. These codes may be entered into the terminal 20 manually (e.g., by using input keys) or may be entered automatically. In other implementations, instead or in addition to healthcare services, healthcare goods information (e.g., SKU numbers) may be input into the terminal 20.
- There are a number of healthcare service codes. Some examples are as follows:
-
Service Code Definition 1 Medical Care 2 Surgical 50 Hospital - Outpatient 68 Well Baby Care 86 Emergency Services 98 Physician Office Visit A1 Physician Visit - Nursing Home AL Vision (Optometry) - Standard codes may be used for services or diagnoses. As an example, International Classification of Diseases propagated by the World Health Organization in Geneva, Switzerland (ICD-10) may be an appropriate manner of communicated the service. Of course, the International Classification of Diseases may be updated and expanded and such changes are contemplated by the system. A sample diagnosis code may be listed below:
- ICD-10-CM Diagnosis Codes:
- Are 3-7 digits;
-
-
Digit 1 is alpha; -
Digit 2 is numeric; - Digits 3-7 are alpha or numeric (alpha characters are not case sensitive); and
- A decimal is used after the third character.
-
-
-
- A78—Q fever;
- A69.21—Meningitis due to Lyme disease; and
- S52.131A—Displaced fracture of neck of right radius, initial encounter for closed fracture.
- After the patient information and the healthcare information are entered into and received by the terminal 20, an authorization request message (e.g., an eligibility authorization request message) may then be formatted at the terminal 20 (step 30(c)). The authorization request message may be formatted in a format specified by the acquirer or as an International Standards Organization (ISO) type, non-financial, information message. In some cases, the authorization request message may be an ISO 8583 type message, such as a standard (VisaNet) authorization request message. Information that may be included in the authorization request message is shown in the following table.
-
Data Element Description Length Card Number The card number assigned by the 16 (Numeric) issuing financial. Healthcare The medical license number of 9 (Numeric) Provider ID provider. Service A healthcare-defined standard 5 (Alpha- Type Code code for healthcare treatment. numeric) - In some implementations, data such as eligibility data associated with the patient may be added to a discretionary data field in the authorization request message. A discretionary data field is a field that may contain any particular information desired, for example, by an issuer. Additionally, discretionary data fields may be present in various data “tracks” that are present in many commercial credit and debit cards. Such data formats are defined by ANSI (American National Standards Institute).
- Once formatted, the authorization request message may then be communicated from the terminal 20 to the acquirer processor 22 (step 30(d)). The
acquirer processor 22 may then communicate the authorization request message to the transaction processing system 24 (e.g., VisaNet) (or “TPS”) (step 30(e)). - The transaction processing system 24 (e.g., VisaNet) then communicates the authorization request message to the designated issuer processor 26 (step 30(f)). A bank identification number (BIN), which is the first six digits of the card number, may be used to facilitate routing to the issuer, or its designated
processor 26. - After receiving the authorization request message associated with the specified BIN, the
issuer processor 26 may use a number of data fields to identify an eligibility request (processing code and BIN) and may convert the card number (e.g., a payment card number) to the insurance carrier's identification number for that patient (step 30(g)). The re-formatted message may then be communicated to the healthcare processor 27 (step 30(h)), which may be operated by an issuer processor or an insurance carrier, other payor, or other designated third party processor. The message format between theissuer processor 26 andhealthcare processor 29 may be any mutually agreed format. - The authorization request message may be evaluated in view of information from the
healthcare processor 27. In other words, the eligibility determination may be made by thehealthcare processor 27 or with information that is provided by thehealthcare processor 27. For example, after receiving the authorization request message associated with the patient's identification number, thehealthcare processor 27 may check the current eligibility status for the patient (step 30(i)). Patient data may be stored in thehealthcare information database 29 and thehealthcare processor 27 may contact thehealthcare database 29 to determine if the patient is eligible for the requested healthcare-related good or service. Thehealthcare processor 27 may then generate and sends a “yes” or “no” response back to the terminal 20, patient and provider. If approved and if applicable, thehealthcare processor 27 may also forward the required co-pay for that service type code for the patient's plan coverage. More specific descriptions of eligibility determination processes performed by thehealthcare processor 27 are provided below. - Any suitable response message format may be used. For example, the data to be transmitted from the
healthcare processor 27 back to the terminal 20 may be formatted in a standard ISO type authorization response at some point in the process. An exemplary authorization response may include the following: -
Data Element Description Length Card Number The card number assigned by the 16 (Numeric). issuing financial institution. Healthcare A medical license number of provider. 9 (Numeric) Provider ID Service A healthcare-defined standard code 5 (Alpha-. Type for healthcare treatment. numeric) Code Carrier An identification number that 6 (Numeric). ID identifies the health insurance carrier or payer. Approval or Healthcare-defined codes for 2 (Alpha- Reject approvals and rejections of Numeric) Reason Code eligibility inquiries (see below). Co-Pay The amount of the co-pay, if 10 (Numeric) Amount applicable. Carrier Carrier defined comments or Up to 200 Comments information. (Alpha- numeric). - There are a number of healthcare-defined codes for rejected requests. Some examples are as follows.
-
Reject Code Definition 15 Required application data missing 42 Unable to respond at current time 43 Invalid/Missing provider identification 52 Service dates not within provider plan environment 67 Patient not found - The response message may be communicated from the
issuer processor 26 to the terminal 20 along the path through which the authorization request message was transmitted. For example, thehealthcare processor 27 may communicate the response message to the issuer processor 26 (step 30(j)). Upon receiving the response message, theissuer processor 26 may convert the insurance carrier's identification number back to the patient's card number (e.g., payment card number) and may map the approval code and co-pay amounts into the designated fields of the authorization response message (step 30(k)). The authorization response message may then be communicated to the transaction processing system 24 (step 30(1)), and thetransaction processing system 24 may communicate the authorization request message to the acquirer processor 22 (step 30(m)). Theacquirer processor 22 then communicates the response message to the originating terminal 20 (step 30(n)). - After the request message is received at the terminal 20, the terminal 20 may display or print out the response message. If the response indicates an approval, the terminal 20 may print a receipt that shows the co-pay information and any additional text returned by the
healthcare processor 27. If the eligibility status cannot be confirmed, a decline response will be displayed on the receipt and additional manual verification procedures may be needed. - Implementations of the invention are not limited to the steps shown in
FIG. 2 . For example, the eligibility determination need not be performed by thehealthcare processor 27. In other implementations, carrier and patient information may be sent from thehealthcare processor 27 to theissuer processor 26, thetransaction processing system 24, and/or theacquirer processor 22. Theissuer processor 26, thetransaction processing system 24, and/or theacquirer processor 22 could then make the eligibility determination based on information received from thehealthcare processor 27. - The examples described above illustrate methods that employ basic eligibility determinations.
FIG. 2( b) is a sample a flowchart of sample steps in determining eligibility to using a health care account. At block 20(A), aportable consumer device 12 may be presented and read by a device at the point of service. At block 20(B), account data may be retrieved from theportable consumer device 12. At block 20(C), a request for verification data may be presented. As previously stated, the verification data may take a variety of forms and the verification may occur locally or through the network. At block 20(d), the verification data may be received. The verification data may vary and there may be a variety of acceptable verification data. At block 20(e), the determination may be made whether the verification data is acceptable. The verification determination may be made locally or through the network. Further, the verification may depend on the type of verification data received. At block 20(f), the acceptance or denial of the verification data may be communicated. - In one example, a card holder may present a
portable consumer device 12 such as a card to a service provider. Theportable consumer device 12 may have a chip and the card holder may be requested to insert theportable consumer device 12 into a card reader with chip reading capabilities and type in a personal identification number (PIN). If the PIN is acceptable, an approval may be noted and the user may continue through the blocks inFIGS. 3( a)-3(d). - In another example, a
portable consumer device 12 holder may present aportable consumer device 12 to a service provider in the form of a virtual card in an electronic wallet on a smart phone. The virtual card holder may use a fingerprint reader to verify that the virtual card holder is authorized to use the virtual card in the electronic wallet. If the fingerprint is accepted, the virtual card data in the virtual wallet may be communicated to the service provider. If the fingerprint is not accepted, a rejection may be communicated to the virtual card holder. - In yet another example, a user may have a traditional type credit card as the
portable consumer device 12. A user may input a PIN that is communicated through the network to the insurance company. If the PIN is correct, a positive signal will be returned through the payment network and if the PIN is not correct, a negative signal will be returned through the payment network. - In some embodiments, an out of band communication may be made to the account owner. Out of band may be considered another communication channel. For example, if an inquiry is made over the payment network, a SMS message may be sent over a cellular network or an email may be communicated through the Internet. In some embodiments, the out of band message may contain a pin or other code that may be needed to complete the verification.
- In yet a further embodiment, a tone may be communicated that must be played for the point of sale terminal for verification. As an example, the tone may be received by the point of sale terminal, may be converted to digital signals which may be communicated over the financial payment network to the insured for verification. As another example, an image may be communicated to the user of a portable computing device and the image need to be displayed to the card reader. The card reader may capture the image, communicate a digital version of the image through the financial payment network to be verified.
- In another embodiment, the message may simply be a notice that the account has been accessed and if the access is improper, to contact an authority. If the access is expected, the account holder may have to do nothing. If the access is not expected, an account holder may have to call the insurance company to stop the transaction.
-
FIGS. 3( a) to 3(d) show a flowchart illustrating steps in a more complicated eligibility determination process that may be performed by the healthcare processor 27 (or other entity). - Referring to
FIG. 3( a), thehealthcare processor 27 extracts patient identification information from the authorization request message (step 40(a)), and then determines whether or not the carrier participates (step 40(b)). The patient identification information in the authorization request message is compared to patient identification data in thehealthcare information database 29. As shown at decision step 40(c), if the patient identification information is matched to appropriate information in thehealthcare database 29, then the transaction proceeds to the next step 40(c). As shown at step 40(e), if the patient information cannot be matched to information in thehealthcare database 29, then the transaction is rejected. A response message with a reject reason code (e.g., “code 90: invalid/missing payor ID”) is created by thehealthcare processor 27. - If the
healthcare processor 27 determines that the patient is covered by the insurance carrier, then thehealthcare processor 27 determines what type of plan covers the patient (step 40(d)). If the patient has an indemnity plan type, then the process proceeds to the indemnity insurance plan subroutine A. If the patient has a POS (point of service) plan type, then the process proceeds to the POS insurance plan subroutine B. If the patient has an HMO or PPO plan type, then the process proceeds to the HMO/PPO insurance plan subroutine C. -
FIG. 3( b) shows a subroutine that is applicable if the patient is covered under an indemnity insurance plan. First, thehealthcare processor 27 determines if the patient is eligible for service (step 40(g)). If the patient is not covered, then the transaction is rejected by thehealthcare processor 27. If the patient is covered, thehealthcare processor 27 approves of the transaction (step 40(h)). -
FIG. 3( c) shows a subroutine that is applicable if the patient is covered under a POS insurance plan. Thehealthcare processor 27 determines if the patient is eligible for the healthcare related good or service (step 40(j)). If the patient is not eligible, the transaction is rejected (step 40(n)). If the patient is eligible, then thehealthcare processor 27 determines if the provider is in the patient's network (step 40(k)). If the patient is not eligible, then thehealthcare processor 27 determines an “out of network” co-pay amount (step 40(o)), and the transaction is approved (step 40(p)). If the provider is in the patient's network, then the “in network” co-pay amount is determined (step 40(1)), and the transaction is approved (step 40(m)). -
FIG. 3( d) shows a subroutine that is applicable if the patient is covered under an HMO or PPO plan type. First, thehealthcare processor 27 determines if the provider is part of the provider group (step 40(q)). If the provider is not part of the HMO/PPO provider group, then the transaction is rejected and a message indicating that the patient is not covered is sent from thehealthcare processor 27 back to the provider'sterminal 20. - If the provider is part of the provider group, then the
healthcare processor 27 determines if the patient is eligible for the service performed (step 40(r)). If not, then the transaction is rejected and a message indicating that the patient is not covered is sent from thehealthcare processor 27 back to the provider'sterminal 20. - If the patient is eligible for the healthcare related good or service, then the
healthcare processor 27 determines if the patient is covered by the service (step 40(s)). If not, then thehealthcare processor 27 seeks authorization to cover the service (step 40(x)). If the patient is eligible, then the patient's co-pay amount is determined and the transaction is approved (step 40(u)). - The specific implementations described above refer to transactions where the eligibility of the patient is determined. Other implementations of the invention may be used for “enhanced eligibility transactions”. There is a growing trend in the delivery of healthcare for individuals to assume a greater role for the payment of services. It is thought that consumers will exercise greater care, and be more cost conscious, in the purchase of healthcare services if they are responsible for directly paying for a greater proportion of their healthcare expenditures. This trend is referred to as consumer-driven or consumer-directed health care (CDHC). The advent of Health Savings Account (HSA) in December 2003 to complement high deductible health plans was a major step in the direction of CDHC. With high deductible health plans, individuals have much more discretion, and a greater stake, in the cost of healthcare services—as they will be paying 100% of the expenses up to the deductible amount of their health plan.
- Health Savings Accounts offered individuals covered by high deductible health plans an opportunity to save on a tax-advantaged (applies to federal income taxes and may or may not apply to state income taxes) an amount up to the deductible of the health plan.
- With this in mind, the healthcare provider potentially faces a more complicated situation in knowing how much to collect from the patient at the time of the visit. To give providers more information, the following data elements may be added in the authorization response message:
-
Data Element Description Length Card Number The card number assigned by the 16 (Numeric) issuing financial institution Healthcare The medical license number of 9 (Numeric) Provider ID provider. Service A healthcare-defined standard code 5 (Alpha- Type Code for healthcare treatment. numeric) Carrier ID An identification number that 6 (Numeric). identifies the health insurance carrier. Approval or Healthcare-defined codes for 6 (Numeric) Reject eligibility inquiries Reason Code. of approval and declines. Co-Pay The amount of the co-pay, if 10 (Numeric) Amount applicable. Insurance A code identifying the type of 3 (Alpha- Type Code insurance policy within a specific numeric) insurance program (e.g. “hm” for health maintenance organization, “mc” for Medicaid, “wc” for workers compensation). Coverage A code indicating the level of 3 (Alpha- Level Code coverage being provided for the numeric) patient, such as “employee only”, family”, etc. Contracted The contracted amount for the 12 (Numeric) Service service type code which the Amount provider has agreed to accept. Remaining The remaining amount of the 12 (Numeric) Deductible deductible which the insured Amount individual has to meet before the carrier will reimburse the provider. - Information such as this may assist a provider in knowing a contracted amount to charge for services under the patient's healthcare plan, and whether to collect from the patient, because the deductible amount has not been met and/or collect any co-pay amounts.
- In another implementation, the account associated with a payment processing system may be used to determine eligibility, co-payment, and adjudicated financial responsibility of an insured (e.g., a person responsible for payments to a healthcare provider under an insurance plan of the insurance carrier). The payment processing system may include an issuer such as the
issuer processor 26, an acquirer such asacquirer processor 22, a transaction handler such as the transaction processing system, and the insured. See text in the section entitled “Payment Processing System” in the later part of this application for a detailed discussion of the payment processing system. Moreover, account associated with the payment processing system may be used to transfer clinical information and concierge services to provide quality healthcare information and services. - Referring to
FIG. 4 , depicts a table illustrating, for an exemplary model system, activities prior to the rendering of a healthcare related commodity (e.g., a good or service for rendering to a patient deriving healthcare insurance through the insured) to a patient and activities at a point of care terminal. The insured, such as the patient, may receive a portable consumer device such as a flexible spending account, from the payment transaction system. The portable consumer device may be authenticated at this stage. The insured may log on to a secure website to set privacy settings for medical records of the insured, or other persons covered by the insured's insurance plan. The insured may also access the website to gain medical information such as information about a medical condition given symptoms of the medical condition. The insured may also access concierge type services from the payment transaction system including receiving refers for healthcare providers. - Once at a healthcare provider's facility, the insurer may use the account associated with the payment processing system to determine eligibility for the patient, determine the amount of co-payment the insured may be responsible for, determine the insured's monetary responsibility for healthcare related commodities rendered to the patient, and/or transfer basic medical records of the patient each of which may occur in real time. The phrase ‘real time’ may be understood to mean the duration of time that is needed to derive an amount owed by the insured for goods and/or services rendered to the patient. By way of example, the ‘real time period’ may be relatively short, such as about thirty seconds or less, of even the time period that the patient is at the facility of the healthcare provider. The reasons for the visit may be entered into the patient's medical records. Alternatively, the determination of the insured's monetary responsibility for healthcare related commodities rendered to the patient may occurs chronologically proximal to the rendering of the healthcare related commodity to the patient.
-
FIG. 5 depicts a table illustrating, for the exemplary model system ofFIG. 4 , exemplary activities at a point of care terminal and exemplary activities after the rendering of the healthcare related commodity to the patient. For example, the insured may swipe a bank card having an identifier of the account (e.g., account number) within the payment processing system at a terminal at the Point of Care (POC). A description of a healthcare related commodity for rendering to a patient deriving healthcare insurance through the insured may be uploaded into records maintained at the payment processing system. - For example, a transmission may be formed that is addressed to the acquirer of the healthcare provider. The transmission may include information such as the insured's account number within the payment processing system, the description of a healthcare related commodity for rendering to a patient deriving healthcare insurance through the insured, and a request for a specification of financial responsibility of the insured for the described healthcare related commodity.
- The request for the specification of financial responsibility of the insured may be an eligibility request, such as a request for eligibility indication for the patient as to insurance coverage through the insured for the described healthcare related commodity rendering the patient. The eligibility indication may include an indicia signifying that the patient is eligible for insurance coverage through the insured for the described healthcare related commodity; an indicia signifying that the patient is ineligible for insurance coverage through the insured for the described healthcare related commodity; and an indicia signifying that the patient is partially eligible for insurance coverage through the insured for the described said healthcare related commodity for rendering to the patient. For example, a request to determine if a child's flu shot is eligible to be covered by the insurance carrier of the insured that is the father of the child. The indicia may be that the child is eligible for coverage.
- The healthcare provider may receive a reply to the request from the addressed payment processing system. For example, the acquirer of the healthcare provider may forward the request to the payment transaction system. The payment transaction system may use an algorithm to convert the identifier of the account within the payment processing system to an insurance account identifier that is associated with both the insured and an insurance carrier. The payment transaction system may form a transmission addressed to an insurance carrier that includes the insurance account identifier, the description of the healthcare related commodity for rendering to the patient deriving healthcare insurance through the insured; and the request for the specification of financial responsibility of the insured for the described said healthcare related commodity (e.g., “how much is the adjudicated monetary responsibility of the insured for prescription medication.”). The payment transaction system may receive a reply to the transmission from the addressed insurance carrier including the specification of financial responsibility of the insured for the described said healthcare related commodity (e.g., $15 U.S. co-pay is due). The payment transaction system may form a transmission to the healthcare provider including at least part of the reply, such as a co-pay amount due, the adjudicated claim information based upon contracted rates, the identifier of the account within the payment processing system, the insurance account identifier, or a combination thereof.
- The healthcare provider may then bill the patient for the amount of that the insured is responsible for. By way of example, and not by way of limitation, the insured may choose to use the same account associated with the payment processing system. Such a choice may be made to make the payment by swiping the insured's portable consumer device issued to same by an issuer. Thereafter, the information gathered by the swiping of the portable consumer device is submitted as a financial authorization request to the payment processing system. The payment may be for at least a portion of the financial responsibility of the insured for the described healthcare related commodity. For example, the payment may be for a transaction with a healthcare provider of the healthcare related commodity for rendering to the patient. The provider of the healthcare related commodity may communicate the transaction to the acquirer. The acquirer may communicate the transaction to the payment transaction processor (e.g., the transaction handler). The payment transaction processor may communicate the transaction to the issuer and the issuer may communicate the transaction to the insured for payment.
- To illustrate, the healthcare provider may be a pharmacy. The insured may swipe the portable consumer device at the POC of the pharmacy. The request may include an identifier for the pharmacy and the identifier of the account associated with the payment processing system. A doctor's prescription for a diagnosed medical condition of the patient may have been previously uploaded into the patient's records maintained at the payment processing system. The reply to the request may include: the identifier for the account associated with the insured, the prescription, and the insured's responsible portion toward the payment for the prescribed medication.
- The insured may use the concierge service to complain of bad healthcare related commodities rendered to the patient.
- The payment transaction system may also facilitate the transfer of payment from the insurance carrier to the healthcare provider through such systems as the Visa ePay system. The Visa ePay system® is a fully automated, electronic payment delivery system that links financial institutions (e.g., acquirers and issuers), payment originators, billers, and credit counseling agencies such that online bill payments remain electronic from entry to posting.
- Referring to
FIG. 6 , a table illustrating exemplary key components of the exemplary model system ofFIG. 4 is depicted. Moreover, referring toFIG. 7 , a table illustrating, for the exemplary model system ofFIG. 4 , corresponding value propositions each of an exemplary third party healthcare information processor role and an exemplary transaction processor role is depicted. Components include advantages such as real-time access to information, greater efficiency in payments, risk management, and access to “quality” services through the concierge services. Roles include a description of what the payment transaction system, such as Visa, may process and a description of what a third party healthcare information processor, such as the Patient Safety Institute (PSI), may process. - Referring to
FIG. 8 , a flowchart illustrates an exemplary process flow, where the process may be implemented in the exemplary system ofFIG. 1 , for the determination of an eligibility request for the rendering of a healthcare related commodity to a patient. See United State's HIPAA, infra, regarding HIPAA standards. - At
FIG. 8 step 1, the provider may submit an eligibility request (HIPAA 270). The eligibility request may contain include information such as an identifier of the insured's account within the payment processing system, the description of a healthcare related commodity rendered to a patient covered by an insurance plan of the insured (e.g., “flu shot” or code 98 denoting “Physician Office Visit”), and specification of financial responsibility of the insured for the described said healthcare related commodity (e.g., “is the patient covered within the insured's insurance plan”). - At
FIG. 8 step 2, the acquirer may receive the eligibility request directly, such as through a virtual point of service (POS) connection. The virtual POS may be have a split dial connection at the healthcare provider's facility such that one line of the split dial is dedicated to the encrypted transmission of healthcare related data. Alternatively, a third party, such as PSI, may receive the eligibility request from the healthcare provider and forward at least part of the eligibility request to the acquirer. - At
FIG. 8 step 3, the eligibility request is routed to the appropriate insurance carrier, for example, through the payment transaction system.Step 3 ofFIG. 8 may entail the involvement of additional third party processors to assist with the routing of the eligibility request. - At
FIG. 8 step 4, the insurance carrier validates whether the patient is eligible under the insurance plan of the insured to be at least partially covered for the healthcare related commodity rendered to the patient. For example, a child of the insured may be listed under the insured's Humana Health Maintenance Organization (HMO) plan. The child has a rhinoplasty at a hospital. Once the insurance carrier receives the eligibility request from the payment transaction system, the insurance carrier may determine that the child is part of the Humana HMO plan, however, the rhinoplasty was an esthetic operation, the payment of which is not covered by the Humana HMO plan. - Referring to
FIG. 9 , a flowchart illustrating an exemplary process flow, which may be implemented in conjunction with the exemplary process flow ofFIG. 8 , for an 835 claim payment is shown. A payer, such as the insurance carrier, may pay the healthcare provider through an electronic payment delivery system such as the Visa ePay system®. - At
FIG. 9 step 2, the payer remits the response to the eligibility request to the electronic payment delivery system for healthcare related commodities rendered. For example, the electronic payment delivery system may create files containing the insurance carrier payments to the healthcare provider and make a ‘healthcare claim advise’ available to the healthcare provider. - At
FIG. 9 step 3, the electronic payment delivery system may transfer funds from an insurance carrier's bank (e.g., insurance carrier's acquirer) account to a healthcare provider's bank (e.g. insurance carrier's acquirer) account and route the created files to pay the healthcare provider's bank for the services rendered. - Referring to
FIG. 10 , a flowchart illustrating an exemplary data and process flow, which may be implemented in the exemplary system ofFIG. 4 , for the determination of an eligibility request for the rendering of a healthcare related commodity by a healthcare provider to a patient associated with an insured of an insurance carrier is shown. The communications may be in the form of electronic transmissions. The electronic transmission may include Electronic Protected Health Information (EPHI), which is may be governed by industry standards such as the American Health Insurance Portability and Accountability Act of 1996 (HIPAA). The transmissions may occur via the payment processing system, such as a credit card payment processing system. The payment of the patient financial responsibility may also occur via the payment processing system such as through the transmission of the transaction data (e.g., account number, account holder name, transaction cost, tax). - A terminal at the POS, may be used to send and receive the electronic transmissions. The terminal at the POS may have a split dial such that portions of the transmission may be sent to different addresses. The transmissions including the patient eligibility data, the patient financial responsibility data, and/or the transaction data for the payment of the patient financial responsibility may occur in real time such that the patient is physically present at the health care provider's facility as the transmissions occur (e.g., a period less than one hour) or a waiting period equivalent to the time the patient entered a facility of the healthcare provider and the time the healthcare provider renders the healthcare related commodity to the patient.
- The patient may use a portable consumer device to provide patient identification information or other information to the POS terminal. For example, the patient may have a payment (credit, debit or prepaid/stored value) or healthcare card with a magnetic stripe that has information about an account such as a credit card, a debit card, a saving account, a checking account, a stored value card account, a gift card account, a money market fund, a trust account, a Flexible Spending Account, a Managed Savings Account, a Dependent Care Reimbursement Account, a Health Care Reimbursement Account, Health Reimbursement Account, and a combination thereof. The magnetic striped card may be swiped through a card reader in the provider's POS terminal. The patient information may then be sent to the insurance carrier via the payment processing system.
- The electronic transmissions may include at least part of the patient information, such as the information obtained from the portable consumer device. For example, the transmission including patient financial responsibility data may have the patient name and patient insurance account number. Alternatively, or in combination, the patient information may be encrypted, hashed, a code may be used to determine other patient information such as by using a “look-up” table. For example patient information, such as a patient's credit card account number, may be included in the patient financial responsibility data transmission. The recipient of the transmission, or a third party, may utilize the patient's credit card account number to determine the patient's health insurance account number given access to a database that links the patient's credit card account number to the patient's health insurance account number.
- At
FIG. 10 step 1, upon patient check-in and authentication, the healthcare provider submits an eligibility request to the patient's insurance carrier. This request may be in theHIPAA 270 code format, and may include unique identifiers of the individual being treated, the health care provider, the health plan, and the employer, for example. - At
FIG. 10 step 2, the healthcare provider may capture a 270 message in a virtual POS terminal, which may be in-house or hosted by an external processor, and route this message to its Acquirer. - At
FIG. 10 step - At
FIG. 10 step 4, the Insurance carrier may validate patient eligibility, and route eligibility status message back to healthcare provider in theHIPAA 271 code format, for example. - At
FIG. 10 step 5, after treatment, healthcare provider may submit claims request to insurance carrier in theHIPAA 837 message format, for example. - At
FIG. 10 step 6, the transaction may follow the same route as the 270 message format. A message, such as a ‘835 message’, may be sent back to the healthcare provider confirming the patient responsibility. For example, when the insurance carrier has an auto adjudication system, and the submitted claim may in fact be auto adjudicated, the 835 message may be transmitted before the patient leaves the health care provider's office and the provider may bill and collect from the patient; alternatively, or in combination, for example if the claim cannot be auto adjudicated, the health care provider may collect the co-payment for the service rendered. - The American Health Insurance Portability and Accountability Act of 1996 (HIPAA) defines rules to ensure that all medical records, medical billing, and patient accounts meet certain consistent standards with regard to documentation, handling and privacy. Any healthcare provider that electronically stores, processes or transmits medical records, medical claims, remittances, or certifications must comply with HIPAA regulations. Fines for HIPAA non-compliance are up to $25,000 for multiple violations, $250,000 or imprisonment up to 10 years for knowing abuse or misuse of individually-identifiable health information.
- HIPAA Privacy Rule. The HIPAA Privacy Rule mandates the protection and privacy of all health information. This rule specifically defines the authorized uses and disclosures of “individually-identifiable” health information.
- HIPAA Security Rule. The HIPAA Security Rule mandates the security of electronic medical records (EMR). Unlike the Privacy Rule, which provides broader protection for all formats that health information make take, such as print or electronic information, the Security Rule addresses the technical aspects of protecting electronic health information.
- HIPAA Transactions and Code Set Rule. The HIPAA Transaction and Code Set Standard addresses the use of predefined transaction standards and code sets for communications and transactions in the health-care industry. The respective HIPAA transaction flows are illustrated in
FIG. 11 . Referring toFIG. 11 , shows a block diagram depicting an exemplary data and process flow, which may be implemented in the exemplary data and process flow ofFIG. 10 , and illustrating interrelationships between a healthcare provider, an insurance carrier, and a sponsoring organization is shown. - The Health Care Eligibility/Coverage/Benefit transactions are designed so that healthcare providers may determine whether an Information Source organization (payer, employer, Health Maintenance Organization “HMO”, etc) has a particular subscriber and/or dependent(s). The data available through these transaction sets may be used to verify an individual's eligibility or benefits: Health Care Eligibility/Coverage/Benefit Inquiry (270) transmits data from a submitter (information receiver) to an information source organization; Health Care Eligibility/Coverage/Benefit Information (271) transmits data from an information source organization to an information receiver.
- The following is an example of the overall structure of the 270 Transaction Set:
-
Eligibility or Coverage/Benefit Information Eligibility/Coverage/Benefit Information Source Source identifies the payer, maintainer, or Subscriber source of the eligibility or benefit information Dependent Eligibility/Coverage/Benefit Information Eligibility or Benefit Inquiry (Question) Receiver identifies the provider who Subscriber receives the eligibility or benefit information Dependent Subscriber identifies the employee or Eligibility or benefit Inquiry (Question) group member, or patient who is covered Eligibility or benefit Inquiry (Question) for insurance and to whom, or on behalf of whom, the insurer agrees to pay benefits Dependent identifies the person who is affiliated with the subscriber (spouse, child, etc.) - The corresponding 271 response may follow the same structure displayed above, with the Eligibility or Benefit Information replacing the Eligibility or Benefit Inquiry.
- The HIPAA Health Care Claim: Professional Transaction (837) is used for submitting professional claims and/or encounters to payers for payment. The transaction originates with the health care provider or the health care provider's designated agent or with payers in an encounter reporting situation. Information is sent to permit the destination payer to begin to adjudicate the claim. The Health Care Claim: Professional Transaction (837) coordinates with a variety of other transactions including, but not limited to Remittance Advice (835). It was designed specifically to address issues concerning the handling of coordination of benefits (COB) in a totally EDI environment, particularly COB transactions involving Medicare and Medicaid. One 837 may contain many claims from different providers all sent to one payer.
- The Health Care Claim Payment/Advice (835) transaction set is designed for the payment of claims and transfer of remittance information. It may be used to make the payment, send an Explanation of Benefits (EOB) remittance advice, or both. As a remittance advice, the 835 provides detailed payment information including, if applicable, the reasons why the total original charges were not paid in full. Note that insurance carriers may pay claims and send remittance advice in different ways (i.e., together or separately) and through different channels (i.e., directly to the provider or through financial institutions).
- As background information for the foregoing description, as will be readily understood by persons of ordinary skill in the art, a transaction such as a payment transaction, may include participation from different entities that are a component of the payment processing system as illustrated in
FIG. 12 . The payment processing system may include an issuer, a transaction handler, such as a credit card company, an acquirer, a merchant, such as a health care provider, or a consumer such as an insured having insurance coverage through which a patient receive healthcare benefits. The acquirer and the issuer may communicate through the transaction handler. The merchant may utilize at least one POS terminal that may communicate with the acquirer, the transaction handler, or the issuer. Thus, the POS terminal is in operative communication with the payment processing system. - Typically, a transaction begins with the consumer presenting a portable consumer device to the merchant to initiate an exchange for a good or service. The portable consumer device may include a payment card, a gift card, a smartcard, a smart media, a payroll card, a health care card, a wrist band, a machine readable medium containing account information, a keychain device such as the SPEEDPASS commercially available from ExxonMobil Corporation or a supermarket discount card, a cellular phone, personal digital assistant, a pager, a security card, an access card, a wireless terminal, or a transponder. The portable consumer device may include a volatile or non-volatile memory to store information such as the account number or an account holder's name.
- The Merchant may use the POS terminal to obtain account information, such as an account number, from the portable consumer device. The portable consumer device may interface with the POS terminal using a mechanism including any suitable electrical, magnetic, or optical interfacing system such as a contactless system using radio frequency or magnetic field recognition system or contact system such as a magnetic stripe reader. The POS terminal sends a transaction authorization request to the issuer of the portable consumer device. Alternatively, or in combination, the portable consumer device may communicate with the issuer, the transaction handler, or the acquirer.
- The Merchant may also use a
portable computing device 1300 such as a smart phone of the user as illustrated inFIGS. 13 a and 13 b. As previously mentioned, verification may be enabled through the portable computing device, such as using a fingerprint reader, receiving an out of band verification message, using the image capture device, etc. Theportable computing device 1300 may also have a virtual wallet that is accessed and used as part of the transaction. - The issuer may authorize the transaction using the transaction handler. The transaction handler may also clear the transaction. Authorization includes the issuer, or the transaction handler on behalf of the issuer, authorizing the transaction in connection with the issuer instructions such as through the use of business rules. The business rules could include instructions or guidelines from the transaction handler, the consumer, merchant, the acquirer, the issuer, a financial institution, or combinations thereof. The transaction handler may maintain a log or history of authorized transactions. Once approved, merchant will record the authorization, allowing the consumer to receive the good or service.
- Merchant may, at discrete periods, such as the end of the day, submit a list of authorized transactions to the acquirer or other components of the payment processing system. The transaction handler may compare the submitted authorized transaction list with its own log of authorized transactions. If a match is found, the transaction handler may route authorization transaction amount requests from the corresponding acquirer to the corresponding issuer involved in each transaction. Once the acquirer receives the payment of the authorized transaction amount from the issuer, it may forward the payment to merchant less any transaction costs, such as fees. If the transaction involves a debit or pre-paid card, the acquirer may choose not to wait for the initial payment prior to paying the merchant.
- There may be intermittent steps in the foregoing process, some of which may occur simultaneously. For example, the acquirer may initiate the clearing and settling process, which may result in payment to the acquirer for the amount of the transaction. The acquirer may request from the transaction handler that the transaction be cleared and settled. Clearing includes the exchange of financial information between the issuer and the acquirer and settlement includes the exchange of funds. The transaction handler may provide services in connection with settlement of the transaction. The settlement of a transaction includes depositing an amount of the transaction settlement from a settlement house, such as a settlement bank, which the transaction handler typically chooses, into a clearinghouse, such as a clearing bank, that the acquirer typically chooses. The issuer deposits the same from a clearinghouse, such as a clearing bank, which the issuer typically chooses into the settlement house. Thus, a typical transaction involves various entities to request, authorize, and fulfill processing the transaction.
- Implementations may be embodied as one or more of a method, a system, a device, and a computer program; where each method, system, device, and a computer program may include software and/or hardware components. Implementations are described using block diagrams and flowcharts to illustrate means for performing the described functions of the method, system, device, and computer program. The computer program may include a computer-readable storage medium having computer-readable program code means embodied in the storage medium. The system may include a host system including a processor for processing data, a memory in communication with the processor for storing the data, an input digitizer in communication with the memory and the processor for inputting the data into the memory; and an application program stored in the memory and accessible by the processor for directing processing of the data by the processor. The application program may be configured to perform a method. The system may include various integrated circuit components, such as microprocessors, controllers, memory elements, processing elements, logic elements, and look-up tables.
- The steps of a method, process, or algorithm described in connection with the implementations disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The various steps or acts in a method or process may be performed in the order shown or may be performed in another order. Additionally, one or more process steps may be omitted or one or more process steps may be added to the processes. An additional step, block, or action may be added in the beginning, end, or intervening existing elements of such processes.
- The above description of the disclosed embodiments is provided to enable any person of ordinary skill in the art to make or use the disclosure. Various modifications to these embodiments will be readily apparent to those of ordinary skill in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (22)
1. A processor-implemented method comprising:
accessing account information associated with an insured from a consumer portable device;
receiving verification data from a holder of the consumer portable device;
determining whether the holder of the consumer portable device is entitled to use an insured account associated with the consumer portable device based on the verification data;
if the determination is that the holder is entitled to use the consumer portable device,
instantiating a consumer portable device at a healthcare provider financial payment acceptance terminal;
forming, via a processor, at the healthcare provider financial payment acceptance terminal a healthcare coverage eligibility determination request including:
the account information associated with the insured;
a description of a healthcare related commodity for a patient deriving healthcare insurance through the insured; and
transmitting the healthcare coverage eligibility determination request to a payment processing system,
wherein the payment processing system is configured to process card-based financial payment transactions; and
receiving, in response to the healthcare coverage eligibility determination request the requested healthcare patient financial responsibility specification from the payment processing system.
2. The method as defined in claim 1 , wherein the payment processing system corresponds to an entity selected from the group consisting of: a payment transaction system; a transaction handler; an acquirer; an issuer; and a combination thereof.
3. The method as defined in claim 1 , wherein the insured is the patient.
4. The method as defined in claim 1 , wherein the healthcare related commodity is selected from a group consisting of:
a healthcare related good;
a healthcare related service; and
a combination thereof.
5. The method as defined in claim 1 , wherein the healthcare related commodity is provided by an entity selected from the group consisting of:
a provider of a healthcare service for compensation by the healthcare insurance of the insured;
a provider of healthcare goods for compensation by the healthcare insurance of the insured; and
a combination thereof.
6. The method as defined in claim 1 , wherein the account corresponds to a payment method selected from the group consisting of a
credit card,
a debit card,
a saving account,
a checking account,
a stored value card account,
a gift card account,
a money market fund, a trust account,
a Flexible Spending Account,
a Managed Savings Account,
a Dependent Care Reimbursement Account,
a Health Care Reimbursement Account,
Health Reimbursement Account, and
a combination thereof.
7. The method as defined in claim 1 , wherein the account information includes an account number for the account.
8. The method as defined in claim 1 , the specification of financial responsibility of the insured for the healthcare related commodity includes information selected from the group consisting of:
a request for a healthcare patient financial responsibility specification for said healthcare related commodity;
a healthcare provider identifier for a healthcare provider that has provided the healthcare related commodity to the patient;
a code associated with the healthcare related commodity;
a contracted amount due for the healthcare related commodity;
a textual message conveying the nature of the healthcare related commodity;
an International Classification of Diseases code according to IDC-10; and
a combination thereof.
9. The method as defined in claim 1 , wherein the requested specification of financial responsibility is selected from the group consisting of:
an amount due from the insured for the healthcare related commodity the patient;
an expense of the healthcare related commodity;
a deductible initial portion of a covered expense of the healthcare related commodity, said covered expense being payable by the insured before the insurance thereof pays the residual part of the covered expense; a remaining portion of the deductible initial portion;
a specification of a percentage of the deductible initial portion;
a remaining value of insurance available to the patient through the insured;
information about insurance available to the patient through the insured; and
a combination thereof.
10. The method as defined in claim 1 , wherein the specification of financial responsibility includes an eligibility indication for the patient as to insurance coverage through the insured for the healthcare related commodity.
11. The method as defined in claim 1 , wherein the specification of financial responsibility includes an eligibility indication for the patient as to insurance coverage through the insured for the healthcare related commodity, wherein the eligibility indication is selected from the group consisting of:
indicia signifying that the patient is eligible for insurance coverage through the insured for the healthcare related commodity;
indicia signifying that the patient is ineligible for insurance coverage through the insured for the healthcare related commodity; and
indicia signifying that the patient is partially eligible for insurance coverage through the insured for the healthcare related commodity.
12. The method as defined in claim 1 , further comprising: making a payment utilizing the account associated with the insured wherein the payment is at least a portion of the financial responsibility of the insured for the healthcare related commodity.
13. The method as defined in claim 1 , wherein the verification data comprises one selected from the group consisting of:
a voice sample,
a facial image;
a fingerprint;
a personal identification number (PIN); and
a preset answer to a personal question.
14. The method as defined in claim 1 , wherein the verification occurs over the payment network.
15. The method as defined in claim 1 , wherein an out of band signal is communicated to a preset address that access to an insurance account was attempted.
16. The method as defined in claim 1 , wherein an out of band signal is communicated to a preset address to verify that access is authorized.
17. The method as defined in claim 1 , wherein if the access is authorized, an acceptance of the access is made.
18. The method as defined in claim 1 , wherein:
the account is issued by an issuer;
the payment is for a transaction with a provider of the healthcare related commodity;
the provider of the healthcare related commodity communicates the transaction to an acquirer;
the acquirer communicates the transaction to a transaction handler;
the transaction handler communicates the transaction to the issuer; and
the issuer communicates the transaction to the insured for payment.
16. A processor-implemented method, comprising:
receiving, via a payment processing system, a healthcare coverage eligibility determination request formed at a healthcare provider financial payment acceptance terminal from a healthcare provider including:
an identifier of an account associated with an insured;
a description of a healthcare related commodity for a patient-deriving healthcare insurance-through the insured; and
a request for a healthcare patient financial responsibility specification for the healthcare related commodity; wherein the payment processing system is configured to process card-based financial payment transactions;
determining, via a processor, an insurance account identifier based at least in part on the identifier of the account, wherein the insurance account identifier is associated with both the insured and its insurance carrier;
transmitting the healthcare coverage eligibility determination request along with the insurance account identifier to the insurance carrier;
receiving a response to the transmitted healthcare coverage eligibility determination request from the insurance carrier, the response including the healthcare patient financial responsibility specification; and
transmitting at least a portion of the response to the health care provider.
17. The method as defined in claim 16 , wherein the determining further comprises using an algorithm to convert the identifier of the account to the insurance account identifier associated with the insured.
18. The method as defined in claim 16 , wherein the specification of financial responsibility includes an eligibility indication for the patient as to insurance coverage through the insured for the healthcare related commodity.
19. The method as defined in claim 18 , wherein the eligibility indication is selected from the group consisting of: indicia signifying that the patient is eligible for insurance coverage through the insured for the healthcare related commodity; indicia signifying that the patient is ineligible for insurance coverage through the insured for the healthcare related commodity; and indicia signifying that the patient is partially eligible for insurance coverage through the insured for the healthcare related commodity.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/231,115 US20140297304A1 (en) | 2005-01-04 | 2014-03-31 | Determination of healthcare coverage using a payment account |
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US64146405P | 2005-01-04 | 2005-01-04 | |
US64148305P | 2005-01-04 | 2005-01-04 | |
US64159705P | 2005-01-04 | 2005-01-04 | |
US11/230,761 US7650308B2 (en) | 2005-01-04 | 2005-09-20 | Auto substantiation for over-the-counter transactions |
US12/648,054 US8560446B2 (en) | 2005-01-04 | 2009-12-28 | Product level payment network acquired transaction authorization |
US14/017,652 US8688581B2 (en) | 2005-01-04 | 2013-09-04 | Product level payment network acquired transaction authorization |
US14/231,115 US20140297304A1 (en) | 2005-01-04 | 2014-03-31 | Determination of healthcare coverage using a payment account |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/017,652 Continuation US8688581B2 (en) | 2005-01-04 | 2013-09-04 | Product level payment network acquired transaction authorization |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140297304A1 true US20140297304A1 (en) | 2014-10-02 |
Family
ID=36641861
Family Applications (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/230,761 Active 2027-05-25 US7650308B2 (en) | 2005-01-04 | 2005-09-20 | Auto substantiation for over-the-counter transactions |
US12/648,054 Active US8560446B2 (en) | 2005-01-04 | 2009-12-28 | Product level payment network acquired transaction authorization |
US14/017,652 Active US8688581B2 (en) | 2005-01-04 | 2013-09-04 | Product level payment network acquired transaction authorization |
US14/231,115 Abandoned US20140297304A1 (en) | 2005-01-04 | 2014-03-31 | Determination of healthcare coverage using a payment account |
US14/231,065 Abandoned US20140214681A1 (en) | 2005-01-04 | 2014-03-31 | Product level payment network acquired transaction authorization |
Family Applications Before (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/230,761 Active 2027-05-25 US7650308B2 (en) | 2005-01-04 | 2005-09-20 | Auto substantiation for over-the-counter transactions |
US12/648,054 Active US8560446B2 (en) | 2005-01-04 | 2009-12-28 | Product level payment network acquired transaction authorization |
US14/017,652 Active US8688581B2 (en) | 2005-01-04 | 2013-09-04 | Product level payment network acquired transaction authorization |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/231,065 Abandoned US20140214681A1 (en) | 2005-01-04 | 2014-03-31 | Product level payment network acquired transaction authorization |
Country Status (5)
Country | Link |
---|---|
US (5) | US7650308B2 (en) |
EP (1) | EP1856663A4 (en) |
AU (1) | AU2006203968B2 (en) |
CA (1) | CA2611661A1 (en) |
WO (1) | WO2006074286A2 (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130218587A1 (en) * | 2012-02-22 | 2013-08-22 | Passport Health Communications, Inc. | Coverage Discovery |
US20130262249A1 (en) * | 2012-04-03 | 2013-10-03 | Blackhawk Network | Redemption Network with Transaction Sequencer |
US20150006307A1 (en) * | 2007-11-02 | 2015-01-01 | Citicorp Credit Services, Inc. | Methods and systems for managing transaction card accounts enabled for use with particular categories of providers and/or goods/services |
US10510046B2 (en) * | 2012-03-28 | 2019-12-17 | Passport Health Communications, Inc. | Proactive matching for coordination of benefits |
US20200342541A1 (en) * | 2019-04-26 | 2020-10-29 | Optum, Inc. | Medical identity theft alert system |
WO2020227727A3 (en) * | 2019-04-15 | 2020-12-17 | Global Care Analytics, Llc | Transaction analysis and asset recovery system |
US10878511B1 (en) * | 2012-05-30 | 2020-12-29 | Vpay, Inc. | Merchant portal system with explanation of benefits |
Families Citing this family (125)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8706630B2 (en) | 1999-08-19 | 2014-04-22 | E2Interactive, Inc. | System and method for securely authorizing and distributing stored-value card data |
US8301503B2 (en) * | 2001-07-17 | 2012-10-30 | Incucomm, Inc. | System and method for providing requested information to thin clients |
PT1442404E (en) | 2001-09-24 | 2014-03-06 | E2Interactive Inc | System and method for supplying communication service |
US7198704B2 (en) * | 2003-04-21 | 2007-04-03 | Microfabrica Inc. | Methods of reducing interlayer discontinuities in electrochemically fabricated three-dimensional structures |
US8655309B2 (en) | 2003-11-14 | 2014-02-18 | E2Interactive, Inc. | Systems and methods for electronic device point-of-sale activation |
US20100211493A9 (en) * | 2003-11-19 | 2010-08-19 | American Express Travel Related Services Company, Inc. | Incentive Programs For Healthcare Cards |
US7922083B2 (en) * | 2003-11-19 | 2011-04-12 | Harrison Sarah E | Payment programs for healthcare plans |
US20070011088A1 (en) * | 2005-07-08 | 2007-01-11 | American Express Company | Assured Payments for Health Care Plans |
WO2005077066A2 (en) * | 2004-02-09 | 2005-08-25 | American Express Travel Related Services Company, Inc. | System and method to reduce travel-related transaction fraud |
US20100070409A1 (en) * | 2004-11-19 | 2010-03-18 | Harrison Sarah E | Healthcare Card Incentive Program for Multiple Users |
US20070194108A1 (en) * | 2004-11-19 | 2007-08-23 | American Express Travel Related Services Company, Inc. | Assured Payments For Health Care Plans |
US20070185799A1 (en) * | 2004-11-19 | 2007-08-09 | American Express Travel Related Services Company, Inc. | Spending Account Systems and Methods |
US20070185800A1 (en) * | 2004-11-19 | 2007-08-09 | Harrison Sarah E | Spending Account Systems and Methods |
US7905399B2 (en) * | 2004-11-19 | 2011-03-15 | Barnes Brian T | Linking transaction cards with spending accounts |
US20070185802A1 (en) * | 2004-11-19 | 2007-08-09 | American Express Travel Related Services Company, Inc. | Incentive Programs For Healthcare Cards |
US8346910B2 (en) | 2004-11-30 | 2013-01-01 | American Express Travel Related Services Company, Inc. | Method and apparatus for managing an interactive network session |
US7650308B2 (en) | 2005-01-04 | 2010-01-19 | Visa U.S.A. Inc. | Auto substantiation for over-the-counter transactions |
US20060149603A1 (en) * | 2005-01-04 | 2006-07-06 | Barbara Patterson | Method and system for determining healthcare eligibility |
US20060149529A1 (en) * | 2005-01-04 | 2006-07-06 | Loc Nguyen | Method for encoding messages between two devices for transmission over standard online payment networks |
US20060151598A1 (en) * | 2005-01-13 | 2006-07-13 | Yen-Fu Chen | Categorization based spending control |
US7472822B2 (en) | 2005-03-23 | 2009-01-06 | E2Interactive, Inc. | Delivery of value identifiers using short message service (SMS) |
US20060213980A1 (en) * | 2005-03-25 | 2006-09-28 | Bluko Information Group | Method and system of detecting cash deposits and attributing value |
US7970626B2 (en) * | 2005-07-08 | 2011-06-28 | Oltine Acquistitions NY LLC | Facilitating payments to health care providers |
US8660862B2 (en) | 2005-09-20 | 2014-02-25 | Visa U.S.A. Inc. | Determination of healthcare coverage using a payment account |
US8301566B2 (en) * | 2005-10-20 | 2012-10-30 | American Express Travel Related Services Company, Inc. | System and method for providing a financial transaction instrument with user-definable authorization criteria |
US8636203B1 (en) * | 2005-12-06 | 2014-01-28 | Visa U.S.A. Inc. | Partial authorization of a financial transaction |
US20070203757A1 (en) * | 2006-02-28 | 2007-08-30 | Dibiasi John P | Healthcare debit card linked to healthcare-related and non-healthcare-related financial accounts |
US8788284B2 (en) * | 2006-05-30 | 2014-07-22 | Visa U.S.A. Inc. | Method and system using combined healthcare-payment device and web portal for receiving patient medical information |
CA2654562A1 (en) * | 2006-06-08 | 2007-12-21 | Visa U.S.A. Inc. | System and method using extended authorization hold period |
US20080314977A1 (en) * | 2006-06-08 | 2008-12-25 | American Express Travel Related Services Company, Inc. | Method, System, and Computer Program Product for Customer-Level Data Verification |
US9195985B2 (en) * | 2006-06-08 | 2015-11-24 | Iii Holdings 1, Llc | Method, system, and computer program product for customer-level data verification |
US20080010094A1 (en) * | 2006-06-21 | 2008-01-10 | Mark Carlson | Distribution of health information for providing health related services |
US7628319B2 (en) * | 2006-07-17 | 2009-12-08 | Mastercard International Incorporated | Method and system for enabling item-level approval of payment card |
US7769599B2 (en) * | 2006-07-31 | 2010-08-03 | Visa U.S.A. Inc. | Electronic payment delivery service |
US20080201224A1 (en) * | 2006-11-13 | 2008-08-21 | Nina Castro Owens | Method and apparatus for processing rewards |
US20080120234A1 (en) * | 2006-11-17 | 2008-05-22 | American Express Travel Related Services Company, Inc. | Variable Revenue Sharing For Multiple Account Payment Instruments |
US20080183627A1 (en) * | 2007-01-29 | 2008-07-31 | American Express Travel Related Services Company, Inc. | Filtered healthcare payment card linked to tax-advantaged accounts |
US7949543B2 (en) * | 2007-02-13 | 2011-05-24 | Oltine Acquisitions NY LLC | Methods, systems, and computer program products for promoting healthcare information technologies to card members |
US20080197188A1 (en) * | 2007-02-15 | 2008-08-21 | American Express Travel Related Services Company, Inc. | Transmission and capture of line-item-detail to assist in transaction substantiation and matching |
US20080319794A1 (en) * | 2007-06-20 | 2008-12-25 | Mark Carlson | Health information services using phone |
US20090006251A1 (en) * | 2007-06-28 | 2009-01-01 | American Express Travel Related Services Company, Inc. | Universal rollover account |
WO2009026460A1 (en) | 2007-08-23 | 2009-02-26 | Giftango Corporation | Systems and methods for electronic delivery of stored value |
US20090083065A1 (en) * | 2007-09-24 | 2009-03-26 | Discover Financial Services Llc | Automatic Substantiation of Health-Related Purchases Using a HIPAA-Unregulated Network |
US9747598B2 (en) | 2007-10-02 | 2017-08-29 | Iii Holdings 1, Llc | Dynamic security code push |
US20090132289A1 (en) * | 2007-11-20 | 2009-05-21 | Aetna Inc. | System and method for facilitating health savings account payments |
US8244611B2 (en) * | 2007-12-19 | 2012-08-14 | Metabank | Private label promotion card system, program product, and associated computer-implemented methods |
US8055557B2 (en) | 2007-12-21 | 2011-11-08 | Metabank | Transfer account systems, computer program products, and associated computer-implemented methods |
US8788414B2 (en) | 2007-12-21 | 2014-07-22 | Metabank | Transfer account systems, computer program products, and computer-implemented methods to prioritize payments from preselected bank account |
US8108279B2 (en) * | 2007-12-21 | 2012-01-31 | Metabank | Computer-implemented methods, program product, and system to enhance banking terms over time |
US20090171843A1 (en) * | 2007-12-28 | 2009-07-02 | George Lee | Universal funding card and delayed assignment of a funding instrument for a financial transaction |
US20090177488A1 (en) * | 2008-01-09 | 2009-07-09 | Discover Financial Services Llc | System and method for adjudication and settlement of health care claims |
US20090204498A1 (en) * | 2008-02-08 | 2009-08-13 | Scott Galit | Government Targeted-Spending Stimulus Card System, Program Product, And Computer-Implemented Methods |
US10515405B2 (en) | 2008-03-03 | 2019-12-24 | Metabank | Person-to-person lending program product, system, and associated computer-implemented methods |
WO2009124264A1 (en) | 2008-04-04 | 2009-10-08 | Metabank | System, program product, and method for debit card and checking account autodraw |
WO2009124262A1 (en) | 2008-04-04 | 2009-10-08 | Metabank | System, program product and method for performing an incremental automatic credit line draw using a prepaid card |
US8150764B2 (en) | 2008-04-04 | 2012-04-03 | Metabank | System, program product, and method to authorize draw for retailer optimization |
US20090313134A1 (en) * | 2008-05-02 | 2009-12-17 | Patrick Faith | Recovery of transaction information |
US8538879B2 (en) | 2008-05-14 | 2013-09-17 | Metabank | System, program product, and computer-implemented method for loading a loan on an existing pre-paid card |
US11227331B2 (en) | 2008-05-14 | 2022-01-18 | Metabank | System, program product, and computer-implemented method for loading a loan on an existing pre-paid card |
WO2009140520A1 (en) | 2008-05-14 | 2009-11-19 | Metabank | A pre-paid card transaction computer to load a loan on a pre-paid card |
KR20090130518A (en) * | 2008-06-16 | 2009-12-24 | 삼성전자주식회사 | Apparatus for providing product and method for providing gui using the same |
US20100057621A1 (en) * | 2008-06-30 | 2010-03-04 | Faith Patrick L | Payment processing system secure healthcare data trafficking |
US7594821B1 (en) | 2008-09-17 | 2009-09-29 | Yazaki North America, Inc. | Sealing gap formed by assembled connector parts |
US8024242B2 (en) | 2008-09-04 | 2011-09-20 | Metabank | System, method, and program product for foreign currency travel account |
WO2010028266A1 (en) | 2008-09-04 | 2010-03-11 | Metabank | System, program product and methods for retail activation and reload associated with partial authorization transactions |
US20100057554A1 (en) * | 2008-09-04 | 2010-03-04 | Mastercard International Incorporated | Method and System for Enabling Promotion of Product(s) and/or Service(s) |
US8403211B2 (en) | 2008-09-04 | 2013-03-26 | Metabank | System, program product and methods for retail activation and reload associated with partial authorization transactions |
US20100088207A1 (en) * | 2008-09-25 | 2010-04-08 | Mastercard International Incorporated | Method and System for Linkage of Generally Available Healthcare Accounts to Credit Card |
US8371502B1 (en) | 2008-10-28 | 2013-02-12 | Metabank | Shopping center gift card offer fulfillment machine, program product, and associated methods |
US8108977B1 (en) | 2008-10-31 | 2012-02-07 | Metabank | Machine, methods, and program product for electronic order entry |
US20100161404A1 (en) * | 2008-11-25 | 2010-06-24 | Mary Theresa Taylor | Promotional item identification in processing of an acquired transaction on an issued account |
US9213965B1 (en) | 2008-11-26 | 2015-12-15 | Metabank | Machine, methods, and program product for electronic inventory tracking |
US20100153265A1 (en) * | 2008-12-15 | 2010-06-17 | Ebay Inc. | Single page on-line check-out |
US8090649B2 (en) | 2008-12-18 | 2012-01-03 | Metabank | Computerized extension of credit to existing demand deposit accounts, prepaid cards and lines of credit based on expected tax refund proceeds, associated systems and computer program products |
US8175962B2 (en) | 2008-12-18 | 2012-05-08 | Metabank | Computerized extension of credit to existing demand deposit accounts, prepaid cards and lines of credit based on expected tax refund proceeds, associated systems and computer program products |
US8286863B1 (en) | 2009-02-04 | 2012-10-16 | Metabank | System and computer program product to issue a retail prepaid card including a user-designed external face using a chit and related computer implemented methods |
US9721238B2 (en) | 2009-02-13 | 2017-08-01 | Visa U.S.A. Inc. | Point of interaction loyalty currency redemption in a transaction |
US8285637B2 (en) * | 2009-04-01 | 2012-10-09 | American Express Travel Related Services Company, Inc. | Authorization request for financial transactions |
US20100276484A1 (en) * | 2009-05-01 | 2010-11-04 | Ashim Banerjee | Staged transaction token for merchant rating |
US8413905B2 (en) * | 2009-10-05 | 2013-04-09 | Visa U.S.A. Inc. | Portable prescription transaction payment device |
US8939356B2 (en) | 2009-06-08 | 2015-01-27 | Visa International Service Association | Portable prescription payment device management platform apparautses, methods and systems |
US10614458B2 (en) * | 2009-08-14 | 2020-04-07 | Visa U.S.A. Inc. | Influenza vaccine administration payment device processing |
US20110166872A1 (en) * | 2009-08-14 | 2011-07-07 | Cervenka Karen L | Auto-substantiation for healthcare upon sponsor account through payment processing system |
US20110082737A1 (en) | 2009-09-28 | 2011-04-07 | Crowe Andrew B | Computer-implemented methods, computer program products, and systems for management and control of a loyalty rewards network |
US20110079643A1 (en) * | 2009-10-05 | 2011-04-07 | Stacy Pourfallah | Prescription sample transaction payment card |
US20110137740A1 (en) | 2009-12-04 | 2011-06-09 | Ashmit Bhattacharya | Processing value-ascertainable items |
US9576323B2 (en) * | 2010-09-20 | 2017-02-21 | Sears Brands, L.L.C. | System for facilitating multi-channel purchase of FSA eligible items |
US9031869B2 (en) | 2010-10-13 | 2015-05-12 | Gift Card Impressions, LLC | Method and system for generating a teaser video associated with a personalized gift |
US9483786B2 (en) | 2011-10-13 | 2016-11-01 | Gift Card Impressions, LLC | Gift card ordering system and method |
US20120150694A1 (en) * | 2010-12-13 | 2012-06-14 | Devin Wade | Systems that allow multiple retailers the ability to participate in restricted spend card programs without managing multiple catalogs of eligible items associated with multiple card programs |
US20120150668A1 (en) * | 2010-12-13 | 2012-06-14 | Devin Wade | Methods for facilitating creation and management of item lists with unique identification codes for items and associating the lists to sponsor's payment financial transaction card programs |
WO2012122065A1 (en) * | 2011-03-04 | 2012-09-13 | Visa International Service Association | Healthcare wallet payment processing apparatuses, methods and systems |
US9589266B2 (en) | 2011-04-01 | 2017-03-07 | Visa International Service Association | Restricted-use account payment administration apparatuses, methods and systems |
US9760871B1 (en) | 2011-04-01 | 2017-09-12 | Visa International Service Association | Event-triggered business-to-business electronic payment processing apparatuses, methods and systems |
US8447693B2 (en) * | 2011-04-13 | 2013-05-21 | Citicorp Credit Services, Inc. | Methods and systems for routing payment transactions |
US20140229256A1 (en) | 2013-02-11 | 2014-08-14 | Solutran | Product substantiation using approved product list system and method |
US9240011B2 (en) | 2011-07-13 | 2016-01-19 | Visa International Service Association | Systems and methods to communicate with transaction terminals |
US8620806B2 (en) * | 2011-07-13 | 2013-12-31 | Mastercard International Incorporated | Merchant data cleansing in clearing record |
US10417677B2 (en) | 2012-01-30 | 2019-09-17 | Gift Card Impressions, LLC | Group video generating system |
US10360578B2 (en) | 2012-01-30 | 2019-07-23 | Visa International Service Association | Systems and methods to process payments based on payment deals |
US8719167B2 (en) | 2012-03-02 | 2014-05-06 | American Express Travel Related Services Company, Inc. | Systems and methods for enhanced authorization fraud mitigation |
US8880431B2 (en) | 2012-03-16 | 2014-11-04 | Visa International Service Association | Systems and methods to generate a receipt for a transaction |
US9460436B2 (en) | 2012-03-16 | 2016-10-04 | Visa International Service Association | Systems and methods to apply the benefit of offers via a transaction handler |
US9922338B2 (en) | 2012-03-23 | 2018-03-20 | Visa International Service Association | Systems and methods to apply benefit of offers |
US9495690B2 (en) | 2012-04-04 | 2016-11-15 | Visa International Service Association | Systems and methods to process transactions and offers via a gateway |
US9864988B2 (en) * | 2012-06-15 | 2018-01-09 | Visa International Service Association | Payment processing for qualified transaction items |
US9626678B2 (en) | 2012-08-01 | 2017-04-18 | Visa International Service Association | Systems and methods to enhance security in transactions |
US10438199B2 (en) | 2012-08-10 | 2019-10-08 | Visa International Service Association | Systems and methods to apply values from stored value accounts to payment transactions |
US10685367B2 (en) | 2012-11-05 | 2020-06-16 | Visa International Service Association | Systems and methods to provide offer benefits based on issuer identity |
US10552861B2 (en) | 2013-02-11 | 2020-02-04 | Solutran, Inc. | Dual redemption path with shared benefits system and method |
US9565911B2 (en) | 2013-02-15 | 2017-02-14 | Gift Card Impressions, LLC | Gift card presentation devices |
US11219288B2 (en) | 2013-02-15 | 2022-01-11 | E2Interactive, Inc. | Gift card box with slanted tray and slit |
US10217107B2 (en) | 2013-05-02 | 2019-02-26 | Gift Card Impressions, LLC | Stored value card kiosk system and method |
US20150039453A1 (en) * | 2013-06-18 | 2015-02-05 | Mastercard International Incorporated | Ngo electronic transaction management system and method |
US10002366B2 (en) * | 2013-07-16 | 2018-06-19 | Cardfree, Inc. | Systems and methods for transaction processing using various value types |
US20150095186A1 (en) * | 2013-09-30 | 2015-04-02 | Jayasree Mekala | Flexible spending account provision system |
US10163106B2 (en) | 2014-04-07 | 2018-12-25 | Visa International Service Association | Systems and methods using a data structure summarizing item information in authorization request messages for communication in transactions involving multiple items |
US10262346B2 (en) | 2014-04-30 | 2019-04-16 | Gift Card Impressions, Inc. | System and method for a merchant onsite personalization gifting platform |
US9792610B2 (en) | 2014-07-08 | 2017-10-17 | Mastercard International Incorporated | Non-payment communications using payment transaction network |
WO2016019118A1 (en) | 2014-07-30 | 2016-02-04 | Wal-Mart Stores, Inc. | Apparatus and method for self-service voucher creation |
US10325251B2 (en) | 2015-10-22 | 2019-06-18 | Mastercard International Incorporated | Apparatus, method, and computer program product for secure, privacy-aware qualified expenditure tracking in an ISO 8583 network or the like |
US20170132652A1 (en) * | 2015-11-11 | 2017-05-11 | Mastercard International Incorporated | Systems and Methods for Processing Loyalty Rewards |
US10210582B2 (en) * | 2015-12-03 | 2019-02-19 | Mastercard International Incorporated | Method and system for platform data updating based on electronic transaction product data |
US10954049B2 (en) | 2017-12-12 | 2021-03-23 | E2Interactive, Inc. | Viscous liquid vessel for gifting |
WO2020014434A1 (en) * | 2018-07-11 | 2020-01-16 | Mastercard International Incorporated | Systems and methods for use in permitting restricted network transactions |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20010053986A1 (en) * | 2000-06-19 | 2001-12-20 | Dick Richard S. | Method and apparatus for requesting, retrieving, and normalizing medical information |
US20020198831A1 (en) * | 2001-06-11 | 2002-12-26 | Patricelli Robert E. | System and method for processing flexible spending account transactions |
Family Cites Families (140)
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 |
US5018067A (en) * | 1987-01-12 | 1991-05-21 | Iameter Incorporated | Apparatus and method for improved estimation of health resource consumption through use of diagnostic and/or procedure grouping and severity of illness indicators |
US5070452A (en) | 1987-06-30 | 1991-12-03 | Ngs American, Inc. | Computerized medical insurance system including means to automatically update member eligibility files at pre-established intervals |
US4962468A (en) * | 1987-12-09 | 1990-10-09 | International Business Machines Corporation | System and method for utilizing fast polygon fill routines in a graphics display system |
ZA907106B (en) | 1989-10-06 | 1991-09-25 | Net 1 Products Pty Ltd | Funds transfer system |
US5235507A (en) * | 1990-01-16 | 1993-08-10 | P. B. Toau And Company, Ltd. | Health insurance management system |
US5324077A (en) * | 1990-12-07 | 1994-06-28 | Kessler Woodrow B | Medical data draft for tracking and evaluating medical treatment |
US5301105A (en) * | 1991-04-08 | 1994-04-05 | Desmond D. Cummings | All care health management system |
US5335278A (en) * | 1991-12-31 | 1994-08-02 | Wireless Security, Inc. | Fraud prevention system and process for cellular mobile telephone networks |
US6012035A (en) * | 1993-07-08 | 2000-01-04 | Integral Business Services, Inc. | System and method for supporting delivery of health care |
US5644778A (en) * | 1993-11-02 | 1997-07-01 | Athena Of North America, Inc. | Medical transaction system |
US5550734A (en) * | 1993-12-23 | 1996-08-27 | The Pharmacy Fund, Inc. | Computerized healthcare accounts receivable purchasing collections securitization and management system |
US5832447A (en) * | 1994-05-24 | 1998-11-03 | Envoy Corporation | Automated system and method for providing real-time verification of health insurance eligibility |
US5717989A (en) * | 1994-10-13 | 1998-02-10 | Full Service Trade System Ltd. | Full service trade system |
US7996260B1 (en) * | 1995-11-13 | 2011-08-09 | Trialcard, Inc. | Promotional carrier for promoting pharmaceutical prescription products |
US5628530A (en) * | 1995-12-12 | 1997-05-13 | Info Tec Llc | Method and system for collectively tracking demographics of starter drug samples |
US6044352A (en) * | 1996-01-11 | 2000-03-28 | Deavers; Karl | Method and system for processing and recording the transactions in a medical savings fund account |
CA2253920A1 (en) * | 1996-05-10 | 1997-12-04 | David M. Barcelou | Automated transaction machine |
US5965860A (en) * | 1996-05-28 | 1999-10-12 | Fujitsu Limited | Management system for using IC card with registered personal information |
US5915241A (en) * | 1996-09-13 | 1999-06-22 | Giannini; Jo Melinna | Method and system encoding and processing alternative healthcare provider billing |
US5995939A (en) * | 1996-10-15 | 1999-11-30 | Cymedix Lynx Corporation | Automated networked service request and fulfillment system and method |
JP3660101B2 (en) | 1996-11-14 | 2005-06-15 | 松下電器産業株式会社 | Personal electronic payment system |
US6112183A (en) * | 1997-02-11 | 2000-08-29 | United Healthcare Corporation | Method and apparatus for processing health care transactions through a common interface in a distributed computing environment |
US6082776A (en) * | 1997-05-07 | 2000-07-04 | Feinberg; Lawrence E. | Storing personal medical information |
US7519558B2 (en) | 1997-08-27 | 2009-04-14 | Ballard Claudio R | Biometrically enabled private secure information repository |
US6915265B1 (en) * | 1997-10-29 | 2005-07-05 | Janice Johnson | Method and system for consolidating and distributing information |
US6208973B1 (en) * | 1998-02-27 | 2001-03-27 | Onehealthbank.Com | Point of service third party financial management vehicle for the healthcare industry |
US6343271B1 (en) * | 1998-07-17 | 2002-01-29 | P5 E.Health Services, Inc. | Electronic creation, submission, adjudication, and payment of health insurance claims |
CA2336303A1 (en) * | 1999-04-28 | 2000-11-02 | Alean Kirnak | Electronic medical record registry including data replication |
US6529884B1 (en) * | 1999-07-14 | 2003-03-04 | Lucent Technologies, Inc. | Minimalistic electronic commerce system |
US6877655B1 (en) * | 1999-08-04 | 2005-04-12 | Canon Kabushiki Kaisha | Providing services utilizing a smart card |
US8751250B2 (en) | 1999-08-09 | 2014-06-10 | First Data Corporation | Health care eligibility verification and settlement systems and methods |
US20040148203A1 (en) | 2002-10-08 | 2004-07-29 | First Data Corporation | Systems and methods for verifying medical insurance coverage |
US20050015280A1 (en) * | 2002-06-11 | 2005-01-20 | First Data Corporation | Health care eligibility verification and settlement systems and methods |
US20020152180A1 (en) * | 1999-09-10 | 2002-10-17 | Paul Turgeon | System and method for performing secure remote real-time financial transactions over a public communications infrastructure with strong authentication |
US6401079B1 (en) | 1999-10-01 | 2002-06-04 | Inleague, Inc. | System for web-based payroll and benefits administration |
US6850901B1 (en) * | 1999-12-17 | 2005-02-01 | World Theatre, Inc. | System and method permitting customers to order products from multiple participating merchants |
US7490048B2 (en) * | 1999-12-18 | 2009-02-10 | Raymond Anthony Joao | Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information |
US6629081B1 (en) * | 1999-12-22 | 2003-09-30 | Accenture Llp | Account settlement and financing in an e-commerce environment |
EP1252595A2 (en) * | 2000-01-12 | 2002-10-30 | Metavante Corporation | Integrated systems for electronic bill presentment and payment |
US20010037295A1 (en) * | 2000-01-31 | 2001-11-01 | Olsen Karl R. | Push model internet bill presentment and payment system and method |
US6988075B1 (en) * | 2000-03-15 | 2006-01-17 | Hacker L Leonard | Patient-controlled medical information system and method |
CA2305249A1 (en) * | 2000-04-14 | 2001-10-14 | Branko Sarcanin | Virtual safe |
CA2407653A1 (en) | 2000-04-24 | 2001-11-01 | Visa International Service Association | Online payer authentication service |
WO2001086558A1 (en) * | 2000-05-09 | 2001-11-15 | Metavante Corporation | Electronic bill presentment and payment system |
US7295988B1 (en) | 2000-05-25 | 2007-11-13 | William Reeves | Computer system for optical scanning, storage, organization, authentication and electronic transmitting and receiving of medical records and patient information, and other sensitive legal documents |
WO2001095208A1 (en) * | 2000-06-02 | 2001-12-13 | Iprint.Com, Inc. | Integrated electronic shopping cart system and method |
US20020002534A1 (en) | 2000-06-27 | 2002-01-03 | Davis Terry L. | Method and system for managing transactions |
US7428494B2 (en) * | 2000-10-11 | 2008-09-23 | Malik M. Hasan | Method and system for generating personal/individual health records |
US7072842B2 (en) * | 2001-01-08 | 2006-07-04 | P5, Inc. | Payment of health care insurance claims using short-term loans |
US6400179B1 (en) * | 2001-01-25 | 2002-06-04 | Dell Products L.P. | Method for termination of signal lines with discrete biased diodes |
US20020147678A1 (en) * | 2001-02-02 | 2002-10-10 | Mellon Bank, N.A. | Adjudication method and system |
US7552061B2 (en) * | 2001-03-06 | 2009-06-23 | Gregory Richmond | Method and system for providing prescription drug coverage |
US7493266B2 (en) * | 2001-03-21 | 2009-02-17 | Gupta Amit K | System and method for management of health care services |
US7246068B2 (en) * | 2001-03-23 | 2007-07-17 | Thomas Jr James C | Computerized system for combining insurance company and credit card transactions |
TW200408987A (en) | 2002-11-20 | 2004-06-01 | Momenta Inc Taiwan | System and method for assisting in selling vehicles |
US20030040939A1 (en) * | 2001-08-24 | 2003-02-27 | Daniel Tritch | Method of storing and retrieving advance medical directives |
JP2003099541A (en) * | 2001-09-20 | 2003-04-04 | Sharp Corp | Medical information system |
US20030083903A1 (en) | 2001-10-30 | 2003-05-01 | Myers Gene E. | Method and apparatus for contemporaneous billing and documenting with rendered services |
US6950969B2 (en) * | 2001-12-28 | 2005-09-27 | Hewlett-Packard Development Company, L.P. | Cascadable dual fan controller |
US7647320B2 (en) | 2002-01-18 | 2010-01-12 | Peoplechart Corporation | Patient directed system and method for managing medical information |
AU2003212867A1 (en) * | 2002-01-30 | 2003-09-02 | Mastercard International Incorporated | System and method for conducting secure payment transaction |
US20030193185A1 (en) * | 2002-04-15 | 2003-10-16 | Valley Jeffrey M. | Prescription pharmaceutical labeling system |
US7925518B2 (en) * | 2002-04-19 | 2011-04-12 | Visa U.S.A. Inc. | System and method for payment of medical claims |
WO2003104945A2 (en) | 2002-06-11 | 2003-12-18 | First Data Corporation | Value processing network and methods |
US20040006490A1 (en) * | 2002-07-08 | 2004-01-08 | Gingrich Mark A. | Prescription data exchange system |
US7219149B2 (en) * | 2003-06-12 | 2007-05-15 | Dw Holdings, Inc. | Versatile terminal adapter and network for transaction processing |
US20040172312A1 (en) * | 2002-11-15 | 2004-09-02 | Selwanes Ragui N. | Method, system and storage medium for facilitating multi-party transactions |
US20040103000A1 (en) * | 2002-11-26 | 2004-05-27 | Fori Owurowa | Portable system and method for health information storage, retrieval, and management |
US7389430B2 (en) * | 2002-12-05 | 2008-06-17 | International Business Machines Corporation | Method for providing access control to single sign-on computer networks |
US20040138999A1 (en) * | 2003-01-13 | 2004-07-15 | Capital One Financial Corporation | Systems and methods for managing a credit account having a credit component associated with healthcare expenses |
US7752096B2 (en) * | 2003-02-19 | 2010-07-06 | Avisena, Inc. | System and method for managing account receivables |
US20040186746A1 (en) * | 2003-03-21 | 2004-09-23 | Angst Wendy P. | System, apparatus and method for storage and transportation of personal health records |
US20040210520A1 (en) * | 2003-04-02 | 2004-10-21 | Fitzgerald Daleen R. | Bill payment payee information management system and method |
US7797192B2 (en) * | 2003-05-06 | 2010-09-14 | International Business Machines Corporation | Point-of-sale electronic receipt generation |
US20040249745A1 (en) | 2003-06-06 | 2004-12-09 | Baaren Sharon A. Van | System and method for automatically adjudicating transactions involving an account reserved for qualified spending |
US20050010448A1 (en) * | 2003-07-07 | 2005-01-13 | Mattera John A. | Methods for dispensing prescriptions and collecting data related thereto |
US20050065824A1 (en) * | 2003-07-15 | 2005-03-24 | Mark Kohan | Data privacy management systems and methods |
US20050033609A1 (en) * | 2003-08-05 | 2005-02-10 | Yonghong Yang | Healthcare system integrated with a healthcare transaction processor, and method for providing healthcare transaction processing services |
US20050038675A1 (en) | 2003-08-12 | 2005-02-17 | Siekman Jeffrey A. | Methods and systems for at-home and community-based care |
US20050065819A1 (en) * | 2003-09-19 | 2005-03-24 | Schultz Pamela Lynn | Electronic reimbursement process for provision of medical services |
US8825502B2 (en) | 2003-09-30 | 2014-09-02 | Epic Systems Corporation | System and method for providing patient record synchronization in a healthcare setting |
JP2005124991A (en) | 2003-10-27 | 2005-05-19 | Junko Suginaka | Portable storage medium and dosage notification device |
US20050119918A1 (en) * | 2003-11-07 | 2005-06-02 | Berliner Roger D. | Payment management system and method |
US20070143215A1 (en) * | 2004-02-06 | 2007-06-21 | Willems Serge Clement D | Device, system and method for storing and exchanging medical data |
US20050182721A1 (en) * | 2004-02-17 | 2005-08-18 | Gershon Weintraub | Remittance information processing system |
US20050187790A1 (en) * | 2004-02-24 | 2005-08-25 | Joshua Lapsker | Reusable discount card and prescription drug compliance system |
US8100332B2 (en) | 2004-02-26 | 2012-01-24 | Ifuel, Llc | Payments using pre-paid accounts |
US20050209893A1 (en) * | 2004-03-18 | 2005-09-22 | Nahra John S | System and method for identifying and servicing medically uninsured persons |
US20060010007A1 (en) * | 2004-07-09 | 2006-01-12 | Denman John F | Process for using smart card technology in patient prescriptions, medical/dental/DME services processing and healthcare management |
US7039628B2 (en) * | 2004-04-21 | 2006-05-02 | Logan Jr Carmen | Portable health care history information system |
US8732001B2 (en) | 2004-06-08 | 2014-05-20 | Robert G. Previdi | Apparatus and method for rewarding consumers |
US8583450B2 (en) * | 2004-07-29 | 2013-11-12 | Ims Health Incorporated | Doctor performance evaluation tool for consumers |
US20060173712A1 (en) * | 2004-11-12 | 2006-08-03 | Dirk Joubert | Portable medical information system |
US20060111943A1 (en) * | 2004-11-15 | 2006-05-25 | Wu Harry C | Method and system to edit and analyze longitudinal personal health data using a web-based application |
WO2006055630A2 (en) * | 2004-11-16 | 2006-05-26 | Health Dialog Data Service, Inc. | Systems and methods for predicting healthcare related risk events and financial risk |
US20060106645A1 (en) * | 2004-11-17 | 2006-05-18 | Adhd Systems, Llc | System and methods for tracking medical encounters |
US20060106646A1 (en) * | 2004-11-18 | 2006-05-18 | Eastman Kodak Company | Medical kiosk with multiple input sources |
US7866548B2 (en) * | 2004-12-01 | 2011-01-11 | Metavante Corporation | Account control method and system that allows only eligible and authorized items to be purchased using the account |
US20060136270A1 (en) | 2004-12-02 | 2006-06-22 | Morgan John D | Medical claim data transfer to medical deposit box and/or medical visit record |
US20060129435A1 (en) * | 2004-12-15 | 2006-06-15 | Critical Connection Inc. | System and method for providing community health data services |
US20060149603A1 (en) | 2005-01-04 | 2006-07-06 | Barbara Patterson | Method and system for determining healthcare eligibility |
US20060149529A1 (en) * | 2005-01-04 | 2006-07-06 | Loc Nguyen | Method for encoding messages between two devices for transmission over standard online payment networks |
US7650308B2 (en) * | 2005-01-04 | 2010-01-19 | Visa U.S.A. Inc. | Auto substantiation for over-the-counter transactions |
CA2642080A1 (en) * | 2005-02-11 | 2006-08-17 | Hipaat Inc. | System and method for privacy managemen |
US20060229911A1 (en) * | 2005-02-11 | 2006-10-12 | Medcommons, Inc. | Personal control of healthcare information and related systems, methods, and devices |
US20060224417A1 (en) * | 2005-03-31 | 2006-10-05 | Werner Douglas J | Computer-implemented process for distributing and tracking pharmaceutical samples |
US7849020B2 (en) * | 2005-04-19 | 2010-12-07 | Microsoft Corporation | Method and apparatus for network transactions |
EP1732034A1 (en) | 2005-06-06 | 2006-12-13 | First Data Corporation | System and method for authorizing electronic payment transactions |
US20070027715A1 (en) * | 2005-06-13 | 2007-02-01 | Medcommons, Inc. | Private health information interchange and related systems, methods, and devices |
MX2008000216A (en) | 2005-06-30 | 2008-11-18 | John R Essig | Consumer-driven pre-production vaccine reservation system and methods of using a vaccine reservation system. |
US8788293B2 (en) * | 2005-07-01 | 2014-07-22 | First Data Corporation | Healthcare system and method for right-time claims adjudication and payment |
US8121855B2 (en) * | 2005-09-12 | 2012-02-21 | Mymedicalrecords.Com, Inc. | Method and system for providing online medical records |
US8660862B2 (en) * | 2005-09-20 | 2014-02-25 | Visa U.S.A. Inc. | Determination of healthcare coverage using a payment account |
US8538875B2 (en) | 2005-11-04 | 2013-09-17 | Instamed Communications Llc | Process for linked healthcare and financial transaction initiation |
US7578432B2 (en) | 2005-12-07 | 2009-08-25 | Bml Medrecords Alert Llc | Method for transmitting medical information identified by a unique identifier barcode to a hospital |
US7739129B2 (en) | 2006-04-10 | 2010-06-15 | Accenture Global Services Gmbh | Benefit plan intermediary |
US8788284B2 (en) | 2006-05-30 | 2014-07-22 | Visa U.S.A. Inc. | Method and system using combined healthcare-payment device and web portal for receiving patient medical information |
CA2654562A1 (en) | 2006-06-08 | 2007-12-21 | Visa U.S.A. Inc. | System and method using extended authorization hold period |
US20080010094A1 (en) | 2006-06-21 | 2008-01-10 | Mark Carlson | Distribution of health information for providing health related services |
US7769599B2 (en) | 2006-07-31 | 2010-08-03 | Visa U.S.A. Inc. | Electronic payment delivery service |
US20080147518A1 (en) | 2006-10-18 | 2008-06-19 | Siemens Aktiengesellschaft | Method and apparatus for pharmacy inventory management and trend detection |
US20080177574A1 (en) | 2007-01-22 | 2008-07-24 | Marcos Lara Gonzalez | Systems and Methods To Improve The Efficiencies Of Immunization Registries |
US10395264B2 (en) | 2007-04-30 | 2019-08-27 | Visa U.S.A. Inc. | Payment account processing which conveys financial transaction data and non financial transaction data |
US20080319794A1 (en) | 2007-06-20 | 2008-12-25 | Mark Carlson | Health information services using phone |
US7739169B2 (en) | 2007-06-25 | 2010-06-15 | Visa U.S.A. Inc. | Restricting access to compromised account information |
US8296235B2 (en) | 2007-09-07 | 2012-10-23 | Ebay Inc. | System and method for cashback funding |
US20090326977A1 (en) | 2008-06-30 | 2009-12-31 | Mckesson Financial Holding Limited | Systems and Methods for Providing Drug Samples to Patients |
US20100057621A1 (en) | 2008-06-30 | 2010-03-04 | Faith Patrick L | Payment processing system secure healthcare data trafficking |
US20100010901A1 (en) | 2008-07-11 | 2010-01-14 | Marshall Charles T | Point-of-sale transaction management |
US20100010909A1 (en) | 2008-07-11 | 2010-01-14 | Marshall Charles T | Benefit ordering and compliance server |
US20100145810A1 (en) | 2008-12-06 | 2010-06-10 | Stacy Pourfallah | Automated substantiation of product level specific account payments |
US9325823B2 (en) | 2008-12-19 | 2016-04-26 | Verizon Patent And Licensing Inc. | Visual address book and dialer |
US20110166872A1 (en) | 2009-08-14 | 2011-07-07 | Cervenka Karen L | Auto-substantiation for healthcare upon sponsor account through payment processing system |
US10614458B2 (en) | 2009-08-14 | 2020-04-07 | Visa U.S.A. Inc. | Influenza vaccine administration payment device processing |
US20110082745A1 (en) | 2009-10-05 | 2011-04-07 | Stacy Pourfallah | Portable consumer transaction payment device bearing sponsored free sample |
US20110082708A1 (en) | 2009-10-05 | 2011-04-07 | Stacy Pourfallah | Portable consumer transaction payment device bearing sample prescription |
US20110079643A1 (en) | 2009-10-05 | 2011-04-07 | Stacy Pourfallah | Prescription sample transaction payment card |
US20110082739A1 (en) | 2009-10-05 | 2011-04-07 | Stacy Pourfallah | Free sample account transaction payment card dispensing kiosk |
US20140379361A1 (en) | 2011-01-14 | 2014-12-25 | Shilpak Mahadkar | Healthcare Prepaid Payment Platform Apparatuses, Methods And Systems |
-
2005
- 2005-09-20 US US11/230,761 patent/US7650308B2/en active Active
-
2006
- 2006-01-04 WO PCT/US2006/000289 patent/WO2006074286A2/en active Application Filing
- 2006-01-04 AU AU2006203968A patent/AU2006203968B2/en active Active
- 2006-01-04 EP EP06717482A patent/EP1856663A4/en not_active Withdrawn
- 2006-01-04 CA CA002611661A patent/CA2611661A1/en not_active Abandoned
-
2009
- 2009-12-28 US US12/648,054 patent/US8560446B2/en active Active
-
2013
- 2013-09-04 US US14/017,652 patent/US8688581B2/en active Active
-
2014
- 2014-03-31 US US14/231,115 patent/US20140297304A1/en not_active Abandoned
- 2014-03-31 US US14/231,065 patent/US20140214681A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20010053986A1 (en) * | 2000-06-19 | 2001-12-20 | Dick Richard S. | Method and apparatus for requesting, retrieving, and normalizing medical information |
US20020198831A1 (en) * | 2001-06-11 | 2002-12-26 | Patricelli Robert E. | System and method for processing flexible spending account transactions |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150006307A1 (en) * | 2007-11-02 | 2015-01-01 | Citicorp Credit Services, Inc. | Methods and systems for managing transaction card accounts enabled for use with particular categories of providers and/or goods/services |
US9230253B2 (en) * | 2007-11-02 | 2016-01-05 | Citicorp Credit Services, Inc. | Methods and systems for managing transaction card accounts enabled for use with particular categories of providers and/or goods/services |
US9558495B1 (en) | 2007-11-02 | 2017-01-31 | Citicorp Credit Services, Inc. (Usa) | Methods and systems for managing transaction card accounts enabled for use with particular categories of providers and/or goods/services |
US20130218587A1 (en) * | 2012-02-22 | 2013-08-22 | Passport Health Communications, Inc. | Coverage Discovery |
US10510046B2 (en) * | 2012-03-28 | 2019-12-17 | Passport Health Communications, Inc. | Proactive matching for coordination of benefits |
US20130262249A1 (en) * | 2012-04-03 | 2013-10-03 | Blackhawk Network | Redemption Network with Transaction Sequencer |
US9710799B2 (en) * | 2012-04-03 | 2017-07-18 | Blackhawk Network, Inc. | Redemption network with transaction sequencer |
US10878511B1 (en) * | 2012-05-30 | 2020-12-29 | Vpay, Inc. | Merchant portal system with explanation of benefits |
WO2020227727A3 (en) * | 2019-04-15 | 2020-12-17 | Global Care Analytics, Llc | Transaction analysis and asset recovery system |
US20200342541A1 (en) * | 2019-04-26 | 2020-10-29 | Optum, Inc. | Medical identity theft alert system |
US11861717B2 (en) * | 2019-04-26 | 2024-01-02 | Optum, Inc. | Medical identity theft alert system |
Also Published As
Publication number | Publication date |
---|---|
WO2006074286A3 (en) | 2008-08-21 |
US20140006288A1 (en) | 2014-01-02 |
WO2006074286A2 (en) | 2006-07-13 |
CA2611661A1 (en) | 2006-07-13 |
US20100100484A1 (en) | 2010-04-22 |
AU2006203968B2 (en) | 2011-12-08 |
EP1856663A4 (en) | 2010-02-03 |
AU2006203968A1 (en) | 2006-07-13 |
US8688581B2 (en) | 2014-04-01 |
US8560446B2 (en) | 2013-10-15 |
US20060149670A1 (en) | 2006-07-06 |
US20140214681A1 (en) | 2014-07-31 |
US7650308B2 (en) | 2010-01-19 |
EP1856663A2 (en) | 2007-11-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8660862B2 (en) | Determination of healthcare coverage using a payment account | |
US20140297304A1 (en) | Determination of healthcare coverage using a payment account | |
US11023857B2 (en) | Healthcare debit card linked to healthcare-related and non-healthcare-related financial accounts | |
AU2006203967B2 (en) | Method and system for determining healthcare eligibility | |
US10311207B2 (en) | Healthcare system and method for right-time claims adjudication and payment | |
US6820058B2 (en) | Method for accelerated provision of funds for medical insurance using a smart card | |
US20140304010A1 (en) | Healthcare system and method for real-time claims adjudication and payment | |
US7174302B2 (en) | System and method for processing flexible spending account transactions | |
US6826535B2 (en) | Method for reducing fraud in healthcare programs using a smart card | |
US8224678B2 (en) | Systems and methods for tracking health-related spending for validation of disability benefits claims | |
US8788281B1 (en) | System and method for processing qualified healthcare account related financial transactions | |
US20050015280A1 (en) | Health care eligibility verification and settlement systems and methods | |
US20070168234A1 (en) | Efficient system and method for obtaining preferred rates for provision of health care services | |
US20100185461A1 (en) | Method for controlling the purchase of health care products and services | |
US20180018647A1 (en) | Method and system for managing consumer-directed accounts | |
US6826537B1 (en) | Cardless method for reducing fraud in government healthcare programs | |
US7058585B1 (en) | Cardless method for reducing fraud in healthcare programs | |
CA2685273C (en) | Determination of healthcare coverage using a payment account | |
AU2014200287A1 (en) | Determination of healthcare coverage using a payment account | |
US20240013169A1 (en) | Digital Healthcare Patient Identification Utilizing Non-Fungible Tokens | |
US20220415460A1 (en) | Digital Healthcare Capture Intake Data for COVID-19 And Other Significant Events | |
US20200388362A1 (en) | Healthcare data chip device | |
EP4128113A1 (en) | Digital healthcare capture intake data for covid-19 and other significant events | |
AU2011204923A1 (en) | Method and system for determining healthcare eligibility |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: VISA INTERNATIONAL SERVICE ASSOCIATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NGUYEN, LOC;PATTERSON, BARBARA ELIZABETH;PRUITT, JANET;AND OTHERS;SIGNING DATES FROM 20030213 TO 20140515;REEL/FRAME:037875/0681 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |