FHIR Chat · No payload and using topics

Stream: subscriptions

Topic: No payload and using topics

Allan Bro Hansen (Oct 16 2017 at 12:07):

Hi
I have did made a post at https://chat.fhir.org/#narrow/stream/implementers/topic/Subscriptions.
Now moving to this (better) stream.

My scenario is to notify external systems when a patient with an appointment arrives.

This "when a patient arrives"-event seems natural to state via the topics and eventDefinition described in connectathon-topic :
{
"resourceType": "Subscription",
"criteria": "Appointment", -- could include filtering of appointments - if subscrieber only wants to hear of specific appointments
"extension": {[
"url": "http://hl7.org/fhir/subscription/topics",
"valueReference": {
"reference": "https://example.com/EventDefinition/123",
"display": "Patient with appointment arrived",
"channel": {
"type": "rest-hook",
"endpoint": "http://notifyMe.com/patientWithAppointmentArrived",
"header": "Authorization: Bearer secret-token-abc-123"
}
}

I would like to stick with a notification without payload, hence the subscriber must subsequently retrieve the data from the server.
This however leaves me with the issue "which GET should be perform by the subscriber"?

One solution: Just do a /Appointment?_lastUpdated=gt<lastQueryTime>
But this will include extra (unwanted) appointments and leaves the understanding of the EventDefinition/123 in terms of an appointment to the subscriber.

Another solution: Support some kind of patientHasArrived search: /Appointment?patientHasArrived=true&_lastUpdated=gt<lastQueryTime>
This seems more desirably (still with some (fewer) unwanted appointments) but introduces a new search criteria and clashes with the description at https://www.hl7.org/fhir/subscription.html#2.46.6.1.

Any thoughts on this?

Jens Villadsen (Oct 16 2017 at 21:22):

And you are absolutely sure you don't want/cannot include the slightest amount of context data within your payload? Ain't performance an issue for you?

Allan Bro Hansen (Oct 17 2017 at 06:08):

I’m absolutely not sure, in fact I am currently slightly in favor of the payload-solution adding pros and cons.
The no-payload solution seemed initially nice because:
1) No need to construct and add the payload (obviously)
2) Leave the security to the REST GET service which already handles it
3) Simple if the POST cannot be delivery – you do not have to keep track of the each message and deliver all of them when the receiving end is ready
4) No chronology issues
But the no-payload solution becomes less elegant with topics/filters, and the subscriber of course has to perform a subsequent GET to get data.
Would nice to hear if someone is actually using the no-payload approach.

Grahame Grieve (Oct 17 2017 at 07:18):

yes I've seen it used in semi-prototype. It was really simple for low complexity / narrow usage.

Grahame Grieve (Oct 17 2017 at 07:18):

as you've found, doesn't scale well in terms of flexibility

Jens Villadsen (Oct 18 2017 at 10:17):

Now, reading throguh https://www.hl7.org/fhir/subscription.html#2.46.6.1 ... I would say that there might be a case missing to support what I think maybe could fit your case:

Jens Villadsen (Oct 18 2017 at 10:20):

@Allan Bro Hansen an event from the server where the body is not empty nor the full resource, but instead a bundle that contains references to all that has changed. Thereby your client knows where to go specifically and you don't disclose any information unless it is fetched intentionally by your client

Jens Villadsen (Oct 18 2017 at 10:20):

using the normal auth mechanisms

Jens Villadsen (Oct 18 2017 at 10:30):

that maybe falls within the evendefinition talk ... I can't really figure that out ..

Allan Bro Hansen (Oct 18 2017 at 10:36):

I guess I would be okay to define a criteria with an "_elements" and hereby define a not-full resource. It still leaves some of the other "with payload" issues (single event messages and chronology). On a side note: I have chosen the "with payload" solution