Quality Payment Program

The Quality Payment Program (QPP) internal Claims application has implemented a method of de-identifying Personally Identifiable Information (PII) taken from the Integrated Data Repository on Cloud (IDRC) and moving that de-identified data into lower tier environments for development purposes. IDRC is a separate Federal Information Security Management Act (FISMA) system that has an authority to operate (ATO) covering its lower tier environments while QPP’s ATO only covers the production environment. The team can now run tests on obfuscated data in lower tier environments before pushing changes into production.

Previously, IDR was in a data center in Baltimore. At the end of 2023, the physical data center was decommissioned, so QPP moved to IDR’s cloud offering.

Quality Payment Program (QPP) consolidates information from several existing Medicare reporting programs: The Value-Based Modifier (VBM), and the Electronic Health Record (EHR) Meaningful Use Program. This information will be received from the Centers for Medicare and Medicaid Services (CMS) Integrated Data Repository (IDR) and originates from the CMS Provider Enrollment Chain and Ownership System (PECOS) system which is separately accredited.

The system receives and stores quality measures data from eligible clinicians, group practices, and Advanced Alternative Payment Models (APMs).  The measures data will be comprised of three categories:  Quality, Improvement Activities (IA), and Advancing Care Information (ACI). Each category is a set on measures or activities.  The IA and ACI categories are practice specific measures/activities, while the quality category measures across an aggregation of all beneficiaries in a practice.

Quality Payment Program (QPP) system does not collect user credentials from system and database administrators, CMS employees and direct contractors. QPP system users access a separate system, Amazon Web Services (AWS), to obtain access to QPP.

End user clinicians are registered users of the Health Care Quality Information System (HCQIS) Access Roles and Profile (HARP) system, which Okta Identity as a Service (IDaaS) references for initial authentication. There is no new user registration currently. Collection of user credential all occurs in these separate systems outside the boundary of QPP.

The following Provider Information is being collected from other Centers for Medicare and Medicaid Services (CMS) data sources (Provider Enrollment Chain and Ownership System (PECOS), shared with Quality Payment Program (QPP), and maintained temporarily within the QPP database:

Provider Base: Provider Base Identifier, Enrollment Identifier, Provider Enrollment Type Code, Provider Entity Type Code, Provider First Approved Date, Provider First Name, Provider Sex Code, Provider Last Approved Date, Provider Last Name, Provider Middle Name, National Provider Identifier (NPI) Number, Provider Organization Name, PECOS Identifier, Geographic United States Postal Service (USPS) State Code, Provider Enrollment Status Code, Tax Identifier Number (TIN) Number, Provider TIN Type Code, End Date, Status Date

Provider Reassignment: Provider Reassignment Identifier, Assignee Identifier, Reassigned to Identifier, Effective Date, End Date

Provider Specialty: Provider Specialty Identifier, Provider Base Identifier, Specialty Code

Specialty Reference: Specialty Description

Provider Address: Provider Address Identifier, Provider Base Identifier, Address Type Code, City Name, Line 1 Address, Line 2 Address, Geographic USPS State Code, ZIP Code

Provider Special Scenario: Provider Special Scenario Identifier, Provider Relationship Identifier, Program Year Number, Run Number, Critical Access Hospital Switch, Provider Aggregation Level Code, Beneficiary Visit Count, Allowed Charge Amount, Low Volume Exclusion Qualification Switch, Cause Low Volume Switch, Patient Facing Encounter Count, Less than 100 Patient Facing Provider Count, National Provider Identifier (NPI) Total Count, Meet Non Patient Facing Criteria Percent, Non Patient Facing Qualification Switch, Hospital Based Covered Professional Services Amount, Total Covered Professional Services Amount, Hospital Based Services Percent, Hospital Based Clinician Qualification Switch, Clinician Count, Provider Small Group Switch, Highest Part B Charge Specialty Name, Multiple Specialty Switch, Merit Based Incentive Payment System Eligible Clinician Switch, Rural Qualification Switch, Provider First Claim Number, Health Professional Shortage Area Qualification Switch

No User Credentials are being collected directly by the QPP application. For authentication, QPP leverages the HCQIS Access Roles and Profile (HARP) system coupled with the Okta identity as a service (IDaaS) solution. Only users who have existing HARP accounts will be able to access QPP to view their provider information on record. No user credential information is stored within the QPP application database.

User credentials used by a Provider to access QPP will be stored within the Federal Risk and Authorization Management Program (FedRAMP) approved and CMS assessed Okta Identity as a Services (IDaaS) solution.

Okta User Credential information: Username, first name, Last name, Middle name, Primary email, Honorific suffix, NPI status code, NPI, Primary phone, Profile status code, Security status code, Registration status code, Country code, Record status code, Password status, Hard locked code, Security questions attempts, User information attempts, Source Type, Password Source.

Developer and Administrator access to the QPP backend is managed through Amazon Web Services (AWS) by the Infrastructure Contractor for the CMS AWS instance, General Dynamics.

Regarding records access using PII information, clinicians/providers using QPP would be able to authenticate using their HARP credentials and then based off their user role/entitlement (User or Security Official) have access to their own information or their organization's information respectively.  The Tax Identifier Number (TIN) is used as a unique record identifier and helps CMS to attribute quality of care to a specific provider. Determining accurate quality of care will help to improve Medicare payments for provider's services. The TIN is what ties the HARP users (provider/clinician) to their appropriate records within QPP. Records can also be queried using PII fields including First Name, Last Name, and Mailing Address. 

• Social Security Number
• Name
• Taxpayer ID
• Mailing Address
• Other - Other - Provider Base Identifier, Enrollment Identifier, Provider Enrollment Type Code, Provider Entity Type Code, Provider First Approved Date, Provider First Name, Provider Provider Last Approved Date, Provider Last Name, Provider Middle Name, NPI Number, Provider, Organization Name, PECOS Identifier, Geographic USPS State Code, Provider Enrollment Status Code, TIN, Provider TIN Type Code, Provider Reassignment Identifier, Assignee Identifier, Reassigned To Identifier, Provider Specialty Identifier, Specialty Code, Provider Address Identifier, Address Type Code, City Name,  Address, Geographic USPS State Code, ZIP Code, Provider Special Scenario Identifier, Provider Relationship Identifier, Program Year Number, Run Number, NPI Total Count, Hospital Based Covered, Provider First Claim Number

• Public Citizens
• Vendors/Suppliers/Contractors
• Other - Hospitals and Providers

• Online

• Within the OPDIV

• Members of the Public
• Other - Hospitals and Providers

Reporting quality payment data is purely voluntary by Eligible Professionals (i.e., health care delivery professionals) or Group Practices. Opt out procedures at the physician or at the Group Practice level is not known to QPP. This is external to the Program. Opt out occurs at the physician/facility level, external to the QPP system.

System user's credential information is collected by Okta, HARP, Enterprise User Administration (EUA), and therefore no process exists within QPP.

Notification of collection of physician Personally Identifiable Information/Protected Health Information (PII/PHI) also occurs outside of the scope of the QPP system at the facility level via the quality measures data forms submitted by the physicians or qualified data registries.

System user's credential information is collected by Okta and HARP, and therefore no process exists within QPP.

Individuals with concerns about PII collection and disclosure are referred to the local Quality Improvement Organization (QIO) Security Point of Contact (POC). If the QIO is not able to assist the individual directly, they will raise the issue to the Quality Net Enterprise Service Desk by issuing a ticket.

System user's credential information is collected by Okta, HARP, and EUA, and therefore no process exists within QPP. Users will need to contact the QualityNet Service Desk to resolve PII complaints.

• Users: Users are provided a user manual and have access to only their own PII for the purpose of verifying accuracy.
• Administrators: Administrators have access to the system to ensure it is running properly. Generally, PII access is not necessary to resolve issues, but in some cases it is necessary. Admins sign non-disclosure agreements and take annual CMS-required security and privacy training as a requirement of their role.
• Developers: Developers have access to the PII for development and testing purposes for system enhancements, fixes, and provider assistance (help desk). Developers sign non-disclosure agreements and take annual CMS-required security and privacy training as a requirement of their role.
• Contractors: Direct contractors are comprised of administrators and help desk personnel. Direct contractors may have access to PII for purposes of troubleshooting user and system issues. Direct contractors sign non-disclosure agreements and take annual CMS-required security and privacy training as a requirement of their role.

All users of the system have access to PII, the extent of which depends on their system role. System roles have been defined within the system security plan (SSP) for QPP and were created and approved by the Business Owner and Product Owners of QPP. Roles are reviewed at least annually to determine if they are still applicable.

Providers with a HARP account is assigned a specific user role within Okta to access QPP.

Developer and Administrator access to the QPP backend is managed through Amazon Web Services (AWS). This access requires a CMS Enterprise User Administration (EUA) account with specific Job codes which define the user role.

All providers are assigned a standard user role within Okta designed to give the least privilege required to perform their duties. There are no advanced user roles for providers.

Developer and Administrator access to the QPP backend is managed through Amazon Web Services (AWS) by the Infrastructure Contractor for the CMS AWS instance, General Dynamics. Users are required to first register with the CMS Enterprise User Administration (EUA) and request the proper job codes (requiring CMS Access Administrators (CAA) and Contract Officer Representative (COR) approval) to allow them. Jira and EUA are used to request and get approval for specific roles, group membership and access. Users must request specific job codes for specific access through EUA. EUA Job codes define the access to the applications and roles needed within the application. Least privilege access is enforced using this method.

All system users are required to take the CMS Cyber Awareness Challenge Computer Based Training (CBT) annually as well as the Identifying and Safeguarding Personally Identifiable Information (PII) training endorsed by CMS.

Security and Privacy Awareness training is offered through Computer Based Training to all users. Training is required to acquire and hold a HARP account (used for Okta QPP authentication). HARP is responsible for enforcing current, up-to-date training. Contractors that have elevated levels of access, such as system or database administrators, must take additional role-based training as required within the CMS Acceptable Risk Safeguards (ARS) controls for security.

https://qpp.cms.gov.

The QPP Website has posted its own Privacy Notice/Policy and Third-Party Websites and Applications (TPWA) tools that are employed when the general public visits the website.

• Session Cookies
• Persistent Cookies