Stream: implementers
Topic: Routing Slip
Kevin Mayfield (Sep 21 2018 at 06:58):
I’ve a project where a rest interface takes a bundle and then messages it to a number of recipients.
I’m thinking messageheader would be suitable for this but recipient is 0..1 but I think I could add in a list as an extension? I would leave the recipient filed blank and just populate sender.
Does that sound ok?
Grahame Grieve (Sep 21 2018 at 07:01):
definitely message header.
Grahame Grieve (Sep 21 2018 at 07:03):
all versions have destination 0..*
Kevin Mayfield (Sep 21 2018 at 08:16):
Maybe routing slip was the wrong term, at this stage it would be a distribution list and the middleware FHIR server then works out the destination (interaction style and physical addresses).
Grahame Grieve (Sep 21 2018 at 10:39):
well then you only need one destination
Kevin Mayfield (Sep 21 2018 at 13:54):
So it would be a List of recipients as an extension to a MessageHeader (on the rest side before it gets converted to one recipient and one destination as a message)
Lloyd McKenzie (Sep 21 2018 at 14:02):
You would list all of the intended destinations and pass the single message to your routing engine. It might then either split the message and change to a single header per destination or might just fan out the message and send it to each intended destination. Do you have a situation where you have one destination system but multiple recipients within that system?
Kevin Mayfield (Sep 23 2018 at 08:43):
Simple-Doc-API.jpeg
This is a 'fag packet' diagram, the interface on the left is where the distribution list would be received, steps 1+2 perform Endpoint queries and build the physical routing. Here the message would be fanned out.
I think I could use virtual devices for the destinations, so the MessageHeader.destination.target.identifier would refer to the Organization or Practitioner. At the fan out step, the MesssageHeader is converted to actual devices and actual recipient.
Kevin Mayfield (Sep 23 2018 at 08:49):
Technically we would have one destination system with multiple recipients. Majority of the endpoints need a transform, so ideally I would want to perform this once per route/endpoint and then fan the message out again. I'd probably handle this within the messaging system outside of FHIR for now.
Last updated: Apr 12 2022 at 19:14 UTC
