Stream: IG creation
Topic: Event Notifications
Kevin Mayfield (Jan 08 2022 at 08:23):
The easiest way to describe this is we are going through a transition from traditional messaging to events.
Long term I expect this will end up as FHIR Workflow but we a several months/years away from that.
So currently in FHIR (mostly STU3) we have FHIR Messages which mimic HL7v2 behaviour.
The current trend is pushing towards sending references around (either resource and/or identifier references).
With a logical model starting to look similar to a HL7v2 EVN segment https://hl7-definition.caristix.com/v2/HL7v2.8/Segments/EVN
plus a
- Patient identifier reference
- resource identifier/resource reference.
It is not like the logical event model https://www.hl7.org/fhir/event.html, maybe some similarities to https://www.hl7.org/fhir/messageheader.html or https://www.hl7.org/fhir/task.html
Kevin Mayfield (Jan 08 2022 at 08:39):
To model this I'm not sure which resource to use (the initial model is leaning towards OperationDefinition and Parameters).
The rough plan is below :
Screenshot-2022-01-08-at-08.52.26.png
Kevin Mayfield (Jan 08 2022 at 08:47):
2 - the EVN resource plus an actual resource is sent to a FHIR Subscription service
3 - if a matching subscription is found. A FHIR Message is generated which contains the EVN resource (the actual resource is stripped for Information Governance reasons).
If we used Task this would be easier 2 becomes POST /Task and the FHIR Message coming out just uses the Task resource.
(Maybe the answer is use Task now for the notification/information requirement but it seems a little wrong, as we have no Action requirement at present which seems to be reason for Task)
Lloyd McKenzie (Jan 09 2022 at 21:03):
Can you expand on "we have no Action requirement at present"?
Josh Mandel (Jan 10 2022 at 04:28):
@Gino Canessa has been looking at sending all around these kinds of references for the two triggered events using R4B/R5 style Subscription (with SubscriptionStatus and Parameters in a notification bundle)
Kevin Mayfield (Jan 10 2022 at 09:19):
@Lloyd McKenzie Have a large group who view HL7 as a way of transferring data (only) to central repositories. It's like a CSV or ETL process.
A common description I've heard is a referral or prescription is lobbed over the wall which comes from people aware the data transfer lacks business process and we should be focusing around the information events or action (workflow) request/response)
Gino Canessa (Jan 10 2022 at 16:14):
Hi Kevin, as @Josh Mandel mentioned, I think this type of workflow should work well with the updated subscriptions specs. There are definitions in R4B (plus an IG) and in R5, but I'll use the R5 version here since everything is kept together in the spec (same functionality in R4B, just with accommodations for what couldn't be changed in a point release).
An overview in the spec is here. I have also created a lot of walkthrough videos and such (actually updating a set today for the connectathon =).
That said, a quick TL;DR is:
- topic-based subscriptions (see SubscriptionTopic)
- includes FHIR-based definitions and the ability to use an externally defined 'event' via CodeableConcept
- includes 'shape' definitions, so that related resources can be described for inclusion
- new bundle type (Subscription Notification), with the intent to be able to tailor the bundle to notifications
- includes a SubscriptionStatus resource, with meta/status/etc. information for the notification
- allows for different 'levels' of payload (no contents, ids only, or full resources)
- extended channel types, so additional protocols/formats/etc. can be used.
I think those would be the parts that are relevant to the use you are describing. I'd be happy to chat or provide additional info.
Kevin Mayfield (Jan 11 2022 at 05:43):
Many thanks for that. Looks exactly like what we are after.
Will come back with more detailed feedback.
Last updated: Apr 12 2022 at 19:14 UTC
