Stream: implementers
Topic: FHIR Search/IHE MHD
Alexander Henket (Oct 08 2020 at 09:24):
We increasingly encounter people who take issue with searches based on patient.identifier, because those would get logged in proxies and other places that may or may not have the same privacy protection in place. We actually have GDRP based auditors running around in the country who will tell you, you cannot do that.
In MedMij, the patient oriented network here in NL, we have declared searches based on the national patient identifier forbidden. The way to know who the query is for is deferred to the HTTP Authentication token.
The IHE MHD spec (@John Moehrke) explicitly requires GET requests and explicitly requires patient.identifier as parameter which conflicts with the above. MHD simply bases on FHIR Search. FHIR Search which specifies a second option (POST application/x-www-form-urlencoded which would forego all concerns as https "hides" the body.
- Are there any other countries (e.g. European because of GDRP) who encounter issues like this?
- What solutions have other countries found?
Grahame Grieve (Oct 08 2020 at 09:25):
I'm confused about this. Why is the HTTP Authentication token logged differently to the URL?
Grahame Grieve (Oct 08 2020 at 09:26):
generally this sounds like the auditors using HIPAA to say that you can't share data
Alexander Henket (Oct 08 2020 at 11:12):
It is not logged differently, but the token is a uuid or other meaningless string to any other party than the target endpoint
Alexander Henket (Oct 08 2020 at 11:15):
You can share data, but in NL, PHRs cannot use the national patient identifier due to scoping issues in law. Patients negotiate a token that binds into that patient identifier outside the direct PHR context and then the PHR is handed the token by the endpoint for further use.
But long story short: nothing is exchanged based on searches that include subject or patient.identifier and the like.
Grahame Grieve (Oct 08 2020 at 11:16):
so they negotiate a specific identifier for their context?
Alexander Henket (Oct 08 2020 at 11:17):
Token, not identifier. The token is a pointer into endpoint/FHIR server lookup table where the national PID is stored for the time-to-live of the token which currently is 15 minutes
Alexander Henket (Oct 08 2020 at 11:18):
So endpoint/FHIR server reads the Bearer token, looks up which patient this is, in its lookup table for tokens, and uses that to answer the query
Grahame Grieve (Oct 08 2020 at 11:19):
so they only have one access to one patient?
Alexander Henket (Oct 08 2020 at 11:20):
(deleted)
Alexander Henket (Oct 08 2020 at 11:23):
(deleted)
Alexander Henket (Oct 08 2020 at 11:36):
so they only have one access to one patient?
I think I misunderstood your question: yes, 1 token grants access to data of 1 patient.
Grahame Grieve (Oct 08 2020 at 12:00):
so you don't want an identifier at all - @John Moehrke this is a more generic IHE issue - XDS for consumers will typically work this way in any country.
Alexander Henket (Oct 08 2020 at 12:19):
Well, the MedMij use case is just that indeed. For Physician/Physician traffic the national patient id is actually allowed and those would follow normal patient id query patterns. However: law still requires the url to clear of that.
You could solve this with a POST of application/x-www-form-urlencoded parameters because they would go into the HTTP Body and are thus obfuscated from intermediary logging.
MHD disallows this. Maybe for good reason?
Grahame Grieve (Oct 08 2020 at 12:33):
mostly (I think) because there's a huge segment of the community out there falsely convinced that the body is more secure than the headers. Though I really shouldn't speak for IHE on that
Alexander Henket (Oct 08 2020 at 12:39):
Some of them are called auditors, architects, productmanagers, or developers. They are too diverse to ignore, so we can either beat them (provide evidence otherwise), or join them (leave patient.identifier out of the url)?
IHE actually chose to only support patient.identifier in url, so I guess they are not in the same group :-)
Vassil Peytchev (Oct 08 2020 at 12:47):
Use an IHE change proposal to request the addition of POST searches.
Alexander Henket (Oct 08 2020 at 12:51):
I will, thanks Vassil. That works for MHD
Michele Mottini (Oct 08 2020 at 13:04):
Note that in the US PHRs do not use MHD - or any other IHE protocol - to get data, they just use plain SMART-on-FHIR auth and then query data using the patient ID, so no identifiers are sent over.
Lloyd McKenzie (Oct 08 2020 at 13:18):
Presumably a patient user can access more information than just their own patient record - parents or others with medical power of attorney would need to be able to access records of children or others. So merely logging in wouldn't tell you what patient's data to return. How would the desired patient's information be indicated?
Alexander Henket (Oct 08 2020 at 13:40):
query data using the patient ID, so no identifiers are sent over.
This looks like a contradiction?
Alexander Henket (Oct 08 2020 at 13:41):
@Lloyd McKenzie in MedMij is impossible to ask data for any other patient than the one you logged in as.
In 'normal' FHIR context you could do all that using the HTTP POST search.
Michele Mottini (Oct 08 2020 at 13:55):
The patient ID is a uuid or a sequential number or some other meaningless string to any other party than the target endpoint
Vassil Peytchev (Oct 08 2020 at 13:55):
query data using the patient ID, so no identifiers are sent over.
This looks like a contradiction?
It highlights the confusing difference between Patient.id and Patient.identifier
Lloyd McKenzie (Oct 08 2020 at 14:14):
HTTP POST search isn't any more secure than a GET search.
Presumably MedMij then relies on the sharing of credentials - as there being no ability for someone with a legal right to access the patient information being unable to do so would presumably be problematic?
John Moehrke (Oct 08 2020 at 15:00):
Let me try to clarify... The concern is that http intermediaries and http endpoint technology will log the GET url, but will not automatically log a POST body.
John Moehrke (Oct 08 2020 at 15:00):
so this is all driven by the default behavior of web infrastructure to log GET but not POST body
John Moehrke (Oct 08 2020 at 15:01):
Patient.identifier vs Patient.id --- as @Vassil Peytchev indicates this confusion has driven many bad decisions. If it was pointed out that the .id would tend to be mostly a guid, AND that it is the id that is in the GET parameter... then discussion might be more informed
John Moehrke (Oct 08 2020 at 15:03):
MHD does not require Patient.identifier. Fact is MHD has been clear that it requires the Patient "id". we have been explicitly silent on the very fact that in FHIR today a token could carry the Patient id or the Patient identifier. In fact I have asked questions here on zulip to help me clarify how that actually works, especially in a federated Patient registry environment.
John Moehrke (Oct 08 2020 at 15:04):
So @Alexander Henket , there is nothing wrong with NL providing further clarification to MHD. There is a national extensions explicitly for this kind of specialization.
John Moehrke (Oct 08 2020 at 15:05):
Broader.. I like the idea of having the OAuth token be patient specific... which could override the any patient parameter, thus making a patient parameter meaningless and potentially forbidden. YES, this would require the app get new tokens each time the patient changes. Where a user is handling many patients at the same time, this might get more complex... but it is just software... we should not be afraid of complexity when it is needed.
John Moehrke (Oct 08 2020 at 15:09):
I don't think I hear anything here that is difficult, but it is clearly new and different. These changes would be beyond what a Change Proposal could accomplish. A new work item would be needed... ITI is accepting new work item proposals right now.
John Moehrke (Oct 08 2020 at 15:10):
here is the request for new work items for ITI https://groups.google.com/g/itiplan/c/DFMRAKtDnG4
John Moehrke (Oct 08 2020 at 15:13):
Grahame Grieve said:
so you don't want an identifier at all - John Moehrke this is a more generic IHE issue - XDS for consumers will typically work this way in any country.
@Grahame Grieve I think it is a general purpose security/privacy preserving model... It certainly is not unique to XDS... it is driven by a Privacy preserving approach..... that said, it is fully driven by the fact that web infrastructure "default" logging logs GET parameters but does not log POST body. The problem can also be satisfied by just forbidding intermediaries and endpoints from logging GET parameters, or at least logging them into a log that is not privacy protecting (like AuditEvent schema enables).
John Moehrke (Oct 08 2020 at 15:18):
it might also be driven by a fallacy that the GET parameters are visible on the network, when the POST body is not visible on the network. TLS protects everything on the network.
John Moehrke (Oct 08 2020 at 15:23):
another factor... s that this is a discussion around where http REST is used not in a point-to-point way. In point-to-point the two endpoints (client v server) are expected to have patient data exposure and are thus managed... the problem is when an architecture requires (or allows) trusted intermediaries. Hence, they are "trusted but not fully trusted"... when one designs an architecture that enables "trusted but not fully trusted", one creates problems like this.. once one starts with a problem like this, pushing the risks around does not eliminate the risks, it just pushes the risk around. The situation of "trusted but not fully trusted" is the problem.
John Moehrke (Oct 08 2020 at 15:27):
SOAP has mature ways of handling "trusted by not fully trusted"... Thus using SOAP transport, with REST verbs... is likely the best solution... but sure does make REST more complex than "simple http REST"... might we call this "end-to-end securable REST"? thus just re-inventing asynchronous SOAP... European Commission has endorsed the SOAP profile "AS4" for these cross-boarder use-cases... this is why IHE XCA added an AS4 transport model.
Alexander Henket (Oct 08 2020 at 16:52):
Can you create a national extension that extends what’s been constrained? FYI: my CP has been submitted to Sarah Bell: see CP-ITI-AHe-Addition-of-POST-based-query-option
Alexander Henket (Oct 08 2020 at 17:31):
Patient.identifier vs Patient.id --- as @Vassil Peytchev indicates this confusion has driven many bad decisions. If it was pointed out that the .id would tend to be mostly a guid, AND that it is the id that is in the GET parameter... then discussion might be more informed
I see... parameter patient exists in FHIR Core and is defined as reference, not token. Reference would indeed be based on Patient.id, hence presumably meaningless. Whether or not you would know what the Patient.id for a patient is on the documents you seek is doubtful. Would an XDS Index have 1 Patient.id across all documents?
MHD in addition to FHIR Core defines patient.identifier as parameter. This seems to be clearly defined as based on the Patient.identifier which would be the national patient identifier we want to avoid.
Finally MHD states "The Document Consumer shall include search parameter patient or patient.identifier, and status." Since patient seems far fetched as it is unlikely I'd have that, I'd say my best bet becomes patient.identifier, but I cannot populate that in the URL (according to said auditors and the MedMij architecture)
We could make this a very big thing, but if you say it is fine to just use the application/x-www-form-urlencoded search defined in FHIR Search for MHD then maybe it is enough to apply the CP to MHD as submitted? I really suspect that treating this as a national extension after MHD explicitly constrained it, is not conformant.
Gino Canessa (Oct 08 2020 at 17:35):
Re: OAuth patient tokens
Doing a SMART launch today with a patient context (e.g., launch/patient), is what you are describing, isn't it? Based on implementations I've seen, that is the behavior enforced.
That said, there are also valid use cases for user level access, such as a provider looking at a list of patients.
I see a role for both, and feel confident that EHR vendors have policies in place to make sure that applications use the appropriate level based on their activity.
Overall, I don't see where the current process is deficient - is there something I'm missing?
Alexander Henket (Oct 08 2020 at 19:06):
We don't do SMART on FHIR in MedMij. The architects who designed it, decided against that. Knowingly or unknowingly, I could never establish. In any case: we create IGs within the constraints of the networks they run on. We don't make those rules.
Alexander Henket (Oct 08 2020 at 19:07):
The PHRs, at least when interacting with MedMij, do OAuth but different from SoF
John Moehrke (Oct 08 2020 at 20:21):
so the parameter defined in MHD for "patient.identifier" was intended to look for the OID defined as the Affinity Domain ID.. but reality is that your national identifier would also be in the Patient.identifier... so it could be used that way without constraint that it can ONLY be used with the affinity domain ID (OID)
John Moehrke (Oct 08 2020 at 20:24):
a realm could certain constrain OUT the Patient.identifier... forcing the use of Patient id only.
John Moehrke (Oct 08 2020 at 20:25):
in an XDS affinity domain, a patient would have one and only one Patient id (and one and only one affinity domain identifier)
John Moehrke (Oct 08 2020 at 20:26):
a realm could certainly require them be randomly assigned opaque values.
Gino Canessa (Oct 08 2020 at 20:35):
We all have to live with various constraints, I understand completely!
However, I would also say that if you have an OAuth layer that needs items defined in SMART, it would be nice to use them (e.g., if you want patient-restricted tokens, using launch/patient, etc.). Not only does it help in general with alignment, but it's less time for you spent re-inventing things.
Daniel Venton (Oct 09 2020 at 14:02):
I suspect the trouble is that when your URL is "https://fhirserver.com/Patient?identifier=http://ssa.gov|123456677" (Substitute appropriate values for NL or other.) No matter what you do, no matter the auth token, no matter the certificates involved, the URL will always always be transmitted across the wire as plain text. Every single router/proxy/gateway/ISP/backbone element that handles the message will see and can log that plain text URL. Moving the values into the message, whether as a header element or part of the body (any style) means that the contents are encrypted and even if packet sniffed and logged should be undecipherable.
It would be great if every component between me and you could be trusted but it's public and by definition can't be.
What if the URL was "https://fhirserver.com/Patient?identifier=http://ssa.gov|123456677&family=test&given=Joe&birthdate=1799-01-01"? Any person that had access to any of those logs now can steal Joe test's identity. Perhaps enough that they will then be able to access his chart.
Disclaimer: As I understand internet protocols.
Vassil Peytchev (Oct 09 2020 at 14:18):
That is not correct. The https encryption happens before the URL is transmitted.
Brendan Keeler (Oct 09 2020 at 14:49):
SOAP-transport REST AS4 sounds like a personal hell
Brendan Keeler (Oct 09 2020 at 14:50):
Please no
John Moehrke (Oct 09 2020 at 17:20):
Vassil Peytchev said:
That is not correct. The https encryption happens before the URL is transmitted.
@Vassil Peytchev take a look at my explanation why GET and POST are seen as different. You will note that I fully agree with you. The issue is not on-the-wire encryption, TLS is understood and used. The issue is trusted intermediaries audit logs. --- at least this is my understanding, right @Alexander Henket ? can you confirm?
John Moehrke (Oct 09 2020 at 17:21):
Brendan Keeler said:
SOAP-transport REST AS4 sounds like a personal hell
re-inventing it is worse hell.. but I agree SOAP and AS4 and re-invention are to be avoided.
Vassil Peytchev (Oct 09 2020 at 17:26):
Yes, @John Moehrke your explanation makes sense. I was responding to the claim that the URL would be "transmitted across the wire as plain text". That part is incorrect.
John Moehrke (Oct 09 2020 at 17:32):
Vassil Peytchev said:
Yes, John Moehrke your explanation makes sense. I was responding to the claim that the URL would be "transmitted across the wire as plain text". That part is incorrect.
agreed... this is a fallacy that is so hard to kill.
Alexander Henket (Oct 13 2020 at 14:34):
@John Moehrke That is what I'm told is the issue at hand yes.
Last updated: Apr 12 2022 at 19:14 UTC
