### 2) Submit eReferral - Direct ![alt text][eReferral Diagram] [eReferral Diagram]: https://content.screencast.com/users/jdoleweerd/folders/Snagit/media/9c0fe487-f934-4052-a181-d6dd0991f08f/2017-10-02_16-35-11.png "eReferral Process Flow Map" [referralRequest Resources]: https://content.screencast.com/users/jdoleweerd/folders/Snagit/media/d7cfa8c4-8722-47b9-9a03-a6bddac2e8d9/2017-11-12_17-51-00.png "ReferralRequest Resource Relationships" ### Description An eReferral is transmitted using [/ReferralRequest](https://www.hl7.org/fhir/referralrequest.html) as the primary resource. Routing is performed based on the contents of the included [/HealthcareService](https://www.hl7.org/fhir/healthcareservice.html) resource (usually retrieved during the [Choose Recipient](https://simplifier.net/ui/ig/eRefferaldraftiGuide/ChooseRecipient-Direct) process). Attachments can be included with the eReferral, as well as a text/HTML-based summary of the eReferral. ### Key FHIR Resources The key resources in the /ReferralRequest are: 1) [/ReferralRequest](https://www.hl7.org/fhir/referralrequest.html) - This is the primary resource of an eReferral, which references all other relevant resources. i) [/Patient](https://www.hl7.org/fhir/patient.html) - Contains the information about the patient who is the subject of the eReferral ii) [/Practitioner](https://www.hl7.org/fhir/practitioner.html) - The eReferral requester iii) [/Organization](https://www.hl7.org/fhir/organization.html) - Organization of the eReferral requester iv) [/HealthcareService](https://www.hl7.org/fhir/healthcareservice.html) - Specifies the target destination of the eReferral (note: also has an /Organization, /Practitioner, /Location, and /Endpoint resource) ![alt text][referralRequest Resources] Other supporting resources include: 1) [/Task](https://www.hl7.org/fhir/task.html) - Used to track the status of the referral as it progresses. 2) [/DocumentReference](https://www.hl7.org/fhir/documentreference.html) - Used to reference documents attached to the referral 3) [/Binary](https://www.hl7.org/fhir/binary.html) - Data payload for attachments ### Request - Submit eReferral Sending an eReferral has three key components: 1) Build a /Bundle including the /ReferralRequest and other relevant resources 2) Include the target /HealthcareService in the payload for routing (usually retrieved during the [Choose Recipient](https://simplifier.net/ui/ig/eRefferaldraftiGuide/ChooseRecipient-Direct) process) 3) POST to the target service's /Endpoint (which is specified in the/HealthcareService) 'POST [endpoint.address]' Referral **attachments** may be included by using the *ReferralRequest.SupportingInfo* element to reference a [/DocumentReference](https://www.hl7.org/fhir/operationoutcome.html) resource, which in turn references [/Binary](https://www.hl7.org/fhir/operationoutcome.html) resources. Small /Binary attachments can be included in the transmission [/Bundle](https://www.hl7.org/fhir/bundle.html). Large /Binary attachments should be included as references. Due to potential API performance and reliability issues, any /Binary over 100kb should be sent as a reference. A referral **text/HTML summary** can be included using the *http-response-header - additional_referral_info*, formatted as HTML, to send custom data that is not otherwise mapped to FHIR data elements. ### Response The response will be an [/OperationOutcome](https://www.hl7.org/fhir/operationoutcome.html) bundle that shows how the receiving system is storing the /ReferralRequest. For example, if a field is removed by the receiving system because it is unnecessary for the referral, it will also be omitted in the returned /OperationOutcome resource. If the receiving system adds some information upon reception, then it will also be added to the /OperationOutcome. ### Extensions - **http-response-header - additional_referral_info** - In the submission package, this HTML value can be used to summarize data that is not otherwise captured in the FHIR dataset. For example, the referral dataset may non-FHIR data elements such as "food preferences", "smoker/non-smoker", "therapies requested", etc... This is to support the variety of data structures that may come from sending systems, and the wide variety of data fields that may be requested on a referral form. - **http-response-header - redirect_path** - In the response package, this extension is used to return the *redirect_path* variable. The *redirect_path* is a URL that can be used to launch a web page that allows the user to further view or manipulate the referral, according to the business logic provided by the receiving system. The URL is is temporarily authenticated (2min), and is meant to be used immediately after eReferral submission. Some examples of business logic that could be made available at the URL include (but are not limited to): - Graphical presentation the referral in a web form - Enable the sender to modify/add information to the referral through a web interface - Enable the sender to select more services associated with the referral - Enable the sender to send additional secure messages to the recipient Example: `"extension": [ { "url": "http://hl7.org/fhir/StructureDefinition/http-response-header", "valueString": "redirect_path: https://www.fhirserver.com/referralrequest/663280?session_token=jo135rua2iqbakdg6nag" },` ### Other Notes - While */Practitioner* and */Organization* are also valid resources for the **recipient** element according to the FHIR specification (in addition to /HealthcareService), using them as the recipient for eReferrals presents a number of practical challenges: 1) Neither the */Practitioner* nor */Organization* resources have an */Endpoint* resource to specify where to route eReferrals 2) Sending to an /Organization is insufficiently specific when organization provides more than one service (which most do). 3) The /Practitioner resource is insufficiently specific for multi-disciplinary teams (a common scenario), or when practitioners work with multiple /HealthcareServices. - Resources within the /ReferralRequest can be included in the bundle, or can reference an external URL. It is expected that in many cases the resources would be included in the /bundle when the sending system cannot provide endpoints to service FHIR resources. However, when possible, it preferrable to user external references. ### MORE INVESTIGATION NEEDED - How to apply the /Task resource? ### FOR FURTHER DISCUSSION - Q: Is the http-response-header the best extension to use for the 2 extensions here? - A: The best i've found so far... -Tim - Q: Should the *redirect_path* extension be time-limited? - A: Yes, available for a few minutes only. If it's going to be accessed later, then should re-request access to it via another method (probably through a GET /referralrequest). -Tim B - Q: Should the *redirect_path have an additional variable that specifies if it is mandatory or optionally used to complete a referral? For example, some eReferrals may require that additional fields or choices are completed online after submitting the initial dataset. - statement note: considering requester.agent as a patient or related person for the use case of patient portals... - note: consider not allowing address to go though in the search call and restricing to latlong to avoid the complexity of multipe resolutions/back and forth for calls - A: Probably yes... -Tim B - Use composition for building the text based version of the referral data: https://www.hl7.org/fhir/composition.html