Payment Record Processing

The purpose of the PRP is to assist with the creation of statistics from Medicare Part A claims. These statistics are used by the Centers for Medicare and Medicaid Services (CMS) actuaries to compile various Medicare financial reports and recommendations to CMS management. Medicare Part A claims files are passed to PRP by the Medical Quality Assurance (MQA) application operated by CMS. 

PRP processes the Part A claim files and creates skeleton records which only contains claim codes and statistics. No information about Medicare beneficiaries is moved to this copy. The Part A claim skeleton records created by PRP are passed to the Statistical Tabulation System (STS). 

The PRP contains Medicare beneficiary information such as: name, mailing address, date of birth (DOB), social security number, medical records (healthcare facility type, treatment descriptors, treatment costs/charges and medical codes), medical notes, and claim account numbers.

The information is not collected from CMS employees and/or CMS direct contractors. The information is provided by the MQA application, which is a component of the National Claims History (NCH).  NCH is a FISMA authorized system and maintains a separate PIA.

Please note that all processing performed by PRP is accomplished by PRP batch application programs. In simple terms, these application programs process Part A Medicare claims history to create the skeleton record output files without human intervention. No user interface or access to PRP programs is provided by this application. Because of this constraint, manual changes cannot be performed to programs and data within the PRP application. This also means that there are no user credentials to be captured by PRP processes.

The PRP is a relatively small application internal to CMS that supports the compilation of statistics from Medicare Part A claims history. Part A claims are classified as institutional and include the inpatient/skilled nursing facility, hospice, certain outpatient and home health type claims. 

Beneficiary information is not directly collected by the PRP.  The input data provided to PRP comes from the MQA application, a component of the NCH, which is a FISMA authorized application that maintains its own PIA.  

The PRP processes the Part A input from MQA to create a ‘skeleton’ record, a discreet subset of each Part A claim. Skeleton records created by PRP are accumulated into output files on a monthly and quarterly basis according to a defined schedule. 

Skeleton files created by PRP are a main input to the STS, which is a CMS- internal application that supports statistical report generation and contains no PII. The PRP provides no user interface and supports no user-staff. STS is the only user of files created by the PRP. 

All interfaces between PRP and STS are flat-file based.

Please note that all processing performed by PRP is accomplished by PRP batch application programs. In simple terms, these application programs process Part A Medicare claims history to create the skeleton record output files without human intervention. No user interface or access to PRP programs is provided by this application. Because of this constraint, manual changes cannot be performed to programs and data within the PRP application. This also means that there are no user credentials to be captured by PRP processes.

• Social Security Number
• Name
• Medical Notes
• Date of Birth
• Mailing Address
• Medical Records Number
• Other - Race and Sex

The PRP creates skeleton records from Part A Medicare claims history. The purpose of PRP skeleton records is to store data concerned about the Medicare business/process and not to store data concerned about the beneficiary/patient. However, the single exception is the Medicare Claim Numbers, which contain the SSNs of the beneficiaries/patients. The Medicare Claim number is placed in the skeleton records to support identification of the specific provider claim if it becomes necessary to validate the data in the skeleton record; in other words to authenticate the statistics being collected.  The SSN is not used to identify the beneficiary.    

The STS application is the only other CMS application that has access to the skeleton files created by PRP. PRP and STS are CMS-internal applications. Neither application supports an interactive user interface. Both applications are batch data processes. Based on the rules defined for the SSN Reduction Initiative (SSNRI), PRP and STS are not required to support SSN to MBI translation.

Beneficiary information is not collected from the beneficiaries by the PRP application. The PRP processes Medicare Part A claims history files received from the MQA component of the NCH.  

As explained, MQA is a component of NCH. NCH is a FISMA authorized application and is covered by a separate PIA. NCH is therefore responsible for the providing methods for individuals to opt-out of the collection or use of their PII.

Beneficiary information is not directly collected from the beneficiary by the PRP application. 

The PRP receives and processes MQA Medicare Part A claims history files created for the NCH. As mentioned above, MQA is a component of NCH.  When major changes occur, NCH is, therefore, responsible for notifying and obtaining consent from individuals, whose PII is in NCH. 

• Users: CMS mission requirements requires access to the PII.
• Administrators: Administrators would have access to PII for the management of system user access.
• Developers: Developers may have limited access, if any, to PII to provide PRP application enhancements and testing of enhancements.
• Contractors: CMS direct contractors may have the role of administrator or developer. If so, then the access to PII would be in line with the explanations for administrators and developers.

The least privilege standard is utilized for all access to the PRP.  Access Control Lists are used to filter access and control access based on an individual's assigned duties.

Account management mechanisms are established for PRP to identify account types (i.e., individual, group, and system); conditions for group membership are established; and associated authorizations are assigned.

PRP administrators, developers, and contractors are granted access based on the assigned duty and intended system use.

The least privilege standard is utilized for all access to the PRP.  Access Control Lists are used to filter access and control access based on an individual's assigned duties.

Logical access controls (e.g., user name and security token, and security software controls) and role-based access are established for PRP to ensure that only authorized individuals can access PRP.

The PRP project manager notifies the CMS PRP Government Task Leader (GTL) to remove or revoke user access privileges that are no longer required.

All CMS employees and direct contractors are required to complete annual CMS Information System Security and Privacy Awareness Training. 

PRP follows the HHS Record Management and CMS Baltimore Data Center Storage Management Guidelines, which are consistent with the HIPAA record retention requirements and the National Archives and Records Administration (NARA) General Records Schedules (GRS) that provide federal retention requirements. 

PRP records may be retained longer, if they are needed for administrative, legal, audit, or other operational purposes.

Administrative controls secure PII in PRP by limiting access to PII to a small number of authorized users by using role-based access permissions and providing annual security awareness and privacy training PRP application users. 

Technical Controls secure PII in PRP by limiting access to CMS authorized users by requiring a user name combined with a numeric security token for system access; maintaining firewalls; encrypting transmission of information; and implementing intrusion detection and prevention software. 

Physical Controls secures PII in PRP by preventing physical access to CMS IT resources through maintaining a building security guard force; requiring identification badges for building access; and implementing video monitoring of CMS facilities.