Stream: implementers
Topic: EventDefinition.name vs EventDefinition.trigger.name ?
Isaac Vetter (May 02 2019 at 02:58):
EventDefinition's name element is described as:
Name for this event definition (computer friendly)
Isaac Vetter (May 02 2019 at 02:59):
EventDefinition.trigger.name is described as
Name or URI that identifies the event
Isaac Vetter (May 02 2019 at 02:59):
The EventDefinition example populates the EventDefinition.trigger.name, but not the EventDefinition.name.
Isaac Vetter (May 02 2019 at 02:59):
I'm hoping to grasp the metaphysics behind this -- when should these two names be different?
Isaac Vetter (May 02 2019 at 02:59):
/ @Bryn Rhodes ?
Bryn Rhodes (May 02 2019 at 05:10):
The trigger element of EventDefinition is a TriggerDefinition, which has a name because it's a self-contained definition of a triggering event. The EventDefinition is a Definition resource that reuses the TriggerDefinition data type to allow events to be referenced as resources directly, so it "inherits" the name element from the Definition pattern. I think in pratice, yes, they would always be the same. EventDefinition is still a draft resource.
Bryn Rhodes (May 02 2019 at 05:11):
That would be a good tracker to submit to resolve the redundancy.
Bryn Rhodes (May 02 2019 at 06:10):
Thinking more about this, the name element in the TriggerDefinition is used for named events, it’s possible to define a data-based event or periodic event that does not have a name. When this type of trigger is used in an EventDefinition, it could be given a name for use by implementing systems.
Josh Mandel (May 02 2019 at 13:56):
Can you help me understand why a TriggerDefinition isn't a resource, if it's designed to be individually identifiable (by standardized names) and re-usable across EventDefinitions @Bryn Rhodes ?
Josh Mandel (May 02 2019 at 14:02):
I'm especially confused given TriggerDefinition.name:
A formal name for the event. This may be an absolute URI that identifies the event formally (e.g. from a trigger registry) ...
Josh Mandel (May 02 2019 at 14:20):
I submitted GF#21232 to start exploring some of this.
Bryn Rhodes (May 02 2019 at 14:21):
When TriggerDefinition is used within PlanDefinition, it's referencing an event defined elsewhere. When it's used as part of EventDefinition, it's actually defining the event. Multiple PlanDefinitions, for example, might reference "patient-view" as a named event, where that event is defined by the CDS Hooks registry.
Josh Mandel (May 02 2019 at 14:22):
Wait, TriggerDefinintion references an EventDefinition which references a list of TriggerDefinitions ??
Josh Mandel (May 02 2019 at 14:25):
(I'm trying to figure out how to build up an event stream from multiple kinds of source events -- each defined in a reusable, modular way -- and then a set of filters, also defined in a reusable, modular way. My write-up here is probably revealing the way I'm struggling with the current infrastructure. Is there a better approach you'd recommend for these subscription use cases? Discussion in https://chat.fhir.org/#narrow/stream/179229-subscriptions/topic/Event.20Definition)
Bryn Rhodes (May 02 2019 at 14:35):
I think of TriggerDefinition as a structure for defining when something should happen, like "when a lab is created". You can use that criteria definition in both a referential and a definitional context. In PlanDefinition, it's a referential context, in EventDefinition, it's a definitional context. And yes, you can have multiple in EventDefinition so that we can support triggering off of multiple events.
Bryn Rhodes (May 02 2019 at 14:36):
That's a great write-up, I've been following that, I think it's a good approach and it seems like the right use of the EventDefinition resource.
Josh Mandel (May 02 2019 at 14:38):
...but it also assumes a new thing like EventFilter -- and it kind of pushes TriggerDefinition down into the details, so it's not a unit of reusability. This is the stuff I'm struggling with.
Bryn Rhodes (May 02 2019 at 14:45):
TriggerDefinition should probably be called TriggerCriteria.
Josh Mandel (May 02 2019 at 14:48):
But should it be a resource?
Bryn Rhodes (May 02 2019 at 14:49):
That's what EventDefinition is
Bryn Rhodes (May 02 2019 at 14:50):
TriggerDefinition is reusing the "structure" in FHIR, but not the instances.
Bryn Rhodes (May 02 2019 at 14:51):
To reuse the instance, it has to be a resource, so that's why we created EventDefinition
Josh Mandel (May 02 2019 at 14:52):
I'm struggling because TriggerDefinition has a name (critical for named-events), and the concept of a registry of TriggerDefinitions -- but that registry couldn't be an actual FHIR registry since it's not a resource.
Josh Mandel (May 02 2019 at 14:52):
I might not be expressing the concern clearly...
Bryn Rhodes (May 02 2019 at 14:53):
No, it makes sense, and there's definitely room for improvement in the documentation to help address this, but what you just said "has a name" and "the concept of registry" is already true of EventDefinition
Josh Mandel (May 02 2019 at 14:54):
OK, but this doesn't feel like a documentation issue to me; it feels like an issue about "what concepts do we have in the spec, and how are they related/reusable".
Josh Mandel (May 02 2019 at 14:54):
Anyway, maybe a good subject for discussion next week :)
Bryn Rhodes (May 02 2019 at 14:55):
Yes, would definitely be a good topic
Josh Mandel (May 02 2019 at 14:55):
Simplest problem statement: A PlanDefinition and an EventDefinition can't share the same TriggerDefinition (like "patient-admission") -- except by duplicating the whole definition.
Bryn Rhodes (May 02 2019 at 15:00):
Yeah, that's true, good statement, you should capture that in the tracker
Last updated: Apr 12 2022 at 19:14 UTC
