FHIR Chat · GDPR PurposeOfUse · implementers

Stream: implementers

Topic: GDPR PurposeOfUse

René Spronk (Nov 06 2017 at 08:11):

I've been reading up on security labels and Oath scopes to see how one could support the necessity to convey 'PurposeOfUse' (GDPR art.6) in a request/query to a FHIR server. Oauth scope (see https://healthcaresecprivacy.blogspot.nl/2016/01/fhir-oauth-scope.html) seems to be an obvious candidate, but currently that's not how SMART (and FHIR itself) recommend that it be done. I'm more familiar with SAML tokens, PurposeOfUse would definitely be a SAML token, so the question is where this would end up using OAuth.

For break-glass we have a solution in the HTTP header (see http://build.fhir.org/security-labels.html#break-the-glass ) - this seems totally out of whack with a desired general solution for PurposeOfUse. It seems to encourage us to ignore OAuth and convey the PurposeOfUse (whatever it may be) in the HTTP header. Which puts the burden on the FHIR server (instead of upon OAuth) to verify if this user is allowed to use the supplied value for PurposeOfUse. I'm not a security pundit, but it seems this simply wouldn't scale.

So would this use case indeed be best served by using OAuth scopes? If using SAML, would you agree that this would be a SAML token? @John Moehrke @Jose Costa Teixeira

Jose Costa Teixeira (Nov 06 2017 at 09:03):

One perspective is that with GDPR two things are much closer: "normal" use and "break glass" ( in the sense that "break glass" means "I want to have access to data that I did not have before and here is whatever-you-need-to-give-me-that-data).

Jose Costa Teixeira (Nov 06 2017 at 09:04):

Ihave no idea about oauth and saml, but whatever brings this to the use of personal data is a step forward, I think

Jose Costa Teixeira (Nov 06 2017 at 09:07):

Btw, in GDPR, the use of Purpose is more restricted when handling sensitive data (like healthcare data) but the mechanism is the same.

Jose Costa Teixeira (Nov 06 2017 at 09:08):

I mean, "Legitimate interest" is not a valid purpose to access healthcare data. But it is one among the purposes,and the machine should behave the same way for all purposes.

René Spronk (Nov 06 2017 at 10:25):

My initial goal is to resolve how "PurposeOfUse" is identified (as code) in a request/query. If one (under GDPR) tries to use "legitimate interest" as a purpose of use related to a clinical resource, access (or: a token to access) simply won't be provided. But that's of later concern - first we need to find out how to convey the PurposeOfUse.

Grahame Grieve (Nov 06 2017 at 11:26):

@John Moehrke @Josh Mandel

Josh Mandel (Nov 06 2017 at 12:08):

There are plenty of things that could make sense here, depending on requirements. Are you doing this in the context of an existing SMART on FHIR implementation? Would you want to rely on the user to assert the purpose use, or the app, or both together, or either alone? Would you want to capture this purpose at the time of the authorization, or capture it anew with each data query?

Josh Mandel (Nov 06 2017 at 12:11):

Two examples of a potential solution: 1) just ask the user a question on the authorization screen, and capture the response, associating it internally with the access token -- in which case, no changes to the SMART protocol are needed because the implementation is entirely within the EHR system. Or 2) ask the app to pass along an additional parameter as part of the initial authorization request.

Josh Mandel (Nov 06 2017 at 12:13):

But if you simply want to log this information without needing to review it in a real-time gating fashion, then 3) putting it in a header for each API call would allow the FHIR Server to log it (and logging/audit event generation is a FHIR Server concern).

Jose Costa Teixeira (Nov 06 2017 at 13:03):

The purpose is determined at the time of defining what is data used for (say, per each use case) and the it is used in every query that is meant for that purpose.

Jose Costa Teixeira (Nov 06 2017 at 13:03):

Option 3 makes sense.

Jose Costa Teixeira (Nov 06 2017 at 13:04):

Idd, @René Spronk the purpose should be conveyed somehow. I diverged :)

Jose Costa Teixeira (Nov 06 2017 at 13:07):

According to (my working interpretation of) the GDPR, you have to provide the purpose you claim to have, and also you need to show that the purpose is lawful. For example if the purpose is "consent", you may have to show evidence of the consent. But I don't think this would be in an API call, right?

Jose Costa Teixeira (Nov 06 2017 at 13:09):

Is there a standard way to put the value of purpose in arequest? Is a header there best choice? I don't know how that works.

John Moehrke (Nov 06 2017 at 13:31):

The where to put PurposeOfUse is not an obvious thing in an OAuth world. Just like it is not clear where one would put the security ROLE of the user. In neither case would one prompt the user. But, it is not clear. In normal business logic the purpposeOfUse and the user-role come from the context of the interaction. Usually from business relationships (the user is a cardiologist at this organization [static role], and right now is the treating cardiologist [functional role], with the purposeOfUse of treatment), ( the user is a clinical data analysis at blah-organization with the purposeOfUse of treatment quality and timeleness analysis).

John Moehrke (Nov 06 2017 at 13:33):

In IHE-IUA (IHE's OAuth profile), we put these as attributes in the token. http://wiki.ihe.net/index.php/Internet_User_Authorization We however never addressed where they came from (Yes, IUA is a bit too thin to be useful).

John Moehrke (Nov 06 2017 at 13:34):

In SMART, I would expect PurposeOfUse to become an attribute of the context. As I point out above it is 'context', like the organization the request is onbehalf of, or the user-role, etc.

John Moehrke (Nov 06 2017 at 13:35):

As Rene also points out, I did model purposeOfUse into scope https://healthcaresecprivacy.blogspot.com/2016/01/fhir-oauth-scope.html

John Moehrke (Nov 06 2017 at 13:37):

That proposal was included in my comments on SMART. The ConfidentialityCode part of that post is part of the HEART scope specification. http://openid.net/specs/openid-heart-fhir-oauth2-1_0-ID1.html

John Moehrke (Nov 06 2017 at 13:39):

What is important to include in the model is that the declaration of PuposeOfUse must be an assertion of truth that all parties can trust is accurate and will be upheld. (Just like the user, user-role, user-organization, etc...) This is why I put it into the token, rather than into the scope.

John Moehrke (Nov 06 2017 at 13:43):

Lastly, yes we know that the break-glass that is in the spec today is problematic. It exists because it was written, not because it was a consensus decision. However, we don't have a better consensus yet. The results of this PurposeOfUse experiment will inform us.

René Spronk (Nov 06 2017 at 14:30):

@Josh Mandel This is not in the context of SMART, it is a generic question, not even limited to OAuth but also to SAML. How in general would we convey PurposeOfUse ?

René Spronk (Nov 06 2017 at 14:33):

@John Moehrke So in a SAML world the pruposeOfUse would be a SAML token; in an OAuth world this could be done using a scope or some other OAuth thingy (Oauth is no my strong point). HTTP header is plain ugly and unreliable, so I'm fully prepared to ignore any use of it as currently in the FHIR spec (for break glass).

René Spronk (Nov 06 2017 at 14:35):

In GDPR the PurposeOfUse may not be wholly derivable from the context of the exchange. After all under GDPR it is a classification defined by a law, which may not have a clearly defined (or 1-to-1) relationship with PurposeOfUse (as a value set) as currently defined in FHIR.

René Spronk (Nov 06 2017 at 14:38):

I haven't looked at IHE IUA as of yet (well not at a detailed level, that is) so I'll have a look at that as well.

René Spronk (Nov 06 2017 at 14:42):

IUA looks pretty similar to XUA, so to someone with a SAML background it 'feels' quite intuitive. But that doesn't mean this would be the ebst solution in the context of OAuth. How would someone, not from the healthcare IT industry, who only knows about OAuth (and not SAML) solve this ussue? Whats'the most Oauth-ish way of solving this?

Josh Mandel (Nov 06 2017 at 14:46):

I still don't have clarity on 1)who is asserting the purpose of use: an individual, or a business partner, or...? and 2) whether the purpose of use is associated with a whole session of interactions, or with individual API calls

Jose Costa Teixeira (Nov 06 2017 at 15:59):

on 1): There may be cases where the _intended_ purpose can be asserted by an individual, or determined by the individual/role/... combination. the _allowed_ purposes can be defined at design time.

Jose Costa Teixeira (Nov 06 2017 at 16:04):

One example (let me know if I am off track): Patient 1 is visiting Dr. D.
Dr. D gets the history of Patient 1's medications from another system. 2 minutes later, Dr. D gets the history of patient 2's medication.

Jose Costa Teixeira (Nov 06 2017 at 16:09):

the 2 API calls above (same mechanism, different patients) can go under the same purpose or not.

Jose Costa Teixeira (Nov 06 2017 at 16:10):

However, some(/most?) systems are not designed to consider the purpose. So the 2 API calls above are identical except for patientID.

Jose Costa Teixeira (Nov 06 2017 at 16:11):

I think it's one step forward if we add the Purpose to the calls. Then we can look at how the machines determine the purpose to put in the request.

John Moehrke (Nov 06 2017 at 16:11):

Josh, PurposeOfUse is a claim/assertion of how the data that would be communicated will be used. For most of our uses today "Treatment"+"Payment"+"normal Operations" would be the PuposeOfUse. In treatment scenarios it is often 'implied' by the interaction (The HL7 v2 messages come from X organzation so are "Treatment", or Y organization so "Payment").

Jose Costa Teixeira (Nov 06 2017 at 16:11):

anyway: heck, we are already talking purpose, which is good.

John Moehrke (Nov 06 2017 at 16:12):

PurposeOfUse gets used more when use-cases beyond "Treatment" are needed.

John Moehrke (Nov 06 2017 at 16:16):

Some systems treat PurposeOfUse just like user-role... this is why I brought up the question of how are we handling user-role in OAuth? How do we know the GP (who is allowed to make observations), from a dietitian that is only allowed to view data to assure meal ordered fits dietary requirements? I ask, because the assertion of the role of the user is just as critical to be a claim/assertion. Different in that user roles tend to get converted easily into scopes, thus don't need to persist into the security token scope.

John Moehrke (Nov 06 2017 at 16:18):

IUA looks much like XUA because hat is all that we tried to do... given the attributes we(IHE) found were needed in a SAML assertion, where/how would they be communicated when OAuth is used rather than SAML. One solution IUA offers is to just carry the SAML using OAuth. The other is a mapping to existing JWT claims, and a set of extended claims for those the needed (healthcare specific).

John Moehrke (Nov 06 2017 at 16:21):

Would be happy to see SMART adopt these from IUA. We are all one big happy family all trying to improve interop.

René Spronk (Nov 06 2017 at 17:02):

Just in case you're not familiar with them: GDPR PurposeOfUse (for use in queries/requests, and in provenance/security labels in a response) https://www.privacy-regulation.eu/en/6.htm

René Spronk (Nov 06 2017 at 17:04):

Article 9 https://www.privacy-regulation.eu/en/9.htm lists lawful grounds for 'healthcare data', in case of healthcare data one needs both a lawful ground from art6 as well as from art9, although we could probably construct 1 hierarchical value set which combines both. So let's assume there's one single code.

René Spronk (Nov 06 2017 at 17:05):

Use cases are b2b back end systems, as well as apps. We may be talking lengthy sessions, or single shot requests. Key is to create generic guidance, which could include some Whens and Ifs of course.

René Spronk (Nov 07 2017 at 08:27):

Following the guidance in https://github.com/IdentityServer/IdentityServer3/issues/67 and https://security.stackexchange.com/questions/145776/what-are-openid-scopes-and-claims I'd say that the GDPR PurposeOfUse is about the 'user' and not about the 'client'. As such it should be handled as a claim/token, and not a scope. In this context the user has to make a conscious decision as to what his/hers PurposeOfUse is.
I fully expect there to be use-cases where a client will be only allowed to access a subset of whatever it is that the user would be able to retrieve based on his/hers PurposeOfUse, that would be in the scope. But in the context of GDPR the PurposeOfUse is NOT a scope, so the IHE IUA guidance is appropriate in this case. @John Moehrke @Josh Mandel @Alexander Mense

Josh Mandel (Nov 07 2017 at 14:33):

It's an interesting point. Generally claims in the id_token are claims supported (and signed) by the identity provider and communicated to the data-receiver (client). A purpose of use is much more contextual than a user's identity -- and the GDLR goal (I think) is to communicate a purpose of use to the data holder rather than to the third-party requesting data.

John Moehrke (Nov 07 2017 at 14:57):

I agree, it is not a direct map to Identity (like structural role). It is more related to what the user is doing (like a functional role). SO it would not be part of an OpenID Connect assertion. So like cascading OAuth, it would be more of the authorization decision, than the identity decision.... right?

John Moehrke (Nov 07 2017 at 14:58):

I am not as convinced as Rene that PuposeOfUse isn't part of the scope.

René Spronk (Nov 07 2017 at 15:26):

I was certainly thinking of a cascading OAuth context. This is primarily about authorization. Some (functional) roles may use certain PurposeOfUses, others may not (e.g. breaking-glass can't be used by billing clerks; "vital interest to patient [i.e. I have an ongoing care-relationship with the patient]" can only be used if indeed one has such an active care-relationship, which some countries maintain a record of at the national level [a PIP in XACML terms], so one can verify this).
@Josh Mandel You're correct that this bit of GDPR information is of utmost importance to the data-holder, but there's is a level of authorization as to what values one could include (as a data-receiver).
I would expect the casdading Oauth environment to at least make some sensible authorization statements at a higher level of abstraction, whereas the access-control-engine used by the data-holder upon receipt of the request will have lots more detailed information at its fingertips when making access control decisions.

Josh Mandel (Nov 07 2017 at 15:31):

I could see relying on an external identity server to learn things like "what is this user's name" or "is the user a licensed practitioner". But when it comes to "what is the user's purpose", there is also an opportunity to "just ask". Trying to shoehorn purpose into user identity seems strange to me.

Jose Costa Teixeira (Nov 07 2017 at 15:45):

Purpose and identity are indeed different. the purpose can be asked, or assumed. Implying a purpose from an identity is not without issues.

Jose Costa Teixeira (Nov 07 2017 at 15:48):

Back to GDPR, what matters is that the purpose of processing / transfer falls under one of the allowed categories. Communicating the purpose is to inform the data holder so that they can claim conformance.

Debbie Bucci (Nov 07 2017 at 19:59):

We have had this same conversation in other forums. The thought was to create a scope that was returned from the authorization to the resource server primarily for auditing purposes (in addition to whatever underlying authorization may be associated by that decision) The details on specifics of how that was determined was determined out of scope. It was so controversial - it was removed.

Debbie Bucci (Nov 07 2017 at 20:37):

Is it really a user decision? thought GPRD designated classes or type of information that fell under the rule. There may be cases it falls under the rule without any conscious decision to be made. Its not always tied to the identity in that case.

John Moehrke (Nov 07 2017 at 20:48):

When the user is the patient accessing their own data, the PuposeOfUse is clear -- it is a patient request for their own data. This includes when it is an application acting on the authority of the patient. This also includes when an authorized family/guardian is acting in their capacity as authorized representative (See PATRQT)....... When the request is by a clinical user for a treatment use-case -- it is clear it is a Treatment PurposeOfUse (and likely payment and operations). ...... It is the other PurposeOfUse that we have not specifically talked about that are not obvious. We should get specific on these... We may find that these are not common enough to work on yet, thus deferring the solution outside of PATRQT and TREAT.

John Moehrke (Nov 07 2017 at 23:14):

I think what @René Spronk is looking for "GDPR Purpose" is a way to convey a 'string' that is understood by the Authority, such that the authority looks for reasons to authorize this user for that purpose. Once it determines that there is an authorized purpose with that 'string' and it does enable the requested type of data (the rest of the scope), for the requesting user (OpenID Connect token); then it can create a permit token containing a valid scope. This scope may or may-not be just like the requested scope. I say 'string' because in the context of GDPR they speak of authorized 'purposes', they don't specifically mention the HL7 defined PurposeOfUse vocabulary. This is fine, since our use of the HL7 defined PurposeOfUse vocabulary is in either a tag (security tags), or in a CodeableConcept; where a string is just as good as a well defined HL7 defined code. BUT, we need a way to declare a purpose (PurposeOfUse) in a scope request...

John Moehrke (Nov 07 2017 at 23:15):

my blog post from 2016 would support this, but might not be structured exactly right https://healthcaresecprivacy.blogspot.com/2016/01/fhir-oauth-scope.html

John Moehrke (Nov 07 2017 at 23:19):

I have an updated one too https://healthcaresecprivacy.blogspot.com/2017/05/fhir-oauth-scope-proposal-using-fhir.html

Jose Costa Teixeira (Nov 07 2017 at 23:26):

Ok that we need settle to declare a Purpose of Use.
One precision: the GDPR concern is not as detailed as this discussion. It simply says that if a company has a mechanism to process or use data, that must follow a purpose.
The impact of that on FHIR is simple: If there is an interface, the interface should be a)for a specific purpose and that purpose documented. b) The interface can serve many purposes and in that case the purposes must be clarified for each actual use.

Jose Costa Teixeira (Nov 07 2017 at 23:27):

For Purposes of Use we can use the GDPR value set or, perhaps better, a hierarchy like in ISO 14265

René Spronk (Nov 08 2017 at 09:00):

The value set for "GDPR Purpose" as implied by the legislation is fairly limited (e.g. it doesn't even discuss the patient as a user). So this certainly would have to be expanded/merged with concepts as defined in the HL7 PurposeOfUse value set.

Jose Costa Teixeira (Nov 08 2017 at 09:05):

Yep, we can have things like "patient accessing his own record" specialization. or "Emergency access because someone is at risk".
From GDPR, what is relevant is to categorize the mechanisms that are in place, not each transaction.
So if an interface supports patients to access their own records and also supports physicians in emergency situations, for GDPR this is mapped to the 2 purposes.

John Moehrke (Nov 08 2017 at 14:39):

Jose, we have those codes

John Moehrke (Nov 08 2017 at 14:40):

Rene, my read seemed to indicate that a Purpose is a open ended indicator that is the map to a Consent -purpose-. Meaning I consent to allow my data to be used by bob for the purpose of X. Thus when bob asks for access to the data, bob needs to indicate it is for purpose X. Where X could be any 'string'.

Jose Costa Teixeira (Nov 08 2017 at 15:19):

It seems unclear what GDPR means with purposes of processing.
A few weeks ago I asked if we should consider Privacy (a la GDPR) in FHIR. but this discussion seems to be around roles and authorization - so maybe I am really off topic here.

John Moehrke (Nov 08 2017 at 15:28):

Jose, who did you ask? The Security WG and CBCC WG are working on Privacy and Security. We have a "Privacy and Security Module" page.

Jose Costa Teixeira (Nov 08 2017 at 15:29):

In a previous chat around here.

Jose Costa Teixeira (Nov 08 2017 at 15:31):

GDPR has a relatively clear message: When you create a mechanism like an interface), that contains personal data , you have to make sure that there is a purpose. Authorization, access control, etc. is orthogonal to that.

John Moehrke (Nov 08 2017 at 15:41):

We are very willing to work on specific tasks. We are working on many. If you have some "Privacy (a la GDPR)" thing that you think is needed, then please elaborate on what that is. I am concerned that you think nothing is being done on "Privacy" other than "roles and authorization".

Jose Costa Teixeira (Nov 08 2017 at 16:05):

i am just commenting that in this discussion i see the roles which are not a vehicle or indicator for GDPR Purpose of Use.

Jose Costa Teixeira (Nov 08 2017 at 16:06):

i prefer to keep those isolated. Purpose is one, role is another.

John Moehrke (Nov 08 2017 at 16:11):

yes PurposeOfUse is a different vector than Role. Sorry if I caused confusion. Role is a concept defined of both structural and functional roles... My point is that PurposeOfUse is, like FUNCTIONAL-Role, in that it is more related to what is being functionally done; and unlike STRUCTURAL-Role, which is more static definition of the user identity. We have had PurposOfUse in FHIR from the very beginning.

John Moehrke (Nov 08 2017 at 16:11):

It is just no yet part of SMART... It is part of IHE-IUA profile on OAuth...

Florian Meißner (Nov 08 2017 at 19:38):

We have had good experience with a federated approach with multiple identity providers. Authentication -> oauth/ authorization -> XACML. This allows us to maintain flexibility even in distributed Systems. Advantage of this approach: The compatibility with the IHE profile "Basic Patient Privacy Consents (BPPC)" remains maintained.

René Spronk (Nov 09 2017 at 08:42):

@John Moehrke you stated "Rene, my read seemed to indicate that a Purpose is a open ended indicator that is the map to a Consent -purpose-. Meaning I consent to allow my data to be used by bob for the purpose of X. Thus when bob asks for access to the data, bob needs to indicate it is for purpose X. Where X could be any 'string'."

In essence that would seem to be correct, although I would slightly rephrase so that it's no just about consent:

Purpose is a open ended indicator that is the map to a Consent[or other lawful ground for exchange] -purpose-. Meaning I consent [or the law allows for some other reason X for sharing] to allow my data to be used by bob for the purpose of X. Thus when bob asks for access to the data, bob needs to indicate it is for purpose X. Where X could be any 'string'.

Grahame Grieve (Nov 09 2017 at 22:15):

not sure where this landed with regard to purpose of use and OAuth. but we do imply how to associate a purpose of use on a per request basis here:

Grahame Grieve (Nov 09 2017 at 22:15):

http://build.fhir.org/security-labels.html#break-the-glass

Grahame Grieve (Nov 09 2017 at 22:17):

However, I think that purpose of use is not an API thing; it's associated with coarser grained interactions for export of data - .e.g the server trusts the client to log the purpose of use when appropriate. I don't know whether that's good design, but that's how I've seen it working now.

Grahame Grieve (Nov 09 2017 at 22:17):

As for OAuth, I feel that it would be good to be able to map from the id in an openID JWT to a user role - a Resource of RIM type Role (Patient, RelatedPerson, Practitioner)

John Moehrke (Nov 10 2017 at 15:05):

So where we landed seems to me: ( a ) the mechanism written in the break-glass section seems wrong, ( b ) IHE has purposeOfUse in the OAuth JWT, and ( c ) SMART is deferring this until next revision of SMART. An OpenID Connect token should not be seen as appropriate as that is only about identity of the user, which might include structural-roles, but would not know about functional-roles or purposeOfUse. Experimentation, and experience might put it in various places. In SMART it could go into context, near other stuff that is describing the workflow context. It could go into scope. It could be that we define specific cascade of OAuth where the Nth OAuth authority is responsible for assuring the user is authorized to participate in a specific worflow/dataflow/reason. This might be the same as the consent OAuth authority (UMA), or might be an additional layer... Certainly at the GDPR level, purpose is very specific to authorization of reason for access (consent).

Grahame Grieve (Nov 10 2017 at 21:34):

why is the mechanism wrong?

Grahame Grieve (Nov 10 2017 at 21:34):

I agree the openID JWT should not contain information roles, but I think it should contain information to connect the user to a fhir resource if one is known

John Moehrke (Nov 14 2017 at 21:28):

@Grahame Grieve In my view the use of an HTTP header to convey "Break The Glass" is not appropriate because the http header is not a security mechanism. The method of conveying break-the-glass, or any PurposeOfUse, needs to be done in a way that is testable that the user has the RIGHT to declare break-the-glass, and that the breaking of that glass does not violate policy, including Consent that might forbid it. Having this in an http header enables malicious individual to simply fixup a http header and gain access that they don't have authorization. However, given there is no good alternative at this time, it seems like this is as good of a experimental method as any.

John Moehrke (Nov 14 2017 at 21:29):

I guess it might be logical to use a http header between the user and the OAuth authority, but between that decision and the relying-party (FHIR Server) the use of http header would not be the right solution.

John Moehrke (Nov 14 2017 at 21:44):

however, why not just do this very same thing with scope... and not mess around with an http header.

Grahame Grieve (Nov 15 2017 at 05:03):

@John Moehrke I completely don't understand why using a header is not the right way. Of course the server has to check that the user is authorized to make the request. that's what the server does with headers.

John Moehrke (Nov 15 2017 at 14:52):

Okay, so in your case your FHIR Server is going to also make authorization decisions, not just enforce a decision made by the OAuth authority? In that case, then it is certainly possible to use the http header.

Grahame Grieve (Nov 15 2017 at 15:05):

it must. The relationship between the resource server and the authorization server is not described, but there must be one, and the resource server must check every request and know the details of the permissions inside the processing of the request

John Moehrke (Nov 15 2017 at 15:19):

In the case of SMART, the OAuth and the Resource server are tightly bound. The Resource server does need to confirm the token, and scope; and it then must enforce the decision (which means constraining results to the scope). But in this case the Resource server is not expected to make any decisions, just enforce decisions that have already been made (by the OAuth authority).... This is a simplified model that can be done when the OAuth authority and the Resource server are tightly bound, like is defined in SMART.... This is not the only way to use OAuth, as you point out... and indeed in the case of IHE-IUA, the authorization decision is expected to be within the Resource Server.... YOUR diagram... http://build.fhir.org/security-layout.png

Josh Mandel (Nov 16 2017 at 06:57):

I'm not quite sure this assessment is complete @John Moehrke when it comes to the resource server making decisions in SMART. It's very possible in the SMART model to have a resource server enforcing all kinds of business logic of its own; the access token is one input into the decision...

Josh Mandel (Nov 16 2017 at 06:59):

Coming back to the question about headers this seems like a very simple approach that should work perfectly if your goal is just to log this Purposes of Use information alongside each request.

Grahame Grieve (Nov 16 2017 at 07:07):

Right. The resource server must actually enforce the decisions - that's where the access control engine must live. The Authorization server is not doing access control

John Moehrke (Nov 16 2017 at 14:43):

I am not proposing we eliminate the proposal for putting purposeOfUse into the http header... just that we also document alternatives and describe more fully the resource server responsibility. PurposeOfUse needs to be considered in the access control 'decision'... that is the role of OAuth... where the resource server is responsible for confirming the decision is proper (not falsified), and responsible for enforcing the decision.

Grahame Grieve (Nov 16 2017 at 15:06):

sure, happy to document it better, and deal with workflow

Mohammad Jafari (Nov 18 2017 at 19:02):

@René Spronk , et. al.:
I'm late to this thread --Kathleen brought it my attention and suggested I share some thoughts:

• Like Roles, Purpose of Use is a hierarchical concept. Someone at a hospital requests access to a patient's record for the purpose of Surgery; in the broader context, this surgery is in turn for the purpose of Treatment. These are mapped to various level of granularity of business processes. Surgery is a finer-grained process taking place within the broader context of Treatment [*]. While we usually only care about restriction on the high-level purpose (e.g. HIPAA PoUs), more detailed purposes down the hierarchy exist and may be of importance from an authorization point of view. For example, in a research project at the Foothills Hospital in Calgary, Canada, I noticed that there was a separate consent form for using data for the purpose of Genetic Research.
  While the specific narrow PoU depends on the specific instance of data access and workflow, the broader purpose could be more static. For example, while the fine-grained PoU of each instance of data access in a research department can vary (e.g. basic, translational, clinical trial, genetic research, etc.) the broader HIPAA PoU of all these requests can be safely assumed to be Research.

• We need to distinguish between the list of Authorized PoUs for a client or a data element vs. the actual PoU for an instance of data access. The former is a type of policy; the latter is a type of attribute assertion. "This app is only allowed to access data for the purpose of Treatment", or "This record can only to be used for the PoU of Research" are policy fragments. "The purpose of this particular access request is Treatment" is an assertion. In the OAuth world, the former is modelled as a granted Scope while the latter can be a custom HTTP header, a SAML assertion, or an OpenID Connect claim.

• The PoU as an attribute assertion can be self-declared or implied by the business workflow. As @Josh Mandel suggested above, an App can self-declare its PoUs. In other clients, e.g. an enterprise system, it is possible to make this assertion automatically based on inference: "this request was generated in the course of a sample-selection process in a Hepatitis research project, THUS the PoU must be Research" (more fine-grained PoUs to further specify the type of research can also be determined this way).

• While it is possible to trust the self-declared PoU by a client, it is also important to make sure these claims are within a pre-approved range of PoUs that are granted to that client. We can trust an App to declare whether it's making a particular request for the PoU of Research or Treatment, but there can be a broader restriction on the set of PoUs that the App can claim. These can be defined and locked down at the time of developing the App ("what type of data processing does this App do?"). These broad PoUs can be part of the public specifications of an App and can be verified and approved in the course of the on-boarding of an App in an App Store ("Let's check if this App really does what it claims it does"). Obviously, there is a limit to the extent of this verification, but for high-level PoUs like those in HIPAA, this could arguably work.

• Based on the above, in our demo implementation, we had the Client present a JWT to the Authorization Server, issued by a trusted authority (e.g. App Store) who would vouch for the identity of the client as well as the PoUs for which it uses the data it receives. The assertions would look this:

App ID: xyz.zyx.abc
Developed by: organization.1.2.3
PoUs: [TREAT, RESEARCH]

This means that the App store has verified that the App only uses data for these broad purposes.

Once the OAuth/UMA server receives these assertions, it checks them against the policies (in our case FHIR Patient Consents). For example, when a request from the above sample App is received, but the policies would only allow the PoU of Treatment, this would result in a rejection of the access request. In other words, the AS would ensure that all possible PoUs for which the client may use the data are authorized.

An extension (which we didn't implement) could expand this so that the AS would determine what PoUs the App is ALLOWED to claim in the form of granted scopes. In other words, instead of flat-out rejection of the request when the PoUs would not be authorized by the policies, the AS could issue an Access Token with a subset of claimed PoUs, e.g. "Treatment but NOT Research."
When the resource server verifies the granted scopes of a presented Access Token [**], it matches it against the fine-grained PoU of the particular request (e.g. in the HTTP header or a self-signed JWT) to make sure the actual PoU of the particular request is authorized by the granted scopes.
For example, a client that, broadly speaking, uses data both for Research and Treatment, could be issued an Access Token only granting Treatment. So, request instances by this client which are for the PoU of Research would be rejected with an "insufficient scope" error, while request instances by the same client which are for the PoU of Treatment would still go through.

[*] For an extensive and rather pedantic argument on this see https://dl.acm.org/citation.cfm?id=2629689
[**] We used introspection for liveness of revocation but this also works if the OAuth server issues access tokens in the form of as self-contained JWTs.

Jose Costa Teixeira (Nov 22 2017 at 06:04):

Thanks @Mohammad Jafari for this thorough description.

Jose Costa Teixeira (Nov 22 2017 at 06:05):

I have no opinion on OAUTH, but here is how I see it working from the GDPR perspective for the PoU:

Jose Costa Teixeira (Nov 22 2017 at 06:09):

1. In the conformance resources (capabilityStatement), AppA says to server "Hi I am App A, this is what i support, and this is (are) my Purpose(s) of Use".
2. At runtime, and depending on the declared PoUs, the server and App can choose what information to send, what additional security and authentication to work with. For example it may be that each call must have an explicit purpose, but for GDPR that is not needed.

Jose Costa Teixeira (Nov 22 2017 at 06:09):

(#1 above is what matters for Article 30 of the GDPR)

Jose Costa Teixeira (Nov 22 2017 at 06:10):

does this make sense?

John Moehrke (Nov 22 2017 at 18:48):

Yes, PoU can be declare at many levels. If the app has only one purpose in life, then it can declare it when it gets the client_id. One should always look to optimize, which in these cases is to move these kinds of policy statements up as high as possible. Often times they are declared only at the highest level (for example a DURSA that covers a broad set of applications in a broad 'domain').

Jose Costa Teixeira (Nov 22 2017 at 18:50):

Ok. For GDPR the purpose is declared at design time, not at run time. I think this corresponds to "only one purpose in life" - because if it is redesigned to have another purpose, well, then it needs a new purpose

John Moehrke (Nov 22 2017 at 18:53):

yes, the higher you put this, the more fragile to changes it is... design is all about trade offs.

John Moehrke (Nov 22 2017 at 18:55):

hence why we enable the FHIR standard with security-labels, Consent, AuditEvent, and security tokens... we give the designer options

Keith Boone (Oct 24 2018 at 04:02):

Where did this land? In our own use, we have need to override a slightly different business rule for which we'd like applications to SPECIFY that the are explicitly breaking the rule for a given request (rather than for all requests in a session). Thus, it seems that the mechanism applied in the HTTP request meets the need. Only users with permission to USE that capability can do it, and only in applications that have been designed to deal with it. The application asserts it needs the capability with a scope, the server either grants or denies the permission for the "session" associated with the access token based on access control rules. A specific request can override a business rule about query content by asserting a purpose of use that is consistent with the override (omitting patient identifier in queries to support a multi-patient query on patient associated data), but the request must also assert that it is being done for a given purpose (POPHEALTH for example). Thus, the application does not violate the business rule by a simple mistake (issuing a query that doesn't follow the usual requirements) without also asserting that "Yes, I know this query will get me data for multiple patients". It seems that _purpose should be a token parameter on request to communicate purpose of use in the RESTful protocol.

I could work with how break-the-glass was written, OR, with a query parameter (or both), but there is a definite need in the case I'm experiencing to be able to associated purpose of use with a specific API request without having to reauthorize the application making the request.

What's the advice here?

Jose Costa Teixeira (Oct 24 2018 at 06:06):

It seems that your case is "while all apps have their defined PoUs, some apps are designed to provide data to some requesters under a different, "extraordinary PoU". That "extraordinary PoU" is per request, not per app. Is this a correct reading?

Jose Costa Teixeira (Oct 24 2018 at 06:07):

If so, I don't think Break-the-glass is adequate.
And a quesion: do you have a list of those extraordinary PoU ? Are they a predefined set of purposes? Or you want to leave that wide open?

Jose Costa Teixeira (Oct 24 2018 at 06:13):

Rehearsing a solution:
If it's a predefined set of purposes, wouldn't it fall under the GDPR ruling that all purposes of use should be known? (if both ordinary and extraordinary purposes are listed). The extraordinary cases simply require an additional safeguard which is "only by individual request".
And a parameter on the query would be appropriate for this.

Grahame Grieve (Oct 24 2018 at 06:32):

break the glass shows how to put a prupose of use on the request. Same method would apply for other purposes of use

Jose Costa Teixeira (Oct 24 2018 at 07:18):

Ok i thought Break the Glass was reserved for "not expected purposes".

Grahame Grieve (Oct 24 2018 at 07:36):

break the glass is, yes. I'm just saying that the method is applicable for other purposes of use

Jose Costa Teixeira (Oct 24 2018 at 09:24):

so basically one method that can apply for break the glass or "normal, permitted" access? that I like

John Moehrke (Oct 24 2018 at 13:42):

@Keith Boone it would be good for you to bring this use-case forward to be developed. I would agree that the method we have shown for Break-the-Glass is a general use method for communicating some vocabulary value. In this case it is a PurposeOfUse vocabulary value, but could be any vocabulary value. In your case you have a very specific meaning you want to convey, so would likely best define a custom vocabulary for that use. Yes it could work this same way.

John Moehrke (Oct 24 2018 at 13:44):

However there are more more formally security methods. You could request a new OAuth token for the override purpose. Thus you would get a token specifically for that purpose, scope, and timeframe. This method uses security layers, rather than business rules.

John Moehrke (Oct 24 2018 at 13:45):

There are also methods of putting the purposeOfUse into the JWT, as IHE-IUA has defined.

John Moehrke (Oct 24 2018 at 13:45):

There are also other security models beyond these, like ones that use SAML/XACML. -- although similarly architected

John Moehrke (Oct 24 2018 at 13:47):

Lastly, SMART-on-FHIR is getting ready to work on gen-2. They need priortized list of features to start adding to SMART-on-FHIR... Presumably they will consider ballot comments that were defered, but I know they will also consider community need.

Keith Boone (Oct 24 2018 at 13:55):

It's still purpose of use vocabulary, in fact, the purpose I identified is defined in v3 ActReason (see http://www.hl7.org/fhir/v3/PurposeOfUse/vs.html#http---hl7.org-fhir-v3-ActReason-POPHLTH). The reason for NOT requesting a new authorization token is that it really is an occasional override for a single request that might be done by a service level actor.

The next part of my question based on Grahame's response has to do with the structure of the Category tag. The example for break the glass gives
Category: http://hl7.org/fhir/security-label#break-the-glass; scheme="http://hl7.org/fhir/tag/security"; label="Break The Glass"

I would assume that the value of the first term is in the form CodeSystemURI#Code and that if I was to use POPHLTH as a purpose of use code, the Category I would associate with the request would be:
Category: http://hl7.org/fhir/v3/ActReason#POPHLTH; scheme="http://hl7.org/fhir/tag/security"; label="Population Health".

Keith Boone (Oct 24 2018 at 14:03):

If my understanding is correct, I can tell you it was only a guess, because http://hl7.org/fhir/security-label#break-the-glass doesn't go anywhere (it's a 404), which I presume actually means "Not Found" rather than I don't get any information because I didn't have access or didn't properly express my purpose when asking for that URL ;-).

Another example for expressing request based purposes might be helpful.

I might also suggest that while Category is a nice HTTP way to express this, it might be better to have a token parameter available to any request so that they might also be included elsewhere that query URLs can be expressed but Category cannot (e.g., Batch/Transaction). For that, I might suggest _purpose as a query parameter be defined to express it.

John Moehrke (Oct 24 2018 at 14:33):

I think the more correct would be http://terminology.hl7.org/ValueSet/v3-PurposeOfUse#POPHLTH... but that doesn't act much better

John Moehrke (Oct 24 2018 at 14:33):

the Category tag is also IETF experimental https://tools.ietf.org/html/draft-johnston-http-category-header-02

John Moehrke (Oct 24 2018 at 14:34):

It is provided as one perspective... Please feel free to recomend improvements

Keith Boone (Oct 24 2018 at 14:36):

That URL is a valueset URL, not a code system URL. I've been told (from V3 days) that value sets identify a list of codes, not a coding system. The form you use works by accident (because there could be two codes from two different code systems with the same code but different code), whereas the form I used identifies a specific code in a specific coding system.

John Moehrke (Oct 24 2018 at 14:37):

oops.. correct -- http://terminology.hl7.org/CodeSystem/v3-ActReason#POPHEALTH

Keith Boone (Oct 24 2018 at 14:39):

Uhm, your URL goes to an error message. The one I used goes to the code.

John Moehrke (Oct 24 2018 at 14:39):

OIDS would be so much more clear

John Moehrke (Oct 24 2018 at 14:40):

yours goes to a 404

Keith Boone (Oct 24 2018 at 14:40):

HA! ;-)

John Moehrke (Oct 24 2018 at 14:41):

I don't have my browser http negotiate set to include FHIR mime-types... do you? I think the terminology server has no browser stylesheet

Keith Boone (Oct 24 2018 at 14:42):

Huh? http://hl7.org/fhir/v3/ActReason#POPHLTH redirects to http://hl7.org/fhir/v3/ActReason/cs.html#POPHLTH
On the other hand, both the Category (http://hl7.org/fhir/security-label#break-the-glass) and the Scheme (http://hl7.org/fhir/tag/security) specified in the FHIR example definitely go to a 404.

Yeah, I know. Enter a tracker.

John Moehrke (Oct 24 2018 at 14:43):

Ah, I am looking at current build, which is different than STU3

John Moehrke (Oct 24 2018 at 14:44):

I prefer normative track stuff, not zombie trial use stuff... :-)

John Moehrke (Oct 24 2018 at 14:45):

so... given that http/category is an experimental IETF draft... should we elevate the visibility as a general 'experimental' purposeOfUse communication system? It is not clear to me this is the IETF intent, but that is not clear too

Keith Boone (Oct 24 2018 at 14:45):

These days, I need stuff that's been agreed to at some level, not stuff that's not quite done yet :)

John Moehrke (Oct 24 2018 at 14:46):

note, I am stuck with DSTU2 in day-job... so you are farther out of the muck

Keith Boone (Oct 24 2018 at 14:47):

Ha, I'm in the same boat for about 8 more days. And will likely wind up right back there after that even so.

Keith Boone (Oct 24 2018 at 14:47):

Although I did get to do IHE STU3 work last year.

Keith Boone (Oct 24 2018 at 14:54):

Tracker added: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=19499

John Moehrke (Oct 24 2018 at 14:56):

note, I would prefer your last suggestion to add a _purpose parameter, and abandon this http/category experiment. Would be good to get other developers engaged

Last updated: Apr 12 2022 at 19:14 UTC