Stream: subscriptions
Topic: Subscription Question
Grahame Grieve (Sep 12 2018 at 09:16):
See http://community.fhir.org/t/fhir-resource-subscription/958
Grahame Grieve (Sep 12 2018 at 09:16):
I don't believe that we've ever had any discussion on the subject, but I believe that we do not say that it's ok to put this in a subscription:
Grahame Grieve (Sep 12 2018 at 09:16):
“criteria”: “Patient/9/$everything?_lastUpdated=gt2018-09-05T11:02:59.777+05:30”,
Grahame Grieve (Sep 12 2018 at 09:17):
And I think we'd need to say it... but it seems to me that this is pretty typical thing to want to do.
Grahame Grieve (Sep 12 2018 at 09:17):
anyone have any comment?
John Moehrke (Sep 12 2018 at 15:21):
what is wrong with that subscription request? I could understand a server not liking (being able to support) all possible subscription criteria. This does indeed look difficult, but not hard enough to forbid.
Sahil Khanna (Sep 12 2018 at 16:46):
Hi Guys..
I am not sure what is the issue with that subscription request.
“criteria”: “Patient/9/$everything?_lastUpdated=gt2018-09-05T11:02:59.777+05:30”,
Even when i am trying to subscribe a particulare resource i am getting a new subscription resource created in my HAPI server.. but when i am updating a new resource.. i am not getting any response back
Sahil Khanna (Sep 12 2018 at 16:48):
i am using below subscription request :
{
"resourceType": "Subscription",
"id": "112233",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"></div>"
},
"status": "requested",
"contact": [
{
"system": "phone",
"value": "ext 4123"
}
],
"end": "2021-01-01T00:00:00Z",
"reason": "Testing subscription",
"criteria": "Encounter?_lastUpdated=gt2018-08-13T10:57:55.982+05:30",
"channel": {
"type": "rest-hook",
"endpoint": "http://localhost:1962/fhir/subscription/poc",
"payload": "application/fhir+json",
"header": [
"Authorization: Bearer secret-token-abc-123"
]
},
"tag": [
{
"system": "http://example.org/fhir/cs/internal",
"code": "bili-done"
}
]
}
Christiaan Knaap (Sep 12 2018 at 19:14):
Spec says "The criteria are Search strings", and $everything is an operation, not a Search string.
Christiaan Knaap (Sep 12 2018 at 19:20):
But if you leave out the /$everything you state roughly the same by doing a compartment search that would be valid according to the current wording though. Still not sure if it is wise to allow it.
Grahame Grieve (Sep 12 2018 at 22:33):
$everything is an operation
yes that is the issue here
Grahame Grieve (Sep 12 2018 at 22:33):
compartment search: /Patient/2345/*
Grahame Grieve (Sep 12 2018 at 22:34):
I don't know whether my server supports that
Kurt Ericson (Sep 12 2018 at 23:35):
Just wanted to chime in to say although we (GCP) don't yet support that type of Subscription; it's a sufficiently common feature request that I think it should be allowed, even if different services decide whether or not they want to support it
Grahame Grieve (Sep 13 2018 at 00:07):
which type?
Kurt Ericson (Sep 13 2018 at 01:02):
e.g. /Patient/2345/* and, potentially, modified by a timestamp (in the example: ?_lastUpdated=gt2018-09-05T11:02:59.777+05:30”)
Grahame Grieve (Sep 13 2018 at 02:01):
I'll add it to my list
Kurt Ericson (Sep 13 2018 at 03:19):
sounds good; thanks!
Isaac Vetter (Sep 13 2018 at 04:01):
Hey Guys,
I see the transfer of a patient chart as a solved problem with XCA and Direct. In the US, we've got even networks of networks.
The potential value of FHIR Subscriptions is in targeted criteria, not
“criteria”: “Patient/9/$everything?_lastUpdated=gt2018-09-05T11:02:59.777+05:30”,
but rather:
“criteria”: “Observation?patient=123&category=laboratory”,
and
“criteria”: “Practitioner/456”,
or even
“criteria”: “MeasureReport/789”,
Grahame Grieve (Sep 13 2018 at 04:06):
@Isaac Vetter there's no evidence yet that this question is a US specific questino
Isaac Vetter (Sep 13 2018 at 04:07):
You're right.
Kurt Ericson (Sep 13 2018 at 04:31):
that's true -- the intent here is a global audience; to be clear, I certainly see the argument for servers NOT wanting to implement it and I don't disagree with those decisions; rather, I wanted to make the point that I think we should be open to patterns that developers want for their workloads, even if certain markets have other ways of dealing with similar transactions
Christiaan Knaap (Sep 13 2018 at 05:06):
Besides the /*, adding _lastUpdated to the subscription criteria seems superfluous in most cases. The Subscription is not evaluated before its creation anyway. So adding _lastUpdated is only useful if you want to subscribe to changes starting some time in the future.
Sahil Khanna (Sep 13 2018 at 12:54):
That is the correct assumption. The requirement is such that they need auto triggering of all updated resources after a particular time interval. So that is why i was $everything in my search criteria.
I am not even sure if the HAPI server i am using will support my search criteria, but $ everything is working fine expect this test case for subscription.
Any other way we can subscribe all resources with one subscription request. I tried using this "/Patient/2345/*" syntax but still it is not working. It can be a scenario that my server does not support this request.
Kurt Ericson (Sep 13 2018 at 13:28):
@Christiaan Knaap that's right; the cases I'm thinking of are for pre-admits to inpatient settings
Sahil Khanna (Sep 20 2018 at 09:03):
@Grahame Grieve @James Agnew can you please advise why i am not getting any response back from HAPI/VONK FHIR server for any update in the subscribed resources. This is what i am doing..
Using below JSON sample i am subscribing the resource..
{
"resourceType": "Subscription",
"status": "requested",
"end": "2018-12-20T13:27:56.202+05:30",
"reason": "Detect New Observation",
"criteria": "Observation?code=http://loinc.org|1975-2",
"channel": {
"type":"rest-hook",
"endpoint": "http://localhost:1962/fhir/subscription/poc",
"payload": "application/fhir+json"
}
}
Sahil Khanna (Sep 20 2018 at 09:04):
I can see that a new subscription resource is created in the FHIR server.
Then when i am sending a PUT request to update the observation, then i am not getting any response on the endpoint mentioned in the subscription resource. The endpoint is active on my Rhapsody application.
Sahil Khanna (Sep 20 2018 at 09:09):
Let me know if i am missing anything...
James Agnew (Sep 20 2018 at 09:20):
Does the subscription change status from requested to active automatically? If not, you probably haven'r registered the appropriate interceptor. in order to enable subscription support. See the demo project for an example of how to do that: https://github.com/hapifhir/hapi-fhir-jpaserver-starter
Sahil Khanna (Sep 20 2018 at 09:20):
@James Agnew .. the status is active. Do you think i am missing something?
Christiaan Knaap (Sep 20 2018 at 11:59):
@Sahil Khanna : As for Vonk: did you post it to the /administration/Subscription endpoint? (See doc)
Christiaan Knaap (Sep 20 2018 at 12:00):
NB: I discovered that accidentally the search on /administration/subscription is broken in version 0.7.2.1. Will be fixed soon. Create/read/update and delete do work, so if you remember the id from the create, you can still read it.
Sahil Khanna (Sep 20 2018 at 12:01):
@Christiaan Knaap Yes i posted it to <BaseURL>/administrator/Subscription, but still no luck.
Christiaan Knaap (Sep 20 2018 at 12:02):
On the public test server or an instance of your own?
Sahil Khanna (Sep 20 2018 at 12:03):
It is on the Public Test server
Christiaan Knaap (Sep 20 2018 at 12:07):
Do you happen to have the id that Vonk generated?
Sahil Khanna (Sep 20 2018 at 12:13):
I have sent you a private message so that you can help me with my issue.
Aziz Boxwala (Sep 20 2018 at 14:20):
@Sahil Khanna
I added the following subscription to hapi.fhir.org. I changed the end date to expire it earlier. I change the endpoint to a webhook test site. Note the "?" at the end of the url. That is a hack to change the path params to query params. Make sure your endpoint can accept the path param, which in your case will append "/Observation/<ResourceId>"
{
"resourceType": "Subscription",
"status": "requested",
"end": "2018-09-22T13:27:56.202+05:30",
"reason": "Detect New Observation",
"criteria": "Observation?code=http://loinc.org|1975-2",
"channel": {
"type":"rest-hook",
"endpoint": "https://webhook.site/0aaeb346-e17a-4b52-af7f-d9c214da0143?",
"payload": "application/fhir+json"
}
}
I then posted the following observation. You can see that the Observation was sent to the endpoint a few minutes ago from hapi.fhir.org by going here: https://webhook.site/#/0aaeb346-e17a-4b52-af7f-d9c214da0143/88dc911a-cc72-4077-88ab-6e89e38621ab/0
{
"resourceType": "Observation",
"status": "final",
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "1975-2"
}
]
},
"subject": {
"reference": "http://mypatients.example.com/Patient/123456"
},
"effectiveDateTime": "2018-09-20",
"valueQuantity": {
"value": 1
}
}
Sahil Khanna (Sep 20 2018 at 15:17):
thank you Aziz.. i think i followed the same steps.. but still let me double check.. i really appreciate that you sent me the steps you followed...
Sahil Khanna (Sep 20 2018 at 15:55):
@Aziz Boxwala ... it worked for me as well.. thank you for your help... the issue was with the network which was blocking the outside traffic.
Aziz Boxwala (Sep 20 2018 at 16:15):
:thumbs_up: You're welcome.
Marcelo caldas (Jan 13 2019 at 15:49):
Hi,
I'm trying to make my subscription work on my own instance of Hapi-fhir server (I'm running the hapi-fhir-jpaexample server).
I'm able to create my subscription and I see it as active, but my endpoint never receives any requests...
Currenlty, I'm at the connectathon-SanAntonio on the bulk data tables if anyone can stop by and help me out?!
thanks,
Marcelo caldas (Jan 13 2019 at 17:31):
ok... I got it working, but i feel I hacked my solution.
Basically, I was using type = rest-hook, which according to the spec, it expects a FHIR server on the other end - so I switched my endpoint to abide by a FHIR REST API, but it's not really a FHIR Server.
Because my criteria is Encounter?status=finished, HAPI was calling <endpoint> + /Encounter/{EncounterID}. Which makes total sense after reading the specs :-)
so my question is - what's the best way to use FHIR subscription when your endpoint is NOT a FHIR server! Just an app interested in data
Grahame Grieve (Jan 13 2019 at 21:10):
we haven't made arrangements for getting the data if you're not a FHIR server. You can say to just get a ping
Meghan Raul (Jan 14 2019 at 22:41):
ok... I got it working, but i feel I hacked my solution.
Basically, I was using type = rest-hook, which according to the spec, it expects a FHIR server on the other end - so I switched my endpoint to abide by a FHIR REST API, but it's not really a FHIR Server.
Because my criteria is Encounter?status=finished, HAPI was calling <endpoint> + /Encounter/{EncounterID}. Which makes total sense after reading the specs :-)so my question is - what's the best way to use FHIR subscription when your endpoint is NOT a FHIR server! Just an app interested in data
Hi Marcelo,
I was able to create a subscription from a client that was not a FHRI server using Cerner's sandbox: https://github.com/MaxPhilips/wgm_notes/blob/jan_2019/subscriptions/test_server_faq.md
Can you elaborate on the how you got a notification on <endpoint> + /Encounter/{EncounterID} ? With Cerner's sandbox I got a notification at the base url I specified
Reading the spec again, @Max Philips Should the request have come to my endpoint/Subscription ? like it states here : https://www.hl7.org/fhir/subscription.html#2.46.7.1
Max Philips (Jan 15 2019 at 16:49):
Based on my reading of the spec there are two cases: 1. Subscription.channel.payload is not present, this would be interpreted as the subscription wants to receive data corresponding to the criteria. POSTs in this case would go to /Encounter or /Observation, or whatever the subscription is for. 2. Subscription.channel.payload is present, this would be interpreted as the subscription wants a notification for its owner to re-query and pull new data.
In particular, for Cerner's connectathon server, we don't have different behaviors for those two scenarios - POSTs will always go to the endpoint as registered regardless of payload set or absent.
Marcelo caldas (Jan 17 2019 at 20:21):
HI @Meghan Raul - From what I read on the subscription specs, the endpoint of the subscription is treated as a ROOT url of a FHIR server - @Grahame Grieve confirmed that above as well. so, if my criteria is ,for example, for Observation and my endpoint is http://acme.com, the subscription when triggered will call http://acme.com/Observation/observation-id .
That being said, I've noticed that HAPI server and VONK have different implementations. Would love to hear from Firely guys on this. It seems to me that HAPI is following the specs as I understood them.
I think @Max Philips explained it well above, but I think is the opposite - if payload is present on my subscription, the entire contents are sent, otherwise - if payload is omitted - then only a "ping" will be sent and my server needs to query back the FHIR server that triggered the subscription, possibly with a _since filter to retrieve only records after my last ping.
Grahame Grieve (Jan 17 2019 at 23:25):
if a payload is missing, a ping will be sent to the nominated URL at the root
Grahame Grieve (Jan 17 2019 at 23:27):
if a payload is present, the resource will be posted or put to [root]/[Type]/[id] where type and id are of the resource that was changed (not the subscription resource)
Grahame Grieve (Jan 17 2019 at 23:27):
see http://hl7.org/fhir/subscription.html#2.46.7.1
Iryna Roy (Apr 10 2019 at 20:03):
Can I clarify please (building the subscription / notification process right now) - the payload of a notification may contain the resource type and id? Awesome if so. Can it contain a bundle of type/ids?
Grahame Grieve (Apr 10 2019 at 20:23):
if there's a payload, it's the resource (with, therefore, type and id). Or there's no payload. But no bundle, no - there's no support for batching up
Iryna Roy (Apr 10 2019 at 20:24):
Ok, so if multiple resources of a type were changed, then there are multiple notifications, right?
Grahame Grieve (Apr 10 2019 at 20:28):
yes
Last updated: Apr 12 2022 at 19:14 UTC
