Questions about OAuth integration and usage for Qualified Registries

[abhijeet mahajan]

Hi QPP team,

I went through OAuth API related documentation but I am still confused about the exact use of this mode of authentication for a Qualified Registry.

From last two years we have been using the one time token that we get from our security official person. 

I understand OAuth from technical perceptive but we are trying to understand how this will benefit us (as a Qualified Registry).

Also, as per the QPP Auth API documentation, this API is currently intended only for EHR application developers and not registries - is that correct ?

I am referring to the following line from the API docs :

https://qpp.cms.gov/api/auth/docs/?_ga=2.169042081.1889613517.1566234642-257741134.1565791857#/OAuth

OAuth

EHR application developers can use these endpoints to build their OAuth-enabled client applications. See QPP OAuth2 Example Client for a sample client application.

Further, following sentence from the June 2019 presentation is bit confusing as well :

"Adding OAuth will allow you to view feedback as the provider, meaning view the final feedback based on the complete data submitted on be half of the provider or group".

Could we get some more detailed explanation of the above. 

Also, the 'final feedback' that we are referring to here is the feedback that we get around July for the data that we submit in March (i.e. during the submission window).

Does it mean that we will be able to get that feedback through an API in the form of JSON object response ? if yes then could you help us to understand which API is that because we didn't find anything in the documentation.

We also tried to access the 'QPP OAuth2 Example Client' sample application but that didn't work since we don't know what credentials to be used. Could you help us with that as well.

Thanks,

Abhijeet

[abhijeet mahajan]

Hi QPP Team,

Any help with possible OAuth integration and the questions above is very much appreciated. We need to plan for this work and it will help if we get this information as early as possible.

Thanks,
Abhijeet

[Shane Jarrell]

Found this https://github.com/CMSgov/qpp-submissions-docs/tree/master/oauth_sample. Looking through it now myself.

[Sarah White]

Hi all,

Registries can also use OAuth, though a lot of the documents use the EHR language since those applications do not qualify to become Qualified Registries and get access to the API using the system-to-system token as you all do now.

A registry might consider adding OAuth because it will open up more endpoints that are on the Submissions API, such as our final scores endpoint. Registries do not have access to this under our current permissions model, but with OAuth the actual security official can grant your application permission to act in the system as them - which means you will be able to programmatically surface up that information normally reserved just in the QPP Feedback UI. We don't have public documentation on that endpoint available yet, but will closer to the production window should applications onboard this submissions window.

Let me know what other questions you may have.

[Deepak Malik]

Hi Sarah,

Below are the doubts regarding QAuth.

1. As per your reply OAuth will open more endpoints . Is there any specific link where use the response of OAuth and see those endpoints.

2. Once we have used OAuth then we dont have to use the token for submission. Is it correct ?

3. When will be documentation for OAuth  available.

Thanks,

Deepak 

[Sarah White]

Hi Deepak,

1. Oauth will allow access to endpoints we have related to final scores. We're currently in the process of updating our documentation for how these work on our Swagger site. 

2. If you are continuing as a qualified registry or QCDR, you could use oauth or a registry token to submit. OAuth would require everyone to log in and give you permission on your application, while the registry token continues to allow submission on behalf of any TIN. So for ease of use, I would recommend using a registry token to submit, but the OAuth token to retrieve information about a provider from the submissions API (and any future accessible APIs) since this can be controlled by the individual practices and providers.

3. We have some very basic oauth documentation already available here: https://cmsgov.github.io/qpp-submissions-docs/getting-started-with-oauth2. What other kinds of documentation would you like to see?

--
You received this message because you are subscribed to the Google Groups "Developer Group for QPP APIs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qpp-apis+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qpp-apis/23f3a595-be8c-4f5f-87d3-84ef8aeb1928%40googlegroups.com.

[abhijeet mahajan]

Hi Sarah,

Does that mean the final score endpoint (https://qpp.cms.gov/api/submissions/submissions/{submissionId}/score) will now be accessible only through OAuth integration OR 

you are talking about a different final score API in addition to the existing one ?

Thanks,

Abhijeet

To unsubscribe from this group and stop receiving emails from it, send an email to qpp-...@googlegroups.com.

[abhijeet mahajan]

Hi Sarah,

Do we have any new API endpoints published which will give Registries additional information than they will get through the scoring APIs accessed with registry tokens ?

 am specifically asking about following part from your answer on Sept 4.

A registry might consider adding OAuth because it will open up more endpoints that are on the Submissions API, such as our final scores endpoint. Registries do not have access to this under our current permissions model, but with OAuth the actual security official can grant your application permission to act in the system as them - which means you will be able to programmatically surface up that information normally reserved just in the QPP Feedback UI.

Thanks,

Abhijeet

[Sarah White]

Hi Abhijeet,

We have a task in our backlog to add the applicable endpoints to our documentation, but I don't have a timeline on that yet. I'll pass along to the team so we can see where we can fit that in after the submission window opens/holidays.

--

You received this message because you are subscribed to the Google Groups "Developer Group for QPP APIs" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qpp-apis+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qpp-apis/0f8c029e-69a2-4cc6-9054-436a20521106%40googlegroups.com.

[abhijeet mahajan]

Hi Sarah,

Any updates on this one ?

Thanks,

Abhijeet

To unsubscribe from this group and stop receiving emails from it, send an email to qpp-...@googlegroups.com.

[abhijeet mahajan]

Just a note to avoid redundant work on your part : I have also asked same question in the current Registry vendor support call and waiting for answer.

[Michelle Ingle]

Abhijeet, 

Wanted to followup and confirm that your question got answered in the Registry Support call?  If not, I can forward this onto our OAUTH Product team.

Thanks!

Michelle

[abhijeet mahajan]

Hi Michelle,

Nope. Question was not answered. Would be great if you could follow up.

Thanks,

Abhijeet

[Michelle Ingle]

Abhijeet, 

I have forwarded this request on to the Scoring team to better understand how the Scoring APIs integrate with OAUTH.

Thanks!

[abhijeet mahajan]

Thanks Michelle !

[Steven Szeliga]

Good Afternoon,

The OAuth token and Registry token for reporting would remain separate and could not be used in replacement of each other. OAuth will specify a user to the system and provide authorization from a UI perspective, from an API perspective, the tokens that have been available for the Development Preview and Production environment would continue to be required to hit the different endpoints. Please let me know if I can provide additional information.

[abhijeet mahajan]

Thanks Steven. 

That means there are no specific API end points which will help us to fetch 'extra' information from the OAuth integration. 

Only way to do that would be either to login to the QPP Portal directly or integrate with CMS OAuth and then still access the QPP Portal UI.

Is that correct understanding ?

Abhijeet