US10318923B1 - Payment assurance and claim pre-validation - Google Patents

Abstract

Methods and systems for payment assurance and claim pre-validation are described. In one embodiment, a pre-visit claim for health care related services is received for payment assurance. In response to the pre-visit claim, a payer is queried for pre-visit claim detail information indicating any payment or authorization issues for services to be rendered. The pre-visit claim may be updated in certain embodiments based on the pre-visit claim detail information, and an appointment may be scheduled for services. In other aspects, a claim for health care related services is received for pre-validation. In response, a payer is queried for claim detail information indicating any payment or authorization issues for the claim. The claim may be updated in certain embodiments based on the claim detail information, and payment for services rendered may be provided by a payer in response to a submitted claim.

Description

BACKGROUND

In today's healthcare delivery model, an industry gap exists between payers, the organizers of benefit and payment systems, providers, responsible for the hands on delivery of care, and patients. Although certain aspects of the healthcare delivery model have been improved, further improvements are needed in the areas of electronic exchange of eligibility, claims submissions, claims status inquiries, and payment remittance. Further new technology systems providing efficient, systematic, and streamlined processes that provide a foundation for emerging business and technology trends must be further developed.

The industry has focused on processing pre-care eligibility inquiries from health care providers, post-care claims submissions, inquiries, responses, and financial transactions such as claim submission and tracking, payment remittance advices, and patient statements. Real time transaction processing is supported for only certain processes such as eligibility inquiries, for example. A need for additional real time transaction processing in the areas of payment assurance, referrals, patient health care itineraries, and care management between payers and providers is needed. Presently, most transactions between providers, clearinghouses, and payers are conducted via batch processing systems, resulting in responses to providers often measured in days.

In this context, there is a need for new systems providing efficient, real time, streamlined processes in connection with payment assurance and claim pre-validation in the healthcare field.

SUMMARY

In one embodiment, a method of payment assurance and claim pre-validation is described. The method includes receiving a pre-visit claim for health care related services. In certain aspects, the pre-visit claim includes patient information and provider information. In response to the pre-visit claim, the method may include querying a payer for pre-visit claim detail information and receiving the pre-visit claim detail information from the payer. In certain aspects, the pre-visit claim detail information includes indicators of payment or authorization issues. The method may further include receiving a confirmation of an appointment for the health care related services and, in advance of the appointment, communicating updates to the payment or authorization issues. After the appointment, the method may include submitting a claim for the health care related services administered during the appointment.

In certain aspects and embodiments, a method of claim pre-validation includes submitting a claim for health care related services includes pre-validating a claim by querying a payer for authorization of each lineitem of services rendered and, in response to the query of each lineitem, receiving pre-validation claim detail information from the payer. Revisions to the claim may be received based on the pre-validation claim detail information, and submitting a claim may further include submitting a revised claim for health care related services. The pre-validation claim detail information may include an indicator of any lineitem errors or authorization issues associated with the submission of the claim.

In other aspects and embodiments, a method of payment assurance includes receiving a preliminary schedule of services including services to be rendered, service codes for the services, and payer covered costs for the services, based on terms of a health care related insurance agreement. The service codes for the services and payer covered costs for the services may serve as a basis for a mock claim, for example. The method may further include receiving clinical information regarding a patient, the clinical information including medical conditions of the patient, a care history of the patient, and health care related programs available to the patient. The method may further include receiving referral incentive information for a patient associated with the patient information, the referral incentive information indicating cost differences between preferred and non-preferred specialists.

In another embodiment, a method of payment and claim validation is described. The method includes receiving a claim for health care related services. In certain aspects, the claim includes patient information and provider information. In response to the claim, the method may include querying a payer for claim detail information and receiving the claim detail information from the payer. Revisions to the claim may be received based on the claim detail information, and a revised claim may be submitted for health care related services. The claim detail information may include an indicator of any lineitem errors or authorization issues associated with the submission of the claim.

In another embodiment, a system for payment assurance and claim pre-validation is described. The system includes an assurance network and a computer, for example. The computer, in certain aspects, is configured to receive a pre-visit claim for health care related services and, in response to the pre-visit claim, query a payer for pre-visit claim detail information. The computer may also be configured to receive the pre-visit claim detail information including indicators of payment or authorization issues from the payer. After forwarding the pre-visit claim detail information to a provider, the computer is further configured to receive a confirmation of an appointment for the health care related services and communicate updates to the payment or authorization issues in advance of the appointment. After the appointment, the computer is further configured to submit a claim for the health care related services administered during the appointment.

These and other aspects, objects, features, and embodiments will become apparent to a person of ordinary skill in the art upon consideration of the following detailed description of illustrative embodiments exemplifying the best mode as presently perceived.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the embodiments described herein, reference is made to the following description, in conjunction with the accompanying figures briefly described as follows:

FIG. 1 illustrates an example organizational diagram of a system including certain elements of and parties to an assurance network;

FIG. 2 illustrates an example general purpose computer according to certain aspects and embodiments described herein;

FIG. 3 illustrates an example process of payment assurance and claim adjudication according to certain aspects and embodiments described herein;

FIG. 4 further illustrates the example process of payment assurance and claim adjudication;

FIG. 5 illustrates an example process of pre-validation and claim submission according to certain aspects and embodiments described herein;

FIG. 6 illustrates an example flow diagram of real time payment assurance and claim editing;

FIG. 7 illustrates an example interface for real time payment assurance;

FIG. 8 further illustrates an example interface for real time payment assurance;

FIG. 9 further illustrates an example interface for real time payment assurance;

FIG. 10 illustrates an example interface for editing a pre-visit claim;

FIG. 11 illustrates an example estimate of costs for a pre-visit claim;

FIG. 12 illustrates an example interface for providing updates to pre-visit claim detail information;

FIG. 13 illustrates an example interface for payment assurance or claim pre-validation;

FIG. 14 illustrates an example interface for claim pre-validation and submission;

FIG. 15 illustrates another example interface for claim pre-validation and submission; and

FIG. 16 illustrates another example interface for claim pre-validation and submission.

The drawings illustrate only example embodiments and are not to be considered limiting, as other equally effective embodiments are within the scope and spirit of this disclosure.

DETAILED DESCRIPTION

In the following paragraphs, embodiments are described in further detail by way of example with reference to the attached drawings. In the description, well known components, methods, and/or processing techniques are omitted or briefly described so as not to obscure certain aspects of the various embodiments. Among the embodiments, some aspects and features are implemented by a computer program executed by one or more processors, as described and illustrated. As would be apparent to one having ordinary skill in the art, the embodiments described herein may be implemented, at least in part, by computer-readable instructions in various forms, and the various embodiments are not intended to be limiting to a particular set or sequence of instructions executed by a processor.

Generally, the embodiments described herein are related to a logical fabric of interoperable elements, referred to as an assurance network, that facilitates and promotes effective exchange of information among various constituents in the healthcare supply chain. The healthcare system is comprised of a diverse group of constituents, not limited to insurance and health plans, health care providers such as individuals and institutions specializing in the hands-on delivery of care including Accountable Care Organizations (ACOs) and Patient-Centered Medical Homes (PCMHs), provider surrogates such as facility administrators, care coordinators, and registration/front desk personnel, individuals as members of health plans, patients of providers, surrogates/delegates for other individuals, potential members of a health plan, and potential patients of a provider, employer groups, brokers, healthcare information exchanges, and healthcare insurance exchanges. Each of these constituents or entities interacts with each other and has an ongoing need to exchange and share financial, administrative, clinical, and educational information in transactional and health/wellness contexts.

Today, this exchange of information is difficult and fragmented, resulting in wasted resources. In an effort to address those problems, a key characteristic of the assurance network according to embodiments described herein includes supporting communication among all entities of the healthcare supply chain, sometimes in substantially real time.

Turning to the drawings, in which like numerals indicate like, but not necessarily the same, elements throughout, exemplary embodiments are described in detail.FIG. 1 illustrates an organizational diagram of asystem100 including certain elements of and parties to anassurance network110. At the outset, it is noted that not all elements of thesystem100 are required in every embodiment. In other words, one or more of the network elements may be omitted or replaced without departing from the spirit and scope of the embodiments.

Increased operational acuity, efficiencies, and revenue may be achieved, for example, according to a strategy of connecting payers and providers via theassurance network110, by offering payment assurance, claim pre-validation, transparency of payment, claims management, referrals, patient health care itineraries, and care management. According to the embodiments described herein, theassurance network110 processes a high volume of transactions in substantially real time and provides payment assurance and claim pre-validation answers, for example, among other information. Theassurance network110 may also provide referrals, patient health care itineraries, and care management between payers and providers, for example, as described in further detail below.

Theassurance network110 is a physical computing and communication network across which financial, administrative, clinical, and awareness information flows, with revenue generated by a combination of endpoint connection fees, subscription fees, and traffic fees, for example, in various embodiments. In this context, theassurance network110 provides a connection point for payers and providers, with the deepest, most assimilated, or integrated connection achieved by “core” assurance network system elements. Here, “core” elements comprise elements designed for deep levels of integration (i.e., seamless operation) in theassurance network110. In other words, for example, core elements are designed to communicate with theassurance network110 according to the syntax, protocols, application and software interfaces, and requirements of theassurance network110, without translation.

It is noted that, in certain aspects, core network elements may be capable of achieving functions that are unavailable to non-core network elements, primarily due to the level of integration achieved by core network elements. In certain aspects, non-core network elements achieve the same (or nearly the same) functions as their core network element counterparts, although via alternative or supplemental means and methods.

As illustrated inFIG. 1, thesystem100 includes a subscribingpayer112, a participatingpayer114, anon-participating payer116, astandard provider interface142, acustom provider interface144, and a cloud/web provider interface146. Theassurance network110 is configured to exchange real time financial, administrative, and clinical information between thepayers112,114, and116, and theproviders142,144, and146. In the context of the healthcare supply chain, thepayers112,114, and116 include computing systems or devices of health care related insurance coverage providers such as health maintenance organization (HMO) and preferred provider organization (PPO) insurance plans, for example, without limitation. Thepayers112,114, and116 may be related to any health care related fields such as medical, dental, and vision fields among others. Theproviders142,144, and146 may include computing systems or devices of health care related providers such as physicians, clinics, hospitals, pharmacies, provider surrogates, and care coordinators, for example, without limitation.

Thesystem100 further includes anassurance server120. Theassurance server120 is an integral element in thesystem100 and is configured to coordinate the exchange of real time financial, administrative, and clinical information between thepayers112,114, and116, and theproviders142,144, and146. As discussed in further detail below, theassurance server120 includes adatabase124 that stores, among other data, software for execution on theassurance server120. Thedatabase124 also stores data provided from thepayers112,114, and116, which may be provided in the form of periodic updates regarding terms and rules of services and coverage provided by thepayers112,114, and116. In certain embodiments, theassurance server120 includes a cloud orweb interface122 to provide access to theassurance network110 by clients using web browsers, for example, among similar applications.

Theassurance server120 comprises several modules or layers in various embodiments. In certain embodiments, theserver120 includes a security module configured to determine whether a third party is allowed to connect to services. The security module is also configured to determine the paths that a connecting third party is allowed to take. For example, the security module may only allow theclearinghouse networks160 and162 to take a path to certain payers or providers. Theserver120 may also include a translator layer (similar to or overlapping with thetranslators126,127, or128) configured to accept communications and data exchanges from select third parties and translate the data exchanges into a standard form. Similarly, the security module also operates on outbound communications and data exchanges.

Theassurance server120 may further include a services module configured to maintain and process logic for real time functions, such as payment assurance, claims submission, eligibility, and claims status inquiries, for example. In certain embodiments, theassurance server120 may include a rules module that contains business rules of payers. These rules are generally of the form of a data validation check, ensuring the proper data is being sent to the payer system. Theassurance server120 may also include a monitoring and management module configured to monitor the health of theassurance network110, as well as log and report data across the services provided by theassurance network110. For example, the monitoring and management module may be configured to track transactions from network input to network output and report performance statistics and issues along the way.

With regard to the subscribingpayer112, the participatingpayer114, and thenon-participating payer116, it is noted that the subscribingpayer112 is a core network element offering a high level of integration in theassurance network110. Such a high level of integration may be attributable, for example, to specialized software, application interfaces, and software and network protocols operating and executing on the computing systems of the subscribingpayer112. In other words, for example, the subscribingpayer112 is configured to comply with the application interfaces and network protocols of theassurance network110 and theassurance server120 in thesystem100. The subscribingpayer112 may include one or more computing systems directed by the execution of software to perform functions according to the embodiments described herein.

As compared to the subscribingpayer112, the participatingpayer114 may be considered a non-core network element. That is, as compared to the subscribingpayer112, the participatingpayer114 may offer a lower level of integration in theassurance network110. This lower level of integration may be attributable, for example, to software executing on the computing systems of the participatingpayer114 that, while performing similar overall processes (and for a similar purpose) as the subscribingpayer112, does not strictly comply with the application interfaces and network protocols and requirements of theassurance network110. As described in further detail below, by reliance on thetranslator126 and through terms of agreements, for example, the participatingpayer114 can attain substantially the same functional levels of payment assurance, claim pre-validation, referrals, patient health care itineraries, and care management available to the subscribingpayer112. The participatingpayer114 may include one or more computing systems directed by the execution of software to perform functions according to the embodiments described herein.

Thenon-participating payer116 may also be considered a non-core network element. Thus, thenon-participating payer116 may offer a lower level of integration in theassurance network110. This lower level of integration may be attributable to the software executing on the computing systems of thenon-participating payer116 that does not comply with the application interfaces and network protocols and requirements of theassurance network110. However, through terms of agreements, for example, thenon-participating payer116 can attain some level of payment assurance, claim pre-validation, referrals, patient health care itineraries, and care management available to the subscribing and participatingpayers112 and114. For example, thenon-participating payer116 can provide periodic updates of financial and administrative data to theassurance server120 for the purpose of providing an accurate estimate of patient liability, both prior to and at the point of service. In addition, based on known adjudication practices of thenon-participating payer116, theassurance server120 can seek to accurately prepare and submit claims for reimbursement.

Thetranslators126,127, and128 are configured to translate the syntax, protocols, and interfaces of non-core network elements to comply with the standards of theassurance network110. In various embodiments, thetranslators126 and127 comprise hardware and/or software modules and may be integrated at a payer (e.g., the payer114), at theassurance server120, or a combination of both. In general, thetranslators126,127, and128 may be relied upon to facilitate the migration of non-core payers and participants into theassurance network110. In certain embodiments, as discussed herein, thetranslators126,127, and128 can be used to substantially achieve integration of non-core network elements into theassurance network110, so that they appear to be core network elements.

In certain embodiments, thetranslators126,127, and128 are configured to acceptstandard assurance network110 request messages from providers and format them into requests that directly access payer systems using existing integration layers. Thetranslators126,127, and128 are further configured to format the resulting data payload into astandard assurance network110 message for communication back to the provider. This approach allows rapid integration into foreign systems. In this manner, translators can be deployed to any participating payer to provide reliable, consistent, communications with theassurance network110. Thetranslators126,127, and128, utilize existing integration layers or directly access exposed web services to the extent possible, rather than rely on an intervening products that introduce an added layer of complexity.

With regard to thestandard provider interface142, thecustom provider interface144, and the cloud/web provider interface146, these interfaces may be provided by practice management system (PMS) computing devices, for example. Here, thestandard provider interface142 is a core network element, offering a high level of integration in theassurance network110. The high level of integration may be attributable, for example, to specialized software, application interfaces, and software and network protocols operating and executing on the computing systems of thestandard provider interface142. In other words, thestandard provider interface142 is configured to comply with the application interfaces and network protocols of theassurance network110 and theassurance server120 in thesystem100. Thestandard provider interface142 may include one or more computing systems directed by the execution of software to perform functions according to the embodiments described herein.

As compared to thestandard provider interface142, thecustom provider interface144 may be considered a non-core network element. That is, as compared to thestandard provider interface142, thecustom provider interface144 may offer a lower level of integration in theassurance network110. This lower level of integration may be attributable, for example, to software executing on the computing systems of thecustom provider interface144 that, while performing similar overall processes (and for a similar purpose) as thestandard provider interface142, does not strictly comply with the application interfaces and network protocols and requirements of theassurance network110. However, by reliance on thetranslator127 and through terms of agreements, for example, thecustom provider interface144 can attain substantially the same functional levels of payment assurance, claim pre-validation, referrals, patient health care itineraries, and care management available to thestandard provider interface142. Thecustom provider interface144 may include one or more computing systems directed by the execution of software to perform functions according to the embodiments described herein.

The cloud/web provider interface146 is a provider interface that is available via a web browser of a client computing system of the provider. The cloud orweb interface122 of theassurance server120 may be accessed by the cloud/web provider interface146 to provide access to theassurance network110 by clients using web browsers, for example. Generally, in various aspects and embodiments, the same functions and features of theassurance network110 that are available to thestandard provider interface142 and thecustom provider interface144 are available via the cloud/web provider interface146. Providers that rely on the cloud/web provider interface146 may be without an integrated PMS or may use a PMS that is not capable of interfacing directly with theassurance network110. These providers will utilize the cloud orweb interface122 to enter and receive financial, administrative, and clinical information. Alternatively, these providers may send a consolidated file of multiple requests to theassurance network110.

It is noted that thesystem100 is configured to permit any of thepayers112,114, and116 to communicate with any of theproviders142,144, and146 for real time payment assurance, claim pre-validation, transparency of payment, claims management, referrals, patient health care itineraries, and care management. Depending upon the level of integration among them, such as for providers and payers using core network elements, substantially real time communications is available among them. Further, for providers and payers that interface with thetranslators126 and127, thesystem100 is configured to provide substantially real time communications. In certain aspects, theassurance network110 can be considered a health care related services payment or transaction clearinghouse network.

In certain aspects, communications via the assurance network110 (and the assurance server120) between thestandard provider interface142 and the subscribingpayer112, for which a deep level of integration between those core network elements is available, may result in the greatest amount of relevant information being communicated and exposed between them. Similarly, in certain aspects, communications via theassurance network110 between thecustom provider interface144 and the participatingpayer114, for which a lower level of integration between those core network elements is available, may result in less information being communicated and exposed between them. However, using thetranslators126 and127 in theassurance network110, levels of integration, communication, and relevant information exposure may be achieved between thecustom provider interface144 and the participatingpayer114 that is similar to the levels of integration achieved between thestandard provider interface142 and the subscribingpayer112.

Theclearinghouse networks160 and162 are communicatively coupled to other payers and providers. As needed, theclearinghouse networks160 and162 may route communications for payment assurance, claim pre-validation, and payment of claims, for example, over theassurance network110. In certain embodiments, a fee may be associated with routing and/or processing certain communications accepted from theclearinghouse networks160 and162. Similarly, fees may be associated with routing communications from theassurance network110 over theclearinghouse networks160 and162. As illustrated inFIG. 1, thetranslator128 is provided between theassurance network110 and theclearinghouse network162. In various embodiments, thetranslator128 comprises hardware and/or software modules and may be integrated as part of one of theclearinghouse networks160 and162, at theassurance server120, or a combination of both. In general, thetranslator128 may be relied upon to facilitate the assimilation of protocols between theclearinghouse networks160 and162 and theassurance network110. With the communicative coupling of theclearinghouse networks160 and162 and theassurance network110, thesystem100 is configured to permit thepayers112,114, and116 and theproviders142,144, and146 to communicate with payers and providers that would not otherwise be accessible, for example, for real time payment assurance, claim pre-validation, transparency of payment, claims management, referrals, patient health care itineraries, and care management.

With regard to the various levels of integration between the parties to and network elements of theassurance network110, various types and levels of exchanges may be provided. For example, for exchanges between providers and payers that utilize core network elements and allow a high level integration into their systems, theassurance network110 supports real time (or substantial real time) adjudication. For exchanges between providers and supported payers that do not actively participate in the real time exchange but provide periodic updates to a range of available data stores (including but not limited to eligibility, claims status, “limits” calculations, and deductible status), theassurance server120 stores this information in thedatabase124 to provide responses to provider inquiries and to estimate claims. For exchanges between providers and unsupported payers that do not actively participate in the exchange of information beyond providing basic eligibility, a third party claims pricing engine or similar technology may be employed to estimate claims adjudication results and patient liability amounts.

As described in further detail below, as thesystem100 is configured to facilitate communications, transactions, and exchanges between payers and providers for real time payment assurance and claim pre-validation, for example, the differences between real time adjudication, synthetic adjudication, and mock adjudication for payment assurance and claim pre-validation should be appreciated. Theassurance network110 permits mock adjudication by executing claim adjudication on a “mock” basis to deliver an adjudication quality result without actually processing the claim (i.e., the claim is “pre-validated”). Synthetic adjudication is a process for exchanges with non-core or non-participating payers (e.g., payers that do not allow real time connectivity between their computing systems and the assurance network110). In synthetic adjudication, payers can expose theassurance server120 with a range of eligibility and claims adjudication information for storage in thedatabase124, to support provider activities before and through care delivery. The most effective synthetic adjudication arrangements would require payers to provide daily eligibility downloads. This information may include current costs for deductibles, out of pocket limits, etc.,—which in combination with any exposed claims adjudication rules and assurance network “learned” rules, would provide the most accurate synthetic adjudication of a claim possible. The assurance network “learned” rules may be dynamically garnered from previous claims submissions and results learned through heuristics and analysis of actual payer-specific behaviors (e.g., payer A always rejects “strep culture” under a “wellness visit”, but not when a presenting medical diagnosis is indicative of a potential presence of infection).

Turning toFIG. 2, an example hardware diagram of ageneral purpose computer200 is illustrated. Any of the computing devices described in connection withFIG. 1 may be implements using one or more elements of thegeneral purpose computer200, as would be readily understood by one having skill in the art. Thecomputer200 includes aprocessor210, a Random Access Memory (RAM)220, a Read Only Memory (ROM)230, amemory device240, anetwork interface250, and an Input Output (I/O)interface260. The elements of thecomputer200 are communicatively coupled via a bus202.

In various embodiments, theprocessor210 comprises any well known general purpose arithmetic processor or Application Specific Integrated Circuit (“ASIC”). The RAM andROM220 and230 comprise any well known random access or read only memory device that stores computer-readable instructions to be executed by theprocessor210. Thememory device240 stores computer-readable instructions thereon that, when executed by theprocessor210, direct theprocessor210 to execute various aspects of the present invention described herein. When theprocessor210 comprises an ASIC, the processes described herein may be executed by the ASIC according to an embedded circuitry design of the ASIC, by firmware of the ASIC, or both an embedded circuitry design and firmware of the ASIC. As a non-limiting example group, thememory device240 comprises one or more of an optical disc, a magnetic disc, a semiconductor memory (i.e., a flash based memory), a magnetic tape memory, a removable memory, combinations thereof, or any other known memory means for storing computer-readable instructions. Thenetwork interface250 comprises hardware interfaces to communicate over data networks. The I/O interface260 comprises device input and output interfaces such as keyboard, pointing device, display, communication, and other interfaces. The bus202 electrically and communicatively couples theprocessor210, theRAM220, theROM230, thememory device240, thenetwork interface250, and the I/O interface260, so that data and instructions may be communicated among them.

In operation, theprocessor210 is configured to retrieve computer-readable instructions stored on thememory device240, theRAM220, theROM230, or another storage means, and copy the computer-readable instructions to theRAM220 or theROM230 for execution, for example. Theprocessor210 is further configured to execute the computer-readable instructions to implement various aspects and features of the present invention. For example, theprocessor210 may be adapted and configured to execute the processes described below with reference toFIGS. 3-5, including the processes described as being performed by theassurance network110 and theassurance server120.

Before turning to the process flow diagrams ofFIGS. 3-5, it is noted that embodiments described herein may be practiced using an alternative order of the steps illustrated inFIGS. 3-5. That is, the process flows illustrated inFIGS. 3-5 are provided as examples only, and the embodiments may be practiced using process flows that differ from those illustrated. Additionally, it is noted that not all steps are required in every embodiment. In other words, one or more of the steps may be omitted or replaced, without departing from the spirit and scope of the embodiments. Further, steps may be performed in different orders, in parallel with one another, or omitted entirely, and/or certain additional steps may be performed without departing from the scope and spirit of the embodiments.

Turning toFIG. 3, an example process ormethod300 of payment assurance and claim adjudication according to certain aspects and embodiments described herein is illustrated. While the process illustrated inFIG. 3 is described in connection with thesystem100 ofFIG. 1, the process is not limited to being performed by thesystem100. At step310, theassurance network110 and theassurance server120 receive a pre-visit claim for healthcare related service. In one example, the pre-visit claim includes patient information and provider information. Here, it is noted that, when a patient contacts a provider (e.g., physician's office) to schedule an appointment, front desk personnel of the provider may use an interface to thesystem100, such as one of theinterfaces142,144, or146, to create a pre-visit claim for healthcare related services. In certain aspects, this pre-visit claim is processed as a mock adjudication of the claim.

With reference toFIG. 6, step310 ofFIG. 3 falls under the real time payment assurance workflow, performed at appointment scheduling. The purpose of real time payment assurance is to identify payment issues before health care services are rendered, for both the patient and the provider. Specifically, the patient can be accurately advised of costs for the services before they are rendered (and even before the appointment is scheduled). The provider, similarly, will be advised of the patient's costs. The provider will also be advised of a patient's coverage under the patient's health care insurance plan for the services. Further, the patient can be advised of any conditions to benefits under the patient's health care insurance plan. For example, the patient may be advised that the services identified by the pre-visit claim are not covered benefits, are not covered benefits at the requesting provider's office (e.g., the provider is out of network), or that the services are not covered due to lack of evidence of prior coverage for a pre-existing condition. Alternatively, real time payment assurance can indicate that one or all of the services identified by the pre-visit claim are covered, by service lineitem or procedure code, for example. As discussed above, thesystem100 is configured to provide real time feedback for the payment assurance using a real time communications link between providers and payers via theassurance network110 and theassurance server120. As suggested inFIG. 6, a request for real time payment assurance may be performed by a provider, for example, before scheduling an appointment for a patient, when the patient checks in for the appointment, or when the patient checks out from the appointment.

Turning toFIG. 7, an example illustration of an interface for real time payment assurance is provided. The example interface illustrated inFIG. 7 may be provided by the cloud orweb interface122 of theassurance server120 to provide access by client interfaces using web browsers such as theinterface146. After navigating to the interface using a uniform resource locator (URL), for example, the provider is presented with an easy to follow user interface to enter information related to the patient and the services to be rendered to the patient, for real time payment assurance. Turning toFIG. 8, as illustrated, a provider may identify a patient's health care insurance plan and a particular physician to render services. Turning toFIG. 9, additional information is provided by the provider to obtain assurance for payment. As illustrated inFIG. 9, after entering health care insurance plan and physician information, patient information such as a patient's name, date of birth, gender, and healthcare subscriber ID, for example, may be provided at the interface. It is noted that the interfaces illustrated inFIGS. 7-9 are provided by way of example only. In other embodiments, additional or alternative entry fields for both patient and provider information may be incorporated into the interface.

Referring back toFIG. 3, at step320, in response to the pre-visit claim, theassurance server120 queries one or more payers for pre-visit claim detail information. Here, theassurance server120 queries one of thepayers112,114, or116, via theassurance network110, for example, based on the patient's health care plan insurance information. Here, in response to the query from theassurance server120, the payer accesses the relevant coverage data related to the patient and sends the relevant coverage data back to theassurance server120. It is noted that the query may include patient information, provider information, and a listing of services to be rendered by lineitem, for example, among other information. Using this information, the payer is configured to determine patient coverage for the services, patient costs (e.g., copays) for the services, and coverage allowances to be paid to the provider for the services. The payer is also configured to determine services that are not covered for any reason. The relevant coverage (and lack of coverage) information is transmitted back to theassurance server120 via theassurance network110.

Atstep330, theassurance server120 receives the pre-visit claim detail information from the payer. In various embodiments, the pre-visit claim detail information. This pre-visit claim detail information may include patient co-pay information and other indicators of payment or authorization issues as discussed herein. For example, payment authorization issues may be related to gaps in coverage, ineligible procedures, ineligible providers, ineligible combinations of procedures and providers, or other alerts which require attention. In certain embodiments, theassurance server120 may also receive a preliminary or modified schedule of services to be rendered, service codes for these services, and payer covered costs for these services, if the pre-visit claim identifies a general service to be rendered such as a wellness checkup. The information received from the payer is forwarded back to the interface of the provider for review. At this time, the provider may advise the patient of the patient's costs for the services along with any alerts or issues identified by the payer. Again, with this information provided to the provider in substantially real time, the provider may both advise the patient of patient costs and be apprised of any limitations on the patient's coverage. As such, real time transparency of coverage and costs is offered to both the patient and provider according to themethod300. The provider may make edits to the pre-visit claim iteratively, as discussed below, to address any alerts and issues. Because both the patient and the provider are provided with relevant coverage information in advance of any services being rendered, the coverage expectations of the patient and the provider can be clarified before the services are rendered. According to themethod300 described herein, the following example advantages (among others) are available and/or achieved: (1) early notice of payment issues; (2) adjudication quality information presented substantially real time to patients and providers; (3) feedback is integrated into current client interfaces of providers; (4) minimal changes to office workflow at the provider are required; (5) denials, appeals, and duplicate claims can be eliminated or greatly reduced; (6) patient collections at the point of service are increased and open receivables are decreased; and (7) a foundation for clinical collaboration is provided.

For additional context in connection withsteps310,320, and330, the example in this paragraph may be considered. Elizabeth, a front desk worker at a physician's office, schedules an annual exam visit for patient Susan Smith with Dr. Jones. As Elizabeth enters Susan's information and schedules a date for the appointment, a response from theassurance network110 and theassurance server120 indicates the following: (1) the service will be fully covered by Susan's health care insurance plan and Susan won't need to make a co-payment at the time of service; (2) Susan has been identified as a diabetic and has missed the following recommended services (XX, YY, ZZ); (3) Susan has not complied with her recommended insulin refill schedule; (4) Susan has been to the emergency room 3 times over the past 12 months; and (5) Susan is eligible to become part of a new Diabetic Management Program with her health plan and, if Dr. Jones completes the gapped services and convinces Susan to sign up for the program, he'll get a $100 bonus and Susan will receive incentive credits in the form of “healthcare dollars”.

Atstep340, the provider has the option to edit the pre-visit claim based on the pre-visit detail information received from theassurance network110 and theassurance server120. For example, the patient may decline certain services based on the coverage and cost information, and the provider may identify additional services to be performed based on a schedule of recommended services provided by the payer. If edits to the pre-visit claim are entered by the provider atstep340, the process proceeds to step345 where the pre-visit claim details are updated. The updated pre-visit claim details are returned to theassurance server120 for additional processing at step320. That is, as illustrated inFIG. 3, once the pre-visit claim details have been updated atstep345, the process returns again to step320 where theassurance server120 queries the payer for updated pre-visit claim detail information. Thus, the process of payment assurance and scheduling an appointment is iterative according to certain aspects of themethod300. This payment assurance for a pre-visit claim or mock adjudication of a pre-visit claim is facilitated by theassurance network110 and theassurance server120 of thesystem100, for example, as described above. Again, as illustrated inFIG. 6, it is noted that the iterative process for payment assurance may be applicable at scheduling, check-in, check-out, or at any other suitable point in the workflow.

Turning toFIG. 10, an example interface for editing a pre-visit claim is illustrated. InFIG. 10, health care related service information is provided at the interface, such as service date, service location, procedure codes, modifier codes, diagnostic codes, charges, and quantities, for editing. InFIG. 10, an example schedule of services is provided for a urinary tract infection. In various embodiments, the schedule of services may be set by the provider or provided by the payer in response to the provider's selection of “urinary tract infection” as a reason for the visit. In other words, the payer may provide substantially real time information regarding recommended schedules of services to be provided, depending upon the selected reason for the visit. As illustrated inFIG. 10, a request for payment assurance can take the form of a pre-visit claim and include a suggested schedule of services to be provided. InFIG. 10, a provider's ability to iteratively update or edit pre-visit claim information is illustrated, because several fields of the schedule of services may be edited by the provider. After the fields are updates, the provider may submit the information to theassurance network110 and theassurance server120. Turning toFIG. 11, a completed estimate of costs for the pre-visit claim is illustrated. Here, information such as charges, allowed costs, adjustments, deductibles, co-insurance payments, co-pays, and other information is available. The amount of provider costs and provider-paid costs is also illustrated along with the patient's costs. It is noted that the interfaces illustrated inFIGS. 10 and 11 are provided by way of example only. In other embodiments, additional or alternative entry fields for both patient and provider information may be incorporated into the interface.

Referring again toFIG. 3, theassurance server120 receives a confirmation of an appointment atstep350 after all updates and edits to the pre-visit claim have been entered and the patient is aware of the schedule of services to be rendered and the costs associated with those services, if any. Atstep360, between the time that the appointment is scheduled and the time of the appointment, theassurance server120 communicates updates to the pre-visit claim detail information to the provider. That is, if changes in a patient's coverage occur between the time that the appointment is scheduled and the time of the appointment, theassurance server120 communicates updated information to the provider. For example, if a payment alert was identified before scheduling the appointment, changed circumstances may render the alert unnecessary if the patient clears the alert by providing necessary information (e.g., proof of prior coverage) to the payer before the appointment. In this case, theassurance server120 would communicate updated information to the provider clearing the alert. Alternatively, if changed circumstances such as cancellation of coverage occurs, theassurance server120 would communicate updated information indicating that the patient's coverage has been cancelled. In response to such updated information, the provider may contact the patient to cancel or reschedule the appointment, if deemed necessary. In certain embodiments, theassurance server120 periodically queries payers for pending appointments, to determine whether changed circumstances have occurred.

Turning toFIG. 12, an example interface providing updates to pre-visit claim detail information is illustrated. As illustrated inFIG. 12, a list of appointments is provided along with alert information. As one example, an alert that coverage has been cancelled or terminated is provided by the interface. In response to such an alert, the provider may contact the patient to cancel or reschedule the appointment, if deemed necessary, unless further or alternative payment assurances or a suitable explanation is provided by the patient. As another example, an alert that a certain procedure code requires pre-authorization to mitigate a penalty is provided by the interface. This alert may have been presented to the patient and provider before the appointment was scheduled, or it may have been provided only as an update after the appointment was scheduled. Here, the updates assist the provider to identify payment issues before rendering services. In connection with the updates, other information consistent with the embodiments described herein may also be provided. For example, updated information regarding a patient's medical policy, gaps in care, care alerts, patient incentive eligibility, provider incentive eligibility, wellness/coaching recommendations, and other information may be provided. These updates are, in certain exemplary embodiments, integrated with the interfaces available to providers. Real time updates to risk assessment and stratification information for a patient may also be provided. Based on a known diagnosis for “diabetes mellitus,” for example, real time reassessments and updates of patient risk may be provided in connection with emerging/potential procedures identified by payers, including the identification of new care management opportunities.

Turning toFIG. 4, patient referral information is forwarded by theassurance network110 and theassurance server120 to the provider in certain embodiments at step400. For context, the following example is provided in connection with patient referral information. Dr. Jones recently joined a health plan's “Gold Star” program. As part of the program, he is provided incentives to keep his patients within the Gold Star network. Dr. Jones' patient, Tim Smith needs to see a specialist. When providing services and recommending a specialist, Dr. Jones explains why he prefers a certain specialist and prints a receipt for Tim that shows the differences in cost to see the Gold Star specialist vs. another specialist. Tim agrees to go to Gold Star specialist. Dr. Jones' office manager, Samantha, submits a real time referral request and sends patient records to Dr. Samoya with Tim's clinical history as well as a payment assurance for a consult visit. It is noted that, as with other steps, step400 may be omitted in certain embodiments. Alternatively, as with other steps, step400 may occur at another timing among the remaining steps in themethod300.

After the appointment, atstep410, the provider relies on theassurance network110 andassurance server120 to submit a claim for the services administered to the patent during the appointment. In certain cases, the claim is submitted based on the pre-visit claim detail information previously provided from the payer—sometimes saving time and effort. However, it is noted that the provider may rely on theassurance network110 andassurance server120 to submit a claim for services even if no pre-visit claim was prepared for the appointment. It is noted that, while the submission of a claim atstep410 includes characteristics similar to submission of a pre-visit claim, the primary difference is that the submission of a claim atstep410 occurs at a different timing in the workflow. With reference again toFIG. 6, submission of a claim atstep410 occurs after services have been rendered and is used to identify payment issues prior to submission of a claim for payment by a payer. Atstep420, based on the submission of the claim atstep410, payment is routed to the provided by the payer for the patient. Payment may be routed according to any known payment routing methods accepted in the industry.

Turning toFIG. 5, an example process or method500 for pre-validation and claim submission is illustrated. Atstep510, theassurance network110 and theassurance server120 receive claim details for pre-validation of a claim from a provider. Atstep520, theassurance server120 queries a payer for authorization of the services rendered during an appointment to satisfy the claim. In certain embodiments, the authorization is queried by each lineitem of the claim. It is noted that the payer for the claim is identified in the claim details. In response to the query, theassurance server120 receives pre-validation claim detail information from the payer atstep530. In certain embodiments consistent with the description provided herein, the pre-validation claim detail information may be provided for each lineitem of the claim. The pre-validation claim detail information received from the payer atstep530 is also forwarded back to an interface of the provider for review.

Atstep540, the provider has the option to edit the claim details based on the pre-validation claim detail information received from theassurance server120. For example, the provider may update procedure and/or diagnostic codes for certain services based on payment alerts in the pre-validation claim detail information. If edits to the claim details are entered by the provider atstep540, the process proceeds to step545 where the claim details are updated. The updated claim details are returned to theassurance server120 for additional processing atstep520. That is, as illustrated inFIG. 5, once the claim details have been updated atstep545, the process returns again to step520 where theassurance server120 queries the payer for updated claim detail information. Thus, the process of pre-validation of a claim is iterative according to certain aspects of the method500.

Turning toFIGS. 13-16, example interfaces for claim pre-validation and submission are illustrated. In certain aspects, the example interfaces for claim pre-validation inFIGS. 13-16 are similar to those for pre-visit claim assurance inFIGS. 7-11. However, it is noted that the interfaces illustrated inFIGS. 13-16 are examples of “integrated” interfaces, available at one of the standard orcustom interfaces142 or144, for example. Modifications to and/or combinations of any of the interfaces illustrated inFIGS. 7-11 orFIGS. 13-16 are within the scope and spirit of the embodiments described herein and may be provided by thesystem100 for pre-visit claim assurance or claim pre-validation.

InFIG. 13, an interface preparing a claim for pre-validation is illustrated. Patient and physician information is entered, for example, along with a reason for the visit in which services were rendered. InFIG. 14, an interface including a display of the pre-validation claim detail information is illustrated. Here, a provider is able to identify payment alerts based on the claim detail information submitted to theassurance network110 andassurance server120. Again, it is noted that this information is provided substantially real time to the provider. InFIG. 15, an interface including a display of pre-validation claim detail information and a provider's ability to edit the claim detail information is illustrated. InFIG. 16, an interface including an alternative display of pre-validation claim detail information is illustrated. In connection withFIG. 16, it is noted that a provider is able to update claim detail information based on the pre-validation claim detail information. For example, if the pre-validation claim detail information provides an alert that a certain screening or procedure is not allowed (i.e., will not be covered for payment), the provider is able to make corrections to the claim detail information accordingly. InFIG. 16, the pre-validation claim detail information provides an alert that a certain screening is not allowed for the patient “Jones, Sara,” because she is a female. After any updates to the claim details are finalized, the process500 proceeds to step550, where the claim is submitted to the payer via theassurance network110, and returns.

It should be appreciated that, where pre-visit assurance of a claim or pre-validation of a claim is requested in connection with a non-participating payer, such as thenon-participating payer116, theassurance server120 may query thedatabase124 instead of thenon-participating payer116 if thenon-participating payer116 has provided daily eligibility downloads for storage in thedatabase124, as described above. The eligibility information in thedatabase124 may include current costs for deductibles, out of pocket limits, etc.,—which, in combination with any exposed claims adjudication rules and assurance network “learned” rules, would provide a basis for theassurance server120 to forward pre-visit assurance or claim pre-validation detail information to providers in substantially real time, even though thenon-participating payer116 is not itself queried. This synthetic adjudication offers flexibility for providing payment feedback even for non-participating payers.

It should further be appreciated that the communications in themethods300 and500 between providers, theassurance network110 and theassurance server120, and payers may be subject to transformations of data syntax and protocol, for example, when necessary for better integration. As one example, themethod300 may include transforming a data format of a pre-visit claim into a standard format. Similarly, themethod300 may include transforming a standard format of pre-visit claim detail information into a format for a provider's client interface device.

While embodiments have been described herein in detail, the descriptions are by way of example. The features of the embodiments described herein are representative and, in alternative embodiments, certain features and elements may be added or omitted. Additionally, modifications to aspects of the embodiments described herein may be made by those skilled in the art without departing from the spirit and scope of the following claims, the scope of which are to be accorded the broadest interpretation so as to encompass modifications and equivalent structures.

Claims (7)

The invention claimed is:

1. An electronic exchange system for payment assurance and claim pre-validation, comprising:

an assurance network including an assurance server,

the assurance server further including;

standard network interfaces, configured to facilitate the following communications directly between the assurance server and subscribing providers and subscribing payers to the assurance network;

receive a pre-visit claim for health care related services from at least one subscribing provider,

in response to the pre-visit claim, query at least one subscribing payer for pre-visit claim detail information,

receive the pre-visit claim detail information from the at least one subscribing payer, the pre-visit claim detail information including indicators of one or more payment or authorization issues,

receive a confirmation of an appointment for the health care related services from the at least one subscribing provider,

in advance of the appointment, communicate updates to the payment or authorization issues from one or more of the at least one subscribing payers, and

after the appointment, submit a claim for the health care related services administered during the appointment to the subscribing payer for adjudication of the claim in real time; and

one or more translators for transforming data syntax and protocol and non-standard interfaces, configured to facilitate the following communications indirectly between the assurance server and at least one subscribing provider and at least one non-subscribing payer to the system;

receive a pre-visit claim for health care related services from a subscribing provider in a standard assurance network data format and translate by a translator the pre-visit claim into a non-standard assurance network data format,

in response to the pre-visit claim, query at least one non-subscribing payer with the non-standard assurance network data format pre-visit claim message for pre-visit claim detail information,

receive a pre-visit claim detail information from the at least one non-subscribing payer in the non-standard assurance network data format at the translator and translate the pre-visit claim information into the standard assurance network data format for the subscribing provider, the pre-visit claim detail information including indicators of payment or authorization issues,

receive a confirmation message of an appointment for the health care related services from the subscribing provider in the standard assurance network data format and translate by the translator the confirmation message into a non-standard assurance network data format for the at least one non-subscribing payer,

in advance of the appointment, communicate updates to the payment or authorization issues from the at least one non-subscribing payer to the subscribing provider, wherein the translator translates the at least one non-subscribing payers updates message from the non-standard assurance network data format to the standard assurance network data format for the subscribing provider, and

after the appointment, receive a claim for the health care related services administered during the appointment and synthetically adjudicate the claim by the assurance network based on non-real time eligibility and adjudication data provided to the assurance network by the non-subscribing payer.

2. The system ofclaim 1, wherein the assurance server is further configured to

query the non-subscribing payer for authorization of each line item of services rendered during the appointment, wherein a query to a non-subscribing payer is presented in the non-standard assurance network data format via the translator,

in response to the query of each line item, receive pre-validation claim detail information from the non-subscribing payer, wherein the pre-validation claim detail information from the non-subscribing payer is presented to the subscribing provider in the standard assurance network data format via the translator,

receive revisions to the claim based on the pre-validation claim detail information from the subscribing provider at the translator and translate revised claim to the non-standard assurance network data format, and

synthetically adjudicate the claim by the assurance network based on non-real time eligibility and adjudication data provided to the assurance network by the non-subscribing payer.

3. The system ofclaim 2, wherein the pre-validation claim detail information includes an indicator of any line item errors or authorization issues associated with the submission of the claim.

4. The system ofclaim 2, wherein the assurance server is further configured to

receive at a database thereof the non-real time eligibility and adjudication data, from the non-subscribing payer, including a preliminary schedule of services including services to be rendered, service codes for the services, and non-subscribing payer covered costs for the services, based on terms of a health care related insurance agreement, the service codes for the services and non-subscribing payer covered costs for the services serving as a basis for a mock claim.

5. The system ofclaim 2, wherein the assurance server is further configured to

receive, from the non-subscribing payer, clinical information regarding a patient associated with the pre-visit claim for health related services, the clinical information including medical conditions of the patient, a care history of the patient, and health care related programs available to the patient.

6. The system according toclaim 4, wherein the non-subscribing payer provides the non-real time eligibility and adjudication data on a daily basis.

7. The system according toclaim 2, wherein the assurance server is configured to derive additional non-subscriber eligibility data from previous claim submissions and to apply this additional non-subscriber eligibility data during synthetic adjudication.

Images