Last Updated: 08/31/2023
{/* IMPORTANT: update this Last-Updated value if you have made any changes to this page's content. */} -
In the
Last Updated: 08/26/2020
{/* IMPORTANT: update this Last-Updated value if you have made any changes to this page's content. */} -+
To submit directly to QPP using the Submissions API, Qualified Registries and QCDRs use CMS-provided tokens in their API calls. You can learn more about the Submissions API authentication and authorization model for Qualified Registries and QCDRs
+
We support OAuth Authentication, which provides client applications with secure, delegated access to the Submissions API. You can learn more about using OAuth with the Submissions API
Last Updated: 08/31/2023
{/* IMPORTANT: update this Last-Updated value if you have made any changes to this page's content. */} -The Submissions API is an easy way to manage your performance data with CMS. Performance data is organized into submissions, which can have many measurements. Measurements within a submission are also grouped by category (e.g. quality) and submission method (e.g. registry) and program name (e.g. mips) into measurement sets.
@@ -18,7 +18,7 @@ const BasicTutorial: React.FC
We need to create a measurement set first. We can do that by asking the API to create a measurement set record in the CMS database. In API terms, this means making a POST (synonym for create) request to the /measurement-sets endpoint.
With the submission id we were given, we can ask the API to calculate the submission score with a GET request. We don't need to include a request body this time since we're only interested in retrieving the score, and CMS doesn't need any information other than the submission id.
Last Updated: 08/31/2023
{/* IMPORTANT: update this Last-Updated value if you have made any changes to this page's content. */} -+
Using OAuth with the Submissions API allows QPP participants to use their own QPP credentials to login through your application to submit their data to and view performance feedback from QPP. Before you can request production access, you will need to use the Developer Preview Environment to build, test and demo your OAuth application.
-+
To use the QPP Submissions API with OAuth, you must create a Developer Preview account and register the application.
-+
Create an account for Developer Preview at
+
Log in to Developer Preview (
+
Locate your EHR (search by the EHR name as it appears in the
+
If you cannot locate your EHR or are a registry user, create one manually.
-+
After requesting the role, it may take a few minutes to populate.
-+
Once you are connected, you can use the OAuth APIs directly on the
+
Registering and testing your application within the Developer Preview is required prior to being granted production OAuth access.
-+
To register the application, you will need:
+
In the test environment, a registered application is assigned a client ID and, if applicable, a client secret. The secret should only be used if it can be kept confidential, such as for communication between your server and the Submissions API.
-+
Additional support along with a sample OAuth Client, can be found in the QPP Github at:
+
To support Developer Preview integration and testing, we created the
+
To submit data via OAuth and the Submissions API during the submission window, your application must be approved for production use by QPP. To apply for production access, you must demonstrate your application to QPP and attest that your organization:
+
You will also be asked to provide:
+
To request production access, please email the QPP Help Desk at QPP@cms.hhs.gov to set up a demonstration with the QPP team. In order to have sufficient time to go through the approval process, requests for production access for an upcoming submission period should be made no later than November 1 prior to submissions opening.
Last Updated: 07/01/2021
{/* IMPORTANT: update this Last-Updated value if you have made any changes to this page's content. */} -+
Qualified Registries and QCDRs entities that are authorized by the Centers for Medicare & Medicaid Services (CMS) to submit Quality Measures, Promoting Interoperability Measures, and/or Improvement Activities on behalf of MIPS eligible clinicians, groups, and/or virtual groups for a specified performance year can submit directly to the Submissions API using an API token.
-+
Tokens are specific to your organization and are specific to the environment within the Submissions API. Developer Preview tokens are for testing against the Submissions API in the Developer Preview environment. Production token are for submitting during the specific performance year's submissions window to the production environment of the Submissions API.
-+
If you are a Registry or QCDR using the Developer Preview, you have an API key that is associated with an 'organization'. This affects what endpoints you are authorized to use, and what behavior each endpoint has.
-+
At a high level, your API key allows you to create and edit data using the /measurement-sets and /measurements endpoints. You cannot create data using the /submissions endpoint. For more information about what you're authorized to do with the Submissions API, click
+
You must authenticate your account when using the Submissions API. Authenticate via bearer auth by adding your API token to the header of every request using the key value: Authorization: Bearer [YOUR API TOKEN].
-+
API keys carry many privileges, and must not be shared in publicly accessible areas such as GitHub and in client-side code. Even within organizations, access must be limited to staff embedding it in software.
-+
Your API key carries many privileges, so be sure to keep it secret! Do not share your secret API key in publicly accessible areas such GitHub, client-side code, and so forth.
-+
All API requests must be made over HTTPS. Calls made over plain HTTP will fail. API requests in the Developer Preview without authentication will also fail.
-+
Please see
+
If you are a current Qualified Registry or QCDR using the Submissions API, you have an API key that is associated with an 'organization'. This affects what endpoints you are authorized to use, and what behavior each endpoint has.
-+
In general, if you have an organization-type API key, you can:
+
Below is a comprehensive list of how each endpoint behaves if you are using an organization-type API key:
+
To retrieve your Developer Preview and production tokens, you must have a HARP account that has a Security Official role for your Qualified Registry or QCDR. Please see
Last Updated: 01/05/2021
{/* IMPORTANT: update this Last-Updated value if you have made any changes to this page's content. */} -+
The Submissions API is a RESTful API. It has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. It uses standard HTTP features, like HTTPS authentication and HTTP verbs, which are understood by off-the-shelf HTTP clients.
-+
The Submissions API supports cross-origin resource sharing, allowing you to interact securely with the API from a client-side web application (though you should never expose your secret API key in any public website's client-side code).
-API responses are returned in JSON, including errors.
+API responses are returned in JSON, including errors.
-+
Visit the
Return to the
Last Updated: 08/31/2023
{/* IMPORTANT: update this Last-Updated value if you have made any changes to this page's content. */} -Benchmarks serve as the reference points for measurements and are used to score submissions. Each benchmark is unique based upon its combination of measureId, submissionMethod, and performanceYear, and each has a list of 9 data points.
diff --git a/src/app/components/references/error-codes.tsx b/src/app/components/references/error-codes.tsx index 61454ee5..4bee889b 100644 --- a/src/app/components/references/error-codes.tsx +++ b/src/app/components/references/error-codes.tsx @@ -5,9 +5,9 @@ const ErrorCodes: React.FCLast Updated: 08/31/2022
{/* IMPORTANT: update this Last-Updated value if you have made any changes to this page's content. */} -Last Updated: 07/06/2023
{/* IMPORTANT: update this Last-Updated value if you have made any changes to this page's content. */} -The MeasurementSets resource represents performance data for a specified category. Each Submission can have multiple MeasurementSets. Each MeasurementSet in a given Submission is uniquely identified by category, submission method, and programName. MeasurementSets contain Measurements, which can be accessed both via MeasurementSets methods and Measurements methods.
@@ -18,7 +18,7 @@ const MeasurementSets: React.FCLast Updated: 08/15/2023
{/* IMPORTANT: update this Last-Updated value if you have made any changes to this page's content. */} -Boolean Measurements are applicable to Improvement Activity (IA) and Promoting Interoperability (PI) measures. For PI Measures, if a measure has an Exclusion measure ID listed, this means that the Exclusion measure ID cannot be submitted in the same Measurement Set as the original measure because they have opposite meanings and cannot both be true.
Proportion Measurements are applicable to Promoting Interoperability (PI) measures. For PI Measures, if a measure has an Exclusion measure ID listed, this means that the Exclusion measure ID cannot be submitted in the same Measurement Set as the original measure because they have opposite meanings and cannot both be true.
Non-Proportion Measurements are applicable to quality measures. Most are authored by QCDRs and are used to attest to measures that are otherwise categorized as 'ratio', 'continuous variable', or a combination of 'proportion' and the former. Note this means that having a false value in the proportion field of QCDR documentation is sufficient to determine that a measure as non-proportional, but having a true value for proportion is insufficient to determine that measure as proportional. Non-proportion measurements are unconstrained, so while the fields are 'numerator' and 'denominator' there is no validation that the numerator must be less than or equal to the denominator or that the denominator is greater than 0, as is the case for proportion measurements.
Single-Performance Rate Measurements are applicable to MIPS CQM Quality measures.
Single-Performance Rate Measurements are applicable to QCDR Quality measures. The performanceRate field is both writable and required for these measures.
Multi-Performance Rate Measurements are applicable to Quality measures. There are two types of Multi-Performance Rate Measurements: registry and normal. The difference between the two is that for Registry Multi-Performance Rate Measurements, the performanceRate field is both writable and required. Multi-Performance Rate Measurements contain multiple strata and the stratum field is required for each.
A Multi-Performance Rate Stratum represents the performance data for a specified subset of the population, as described by the stratum field. Submissions should follow the specifications for population and stratum name, below is an example submission.
diff --git a/src/app/components/references/references.tsx b/src/app/components/references/references.tsx index 31c0bd51..1a26525e 100644 --- a/src/app/components/references/references.tsx +++ b/src/app/components/references/references.tsx @@ -6,16 +6,16 @@ const References: React.FCLast Updated: 05/12/2021
{/* IMPORTANT: update this Last-Updated value if you have made any changes to this page's content. */} -Last Updated: 08/31/2023
{/* IMPORTANT: update this Last-Updated value if you have made any changes to this page's content. */} -The scoring engine is responsible for interpreting submissions and outputting a score. Each category score is utilized to create the QPP score object.
Note: Registries and QCDRs submitting on behalf of others will only have access to view the score for the data they submitted. If they need to see the complete score, they will need permission from the practice.
-
In the Developer Preview Testing Environment you can use the
Note: You can use the
Once submitting quality data during the Submission window you can use the
The only available option for reporting Improvement Activities is boolean, and only Activities completed need to be reported.
The example submission below contains 4 activities. The reported activities contain both High and Medium weighted activities.
Use the
The Promoting Interoperability Category requires all measures associated with the category to either be reported or their corresponding exclusion to be claimed. Additionally, to receive credit for the category, all the criteria below must be fulfilled:
The measure types available for submission are outlined below. Each measure in the repo will dictate which type is to be utilized.
Use the
The Quality category requires 6 measures to receive full credit, one of which must be either an Outcome measure or High Priority. If no Outcome or High Priority measure is submitted, you will only be scored on the top 5 measures and receive a score of 0 for the sixth measure.
Submission structure in the Quality category are contingent on the measure being submitted. If there are questions around the data to be submitted in the fields, please refer to the measure specification. The available types related to the measures are outlined below:
Use the Last Updated: 08/31/2022
The Submissions resource represents one year of performance data for a given individual or group. Submissions contain MeasurementSets which can be accessed both via Submissions methods and MeasurementSets methods.
Last Updated: 09/29/2023
See Last Updated: 08/26/2020
+
Please contact the Quality Payment Program Service Center
+
For information around Quality Payment Program requirements, please visit
+
For frequently asked questions regarding APIs please see the
+
Please bring any questions not answered by our available documentation to the monthly support calls/Virtual Office Hours. Or contact the Quality Payment Program service center: Last Updated: 08/26/2020
+
Thank you for using The Centers for Medicare and Medicaid Services ("CMS") APIs and other developer services (collectively, "APIs"). By accessing or using our APIs, you are agreeing to the terms below as well as any relevant sections of CMS's
+
The service ("API") through which you interact with CMS data is subject to these terms. Use of the API constitutes acceptance to these Terms.
+
If you are using the API on behalf of an entity, you represent and warrant that you have authority to bind that entity to the Terms and by accepting the Terms, you are doing so on behalf of that entity (and all references to "you" in the Terms refer to you and that entity).
+
In order to access the API, you may be required to provide certain information (such as identification or contact details) as part of the registration process for the API, or as part of your continued use of the API. Any registration information you give to CMS must be accurate and up to date and you must inform us promptly of any updates so that we can keep you informed of any changes to the API or the Terms which may impact your usage of the API.
+
Developer credentials (such as passwords, keys, tokens, and client IDs) are intended to be used only by you and identify any software which you are using with the APIs. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects.
+
You will only access (or attempt to access) an API by the means described in the documentation of that API. If CMS assigns you developer credentials (e.g., client IDs), you must use them with the applicable APIs.
+
While not required, when using content, data, documentation, code, and related materials associated with the API in your own work, we ask that proper credit be given.
+
Your use of the API may be subject to certain limitations on access, calls, or use as set forth within this Agreement or otherwise provided by CMS. These limitations are designed to manage the load on the system, promote equitable access, and prevent abuse, and these limitations may be adjusted without notice, as deemed necessary by CMS. If CMS reasonably believes that you have attempted to exceed or circumvent these limits, your ability to use the API may be temporarily or permanently blocked. CMS may monitor your use of the API to improve the service or to ensure compliance with this Agreement.
+
If you wish to terminate this Agreement, you may do so by refraining from further use of the API. CMS reserves the right (though not the obligation) to: (1) refuse to provide the API to you, if it is CMS's opinion that use violates any CMS policy; or (2) terminate or deny you access to and use of all or part of the API at any time for any other reason which in its sole discretion it deems necessary to in order to prevent abuse. You may petition CMS to regain access to the API through the support email address provided by CMS for the API. If CMS determines in its sole discretion that the circumstances which led to the refusal to provide the API or terminate access to the API are no longer in existence, then CMS may restore your access. All provisions of this Agreement shall survive termination including, without limitation, warranty disclaimers, and limitations of liability.
+
The API platform is provided "as is" and on an "as-available" basis. While we will do our best to ensure the service is available and functional at all times, CMS hereby disclaim all warranties of any kind, express or implied, including without limitation the warranties of merchantability, fitness for a particular purpose, and non-infringement. CMS makes no warranty that data will be error free or that access thereto will be continuous or uninterrupted.
+
In no event will CMS be liable with respect to any subject matter of this Agreement under any contract, negligence, strict liability or other legal or equitable theory for: (1) any special, incidental, or consequential damages; (2) the cost of procurement of substitute products or services; or (3) for interruption of use or loss or corruption of data.
+
Any disputes arising out of this Agreement and access to or use of the API shall be governed by federal law. Some APIs may have API specific Terms. If there is a conflict between these terms and additional terms applicable to a specific API, the additional terms will control for that conflict.
+
CMS's failure to exercise or enforce any right or provision of this Agreement shall not constitute waiver of such right or provision.
+
Return to the Last Updated: 08/31/2023
+
See Last Updated: 08/31/2023
+
The Change log is updated with each significant change to the API with the details that you need to be aware of.
Last Updated: 08/26/2020
+
See updated documents Last Updated: 12/05/2020
+
The Submissions API enables submissions and real-time performance scoring of Quality Payment Program (QPP) data.
+
The Submissions API is a RESTful API. It has predictable, resource-oriented URLs, and uses HTTP response codes to indicate API errors. It uses standard HTTP features, like HTTPS authentication and HTTP verbs, which are understood by off-the-shelf HTTP clients.
+
The Submissions API supports cross-origin resource sharing, allowing you to interact securely with the API from a client-side web application (though you should never expose your secret API key in any public website's client-side code).
+
API responses are returned in JSON, including errors.
+
The base URL to submit Quality data using the API in Production is:
+
The base URL to submit LVT Opt-In decisions using the Eligibility API in Production is:
+
To make the API as explorable as possible, we have
+
The
+
Requests made in the Interactive Documentation and Developer Preview are not officially submitted to CMS.
+
The developer documentation is a living document that is constantly maintained to stay in sync with policy, technical changes, and test data changes. Additionally we update the content to provide answers to frequently asked questions. Please refer back to this regularly to keep aware of recent changes.
+
Please bring any questions not answered by our available documentation to the monthly support calls/Virtual Office Hours, or contact the Quality Payment Program at {envConfig.phoneNumber}, Monday through Friday, 8:00 AM-8:00 PM ET or by e-mail at: {envConfig.qppEmail}
POST .../score-preview endpoint to view the scoring object returned for the data you are proposing to submit.
The data is not saved. Try the POST .../submissions/score-preview endpoint During Submissions Window
+ During Submissions Window
GET .../submissions/{id}/score to view the score for the data after it is submitted.
This submission data is saved under the submissionId and retrieved to view the score.
Try the GET .../submissions/{id}/score endpoint
- Improvement Activities (IA) Scoring
+ Improvement Activities (IA) Scoring
Example IA Submission
+ Example IA Submission
Example Scoring
+ Example Scoring
.../submisisons/score-preview endpoint (above) to see the scoring response.
- Promoting Interoperability (PI) Scoring
+ Promoting Interoperability (PI) Scoring
Example PI Submission
+ Example PI Submission
Example Scoring
+ Example Scoring
.../submisisons/score-preview endpoint (above) to see the scoring response.
- Quality
+ Quality
Example Quality Submission
+ Example Quality Submission
Example Scoring
+ Example Scoring
.../submisisons/score-preview endpoint (above) to see the scoring response.
Submissions
+ Submissions
Frequently Asked Questions
+ Frequently Asked Questions
- General and Developer Preview
+ General and Developer Preview
Submissions API
+ Submissions API
-
@@ -61,7 +61,7 @@ const FrequentlyAskedQuestions: React.FC PY23 Questions and Known Issues
+ PY23 Questions and Known Issues
diff --git a/src/app/components/resources-and-support/help.tsx b/src/app/components/resources-and-support/help.tsx
index ecf8a9ba..3d96a206 100644
--- a/src/app/components/resources-and-support/help.tsx
+++ b/src/app/components/resources-and-support/help.tsx
@@ -6,21 +6,21 @@ const Help: React.FC
diff --git a/src/app/components/resources-and-support/terms-of-service.tsx b/src/app/components/resources-and-support/terms-of-service.tsx
index 1558d7f7..e07465ce 100644
--- a/src/app/components/resources-and-support/terms-of-service.tsx
+++ b/src/app/components/resources-and-support/terms-of-service.tsx
@@ -6,70 +6,70 @@ const TermsOfService: React.FCHelp
+ Help
-
diff --git a/src/app/components/topics/announcements.tsx b/src/app/components/topics/announcements.tsx
index ab0a5f0f..5cbcdae8 100644
--- a/src/app/components/topics/announcements.tsx
+++ b/src/app/components/topics/announcements.tsx
@@ -6,14 +6,14 @@ const Announcements: React.FCAPI Terms of Service Agreement
- API Terms of Service Agreement
+ Scope
- Scope
+ Data Rights and Usage
+ Data Rights and Usage
- Accounts/Registration
- Accounts/Registration
+ Attribution
- Attribution
+ Service Management
+ Service Management
- Right to Limit
- Right to Limit
+ Service Termination
- Service Termination
+ Liability
+ Liability
- Disclaimer of Warranties
- Disclaimer of Warranties
+ Limitations on Liability
- Limitations on Liability
+ Disputes
- Disputes
+ No Waiver Rights
- No Waiver Rights
+
Announcements
+ Announcements
- General
- General
+ Submission API
+ Submission API
- Measures Repository
+ Measures Repository
Change Log
- Change Log
+ Submission API
+ Submission API
{buildTableHeader()}
{buildTableBody(submissionChangesTable)}
- Measures Repository
+ Measures Repository
{buildTableHeader()}
{buildTableBody(measuresChangeTable)}
diff --git a/src/app/components/topics/developer-preview.tsx b/src/app/components/topics/developer-preview.tsx
index bbe14861..cb3b989e 100644
--- a/src/app/components/topics/developer-preview.tsx
+++ b/src/app/components/topics/developer-preview.tsx
@@ -7,8 +7,8 @@ const DeveloperPreview: React.FC
diff --git a/src/app/components/topics/introduction.tsx b/src/app/components/topics/introduction.tsx
index 0b4f350d..cf254252 100644
--- a/src/app/components/topics/introduction.tsx
+++ b/src/app/components/topics/introduction.tsx
@@ -6,42 +6,42 @@ const Introduction: React.FCDeveloper Preview
- Developer Preview
+
diff --git a/src/styles/_global.scss b/src/styles/_global.scss
index cc756994..02aa1ef1 100644
--- a/src/styles/_global.scss
+++ b/src/styles/_global.scss
@@ -1,5 +1,7 @@
@import './variables';
@import 'font-awesome/css/font-awesome.min.css';
+@import '@cmsgov/design-system/css/index';
+@import '@cmsgov/design-system/css/core-theme';
body {
margin: 0;
@@ -88,6 +90,9 @@ a.qpp-docs-title-back {
.qpp-docs-title-text {
color: #fff;
+ font-size: 24px;
+ margin-top: 20px;
+ margin-bottom: 10px;
}
/* Design System Overrides */
@@ -95,10 +100,9 @@ a.qpp-docs-title-back {
font-family: Rubik, Arial, 'Helvetica Neue', Helvetica, sans-serif;
}
-.ds-h1,
-.ds-h2,
-.ds-h3,
-.ds-h4 {
+.ds-text-heading--2xl,
+.ds-text-heading--xl,
+.ds-text-heading--lg {
font-weight: normal;
}
Easily submit and score QPP data in real-time via API
- Easily submit and score QPP data in real-time via API
+ {`${envConfig.qppCmsUrl}/api/submissions`}
{`${envConfig.qppCmsUrl}/api/eligibility`}
Explore and integrate with the Submissions API
- Explore and integrate with the Submissions API
+ Stay Up To Date
- Stay Up To Date
+