Stream: subscriptions
Topic: May 2020 Virtual Connectation
Jenni Syed (Apr 23 2020 at 13:12):
Hey all - I'm looking at time options for the orientation call. If you are planning on participating in this track, can you respond here with time zone?
Isaac Vetter (Apr 23 2020 at 13:25):
Central US
Jenni Syed (Apr 27 2020 at 21:02):
Reminder to give feedback here if you have hopes of attending - otherwise you may be stuck with a recording of orientation! :)
Jenni Syed (Apr 27 2020 at 21:03):
I'm hoping to be able to account for as many timezones as I can...
Jenni Syed (Apr 30 2020 at 15:21):
The orientation for this track will be Friday, May 1st at 10:00 AM America/Central: https://confluence.hl7.org/pages/viewpage.action?pageId=80119407#id-202005SubscriptionsTrack-TrackOrientation
The ics and details are on the track page above.
Jenni Syed (May 01 2020 at 16:21):
The orientation recording is now out on the confluence page for the track!
Gino Canessa (May 12 2020 at 21:46):
Hi everyone! I just wanted to post some info for testing as people are spinning up for the connectathon this week.
For anyone who hasn't used it yet, there is a client/server test implementation available at subscriptions.argo.run.
The info describing everything got long, so I moved it here. It's basic/rough, but has content.
Questions/comments/feedback welcome. Cheers!
Richard Thomas (May 12 2020 at 22:50):
Central US
Jenni Syed (May 13 2020 at 13:58):
/poll How do you feel about having a short kick off immediately following the larger connectathon kickoff?
I won't be able to attend
Sounds good
I need some space between the two (please add a comment)
Jenni Syed (May 13 2020 at 13:59):
Based on the survey responses, it looked like the timezones were mostly Central and Eastern
Gino Canessa (May 13 2020 at 16:09):
I feel like I should have picked an obscure timezone for funsies.
David Pyke (May 13 2020 at 16:10):
Newfoundland Time is always a good one
John Moehrke (May 13 2020 at 16:16):
Central timezone is the timezone of the EHR world
Gino Canessa (May 13 2020 at 16:23):
Yes, I'd like to change my answer to Cocos Islands time: UTC+6:30 :grinning:
Keith Boone (May 13 2020 at 16:27):
I depends on whether you are talking about hospital or ambulatory EHR.
Keith Boone (May 13 2020 at 16:28):
But, it's also the time zone of departmental and medical device world if I remember correctly.
Keith Boone (May 13 2020 at 16:29):
Something about being able to ship from Illinois/Wisconsin to just about anywhere by train, plane, or truck easily.
Jenni Syed (May 13 2020 at 16:51):
Ok, we'll start our kickoff immediately following the end of the main kickoff today. :) Look forward to seeing everyone!
Jenni Syed (May 13 2020 at 16:51):
Reminder to go add yourself in conman and any client/servers you may have. We can also post them in this chat.
Jenni Syed (May 13 2020 at 20:50):
Thank you for joining our kickoff!
We'll be doing our quick scrum tomorrow at 8:45 Central! Should only be a max of 15 minutes. I'll try to leave the zoom meeting going after that during the day so that anyone can pop in and out to ask questions or collaborate when this chat isn't enough :)
Jenni Syed (May 14 2020 at 14:20):
@Gino Canessa Something that came up on the call: the SubscriptionStatus is now the only place that has the event count (use to be on Subscription). I think it use to be there so that when the client queried subscription, it could tell how "far off" something had gone wrong. Someone also asked if SubscriptionStatus should be queryable (but there are also some awkward fields in the status that don't make sense for a query)
Jenni Syed (May 14 2020 at 14:20):
For some reason I was thinking SubscriptionStatus was a data type and not a resource :)
Gino Canessa (May 14 2020 at 14:29):
Blah, I forgot to put the call in my calendar - I can pop into the meeting in a few.
In some ways it would be easier to have SubscriptionStatus be a datatype, but then it can't be added to Bundle resources directly, since we would have to add the actual element to Bundle (no way to insert a datatype).
I'm trying to remember why we wanted it out (issues with versioning?) and will go through my notes. I don't know if we wrote anything up, but the idea was that you could still get that information, just that the server didn't have to track it on that resource.
Weiyu Zhang (May 14 2020 at 15:06):
Hi all, the Epic subscription server is available at https://connectathon.epic.com/Interconnect-Fhir-Unsecure/api/FHIR/R4Build/.
SubscriptionTopic is searchable via status, and notifications are triggered via Practitioner reads (e.g. https://connectathon.epic.com/Interconnect-Fhir-Unsecure/api/FHIR/R4/Practitioner/eU3aNE-vCGLgH6ukixYqTFA3)
Jenni Syed (May 14 2020 at 15:11):
BTW - we're talking about the status question on the zoom right now
Jenni Syed (May 14 2020 at 15:44):
RE: Status, logged https://jira.hl7.org/browse/FHIR-27130 and https://jira.hl7.org/browse/FHIR-27129
Jenni Syed (May 14 2020 at 15:55):
https://jira.hl7.org/browse/FHIR-27131 logged for inconsistency on the event notification count
Louis Gordon (May 14 2020 at 15:57):
what is the use case for eventsSinceSubscriptionStart?
Jenni Syed (May 14 2020 at 15:58):
@Louis Gordon it's primarily to keep track of how many notification events the server thinks it has sent (vs how many the client thinks). Error handling
Louis Gordon (May 14 2020 at 15:59):
ah i see, thank you
Avery Allen (May 14 2020 at 16:00):
Cerner's Subscriptions implementation is on this server:
https://fhir-open.stagingcerner.com/beta/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca/
More details about the resources implemented and how to use them can be found here:
Notes for Subscription track: https://github.com/averyallen/wgm_notes/blob/may_2020/subscriptions/test_server_faq.md
Weiyu Zhang (May 14 2020 at 18:20):
@Avery Allen dumb question - what content type is that https://fhir-open.stagingcerner.com/beta/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca/Subscription/notify endpoint expecting? are the v2 segments supposed to be in a FHIR wrapper of some sort?
Avery Allen (May 14 2020 at 18:25):
The notify endpoint is just text/plain.
Here's an example request:
curl -i --location --request POST 'https://fhir-open.stagingcerner.com/beta/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca/Subscription/notify' \
--header 'Content-Type: text/plain' \
--data-raw 'EVN|A04|1
PID|123|1316024|1111'
Avery Allen (May 14 2020 at 18:29):
Here's the regex pattern we use for parsing the message:
/EVN\|A04\|\d+\nPID\|\d+\|(?<patient_id>\d+)\|(?<encounter_id>\d+)/m
You can change the patient_id value to play around with the filterBy param that's set on a Subscription. The encounter_id field is propagated in the notification bundle that's sent out if the subscription applies to the event that's triggered.
Louis Gordon (May 14 2020 at 18:44):
Bit unrelated and basic but in terms of subscription implementations would it be reasonable to expect it to be a sort of REST replacement for messaging? ex: i want to be notified about any admission, not just for a particular patient. I've seen a bit of filter usage so I'm wondering what vendor support is looking like?
Vassil Peytchev (May 14 2020 at 18:52):
Avery Allen said:
Here's the regex pattern we use for parsing the message:
/EVN\|A04\|\d+\nPID\|\d+\|(?<patient_id>\d+)\|(?<encounter_id>\d+)/m
If that is supposed to be a V2 message, you probably want \r instead of \n, and \r is considered part of each segment... Not to mention that encounter ID is likely found in PV1, not in PID.
Jenni Syed (May 14 2020 at 18:57):
It was hacked together from some examples we saw. I don't think this would be something you would see IRL
Jenni Syed (May 14 2020 at 18:58):
IE: don't focus too much on how we hacked up the notification process :)
Jenni Syed (May 14 2020 at 20:00):
Reminder that we have our check in at 16:00 Central (in an hour)!
Jenni Syed (May 14 2020 at 20:58):
Reminder that our check in is in a few minutes!
Jenni Syed (May 14 2020 at 20:59):
@Gino Canessa my zoom won't stay connected :pensive:
Jenni Syed (May 14 2020 at 20:59):
I'll keep trying but it just reboots
Gino Canessa (May 14 2020 at 21:22):
Retrying works!
Gino Canessa (May 14 2020 at 21:22):
:-)
Jenni Syed (May 15 2020 at 13:51):
Hey all - the zoom is open if anyone wants to jump on and chat this morning. I am stepping away for breakfast but will be back and checking in during that time as well.
Jenni Syed (May 15 2020 at 14:54):
Reminder that our check in will start in 5 minutes!
Jenni Syed (May 15 2020 at 15:04):
FHIR#27138 : Adding search parameters for subscription topic derived
Jenni Syed (May 15 2020 at 16:56):
I brought up a possible break out for back port over on one of the original threads here: https://chat.fhir.org/#narrow/stream/179229-subscriptions/topic/any.20work.20backporting.20r5.20subscriptions.20to.20r4.3F Conversations are now ongoing :)
Jenni Syed (May 15 2020 at 17:04):
FHIR#27141 for conversations around SubscriptionStatus linking to the canonical topic URL instead of the local server topic
Jenni Syed (May 15 2020 at 17:10):
FHIR#27142 logged for clarifying the url vs derivedFromCanonical usage
Jenni Syed (May 15 2020 at 17:14):
FHIR#27143 logged for the normative search params
Jenni Syed (May 15 2020 at 17:16):
@Lloyd McKenzie I'm running into issues where it seems like the jira validation for the "Related URL" is failing URLs like http://build.fhir.org/subscriptiontopic.html#search. Is there a meta-jira? :) (see the jiras above where it wouldn't let me save until I moved them to the text section)
Also, it looks like some of the newer r5 subscription resources aren't options (SubscriptionTopic, SubscriptionStatus).
Jenni Syed (May 15 2020 at 17:49):
@Gino Canessa This document actually has some good concerns documented around subscription security. In regards to the notification aspect, it includes some of the examples we were discussing today: https://chat.fhir.org/#narrow/stream/179229-subscriptions/topic/Security.20and.20Privacy.20Issues.20in.20FHIR.20Subscription
Jenni Syed (May 15 2020 at 17:50):
I'm not sure they're entirely solved for on the notification part - it mentions similar options that we've discussed and some drawbacks.
Gino Canessa (May 15 2020 at 17:50):
Had the message starred, but never had the chance to read it.. will take a few and do that
Jenni Syed (May 15 2020 at 17:51):
@John Moehrke A topic that came up as a possible breakout in our subscription discussion today was around security when notifications are sent from the FHIR server to the client. We were curious if there was availability when you might be able to attend (also for anyone else watching :) )
Jenni Syed (May 15 2020 at 17:52):
There are some challenges, especially when the client is not a full server (requiring a client to implement an OAuth or SMART server seems like a large barrier to entry). But we were curious if we could include some recommendations in an IG (like the Argonaut one) and some more detailed guidance around security in the actual Subscriptions page
Lloyd McKenzie (May 15 2020 at 17:53):
Grrr. Insufficient testing on my part. Will work on a fix, but may not be in until this evening. Sorry @Jenni Syed :(
Jenni Syed (May 15 2020 at 17:53):
NP - I worked around it :)
John Moehrke (May 15 2020 at 19:44):
did you want to meet today? or are we thinking sometime next week?
John Moehrke (May 15 2020 at 19:45):
for high-security environments, I expect them to demand a subscription that only pokes the subscriber, requiring the subscriber to request (GET) the data.
John Moehrke (May 15 2020 at 19:46):
I have not kept up with current subscription design. so I have no idea what security considerations (or not) might apply
Jenni Syed (May 15 2020 at 19:52):
We have some recommendations out there now for general guidance: http://build.fhir.org/subscription.html#safety
Jenni Syed (May 15 2020 at 19:52):
But for eg: if I just send a "poke", the client will turn around and query data. Curious about concerns around getting notifications from untrusted sources. In the "poke" case, maybe that just helps organize a DDOS against the server :P
Jenni Syed (May 15 2020 at 19:53):
In the "send full data" it results in bad data in the subscriber. We do need to establish trust in some way there
Jenni Syed (May 15 2020 at 19:54):
Requiring the client to have a full auth server (eg: so the server authenticates against their auth endpoint) is too heavy. We don't really like saving a limited use token with the subscription either.
Jenni Syed (May 15 2020 at 19:54):
mutual TLS isn't great :)
Jenni Syed (May 15 2020 at 19:54):
I think the main spec should still give general guidance but maybe get to an Argo-specific recommendation on an IG
Jenni Syed (May 15 2020 at 19:55):
otherwise it will be tough for clients connecting to many servers and vice versa
Jenni Syed (May 15 2020 at 19:55):
we were hoping to discuss today but I would be willing to use one of the WG meetings next week as well
Jenni Syed (May 15 2020 at 20:20):
Hi all - I have an updated version of the track report, if you haven't sent me a summary or something is incorrect, let me know! https://docs.google.com/document/d/1B6FvP5IP83tuUPvOMQjZIR5jYyw4OSbahgRqnbkPZZ8/edit#heading=h.3qwti6xmg517
Jenni Syed (May 15 2020 at 20:47):
Reminder - we have our last connectathon check in in 15!
Gino Canessa (May 15 2020 at 22:07):
Thanks for running everything this week Jenni! And for writing such great JIRA issues! :clap:
Jenni Syed (May 15 2020 at 22:09):
Thank you everyone for participating! It's kind of useless without all of you!
Jenni Syed (May 15 2020 at 22:09):
Speaking of trackers: FHIR#27148 (prefer for full URL/ req/response) and FHIR#27149 (registry). Those are our last trackers of the track!
Jenni Syed (May 15 2020 at 22:23):
Summary of the brief security discussion we had for sending Notifications to a client (so the client can validate that the notification should be trusted):
- Want to reuse what we can and not build our own
- Recognize that the main Subscription guidance may need to stay general
- Would be useful to have a small IG so that use cases like Argonaut and CMS can be interoperable without servers and clients having to support n amount of different auth mechanisms.
- JWT sent from sever to client may have some appeal: it reuses some existing infrastructure (like CDSHooks auth) and has libraries that you can reuse to validate and create JWT. The Key infrastructure is publicized and this allows for asymmetric key (no need to keep servers and clients in lock step on secret rotation - new public keys are discoverable via a standard)
- need to continue discussion and this will feed back into general guidance. Still discussion to be had.
Jenni Syed (May 15 2020 at 22:24):
@Gino Canessa @Isaac Vetter let me know if I missed something ^^
Lloyd McKenzie (May 16 2020 at 03:18):
@Jenni Syed URL issue fixed (thanks for reporting)
Last updated: Apr 12 2022 at 19:14 UTC
