Stream: implementers
Topic: X-Consent header
Michael Donnelly (Jan 16 2019 at 22:09):
Tuesday Q3, Security and CBCP approved adding an X-Consent header. A number of people have had questions about it, so this is an attempt to clarify the purpose and mechanism of this optional header.
USE CASE
A patient, Mary Smith, is in the Emergency Department at San Antonio General. SAG would like to get Mary's data from her primary care provider at Austin Health Alliance. The X-Consent header is useful when a number of things are true:
- SAG and AHA have an existing business agreement
- AHA doesn't have any documentation in their system explicitly prohibiting them from sharing Mary's data with SAG
- AHA also doesn't have documentation explicitly authorizing them to share Mary's data with SAG
When SAG requests Mary's data from AHA, AHA checks for all of this:
The case X-Consent seeks to address is the one where AHA has nothing on file.
Michael Donnelly (Jan 16 2019 at 22:09):
WHAT HAPPENS NEXT?
SAG collects consent, on behalf of AHA, for AHA to share her data with SAG. SAG then repeats its previous request, including an X-Consent header to
1. let AHA know that it has Mary's consent and
2. provide documentation of that consent to AHA.
IS THERE ANOTHER WAY TO DO THIS?
There are some suggestions that have come up more than once.
Can we use OAuth2?
Yes, just not for the consent part
- When an OAuth2 token is issued for a patient, that token can be used to get that patient's data (or maybe other patients for which that patient has proxy access, like his or her children).
- When an OAuth2 token is issued for a clinical end user, that token can be used to get data that user would be able to see in the EHR.
- When an OAuth2 token is issued for back-end services, it's less straightforward than the cases above.
Since a user at SAG doesn't have an account at AHA, this is a case for back-end services. The token SAG gets represents SAG as an organization not a specific person there and isn't able to address this use case.
Can SAG POST a Consent resource to AHA?
The consent document might not be a Consent resource. It could be a scan of a physical form Mary signed. As such, there wouldn't be anything for AHA to inspect and change their business rules.
Michael Donnelly (Jan 16 2019 at 22:10):
TECHNICAL DETAILS
I kept the flow above high level to avoid getting bogged down in details. At a more technical level:
Note that this doesn't explicitly include a step where AHA retrieves the consent document from SAG. Optionally, AHA could get the consent before responding to SAG's query (and if it's a Consent resource, it could inspect it). Realistically, given that they already have a business agreement, AHA doesn't want to delay the response with another round trip to call a web service.
Michael Donnelly (Jan 16 2019 at 22:10):
FAQ
If the consent is a scan, how can the custodian of the data inspect it?
It can't. This model is dependent on a business agreement between the systems.
If the consent is a scan, does it have to be scanned right away?
Nope. In the X-Consent header, SAG could provide the URL where it plans to publish the consent document. If AHA queried that URL before the document had been scanned, SAG's response would include a Retry-After header, and AHA would retry then.
Can't SAG cheat (claim to have consent it doesn't)?
In theory, sure.
X-Consent isn't about security, it's about consent. A given of this model is that SAG and AHA have an existing business agreement. A violation of this agreement is likely to result in one or more of: termination of someone's employment, charges being pressed, and/or litigation.
Does AHA have to retrieve the consent document every time?
With the right business agreement with the right technical support, we should be able to minimize unnecessary network traffic.
I believe the safest way to handle this is for SAG to include an ETag along with the URI in X-Consent. There's a Zulip discussion about caching this consent.
Michael Donnelly (Jan 16 2019 at 22:11):
@John Moehrke @David Pyke
John Moehrke (Jan 17 2019 at 19:30):
I like that clarification. The X-Consent header is there to use. The server can impose any policy it needs to. The existance of the X-Consent header is not a mandate. Thus policy and business relationships will still be most important.
Mohammad Jafari (Jan 26 2019 at 00:45):
Being a bit late to this thread, I wanted to express some concerns/questions about this approach.
Generally, evaluating patient's consent is part of the authorization logic. First, a broader authorization policy needs to be checked to determine whether patient's consent is needed to begin with; then, the patient's consent(s) need(s) to be evaluated (by a module we called "Consent Decision Point" in our previous demos which is part of the broader policy decision point) and the result of that evaluation is passed as an input into the broader authorization service which will ultimately determine what will be released and to what extent (e.g. some resources from a bundle might be redacted).
In this context, I think the proper way for a client to inform the server of an existing consent on file if to present the link to the consent as a claim/attribute in its initial request to the authorization server to obtain an OAuth token. The client provides a set of claims/attributes which essentially says: "I am X, I want a token to be able to access patient Y's resources (optionally also narrow down the requested resource types, date range, or confidentiality level, etc.) and also here is the link to this patient's consent I have on file."
This will provide an opportunity to consider all the provided claims/attributes, and eventually decide whether or not to issue a token (potentially granting more limited set of scopes compared to what the client asked for). In this approach _all_ of the authorization logic, including evaluating the consent directive happens in one place.
Note that there may be a lot of intertwined policy decisions in this process and consent evaluation can hardly be separated from the rest of the authorization logic; for example, the authorization server may be configured based on policy to trust Client A's claim that they are in possession of a consent without evaluating it while Client B must actually make the consent available to be processed.
I think my concerns are:
a) What is the problem that x-consent header trying to solve which cannot be covered by the above standard flow?
b) How and where the authorization logic is going to be handled? By bringing in the consent link into the FHIR request, it seems like part of the authorization logic (i.e. evaluating consent) will fall on the FHIR server. I think the tendency to isolate authorization logic (of which consent evaluation is a part) from the FHIR server is a more appropriate approach. Having all or part of the authorization processing take place inside the FHIR server, and after an authorization server has issued a token does not seem to be a good design decision.
If I am missing something about the context of the use-case here, I will be grateful if someone can provide more information .
Grahame Grieve (Jan 26 2019 at 20:41):
a) not all FHIR access is through a user mediated OAuth process
b) the FHIR server cannot do nothing about authorization. Each request has to be checked in detail against the authorizations and consents, irrespective of the checking done when the session was established. We've said nothing about how the RS and AS act in concert in this degree, but clearly they need to. Adding the X-Consent header doesn't make any difference in this regard
Mohammad Jafari (Jan 27 2019 at 00:16):
I agree that "the FHIR server cannot do nothing about authorization" and that's precisely why I think this is not a good idea because it sends to the FHIR server some authorization information and breaks the separation of Authorization and FHIR server by bringing an authorization claim/assertion into the FHIR API.
A reference to a consent resource or even a simple claim that a party has a patient consent on file are indeed authorization assertion/claims which can only be consumed in a meaningful and consequential way by an Authorization Server which is ultimately the only place which knows what to do with that information.
I think consent assertions should not be conveyed using HTTP headers for the same reason that we don't use HTTP headers for other authorization claims/assertions like client ID, client's organization ID, purpose of use, or the client's confidentiality/sensitivity clearance.
There are well-defined and standard ways for conveying such assertions to an authorization server (where they actually can be meaningfully consumed) and there are well-defined and standard ways to convey the authorization decision to an API server in the form of an authorization token. If a FHIR server needs authorization, those standard methods should be used. If authorization is not a concern, then what would it need the consent reference for?
My contention is that sending some authorization information directly to the FHIR server as part of the FHIR API breaks the separation between the Authorization and FHIR API and potentially creates confusion by misleading implementers to implement some piecemeal authorization logic inside the FHIR server by enforcing the consent decisions isolated or in parallel to the rest of authorization policies.
I'd still like to hear how this header is supposed to be consumed by a FHIR server in a use-case and what the FHIR server is supposed to do with it.
Grahame Grieve (Jan 27 2019 at 07:26):
you're still assuming that there is an authorization server. In lots of cases, there is not.
John Moehrke (Jan 27 2019 at 16:27):
The X-Consent header is being defined as a method, not a mandate. The server is fully free to ignore it, or to reject any requests that contain the header.
It is not right to say we don't do this for other security mechanisms, as the auth header is an http header, etc... AND within the FHIR specification there is discussion of a break-glass mechanism that leverage a proposed IETF specification for Category http://build.fhir.org/security-labels.html#break-the-glass
NONE of these are required, they can all be forbidden... the point of having them specified is to enable re-use when someone finds them useful and acceptable risk.
k connor (Jan 28 2019 at 03:52):
RE Graham: " you're still assuming that there is an authorization server. In lots of cases, there is not." I'm not sure what the use cases are for not having an authorization server in healthcare systems except maybe within an enterprise. It would be helpful to have a few mainstream examples where that's permissible within known privacy policy domains. Also, I think we need to articulate the use cases for when x-consent header makes sense. I've been thinking it makes sense where a Server is pushing patient records, so no claims involved from the Client side, as a way to convey the governing consent or any governing privacy policy for that matter. That seems different from the use case being discussed, where it might make sense to have the OAuth claims of the requester indicating that they have a "consent on file." That would help implementers determine whether they;ve got any business impetus for supporting x-consent header.
Grahame Grieve (Jan 28 2019 at 09:51):
depends whether you mean, by authorization server, an OAuth Authorization server, or just generally, an point of decision making. Of course you'll have an decision making point. But most interfaces in healthcare a system:system trust based, and the user assertions are part of the request, not part of a special session established with user involvement
John Moehrke (Jan 28 2019 at 13:17):
I am happy to get clarity on some of the best use-cases, but want to keep us short of trying to go exhaustive in the use-cases (an infinite well of possibilities). The most visible use-case to me is the same one that drives the similar function in the eHealth Exchange, which is the one Michael was outlining. It is not the only use-case, it might not be the best, but it is the one that is used today. That use-case does start with a high degree of trust between the client and server. They have strong reason to trust each other, no need to elaborate on why or how. The communication of the x header is by the business layer, not the security layer. So having it in the http header, and not in the OAuth. The server verification of the x header claim can be light or very heavy, again we don't need to elaborate. All we are trying to do is "standardize" a method of communicating this fact, not how the fact was obtained or how it is used. Yes the use-case we elaborate will speak to how it is obtained and ow it is used in that context. But that specific use-case is not a mandate, it is an illustration of one way to use this method.
Mohammad Jafari (Jan 29 2019 at 19:10):
The use-case @k connor is referring to is entirely different from the use-case outlined earlier in this thread. In this case, this header is used by the _FHIR server_ in its response to the client, to specify what patient consent was used to authorize access. This can be useful if the FHIR Server wants to specify (for purposes such as accounting of disclosure) the reasoning behind its decision to release the FHIR resources in its response. It may also help the client compare this consent with its own record and get an opportunity to update the record in case the it has a more recent consent from the patient.
I think even in this use-case it makes more sense to include such information in the the authorization server response (because that's where the decision is made and the AS is the party that knows best what consent/policies were used to make the decision to allow/deny issuing a token) but I don't have the concerns I expressed earlier (about encouraging piecemeal authorization logic inside the FHIR server) about using the x-consent header in this case.
Mohammad Jafari (Jan 29 2019 at 19:16):
I think ultimately what can help this discussion is to a) identify the use-case in which the client uses this header, and b) explain what sequence of actions the FHIR server is expected to take in order to consume this header in that use-case.
My understanding is that the logic for processing such a header is authorization logic in nature and is inherently intertwined with the logic for processing other applicable authorization policies (as I argued earlier in this thread) which does not belong in the FHIR server.
Grahame Grieve (Jan 29 2019 at 20:44):
that's where you're wrong: the logic absoutely does belong in the FHIR server, since it's the one that actually has to apply the rules
Mohammad Jafari (Jan 29 2019 at 20:48):
@Grahame Grieve "the FHIR server cannot do nothing about authorization" is what you said above. I'm reiterating that by saying the authorization logic does not belong in the FHIR server.
Grahame Grieve (Jan 29 2019 at 20:49):
right. the FHIR Server must be deeply involved in authorization. The authorization server is only a bystander
Mohammad Jafari (Jan 29 2019 at 20:52):
I see, so you actually meant that double negative as a positive :slight_smile:
My understanding is that the FHIR specs has purposefully stayed away from defining authorization flow/logic and has left it to existing authorization technologies and I think that's the right decision.
John Moehrke (Jan 29 2019 at 20:59):
The FHIR specification is defining interoperability mechanisms, not decision or enforcement.... This is true of x-consent like any other mechanism defined in the FHIR specificaiton. Said another way the sole purpose of defining the x-consent header is to enable "a" method of communicating a consent that the requester has that it thinks is applicable to the server. That is all. There is no expectation beyond that. Yes there are some behaviours that this clearly enables, but those behavours would technology and policy specific.
Grahame Grieve (Jan 29 2019 at 21:08):
right. we have not defined how it should be done. but it has to be done.
k connor (Jan 29 2019 at 23:00):
RE John: "the sole purpose of defining the x-consent header is to enable "a" method of communicating a consent that the requester has that it thinks is applicable to the server". Mohammad and I are proposing an additional use case - where the x-consent header is used by the _FHIR server_ in its response to the client, to specify what patient consent was used to authorize access. See his comment 1/29 above.
John Moehrke (Jan 30 2019 at 00:06):
RE John: "the sole purpose of defining the x-consent header is to enable "a" method of communicating a consent that the requester has that it thinks is applicable to the server". Mohammad and I are proposing an additional use case - where the x-consent header is used by the _FHIR server_ in its response to the client, to specify what patient consent was used to authorize access. See his comment 1/29 above.
That already exists -- see the extension on OperationOutcome -- http://build.fhir.org/extension-operationoutcome-authority.html
Mohammad Jafari (Jan 30 2019 at 18:50):
@John Moehrke I can stand corrected but my understanding is that OperationOutcome is not intended to be returned with a successful response, so, it doesn't really address the use-case @k connor and I mentioned above.
a) If the FHIR server wants to notify the client about the reasoning behind its decision to release some information for accounting/traceability purposes, or
b) When a client who has received a successful response needs to check whether the response is based on an up-to-date consent, for example, since it may suspect that part of the response may have been redacted based on an older consent.
In these cases the FHIR server returns a successful response but it may still want to communicate the consent based on which access was granted.
John Moehrke (Jan 30 2019 at 20:41):
That use-case is not the one being addressed by X-Consent header. If you have a solution, you can submit a change request for consideration.
Mohammad Jafari (Feb 01 2019 at 16:13):
FTR, Kathleen and I summarized our thoughts on these use-cases here:
https://medium.com/@jafarim/when-the-client-has-the-patients-consent-37650e8a6c1c
I hope this can be helpful in clarifying them.
In summary, I think using X-Consent header is justified in the case where there is no mechanism for the client to communicate dynamic per-transaction attribute assertions/claims with the authorization service, but when it is possible for the client to communicate per-transaction attribute assertions, consent on file should be communicated using an assertion/claim.
Grahame Grieve (Feb 01 2019 at 20:05):
I think your diagrams would be clearer if you included the consent decision point explciitly. And also if you were clear that the execution of the the authorization decisions are on the FHIR server, not the authorization server
Grahame Grieve (Feb 01 2019 at 20:05):
note that we are working on a common API for the consent decision point for the FHIR servers
Mohammad Jafari (Feb 01 2019 at 22:15):
I am not sure I agree with on that @Grahame Grieve. I have argued at length both earlier in this thread and in the writeup that processing the consent should take place at the authorization service where there is context for other rival and overarching policies and a meaningful decision can be made by considering all applicable policies in different forms and formats (FHIR consent, legacy consent standards, XACML, ODRL,...) and resolving potential conflicts.
The interface for processing consents is very similar to the interface for an authorization service:
1) request comes in as a set of assertions,
2) consult a policy information point to add additional assertions to the request if necessary,
3) find applicable policies,
4) evaluate the request against each applicable policy and record the results (authorization decisions and obligations)
5) Combine all the partial decisions into a final decisions (one authorization decision and a set of obligations) based on overarching conflict resolution policies.
The FHIR Server would simply serve the FHIR consent to the authorization service so that it can be processed alongside all other applicable policies. We have demoed this architecture a few times in previous connectathons.
But I think this is out of the scope of the current thread. If there's already a thread on consent decision point, I'm happy to continue there.
Grahame Grieve (Feb 02 2019 at 00:33):
you are wrong to treat the request as an atomic unit. The authorization server cannot approve the request or not as a single unit. The engine that constructs the response must be aware of the fine grained rules so it knows how to build the response
Mohammad Jafari (Feb 02 2019 at 00:49):
The fine-grained rules to construct the response come from the obligations resulting from different policies including the patient consent, as I discussed above and as we have demonstrated in fhir connectathons as far back as 2015 with different variations of the authorization service, security labeling service, and privacy preserving services. Our team has a deep understanding and a lot of experience with authorization and labeling. If you think this is all wrong you certainly need to elaborate.
Grahame Grieve (Feb 02 2019 at 04:31):
ok. this request:
GET [base]/Observation?subject=Patient/[id]&_lastUpdated=ge:2018-01-01
Grahame Grieve (Feb 02 2019 at 04:31):
patient has consented to share observations except those pertaining to STD and Mental health
Mohammad Jafari (Feb 02 2019 at 19:15):
We have demoed this a few times in the connectathons with a) enterprise authorization service (e.g. XACML), b) with UMA, and with c) plain OAuth. The reports were published to the Security WG. For example, the summary of the approach with basic authorization is as the following:
- After the response to the query is determined by the FHIR server, the policy enforcement point (PEP) in the FHIR server captures and creates a request and sends it to the authorization service; the request includes the response contents and attribute assertions.
- The authorization service evaluates the response content, and the attribute assertions against applicable consents (there's a consent discovery component which determined which patients' information are in the response based on the bundle contents and retrieves the applicable consents from those patients which may or may not be stored in the same FHIR server).
- The result of this evaluation is an array of decisions; one decision from each applicable consent. Each decision includes an authorization decision (permit, deny, not_applicable) and a set of obligations e.g. redact resources labeled with STD and mental health.
- A decision combiner component turns the array of decisions into one final decision (i.e. one authorization decision and one final set of obligations). This conflict resolution can be highly configurable (policy-based) or as simple as most recent consent overrides. This final decision is sent back to the FHIR PEP.
- The PEP invokes the labeling and privacy preserving service (SLS/PPS), passing the response bundle alongside the final decision from the authorization server which includes labeling and redaction obligations. The SLS/PPS returns a modified response by applying the obligations.
- The FHIR server sends back the response as packaged by the SLS/PPS back to the client.
There is some nuanced glue logic here, e.g. if the request is for a single resource and not a bundle, if the decision requires that resource to be redacted, the FHIR server should send a 404, whereas if the response is a bundle, it can simply remove that one resource from the outgoing bundle.
With UMA and OAuth the flow is a bit different but is based on similar steps.
When we demoed this in 2016, I used the hooks inside the HAPI server (servlet interceptors) to have the FHIR server make the appropriate calls to the authorization service and SLS/PPS before sending out the response. Since then I have re-implemented this in the form of a reverse proxy which can sit in front of any FHIR server and enforce the authorization flow.
We have the documents from the earlier work (the code was not open-sourced) but the reverse proxy is a project I have worked on outside of contracts in my own time and is open-source. Will be happy to share the docs, present a demo or the code, or chat further if you @Grahame Grieve or others are interested. Where is the consent decision point conversation taking place?
Grahame Grieve (Feb 02 2019 at 21:12):
interesting. I would not like to second guess the cascade of decisions the FHIR server makes. For that reason, we are working up an in-server API that is common across servers, and that the server consults as it makes it's decisions. See https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy/topic/FHIR-Security.20and.20Privacy.20Overview.20Mon.20Q3
Grahame Grieve (Feb 02 2019 at 21:13):
I'm going to propose some changes to the interface after what you wrote
Mohammad Jafari (Feb 02 2019 at 22:12):
I see.
To add to the above, the reason I moved towards implementing an HTTP reverse proxy was to avoid having to tweak the FHIR server (even as much as putting in the hooks and configs for the AS or OAuth). At the connectathon I noticed that our flow could only work with our own HAPI server which we had modified to add the AS and SLS/PPS calls, and we were not able to use our auth layer on someone else's FHIR server unless we were given access to change their server source/configs which can be an administrative nightmare ("we need write access to your code repo and code pipeline and deploy access to your server environment :smirk: ") as well as technical challenge ("oh we need to add a few calls to the server side but I see your FHIR server is written in COBOL :astonished: ").
So, I wanted a solution that can be orthogonal to the backend and can work with any FHIR server without the need to do anything inside the FHIR box. This approach also helps with the separation of concern (in a microservice sense) so there is less coupling between the FHIR server and the authorization proxy and the development/management of these servers can be done by separate groups.
I see that in contrast, the alternative is to make this part of the FHIR standard so that every FHIR server is guaranteed to have it implemented in the same way. This works too, but with the caveat that a) it will make the specs bulkier, and b) there is a risk of defining the specs in a way that only works well with some authorization technologies (e.g. as I mentioned above the flows for plain OAuth2 vs. UMA profile vs. classic enterprise auth service are a bit different and call for different interfaces).
I will monitor that thread and maybe write more about the details as the conversation moves forward. Maybe I will also introduce and discuss the fhir reverse proxy in a separate thread.
Grahame Grieve (Feb 03 2019 at 10:10):
so we won't be adding that API to the spec, I think. Maybe we'll document it somewhere to encourage people to adopt it, but that won't make your wrapping approach useless- they'll just be solving different deployment architecture
John Moehrke (Feb 03 2019 at 19:52):
cascading OAuth (UMA or simple OAuth) has been recommended in the specification for a long time. So the model you are promoting is already promoted.. Today we have specific pointer at a healthcare specific version, such as HEART. More general architecture examples could be added simply by recommending the wording in a Change Request.
Brian Postlethwaite (Feb 03 2019 at 23:33):
Just removing the resour e from a bundle isn't enough, you would also need to consider the total count and paging too.
If the paging through observations went through a set of mental health related ones chances of receiving an empty page would be high, which isn't particularly useful to a client.
This needs to be a step back into the paging logic. So it's not as simple as has been described.
Mohammad Jafari (Feb 04 2019 at 02:20):
@Brian Postlethwaite yes. There is a lot of little nuances like this as I mentioned earlier. Another example I encountered was redacting embedded resources and handling references to redacted resources in un-redacted resources.
I think it will be worth to document a list of these implementation details for the community at some point.
Mohammad Jafari (Feb 04 2019 at 02:33):
@Grahame Grieve ok. I'll be happy to help with/contribute to that document.
John Moehrke (Feb 04 2019 at 13:17):
The discussion of methods of redaction is independent of the X-Consent header topic... I would agree that having a section on the security pages that outlines these various "Considerations" would be good. We have some of this mentioned http://build.fhir.org/secpriv-module.html#query-parameters
Last updated: Apr 12 2022 at 19:14 UTC
