Stream: subscriptions
Topic: Setting up Subscriptions
Rishi Tarar (Apr 11 2018 at 16:04):
Trying to set a FHIR Subscription test for certain resources.
We used the HAPI FHIR JPA from https://hub.docker.com/r/polyakov/hapi-fhir-jpaserver-example/
When creating subscriptions, they are always set to "Requested" status.
1. How do I enable the subscription to active?
2. Where do I configure the email SMTP details?
Any ideas?
Grahame Grieve (Apr 11 2018 at 16:07):
@James Agnew
James Agnew (Apr 18 2018 at 15:53):
Hi @Rishi Tarar ,
Sorry for the slow reply! Subscriptions are set up in HAPI FHIR JPA using interceptors, one per channel type. See subclasses of BaseSubscriptionInterceptor to see them: http://hapifhir.io/apidocs-jpaserver/ca/uhn/fhir/jpa/subscription/BaseSubscriptionInterceptor.html
You'd use SubscriptionEmailInterceptor for email, and that class has all of the configuration around delivery.
Anusha (Apr 25 2018 at 10:17):
Hello All,
Looking through the Subscriptions in the 3.x.x of RestHook channel type,
Where I have created Subscription resource and given the criteria ex, "Observation?status=registered" and endpoint.
According to my Understanding when there is a change in Observation Resource in status(criteria given in subscription). We need to get notification
to the Endpoint given.
When i updated the Observation staus other than "registered",in the console iam viewing this info
Subscription check found 0 results for query: Observation?status=registered&_id=Observation/753
And i have no idea in what format Notification will be how can we knew it.
DO we need to enable any Configurations? or iam in the correct way of understanding only.
Thank You
Grahame Grieve (Apr 25 2018 at 12:39):
which server are you testing against?
Grahame Grieve (Apr 25 2018 at 12:39):
and what status does it have for your subscription?
Christiaan Knaap (Apr 25 2018 at 12:45):
Your understanding of the criteria is not entirely correct.
"Observation?status=registered" means: send me a notification for any create or update of an Observation that has status 'registered'.
So if you change the status to something else than 'registered', the Observation will no longer match the criteria and you will not be notified.
You cannot have a subscription for changes to a specific property of an Observation.
Grahame Grieve (Apr 25 2018 at 12:49):
we are trailing a subscription criteria that can do that, but I'm not sure which servers support that
Christiaan Knaap (Apr 25 2018 at 13:03):
I must have missed that. Where can I find a description of this functionality?
Grahame Grieve (Apr 25 2018 at 13:33):
I think the San Diego connectathon
Grahame Grieve (Apr 25 2018 at 13:33):
there was a subscription stream
Christiaan Knaap (Apr 25 2018 at 13:41):
I think you are referring to the use of EventDefinition in conjunction with Subscription, as stated under EventDefinition: "The EventDefinition resource is intended to be used to provide a reusable description of events for use by other resources that require event definition, such as Subscription. EventDefinition is a definition of an event that could occur, whereas Subscription is asking for notification of events when they occur." (http://build.fhir.org/eventdefinition.html).
However, this has not found it's way into Subscription itself yet.
Grahame Grieve (Apr 25 2018 at 21:36):
no the connectathon stream only defined an extension and has not moved beyond that
Anusha (Apr 26 2018 at 05:05):
@Christiaan Knaap
Thanks for correcting me.
Anusha (Apr 26 2018 at 12:18):
@Grahame Grieve
hapi fhir server
and subscription status is requested
Anusha (Apr 27 2018 at 13:06):
Hi All,
Iam little bit confused some of the lines in subscription documentation,
When a resource is created or updated that meets the criteria, the server sends a POST request with no body to the nominated URL.
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.
what it mean by it re-issues the criteria as a query to the server?
please help me in understanding the above.
Grahame Grieve (Apr 27 2018 at 23:56):
in this case, where the server is sending pings without any details, then the only way for the subscriber to get the details is to ask the server (re-issue the query).
Rishi Tarar (Apr 30 2018 at 20:48):
(deleted)
Anusha (May 03 2018 at 07:08):
Hi All,
Iam working on Subscription with Resthook channel type of hapi-fhir V3.2.0, where iam getting error log as "Failure to handle Subscription payload" and
at the subscriber side Iam receiving that " No mapping found for HTTP request with URI [/hapi-fhir-jpaserver-example/Patient/102] in DispatcherServlet with name 'spring'".
Can anyone help me out with the issue.
Christiaan Knaap (May 03 2018 at 11:29):
You may find more support on the #hapi stream for this
Justin (Jul 25 2018 at 12:53):
Hey guys,
I am very new to all of the Fhir and HL7 spaces but I am working on an app that a Fhir Subscription model will work great on but am having some issues/questions:
1. I know the Fhir Server can go to a Rest-Hook service (like a C# .asmx project) but in what format does that message come? 2. Is there a way to add more than 1 criteria to the same Subscription entry? (I want to know about Encounters that happen with a Status of Planned, Finished, and In-Progress 3. What kind of sandbox instances can i get started with to see if my .asmx project can receive these messages?
Thank you in advance!
Justin
Christiaan Knaap (Jul 25 2018 at 14:38):
1. Is answered in http://hl7.org/fhir/subscription.html#2.46.6.1
2. Criteria are expressed in the FHIR API Search framework, see the choice construction in the second paragraph of http://hl7.org/fhir/search.html#combining
3. One of the public test servers (see here) but it is also very easy to setup a local Vonk test server.
Justin (Jul 25 2018 at 14:57):
Thanks for the answer!
So what do I need to add to the Subscription to request the entire resource be sent to my endpoint?
Also, I see the combining, but can we use "or" statements instead of "and" so we want Encounters with a Status of Planned OR Arrived OR Finished?
Justin (Jul 25 2018 at 17:28):
Also, how do you import a Subscription Resource into a Fhir server?
Rishi Tarar (Aug 01 2018 at 01:55):
@Christiaan Knaap @James Agnew
I am using the HAPI FHIR Server and a custom CQF Ruler as a call back endpoint for my CDS Service.
I dea is to fire a subscription via a rest hook to ship resources of interest to be evaluated by CDS Service.
So my Subscription looks like this
{
"resourceType": "Subscription",
"status": "active",
"end": "2018-12-20T13:27:56.202+05:30",
"reason": "Detect New Discharge",
"criteria": "Encounter?status=finished",
"channel": {
"type":"rest-hook" ,
"endpoint": "https:/blah.com/clinicDecision/cds/stroke",
"payload": "application/fhir+json"
}
}
So when I create an Encounter with status=finished with ID:4622205, I do get a call back but it looks like this .. so rest hook is working(see entry below from logs in CDS service).
info method=PUT path="/clinicDecision/cds/stroke/Encounter/4622205" host=blah.com request_id=4a65aa71-f673-4551-aaa4-efaa1be815af fwd="104.154.163.222" dyno=web.1 connect=1ms service=669ms status=404 bytes=310 protocol=https
Notice the URL /clinicDecision/cds/stroke/Encounter/4622205 for the call back URL. It appears the FHIR server is appending the newly created resource to the callback URL.
I thought I would get a bundle or a specific Encounter Resource in the payload.
I have tried create , update of the Encounter resource.
I am not sure if this expected behaviour or a bug or I may be doing something wrong.
-R
Christiaan Knaap (Aug 01 2018 at 08:49):
I don't know what happens in HAPI, but have you also tried this in Vonk to check whether an error may be on your side on on the HAPI side?
Please note that in Vonk you have to post your Subscription to the administration API: POST http://vonk.fire.ly/administration/Subscription, and then your Encounter to the regular endpoint: POST http://vonk.fire.ly/Encounter.
Rishi Tarar (Aug 01 2018 at 11:47):
@Christiaan Knaap @James Agnew
Thank you.
Tested it with Vonk and Subscriptions fire to the callback rest hook endpoint. It works as expected on Vonk. It probbably is a bug in HAPI.
It is also interesting to note that Vonk rest-hook callbacks are POST and HAPI is PUT.
{"resourceType":"Encounter","id":"c6831b8e-bac5-4dee-b0f1-172761204f56","meta":{"versionId":"6d1f1379-4c78-4acb-bea5-a2a65a4d3fc1","lastUpdated":"2018-08-01T11:41:49.369+00:00"},"status":"finished","class":{"system":"http://hl7.org/fhir/encounter-class","code":"inpatient","display":"Inpatient"},"subject":{"reference":"Patient/934740","display":"Bunny Bugs "},"period":{"start":"2000-08-21T11:56:23.000+05:30"}}
Christiaan Knaap (Aug 01 2018 at 11:50):
Thanks for testing.
On the latter point HAPI is more correct, since the spec specifies that it has to be an Update operations (ie PUT)
James Agnew (Aug 01 2018 at 16:54):
HAPI is treating the endpoint as the base URL of a FHIR REST endpoint, which is why it adds the resource type and ID to it.
I could swear that was more explicit in the spec at some point, but at this point it doesn't seem like it is. I know lots of people rely on this behaviour though to use the rest-hook mechanism for replication.
Maybe it should be configurable...
Jens Villadsen (Sep 05 2018 at 08:46):
Subscriptions in the standard still lack the functionality to ship the immediate evaluation of the criteria once created, right? Am I the only one that sees that as a problem?
Grahame Grieve (Sep 05 2018 at 13:08):
what does 'ship the immediate evaluation of the criteria once created' mean?
Jens Villadsen (Sep 05 2018 at 19:02):
Its the case I presented during a BoF on Subscriptions at DevDays '17. The case is today:
Step 1) Client issues a query against the server in order to obtain the current state
Step 2000) Client creates a subscription at the server with the same query used in step 1
That's what the current spec says
Jens Villadsen (Sep 05 2018 at 19:04):
Anything can happen in between Step 1 and Step 2000. Being the state the client thought was the correct and the state where the client starts to get updates from the subscription
Jens Villadsen (Sep 05 2018 at 19:05):
What I suggest is that you cut away step 1 - it does not make sense
Jens Villadsen (Sep 05 2018 at 19:06):
Instead, once a subscription is created, the criteria should be evaluated at once and the result should be sent to the client on the means specified in the subscription
Jens Villadsen (Sep 05 2018 at 19:06):
so that is "ship the immediate evaluation of the criteria once created"
Jens Villadsen (Sep 05 2018 at 19:08):
@Grahame Grieve
John Moehrke (Sep 05 2018 at 21:16):
It depends on the method used by the Client to get updates. Where for example with websockets the client just gets a ping; therefore the client must remember the timestamp it last used in previous query. Thus it is often helpful to do all the queries up to NOW, then start the subscription., do one more, then wait for a ping.
John Moehrke (Sep 05 2018 at 21:19):
a very different use of subscription, that I worked on a prototype, is as an async API to XCA environment. In that case there is nothing to find prior to the subscription, as the subscription is what kicks off the XCA FindDocuments queries to ALL partners on the network. As results come back on the XCA queries, a notification is given to the client, so that the client can then go get everything starting from last time it queried, which for the first time is time zero.
Grahame Grieve (Sep 05 2018 at 21:59):
why not create the subscription, then do the query?
Jens Villadsen (Sep 06 2018 at 07:04):
doesn't that put a certain amount of logic into the client that ain't necessarily consistent across client implementations?
Jens Villadsen (Sep 06 2018 at 07:12):
I admit that I cannot directly see the case for my suggestion on "eager evaluation" when payload is not part of the notifications
Jens Villadsen (Sep 06 2018 at 07:16):
But when payload is wanted, I can't see any reason for not doing eager evaluation. It places the responsibility at a central place
Jens Villadsen (Sep 06 2018 at 07:32):
Thereby providing some consistency to what can be expected
Grahame Grieve (Sep 10 2018 at 20:47):
the initial load could be very large
John Moehrke (Sep 10 2018 at 21:07):
Isn't the client the only one that can know what that initial load is? Let me explain, the server can only know what NEW has happened. The server can't know what else the client is interested in. Thus the client is the only one that can know how deep into history it needs to go. If the client has no interest in history, just NEW, then the client does nothing. right?
Grahame Grieve (Sep 10 2018 at 22:50):
that's what I think, yes
Sahil Khanna (Sep 18 2018 at 11:54):
@Rishi Tarar , did you enable anything for subscription on HAPI FHIR Test server? I followed your steps, but i didnt receive any response back for the update in subscribed resources.. Please advise.
Jens Villadsen (Sep 24 2018 at 21:32):
that's what I think, yes
@John Moehrke What you describe as the initial load is executed anyways - by the client at first 'encounter' with the server.
Last updated: Apr 12 2022 at 19:14 UTC
