How to perform Data Masking for part of the url?

[cladius_fernand]

I need to mask a portion of the url itself in my api layer. So if my actual request uri is say http://<my-api-server>/Patient/105, I do not want 105 (the Patient ID) to be displayed in the trace session. This requirement stems from the PHI requirements.

Any pointers?

[Former Community Member]

This doesn't answer your question directly, but I think sensitive information should not be sent over URIs because any SSL termination point (web servers or load balancers) can log them and you generally don't have control over them.

My recommendation is to use a token instead of an actual Patient Id if Patient Id is considered sensitive information.

[cladius_fernand]

The FHIR standard mandates that the id should be part of the URI. As such I cannot move that out of the URI. The point to be noted is that the Patient Id by itself is not sensitive (as opposed to an access token). However, if the health-record information is visible during a trace session along with the Patient Id then it is automatically a PHI leak. I can workaround this issue by simply masking the entire response payload instead. But then I lose out on a considerable amount of debugging that could otherwise be performed.

It would be great, if there was a way to simply mask the portions of the request and response which are part of PHI.

[Former Community Member]

If masking URL is not a requirement, then sensitive payload data in trace and debug sessions can be masked as per here (http://docs.apigee.com/api-services/content/data-masking). You can specify XPATH or JSON PATH to mask portions of the payload.

[cladius_fernand]

@Srinandan Sridhar, @Diego Zuluaga, thanks for your inputs. As mentioned, I cannot modify the url structure to omit the patient-id since I have to adhere to the FHIR standard. Hence, I'm left with only one alternative i.e. to mask the entire response payload. Given a real-life scenario like this, is the product team going to consider adding url masking as a feature in the future?

[#6]

@Cladius Fernando - Why not encrypting just the patient_id from the URL? For the client, this info has no meaning, whereas for the API, it does, after decrypting the value. The process of encrypting and decrypting individual elements of the request can be quickly done with libraries provided in my previous post.

[#7]

I've seen this requirement a few times and understand the need to mask Personally Identifiable Information (PII) or even financial data. Some customers change GET verbs to POST on some of their resources, however, the data is still in clear text. It's just not visible in the URL. Not really a solution. Other customers leverage OAuth tokens with sensitive data associated to them as custom attributes as per @Srinandan Sridhar suggestion. This seems reasonable, however some customers lose addressability of their resources as it gets more complex to specify which resource they're trying to request. In your case, this seems to meet the requirement mentioned above.

Another possible solution is to encrypt any pieces of data sent to the client, which doesn't require managing state on the server. Here's an article explaining how to implement it with Client Sessions. This solutions can be implemented using JS policies and crypto.js libraries or Node.js module.

Hope it helps!