Project Scope: As the the need for integration between different actors in healthcare has grown, the aspect of transactions routings across one or more intermediaries such as clearinghouses and exchanges is recognized. An example of this scenario is when a payer uses a clearinghouse intermediary as their 'gateway' for transactions. There are both technical and business operational value adds in this intermediary model. This model was born in the world of the original X12 transaction set and it is expected to continue in the evolving RESTful FHIR API integration model. There are other examples as well such as HIEs/trust frameworks. In the model described above, the interaction originator will know the the final destination but will be abstracted from the number of intermediaries involved in the message routing. For example, if provider A needs to request information from payer B and payer B uses a payer agnostic intermediary, provider A will initiate the interaction with a known endpoint representing payer B, which in this case is an intermediary, and the intermediary will handle routing of the transaction and provide any value-add services. The intermediary, or intermediaries, will need to have origination and routing information available during the life-cycle of the transaction to ensure appropriate delivery. A variation of the use case is one in which the requester, provider A, simply provides the request to their intermediary who then provides routing information so that the transaction can move across additional intermediaries before getting to payer B. Of course, there are cases in which there are no intermediaries involved and the routing information is not explicitly needed, but there is no harm with it being available. Our goal is to provide a model which supports a hybrid model of point to point interaction as well as intermediary brokered interaction without the actors in either side needing detailed knowledge of how intermediary routing works. A reliable routing solution needs to support: • Consistent definition and representation of routing information • Synchronous and asynchronous models – support for push and pull models in synchronous and asynchronous patterns • A hybrid environment - transactions over both dynamic point to point and intermediary brokered models The planned approach is to create an IG which uses the model described as part of Custom Headers defined within the FHIR Exchange Module ( http://build.fhir.org/http.html#custom ) with proposed new “X-Originator” and “X-Destination headers. Solution advantages: • Common pattern, used for many years in healthcare and other industries • Lightweight • Works even when doing GET or POST (i.e., searches or matches), so if there is no FHIR resource being exchanged then routing information is still available • Universally usable, regardless of FHIR transaction – it’s resource agnostic Project Need: In today’s environment, FHIR integration is typically point-to-point without the need for routing information. As FHIR scales and given that an intermediary/multi-intermediary hybrid model will continue to exist in the industry as partners leverage intermediaries for technical and business operations value-add services, there is a need to support reliable multi-hop routing. Supporting Reference: This approach received positive feedback through FAST Subject Matter Expert (SME) Panel Sessions that took place in December 2019 and Summer 2020, as well as the FAST Workshop that took place in September 2020, with both groups providing input regarding the proposed solution approach for reliable transaction routing, the appropriate output and next steps, and the path forward to gain consensus on the proposed solution within the industry. Links to additional documentation: https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/FAST+HL7+FHIR+Standard+Based+Solution+for+Intermediary-to-Intermediary+Exchange+-+Expert+Panel+Discussion https://oncprojectracking.healthit.gov/wiki/download/attachments/118849815/FAST-PS-Exchange_Process_v2_062620.docx?version=1&modificationDate=1593187080074&api=v2