Stream: subscriptions
Topic: State Changes Blog
Gino Canessa (Jan 07 2020 at 17:12):
Hey all, I know there's been a lot of discussion around FHIR R5 Subscriptions and when states trigger. So, I've written a blog post around my current understanding and thoughts. Questions/comments/feedback welcome!
Martin Grundberg (Jan 12 2020 at 10:13):
Hey all, I know there's been a lot of discussion around FHIR R5 Subscriptions and when states trigger. So, I've written a blog post around my current understanding and thoughts. Questions/comments/feedback welcome!
Great blog post! Thx for sharing!
I’m really interested in the area of state transitions as it really is what drives process and workflow as well as has high impact on business logic and validations. The easier it is for the client to understand what has happened the better, and having to compare versions to find out what has happened is not great.
You divide state changes into Create, Delete and Update. Update of course can be really anything.
Do you know if resource specific standard update events are defined or are being discussed? I think that would be a very good idea. An example is in the ADT area, it should be possible for a client to understand directly that an event is an Admission, Discharge or Transfer instead of having to figure out what type of Update event has occurred. For ADTs, these standard events would then apply to the Encounter resource.
Paul Church (Jan 12 2020 at 16:13):
One consideration that can complicate the otherwise straightforward 'create' is that the case where the client gets access to a resource that it previously did not have access to is...kind of like a create?
Paul Church (Jan 12 2020 at 16:17):
On the delete / loss of access side, I think the server should definitely broadcast the ID to avoid the following problematic pattern:
- User is looking at their data in an app, sees a lab result that they don't want that app to have access to.
- User goes to the data provider and changes their settings to stop sharing that lab result.
- The app isn't notified, because this was a deletion related to privacy settings.
- The user checks in the app and the lab result is still displayed!
René Spronk (Jan 12 2020 at 16:58):
@Martin - sounds like Messaging to me :rolling_eyes:
David Hay (Jan 12 2020 at 17:54):
Gave it a little push... :slight_smile:
Paul Church (Jan 12 2020 at 17:55):
One of the considerations that went into the Topic design was that there could be "standard" topics published by an IG, and they can have specialized logic that identifies an event like an ADT rather than just a bag of generic resource updates. I don't know how far that's been developed but the idea was there.
Aron Kohn (Jan 12 2020 at 18:02):
Great post and thanks for asking for opinions in public!
With Dynamics 365 experience, this seems very similar of how plugin registrations works. The dynamics team enabled on the subscription layer to actually pick and choose whether to include Pre or Post images (record snapshot) which each event (when applicable) and even on a more granular level, which fields should be included with those images.
In the FHIR world where there are privacy concerns, regulations and etc. I would think that it would be nice to have the same type of options but it would need to go through some sort of authorization whether to allow the subscription or not.
Gino Canessa (Jan 13 2020 at 16:38):
Do you know if resource specific standard update events are defined or are being discussed? I think that would be a very good idea. An example is in the ADT area, it should be possible for a client to understand directly that an event is an Admission, Discharge or Transfer instead of having to figure out what type of Update event has occurred. For ADTs, these standard events would then apply to the Encounter resource.
This is something we were discussing at the CMS Connectathon last week. Right now, any of those events could be defined as a SubscriptionTopic (and would only need to be defined once, as Paul mentioned), but those topics would rely heavily on the description of the event. E.g., most people using them don't want to figure out computable definitions for 'standard' events.
That lead to the idea of adding an additional way of describing triggers (to the existing fhirPath and queryCriteria), which would allow for a code system and event (e.g., HL7v2 + ADT01) or a reference to an EventDefinition resource.
So far, it hasn't been asked for enough enough to get traction/feedback for inclusion into the spec. Today, it could be added as an extension (maybe even a 'standard' one), but not as a first-class field. If we want to dig into it, there will need to be discussion around pros-cons, trade-offs, etc., but I'm all ears.
Gino Canessa (Jan 13 2020 at 16:39):
@Martin - sounds like Messaging to me :rolling_eyes:
That's something that has come up recently as well - we are actively trying to figure out if there is overlap/opportunity/fit.
Gino Canessa (Jan 13 2020 at 16:42):
One of the considerations that went into the Topic design was that there could be "standard" topics published by an IG, and they can have specialized logic that identifies an event like an ADT rather than just a bag of generic resource updates. I don't know how far that's been developed but the idea was there.
Yes, SubscriptionTopic includes derivedFromUri and derivedFromCanonical fields to ensure that clients can find what they are looking for (e.g., a Server can derive from a canonical topic to add additional filters, and a client can still find the derived topic).
There is also guidance about what can be done when deriving from a topic (e.g., adding additional filters is good, changing the key resource is bad).
Gino Canessa (Jan 13 2020 at 16:57):
With Dynamics 365 experience, this seems very similar of how plugin registrations works. The dynamics team enabled on the subscription layer to actually pick and choose whether to include Pre or Post images (record snapshot) which each event (when applicable) and even on a more granular level, which fields should be included with those images.
In the FHIR world where there are privacy concerns, regulations and etc. I would think that it would be nice to have the same type of options but it would need to go through some sort of authorization whether to allow the subscription or not.
That's interesting! There has been quite a bit of discussion around including graphs (by either GraphQL or GraphDefinition ), but the general consensus has been to focus on the core mechanisms first and make sure they are solid.
There is also a strong camp that would prefer to have those types of operations done post-notification for simplicity (e.g., a client receives the notification, then authenticates and builds their desired graph normally, even if that client is just a hop to build the graph and sends it on to someone else).
Pre-state graphs are much harder, since they either need to be built during the workflow in question, or later using a time database, etc. Given all the architectural implications, I don't think it's feasible in the core spec (today). That said, if a sever wanted to implement pre-state notifications, it should just require one or two extension fields to make it happen.
Last updated: Apr 12 2022 at 19:14 UTC
