Proactive matching for coordination of benefits

Proactive resolution of coordination of benefits (COB) issues is provided. Payer data is received as membership files from a plurality of payers, the payer data including eligibility and member demographic data. Upon detection of new or modified information, a normalizing engine may be utilized to normalize name information, address information, and social security number information into a format for comparing with other stored payer data according to various rules. A matching engine may be utilized to compare the normalized payer data against other insurance provider data to determine COB instances by discovering matches or partial-matches of member information. A set of rules may be applied to determine a primary versus a secondary payer. An output file, which may comprise matches and COB determinations, raw data, and a web interface for accessing archived reports and files and to generate individual member searches, may be provided to one or more payers.

BACKGROUND

Coordination of benefits (COB) is a method used to determine which insurance company (i.e., payer) is primarily responsible for payment when an individual is covered under more than one insurance plan. COB may also be used to help ensure that an insurance claim is not paid multiple times, for example, by multiple payers, when an individual is insured under multiple insurance plans. In healthcare, individuals may be covered by multiple insurance plans, for example, when two partners both receive healthcare benefits through their jobs, and their benefits are expanded to their spouses or domestic partners, and to their children if dependents are automatically covered. As a result, each partner (and children if applicable) may be covered by two health insurance plans.

Oftentimes, there may be guidelines that regulate how claims are processed relative to multiple coverages. For example, if a married couple is covered by two health insurance plans, the husband's insurance plan may be primary coverage for him, while his spouse's insurance plan may be primary coverage for her. However, if one person has insurance coverage through a government-subsidized payer (e.g., Medicaid or Veterans Affairs (VA)) and the spouse has insurance coverage through an employer, then the spouse's insurance coverage through the employer may be primary coverage for both. As another example, typically, if a child is covered by both parents' health insurance plans, a “birthday rule” may be user, wherein the health insurance provider (i.e., payer) of the parent whose birthday falls first in a calendar year may be determined to be the primary health insurance provider of the child. As can be appreciated, there may be exceptions to the “birthday rule,” as well as other rules for determining primary coverage.

Currently, if an individual receives a healthcare service from a healthcare service provider, and the individual has multiple coverages (i.e., is covered under more than one health insurance plan), the healthcare provider may not know which health insurance plan carrier (i.e., payer) is primary or secondary and to which payer a claim should be filed. Consider, for example, a child who is covered under two different healthcare insurance policies is injured and goes to a hospital for treatment. One policy may be under his mother and the other one may be under his father. Even if both parents are present and they both have their insurance cards, the hospital may not know to which insurance company to submit the claim. In many cases, the healthcare provider may submit a claim to both payers. Most of the time, one of the insurance companies (i.e., payers) may pay. In some instances both the insurance companies may pay, which can lead to wasted administrative and accounting work and costs. For example, one payer may later determine they are secondary and may request to be reimbursed for the payment made. In other cases, neither payer may pay, both denying the claims until they receive a document that says the individual does not have a COB instance (i.e., the individual does not have multiple health insurance coverages).

Current COB methods may cause administration challenges that can add cost and increased workloads to departments within an insurer's operation. For example, current COB methods may cause service workarounds, claim delays, rework, phone calls, recovery fees, and administrative costs in a search for which individuals may have duplicate coverage and for which payer may be primary and which payer may be secondary. It is with respect to these and other considerations that the present invention has been made.

SUMMARY

Embodiments of the present invention provide for proactively resolving coordination of benefits (COB) issues by maintaining a database of membership data, utilizing stored data for determining matches, determining primacy, and providing output to insurance providers. Embodiments may be utilized to help eliminate wasted administrative costs, avoid claim overpayment risks, and reduce hassles and costs for providers and members.

DETAILED DESCRIPTION

Embodiments provide a central repository for proactively resolving coordination of benefits (COB) issues. Embodiments may be utilized to help eliminate wasted administrative costs, avoid claim overpayment risks, and reduce hassles and costs for providers and members. Embodiments provide for receiving payer data from a plurality of payers, identifying COB instances via a data matching service, applying a set of rules for determining a primary versus a secondary payer, and providing output which may comprise matches and COB determination, raw data, and a web interface for accessing archived reports and files, and to generate individual member searches.

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.

As described above, COB is a method utilized to ensure that an insurance claim is not paid multiple times when an individual is covered under multiple insurance plans. There may be various situations in which an individual may be covered by multiple insurers (e.g., working spouses, both with insurance; divorced couples with historic shared coverage; employees with Medicare and corporate insurance, etc.). For example, spouses may each receive healthcare benefits through their jobs and their healthcare benefits may be expanded to also cover the spouse, resulting in each partner being covered by two health insurance plans. Additionally, this may extend to children having multiple coverages. Under COB, one payer may be designated as the primary payer, and the other payer may be designated as the secondary payer. If a primary payer refuses to pay a claim or does not pay a claim in full, the claim may be passed to the secondary payer to pay.

Currently, insurance payers may use various methods to control their costs of COB. One method is a pay and chase philosophy. For example, a claim may be received, and the payer may pay the claim without performing a COB. This may benefit the healthcare provider receiving the payment because the healthcare provider is receiving cash-flow; however, the payer may later determine they should not have paid for a particular claim and may come back to the healthcare provider for reimbursement. This may be referred to as a pay and chase mechanism. In a situation where a healthcare provider submits a claim to two payers and both payers pays the claim, one of the payers may come back requesting a reimbursement.

Another method that insurance payers use may be to refuse payment if they think there may be a COB instance if they do not have a record on an individual, for example, a file document that says there is not a COB instance. Consequently, a healthcare provider may receive a denial to the claim and may have to figure out why the claim was denied. If the healthcare provider discovers that it is a legitimate denial, for example, that payer A really is not primary and should not pay first, the healthcare provider may then have to submit a claim to payer B, and resubmit a new claim to payer A, which may include the amount not covered by payer B. As can be appreciated, this can be a very complicated process.

Embodiments provide for a proactive matching for COB. Referring now toFIG. 1, a simplified block diagram of a high-level system architecture with which embodiments of the invention may be implemented100is shown. As illustrated, payer data104may be received from a plurality of healthcare insurance payers102. Payer data104may be pushed to an intermediary system116by one or more payers102, pulled by the intermediary system116, and may be received in real time or according to a predetermined frequency (e.g., weekly, monthly, quarterly, etc.). The payer data104may be a membership file which may include eligibility and member demographic data such information as, but is not limited to, a member's name, phone number(s), social security number, driver license number, birth date, gender, address, member identification number, plan name, plan type, insured's name, dates of coverage, marital status, employment status, policy holder's information, custodial parent information, etc. According to embodiments, when payer data104is received, the data may be analyzed and loaded into a repository106.

The system100may include an intermediary system116, which may act as a data aggregator of membership data from one or more payers102. The intermediary system116is illustrative of a business or other entity that may include a collection of computers, storage media, or other computing devices operative to receive and normalize payer data104and to compare and match the data for a proactive coordination of benefits process.

According to embodiments, the intermediary system116may comprise a normalizing engine108operable to perform normalization of payer data104. According to embodiments, normalization may be performed to help improve matching (as will be described below) without undermining integrity of results. Various rules112may be utilized by the normalizing engine108to normalize name information, address information, social security numbers, etc. into a format that may increase the likelihood of discovering matching information from various payer data104. According to embodiments, normalization may include normalizing name information, for example, normalizing an inconsistent use of punctuation and spaces in names and the inclusion of suffixes (JR, SR, III) in a last name field. Normalization may include a removal of punctuation characters from names, including spaces (e.g., O'NEAL to ONEAL and SMITH-JONES or SMITH JONES to SMITHJONES). The normalization process may include removal of suffixes (e.g., JR, SR, II, III and IV) from last names when they are the last characters in the last name and preceded by a space. Normalization of name information may include applying a synonym table to names (e.g., Bill/Will/Billy/William, Joe/Joey/Joseph, etc.).

According to embodiments, data normalization may include address normalization. City name normalization may include spelling variations, abbreviation differences (e.g., “ST MTN” verses “STONE MOUNTAIN”), and punctuation differences (e.g., “FT. VALLEY” verses “FT VALLEY”). A first line of a street address may be normalized by removing spaces and punctuation and reducing directional words such as “East” or “Southwest” to abbreviations. More consistent results may be obtained with using directional abbreviations rather than expanding abbreviations to whole words because of possible uncertainty in interpreting directional abbreviates. For example, the “E” in “123 Main St, E 2” could be an apartment number or some other subdivisional unit rather than an abbreviation for east.

According to embodiments, data normalization may include social security number normalization. Normalizing social security numbers (SSN) may comprise an elimination of patterns of characters such as “999999999” and “123121234”. Normalization of SSN may also comprise a removal of duplicate SSN numbers among family members. For example, if a policy holder and a dependent share the same SSN value, the SSN may be removed from the dependent.

According to embodiments, a comparison may be made of payer data104stored in the repository106to determine if any information associated with a member may be new, modified, or previously unmatched. Data that is determined to be new, modified, or previously unmatched may be sent to a matching engine110operable to compare payer data104against other insurance provider files (i.e., received payer data104) to discover if an individual may be covered under more than one health insurance policy, for example, by determining COB instances by discovering matches or partial-matches of member information (i.e., payer data104).

Matching payer data104may be determined according to various rules112. According to an embodiment, an address match may include a match of a predetermined number of characters of a normalized street address and a match of either a city name or zip code. For example, an address match may be determined if the first 10 characters of the normalized first street address match and either the city name or the 5 character zip code matched.

According to an embodiment, a SSN match may include a partial match of a predetermined number of digits of the SSN. For example, a match may be determined if eight of the nine digits in a SSN match. According to one embodiment, a partial SSN match may include a detection of transposed numbers.

Confidence levels may be given to various combinations of matches or partial matches of data. For example, according to one embodiment, an SSN in combination with name, date of birth and other fields may provide reliable matching results. For example, the probability of a mismatch may be limited to a narrow combination of a mistyped SSN for two individuals along with identical supporting information.

According to one embodiment, variations of matching an SSN and date of birth with a name may be utilized in the matching process. For example, the matching process may include comparing a complete normalized first and last name. A comparison using a partial match of a last name (e.g., first six characters) and a complete first name may be applied to find variations in last name spelling and to detect situations where one payer may include a hyphenated last name. A synonym first name with a full last name may be applied to march variations (e.g., Bill/William and Judy/Judith). A partial first name (e.g., first six characters) in conjunction with a full last name may be matched to detect variations in name spelling and inclusion of middle names in the first name field.

Sometimes, SSNs may not be available. In such cases, other mechanisms may be utilized. For example, the process may include matching normalized names and addresses in conjunction with a date of birth. A combination of exact name matches after name normalization along with partial matches using a predetermined number of characters of the normalized last name and first name. These matches may be supplemented with partial SSN matches.

According to another embodiment, additional match rules may be applied (e.g., SSN and last name match; SSN and first name match; phone, DOB, and gender match, etc.). An SSN and last name match may be utilized to detect a match when a first name is misspelled or contains a middle name. Since duplicate SSNs within a same family may be removed as part of the normalization process, a family member with a unique SSN and the same last name may make a good match regardless of the first name.

An SSN and first name match may be utilized to detect married women whose last names have changed. This may also be utilized to detect misspelled last names. A phone, date of birth, and gender match may be utilized to detect matches that may not have been identified elsewhere.

Below is a table of example rules112that may be utilized as match logic by the matching engine110according to an embodiment. As can be appreciated, various combinations of match logic may be utilized in a matching process.

Name matchThe normalized first and last names must matchexactlyName matchThe normalized first name must match exactly and(partial last)the first 6 characters of the normalized last namemust matchName matchThe normalized last name must match exactly and(partial first)the first 3 characters of the normalized first namemust matchName matchThe normalized last name must match exactly and(equivalent first)the normalized first name must match through alimited first name synonym table (Bill/Billy/William,Joe/Joey/Joseph, etc.)Addresses matchThe normalized street address has to match exactlyand either the city name or zip code must matchexactlyDOBAll 8 digits of the date of birth (xx/xx/xx) must matchperfectly and in exactly the same order (notranspositions)DOB seven digitsSeven of the eight digits in the date of birth mustmatch perfectly. All seven digits have to be in exactlythe same relative position in the DOB, e.g., the digitsfor the month and day cannot be transposedSSNAll 9 digits of the SSN must match perfectly and mustbe in exactly the same order (no transpositions)SSN 8 digitsEight of the nine digits in the SSN must matchperfectly. All 8 matching digits have to be in exactlythe same relative position with the SSN number, e.g.,the 4thdigit in one SSN has to match the 4thdigit inthe other SSN, etc.

Once the matching methodology has been exhausted and all possible matches are identified, the matching engine110may be operable to determine an assignment of primary and secondary responsibility. According to an embodiment, a process of determination of primacy may be based on National Association of Insurance Commissioners (NAIC) and state guidelines as well as available data from a payer102that may provide any exceptions to NAIC and state guidelines (e.g., divorce decree, child custody agreement, etc.). Embodiments may include an identification of a plan type (e.g., medical, dental, life, student, Cobra, etc.) from each payer102. This identification may be utilized for creating a definitive primacy determination and for providing qualified instances of COB.

After the matching process is complete and primacy determinations are made, matches and primacy determinations may be stored in a COB database114. Output files118may be generated for each payer102. The database114may be a central repository and include all payers102and all matches. According to an embodiment, the matching process and subsequent output118may be in a real-time format. An output file118may include a summary report, raw data, and ad hoc queries. The summary report may provide an overview of the payer data104received, as well as a summary of the matches and COB determinations. The raw data may be in the format of a file for each payer102to import into their internal system for processing and review. The ad hoc query may be a web interface operative to access archived reports and files and to generate individual member searches as needed. Payers102may utilize the output118to update their databases to utilize for processing future claims.

Embodiments may be utilized for determining insurance coverage and eliminate the need for providers to search multiple disparate databases to select a correct payer for healthcare services. Embodiments may be utilized to update COB information before a claim is submitted, which may maximize claim auto-adjudication and provider portal functionality.

Having described a high-level system architecture with which embodiments of the invention may be implemented,FIG. 2is a flow chart of a method of providing an identification of COB instances via a normalization and data matching process, applying a set of rules for determining primacy, and providing output. Referring now toFIG. 2, the method200begins at START OPERATION202, and proceeds to OPERATION204where payer data104is received from a plurality of payers102. As described above payer data104may be a membership file which may include eligibility and member demographic data such information as, but not limited to, a member's name, phone number(s), social security number, driver license number, birth date, gender, address, member identification number, plan name, plan type, insured's name, dates of coverage, marital status, employment status, policy holder's information, custodial parent information, etc.

When payer data104is received the method200proceeds to DECISION OPERATION206, where the data104may be analyzed and a determination may be made as to whether there is any new or modified information. For example, new or modified information may include new member data, a change of a member's name, address, phone number, employment status, marital status, etc.

If new or changed payer data104is found, the new or changed data104may be stored in a repository106, and the method200may proceed to OPERATION208where the new or modified payer data104may be normalized into a format for comparing with other stored payer data104. As described above, name information, address information, social security numbers, date-of-birth information, etc. may be normalized according to various rules112. For example, normalizing name information may include normalizing an inconsistent use of punctuation and spaces in names and the inclusion of suffixes (JR, SR, III) in a last name field, a removal of punctuation characters from names, a removal of suffixes (e.g., JR, SR, II, III and IV) from last names when they are the last characters in the last name and preceded by a space, or applying a synonym table to names (e.g., Bill/Will/Billy/William, Joe/Joey/Joseph, etc.).

After the payer data104has been normalized, the method200may proceed to OPERATION210, where the normalized payer data104may be compared with payer data104received from other payers102to find possible matches. Matching data found from different payers102may be indicative of an individual being covered under multiple healthcare insurance policies. As described above, various rules112may be applied for determining matching payer data104.

When all rules112have been applied and all possible matches have been identified, the method200may proceed to OPERATION212, where primacy may be determined. Determining which payer102may be primary and which payer102may be secondary may be determined according to NAIC regulations and state guidelines. For example, a child whose parents are married, the plan of the parent whose birthday falls earlier in the calendar year may be determined as the primary plan. Other available data from a payer102that may provide any exceptions to NAIC regulations and state guidelines may be used for determining primacy. For example, other data provided by the payer102may include information of a court decree stating that one parent's plan is the primary plan. Discovered matches may be stored in the COB database114at OPERATION214.

After the matching process is complete and primacy determinations have been made, the method200proceeds to OPERATION216, where output files118may be generated for each payer102. The output files118may include a summary report and raw data that may be provided in a format able to be imported into the payer's102internal system for processing and review. The output files118may also include ad hoc queries, which may include a web interface for access to archived reports and files for providing individual member search functionalities. As can be appreciated, payers102may be able to utilize the output118to clean up and update COB information before a claim is filed, and thereby maximizing claim auto-adjudication. The method ends at operation298.

With reference toFIG. 3, a system consistent with embodiments of the invention may include one or more computing devices, such as computing device300. The computing device300may include at least one processing unit302and a system memory304. The system memory304may 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 memory304may include operating system305, one or more programming modules306, and may include a normalizing engine108and a matching engine110, wherein the normalizing engine108and the matching engine110are software applications having sufficient computer-executable instructions, which when executed, perform functionalities as described herein. Operating system305, for example, may be suitable for controlling computing device300'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 inFIG. 3by those components within a dashed line308.

The computing device300may 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 inFIG. 3by a removable storage309and a non-removable storage310. Computing device300may also contain a communication connection316that may allow device300to communicate with other computing devices318, such as over a network in a distributed computing environment, for example, an intranet or the Internet. Communication connection316is one example of communication media. Data may be input and output to/from the device300via one or more input devices312and/or output devices314.

Program modules, such as the normalizing engine108and the matching engine110, 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.

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,FIGS. 1-3and 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.