Stream: fhir/infrastructure-wg
Topic: Notes from Subscriptions Wed Q1
Michael Donnelly (May 08 2019 at 13:09):
Pain points from the HL7 FHIR Connectathon this weekend:
- Hard to subscribe to exactly what you want.
- Knowing when something stops meeting your criteria (issue with expressivity)
- Systems are broken down into topics and subscriptions; we want clear separation between those.
- One topic can have multiple subscriptions.
- Topics have been handled thus far as a Subscription linked to an EventDefinition
- Good syntax and a framework will be better for R5 than what we have today.
Michael Donnelly (May 08 2019 at 13:12):
Josh has a proposal to refactor FHIR subscriptions and test it out at the HL7 FHIR Connectathon before this fall's WGM.
https://docs.google.com/document/d/1rjOI49M-PBVDT7DpLT9LolV4e3qNU1jZbBKdxTwtRE8/edit
Michael Donnelly (May 08 2019 at 13:12):
This won't use lots of extensions because there's a "developer ergonomics bias" against complicated structures like that.
Michael Donnelly (May 08 2019 at 13:14):
We're looking at examples of subscription mechanisms that have topics with filters.
Michael Donnelly (May 08 2019 at 13:16):
A trigger has:
- a human readable description
- a computable definition
- native-FHIR systems (like HAPI) can use this
- façade servers will have to write their own logic
- what resources are subscription candidates for this topic
Michael Donnelly (May 08 2019 at 13:18):
A topic has a list of properties on which that topic can be filtered
- almost all will be FHIR search criteria
- not all FHIR search criteria will be filters
Michael Donnelly (May 08 2019 at 13:22):
Once you create a topic, nothing happens until there's a subscription to that topic.
Michael Donnelly (May 08 2019 at 13:23):
Topics can be server specific. If there are widely defined topics, a server will specify which of those it will support.
Michael Donnelly (May 08 2019 at 13:24):
:checkbox: PARKING LOT: how do we align topics from server to server?
Michael Donnelly (May 08 2019 at 13:26):
When a client wants to subscribe, it creates a subscription on the server. Much of this is like what we have today. Differences:
- instead of search criteria, the client specifies the topic to which it wants to subscribe
- it supplies a list of criteria for any filters defined in the topic
Michael Donnelly (May 08 2019 at 13:26):
Topic has "canFilterBy" and Subscription has "filterBy"
Michael Donnelly (May 08 2019 at 13:28):
(filterBy syntax can look a lot like FHIR search syntax)
Michael Donnelly (May 08 2019 at 13:28):
How does a provider get notifications about patients he or she cares about?
Michael Donnelly (May 08 2019 at 13:30):
Today you might be able to do something like "Encounter?patient:_has:Group:patient:_id=my-group"
Michael Donnelly (May 08 2019 at 13:32):
With this proposal, you'd filterBy "matchType": "memberOfGroup" with "value": ["Group/my-high-risk-patients"]
Michael Donnelly (May 08 2019 at 13:33):
:white_medium_square: PARKING LOT: Filter syntax
:checkbox: PARKING LOT: Scheduling use case
Michael Donnelly (May 08 2019 at 13:34):
Previously, there was no clear way to learn about something falling out of your search set.
Michael Donnelly (May 08 2019 at 13:35):
In the current system, when you have a REST hook channel, you specify a URL that the server treats as a FHIR base.
Michael Donnelly (May 08 2019 at 13:35):
In this proposal, the server posts a bundle to that URL.
Michael Donnelly (May 08 2019 at 13:35):
A FHIR server can parse the Bundle and use it. Other clients will know it'll get everything to the same place.
Michael Donnelly (May 08 2019 at 13:36):
If a server only wants tobatch up notifications (e.g. twice a minute), it can put more things in the Bundle.
Michael Donnelly (May 08 2019 at 13:36):
Bundles can handle deletes.
Michael Donnelly (May 08 2019 at 13:37):
A client can say they only want the IDs and not the full resources.
Michael Donnelly (May 08 2019 at 13:37):
Some clients want nothing - jsut getting pinged on the endpoint with an empty payload will let them know something happened.
Michael Donnelly (May 08 2019 at 13:38):
The last case could be useful if the message is going through somewhere unsecure.
Michael Donnelly (May 08 2019 at 13:38):
How does a Bundle do a delete?
Bundle.entry.request.method=DELETE
Michael Donnelly (May 08 2019 at 13:39):
This Bundle is the server telling the client, "This is what you should execute to look like me."
Michael Donnelly (May 08 2019 at 13:41):
But many clients don't want to look like the server.
Michael Donnelly (May 08 2019 at 13:41):
Should this be a transaction bundle or a history bundle?
Michael Donnelly (May 08 2019 at 13:42):
A transaction Bundle only allows you to send the request part.
Michael Donnelly (May 08 2019 at 13:42):
So history is probably what we want. (Josh updated his Google doc)
Michael Donnelly (May 08 2019 at 13:43):
How can a server detect deletes?
Michael Donnelly (May 08 2019 at 13:46):
Before: Practitioner.org = 123
After: Practitioner.org:not=123
Michael Donnelly (May 08 2019 at 13:47):
But the latter won't work because there's nothing to evaluate.
Michael Donnelly (May 08 2019 at 13:47):
There's no resource to reason about.
Michael Donnelly (May 08 2019 at 13:53):
Even with an implied search criterion of _id being the current context, nothing will ever be true (in FHIRpath) for it.
Michael Donnelly (May 08 2019 at 13:53):
Maybe After: "$not-found"
Michael Donnelly (May 08 2019 at 13:53):
?
Michael Donnelly (May 08 2019 at 13:54):
Looks like in addition to Before and After with FHIRpath, we need boolean's of isDeletion and isCreation.
Michael Donnelly (May 08 2019 at 13:55):
:star: For later follow up: we need syntax to address detection of deletion and creation in native FHIR servers.
Michael Donnelly (May 08 2019 at 13:59):
Scheduling use case
Michael Donnelly (May 08 2019 at 14:00):
A client wants to know about schedule slots - when it can schedule appointments
Michael Donnelly (May 08 2019 at 14:00):
They're looking at Slots as a proxy for time periods that a Practitioner is available.
Michael Donnelly (May 08 2019 at 14:02):
Subscribe to Slot where Practitioner=123
Michael Donnelly (May 08 2019 at 14:02):
They get an update when the Slot changes
Michael Donnelly (May 08 2019 at 14:03):
The client does a couple of queries.
Michael Donnelly (May 08 2019 at 14:03):
The problem is that there's no Practitioner on Slot.
Michael Donnelly (May 08 2019 at 14:05):
Idea: instead of subscribing to Slot, the client could subscribe to changes in Schedule for Practitioner, but when there's a change the client would requery for Slots for that Practitioner.
Michael Donnelly (May 08 2019 at 14:06):
Canonical references
Michael Donnelly (May 08 2019 at 14:07):
Josh would like an Argonaut IG to point to topics out there somewhere.
Michael Donnelly (May 08 2019 at 14:07):
url - server declares its own canonical url
instantiatesUrl - declare alignment with an official topic
Michael Donnelly (May 08 2019 at 14:13):
Should a Subscription.topic be to a shared URL or one specific to the server?
Michael Donnelly (May 08 2019 at 14:14):
:star: This remains an open question.
Michael Donnelly (May 08 2019 at 14:15):
Filter Syntax
Michael Donnelly (May 08 2019 at 14:16):
Should we have filters split out into separate JSON elements or combined into comma separated lists?
Michael Donnelly (May 08 2019 at 14:18):
Arbitrary. The group has a weak preference for JSON, and we'll try that out first, but we're open to considering the other way in the future.
Michael Donnelly (May 08 2019 at 14:21):
Motion
@Eric Haas moved/Michael Donnelly seconded:
- Use Josh's proposal to
- draft a new Topic resource
- update the Subscription resource
- make best effort to resolve the outstanding issues (see stars in this Zulip topic)
- get it into the CI build
- test this in an HL7 FHIR Connectathon track this September.
Vote: 13/0/0
Michael Donnelly (May 08 2019 at 14:23):
Considering Michele's alternate proposal
https://github.com/CareEvolution/Public/blob/master/Subscriptions.md
Michael Donnelly (May 08 2019 at 14:23):
Use a List for subscriptions.
Michael Donnelly (May 08 2019 at 14:24):
Entries are added to or removed from the List by the server. (The mechanism for this is up to the server.)
Michele Mottini (May 08 2019 at 14:25):
I have an alternative proposal: https://github.com/CareEvolution/Public/blob/master/Subscriptions.md (that is backward compatible, so it can be used in existing servers)
Michael Donnelly (May 08 2019 at 14:25):
There could be a list of "Admissions in the last 24 hours"
Josh: Since the items in the list are patients, the list should be called "Patients who were admitted in the last 24 hours".
Michael Donnelly (May 08 2019 at 14:26):
A client can subscribe to the List and get notification of changes to it.
Michael Donnelly (May 08 2019 at 14:26):
In the example of "patients admitted in the last 24 hours", the list would be updated when a new patient is admitted or when a patient on that list has been admitted for more than 24 hours.
Michael Donnelly (May 08 2019 at 14:27):
Josh: In my opinion, this doesn't address the core concerns we have including scalability.
Michael Donnelly (May 08 2019 at 14:27):
JM: the list could get longer and longer over time.
Michele Mottini (May 08 2019 at 14:28):
It works for us - and we have some fairly large deployments
Michele Mottini (May 08 2019 at 14:32):
(fairly large = tens of million patients, billion of data points)
Michael Donnelly (May 08 2019 at 14:33):
Q1 ended. Notes above aren't my opinions or arguments, they're notes on the discussion that took place at the WGM.
Michael Donnelly (May 08 2019 at 14:33):
@Josh Mandel you can put as more or little of this as you want into the minutes.
Michele Mottini (May 08 2019 at 14:34):
(thanks Michael for 'live-streaming' it)
Josh Mandel (May 08 2019 at 19:15):
Thanks a bundle @Michael Donnelly -- This is super helpful for folks who could not join. I've added pretty much all these notes verbatim to the official minutes as well.
Brian Postlethwaite (May 15 2019 at 00:59):
I'm not a big fan of using a deletion in a bundle to indicate that the item went out of the search.
Is this process also to be used to handle actual deletions?
I would have preferred including the new version of the resource (with whatever details it does have) and include an extension in the bundle entry to indicate that it went out of range. If the resource was excluded for security (or other) issues, there is enough detail to know without the actual resource. Deletion just feels wrong.
I do like the List idea.
Josh Mandel (May 15 2019 at 01:09):
On deletion, just to be clear: if the resource actually was deleted, then an entry with "DELETE" makes sense to you @Brian Postlethwaite ?
Josh Mandel (May 15 2019 at 01:12):
It's just for the "got updated" case that you're concerned? Because I think updates should be conveyed as "Bundle.entry.request.method": "UPDATE"
Brian Postlethwaite (May 15 2019 at 01:17):
yes a real deletion is fine. Its for cases where the filter was Practitioner.active = true and the record is updated to not be active.
Its still there, but isn't wanted to be included anymore. Don't want to delete it, as there is content referencing it.
Just need to know that this specific ID went out of range, and I should also mark it.
This would be very useful to have the new data to update in-place, then I can see why, and choose what to do with my own system.
Josh Mandel (May 15 2019 at 01:24):
Agreed. Is that inconsistent with what we wrote, or just unclear?
Brian Postlethwaite (May 15 2019 at 01:43):
Wasn't clear in the discussion above, I'll re-read the updated content.
Last updated: Apr 12 2022 at 19:14 UTC
