search

smart-on-fhir / smart-scheduling-links

Clinical Appointment Slot Discovery
28 stars 15 forks source link

Access control for published slot data? #20

Closed jmandel closed 3 years ago

jmandel commented 3 years ago

To ensure that availability data can be used in a wide (and growing and dynamic) ecosystem, we should recommend that they be published openly (rather than authenticated, or behind a VPN, or otherwise controlled).

jmandel commented 3 years ago

From discussion: note that with the $bulk-publish model, each client request does not require additional compute, so it should scale well across many clients without need for custom-negotiating access tokens, client keys, etc.

cooperthompson commented 3 years ago

Offering another perspective, I do think both EHR vendors and health systems will probably want to know which external clients are using their availability data. We'd really need system-level authentication of some sort to support that. That can be something fancy like JWT assertions OAUth2/client_credentials, or just Basic Auth with a service account, of something even less secure. Do we want to trade away the benefits of having system identity for reporting and troubleshooting?

Epic has a super-minimal Epic-Client-ID header that is the lowest possible level of authentication (since client IDs aren't secrets). But ultimately we almost always do want some way to identify who the calling system is so we can reach out to them when they have a runaway for-loop that is hammering our servers. Web logs have client IP address, but often that just tells you it is coming from AWS or Azure these days...

jmandel commented 3 years ago

Agreed that "closed loop" interactions are really nice.

I wonder if we might get some of these benefits from public announcements / issue reporting, and an implementers mailing list that we API hosts + client apps to sign onto for announcements. In other words, can we get some of the benefits of a narrow/closed ecosystem (e.g., clear points of contact) without applying technical limitations?

cooperthompson commented 3 years ago

That would handle the well-behaved players. But there are also many well-meaning but still-learning folks that have (for example) some class project in university to make some app that could look at this API, and they probably won't always know to hit the mailing list.

Our open.epic sandbox has a completely wide open FHIR REST API, and we see all sorts of bonkers behavior. We had someone that was doing an Observation.read on the same Observation every ~7 seconds for the better part of a year. We didn't have a client ID, so we didn't know who to reach out to. They probably were just playing around then left something running on a server somewhere and forgot about it.

Also, if we deploy bug fixes or updates that require a client change something, a public announcement group would catch some, but probably not all users of the API.

jmandel commented 3 years ago

For sure, I've seen my share of "bonkers" behaviors too, just from the sandbox perspective :-)

Ultimately it's infeasible to track down and address all the strange and incorrect things that people want to do with widely available data (whether they get them directly from a Slot Publisher or scrape them from a consumer app), but I'd love to explore lightweight interactions that could help.

One thing that came up here is the mailing list idea.

Another is the idea of an optional client identifier of some kind. If it was optional, would you still find this useful? Like an optional FHIR-Bulk-Publish-Client: <<URL for more info>> header that folks could optionally populate? Or would making it optional negate its utility?