Stream: implementers
Topic: Smart on fhir - no EHR
Matthew Koch (Nov 29 2018 at 22:18):
Hi all. I’ve seen a lot of information about SMART on fhir referenced here. Most of the scenarios I have come across deal with a backing EHR system. Is SMART on FHIR still applicable if you are building a server on top of a data warehouse? Or would dropping down to the OAuth level and simply using one of the defined flows such as client credentials make more sense?
Grahame Grieve (Nov 29 2018 at 22:40):
I would still use Smart on FHIR as long as the server is serving FHIR resources. It's a vary shallow profile on OAuth2 based on good security analysis, along with bindings to a FHIR server (scopes etc). Why redo that?
Muhammad Abubakar Ikram (Nov 30 2018 at 07:01):
@Matthew Koch Actually Smart on FHIR has an app gallery so if your health data repository also implement the security layer defined by Smart on FHIR, you will be able to use those apps against your health data. You can do this if you want to leverage your health data repository with this functionality, Otherwise you can ofcourse implement other security layers and their flows of your choice, But then only your's client would be able to talk to your FHIR server.
Elano Machado (Nov 30 2018 at 15:15):
@Muhammad Abubakar , do you know where we can download this doc/specification about security layer by Smart on FHIR? I would like to try some apps against my health data. Thanks in advance!
Mikael Rinnetmäki (Dec 02 2018 at 05:33):
@Matthew Koch, you could say the #finnish PHR is a server on top of a data warehouse. There's no EHR behind it. And it uses SMART to allow apps access to the data.
Or the other way to look at it is that the #finnish PHR is the data warehouse exposing data to servers using SMART. :)
Muhammad Abubakar Ikram (Dec 03 2018 at 09:30):
@Elano Machado please go here https://smarthealthit.org/
Brian Postlethwaite (Dec 03 2018 at 09:35):
Probably want to look at the more recent version now at http://hl7.org/fhir/smart-app-launch/
Matthew Koch (Dec 03 2018 at 21:58):
Thanks all who replied. Most of the examples for SMART assume EHR integration, or at least the ones I've been exposed to. Our use case is to provide RESTful API access to our partners who want to consume clinical research data for their own analysis purposes. These are not "apps" per say, but more like simple clients that would need to go through the appropriate authentication/authorization layers before data access would be granted. This exchange would likely end up being machine to machine in nature once the handshake is established.
The simplest example I can think of is this: https://petstore.swagger.io/ - just swap out the resources for ones we will be exposing from our data warehouse.
@Grahame Grieve / @Mikael Rinnetmäki / @Muhammad Abubakar
I certainly do not want to reinvent anything here which is why we are looking at SMART. I've been unable to wrap my head around which model or flow makes sense for us, as we are not really launching apps. Looking at http://hl7.org/fhir/smart-app-launch/, even the "standalone" scenario assumes eventual authorization against an EHR authorization server.
Grahame Grieve (Dec 03 2018 at 22:07):
EHR is neither here nor there. You can use smart app lauch against a terminology server.
Grahame Grieve (Dec 03 2018 at 22:07):
I think you are saying that you don't want to have user authorization in play
John Moehrke (Dec 03 2018 at 22:39):
Matt, there are an infinite number of security models. SMART is provided as a bundle that should work for most use-cases. SMART does not attempt to say that it is the only security model.
- There are some that are using Mutual-Authentication-TLS, using the client certificate as authenticated within the TLS protocol. This is useful for system-to-system, but does have challanges.
- There is the SMART backend services profile that is being looked to for these system-to-system but using OAuth, and leveraging SMART. Have you looked at this? https://github.com/smart-on-fhir/fhir-bulk-data-docs/blob/master/authorization.md
John Moehrke (Dec 03 2018 at 22:42):
-
There are other OAuth profiles, including a simple JWT token profile from IHE -- IUA https://wiki.ihe.net/index.php/Internet_User_Authorization
** Which does include a SAML tunneling inside JWT -
There are even SAML profiles, using SAML-SSO-Profile.
- There are use of XDS/XCA to communicate FHIR-Documents (along with CDA and PDF). These use SOAP WS-Security and SAML
- There is an infinite set
What is important is that both (all) sides of the communication must agree
Matthew Koch (Dec 04 2018 at 00:51):
@Grahame Grieve That's not true re: user authorization - we'd need to have segmentation between what users are able to retrieve data for specific data sets - e.g., it must be protocol (ResearchStudy) driven. A user must authenticate, but any requests must also be authorized.
Matthew Koch (Dec 04 2018 at 00:53):
@John Moehrke Thanks for the list. So it seems there are quite a few different ways to go - in fact, I almost wish this list was smaller so I could attempt to wrangle one and see it through. The "all sides of the communication must agree" part is probably the hardest part.
Given what I have attempted to describe, does it sound like SMART still has a place, or would I be better suited to look at another security model?
Grahame Grieve (Dec 04 2018 at 01:45):
A user must authenticate, but any requests must also be authorized.
Well, of course, that's exactly how smart app launch works
Grahame Grieve (Dec 04 2018 at 01:46):
it sounds like the mismatch you see is between the smart defined scopes, and what you want the user to be able to choose. The smart app scopes are a matter of ongoing discussion
Mikael Rinnetmäki (Dec 04 2018 at 07:18):
@Matthew Koch I'd still say SMART should be good for you. You could take a look at https://www.kanta.fi/documents/20143/91486/PHR+authorization.pdf/9fdb48d0-a6c8-0bc6-10ab-35495ca030b4 for instance, or to other docs at https://www.kanta.fi/en/system-developers/technical-instructions.
In this case, the app ("client", if you will) itself initiates the authorization process, and the authorizing party must authorize the app to access their data. Your flow might be different, but if you want the research subjects to give their consent to use the data, this is where it would take place.
After successful authorization, the app gets an access token and a refresh token. Using those tokens the app may access the data in the resource server as it needs, as long as the authorization is valid (using refresh tokens it will be valid until the authorization is explicitly revoked).
Muhammad Abubakar Ikram (Dec 04 2018 at 10:03):
@Matthew Koch Keeping the things simple, if you have your only private clients and you don't want to public your FHIR server you can start with OAuth2.0 client credentials (https://tools.ietf.org/html/rfc6749#section-4.4) flow or if you want to authenticate not only clients but also the users you can use OAuth2.0 resource owner flow (https://tools.ietf.org/html/rfc6749#section-4.3). Furthermore, in future, you can also add a SMART-on-FHIR security layer to your server if you need it.
John Moehrke (Dec 04 2018 at 15:36):
Given that Research Subject has provided a Consent with the authorization rules (what data they authorize the research study to use), then you can just indicate in your Implementation Guide that it is up to the Resource Server to enforce that consent. The OAuth scopes defined by SMART-on-FHIR are not a replacement for consent rules. Even in the prime use-case for SMART-on-FHIR there is an expectation that the Resource Server is responsible for enforcing relevant patient privacy consents, and business rules. This server side logic is not often mentioned publicly, and it doesn't need to be often. In your case it needs to be more clear it is a functional requirement, while the mechanism still can be unmentioned.
So, you can declare that SMART-on-FHIR is used; and express that the resource server is expected to enforce the consent identified for that research study. This is reasonable, it leverages SMART, it leverages Consent, and it is similar to normal use of SMART.
John Moehrke (Dec 04 2018 at 15:42):
That said, it might be useful to expand SMART-on-FHIR with a recognition of ResearchSubject as a special case of indirection to Patient. This would likely be necessary with the advancements of research study mechanics.
John Moehrke (Dec 04 2018 at 15:43):
Other changes to SMART are in discussion, including mechanisms to identify the PurposeOfUse for the request. In your case this would be Research, and the ResearchStudy would be the specific PurposeOfUse. These improvements of SMART could certainly be initiated.
John Moehrke (Dec 04 2018 at 15:47):
A hack that is likely to happen without actual changes is a creative use of 'client-id' of the 'app'; where each project is effectively a different app... Not proper, but I am sure it will be done.
John Moehrke (Dec 04 2018 at 15:47):
That said... I expect an access for the purpose of a Research Study would more likely be a system-to-system and look more like flat-file access. So that security model should be strongly considered. (vs SMART-on-FHIR which is more designed for user initiated interactive sessions with an identified and authorized app)
Hugh Glover (Dec 04 2018 at 16:21):
Using SMART-on-FHIR to get data to be used in a clinical trial by querying patient records on the basis of knowing the ResearchSubject requires the indirection from ResearchSubject to Patient to be preserved. If all I know is a ResearchSubject ID then the response I get from SMART should not allow me to identify the patient any more than I did when I raised the query.
Grahame Grieve (Dec 04 2018 at 18:50):
I feel as though this is a good connectathon subject: smart-on-fhir + research subject for research data analysis
Hugh Glover (Dec 04 2018 at 20:36):
I'll put it on the list
Christiaan Knaap (Dec 05 2018 at 08:06):
Notifying @Lilian Minne
Bram Wesselo (Jan 29 2019 at 13:37):
it sounds like the mismatch you see is between the smart defined scopes, and what you want the user to be able to choose. The smart app scopes are a matter of ongoing discussion
Any news on this subject (or a solution for a standardized authorization for clinical research data)? Did you discuss it at the connectathon? Thanks
Last updated: Apr 12 2022 at 19:14 UTC
