Skip to main content

Payment Recovery Information System

Privacy Impact Assessment (PIA) published by CMS as an Operating Division of the U.S. Department of Health and Human Services

Date signed: 1/10/2024

PIA Information for Payment Recovery Information System
PIA QuestionsPIA Answers
OPDIV:CMS
PIA Unique Identifier:P-3093439-148787
Name:Payment Recovery Information System
The subject of this PIA is which of the following?Major Application
Identify the Enterprise Performance Lifecycle Phase of the system.Operate
Is this a FISMA-Reportable system?Yes
Does the system include a Website or online application available to and for the use of the general public?No
Is this a new or existing system?Existing
Does the system have Security Authorization (SA)?Yes
Date of Security Authorization7/14/2022
Indicate the following reason(s) for updating this PIA. Choose from the following options.PIA Validation (PIA Refresh/Annual Review)
Describe in further detail any changes to the system that have occurred since the last PIA.Additional business rules and other workflow enhancements were implemented in Release 7 (R7) related to Payment Error Calculation (PEC) and Medical Record Review Determination (MRRD) business process workflow changes.
Describe the purpose of the system

The CMS's Center for Program Integrity (CPI)/Division of Prescription Drug Audits (DPDA), with the help of a Recovery Audit Contractor (RAC) and a Data Validation Contractor (DVC), identifies and justifies scenarios where improper payments are likely to have been made in Medicare Part D transactions. Every time a beneficiary fills a prescription under Medicare Part D, a prescription drug plan sponsor must submit a summary record called the PDE data to CMS. This is initiated by evidence found in a partial sampling of existing Prescription Drug Events (PDE) records and targeted industry research performed by the RAC and includes clear criteria for identifying these situations within an audit framework. 

This package of reviewed research is called a New Audit Issue Review Package (NAIRP). Each new audit issue will be specific in context and purpose. Examples of approved NAIRPs are duplicate payments for the same services, or payments that were erroneously processed for excluded providers.

If the scenario is approved for auditing by CMS, transactions matching the criteria from the NAIRP are audited using the Supporting Documentation and PDE records to verify their validity in the specific context. This process, in which the NAIRPs are used as criteria in auditing actual PDE records, is called Improper Payment Review Package (IPRP).

Payment Recovery Information System (PRIS) helps to manage and safeguard the documents, record decisions, and automate workflow related to these business processes. Depending on the IPRP audit findings and the outcome of any appeal(s) of those findings (three levels of appeal are possible), they then set to recovering or restoring any totals that are found to be incorrect as a result; these outcomes that are referred to as either an offset or a credit.

In addition to the Medicare Part D Recovery Audit Program, an independent contractor for CMS conducts Recovery Audit Program (RADV) audits (Evaluate Payment Error Calculation (PEC) and Medical Record Review Determination (MRRD) Appeals and Disputes and make a final determination in the PRIS system) to ensure the integrity and accuracy of risk adjusted payments. During RADV audits (PEC and MRRD Appeals analysis), the independent contractor examines enrollee medical record documentation to validate Hierarchical Condition Categories (HCCs)/diagnosis data submitted by MA organizations to support claims for enhanced Medicare payment. If the audited medical record does not support the HCC/diagnosis, the audited HCC is found to be discrepant, and errors are calculated and reported to the Medicare Advantage (MA) organization. Based on this discrepancy, it is the obligation of CMS to recover all overpayments from the MA organizations for each overpayment error identified. The Medicare RADV program was created to identify and correct past improper payments to Medicare providers and implement procedures to help CMS, Medicare carriers, fiscal intermediaries, and Medicare Administrative Contractors implement actions that will prevent future improper payments. Communication about audit results and trends leads to continuous process improvement and more accurate payments and helps plan sponsors correct issues in a timely manner.

 

Describe the type of information the system will collect, maintain (store), or share. (Subsequent questions will identify if this information is PII and ask about the specific data elements)

 The system collects e-mail address, phone numbers, medical notes, taxpayer ID, mailing address, medical records number, CMS Hierarchical Condition Category (HCC) and Enrollee ID, first and last name, date of birth, sex, HICN, provider National Provider Identifier (NPI) (identifier).

The following pieces of data are uploaded to PRIS for NAIRP:
- The New Audit Issue document by the RAC.
- Supporting example PDE records provided by CMS.
- New Audit Issue review submitted by the DVC.

The IPRP will contain:
- PDE records for the year and scope being audited as specified by the approved NAIRP.
- DVC Validation Finding Reports.
- RAC Rebuttal Letter, if applicable.
- Notification of Improper Payment (NIP) letters from RAC to Part D Plan Sponsors.
- Appeal Supporting Documentation
- Appeal Decision Letter(s).

All three levels of appeal may include:
- Appeal responses, if any.
- Appeal review and findings report (one per level), if any.

The MRRD package will contain:

- Medical Records
- Medical Reports
- Enrollee ID

- Health Maintenance Organization (HMO) ID

- RADV Year
- CMS-Hierarchical Condition Category (HCC)

- Other Supporting Documents, Cover sheet, Audit Report, and Justification.

The PEC package will contain:

- HMO ID

- RADV Year

- MA Contract Name

- SAS Calculation documents and results
- Supporting Documents, Cover sheet, Audit Report, and Justification.

All this information is stored within PRIS for the length of time appropriate to satisfy the CMS Records Management requirements, currently seven years from when it was first uploaded into PRIS.

The management and maintenance of the user information to create user accounts for the PRIS User Interface (UI) is handled within CMS’s Enterprise User Administration (EUA) system. Usernames and passwords are collected by CMS Enterprise Portal (CEP) separate from PRIS and is covered by its own PIA.

Provide an overview of the system and describe the information it will collect, maintain (store), or share, either permanently or temporarily.

There are four major business processes that the PRIS application was created to help facilitate and manage between stakeholder actions.

The first is investigating and creating an NAIRP. This investigative and reporting work is performed offline by the RAC, with the NAIRP being uploaded to PRIS for Division of Plan Oversight and Accountability (DPOA) and the DVC to review and comment on. The NAIRP will contain:
- The New Audit Issue document submitted by the RAC, describing the expected issue where improper payments were made and the research explaining why this is an appropriate audit issue.
- Supporting example PDE records contain summary data related to all Medicare Part D expenditures, and include information on the patient (first and last name, date of birth, sex, HICN), provider National Provider Identifier (NPI) (identifier) and statistical information on the prescribed drug.
- New Audit Issue review submitted by the DVC
These stakeholders perform a series of reviews and collaboration on the path to approval for the NAIRP. Approval of the NAIRP by CMS is processed off-system, with the documents submitted to PRIS at each process gateway. The outcome is recorded in PRIS and is used to generate an approved Audit Code that will be available for the IPRP workflow process.

The second major business process is the IPRP. This process is where the RAC audits the relevant PDE data to determine if improper payments were made over target years and what totals, if any, should be processed as an offset or a credit. 
The IPRP will contain:
- PDE records.
- DVC Validation Finding Reports
- RAC Rebuttal Letter, if applicable
- Notification of Improper Payment (NIP) letters from RAC to Part D Plan Sponsor
- Appeal Supporting Documentation
- Appeal Decision Letter(s)

The third major business process is MRRD Appeals. The MRRD Appeals workflow process starts in PRIS when the package data (single Dispute ID) and documents become available in PRIS.

  • The MRRD Reconsideration Coordinator (RC) starts off by reviewing the package documents/data and identifies the package as eligible or not eligible for the dispute in question.
  • The MRRD RC uploads relevant documents, provides their recommendation to RO, and then routes the package to MRRD RO.
  • The MRRD Reconsideration Official (RO) reviews the package data and records his/her decision to agree or disagree with the Technical Writer response.
  • The MRRD RO uploads relevant documents and makes a final ruling either to uphold or overturn the original disposition.

The fourth major process is PEC Appeals. The PEC Appeal workflow process starts in PRIS when the package data (Appeal ID) and documents become available in PRIS.

  • The PEC Reconsideration Reviewer (RR) starts off by reviewing the package documents/data and identifies the package as eligible or ineligible for the appeal in question.
  • The PEC RR completes Statistical Analysis Software (SAS) calculation and records the SAS calculated total.
  • The PEC RR routes the package to Independent Statistical Consultant (ISC).
  • The ISC conducts a quality review of the package by recording SAS total and supporting documentation and routes to PEC RR. This repeats until the package is ready to be routed to PEC Reconsideration Official (RO).
  • The PEC RO may choose to do additional SAS calculation, uploads supporting documentation, uploads a final decision letter and makes a final ruling disposition either to uphold or overturn the original payment error in the package.
Does the system collect, maintain, use or share PII?Yes
Indicate the type of PII that the system will collect or maintain.
  • Name
  • E-Mail Address
  • Phone Numbers
  • Medical Notes
  • Taxpayer ID
  • Date of Birth
  • Mailing Address
  • Medical Records Number
  • Other - Sex; Medicare Beneficiary Health Care Insurance Claim Number (HICN); Provider NPI; Medical Records; CMS Hierarchical Condition Category (HCC); Enrollee ID.
Indicate the categories of individuals about whom PII is collected, maintained or shared.Patients
How many individuals' PII in the system?1,000,000 or more
For what primary purpose is the PII used?

Example PDE records are used to justify the existence, volume, and validity of a particular audit issue during the creation of an NAIRP. This will be a smaller random sub-set of the total PDE records available within a given time frame.

The PDE Records are uploaded by the RAC as part of the IPRP audit based on the criteria and volume required by the associated approved NAIRP. These details help auditors determine whether the payment was properly done, or improper, as the name suggests.

Supporting Documentation is provided by the Plan Sponsors through the UI, and is used as reference to make the decisions for each audit based on the relevant NAIRP.

The only PII in the system are contained within the PDE records and Supporting Documentation. This data is not extracted by or used in any other way by the system.

In the PEC and MRRD Appeals business process workflows, the documents like the Medical Records and other supporting documents and reports contain PII that are only used to evaluate the appeals by the independent auditors of these appeals and are stored in PRIS for a period as determined by CMS's records retention schedule.

The user names and passwords are handled through the login procedure of ePortal via EUA prior to PRIS, and do not get recorded by the PRIS system.

Describe the secondary uses for which the PII will be used (e.g. testing, training or research)There is no secondary use for which PII is used.
Describe the function of the SSN.Not Applicable
Cite the legal authority to use the SSN.Not Applicable
Identify legal authorities​ governing information use and disclosure specific to the system and program.Sections 1842, 1862, (b) and 1874 of Title XVIII of the Social Security Act (The Act) 42 U.S.C. 1395u, 1395y (b), and 1395kk(a) and 1395ll5 U.S.C. 301 Departmental Regulations and 5 U.S.C. 552a
Are records on the system retrieved by one or more PII data elements?No
Identify the sources of PII in the system: Directly from an individual about whom the information pertains
  • Hard Copy
  • Mail/Fax
  • Email
  • Other - Other - Data/documents received from an integrating system - Centralized Data Abstraction Tool (CDAT) system.
Identify the sources of PII in the system: Government Sources
  • Within the OPDIV
  • Other HHS OPDIV
Identify the sources of PII in the system: Non-Government Sources
  • Members of the Public
  • Private Sector
Identify the OMB information collection approval number and expiration dateNot Applicable
Is the PII shared with other organizations?No
Describe the process in place to notify individuals that their personal information will be collected. If no prior notice is given, explain the reason.No prior notice is given as the PRIS system does not collect PII directly from the individuals. This information is provided as approved business use from the original collection source under CMS’ use as part of PDEs and Plan Sponsor's submissions.
Is the submission of the PII by individuals voluntary or mandatory?Voluntary
Describe the method for individuals to opt-out of the collection or use of their PII. If there is no option to object to the information collection, provide a reason.There is no option to opt-out of the collection or use of PII within PRIS because the data used in PRIS has already been collected from other CMS systems. This data does not involve direct collection or sharing of PII with anyone other than those involved in auditing these payments as part of the original agreement to participate in the Medicare Part-D program.
Describe the process to notify and obtain consent from the individuals whose PII is in the system when major changes occur to the system (e.g., disclosure and/or data uses have changes since the notice at the time of original collection). Alternatively, describe why they cannot be notified or have their consent obtained.The PII within PRIS is provided by CMS on behalf of those the PII relates to. Participants are given the choice and informed that the data is necessary and may be later used when being audited in this way to enroll in a Medicare Part D plan. Because PRIS only receives data collected by that process through a different system, there is no process in place for notifying individuals or obtaining their consent. 

If a major change occurs, it would be the responsibility of the plan sponsor to provide written communication/agreement that data is required to be reported to CMS when requested for various legal matters. This would include audits.
Describe the process in place to resolve an individual's concerns when they believe their PII has been inappropriately obtained, used, or disclosed, or that the PII is inaccurate. If no process exists, explain why not.Any individual who has concerns should contact CMS through the Office for Civil Rights (OCR), which can be done by visiting https://www.hhs.gov/hipaa/filing-a-complaint/. Information about the ability to file a complaint is available at this same address.

In the event that the Internet is not accessible, and you have questions about this topic, CMS can be reached by phone at 1-800-MEDICARE (1-800-633-4227). When calling, ask to speak to a customer support rep about Medicare’s Privacy Notice. TTY users may call 1-800-486-2048.

Individuals who wish to file a complaint directly without access to the Internet may directly call OCR at 1-800-368-1019. TTY users may call 1-800-537-7697 to file their complaints.
Describe the process in place for periodic reviews of PII contained in the system to ensure the data's integrity, availability, accuracy and relevancy. If no processes are in place, explain why not.The PRIS application does not collect PII directly and does not address data integrity within documents / packages. All files uploaded are virus scanned and secured to ensure that changes or unauthorized disclosures are prevented.

CMS has a National Institute of Standards and Technology (NIST)-compliant continuous monitoring program to ensure system integrity and availability for all data submitted to PRIS. Yearly testing of the system is required to review and update this process for disaster recovery purposes. Back-ups are in place to ensure information is readily available, even if one or more servers should fail.
Identify who will have access to the PII in the system and the reason why they require access.
  • Users: Users are within two distinctions (NAIRP and IPRP), and each have access to perform their respective business functions: Business Owner - This stakeholder group performs a review of NAIRP and IPRP, makes a final decision on disputed IPRPs, initiates IPRP Offset Process, and submits decision information for Level 3 appeals (on behalf of Office of Administration (OA) users – Level 3 Appeal Decision Makers) within PRIS. RAC - Responsible for submitting nAew audit issue and improper payment packages for a Part D PDE within PRIS. DVC - They are responsible for validating the accuracy of the Improper Payment Package submitted by the RAC and reviewing the new audit issue submitted by the RAC as part of the NAIRP. Level 1 Appeal Users - This CMS contractor to perform tasks as the Level 1 Appeals contractor. They are tasked to review and provide decisions on Level 1 Appeals submitted by the Part D Plan Sponsor. They also send Notification of Improper Payment (NIP) packages to the Part D Plan Sponsor. Level 2 Appeal Users - These users review Level 2 Appeals submitted by the Part D Plan Sponsor and provide a decision on the appeal. This role is fulfilled by CMS employees.
  • Administrators: The System Administrators and Infrastructure Hosting and Centralized Connectivity Services (IHCCS) contractor will perform application oversight and manage related helpdesk tickets for all users.
  • Developers: The staff necessary to develop, test, validate, and support the developed system.
  • Contractors: Contractors (Recovery Audit Contractors, RAC and Data Validation Contractors, DVC) are direct contractors who operate on behalf of the agency, and they use the agency's credentials when doing so. the Part D RAC and DVC review Prescription Drug Event (PDE) records by querying the Integrated Data Repository (IDR) based on the audit scope to pull together improper payment packages to send to Plan Sponsors and pull information from Plan Sponsors information that is submitted during appeal and Request for Information (RFI) processes. RAC - They are responsible for submitting new audit issue and improper payment packages for a Part D PDE within PRIS. DVC - They are responsible for validating the accuracy of the Improper Payment Package submitted by the RAC and reviewing the new audit issue submitted by the RAC as part of the New Audit Issue Review Package (NAIRP).
Describe the procedures in place to determine which system users (administrators, developers, contractors, etc.) may access PII.All user roles (Business Owner, Level 1, Level 2 Appeals Users, PEC and MRRD end users) are approved by the PRIS Business Owners through the appropriate procedures within EUA. Each user is provided the specific security EUA role that is appropriate for their needed business role.

Administrators are authorized by the business owners and identified through the application contract. Their access is limited to support functions in support of the helpdesk process.

Those in the developer role are not provided direct access to any production data that may contain PII.

The RAC, DVC and Level 1 Users are designated by the Business Owners through the appropriate procedures dictated by each group’s contract.
Describe the methods in place to allow those with access to PII to only access the minimum amount of information necessary to perform their job.

Access to the NAIRP and IPRP data is limited by EUA role and through the business process where visibility is limited to current actions necessary. Once the work is completed by any user within the business process workflow, the package visibility is removed. Furthermore, access to PRIS is limited to users through CMS network access only, either directly or via Virtual Private Network (VPN). Further methods to ensure that role-based access is kept segregated can be found in EUA’s PIA.

The PEC and MRRD users can indefinitely view package information if they have the appropriate user role in PRIS to access PEC and MRRD package data and documents and the package data/documents are available in PRIS. The users however can modify the package only when appropriate to do so depending on the workflow state of the package and limitations set forth in the business workflow.

Identifying training and awareness provided to personnel (system owners, managers, operators, contractors and/or program managers) using the system to make them aware of their responsibilities for protecting the information being collected and maintained.All users are required to take the annual CMS role-based privacy and security awareness training. Internal and external security and privacy staff attend the CMS quarterly security awareness training and meetings throughout the year to keep abreast of relevant and timely security issues.
Describe training system users receive (above and beyond general security and privacy awareness training)Administrators and Developers receive role-specific yearly training for role-based security.
Do contracts include Federal Acquisition Regulation and other appropriate clauses ensuring adherence to privacy provisions and practices?Yes
Describe the process and guidelines in place with regard to the retention and destruction of PII. Cite specific records retention schedules.CMS has employed a records retention schedule referred to as a Bucket Approach, or otherwise known as flexible scheduling. More about this approach, what it means, and how it is applied at Federal Agencies can be found on the National Archives (NARA) website at: https://www.archives.gov/records-mgmt/faqs/flexible-scheduling.html

Since the PDE records and Supporting Documentation in packages that are used for reviewing the compliance and ensuring the integrity of Medicare programs, they are considered part of Bucket 3: Financial Records within the records schedule for CMS (DAA-0440-2015-0004). All files within this grouping are considered Temporary; they do not have to be transferred for Permanent storage at NARA once the amount of time they must be retained is complete. All files within this category must be destroyed after seven (7) years old or when no longer needed for agency business, whichever is later.

Every January, relevant files for the previous calendar year are reviewed for deletion based on the date of their creation. For example, in January of 2018, all the packages created from January to December of 2010 will be reviewed. Packages that are currently part of a legal discovery or otherwise related to active agency business as determined by the Business Owners (BO) will be removed from consideration and kept. All exceptions will be included in the following year’s review. The rest of these packages are then deleted and removed by the system administrators.
Describe, briefly but with specificity, how the PII will be secured in the system using administrative, technical, and physical controls.The PRIS data resides in the CMS Enterprise content management (ECM) environment which is housed in the Baltimore Data Center behind locked doors and is only accessible by approved personnel. All policies relating to information security are addressed in the CMS organizational security and privacy policy and procedures, including the CMS policy for Information Security Program and CMS Acceptable Risk Safeguards (ARS). Technical controls include access controls which are established to limit operations and maintenance user access to the data based on role-based design and assigned on a need-to-know basis. Data is protected by the mainframe security configuration and Resource Access Control Facility (RACF) controls.

The application is regularly assessed using the CMS security policies and controls that include administrative, technical, and physical controls. All controls are tested within a 3-year period as part of annual Federal Information Security Modernization Act of 2014 (FISMA) evaluations.