#Bser copy download series

TheReferral Initiator has modified information in the referral request. The Referral Initiator has prepared the referral request and forwarded it to a Referral Recipient from whom action is sought. The states and state transitions depicted in the referral request state machine diagram are defined in the following table. The following diagram depicts the states and applicable state transitions for the referrl request resource: 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 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 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 focus element of the message header contains a reference to the root resource of the message content (BSeR Referral Request or BSeR Referral Feedback).

Coded elements for event, reason, and response provide context for the message bundle. The message header contains references to the sender and intended reciever of the message bundle. 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. However, the use of RESTful API between specific trading partners has not been ruled out. 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.

Some clinical, some semi-clinical, and some more akin to non-clinical social services. Referral recipients are anticipated to be a more diverse set of healthcare service providers. Referral initiator are anticipated to be traditional healthcare provider organizations (hospitals, clinics, phycian practices). 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. The kinds of functionality that the RESTful API and the messaging framework offer are very similar their primary difference is architectural in nature. The basic MessageHeader resource upon which the messaging framework is implemented is itself a resource that can treated in a RESTful approach. FHIR messaging and RESTful frameworks are related in that both share the same set of resources on which they operate.

If these middleware agents are modifying the message content, then they become responsible for honoring the contract that applies in both directions.ДЄdoption of the FHIR messaging framework does not rule out the use of alternative information exchange frameworks such as RESTful APIs. Either they are transparent to the message/transaction content and irrelevant to framework, or they are actively involved in manipulating the message content. 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. The agreements around the content of the messages and the behavior of the two applications form the 'contract' that describes the exchange. 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.

#Bser copy download series

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 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. 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.