Stream: subscriptions
Topic: Modeling resource triggers
Josh Mandel (Sep 10 2020 at 13:36):
Separating out the resource type into 0..1 within a resource trigger is going to make it extremely verbose to express common cases like notify on any resource created in a patient compartment. You would need to repeat the patient query for every resource type. This might be fine; just sharing one of the initial considerations that went into the current design.
Jenni Syed (Sep 10 2020 at 15:01):
Yes, and the more complex (multi resource) we get, the harder it is to support. I would really like to go as "simple" as we can and get initial implementation and real world feedback before going really complex... there's definitely a balance
Jenni Syed (Sep 10 2020 at 15:01):
EG: if we support multi-resource, I would propose it's automatically an "and"
Jenni Syed (Sep 10 2020 at 15:01):
Patient is over 65 AND prescribed this med
Jenni Syed (Sep 10 2020 at 15:02):
any "or" should just be separate subscriptions
Jenni Syed (Sep 10 2020 at 15:02):
But even that "basic" patient example means that whatever is processing the topics is adding post-filter logic/needing to go query the source system and could slow down the notifications for all
Jenni Syed (Sep 10 2020 at 15:03):
(depends heavily on the architecture underlying notifications)
Grahame Grieve (Sep 10 2020 at 16:20):
I'm not following your response Jenni. I think that the processing issues are important but how are they not orthogonal to the way the search parameter relationships are expressed. I agree that verboseness is the result, but lack of clarity won't help processing.
Unless you are questioning the fact that a notification can be fore multiple resources at all
Jenni Syed (Sep 10 2020 at 16:21):
So, in some of our notification systems internally, they are very separate from the clinical system
Jenni Syed (Sep 10 2020 at 16:22):
Each "domain" has events it publishes, and the metadata that comes along is primarily within that domain or microservice
Jenni Syed (Sep 10 2020 at 16:22):
eg: a notification about patient registration would know demographics
Jenni Syed (Sep 10 2020 at 16:22):
or an admission would know patient id and encounter details
Jenni Syed (Sep 10 2020 at 16:24):
If that system that knows where to publish those to is separate from the clinical system (entirely common in public clouds, also possible in ours if we want to put it in our cloud), then that "and" on the other resource is usually a filter between that "blind" push notification and the end receiver
Jenni Syed (Sep 10 2020 at 16:25):
in the case of something like "and the patient is 65" - that's not an event the system can combine - it's more a query it now has to go run against a clinical system
Jenni Syed (Sep 10 2020 at 16:26):
which may or may not be very efficient depending on where the systems are
Jenni Syed (Sep 10 2020 at 16:26):
and your notifications now could start to bottleneck
Grahame Grieve (Sep 10 2020 at 16:26):
right so that's why you say which things you can do on top the topic - I get that. What I'm saying is that I the current design is confusing because there's no way to relate the 'you can do this' to 'for this resource type'.
Josh Mandel (Sep 10 2020 at 18:49):
Right -- today we limit the list of allowed params to... things that make sense across the board for all the resources that can trigger the notification. I thought (still think) that's kind of a cute way to keep usage focused, but maybe too cute.
Grahame Grieve (Sep 10 2020 at 18:52):
right. it's cute, but how do I process that?
Grahame Grieve (Sep 10 2020 at 19:02):
@Gino Canessa more on this. What's the intent if SubscriptionTopic.resourceTrigger.resourceType is not present?
Grahame Grieve (Sep 10 2020 at 19:02):
does this mean all resource types, or no resource types?
Gino Canessa (Sep 10 2020 at 19:06):
I believe the default was 'all'. That allows:
- notifications on any resource being 'deleted'
- notifications for any resource being 'created' that can satisfy the other criteria (e.g., having a
patient=Patient/123)
That said, I don't think anyone's pushed on it one way or the other for more detailed implications.
Grahame Grieve (Sep 10 2020 at 19:07):
well, I'm going to push that whatever it is, it should be documented ;-)
Gino Canessa (Sep 10 2020 at 19:12):
PR's welcome :stuck_out_tongue_wink:
I'll add it to my list to reconcile with Jenny's at the end of the connectathon.
Grahame Grieve (Sep 10 2020 at 19:12):
@Gino Canessa I just stumbled into a problematic issue. SubscriptionTopic.resourceTrigger.resourceType has a required binding to ResourceType. That's a problem for an R4 backport because the R4 ResourceType list is different
Gino Canessa (Sep 10 2020 at 19:16):
How is it problematic? An R5 subscription should use the R5 resource listing, and R4 doesn't have a field for that (it is embedded in the criteria string currently).
Grahame Grieve (Sep 10 2020 at 19:20):
the R4 backport is using the R5 SubscriptionTopic.
Grahame Grieve (Sep 10 2020 at 19:21):
but the R5 subscription topic resource type list is wrong. e.g. I want to subscribe to MedicationStatement
Gino Canessa (Sep 10 2020 at 19:32):
Fair enough. I assume we should change it to extensible. Would've come up once someone tried with a custom resource too.
Grahame Grieve (Sep 10 2020 at 19:35):
it should match what we do elsewhere with type (e.g. ElementDefinition.type.code), which is a uri with an extensible binding to the ResourceTypes value set and an assertion that a relative reference is a reference to the types defined in the FHIR specification
Gino Canessa (Sep 10 2020 at 19:37):
Do you have an example to save me some searching?
Grahame Grieve (Sep 10 2020 at 19:38):
http://build.fhir.org/elementdefinition-definitions.html#ElementDefinition.type.code
Gino Canessa (Sep 22 2020 at 21:08):
Working through FHIR#28490 . The changes to SubscriptionTopic are straightforward, but I would like some additional feedback on how to represent this on the Subscription side.
I think the problem is trying to cover two use cases that would be modeled differently:
- Multiple resources are listed because it's common to all of them (e.g., 'n' resources, filtered by patient id).
- Multiple resources are listed because you need something across them (e.g., Diagnosis 'x' and Patient age > 'y').
If only one of the two cases is valid, the modeling is pretty simple to fix. If both cases are needed, we'll likely need to consider changing the filter structure (on Subscription) to be just text (so that you can build things like Resource1.field=x&Resource2.field=y).
Can discuss further at the WGM session as well, but I know that not everyone will be present. Thanks!
Josh Mandel (Sep 23 2020 at 17:10):
Use case number one in the list above makes sense to me, and has been driving topic design from the beginning.
I haven't heard about what you describe as use case number two, and indeed from your example this would raise serious questions about the idea that filters correspond to query strings, since your example is not a valid FHIR query.
So my initial reaction is that use case number one is in scope, and use case number two is not in scope
Gino Canessa (Sep 29 2020 at 22:03):
With the changes to the R5 triggers (which look good), it brings the same question to the backport. Prior to this change, we had been saying all of the filters should just be dumped into the criteria string. But, with the additional structure in the R5 versions, this doesn't seem like it would work (e.g., being able to specify filters per resource).
Right now, I'd lean towards some sort of static value in the criteria, and use a complex extension to define the filters - since we already need a couple of fields (resource type and criteria), I think just splitting them out to match R5 (param, modifier, and value) makes sense.
Does anyone have a strong opinion one way or the other?
Grahame Grieve (Sep 29 2020 at 22:06):
it would be good if the criteria listed the overall types that are possible
Grahame Grieve (Sep 29 2020 at 22:06):
?_type=type,type,type
Gino Canessa (Sep 30 2020 at 14:32):
Sounds like I can leave it in just the criteria field, but document that the _type parameter is required if there is more than one type available then. Thanks!
Last updated: Apr 12 2022 at 19:14 UTC
