Stream: implementers
Topic: Additional Query Parameters
Conrad Chmara (Feb 27 2017 at 15:49):
I am currently working with another group to start sharing information. They are currently proposing to have additional query parameters added to all requests. They would like to see these items passed as query parameters. Items to be passed include a transaction id, user id, etc. Basically additional Audit information. From a FHIR perspective how should these really be added. Message Headers? Or is it ok to add them as query params? They are also referring to these items as extensions. Are there resources I can look at that may reference implementing things like this in a FHIR manner? We will be using HAPI for the client, they have told us that they plan on using HAPI as the server.
Lloyd McKenzie (Feb 27 2017 at 16:41):
Generally this sort of information would be handled at the HTTP layer. They'll be relevant whether doing queries or creates or updates. The HTTP header is where protocols like OAuth put this sort of information. However, if you're looking at transporting information over MLLP, then you may need to put tags on the MessageHeader or something. I wouldn't use extensions as extensions are typically part of signed content and authentication information needs to be something you can strip out seemlessly.
Lloyd McKenzie (Feb 27 2017 at 16:41):
Is there a particular reason you're looking at messaging as your exchange paradigm?
Conrad Chmara (Feb 27 2017 at 16:48):
Not my implementation. I need to be able to retrieve data from this source. I am basically looking for clarification, as I have not read about using extensions in this manner.
They are proposing that for a resource lookup these params would always need to be added. For example baseUrl/Resource/?subject=XXX&type=something&transactionId=123445&userID=me&otherAuditInformation
They will only support searches for resources. I would like to know more so I could suggest alternatives.
Conrad Chmara (Feb 27 2017 at 16:52):
Even if it just means clarifying their language in the ICD to denote these are not FHIR related items and are security items.
Lloyd McKenzie (Feb 27 2017 at 17:50):
FHIR allows for the possibility of non-FHIR-defined parameters on queries (and even on other calls), so it wouldn't be non-conformant. It's just a little non-typical. FHIR doesn't specify how authorization occurs. But we do expect to bring SMART on FHIR into the core specification in STU 4 as a "preferred option" for RESTful security. It won't be mandatory though.
Conrad Chmara (Feb 27 2017 at 17:57):
Thank you for the clarification. I just wanted to make sure I didn't miss anything when I was researching.
Last updated: Apr 12 2022 at 19:14 UTC
