Stream: subscriptions
Topic: Rest subscription without payload
Alexander Ivanov (Jan 12 2018 at 09:52):
We have started to use subscriptions and now we have two questions:
1. Why Fhir allow us to use only POST method on rest-hook channel? It seems legit to use GET if there is no payload. We have some legacy software that only supports GET requests so now we have to use extensions, is there any better way to do it?
{
"resourceType": "Subscription",
"criteria": "Patient/123",
"channel": {
"extension": {
[
"url": "http://example.com/fhir/subscription/channel/rest-hook/method",
"valueString": "GET"
]
},
"type": "rest-hook",
"endpoint": "https://example.com/callback"
}
}
2. Fhir suggests us to make a query to the server after receiving rest-hook, but it would be great to get matching Resource Id in callback (maybe somewhere in Headers). Is it Fhir way?
Grahame Grieve (Jan 12 2018 at 11:58):
I don't think that get is consistent with HTTP semantics. You'll have problems with proxies. So I'm ok with that being something you do with an extension if you have to do it
Grahame Grieve (Jan 12 2018 at 11:58):
at the moment, you can either recieve just the POST, or a POST with a whole resource. We haven't had a request for just the id. Why do you want the id?
Isaac Vetter (Jan 12 2018 at 22:48):
@Alexander Ivanov , for (1), I think that the reason an HTTP POST is required, is because the notification is logically an update.
Grahame Grieve (Jun 25 2018 at 10:14):
.. found it! I am in St Petersburg talking to Alexander about this
Grahame Grieve (Jun 25 2018 at 10:15):
@Isaac Vetter Alexander points out that it isn't necessarily an update... but we certainly don't want a cache to respond on this one. @Alexander Ivanov you're going to get back to us about this after more research
Alexander Ivanov (Jun 27 2018 at 11:30):
1. We have several internal proprietary legacy services which only supports GET callbacks, but we had already solved this problem with NGINX. So I think POST is fine as a standart default (because of possible caching of GET).
2. The idea with "Id" in header was about simplified search for resource after notification (only for interaction without payload). For example we can insert header:
Location: Patient/c3dc2595-6b61-4b50-8ed7-6e924388f599
and call for Resource without search, like GET <base_url>/Patient/c3dc2595-6b61-4b50-8ed7-6e924388f599
Grahame Grieve (Jun 27 2018 at 19:51):
hi Alexander . The second is a little bit cryptic - what has that go to do with id in header> and what's the 'without search' bit?
Alexander Ivanov (Jun 29 2018 at 15:33):
2.46.6.1 part of documentation describes the following: When the subscriber receives a POST to https://biliwatch.com/customers/mount-auburn-miu/on-result, it re-issues the criteria as a query to the server, appending &_since=:last (where :last is replaced by the time at which the client last checked). In this way it can fetch all new relevant Observations.
But I’d like to have exact id (path) of updated resource, is there proper way to do it?
Aleksandr Sorokin (Jun 29 2018 at 18:39):
I think @Alexander Ivanov offers a good idea. Fhir server already know an id of updated/created resource. It may be more convenient for the clients to get resource directly without search
Aleksandr Sorokin (Jun 29 2018 at 18:56):
For example fhir server may not include _since or _lastUpdated search parameter and the client will receive all the resources, not only those that have been updated
Grahame Grieve (Jun 29 2018 at 19:08):
you can specify the whole resource. do you have a use case for the id and not the resource?
Alexander Ivanov (Jun 30 2018 at 09:12):
In our case, Resource can be updated several times in a short period of time. It is convenient to take only the latest version.
Our product is a broker (dispatcher) of diagnostic requests between clinics and laboratories. Our main subscriptions are subscriptions to ProcedureRequest (ServiceRequest), Task and DiagnosticReport.
And the main problem is DiagnosticReport subscriptions. DiagnosticReport can contain "presentedForm" with base64 encoded resource so it can be large. And also DiagnosticReport can be updated several times in a short period of time because of laboratory uploads some new presentedForms. The clinic could not solve this issue with search criteria because all this DiagnosticReports have the same status "partial". So usually clinic waits for about 10 minutes and aggregates "id" of Resources which was updated and loads them after.
We can use the Profile to restrict using base64 encoded values in Attachments and force them to use links to Binary but it will take time. Anyway, it is not permitted by the standard to use our current approach.
And one more question, what was the initial purpose of using subscriptions without payload, maybe I'm missing some case?
Alexander Ivanov (Jun 30 2018 at 09:17):
Maybe @Aleksandr Sorokin can tell more about the logic behind frequent updates of DiagnosticReport and receiving results by clinic.
Grahame Grieve (Jun 30 2018 at 12:38):
initial purpose was very simple, supporting mobile apps
Grahame Grieve (Jun 30 2018 at 12:38):
you've certainly explained the use case. I'm wondering whether you want just the id, or the version id too?
Aleksandr Sorokin (Jun 30 2018 at 13:34):
I think the version id will be redundant because clients are usually interested in the latest version or may get version history if needed, but @Alexander Ivanov may have an another opinion
Alexander Ivanov (Jun 30 2018 at 13:40):
None of our clients asked for version, so I think the only "id" field is fine.
Last updated: Apr 12 2022 at 19:14 UTC
