Stream: smart
Topic: how does an implementer grant access based on scopes
Eric Haas (May 16 2018 at 23:18):
In a Questionnaire call, I was was asked how a patient vs provider facing app would be able to access only the questionnaire for patients to fill out themselves vs those that authored by providers? because of the login scope the EHR knows it dealilng with a patient, but how it know which Questionnaires are OK to share since they are all sitting at the same endpoint? I am assuming (secuity) tags?
Michael Donnelly (May 16 2018 at 23:21):
In Epic, whatever resource you hit, an early step in the logic is to check whether you can see it.
Michael Donnelly (May 16 2018 at 23:23):
1. Check if the client is allowed to access that type of resource.
2. Check if the user is allowed to access that type of resource.
3. Check if the user is allowed to see that kind of data for that patient.
4. Check if the data are specifically restricted (e.g. encounters in behavioral health departments) and, if so, if this user is able to break through that restriction.
Michael Donnelly (May 16 2018 at 23:23):
All that applies for patients and providers, though the logic is different.
Kevin Shekleton (May 16 2018 at 23:23):
Same for Cerner. We have lots of additional authorization/permission/filtering checks applied as well.
Eric Haas (May 16 2018 at 23:25):
OK thanks
Drew Torres (May 16 2018 at 23:25):
We also determine persona based on the endpoint used to access the resource (provider vs patient) that allows additional business rules to be applied.
Michael Donnelly (May 16 2018 at 23:26):
[Seven minutes turnaround to get answers from three implementers after one a.m.]
Drew Torres (May 16 2018 at 23:28):
Dedication... and jet lag
John Moehrke (May 17 2018 at 14:02):
Security tags on the data would tend to be a 5th test to Michael's list. I would agree that his list is first. Further within Security Tags there is a more useful use-case that only uses the Confidentiality vocabulary, as these are non-overlapping 'risk' values. The value given is usually influenced by the content of that resource. The sensitivity vocabulary is usually only a temporary tag between looking at the resource for sensitive topics, and the picking of which Confidentiality value to tag it with. Other vocabulary are more likely to be transactional.
The PurposeOfUse is often fixed at a single (Treatment) purpose of use for single purpose API endpoints. Supporting many purposeOfUse is unusual, but it is part of the design. PurposeOfUse would factor into decision mixed somewhere into steps 1-5... does this user have permission to use the data for that purposeOfUse, is this data allowed (was it collected for this purpose) to be used for this purposeOfUse, has the patient authorized (consent or contract) this user to have this data for this purpose...
Last updated: Apr 12 2022 at 19:14 UTC
