Stream: implementers
Topic: patient vs subject
Jenni Syed (May 10 2016 at 16:02):
I know subject queries allow for the "type" of subject to be specified since it can vary. What should servers accept for the "patient" parameter? So far, our server expects just the id, since it's clear what type of resource patient references. Should servers also accept/parse for patient:Patient=123 and patient=Patient/123?
If so, this goes back to some earlier questions around why we have 3 different ways for doing this simple query...
Sean Moore (May 10 2016 at 16:07):
Hey Jenni, I can't for sure speak to what we should do, but we support the modifier and the Relative URL (we support receiving a full URL too). We do this for compatibility with clients, since we often receive the modifier even though it is not needed.
Sean Moore (May 10 2016 at 16:07):
I think we're too far gone with client support of modifiers and URLs to constrain this at this point, but I would love to constrain it further if possible.
Michael Donnelly (May 10 2016 at 16:09):
And not make it worse in the future.
Michael Donnelly (May 10 2016 at 16:09):
The problem with "options" is that they're not really optional for servers.
Jenni Syed (May 10 2016 at 16:14):
Correct. And for urls, you start getting into validating that it's "equivalent" to your server... It feels like a server should be able to generally say "I allow references to external FHIR servers" or not.
Grahame Grieve (May 10 2016 at 16:15):
we knew these were not optional or serversr
Grahame Grieve (May 10 2016 at 16:16):
I'm pretty sure we dsicussed these variations on the argonaut mailing list and come to agreement
Sean Moore (May 10 2016 at 16:17):
Jenni Syed I agree with you. External linking to FHIR servers is somethign we likely won't support. Do we need a way to formalize that in the conformance statement (or profile)?
Grahame Grieve (May 10 2016 at 16:18):
we haven't considered that before
Sean Moore (May 10 2016 at 16:19):
I don't see that as a requirement necessarily, provided we're okay with the behavior of servers to reject such a thing. Is cross server FHIR references something others are trying to do?
Grahame Grieve (May 10 2016 at 16:21):
it's allowed and I've seen a little of it in prototypes in distributed systems. I wouldn't think it would apply in the argonaut context or similar
Jenni Syed (May 10 2016 at 16:25):
Grahame - I assume for the "settled" aspect, you're referring to this: https://groups.google.com/d/topic/argonaut-project/srjnfhNBQbk/discussion. There was a mention of banning the Paitient/ side. But I'm not sure if we discussed beyond that
James Agnew (May 10 2016 at 16:26):
I expect that there will be lots of servers that don't allow cross-server references, and lots that do. Both are valid ways of using FHIR.
Jenni Syed (May 10 2016 at 16:26):
Which, if we did that, would remove the patient=Patient/123
Jenni Syed (May 10 2016 at 16:26):
(If i understood your intent correctly)
Jenni Syed (May 10 2016 at 16:26):
For some reason, I thought there was a longer thread on this as well, but can't find it.
Jenni Syed (May 10 2016 at 16:31):
As to external server references, I assume many of the ref impls and some FHIR servers that keep track of HIE-type info may do this. But as @James Agnew mentions, I think there will be large contingents that don't allow that as well
Grahame Grieve (May 10 2016 at 16:35):
That's the one I had in mind, but I thought we closed that out.
Grahame Grieve (May 10 2016 at 16:35):
we should ;-)
Sean Moore (May 10 2016 at 18:35):
I will respond to that chain with two proposals:
Sean Moore (May 10 2016 at 18:36):
1. that we should remove the compartment syntax from Argonaut server support (/Patient/[id]/resource)
Sean Moore (May 10 2016 at 18:36):
2. That argonaut servers will not provide support for resolving external resource references outside of their server.
Sean Moore (May 10 2016 at 18:36):
Any concerns?
Sean Moore (May 10 2016 at 18:37):
I think the IG should also include bestpractices for how to construct a query as a client - i.e. support patient=foo above patient:patient=Patient/foo
Jenni Syed (May 10 2016 at 18:39):
agree. I think we did agree that compartment searches weren't required
Jenni Syed (May 10 2016 at 18:39):
but it would be good to have a wrap up/conclusion
Josh Mandel (May 11 2016 at 00:09):
Agreed we need to wrap this discussion up in a neat package!
I'm fine saying in Argonaut that we remove compartment syntax. I do think we need server support for all of the legal FHIR ways to filter on "patient=123" (I agree it's a bit of optionality but my assessment is that it's not hard for servers to get this right, and like it or not, client libraries have diverse behavior here.) @Sean Moore That leaves me with your point #2, which I don't understand: given that the current Argonaut focus is on read APIs, when would an Argonaut server need to "resolve external resource references"?
Jenni Syed (May 11 2016 at 14:32):
@Josh Mandel You're correct that implementing read-only helps alleviate that concern (though I think some of our servers either already enable write or are considering that). However, the patient param can be set to a full URL as well. http://hl7.org/fhir/dstu2/search.html#reference
Jenni Syed (May 11 2016 at 14:33):
So, they can technically search for a resource on your server that references a patient on another. Our server wouldn't allow it - either on the read/query nor write
Josh Mandel (May 11 2016 at 14:34):
That seems fine... Or, I mean, you could "allow it" but it would return no results.
Grahame Grieve (May 11 2016 at 15:48):
ah yes. well, I agree that argonaut should not allow full url in search. sorry for missing that point
Eric Haas (May 11 2016 at 19:40):
I will go ahead and document as a resolved issue in Argo and add to the General Argo Guidance and in Patient IG.
Grahame Grieve (May 11 2016 at 19:42):
thx Eric
Brian Postlethwaite (Jun 06 2016 at 09:44):
I think you will still want to be able to support subject=Patient/123, as in some cases search parameters can be more than 1 type of reference.
Brian Postlethwaite (Jun 06 2016 at 09:45):
e.g. SearchParam: appointment.actor
Brian Postlethwaite (Jun 06 2016 at 09:46):
/Appointment?actor=Patient/43
/Appointment?actor=Practitioner/43
/Appointment?actor=43 (what would you do with this? search both patients and practitioners - and the other valid types - for the id 43
Last updated: Apr 12 2022 at 19:14 UTC
