PREDICTIVE DATA EVALUATION AND FRONT-END USER INTERFACE INTERACTION PROCESSING
Systems and methods of using data to provide functionality and/or information are disclosed, in the context of predictive data evaluation and front-end user interface interaction processing. In an example, healthcare information system data may be extracted or accessed for use in a front-end user interface (e.g., accessed before any services have been provided). Electronic operations for transformation and processing of healthcare transaction data may include performing on-demand scoring to enable appropriate front-end payment collection strategies for patient access to a healthcare transaction (e.g., scheduling, registration, pre-authorization) with a healthcare provider. An interface may be provided that can guide or direct use of the front-end payment collection using propensity-to-pay (PTP) scoring, for example by personnel of the provider. The interface may enable receiving an estimate of future visit charges and present one or more PTP scores based on a balance or estimate for a guarantor.
This application is a continuation of U.S. patent application Ser. No. 14/590,795, filed Jan. 6, 2015, which claims priority to U.S. Provisional Patent Application No. 61/924,121, filed Jan. 6, 2014; both applications are incorporated by reference herein in their entireties.
TECHNICAL FIELDDisclosed herein are embodiments that relate to techniques to acquire or otherwise access data pertaining to healthcare transactions and to provide functionality and/or information for such healthcare transactions. In some embodiments, the data may be transformed and organized using a data table structure that enables longitudinal views of transactions.
BACKGROUNDComputing systems have greatly improved capability to track and manage collection of payments. The Internet provides a convenient medium for customers to make payments. Nevertheless, current billing systems lack functionality to provide features that would enhance effectiveness of payment collections. Similarly, current billing systems are fragmented and incomplete and lack functionality to provide features that provide a positive customer payment experience, thus producing confusion and frustration for customers and turning a positive experience into an overall negative experience.
Collecting payments for goods and services provided is a critical function, particularly where it may be necessary or preferable to bill for services or products subsequent to providing them to a beneficiary (e.g., a customer). Convenience in making payments is of importance to many customers, and the payment experience for remitting payments for billed charges can significantly impact an impression of customers. The healthcare industry is an industry in which billing and payment collection is fragmented and tends to produce a negative patient experience.
Current healthcare billing systems (sometimes referred to as Revenue Cycle Management (RCM) systems) are primarily designed to track claims and optimize payments by third-party payers (e.g., insurers). As a result, presently available healthcare billing systems present only vertical (period-based) portrayals of data and information. Specifically, the billing systems can tell a healthcare provider how much cash was collected this month but cannot tell how much of that cash was collected on balances created in any specific month prior as compared to those balances created this month. With only a vertical portrayal, a healthcare provider cannot accurately predict payment rates, understand vendor performance, set intelligent goals, offer intelligent financing, manage repayment risks, etc.
Presently available healthcare billing systems also are not equipped to elegantly manage patient (or guarantor) account balances. Patients/guarantors are generally confused by statements generated by existing billing systems. The patient/guarantor interfaces to billing systems, such as to make online bill payments, are fragmented and incomplete, turning a positive patient care experience into an overall negative experience with the healthcare provider. As an example, presently available healthcare billing systems do not present a guarantor a single electronic statement that includes all charges incurred for multiple disparate visits during a single period. As another example, a guarantor responsible for multiple different patients (e.g., dependents) generally cannot view an electronic aggregation of charges for visits of those different patients, especially over time. A guarantor also cannot link an account, or assume responsibility for an account, of another guarantor (e.g., a spouse) without a tedious paper request and approval process.
There is also a lack of flexible financing options for patients to pay for healthcare services. Similarly, there is a lack of flexible financing options for a variety of beneficiaries to pay for encounters providing goods and/or services, for which the encounter charges are billed to the beneficiary and/or a guarantor of the beneficiary.
There is also a lack of effective systems and methods for assessing the propensity of a guarantor to pay for a particular type of goods or services. For example, the credit scores generated by credit reporting agencies can be poor predictors or indicators of a guarantor's likelihood of paying for healthcare services. Similar shortcomings exist in other industries and markets, including but not limited to dental services, legal services, auto repair services, and other goods and services. Credit reporting agencies are largely dependent on data reported by credit lenders, and are often removed from actual transaction data in specific verticals like healthcare because few providers report payment dynamics to these agencies from actual transaction data. Thus, their credit scores may be limited to data based on transactions involving credit and for goods/services that may have nothing to do with a given market (e.g., healthcare services).
SUMMARYThe present disclosure provides embodiments of computer-implemented systems and methods of the transformation and processing of healthcare transaction data, including for use with front-end payment data processing systems and graphical user interfaces. Embodiments of the disclosed systems and methods may, for example, utilize on-demand scoring to enable appropriate front-end payment collection strategies for patient access areas (scheduling, registration, pre-authorization). An interface may be provided that can guide or direct use of propensity-to-pay (PTP) scoring, for example by personnel of the provider. The interface may enable receiving an estimate of future visit charges. The interface may present one or more PTP scores based on a current open charges balance, an estimate of future charges, or a total balance owed by a guarantor. The front-end PTP score can be used to guide front-end staff of an appropriate collection tactic at the scheduling/registration of a patient before any services have been provided. For example, the front-end PTP score may guide how much a patient/guarantor may be required to pay in advance or “arrange in advance” of receiving a treatment. The front-end PTP score may allow creation of a financing plan and payment authorization structure at time of service.
Collecting payments for goods and services provided is a critical function of businesses, particularly where it may be necessary or preferable to bill for services or products subsequent to providing them to a beneficiary (e.g., a customer). Certain industries face particular challenges in collecting payments. The presently disclosed embodiments provide improved payment management functionality for a service (or product) provider, such as a healthcare provider, and enable an improved billing experience for guarantors of payment for charges billed for a visit.
The term “provider” as used herein refers broadly to an entity providing a product or service. A provider may be a single individual (e.g., a physician) providing a benefit or may be an entire organization (e.g., a healthcare organization with multiple subsidiaries, facilities, locations, departments). In other words, the term “provider” is not limited to a single individual. Rather a provider may include a single individual or entity, a group of individuals or entities, multiple locations, subsidiaries, departments (e.g., laboratory, pathology, anesthesiology, etc.), affiliates, and the like.
The term “guarantor” as used herein refers to a person (or entity) that has assumed primary or at least shared financial responsibility for payment for an amount owed, such as for a product or for services rendered (e.g., healthcare services rendered to a patient), either at a visit or at the time of receipt of such product or service. A guarantor makes or gives a promise, assurance, or pledge relating to financial payment performance on a financial liability, either on behalf of himself/herself or on behalf of another. The guarantor, in some instances, may also be the beneficiary of the product or service (e.g., a patient in the case of healthcare services). Another example of a guarantor may be a parent or legal guardian of a minor. Although in some instances laws or regulations may dictate qualifications for a guarantor (e.g., age requirements, mental capacity), the term herein is not bound to these restrictions.
The term “visit” as used herein refers to an encounter or an instance of receipt of services (or a product). For example, some embodiments of the disclosure are described with reference to healthcare services rendered to a patient, and a visit can be considered a physical visit to a healthcare provider and receipt of healthcare services rendered during that physical visit. However, the disclosed embodiments are not limited to healthcare. Other examples of visits relate to dental services, vision services, mental health services, legal services, automobile services (e.g., mechanic, routine maintenance), and other repair services. An example of a product-related visit may include a purchase of furniture or appliances. As can be appreciated, a visit or encounter may not necessarily involve physical movement of the beneficiary to another location, and can include services or products that come to the beneficiary or that are otherwise performed for or directed to the benefit of the beneficiary.
The term “self-pay” as used herein refers to any obligation owed by the beneficiary (and/or a guarantor) to a provider. In the context of healthcare, self-pay can include co-pays, balances after insurance adjudication, deductible amounts, etc. The term “self-pay” is not intended to reflect whether or not a beneficiary/guarantor is insured. Rather, “self-pay” is intended to encompass any obligation properly owed by the beneficiary/guarantor in the normal course of business. In other words, a provider may consider self-pay receivables as those balances due from patients/guarantors for hospital and physician services as a result of having no insurance or having a balance due even after insurance pays, due to coinsurance, deductibles, or noncovered services.
The presently disclosed embodiments access data (e.g., extract, obtain, collect, receive, or otherwise access data), transform the data, and load the data to generate longitudinal portrayals of the data. A longitudinal portrayal may be cohort-based, where a cohort is a group of guarantor accounts (within a billing system), balances, and/or visits that share a common origination characteristic (typically a specific time period when a corresponding initial debt was incurred) and for which all transactions affecting the balances (e.g., payments, added charges, adjustments, interest, fees) are tracked longitudinally over time. In other words, a longitudinal portrayal includes all transactions affecting the balances of a grouping of accounts as tracked over a period of time. The grouping of accounts may include accounts (e.g. one or more accounts) from independent billing systems and/or balance sheet entities.
The presently disclosed embodiments may collect historical visit data and/or patient information from or within a billing system (or plurality of billing systems) and create a standardized extract file layout for each respective billing system of record for subsequently structuring necessary information to create relevant products to drive self-pay financial performance and patient experience. The presently disclosed embodiments may also collect data from other systems, such as from a credit data source, a demographics data source, and systems affiliated with the provider and/or billing system (e.g., installment loan platforms), to supplement the visit data and/or patient information. Each transaction identified in the collected historical data is date/time stamped so that a longitudinal portrayal can be created of a given visit from the time the initial visit charge is incurred until the visit charge is ultimately resolved. The collected data may be transformed and organized using a data table structure that enables longitudinal views of, for example, guarantor type, service location, service type, guarantor financial class, account status, source of payments, insurance information, balance, patient and guarantor relationships, and cash and non-cash transactions. As a result, a longitudinal view of cash and non-cash transaction dynamics (and other financial performance dynamics) of self-pay balances can be provided.
The disclosed embodiments may use the collected data to provide business intelligence functionality and/or information. An interactive interface can be provided by which a provider can achieve a comprehensive view on the performance characteristics of the provider's self-pay business currently as well as in a given time period or over varying time spans. The business intelligence functionality of the disclosed embodiments can provide a consolidated view of multiple locations, affiliates, provider entities (e.g., subsidiaries, departments, and other organizational groupings), and the like of a given provider (e.g., multiple hospitals and clinics, laboratories, pathology, anesthesiology). The business intelligence can also enable a provider to reliably compare performance and/or effectiveness of third-party vendors (e.g., accounts receivable servicing vendors, debt collection vendors, and the like) on an equal or analogous basis to tightly manage vendor performance. The business intelligence can also enable intelligent forecasts of payor and guarantor cash flows for reserve setting purposes, and enable setting and tracking of goals against such forecasts. Standard reports can be dynamically filtered by hundreds of variables. An ad hoc reporting tool can generate custom reports designed by the user.
The presently disclosed embodiments can also use extracted data to provide propensity-to-pay (PTP) scores. A PTP scoring assessment uses a provider's historical transaction data to help assess likelihood of future guarantor payments based on the specific historical payment behaviors of the guarantor being scored. Presently available scoring solutions rely heavily and often exclusively on credit data provided by credit reporting agencies or demographics data provided by third parties, and neither of these data elements is highly predictive of a given guarantor's PTP in a specific market, such as the healthcare market. Using the provider's historical transaction data greatly improves the predictive capability of the resulting PTP scores. The scoring can consider present visit data and/or past transaction data of the guarantor to the provider. The resulting scoring creates a proprietary, highly predictive score without creating either a “soft” or “hard” hit to the guarantor's file at any one of the three major credit reporting agencies (TransUnion, Equifax or Experian).
The PTP scoring can be “always-on,” such that PTP scores automatically update, such as at various stages of account aging, when cash and non-cash transactions occur, and/or in response to triggers. A guarantor with an account balance may be initially assessed for PTP using provider and third-party data, and any subsequent provider-based credit or debit activity on the specific account can result in an updated score (e.g., automatically updating the score). Always-on scoring can enable a provider to create a tailored guarantor billing experience by grouping guarantors into meaningful customer segments that warrant specific action and treatment. Always-on scoring can also enable better account management strategies while accounts are in accounts receivable and can enable better account management strategies for accounts moving to bad debt, inclusive of those accounts recommended for a presumptive charity write-off.
The scoring can also occur “on-demand,” or triggered by an event in which a balance is owed (e.g., post adjudication of actual visit charges) or is expected to be owed (e.g., pre-treatment or at the time of treatment). If the balance is expected to be owed, the triggering event may be a provider's estimate of a balance to be owed. If the balance is actually owed, the event may be a provider's actual charge(s) for the balance owed. Once the on-demand scoring occurs, the always-on functionality may enable an on-going perspective of the guarantor in question. If the guarantor is new to the provider, the PTP logic may use the provider's historical payment data for other guarantors, and/or third-party data. On-demand scoring enables appropriate front-end payment collection strategies for patient access areas (scheduling, registration, pre-authorization). An interface may be provided that can guide or direct use of the PTP scoring, for example by personnel of the provider. The interface may enable receiving an estimate of future visit charges. The interface may present one or more PTP scores based on a current open charges balance, an estimate of future charges, or a total balance owed by a guarantor.
The scoring functionality can also include a presumptive charity rank ordering based on PTP assessment for those guarantors that meet charity policy requirements (e.g., requirements specified by the provider or other asset holder) based on third-party demographics data and third-party scores/attributes. By comparison, rank ordering presumptive charity-eligible patients using presently available credit scores, such as are produced purely from credit reporting data or demographics data (and thus not very predictive in any certain industries, such as healthcare), introduces waste and inefficiency.
The disclosed embodiments may use the extracted data and employ rigorous matching logic to automatically populate an account of a registered guarantor with information (and particularly billing information) for visits of the guarantor and/or associated beneficiaries. The guarantor accounts and balances can continue to reside on the originating billing system, and this billing system may remain the system of record for transactions posted to these accounts. The disclosed embodiments can present, for a given billing period, a single digital statement for charges for visits during a given billing period (e.g., 30-day period) and for which the guarantor has accepted financial responsibility. The single statement may combine visit data of multiple beneficiaries from a plurality of billing systems of one or more healthcare service providers.
The disclosed embodiments may also enable a guarantor to, for example, “consolidate a household” with another registered guarantor. This means that a selected guarantor can be designated as a “managing guarantor” of an aggregated group of guarantors (e.g., within a household or a nuclear family) and can interactively manage and/or pay on any guarantor account within that aggregation of managed guarantor accounts (e.g., set up a payment plan or financing plan, pay a specific balance, etc.). The linking is compliant with the Health Insurance Portability and Accountability Act (HIPAA) and allows consolidation of billing management for any number of consenting adults or dependent minors to one singular portrayal of a patient's financial obligations potentially spanning multiple billing systems within a given provider, or for multiple providers, and managed by one authorized accounts manager (or manager guarantor). Account linking is generally very difficult operationally, highly risky from a HIPAA compliance standpoint, and sometimes impossible (across multiple disparate billing systems) in a paper environment. The disclosed embodiments facilitate electronic communications (e.g., requests and acceptances) that enable linking accounts in minutes as compared to weeks or months in a paper world. Thus, the single digital statement of a manager guarantor provides a vehicle to efficiently manage financial records of all healthcare-related transactions for one or more providers and for all members of, for example, a household. Nevertheless, the managed guarantor remains the responsible financial party for his/her visits and the managed guarantor can continue to access account information and make payments on any of his/her specific accounts. The disclosed embodiments may facilitate both guarantors agreeing to the consolidation, and either guarantor can unilaterally terminate the consolidation at any time.
The digital statement provides a singular portrayal of new charges as well as prior charges and transaction history for all linked individuals (patients/guarantors). The digital statement is interactive and dynamic, allowing the guarantor (or manager guarantor) to view as much or as little detail as desired. The digital statement provides the manager guarantor complete transparency on an aggregated statement of charges, with filtering/searching capability to view specific patient accounts within the household for given periods of time and to drill down on any encounter/visit for detailed articulation of charges, including physician, service location, provider revenue code, Current Procedural Terminology (CPT) code, and corresponding descriptions. The filtered searches can be downloaded for import to another application or conversion to another format.
In some disclosed embodiments, a guarantor (including a manager guarantor) may be enabled to select and configure a single monthly due date on which payments will be due to the provider. The digital statement provides a clear, concise portrayal of a guarantor's financial obligations in one statement each month presented with ample time (e.g., 21 days) before a chosen payment date. The digital statement can show pending insurance claims still in the adjudication process. The digital statement may also provide a mechanism for a guarantor to dispute or challenge a questionable set of charges for a given visit/encounter. Thus, the disclosed embodiments can provide an avenue to efficiently flag and resolve disputed charges or raise other issues with the provider and similarly provide a workflow for the provider to address charges disputed or other issues raised by a guarantor.
The disclosed embodiments provide the same functionality for any guarantor of an account even if the guarantor has delegated account management rights to another guarantor (e.g., a manager guarantor). The disclosed embodiments offer encounter-level payment, adjustment, and interest tracking.
Upon receiving the digital statement, a guarantor can choose how to make a payment. While a payment can be made at any time, general choices (e.g., payment options) may be presented upon receipt of the digital statement, such as the following:
-
- Pay in full for new visits to potentially earn a prompt-pay discount, based on choices and/or configured preferences of the healthcare provider and possibly subject to what is allowed by the guarantor's insurance plan.
- Customize a new financing plan to pay a new balance comprising charges for visits from a current statement period.
- Accept (e.g., by taking no action or affirmatively accepting) preset financing terms for a multi-month financing plan at a pre-established interest rate (e.g., a low or 0.0% interest rate) as configured by the provider or other asset holder.
At the time of filing of this application, the law distinguishes a payment plan, which is presently defined by law to have a duration of four months or less (and subject to certain additional regulatory requirements), from a financing plan, which is presently defined by law to last longer than four months. As used herein, the term “financing plan” includes any payment plan spanning multiple periods (e.g., months), whether or not distinguished according to definition under the law. A financing plan includes open-ended (e.g., revolving) credit as well as closed-ended (e.g., a loan) credit.
The payment options enabled by the disclosed embodiments provide a vehicle through which a guarantor (or manager guarantor) can obtain reliable open-ended credit for current and future financial obligations to a provider. Aggregated current and historical charges are presented to the guarantor (or manager guarantor) for balance management and self-servicing. This information may be presented to a guarantor irrespective of whether management rights have been delegated to a manager guarantor. A guarantor can authorize automated, recurring payments on accounts or make a one-time payment on an account or group of accounts. The same functionality may be available to any guarantor, irrespective of management delegation. A set of charges for a given billing/statement period (e.g., a set of current open charges) that are not paid in full may be placed on a preset financing plan or configured for a custom financing, such that a payment amount will be automatically debited from the guarantor's (or manager guarantor's) selected financial transaction account and automatically credited to specific accounts on the provider's billing system(s).
The amount for current open charges (e.g., an open charges balance) for each statement period's visits can be financed according to a new financing plan with unique terms, which may be preset financing terms or financing terms selected or configured by the guarantor (subject to constraints/authorization of the provider). A guarantor may have multiple financing plans active simultaneously. The disclosed embodiments enable one monthly payment for all open financing plans on a guarantor-configured payment date. The financing option allows a guarantor to create self-configured financing plans, for example, by choosing a monthly payment amount and subsequently accepting the associated terms the provider has authorized for the resulting amortization schedule (e.g., minimum payment amount, maximum amortization period, interest rates, etc.). Self-configured financing plans may be configured by the guarantor choosing any one or more of an interest rate, a payment amount, a period for repayment, and/or other terms that can be compared to provider-authorized terms and/or associated with provider-authorized terms that can be accepted by the guarantor.
The payment options enabled by the disclosed embodiments also provide a vehicle through which a guarantor can pay off an entire set of new monthly charges and potentially receive a prompt payment discount or other discount offered by the provider. The disclosed embodiments enable providers to effectively offer and administer prompt payment discounts as well as other types of discounts.
The disclosed embodiments enable automatic transactions (or transfers of funds) on a configured payment date and using a configured payment method. Payment preferences can be configured by each guarantor, including but not limited to the payment date, a preferred mode of payment (e.g., checking account, savings account, credit card, debit card, Health Savings Account), and/or a preferred payment option (e.g., pay in full, preset financing terms, custom financing terms). A guarantor can link one or more financial transaction vehicles of choice to automatically settle payments on new obligations and historical financings with a balance still due.
The features of the disclosed embodiments provide control and choice for how a guarantor (or manager guarantor) manages healthcare financial obligations.
The disclosed embodiments may enable provider-level, guarantor-level, and/or visit-level decisioning and/or underwriting such that any visit or set of visits for any patient and/or for any guarantor can be channeled customized financing terms. The decisioning may include decisioning rules that define criteria to group guarantors. The criteria, as mentioned, may be at a provider-level, a guarantor-level, and/or a visit-level (e.g., provider, guarantor income estimate, balance amount, insurance carrier, type of treatment, etc.). Providers can also enable automated discounts for uninsured patients pursuant to the provider's policies.
The disclosed embodiments may enable brokering of charges and/or balances. A balance for a batch of open charges, or an open charges balance can be automatically evaluated based on one or more pre-defined evaluation criteria to determine whether the open charges balance should be transferred to a new system of record associated with a new entity. If the one or more pre-defined evaluation criteria are met, the disclosed embodiments may automatically effectuate electronic transactions to transfer the open charges balance to an entity associated with the new system of record. More particularly, the disclosed embodiments may automatically effectuate electronic transactions to transfer title of an accounts receivable asset that constitutes some or all rights to collect payment for the open charges balance. The disclosed embodiments may track transactions relating to the open charges balance, including payments to pay the current batch of open charges, and this tracking may be separate from the first billing system.
The disclosed embodiments may also enable providers or other asset holders to offer guarantors interest-bearing financing plans. The disclosed embodiments can track and manage interest. The financing plans can enable a provider to secure incremental payments from guarantors and lower the provider's cost of servicing accounts. The financing plans can ease a payment burden on a guarantor by spreading payments over a period of time (e.g., monthly payments for several months).
The disclosed embodiments can generate automated posting files for the provider billing system(s) such that proper accounts are credited with payment and/or assessed interest. Adjustments can be automatically applied at the visit level to ensure any overpayments on interest are applied to principal or credited back to the guarantor's appropriate financial account. For example, the disclosed embodiments may receive first visit data tracked in a first billing system, including a charge for a first visit, and second visit data being tracked in a second billing system, including a charge for a second visit. The second billing system is independent from the first billing system. The disclosed embodiments may communicate a transaction request to a payment gateway to request the payment gateway process an electronic financial transaction to obtain payment funds in a payment amount from a payor financial institution associated with a payment vehicle, to transfer a first portion of the payment funds to a payee financial institution associated with the first patient billing system, and to transfer a second portion of the payment funds to a payee financial institution associated with the second patient billing system. The disclosed embodiments may also communicate electronic posting files to notify the first billing system of transfer of the first portion of the payment funds toward payment of the charge for the first visit and to notify the second billing system of transfer of the second portion of the payment funds toward payment of the charge for the second visit. In this manner, guarantor accounts can be linked across billing systems.
The system 100 utilizes collected data, such as data received (e.g., obtained, extracted, or otherwise accessed) from the billing data source 116A, the healthcare data source 116B, the credit data source 116C, and/or the demographics/consumer data source 116N, to provide payment management functions for the client healthcare provider and associated guarantors. The functions provided by the system 100 include, but are not limited to: providing business intelligence information to the client healthcare provider, assessing PTP scoring information, brokering charges and/or balances to transfer a corresponding accounts receivable asset to a new asset holder, enabling offers of configurable financing and payment terms to beneficiaries and/or guarantors, linking accounts of guarantors across billing systems, and linking accounts of guarantors to an account of a manager guarantor.
The business intelligence provided by the system 100 may include information to enable a provider to reliably compare performance and/or effectiveness of third-party vendors (e.g., A/R servicing vendors, debt collection vendors, and the like) on an equal or sufficiently analogous basis to tightly manage vendor performance. The business intelligence can also enable intelligent forecasts of payor and guarantor cash flows for reserve setting purposes, and enable setting and tracking of goals against such forecasts. Standard reports can be dynamically filtered by hundreds of variables, including but not limited to facility vs. professional billing, location, balance range, patient/guarantor financial class, timer period, etc. An ad hoc reporting tool can generate custom reports designed by the user. The generated reports can be pushed via the provider's email system. Generated reports can also be pulled, for example, through electronic, system-generated subscription functionality. A client provider viewing a report may be able to drill down on any reported element to the individual guarantor accounts that comprise the reported element and subsequently display additional account-level information on that universe of accounts (e.g., double-click on a section of a bar graph and see a detailed listing of all individual accounts that comprise that data set).
The PTP scoring provided by the system 100 may include using a client provider's historical transaction data to help assess the likelihood of future guarantor payments based on the specific historical payment behaviors of the guarantor being scored or a like guarantor (e.g., having similar payment characteristics and/or attributes). The PTP scoring can be “always-on,” such that scores automatically update, such as at various stages and/or in response to triggers, as described previously. The PTP scoring can also occur “on-demand,” or triggered by an event in which a new balance is owed or is expected to be owed, as described previously.
The system 100 also utilizes extracted data to provide payment and/or communication functionality to patients (or other beneficiaries) and/or guarantors of patients. For example, the system 100 provides the ability for a patient/guarantor to view account information and provide payment information for healthcare services, and the system 100 interfaces with the payment gateway 110 for processing the payment. The payment gateway 110 may effectuate or otherwise facilitate electronic payment transactions between a patient (or guarantor) financial institution 176 and a provider (or asset holder) financial institution 178. The system 100 can present, for a given billing period, a single statement for visits during the given billing period for which the guarantor has accepted financial responsibility. The single statement may combine visit data from a plurality of billing systems of one or more client healthcare service providers. As another example, the system 100 also interfaces with the SMS provider 112 to facilitate communication with the patient and/or the patient's guarantor.
The system may also interface with the provider's general ledger (G/L) 180 to provide communications to reconcile what is posted to the provider's G/L to individual accounts within the billing system. For guarantor payments that only involve principal, that reconciliation may be generally straightforward because the posting files to the billing system, which go through that system to the provider's G/L, tie exactly to the files that go from the payment gateway 110 to the provider G/L in terms of money transferred. The complexity increases when a portion of the payment is allocated to interest charges, because the billing system may not have any ability to deal with the concept of interest. As such, an ‘interest payment’ file can be posted to the provider's G/L to tie the cash the provider received from the payment gateway 110 (in terms of money transferred to provider's bank 178) to what the provider is showing in its billing system. Otherwise, it would appear that the billing system amount (which is principal only in the case of a billing system that cannot account for interest) is short (and it is by the amount of interest). If a billing system can handle interest, posting files may only be posted to the billing system (and not to the provider's G/L) because existing reconciliation processes between the provider's billing system and the provider's G/L are available for both principal and interest. The payment gateway 110 may still post a posting file to the provider's G/L and that amount can be reconciled solely to the billing system records.
The system 100 can automate brokering of charges and/or balances. A batch of open charges of a guarantor (and any linked or managed guarantors) in a given period can be aggregated from the data extracted from one or more billing systems to determine an open charges balance. The open charges balance can be automatically evaluated by the system 100, based on one or more pre-defined evaluation criteria, to determine whether the open charges balance should be transferred to a new system of record associated with a new entity. If the one or more pre-defined evaluation criteria are met, the system 100 may automatically effectuate electronic transactions to transfer the open charges balance to an entity associated with the new system of record. The system 100 may be the new system of record.
The system 100 can enable configurable financing and payment terms by allowing a provider to configure pre-set financing terms or authorized financing terms that can be offered to guarantors for an open charges balance. The authorized financing terms may allow guarantor configuration of a financing plan, while the pre-set financing terms may not allow guarantor configurability. Further, the system 100 can evaluate the open charges balance to determine an appropriate set of terms (e.g., pre-set financing terms and/or authorized financing terms) to offer for the open charges balance.
The system 100 can link guarantor accounts to a guarantor who has accepted management responsibility. The system 100 can facilitate electronic communications to obtain any required consent to manage and/or authorization to delegate management authority. Upon appropriate approvals, the account data of a managed guarantor can be aggregated with account data of the manager guarantor.
The system 100 can also link guarantor accounts across billing systems. First visit data originated in a first billing system and second visit data originated in a second billing system can be aggregated for a guarantor to allow presentation of the guarantor's visit data from both billing systems in a singular interactive electronic statement. The system 100 also facilitates payments for the aggregated open charges balance, initiating the appropriate financial transactions between payor and payee financial institutions and communicating posting files to the billing systems to notify of the portion paid toward specific charges originated in each billing system.
The payment management system 102 may implement or otherwise provide one or more of the foregoing functionality. The payment management system 102 of
The data tier 120 may include an extraction engine 122 and one or more databases in a datastore 121. The extraction engine 122 may be configured to extract data from the billing data source 116A, the healthcare data source 116B, the credit data source 116C, and/or the demographics/consumer data source 116N for use by the system 100. The extraction engine 122 may be configured to simply aggregate or otherwise collect data tracked in a first billing system of which the payment management system 102 is a component or of which is integrated into the payment management system 102. In other words, extraction by the extraction engine may simply be collection or other access of local and directly accessible data, and is not limited to retrieving or extracting data from external or remote data sources. The extraction engine 122 may translate, convert, transform, or otherwise structure the extracted and/or collected data and may load the transformed data to the datastore 121 and/or to data structures of databases in the datastore 121. The extraction engine 122 is discussed in greater detail below with reference to
The application tier 140 may include a business intelligence subsystem 142, a scoring subsystem 144, a public payment portal subsystem 146, and a private payment portal subsystem 148. These subsystems leverage data extracted and/or stored by the data tier 120 to provide payment management features and functionalities.
The business intelligence subsystem 142 provides business intelligence information and functionality to a client healthcare provider. The business intelligence subsystem 142 may be configured to generate reporting information pertaining to any aspect of the payment management system 102. The business intelligence subsystem 142 may be further configured to generate forecasts of accounts receivable activity based on PTP metrics corresponding to outstanding balances.
The scoring subsystem 144 provides PTP and presumptive charity information and functionality to a client healthcare provider. The scoring subsystem 144 may be configured to assign PTP scores and/or segmentation or grouping identifiers derived from those PTP scores to accounts managed by the payment management system 102. The PTP scores may incorporate information regarding the transaction history of the account guarantor with the healthcare system. PTP scores may also incorporate information related to the condition of the patient, credit reporting information, demographics, and/or the like. The scoring subsystem 144 may be further configured to identify accounts that are candidates for presumptive charity based on, inter alia, PTP scoring and/or other information indicating that the guarantor is unlikely to have the ability to pay (e.g., balance history, credit reporting information, demographics, and/or the like).
The public payment portal subsystem 146 allows unregistered guarantors to pay charges for healthcare services. The guarantor may be notified of the charges, for example, by a bill or statement mailed in paper format. The public payment portal subsystem 146 enables a client provider to offer a uniform, single online (or electronic) payment interface, regardless of the client provider billing system in which the charges for the healthcare services may be originated, tracked, stored, and otherwise managed. In other words, a client healthcare provider that utilizes a plurality of billing systems (e.g., due to acquisition of business units, clinics, hospitals, and the like) can manage payments to any of these plurality of billing systems through the disclosed embodiments. The public payment portal subsystem 146 allows guarantors who may not be registered for the private payment portal subsystem 148 to make payments through the disclosed embodiments.
The private payment portal subsystem 148 enables a registered guarantor to log in and be presented with protected health information (PHI) that facilitates payment and account management. Through the private payment portal subsystem 148, the registered guarantor can view visit information to better understand charges for a visit. The registered guarantor can view an electronic billing statement reflecting charges for visits incurred during the statement period. The electronic billing statement may reflect an aggregation of charges originated at a plurality of different billing systems. The registered guarantor can also request to have an account managed by another registered guarantor or alternatively request to manage the account of another registered guarantor. The electronic billing statement of a manager guarantor may reflect charges of managed guarantors. In some embodiments, a client provider may coordinate linking of accounts, such as by sending a request to a guarantor to take a manager guarantor role and requesting another guarantor be managed by the manager guarantor.
The presentation tier 160 may include a client input subsystem 162 and a guarantor input subsystem 164. The client input subsystem 162 may present or otherwise provide a graphical user interface for a client healthcare provider to interface with the system 100. In some embodiments, the graphical user interface may be provided through or otherwise integrated with an interface of a billing system.
The client input subsystem 162 may more particularly interface with the business intelligence subsystem 142 and/or the scoring subsystem 144 to enable a client healthcare provider to view and otherwise access and/or manipulate business intelligence information provided by the business intelligence system 142 and/or to access scoring functionality provided by the scoring subsystem 144. An example of a graphical user interface of a client input subsystem 162 is shown in
The guarantor input subsystem 164 may present or otherwise provide a graphical user interface for a guarantor to interface with the system 100. The guarantor input subsystem 164 may more particularly interface with the public payment portal subsystem 146 and/or the private payment portal subsystem 148 to enable a patient or guarantor to view statements, make payments, link to accounts of other guarantors, and the like. An example of a graphical user interface of a guarantor input subsystem 164 is shown in
The graphical user interface(s) of the client input subsystem 162 and the guarantor input subsystem 164 may be provided to a patient/guarantor computing device 170, a provider/asset holder computing device 172, and/or other client computing device, such as via a network 115 (e.g., over the Internet). Described differently, the system 100 may implement a software as a service (SaaS) delivery model in which the payment management functionality provided by the system 100 and associated data are accessed over the Internet. However, as can be appreciated, the system 100 may be implemented using other appropriate architectures and configurations. For example, the disclosed embodiments may be deployed directly on or using computing devices of a client provider, for example, inside the client provider's firewall. As another example, the disclosed embodiments may be deployed within and/or on a client provider's billing system.
Extraction EngineThe extraction engine 122 may be configured to access information pertaining to particular guarantors, patients, organizations, and/or the like. As disclosed in further detail herein, the information gathered by the extraction engine 122 may be used by the payment management system 102 to provide improved payment management functionality. The extraction engine 122 may be configured to acquire data from one or more data sources 116A-N. The extraction engine 122 may be configured to access the data sources 116A-N by use of the network 115. The network 115 may comprise any suitable communication infrastructure, including, but not limited to, a Transmission Control Protocol/Internet Protocol (TCP/IP) network, a Local Area Network (LAN), a Wide Area Network (WAN), a Virtual Private Network (VPN), a Storage Area Network (SAN), and/or the like.
In other embodiments, the extraction engine 122 may access the one or more data sources 116A-N directly, such as in local storage. Stated differently, the extraction engine 122 may extract data merely by accessing local data sources or otherwise directly accessible data sources. Extraction is not limited to extracting or otherwise obtaining data from external or remote data sources.
The billing data sources 116A may include one or more hospital billing systems, clinic billing systems, practitioner billing systems (e.g., physician billing systems), and/or the like. The healthcare data sources 116B may include, but are not limited to: electronic health record systems, Personal Health Record (PHR) systems, Personal Health Information Technology (PHIT) systems, Electronic Health Record (EHR) systems, Health Information Exchange (HIE) systems, and/or the like. The credit data sources 116C may include credit reporting agencies, such as Equifax, Experian, TransUnion, and/or the like. The demographics/consumer data sources 116N may include demographic and/or consumer profiling data sources configured to provide information including, but not limited to: census information (e.g., date of birth, head of household, marital status, ethnicity, age, education level, and the like), household information (e.g., phone number, number of dependents, length of residence, residence status, residence size, residence value, and the like) economic information (e.g., income level, purchasing power, and the like), mortgage information (e.g., mortgage amount, rate, term, and the like), neighborhood information, socio-economic indicators, and so on.
The extraction engine 122 may be configured to access the data sources 116A-N in accordance with applicable regulations, which may include, but are not limited to, regulations of the HIPAA, Payment Card Industry Data Security Standard (PCI DSS), Sarbanes-Oxley Act (SOX), Fair Credit Reporting Act (FCRA), Fair and Accurate Credit Transactions Act (FACTA), self-imposed regulations (e.g., a privacy policy or contract), jurisdictional regulations (e.g., data access regulations of particular states, countries, and/or regions), and/or the like. The extraction engine 122 may be further configured to access data of the data sources 116A-N according to particular data sharing protocols and/or standards. In some embodiments, the extraction engine 122 is configured to transform, convert, and/or translate information acquired from the data sources 116A-N for use by the payment management system 102.
As depicted in
The data source adapters 123A-N may be configured to secure data transferred to/from the data sources 116A-N by, for example, authenticating the data sources 116A-N, providing authentication credential(s) to the data sources 116A-N, encrypting data transmitted to/from the data sources 116A-N, signing data transmitted to/from the data sources 116A-N, and/or the like. In some embodiments, the data source adapters 123A-N are configured to communicate with the data sources 116A-N by use of respective, mutually authenticated secure sockets layer (SSL) connections.
The extraction engine 122 may comprise a data access policy module 223 configured to manage data access operations of the data source adapters 123A-N. The data access policy module 223 may be configured to: a) ensure compliance with data access restrictions applicable to the data sources 116A-N; b) manage authentication credentials of the data sources 116A-N (e.g., credentials used to authenticate the data sources 116A-N to the extraction engine 122, such as public key certificates, cryptographic signatures, Kerberos tickets, and/or the like); c) manage authentication credential(s) of the data source adapters 123A-N (e.g., credentials used to authenticate the data source adapters 123A-N to the data sources 116A-N, such as private keys, and/or the like); d) maintain auditing information pertaining to operations of the data source adapters 123A-N; and e) perform other similar functions. The auditing information may be stored in the datastore 121 and/or another storage system. Although
The datastore 121 may comprise a directory of entity records 210, which may comprise information pertaining to particular patients and/or guarantors of the healthcare system. In some embodiments, the entity records 210 include, inter alia, data access rules 211. The data access rules 211 may specify, inter alia, the types of information the payment management system 102 is authorized to access for particular entities. For example, a data access rule 211 for an entity may indicate whether the payment management system 102 is allowed to access healthcare information pertaining to the entity from a healthcare data source 116B. The data access policy module 223 may be configured to manage the data access rules 211 in the datastore 121; the data access policy module 223 may be configured to set and/or update data access rules 211 pertaining to particular entities in response to inputs received through one or more of: a) the client input subsystem 162, b) the guarantor input subsystem 164, and/or c) other configuration interface(s). The data access rules 211 may further include preferences regarding privacy, data sharing, and/or the like. The data access rules 211 may be configured to ensure compliance with the data access regulations, disclosed above. Accordingly, the data access policy module 223 may be configured to secure the data access rules 211, such that the data access rules 211 are only modified and/or updated in response to authorized requests. The data access policy module 223 may, for example, be configured to authenticate requests to modify the data access rules 211 to ensure that the modifications are authorized by the corresponding entity and/or entity guardian.
The data source adapters 123A-N may be configured to request or otherwise access data from the data sources 116A-N in accordance with the data access rules 211. The data source adapters 123A-N may, for example, only access healthcare information pertaining to entities that have authorized such access. The data access rules 211 may be further configured to limit access to particular types of information. A data access rule 211 may, for example, exclude certain types and/or classes of healthcare information from being accessed by the payment management system 102.
As disclosed above, the data source adapters 123A-N may be configured to request data from respective data sources 116A-N by, inter alia, issuing requests for data pertaining to particular entities. The requests may be configured to comply with the data access rules 211, disclosed above. In one embodiment, a data source adapter 123B may be configured to access specific healthcare information pertaining to a particular entity from a healthcare data source 116B. Similarly, a data source adapter 123C may be configured to acquire credit information pertaining to a particular entity from a credit data source 116C, and/or a data source adapter 123N may be configured to acquire specific demographic information pertaining to the particular entity from a demographics/consumer data source 116N. Alternatively, or in addition, one or more of the data source adapters 123A-N may be configured to access data in one or more bulk transfer operations. In one embodiment, the data source adapter 123A may be configured to perform bulk transfer operations to acquire all of the billing records for a particular period (e.g., a day) from a billing data source 116A. In another embodiment, the one or more data source adapters 123A-N may be configured to access data of respective data sources 116A-N, and in real time. As an example, the data source adapter 123A may access the billing records of a billing data source 116A (e.g., a billing system and/or records local to, or integrated with, the payment management system 100 of
The data source adapters 123A-N may be configured to acquire data according to data sharing protocol(s), format(s), or arrangement(s) supported by the respective data sources 116A-N, which may differ from the data protocol(s), format(s), and/or arrangement(s) of the datastore 121. The extraction engine 122 may, therefore, comprise data transformation modules 124A-N configured to transform, convert, and/or translate data acquired from the data sources 116A-N for use by the payment management system 102. The transformation modules 124A-N may be configured to parse data structures acquired from the respective data sources 116A-N and to transform the constituent data into a format that is compatible with the schema of the datastore 121. Although
As disclosed above, the extraction engine 122 may be configured to acquire or otherwise access data pertaining to healthcare transactions from one or more billing data sources 116A (by use of data source adapters 123A), and to transform the billing information into a normalized data format compatible with the datastore 121. The extraction engine 122 may further include a datastore interface module 125 configured to store corresponding records in the datastore 121. The extraction engine 122 may be configured to store billing transaction records 214, which may be configured to track bills issued to a particular patient and/or guarantor. A billing transaction record 214 may include, but is not limited to, a transaction identifier (e.g., invoice and/or bill identifier), a time stamp (the date and/or time corresponding to the billing transaction), the payee (e.g., hospital, clinic, service provider, etc.), service(s) provided, service type, service provider(s), service location, patient, patient type, bill type, and/or the like. The extraction engine 122 may be configured to associate billing transaction records 214 with particular patient(s) and/or guarantor(s). In some embodiments, the extraction engine 122 is configured to maintain such associations by use of links and/or references to account records 212 and entity records 210.
The bill type may indicate whether the corresponding billing transaction pertains to an amount that is non-adjudicated, adjudicated, self-pay, split balance, payment plan, financing plan, and/or the like. A non-adjudicated billing transaction record 214 refers to a billing transaction that may be covered by insurance, but that insurance adjudication has not yet taken place. A non-adjudicated billing transaction record 214 may be generated at the time the patient is discharged, at the time of the visit, and/or the like. An adjudicated billing transaction record 214 refers to a billing transaction that has been adjudicated by the insurer. Accordingly, an adjudicated billing transaction record 214 may include a self-pay amount to be paid by the patient and/or guarantor associated with the billing transaction record 214. A self-pay billing transaction record 214 refers to a portion of a billing transaction that is directed to a patient obligation (e.g. a charge not covered by insurance and/or the self-pay portion of an adjudicated billing transaction). Therefore, like the adjudicated billing transaction record 214 above, a self-pay billing transaction record 214 indicates a balance that is payable by the patient and/or guarantor associated with the billing transaction record 214. A split balance billing transaction record 214 refers to a billing transaction record 214 corresponding to a portion of a balance payable by a particular patient and/or guarantor. A financing plan billing transaction record 214 refers to a billing transaction associated with a financing plan (e.g., financing plan record 218), as disclosed in further detail herein. Although particular bill types are described herein, the disclosure is not limited in this regard and could be adapted to include any suitable bill type corresponding to any suitable billing condition, balance type, or the like.
The extraction engine 122 may be configured to acquire information pertaining to particular patients and/or guarantors (entities) of the payment management system 102. Such information may include, but is not limited to, entity identifying information (e.g., name, birthdate, address, contact information, social security number (SSN), and/or the like), insurance information (health insurance provider, limits, deductibles, co-payments, and/or the like), demographic information (neighborhood, socio-economic characteristics, and/or the like), credit information, healthcare-related information, scoring metrics, data access rules 211, and/or the like. The contents of the entity records 210 may be aggregated from the data sources 116A-N. An entity record 210 may include identifying information acquired from a billing data source 116A, credit information from a credit data source 116C, demographics and consumer information from a demographics/consumer data source 116N, and/or the like. In some embodiments, entity records 210 may further include healthcare information related to the patient (e.g., patient type) determined from information in a healthcare billing transaction and/or healthcare data source 116B.
The extraction engine 122 may be further configured to include information pertaining to patient-guarantor relationships. An entity record 210 may, for example, identify one or more guarantors. As disclosed above, a guarantor refers to an entity that is at least partially responsible for healthcare costs of a particular patient. The entity record 210 of such a patient may identify the guarantor(s) that have assumed responsibility for healthcare costs of the particular patient. Similarly, the entity record 210 of a guarantor may identify the patient(s) for whom the particular entity has assumed responsibility. In one example, the entity records 210 of a family may be correlated or otherwise associated, such that entity record(s) 210 of the parent(s) and/or guardian(s) of the family reference entity record(s) 210 of the dependent(s) of the family (and vice versa). Although examples of familiar patient-guarantor relationships are described herein, the disclosure is not limited in this regard; patient-guarantor relationships can be formed between any consenting adults. Moreover, in some embodiments, a guarantor is not responsible for financial obligations; instead, the guarantor may be granted management rights to coordinate payment for an account.
The patient-guarantor relationships may be determined by use of a correlation engine 126. The correlation engine 126 may be configured to determine patient-guarantor relationships by use of information acquired from one or more of the data sources 116A-N, including, but not limited to, billing transaction information (e.g., a guarantor may be specified by the billing data source 116A), healthcare information (e.g., parent-child relationships) acquired from a healthcare data source 116B, demographic information, and/or the like. Alternatively, or in addition, the correlation engine 126 may be configured to establish patient-guarantor relationships in response to inputs provided through one or more of the client input subsystem 162 and/or guarantor input subsystem 164, as disclosed in further detail herein.
The patient-guarantor relationships managed by the correlation engine 126 may be used to generate respective account records 212. The account records 212 may identify a patient and guarantor(s) (e.g., may be linked to a patient entity record 210 and guarantor entity record(s) 210). As disclosed above, in some instances, the patient and guarantor may be one and the same (e.g., the patient may be solely responsible for payment and, as such, may act as his or her own guarantor). Alternatively, a guarantor may be responsible for billing transactions corresponding to one or more other entities (e.g., a parent may act as the guarantor for billing transactions corresponding to his or her dependents). Accordingly, and as illustrated in
The extraction engine 122 may be configured to link account records 212 to billing transaction records 214 by use of the correlation engine 126. The correlation engine 126 may be configured to associate a billing transaction record 214 with an account record 212 by a) accessing information in the billing transaction record 214 that identifies a patient and/or guarantor (e.g., patient and/or guarantor name, all or portion of an SSN, and/or the like); b) identifying entity record(s) 210 corresponding to the patient and/or guarantor in the datastore 121 using the identifying information and/or the patient-guarantor relationships of the entity records 210; and c) linking the billing transaction record 214 with an existing account record 212 corresponding to the accessed entity record(s) 210, or generating a new account record 212 for the billing transaction record 214.
The extraction engine 122 may be further configured to acquire information pertaining to payment transactions from the billing data sources 116A (by use of the data source adapters 123A). In response, the extraction engine 122 may be configured to store a payment transaction record 216 in the datastore 121 (by use of a transaction module 124A and/or datastore interface 125). The payment transaction record 216 may include, but is not limited to, a transaction identifier (e.g., invoice and/or bill identifier), a payment date, a payment source (e.g., cash, check, credit card, etc.), a payment type (e.g., full payment, co-payment, etc.), payee-identifying information, an indication of where the transaction took place (e.g., hospital, clinic, on-line, etc.), and/or the like. The correlation engine 126 may be configured to link the payment transaction record 216 to a billing transaction record 214 based on, inter alia, the transaction identifier, patient and/or guarantor-identifying information of the payment transaction record 216, and/or the like. The balance of a billing transaction record 214 may be paid over a number of different payment transactions; therefore, and as illustrated in
The transaction information acquired by the extraction engine 122 may comprise a normalized, longitudinal data set, which may be leveraged by other subsystems of the payment management system 102. Referring to
The graphical user interface 300 enables a client provider user to interface with the client input subsystem 162 to access the functionality of the business intelligence subsystem 142 and the scoring subsystem 144 of
The report engine 410 may be further configured to generate a report 411B retaining to a particular billing system (e.g., hospital, clinic, service provider, professional, and/or the like). The report 411B may include a history of billing transaction records 214 and/or payment transaction records 216 (if any) that satisfy a particular selection criterion (e.g., that pertain to services provided by a particular service provider and/or managed by a particular billing system). The report engine 410 may be configured to generate other reports 411N corresponding to any suitable aspect of the payment management system 102.
The filter engine 412 may be configured to dynamically filter the reports 411A-N to generate corresponding filtered reports 413A-N. The filter engine 412 may be configured to filter report data based on one or more filter criteria. Exemplary filter criteria may include, but are not limited to, clinic versus hospital billing (e.g., compare payment metrics of payment transactions of a particular clinic to payment transactions of a particular hospital), billing location, balance, patient and/or guarantor financial class (and/or other demographic characteristics), time frame, and/or the like. The business intelligence subsystem 142 may be configured to make the reports 411 and/or filtered reports 413 available to the presentation tier 160 for display to a user. The business intelligence subsystem 142 may be further configured to create reports 411 and/or filtered reports 413 in response to inputs provided via the client input subsystem 162 and/or guarantor input subsystem 164. Alternatively, or in addition, the business intelligence subsystem 142 may be configured to actively generate and/or update report data for use by the payment management system 102. The business intelligence subsystem 142 may be configured to generate one or more reports 411 and/or filtered reports 413 in response to the extraction engine 122 injecting data of one or more data sources 116A-N into the datastore 121. The reports 411 and/or filtered reports 413 may be maintained in respective report records 219 in the datastore 121.
In some embodiments, the business intelligence subsystem 142 may further comprise a forecast engine 416, which may be configured to generate cash flow forecasts for both expected payer and patient cash payments on balances residing on and off a provider's balance sheet (e.g., accounts receivable, financing plans held off balance sheet, bad debt, etc.) based on, inter alia, PTP scoring data and historical payment characteristics corresponding to the account records 212 and/or billing transaction records 214.
The reports 411, filtered reports 413, and/or forecasts 419 generated by the business intelligence subsystem 142 may incorporate one or more PTP scores and/or segmentation classifications. As disclosed above, a PTP score refers to a PTP metric, which may be derived, in part, from data acquired from the data sources 116A-N and, in particular, to billing and/or payment transaction records 214, 216. The application tier 140 may comprise a scoring subsystem 144 configured to generate PTP scores. In some embodiments, the scoring subsystem 144 is configured to generate different types of PTP scores based on a “stage” of an account (e.g., account's status within the client provider's billing system, such as pre-A/R, A/R, bad debt, etc.).
ScoringThe staging module 510 may be configured to determine the current stage of an account record 212 based on data acquired from the billing data sources 116A (e.g., billing transaction records 214 and/or payment transaction records 216). In some embodiments, the staging module 510 comprises a monitor 511 configured to detect staging events regarding accounts managed by the payment management system 102. In some embodiments, the monitor 511 comprises stored procedural code configured for execution by the datastore 121 in response to particular conditions (e.g., a stored procedure, database trigger, or the like). As disclosed above, the conditions pertaining to account staging may include, but are not limited to, creation of and/or modifications to account records 212, billing transaction records 214, payment transaction records 216, financing plan records 218, and/or the like. Alternatively, or in addition, the monitor 511 may be configured to query the datastore 121 to identify events relevant to account staging and/or may be triggered by the extraction engine 122 in response to, inter alia, the extraction engine 122 injecting data into the datastore 121.
In some embodiments, the staging module 510 includes an assignment engine 512 configured to determine a current state of an account record 212 in response to detecting relevant staging events in the datastore 121 (by use of the monitor 511). The assignment engine 512 may designate an account record 212 as a stage 0 account in response to one or more of the following: a) creation of the account record 212 in the datastore 121, b) associating the account record 212 with a non-adjudicated billing transaction record 214 (based on the bill type of the account record 212), c) associating the account record 212 with a patient and/or guarantor (e.g., an entity record 210), and/or d) other similar actions. The assignment engine 512 may designate an account record 212 as a stage 1 account (self-pay account) in response to associating the account record 212 with an adjudicated, self-pay, and/or split-balance billing transaction record 214. The assignment engine 512 may designate an account record 212 as a stage 2 account (financing plan) in response to creating a financing plan record 218 corresponding to the account record 212 (e.g., in response to setting up a financing plan for one or more billing transaction records 214 associated with the account record 212). The assignment engine 512 may designate an account record 212 as a stage 3 account (bad debt) in response to determining that the billing system has marked an account as bad debt and/or determining that a billing transaction record 214 associated with the account record 212 has not been paid within a predetermined accounts receivable (AR) cycle of the corresponding billing system (e.g., has remained unpaid for 120 days or longer). The assignment engine 512 may designate an account record 212 as a stage 4 account (secondary bad debt) in response to determining that the billing system has marked an account as secondary bad debt and/or determining that a billing transaction record 214 associated with the account record 212 has not been recovered in a first bad-debt recovery cycle. The assignment engine 512 may be further configured to update the account record 212 in the datastore 121 to indicate the stage assigned to the account record 212 (e.g., the account record 212 may include a stage field configured to indicate the stage assigned thereto). Although particular stages and/or stage assignment criteria are described herein, the disclosure is not limited in this regard and may be adapted to assign account records 212 to any suitable stage corresponding to any suitable payment management status and/or action(s).
The staging module 510 may further comprise a trigger engine 513 configured to implement one or more triggered actions 514A-E in response to one or more of the following: a) assigning a stage to an account record 212, b) updating data pertaining to an account record 212 in the datastore 121, c) a request for updated stage assignment information, and/or d) other similar actions.
The triggered actions 514A corresponding to stage 0 (account creation) may include generating a front-end PTP score for the account record 212.
The triggered actions 514B corresponding to stage 1 (self-pay) may include generating a healthcare PTP score corresponding to the account record 212, sending PTP segmentation identifiers and/or information to the corresponding billing system(s), and/or creating a record of a self-pay balance for use by the payment management system 102.
The triggered actions 514C corresponding to stage 2 (financing plan) may include a) creating a financing plan record 218 corresponding to the account record 212 (if not yet created) and b) setting a due date for the financing plan record 218. The due date may be used to determine whether the account should be placed into stage 3 (bad debt) due to failure to make timely payments.
The triggered actions 514D corresponding to stage 3 (bad debt) may include a) determining whether the account record 212 is a candidate for presumptive charity and/or b) generating a bad debt PTP score for the account record 212.
The triggered actions 514E for stage 4 (secondary bad debt) may comprise generating a secondary bad debt PTP score for the account record 212.
Determining whether an account record 212 is suitable for presumptive charity may include calculating a charity score for the account record 212 using, inter alia, PTP score(s) calculated for the account record 212 and/or other data, such as a current health condition of the patient and/or guarantor(s), amount owed, income level, credit reporting information, and the like. For example, guarantors can be assessed for financial assistance eligibility by comparing a household income estimate and a size of household estimate to a percentage of the Federal Poverty Level to determine a charity write-off (e.g., for a given household size, some percentage of the Federal Poverty Level qualifies the guarantor for xx % charity write-off). Typically, an abundance of guarantors become “eligible” according to this approach using strictly “estimates” of income and household size. These eligible guarantors can be ranked according to PTP score(s) for each account record 212 to determine how the charity write-offs are actually dispersed. A PTP threshold can be adjusted up or down to either channel more or less money to charity depending on a charity write-off budget.
A charity score may be calculated by receiving third-party data such as from a credit data source 116C and/or demographic/consumer data source 116N (
A charity score may also be calculated using solely data from the billing data source 116A and/or the healthcare data source 116B. In other words, a charity score may be calculated without relying upon credit reporting data (e.g., traditional credit bureau data) and/or demographics/consumer data. The scoring engine 516 may be configured to calculate a charity score for an account and determine whether the account is a candidate for presumptive charity by comparing the charity score to a threshold. The staging module 510 may be configured to identify account records 212 that are candidates for presumptive charity to an administrator of the payment management system 102, who may selectively write off the candidate accounts.
The scoring engine 516 of the scoring subsystem 144 may be configured to generate PTP scores 518 for account records 212. The scoring engine 516 may be configured to generate PTP scores 518 in response to a) updates to the datastore 121 (e.g., in response to receiving relevant data from the data sources 116A-N) and/or b) the triggered actions 514A-E of the trigger engine 513 (e.g., active, always-on scoring). Alternatively, or in addition, the scoring engine 516 may be configured to generate other PTP metrics, such as guarantor segment (or group) identifier, in response to requests received through, inter alia, interface(s) of the presentation tier 160 (e.g., on-demand scoring). The other PTP metrics may indicate a propensity to pay an amount owed. For example, a guarantor segment (or group) identifier may indicate a segment, group, classification, category, or the like, in which the guarantor belongs. A propensity-to-pay may be associated with the metric (e.g., a guarantor grouping) and thereby may indicate collection strategies for the guarantor and/or may be used to determine financing terms, similar to how a PTP score can be used. The scoring engine 516 may be further configured to generate different types of PTP scores 518 in accordance with a stage of the account records 212 and/or in response to requests for particular PTP score types (e.g., front-end PTP score, healthcare (HC) PTP score, bad debt (BD) PTP score, secondary BD PTP score, and so on).
The PTP data aggregation module 517 may include one or more PTP data aggregation engines 524A-N configured to aggregate particular types of PTP data 525A-N. The PTP data aggregation module 517 may include, but is not limited to, a healthcare transaction data aggregation engine 524A, a healthcare condition data aggregation engine 524B, a credit data aggregation engine 524C, a demographics data aggregation engine 524N, and so on. The healthcare transaction data aggregation engine 524A may be configured to derive historical healthcare transaction data 525A from a history of billing transaction records 214, payment transaction records 216, and/or financing plan records 218 associated with the account record 212. The healthcare transaction data 525A may include and/or be derived from billing transaction records, payment transaction records, and/or financing plan records associated with account records of one or more guarantors. The historical healthcare transaction data 525A may include PTP characteristics of guarantors, which may include, but are not limited to, time to payment for healthcare transactions, late payments, payment amounts, insurance coverage, copayments, flexible spending account activity (e.g., estimated remaining balance), healthcare spending account activity, financing plan history (e.g., whether the patient and/or guarantor(s) have used a financing plan to pay for services and/or whether the payments were made in a timely manner), and so on.
The healthcare condition data aggregation engine 524B may be configured to acquire information pertaining to a healthcare condition and/or status of the patient and/or guarantor(s) associated with the account record 212. The healthcare condition data 525B may include, but is not limited to, diagnoses, disease conditions, chronic health condition(s), degenerative conditions, and/or the like. In some embodiments, the healthcare condition aggregation engine 524B is configured to derive healthcare condition data 525B from billing transaction information acquired from the billing data sources 116A (e.g., treatment codes, diagnostic codes, and/or the like). Alternatively, or in addition, healthcare condition data 525B may be acquired from a healthcare data source 116B (e.g., directly from healthcare records of the patient and/or guarantor(s)).
The credit data aggregation engine 524C may be configured to aggregate credit reporting data 525C pertaining to the patient and/or guarantor(s) of the account record 212. The credit reporting data 525C may be acquired and/or derived from one or more credit data sources 116C, as disclosed above.
The demographics data aggregation engine 524N may be configured to aggregate demographics data 525N pertaining to the patient and/or guarantor(s) of the account record 212. The demographics data 525N may be acquired and/or derived from one or more demographics/consumer data sources 116N, as disclosed above.
As illustrated in
The PTP calculation module 520 may be configured to determine which PTP score(s) 518A-N are to be calculated, and to request corresponding PTP data 525A-N from the PTP data aggregation module 517. The PTP calculation module 520 may select a type of PTP score(s) 518A-N to calculate based on, inter alia, the stage assigned to the account record 212, data availability, a request for a particular type of PTP score 518A-N, and/or the like.
As illustrated in
The front-end PTP engine 522A may be configured to calculate a front-end PTP score 518A for a guarantor based on, inter alia, a) credit reporting data 525C and/or b) demographics data 525N. The front-end PTP score 518A may correspond to the PTP of a patient and/or guarantor(s) independent of healthcare transaction history and/or characteristics. The front-end PTP score can be used to guide front-end staff of an appropriate collection tactic at the scheduling/registration of a patient before any services have been provided. For example, the front-end PTP score may guide how much a patient/guarantor may be required to pay in advance or “arrange in advance” of receiving a treatment. The front-end PTP score may be generated for an estimate of charges for healthcare services to be performed. The front-end PTP score may be based on and/or integrate preferences of the provider in terms of matching front-end tactics according to such variables as type of treatment (emergent vs. scheduled and medically necessary vs. scheduled and elective), past payment behavior, prior discounts, balance range, etc. Recommended collection tactics may include an amount of cash payment to require prior to providing treatment, authorization for financing options, and the like. The front-end PTP score may allow creation of a financing plan and payment authorization structure at time of service that would not be ratified until after an insurance claim is adjudicated and a patient balance is known. For example, if the estimate is $2,000, in order to proceed the patient may be required to establish an account in the payment management system 102 and agree to a 10-month loan at $200 per month. As another example, for maternity care, a patient may be required to funding a deposit balance (e.g., $300 per month for nine months) to fund the arrival of the baby and associated medical bills. The deposit account balance may be tracked by an account in the payment management system 102.
The HC PTP engine 522B may incorporate the data of the front-end PTP score 518A (credit reporting data 525C and/or demographics data 525N) as well as historical healthcare transaction data 525A and/or healthcare condition data 525B. The HC PTP score 518B may, therefore, indicate a PTP based on historical healthcare payment activity of the patient and/or guarantor(s) and/or conditions affecting the patient and/or guarantor(s).
The BD PTP engine 522C may be configured to calculate a BD PTP score 518C incorporating data 525A-N, and may include activity that has occurred during the AR cycle (e.g., partial payments, additional debt accrued, updated historical healthcare transaction data 525A, updated healthcare condition data 525B, updated credit reporting data 525C, updated demographics data 525N, and so on).
The secondary BD PTP engine 522N may calculate a secondary BD PTP score 518N based on further updates during bad debt recovery.
The PTP calculation engines 522A-N may incorporate similar sets of data (data 525A-N) to generate the PTP scores 518A-N. The PTP calculation engine 522A-N may differ with respect to the weighting and/or combination of algorithms used to calculate the PTP scores 518A-N. In some embodiments, the PTP calculation engines 522A-N are configured to calculate PTP scores 518A-N by use of respective regression analysis models 523A-N. The regression analysis models 523A-N may comprise PTP statistical modeling data pertaining to sets of account records 212 (e.g., accounts in particular stages 0-4). The regression analysis models 523A-N may, therefore, correspond to different variable and/or data weighting values for the PTP data 525A-N based on, inter alia, statistical estimation and/or modeling processes within the respective account record sets. Accordingly, the PTP scores 518 generated by the PTP engines 522A-N may differ significantly despite incorporating similar sets of PTP data 525A-N.
The PTP scores 518A-N may be provided to a client provider billing system and/or presented to a provider via an interface, such as the graphical user interface of the client input subsystem 162 of
In some embodiments, the scoring subsystem 144 may further include a charity evaluation module 527. The charity evaluation module 527 may be configured to identify account records 212 that are candidates for presumptive charity (write-off). The charity evaluation module 527 may be configured to identify presumptive charity candidates in response to account records 212 that satisfy charity conditions. In some embodiments, the charity evaluation module 527 is configured to calculate a charity score 528 for an account record 212, which may be based on, inter alia, one or more PTP scores 518 corresponding to the account record 212 (e.g., BD PTP score 518C) and an ability-to-pay metric that includes, but is not limited to, the amount owed as indicated by the historical healthcare transaction data 525A, the condition of the patient and/or guarantor(s) as indicated by the healthcare condition data 525B, debt level as indicated by the credit reporting data 525C, income level as indicated by the demographics data 525N, and so on. The charity evaluation module 527 may be configured to compare the charity score 528 to a predetermined threshold to determine whether the corresponding account is suitable for presumptive charity. As illustrated in
In some embodiments, the charity evaluation module 527 is configured to determine charity eligibility based on demographic characteristics of the patient and/or guarantor (e.g., income estimate, size of household, and/or the like). The demographic characteristics may be compared against poverty guidelines (e.g., Federal Poverty Level) and/or hospital policy to identify accounts that fall within the client providers' policies for charity relief (e.g., 0%, 50%, 80% or 100% of poverty-level cases). PTP scores 518A-N associated with the guarantor(s) may be used to rank the identified accounts to determine an actual distribution of charity. Charity distributions may, therefore, be made to guarantors that are both a) eligible for charity according to the demographic characteristics disclosed above, and b) are least likely to be able to pay according to the corresponding PTP scores 518. The charity evaluation module 527 may be further configured to hold out samples of charity eligible accounts that do not receive charity in order to, inter alia, calculate an optimal point in a charity allocation curve where the foregone collection opportunity on charity accounts is optimized for the community benefit of classifying an impaired asset as presumptive charity rather than bad debt. A charity guideline may be adjusted using the PTP scores 518 in accordance with a specific charity target or budget (while optimizing AR and charity account selection). As previously noted, the PTP scores 518 may be determined based solely on historical transaction data tracked in a billing system (e.g., billing transaction records 214, payment transaction records 216, and financing plan records 218), and without third-party data (e.g., credit reporting data 525C).
The scoring subsystem 144 may further comprise a segmentation engine 537 configured to determine a segment classification 538 for the account record 212. The segment classification 538 may be used by other tiers, modules, components, and/or engines of the payment management system 102 to manage the account record 212. The segmentation module 537 may be configured to assign segment classifications based on, inter alia, the stage assigned to the account records 212 and/or the PTP score(s) 518 of the account records 212. The segment classifications may include, but are not limited to, high risk, moderate risk, low risk, delayed payment, on-time payment, and/or the like. The segment classifications may be used to determine contact and/or billing procedures for account records 212, such as contact frequency, contact type, financing plan characteristics (e.g., whether the account record 212 is eligible for a financing plan and/or the terms of the financing plan), interest rates for financing plans, and/or the like. The segmentation classifications 538 may be based on a statistical distribution of the PTP scores 518, regression analysis, and/or the like. The segmentation classification 538 of the account record 214 may be maintained in the datastore 121, as illustrated in
Referring back to
Determining an accounts receivable forecast 419 may comprise scaling the payments owed under a set of account records 212 by respective PTP score(s) 518 of the account(s) and/or estimating a payment time of the accounts based on the time-to-pay estimates, disclosed above. The PTP score(s) 518 used to generate the forecasts 419 may be selected in accordance with the stage assigned to the respective account records 212 by the staging module 510.
The forecast engine 416 may be configured to generate forecasts 419 pertaining to particular aspects of the payment management system 102 including, but not limited to, forecasts 419A for particular time frames, forecasts 419B for particular billing entities (e.g., particular hospitals, clinics, service providers, and/or the like), forecasts 419N for particular billing locations, and/or the like. Generating a time-frame forecast 419A may comprise estimating accounts receivable activity on all outstanding account records 212 based on corresponding PTP score(s) 518 and/or time-to-pay estimates, as disclosed above. Generating a billing entity forecast 419B may comprise a) identifying a set of billing transaction records 214 corresponding to a particular billing entity, and b) calculating an accounts receivable forecast 419 based on PTP and/or time-to-pay metrics of the corresponding account records 212, as disclosed above. Generating a location forecast 419N may comprise a) identifying a set of billing transaction records 214 corresponding to a particular location, and b) calculating an accounts receivable forecast 419B based on PTP and/or time-to-pay metrics of the corresponding account records 212, as disclosed above. Although exemplary forecasts 419 are described herein, the disclosure is not limited in this regard and could be adapted to generate forecasts pertaining to billing transaction records 214 and/or account records 212 selected and/or filtered based on any suitable criterion (e.g., demographics, insurance type, socio-economic level, segment classification 538, and so on).
Step 620 may comprise calculating a PTP score 518 for an account record 212 by use of the PTP data 525A-N of step 610. Step 620 may comprise extracting PTP characteristics from the PTP data 525A-N, weighting the extracted characteristics, and/or combining the weighted characteristics to calculate one or more PTP score(s) 518, as disclosed above. The PTP characteristics may include time to payment for healthcare transactions, late payments, payment amounts, insurance coverage, copayments, flexible spending account activity (e.g., estimated remaining balance), healthcare spending account activity, financing plan history (e.g., whether the patient and/or guarantor(s) have used a financing plan to pay for services and/or whether the payments were made in a timely manner), a total amount presently owed to a provider (or one or more client providers), prior bad debt charge-offs, prior hardship program assistance (charity), time periods between transactions, and dispute history.
In some embodiments, step 620 further comprises determining a stage associated with the account record 212. As disclosed above, stage assignments may be based on account and/or billing transaction events, such as account creation, billing adjudication, self-pay, split balance, bad debt, secondary bad debt, and/or the like. Step 620 may comprise calculating a particular PTP score 518A-N based on the assigned stage. Accordingly, step 620 may comprise calculating one or more of a front-end PTP score 518A, an HC PTP score 518B, a bad debt PTP score 518C, a secondary bad debt PTP score 518N, and/or the like.
In certain embodiments, one or more of the PTP score(s) 518 calculated at step 620 incorporate historical healthcare transaction data 525A pertaining to the patient and/or guarantor(s). The one or more PTP score(s) 518 may, therefore, incorporate characteristics and/or metrics that are specific to healthcare transactions of the patient and/or guarantor(s). Such characteristics may include, but are not limited to, historical payment amounts, historical time to payment, bad debt (if any), secondary bad debt (if any), payment types, payment relationships (e.g., guarantor on other healthcare transactions), and/or the like.
In certain embodiments, one or more of the PTP score(s) 518 calculated at step 620 incorporate information pertaining to a health condition of the patient and/or guarantor(s). As disclosed above, information pertaining to health condition(s) of the patient may be derived from billing transaction information provided by the billing data source(s) 116A. The health condition(s) may be determined based on condition and/or diagnosis coding information in the billing information. The health condition(s) of the guarantor (if different from the patient) may be determined based on separate billing transaction information obtained from one or more other healthcare billing data sources 116A (e.g., other patient visits, diagnosis, and/or the like). Alternatively, or in addition, information pertaining to the health condition of the patient and/or guarantor(s) may be obtained from a separate healthcare data source 116B. The health condition of the patient and/or guarantor(s) may be used to determine payment probability and/or timing (patients with serious conditions may not be in a position to pay in a timely manner).
Step 620 may further comprise calculating a charity score 528 for the account record 212, which, as disclosed above, may be used to identify accounts that are candidates for write-off (presumptive charity). Step 620 may further comprise assigning a segment classification 538 to the account record 212, as disclosed above.
Step 621 may comprise generating a forecast corresponding to accounts receivable activity pertaining to the set of account records 212 accessed at step 611. Step 611 may comprise determining a likelihood of payment transactions on the set of accounts during a particular time period (and/or whether any payment will be received). The forecast of step 621 may incorporate a) PTP score(s) 518 of the account records 212 and/or b) time-to-pay estimates of the account records 212. The time-to-pay estimates may be derived from PTP score(s) 518 of the account records 212 and/or PTP data 525A-N, as disclosed above.
Public Payment Portal SubsystemThe authentication engine 706 may interface with the datastore 121 of
The payment clearance and routing engine 708 may coordinate transaction authorization and payment processing. The payment clearance and routing engine 708 may interface with a payment gateway that facilitates and/or coordinates payment from the guarantor's financial institution and the client provider's financial institution. The payment clearance and routing engine 708 may also coordinate communication to the billing system when a payment transaction is completed or otherwise effectuated.
Once authentication information is received 804 that corresponds to the received 802 visit charge data, the user may be able to specify a payment vehicle and amount. User input is received 806 specifying the payment vehicle (e.g., the guarantor's credit card, debit card, bank account, Health Savings Account, or the like) and specifying a payment amount. A financial transaction authorization request is generated 808. The transaction is processed 810 between the guarantor financial institution and the client provider financial institution. The processing 810 may be facilitated and/or performed by a payment gateway. Authorization for the transaction may be granted and thus received in response to the transaction authorization request. Alternatively, confirmation of the transaction may be received. Once the transaction has been completed or otherwise effectuated, the billing system may be notified 812 of the transaction. The notification may occur by generation of a transaction posting file that may be transmitted to the billing system.
The payment posting files may include, but are not limited to, the following: an identifier (e.g., a billing system assigned identifier at a charge level, at the visit charge level, or at the guarantor level), a transaction amount (e.g., a positive or negative amount that may include multiple fields for principal, interest, commission, etc.), a transaction code to define the type of transaction (e.g., patient payment, prompt-pay discount adjustment, interest charged, interest paid, etc.), a reference number (e.g., a field which can be loaded along with the payment and extracted again to load back to the payment management system for use in identifying which payments have or have not yet been posted back into a billing system), a transaction date, and a text note (e.g., text to be shown in the user interface of the billing system).
The public payment portal subsystem may enable receiving and/or configuring instructions to make recurring payments (e.g., configure financing plans) to pay for visit charges. For example, the patient/guarantor could decide to make four payments (e.g., $250 each on a $1,000 obligation) and schedule each of those payments to occur on a periodic basis (e.g., monthly) over four months. An anonymous unique transaction authorization identifier (e.g., a token received from a third-party gateway) may be received and stored. The anonymous unique transaction authorization identifier or a similar token could then be presented again to the gateway in the ensuing months to effectuate the recurring transactions.
Guarantor Input SubsystemThe user interface 900 of
The account overview area 902 displays a brief overview of a current balance on the account (including all managed accounts), a statement balance (including all managed accounts), a next payment date, and a next statement date.
The autopay overview area 904 displays information relating to payments (or amounts of money) that are pending to be automatically deducted from a preconfigured payment vehicle (e.g., the guarantor's credit card, debit card, bank account, or Health Savings Account) or according to a preconfigured payment methodology for existing financing plans as well as preset payment arrangements for current statement charges.
The payment options area 906 displays options for paying for health services rendered during new visits (or visits pertaining to a current statement period). The payment options may include paying the current visits balance in full to potentially receive a discount. The discount may be configured by the client healthcare provider that provided the healthcare services to the patient. The payment options may also include an option to finance payment for healthcare services rendered during new visits for the current statement period. The user interface 900 may enable the guarantor to configure financing terms that may better fit a budget of the guarantor or otherwise be more workable for the guarantor to successfully pay in full, or over time, for the charges for the healthcare services rendered for the visits. The user interface 900 may also indicate preset financing terms which may be accepted by the guarantor. The user interface 900 may be configured to indicate automatic acceptance of the preset financing terms if another payment option is not selected. The preset financing terms may be preconfigured, for example, by the client healthcare provider. The illustrated user interface 900 of
The account summary area 908 displays information summarizing a current status of the account, including a summary of the current statement period and a summary of recent activity.
A “Statements” link 910 is provided on the user interface 900 to enable the logged in guarantor to access an electronic statement of the guarantor's account. A “My Visits” link 912 is provided on the user interface 900 to enable the guarantor to access and view information about visits included or otherwise associated with the account of the guarantor or with an account managed by the guarantor. A “My Financing” link 914 is provided on the user interface 900 to enable the guarantor to access information pertaining to financing plans that the guarantor has taken out to finance payment for healthcare services. A “My Payment History” link 916 is provided on the user interface 900 to enable the guarantor to access information pertaining to payments the guarantor has made in direct payment for healthcare services rendered or in payment toward financing plan balances for financing plans taken out to finance payment for healthcare services.
The user interface 900 also includes a manage account tab 920, a payments and financing tab 922, and a support tab 924. The manage account tab 920 enables a guarantor to access account management tools and/or functionality, such as viewing and/or modifying personal information, accessing account statements, accessing information about visits, and managing a household (e.g., linked accounts). The payments and financing tab 922 enables a guarantor to access information relating to payments of the guarantor and financing plans the guarantor may have taken out to finance payment for healthcare services. The information may include a listing of financing plans, a listing of payment methods, pending payments (e.g., automatic transactions that are scheduled), and a payment history. Functionality may also be provided on the payments and financing tab 922 to review (e.g., forensically “trace”) where a given payment was applied (e.g., to which billing system accounts, visits, and visit charges). The support tab 924 enables a guarantor to access support information.
As noted above, the user interface 900 of
The user interface 900 of
The registration engine 1006 provides functionality to enable a guarantor to register for access to the private payment portal subsystem 1000. The registration engine 1006 receives information for guarantors and pre-approval or acceptance of registration from a client provider. The information for guarantors may be received and stored in a patient/guarantor database in the datastore 121 of
The authentication engine 1008 may receive user login and password information and authenticate a guarantor, to confirm the guarantor is registered, before allowing access to the private payment portal subsystem 1000 and PHI accessible therethrough. The authentication may access registered guarantor information extracted from, for example, a billing system and stored in a database in the datastore 214. The authentication engine 1008 may also perform more rigorous authentication, for example, at registration or at login. For example, the authentication engine 1008 may cross check guarantor information with third-party data sources to perform identity verification (e.g., looking for one or more matches to a name, address, SSN, email, etc.) or alternatively offering multifactor authentication.
The guarantor linking engine 1010 may provide functionality for linking accounts. For example, a first guarantor may request a second guarantor to manage the first guarantor's account (e.g., a request to be managed), or the first guarantor may request to manage the second guarantor's account (e.g., a request to manage). The guarantor linking engine 1010 enables a first guarantor to request or assign (and a second guarantor to accept) managerial responsibilities for the first guarantor's account. The second guarantor, upon accepting managerial responsibilities, accepts financial responsibility for the account and/or obligations of the first guarantor (or managed guarantor). The guarantor linking engine 1010 may also enable either party to sever a linkage at any time, such that the formerly managed guarantor (e.g., the first guarantor) again assumes responsibility for all past and current obligations. The guarantor linking engine 1010 implements and facilitates ensuring any necessary permissions and releases are properly executed, managed, and/or stored.
The guarantor matching engine 1012 may identify orphan, unmatched, or otherwise unassociated accounts (e.g., including charges, payments, and other obligations and/or transactions) within and across one or more billing systems for a guarantor. Described differently, the guarantor matching engine 1012 can identify unmatched accounts in a billing system that should be associated with a guarantor account record in the payment management system, can determine the guarantor account those unmatched billing system accounts should be associated with, and can associate those unmatched billing system accounts to the appropriate guarantor account record in the payment management system. The guarantor matching engine 1012 may utilize a matching algorithm that may use or otherwise consider, for example, one or more of: a name of the patient or guarantor on the unmatched transaction, at least a portion of an ID number (e.g., an SSN, driver's license), a date of birth, and an address. Once the match or association is made, the formerly unmatched accounts may be tracked in this associated format even if the originating billing systems do not realize these accounts should be tied to the same guarantor and are not properly associated in the billing system itself. The guarantor matching engine 1012 may allow a guarantor to match an account in a billing system that the guarantor may be aware of, such as by receiving a paper billing statement from a billing system of the client healthcare provider. The visit and/or corresponding visit charges may belong to the current guarantor (or a currently managed guarantor), but may reside in a different billing system of the client provider from other visits and corresponding visit charges that are properly reflected on the electronic statement. The account of the guarantor within the different billing system may be unmatched to the account of the guarantor associated with the electronic statement. The account matching functionality that is provided by the guarantor matching engine 1012 enables the guarantor to locate the missing visit data and match the associated billing system account with the guarantor's account corresponding on the payment management system. Once an unmatched account in a billing system is associated with a guarantor account in the payment management system (either through matching logic or if the user manually links an otherwise orphan account), that association persists even though the billing system itself may not recognize the relationship. In other words, the billing system may not be updated based on the matching process. The billing system tracking remains independent of the payment management system tracking.
The visits batching engine 1014 may associate all visits for a given guarantor (or group of linked guarantors) during a specific period of time (e.g., monthly) and present this aggregated pool of obligations as a batch of open charges and/or an open charges balance for payment or for financing. The visits batching engine may compile visit data and/or visit charge information for the statement engine 1016.
The statement engine 1016 may gather visit data and/or visit charge data to generate and provide electronic statements. The statement engine 1016 may also enable a guarantor to view a listing of the visits associated with his account, sort them, filter them, understand how payments were applied to principal or interest, etc. The statement engine 1016 may also enable a user to drill down on a visit to view more detailed information. The statement engine 1016 may also present functionality (e.g., a link or button) to enable a guarantor to access the dispute engine 1022 to dispute a visit charge on the electronic statement.
The payment terms management engine 1018 may compare authorized payment terms with the specific characteristics of a given guarantor (including outputs of the scoring subsystem) to determine what payment offers should be made available to the given guarantor. The payment offers may include prompt payment discounts, financial hardship discounts, other discounts, and the like. The authorized payment terms may be preconfigured by a provider or other asset holder with legal ability to collect a payment. The provider or asset holder may configure different authorized terms for different groups, segments, or classifications of guarantors. A guarantor may be grouped by provider-level, guarantor-level, and/or visit-level decisioning and/or underwriting such that any visit or set of visits for any patient and/or for any guarantor can be channeled a customized payment offer. The decisioning may include decisioning rules that define criteria to group guarantors. The criteria, as mentioned, may be at a provider-level, a guarantor-level, and/or a visit-level (e.g., provider, guarantor income estimate, balance amount, insurance carrier, type of treatment, etc.). Providers can also enable automated discounts for uninsured patients pursuant to the provider's policies.
The payment clearance and routing engine 1020 may facilitate payment transactions. For example, the payment clearance and routing engine 1020 may generate transaction authorization requests for interfacing with a payment gateway. The payment clearance and routing engine 1020 may also generate transaction posting files to communicate to a billing system a completed or otherwise effectuated payment transaction. The payment clearance and routing engine 1020 may first clear a financial transaction between a guarantor's bank and a provider's (or asset holder's) bank, facilitated by a third-party payment gateway, and then disaggregate that singular monthly payment to multiple visits (accounts) of the one or more originating billing systems. The payment clearance and routing engine 1020 creates posting files that allocate an appropriate payment amount to the appropriate visits (accounts) within each of the relevant billing systems (with further allocation to principal and interest amounts in the relevant system of record). The payment amount could be a combination of the amount due on the current month's batch of visits plus any monthly payments due on prior batches that have been financed.
The payment posting files may include, but are not limited to, the following: an identifier (e.g., a billing system assigned identifier at a charge level, at the visit charge level, or at the guarantor level), a transaction amount (e.g., a positive or negative amount that may include multiple fields for principal, interest, commission, etc.), a transaction code to define the type of transaction (e.g., patient payment, prompt-pay discount adjustment, interest charged, interest paid, etc.), a reference number (e.g., a field which can be loaded along with the payment and extracted again to load back to the payment management system for use in identifying which payments have or have not yet been posted back into a billing system), a transaction date, and a text note (e.g., text to be shown in the user interface of the billing system).
The dispute engine 1022 may enable dispute functionality for allowing a guarantor to dispute a visit charge on a statement or otherwise facilitate communication between a guarantor and a provider to address issues. A dispute may include a claim that insurance coverage was available or misapplied, a dispute of a charge, a request for charity or other financial assistance, or any other issue, concern, or situation in which a guarantor desires a client provider to reconsider a visit charge and/or to contact the guarantor regarding a visit charge. The dispute engine 1022 may enable secure two-way electronic communication between the guarantor and the client provider. The dispute engine 1022 may change a status of visit charges to “suspended” and/or remove the charge from the account balance until the dispute is resolved. The dispute engine 1022 may also implement or interface with one or more work queues, such as a dispute queue, to queue disputes or other issues for resolution by the client provider.
The financing engine 1024 may provide functionality for configuring financing plans to pay account balances. The financing engine may use a PTP score, or other output of the scoring subsystem 144 of
The financing engine 1024 may enable provider-level, guarantor-level, and/or visit-level decisioning and/or underwriting such that any visit or set of visits for any patient and/or for any guarantor can be channeled customized financing terms. The decisioning may include decisioning rules that define criteria to group guarantors. The criteria, as mentioned, may be at a provider-level, a guarantor-level, and/or a visit-level (e.g., provider, guarantor income estimate, balance amount, insurance carrier, type of treatment, etc.).
The financing engine 1024 may enable a provider or asset holder to configure various pre-set financing options, each having terms for a group, segmentation, or other classification of guarantors, as determined by the decisioning rules. As stated, the decisioning can be at a provider level, a guarantor level, and/or a visit level. The financing engine 1024 may apply the decisioning rules to group a guarantor, and then may present one or more pre-set financing options corresponding to the group of the guarantor. Described differently, the financing engine 1024 may determine which pre-set financing option(s) to present to a guarantor based upon criteria of the guarantor at one or more of a provider level, a guarantor level, and/or a visit level.
The financing engine 1024 may allow a guarantor to create self-configured financing plans, for example, by choosing a monthly payment amount and subsequently accepting the associated terms the provider has authorized for the resulting amortization schedule (e.g., minimum payment amount, maximum amortization period, interest rates, etc.). Self-configured financing plans may be configured by the guarantor choosing any one or more of an interest rate, a payment amount, a period for repayment, and/or other terms that can be compared to provider-authorized terms and/or associated with provider-authorized terms that can be accepted by the guarantor. Again, the financing engine 1024 may enable a provider or asset holder to configure various guarantor-configurable financing options, each providing authorized terms for a group, segmentation, or other classification of guarantors, as determined by the decisioning rules. As stated, the decisioning can be at a provider level, a guarantor level, and/or a visit level. The financing engine 1024 may apply the decisioning rules to group a guarantor, and then may present one or more guarantor configurable financing options corresponding to the group of the guarantor. Described differently, the financing engine 1024 may determine which set of authorized financing terms apply for a guarantor configurable financing option presented to a guarantor. The determination of which set of authorized financing terms apply may be based upon criteria of the guarantor at one or more of a provider level, a guarantor level, and/or a visit level.
The financing engine 1024 may allow a guarantor to have multiple financing plans active simultaneously and can enable one monthly payment for all open financing plans. In other words, a new financing plan for a current open charges balance is stacked on previously established financing plans for prior open charges balances.
The balance brokering engine 1026 may enable brokering of charges and/or balances. A balance for a batch of open charges, or an open charges balance can be automatically evaluated based on one or more pre-defined evaluation criteria to determine whether the open charges balance should be transferred to a new system of record associated with a new entity. The balance brokering engine 1026 may evaluate the batch of open charges and/or open charges balance based on the pre-defined evaluation criteria. If the one or more pre-defined evaluation criteria are met, the balance brokering engine may automatically effectuate electronic transactions to transfer the open charges balance to an entity associated with the new system of record. More particularly, the balance brokering engine 1026 may automatically effectuate electronic transactions to transfer title of an accounts receivable asset that constitutes some or all rights to collect payment for the open charges balance.
The balance brokering engine 1026 may also integrate provider configuration settings with each guarantor's desired financing choice to determine which system of record should hold the new asset (e.g., an accounts receivable asset or financed balance asset). Once that determination is made, the balance brokering engine 1026 may calculate an appropriate pricing construct established between the provider and a potential new asset holder (e.g., a third-party entity or creditor, such as an owner or operator of the payment management system, a bank, or another special purpose lending or financial institution). The balance brokering engine 1026 may facilitate a financial transaction from the new entity (new asset holder) to the provider to clear the guarantor balance from the provider's system of record (e.g., billing system). The balance brokering engine 1026 may post the transferred asset (e.g., purchased asset) to an appropriate billing system of the new asset holder and subsequently integrate with the payment clearance and routing engine 1020 and statement engine 1016 to accurately clear payments and present accurate account balances for both the provider and the new asset holder.
The principal and interest calculation engine 1028 may calculate a schedule of interest accruals and principal payments due over an amortization schedule for a given financing construct. The principal and interest calculation engine 1028 may dynamically recalculate interest and principal allocations as payments and other debit and credit adjustments flow through the systems of record (e.g., provider billing systems, asset holder billing systems) over time.
The management engine 1030 may interface with the client input subsystem 162 and/or the guarantor input subsystem 164 of
When a registered guarantor logs in, the login of the guarantor may be authenticated 1104 to help ensure that PHI is being provided to an appropriate viewer (e.g., a guarantor or a manager guarantor).
Accounts of registered guarantors can be linked 1106 so that a single guarantor (a manager guarantor) can manage linked accounts, such as the account of a spouse, a parent, or the like. A statement or similar listing of charges on a guarantor's account and all other guarantor and patient accounts the guarantor manages can be presented 1108 to enable the guarantor to understand a balance (e.g., any balance) on the account and to enable the guarantor to arrange payment. A guarantor can arrange payment using either a singular payment to meet payment requirements on all subsidiary accounts (current visits and visits on financing plans) or direct specific payments to individual visits on a one-off basis through either one aggregated payment with allocation detail selected by the guarantor or multiple individual payments at the guarantor's discretion. A guarantor can also dispute a charge presented for payment. The dispute may be processed 1110, such as by temporarily removing the disputed charge from the account balance until resolution of the dispute. The dispute may be automatically entered in a dispute work queue for processing, for example, by the client provider. Payment options can be presented and a selection of an option can be received and processed 1112. The payment options may include, but are not limited to, payment in full, guarantor-configured financing terms, or pre-set financing terms.
Upon registering, a registered guarantor can provide communication preferences, which may be received and stored 1208. The communication preferences may include, but are not limited to, preferences specifying manner, format, timing, and the like, for providing information to the guarantor concerning the guarantor's account (including accounts linked to the guarantor's account for which the guarantor has assumed management). A registered guarantor may also provide payment preferences, which may be received and stored 1210. The payment preferences may include, but are not limited to, preferences specifying manner (e.g., payment vehicle), format, timing, and the like, for making payments on the guarantor's account. The payment preferences may enable contacting or otherwise interfacing with a payment gateway (e.g., third party) or a financial institution of a payment vehicle, which may generate an anonymous unique transaction identifier that can be used to facilitate payment transactions. The anonymous unique transaction identifier is received 1212 and stored for use during payment processing. The anonymous unique transaction identifier may link the guarantor's account to a previously specified financial services account for subsequent payment authorizations. The anonymous unique transaction identifier may facilitate recurring transactions (using the specified financial services account) without storing payment card industry (PCI) information, such as account numbers and credit card numbers. The anonymous unique transaction identifier may be, for example, a token that is generated by a third-party payment gateway and can be used to facilitate a payment through that payment gateway.
As can be appreciated, in other embodiments, a graphical user interface may provide input fields and functionality for a first guarantor to request managerial rights over an account of a second guarantor. For example, an individual may want to request to manage his/her spouse's account. The first guarantor can provide information for the second guarantor whose account the first guarantor wishes to manage. Again, the user interface may collect personally identifiable information of the guarantor to be managed (e.g., name, user ID, and/or last four digits of SSN) to aid in ensuring that guarantors send manage requests only to other personally known guarantors. An electronic notification of both the linking request and the linking acceptance may be sent to both guarantors to ensure they both are aware of and accept the obligations imposed and the permissions granted in the linked (i.e., managed) account arrangement. The electronic notifications may aid in complying with internal client provider policies and/or external regulations (e.g., HIPAA).
If the manage request is accepted, account information, including, for example, specific clinical visit information, for both the managed guarantor and the manager guarantor is provided 1510 in the account of the manager guarantor. In the case of a request to be managed, the account information for guarantor A is provided 1510 in the account for guarantor B. In the case of a request to manage, the account information for guarantor B is provided 1510 in the account for guarantor A. Linking accounts may include resetting 1512 a managed guarantor's payment data to match the manager guarantor's payment date. With the accounts successfully linked, the visit data, charge data, and balance data for the managed guarantor are combined into the account of the manager guarantor and otherwise consolidated 1514 for purposes of presentment of statements and/or financing plans. For example, the manager guarantor can view visit information of the managed guarantor's account. An electronic statement and/or account balance of the manager guarantor would reflect charges for visits of the managed guarantor. For example, even if the manager guarantor does not have current visits for the statement period, if the managed guarantor has a current visit during the statement period then an electronic statement would be generated for the manager guarantor reflecting the visit charges of only the managed guarantor.
At the severing of an account, the previously managed guarantor may have an outstanding balance owed (not paid in full by previous manager guarantor). As noted above, a managed guarantor may continue to be financially responsible for any unpaid visit charges, despite delegating management of account to another guarantor (manager guarantor). Accordingly, when accounts are severed, an originally responsible guarantor continues to be financially responsible for any guaranteed visit charges. Accordingly, a previously managed guarantor may be presented 1612 the outstanding balance effectively as a new obligation and may be presented payment options (including financing) to pay the new obligation (or outstanding balance). If the previously managed guarantor had (before linking of the accounts) configured a payment date preference that was different from the previous manager's configured payment date, the previously managed guarantor's payment date may be reset 1614 to the previously managed guarantor's established preference.
The electronic statement may serve primarily as an electronic record of required financing disclosures (e.g., interest assessments, payments received, etc.) to meet regulatory requirements. The electronic statement may be provided, for example, in a PDF format. The interactive overview may be an interactive “statement” of charges that dynamically changes with user interaction. When a guarantor first logs in after receiving an electronic notice that a statement is ready, the interactive overview data may match or closely match the electronic statement and reflect, for example, a presumption that the preset or standard payment configuration for new charges will likely be utilized by the guarantor. If the guarantor elects instead to reconfigure the financing plan or make a prompt payment on new charges, the interactive overview data can change (e.g., the current amount due and/or amount to be auto debited will rise or fall accordingly) as soon as that election is saved. If the interactive overview changes according to an action of a guarantor, the interactive overview may be out of sync with the statement. But the next monthly statement may capture the actions taken during this period and reflect balances, charges, interest assessments, discounts, fees, payments, and adjustment, accordingly.
Dispute functionality may also be provided 1806 to enable a guarantor to dispute particular visit charges appearing on the electronic statement. The dispute functionality may suspend 1808 the status of a disputed charge or otherwise temporarily remove the disputed charge from the account balance and/or the current statement until resolution of the dispute. In other words, the amount for a disputed charge may be subtracted from a current amount owed. Accordingly, the balance and/or current amount owed that are reflected on the electronic statement can be impacted by actions of the guarantor. A dispute about a visit charge may be automatically channeled to a work queue, such as a disputes work queue, for processing by the client provider. A dispute record may be generated and introduced to the disputes work queue. The disputes work queue may facilitate tracking and/or processing of disputes and ensuring that disputes are timely resolved by the client provider.
Although a specific visit can be disputed, other visits that comprise a given statement period's charges are not impacted and continue to appear on the electronic statement, the interactive overview, and/or the current balance. In other words, disputing a visit does not prevent a client provider from collecting on non-disputed visits that comprise the current visit charges (e.g., batch or bundle of business). A guarantor could create a financing plan on a batch of current visits, subsequently have additional charges be applied to a specific visit after it was originally billed, and the set of charges for that specific visit could be challenged. The disputed visit could be taken offline effectively without disrupting or impacting the rest of the visit charges within the financing plan.
Account matching functionality may also be provided 1810 to link an unmatched account with the client provider, as mentioned above with reference to the guarantor matching engine 1012 of
Payment options are also provided 1812 to the guarantor to make a payment on the balance shown on the electronic statement. As noted previously, the payment options may include:
-
- Pay in full for new visits to potentially earn a prompt-pay discount, based on choices and/or configured preferences of the client provider and possibly subject to what is allowed by the guarantor's insurance plan.
- Customize a new financing plan to pay a new balance comprising charges for visits from a current statement period, subject to policies and preferences of the client provider.
- Accept (e.g., by taking no action or affirmatively accepting) preset financing terms for a multi-month financing plan at a pre-established interest rate (e.g., a low or 0.0% interest rate) as configured by the client provider.
Providing 1812 payment options may include receiving input for making a payment in full. Providing 1812 payment options may include receiving input specifying customized terms for a new financing plan and comparing the customized terms to preferences, constraints, stipulations, policies, and the like of the client provider and/or external regulations. Selecting a payment option may alter the amount due for new charges during that statement period. For example, in the case where the electronic statement is generated assuming the preset financing option would be selected, customizing a financing plan or paying new charges in full while receiving a prompt-pay discount may alter the amount due. The interactive overview of the account (e.g., seeFIG. 9 ) may change on prospective items as a result of guarantor interaction and payment selections. The next periodic billing statement will reflect these new actions. In other words, the amount a guarantor is expected to pay on a received statement may change based on a payment option selection that departs from an assumed payment option (e.g., preset financing terms or payment in full) used to generate the electronic statement.
A payment on the account, for the electronic statement, may be processed 1814. At any point, the guarantor (or manager guarantor) for whom the electronic statement was generated may make a payment against a balance owed. The payment may match a current amount due on the statement. Alternatively, the payment may be different from a current amount due. When the payment is different from the current amount due, rules may specify an order of applying payment to the current amount due. The current amount due may comprise payments for previously accepted/configured financing plans as well as the current visit charges. The payment may be applied to the oldest financing plans first. Or another ordering may be specified, according to preferences and/or settings defined by the system, the client provider, and/or an asset holder. A posting file may be generated to inform the respective billing system(s) of which accounts or charges the payment should be applied.
Guarantor preferences may be checked to determine 1910 payment preferences for the guarantor. The payment preferences of the guarantor may include a payment method preference specifying a preferred mode of payment or payment vehicle (e.g., the guarantor's credit card, debit card, bank account, or Health Savings Account). A financial transaction authorization request is generated 1912. The transaction is processed 1914 between the guarantor financial institution and the client provider financial institution. The processing 1914 may be facilitated and/or performed by a payment gateway. Authorization for the transaction may be granted and thus received in response to the transaction authorization request. Alternatively, a confirmation of a completed or otherwise effectuated transaction may be received, for example, directly from the guarantor and/or the client provider financial institution(s). Once the transaction has been completed or otherwise effectuated, the billing system may be notified 1916 of the transaction. The notification may occur by generation of a transaction posting file that may be transmitted to the billing system. The transaction posting file may inform the respective billing system(s) as to which specific accounts or charges the payment should be applied.
Guarantor preferences may be checked to determine 2012 payment preferences for the guarantor. The payment preferences of the guarantor may include a payment method preference specifying a preferred mode of payment or payment vehicle (e.g., the guarantor's credit card, debit card, bank account, or Health Savings Account). A financial transaction authorization request is generated 2014. The transaction is processed 2016 between the guarantor financial institution and the client provider financial institution. The processing 2016 may be facilitated and/or performed by a payment gateway. Authorization for the transaction may be granted and thus received in response to the transaction authorization request. Alternatively, confirmation of the transaction may be received. Once the transaction has been completed or otherwise effectuated, the billing system may be notified 2018 of the transaction. The notification may occur by generation of a transaction posting file that may be transmitted to the billing system. The transaction posting file may inform the respective billing system(s) as to which specific accounts or charges the payment should be applied.
There may be a check 2104 for rules, stipulations, or constraints, specifying pre-set financing terms configured by the client provider and/or the present or eventual asset holder. The rules may define groupings or categories of guarantors based on criteria at any one or more of a provider level, a guarantor level, and/or a visit level, to specify different pre-set financing terms for each grouping or category. For example, decisioning rules may be defined at a provider level to specify a first set of pre-set financing terms for guarantors having charges incurred from (or amounts or balances owed to a first provider and to specify to a second set of pre-set financing terms for charges incurred from (or amounts or balances owed to) a second provider. As another example, decisioning rules may be defined at a guarantor level to specify a first set of pre-set financing terms for guarantors having a first set of attributes (e.g., a PTP score, a credit score, an estimated household income level, an estimated household size, and an ability to pay (ATP) score) and to specify a second set of pre-set financing terms for guarantors having a second set of attributes. As still another example, decisioning rules may be defined at a visit level to specify a first set of pre-set financing terms for a guarantor according to characteristics of visit charges (or corresponding visits) included in a current batch of open charges and/or open charges balance of the guarantor. The decisioning rules may specify a second set of pre-set financing terms for a guarantor for a guarantor having visit charges with different characteristics. The rules may be defined by a provider or other asset holder (e.g., holder of title of an accounts receivable asset that constitutes rights to collect payment for a balance, such as an open charges balance) to specify different financing plan parameters for different situations. The client provider or other asset holder may configure such rules and corresponding financing plan parameters and they may be stored in a client-configured database (e.g., within the datastore 121 of
The payment of the current period charges over the pre-set multiple number of periods at a pre-set interest rate may be calculated 2106, based on the pre-set financing terms. For example, the pre-set number of periods and/or preset interest rate may be based on client-configured preferences, for example, stored in a client-configured database (e.g., in the datastore 121 of
There may be a check 2106 for rules, stipulations, or constraints, specifying parameters for financing plans that are authorized by the client provider. The rules may define groupings or categories of guarantors based on criteria at any one or more of a provider level, a guarantor level, and/or a visit level, to specify different financing plan parameters for each grouping or category. For example, decisioning rules may be defined at a provider level to specify a first set of financing plan parameters guarantors having charges incurred from (or amounts or balances owed to) a first provider and to specify to a second set of financing plan parameters for charges incurred from (or amounts or balances owed to) a second provider. As another example, decisioning rules may be defined at a guarantor level to specify a first set of financing plan parameters for guarantors having a first set of attributes (e.g., a PTP score, a credit score, an estimated household income level, an estimated household size, and an ability to pay score) and to specify a second set of financing plan parameters for guarantors having a second set of attributes. As still another example, decisioning rules may be defined at a visit level to specify a first set of financing plan parameters for a guarantor according to characteristics of visit charges (or corresponding visits) included in a current batch of open charges and/or open charges balance of the guarantor. The rules may be defined by a provider or other present or eventual asset holder (e.g., holder of title of an accounts receivable asset that constitutes rights to collect payment for a balance, such as an open charges balance) to specify different financing plan parameters for different situations. The client provider or other asset holder may configure such rules and corresponding financing plan parameters, and they may be stored in a client-configured database (e.g., within the datastore 121 of
Guarantor preferences may be checked to determine 2110 payment preferences for the guarantor. The payment preferences of the guarantor may include a payment method preference specifying a preferred mode of payment or payment vehicle (e.g., the guarantor's credit card, debit card, bank account, or Health Savings Account). A financial transaction authorization request is generated 2112. The transaction is processed 2114 between the guarantor financial institution and the client provider financial institution. The processing 2114 may be facilitated and/or performed by a payment gateway. Authorization for the transaction may be granted and thus received in response to the transaction authorization request. Alternatively, confirmation of the transaction may be received. Once the transaction has been completed or otherwise effectuated, the billing system may be notified 2116 of the transaction. The notification may occur by generation of a transaction posting file that may be transmitted to the billing system. The transaction posting file may inform the respective billing system(s) as to which specific accounts or charges the payment should be applied.
The decisioning rules 2204 may be configured by an asset holder of an open charges balance that the guarantor is expected to pay. The asset holder may be a provider of the services, an operator of the payment management system, or a third party entity to which the open charges balance was transferred or will be transferred (e.g., by the balance brokering engine in
The provider-level criteria consider guarantor characteristics relating to a provider of services or otherwise associated with the visit charges of the open charges balance. In other words, the provider-level criteria consider provider characteristics, such that the authorized financing terms of the guarantor-configured financing option depend on a visit provider for the one or more visit charges. As an example, a provider-level criteria may specify that the decisioning rule payment options apply to the guarantor if the visit charges include charges from a particular provider. In this manner, guarantors owing payments to a first provider (e.g., St. Luke's) may be grouped into a category and receive a set of one or more corresponding pre-determined payment options while guarantors owing payments to a second provider (e.g., Intermountain Healthcare), may be grouped into a different category and receive a different set of one or more corresponding pre-determined payment options.
The guarantor-level criteria consider guarantor characteristics specific to the given guarantor. Examples of types of guarantor-level criteria include, but are not limited to: a PTP score, a credit score, an income estimate, a size of household estimate. an ability to pay score, a total amount presently owing to one or more providers, a location (e.g., residence) of the guarantor, physical characteristics of the guarantor (e.g., height, weight, blood pressure), and a type of insurance held by a guarantor. Accordingly, a first guarantor having a first PTP score may be presented different pre-determined payment options than a second guarantor having a second PTP score that is different from the first PTP score.
The visit-level criteria consider guarantor characteristics relating to visits and/or visit charges of the open charges balance. Examples of types of vi sit-level criteria include, but are not limited to: a visit charge amount, an open charges balance, an age of the open charges, a location of the visit, and a visit benefit (e.g., a treatment provided) to a beneficiary of the visit.
As noted, the pre-determined payment options may include one or more of authorized financing terms 2212 for guarantor-configurable financing options and pre-set financing terms 2214 for pre-set financing options. The authorized financing terms 2212 and pre-set financing terms 2214 may provide for a variety of financing types, including open-ended installment loan financing, revolving open-ended credit financing, and close-ended financing. For example, installment loan financing terms may include an amortization of the open charges balance into multiple regular periodic payments. As another example, revolving open-ended credit financing terms may simply specify a minimum payment amount due.
The authorized financing terms 2212 may provide allowable ranges into which guarantor-configured financing terms may fall. Guarantor-requested financing terms 2250 received from a guarantor may be compared to the authorized financing terms 2212 by the offer generator to generate a financing offer for an open charges balance. The guarantor-requested financing terms may include one or more of: a financing type (e.g., installment loan type, revolving credit type), a desired number of periods for payment over which recurring payments will be made to complete payment of the open charges balance, a desired interest rate, an interest rate type, including a fixed interest rate or a variable interest rate, a period payment amount; and a minimum payment amount. The authorized financing terms 2212 may indicate acceptable minimums, ranges, or otherwise authorized terms per the provider and/or asset holder. The authorized financings terms may include one or more of a financing type (e.g., installment loan type, revolving credit type), a minimum payment amount, a maximum amortization period, a minimum interest rate, an interest rate type (e.g., a fixed interest rate or a variable interest rate), interest rate tranches, an interest free period, a credit limit for open charges, interest bearing or non-interest bearing, a prompt payment discount, a charity (or hardship) discount, a pre-payment discount, and a self-pay discount.
The offer generator 2208 may compare guarantor characteristics to criteria of the decisioning rules 2204 to determine an appropriate set of one or more pre-determined payment options, including corresponding authorized financing terms and/or pre-set financing terms 2214. The offer generator 2208 may receive guarantor requested terms 2250, in the case of guarantor-configurable payment options and compare those terms to the authorized financing terms 2212. Based on the decisioning rules and any comparison to authorized financing terms 2214, the offer generator 2208 generates an appropriate financing offer for the guarantor to finance the open charges balance.
If the open charges balance is remaining with the provider, the auto-payment is established 2318 to transfer funds from the guarantor bank account to the provider bank account. The financing plan terms are recorded 2320 by the payment management system.
If the open charges balance is to be transferred, the auto-payment is established 2318 to transfer funds from the guarantor bank account to the new asset holder bank account. In the case of a transferred asset, an asset purchase payment is routed 2330 from the new asset holder to the provider (e.g., electronic transactions are effectuated). Also, a posting file is routed 2332 to the provider billing system to communicate satisfaction of the balance with respect to the provider system (and thus assumption of the balance by the new asset holder). The transferred asset is booked 2334 or otherwise recorded to the accounting system of the new asset holder (e.g., a system of record, a G/L, and/or the like).
After an asset (e.g., open charges balance) is transferred to the new asset holder 2412, charges for a subsequent period are aggregated to a new open charges balance and can be used as a basis for a new asset decisioning/brokering by the balance brokering engine 1026. As an example, January's visits of $200 may be eligible for a purchase by the new asset holder 2412 and may be transferred to a new system of record of the new asset holder 2412, according to pre-arranged asset purchase terms (e.g. 5% discount and non-recourse). February's visits of $1000 are also eligible for asset transfer, but the larger balance may warrant a steeper discount or move the asset to a full recourse model (e.g. 10% discount and full recourse back to the provider in the event of a guarantor default) held by yet another asset holder. In March, the guarantor 2414 may tally $100K in charges due to birth of premature baby. This balance may not qualify for asset transfer. Instead, the terms of the provider 2410 are offered and the payment management system 102 may simply remain a servicer of the account of the guarantor 2414. The guarantor's statement in April may show any new charges for that month, plus an amount due to the new asset holder 2412 for the January loan and an amount due to the second new asset holder for the February loan, and the amount due to the provider 2410 for the March loan plus the amount due for April charges. All of the amounts due for the several financings may be summed to one debit against the guarantor's bank account and the payment management system 102 may split the payment between the various entities (provider 2410 and new asset holder 2412) and allocate appropriate amounts to interest and principal.
EXAMPLE EMBODIMENTSSome examples of embodiments of adaptive natural language interfaces and other adaptive output systems are provided below.
Example 1A system for managing payments for services, comprising: one or more processors; a memory in electrical communication with the one or more processors to store first visit data tracked by a first billing system, the first visit data specifying one or more visit charges incurred during a time period, each of the one or more visit charges incurred for a visit; a visits engine to compile the one or more visit charges into a current batch of open charges and generate an open charges balance by aggregating all open charges of the current batch of open charges; a balance brokering engine to evaluate the open charges balance based on asset sales criteria for determining whether the open charges balance should be transferred from the first billing system to a new system of record and effectuate electronic transactions to transfer title of an accounts receivable asset that constitutes rights to collect payment for the open charges balance, including payment for the current batch of open charges, to the new system of record, if the asset sales criteria are met; and wherein the system tracks the open charges balance, including payments to pay the one or more visit charges and other transactions relating to the open charges balance, wherein the system tracks the open charges balance separate from the first billing system and tracks transactions tracked in the first billing system that pertain to the one or more visit charges.
Example 2The system of Example 1, further comprising an extraction engine to extract the first visit data from the first billing system and to generate a single longitudinal portrayal including the first visit data and the second visit data.
Example 3The system of Example 1, further comprising a payment clearance and routing engine to interface with a payment gateway to effectuate electronic transactions to transfer the title of the accounts receivable asset.
Example 4The system of Example 1, wherein the balance brokering engine is configured to effectuate the transactions to transfer title of the accounts receivable asset to the new system of record by: debiting the open charges balance from a financial institution account associated with the new system of record; crediting the open charges balance to a financial institution account associated with the first billing system.
Example 5The system of Example 1, wherein the asset sales criteria are defined by a provider associated with the first billing system.
Example 6The system of Example 1, wherein the asset sales criteria are defined by a potential new asset holder associated with the new system of record to which the open charges balance is transferred if the asset sales criteria are met.
Example 7The system of Example 1, wherein the system is the new system of record.
Example 8The system of Example 1, wherein the new system of record is a third-party system, remote from the payment management system and coupled to the system management system over a communication network.
Example 9A computer-implemented method for managing payments for a benefit, such as a product or service, the method comprising: receiving, at a payment management system comprising one or more computing devices, visit data being tracked by a first billing system and specifying one or more visit charges, each of the one or more visit charges including one or more charges incurred for a visit during a time period; compiling the one or more visit charges for the time period into a current batch of open charges; generating an open charges balance by aggregating all open charges of the current batch of open charges; evaluating the open charges balance, by the payment management system, based on one or more pre-defined asset sales criteria to determine whether the open charges balance should be transferred to a new system of record; if the one or more asset sales criteria are met, automatically effectuating by the payment management system electronic transactions to transfer title of an accounts receivable asset that constitutes all rights to collect payment for the open charges balance, including payment for the current batch of open charges, to an entity associated with the new system of record; and tracking, at the payment management system, transactions relating to the open charges balance, including payments to pay the current batch of open charges, the tracking being separate from the first billing system.
Example 10The method of Example 9, wherein effectuating transactions to transfer title of the accounts receivable asset to the new system of record comprises communicating a transaction request to a payment gateway to request the payment gateway: debiting the open charges balance from a financial institution account associated with the new system of record; crediting the open charges balance to a financial institution account associated with the first billing system.
Example 11The method of Example 9, further comprising: compiling into the current batch of open charges one or more additional transactions that relate to the one or more visit charges, the one or more additional transactions including additional transactions that adjust at least one of the one or more visit charges in the current batch of open charges adjust a gross batch balance that is a sum of the one or more visit charges, wherein generating the open charges balance comprises aggregating all open charges of the current batch of open charges, including the one or more additional transactions.
Example 12The method of Example 11, wherein the additional transactions include one or more of: an interest charge based on an amount owing for one or more past open charges balances; a system of record fee; a payment from an insurance provider to be deducted in aggregating all the open charges of the current batch of open charges; a provider adjustment to a visit charge; and a removal of a disputed visit charge.
Example 13The method of Example 11, wherein effectuating transactions to transfer title of the accounts receivable asset to the new system of record comprises communicating a transaction request to a payment gateway to request the payment gateway: debiting each of the current open charges from a financial institution account associated with the new system of record; crediting each of the one or more open charges to a financial institution account associated with the first billing system with.
Example 14The method of Example 9, wherein the one or more asset sales criteria include system criteria that are pre-defined by a payment management system administrator.
Example 15The method of Example 14, wherein the system criteria include a propensity to pay score.
Example 16The method of Example 9, wherein the one or more asset sales criteria include provider criteria that are pre-defined by a provider of a visit of the one or more visit charges.
Example 17The method of Example 16, further comprising receiving, at the payment management system the one or more provider criteria.
Example 18The method of Example 9, wherein the asset sales criteria are defined by a potential new asset holder associated with the new system of record to which the open charges balance is transferred if the asset sales criteria are met.
Example 19The method of Example 9, further comprising: receiving, at the payment management system, data specifying a payment vehicle for paying a payment amount; communicating a transaction request to a payment gateway to request the payment gateway debit payment funds in the payment amount from a payor financial institution associated with the payment vehicle and credit at least a portion of the payment funds to a payee financial institution associated with the new system of record, in payment toward the batch balance; and communicating an electronic posting file to notify the new system of record of transfer of at least at portion of the payment funds in payment toward the open charges balance.
Example 20The method of Example 19, further comprising: receiving at the one or more computing devices payment option input specifying provider pre-determined payment options; receiving at the one or more computing devices a selection of one of the provider pre-determined payment options; and determining the payment amount based on the selected one of the provider pre-determined payment options.
Example 21The method of Example 9, further comprising: receiving, at the payment management system, second visit data being tracked in a second billing system and specifying one or more second visit charges, each of the one or more second visit charges including one or more charges incurred for a visit during the time period; and compiling the one or more second visit charges for the time period into the current batch of open charges, wherein generating the open charges balance comprises aggregating all open charges of the current batch of open charges, including the one or more second visit charges, thereby aggregating visit charges for the time period that are tracked in multiple billing systems.
Example 22The method of Example 21, wherein the second visit data is received from the second billing system, wherein the second billing system is remote from the one or more computing devices.
Example 23The method of Example 21, wherein the one or more visit charges includes a visit charge for a first visit of a beneficiary, wherein the one or more second visit charges includes a visit charge for a second visit of a second beneficiary.
Example 24The method of Example 9, wherein the time period comprises an initial time period and the current batch of open charges comprises a first batch of open charges, the method further comprising: receiving, at the payment management system, second visit data being tracked in the first billing system and specifying one or more second visit charges, each of the one or more second visit charges including one or more charges incurred for a visit during a second time period distinct from to the initial time period; compiling the one or more second visit charges for the second time period into a second batch of open charges; generating a second open charges balance by aggregating all open charges of the second batch of open charges; wherein the second open charges balance is maintained separate from the first open charges balance; evaluating the second open charges balance, by the payment management system, based on the asset sales to determine whether the second open balance should be transferred to a new system of record; if the asset sales criteria are not met, maintaining title of an accounts receivable asset that constitutes all rights to collect payment for the second open charges balance, including payment for the second batch of open charges, at the first billing system, wherein the first billing system remains as a system of record; and tracking, at the payment management system, transactions relating to the second open charges balance, including payments to pay the second batch of open charges, the tracking being separate from the first billing system, the tracking including transactions tracked in the first billing system that pertain to the one or more second visit charges.
Example 25The method of Example 24, wherein a visit charge of the first visit data specifies a charge for a first visit of a beneficiary, wherein a visit charge of the second visit data specifies a charge for a second visit of a second beneficiary.
Example 26The method of Example 24, wherein the first visit is a first healthcare visit, the second visit is a second healthcare visit, and the beneficiary is a patient.
Example 27The method of Example 24, wherein the first visit is a first healthcare visit of a first beneficiary and the second visit is a second healthcare visit of a second beneficiary.
Example 28The method of Example 9, wherein the new system of record is the payment management system.
Example 29The method of Example 9, wherein the new system of record is a third-party system, remote from the payment management system and coupled to the payment management system over a communication network.
Example 30A system for managing payments, comprising: one or more processors; a memory in electrical communication with the one or more processors to store first visit data tracked by a first billing system, the first visit data specifying one or more visit charges incurred during a time period, each of the one or more visit charges incurred for a visit; a visits engine to compile the one or more visit charges into a current batch of open charges and generate an open charges balance by aggregating all open charges of the current batch of open charges; a financing engine to: present, to a guarantor of the one or more visit charges, pre-determined payment options for paying the open charges balance, each of the pre-determined payment options including terms at least partially defined by one of a present asset holder and a potential asset holder of the open charges balance; receive, at the payment management system, a guarantor selection of one of the pre-determined payment options for paying the open charges balance; and determine a payment amount based on the selected one of the pre-determined payment options.
Example 31The system of Example 30, wherein the present asset holder is a provider of one or more visits of the current batch of visit charges.
Example 32The system of Example 30, further comprising: a payment portal to receive payment data specifying a payment vehicle for paying a payment amount; and a payment and clearance routing engine to: transmit a transaction request to a payment gateway to request the payment gateway to obtain funds in the payment amount from a payor financial institution associated with the payment vehicle, to transfer a first portion of the payment funds to a payee financial institution associated with the first patient billing system, and to transfer a second portion of the payment funds to a payee financial institution associated with the second patient billing system; and communicate one or more electronic posting files to notify the first patient billing system of transfer of the first portion of the payment funds toward payment of the charge for the first visit and to notify the second patient billing system of transfer of the second portion of the payment funds toward payment of the charge for the second visit.
Example 33The system of Example 30, wherein the system tracks the open charges balance, including payments to pay the one or more visit charges and other transactions relating to the open charges balance, wherein the system tracks the open charges balance separate from the first billing system and tracks transactions tracked in the first billing system that pertain to the one or more visit charges.
Example 34The system of Example 30, wherein the pre-determined payment options include a complete resolution option to make a single payment in satisfaction of the open charges balance, wherein if the guarantor selection of one of the provider pre-determined payment options selects the complete resolution option, then the financing engine determines the payment amount by: checking for a pre-determined payment discount specified as a term of the complete resolution option; and determining the payment amount as the open charges balance net of the prompt payment discount.
Example 35The system of Example 30, wherein the pre-determined payment options include a guarantor-configured financing option allowing the guarantor to request one or more financing terms, the guarantor-configured financing option including authorized financing terms at least partially defined by the one of the present asset holder and the potential asset holder of the open charges balance, wherein if the guarantor selection of one of the provider pre-determined payment options selects the guarantor-configured financing option, then the financing engine determines the payment amount by: receiving a guarantor request for one or more financing terms for financing the open charges balance; comparing a guarantor requested financing term to the authorized financing terms; generating an financing offer, based on the guarantor requested terms and the authorized financing terms; and determining the payment amount based on terms of the authorized offer of financing.
Example 36The system of Example 35, wherein the financing engine determines the guarantor-configured financing option that is presented to the guarantor based on decisioning rules configured by the one of the present asset holder and the potential asset holder of the open charges balance, each decisioning rule specifying authorized financing terms for a group of one or more guarantors that satisfy criteria of the decisioning rule.
Example 37The system of Example 30, wherein the provider pre-determined payment options include a pre-set financing option including pre-set financing terms at least partially defined by the one of the present asset holder and the potential asset holder of the open charges, wherein, if the selection of one of the provider pre-determined payment options selects the pre-set financing option, then the financing engine determines the payment amount by one of: determining a minimum payment amount in compliance with the terms of the pre-set financing option, if the pre-set financing option comprises open-ended credit financing; and amortizing the open charges balance into regular periodic payments, based on the pre-set financing terms, and determining the payment amount as a first regular periodic payment of the regular periodic payments, if the pre-set financing option comprises installment loan financing.
Example 38The system of Example 37, wherein the pre-set financing terms of the pre-set financing option that is presented to the guarantor are determined based on decisioning rules configured by the one of the present asset holder and the potential asset holder of the open charges balance, each decisioning rule specifying the terms of the pre-set financing option for a group of one or more guarantors that satisfy criteria of the decisioning rule.
Example 39The system of any of Examples 30-38, wherein the financing engine is configured to determine the payment amount by summing a current payment amount with payments due for financing one or more prior open charges balances, the current payment amount being the payment amount determined based on the selected one of the pre-determined payment options for the open charges balance of the current batch of open charges, the payments due for financing one or more prior open charges balances each determined based on a previously selected pre-determined payment option for a corresponding prior open charges balance.
Example 40A computer-implemented method for managing payments, the method comprising: receiving, at a payment management system comprising one or more computing devices, first visit data that is tracked by a first billing system and specifying one or more visit charges incurred during a time period, each of the one or more visit charges including one or more charges incurred for a visit; compiling the one or more visit charges for the time period into a current batch of open charges; generating an open charges balance by aggregating all open charges of the current batch of open charges; presenting, to a guarantor of the one or more visit charges, pre-determined payment options for paying the open charges balance, each of the pre-determined payment options including terms at least partially defined by one of a present asset holder and an eventual asset holder of the open charges balance; receiving, at the payment management system, a guarantor selection of one of the pre-determined payment options for paying the open charges balance; and determining a payment amount based on the selected one of the pre-determined payment options.
Example 41The method of Example 40, wherein at least one of the one or more visit charges comprises an estimate of costs for the visit in advance of occurrence of the visit.
Example 42The method of Example 40, further comprising: receiving, at the payment management system, data specifying a payment vehicle for paying the payment amount; communicating a transaction request to a payment gateway to request the payment gateway to debit payment funds from a payor financial institution associated with the payment vehicle and to credit at least a portion of the payment funds to a payee financial institution associated with the first billing system in payment toward the open charges balance; and communicating an electronic posting file to notify the first billing system of transfer of at least a portion of the payment funds in payment toward specific visit charges of the current batch of open charges.
Example 43The method of Example 40, wherein the transaction request is also to request the payment gateway to credit at least a portion of the payment funds to the payee financial institution associated with the first billing system in payment toward one or more prior open charges balances.
Example 44The method of Example 40, wherein the transaction request is also to request the payment gateway to credit at least a portion of the payment funds to the payee financial institution associated with the first billing system in payment toward only a past open charges balance.
Example 45The method of Example 40, wherein the pre-determined payment options are at least partially configured by one or more of a present asset holder and an eventual asset holder of the open charges balance.
Example 46The method of Example 45, wherein the present asset holder is a provider of one or more visits of the current batch of visit charges.
Example 47The method of Example 40, wherein the pre-determined payment options include a complete resolution option to make a single payment in satisfaction of the open charges balance, wherein if the selection of one of the provider pre-determined payment options selects the complete resolution option, then determining the payment amount comprises: checking for a pre-determined payment discount specified as a term of the complete resolution option, wherein presenting the pre-determined payment options includes presenting such pre-determined prompt payment discount; and determining the payment amount as the open charges balance net of the prompt payment discount.
Example 48The method of Example 47, wherein the payment discount varies according to a segmentation or grouping at one or more of a provider level, a guarantor level, and a visit level.
Example 49The method of Example 47, wherein the payment discount comprises a prompt payment discount.
Example 50The method of Example 40, wherein the pre-determined payment options include a guarantor-configured financing option allowing the guarantor to request one or more financing terms, the guarantor-configured financing option including authorized financing terms at least partially defined by one of a present asset holder and an eventual asset holder of the open charges balance, wherein if the guarantor selection of one of the pre-determined payment options selects the guarantor-configured financing option, then determining the payment amount comprises: receiving a guarantor request providing one or more guarantor requested financing terms for financing the open charges balance; comparing the one or more guarantor requested financing terms to the authorized financing terms; generating an authorized offer of financing, based on the guarantor requested terms and the authorized financing terms; and determining the payment amount based on terms of the authorized offer of financing.
Example 51The method of Example 50, wherein the authorized offer provides installment loan financing terms, including an amortization of the open charges balance into multiple regular periodic payments, and wherein the payment amount is determined to be a first regular periodic payment provided by the amortization of the open charges balance.
Example 52The method of Example 50, wherein the authorized offer provides open-ended credit financing terms specifying a minimum payment amount due, based on a percentage of the open charges balance, and wherein the payment amount is determined to be the minimum payment amount.
Example 53The method of Example 50, wherein the guarantor-requested financing terms include one or more of: a financing type, including an installment loan type or a revolving credit type; a desired number of periods for payment over which recurring payments will be made to complete payment of the open charges balance; a desired interest rate; an interest rate type, including a fixed interest rate or a variable interest rate; a period payment amount; and a minimum payment amount.
Example 54The method of Example 50, wherein the authorized financings terms comprise one or more of: a financing type, including an installment loan type or a revolving credit type; a minimum payment amount; a maximum amortization period; a minimum interest rate; an interest rate type, including a fixed interest rate or a variable interest rate; interest rate tranches; an interest free period; a credit limit for open charges; interest bearing or non-interest bearing; a prompt payment discount; a charity (or hardship) discount; a pre-payment discount; and a self-pay discount.
Example 55The method of Example 50, wherein the guarantor-configured financing option, including the authorized financing terms, that is presented to the guarantor is determined based on decisioning rules configured by the one of the present asset holder and the eventual asset holder of the open charges balance, each decisioning rule specifying authorized financing terms for a group of one or more guarantors that satisfy criteria of the decisioning rule.
Example 56The method of Example 55, wherein the criteria of each decisioning rule group the guarantor at one or more of a provider level, a guarantor level, and a visit level.
Example 57The method of Example 55, wherein provider-level criteria of a decisioning rule group the guarantor according to one or more provider characteristics, such that the authorized financing terms of the guarantor-configured financing option depend on a visit provider for the one or more visit charges.
Example 58The method of Example 55, wherein provider-level criteria of a decisioning rule group the guarantor according to one or more provider characteristics, such that a first set of authorized financing terms is presented to a guarantor for visit charges incurred from visits to a first provider and a second set of authorized financing terms is presented for visit charges incurred from visits to a second provider.
Example 59The method of Example 55, wherein guarantor-level criteria of a decisioning rule group the guarantor according to one or more characteristics of the guarantor, including but not limited to: a propensity to pay score; a credit score; an income estimate; a size of household estimate; an ability to pay score; a total amount presently owing to one or more providers; a location (e.g., residence) of the guarantor; a physical characteristics of the guarantor (e.g., height, weight, blood pressure); and a type of insurance held by a guarantor.
Example 60The method of Example 55, wherein visit-level criteria of a decisioning rule group the guarantor according to one or more characteristics of the one or more visits, including but not limited to: a visit charge amount; an open charges balance; an age of the open charges; a location of the visit; and a visit benefit to a beneficiary of the visit.
Example 61The method of Example 40, wherein the pre-determined payment options include a pre-set financing option including pre-set financing terms at least partially defined by one of a present asset holder and an eventual asset holder of the open charges, wherein, if the guarantor selection of one of the pre-determined payment options selects the pre-set financing option, then determining the payment amount comprises one of: determining a minimum payment amount in compliance with the terms of the pre-set financing option, if the pre-set financing option comprises open-ended credit financing; and amortizing the open charges balance into regular periodic payments, based on the pre-set financing terms, and determining the payment amount as a first regular periodic payment of the regular periodic payments, if the pre-set financing option comprises installment loan financing.
Example 62The method of Example 61, wherein the pre-set financing terms of the pre-set financing option include one or more of: a financing type, including an installment loan type or a revolving credit type; a number of periods for payment over which recurring payments will be made to complete payment of the open charges balance; an interest rate; an interest rate type, including a fixed interest rate or a variable interest rate; a period payment amount; a minimum payment amount; interest rate tranches; an interest free period; a credit limit for open charges; interest bearing or non-interest bearing; a prompt payment discount; a charity (or hardship) discount; a pre-payment discount; and a self-pay discount.
Example 63The method of Example 61, wherein the pre-set financing terms of the pre-set financing option that is presented to the guarantor are determined based on decisioning rules configured by the one of the present asset holder and eventual asset holder of the open charges balance, each decisioning rule specifying the terms of the pre-set financing option for a group of one or more guarantors that satisfy criteria of the decisioning rule.
Example 64The method of Example 63, wherein the criteria of each decisioning rule group the guarantor at one or more of a provider level, a guarantor level, and a visit level.
Example 65The method of Example 63, wherein provider-level criteria of a decisioning rule group the guarantor according to one or more provider characteristics, such that the terms of the pre-set financing option depend on a visit provider for the one or more visit charges.
Example 66The method of Example 63, wherein provider-level criteria of a decisioning rule group the guarantor according to one or more provider characteristics, such that the pre-set financing option includes a first set of terms for visit charges incurred from visits to a first provider and includes an alternate second set of terms is presented for visit charges incurred from visits to a second provider.
Example 67The method of Example 63, wherein the guarantor-level criteria of a decisioning rule group the guarantor according to one or more characteristics of the guarantor, including but not limited to: a propensity to pay score; a credit score; an income estimate; a size of household estimate; an ability to pay score; a total amount presently owing to one or more providers; a location (e.g., residence) of the guarantor; a physical characteristics of the guarantor (e.g., height, weight, blood pressure); and a type of insurance held by a guarantor.
Example 68The method of Example 63, wherein visit-level criteria of a decisioning rule group the guarantor according to one or more characteristics of the one or more visits, including but not limited to: a visit charge amount; an open charges balance; an age of the open charges; a location of the visit; and a visit benefit to a beneficiary of the visit.
Example 69The method of any of Example 40-68, wherein determining the payment amount further comprises summing a current payment amount with payments due for financing one or more prior open charges balances, the current payment amount being the payment amount determined based on the selected one of the pre-determined payment options for the open charges balance of the current batch of open charges, the payments due for financing one or more prior open charges balances each determined based on a previously selected pre-determined payment option for a corresponding prior open charges balance of a prior batch of open charges.
Example 70The method of Example 69, wherein each of the payments due for financing one or more prior open charges balances is determined according to a next regular periodic payment for an amortization of a prior open charges balance for a previous time period:
Example 71The method of Example 40, further comprising: receiving, at the payment management system from a computing device of the one of the present asset holder and the eventual asset holder of the open charges balance, payment option input to at least partially define the terms of the pre-determined payment options.
Example 72A computer-implemented method for managing payments, the method comprising: receiving, at a payment management system comprising one or more computing devices, charge data specifying one or more charges; compiling the one or more charges into a current batch of open charges; generating an open charges balance by aggregating all open charges of the current batch of open charges; presenting to a guarantor of the one or more charges pre-determined payment options for paying the open charges balance, each of the pre-determined payment options including terms at least partially defined by one of a present asset holder and a potential asset holder of the open charges balance; receiving, at the payment management system, a guarantor selection of one of the pre-determined payment options for paying the open charges balance; and determining a payment amount based on the selected one of the provider pre-determined payment options.
Example 73The method of Example 72, wherein at least one of the one or more charges comprises an estimate of a charge for a benefit to occur.
Example 74The method of Example 73, wherein the benefit is to occur during a future time period.
Example 75The method of Example 72, wherein the pre-determined payment options include a guarantor-configured financing option allowing the guarantor to request one or more financing terms, the guarantor-configured financing option including authorized financing terms at least partially defined by one of a present asset holder and a potential asset holder of the open charges balance, wherein if the selection of one of the pre-determined payment options selects the guarantor-configured financing option, then determining the payment amount comprises: receiving a guarantor request for one or more financing terms for financing the open charges balance; comparing a guarantor requested financing term to the authorized financing terms; generating an authorized offer of financing, based on the guarantor requested terms and the authorized financing terms; and determining the payment amount based on terms of the authorized offer of financing.
Example 76The method of Example 75, wherein the guarantor-configured financing option that is presented to the guarantor is determined based on decisioning rules configured by the one of the present asset holder and the potential asset holder of the open charges balance, each decisioning rule specifying authorized financing terms for a group of one or more guarantors that satisfy criteria of the decisioning rule.
Example 77The method of Example 72, wherein the pre-determined payment options include a pre-set financing option including pre-set financing terms at least partially defined by one of a present asset holder and an eventual asset holder of the open charges, wherein, if the guarantor selection of one of the pre-determined payment options selects the pre-set financing option, then determining the payment amount comprises one of: determining a minimum payment amount in compliance with the terms of the pre-set financing option, if the pre-set financing option comprises open-ended credit financing; and amortizing the open charges balance into regular periodic payments, based on the pre-set financing terms, and determining the payment amount as a first regular periodic payment of the regular periodic payments, if the pre-set financing option comprises installment loan financing.
Example 78The method of Example 77, wherein the pre-set financing terms of the pre-set financing option that is presented to the guarantor are determined based on decisioning rules configured by the one of the present asset holder and the potential asset holder of the open charges balance, each decisioning rule specifying the terms of the pre-set financing option for a group of one or more guarantors that satisfy criteria of the decisioning rule.
Example 79A system for managing payments for healthcare services, comprising: one or more processors; a memory in electrical communication with the one or more processors, the memory to store historical healthcare data including healthcare transaction data tracked by a first billing system, the historical healthcare data pertaining to one or more guarantors; a scoring engine configured to extract propensity-to-pay (“PTP”) characteristics from the historical healthcare data, including PTP characteristics of the one or more guarantors, and calculate a PTP metric for a guarantor based on PTP characteristics of the guarantor extracted from the historical healthcare data, wherein the PTP metric indicates a likelihood that the guarantor will pay for visit charges for healthcare visits.
Example 80The system of Example 79, wherein the PTP metric comprises a PTP score.
Example 81The system of Example 80, wherein the scoring engine comprises a plurality of calculation engines, each configured to calculate a respective type of PTP score for a guarantor.
Example 82The system of Example 81, wherein the plurality of calculation engines differ with respect to one or more of a weighting and a combination of algorithms used to calculate a PTP score.
Example 83The system of Example 79, wherein the PTP metric is a group identifier that groups a guarantor into a group having an associated propensity-to-pay a visit charge for a healthcare visit.
Example 84The system of Example 79, further comprising: a staging module to determine a current stage of an account record of the guarantor, based on the historical healthcare data, wherein the scoring engine calculates the PTP metric for the guarantor based on the stage of the account record of the guarantor.
Example 85The system of Example 86, wherein the staging module comprises a trigger engine configured to implement one or more triggered actions in response to one or more of: assigning a stage to an account record; updating data pertaining to an account record; and a request for updated stage assignment information.
Example 86The system of Example 79, the memory to further store first visit data that is tracked by a first billing system and specifying one or more visit charges incurred during a time period, each of the one or more visit charges incurred for a visit, the system further comprising: a visits engine to aggregate, collect, or compile the one or more visit charges into a current batch of open charges and generate an open charges balance by aggregating all open charges of the current batch of open charges, wherein the scoring engine calculates the PTP metric for the guarantor with respect to the open charges balance, such that the PTP metric indicates a likelihood that the guarantor will pay for the open charges balance.
Example 87The system of Example 86, further comprising: a financing engine to: present, to a guarantor of the one or more visit charges, pre-determined payment options for paying the open charges balance, each of the pre-determined payment options including terms at least partially defined by an asset holder of the open charges balance; receive, at the payment management system, a guarantor selection of one of the pre-determined payment options for paying the open charges balance; and determine a payment amount based on the guarantor selected one of the pre-determined payment options.
Example 88The system of Example 87, wherein each of the pre-determined payment options include one or more terms defined by one of a present asset holder and an eventual asset holder of the open charges balance, wherein the one or more terms depend on the PTP score of the guarantor.
Example 89The system of Example 79, wherein the historical healthcare data includes healthcare transaction data tracked by a second billing system.
Example 90The system of Example 79, the memory further to store credit reporting data from one or more third party credit reporting sources, wherein the scoring engine calculates the PTP metric for the guarantor based on both the PTP characteristics and the credit reporting data.
Example 91The system Example 90, wherein the scoring engine is configured to extract an ability-to-pay (ATP) metric from the credit reporting data, and wherein the scoring engine calculates the PTP metric based on the PTP characteristics and the ATP metric.
Example 92The system of Example 91, further comprising: a charity evaluation module configured to calculate a charity score for a guarantor based on the PTP metric and the ATP metric.
Example 93A computer-implemented method for managing payments for healthcare services, the method comprising: aggregating, compiling or collecting, at a payment management system comprising one or more computing devices, historical healthcare data including healthcare transaction data tracked by a first billing system, the historical healthcare data pertaining to healthcare visits of patients, whose visit charges are guaranteed by one or more guarantors; extracting propensity-to-pay (“PTP”) characteristics from the historical healthcare data, including PTP characteristics of the one or more guarantors; calculating a PTP metric for a first guarantor of the one or more guarantors based on PTP characteristics of the first guarantor extracted from the historical healthcare data, the PTP metric indicating a likelihood that the first guarantor will pay for visit charges for healthcare visits.
Example 94The method of Example 93, wherein the healthcare transaction data includes billing transaction records, payment transaction records, and/or financing plan records associated with an account record of one or more of the first guarantor and a first patient associated with the first guarantor, the account record maintained by the payment management system.
Example 95The method of Example 93, wherein the healthcare transaction data includes billing transaction records, payment transaction records, and/or financing plan records associated with visit charges of a patient associated with the first guarantor.
Example 96The method of Example 95, wherein the patient is the first guarantor.
Example 97The method of Example 93, wherein the healthcare transaction data includes healthcare transaction action data for a second guarantor whose account record is linked to the account record of the first guarantor.
Example 98The method of Example 97, further comprising calculating a PTP metric for the second guarantor based on PTP characteristics of the second guarantor extracted from the historical healthcare data, the PTP metric indicating a likelihood that the second guarantor will pay for visit charges.
Example 99The method of Example 93, wherein the PTP metric is calculated based on PTP characteristics of the first guarantor that are inferred from PTP characteristics of one or more different guarantors of the one or more guarantors that are calculated as being similar to the first guarantor.
Example 100The method of Example 93, wherein the historical healthcare data includes healthcare condition data, including information pertaining to a healthcare condition of a patient associated with the guarantor.
Example 101The method of Example 100, wherein the healthcare condition data includes one or more of diagnoses, disease conditions, chronic health condition(s), degenerative conditions.
Example 102The method of Example 101, wherein the healthcare condition data is derived at least partially from billing transaction information included in the healthcare transaction data tracked by the first billing system, the billing transaction information including one or more of treatment codes and diagnostic codes.
Example 103The method of Example 101, wherein the healthcare condition data is derived at least partially from healthcare records of the patient maintained by a healthcare service provider associated with the first billing system and providing healthcare services to the patient.
Example 104The method of Example 93, wherein the historical healthcare data includes healthcare transaction data tracked by a second billing system.
Example 105The method of Example 93, wherein the historical healthcare data includes healthcare transaction data tracked by a plurality of billing systems in addition to the first billing system.
Example 106The method of c Example 93, further comprising: receiving credit reporting data from one or more third-party credit reporting sources; calculating the PTP metric for the guarantor based on both the PTP characteristics and the credit reporting data.
Example 107The method of Example 106, wherein the credit reporting data is reported to the one or more third-party credit reporting sources by third-party credit grantors, the credit reporting data including one or more of: types of credit extended to the guarantor; a length of time the guarantor's credit accounts have been open; timeliness of guarantor payments to lenders; amount of credit extended to the guarantor; whether new sources of credit are being actively sought by the guarantor; one or more credit scores of the guarantor, each credit score summarizing credit risk of the guarantor; a net worth estimate; an income estimate; and a size of household estimate.
Example 108The method of Example 107, wherein the one or more credit scores include one or more of a general credit score.
Example 109The method of claim Example 108, wherein the general credit score is a FICO score.
Example 110The method of Example 108, wherein the one or more credit scores include one or more industry-specific credit scores, including but not limited to credit scores of: the telecommunications industry; the healthcare industry; and the retail industry.
Example 111The method of Example 93, wherein the PTP characteristics include one or more of: an average time to payment for healthcare transactions; late payments; payment amounts; insurance coverage; copayments; flexible spending account activity (e.g., estimated remaining balance); healthcare spending account activity; financing plan history (e.g., whether the patient and/or guarantor(s) have used a financing plan to pay for services and/or whether the payments were made in a timely manner); a total amount presently owed to a provider; prior bad debt charge-offs; prior hardship program assistance (charity); time periods between transactions; and dispute history.
Example 112The method of Example 93, further comprising: receiving, at a payment management system, first visit data that is tracked by a first billing system and that specifies one or more visit charges each incurred for a visit to a healthcare provider, wherein the PTP score for the guarantor is calculated for a visit charge of the one or more visit charges that is guaranteed by the guarantor.
Example 113The method of Example 93, further comprising: receiving, at a payment management system, an estimate of one or more visit charges for a visit to a healthcare provider, wherein the PTP score for the guarantor is calculated for the estimate of one or more visit charges.
Example 114The method of Example 93, further comprising: receiving, at a payment management system, first visit data that is tracked by a first billing system and that specifies one or more visit charges incurred during a time period for a visit to a healthcare provider, each of the one or more visit charges guaranteed by the guarantor; compiling the one or more visit charges for the time period into a current batch of open charges; and generating an open charges balance by aggregating all open charges of the current batch of open charges, wherein the PTP metric for the guarantor is calculated for the open charges balance.
Example 115The method of Example 114, wherein the PTP metric comprises a PTP score.
Example 116The method of Example 115, wherein the PTP score for the guarantor is calculated for the open charges balance based on integrating PTP scores for each of the one or more visit charges of the batch of open charges.
Example 117The method of Example 115, further comprising: generating a guarantor group identifier based on the PTP score; and providing the guarantor group identifier to the first billing system.
Example 118The method of Example 93, wherein the PTP metric comprises a guarantor group identifier.
Example 119The method of Example 93, further comprising: receiving demographic data pertaining to the guarantor from one or more third-party demographics data sources and consumer data sources; calculating the PTP metric for the guarantor based on both the PTP characteristics and the demographics data.
Example 120The method of Example 93, further comprising determining a current stage of the guarantor's account, wherein the PTP metric for the guarantor is calculated further based on the current stage of the guarantor's account.
Example 121The method of Example 120, wherein determining a current stage of the guarantor's account comprises: detecting a staging event regarding the guarantor's account; and designating a stage of the guarantor's account in response to detecting the staging event.
Example 122The method of Example 93, further comprising: providing the PTP metric to the first billing system; updating the PTP metric based on a subsequent healthcare data pertaining to one or more subsequent healthcare visits; and providing an updated PTP metric to the first billing system.
Example 123A computer-implemented method for managing payments to a provider, the method comprising: aggregating, at a payment management system comprising one or more computing devices, historical transaction data tracked in a first billing system of a provider, the historical transaction data pertaining to encounters of beneficiaries with the provider, each of the beneficiaries guaranteed by a guarantor of one or more guarantors; extracting payment characteristics from the historical transaction data, including payment characteristics of the one or more guarantors; calculating a payment score for a first guarantor of the one or more guarantors based on payment characteristics of the first guarantor extracted from the historical transaction data, the payment score summarizing a predication that the first guarantor is going to pay for charges for encounters.
Example 124The method of Example 123, wherein the payment score comprises a propensity-to-pay (PTP) score providing indication of a likelihood that the first guarantor will pay for charges for encounters.
Example 125The method of Example 123, wherein the payment score comprises an ability-to-pay (ATP) score providing indication of a capacity of the first guarantor to pay for charges for encounters.
Example 126The method of Example 123, wherein the encounters comprise visits to a healthcare provider for healthcare services.
Example 127The method of Example 123, wherein the encounters comprise encounters to purchase products from a provider.
Example 128The method of Example 123, wherein the historical transaction data includes billing transaction records, payment transaction records, and/or financing plan records associated with charges of an encounter of a beneficiary who is associated with the first guarantor.
Example 129The method of Example 128, wherein the beneficiary is the first guarantor.
Example 130A system for managing payments for services, comprising: one or more processors; a memory in electrical communication with the one or more processors to store first visit data specifying a first visit charge pertaining to a first visit for which a first guarantor is responsible and to store second visit data specifying a second visit charge pertaining to a second visit for which a second guarantor is responsible, wherein the first visit data is tracked in a first billing system; a linking engine to receive a request to link an account of the first guarantor to the account of the second guarantor, provide an electronic notice of the request, receive indication of acceptance of the request, and to link the account of the first guarantor to the account of the second guarantor; a visits engine to aggregate the first visit data pertaining to the first visit charge with the second visit data pertaining to an account of the second guarantor; a statement engine to provide to the second guarantor an electronic statement including information from the first visit data pertaining to the first visit charge of the first guarantor aggregated with information from the second visit data pertaining to the second visit charge of the second guarantor.
Example 131The system of Example 130, wherein the second visit data is tracked in the first billing system.
Example 132The system of Example 130, wherein the second visit data is received from and tracked in a second billing system on one or more computers remote from the payment management system and coupled to the payment management system over a network.
Example 133The system of Example 130, further comprising a payment clearance and routing engine to receive payment data specifying a payment vehicle for paying a payment amount, communicate one or more transaction requests to process an electronic financial transaction to obtain payment funds in the payment amount from a payor financial institution associated with the payment vehicle and to transfer a first portion of the payment funds to a payee financial institution associated with associated with a provider of the first visit, and communicate one or more electronic posting files to notify the account of the first guarantor of transfer of the first portion of the payment funds toward payment of the charge for the first visit.
Example 134The system of Example 130, wherein the linking engine automatically requests from each of the first guarantor and the second guarantor a digitally signed release in compliance with externally imposed rules to protect information, wherein the linking engine receives the digitally signed release of each of the first guarantor and the second guarantor prior to the statement engine providing to the second guarantor information from the first visit data pertaining to the first visit charge.
Example 135The system of Example 134, wherein the externally imposed rules to protect information comprise the Health Insurance Portability and Accountability Act.
Example 136The system of Example 130, wherein the linking engine is further configured to receiving a request from one of the first guarantor and the second guarantor to unlink the account of the first guarantor from the account of the second guarantor, such that the second guarantor ceases to manage the account of the first guarantor on the payment management system, and unlink the account of the first guarantor from the account of the second guarantor, including removing from information pertaining to an account of the second guarantor information from the first visit data pertaining to the first visit charge, wherein the statement engine, upon the unlinking, provides to the second guarantor information pertaining to an account of the second guarantor on the payment management system, without information from the first visit data pertaining to the first visit charge.
Example 137The system of Example 136, wherein unlinking the account of the first guarantor from the account of the second guarantor comprises maintaining in the account of the second guarantor information pertaining to payments initiated by the second guarantor toward visit charges of the first guarantor.
Example 138A computer-implemented method for managing payments for services, the method comprising: receiving, at a payment management system comprising one or more computing devices, first visit data including a first visit charge pertaining to a first visit for which a first guarantor is responsible, the first visit charge including one or more charges incurred during the first visit; tracking the first visit charge in an account of the first guarantor on the payment management system; receiving at the payment management system a request of the first guarantor for a second guarantor to manage the account of the first guarantor on the payment management system; generating an electronic notice to the second guarantor of the request of the first guarantor; receiving at the payment management system an electronic indication of the second guarantor's acceptance of the request of the first guarantor; making the second guarantor a manager of the account of the first guarantor, based on the received indication of the second guarantor's acceptance, by linking the account of the first guarantor to the account of the second guarantor; and providing to the second guarantor information from the first visit data pertaining to the first visit charge, including an amount of the first visit charge, aggregated with information pertaining to an account of the second guarantor on the payment management system.
Example 139The method of Example 138, wherein the first visit data is tracked in a first billing system associated with a provider of the first visit.
Example 140The method of Example 139, wherein the first billing system is separate from the payment management system and the account of the first guarantor is tracked separately from tracking of the first visit data in the first billing system.
Example 141The method of Example 139, wherein the first billing system is on the one or more computing devices of the payment management system.
Example 142The method of Example 138, further comprising: populating the account of the first guarantor and the account of the second guarantor with information pertaining to the request of the first guarantor.
Example 143The method of Example 142, further comprising: providing to a computing device of the first guarantor information pertaining to the account of the first guarantor, including information pertaining to the request of the first guarantor.
Example 144The method of Example 142, further comprising: providing to a computing device of the second guarantor information pertaining to the account of the second guarantor, including information pertaining to the request of the first guarantor.
Example 145The method of Example 138, further comprising: receiving, at the payment management system, second visit data including a second visit charge pertaining to a second visit for which the second guarantor is responsible; and tracking the second visit charge in the account of the second guarantor on the payment management system, wherein the information provided to the second guarantor also includes information from the first visit data pertaining to the second visit charge, including an amount of the second visit charge.
Example 146The method of Example 145, wherein the first visit data and the second visit data are tracked in a first billing system associated with a provider of the first visit and a provider of the second visit.
Example 147The method of Example 145, wherein the second visit data is tracked in a second billing system separate from the payment management system and the account of the second guarantor is tracked separately from tracking of the account of the second guarantor on the payment management system.
Example 148The method of Example 147, wherein the second billing system is remote from the one or more computing devices of the payment management system and coupled to the payment management system over a network.
Example 149The method of Example 145, further comprising: receiving, from a computing device of the second guarantor, input from the second guarantor pertaining to payment of the first visit charge and payment of the second visit charge.
Example 150The method of Example 138, further comprising: receiving, from a computing device of the second guarantor, input from the second guarantor pertaining to payment of the first visit charge.
Example 151The method of Example 138, wherein the first visit data includes a second visit charge pertaining to a second visit for which the first guarantor is responsible, the method further comprising: providing to the second guarantor information pertaining to the second visit charge, including an amount of the second visit charge with the information from the first visit data and the information pertaining to an account of the second guarantor; and receiving from a computing device of the second guarantor input from the second guarantor pertaining to payment for the second visit charge.
Example 152The method of Example 138, wherein the request of the first guarantor for the second guarantor to manage the account of the first guarantor includes authorization for the second guarantor to receive and view the account information of the first guarantor.
Example 153The method of Example 138, further comprising: receiving at the payment management system a request from one of the first guarantor and the second guarantor to unlink the account of the first guarantor from the account of the second guarantor, such that the second guarantor ceases to manage the account of the first guarantor on the payment management system; unlinking the account of the first guarantor from the account of the second guarantor, including removing from information pertaining to an account of the second guarantor information from the first visit data pertaining to the first visit charge; and providing to the second guarantor information pertaining to an account of the second guarantor on the payment management system, without information from the first visit data pertaining to the first visit charge.
Example 154The method of Example 153, wherein unlinking the account of the first guarantor from the account of the second guarantor comprises maintaining in the account of the second guarantor information pertaining to payments initiated by the second guarantor toward visit charges of the first guarantor.
Example 155The method of Example 138, further comprising: receiving at the payment management system payment data specifying a payment vehicle for paying a payment amount; communicating one or more transaction requests to process an electronic financial transaction to obtain payment funds in the payment amount from a payor financial institution associated with the payment vehicle and to transfer a first portion of the payment funds to a payee financial institution associated with associated with a provider of the first visit; and communicating one or more electronic posting files to notify the account of the first guarantor of transfer of the first portion of the payment funds toward payment of the charge for the first visit and to notify.
Example 156The method of Example 155, wherein the transaction request is further to process an electronic transaction to transfer a second portion of the payment funds to a payee financial institution associated with a second billing system, and wherein the one or more electronic posting files are further to notify the second billing system of transfer of the second portion of the payment funds toward payment of the charge for the second visit.
Example 156The method of Example 138, wherein making the second guarantor a manager of the account of the first guarantor comprises: automatically requesting from each of the first guarantor and the second guarantor a digitally signed release in compliance with externally imposed rules to protect information; and receiving the digitally signed release of each of the first guarantor and the second guarantor, prior to providing to the second guarantor information from the first visit data pertaining to the first visit charge.
Example 157The method of Example 156, wherein the externally imposed rules to protect information comprise the Health Insurance Portability and Accountability Act.
Example 158A computer-implemented method for managing payments for services, the method comprising: receiving, at a payment management system comprising one or more computing devices, first visit data including a first visit charge pertaining to a first visit for which a first guarantor is responsible, the first visit charge including one or more charges incurred during the first visit; tracking the first visit charge in an account of the first guarantor on the payment management system; receiving at the payment management system a request of a second guarantor to manage an account of the first guarantor on the payment management system; generating an electronic notice to the first guarantor of the request of the second guarantor; receiving at the payment management system an electronic indication of the first guarantor's acceptance of the request of the second guarantor; making the second guarantor a manager of the account of the first guarantor, based on the received indication of the first guarantor's acceptance, by linking the account of the first guarantor to the account of the second guarantor; and providing to the second guarantor information from the first visit data pertaining to the first visit charge, including an amount of the first visit charge, aggregated with information pertaining to an account of the second guarantor on the payment management system.
Example 159The method of Example 158, the further comprising: receiving, at the payment management system, second visit data including a second visit charge pertaining to a second visit for which the second guarantor is responsible; and tracking the second visit charge in the account of the second guarantor on the payment management system, wherein the information provided to the second guarantor also includes information from the first visit data pertaining to the second visit charge, including an amount of the second visit charge.
Example 160The method of Example 159, wherein the first visit data and the second visit data are tracked in a first billing system associated with a provider of the first visit and a provider of the second visit.
Example 161The method of Example 159, wherein the second visit data is tracked in a second billing system separate from the payment management system and the account of the second guarantor is tracked separately from tracking of the account of the second guarantor on the payment management system.
Example 162A system for managing payments for services, comprising: one or more processors; a memory in electrical communication with the one or more processors to store first visit data received from a first billing system and second visit data that is tracked by a second billing system that is independent from the first billing system, the first visit data specifying a charge for a first visit, and the second visit data specifying a charge for a second visit; a visits engine to aggregate the first visit data pertaining to the first visit charge with the second visit data pertaining to the second visit charge; a statement engine to provide a statement including information from the first visit data pertaining to the first visit charge aggregated with information from the second visit data pertaining to the second visit charge.
Example 163The system of Example 162, further comprising: a payment portal to receive payment data specifying a payment vehicle for paying a payment amount; and a payment and clearance routing engine to: transmit a transaction request to a payment gateway to request the payment gateway to obtain funds in the payment amount from a payor financial institution associated with the payment vehicle, to transfer a first portion of the payment funds to a payee financial institution associated with the first patient billing system, and to transfer a second portion of the payment funds to a payee financial institution associated with the second patient billing system; and communicate one or more electronic posting files to notify the first patient billing system of transfer of the first portion of the payment funds toward payment of the charge for the first visit and to notify the second patient billing system of transfer of the second portion of the payment funds toward payment of the charge for the second visit.
Example 164The system of Example 162, further comprising an extraction engine to extract the first visit data from the first billing system and to generate a single longitudinal portrayal including the first visit data and the second visit data.
Example 165The system of Example 162, wherein the visits engine is further to compile the first visit charge and the second visit charge into a current batch of open charges and generate an open charges balance by aggregating all open charges of the current batch of open charges, the system further comprising: a balance brokering engine to evaluate the open charges balance based on asset sales criteria for determining whether the open charges balance should be transferred from the first billing system to a new system of record and effectuate electronic transactions to transfer title of an accounts receivable asset that constitutes rights to collect payment for the open charges balance, including payment for the current batch of open charges, to the new system of record, if the asset sales criteria are met; and wherein the system tracks the open charges balance, including payments to pay the one or more visit charges and other transactions relating to the open charges balance, wherein the system tracks the open charges balance separate from the first billing system and tracks transactions tracked in the first billing system that pertain to the one or more visit charges.
Example 166The system of Example 165, further comprising: a scoring engine configured to extract propensity-to-pay (“PTP”) characteristics from the first visit data and the second visit data, including PTP characteristics of the one or more guarantors, and calculate a PTP metric for a guarantor based on PTP characteristics of the guarantor extracted from the historical healthcare data, wherein the PTP metric indicates a likelihood that the guarantor will pay for visit charges for healthcare visits, wherein the PTP metric is one of the asset sales criteria upon which the balance brokering engine evaluates the open charges balance.
Example 167The system of Example 162, further comprising: a financing engine to: present, to a guarantor of both the charge for the first visit and the charge for the second visit, pre-determined payment options for paying an open charges balance including the charge for the first visit and the charge for the second visit, each of the pre-determined payment options including terms at least partially defined by one of a present asset holder and a potential asset holder of the open charges balance; receive, at the payment management system, a guarantor selection of one of the pre-determined payment options for paying the open charges balance; and determine a payment amount based on the selected one of the pre-determined payment options.
Example 168A computer-implemented method for managing payments for services, the method comprising: receiving at one or more computing devices first visit data from a first billing system, the first visit data including a charge for a first visit; receiving at the one or more computing devices second visit data being tracked in a second billing system that is independent from the first billing system, the second visit data specifying a charge for a second visit; receiving at the one or more computing devices payment data specifying a payment vehicle for paying a payment amount; communicating a transaction request to a payment gateway to request the payment gateway process an electronic financial transaction to obtain payment funds in the payment amount from a payor financial institution associated with the payment vehicle, to transfer a first portion of the payment funds to a payee financial institution associated with the first patient billing system, and to transfer a second portion of the payment funds to a payee financial institution associated with the second patient billing system; and communicating one or more electronic posting files to notify the first billing system of transfer of the first portion of the payment funds toward payment of the charge for the first visit and to notify the second billing system of transfer of the second portion of the payment funds toward payment of the charge for the second visit.
Example 169The method of Example 168, further comprising generating on the one or more computing devices an open charges balance by summing the charge for the first visit and the charge for the second visit to aggregate charges during a given time period and that are tracked in multiple billing systems.
Example 170The method of Example 168, wherein the payment gateway is a remote third party gateway coupled to the one or more computers by a network, wherein communicating a transaction request to the payment gateway comprises transmitting the transaction request over the network.
Example 171The method of Example 168, wherein the payment amount differs from the charge for the first visit and differs from the amount of the charge for the second healthcare visit.
Example 172The method of Example 168, further comprising: receiving at the one or more computing devices payment option input specifying present or eventual asset holder pre-determined payment options; and receiving at the one or more computing devices a selection of one of the provider pre-determined payment options; and determining the payment amount based on the selected one of the provider pre-determined payment options.
Example 173The method of claim Example 172, wherein the payment options input includes a pay-in-full discount.
Example 174The method of Example 172, wherein the payment options input includes provider-determined preset financing terms.
Example 175The method of Example 172, wherein the payment options input includes provider-determined parameters for guarantor-customized financing terms.
Example 176The method of Example 168, further comprising generating a single longitudinal portrayal of visit data including the first visit data and the second visit data.
Example 177The method of Example 176, further comprising providing the longitudinal portrayal to a client computing device over a network.
Example 178The method of Example 168, wherein the first visit data specifies a charge for a first visit of a beneficiary and the second visit data specifies a charge for a second visit of the beneficiary.
Example 179The method of Example 168, wherein the first visit data specifies a charge for a first visit of a beneficiary and the second visit data specifies a charge for a second visit of a second beneficiary.
Example 180The method of Example 168, wherein the first visit is a first healthcare visit, the second visit is a second healthcare visit, and a beneficiary of the first healthcare visit and the second healthcare visit is a patient.
Example 181The method of Example 168, wherein the first visit is a first healthcare visit of a first patient and the second visit is a second healthcare visit of a second patient.
Example 182The method of Example 168, wherein the payment data specifies a payment vehicle of a guarantor of a beneficiary of the first visit and a beneficiary of the second visit.
Example 183The method of Example 182, wherein the guarantor is the beneficiary of at least one of the first visit and the second visit.
Example 184The method of Example 168, wherein the second visit data is received from the second billing system, wherein the second billing system is remote from the one or more computing devices.
Example 185The method of Example 168, wherein the first visit data includes a charge for each of a first plurality of visits during a time period, and wherein the one or more electronic posting files to notify the first patient billing system of transfer of the first portion of the payment funds and allocates the first portion of the payment funds toward payment of the charge of one or more of the first plurality of visits.
Example 186The method of Example 185, further comprising receiving at the one or more computing devices one or more payor preferences for specifying how a payment is to be allocated to among the first plurality of visit charges; generating the one or more electronic posting files based on the payor preferences.
Example 187The method of Example 168, wherein the charge for the first visit is tracked in an account within the first billing system and the charge for the second visit is tracked in an account in the second billing system, wherein a first electronic posting file of the one or more electronic posting files specifies the account within the first billing system and a second electronic posting file of the one or more electronic posting files specifies the account within the second billing system.
Example 188The method of Example 168, wherein the first billing system is associated with a first balance sheet entity and the second billing system is associated with a second balance sheet entity that is independent from the first balance sheet entity.
Example 189The method of Example 168, wherein the charge for the first visit comprises an aggregation of a plurality of line item charges for the first visit, such that all the line item charges for the first visit were incurred for the first visit.
The above description provides numerous specific details for a thorough understanding of the embodiments described herein. However, those of skill in the art will recognize that one or more of the specific details may be omitted, or other methods, components, or materials may be used. In some cases, operations are not shown or described in detail.
Furthermore, the described features, operations, or characteristics may be combined in any suitable manner in one or more embodiments. It will also be readily understood that the order of the steps or actions of the methods described in connection with the embodiments disclosed may be changed as would be apparent to those skilled in the art. Thus, any order in the drawings or Detailed Description is for illustrative purposes only and is not meant to imply a required order, unless specified to require an order.
Embodiments may include various steps, which may be embodied in machine-executable instructions to be executed by a general-purpose or special-purpose computer (or other electronic device). Alternatively, the steps may be performed by hardware components that include specific logic for performing the steps, or by a combination of hardware, software, and/or firmware.
Embodiments may also be provided as a computer program product including a computer-readable storage medium having stored instructions thereon that may be used to program a computer (or other electronic device) to perform processes described herein. The computer-readable storage medium may include, but is not limited to: hard drives, floppy diskettes, optical disks, CD-ROMs, DVD-ROMs, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, solid-state memory devices, or other types of media/machine-readable media suitable for storing electronic instructions.
As used herein, a software module or component may include any type of computer instruction or computer-executable code located within a memory device and/or computer-readable storage medium. A software module may, for instance, comprise one or more physical or logical blocks of computer instructions, which may be organized as a routine, a program, an object, a component, a data structure, etc., that perform one or more tasks or implement particular abstract data types.
In certain embodiments, a particular software module may comprise disparate instructions stored in different locations of a memory device, which together implement the described functionality of the module. Indeed, a module may comprise a single instruction or many instructions, and may be distributed over several different code segments, among different programs, and across several memory devices. Some embodiments may be practiced in a distributed computing environment where tasks are performed by a remote processing device linked through a communications network. In a distributed computing environment, software modules may be located in local and/or remote memory storage devices. In addition, data being tied or rendered together in a database record may be resident in the same memory device, or across several memory devices, and may be linked together in fields of a record in a database across a network.
Claims
1. A computer system, comprising:
- memory circuitry;
- processor circuitry; and
- a storage medium including instructions that, when executed by the processor circuitry and memory circuitry of the computer system, implement a plurality of engines in the computer system, the plurality of engines comprising:
- a data extraction engine, adapted to generate data for a predictive data evaluation, with operations to:
- receive a transaction estimate data record from an estimation system, wherein the transaction estimate data record includes a data value that represents an estimate for a prospective transaction between a human subject and a service provider;
- receive an evaluation data record from a data analysis system, wherein the evaluation data record includes a plurality of characteristics uniquely generated for the human subject related to the prospective transaction; and
- generate a prospective transaction data record for the prospective transaction, wherein the prospective transaction data record is established at a time of generation of a user-interactive graphical user interface, and wherein the prospective transaction data record is based on the plurality of characteristics and requirements of the service provider;
- an application engine, adapted to generate the user-interactive graphical user interface and process interaction with the user-interactive graphical user interface, with operations to:
- output information for the prospective transaction for the human subject, using the transaction estimate data record;
- output multiple selection options that are uniquely generated to the human subject, using the prospective transaction data record;
- receive an indication of a selected transaction option from among the multiple selection options, wherein the selected transaction option is associated with defined characteristics of a second prospective transaction;
- update the graphical user interface to output a confirmation of the selected transaction option and details of the second prospective transaction, in response to receipt of the indication of the selected transaction option; and
- transmitting an indication of the selected transaction option to a processing system, to enable subsequent performance of the second prospective transaction.
2. The computer system of claim 1,
- wherein the multiple selection options that are uniquely generated to the human subject are determined based on rules for the second prospective transaction that are defined by the service provider,
- wherein the user of the graphical user interface is a human agent associated with the service provider, and
- wherein selection of the selected transaction option in the user-interactive graphical user interface is provided from the human agent.
3. The computer system of claim 2, the plurality of engines further comprising:
- a transaction engine, adapted to, upon receipt of an indication that the prospective transaction with the service provider is performed, perform data processing operations and transmit electronic communications to implement the second prospective transaction.
4. A method of predictive data evaluation used to generate a user-interactive graphical user interface, comprising electronic operations implemented with processor circuitry of a computing system, and the electronic operations comprising:
- receiving a healthcare transaction estimate data record from a healthcare estimation system, wherein the healthcare transaction estimate data record includes a data value that represents an estimate of expected charges of a prospective healthcare transaction for a consumer;
- receiving a consumer evaluation data record from a consumer data analysis system, wherein the consumer evaluation data record includes a data value that represents an evaluative score for the consumer and data values that represent a plurality of characteristics determined for the consumer;
- generating a proposed payment transaction data record for the estimate of the expected charges of the prospective healthcare transaction using the healthcare transaction estimate data record and the consumer evaluation data record, wherein the proposed payment transaction data record is established at a time of generation of the graphical user interface, and wherein the proposed payment transaction data record is based on: the evaluative score, the plurality of characteristics determined for the consumer, and a plurality of requirements of a creditor of the expected charges for the prospective healthcare transaction;
- generating the graphical user interface based on the proposed payment transaction data record, wherein the graphical user interface: outputs information for the prospective healthcare transaction and a representation of the estimate of the expected charges, using the healthcare transaction estimate data record; outputs multiple selection options that are uniquely generated to the consumer, wherein the multiple selection options are generated using the proposed payment transaction data record; and receives an indication of a user selection of a selected payment transaction option from among the multiple selection options, wherein the user selection is associated with characteristics of a prospective financial transaction; wherein the graphical user interface is updated to output an indication of confirmation of the selected payment transaction option and details of the prospective financial transaction; and
- transmitting an indication of the selected payment transaction option to a processing system, in response to receipt of the indication of the user selection of the selected payment transaction option.
5. The method of claim 4,
- wherein the user of the graphical user interface is a healthcare support staff member, wherein the graphical user interface is output to the healthcare support staff member, and
- wherein the user selection of the selected payment transaction option is received from the healthcare support staff member.
6. The method of claim 5, the electronic operations further comprising:
- generating a second graphical user interface, wherein the second graphical user interface is output to the consumer, and wherein the second graphical user interface: outputs a representation of the estimate of the expected charges, using the healthcare transaction estimate data record; outputs an indication of the user selection of the selected option; and receives a selection of a confirmation for a payment arrangement of the selected payment transaction option in the second graphical user interface;
- in response to receipt of the selection of the confirmation for the payment arrangement, updating the second graphical user interface to output a confirmation; and
- transmitting an indication to a payment processing system to proceed with the prospective financial transaction.
7. The method of claim 4,
- wherein the graphical user interface is provided to the consumer,
- wherein the user selection of the selected payment transaction option is received from the consumer, and
- wherein the multiple selection options that are uniquely generated to the consumer are based upon rules established by a prospective asset holder of the expected charges of the prospective healthcare transaction.
8. The method of claim 4, the electronic operations further comprising:
- in response to a notification of a performance of the prospective healthcare transaction, activating a plurality of financing and payment transactions associated with the selected payment transaction option.
9. The method of claim 4:
- wherein the estimate of the expected charges is generated by the healthcare estimation system based on: historical healthcare transactions, contractual agreements for charges of the prospective healthcare transaction, a health plan coverage of a patient for the prospective healthcare transaction, a deductible under the health plan coverage, and progress towards the deductible under the health plan coverage;
- wherein the data values that represent the plurality of characteristics determined for the consumer include data values that represent one or more of: identifying information, insurance information, demographic information, credit information, or healthcare-related information, of the consumer;
- wherein the data value that represents the evaluative score for the consumer includes a propensity to pay score or an ability to pay score;
- wherein the propensity to pay score is generated based on the estimate of the expected charges and one or more of: past payment history of the consumer for the historical healthcare transactions, past bad debts of the consumer for the historical healthcare transactions, an outstanding balance of the historical healthcare transactions, or credit risk of the consumer; and
- wherein the ability to pay score is generated based on one of more of: the historical healthcare transactions, demographic data of the consumer, or debt and income characteristics of the consumer.
10. The method of claim 4,
- wherein the selected payment transaction option is used to establish a financing or payment arrangement for the prospective healthcare transaction,
- wherein the financing or payment arrangement includes one or more of: a discount for payment in full prior to the prospective healthcare transaction, a prompt pay discount for payment within a time period after the prospective healthcare transaction, a discount for establishing a financing plan prior to the prospective healthcare transaction, a discount for need-based financial assistance, down payment requirements for a financing plan, a duration term for a financing plan, an interest rate for a financing plan, or a minimum amount payment for a financing plan.
11. The method of claim 4, wherein the selected payment transaction option is indicated to provide payment to multiple healthcare providers for a plurality of healthcare activities related to the prospective healthcare transaction.
12. The method of claim 4, wherein the evaluative score is based at least in part on a propensity to pay (PTP) score, with the electronic operations further comprising:
- generating the PTP score for the consumer using the consumer data analysis system, wherein data representing the PTP score is established at the time of generation of the graphical user interface.
13. The method of claim 4, wherein the consumer is: a patient of the prospective healthcare transaction, or a guarantor of the patient.
14. The method of claim 4, wherein in response to performance of the prospective healthcare transaction, a payment received for the estimate of expected charges of the prospective financial transaction is reconciled to actual charges for the performance of the prospective healthcare transaction.
15. The method of claim 14, the electronic operations performed in response to performance of the prospective healthcare transaction further comprising:
- generating a healthcare transaction reconciliation data record, wherein the healthcare transaction reconciliation data record indicates a remaining balance after applying a payment or financing arrangement for the prospective financial transaction;
- generating an updated payment arrangement data record; and
- generating a second graphical user interface, wherein the second graphical user interface: outputs a representation of the payment received with the prospective financial transaction; outputs a representation of remaining charges for the performance of the prospective healthcare transaction, using the healthcare transaction reconciliation data record; outputs additional selection options that are uniquely generated to the consumer for payment of the remaining balance, using the proposed payment transaction data record; and receives an indication of a user selection of a selected reconciliation payment transaction option from among the additional selection options; and
- transmitting, to the processing system, an indication of the selected reconciliation payment transaction option, in response to receipt of the indication of the user selection of the selected reconciliation payment transaction option.
16. The method of claim 14, the electronic operations performed in response to performance of the prospective healthcare transaction further comprising:
- generating a healthcare transaction reconciliation data record, wherein the healthcare transaction reconciliation data record indicates reduced charges for the performance of the prospective healthcare transaction as compared with the estimate of the expected charges for the prospective financial transaction;
- generating an updated payment arrangement data record with an adjustment to a payment or financing arrangement to provide payment of the reduced charges, wherein the adjustment to the payment or financing plan includes a change to an amount, payment terms, or financing terms, based on the reduced charges; and
- transmitting, to the processing system, an indication of the adjustment to the payment or financing arrangement to provide payment of the reduced charge.
17. A non-transitory computer-readable storage medium having stored thereon instructions that, when executed by a computing system, cause the computing system to provide a user-interactive graphical user interface with operations that:
- receive a healthcare transaction estimate data record from a healthcare estimation system, wherein the healthcare transaction estimate data record includes a data value that represents an estimate of expected charges of a prospective healthcare transaction for a consumer;
- receive a consumer evaluation data record from a consumer data analysis system, wherein the consumer evaluation data record includes a data value that represents an evaluative score for the consumer and data values that represent a plurality of characteristics determined for the consumer;
- generate a proposed payment transaction data record for the estimate of the expected charges of the prospective healthcare transaction using the healthcare transaction estimate data record and the consumer evaluation data record, wherein the proposed payment transaction data record is established at a time of generation of the graphical user interface, and wherein the proposed payment transaction data record is based on the evaluative score, the plurality of characteristics determined for the consumer, and a plurality of requirements of a creditor of the expected charges for the prospective healthcare transaction;
- generate the graphical user interface based on the proposed payment transaction data record, wherein the graphical user interface: outputs information for the prospective healthcare transaction and a representation of the estimate of the expected charges, using the healthcare transaction estimate data record; outputs multiple selection options that are uniquely generated to the consumer, wherein the multiple selection options are generated using the proposed payment transaction data record; and receives an indication of a user selection of a selected payment transaction option from among the multiple selection options, wherein the selected payment transaction option is associated with characteristics of a prospective financial transaction; wherein the graphical user interface is updated to output an indication of confirmation of the selected payment transaction option and details of the prospective financial transaction; and
- transmit an indication of the selected payment transaction option to a processing system, in response to receipt of the indication of the user selection of the selected payment transaction option.
18. The computer-readable storage medium of claim 17,
- wherein the user of the graphical user interface is a healthcare support staff member,
- wherein the graphical user interface is output to the healthcare support staff member,
- wherein the user selection of the selected payment transaction option is received from the healthcare support staff member, and
- wherein the instructions further perform electronic operations that: generate a second graphical user interface, wherein the second graphical user interface is output to the consumer, and wherein the second graphical user interface: outputs a representation of the estimate of the expected charges, using the healthcare transaction estimate data record; outputs an indication of the user selection of the selected option; and receives a selection of a confirmation for a payment arrangement of the selected payment transaction option in the second graphical user interface; in response to receipt of the selection of the confirmation for the payment arrangement, update the second graphical user interface to output a confirmation; and transmit an indication to a payment processing system to proceed with the prospective financial transaction.
19. The computer-readable storage medium of claim 18,
- wherein the user of the graphical user interface is the consumer,
- wherein the user selection of the selected payment transaction option is received from the consumer, and
- wherein the multiple selection options that are uniquely generated to the consumer are based upon rules established by a prospective asset holder of the expected charges of the prospective healthcare transaction.
20. The computer-readable storage medium of claim 19:
- wherein the estimate of the expected charges is generated by the healthcare estimation system based on: historical healthcare transactions, contractual agreements for charges of the prospective healthcare transaction, a health plan coverage of a patient for the prospective healthcare transaction, a deductible under the health plan coverage, and progress towards the deductible under the health plan coverage;
- wherein the data values that represent the plurality of characteristics determined for the consumer include data values that represent one or more of: identifying information, insurance information, demographic information, credit information, or healthcare-related information, of the consumer; and
- wherein the data value that represents the evaluative score for the consumer includes a propensity to pay score or an ability to pay score.
21. The computer-readable storage medium of claim 17,
- wherein the selected payment transaction option is used to establish a financing or payment arrangement for the prospective healthcare transaction,
- wherein the financing or payment arrangement includes one or more of: a discount for payment in full prior to the prospective healthcare transaction, a prompt pay discount for payment within a time period after the prospective healthcare transaction, a discount for establishing a financing plan prior to the prospective healthcare transaction, a discount for need-based financial assistance, down payment requirements for a financing plan, a duration term for a financing plan, an interest rate for a financing plan, or a minimum amount payment for a financing plan.
Type: Application
Filed: Aug 8, 2016
Publication Date: Nov 24, 2016
Inventors: Kent F. Ivanoff (Boise, ID), Vincent Martino (Eagle, ID), Nikolaus Trotta (Boise, ID)
Application Number: 15/230,863
