Subscription with blank payload

1

Hi,

my question is following:
If one sets up a Subscription with rest-hook method and without payload:

{
“resourceType”: “Subscription”,
“criteria”: “/Observation?patient=123&code=http://loinc.org|1975-2”,
“channel”: {
“type”: “rest-hook”,
“endpoint”: “https://biliwatch.com/customers/mount-auburn-miu/on-result”,
“payload”: “”,
“header”: [“Authorization: Bearer secret-token-abc-123”]
}
}

then the “Server sends a POST request with no body to the nominated URL”
Question is then how does the client know what Subscription is this notification about - for what patient and what observation type? The nominated URL in this example is a base URL without giving a clue. It is also not defined in spec if the Subscription local ID ( that is returned in Location header by the HTTP POST response from initial ) is passed somewhere in the empty POST request.
I can come up with 2 options how to make this work

  1. Server adds a Location header to POST request when notifying client. The client knows what search criteria corresponds to each subscription and thus figure out what type of observation of what patient has a new value. Problem with this seems to be that Location header is not meant to be used in POST requests, but in responses only.
  2. The nominated callback URL in the channel endpoint element contains same search parameters as in criteria
    “endpoint”: “https://biliwatch.com/customers/mount-auburn-miu/on-result?patient=123&code=http://loinc.org|1975-2”

so how should this be implemented, any more options - or have I overlooked something in the specification already supports this?

cheers
Jürgen

2

“how does the client know what Subscription is this notification about” - it pretty much doesn’t know. It knows that there’s some new entry that matches a query, so it can find out what that is by running the query. Obviously it’s more convenient for the client to get the whole resource so it doesn’t have to query for it, but the advantage of not getting the resource is that no protected information leaks on the subscription channel, and so the security arrangements can be much less.

3

If a client wants to create multiple subscriptions, it’s is free to define a different endpoint for each. It can give them nice easy/friendly names if it wants to, etc. The API is “provide any URL you want”, so that’s pretty expressive :slight_smile:

4

okay, so that I was thinking as well it woks out. The endpoint URL would need to match the criteria search parameters, though. I don¨t see otherwise how it would work for client to construct the search URI to run the query matching the subscription.

5

I’m not following what you mean. Maybe an example would help.

My app wants to create 3 subscriptions on your server. So I create an HTTP handler in my app listening to:

http://my-app/subscription-notices/{{internal-id}}

Then I go ahead and create subscriptions. I assign the first one an internal id of “1”, and so I create a subscription like:

{
  "resourceType": "Subscription",
  "criteria": "/Observation?patient=123&code=http://loinc.org|1975-2",
  "channel": {
    "type": "rest-hook",
    "endpoint": "https://my-app/subscription-notices/1",
    "payload": ""
  }
}

That allow me, as the client, to tie these particular search details to an endpoint I specify. Then I can create another like:

{
  "resourceType": "Subscription",
  "criteria": "/Observation?patient=456",
  "channel": {
    "type": "rest-hook",
    "endpoint": "https://my-app/subscription-notices/2",
    "payload": ""
  }
}

I can keep track internally of which internal ids map to which of my subscriptions; and the server just blindly posts the endpoints I supply.

6

Yes, of course your method works.
I had in mind a more dynamic solution where the client does not need to arrange the subscription management. Also the subscribing application and observation receiving client may be different systems. In our case it is preferable that the endpoint notification is self sufficient

{
  "resourceType": "Subscription",
  "criteria": "/Observation?patient=123&code=http://loinc.org|1975-2",
  "channel": {
    "type": "rest-hook",
    "endpoint": "https://my-app/subscription-notices?patient=123&code=http://loinc.org|1975-2",
    "payload": ""
  }
}

But by reading the current specificatiion again I realize this won’t work as the server POST’s the notification to the endpoint, so the parameters would get lost.
However, the spec also says

The server must append the headers, if any are given, to the POST request that it makes to the client.

So now I wonder if those parameters could be provided in Channel header element. I think should be possible as the spec says:

Subscription.channel.header: Additional headers / information to send as part of the notification.

Having custom headers should just work fine then, blindly for the sever if formatted according to RFC 2616.

7

well, yes you could use custom headers. But if I was doing what you’re doing, I’d just say to send the whole resource, and deal with the security concerns directly. But that’s a personal choice

8

Hi jkerstna/grahamegrieve,

Is there a way to subscribe all resources linked to a particular MRN with a single subscription request.
The reason is, i want to fetch all updated resources as a bundle for a particular MRN (if the criteria matches).

I am trying to implement below subscription criteria on HAPI server:

“criteria”: “Patient/9/$everything?_lastUpdated=gt2018-09-05T11:02:59.777+05:30”,

but looks like the allowed syntax for criteria is “Resource?[params]”, something like this “criteria”: “Observation?code=http://loinc.org|1975-2”,

Any inputs on this will be much appreciated !!!

Thanks
Sahil Khanna