Medical Review Management System
Date signed: 7/15/2025
| PIA Questions | PIA Answers |
|---|---|
| OPDIV: | CMS |
| PIA Unique Identifier: | P-9893298-916723 |
| Name: | Medical Review Management 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 |
| Identify the operator: | Agency |
| Is this a new or existing system? | New |
| Does the system have Security Authorization (SA)? | No |
| Planned Date of Authorization | 7/28/2025 |
| Describe the purpose of the system | Medical Review Management System (MRMS) is designed to streamline the validation audits of Skilled Nursing Facility (SNF) Minimum Data Set (MDS) assessment data elements by providing all necessary tools in one centralized platform. The system facilitates the entire validation audit process, including: Uploading MDS assessment records for audit. Providing a portal for uploading medical chart documentation. Storing medical chart documentation used to validate MDS assessment data elements. Assigning reviewers to audits. Providing an audit tool for reviewers to document audit findings. Calculating Inter-Rater Reliability (IRR) statistics between a lead reviewer and team reviewer findings. Capturing communications between the validation audit team and SNFs to document when audit notifications and follow-ups were conducted. Tracking audit progress and processing audits efficiently. Outputting audit finding datasets for further analysis. Storing SNF audit finding reports. |
| 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 MRMS stores all necessary information for conducting SNF validation audits. This includes: SNF Information: Facility name, Centers for Medicare & Medicaid Services (CMS) certification number (CCN), mailing address, phone number, and points of contact (POCs), including POC names, email addresses and phone numbers. Validation Audit Team Data: Names, email addresses, and roles of team members who can access the MRMS. Communication Documentation: Dates and outcomes of audit notifications, follow-ups, reminders, and report notifications. MDS Assessment Data Elements: Details used to identify specific MDS assessment records, including the assessment ID, SNF CCN, assessment type, resident details (name, sex, DOB, resident id, resident Medicare number, admission, entry, discharge, and reference dates), and elements being audited (e.g., pressure ulcer and resident function data). Medical Chart Documentation: Submitted by SNFs for audit purposes and accessed by reviewers. Medical documentation is submitted by SNFs. It may include many Personal Identifiable Information (PII) variables that have been submitted with the documentation; however, the PII information in the medical chart will not be used by the team. Reviewer Guidance Documentation: Educational material that guides reviewers through the audit process. Reviewer Audit Findings: Yes/no variables indicating if medical chart documentation supports MDS assessment data elements, and value variables for selecting supported MDS assessment values when documentation does not match. Individual SNF Audit Reports: Stored in the MRMS after audit completion. All data is maintained in the MRMS until the end of the contract or until the Contracting Officer’s Representative (COR) directs its destruction. Social Security Numbers may be inadvertently collected by the MRMS system. |
| Provide an overview of the system and describe the information it will collect, maintain (store), or share, either permanently or temporarily. | The information stored in the MRMS is collected for various purposes: SNF Information: Most of this data is facility-level, gathered from the Centralized Data Repository (CDR) and stored in the MRMS. This data identifies SNFs selected for audit, is used to connect sampled MDS assessment records to the selected SNF and provides needed information for follow up with non-responsive SNFs (those that do not respond to requests for points of contact (POC) information). Additional individual-level data includes SNF POC names, email addresses, and phone numbers, gathered directly from SNFs for communication during the audit. Validation Audit Team Data: Entered by the IT development/maintenance team, this data ensures access is limited to approved users, that approved users can only access the data they need to conduct their work, tracks user activity, and provides a mechanism to notify users of work activity assignments. Communication Documentation: Auto-generated by workflows and entered by users, this data is collected and stored as a reference during follow-up communications. It also serves as evidence that SNFs were notified of audits, follow-ups were conducted with non-responsive SNFs, audit reminders were sent out, and individual audit reports were provided to SNFs. MDS Assessment Data: Gathered at the individual resident level from the CDR, some data elements identify the resident medical charts that correspond to sampled MDS assessment records. This information helps SNFs identify and gather the correct medical chart documentation. Identifiers include assessment ID, assessment type, and resident identifiers (name, sex, DOB, admission, entry, discharge, and reference dates). The other data elements included in the MDS assessment data are those being audited; they include pressure ulcer and resident function data. Medical Chart Documentation: Collected from SNFs, medical chart documentation is reviewed to determine if MDS Assessment data elements are supported by the resident medical chart. This documentation may include various data, some of which may be unnecessary for the audit. Reviewer Guidance Documentation: Uploaded by the IT development/maintenance team, this reference material assists reviewers during the audit process. Reviewer Audit Findings: This data captures reviewer audit results for each individual MDS record at the data element level. Individual SNF Audit Reports: Generated in the CDR and linked to associated SNFs within the MRMS, these PDF reports include both facility-level and individual-level data. The MRMS acts as a repository for all SNF validation audit reports. Social Security Numbers may be inadvertently collected by the MRMS system. |
| Does the system collect, maintain, use or share PII? | Yes |
| Indicate the type of PII that the system will collect or maintain. |
|
| Indicate the categories of individuals about whom PII is collected, maintained or shared. |
|
| How many individuals' PII in the system? | 10,000-49,999 |
| For what primary purpose is the PII used? | Resident names, medical record numbers, dates of birth, and sex are collected to identify medical charts for validating MDS data elements. These details are given to selected SNFs to submit the correct medical chart documentation. Medical notes and therapy records are gathered to validate the audited data elements. Name, phone numbers, and email addresses from selected Skilled Nursing Facility points of contact (POCs) are gathered and stored within the system so that the validation team can reach a POC during the audit process. |
| Describe the secondary uses for which the PII will be used (e.g. testing, training or research) | No secondary use. |
| Describe the function of the SSN. | SSNs have no function and are not collected. The SSN could be inadvertently included in the medical chart documentation submitted to the MRMS by Skilled Nursing Facilities (SNFs). To avoid this occurring, the audit notification will explicitly indicate that SNFs not include the SSN in any of the medical charts they submit. Even with an explicit statement, there may be documentation submitted that includes the SSN. To monitor for and mitigate instances of the SSN being submitted accidentally, the documentation coordinator will review incoming documentation to verify that the SSN was not included in the documentation. If documentation includes the SSN, the documentation coordinator will complete the following actions: 1) notify the SNF via email that SSNs were erroneously submitted with documentation and remind them that SSNs should not be submitted with medical chart documentation, 2) redact SSNs from the documentation, when possible, 3) if it is not possible, contact the SNF and request re-submission of medical chart documentation without inclusion of SSNs. In the event that the documentation intake coordinator does not identify inclusion of SSNs, but a reviewer identifies SSNs during their review, they will return the record to the documentation coordinator. The documentation coordinator will follow the steps listed above. |
| Cite the legal authority to use the SSN. | Protecting Access to Medicare Act of 2014 (Pub. L. 113-93) authorized the SNF Value-Based Purchasing (VBP) Program by adding section 1888(h) to the Social Security Act (the “Act”). The Consolidated Appropriations Act of 2021 (CCA) authorized the Secretary to apply up to ten measures to the SNF VBP Program by amending section 1888(h)(2)(A)(ii) of the Act. |
| Identify legal authorities governing information use and disclosure specific to the system and program. | Protecting Access to Medicare Act of 2014 (Pub. L. 113-93) authorized the SNF Value-Based Purchasing (VBP) Program by adding section 1888(h) to the Social Security Act (the “Act”). The Consolidated Appropriations Act of 2021 (CCA) authorized the Secretary to apply up to ten measures to the SNF VBP Program by amending section 1888(h)(2)(A)(ii) of the Act. Under Sec. 1888(h)(12)(A)), the Secretary must apply a validation process to the SNF VBP measures and “the data submitted under [section 1888(e) (6)] …as appropriate….” The data submitted under section 1888(e)(6) is the SNF Quality Reporting Program (QRP) data, and those data include the resident assessment data needed to develop and implement SNF PPS rates. In short, Sec. 1888(h)(12)(A) requires a validation process of SNF VBP and QRP quality measures from data elements gathered from resident assessments, the MDS, and the mechanism for validation is conducted by validating resident medical chart documentation supports MDS data element values. |
| Are records on the system retrieved by one or more PII data elements? | Yes |
| Identify the number and title of the Privacy Act System of Records (SORN) that is being used to cover the system or identify if a SORN is being developed. | Published: SORN 09-70-0528 Long Term Care-Minimum Data Set (MDS) |
| Identify the sources of PII in the system: Directly from an individual about whom the information pertains |
|
| Identify the sources of PII in the system: Government Sources |
|
| Identify the sources of PII in the system: Non-Government Sources |
|
| Identify the OMB information collection approval number and expiration date | PRA OMB Control Number CMS-10895. OMB has not provided an Expiration Date as of yet Quality Measures and Administrative Procedures for the Skilled Nursing Facility Value-Based Purchasing Program and Quality Reporting Program for the FY 2025 SNF PPS Proposed Rule (CMS-10895). |
| 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. | Not applicable. Notice is the responsibility of individual Skilled Nursing Facilities. Skilled nursing facilities are required to submit data to CMS for payment. |
| 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 object to the information collection because skilled nursing facilities are required to submit data for payment through Medicare and PII data is required for the reimbursement process. |
| 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. | This is not applicable. The MRMS is a part of the CMS data systems. There is not a separate process for notification. |
| 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. | This is not applicable. The MRMS is a part of the CMS data systems. There is not a separate process for notification. |
| 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. | We will not be creating or modifying PII/Protected health information (PHI) in the system; therefore, there periodic review is not applicable. All PII will be encrypted while in transit and at rest. |
| Identify who will have access to the PII in the system and the reason why they require access. |
|
| Describe the procedures in place to determine which system users (administrators, developers, contractors, etc.) may access PII. | Users require access to verify medical chart documentation and conduct validation audits. Administrators require access to monitor principles of least privilege and control access. |
| 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 records and PII throughout the system is restricted through the use of SharePoint permissions based on user roles. MRMS users will only have access to the records necessary for their job function. Any access to PII will be restricted using the Principle of Least privilege and enforced by Power Automate workflows to ensure that users can only access the PII that is required for them to perform their job. |
| Identify 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 personnel complete cybersecurity awareness training, information systems security and privacy awareness training, role-based security training, and read and sign the rules of behavior before accessing CMS systems and periodically thereafter, covering relevant security policies and practices, with training conducted at least annually. |
| Describe training system users receive (above and beyond general security and privacy awareness training) | All personnel complete cybersecurity awareness training, information systems security and privacy awareness training, role-based security training, and read and sign the rules of behavior before accessing CMS systems and periodically thereafter, covering relevant security policies and practices, with training conducted at least annually. |
| 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. | All information must be maintained in accordance with Executive Order 13556 -- Controlled Unclassified Information, National Archives and Records Administration (NARA) records retention policies and schedules and HHS Policy for Records Management and CMS policies and must not dispose of any records unless authorized by HHS/CMS. All records are required to follow the appropriate CMS Records Management life cycle in accordance with the HHS/CMS Records Disposition Plan per the SNF VBP Validation contract and NARA Records Disposition Authority Number: DAA-0440-2015-0007-0001. |
| Describe, briefly but with specificity, how the PII will be secured in the system using administrative, technical, and physical controls. | SPOC is responsible for ensuring that the appropriate architectures are in place to secure system security. Principle of leas privilege will be enforced. All PII will be encrypted while in transit and at rest. All interaction with external systems will be evaluated to ensure that sensitive information is protected and encrypted while in transit and at rest. Access to records and PII throughout the system is restricted through the use of SharePoint permissions based on user roles. MRMS users will only have access to the records necessary for their job function. |
Privacy Impact Assessment (PIA) published by CMS as an Operating Division of the U.S. Department of Health and Human Services