FHIR Chat · Subscription additional Criteria · subscriptions

Stream: subscriptions

Topic: Subscription additional Criteria

Anand Jahagirdar (Jan 26 2021 at 12:30):

Hi All,
I have following requirement for FHIR subscription:
Client application wants to subscribe and get notification in following scenario:

 - When Task resource linked to a patient X is created, modified
 AND

 - Encounter linked to a patient X has specific code ABC

I thought of using Subscription with following :

- *Criteria * field as : <Server>/fhir/task?owner:Patient=12345
- additional criteria ( as mentioned in https://build.fhir.org/ig/HL7/fhir-subscription-backport-ig/StructureDefinition-backport-subscription.html)
as <Server>/fhir/Encounter? patient=12345&code=ABC

Could you please let me know if my usage of ANDing Criteria and additional criteria is correct?

I am using combination of Criteria and additional criteria as in AND combination to narrow down the condition to send notification (only when Task resource for a patient with particular encounter exists).

Anand Jahagirdar (Jan 27 2021 at 06:48):

@all, do you have any inputs for me. thanks.

René Spronk (Jan 27 2021 at 08:20):

@Gino Canessa ? the backport description doesn't show us exactly what 'additional criteria' maps to in R5 ..

Gino Canessa (Jan 27 2021 at 14:31):

@René Spronk Indeed, it doesn't appear to. The short answer is that it is needed to avoid creating a new search syntax for multiple resource triggers (e.g., if a subscription can trigger off of Encounter or Appointment, how do you express the filters rooted in each). That said, if you could open a ticket I would appreciate it.

René Spronk (Jan 27 2021 at 14:50):

https://jira.hl7.org/projects/FHIR/issues/FHIR-30634

Gino Canessa (Jan 27 2021 at 15:21):

Hi @Anand Jahagirdar , sorry for not seeing this - WGM week is crazy.

From a quick look, that is not quite correct. Having multiple resource triggers is a way of specifying different ways the subscription could be triggered (e.g., starting from an Appointment or starting from an Encounter).

I think it requires a change to the definition of your SubscriptionTopic; e.g., you want to know when a Task is created or modified and that Task's patient _has an Encounter with the code you are looking for (I'm not sure if you mean a reason code, or some other).

With the updated definition, the only filter is on the Patient (id). The model moves most of the complexity into the topic, so a server is aware of what they are signing up for by when supporting a topic.

Anand Jahagirdar (Jan 27 2021 at 17:08):

Thanks @Gino Canessa .
Let me explain what I understood from your statement:

• I have to create a subscriptionTopic : Change in Task whose patient has an encounter with specific reason code.

Then how will criteria look like? Task resource or Patient resource.
I believe it will be Task resource.
From server implementation point of view,

• I will still be monitoring Task resource creation / modification:
  • When I update/ create Task, I will evaluate the Patient resource corresponding to Task has particular encounter or not.
  • If Yes, send notification with Task
  • If No, no notification.

I am still not clear how I should communicate this to my clients:

- only through subscription Topic
- or through Criteria as well.

Again, I assume through subscription topic and Criteria is on plain Task resource.

Is my understanding correct ? thanks.

Gino Canessa (Jan 28 2021 at 17:41):

There are two areas where criteria of some kind are applied. The first is the core of what a SubscriptionTopic does, the resourceTrigger. Based on what I understand you are trying to do, it sounds like you would want a resourceTrigger rooted in Task. Building the exact triggering criteria expressions for this topic will probably take some tinkering and sample data to make sure it is correct.

Generally speaking, we have tried to put anything 'complex' into this area. This is to allow servers to understand the implications of topics they want to support. In earlier versions of subscriptions, this was on the subscription itself. Unfortunately, that meant servers were being asked to do a lot of work which they didn't support or at least had not optimized for.

However, it wouldn't make sense to make topics for each individual patient (for example). So, the other place where some form of filtering exists is in the canFilterBy and matching filterBy (R5) or criteria/additionalCriteria (R4 backport). These are filters the server exposes to clients. If it is expected that a client would want only notifications for one particular patient (for example), the allowed filters can include the search parameter patient. When creating a subscription, the requester can then set that filter to match what they should receive.

For the communication between server and client, it is a little challenging in the backport (compared to R5) because the new resources do not exist; right now the idea is to do that kind of discovery is out of band. Given how specific this topic is, I assume you have some sort of integration documentation - that would be a good place to describe this and list the canonical URL for the topic. Long term, topics will also be listed in the FHIR registry, to make them easier to reuse.

So overall (again, using the backport):

• You define the topic (e.g., task for patients that have had this particular type of encounter) with the appropriate trigger definitions (e.g., query criteria, FHIRpath, etc.).
• Implementers are made aware of the topic and what it means externally (e.g., through documentation).
• Subscribers can filter based what is allowed in the SubscriptionTopic (e.g., if a subscriber is only interested in notifications for Patient/123).

Gino Canessa (Jan 28 2021 at 17:45):

For me, I like to think about the trigger being what the subscription is for (so must fully describe the event and change of interest), and exposed filters are for letting clients reduce to what they can/should/want to see of that set.

Anand Jahagirdar (Jan 30 2021 at 06:59):

Thanks for the clarifications @Gino Canessa

Last updated: Apr 12 2022 at 19:14 UTC