...

The Trusted Exchange Framework Common Agreement™, known as TEFCA™, operates in the United States as a nationwide framework for health information sharing. It was created to remove barriers for sharing health records electronically among healthcare providers, patients, public health agencies, and payers.

360X describes the use of referral-specific payloads that enable the management of end-to-end (closed-loop) referrals. Given that the TEFCA "push" interactions are based on XCDR, a related IHE profile to XDR, there could be a relatively straight-forward path for enabling 360X on TEFCA. 

...

1. Enable the mapping of the referral targets (currently Direct addresses in 360X) to TEFCA endpoints and Responding Nodes, and describe the routing. This includes:
   - enhancing the provider directory to indicate support for 360X
   - TEFCA or IHE profiling how SubmissionSet.intendedRecipient and author can be used to indicate the precise recipient and sender (most people will probably want to use Direct address for this purpose for now, but we would want to consider how other identifiers might be used).
   - requirements on the TEFCA Responding Node to be able to understand those values and route the message accordingly, or return an error if the value is unrecognized and/or routing is not possible. 
2. Describe an XCDR transport option in the IHE specification that enables the sending and receiving of 360X transactions across communities, allowing TEFCA to then reference it.

Planning

1. IHE change proposal to add explicit handling of SubmissionSet.intendedRecipient: https://wiki.ihe.net/index.php/ITI_XCDR_Endpoint_Addressing
   1.  Ideas on recipient identifiers
   2. How can we make sure directories work with this - dioscussion
      
      1. Use sub-organizations - already in TEFCA
      2. other directories 
      3. End user changes need to be avoided 
      4. Maintenance - provider directories inside the EHR vs QHIN