Stream: Canadian eReferral
Topic: Message return values in the response
Jonathan Fishbein (Mar 04 2021 at 18:37):
Going to kick this stream off with the inaugural question!
Been working through the Ontario eReferral Specification (https://simplifier.net/guide/eReferral-Ontario/Home) and curious more generally what's expected the message response from a receiving system. FHIR messaging seems to suggest that application specific responses can be returned if needed, so what is expected here? Is it just a 200 (or error response with an OperationOutcome resource?) Is it the current, processed state of the referral reflected back in a Bundle? A reflection of the incoming payload?
Lloyd McKenzie (Mar 05 2021 at 03:51):
It depends. If functioning in async mode, you'd get back a simple 200 with no payload indicating that the message had been delivered and persisted (so you don't need to resend). If it's operating in synchronous mode, you might get the same - if the MessageDefinition didn't indicate there were expected responses. Otherwise you'd get back a 'message' Bundle that contains the response message - compliant with one of the allowed MessageDefinitions for the response.
Jonathan Fishbein (Mar 06 2021 at 16:03):
Thanks for tips @Lloyd McKenzie. The Ontario eReferral Specification guide does not specify whether the messages should be sent synchronously or asynchronously (I'm defaulting to synchronous processing) not does it include MessageDefinitions for the messages it outlines. Definitely something to consider adding as the specification evolves.
Lloyd McKenzie (Mar 06 2021 at 18:01):
In some cases, the decision of synchronous vs. asynchronous might be made by the server. It might reject synchronously if something doesn't meet the rules that can be checked computably, while only accept synchronously (after a human's had a chance to look at it)
Lloyd McKenzie (Mar 06 2021 at 18:01):
Certainly including MessageDefinitions in the spec would be a good idea
Lloyd McKenzie (Mar 06 2021 at 18:02):
I'd also love to see work on how to do eReferrals in a purely RESTful manner - if we think there are applications that can handle that. (It requires the ability to query data.
Tim Berezny (Mar 11 2021 at 00:28):
In the current version of the eReferral spec, you'd just expect back a 200 with an operationOutcome. This is if you submit a referral directly.
HOWEVER, if the referral were submitted via a SoF method, you would expect back a "notify-add-service-request". Note: as per our recent new event discussions, this event would be re-titled "add-task-pr", which contains the referral data as interpreted by the target system, and the newly created process-referral task.
It may be (probably would be) appropriate to expect this message back in the direct referral method as well.
MessageDefinitions sounds like something we need to look in to...
Tim Berezny (Mar 16 2021 at 21:17):
@Jonathan Fishbein , I've been pondering this, and I think that when submitting a referral I could go either way for a synchonous vs async appoach.
Synchronous: The target referral system responds to the add-servicerequest event with its full representation of the servicerequest + Task (process-request) resource.
Asyncronous: The target referral system responds with a simple 200, then sends another event to the source system code=add-task-process-request (as per the event codes we've been discussing at the eReferral committee. FLOW DIAGRAM SCREENSHOT.
Note that currently the Caredove-Ocean integration uses the Async approach, because there is an inherent delay between when Ocean creates the request (when it opens the Caredove form) and when Caredove creates its version of the request (when "Submit" in clicked in Caredove).
Jonathan Fishbein (Mar 16 2021 at 22:52):
@Tim Berezny Was thinking about this too, and I actually don't think it matters much in our case. Most of the referral processing is designed to work asynchronously anyways with the events getting passed back and forth on referral status/state changes as the asynchronous responses. There really isn't a required asynchronous response or synchronous response for any of our messages (we have no real ack response) so if a system wants to process the messages synchronously, and can do so in a way that doesn't make the requester hang unreasonably, that's fine. If it wants to process it asynchronously, that's fine too because the next message in the workflow is kind of considered the asynchronous response.
Last updated: Apr 12 2022 at 19:14 UTC
