Stream: implementers
Topic: How to target a eReferral Destination
Tim Berezny (Aug 22 2017 at 17:25):
I am trying to design an architecture for ROUTING eReferrals.
I have a conceptual idea of giving referable services a "eReferral #", like a fax number or phone number, except that the value would be the target ENDPOINT for a /referralRequest. That way, as long as you know the services "eReferral #", you can send a ReferralRequest /bundle to that endpoint, and it will land in the right spot. It could work very well with building directories or registries of services.
However, often many services might share an endpoint, so the routing to the right service would depend on the contents of the data package (particularly, the ID of he /healthcareService in the bundle). Also, i think this is probably the more standard way of approaching it from the FHIR perspective.
The reason i don't like the latter method as much is that that in order to route the package, you need to know TWO values, and endpoint and an ID. I like the simplicity of just publishing an endpoint, which will route a referralRequest /bundle to the right service.
So my question is, should i pursue the idea of using endpoints alone to route eReferrals, or stick with the ID/endpoint combo approach? (or pursue a different approach entirely)?
Brian Postlethwaite (Aug 28 2017 at 10:36):
Using the endpoint makes sense to me (that's how I plan to do it) and other information may need to be considered with routing, depending on the channel you use. Here in Australia there is a standard for doing this called SMD, and in the USA, I believe that the Direct messaging is used (don't know a greatdeal more than that)
Tim Berezny (Sep 05 2017 at 14:59):
Thanks @Brian Postlethwaite , Is this what you are referring to (SMD)?
Brian Postlethwaite (Sep 05 2017 at 22:13):
Yes, thats the stuff. There is lots of documentation on it there.
Sandeep Giri (Sep 10 2017 at 00:22):
How is the "target endpoint" you are describing different from the FHIR server url? If an EHR has a FHIR interface then a referring entity should be able to send in a referral by doing a "POST <fhir server url>/ReferralRequest", correct? In other words, if you and your referral submitter agree on using FHIR ReferralRequest resource to submit a referral, then all the submitter needs to know is your FHIR server url.. or, are you envisioning something different?
Brian Postlethwaite (Sep 10 2017 at 18:10):
That's correct, but if its not in FHIR, then could be a v2 messaging endpoint or direct details etc.
Tim Berezny (Nov 27 2017 at 17:59):
How is the "target endpoint" you are describing different from the FHIR server url? If an EHR has a FHIR interface then a referring entity should be able to send in a referral by doing a "POST <fhir server url>/ReferralRequest", correct? In other words, if you and your referral submitter agree on using FHIR ReferralRequest resource to submit a referral, then all the submitter needs to know is your FHIR server url.. or, are you envisioning something different?
Sorry i missed this comment in Sept @Sandeep Giri and @Brian Postlethwaite
Quick recap: I'm trying to target a SERVICE to refer to, kind of like how you would give a service a fax number, give it an eReferral number.
There are a few important caveats:
1) If your EMR has an endpoint to submit your referralRequest to, your service/EMR might actually support MANY different services. Thing of referring to a hospital outpatient unit. If i send to the hospital EMR endpoint, which outpatient unit does it go to? the EMR would have to configure an endpoint for each service.
2) If I send the referral as a /bundle (because maybe the sending system can't provide endpoints), the my understanding is you always submit to the <Fhir Server url>., instead of a specific subfolder/resource.
Both these things might be ok, and would require the receiving system to create a <fhir server url> that is unique for each target service. I am unsure if this is ok in the FHIR context still, or too complicated for the kinds of FHIR servers currently in popular use.
Lloyd McKenzie (Nov 27 2017 at 18:14):
Note that the content of the referral can provide an indication of who it's for/what is to be done that could support additional routing within an institution once received
Tim Berezny (Nov 28 2017 at 01:22):
Yes, that's the alternate approach that I think i'm leaning on now instead of trying to adopt a "eReferral #", include the target /healthcareService in the referralRequest. This seems to be the strong approach when factoring everything in. Thanks @Lloyd McKenzie
Sandeep Giri (Dec 04 2017 at 18:54):
having a central endpoint makes implementation easier (kind of like having a single email or fax # to catch all incoming service requests) -- then you can apply some "pre-processing logic" that looks at the various attributes in the ReferralRequest to route them to the appropriate entity. Some other options to consider -- the Direct project (https://www.healthit.gov/policy-researchers-implementers/direct-project ) has already assigned endpoints to a majority of health systems and clinics, you may be able to use that as a commonly known endpoint to receive referral requests, and implement your own logic for triaging and routing. Alternately, the EHR may also give you the option to implement logic where incoming referrals are assigned to different department's work queues.
Brian Postlethwaite (Dec 07 2017 at 08:39):
Yes, I considered that you could reference the endpoint from the healthcare service as someone mentioned. (needs to be discovered to put into the referral for sending)
Last updated: Apr 12 2022 at 19:14 UTC
