Patent Publication Number: US-2023162846-A1

Title: Systems and methods for predicting healthcare provider specialties

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims priority to U.S. Provisional Patent Application No. 63/264,318 filed Nov. 19, 2021 and titled “SYSTEMS AND METHODS FOR PREDICTING HEALTHCARE PROVIDER SPECIALTIES”, the contents of which are incorporated herein by reference for all purposes. 
    
    
     FIELD 
     The described embodiments relate to systems and methods for detecting healthcare fraud, waste, or abuse, and in particular, system and methods for predicting healthcare provider specialties. 
     BACKGROUND 
     Healthcare fraud, waste, and abuse causes significant financial loss in the healthcare system. The detection of healthcare fraud, waste, and abuse is typically based on behavioral analytics of a subject entity compared to the subject entity&#39;s peers. The subject entity can be, example, a provider, a healthcare claim, or a patient. A subject entity having anomalous behavior compared to its respective peer group can be further investigated. 
     SUMMARY 
     The various embodiments described herein generally relate to methods (and associated systems configured to implement the methods) for assessing a query healthcare claim for fraud, waste, or abuse. The disclosed methods and systems can relate to predicting healthcare provider specialties. 
     An example computer-implemented method of generating a predictive model for predicting healthcare provider specialties involves operating at least one processor to receive historical healthcare claim data. Each healthcare claim can include a claim code, a healthcare provider, and a disclosed specialty. The method further involves operating the at least one processor to generate a code utilization profile for each healthcare provider based on the historical healthcare claim data; receive registry data comprising registry specialties for each healthcare provider; select a training dataset comprising the code utilization profiles and corresponding registry specialties; and train the predictive model with the training dataset to predict a healthcare provider specialty for a healthcare claim. 
     In at least one embodiment, operating the at least one processor to select a training dataset comprising the code utilization profiles and corresponding registry specialties can involve operating the at least one processor to, for each healthcare provider: identify a registry specialty of the registry data for the healthcare provider; generate a specialty correspondence indicator representative of a correspondence between the registry specialty of the registry data and the disclosed specialty of the historical healthcare claim data for the healthcare provider; and determine whether to include, in the training dataset, the code utilization profile and corresponding registry specialty for the healthcare provider based on the specialty correspondence indicator. 
     In at least one embodiment, operating the at least one processor to generate a specialty correspondence indicator can be based on one or more natural language processing fuzzy algorithms. 
     In at least one embodiment, operating the at least one processor to generate a specialty correspondence indicator representative of a correspondence between the registry specialty of the registry data and the disclosed specialty of the historical healthcare claim data for the healthcare provider can involve operating the at least one processor to generate at least one preliminary specialty correspondence indicator for the registry specialty and the disclosed specialty; and obtain the specialty correspondence indicator based on the at least one preliminary specialty correspondence indicator. 
     In at least one embodiment, the at least one preliminary specialty correspondence indicator can include a plurality of preliminary specialty correspondence indicators; and the specialty correspondence indicator can be an average of the plurality of preliminary specialty correspondence indicators. 
     In at least one embodiment, operating the at least one processor to determine whether to include, in the training dataset, the code utilization profile and corresponding registry specialty for the healthcare provider based on the specialty correspondence indicator can involve operating the at least one processor to exclude, from the training dataset, the code utilization profile and corresponding registry specialty for the healthcare provider if: the specialty correspondence indicator is less than a pre-determined threshold value for the specialty correspondence indicator; or one or more preliminary specialty correspondence indicators of the plurality of preliminary specialty correspondence indicators is less than a pre-determined threshold value for that preliminary specialty correspondence indicator. 
     In at least one embodiment, the at least one preliminary specialty correspondence indicator can include at least one of: a partial score, a token score, or a weighted score. The partial score can be based on one or more abbreviations in the registry specialty or one or more abbreviations in the disclosed specialty. The token score can be based on at least one token word of the registry specialty or at least one token word of the disclosed specialty. The weighted score being based on a length of the registry specialty and a length of the disclosed specialty. 
     In at least one embodiment, the token score can be based on a ratio of a set of token words of the registry specialty and a set of token words of the disclosed specialty. 
     In at least one embodiment, the weighted score can be the partial score if the length of the registry specialty is significantly longer or shorter than the length of the disclosed specialty. 
     In at least one embodiment, operating the at least one processor to generate a code utilization profile for each healthcare provider based on the historical healthcare claim data can involve operating the at least one processor to, for each healthcare provider: identify healthcare claims corresponding to the healthcare provider; determine a total number of healthcare claims corresponding to the healthcare provider; for each healthcare claim code, determine a number of healthcare claims corresponding to the healthcare provider; and for each healthcare claim code, determine a utilization percentage based on the number of healthcare claims corresponding to the healthcare provider for the healthcare claim code to the total number of healthcare claims corresponding to the healthcare provider. 
     In at least one embodiment, operating the at least one processor to select a training dataset comprising the code utilization profiles and corresponding registry specialty can involve operating the at least one processor to: for each code utilization profile and corresponding registry specialty, determine a volume size of the healthcare provider, the volume size being one of small, average, or large; if the healthcare provider is one of small or large volume size, exclude the code utilization profile and corresponding registry specialty from the training dataset; and if the healthcare provider is average, include the code utilization profile and corresponding registry specialty in the training dataset. 
     In at least one embodiment, the healthcare provider volume size being small, average or large can be based on at least one of a number of healthcare claims associated with the healthcare provider or a number of patients having healthcare claims associated with the healthcare provider. 
     In at least one embodiment, the healthcare provider specialty can be based on a taxonomy different from a taxonomy of the disclosed specialty and a taxonomy of the registry specialty. 
     In at least one embodiment, the taxonomy of the healthcare provider specialty can include a classification that corresponds to a plurality of classifications from the taxonomy of the disclosed specialty or the taxonomy of the registry specialty. 
     In at least one embodiment, operating the at least one processor to train the predictive model with the training dataset to predict a healthcare provider specialty for a healthcare claim can involve operating the at least one processor to reduce the training dataset dimensionality. 
     In at least one embodiment, operating the at least one processor to reduce the training dataset dimensionality can involve operating the at least one processor to bicluster the training dataset. 
     In at least one embodiment, operating the at least one processor to bicluster the training dataset can involve operating the at least one processor to assign each healthcare claim to at least one of a claim type cluster grouping and a business code cluster grouping. 
     In at least one embodiment, operating the at least one processor to reduce the training dataset dimensionality can involve operating the at least one processor to apply recursive feature elimination to the training dataset. 
     In at least one embodiment, the method can involve operating the at least one processor to compare the healthcare provider specialty predicted by the predictive model to one or more pre-determined business rules. 
     In another broad aspect, an example system for generating a predictive model for predicting healthcare provider specialties is disclosed herein. The system includes at least one processor configured to receive historical healthcare claim data. Each healthcare claim can include a claim code, a healthcare provider, and a disclosed specialty. The at least one processor is further configured to generate a code utilization profile for each healthcare provider based on the historical healthcare claim data; receive registry data comprising registry specialties for each healthcare provider; select a training dataset comprising the code utilization profiles and corresponding registry specialties; and train the predictive model with the training dataset to predict a healthcare provider specialty for a healthcare claim. 
     In at least one embodiment, the at least one processor configured to select a training dataset comprising the code utilization profiles and corresponding registry specialties can include the at least one processor configured to, for each healthcare provider: identify a registry specialty of the registry data for the healthcare provider; generate a specialty correspondence indicator representative of a correspondence between the registry specialty of the registry data and the disclosed specialty of the historical healthcare claim data for the healthcare provider; and determine whether to include, in the training dataset, the code utilization profile and corresponding registry specialty for the healthcare provider based on the specialty correspondence indicator. 
     In at least one embodiment, the at least one processor configured to generate a specialty correspondence indicator can be based on one or more natural language processing fuzzy algorithms. 
     In at least one embodiment, the at least one processor configured to generate a specialty correspondence indicator representative of a correspondence between the registry specialty of the registry data and the disclosed specialty of the historical healthcare claim data for the healthcare provider can include the at least one processor being configured to: generate at least one preliminary specialty correspondence indicator for the registry specialty and the disclosed specialty; and obtain the specialty correspondence indicator based on the at least one preliminary specialty correspondence indicator. 
     In at least one embodiment, the at least one preliminary specialty correspondence indicator can include a plurality of preliminary specialty correspondence indicators; and the specialty correspondence indicator can be an average of the plurality of preliminary specialty correspondence indicators. 
     In at least one embodiment, the at least one processor configured to determine whether to include, in the training dataset, the code utilization profile and corresponding registry specialty for the healthcare provider based on the specialty correspondence indicator can include the at least one processor configured to exclude, from the training dataset, the code utilization profile and corresponding registry specialty for the healthcare provider if: the specialty correspondence indicator is less than a pre-determined threshold value for the specialty correspondence indicator; or one or more preliminary specialty correspondence indicators of the plurality of preliminary specialty correspondence indicators is less than a pre-determined threshold value for that preliminary specialty correspondence indicator. 
     In at least one embodiment, the at least one preliminary specialty correspondence indicator can include at least one of: a partial score, a token score, or a weighted score. The partial score can be based on one or more abbreviations in the registry specialty or one or more abbreviations in the disclosed specialty. The token score can be based on at least one token word of the registry specialty or at least one token word of the disclosed specialty. The weighted score being based on a length of the registry specialty and a length of the disclosed specialty. 
     In at least one embodiment, the token score can be based on a ratio of a set of token words of the registry specialty and a set of token words of the disclosed specialty. 
     In at least one embodiment, the weighted score can be the partial score if the length of the registry specialty is significantly longer or shorter than the length of the disclosed specialty. 
     In at least one embodiment, the at least one processor configured to generate a code utilization profile for each healthcare provider based on the historical healthcare claim data can include the at least one processor configured to, for each healthcare provider: identify healthcare claims corresponding to the healthcare provider; determine a total number of healthcare claims corresponding to the healthcare provider; for each healthcare claim code, determine a number of healthcare claims corresponding to the healthcare provider; and for each healthcare claim code, determine a utilization percentage based on the number of healthcare claims corresponding to the healthcare provider for the healthcare claim code to the total number of healthcare claims corresponding to the healthcare provider. 
     In at least one embodiment, the at least one processor configured to select a training dataset comprising the code utilization profiles and corresponding registry specialty can include the at least one processor configured to: for each code utilization profile and corresponding registry specialty, determine a volume size of the healthcare provider, the volume size being one of small, average, or large; if the healthcare provider is one of small or large volume size, exclude the code utilization profile and corresponding registry specialty from the training dataset; and if the healthcare provider is average, include the code utilization profile and corresponding registry specialty in the training dataset. 
     In at least one embodiment, the healthcare provider volume size being small, average or large can be based on at least one of a number of healthcare claims associated with the healthcare provider or a number of patients having healthcare claims associated with the healthcare provider. 
     In at least one embodiment, the healthcare provider specialty can be based on a taxonomy different from a taxonomy of the disclosed specialty and a taxonomy of the registry specialty. 
     In at least one embodiment, the taxonomy of the healthcare provider specialty can include a classification that corresponds to a plurality of classifications from the taxonomy of the disclosed specialty or the taxonomy of the registry specialty. 
     In at least one embodiment, the at least one processor configured to train the predictive model with the training dataset to predict a healthcare provider specialty for a healthcare claim can include the at least one processor configured to reduce the training dataset dimensionality. 
     In at least one embodiment, the at least one processor configured to reduce the training dataset dimensionality can include the at least one processor configured to bicluster the training dataset. 
     In at least one embodiment, the at least one processor configured to bicluster the training dataset can include the at least one processor configured to assign each healthcare claim to at least one of a claim type cluster grouping and a business code cluster grouping. 
     In at least one embodiment, the at least one processor configured to reduce the training dataset dimensionality can include the at least one processor configured to apply recursive feature elimination to the training dataset. 
     In at least one embodiment, the at least one processor can be configured to compare the healthcare provider specialty predicted by the predictive model to one or more pre-determined business rules. 
     In another broad aspect, an example method of assessing a query healthcare claim for fraud, waste, or abuse is disclosed herein. The method involves operating at least one processor to receive healthcare claim data for a healthcare provider. The healthcare claim data includes at least the query healthcare claim. Each healthcare claim of the healthcare claim data includes a claim code and a disclosed specialty. The method further involves operating the at least one processor to generate a query code utilization profile for the healthcare provider of the query healthcare claim; determine a predicted healthcare provider specialty for the query healthcare claim by applying the query code utilization profile to a predictive model generated for predicting a healthcare provider specialty; determine whether a behavior of the healthcare provider of the query healthcare claim data is anomalous based on the predicted healthcare provider specialty; and assess the query healthcare claim based on the behavior of the healthcare provider. 
     In another broad aspect, an example system for assessing a query healthcare claim for fraud, waste, or abuse is disclosed herein. The system includes at least one processor configured to receive healthcare claim data for a healthcare provider. 
     The healthcare claim data includes at least the query healthcare claim. Each healthcare claim of the healthcare claim data includes a claim code and a disclosed specialty. The at least one processor is further configured to generate a query code utilization profile for the healthcare provider of the query healthcare claim; determine a predicted healthcare provider specialty for the query healthcare claim by applying the query code utilization profile to a predictive model generated for predicting a healthcare provider specialty; determine whether a behavior of the healthcare provider of the query healthcare claim data is anomalous based on the predicted healthcare provider specialty; and assess the query healthcare claim based on the behavior of the healthcare provider. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Several embodiments will now be described in detail with reference to the drawings, in which: 
         FIG.  1    is a block diagram of components interacting with an example healthcare fraud detection system, in accordance with an example embodiment; 
         FIG.  2    is a flowchart of an example embodiment of various methods of generating a predictive model for predicting healthcare provider specialties; 
         FIG.  3 A  is an illustration of example historical healthcare claim data, in accordance with an example embodiment; 
         FIG.  3 B  is an illustration of example code utilization profiles for the historical healthcare claim data of  FIG.  3 A , in accordance with an example embodiment; 
         FIG.  3 C  is an illustration of example registry data, in accordance with an example embodiment; 
         FIG.  3 D  is an illustration of an example training dataset based on the example code utilization profiles of  FIG.  3 B  and the example registry data of  FIG.  3 C , in accordance with an example embodiment; 
         FIG.  4    is an illustration of an example healthcare provider specialty prediction, in accordance with an example embodiment; 
         FIG.  5    is a block diagram of components interacting in the example method of  FIG.  2   ; and 
         FIG.  6    is a block diagram of components interacting in an example method for assessing a query healthcare claim, in accordance with an example embodiment. 
     
    
    
     The drawings, described below, are provided for purposes of illustration, and not of limitation, of the aspects and features of various examples of embodiments described herein. For simplicity and clarity of illustration, elements shown in the drawings have not necessarily been drawn to scale. The dimensions of some of the elements may be exaggerated relative to other elements for clarity. It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the drawings to indicate corresponding or analogous elements or steps. 
     DESCRIPTION OF EXAMPLE EMBODIMENTS 
     The various embodiments described herein generally relate to methods (and associated systems configured to implement the methods) of generating a predictive model for predicting healthcare provider specialties. The systems and methods can use artificial intelligence or machine learning methods to train the predictive model. 
     Healthcare fraud, waste, and abuse detection is typically based on a comparison of the behavior of a subject entity to the behavior of the subject entity&#39;s peers. Accordingly, comparison to appropriate peers is critical. However, the definition of the subject entity&#39;s peers can be subjective. 
     Healthcare providers&#39; specialties are recorded in an external registry, such as a National Provider registry. However, information recorded in external registries may be incorrect or obsolete. The time relevance of such external registries may not be reliable. 
     For example, healthcare providers specialties are also disclosed with healthcare claims and the specialties disclosed with healthcare claims may not be accurate, and further may not align with the specialties recorded in the external registry. As such, reliance on external registries for the subject entity&#39;s peers may result in false positives for anomalous behavior. 
     The systems and methods described herein operate to predict healthcare provider specialties by analyzing code utilization profiles of healthcare claim data. The system can generate a predictive model for predicting healthcare provider specialties. In some embodiments, the system can receive registry data and historical healthcare claim data and generate a code utilization profile for each healthcare provider based on the historical healthcare claim data. The system can also select a training dataset including the code utilization profiles and corresponding registry specialties of the registry data. The system can use artificial intelligence and/or machine learning methods to train the predictive model with the training dataset to predict a healthcare provider specialty for a healthcare claim. 
     Reference will now be made to  FIG.  1   , which is a block diagram  100  of components interacting with an example healthcare fraud detection system  110 . As shown in  FIG.  1   , the healthcare fraud detection system  110  is in communication with a computing device  120  and an external data storage  130  via a network  140 . 
     The healthcare fraud detection system  110  includes a processor  112 , a communication component  114 , and a data storage component  116 . The healthcare fraud detection system  110  can be provided on one or more computer servers that may be distributed over a wide geographic area and connected via the network  140 . 
     The healthcare fraud detection system  110  can perform various functions related to the detection of healthcare fraud, waste, or abuse. For example, the healthcare fraud detection system  110  can receive data, such as healthcare claim data, from computing device  120 . The healthcare fraud detection system  110  can also access data, such as registry data or medical code definitions, stored in external data storage  130 . The healthcare fraud detection system  110  can develop a code utilization profile from healthcare claim data. The healthcare fraud detection system  110  can generate a prediction model for predicting healthcare provider specialties for healthcare claim data. 
     In some embodiments, each of the processor  112 , the communication component  114 , and the data storage component  116  can be combined into a fewer number of components or may be separated into further components. The processor  112 , the communication component  114 , and the data storage component  116  can be implemented in software or hardware, or a combination of software and hardware. 
     The processor  112  can operate to control the operation of the healthcare fraud detection system  110 . The processor  112  can initiate and manage the operations of each of the other components within the healthcare fraud detection system  110 . The processor  112  may be any suitable processors, controllers, digital signal processors, or graphics processing units (GPUs) that can provide sufficient processing power depending on the configuration, purposes and requirements of the healthcare fraud detection system  110 . In some embodiments, the processor  112  can include more than one processor with each processor being configured to perform different dedicated tasks. 
     The communication component  114  may include any interface that enables the healthcare fraud detection system  110  to communicate with other devices and systems. In some embodiments, the communication component  114  can include at least one of a serial port, a parallel port or a USB port. The communication component  114  may also include at least one of an Internet, Local Area Network (LAN), Ethernet, Firewire, modem or digital subscriber line connection. Various combinations of these elements may be incorporated within the communication component  114 . 
     For example, the communication component  114  may receive input from various input devices, such as a mouse, a keyboard, a touch screen, a thumbwheel, a track-pad, a track-ball, a card-reader, voice recognition software and the like depending on the requirements and implementation of the healthcare fraud detection system  110 . 
     The data storage component  116  can include RAM, ROM, one or more hard drives, one or more flash drives or some other suitable data storage elements such as disk drives, etc. The data storage component  116  can also include one or more databases (not shown) for storing information relating to, for example, registry data, healthcare claim data, service providers, patients, claim codes, types of treatments and/or procedures, etc. 
     Similar to the data storage component  116 , the external data storage  130  can also include RAM, ROM, one or more hard drives, one or more flash drives or some other suitable data storage elements such as disk drives, etc. In some embodiments, the external storage  130  can be similar to the data storage component  116  but located remotely from the healthcare fraud detection system  110  and accessible via the network  140 . The external data storage  130  can also include one or more databases (not shown) for storing information relating to, for example, registry data, healthcare claim data, service providers, patients, claim codes, types of treatments and/or procedures, etc. 
     The computing device  120  can include any networked device operable to connect to the network  140 . A networked device is a device capable of communicating with other devices through a network such as the network  140 . A networked device may couple to the network  140  through a wired or wireless connection. Although only one computing device  120  is shown in  FIG.  1   , it will be understood that more computing devices  120  can connect to the network  140 . 
     The computing device  120  may include at least a processor and memory, and may be an electronic tablet device, a personal computer, workstation, server, portable computer, mobile device, personal digital assistant, laptop, smart phone, WAP phone, an interactive television, video display terminals, gaming consoles, and portable electronic devices or any combination of these. 
     The network  140  may be any network capable of carrying data, including the Internet, Ethernet, plain old telephone service (POTS) line, public switch telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g. Wi-Fi, WiMAX, Ultra-wideband, Bluetooth®), SS 7  signaling network, fixed line, local area network, wide area network, and others, including any combination of these, capable of interfacing with, and enabling communication between, the healthcare fraud detection system  110 , the external storage  130  and the computing device  120 . 
     It will be understood that some components of  FIG.  1   , such as components of the healthcare fraud detection management system  110  or the external data storage  130 , can be implemented in a cloud computing environment. 
     Reference is now made to  FIG.  2   , which illustrates a flowchart of an example method  200  of generating a predictive model for predicting healthcare provider specialties, in accordance with an example embodiment. A healthcare fraud detection system, such as healthcare fraud detection system  110  having at least one processor  112  can be configured to implement the method  200 . 
     At  210 , the processor  112  receives historical healthcare claim data. The historical healthcare claim data can include a plurality of historical healthcare claims. Each historical healthcare claim can include a claim code related to services performed, a healthcare provider who rendered the services, a disclosed specialty of the healthcare provider who rendered the services, and a patient who received the services. The historical healthcare claim data can be received from a computing device, such as computing device  120 , or an external data storage, such as external data storage  130 . 
     Reference is now made to  FIG.  3 A , which illustrates example historical healthcare claim data  300 , in accordance with an example embodiment. As shown in  FIG.  3 A , the historical healthcare claim data  300  can include a healthcare provider identifier  302 , a specialty disclosed by the healthcare provider  304 , healthcare claim codes  306 , and line counts  308 . Line counts  308  can be a total number of healthcare claims that utilize a healthcare claim code  306 . That is, the healthcare claim data  300  shown in  FIG.  3 A  is aggregated data. For example, provider P 2  reported code C in  2000  lines of the historical healthcare claims and code D in  2500  line of the historical healthcare claims  300 . 
     The historical healthcare data  300  can be subject to various privacy and security restrictions and/or contractual obligations. Use of aggregated data allows for compliance with such restrictions and obligations. 
     In order to aggregate the historical healthcare claim data  300 , the historical healthcare claim data  300  can be standardized to a common format. For example, the historical healthcare claim data  300  can originate from different sources, having different field names, table structures, and claim codes—including non-standard claim codes. A standard, common format can be adopted. 
     Returning now to  FIG.  2   , at  220 , the processor  112  generates a code utilization profile for each healthcare provider based on the historical healthcare claim data. To generate a code utilization profile for a healthcare provider, the processor  112  can identify healthcare claims corresponding to the healthcare provider and determine a total number of healthcare claims corresponding to the healthcare provider. For each healthcare claim code, the processor  112  can determine a number of healthcare claims corresponding to the healthcare provider. The processor  112  can, for each healthcare claim code, determine a utilization percentage based on the number of healthcare claims corresponding to the healthcare provider for the healthcare claim code to the total number of healthcare claims corresponding to the healthcare provider. 
     Reference is now made to  FIG.  3 B , which illustrates example code utilization profiles  310  for the historical healthcare claim data of  FIG.  3 A , in accordance with an example embodiment. As shown in  FIG.  3 B , the code utilization profile for each healthcare provider can include the healthcare provider identifier  302 , the specialty disclosed by the healthcare provider  304 , and utilization percentages  312   a,    312   b,    312   c,    312   d,    312   e  . . . (herein collectively referred to as the utilization percentages  312 ) for each healthcare claim code  306 . For example, the code utilization for provider P 2  is 44.4% (i.e., 2000/4500) for code C and 55.6% (i.e., 2500/4500) for code D. 
     Returning now to  FIG.  2   , at  230 , the processor  112  receives registry data. The registry data can include registry specialties for each healthcare provider. The registry data can be received from a computing device, such as computing device  120 , or an external data storage, such as external data storage  130 . The registry data can be stored in a database, such as a National Provider Identifier (NPI) registry that provides the service provider&#39;s registration information. The registry specialty recorded in the registry data can be defined in accordance with a particular taxonomy, such as a National Plan and Provider Enumeration System (NPPES). 
     Reference is now made to  FIG.  3 C , which illustrates example registry data  320 , in accordance with an example embodiment. As shown in  FIG.  3 C , the registry data can include a healthcare provider identifier  322  and a specialty recorded in the registry  324 . 
     Returning now to  FIG.  2   , at  240 , the processor  112  selects a training dataset. The processor  112  can select a portion of the code utilization profiles generated at  210  and corresponding registry specialties received at  230  to use as the training dataset. 
     In some embodiments, the processor  112  can use the remaining data (i.e., the portion that is not included in the training dataset) as a validation dataset. For example, 80% of the historical healthcare claim data  300  can be used as the training dataset and the remaining 20% of the historical healthcare claim data  300  can be used as the validation dataset. In some embodiments, class imbalance can also be accounted for. That is, some specialties may not have a comparable number of providers. 
     In some embodiments, the processor  112  can, for each healthcare provider, identify a registry specialty  324  within the registry data  320  received at  230  for the healthcare provider. The registry specialty  324  of the registry data  320  can be used to validate the disclosed specialty  304  of the historical healthcare claim data  300  for a healthcare provider. The processor  112  can generate a specialty correspondence indicator representative of a correspondence between the registry specialty  324  of the registry data  320  and the disclosed specialty  304  of the historical healthcare claim data  300  for the healthcare provider. For example, a greater value of the specialty correspondence indicator can represent an accurate match between the registry data  320  and the disclosed specialty  304  and a lower value can represent an inaccurate match. 
     The processor  112  can determine whether to include, in the training dataset  330 , the code utilization profile  310  and corresponding registry specialty  324  for the healthcare provider based on the specialty correspondence indicator. For example, the processor  112  can compare the specialty correspondence indicator with a pre-determined threshold value. If the specialty correspondence indicator is greater than or equal to the pre-determined threshold value, the registry data  320  and the disclosed specialty  304  can be considered an accurate match and the code utilization profile  310  and corresponding registry specialty  324  for the healthcare provider can be included in the training dataset  330 . If the specialty correspondence indicator is less than the pre-determined threshold value, the registry data  320  and the disclosed specialty  304  may not be considered an accurate match and the code utilization profile  310  and corresponding registry specialty  324  for the healthcare provider can be excluded from the training dataset  330 . 
     The processor  112  can generate a specialty correspondence indicator based on one or more natural language processing (NLP) fuzzy algorithms. In some embodiments, the processor  112  can generate at least one preliminary specialty correspondence indicator for the registry specialty and the disclosed specialty; and obtain the specialty correspondence indicator based on the at least one preliminary specialty correspondence indicator. For example, the processor  112  can generate a plurality of preliminary specialty correspondence indicators and obtain an average of the plurality of preliminary specialty correspondence indicators. 
     In at least one embodiment, a preliminary specialty correspondence indicator can be a full ratio score between the disclosed specialty  304  and the registry specialty  324 . A full ratio score can be determined based on a comparison of string text corresponding to the disclosed specialty  304  and string text corresponding to the registry specialty  324 . 
     In at least one embodiment, a preliminary specialty correspondence indicator can be a partial ratio score, or a partial score, between the disclosed specialty  304  and the registry specialty  324 . The partial ratio score can result in a higher value than the full ratio score as the partial ratio score can account for partial strings of the disclosed specialty  304  (e.g., different nomenclature or abbreviations in the disclosed specialty  304 ) and partial strings of the registry specialty  324  (e.g., different nomenclature or abbreviations in the registry specialty  324 ). For example, “Physical and Rehab” is an abbreviation of “Physical &amp; Rehabilitation”. A partial ratio of “Physical Rehab” to “Physical &amp; Rehabilitation” can result in a higher score than a full ratio score of “Physical Rehab” to “Physical &amp; Rehabilitation”. 
     In at least one embodiment, a preliminary specialty correspondence indicator can be a full token set ratio score, or full token set score, between the disclosed specialty  304  and the registry specialty  324 . The full token set ratio score can be determined by generating a token word for each word of the disclosed specialty  304  and the registry specialty  324 . Duplicate token words of the disclosed specialty  304  and duplicate token words of the registry specialty  324  can be discarded to obtain a set of unique token words for the disclosed specialty  304  and a set of unique token words for the registry specialty  324 , respectively. The full token set ratio score can be determined based on a set of unique token words for the disclosed specialty  304  and a set of unique token words for the registry specialty  324 . The full token set ratio score can result in a higher value than a full ratio score as the token set ratio score can account for words that share a common token. 
     For example, a full token set ratio of “Durable Medical Equipment—Oxygen/Respirator” to “Durable Medical Equipment &amp; Medical Supplies” can result in a higher score than a score obtained from a full ratio of “Durable Medical Equipment—Oxygen/Respirator” to “Durable Medical Equipment &amp; Medical Supplies”. That is, the words “oxygen” and “respirator” can share a common token and “respirator” results in a duplicate token word following “oxygen”. 
     In at least one embodiment, a preliminary specialty correspondence indicator can be a full token sort ratio score, or full token sort score, between the disclosed specialty  304  and the registry specialty  324 . The set of unique token words of the disclosed specialty  304  and the set of unique token words of the registry specialty  324  can be sorted to obtain an ordered set of unique token words for the disclosed specialty  304  and an ordered set of unique token words for the registry specialty  324 , respectively. 
     The full token sort ratio score can be determined based on the ordered set of unique token words for the disclosed specialty  304  and an ordered set of unique token words for the registry specialty  324 . The full token sort ratio score can result in a higher value than a full token set ratio score because the token sort ratio score can account for similar words being in different orders. 
     It should be noted that partial strings in the disclosed specialty  304  and the registry specialty  324  can also be accounted for to obtain a partial token set score and a partial token sort score. In at least one embodiment, the processor  112  can determine whether the length of the disclosed specialty  304  is significantly longer than the length of the registry specialty  324 , or vice versa. An example threshold for being significantly longer can be about 1.5 times. If the length of either the disclosed specialty  304  or the registry specialty  324  is significantly longer than the other, the processor  112  can determine a partial token set ratio score or a partial token sort ratio score instead of a full token set ratio score or a full token sort ratio score, respectively. 
     In at least one embodiment, a preliminary specialty correspondence indicator can be a weighted ratio score, or weighted score, between the disclosed specialty  304  and the registry specialty  324 . For example, the weighted score can be the greater score of a plurality of scores, such as the full ratio, the full token set ratio, and the full token sort ratio. Furthermore, if the processor  112  determines that the length of the disclosed specialty  304  is signification longer than the length of the registry specialty  324 , or vice versa, the weighted score can be the greater score of the full ratio, the partial token set ratio, and the partial token sort ratio. For example, a weighted ratio of “Ob/Gyn” to “Obstetrics &amp; Gynecology” can result in a higher score than a score obtained from a full ratio of “Ob/Gyn” to “Obstetrics &amp; Gynecology”. 
     In some embodiments, the processor  112  can determine whether to include, in the training dataset  330 , the code utilization profile  310  and corresponding registry specialty  324  for the healthcare provider based on the at least one preliminary specialty correspondence indicator. For example, the processor  112  can compare each preliminary specialty correspondence indicator with a pre-determined threshold value for that preliminary specialty correspondence indicator. The pre-determined threshold value for a token set ratio score may be different from the pre-determined threshold value for a partial ratio score. 
     If a preliminary specialty correspondence indicator is greater than or equal to the pre-determined threshold value, the registry data  320  and the disclosed specialty  304  can be considered an accurate match and the code utilization profile  310  and corresponding registry specialty  324  for the healthcare provider can be included in the training dataset  330 . If the preliminary specialty correspondence indicator is less than the pre-determined threshold value, the registry data  320  and the disclosed specialty  304  may not be considered an accurate match and the code utilization profile  310  and corresponding registry specialty  324  for the healthcare provider can be excluded from the training dataset  330 . 
     In some embodiments, the processor  112  can determine whether to include, in the training dataset  330 , the code utilization profile  310  and corresponding registry specialty  324  for the healthcare provider based on the specialty correspondence indicator as well as the at least one preliminary specialty correspondence indicator. For example, if any one of the specialty correspondence indicator or the preliminary specialty correspondence indicators are less than a respective pre-determined threshold value, the registry data  320  and the disclosed specialty  304  may not be considered an accurate match and the code utilization profile  310  and corresponding registry specialty  324  for the healthcare provider can be excluded from the training dataset  330 . That is, the registry data  320  and the disclosed specialty  304  can only be considered an accurate match and included in the training dataset  330  if the specialty correspondence indicator and each of the at least one preliminary specialty correspondence indicator is greater than the respective pre-determined threshold value. 
     In some embodiments, the processor  112  can determine whether to include, in the training dataset  330 , the code utilization profile  310  and corresponding registry specialty  324  for the healthcare provider based a volume size of the healthcare provider. Low volume and/or extremely large volume healthcare providers can skew the overall distribution. As such, the processor  112  can exclude such healthcare providers from the training dataset  330 . In some examples, excluded healthcare providers can represent about 1 to 3% of the top and bottom of the distribution, depending on the healthcare claim type and healthcare provider specialty. Extremely large volume healthcare providers can include, but is not limited to, national laboratories. Healthcare providers with a very small number of patients, or a very small number of claims, or both a very small number of patients and a very small number of claims can be considered low volume healthcare providers. In some embodiments, the processor  112  can determine that only healthcare providers having an average volume size can be included in the training dataset  330 . 
     Reference is now made to  FIG.  3 D , which illustrates an example training dataset  330 , in accordance with an example embodiment. As shown in  FIG.  3 D , the training dataset  330  can include the code utilization profiles, such as the healthcare provider identifier  302 , the disclosed specialty  304 , and the utilization percentages  312 , and the registry specialty  324 . In example training dataset  330 , the processor  112  selected providers P 1 , P 2 , and P 4  to be included in the training dataset  330  and provider P 3  to be excluded from the training dataset. 
     Returning now to  FIG.  2   , at  250 , the processor  112  trains the predictive model with the training dataset selected at  240  to predict a healthcare provider specialty for a healthcare claim. The processor  112  can train the predictive model using artificial intelligence and/or machine learning methods. The healthcare provider specialty predicted by the predictive model can be based on a taxonomy that is different from the taxonomy of the registry specialty  324  and/or the taxonomy of the disclosed specialty  304 . 
     Using a more robust taxonomy for the predictive model can minimize the misclassification rate. A taxonomy with larger groups can be more robust. For example, the taxonomy of the predictive model can include “general medicine” as a specialty. The “general medicine” specialty of the predictive model can encompass specialties such as “internal medicine”, “family medicine”, and “nurse practitioner” of the disclosed specialty  304  or the registry specialty  324 . Similarly, “social worker”, “psychiatrist”, and “counselor” specialties in the disclosed specialties  304  or the registry specialties  324  can be combined into a single specialty in the taxonomy of the predictive model. A taxonomy with larger groups can also allow for easier identification of specialties within the larger groups, such as internal medicine and surgery. The taxonomy of the predictive model can be developed through a reiterative process. In some cases, the taxonomy of the predictive model can be manually developed based on the knowledge subject matter experts. 
     The training dataset  330  can be a high dimensional and sparse dataset. To improve the accuracy of the predictive model, the processor  112  can reduce the dimensionality of the training dataset  330 . The dimensionality of the training dataset  330  can be reduced by biclustering the training dataset  330 . For example, the processor  112  can cluster the training dataset  330  based on claim type groupings and cluster the claim type groupings by business code groupings. Example claim type groupings can include, but is not limited to, professional, dental, pharmacy, and facility. Example business code groupings for professional claim types can include, but is not limited to, Current Procedural Terminology (CPT) code groups and diagnosis code groups. Example business code groupings for pharmacy claim types can include but is not limited to therapeutic code groups. To cluster the training dataset  330 , the processor  112  can assign each healthcare claim to one of the clusters. 
     To further reduce the dimensionality of the training dataset  330  and thereby enhance signal to noise ratio, the processor  112  can apply recursive feature elimination to the training dataset  330 . In particular, the processor  112  can apply recursive feature elimination to the business code groupings. An example of business code groupings are Clinical Classification Software (CCS) groups for CPT codes. 
     The processor  112  can compare the healthcare provider specialty predicted by the predictive model to one or more pre-determined business rules and enforce the pre-determined business rules on the specialty prediction. The pre-determined business rules can be manually developed based on knowledge of subject matter experts. The pre-determined business rules can relate to, but is not limited to, time behavior, network coverage, geographic coverage. For example, a business rule can relate to the place of service (POS) code location. In particular, a business rule can require that certain healthcare provider specialties are only practiced at a select POS code locations. Accordingly, the processor  112  can identify healthcare claims associated with a particular healthcare provider specialty and POS code location that is not one of the select POS code locations for that healthcare provider specialty. 
     Reference is now made to  FIG.  4   , which illustrates an example healthcare provider specialty prediction generated by the predictive model, in accordance with an example embodiment. As shown in  FIG.  4   , the predictive model can receive a query code utilization profile  400  for a healthcare provider  402 , including the utilization percentages  404   a,    404   b,    404   c,    404   d,    404   e  . . . (herein collectively referred to as utilization percentages  404 ) for various healthcare claim codes. The predictive model can return a predicted specialty  406  for the healthcare provider. 
     In some embodiments, the processor  112  can retrain the predictive model, depending on the business need. For example, the processor  112  can retrain the predictive model on a quarterly or semi-annual basis. The processor  112  can also monitor the performance of the predictive model and automatically retrain the predictive model when a model drift, or a degradation in performance below a pre-determined threshold, is observed. 
     The predictive model can be trained using multiple algorithms and the best performing model can be identified during validation using metrics such as a precision/recall curve and a ROC-AUC curve. 
     Reference is now made to  FIG.  5   , which illustrates a block diagram  500  of components interacting in example method  200 , in accordance with an example embodiment. The processor  112  receives historical healthcare claim data  300  at  210  and generates code utilization profiles  310  for each healthcare provider at  220 . The processor  112  also receives registry data  320  at  230  and compares the code utilization profiles  310  with the registry data  320 . The processor  112  can select a training dataset  330  from the historical healthcare claim data  300  and the registry data  320  at  240 , based on the size volume of the healthcare providers of the claims data  300  and the correspondence between the disclosed specialties of the claim data  300  and the registry specialties of the registry data  320 . 
     The training dataset  330  can be sparse and have high dimensionality. To reduce the dimensionality, the processor  112  can bicluster the training dataset  330  based on the claim codes used in the historical healthcare claim data  300 . For example, the processor  112  can receive medical code definitions  502  from an external data source, such as external data storage  130 , and cluster and classify the training dataset  330  based on the medical code definitions  502 . 
     Additional pre-determined business rules can be applied to the healthcare provider specialty as predicted by the predictive model to provide a business reasonability check  506 . The pre-determined business rules can relate to, but is not limited to, time behavior, network coverage, geographic coverage. In some embodiments, the predictive model and pre-determined business rules can be implemented as an application programming interface  510 . Furthermore, implementation as an application programming interface reduces latency requirements. 
     Reference is now made to  FIG.  6   , which illustrates a block diagram  600  of components interacting in an example method for assessing a query healthcare claim for fraud, waste, or abuse, in accordance with an example embodiment. A healthcare fraud detection system, such as healthcare fraud detection system  110  having at least one processor  112  can be configured to implement the example method for assessing a query healthcare claim. 
     The processor  112  can receive query healthcare claim data for a healthcare provider. The healthcare claim data can include at least the query healthcare claim  602 . Each healthcare claim of the healthcare claim data can include a claim code and a disclosed specialty. The processor  112  can generate a query code utilization profile  400  for the healthcare provider of the query healthcare claim  602 . The processor  112  can determine a predicted healthcare provider specialty for the query healthcare claim  602  by applying the query code utilization profile  400  to a predictive model  510  generated for predicting a healthcare provider specialty. The processor  112  can determine whether a behavior of the healthcare provider of the query healthcare claim data is anomalous based on the predicted healthcare provider specialty. The processor  112  can assess the query healthcare claim for fraud, waste, or abuse based on the behavior of the healthcare provider. 
     It will be appreciated that numerous specific details are set forth in order to provide a thorough understanding of the example embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments described herein. Furthermore, this description and the drawings are not to be considered as limiting the scope of the embodiments described herein in any way, but rather as merely describing the implementation of the various embodiments described herein. 
     It should be noted that terms of degree such as “substantially”, “about” and “approximately” when used herein mean a reasonable amount of deviation of the modified term such that the end result is not significantly changed. These terms of degree should be construed as including a deviation of the modified term if this deviation would not negate the meaning of the term it modifies. 
     In addition, as used herein, the wording “and/or” is intended to represent an inclusive-or. That is, “X and/or Y” is intended to mean X or Y or both, for example. As a further example, “X, Y, and/or Z” is intended to mean X or Y or Z or any combination thereof. 
     It should be noted that the term “coupled” used herein indicates that two elements can be directly coupled to one another or coupled to one another through one or more intermediate elements. 
     The embodiments of the systems and methods described herein may be implemented in hardware or software, or a combination of both. These embodiments may be implemented in computer programs executing on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface. For example and without limitation, the programmable computers (referred to below as computing devices) may be a server, network appliance, embedded device, computer expansion module, a personal computer, laptop, personal data assistant, cellular telephone, smart-phone device, tablet computer, a wireless device or any other computing device capable of being configured to carry out the methods described herein. 
     In some embodiments, the communication interface may be a network communication interface. In embodiments in which elements are combined, the communication interface may be a software communication interface, such as those for inter-process communication (IPC). In still other embodiments, there may be a combination of communication interfaces implemented as hardware, software, and combination thereof. 
     Program code may be applied to input data to perform the functions described herein and to generate output information. The output information is applied to one or more output devices, in known fashion. 
     Each program may be implemented in a high level procedural or object oriented programming and/or scripting language, or both, to communicate with a computer system. However, the programs may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language. Each such computer program may be stored on a storage media or a device (e.g. ROM, magnetic disk, optical disc) readable by a general or special purpose programmable computer, for configuring and operating the computer when the storage media or device is read by the computer to perform the procedures described herein. Embodiments of the system may also be considered to be implemented as a non-transitory computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner to perform the functions described herein. 
     Furthermore, the system, processes and methods of the described embodiments are capable of being distributed in a computer program product comprising a computer readable medium that bears computer usable instructions for one or more processors. The medium may be provided in various forms, including one or more diskettes, compact disks, tapes, chips, wireline transmissions, satellite transmissions, internet transmission or downloadings, magnetic and electronic storage media, digital and analog signals, and the like. The computer useable instructions may also be in various forms, including compiled and non-compiled code. 
     Various embodiments have been described herein by way of example only. Various modification and variations may be made to these example embodiments without departing from the spirit and scope of the invention, which is limited only by the appended claims. Also, in the various user interfaces illustrated in the drawings, it will be understood that the illustrated user interface text and controls are provided as examples only and are not meant to be limiting. Other suitable user interface elements may be possible.