<a class="ig-section-edit" target="blank" href="https://oncprojectracking.healthit.gov/wiki/pages/editpage.action?pageId=18776126"><img src="https://oncprojectracking.healthit.gov/wiki/download/attachments/18776124/document_edit.png?api=v2" /></a>

<div class="ig-title-hidden">

Assumptions and Constraints for Transport and Payload

</div>

3.1 General Assumptions and Constraints

• All messages sent within the closed-loop referral workflow MUST be sent in accordance with the Direct Applicability Statement. As per the Direct Applicability Statement section 6.0 (security considerations), the Full Service HISP and Simple SMTP models are supported.
• All payloads sent as part of the Directed messages referral workflow SHALL be sent and handled in accordance with theXDR and XDM for Direct Messaging Specification.
• The initial referral request will be limited to a referral initiator and a referral recipient. To solve additional needs, such as forwarding, the referral recipient is expected to create a new referral request or recommend additional requests be created by the referral initiator.
• Due to practical limitations in the physical layer of the transport mechanism, messages will be limited to 20MB in total size.
• The referral initiator's address and the referral recipient's address are addresses per the referenced standards that may represent an individual or group of individuals (i.e., "Dr. Smith" or "Springfield Cardiology Practice Group") and, therefore, the EHRT and/or users may need to handle the appropriate routing and management of messages.

3.2 Referral Initiator's Office Assumptions and Constraints

• The referral initiator MAY NOT be aware of the referral recipient's Direct and 360X capabilities. Consequently, all messages MUST be sent as SMTP + S/MIME unless the full capabilities of the referral recipient are known.
• The referral initiator MUST send the full payload upon initiating the referral request unless the full capabilities of the referral recipient are known to not support 360X. If there is an existing agreement beyond the scope of this document, initial referral requests MAY use a partial payload until the referral request is accepted.
• The referral initiator MAY use a Provider Directory to determine the referral recipient's Direct capabilities.
• The referral initiator MUST use a Direct-addressable endpoint that is capable of receiving a subsequent response from the referral recipient.
• The referral initiator MUST have the ability to accept and parse a 360x payload.
  • Optional payloads are left to the discretion of the referral recipient's EHRT, but they must be appropriately handled by the referral initiator's EHRT.
• In order to be compliant with all Directed certification processes, and to accommodate partners who are NOT 360X compliant, the sender MUST send the C-CDA as both a MIME part (attachment) and a document within the XDM package.

3.3 Referral Recipient's Office Assumptions and Constraints

• The referral recipient MUST have the ability to accept/decline and parse a 360x payload.
• The referral recipient is responsible for the appropriate storage and disposal of declined referrals.

3.4 Patient Identifiers

• The referral initiator MUST provide a unique patient identifier with the initial referral request, and must use the same patient identifier in any subsequent communications throughout a single referral information exchange. This identifier SHALL be present in the metadata for the XD submission set and document entries, and in the PID segment of the HL7 V2 messages. The identifier SHOULD be present in the C-CDA document header.
• The referral initiator MUST use one of two options for the patient identifier:
  • a unique patient identifier known to the message initiator. In the XD Metadata, this identifier SHALL be present in the sourcePatientId attribute of each and every document entry.
  • a unique patient identifier commonly known to both the referral initiator and the referral recipient. The method by which this knowledge is obtained is outside the scope of this implementation guide, and it may include communication with other parties, such as a regional HIE, an MPI, etc. In the XD Metadata, this identifier SHALL be present in the patientId attribute of the submission set, and the patientId attribute of each and every document entry.
• The referral recipient MUST use the unique patient identifier provided in the initial referral request in any subsequent communications with the referral initiator throughout a single referral information exchange. This identifier SHALL be present in the metadata for the XD submission set and document entries, and in the PID segment of the HL7 V2 messages. The identifier MAY be present in the C-CDA document header.
• The referral recipient MAY provide another unique patient identifier in any subsequent communications for the purpose of simplifying future communications between the two systems. Any further use of additional patient identifiers is outside the scope of this Implementation Guide.

3.5 Referral identifier

• The referral initiator MUST provide a unique identifier for the referral with the initial referral request, and must use the same referral identifier in any subsequent communications throughout a single referral information exchange. This identifier SHALL be present in the metadata for the XD submission set and document entries, and in the ORC and OBR segments of the HL7 V2 messages. The identifier MAY be present in the C-CDA referral section.
• The referral recipient MUST use the unique referral identifier provided in the initial referral request in any subsequent communications with the referral initiator throughout a single referral information exchange. This identifier SHALL be present in the metadata for the XD submission set and document entries, and in the ORC segment of the HL7 V2 messages. The identifier MAY be present in the C-CDA document header.

3.6 Reason for Referral

• The reason for referral SHALL be communicated with the HL7 V2 OBR segment and SHALL be included in the C-CDA Reason for Referral Section.
• The purpose of the reason for the referral in the HL7 V2 OBR segment is to enable the receiver of the referral to manage the referral request to make the appointment. The purpose of the reason for referral in the C-CDA document is to possibly convey more detailed supporting clinical information that the provider can use to prepare for the referral using, e.g., free text.