Some weeks I'm just slow. I probably spent a week trying to figure out how to deal with Client registration for SMART on FHIR applications. One of the things I discovered in the process after I did the math:
Think about the number of different applications that patients could use. Oh, maybe a 100 if we are lucky. Most of us will use one or two. I know from previous experience the average number will be around 1.1 (at least at first).
Think about the number of patients a provider sees in a year. Say they have a panel of 2-3 thousand patients, they probably see somewhere between 1/4 to 1/2 of these annually. Call it an even 1000.
Think about the fact that the application on your phone and the same application on your wife's phone, even though they are talking to the same endpoint, don't necessarily know about each other, and so if using Dynamic Registration probably get assigned separate client_id and client_secret values.
Now, look at a 100 provider practice, and understand that some of the providers in that practice see the same patients that other providers do. So 100 * 1000 * 50% (for overlap) 50,000 patients seen in that practice (NOTE: These are rough numbers, what is important is the magnitude).
Now, just think about the fact that if every 50% of the patients each use an application, and each one
requires its own client_id and client_secret, you now have 25,000 client_id and client_secret values for what, maybe 100 applications. And if any of those applications are busted (meaning they register more often than they need to because someone missed something in the spec), you could have some applications registering daily or hourly or whatever the expiration time is on the authorization token, and now that number could really balloon.
Is this realistic? Is it valuable? Is it worth having to manage? Would it not be better to have 100 client secrets and client ids which you could then manage if necessary?
I know ONC is promoting use of Dynamic Client Registration, but I look at the cost of doing that, and I am quite certain that there really is a better way. It's interesting that Twitter, Facebook, Google and many other API publishers outside of healthcare haven't been using OAuth 2.0 Dynamic Application Registration.
I'm wondering, is Dynamic Application Registration really Smart?
Keith
Think about the number of different applications that patients could use. Oh, maybe a 100 if we are lucky. Most of us will use one or two. I know from previous experience the average number will be around 1.1 (at least at first).
Think about the number of patients a provider sees in a year. Say they have a panel of 2-3 thousand patients, they probably see somewhere between 1/4 to 1/2 of these annually. Call it an even 1000.
Think about the fact that the application on your phone and the same application on your wife's phone, even though they are talking to the same endpoint, don't necessarily know about each other, and so if using Dynamic Registration probably get assigned separate client_id and client_secret values.
Now, look at a 100 provider practice, and understand that some of the providers in that practice see the same patients that other providers do. So 100 * 1000 * 50% (for overlap) 50,000 patients seen in that practice (NOTE: These are rough numbers, what is important is the magnitude).
Now, just think about the fact that if every 50% of the patients each use an application, and each one
requires its own client_id and client_secret, you now have 25,000 client_id and client_secret values for what, maybe 100 applications. And if any of those applications are busted (meaning they register more often than they need to because someone missed something in the spec), you could have some applications registering daily or hourly or whatever the expiration time is on the authorization token, and now that number could really balloon.
Is this realistic? Is it valuable? Is it worth having to manage? Would it not be better to have 100 client secrets and client ids which you could then manage if necessary?I know ONC is promoting use of Dynamic Client Registration, but I look at the cost of doing that, and I am quite certain that there really is a better way. It's interesting that Twitter, Facebook, Google and many other API publishers outside of healthcare haven't been using OAuth 2.0 Dynamic Application Registration.
I'm wondering, is Dynamic Application Registration really Smart?
Keith
You will be covering your alternative... right?
ReplyDeletePosting an email response here:
ReplyDelete==== Excerpt from Blog ==
Think about the fact that the application on your phone and the same application on your wife's phone, even though they are talking to the same endpoint, don't necessarily know about each other, and so if using Dynamic Registration probably get assigned separate client_id and client_secret values.
==== Upto here ===
From the above excerpt, it seems to indicate that each instance of App would get a separate Client ID/Secret. Is that really true? Our understanding is that the client ID/Secret is generated at the “App” level, same as any manual or self-service registration process would do; and once done, the same ID (and secret if Confidential App) will be used by each instance of the App. So, in a sense, dynamic registration is no different than manual registration other than the obvious fact that this is done via API.
Here’s link to the SMART team’s web page that describes both the manual and dynamic approach
http://docs.smarthealthit.org/sandbox/register/
Could you clarify if we misunderstood your point, or if our understanding of the dynamic registration spec is wrong? If my post gets published, feel free to comment publicly.
Thanks in advance and looking forward to seeing you at the Interop Forum tomorrow!
Regards
Avinash