Patient Query Support and PHI Concerns

[Sean Moore]

I'd like to start a conversation on how we'd like to approach queries within the FHIR specification - it concerns Patient searches specifically, but the changes we are going to propose could affect query support across all resources.

Situation: In DSTU1, all FHIR Search operations are implemented using query string key/value parameters, allowing you to easily create a search for a specific set of resources. This is an awesome way to access data, but it brings up a concern in actual implementation - query strings aren't encrypted even when transacting via HTTPs, and they're logged in pretty much every possible location they can be - web server logs, browser history, devices, proxies, etc.

Note that in DSTU1, there are other means to perform searches, but I'd consider them not well-defined, and not viable alternatives compared to the ease of querying the resource directly. They're also deprecated or marked as to-dos in DSTU2, so they're clearly unstable.

This causes a clear concern when performing a patient demographic query via the Patient resource - PHI is transmitted in clear text in the request, and is stored in all variety of logs between the API server and the client application. When there's only test data backing the API server, it's not a concern, but it's something we need to address for production databases.

In DSTU2, searches can be performed either via HTTP GETs w/ data contained in the query string, or as url encoded HTTP POSTs, with the search parameters contained within the body. From 2.1.1 Search:

For this RESTful search (see definition in RESTful API), the parameters are a series of name=[value] pairs encoded in the URL or as an application/x-www-form-urlencoded submission for a POST.

However, there doesn't at this point appear to be any ability to document in the Conformance statement which of the methods are supported by the server; the presumption is that both are supported, I imagine.

Searches via form-urlencoded submissions allow us to provide much of the same benefits as a query string-encoded search via HTTP GET, are well supported in the browser and native application frameworks, and are already part of the upcoming standard.

Here are the options Epic is considering:

1. For PDQ, and potentially some other subset of all available resource queries, we will only accept form-urlencoded POSTs at our endpoint. This minimizes the overall changes to the API, although I'm concerned that it adds more complexity to the API than really makes sense, and we'd need to have a means of declaring which endpoints only accept POSTs, likely in the Conformance resource for the API server.

2. Only support form-urlencoded POSTs on the API endpoints for searches, requiring clients to re-implement search logic wholesale, with the benefit of not needing to maintain the different search mechanisms in client libraries. We'd provide feedback to HL7 that this is should be the only considered mechanism for searches, and deprecate HTTP GETs to perform searches.

I'm interested in  hearing feedback on these proposed solutions, or in hearing other alternatives. 

[Michele Mottini]

 query strings aren't encrypted even when transacting via HTTPs,

I am pretty sure that query strings ARE encrypted when using HTTPS

In DSTU2, searches can be performed either via HTTP GETs w/ data contained in the query string, or as url encoded HTTP POSTs, with the search parameters contained within the body.

This is true also in DSTU1

 

I'm interested in  hearing feedback on these proposed solutions, or in hearing other alternatives. 

I'd say the servers should implement both methods - they are both in the specs, and using GET is handy for testing and easier to implement. 

  - Michele

[Josh Mandel]

Apologies for the brier reply, but I think Michele has got this right on both counts. Sean, do you see concerns with this approach?

Best,

Josh

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sean Moore]

thanks for pointing out that form-urlencoded POSTs are available in DSTU1; I had missed that on review. Query strings are logged in browser / device history, and stored on server logs, so we still don't see GETs as an acceptable mechanism to support Search.

I'd say the concern still stands though - there's a very clear 'or' in both DSTU1 and DSTU2; I take that to mean that servers need to support both, and clients can choose whichever mechanism they wish to support.We're all programmers here, so I think it's not unfair to say that the majority of clients will support GET as the search mechanism, because it is easier. If servers support both mechanisms, but clients only support one, are we truly better off?

I'm in agreement with Michele that it's far easier to support GET in terms of testing and implementation, but this can't be our only consideration. We're not comfortable implementing search via GET in production, so why should it be seen as a viable option in testing environments?

I'm also interested in the work effort involved for clients - it's been straightforward to me to convert a jQuery-based application to the form-urlencoded approach, but admittedly it's not at the caliber of a client library for other applications to make use of, nor what I'd call a production-viable application.

[Kevin Shekleton]

Sean,

This is a good discussion; thanks for starting this dialogue.

Any device or system in which the request passes through has full access to the request contents (if it's over HTTPS it will need the cert/key). Thus, even if you are placing the data in question into the POST body, it can be logged by the aforementioned systems. So, I don't believe moving these parameters to a POST body inherently protects the data as compared to GET requests. Certainly many systems are by default configured to log the URI path/query params but they also can easily be configured to log the request body contents as well.

You mentioned browsers caching the URI search requests. I'm guessing you are referring to the browser's history? If so, I was assuming that these pure web-based applications (eg, public clients that make FHIR calls from the client browser) would be making all of these requests via AJAX calls. In this case, the browser would not be logging these URIs in the browser history.

In the specific case of servers logged this data (eg, access logs), I'm not following the concern since presumably you own this server and can control the logging being done. If there is concern with the access logs being accessed by bad actors in your system, you can always just configure those servers to not log the requests or strip the query/path parameters.

For the FHIR service I'm working on, we feel very comfortable implementing search according to the current spec (this includes utilizing HTTP GET requests). We're working closely with our internal Security group on this and they too don't have any concerns. FWIW, we have similar services in use in production today (not FHIR) that utilize similar URI strategies in question here. These services have gone through periodic, very thorough internal and external security audits (using multiple independent 3rd party security firms) and this has never come up in our risk/security assessments. These past examples I mention were not the FHIR services but similar services which technically utilize the same types of URIs.

Cheers,

Kevin

Kevin Shekleton | Distinguished Engineer | Cerner

[Kevin Shekleton]

For those interested, here is a change request to FHIR regarding this discussion: http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=7953&start=0