Stream: implementers
Topic: Subscriptions and includes
Jens Villadsen (Oct 04 2018 at 08:41):
What does the event look like from a Subscription where payload is set and the criteria is eg. Encounter/?_include=Encounter:subject
Is it just the Encounter or is it a bundle with the Encounter and Patient(subject)?
Jens Villadsen (Oct 05 2018 at 15:13):
@Grahame Grieve ?
Grahame Grieve (Oct 05 2018 at 21:04):
yes
Jens Villadsen (Oct 08 2018 at 08:36):
@Grahame Grieve yes, as in the first or the last?
Grahame Grieve (Oct 08 2018 at 12:41):
yes
Grahame Grieve (Oct 08 2018 at 12:48):
actually, now that I read it carefully, I don't know. Ask on the subscriptions track
Brian Reinhold (Oct 08 2018 at 13:05):
actually, now that I read it carefully, I don't know. Ask on the subscriptions track
@Jens Villadsen I implemented a simple subscription where the payload was set and I got the resource in the notification. I don't know if that is your question, whether you get the Encounter resource or just a search string for it. Looking back at my code I am a little shocked that it worked as I look at the criteria and it is
subscription.setCriteria("Observation?patient=sisansarahId-1.2.3.4.5.6.7.8.10");
I would expect it to be
subscription.setCriteria("Observation?subject=sisansarahId-1.2.3.4.5.6.7.8.10");
Somehow it worked ...
Jens Villadsen (Oct 08 2018 at 13:27):
actually, now that I read it carefully, I don't know. Ask on the subscriptions track
@Jens Villadsen I implemented a simple subscription where the payload was set and I got the resource in the notification. I don't know if that is your question, whether you get the Encounter resource or just a search string for it. Looking back at my code I am a little shocked that it worked as I look at the criteria and it is
subscription.setCriteria("Observation?patient=sisansarahId-1.2.3.4.5.6.7.8.10");
I would expect it to be
subscription.setCriteria("Observation?subject=sisansarahId-1.2.3.4.5.6.7.8.10");
Somehow it worked ...
thats interesting ... lets continue on the subscription stream on "Subscription and includes"
John Moehrke (Oct 08 2018 at 13:37):
for a subscription, the server likely needs to be a bit more picky about 'unknown' parameters. right? with a REST query, ignoring an unknown parameter just affects one response. But ignoring an unknown parameter on a subscription can result in much more unwanted traffic.
Jens Villadsen (Oct 08 2018 at 13:39):
@John Moehrke - that sounds correct to me. Also, if it indeed is the case that one cannot use the include/revinclude parameters (and maybe other friends from http://build.fhir.org/search.html#Summary) perhaps the criteria definition on subscription should be sharpened a bit.
René Spronk (Oct 08 2018 at 14:18):
Historically we've always said (in v2 and v3) that a subscription uses the same format as a search (it is kind of a 'delayed/ongoing search') , so I'd expect that to be the starting point for FHIR unless one has a good reason to include exceptions.
John Moehrke (Oct 08 2018 at 14:25):
Format, I would agree. I am just thinking a warning to servers that they likely should be more strict because of this possibility. It would be an informative recommendation, not a normative requirement.
Michele Mottini (Oct 08 2018 at 15:12):
(deleted)
Grahame Grieve (Oct 08 2018 at 18:27):
Historically we've always said (in v2 and v3) that a subscription uses the same format as a search
@René Spronk interesting - where did we say that?
René Spronk (Oct 09 2018 at 07:16):
That's my recollection as an InM co-chair. Searching for references:
v2.7 section 5.7.1: Runtime subscription has existed in earlier versions of HL7, but little attention has been drawn to it. Original mode queries could define an open ended time interval in QRF-9-When quantity/timing qualifier. The unexplained semantics of this field had been interpreted to mean: If the QRF-9 specified an end time in the future, then the source system would keep sending results using the query continuation protocol.
In v3 the QueryByParameter class has this same kind of fuzzy implied subscription mechanism; the subscription mechanism has not been explicitely documented, although the word subscription is being used in the documentation.
As far as HL7 was concerned, a subscription is just a query, with a 'delayed' response period.
Jens Villadsen (Oct 09 2018 at 08:05):
@René Spronk Subscriptions cannot just be considered as a 'delayed' response period as it works continuously.
René Spronk (Oct 09 2018 at 10:11):
Sloppy wording perhaps - a normal query is "now", a subscription is a query that is executed "from now onwards up to point in time x".
René Spronk (Oct 09 2018 at 10:12):
Point being: subscription is a query like any others, only the timing differs
Jens Villadsen (Oct 09 2018 at 10:44):
@René Spronk if it is a query like any others - how should the criteria Encounter/?_include=Encounter:subject on a Subscription be handled?
René Spronk (Oct 09 2018 at 12:34):
The exact same way as it would be handled as a regular query. In other words: any (new) encounters, inclusive of their subject resources will be sent to the subscribing party as part of the subscription stream. So as a result of the subscription will be that you'll receive repetitive bursts each consisting of 2 resources. It's exactly what you asked for.
But again: it's up to FHIR to redefine this behaviour should it be desirable. This is just a response based on past behaviour of HL7 standards, but that doesn't mean one can't define it any other way if there are reasons to do so.
Angus Millar (Oct 28 2018 at 01:25):
I guess given the description @René Spronk that chain search parameters are also allowed? This makes the task a little more difficult as now a server must trigger the subscription searches on every server resource create/update, not just the create/update of the desired resource type.
For instance, criteria Observation.subject:Patient.organization.identifier=http//somesystem/for/org|ACME
For this I must trigger the subscription search on every create.update to the resources Observation, Patient and Organization.
Just looking for confirmation you agree. It feels rather different to a message subscription where you may just filter messages on topics as they pass through and push that message to a subscription if matched. Here we have to perform many searches very often. I'm guessing that is the case.
René Spronk (Oct 28 2018 at 09:10):
Yes - any URL that's a valid search expression can also be used as the basis for a subscription.
Last updated: Apr 12 2022 at 19:14 UTC
