FHIR Chat · Subscribing to events · argonaut

Stream: argonaut

Topic: Subscribing to events

Michael Donnelly (May 01 2019 at 18:01):

There are three concepts to a subscription that can easily be conflated:
1. The subject of a subscription (e.g. a patient or any patient with a certain PCP)
2. When you want to hear about that subject (e.g. when the patient has a new appointment or when a patient with that PCP is admitted)
3. The content of the notification.
I think it behooves us to treat these as separate concepts and answer what we want before diving into the details of how to do it.

Josh Mandel (May 01 2019 at 20:45):

Agree on separation of concerns here. I think (3) is the clearest -- or the least confusing with our current "payload" approach, though it's still interesting in its own right.

Josh Mandel (May 01 2019 at 20:46):

For (1) and (2), the way I look at the world, "subject" is a bit slippery. It's clearer for me to think about an event stream (e.g., all events that match a specific definition like "admission") and then a series of filters that narrow things down (e.g, by subject, but possibly by diverse parameters, like time range, codes, etc).

Josh Mandel (May 01 2019 at 20:47):

I'm still trying to articulate this properly, but this gist is a start, in terms of how I'd think about breaking down the "events" (more or less your (2), @Michael Donnelly) and "filters" (a generalization of your (1), @Michael Donnelly ).

Josh Mandel (May 01 2019 at 20:48):

(For those who haven't seen it, this is building on the "named event" approach that's being tested at connectathon. You may have to "expand source" in Jira to see it properly.)

Michele Mottini (May 01 2019 at 21:54):

Our system support event definition and subscriptions based on these user-definable queries:
pasted image

Josh Mandel (May 01 2019 at 21:55):

Can you help explain what "Wrap query" means @Michele Mottini ?

Josh Mandel (May 01 2019 at 21:56):

Also, if you have a chance to glance through my gist, whether this makes sense to you (and/or seems like a good direction)?

Michele Mottini (May 01 2019 at 21:56):

oh I have no idea - there are a ton of options there I do not know how to use

Michele Mottini (May 01 2019 at 21:57):

basically it is impossible to define those 'events' via FHIR in some reasonable way

Michele Mottini (May 01 2019 at 21:58):

so what we are doing are just exposing them as List

Michele Mottini (May 01 2019 at 21:58):

and then you can subscribe (via FHIR) to one of these List

Michele Mottini (May 01 2019 at 21:59):

I wonder if that's an approach that could be of general use

Michele Mottini (May 01 2019 at 22:01):

(I checked: wrap query is 'Except', 'Intersect', 'Union' - basically you can have a list of different filters there and 'Wrap query' tells the system how to combine them)

Michele Mottini (May 01 2019 at 22:03):

(here is an example - Anticoagulant Therapy Surveillance:)
pasted image

Josh Mandel (May 01 2019 at 22:14):

Huh! So is all of that backed by EventDefinition? How does it represent "except" for instance?

Michele Mottini (May 01 2019 at 23:13):

No, it is not backed by EventDefinition - it is totally not-FHIR

Michele Mottini (May 01 2019 at 23:14):

and I don't think is feasible to define such a thing via FHIR - hence the idea that you keep defining them out of band and just publish them as List

Josh Mandel (May 02 2019 at 00:14):

Gotcha -- thanks!

Michael Donnelly (May 02 2019 at 01:03):

I think that's a valid way of looking at it Josh, but I'd like to explore a different angle and see if it works at all.

When an event occurs, it has two parts
A. The EventDefinition (the platonic form of the event)
B. Contextual data

Michael Donnelly (May 02 2019 at 01:06):

For ADT or scheduling events, the Encounter is the context.

Michael Donnelly (May 02 2019 at 01:07):

There are a bunch of indirect contextual data as well: the Patient for the Encounter, the Location where it occurs, the Practitioner for the attending provider.

Michael Donnelly (May 02 2019 at 01:07):

Another layer deeper, we have the Patient's PCP, etc.

Michael Donnelly (May 02 2019 at 01:11):

Now that I've started writing it out, I think my idea adds complexity without adding value.

Michael Donnelly (May 02 2019 at 01:15):

Your first two examples (each with its explicit EventDefinition and EventFilter) look great. I believe it'd be clear to the client what it's asking for and what it'll get, and a system that already triggers v2 shouldn't have trouble with that.

Michael Donnelly (May 02 2019 at 01:20):

The Expressiveness example makes perfect sense. I think having named events like that is a good idea; easier for client developers to understand, fewer fiddly bits. The status part could be problematic depending on the mapping involved and how much processing is involved in getting the %previous.status.

Michael Donnelly (May 02 2019 at 01:21):

...but since that'd be agreed upon ahead of time in a spec or IG, there's plenty of room to work that out ahead of time.

Michael Donnelly (May 02 2019 at 01:27):

Getting into Continuing to explore expressiveness is thinner ice. Instead of the trigger being an EventDefinition based on an actual step in a workflow, the trigger is or could be perceived to be based on a change to a datum.

Michael Donnelly (May 02 2019 at 01:28):

Practically, if we needed to implement that, we'd take all the specific events in our system, put it through a generalization layer (for all events in a set) and then doing the filtering.

Michael Donnelly (May 02 2019 at 01:45):

Would it be too confusing if EventDefinitions could refer to other event definitions? E.g.

{
  "resourceType": "EventDefinition",
  "id": "admission-by-patient",
  "trigger": {
    "type": "named-event",
    "name": "admission-by-patient",
    "condition": "eventDefinition = 'EventDefinition/admission' and eventFilter = 'EventFilter/by-patient'"
  }
}

Michael Donnelly (May 02 2019 at 01:46):

Then if we wanted a more general version for multiple events without the client having to explicitly make multiple subscriptions, we could do something like

{
  "resourceType": "EventDefinition",
  "id": "inpatient-status-change-by-patient",
  "trigger": {
    "type": "named-event",
    "name": "inpatient-status-change-by-patient",
    "condition": "(eventDefinition = 'EventDefinition/admission' or eventDefinition = 'EventDefinition/transfer' or eventDefinition = 'EventDefinition/discharge') and eventFilter = 'EventFilter/by-patient'"
  }
}

Michael Donnelly (May 02 2019 at 01:50):

Before putting in that effort, I'd want a better idea of which clients actually wanted a set like that. If it's common that clients want multiple event definitions and (understandably) don't want a separate subscription for each, we could let them specify multiple EventDefinitions in the triggers:

{
  "resourceType": "Subscription",
  "triggerParameter": [
    {"name": "patientId", "value": "Patient/123"}
  ],
  "trigger": [{"reference": "EventDefinition/admission"},
              {"reference": "EventDefinition/transfer"},
              {"reference": "EventDefinition/discharge"},
              {"reference": "EventFilter/by-patient"}]
}

Michael Donnelly (May 02 2019 at 01:51):

With the EventDefinitions having OR logic, naturally.

Josh Mandel (May 02 2019 at 02:06):

Ooh, I really like the final bit you arrived at there @Michael Donnelly -- this kind of thing is super practical and potentially could span across multiple resource types (encounter events and EventDefinition/new-lab-result or whatever, so there's a pool of Observations + Encounters that can be then filtered down by-patient).

Josh Mandel (May 02 2019 at 02:08):

(Separately: the joining of EventDefinitions like:

"condition": "eventDefinition = 'EventDefinition/admission' and eventFilter = 'EventFilter/by-patient'"

confuses me a bit, because I was assuming that the "condition" would be a valid FHIRpath expression over some input resource, and if I think about what you wrote here:

1. My head hurts, and
2. It would seem to emit stream of EventDefinitions rather than a stream of events)

Michael Donnelly (May 02 2019 at 02:10):

I think it ends up not being worth it anyway; if clients can assemble their own set of EventDefinitions in the Subscription itself, the need for combo EventDefinitions isn't crucial.

Michael Donnelly (May 02 2019 at 02:10):

And I totally agree; no reason why a client couldn't put as many EventDefinitions into the same Subscription as long as they all use the same EventFilter.

Josh Mandel (May 02 2019 at 02:14):

I'm stealing your example for my gist :)

Josh Mandel (May 02 2019 at 02:23):

Added "The Rules" and incorporated your example below, @Michael Donnelly.

Michael Donnelly (May 02 2019 at 03:02):

That works.

Michael Donnelly (May 02 2019 at 03:04):

Good balance of letting servers base events off workflow rather than data model and giving clients the power to hear about the specific things that matter to them.

Last updated: Apr 12 2022 at 19:14 UTC