FHIR Chat · docs: issue 7: Determine an approach to security · cds hooks

Stream: cds hooks

Topic: docs: issue 7: Determine an approach to security

Github Notifications (Dec 17 2016 at 09:36):

kpshek commented on issue 7

In previous conversations, we have said that the CDS service should have the same access privileges as the current practitioner. Thus, the FHIR data the CDS service is able to retrieve should be only the data the current practitioner has privileges to retrieve. I confirmed this with two physicians that I work with at Cerner.

Given this, this precludes us from using the SMART Backend Services model or what is commonly referred to as B2B tokens. This is because this security model does not contain the notion of a user and thus the token is not scoped to the privileges/authorization of the current practitioner. Additionally, B2B tokens are scoped to the entire patient population but a more appropriate and secure model for a CDS Hooks invocation would be scoped to the current patient in context.

This leads us to using OAuth 2 access tokens with an embedded practitioner (and the current patient in context). Effectively, the same tokens obtained by a SMART app during an embedded launch.

I agree with @Isaac Vetter that we should use consistent field names between SMART and CDS Hooks; access_token, expires_in, and token_type (always Bearer). I think we should return scope too.

To ensure proper auditing, I think each CDS service should have it's own client id. This allows the EHR to track each FHIR access with the calling CDS service. As such, this means that each CDS service will have a distinct access token.

For performance reasons, we have also previously discussed the EHR managing the creation, lifecycle, and management of these access tokens and provide them to the CDS services upon each hook invocation. I'm fine exploring this strategy to see how it works.

---

I've had informal conversations with some on data or event-based CDS Service invocations (as opposed to the current user-invoked hooks). In this scenario there is no practitioner in context causing the CDS service to be invoked and thus will necessitate a different security model. In this case I believe we do need to leverage the SMART Backend service / B2B model. Additionally, I do not think it is necessary for the EHR to manage the OAuth access tokens in this case. I call this out here just for completeness but we'll handle/discuss this on a separate issue when we broach this topic more formally.

Github Notifications (Dec 17 2016 at 20:02):

jmandel commented on issue 7

Going back to the original two goals...

I think the discussion here is focused on (1), which is to say: how the CDS Service should authenticate itself to the EHR. If the EHR just passes the access_token (and expires_in, etc) along to the service at launch time, this works — though it's worth saying that it relies entirely on a service's SSL certificate (https URL) for security, similar to a public client app in SMART's EHR launch flow. We *could* give the client an opportunity to authenticate *before* it receives a token, e.g. by passing the service a launch id (which gets traded for a token in an authenticated call) rather than a ready-to-go access token at invocation time. This is a security design decision; we'd want to understand our threat model and choose accordingly.

For (2), which is to say "how the EHR authenticates to the service", I think my assessment back in 3/2016 was wrong, or incorrectly written. This is a use case where the Backend Service flow (with the ERH as the client and the CDS Service as the server!) would work.

Github Notifications (Jan 14 2017 at 22:41):

isaacvetter commented on issue 7

how [should] the CDS Service authenticate itself to the EHR?
(1) relies entirely on a service's SSL certificate (https URL) for security, similar to a public client in SMART's EHR launch flow.
or
(2) pass the service a launch id ... rather than a ready-to-go access token at invocation time.
Technically, either approach works; this is a security design decision

I think that the EHR providing a launch token, instead of an access token in the cds request, is prohibitively expensive in terms performance.

Also, if the launch token was somehow determined to be invalid by the OAuth server, the cds-service doesn't have the option of presenting a login screen to the user.

It seems clear to me that the EHR should provide an access token as part of the cds request to the cds-service.

For (2), which is to say "how the EHR authenticates to the service", I think my assessment back in 3/2016 was wrong, or incorrectly written. This is a use case where the Backend Service flow (with the ERH as the client and the CDS Service as the server!) would work.

Github Notifications (Jan 14 2017 at 23:53):

kpshek closed issue 7

Last updated: Apr 12 2022 at 19:14 UTC