Stream: implementers
Topic: Multi-server environments
Elliot Silver (Aug 03 2018 at 21:07):
In response to GF#16031, we're looking for feedback on concerns for working with multi-server environments.
Most discussions I've seen on Zulip seem to assume a single server that will have all the information a client is looking for, however that architecture isn't required by FHIR. Even if a single server has all the information a particular client needs, there is no requirement that an environment have only a single server.
In previous discussions, it was suggested that search doesn't need to span servers. That is, e.g., searching server A for observations for patients named Smith will only return observations (on server A) for patients named Smith (on server A); any server A observations for non-server A patients aren't necessarily returned. Is this generally expected? (And if you know where this is actually documented, I'd appreciate a link.)
Are there other places where multiple servers introduce complexity that we should warn implementers about? Or should implementers just realize that (a) they might encounter multi-server environments, and (b) multi-server environments make things tricky?
Grahame Grieve (Aug 03 2018 at 21:07):
it's specifically documented that search is allowed to return resources from other servers.
Grahame Grieve (Aug 03 2018 at 21:08):
(recent change after this was discussed here before)
Grahame Grieve (Aug 03 2018 at 21:08):
I personally think (a) and (b) are inherently true and nothing special about FHIR
Elliot Silver (Aug 03 2018 at 21:23):
it's specifically documented that search is allowed to return resources from other servers.
Agree, which is why searches include the full URL of the results, not just the relative URL. It is also documented that _include need not include resources on other servers.
I personally think (a) and (b) are inherently true and nothing special about FHIR
I agree with that too. What about "implementers should just realize"? And even if they realize it, and know that there are tricky bits here, wouldn't we do them a service to point out what some of those tricky bits are? Surely we expect all implementers to realize that healthcare systems have safety risks, yet we provide a list of clinical safety gotchas.
Grahame Grieve (Aug 03 2018 at 21:41):
I think that whatever warning we can get agreement too will be so generic it's not useful. "Implementers should be aware that there might be more than one server out there...." (ok, we could probably get better than that, but how much better?)
Elliot Silver (Aug 03 2018 at 22:09):
I'd hope we could do more than absolutely generic.
Lloyd McKenzie (Aug 03 2018 at 22:10):
Care to propose some specific language? :)
Elliot Silver (Aug 03 2018 at 22:13):
No, not really. I submitted the tracker item because I was looking for guidance. I've got some bullet points in the tracker, but they need verification. And the one thing I thought was explicitly defined (cross-server search), I can't find text in the spec to back it up.
John Moehrke (Aug 04 2018 at 15:01):
There be dragons there... http://build.fhir.org/assets/images/dragon.png
Grahame Grieve (Aug 04 2018 at 21:22):
well, we can add that if you want. For editors: it's easy to add this now - just wrap your implementer warning in the source with [%dragons-start] and [%dragons-end%]
Grahame Grieve (Aug 04 2018 at 21:23):
(in the main build)
Brian Postlethwaite (Aug 07 2018 at 03:19):
I'm not sure if this was in jest or not now :~
Last updated: Apr 12 2022 at 19:14 UTC
