Abstract:
Front-end patient financial triage is provided, wherein various financial clearance checks may be processed prior to proceeding with a non-emergent patient encounter. A patient&#39;s credit history, historic payment information, and symptoms of his/her financial health, such as employment and income, family size, etc., as well as address and social security number verification may be utilized to help a health care provider determine if a patient may pay for health care services. A web-based configuration tool may be provided for allowing the health care provider to dynamically change rules that define cascading processes of a financial clearance transaction. A health care provider may be able to use this actionable financial information to make better up-front decisions about which financial category may be most appropriate for a patient. Embodiments may help to protect a health care provider&#39;s financial liability, reduce bad debt and preventable write-offs.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    The present application claims priority to U.S. Provisional Patent Application No. 61/765,317 titled “Financial Triage” filed Feb. 15, 2013, the disclosure of which is incorporated herein by reference in its entirety. 
     
    
     BACKGROUND 
       [0002]    Triage is a thorough up-front analysis to inspire better decision making that produces better end results. Hospitals, for example, employ educated and trained nurses and other specialists to handle the task of triage. Health care organizations oftentimes make an investment in making triage more efficient and accurate due to serious consequences that may occur because of a minor clinical mistake. 
         [0003]    The same expectations have not been applied to a patient and payer data verification workflow (referred to herein as patient access workflow). As can be appreciated, the stakes may not be the same; however, mistakes can be costly. In an environment where performance may be measured by how many registrations a user/registrar may complete in an hour or shift, there may be ample opportunity for error and little time for manual research to help prevent errors. Oftentimes, users/registrars try to do what they can to meet a minimum financial clearance to pass a patient to a next department, leaving a majority of financial triage work to financial counselors or other employees in the back office. 
         [0004]    Sometimes it can take thirty days or more for a hospital to begin determining whether a patient service can be written off as charity care, or whether a government-subsidized plan may cover charges. When neither a government-subsidized plan nor charity is legitimate and a patient owes a balance (which may be a full balance), it is oftentimes only partially retrieved by in-house or third party collection or may never be collected at all. 
         [0005]    It is with respect to this and other considerations the present invention has been made. 
       SUMMARY 
       [0006]    Embodiments of the present invention provide for a front-end patient financial triage. Various financial clearance checks may be processed before proceeding with a non-emergent patient encounter. A patient&#39;s credit history, historic payment information, and symptoms of his/her financial health, such as employment and income, family size, etc., as well as address and social security number verification, may be utilized to help a health care provider determine if a patient may pay for health care services. 
         [0007]    A health care provider may be able to use this actionable financial information to make better up-front decisions about which financial category may be most appropriate for a patient. Embodiments may help to protect a health care provider&#39;s financial liability, reduce bad debt and preventable write-offs. Additionally, unnecessary labor and costs of collection may be reduced. 
         [0008]    The details of one or more embodiments are set forth in the accompanying drawings and description below. Other features and advantages will be apparent from a reading of the following detailed description and a review of the associated drawings. It is to be understood that the following detailed description is explanatory only and is not restrictive of the invention as claimed. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0009]      FIG. 1  is a simplified block diagram of a high-level system architecture with which embodiments of the invention may be implemented. 
           [0010]      FIG. 2  illustrates an example of a self-pay patient financial triage process according to an embodiment. 
           [0011]      FIG. 3  is a simplified block diagram of a computing device with which embodiments of the present invention may be practiced. 
       
    
    
     DETAILED DESCRIPTION 
       [0012]    Embodiments provide for front-end financial triage. Many health care organizations currently verify insurance eligibility, which may be a first step in a front-end financial triage of an insured patient. Having insurance coverage does not inherently mean that a patient may be able to pay for health care services. Some patients may not be able to pay their deductible. For example, a family of four with one working parent earning $30,000 annually may be covered by the parent&#39;s employer; however, because of the family&#39;s financial circumstances, may also qualify for charity care. Accordingly, a health care provider may bill the family&#39;s insurance company (payer) for a portion of the charges, and may write off the deductible as charity. Other patients may have wherewithal to pay, but may intentionally avoid payment. 
         [0013]    Some patients may not be forthright about their finances. Some patients who are capable to pay may claim to need a health care provider&#39;s assistance with a high deductible. Other patients may need financial assistance, but may be reluctant to seek help. Embodiments may help to distinguish between patients who can pay and those who cannot. Credit reporting bureaus may be accessed to generate a patient&#39;s medical credit score. The score, which may be based on various factors such as employment, income, family size, debt, and payment history, may help a health care provider to determine whether a patient has the ability to pay and may provide a ranking of how likely he/she is to pay. 
         [0014]    These embodiments may be combined, other embodiments may be utilized, and structural changes may be made without departing from the spirit or scope of the present invention. The following detailed description is therefore not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims and their equivalents. Referring now to the drawings, in which like numerals refer to like elements throughout the several figures, embodiments of the present invention and an exemplary operating environment will be described. 
         [0015]    Referring now to  FIG. 1 , a simplified block diagram of a high-level system architecture  100  with which embodiments of the invention may be implemented is illustrated. The system  100  may include a financial clearance engine  104  operable to receive inbound information  102 , run the received inbound information  102  through decision tree logic, and provide various actions and output  142  from the actions. The inbound information  102  may include one or more of demographic verification data  110 , social security number verification data  112 , coverage verification data  114 , credit report data  116 , income data  118 , family size data  120 , payment history data  122 , estimate data  124 , health care provider identification data  126 , service type/department identification data  128 , as well as other data  130 . 
         [0016]    According to one embodiment, a request may be sent by the financial clearance engine  104  to one or more third party data sources for one or more of demographic verification data  110 , social security number verification data  112 , coverage verification data  114 , credit report data  116 , income data  118 , family size data  120 , payment history data  122 , estimate data  124 , health care provider identification data  126 , and service type/department identification data  128 . Verification and/or validation processes may be performed by one or more external engines, and results of the verification and/or validation processes may be provided to the financial clearance engine  104  as inbound information  102 . 
         [0017]    According to another embodiment, a request may be sent by the financial clearance engine  104  to one or more third party data sources for one or more of demographic verification data  110 , social security number verification data  112 , coverage verification data  114 , credit report data  116 , income data  118 , family size data  120 , payment history data  122 , estimate data  124 , health care provider identification data  126 , and service type/department identification data  128 . Verification and/or validation processes may be performed by the financial clearance engine  104 . 
         [0018]    Requests for inbound information  102  may be sent according to a waterfall approach. For example, a first request may be sent for address verification data (demographic verification data)  110 . Rules  106  may be applied to determine if the received address verification data is sufficient or if another request for additional data may need to be sent. If a determination is made that more data is needed, according to the rules  106 , a next request may be sent to one or more third party data sources. For example, a next request may be sent to a credit reporting agency. Inbound information  102  from the credit reporting agency may include additional demographic verification data  110 , and may also include a credit score/report  116  of a patient (or guarantor of a patient&#39;s account). The credit score/report  116  data may be utilized to determine a patient&#39;s likelihood for charity eligibility  132 , and may also be utilized to assess the patient&#39;s propensity to pay  138 . The eligibility for charity  132  and propensity to pay  138  may be determined utilizing one or more additional pieces of inbound information  102 , for example, the patient&#39;s income  118 , family size  120 , payment history  122 , estimate data  124 , etc. According to an embodiment, a patient&#39;s federal poverty level according to federal poverty guidelines may be determined according to received inbound information  102 . 
         [0019]    According to embodiments, one or more pieces of output data  142  may be provided by the financial clearance engine  104 . As mentioned above, the financial clearance engine  104  may be operable to determine a patient&#39;s likelihood for charity eligibility  132 , and may also be utilized to assess the patient&#39;s propensity to pay  138 . Additional output data  142  may include address validation  134 , social security number validation  136 , and may include other output data  140 . 
         [0020]    Output data  142  may be provided in various ways. For example, output data  142  may be displayed in real time in HTML on a web-based page, may be sent to a requesting party via a batch file, may be posted electronically to a hospital information system (HIS), etc. The output data  142  may include a notification of missing or inconsistent data, may include a response to charity eligibility  132 , and may include a medical credit score and a confidence level. The score may be provided on a scale. For example, on a scale of 1 to 10, a given patient&#39;s ability to pay may be determined to be a 6. The response to charity eligibility  132  may be provided by a simple yes or no answer, or may also include what types of charities for which a patient may be eligible. If a patient is eligible for government-subsidized coverage, the response to charity eligibility  132  may also include this information. According to an embodiment, the output data  142  may also include recommendation information. For example, if a determination is made that a patient is able to pay for an upcoming health care encounter, but has a history of non-payment for health care bills, a recommendation to collect payment up-front may be provided. 
         [0021]    According to embodiments, the system  100  may include a configurator  108  operable to allow a user to dynamically change the financial clearance engine rules  106 . The configurator  108  may be a web-based tool for modifying one or more rules  106 . The one or more rules  106  may define the decision tree and may define what pieces of inbound data  102  to request depending on certain predefined circumstances. The rules  106  may be utilized to determine the quantum of information to process. For example, the rules  106  may define the parameters used to determine what transactions to run, including patient type (e.g., commercial payer, government-subsidized payer, self-pay, etc.), amount owed by a patient, where services are being rendered (e.g., health care provider  126 ), in what department  128  or a service type being provided (e.g., emergency department, scheduling, inpatient surgery, outpatient surgery, etc.). The rules  106  may determine how to cascade processes of a financial clearance transaction, which may drive hierarchy of the process, for example, whether a financial clearance transaction may need to include coverage discovery (e.g., coverage verification  114 ) as part of the process. As another example, if a patient owes a minimal amount (e.g., $10), certain transactions/processes may not be performed because the cost to perform the transactions/processes may outweigh the amount due to the provider. 
         [0022]    As described above, coverage verification data  114  may be one piece of inbound information  102 . A self-pay patient may be assessed for qualification for a government-subsidized payer program (e.g., Medicaid). Oftentimes, patients who qualify for government-subsidized coverage seek treatment as self-pay because they are not aware of their own eligibility. Verifying government eligibility and beginning the enrollment process during pre-registration or registration may help to provide excellent customer service. It may be beneficial to both the patient and the health care provider because it may help to secure reimbursement for the health care provider and help to ease personal financial burden for the patient. 
         [0023]    Sometimes, a patient may earn too much money to qualify for government-subsidized coverage, but may not earn enough to pay for a needed surgery. Patients who fall into this category may be eligible for some level of charity care. Rules  106  may define charity care levels for screening patients against the health care provider&#39;s guidelines. 
         [0024]    Patients with too much income to qualify for government-subsidized coverage or charity care may be expected to make payment prior to a health care encounter. If a patient resists, the medical credit score determined by the financial clearance engine  104  may help a registrar/user to respond accordingly. By running a score, more current, accurate, and detailed information than what the patient may be willing to divulge may be provided. With an understanding of a patient&#39;s ability and propensity to pay  138 , a health care provider may be able to proceed with more confidence and offer any approved discounts or payment plan options to encourage payment. 
         [0025]    Historically, it has not been practical to address financial triage tasks while a patient is on-site, and has become a task for health care provider financial counselors to gather the necessary information from patients to determine eligibility. Because financial triage tasks may require heavy paperwork, research, and follow-up, it has rarely been completed pre-service and may often be delayed for weeks or longer. Embodiments of the present invention automate the decision tree and may identify a correct classification for a patient in real time. Features for converting paperwork to electronic formats may be included, further automating and accelerating the process. 
         [0026]      FIG. 2  illustrates an example of a self-pay patient financial triage process  200  according to an embodiment. The process  200  may start at OPERATION  202  and proceed to OPERATION  204 , where a patient&#39;s social security verification data  112  may be input, and a verification that the patient&#39;s social security number matches the patient&#39;s name may be performed. The process  200  may then proceed to OPERATION  206 , where a verification of the patient&#39;s address may be performed. According to embodiments, address validation  136  may comprise a verification that an address is a deliverable address and also a verification that a patient lives or has lived at the address. 
         [0027]    The process  200  may proceed to DECISION OPERATION  208 , where a determination may be made as to whether a patient is eligible for government-subsidized coverage. Eligibility for government-subsidized coverage may be determined utilizing one or more pieces of inbound information  102 , such as demographic verification data  110 , income data  118 , family size data  120 , etc. If a determination is made that a patient is eligible for government-subsidized coverage, the patient may be screened for other coverages at OPERATION  210 . An enrollment process for government-subsidized coverage may be launched at OPERATION  212 , and at OPERATION  214 , the patient&#39;s account may be cleared (for the financial triage process) to allow the patient to proceed to receive treatment. The process may end at OPERATION  298 . 
         [0028]    If the patient does not qualify for government-subsidized coverage at OPERATION  208 , determining if a patient is eligible for charity may be performed at DECISION OPERATION  216 . Eligibility for charity may be determined utilizing various pieces of inbound information  102  such as demographic verification data  110 , coverage verification data  114 , credit report data  116 , income data  118 , family size data  120 , estimate data  124 , health care provider data  126 , service type/department data  128 , etc. Using inbound information  102 , the patient may be screened for qualifications for one or more charities at OPERATION  218 . If the patient qualifies for charity care, documentation of qualification may be performed at OPERATION  220 , and at OPERATION  222 , the patient&#39;s account may be cleared (for the financial triage process) to allow the patient to proceed to receive treatment. The process may end at OPERATION  298 . 
         [0029]    If the patient does not qualify for charity, determining the patient&#39;s ability to pay may be performed at DECISION OPERATION  224 . Determining a patient&#39;s ability to pay may include both verifying the patient&#39;s ability and propensity to pay (OPERATION  226 ). This determination may be made utilizing various pieces of inbound information  102  such as demographic verification data  110 , coverage verification data  114 , credit report data  116 , income data  118 , family size data  120 , payment history data  122 , estimate data  124 , health care provider data  126 , service type/department data  128 , etc. If a determination is made that the patient is able to pay and is likely to pay, a payment plan or third party financing terms may be set up at OPERATION  228 . At OPERATION  230 , the patient&#39;s account may be cleared (for the financial triage process) to allow the patient to proceed to receive treatment. 
         [0030]    If a determination is made that the patient is not able to pay and/or does not have a propensity to pay, the process  200  may proceed to DECISION OPERATION  232 , where a determination is made as to whether the patient qualifies for financing. If the patient does not qualify for financing (e.g., the patient&#39;s propensity to pay  138  is determined to be below a predetermined threshold), payment for health care services may be required (prior to services being rendered) at OPERATION  234 . Once payment is received, at OPERATION  236 , the patient&#39;s account may be cleared (for the financial triage process) to allow the patient to proceed to receive treatment. The process may end at OPERATION  298 . 
         [0031]    As described above, embodiments of the invention may be implemented via local and remote computing and data storage systems. Such memory storage and processing units may be implemented in a computing device, such as computing device  300  of  FIG. 3 . Any suitable combination of hardware, software, or firmware may be used to implement the memory storage and processing unit  302 . For example, the memory storage and processing unit may be implemented with computing device  300  or any other computing devices  318 , in combination with computing device  300 , wherein functionality may be brought together over a network in a distributed computing environment, for example, an intranet or the Internet, to perform the functions as described herein. Such systems, devices, and processors (as described herein) are examples and other systems, devices, and processors may comprise the aforementioned memory storage and processing unit, consistent with embodiments of the invention. 
         [0032]    With reference to  FIG. 3 , a system consistent with embodiments of the invention may include one or more computing devices, such as computing device  300 . The computing device  300  may include at least one processing unit  302  and a system memory  304 . The system memory  304  may comprise, but is not limited to, volatile (e.g. random access memory (RAM)), non-volatile (e.g. read-only memory (ROM)), flash memory, or any combination. System memory  304  may include operating system  305 , one or more programming modules  306 , and may include the financial clearance engine  104 , wherein financial clearance engine  104  is a software application having sufficient computer-executable instructions, which when executed, performs functionalities as described herein. Operating system  305 , for example, may be suitable for controlling computing device  300 &#39;s operation. Furthermore, embodiments of the invention may be practiced in conjunction with a graphics library, other operating systems, or any other application program and is not limited to any particular application or system. This basic configuration is illustrated in  FIG. 3  by those components within a dashed line  308 . 
         [0033]    Although embodiments of the present invention have been described as being associated with data stored in memory and other storage mediums, data can also be stored on or read from other types of computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or a CD-ROM, or other forms of RAM or ROM. Further, the disclosed methods&#39; stages may be modified in any manner, including by reordering stages and/or inserting or deleting stages, without departing from the invention. 
         [0034]    The computing device  300  may also have one or more input device(s)  312  such as a keyboard, a mouse, a pen, a sound input device, a touch input device, etc. The output device(s)  314  such as a display, speakers, a printer, etc. may also be included. The aforementioned devices are examples and others may be used. The computing device  300  may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in  FIG. 3  by a removable storage  309  and a non-removable storage  310 . Computing device  300  may also contain a communication connection  316  that may allow device  300  to communicate with other computing devices  318 , such as over a network in a distributed computing environment, for example, an intranet or the Internet. Communication connection  316  is one example of communication media. 
         [0035]    Program modules, such as the financial clearance engine  104 , may include routines, programs, components, data structures, and other types of structures that may perform particular tasks or that may implement particular abstract data types. Moreover, embodiments of the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable user electronics, minicomputers, mainframe computers, and the like. Embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. 
         [0036]    Furthermore, embodiments of the invention may be practiced in an electrical circuit comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic elements or microprocessors. Embodiments of the invention may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, including but not limited to mechanical, optical, fluidic, and quantum technologies. In addition, embodiments of the invention may be practiced within a general purpose computer or in any other circuits or systems. 
         [0037]    Embodiments of the invention, for example, may be implemented as a computer process (method), a computing system, or as an article of manufacture (computer readable media). The computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process. Accordingly, the present invention may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.). In other words, embodiments of the present invention may take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system. 
         [0038]    Embodiments of the present invention, for example, are described above with reference to block diagrams and/or operational illustrations of methods, systems, and computer program products according to embodiments of the invention. For example,  FIG. 1-3  and the described functions taking place with respect to each illustration may be considered steps in a process routine performed by one or more local or distributed computing systems. The functions/acts noted in the blocks may occur out of the order as shown in any flowchart. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. 
         [0039]    It will be apparent to those skilled in the art that various modifications or variations may be made in the present invention without departing from the scope or spirit of the invention. Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. 
         [0040]    While the specification includes examples, the invention&#39;s scope is indicated by the following claims. Furthermore, while the specification has been described in language specific to structural features and/or methodological acts, the claims are not limited to the features or acts described above. Rather, the specific features and acts described above are disclosed as example for embodiments of the invention.