Stream: implementers
Topic: PHI in Request URI for GET requests
David Teirney (Oct 19 2016 at 18:30):
Hello, we've received some information from an API management vendor that there has been a discussion about moving away from HTTP GET requests with PHI in the query string. To help avoid PHI being logged in the SSL terminating web servers.
Does anyone know where that conversation is happening?
Related to the comments in https://www.hl7.org/fhir/security.html#http
Thanks!
Mat Coolidge (Oct 19 2016 at 18:36):
As long as the requests are encrypted (SSL) the query parameters will also be encrypted: http://security.stackexchange.com/questions/12531/ssl-with-get-and-post
Mat Coolidge (Oct 19 2016 at 18:37):
only the sending and receiving application should have access unless the cert has been compromised and in that case POST wont help anyways
Grahame Grieve (Oct 19 2016 at 19:25):
this is fundamentally a question about logging policy. If you have PHI in the URL, PHI will appear in the log. and the logs will become covered under HIPAA etc.
Grahame Grieve (Oct 19 2016 at 19:25):
responding to this by removing PHI from the URLs is fixing the wrong problem, (and assumes that the bodies are never logged - logging these is also a policy choice)
David Teirney (Oct 19 2016 at 20:35):
Thanks for the information. We've worked with PHI in the HTTP request for a very long time and have policies in place for managing that information when it finally gets decrypted by the SSL terminator and enters the secure network. We've been working with another vendor for API Management that doesn't support PHI within the first line of the HTTP request under their HIPAA compliance statement (due to logging infrastructure within their SaaS offering).
Just trying to track down the conversation they mentioned regarding the FHIR spec looking to move away from using GET due to this potential PHI logging issue.
@Grahame Grieve if you're not aware of any discussion relating to this perhaps I misunderstood what was being discussed with the vendor.
John Moehrke (Oct 19 2016 at 20:41):
David, it is commonly misunderstood. You have outlined the risk correct, in that the risk is inside the secured system behind TLS. The Security wg has taken care to make sure this risk is understood properly, and gets recognized as an operational requirement. See http://hl7-fhir.github.io/security.html#http
Grahame Grieve (Oct 19 2016 at 20:42):
we do say this: With regard to HTTP logs, implementers need to consider the implications of distributing access to the logs. HTTP logs, including those that only cotain the URL itself, should be regarded as being as sensitive as the resources themselves. Even if direct PHI is kept out of the logs by careful avoidance of search parameters (e.g. by using POST), the logs will still contain a rich set of information about the clinical records
John Moehrke (Oct 19 2016 at 20:44):
This said, the misunderstanding that POST is better than GET is incorrect. The observed risk that a off-the-shelf web-server has some logging levels that will log the HTTP GET parameters is true, but they can also be configured to log the whole POST content. This is a case where management of the system configuration and protection of sensitive content need to be done. This is a systems design problem.
Grahame Grieve (Oct 19 2016 at 20:44):
or, in my language, a policy question
John Moehrke (Oct 19 2016 at 20:49):
yes, a policy question is always a good answer. In my short words it might not have been obvious that the POLICY drives the design.
David Teirney (Oct 19 2016 at 23:55):
Thanks all for your feedback. For the moment I assume I misunderstood the conversation with the vendor as it appears there are no plans for FHIR to change anything with respect to the use of GET where the request URI will contain PHI.
Grahame Grieve (Oct 19 2016 at 23:56):
you can do patient search by POST - we do allow that, and servers should support that ( though most clients don't bother). Perhaps that is what they were referring to
David Teirney (Oct 19 2016 at 23:59):
Yes, possibly. Getting patient specific information from every other resource typically uses GET with the patient.identifier as a query param though so no real benefit to using POST for just the search for the patient.
Grahame Grieve (Oct 20 2016 at 00:03):
y. I agree.
Last updated: Apr 12 2022 at 19:14 UTC
