Stream: Da Vinci/plan-net-connectathon
Topic: Questions to CMS for Open Access
Saul Kravitz (Sep 11 2020 at 18:51):
Neophytos. @Neophytos Iacovou
Robert Little
Anand @anand rakshe
Shaheer @Shaheer AbdulKareem
Please draft a question for CMS that Saul will submit through DaVinci channels for an official response from CMS. saul@mitre.org
Shaheer AbdulKareem (Sep 11 2020 at 19:12):
Saul Kravitz said:
Neophytos. Neophytos Iacovou
Robert Little
Anand anand rakshe
Shaheer Shaheer AbdulKareem
Please draft a question for CMS that Saul will submit through DaVinci channels for an official response from CMS. saul@mitre.org
@Saul Kravitz
@anand rakshe
@Neophytos Iacovou
Below is what I came up with, please feel free to rephrase and/or add additional details as needed:
Does using a public anonymous token to access the service comply with the CMS requirement of having public access to the Provider Directory?
This approach will not limit the access to an individual person.
It will ensure that the service accessed by an application gets tracked properly, stats gets collected & also allows us to manage the scalability and protect the service in a better way.
Neophytos Iacovou (Sep 11 2020 at 19:32):
Shaheer AbdulKareem said:
Saul Kravitz said:
Neophytos. Neophytos Iacovou
Robert Little
Anand anand rakshe
Shaheer Shaheer AbdulKareem
Please draft a question for CMS that Saul will submit through DaVinci channels for an official response from CMS. saul@mitre.orgSaul Kravitz
anand rakshe
Neophytos Iacovou
Below is what I came up with, please feel free to rephrase and/or add additional details as needed:
Does using a public anonymous token to access the service comply with the CMS requirement of having public access to the Provider Directory?
This approach will not limit the access to an individual person.
It will ensure that the service accessed by an application gets tracked properly, stats gets collected & also allows us to manage the scalability and protect the service in a better way.
what do you think of this version:
We understand, and agree, why CMS does not want to place barriers between an individual and their accessibility to the Provider Directory API. We are not proposing barriers between an individual and the information provided by the API.
What we are asking for clarification is on the following: can we secure access to the Provider Directory API from the 3rd party applications consuming the API?
Several mechanisms are widely and commonly used by organizations offering public access APIs; for example' using a public anonymous token, or a clientID/Secret combination.
This approach would not make it any harder for an individual to use the API. However, it will ensure the service accessed by a 3rd party application is properly tracked to the application being used, statistics are collected, and allows us to manage the scalability, and most importantly protects the API from attacks (which would now be traceable to the application - not the individual).
anand rakshe (Sep 11 2020 at 22:31):
What is true open provider directory API from FHIR server ? From non functional requirements perspective (security, performance etc) consumer of API(developer of 3rd party APP) will require authentication. All API consumers should be known and use API key(or other auth mechanism) so Payer as a provider of API knows who all the callers/developers are (this is standard industry approach today). Developers could intentionally or accidently bombard API which may create issues. (please reword as needed)
Josh Mandel (Sep 14 2020 at 13:40):
I wasn't here for the discussion so I'm inferring what might have led up to this question. That said, I would have hoped that plans could publish provider directories essentially essentially as flat public FHIR resource collections (e.g., bundles, or ndjson files) that could be publicly hosted. Having to deal with obtaining a token and then following some special protocol just to access these data seems like an extra/unnecessary step. Is the primary goal to prevent denial of service attacks? For static public stuff there are more transparent ways (e.g. whatever bags of tricks your CDN deploys).
Lee Surprenant (Sep 14 2020 at 13:59):
what about search?
Lee Surprenant (Sep 14 2020 at 13:59):
I guess that should be cacheable too, but its more than just hosting static assets, right? or are you thinking to push that to the clients?
Josh Mandel (Sep 14 2020 at 14:01):
there may be a bunch of other contexts where access control makes more sense. But for me the fundamental use case here is about getting information out of a silo and into places where it can be aggregated and made more useful. For example, I would not expect most plans to offer a really excellent search-as-you-type API experience with well-honed results -- but I could definitely imagine a third party building that if the data were available.
Josh Mandel (Sep 14 2020 at 14:04):
So to be specific, I expect it would meet CMS requirements if plans hosted a public file with all the data and no access control. (Then as a "value add", plans might offer additional APIs that might maybe have requirements like public authentication tokens and so forth.)
Neophytos Iacovou (Sep 14 2020 at 14:20):
anand rakshe said:
What is true open provider directory API from FHIR server ? From non functional requirements perspective (security, performance etc) consumer of API(developer of 3rd party APP) will require authentication. All API consumers should be known and use API key(or other auth mechanism) so Payer as a provider of API knows who all the callers/developers are (this is standard industry approach today). Developers could intentionally or accidentally bombard API which may create issues. (please reword as needed)
I've been assuming the same but as it turns out some people think we can NOT ask API consumers to identify themselves, therefore we are asking CMS to clarify if we can.
Josh, some plans may choose to offer the entire PD as you described. I'm not sure that meets the mandate given the mandate strongly urges us to implement a PD API. But if a plan decides to publish their entire PD as a "static" file asking for security on the file may not be important to them.
However, if they are building APIs and expect 3rd party apps to interact with the APIs, I think it is totally reasonable (given most of the Internet works this way) we ask the developers to identify their applications.
.What do you think?
Josh Mandel (Sep 14 2020 at 15:47):
I think GET /path/to/directory.ndjson is an API, and a simple one at that. Should be open/available. If this is available, I'm much less worried about access control on finer-grained APIs.
Saul Kravitz (Sep 14 2020 at 16:20):
So, it sounds like there are two questions:
Pre-amble:
We understand, and agree, why CMS does not want to place barriers between an individual and their accessibility to the Provider Directory API. We are not proposing barriers between an individual and the information provided by the API. What we are asking for clarification is on the following:
1) (Josh) Plans could publish provider directories essentially essentially as flat public IG-compliant FHIR resource collections (e.g., bundles, or ndjson files) that could be publicly hosted. Would an API supporting retrieval of such files (e.g., GET /path/to/directory.ndjson) satisfy CMS requirements for open access?
2) (Neophytos, Anand, Shaheer) From non functional requirements perspective (security, performance etc) consumer of API(developer of 3rd party App) should require authentication. All API consumers(apps, not users) should be known and use API key(or other auth mechanism) so Payer as a provider of API knows who all the callers/developers are (this is standard industry approach today). Developers could intentionally or accidently bombard API which may create issues. (please reword as needed)Can we secure access to the Provider Directory API from the 3rd party applications consuming the API?
Several mechanisms are widely and commonly used by organizations offering public access APIs; for example' using a public anonymous token, or a clientID/Secret combination.
This approach would not make it any harder for an individual to use the API. However, it will ensure the service accessed by a 3rd party application is properly tracked to the application being used, statistics are collected, and allows us to manage the scalability, and most importantly protects the API from attacks (which would now be traceable to the application - not the individual).
Josh Mandel (Sep 14 2020 at 17:08):
I wasn't thinking (1) was a question, but if you think there is ambiguity then it is worth getting clarification.
Neophytos Iacovou (Sep 14 2020 at 18:07):
how long does it typically take them to respond?
Saul Kravitz (Sep 14 2020 at 18:14):
@Josh Mandel : My guess is that the answer to #1 is No. That is similar to the approach that they took with the QHP formulary/directory. I think it will be interesting to see the answer.
@Neophytos Iacovou : First we need to submit via DaVinci. If there is no objection, is my version (cobbled together from your input) good to go?
I imagine it will take ~1-2 weeks to get a formal response.
Neophytos Iacovou (Sep 14 2020 at 18:34):
your version is good to go
Josh Mandel (Sep 14 2020 at 19:06):
@Saul Kravitz can you clarify to whom is this question being directed, or through what submission process?
Robert Little (Sep 14 2020 at 19:38):
Good afternoon Team, Sorry it took me so long to get into this... @Saul Kravitz , I believe your summary is accurate. I'm good with the way you have positioned the questions. The goal is NOT to limit the member but to be able to monitor and have some control over the third party application that is using the end points to ensure they are not using the end points for inappropriate purposes. This ask is not requesting anything more than what is currently industry standard.
Saul Kravitz (Sep 14 2020 at 20:17):
@Josh Mandel -- at the connectathon this issue came up, and we managed to arrange for a cameo appearance from Denise St Claire (CMS) to discuss. The conclusion is that we would submit a written version of the question to CMS via DaVinci, and they would respond publicly. I'm trying to formulate the question based on the connectathon track participants' input.
Josh Lamb (Sep 15 2020 at 18:50):
@Saul Kravitz +1 for both questions:
1.) Can we provide the directory as a file endpoint (using PlanNet R4 profiles) ?
2.) Can we require authentication?
Jason Teeple (Sep 22 2020 at 18:16):
Saul Kravitz said:
Josh Mandel -- at the connectathon this issue came up, and we managed to arrange for a cameo appearance from Denise St Claire (CMS) to discuss. The conclusion is that we would submit a written version of the question to CMS via DaVinci, and they would respond publicly. I'm trying to formulate the question based on the connectathon track participants' input.
@Robert Dieterle created similar question and has been in the Davinci backlog since mid-august. Bob, was the question submitted to CMS? https://confluence.hl7.org/display/DV/CMS+Final+Rule+Questions+Intake+Backlog
Neophytos Iacovou (Sep 24 2020 at 22:47):
Jason Teeple said:
Saul Kravitz said:
Josh Mandel -- at the connectathon this issue came up, and we managed to arrange for a cameo appearance from Denise St Claire (CMS) to discuss. The conclusion is that we would submit a written version of the question to CMS via DaVinci, and they would respond publicly. I'm trying to formulate the question based on the connectathon track participants' input.
Robert Dieterle created similar question and has been in the Davinci backlog since mid-august. Bob, was the question submitted to CMS? https://confluence.hl7.org/display/DV/CMS+Final+Rule+Questions+Intake+Backlog
have we heard back on this issue?
Jason Teeple (Sep 25 2020 at 11:03):
Not to my knowledge.
Saul Kravitz (Oct 29 2020 at 13:07):
@Viet Nguyen @Robert Dieterle
Saul Kravitz (Oct 29 2020 at 17:14):
Denise St. Clair (CMS) answered these today in our DaVinci Education session:
1.) Can we provide the directory as a file endpoint (using PlanNet R4 profiles) ? No
2.) Can we require authentication? No
Neophytos Iacovou (Nov 10 2020 at 15:27):
have they ever come back on this issue?
Saul Kravitz (Nov 10 2020 at 16:47):
The answers were No and No.
Last updated: Apr 12 2022 at 19:14 UTC
