Stream: subscriptions
Topic: Fhirpath triggers
Josh Mandel (Sep 10 2020 at 13:36):
Many of the people I've talked with feel the computational load for search and FHIRPath based topics is too high to be supported. Many are expecting to have thousands or tens of thousands of subscriptions simultaneously and want to maintain a reasonable response time (<5 minutes).
David, are you saying you want to remove this from the definitions, or just saying that you don't expect some servers to support it? in general servers choose which topics to support and a server that does not want to support any topics based on fhirpath do not need to. it's also worth noting that a server might support specific highly optimized expressions and not others; there is no expectation that a server needs to support generic topic definitions dynamically at runtime.
Josh Mandel (Sep 10 2020 at 13:42):
@David Pyke Discovery of support for specific topics would be by searching the server for topics available.
If you're thinking about ways to discover proactively whether a server will accept a specific topic that you try to post to it... right now we have a way for a server to say you can post a new topics or you can't. I don't know that modeling the details beyond that is going to be very helpful -- but of course fhir Capability Statements let you specify a list of profiles for any resource type if you want to go that route. (I don't think we would have to do something specific in subscriptions.)
David Pyke (Sep 10 2020 at 13:50):
I think we need to have a way of listing if you support dynamic or not, rather than what types of resources you can do dynamically.
David Pyke (Sep 10 2020 at 13:52):
It may end up needing a dynamic resource and a non-dynamic element on subscription. That way if you opt out of dynamic, you can just use a codelist/uri on Subscription and show that the dynamic based Topic resource being not supported
Jenni Syed (Sep 10 2020 at 14:59):
When you say support dynamic... is that essentially equivalent to advertising support of SubscriptionTopic create in conformance? Or are you looking more specifically at how flexible those can be (which may be, to Josh's point, advertising profiles of SubscriptionTopic?)
David Pyke (Sep 10 2020 at 15:03):
I'm thinking advertising support of SubscriptionTopic. Those that don't support that can use a codelist/uri
Jenni Syed (Sep 10 2020 at 15:04):
For R5, SubscriptionTopic is required. In R4, there's a query for "known" uris for the patch back
Jenni Syed (Sep 10 2020 at 15:04):
the fully dynamic query is one thing we specifically dropped from R5 because of performance concerns
Jenni Syed (Sep 10 2020 at 15:04):
So it's declaration of "I only support the R5 back port profile of Subscription" maybe...
David Pyke (Sep 10 2020 at 15:05):
Right, so I'm suggesting that SubscriptionTopic get moved to optional and Subscription gains a Topic element. SubscriptionTopic gets all search and FHIRPath capabilites
Jenni Syed (Sep 10 2020 at 15:06):
I'm not sure I'm following
David Pyke (Sep 10 2020 at 15:08):
Subscripton's link to SubscriptionTopic becomes 0..1 and gains topicCode or topicUri 0..* SubscriptionTopic has all search based or FHIRPath based capabilities.
David Pyke (Sep 10 2020 at 15:08):
Possibly with a invariant that forces either a reference to SubscriptionTopic or a topicCode/Uri to have an entry
Josh Mandel (Sep 10 2020 at 15:21):
What would this accomplish? Currently every SubscriptionTopic has a canonical URI and you can use that just the way you'd use the "topicUri" you're proposing -- but the canonical URLs are better because you can also optionally make them resolve, document behaviors, authorship, relation to other topics, etc.
David Pyke (Sep 10 2020 at 15:23):
It gives a simple implementation path for systems that don't need/want to have those capabilities
Josh Mandel (Sep 10 2020 at 15:24):
It's no simpler: if you have a "topicUri", just consider that as a SubscriptionTopic.url (canonical URL). You don't need to make it resolve or anything.
Josh Mandel (Sep 10 2020 at 15:24):
For example, http://build.fhir.org/subscriptionstatus-definitions.html#SubscriptionStatus.topic is just a canonical reference.
David Pyke (Sep 10 2020 at 15:24):
But with my changes, you don't have to implement the SubscriptionTopic resource
Josh Mandel (Sep 10 2020 at 15:25):
You shouldn't have to anyway.
David Pyke (Sep 10 2020 at 15:25):
You do if it's required for the Subscription resource
Josh Mandel (Sep 10 2020 at 15:25):
You're referring to http://build.fhir.org/subscription-definitions.html#Subscription.topic ?
Jenni Syed (Sep 10 2020 at 15:25):
It could be contained, but you will lose the capability for people to discover what topics you allow
David Pyke (Sep 10 2020 at 15:26):
Yes
Jenni Syed (Sep 10 2020 at 15:26):
which was why we did this - it follows pub/sub patterns outside of FHIR
Jenni Syed (Sep 10 2020 at 15:26):
that lack of capability to discover was a big deal
Josh Mandel (Sep 10 2020 at 15:26):
I actually don't remember why http://build.fhir.org/subscription-definitions.html#Subscription.topic can't be a canonical reference. Jenni, do you?
Josh Mandel (Sep 10 2020 at 15:26):
Agreed that a first-class discovery API to ask a server about topics is super helpful!
Jenni Syed (Sep 10 2020 at 15:26):
Discovery
Jenni Syed (Sep 10 2020 at 15:26):
was the main reason
David Pyke (Sep 10 2020 at 15:26):
Being able to discover a codelist would be just as good, in my mind
Josh Mandel (Sep 10 2020 at 15:27):
Using a canonical at http://build.fhir.org/subscription-definitions.html#Subscription.topic wouldn't prevent discovery.
Josh Mandel (Sep 10 2020 at 15:27):
i.e. a client could always ask the server "which topics do you support" and the server can choose to respond. That's distinct from whether a server-local reference is required within Subscription.topic.
Josh Mandel (Sep 10 2020 at 15:28):
In any case, I don't see any "simplification" from offering multiple ways to do this @David Pyke
Jenni Syed (Sep 10 2020 at 15:28):
How would they ask what is supported with the canonical reference?
David Pyke (Sep 10 2020 at 15:30):
Witha topicCode element in Subscription, they can not implement the SubscriptionTopic resource, mark the CapabilityStatement with a lack of support for it (eliminating dynamics) and then pull the codelist for supported codes and their meanings
David Pyke (Sep 10 2020 at 15:31):
If we have an HL7 defined list of basic supported codes (extensible), that makes it even easier to support
Josh Mandel (Sep 10 2020 at 15:31):
How would they ask what is supported with the canonical reference?
GET /SubscriptionTopic, just like today if the server wants to support it. But yeah, I don't actually understand the underlying pain point here.
Josh Mandel (Sep 10 2020 at 15:32):
then pull the codelist for supported codes
This is a new API, right? That means ... another additional discovery mechanism.
Josh Mandel (Sep 10 2020 at 15:32):
Why is it easier to host that one vs hosting a fixed list of SubscriptionTopics?
Josh Mandel (Sep 10 2020 at 15:32):
I think there's something I'm missing.
David Pyke (Sep 10 2020 at 15:33):
IF you can have a fixed list of SubscriptionTopics and list them and be able to show a lack of search or FHIRpath based topics, then the problem isn't difficult
Josh Mandel (Sep 10 2020 at 15:44):
If you have a fixed list, I'm not sure what it means to "be able to show a lack of search or FHIRpath based topics" -- you'd just have a fixed list, and presumably the items on it wouldn't be fhirpath-based topics.
David Pyke (Sep 10 2020 at 15:50):
Good point.
Gino Canessa (Sep 10 2020 at 15:55):
Jumping back a bit to the canonical question (Josh), we discussed it somewhat recently. The discussion ended with:
- the client needs to have access to a
SubscriptionTopicresource - if we allow canonicals, servers may not keep a definition copy locally
David Pyke (Sep 10 2020 at 16:09):
Okay, so if canonicals are not appropriate, I'd like to go back to must suggestion
Vassil Peytchev (Sep 10 2020 at 16:12):
I am not sure I understand this part:
the client needs to have access to a
SubscriptionTopicresource
Why is that? Josh was just saying that resolving the canonical was not necessary.
Josh Mandel (Sep 10 2020 at 16:21):
Right now, a client creating a Subscription needs to populate Subscrition.topic with some kind of valid reference. We generally expect that'll be a server-local FHIR reference like {"reference": "SubscriptionTopic/891247142"} but in theory it could be a canonical URL based reference like {"reference": "https://argo.run/example-topics/admission"}, if a server chooses to allow this.
Josh Mandel (Sep 10 2020 at 16:23):
... but either way, the client wants some way to know which topics it'll be allowed to subscribe to, which is to say some discovery mechanism. And this means it's really most convenient if the server supports enumeration of its SubscriptionTopics via "GET /SubscriptionTopic". (A server could maybe just say "discovery is out of band, don't ask me about SubscriptionTopics," but I don't hear anyone advocating for that as a good practice :-))
Grahame Grieve (Sep 10 2020 at 16:25):
I would prefer that topic is a canonical(SubscriptionTopic) not a Reference(SubscriptionTopic); I haven't followed the issue why it shouldn't be. And @David Pyke I haven't understand what you're trying to achieve at all
David Pyke (Sep 10 2020 at 16:27):
I'm trying to achieve a subscription system that uses a fixed codelist of specific events
Grahame Grieve (Sep 10 2020 at 16:27):
but that's already how it works, if you want - a fixed list of specific topics
David Pyke (Sep 10 2020 at 16:30):
Okay, then I'm completely stumped where such a code is entered.
David Pyke (Sep 10 2020 at 16:31):
Subscription points to SubscriptionTopic which has a resourceTrigger
David Pyke (Sep 10 2020 at 16:32):
SubscriptionTopic has a canonical to another SubscriptionTopic that it's derived from
Grahame Grieve (Sep 10 2020 at 16:33):
"such a code" - what kind of code?
David Pyke (Sep 10 2020 at 16:33):
A code list "admit" that says trigger when an admission for patientX happens
Grahame Grieve (Sep 10 2020 at 16:34):
That's what the topic is
David Pyke (Sep 10 2020 at 16:41):
Okay, I'm obviously not getting this. how do you express "Trigger when PatientX is admitted" without having to use search or FHIRPath logic?
Grahame Grieve (Sep 10 2020 at 16:44):
I don't know. How do you express that without saying what it actually means?
Grahame Grieve (Sep 10 2020 at 16:44):
I think what you want is for some magic to happen somewhere where by you can say what you want without defining how it happens
Grahame Grieve (Sep 10 2020 at 16:45):
for me, this is what derivedFrom is about.
David Pyke (Sep 10 2020 at 16:45):
Personally, I'd like a subscription that has a link to a patient and a codelist that has "admit" as one of the codes. In the back end, there would be something processing the codes and handling this. There is a blackbox attribute to it but I have a number of people wanting this.
David Pyke (Sep 10 2020 at 16:46):
Having to use search or FHIRPath logic is seen as too computationally expensive
Grahame Grieve (Sep 10 2020 at 16:47):
HL7 can define a base list of topics, which correspond to widely supported events. We publish formally correct definitions of them, both in narrative and using search/fhirpath. Because they are well known definitions, people can treat them as magic, ignore the formal definitions, and implement them as they want in their system.
Then they can advertise HL7's well known definitions as 'the ones they support'
David Pyke (Sep 10 2020 at 16:47):
That works for me. AS long as there's a fixed list somewhere
Grahame Grieve (Sep 10 2020 at 16:48):
because of course people won't necessarily implement using search or FHIRPath.
Grahame Grieve (Sep 10 2020 at 16:48):
but it does mean that someone has to do the work to define them.
Grahame Grieve (Sep 10 2020 at 16:49):
they can even advertise their variations in support for the underlying topic, but still link back to the base topic using derivedFrom
David Pyke (Sep 10 2020 at 16:49):
I have a base list that I'm using for Carequality that we could translate
Grahame Grieve (Sep 10 2020 at 16:49):
this, btw, is why I think it's clearer for it to be a canonical()
David Pyke (Sep 10 2020 at 16:52):
Personally, I think a codelist and patient reference are simpler but that's me
Grahame Grieve (Sep 10 2020 at 16:54):
handling fewer requirements is always simpler. Doesn't make it better
Grahame Grieve (Sep 10 2020 at 16:55):
I think that a Subscription
topic = http://carequality.org/SubscriptionTopic/Admit
filterBy
searchParamName = patient
searchModifier = =
value = "X"
seems pretty straight foward
Jenni Syed (Sep 10 2020 at 16:56):
BTW, the way you advertise that canonical on the SubscriptionTopic today is via the url & derivedFrom fields
Jenni Syed (Sep 10 2020 at 16:57):
(that the topic is a reference to another canonical)
Grahame Grieve (Sep 10 2020 at 16:58):
But @Gino Canessa it would be more align with FHIR elsewhere for it to be :
topic = http://carequality.org/SubscriptionTopic/Admit
filterBy
parameter = patient
op = =
value = "X"
Because there's no actual requirement that the parameter be a search parameter - it can be just a parameter that you can filter by as defined in the topic
Jenni Syed (Sep 10 2020 at 16:58):
But Grahame's example is also valid as tht still references a SubscriptionTopic
David Pyke (Sep 10 2020 at 16:58):
That works
Gino Canessa (Sep 10 2020 at 16:59):
Making it canonical means that sometimes a client will be able to get a definitional resource (for checking things like allowed filters) and sometimes it won't. For specific use cases, this is fine. For generic clients, this is problematic.
At the end of the day, I'm fine with either - just relaying the last round of discussions on the topic.
Jenni Syed (Sep 10 2020 at 16:59):
@Grahame Grieve for "discovery" - would you still expect it to be listed in a SubscriptionTopic search or would it just be a profile advertised?
Grahame Grieve (Sep 10 2020 at 17:00):
Jenni, I'm not sure the difference you're drawing there, maybe because I don't know what you mean by 'profile advertised"
And Gino, why would it make any difference?
Jenni Syed (Sep 10 2020 at 17:00):
The way a client discovers what they can subscribe to today is by search on SubscriptionTopic
Grahame Grieve (Sep 10 2020 at 17:00):
a reference or a canonical can be unresolvable
Jenni Syed (Sep 10 2020 at 17:00):
they can search by canonical
Grahame Grieve (Sep 10 2020 at 17:01):
I thought it was GET [base]/Subscription/$topic-list
Jenni Syed (Sep 10 2020 at 17:01):
that's in patch back
Jenni Syed (Sep 10 2020 at 17:01):
in R5, SubscriptionTopic is its own resource
Jenni Syed (Sep 10 2020 at 17:02):
So it's GET /SubscriptionTopic
Grahame Grieve (Sep 10 2020 at 17:03):
well, either way. if you search SubscriptionTopic, you'll get a list of topics. These might have carequality or hl7 canonical urls, or your own ones with derivations to the carequality or hl7 ones, or they might just be your own ones
Jenni Syed (Sep 10 2020 at 17:03):
It does look like it would work as the only required fields are the url and status
Gino Canessa (Sep 10 2020 at 17:05):
Grahame Grieve said:
But Gino Canessa it would be more align with FHIR elsewhere for it to be :
topic = http://carequality.org/SubscriptionTopic/Admit filterBy parameter = patient op = = value = "X"Because there's no actual requirement that the parameter be a search parameter - it can be just a parameter that you can filter by as defined in the topic
We don't have a mechanism for defining parameters like that, so we were using search parameters. If we want to open that up, we need to add content around how to describe them.
Jenni Syed (Sep 10 2020 at 17:05):
could that be as simple as a text description or would you need fhirpath?
Grahame Grieve (Sep 10 2020 at 17:07):
We don't have a mechanism for defining parameters like that
What is SubscriptionTopic.canFilterBy but a mechanism for that. I suppose that if you wanted to define your own, you'd really need a canonical(SearchParameter) to formally define it as well as the name
Grahame Grieve (Sep 10 2020 at 17:07):
Jenni - not sure what the context of that is?
Jenni Syed (Sep 10 2020 at 17:20):
Proposal for the method to define instead of SearchParameter reference :)
Grahame Grieve (Sep 10 2020 at 17:22):
the computable definition parts are optional
Grahame Grieve (Sep 10 2020 at 17:30):
@Gino Canessa on the subject of String vs Canonical, the backport has something else again: uri
Grahame Grieve (Sep 10 2020 at 17:31):
but that aligns with canonical, I guess
Gino Canessa (Sep 10 2020 at 17:47):
Grahame Grieve said:
the computable definition parts are optional
The part of interest was the canFilterBy fields, IIRC. It just means a developer needs to know what filters are allowed out-of-band if the canonical doesn't resolve. Not terrible, just needs to be documented.
Last updated: Apr 12 2022 at 19:14 UTC
