Stream: subscriptions
Topic: what does the topic url return?
Eric Haas (Dec 31 2020 at 18:04):
it the backport IG it states:
In order to limit the scope of this Implementation Guide, SubscriptionTopic definitions are not defined here. Since topics are always referenced by their canonical URL, servers using FHIR R4 have no need to implement any of the functionality around topics themselves.
So what happens when one hits the canonical url. What gets returned exactly?
Eric Haas (Dec 31 2020 at 18:16):
in the test app it resolve to the argonaut page. I would expect it to resolve to some definition of the topic. ( registry somewhere? )
Eric Haas (Dec 31 2020 at 18:24):
The problem I am trying to solve is where to define what is returned ( a list of resources in addition to the target.) In R5 would be an extension to a List reference on the SubTopic. In R4 am unclear what the analog is?
Josh Mandel (Jan 04 2021 at 15:23):
Like all canonical URLs in FHIR , this SubscriptionTopic URL serves primarily as an identifier. A "best practice" is that it should dereference to useful content, which presumably would include a FHIR representation of the topic itself when appropriate "accept" headers are provided -- but even if this works, developers should not rely on this behavior in their software!
Eric Haas (Jan 04 2021 at 17:05):
How does the client then know what it is subscribing too? There needs to be some way to find out what it is (In R5 the resource does that, but no analog in R4). The documentation assumes that I guess, because I don't care about the canonical unless I am interested in a certain topic.
Eric Haas (Jan 04 2021 at 17:14):
Basically am looking for "here's an amazing topic....if you want to subscribe, here is the canonical." instead of here is an operation to get you a list of canonicals....
Gino Canessa (Jan 04 2021 at 17:19):
So far in the R4 backport we've left it out of band. The assumption so far has been that people implementing the R4 backport can discover the definitional resources for the topics they want and use the canonical URL to find out if it is supported on the server.
So far, the use cases haven't needed more than that - do you have one that does?
Josh Mandel (Jan 04 2021 at 17:43):
How does the client then know what it is subscribing too?
The answer here is similar to the answer to any canonical resolution question -- e.g., how does an app learn what a ValueSet URL means? The answer is... get the right IG packages from somewhere (e.g., a registry), and look the URL up in those packages.
Josh Mandel (Jan 04 2021 at 17:44):
It's not a fantastic answer, but there's nothing special/different about subscription topics vs ValueSets, Measures, or any other conformance resources.
Eric Haas (Jan 04 2021 at 18:07):
The assumption so far has been that people implementing the R4 backport can discover the definitional resources for the topics they want and use the canonical URL to find out if it is supported on the server.
That need to be explicitly said in the IG - for naive readers it is not obvious ( I already have a tracker)
Josh Mandel (Jan 04 2021 at 18:10):
Sure -- if you can propose specific language, that'd be great. Even better would be to point to the place in FHIR Core that explains how resolution of canonical URLs works, because Subscriptions shouldn't be doing anything "special" here.
Eric Haas (Jan 04 2021 at 18:19):
A URI that refers to a resource by its canonical URL (resources with a url property). The canonical type differs from a uri in that it has special meaning in this specification, and in that it may have a version appended, separated by a vertical bar (|). Note that the type canonical is not used for the actual canonical URLs that are the target of these references, but for the URIs that refer to them, and may have the version suffix in them. Like other URIs, elements of type canonical may also have #fragment references
and here: http://build.fhir.org/references.html#canonical
talk about resources
I think in this case the canonical doesn't resolve to an actual resource because the resource doesn't exist in R4. That make this more hand wavy IMO. Things like valuesets you expect to get a resource with VSD. The canonical should resolve to something that informs you what it is.
Eric Haas (Jan 04 2021 at 18:20):
... you are subscribing to.
Eric Haas (Jan 04 2021 at 18:35):
What about defining the list of ids to return ( in addition to the focus resource)
The use case I imagine ( and I am split-balling here , but looking at the next iteration of DV Notifications) is the subscriber won't to or can't efficiently search for a bunch of resources but the publisher won't risk pushing a bunch of content over the wire. Assuming this scenario made any sense, what if you split the difference and sent a list (graph) of resource ids.... In R5 an extension on topic, in R4 an extension on Parameter item next to canonical??
Gino Canessa (Jan 04 2021 at 19:36):
Defining a graph for return is an open topic right now; it's fairly complex and we need to ensure that we define something that is both generic and implementable.
- If we decide a client just asks for a graph, a server may support somewhere between all and none of the requested links.
- If the policy is to reject the request, then the server needs to advertise what it supports.
- If the policy is to modify the request, clients need a way to determine what was accepted.
- If we decide servers have the option of including one or more specific graphs (per topic), it simplifies negotiation but has more front-end work.
- We could also go the route of defining a graph within a topic, with servers indicating support for the graph or not.
- What's the best format for defining the graph?
- List of resources
- _include / _revInclude
- GraphDefinition
- GraphQL
- etc.
I've been pretty swamped between the R5/R4 docs and updating the implementations for the connectathon, so I haven't had time to pursue more discussion. I'd be happy to talk about it during the connectathon and/or the WGM though.
Eric Haas (Jan 05 2021 at 19:12):
@Gino Canessa can we do a Noon Eastern Breakout with DV Notifications to discuss this?
Eric Haas (Jan 05 2021 at 19:12):
on Friday?
Gino Canessa (Jan 05 2021 at 19:15):
That works for me, but I believe we're missing @Jenni Syed on Friday. However, I'm happy to take comments beforehand and champion them in the discussion as well.
Jenni Syed (Jan 05 2021 at 19:25):
@Eric Haas In R5, you use the Topic resource to discover topics supported. The Topic itself describes what it is (assuming the caller is savvy enough to understand it in order to "discover" dynamically). If, OTOH, you are following an IG, you would search the Topic Resource by the canonical from the IG
Jenni Syed (Jan 05 2021 at 19:25):
I think the R5 solution is covered and we don't need anything
Jenni Syed (Jan 05 2021 at 19:26):
We didn't really want to port back the full R5 to R4... use cases would be using IGs and know the canonical
Jenni Syed (Jan 05 2021 at 19:26):
the way you discover in the backport was through the operation, which just (I thought... now need to go confirm) that listed the canonicals
Jenni Syed (Jan 05 2021 at 19:26):
again, because all use cases for backport would have followed an IG
Jenni Syed (Jan 05 2021 at 19:29):
I'm not sure I'm following the other use case specifically
Jenni Syed (Jan 05 2021 at 19:29):
eg: defining the list of ids - are you saying the Topic allows for a set of ids as a match - hard coded? Or that the Subscription to that topic might?
Jenni Syed (Jan 05 2021 at 19:30):
Curious why that specificity would be on topic and not the Subscription itself
Jenni Syed (Jan 05 2021 at 19:30):
IE: An admit topic allows for a patient id to be input during subscription, it doesn't hard-code the list of patients on the topic
Jenni Syed (Jan 05 2021 at 19:31):
(obv, you could if you allowed dynamic topic creation, but most servers will likely NOT allow this type of creation?)
Gino Canessa (Jan 05 2021 at 19:45):
I thought the breakout was about graphs more than the topic issue (which I assume will be a point of discussion throughout the connectathon), but perhaps I misread. @Eric Haas ?
Eric Haas (Jan 05 2021 at 21:51):
To Clarify:
1) @Gino Canessa is correct the breakout is about graphs and whether EHRs would support that.
2) @Jenni Syed "the way you discover in the backport was through the operation, which just (I thought... now need to go confirm) that listed the canonicals" That is correct but my point is a list of canonicals does not give you a description of the topic in R4 so its useless without way to get a definition.
Jenni Syed (Jan 06 2021 at 20:25):
So someone is dynamically using topics to determine what to subscribe to? Can you provide an example @Eric Haas ? As Gino mentioned, so far all use cases are based on IGs which define the subscription topics I thought :)
Jenni Syed (Jan 06 2021 at 20:26):
We never intended for R4 backport to have full functional parity with R5 in order to reduce complexity and match with the use cases requesting the backport (minimum viable)
Eric Haas (Jan 07 2021 at 01:15):
I am only pointing out that neither the track not the backport IG discussed how to advertise what topic based subscriptions are available beyond getting an opaque url (URN? ). Out of band seems like an OK answer to me.
Eric Haas (Jan 07 2021 at 01:21):
@Gino Canessa , @Jenni Syed are either of you available next Friday noon Eastern breakout for discussion on the idea of defining a Graph of content to publish (id-only of course ;-) ). I am not proposing for the backport but exploring it for DaVinci Notifications as an extension.
Jenni Syed (Jan 07 2021 at 01:47):
I can't meet until after 3 eastern. Maybe 2 eastern but that might be risky
Jenni Syed (Jan 07 2021 at 01:47):
Gino is covering track lead on Friday due to a prior commitment on my side
Jenni Syed (Jan 07 2021 at 01:49):
(omg, just saw my parody vs parity... Predictive/swipe text ftw)
Jenni Syed (Jan 07 2021 at 01:50):
Fixed. Never happened. :grinning:
Eric Haas (Jan 07 2021 at 04:32):
ok 3 eastern it is.
Jenni Syed (Jan 13 2021 at 17:25):
I added this to the track page
Last updated: Apr 12 2022 at 19:14 UTC
