Stream: implementers
Topic: Resource to represent a FHIR Query
Marcus Wurlitzer (Mar 04 2021 at 18:09):
Hi all, is there a "FHIR way" to represent metadata of a FHIR query? Background: someone requests data from our FHIR server with a query. We would like the sender to submit not only the query, but also information about who sends it, at what time, what authorization they have, and possibly more. That "Query resource" may be stored as a kind of audit event and also used to form the response (think of asynchronous queries). Quick sketch of what such Resource could be like:
- Query.sender - Reference(Person)
- Query.sendingOrganization - Reference(Organization)
- Query.timestamp - instant
- Query.parameters 0..* any number of parameters that may be query-specific. Also including an authorization token (or perhaps this should go somewhere else?)
- Query.requestBundle - Bundle with the actual queries to be executed
- Query.responseBundle - the response
Is there a way to do it in FHIR? Or would you say that this goes to a "meta-level" that is beyond what FHIR is supposed to be?
Yunwei Wang (Mar 04 2021 at 18:28):
This is interesting idea. First question, are you using post? Otherwise, how could a client search and send those data at the same time?
Marcus Wurlitzer (Mar 04 2021 at 19:10):
This would be a POST query then, yes, like a Bundle with an entry where request.method = GET and request.url = Patient?identifier=12345.
Yunwei Wang (Mar 04 2021 at 19:26):
I think you can create a profile on Bundle with extensions for Reference(Person) and Reference(Organization). why do you need Reference(Organization) since Person already have Person.managingOrganization
Marcus Wurlitzer (Mar 04 2021 at 19:39):
Right - the Bundle has many properties that would be needed. Is the concept of messaging related to this?
Lloyd McKenzie (Mar 05 2021 at 04:46):
It sounds like what you're trying to do is more up the messaging pathway. In REST, the user would authenticate with OAuth and you might, at that point, capture their reason for access.
Lloyd McKenzie (Mar 05 2021 at 04:46):
Note that Person is never allowed to be referenced. You must use Patient, RelatedPerson or Practitioner. Person is a linking resource, it can't ever act on its own.
Lloyd McKenzie (Mar 05 2021 at 04:47):
There's no need to specify timestamp or parameters because you know when the query is received and the parameters are what's captured online. If you want to record all of that information in a permanent record, you can create an AuditEvent instance.
Lloyd McKenzie (Mar 05 2021 at 04:48):
Most of the FHIR community uses REST for query. You're free to use messaging, but you won't find a lot of interoperability partners.
Lloyd McKenzie (Mar 05 2021 at 04:48):
Also, solutions like SMART, CDS-Hooks, etc. won't be able to work on top of your interface.
René Spronk (Mar 05 2021 at 07:59):
Indeed, using a Parameters resource as the focal resource in a FHIR Message would support your use case.
Marcus Wurlitzer (Mar 08 2021 at 14:41):
Thanks Lloyd, I get the point on acting RESTfully, but I think this is a really an asynchronous query scenario here which cannot be handled truly RESTfully. Think having your own FHIR server and you wanting to review every query before execution.
Thank you for pointing out the nature of the Person resource.
Yunwei Wang (Mar 08 2021 at 14:46):
@Marcus Wurlitzer
but I think this is a really an asynchronous query scenario here which cannot be handled truly RESTfully. but I think this is a really an asynchronous query scenario here which cannot be handled truly RESTfully.
That is why Lloyd mentioned "messaging" which is async by nature. Take a look of this one: http://build.fhir.org/messaging. It may give you some ideas.
Marcus Wurlitzer (Mar 09 2021 at 09:16):
Yes, that's what I was thinking as well. Thank you all for your suggestions.
Last updated: Apr 12 2022 at 19:14 UTC
