This page is part of the Bidirectional Services eReferrals (BSeR) (v0.2.0: STU 1 on FHIR STU3 Ballot 2) based on FHIR R3. The current version which supercedes this version is 1.0.0. For a full list of available versions, see the Directory of published versions 
This version of the BSeR FHIR Implementation Guide make use of FHIR messaging framework as the primary paradigm for the exchange of a Referral Request from the Referral Initiator to the Referral Recipient and the Referral Feedback from the Referral Recipient to the Referral Initiator.
The FHIR messaging framework assumes that content will be delivered from one application to another by some delivery mechanism, and then one or more responses will be returned to the source application. The exact mechanism of transfer is irrelevant to framework, but may include file transfer, HTTP based transfer,MLLP (HL7 minimal lower layer protocol), MQ series messaging or anything else. The only requirement for the transfer layer is that requests are sent to a known location and responses are returned to the source of the request.
The agreements around the content of the messages and the behavior of the two applications form the "contract" that describes the exchange. The contract will add regional and local agreements to the rules defined in framework.The FHIR messaging framework, and by implication this implementation guide, ignores the existence of interface engines and message transfer agents that exist between the source and destination. Either they are transparent to the message/transaction content and irrelevant to framework, or they are actively involved in manipulating the message content. If these middleware agents are modifying the message content, then they become responsible for honoring the contract that applies in both directions.
Adoption of the FHIR messaging framework does not rule out the use of alternative information exchange frameworks such as RESTful APIs. FHIR messaging and RESTful frameworks are related in that both share the same set of resources on which they operate. The basic MessageHeader resource upon which the messaging framework is implemented is itself a resource that can treated in a RESTful approach. The kinds of functionality that the RESTful API and the messaging framework offer are very similar; their primary difference is architectural in nature.
The messaging framework was selected as the primary paradigm for this version of the BSeR FHIR implementation guide because of the great variability in the kinds of organizations and spectrum of technical sophitication expected. Referral initiator are anticipated to be traditional healthcare provider organizations (hospitals, clinics, phycian practices). Referral recipients are anticipated to be a more diverse set of healthcare service providers. Some clinical, some semi-clinical, and some more akin to non-clinical social services.
The messaging framework is useful for this cohort of players because it requires less in way of technical infrastructure, trading partner agreements, and concern for privacy and security with regard to exposed clinical content. However, the use of RESTful API between specific trading partners has not been ruled out.
The information payload exchanged between intiator and recipient is a message bundle (a bundle with bundle.type = 'message') with message header as the first resource in the bundle. The message header contains references to the sender and intended reciever of the message bundle. Coded elements for event, reason, and response provide context for the message bundle. The focus element of the message header contains a reference to the root resource of the message content (BSeR Referral Request or BSeR Referral Feedback).
The following diagram exposes the details of the request and feedback message header profiles and illustrates how each is used to by the referral initiator and referral recipient.
The referral request state machine illustrates the various states or statuses a referral request undergoes as it is subjected to triggering events performed by the referral initiator and the referral recipient. The end state of a state transition is used as the value for the message header reason when sending the request or feedback message bundle.
The following diagram depicts the states and applicable state transitions for the referrl request resource:
The states and state transitions depicted in the referral request state machine diagram are defined in the following table.
| Trigger ID | Trigger Event | Actor | Starting State | Ending State | End State Description |
|---|---|---|---|---|---|
| 1 | Submit | Referral Initator | Start | Submitted | The Referral Initiator has prepared the referral request and forwarded it to a Referral Recipient from whom action is sought. |
| 2 | Revise | Referral Initator | Submitted | Modified | TheReferral Initiator has modified information in the referral request. |
| 3 | Resubmit | Referral Initator | Modified | Submitted | The Referral Initiator has forwarded a modified version of the referral request to a Referral Recipient from whom action is sought. |
| 4 | Withdraw | Referral Initator | Submitted | Withdrawn | The Referral Initiator has withdrawn the referral request by informing the Referral Recipient prior to completion that no further action is being sought. |
| 5 | Close | Referral Initator | Submitted | Completed | The Referral Initiator has closed the referral request following completion by the Referral Recipient indicating that the referral request has been fulfilled and no futher action is being sought |
| 6 | Revise | Referral Initator | Rejected | Modified | The Referral Initiator has modified information in the referral request in response to a rejection by the Referral Recipient |
| 7 | Withdraw | Referral Initator | Rejected | Withdrawn | The Referral Initiator has withdrawn the referral request in response to a rejection by the Referral Recipient |
| 8 | Receive | Referral Recipient | Submitted | Received | The Referral Recipient has claimed ownership of the referral request and is evaluating whether to perform it. |
| 9 | Accept | Referral Recipient | Received | Accepted | The Referral Recipient has agreed to execute the referral request but has not yet started work. |
| 10 | Begin | Referral Recipient | Accepted | In Progress | The Referral Recipient has started to act upon the referral request but is not yet complete. |
| 11 | Hold | Referral Recipient | In Progress | On Hold | The Referral Recipient has started to act upon the referral request but work has been paused. |
| 12 | Resume | Referral Recipient | On Hold | In Progress | The Referral Recipient has resumed acting upon the referral request following a pause, but is not yet complete. |
| 13 | Finish | Referral Recipient | In Progress | Completed | The Referral Recipient has successfully completed acting upon referral request. |
| 14 | Reject | Referral Recipient | Received | Rejected | The Referral Recipient has decided not to act upon the referral request as received from the Referral Intiator |
| 15 | Fail | Referral Recipient | On Hold | Aborted | The Referral Recipient is unable to resume action upon a paused referral request due to a processing exception |
| 16 | Cancel | Referral Recipient | Accepted | Cancelled | The Referral Recipient has decided not to act upon referral request it previously accepted but did not start to act upon. |
| 17 | Fail | Referral Recipient | In Progress | Aborted | The Referral Recipient is unable to continue acting upon the referral request due to a processing exception |
