Stream: FHIRcast
Topic: FHIRcast Ballot
Yunwei Wang (Apr 16 2019 at 21:01):
ONLY the contents under https://fhircast.hl7.org/specification/May2019Ballot/ are in this balloting cycle? Other content, like https://fhircast.hl7.org/launch-scenarios/, are not in this cycle. Is that correct?
Isaac Vetter (Apr 17 2019 at 17:19):
Hey Yunwei, technically, yes. With that said, your attention to any FHIRcast content would be valuable and appreciated. Feel free to log github issues as well.
Ken Sinn (Apr 23 2019 at 18:04):
Hi Isaac, If we have suggestions for new content (e.g. new events) for the IG, should they be logged via the ballot or github?
Isaac Vetter (Apr 23 2019 at 19:06):
Hey Ken, I hope to push all of the ballot comments into github issues for transparency, so if a ballot comment is convenient for you, that would be better.
Isaac Vetter (Apr 30 2019 at 20:01):
Fyi - Ballot commenting is closed! We got 161 comments. All submitted ballot comments are now also github issues. This should help provide additional clarity, transparency and history to the ballot issues identified.
Isaac Vetter (Apr 30 2019 at 20:48):
shoutout to @Bas van den Heuvel , @Will Maethner , @Phillip Warner , @Ricardo Quintano , @Ken Sinn , @Yunwei Wang , @Anthony(Tony) Julian @Ioana Singureanu for the thoughtful and thorough comments.
Anthony(Tony) Julian (Apr 30 2019 at 21:02):
Would be happy to discuss with you, and help if I can.
Anthony (Tony) Julian FHL7,MQF|IT Technical Specialist II|EIA Platform|Information Technology|Phone: 507-293-8384|Fax: upon request|E-mail: ajulian@mayo.edu<mailto:ajulian@mayo.edu>
Mayo Clinic | 200 First Street S.W. | Rochester, MN 55905 | www.mayoclinic.org<http://www.mayoclinic.org/>
Ken Sinn (May 01 2019 at 01:44):
Can't take any credit -- the dev team at eHealth Ontario are the ones that raised the comments. I just pass the messages along. Excited to have them work with community to resolve their comments!
Isaac Vetter (May 07 2019 at 20:39):
@Jonathan Whitby Do you know if we can use the GoToMeeting info from confluence https://confluence.hl7.org/display/IMIN/2019-05+WGM#id-2019-05WGM-PhoneNumbers: to enable remote WGM participation on Wed Q1? @Ken Sinn is asking on behalf of some colleagues.
Jonathan Whitby (May 08 2019 at 12:21):
@Isaac Vetter Yes, this should be running for all II meeting sessions.
Isaac Vetter (May 09 2019 at 18:12):
The HL7 Imaging Integration working group (the primary sponsor of FHIRcast) has resolved 76 ballot comments this week at the HL7 meeting. We have 84 open ballot comments yet to resolve!
Isaac Vetter (May 09 2019 at 18:12):
The workgroup will host a series of gotomeetings over the next two months to discuss and resolve these ballot issues. Here's the call details details:
Isaac Vetter (May 09 2019 at 18:12):
- Tuesday, May 21, 2019, 10:00-11:00 US ET
- Tuesday, May 28, 2019, 10:00-11:00 US ET
- Thursday, May 30, 2019, 10:00-11:00 US ET
- Tuesday, June 18, 2019, 11:00-12:00 US ET
- Thursday, June 27, 2019, 10:00-11:00 US ET
Yunwei Wang (May 09 2019 at 22:22):
Good job @Isaac Vetter
How do I search through comments by submitter?
Update: I figured out. I can just filter by any text
John Silva (May 10 2019 at 11:49):
Trying to understand how subscription lifecycle is defined. When a client subscribes to a topic (or is this a session) they set the properties like events, lease time, callback URL, etc. First question, does each client have their own 'subscription' managed on the Hub? How do multiple clients share the 'common context' if each client has their own subscription, assuming that the Hub needs to maintain a separate subscription objects for each client subscriber (e.g. for unique callback URLs for each)? It seems that to share a common context the Topic needs to be common among the clients that are participating in the common context. I do not see how the current .NET sandbox Hub implementation supports this.
Leo Bergnéhr (May 10 2019 at 13:55):
Right now in the sandbox this is not modeled as a common object but rather from the common identifier of the topic, i.e. that the strings are the same means it's the same context: https://github.com/fhircast/sandbox/blob/master/Hub/Rules/Subscriptions.cs#L21
Will Maethner (May 10 2019 at 13:57):
Hey @John Silva,
First question, does each client have their own 'subscription' managed on the Hub?
Yes, each client (or subscriber) will create their own subscription to the Hub.
How do multiple clients share the 'common context' if each client has their own subscription, assuming that the Hub needs
to maintain a separate subscription objects for each client subscriber (e.g. for unique callback URLs for each)? It seems that to share a common context the Topic needs to be common among the clients that are participating in the common context.
The topic is essentially the session ID of the Hub's client. Let's say the EHR has the Hub and the user launches their EHR. It will get assigned a topic ID by the Hub (e.g. topic1) that subscribers can use. For example if two different applications then subscribed to that same topic with the same events, then they will get the same notifications throughout that session.
John Silva (May 10 2019 at 15:21):
OK, the answer to the first question makes sense and was what I expected. The answer to the second has some subtleties because of the confusion of the naming of topic and sessionId --- are these really two names for the same thing? If so, why two different names? If not, then what is the difference? (I think there might already be some ballot questions about this or github feedback on the fhircast/sandbox repo)
My other question is: "Is a client allowed to change the contents of their subscription? For example, if my client first creates a subscription with a 3600 sec lease time and then later wants to change it to a 7200 sec lease time, is that allowed (spec-wise)? It doesn't seem like the sandbox has a way to do this so I'm not sure if it's just the sandbox implementation or not. (I was starting to write a integration test for this scenario and it failed -- hence my question.)
[The sandbox hub uses an ImmutableHashSet -- it seems like this might not allow changes? Is that how that object behaves?]
Will Maethner (May 10 2019 at 15:31):
The answer to the second has some subtleties because of the confusion of the naming of topic and sessionId --- are these really two names for the same thing? If so, why two different names? If not, then what is the difference? (I think there might already be some ballot questions about this or github feedback on the fhircast/sandbox repo)
As far as the spec goes there is only the topic which just represents a session. The definition is below.
hub.topic Required string The uri of the user's session that the subscriber wishes to subscribe to or unsubscribe from.
Is your question around how the spec defines topic and session or the sandbox (there may be some cleanup needed in the sandbox to make this clearer).
Is a client allowed to change the contents of their subscription?
Yes this is allowed. The Subscribing and Unsubscribing section in the spec describes this "Hubs MUST allow subscribers to re-request subscriptions that are already activated. Each subsequent request to a hub to subscribe or unsubscribe MUST override the previous subscription state for a specific topic, and callback URL combination once the action is verified." So basically you just resubscribe with the same topic and callback and the Hub should overwrite its current subscription with any new or changed parameters. In this way you could change the events that you are subscribed to or those lease seconds as you describe.
As for the sandbox I will say that it definitely needs some updates to fully comply with the spec. It has been hard to keep it fully compliant especially as we have made updates to the spec. If you have any questions about how FHIRcast works then use the spec as the source of truth rather than the sandbox and if you do notice ways the sandbox doesn't comply then the best thing to do is log a github issue that way we can be sure to fix it.
John Silva (May 10 2019 at 16:00):
Thanks @Will Maethner There was discussion at the FHIR Connectathon on this past Saturday about the fact that the Topic should probably be only a string, not a full URL. I think Issac put a github item for this question. However, it is still very confusing that there are different names for what seems to be the same thing? I guess this might stem from the fact that the sessionId might come from the Outh2 world.
OK, it makes sense that clients MUST be allowed to update their subscriptions -- of course they would NEED to do that before their subscription timed out. We also talked about the behavior of what should happen when the subscription timed out both on the Hub and on the client (subscriber); Issac or Niklas captured this discussion I believe.
I was trying to update the sandbox to add an integration test to test for the 'update my subscription' scenario and it didn't work. I was then trying to determine how to update the Hub code to properly implement this. I wasn't sure if the fact it uses the ImmutableHashSet is why since I do not have experience using that .NET object.
John Silva (May 11 2019 at 12:11):
@Leo Bergnéhr @Will Maethner - I created a branch on @Wouter Devriendt clone repro with my changes to try to allow a subscription to be updated. When debugging it seems to do the right thing but I suspect that, because of the ImmutableHashSet, it doesn't really allow the changes to the existing subscription object. Can you take a look at this branch to see why ? (do we need to use something other than an ImmutableHashSet?)
https://github.com/fhircast/sandbox/compare/master...wdvr:updateSubscription
Leo Bergnéhr (May 13 2019 at 07:39):
Leo Bergnéhr Will Maethner - I created a branch on Wouter Devriendt clone repro with my changes to try to allow a subscription to be updated. When debugging it seems to do the right thing but I suspect that, because of the ImmutableHashSet, it doesn't really allow the changes to the existing subscription object. Can you take a look at this branch to see why ? (do we need to use something other than an ImmutableHashSet?)
https://github.com/fhircast/sandbox/compare/master...wdvr:updateSubscription
@John Silva: The immutable classes is just a way of handling multi-threading in .NET. You can still add/remove items, but you get a new collection back which you need to set as the collection it uses to fetch items from. See here: https://docs.microsoft.com/en-us/dotnet/api/system.collections.immutable.immutablehashset-1.add?view=netcore-2.2#System_Collections_Immutable_ImmutableHashSet_1_Add__0_. We might want to change the type from hash set to another type of collection to better allow updates in place.
John Silva (May 13 2019 at 10:25):
@Leo Bergnéhr - Yes, maybe changing to another type would make more sense. What I did in my branch was to update the contents of the existing item so the HashSet is still 'pointing' to the same item, I just changed the contents of the item it's 'pointing' to. (not necessarily the best approach but wanted to get something working for the sandbox.)
Last updated: Apr 12 2022 at 19:14 UTC
