FHIR Chat · Subscription message triggers

Stream: implementers

Topic: Subscription message triggers

Kevin Mayfield (Jan 08 2020 at 08:41):

I'm working on a scenario of something like 'If patients is admitted to ED with an asthma condition send a Medication review to their GP (primary carer or organisation)'.

That's likely to be a message either HL7v2 ORM^O01 or FHIR equivalent and I'm not expecting for pub/sub to build the message or handle the delivery. I think I need a message-trigger channel which contains:

EventCode (e.g. ORM^O01)
Recipient (endpoint)
Triggering resource (payload?)

{
  "channel": {
    "type": "message-trigger",
  "eventCoding": {
    "system": "http://example.org/fhir/message-events",
    "code": "order"
  },
    "endpoint": {
     "identifier": {
            "system": "https://fhir.hl7.org.uk/Id/gmc-number",
            "value": "C3456789"
          }
     }
  }
}

Kevin Mayfield (Jan 08 2020 at 08:45):

Is this the best of doing this? I wouldn't expect the subscription handler to know how to send the message at this point (in my use case I think this would result in a HL7v3 message or an email)

Kevin Mayfield (Jan 08 2020 at 08:55):

Seems like I'm describing R5 Subscription and main difference is using something like reference for endpoint.

Gino Canessa (Jan 08 2020 at 20:26):

Hi Kevin. First, apologies if this is a little disjointed - I'm at a connectathon and have had this open for a few hours. I'm going to try and tackle your question in parts, with a few questions. I'm going to go through it in Subscriptions R5:

1) I would start with basic Encounter-Start topic, and derive a new topic to add filtering for Encounter.class, which would allow a Subscription.filterBy on Encounter.class='EMER'.

2) To filter on asthma would be the same process (likely same step, no need to derive twice).

This process should work well if your use cases map well (e.g., the same topic will be useful for any type of admission and any condition). IF this is representative of a class of scenarios with different fields, we should open some discussions on how to put events into SubscriptionTopics (e.g., have a topic which is defined solely by the event).

On the other side, I would recommend using a standard channel (e.g., REST) to get the notification to another internal system, which could then build the specific graph and forward on the notification in whatever channel fits your workflow.

Kevin Mayfield (Jan 09 2020 at 06:53):

Yep that's sounds good. I need to research messaging side a little more, I think I may just want to start a workflow - that could be rest channel to a process that converts it to a full message.

Kevin Mayfield (Jan 10 2020 at 09:22):

On second thoughts what I'm wanting out from the Subscription is pass a message to pass to the another process to action the subscription.... Something like a message-hook channel which outputs a message bundle and includes:

MessageHeader[1..1]
Resource[0..1] (rest-hook)
eventCoding[0..1] (for message)
Communication[0..1] (for SMS and email]

This is based at looking at HAPI and wanting to decouple delivery from the server.

Eric Haas (Jan 13 2020 at 00:32):

@Kevin Mayfield are you referring to using the messaging channel? to output from a subscription a message?

Kevin Mayfield (Jan 13 2020 at 08:22):

In part yes but I'm thinking the role of a subscription service (especially in a epr/ehr) is mainly to trigger events. It shouldn't action the events (build a fhir message, deliver sms or email).
So in hapi jpa, subscription works as is but events (email, sms, message--trigger) are sent to middleware (service) such as apache camel to action.

A subscription in a middleware service would work as is.

Wonder if I'm describing new channel types?

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Subscription message triggers · implementers