Stream: fhircast-github
Topic: docs / Issue #31 Clarify implications of user/patient-cen...
Github Notifications (FHIRcast) (May 16 2018 at 11:40):
dennispatterson edited Issue #31
Because events such as "switch-patient-chart" exist, but OAuth allows patient-centric scopes that limit interaction to a single patient (e.g. patient/MedicationRequest.read), the documentation should clarify that to support this sort of switching, user-centric scopes must be used. Or, that if context is switched to a different patient, an app can be notified that a switch event occurred, but not informed of the new patient information.
Github Notifications (FHIRcast) (May 16 2018 at 11:57):
dennispatterson edited Issue #31
Because events such as "switch-patient-chart" exist, but OAuth allows patient-centric scopes that limit interaction to a single patient (e.g. patient/MedicationRequest.read), the documentation should clarify that to support this sort of switching, user-centric scopes must be used.
Or, that if patient-centric scopes are used and context is switched to a different patient, an app can be notified that a switch event occurred, but not informed of the new patient information.
Github Notifications (FHIRcast) (Dec 11 2018 at 16:35):
isaacvetter labeled Issue #31
Because events such as "switch-patient-chart" exist, but OAuth allows patient-centric scopes that limit interaction to a single patient (e.g. patient/MedicationRequest.read), the documentation should clarify that to support this sort of switching, user-centric scopes must be used.
Or, that if patient-centric scopes are used and context is switched to a different patient, an app can be notified that a switch event occurred, but not informed of the new patient information.
Github Notifications (FHIRcast) (Dec 11 2018 at 20:10):
JohnMoehrke commented on Issue #31
We discussed this on the FHIR Security call today. There is a risk due to the content of the notification. If the notification was just the FHIR _id or url; then there would be manageable risk, as the app would then need to make the request to the FHIR Server using that app specific OAuth token. However due to the notification can contain some of the content of the protected resources (aka PHI) then there is a risk. The hub provides this data, but that hub is not able to know if the app to be notified should have access to that data.
I don't think this risk is limited to patient switch and patient scopes. As there may be resource specific restrictions, or even privacy restrictions.
It should likely be indicated that any context switch may require participating apps to get new security token. This would be most clearly needed where the context switches patients, and where the app security token is patient specific. Not all context switches require new security token, so this should just be noted.
An alternative is to have well defined subsets (elements). Likely too hard to manage.
Alternative is to remove the ability to send sensitive information in the notification. This will create more interactions by the apps, but it is the right security thing to do.
Last updated: Apr 12 2022 at 19:14 UTC
