Stream: implementers
Topic: use of keep alive
Jens Villadsen (May 10 2017 at 10:02):
I have a setup that includes a FHIR server and a FHIR client where the client is responsible for posting and updating resources on the server - e.g. a stream of recorded events . The organization that owns the server would like to know if the client is alive, which can be hard to tell if no new events have happened over a longer period of time. One proposal have been to let the client spawn a daemon process that continuously in a fixed interval posts 'heartbeat' resources to the server, which would then be a specific FHIR resource. While this not a bullet proof architecture, it does give some assurance of this given setup. I'm looking for comments/inputs to this, and I can imagine other people might also have this need.
Lloyd McKenzie (May 10 2017 at 10:19):
Why do a POST? Why not do a simple GET - e.g. against the "capabilities" endpoint
Jens Villadsen (May 10 2017 at 10:23):
The detail that I forgot to mention is that the client is basically shipping out events from a queue. What the the receiving part would like to know is if there is congestion/delay in the received events. This is why I would post a resource containing a timestamp from when this event was put into the queue.
Jens Villadsen (May 10 2017 at 10:24):
Then the server is able to calculate the delay itself
Grahame Grieve (May 10 2017 at 10:46):
I think that this is one of those things that is outside FHIR. Just define an end-point on your server like /ping and post an empty body to it
Lloyd McKenzie (May 10 2017 at 11:01):
Or send an empty Bundle as a batch
Michel Rutten (May 10 2017 at 11:03):
FYI http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13050&start=0
Jens Villadsen (May 10 2017 at 12:11):
Revisiting my original thought, a more clean strategy could be simply to use the HTTP header Date field reflecting the time of the generation of the message. It would then not require any custom FHIR stuff, but simply use the standards as intended
Jens Villadsen (May 10 2017 at 12:13):
I've must have been stuck in the HL7v2 thinking when I started thinking of this ... tsk tsk ...
Jens Villadsen (May 10 2017 at 13:17):
crap ... empty bundle's it is as the use of the header would only be able to inform whether there is congestion or not - the use of the header alone does not provide any value if nothing is sent
Last updated: Apr 12 2022 at 19:14 UTC
