Stream: implementers
Topic: FHIR Ping
René Spronk (Jan 28 2019 at 12:01):
What's the easiest/fastest way to get an answer to a 'FHIR Ping' (i.e. a boolean check whether or not there is a FHIR listener at a certain base URL) ?
[base]/metadata will work on all servers, a 200 response indicates a FHIR Listener. But this is slow, the response structure [which is itself ignored] rather large
[base]/Patient?_id=<some fixed uuid> probably works on most servers, returns an empty Bundle, and has a quick round trip time. However, if the server doesn't support the _id parameter it will return a bundle with (a subset of) 'all patients'.
Any suggestions/comments?
Brian Postlethwaite (Jan 28 2019 at 12:06):
metadata?_summary=true makes it smaller. And should be quick, in some servers this is a hard coded file, other this is generated in code without db/disk, others like mine generate and cache the result, so you have basically instant results. And with compression too, the result can be quite little.
René Spronk (Jan 28 2019 at 12:54):
Hmm. on http://test.fhir.org/r3 /metadata takes forever, whether one uses _summary or not. /metadata is attractive, and in the kind of script I'm writing performance is not a key issue, but shouldn't there be an easy way of doing this? Currently "/Patient?_id=xyz123abc" beats (in terms of round trip time) any /metadata based URL hands down.
Michel Rutten (Jan 28 2019 at 13:09):
Maybe you could try HEAD to avoid transmission of the body, if the server supports it?
René Spronk (Jan 28 2019 at 14:23):
Risky, this may well result in a 405 or 501, on any webserver, regardless of whether it supports FHIR or not.
Grahame Grieve (Jan 28 2019 at 19:21):
http://test.fhir.org/r3/metadata?_summary=true in json = 1012ms for me
Grahame Grieve (Jan 28 2019 at 19:21):
response size 40kb
John Silva (Jan 28 2019 at 21:48):
That (1+ sec) seems too long! Why not have a FHIR Ping, as suggested by the thread title; a 'no-op' operation to check that the FHIR Server is alive? This would (should also put less load on the FHIR server if many clients for example, were trying to ping it.)
Brian Postlethwaite (Jan 28 2019 at 22:16):
You could ask for patent/--- which is an invalid id.
Brian Postlethwaite (Jan 28 2019 at 22:17):
Have you tried other servers metadata timing? And how critical is how long this ping takes? Doesn't sound like a user experience problem.
Brian Postlethwaite (Jan 28 2019 at 22:17):
Is a user waiting for the ping?
Grahame Grieve (Jan 28 2019 at 22:33):
well, it depends quite what you want to find out. You can hit .well-known on my server. But that doesn't tell you that the FHIR server is functional. I use patient search in the web server watcher I use to make sure that the FHIR server is fucntional
nicola (RIO/SS) (Jan 29 2019 at 06:46):
we use _count=0
René Spronk (Jan 29 2019 at 09:05):
Problem with /Patient/? is that there may be FHIR servers that don't support Patient resources. OK, those are going to be few and far between - /metadata is the only truly universal solution; it seems only test.fhir.org is "slow" (relatively speaking)..
Grahame Grieve (Jan 29 2019 at 09:12):
how long is it taking for you?
Grahame Grieve (Jan 29 2019 at 09:13):
locallly it takes me 200ms. Anything more than is network time
René Spronk (Jan 29 2019 at 13:55):
Ok, when querying for /Patient/?id=aaa123abc, delays are (in seconds) .14 (Vonk - admittedly hosted 'nearby'), .47 (test.fhir.org), .41 (hapi r3). Using /metadata: delays are (in seconds) .46 (Vonk), 10.4 (test.fhir.org), .88 (hapi r3) - a whopping 10.4 seconds. Can't imagine that to be wholly due to 'network time' I'm afraid..
Nick Hatt (Jan 29 2019 at 14:27):
/metadata doesn't really need to be part of the FHIR server, it's static enough that could host it on a CDN. Furthermore, implementers may have multiple separate codebases implementing different clusters of resources. Microservice practitioners would probably try to carve resources up into different functional areas, making the health check topology unique and ever-changing.
Servers with enough consumers should offer a status page that is hosted external to the stack. They should give the best possible representation of their internal structure, without giving away too much of the internals of the platform. We use statuspage.io.
John Silva (Jan 29 2019 at 14:47):
@Nick Hatt -- good points! It seems like the answers here are all using 'side effects' to deduce if a FHIR server is up or not. Why not implement a 'real ping' so that it can be used for this desired intention?
Michael Lawley (Jan 29 2019 at 14:49):
tx servers may not support Patient
Michael Lawley (Jan 29 2019 at 14:58):
You could also use metadata?_elements=fhirVersion to cut the response size
Nick Hatt (Jan 29 2019 at 15:46):
@John Silva I'm challenging the idea that FHIR server needs to be singular from a service level perspective. Assume I use AWS S3 to implement the Binary resource, and maybe Patient is served from Azure, for example. I need to be able to express this difference to my API clients. That may be because I'm contractually obligated (via an SLA) or because I want to them design around potential failures.
Peter Jordan (Jan 29 2019 at 19:30):
Another possibility is [base]/$versions .
Plenty of FHIR servers don't support the Patient resource (e.g. Terminology Servers, Provider Directory Servers, etc.).
Michael Lawley (Jan 29 2019 at 20:26):
I think there are also many that don't support [base]/$versions too
Grahame Grieve (Jan 29 2019 at 20:46):
http://test.fhir.org/r3/metadata?_summary=true : 1824 ms
http://test.fhir.org/r3/metadata : 2396 ms
I have no idea why you're getting 10sec+ times
Grahame Grieve (Jan 29 2019 at 20:46):
Nick is correct but it's irrelevant how the server is structured - the client sees it as a single endpoint
Michael Lawley (Jan 29 2019 at 20:57):
Nick's point could be an argument for a specific health endpoint which has the specific purpose of attesting to the "status" of the server as a whole. This could get quite complex (but also useful) in the context of federated servers.
Michael Lawley (Jan 29 2019 at 21:00):
Also, FWIW, I get a significant speed different between http://test.fhir.org/r3/metadata?_elements=fhirVersion and http://test.fhir.org/r3/metadata?_elements=fhirVersion&_format=json (3.5s - XML vs 0.5s - JSON)
Grahame Grieve (Jan 29 2019 at 21:11):
same for me. seems the server is very prone to contention?
René Spronk (Jan 30 2019 at 08:13):
@Grahame Grieve Originally I didn't use any headers, so your server creates HTML (10.4 secs), if requesting JSON, it'1 1.5 secs (for /metadata)
Joel Schneider (Jan 31 2019 at 21:13):
The HTTP OPTIONS method could potentially be useful for something like this. However, the FHIR RESTful API spec does not specify behavior for OPTIONS.
Vadim Peretokin (Feb 01 2019 at 09:54):
@René Spronk have you tried the suggestion from @nicola (RIO/SS) ? http://test.fhir.org/r3?_count=0&format=json seems quick, 0.5-0.7s
Brian Postlethwaite (Feb 03 2019 at 23:34):
Not all servers support global search...
Vadim Peretokin (Feb 04 2019 at 08:01):
Well, yes, technically all you have to support is /metadata and nothing else to be compliant, but we've already started from that
René Spronk (Feb 04 2019 at 08:33):
So I went for http://test.fhir.org/r3/metadata?_elements=fhirVersion&_format=json - /metadata is supported by all systems, and should they not support the query parameters (_elements) the ping will still work..
Brian Postlethwaite (Feb 04 2019 at 09:45):
I Iike it.
John Moehrke (Feb 04 2019 at 13:13):
I think it would be better for us to take your use-case and come up with an R5 solution. I would like that solution to be a variation of the /metadata endpoint. One would hope that _summary could be made fast, and thus we could put in a 'recommendation' that a _summary should be able to be responded to quickly... not sure how that goes... I worry that _elements is an unusual thing, and would often be implemented by first getting the normal response then filtering to the _elements... thus it would tend to be slower.
René Spronk (Feb 04 2019 at 14:19):
Well, either we mandate something new (some new mechanism, from R5 onwards) which shall be supported by all FHIR servers, or we tweak the /metadata query, e.g. by specifying that its contents should be returned ASAP and that a cached version of /metadata may be way of achieving this.
Grahame Grieve (Feb 04 2019 at 19:45):
don't know what that would achieve. I'm already returning it as a quickly as possible.
Last updated: Apr 12 2022 at 19:14 UTC
