Stream: subscriptions
Topic: Jan Connectathon track
Jeremy Richardson (Jan 12 2018 at 17:53):
http://www.hl7.org/events/working_group_meeting/2018/01/
http://wiki.hl7.org/index.php?title=201801_FHIR_Subscriptions
Hi, I'm from M*Modal and I saw that Agfa and Sectra were both "expected participants" in the Jan Connectathon in New Orleans on FHIR Subscription. Is anyone on here from Agfa, Sectra?
Jeremy Richardson (Jan 12 2018 at 22:05):
Wondering who else is going? What's the format going to be?
Grahame Grieve (Jan 12 2018 at 22:09):
well, I'll be there, but I won't be that closely involved.
Grahame Grieve (Jan 12 2018 at 22:10):
@Isaac Vetter have you kept with the emails from Sandy about connectathon preparation?
Isaac Vetter (Jan 12 2018 at 22:37):
Hey @Jeremy ! From Sectra, @Niklas Svenzén is planning on attending. From Agfa, I think Mohannad Hussain will be participating.
Isaac Vetter (Jan 12 2018 at 22:39):
We'll meet up Saturday morning and grab a table. For the FHIRcast testing, you should plan on subscribing to an FHIR server for the patient-chart-open event, be able to receive notifications and have your application switch patient context upon receiving this event.
Isaac Vetter (Jan 12 2018 at 22:40):
My colleague, @Will Maethner , will have the Epic FHIR server that we're bringing to the connectathon available over the internet , the week before the connectathon. Will -- can you share the connection info here, once it's available?
Brad Genereaux (Jan 27 2018 at 15:03):
Hey @Jeremy ! I'm participating this weekend, here from Agfa.
Isaac Vetter (Jan 27 2018 at 15:44):
Good Morning everyone! If you haven't already, check out the scenarios that we're testing this weekend, log issues with the spec on github.
Isaac Vetter (Jan 28 2018 at 19:03):
Hey Everybody, if you can, please swing by table #14 for a connectathon wrap-up
Jens Villadsen (Jan 30 2018 at 08:18):
@Isaac Vetter - will you be updating FHIRcast with any changes/findings that you found during the track?
Isaac Vetter (Jan 30 2018 at 15:51):
Hey @Jens Villadsen ! We've got a growing list of issues: https://github.com/fhircast/docs/issues that need to be addressed. Changes that come out of these conversations will dedfinitely change the spec.
Isaac Vetter (Jan 30 2018 at 15:53):
If you've got feedback, creating issues on the github site is a great way to provide it. Further, once can submit a pull request with specific changes to the spec as well.
Grahame Grieve (Feb 16 2018 at 00:32):
Is this a track we're going to repeat in May?
Isaac Vetter (Feb 16 2018 at 01:46):
Hey Grahame, I think that there's community interest for FHIRcast, but not Subscriptions. As they divurge, it wouldn't make sense to call this Subscriptions.
Isaac Vetter (Feb 26 2018 at 16:29):
Hey @Grahame Grieve , @Josh Mandel - Would you guys mind sharing feedback/guidance on FHIRcast? My goal is to ... refactor the spec before May.
Grahame Grieve (Feb 26 2018 at 17:53):
well, what's the wash up discussion of API vs resource from NOLA?
Isaac Vetter (Feb 27 2018 at 02:37):
this isn't entirely resolved yet, but we're working on it! Before May.
Grahame Grieve (Feb 27 2018 at 04:44):
well, that's my primary feedback... where is that going? I'd really like to see UserSession go away, myself, and have an API based approach, but I'm not sure it's truly a replacement
John Moehrke (Feb 27 2018 at 18:45):
What does that mean ? @Grahame Grieve what is an API? I am told by everyone that FHIR is an API... so what is the problem with being a FHIR Resource, and what is the alternative? (Note I fully recognize that this thing is not persistable like other FHIR Resources, but using the FHIR tooling is really nice, and having the elements defined using FHIR datatypes would be really nice, and leveraging FHIR extestibility, conformance, etc... would be really useful)... So, can we start as a FHIR resource and later figue out where we go?
Grahame Grieve (Feb 27 2018 at 20:06):
at the connectathon, we discussed a simpler approach, where the server just has a pub/sub kind of arrangement where a client can either register a listener end-point or inform the server that the user focus has changed to a different url. And the listeners get informed about the change of url. (probably a triple: user id, client id, focus id). THis is much simpler, and doesn't need any resource.
Leo Bergnéhr (Feb 27 2018 at 20:19):
What does that mean ? @Grahame Grieve what is an API? I am told by everyone that FHIR is an API... so what is the problem with being a FHIR Resource, and what is the alternative? (Note I fully recognize that this thing is not persistable like other FHIR Resources, but using the FHIR tooling is really nice, and having the elements defined using FHIR datatypes would be really nice, and leveraging FHIR extestibility, conformance, etc... would be really useful)... So, can we start as a FHIR resource and later figue out where we go?
The way I see it, there are actually valid arguments for making UserSession queryable, i.e. having it not only as a volatile thing that caries event information. With a persistent UserSession you could, for example, bring clients up after each other and get them to the same state without having to initiate a sync from one of them. It also makes it possible to save a users's state, i.e. "parking" your work and get back to it later, perhaps on another workstation, bringing any other apps on that same workstation to the same context.
Otherwise I agree that there are many benefits with it being a resource.
Grahame Grieve (Feb 27 2018 at 20:37):
what other benefits?
Leo Bergnéhr (Feb 27 2018 at 20:44):
I'll quote @John Moehrke :
but using the FHIR tooling is really nice, and having the elements defined using FHIR datatypes would be really nice, and leveraging FHIR extestibility, conformance, etc... would be really useful)
But perhaps ther's a way of getting may of these benefits with this much simpler idea you are referring to. I'm not sure I fully understand how that would work. It sounds like subscriptions with something like UserSession but with a lot of things stripped away?
Last updated: Apr 12 2022 at 19:14 UTC
