One of the few things that people are aware of is that SMART on FHIR enables, but does not explicitly specify how to support access controls on patient data. Folks who are familiar with the OAuth 2.0 specifications will readily understand that the principle mechanism by which access is requested and controlled is through scopes. A scope is a named thing that describes something that the application desires access to. Within the OAuth 2.0 flow, the client app requests one or more scopes, and the authorization flow grants access to a possibly limited subset of those scopes (or the full set of requested scopes). You can see this in action in certain app workflows for Apps working with Twitter or Facebook where you are requested for a set of capabilities (e.g., e-mail address, contact lists, the ability to post on your behalf), and you can reject one or more of these, but the application still works (possibly with limited functionality).
SMART on FHIR specifies a flow in which the user authorizes the app (see Authorized App in the diagram below).
The expectation is that the application will first authenticate the user, and then request them to authorize certain accesses to resources they control. Normally these requests are related to specific scopes. In SMART on FHIR, there are a defined set of standard* SMART on FHIR scopes. Common scopes might related to the proposed rule might be things like Patient/Observation.read (the ability to read any Observation), or Patient/Condition.read. Other scopes it defines include things like Patient/Appointment.write (the ability to create or update an appointment).
But implementers of API services don't have have to limit themselves to just the SMART scopes. They can offer the patient the ability to further restrict what data the application can access. For example, consider the case where I might want to use an application that does some useful stuff with my blood pressure, height, weight, cholesterol, A1C and blood pressure data, but it also does stuff with other lab results that I don't want it to access? Could I limit the access? Well, I personally cannot, but the implementer of the API service CAN offer me the ability to restrict Observations to a set of common results (or even let me create a list of LOINC codes).
How would this work? The EHR Authorization server would have to be smart (as well as SMART), and offer me opportunities to support not just restricting scopes, but to also gather additional information from me about other restrictions I want to place on the data. It could then store that information in memory and associates it with the code it returns to the client application. When the client application exchanges that code for an access token, these additional restrictions can be recorded in claims on the access token it returns.
Then, when the application makes a request, the API server can check to see that the request is consistent with the claims in the access token. And when the APP makes a request that the patient wanted blocked, it can do one of several things: The first is to act as if the data that the application requested simply isn't present, and otherwise act normally. This is a good case because it won't intrude on application integration because there will always be cases where data it asks for isn't present, and so it will deal with it. The second thing the API server could do is report an error, in which case the application itself might break (good ones won't break), or have reduced functionality because some query it thought it combine fails.
The beauty of this is that it allows the API server implementer to go beyond just SMART on FHIR scopes, still work according to the standard, and yet provide the patient with more control over what information is accessed on a PER application basis. This App can have access to my weight, that one (which makes stupid remarks when it goes up or down) cannot. Furthermore, there's nothing that says this access need remain. If I'm a really clever implementer, I can simply associate the restrictions with a claim in the token that points somewhere to the patient preferences for what the app using that token can access, and the patient can later change those preferences.
So there you have it, how to have fine-grained access control in SMART on FHIR. And while everyone might think fine-grained is better, recent research seems to indicate otherwise (at least for espresso).
Keith
* OK, Draft Standard, as SMART on FHIR is not yet quite a full-fledged standard, but you get the point.
SMART on FHIR specifies a flow in which the user authorizes the app (see Authorized App in the diagram below).
The expectation is that the application will first authenticate the user, and then request them to authorize certain accesses to resources they control. Normally these requests are related to specific scopes. In SMART on FHIR, there are a defined set of standard* SMART on FHIR scopes. Common scopes might related to the proposed rule might be things like Patient/Observation.read (the ability to read any Observation), or Patient/Condition.read. Other scopes it defines include things like Patient/Appointment.write (the ability to create or update an appointment).
But implementers of API services don't have have to limit themselves to just the SMART scopes. They can offer the patient the ability to further restrict what data the application can access. For example, consider the case where I might want to use an application that does some useful stuff with my blood pressure, height, weight, cholesterol, A1C and blood pressure data, but it also does stuff with other lab results that I don't want it to access? Could I limit the access? Well, I personally cannot, but the implementer of the API service CAN offer me the ability to restrict Observations to a set of common results (or even let me create a list of LOINC codes).
How would this work? The EHR Authorization server would have to be smart (as well as SMART), and offer me opportunities to support not just restricting scopes, but to also gather additional information from me about other restrictions I want to place on the data. It could then store that information in memory and associates it with the code it returns to the client application. When the client application exchanges that code for an access token, these additional restrictions can be recorded in claims on the access token it returns.
Then, when the application makes a request, the API server can check to see that the request is consistent with the claims in the access token. And when the APP makes a request that the patient wanted blocked, it can do one of several things: The first is to act as if the data that the application requested simply isn't present, and otherwise act normally. This is a good case because it won't intrude on application integration because there will always be cases where data it asks for isn't present, and so it will deal with it. The second thing the API server could do is report an error, in which case the application itself might break (good ones won't break), or have reduced functionality because some query it thought it combine fails.
The beauty of this is that it allows the API server implementer to go beyond just SMART on FHIR scopes, still work according to the standard, and yet provide the patient with more control over what information is accessed on a PER application basis. This App can have access to my weight, that one (which makes stupid remarks when it goes up or down) cannot. Furthermore, there's nothing that says this access need remain. If I'm a really clever implementer, I can simply associate the restrictions with a claim in the token that points somewhere to the patient preferences for what the app using that token can access, and the patient can later change those preferences.
So there you have it, how to have fine-grained access control in SMART on FHIR. And while everyone might think fine-grained is better, recent research seems to indicate otherwise (at least for espresso).
Keith
* OK, Draft Standard, as SMART on FHIR is not yet quite a full-fledged standard, but you get the point.
Here is my favourite BMI calculator. This calculator help you in calculating your health and fitness.
ReplyDelete