E.8 Draft PIM Chapter 16.docx
DOCX document 56 KB Posted
- Attached to
- Unified Program Integrity Contract (UPIC) Federal contract opportunity
- Solicitation number
- HHSM-500-2015-RFP-0122
About this file
E.8 Draft PIM Chapter 16
View the file
Other files for this federal contract opportunity
Show all 50
Unified Program Integrity Contract (UPIC) has more files on GovTribe.
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Exhibit E.8 HHSM-500-2015-RFP-0122 UPIC
Medicare Program Integrity Manual Chapter 16 – Fraud Prevention System
16.1 – Overview of Fraud Prevention System
16.2 – Prioritization of Alert Summary Records
16.3 – Coordination of ASRs and Investigations
16.4 – Ruling on ASRs
16.5 – Use of the Barriers to Actions Option in FPS
16.6 – Compromised Beneficiary and Provider ID Numbers
| 16.7 – Participation in Model Development Activities | 16.8 – Joint Operating Agreement | ||
| 16.9 – Calculation of FPS Return on Investment | 16.10 – Attribution of Administrative Actions to FPS | 16.11 – Documenting Attribution of Administrative Actions | |
| 16.11.1 – Administrative Actions Excluded from FPS Savings | 16.11.2 – Administrative Actions Included in FPS Savings |
Exhibit 47.1 – Definitions for Compromised Beneficiary ID Numbers Exhibit 47.2 – Definitions for Compromised Provider ID Numbers
For this entire chapter, until such time as all Zone Program Integrity Contractors (ZPICs) are awarded, any reference to ZPICs shall also apply to Program Safeguard Contractors (PSCs) and Unified Program Integrity Contractors (UPICs), unless otherwise noted.
16.1 – Overview of Fraud Prevention System
The Small Business Jobs Act of 2010 mandates that CMS implement predictive modeling and other advanced analytic technologies to prevent potential fraud, waste, and abuse. The Center for Program Integrity (CPI) implemented this requirement through the launch of the Fraud Prevention System (FPS) on June 30, 2011.
The FPS applies predictive models, edits and other advanced algorithms to identify providers exhibiting a pattern of behavior that is indicative of potential fraud, waste, and abuse. The system screens all national Medicare Part A, Part B, and DME claims prepayment and consolidates alerts by provider. The FPS has a case management system that presents the findings in a prioritized list, provides detailed information (including claims lines, beneficiaries, associated providers and claims), and tracks the information related to the investigation and the action taken. The ZPICs must make every effort to move beyond pay and chase to prevention and detection. The FPS is a major resource that assists in this effort.
Beginning July 1, 2011, ZPICs were instructed to use FPS. ZPICs are also required to use the FPS Dashboard. Should a ZPIC determine that changes must be made to the FPS or the FPS Dashboard, the ZPIC must contact the pertinent Contracting Officer’s Representative (COR).
16.2 – Prioritization of Alert Summary Records
ZPICs must assign ASRs that are in the ZPIC workload to a ZPIC FPS user. The ZPIC shall prioritize their work based on the direction of their SOW and the requirements as indicated in Chapter 4, Program Integrity, § 4.2.2.1.
16.3 – Coordination of ASRs and Investigations
For ASRs that affect multiple zones, ZPICs shall coordinate to designate a single lead ZPIC as appropriate. The lead ZPIC shall notify the COR/BFL of its assignment. ZPICs must coordinate with the appropriate ZPIC if an ASR does not belong to their ZPIC. ZPICs shall rule an ASR based on the provider, not based on individual alerts.
The ZPICs must collaborate and coordinate with other ZPICs who share an ASR to substantiate potential fraud, waste, and abuse. A ZPIC is defined as “Participating” on an ASR if the ZPIC selects the option of Participating on an ASR in the FPS. A ZPIC may only choose to participate on ASRs for which it is not the Lead. In situations where a ZPIC is the lead on an ASR and there is at least one other ZPIC participating, the lead ZPIC must collaborate and coordinate with the Participating ZPIC(s) and PSC(s) to substantiate potential fraud, waste, or abuse.
16.4 – Ruling on ASRs
ZPICs shall rule an ASR “Pend” until a determination of a “Suspect New,” “Suspect Existing,” or “Not Suspect” ruling has been made.
Suspect New: The ZPIC/PSC shall determine that an ASR is SuspectNew if the ZPIC/PSC is opening a new investigation on the subject provider/supplier (the ASR is also the National Provider Identifier). The ZPIC/PSC shall rule these ASRs SuspectNew in the Fraud Prevention System (FPS) regardless of whether the investigation is related to the models that identified the provider/supplier in the FPS.
Suspect Existing: The ZPIC/PSC shall determine that an ASR is SuspectExisting if the ZPIC/PSC has an open investigation on the subject provider/supplier (the ASR is also the National Provider Identifier). The ZPIC/PSC shall rule these ASRs SuspectExisting in the FPS regardless of whether the ongoing investigation is related to the models that identified the provider/supplier in the FPS.
When the ZPIC has determined that the subject of an ASR is potentially fraudulent, the ASR must be ruled “Suspect New” or “Suspect Existing” regardless of findings on individual alerts within the ASR. When the Fraud Investigation Database (FID) tag appears in an ASR, this ASR should not automatically be ruled “Suspect New” or “Suspect Existing.” The ZPIC should proceed with the screening of the ASR as warranted to substantiate whether the subject of the ASR is potentially fraudulent as indicated in Chapter 4, § 4.6.3.
If the ASR leads to opening an investigation, the ASR shall be ruled “Suspect New” or “Suspect Existing.” An ASR shall be ruled “Suspect New” when new investigations are developed from ASRs; and an ASR shall be ruled “Suspect Existing” when ongoing investigations by the ZPIC are supplemented by ASRs. Any ASR ruled “Suspect New” or “Suspect Existing” shall have a coordinating FID entry.
If the screening/investigation of the subject of an ASR, that is a new lead, does not substantiate any potential fraud and abuse, the ASR shall be ruled as “Not Suspect.” ZPICs shall reevaluate ASRs ruled “Not Suspect - Change” that fall within their workload. The ZPIC shall report ASR-level statistics in the FPS, including but not limited to actions, activities, and rulings.
16.5 – Use of the Barriers to Actions Option in FPS
ZPICs shall use the “Barriers to Actions” option in the Activities menu in the FPS to indicate that the pattern of behavior by the subject of the ASR has demonstrated potential fraud, waste, and/or abuse and that the ZPIC has taken all the appropriate action(s) that it can on an ASR; however, there is nothing else that the ZPIC can do to resolve the ASR. Examples of Barriers to Action include, but are not limited to: Medicare regulations, Medicare policy, State law, and law enforcement direction. In conjunction with the use of the “Barriers to Actions” option, ZPICs shall also update the notes of the ASR to explain the barrier(s) that they have encountered. The note shall start with “Explanation of Barriers to Action,” and clearly explain the reasons why the ZPIC is unable to continue to work the ASR.
16.6 – Compromised Beneficiary and Provider ID Numbers
Beginning in September 2011, CMS transitioned to a risk-based classification of compromised numbers. (See Exhibits 47.1 and 47.2.) The definitions and risk levels were developed by a CMS cross-component team based on previous definitions and additional research. The new definitions were also reviewed by the program integrity contractors that submit or use the data. The original status classifications (i.e., Suspect and Verified) ceased being used for submissions after August 2011. For all compromised numbers currently in the Compromised Numbers Checklist (CNC), the CNC contractor will maintain both the current and new status ratings.
In addition, CMS has added a new field to the Fraud Investigation Database (FID). In the new field, the ZPICs shall indicate whether the compromised provider number belongs to a provider who is 1) a “victim” of identity theft, 2) a “non-victim/perpetrator” of identity theft, or 3) “unknown” with regard to identity theft (i.e., the ZPIC cannot determine if the provider is a victim or a non-victim/perpetrator or the compromised number is not related to identity theft).
Where the ZPIC finds that there are compromised numbers that cannot be easily classified into the new definitions, CMS requests that the ZPIC send a new proposed definition to the CNC contractor. CPI will review the proposal and, as appropriate, will add the definition to those that ZPICs can use for the CNC spreadsheet. CMS will notify the ZPICs of the decision regarding the addition of new codes and all ZPICs shall begin using the definition in their reporting.
Approved UPIC users of the CNC web application must add and update information regarding compromised Medicare Providers and Beneficiaries that have been gathered through investigations into the CNC database on a timely basis using the CNC Web application. When a large amount of data needs to be created or updated, UPIC users can upload a data file in the appropriate template using the CNC Web Bulk Upload capability. The CNC Web application also enables users to search compromised numbers and generate reports.
16.7 – Participation in Model Development Activities
ZPICs may be required to participate in FPS workgroups and testing. ZPICs shall be innovative in the development of models. In addition, ZPICs shall be required to participate in Command Center meetings, as requested.
16.8 – Joint Operating Agreement
In carrying out the requirements of the SBJA, CPI must enter into contracts for purposes of developing predictive models, edits and other advanced algorithms designed to identify fraud, waste and abuse with regard to Part A and Part B Medicare claims. The contractors, also referred to as the Modeling Contractor and the Development Contractor, must establish effective relationships with the ZPICs. In order to ensure that all parties understand their individual and collective roles and responsibilities, CPI, the Modeling Contractor, Development Contractor, Medicare Administrative Contractors, and the ZPICs shall enter into Joint Operating Agreements (JOA). The JOA also defines the process the contractors must follow if one party believes another party is not following the requirements of the JOA. The specific content of the JOA may be modified based on circumstances the COR determines pertinent to the effective operation of the FPS. The contractors must be responsible for identifying, negotiating, and addressing any changes to the appropriate roles and responsibilities of JOA parties subject to the approval of the COR. JOAs must be updated at least annually. The JOA is effective upon signing by all parties. In most circumstances, the JOA must be signed by all parties no later than 60 calendar days following the award of the pertinent contract.
16.9 – Calculation of FPS Return on Investment
For purposes of assessing the effectiveness of the FPS, six outcome measures have been developed for which ZPICs shall submit provider-level data. The six outcome measures will be used in calculating the overall return on investment for FPS activities. Beginning October 1, 2015, the FPS return on investment will be calculated on a fiscal year (October 1st through September 30th) basis. The six outcome measures are:
· Total Dollar Amount of Overpayments Attributable to FPS Referred to MACs for Recovery,
· Total Amount Denied by FPS Attributable Auto-Denial Edits,
· Total Amount Denied by FPS Attributable Prepayment Edits,
· Value of FPS Attributable Law Enforcement Referrals Made,
· Amount in Suspension Account for FPS Attributable Payment Suspensions As of the Day of Reporting, and
· FPS Attributable Revocations Submitted to CMS and/or the Appropriate MAC.
Additional information, such as pertinent dates/time periods associated with the requested data, due dates for the reports, definitions regarding what specific information that will be provided to support the above six outcome measures, etc., will be disseminated to the ZPICs no later than 15 calendar days in advance of the due date for the requested data. The requested data is available through information currently maintained in the ZPIC’s case management system and/or received directly from the MACs through standard reports. Engagement meetings may be held with the ZPICs to discuss the data submission process, clarify specific information being requested by CPI, validate the ZPIC-submitted data, correct errors, identify gaps, etc. While the FPS return on investment will typically be calculated on a fiscal year basis, the ZPICs may be required to submit the pertinent data quarterly to facilitate validation efforts, account for any methodological changes, etc.
16.10 – Attribution of Administrative Actions to FPS
In order to effectively and efficiently carry out the various predictive modeling functions of the FPS, it is necessary that the National Provider Identifier (NPI) fields within the FID be complete and up-to-date. ZPICs shall enter the NPI in the FID for all new investigations and cases.
Savings resulting from administrative actions shall be attributable to the FPS when the administrative action was completed after the FPS lead became part of a ZPIC’s workload and one of the following conditions is met:
Condition 1: The provider/supplier was initially identified by the FPS.
Condition 2: The information or data in the FPS lead corroborated, augmented, and/or expedited the investigation.
ZPICs shall document whether an administrative action is attributable to FPS in the FID. The following table clarifies how the FID shall be updated based on several possible situations.
| Situation |
| Entry into FID Field Related to FPS |
| Entry into FID Notes |
FPS In Workload Date is prior to administrative action AND the provider/supplier was initially identified by FPS (Scenario #1) Note: This is relevant regardless of whether the investigation is related to the models in the ASR.
| “Initiated by an ASR” |
| No additional documentation |
FPS In Workload Date is prior to administrative action AND the information or data in the FPS lead corroborated, augmented, and/or expedited the investigation (Scenario #2) Note: this situation may occur at any time during the investigation.
| “Yes,” “Yes (Historical),” or “Supplemented by an ASR” |
| Briefly describe in the notes how the information in FPS corroborated, augmented, and/or expedited the investigation |
| The investigation was not initiated by FPS AND the FPS information did not augment, expedite, or corroborate the investigation |
| “No” |
| No additional documentation |
16.11 – Documenting Attribution of Administrative Actions
There are various scenarios where administrative actions and the associated savings are attributable to the FPS, as well as scenarios where administrative actions and associated savings are not attributed to the FPS.
16.11.1 – Administrative Actions Excluded from FPS Savings
The following describe situations where the savings associated with administrative actions are not attributable to the FPS, i.e., the savings are excluded from the total savings associated with the FPS:
Exclusion Scenario #1:
Administrative action already completed – The FPS lead identified a provider/supplier that was already under investigation by the ZPIC. The administrative action took place before the lead became part of the ZPIC workload. Specifically, the overpayment was referred to the MAC for recovery, the law enforcement referral was sent to law enforcement, the prepayment or auto-denial edit was sent to the MAC for implementation, the payment suspension was submitted to CMS, or the revocation package was submitted to the CMS prior to the lead becoming part of the ZPIC workload. The administrative action was not revised or resubmitted with new information from the FPS lead.
· Example: A ZPIC has an investigation based on proactive data analysis. Based on the data, the ZPIC worked with the MAC that is in their zone to create a prepayment edit. Typically, when a prepayment or auto-denial edit is sent to the MAC for implementation, the investigator uses the FPS edit codes when the edit is related to an FPS lead. Since the original edit was put in place in 2009 using non-FPS edit codes, this was prior to the FPS lead being added to the investigation in 2012.
· Example: A ZPIC has worked an investigation based on a complaint they received from an external source. Based on the actions completed during the investigation, the provider/supplier submitted a voluntary overpayment. Although the FPS lead corroborated the information in the complaint, the voluntary overpayment was submitted based on activity that occurred based on the external complaint source and prior to the FPS lead.
Exclusion Scenario #2:
Administrative action in process – FPS did not augment. The FPS lead identified a provider /supplier that was already under investigation by the ZPIC. The administrative action was in process before the lead became part of the ZPIC workload. For example, a law enforcement referral is near completion or a post-payment review is underway. The information and data in the FPS lead did not augment or expedite the administrative action.
· Example: Based on a complaint, the ZPIC opened an investigation and requested medical records. The ZPIC received the medical records and was in the process of completing the medical review when the FPS lead provided additional information. While the information and data in the FPS lead corroborated the findings, the administrative action was already in process and was not expedited because of the FPS lead.
· Example: The ZPIC opened an investigation in July 2012 and was in the process of developing a referral to law enforcement. In September 2012 the FPS lead was added to the workload. The FPS lead did not include any information or data that related to the issue in the referral to law enforcement.
Exclusion Scenario #3:
FPS issues not relevant to investigation. The FPS lead identified a provider/supplier that was already under investigation by the ZPIC. The information and data in the FPS lead did not corroborate, augment, or expedite the investigation. The information and data in the FPS lead related to issues separate and distinct from the issues considered in the ongoing investigation.
· Example: A complaint was received in 2012 related to a provider/supplier soliciting patients. The same month, an FPS lead was added to the workload on the same provider/supplier. The issues identified in the FPS were ultimately unsubstantiated and were unrelated to the issue in the complaint that resulted in the overpayment.
· Example: A provider/supplier was identified by one ZPIC (lead ZPIC) and then a second ZPIC was contacted and added as a participating partner on the investigation. The participating ZPIC put the provider/supplier on prepayment review based on the information provided by the lead ZPIC. The documentation refers to the lead ZPIC as the source of information. In contacting the lead ZPIC, it was determined that the lead ZPIC did not have an FPS lead with issues related to the investigation.
· Example: The ZPIC identified a lead and conducted an onsite visit. During the onsite visit, the ZPIC collected medical records and subsequently began the medical review. Nine months later, the FPS lead was added to the investigation. The information in the FPS lead was not relevant to the issue under investigation. The overpayment based on the medical review was referred to the MAC after the FPS lead was added to the investigation, but the action was started well before the FPS lead and the lead was not relevant.
16.11.2 – Administrative Actions Included in FPS Savings
The following describe situations where the savings associated with administrative actions are attributable to the FPS, i.e., the savings are included in the total savings associated with the FPS:
Inclusion Scenario #1
FPS identifies provider/supplier. The provider/supplier was initially identified through FPS. All actions occurred after the FPS lead became part of the ZPIC’s workload. In this situation, the FPS has a ruling of “SuspectNew.”
· Example: A ZPIC has worked with the MAC that is in their zone to create new codes that are FPS specific. When a prepayment edit is sent to the MAC for implementation, the investigator uses the FPS edit codes when the edit is related to an FPS lead. The FPS lead was ruled SuspectNew in the FPS and the prepayment edit was sent to the MAC for implementation with the FPS specific edit codes.
· Example: An FPS lead initiated a new investigation on a previously unidentified provider/supplier in 2012. The investigation was closed after education was given to the provider/supplier. As part of standard processes, the ZPIC continued to monitor the billing for this provider/supplier as described in PIM Chapter 4, §4.21. Upon reviewing the billing in 2013, the ZPIC determined that the provider/supplier did not change the billing patterns. The ZPIC opened a new investigation and implemented a prepayment edit. Though the ZPIC opened the second investigation as an existing, known provider/supplier, the provider/supplier was initially known because of an FPS lead.
· Example: An FPS lead is reviewed by the ZPIC. There is not an existing investigation on the provider. As part of the initial review of information, the ZPIC finds that there are concerns with the provider that are unrelated to the ASRs but of significant concern. The lead is ruled SuspectNew and administrative actions are attributable to FPS as the FPS initiated the investigation of the provider.
Inclusion Scenario #2A
FPS corroborates and augments existing investigation. The FPS lead identified a provider/supplier that was already under investigation by the ZPIC. The administrative action occurred after the FPS lead became part of the workload. The data and information in the FPS lead corroborated and augmented the investigation (e.g. added new information to the investigation).
· Example: The ZPIC was working on a data project focused on top diagnosis codes billed for compromised numbers and had not yet opened an investigation. The FPS lead was added to the workload. The information and data in the FPS lead corroborated the issue of billing compromised numbers for a provider/supplier that was identified in the data project. The FPS lead also augmented the issues by adding findings related to billing for beneficiaries with which the provider/supplier had no previous relationship and billing for beneficiaries also receiving dialysis.
· Example: The ZPIC received a complaint in April 2013 from an employee alleging that the home health agency is recertifying patients who do not need continued care. Also in April 2013, the FPS lead entered the ZPIC workload. The information and data in the FPS lead corroborated the allegation in the complaint and also augmented the investigation by adding issues related to the beneficiaries’ length of stay and care of dialysis patients. The onsite visit was subsequently ordered and ultimately an overpayment was referred to the MAC for recovery.
Inclusion Scenario #2B
FPS corroborates and expedites existing investigation. The FPS lead identified a provider/supplier that was already under investigation by the ZPIC. The administrative action occurred after the FPS lead became part of the workload. The information and data in the FPS lead corroborates and/or augments the information in the investigation. The ZPIC expedites the investigation.
· Example: A provider/supplier was identified through the ZPIC’s proactive data analysis. The FPS lead became part of the ZPIC’s workload. The information and data in the FPS lead corroborated the existing information. The ZPIC reprioritized the investigation as a high priority and requested medical documentation from the provider/supplier. The provider/supplier did not respond to the request and the overpayment was referred to the MAC for recovery.
· Example: The ZPIC had a provider/supplier under review due to a source other than the FPS since August, 2011. The FPS then identified two related providers/suppliers in March, 2012, one of which was the provider/supplier already under review. The information and data in the FPS lead corroborated the allegations that had been part of the initial review. The ZPIC subsequently re-prioritized the investigation and conducted an onsite visit in September, 2012. The onsite confirmed that the provider/supplier did not have an office. Therefore, the ZPIC referred the overpayment to the MAC in October, 2012 for recovery and submitted a revocation package to CMS.
Inclusion Scenario #2C
FPS corroborates existing investigation. The FPS lead identified a provider/supplier that was already under investigation by the ZPIC. The information and data in the FPS corroborated other information available (e.g. a complaint or proactive data analysis). The combination of information from FPS, complaints, data analysis, and other sources leads the investigator to determine the course of action. All administrative actions begin after the FPS information and data are added to the investigation.
· Example: In September 2011, the ZPIC identified a provider/supplier through proactive data analysis. In January 2012, the ZPIC received additional information related to the same provider/supplier from multiple sources: a complaint was received, the FPS flagged the provider/supplier, and an Office of Inspector General, Office of Evaluation and Inspections (OIG/OEI) study flagged the provider/supplier. The investigator used these three sources of additional information collectively to corroborate the issues, open an investigation, and determine the course of action. Subsequently, the ZPIC initiated activity that resulted in an overpayment referred to the MAC for recovery.
Exhibit 47.1 – Definitions for Compromised Beneficiary ID Numbers
| # |
| Definitions |
| Risk Level |
| B001 |
| If a beneficiary reports to CMS or one of its contractors via phone or in writing that their Medicare ID Card Lost. |
| Low |
| B002 |
| If a contractor discovers a breach involving Medicare beneficiary numbers. |
| Low |
| B003 |
| Beneficiary reports notification of lost SSN from other institution. |
| Low |
| B004 |
| Beneficiary ID is tied to a provider ID (NPI, PTAN) for a verified compromised provider for whom 50 - 70% of patients billed have been verified as compromised. (1) |
| Low |
| B005 |
| Beneficiary is being billed for inappropriate services by out of state providers who are outside the established allowable distance. (1) |
| Medium |
| B006 |
| Beneficiary ID is tied to a provider ID (NPI, PTAN) for a verified compromised provider for whom 71 - 90% of patients billed have been verified as compromised. (1) |
| Medium |
| B007 |
| Beneficiary did not receive one of the services on their MSN and 1-800 CSR opens a BIU. |
| Medium |
| B008 |
| ‘Suspect' and 'historical' beneficiary IDs "grandfathered in" as a result of new classification rules. |
| Medium |
| B009 |
| Beneficiary number is billed by a confirmed false front provider or shell lab. |
| High |
| B010 |
| Law enforcement confirms that an ID has been sold or the beneficiary is receiving some form of consideration. |
| High |
| B011 |
| As a result of an investigation, beneficiary ID was identified as stolen and a provider attempted to use the ID inappropriately (claim was submitted after the date the number was compromised). |
| High |
| B012 |
| Beneficiary ID was lost, stolen, or part of a breach, and it has been confirmed that at least one inappropriate service was billed (claim was submitted after the date the number was compromised). |
| High |
| B013 |
| Beneficiary did not receive 2+ services on their MSN from different providers and there are 2+ BIUs on at least one of the providers. (1) |
| High |
| B014 |
| Beneficiary tied to a provider ID (NPI, PTAN) for a verified compromised provider who has signed a related affidavit. |
| High |
| B015 |
| Beneficiary ID is tied to a provider ID (NPI, PTAN) for a verified compromised provider for whom more than 90% of `patients billed have been verified as compromised. (1) |
| High |
| B016 |
| Verified' beneficiary IDs "grandfathered in" as a result of new classification rules. |
| High |
(1) CMS will be the primary user of these categories and will continually perform data analysis to detect compromised numbers that will meet these criteria.
Exhibit 47.2 – Definitions for Compromised Provider ID Numbers
| # |
| Definitions |
| Risk Level |
| P001 |
| Provider ID is lost, stolen, or part of a security breach. |
| Low |
| P002 |
| Provider who bills a high or medium risk suspected compromised beneficiary. |
| Low |
| P004 |
| Provider ID has been sold or is allegedly receiving kick-backs, or is purposely submitting fraudulent claims – but who has not yet been confirmed by Law Enforcement. |
| Medium |
| P005 |
| Provider who files a complaint but has not yet filed an affidavit. |
| Medium |
| P006 |
| Compromised provider who recanted an affidavit he originally signed. |
| High |
| P007 |
| Provider submitted an affidavit stating that he/she was not aware of suspect billing charges. |
| High |
| P008 |
| Provider submitted an affidavit stating that he/she is not aware of a new ID or new location associated with him. |
| High |
| P009 |
| Provider whose ID has been sold, is receiving kick-backs, or is purposely submitting fraudulent claims - and those facts have been confirmed by Law Enforcement. |
| High |
| P010 |
| Through investigation, it is determined that the provider location is not legitimate. |
| High |
| P011 |
| 'Suspect' and 'historical' provider IDs "grandfathered in" as a result of new classification rules. |
| Medium |
File details come from the government source that posted it. Updated .