Quality Management and Review System

OPDIV:

CMS

PIA Unique Identifier:

P-8273992-375585

Name:

Quality Management and Review 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:

Contractor

Is this a new or existing system?

Existing

Does the system have Security Authorization (SA)?

Yes

Date of Security Authorization

9/23/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.

No change to the physical location or addition of new PII since last PIA.

Describe the purpose of the system

Provides a modern, secure, efficient application that supports the Beneficiary and Family Centered Care-Quality Improvement Organizations (BFCC-QIOs) in performing case review of Medicare beneficiaries to assess the quality of care, determine medical necessity of treatment, (including various case review types) and appropriateness of termination of services.

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)

Users are Centers for Medicare & Medicaid Services (CMS) employees and direct contractors. Quality Management and Review System (QMARS) uses Health Care Quality Improvement Systems (HCQIS) Access Roles and Profile (HARP) for authentication and authorization of users. Once authorized, users’ access is verified at a page level, based on pre-defined permissions associated to the application role(s). 

The following information is collected, maintained, and shared by QMARS:

Beneficiary

Medicare complaint information, 
First Name,
Last Name,
address,
Social Security Number (SSN),
phone numbers,
email address
date of birth
demographics
Sex
Race / Ethnicity
Username
Health Insurance Claim Number (HICN).
Medicare Beneficiary Identifiers (MBIs)
billing,
eligibility status,
and claim status.
Medical case review notes
Medical records (in .pdf format)
Financial Account Information:  
Information about payments,
payroll,
automated decision-making,
procurement,
market sensitive,
inventory.
Provider Facility:
Name, location,
facility type,
provided services,
medical staff information
name,
position
Health Service Encounter (HSE),
service dates,
inpatient/outpatient
name,
address,
and telephone numbers,
health insurance information,
email address,
claim information.
National Provider Identifier (NPI),
CMS Certification Number (CCN),
Name,
Setting,
Specialty, State, Address, Email.
QIO:
User name
Case review invoice number,
inpatient/outpatient (name, address, phone number),
medical staff name,
position,
health insurance information,
email address,
claim information such as State,
HICN,
Medicare Advantage ID,
Claim Information (Images of Medical Records),
Medical Records Requests Due/ Received dates,
Postage Due and Paid information,
Peer Reviewer Name,
Concern Category and Detail,
Physician name,
Improvement Categories,
Standard of Care (categories, descriptions, and publications),
Dates information received,
Conclusions,
Rationale/Justifications,
Minutes spent on tasks,
Notification Dates,
QIO Address (Business). 

Device Identifiers: Unique Device Identification (UDI) System is intended to assign a unique identifier to medical devices within the United States. The FDA has established and continues to implement a unique device identification system to adequately identify medical devices through their distribution and use. When fully implemented, the label of most devices will include a UDI in human- and machine-readable form.

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

QMARS is a part of the QualityNet System, which has its own PIA, designed to provide the Quality Improvement Organizations (QIO) a platform to perform their contract requirements related to Medicare reviews. It collects and maintains information about Case Reviews, QMARS allows the QIO to process, track and report on medical case review related to beneficiary complaints and concerns identified by the QIO or other entities. These reviews determine whether the health care provider followed accepted standards of care in treating the Medicare beneficiary.

Information collected and stored in QMARS includes copies of the medical records related to the care received, which are reviewed by the peer reviewer ((PR) normally a licensed physician, under contract to the QIO). The PR determines whether standards of care were met, and that analysis is stored in the system. In addition, the provider, other involved physicians, and the beneficiary are sent letters summarizing the decisions and justifications for the PR’s decisions. All system generated letters, as well as additional documents (correspondence, additional medical information, etc.) received from the parties in the review are stored as attachments within QMARS. It also provides CMS the information needed to measure and improve the efficacy of CMS QIO’s program.

The primary goal of QMARS is to determine whether standards of care were met in different facilities across the United States.

The following information is collected, maintained, and shared by QMARS for QIO reporting, evaluation and as required to manage the QIO program. The QMARS information stored is QIO’s Case Review, patient information (name, address, health care information, including Claims and Medical records, Health Service Encounter (HSE) information). Information related to the Beneficiary is collected and stored so that the Reviewer can have accurate information about the complainant who received the care in question. Information related to Authorized Representatives and Alternate Contacts is collected so that information can be obtained from, or shared with, these contacts as necessary.

Information is collected about the Provider so that the reviewer may reach out as necessary, and to review other cases that include the same provider. The workflow management data is entered and stored to process the case within the system, including case routing and reporting on timelines and other measures.

The QMARS beneficiary personal information includes name, date of birth, SSN, mailing address, telephone number, medical case review notes, Health Insurance Claim number (HICN)/ Medicare claim number.

Facility Information includes name, location, type of facility, services provided, number and type of medical staff, and facility personal information (name, facility email and telephone number, and position).

Users are CMS employees and direct contractors. QMARS utilizes HARP for authentication to the system to include username, password and second factor authentication.

The QMARS system regularly use PII to retrieve system records including using beneficiary last name, first name, SSN, Birth Date, or Death Date to retrieve case records.

Does the system collect, maintain, use or share PII?

Yes

Indicate the type of PII that the system will collect or maintain.

• Social Security Number

• Name

• E-mail Address

• Phone Numbers

• Medical Notes

• Date of Birth

• Mailing Address

• Medical Records Number

• Device Identifiers

• Date of Death

• Other - Race/ Ethnicity; Health Insurance Information; Health Insurance Claim Number (HICN); Medicare Beneficiary Identifier (MBI), Dates of Service; Provider Information; National Provider Identifier (NPI); CMS Certification Number (CCN); Medicare Advantage ID; User Credentials (User ID and Password); Medicare complaint information, facility location, type of facility, medical staff information, Health Service Encounter, claim information, setting, specialty, case review invoice number, position, Postage due and paid information, concern category and detail, improvement categories, standard of care, conclusions, rationale/justifications, minutes spent on tasks, notification dates, and QIO Address.

Indicate the categories of individuals about whom PII is collected, maintained or shared.

• Employees

• Patients

• Other - Application users, Beneficiaries

How many individuals' PII in the system?

100,000-999,999

For what primary purpose is the PII used?

The PII collected is used to intake a beneficiary or their representative in the QMARS system to improve the effectiveness, efficiency, economy, and quality of services provided to people with Medicare. 

Describe the secondary uses for which the PII will be used (e.g. testing, training or research)

Training, a subset of PII from the production environment is available in the training environment to facilitate training and User Acceptance Testing (UAT) with Quality Improvement Organization (QIO) contractors.

Describe the function of the SSN.

QMARS uses the SSN to associate a Medicare Beneficiary with the HICN and MBI to match a Beneficiary to the Health Service Encounter (HSE).  

There are Medicare plan exceptions for QMARS use of the SSN:

Appeals - People filing appeals can use either the HICN or the MBI for their appeals and related forms.

There are Fee-for-Service claim exceptions for QMARS use of the SSN:

Appeals - You can use either the HICN or the MBI for claims, appeals and related forms.

Cite the legal authority to use the SSN.

Executive Order 226A, 1875 and 1881 of the Social Security Act; Title 42 U.S.C., sections 426-1, 1395II and 1395rr.

Identify legal authorities​ governing information use and disclosure specific to the system and program.

Code of Federal Regulations (CFR) 42 Section 494. 180 (h) and Sections 226A, 1875, and 1881 of the Social Security Act (the Act) (Title 42 United States Code (U.S.C.), sections 426–1, 1395ll, and 1395rr).
TRHCA - 2006 Tax Relief and Health Care Act
MMSEA - Medicare, Medicaid and SCHIP Extension Act of 2007
MIPPA - Medicare Improvements for Patients and Providers Act of 2008

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.

09-70-0536 - Medicare Beneficiary Database (MBD) published 12/4/2006.

Identify the sources of PII in the system: Directly from an individual about whom the information pertains

• In-Person

• Online

• Hard Copy

• Mail/Fax

Identify the sources of PII in the system: Government Sources

Within the OPDIV

Identify the sources of PII in the system: Non-Government Sources

Private Sector

Identify the OMB information collection approval number and expiration date

No Office of Management and Budget (OMB) control number is required for this application because information is not collected directly from an individual about whom the information pertains. 

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.

The collection of personal information is done at the QIO facility level and not directly by QMARS. At QIO facility, users are given an informed consent form stating the uses of their PII. Providers are responsible for notifying users that their information will be collected and shared.

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.

If the individuals wish to opt-out of providing their PII at the source of collection which is in the physician office, they may wave the collection of data at this facility.

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.

QMARS does not obtain or notify individuals concerning their PII. CMS and the QIOs have the responsibility to notify the individuals.

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.

QMARS does not obtain or notify individuals concerning their PII. CMS and the QIOs have the responsibility to handle any concerns identified by individuals.

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.

All data is scanned upon import to ensure the received information is complete and relevant. Once the data is in the environment, information stores are backed-up in accordance with CMS requirements. Database integrity checks are performed on a scheduled Integrity, the data are scanned daily utilizing QualityNet (Amazon Web Services (AWS) Security Hub, So Now You Know (SNYK), etc.) to confirm quality and integrity basis to ensure that information has not been compromised. Functionally, reviewers assess the completeness, relevancy, and accuracy of quality review information as part of their review process integral to the work process.

Additionally, the Privacy Impact Assessment document and System Security Plan will be reviewed annually. An annual Cybersecurity and Risk Assessment Program (CSRAP) is conducted to ensure compliance with the CMS Acceptable Risk Standards (ARS).

Identify who will have access to the PII in the system and the reason why they require access.

• Users: QMARS users are comprised of CMS Central and Regional offices, Kepro, Livanta, BFCC NCC, BFCC QIO, BFCC ORC, and other CSCSQ Information Systems Group (ISG) support contractors with CMS Data Use Agreement (DUA). Users receive the least privileges possible to perform their job duties through the user roles.

• Contractors: Contractors – Quality Improvement Organizations (QIOs) require access to PII data in Production to perform contractual duties. This is a contractor managed system; contractors have access to PII data in Production side subnet environments to test and maintain the system.

• Others - Contractors are Direct Contractors, Others are Healthcare providers: Healthcare providers will have access to PII pertaining to the Health Services Encounters (HSE) they perform.

Describe the procedures in place to determine which system users (administrators, developers, contractors, etc.) may access PII.

Access to information is based on a user’s specific job function, or role. Each role is evaluated for the minimum necessary access levels needed of the role to perform the tasks necessary for the job. These roles are formally validated and serve as the basis for access to all PII. When an individual is hired, they are assigned the role required to perform their duties. Access requests are approved, and a limited number of System Administrators have access to assign the approved roles within the system.

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.

The HARP system is a secure identity management portal provided by the CMS to provide secure, confidential access to the QMARS system. Users are assigned roles within HARP which is designed to grant the minimum access required to perform their job/contracted role. Security Officers are assigned to QMARS through HARP. The Security Officer has the responsibility to remove users that are inactive and/or no longer requiring access to the data or the QMARS system.

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 CMS employees and direct contractors with access to CMS networks, applications, or data must complete mandatory annual Privacy Awareness Training annually. All QMARS users are required to take the CMS Cyber Awareness Challenge, and the Identifying and Safeguarding Personally Identifiable Information (PII) training Records Retention, and the Information System Security and Privacy Training.

Describe training system users receive (above and beyond general security and privacy awareness training)

CMS employees and contractors with elevated levels of access, such as system or database administrators, must take additional role-based training as required. CMS provides a training system to educate, test and certify the QMARS users in order identify and avoid cyber-threats in the workplace.

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.

QMARS follows the CMS Record Retention Schedule, published April 2015, under the Health Care Quality Improvement Systems (HCQIS) Disposition Authority: N1-440-09-3-Temporary. Delete/destroy after 4 survey cycles or 7 years whichever is later. Assessment Data will be destroyed when 20 years old.

Describe, briefly but with specificity, how the PII will be secured in the system using administrative, technical, and physical controls.

Administrative controls include, but not limited to contingency plans and annual testing, backups of all files, offsite storage of backup files, background checks for all personnel, incident response procedures for timely response to security and privacy incidents, initial security training with refresher courses annually, and annual role-based security training for personnel with assigned security roles.

Technical controls include but are not limited to user authentication with least privilege authorization, firewalls, intrusion Detection and Prevention systems, encrypted communication (data at rest and data is accessed using Federal Information Processing Standards (FIPS) 140-2 requirements). Hardware configured with a deny all/except approach, auditing, and correlation of audit logs from all systems.

Management Controls include but are not limited to: Certification and Accreditation (C&A), annual security assessments (Adaptive Capabilities Testing (ACT)), monthly management of outstanding corrective action plans, ongoing risk assessments, and automated continuous monitoring via Splunk, AWS Security Hub, Nessus Tenable compliance/vulnerability scans, and SNYK.