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

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

Transaction Contents

</div>

7.1 Referral Request Payload

7.1.1 Referral Request Package

The referral request will consist of an XDM package containing:

The format of the request will be an XDM package (containing the HL7 V2 Order, C-CDA and XD metadata), sent as an attachment of a Direct Protocol message.  Per the summary above, 360X does not specify the C-CDA nor its contents, but to qualify for MU objectives, CMS and ONC require the C-CDA contain the Common MU data Set (2014 Edition) or the Common Clinical Data Set (CCDS) (2015 Edition) and be of the specified version.  The document template used may be a CCD Summary of Episode Note (where industry has indicated that this is the "best fit" doc template for that data set) or a Referral Note template; both templates are allowed under the Meaningful Use program and 360X.

  

<div class="clr-fig-caption">Figure 7.1: 360X compliant transport protocol and referral request payload</div>

Note that in the current state of industry interoperability, many application providers support a C-CDA alone transmitted using Direct.  If an application needs to communicate to both 360X compliant applications and applications using exiting capabilities, a single message might be constructed as follows so as to avoid crafting different messages for different recipient capabilities.  

<div class="clr-fig-caption">Figure 7.2: 360X compliant application providing a single message to accommodate both 360X compliant and legacy recipients</div>

7.1.2 Referral Request : HL7 V2 General Clinical Order (OMG)

The 360X referral request package SHALL contain an HL7 V2 General Clinical Order, OMG^O19^OMG_O19 message as defined in the HL7 V2 message Payload Definition found in Appendix C.  The HL7 message is represented as a distinct document entry object in the XDM metadata, and it shall be present as a separate file within the XDM structure, with a file extension of .hl7.

A sample OMG^O19 message is provided here:

MSH|^~\&||^1.3.6.1.4.1.21367.2016.10.1.21^ISO||^1.3.6.1.4.1.21367.2016.10.1.32^ISO|20160930153834+0000||OMG^O19^OMG_O19|17882|P|2.5.1|||NE|NE|||||360X|
PID|1||T7190334^^^&1.3.6.1.4.1.21367.2016.10.1.21.5&ISO^MRN||Packton^Peter^^^L||19580817|M|
ORC|NW|889342^^1.3.6.1.4.1.21367.2016.10.1.21.15^ISO||||||||||34225PC^Allen^Anthony^M^III^MD^^^&1.3.6.1.4.1.21367.2016.10.1.21.10&ISO^L^^DN|
TQ1||||||||20161018235959+0000|
OBR||889342^^1.3.6.1.4.1.21367.2016.10.1.21.15^ISO||57133-1^^LN||||||||||||34225PC^Allen^Anthony^M^III^MD^^^&1.3.6.1.4.1.21367.2016.10.1.21.10&ISO^L^^DN|||||||||||||||^Rule out headache^|

7.1.3 Related Clinical Information: C-CDA

The 360X referral request package SHALL contain a C-CDA document for the related clinical information. The C-CDA is represented as a distinct document entry object in the XDM metadata, and it shall be present as a separate file within the XDM structure, with a file extension of .xml.The following spreadsheet contains the analysis of available C-CDA document and section templates:

RN_w_CCDS_sections_empty.xml
RN_w_CCDS_sections_empty.xml

 

RN_minimum_empty.xml
RN_minimum_empty.xml


7.1.4 XD Metadata Requirements

The XD metadata will represent the following information which includes and augments the data defined in the paragraph above, for the initial referral request. Defined below is the meta data for

7.1.4.1 Submission Set

AttributePurpose within 360XSource dataR/RE/C/O (Source of Requirement)
    
    
authorMUST indicate the message sender as a slot named "authorTelecommunication", see Extensions. When converted from an RFC 5322 message, MUST indicate the value of the from the header. Even though the authorPerson slot is required by IHE, since authorTelecommunication is valued the authorPerson may be omitted. R
(XDR and XDM for Direct Messaging)
intendedRecipientRecipient of the referral message – person, department, institution. Contains the Direct address. MUST indicate the message receiver. When converted from RFC 5322, MUST carry the recipient address. See Extensions for how to carry the Direct Address.
Note that this is not necessarily the provider who will perform or is asked to perform the referral; it is simply the message recipient which is negotiated at the time of implementation.
Direct Address from the SMTP message handlerR
(XDR and XDM for Direct messaging)
patientIdPer IHE for XD*, the patientId is as defined in context of the document registry (i.e. known to the message recipient), whereas the sourcePatientId (on the document entry) is in the context of the message initiator. The submission set patientId MUST be identical to the Document Entry patientId.
Note per above, source is PID-3 segment of the HL7 V2 OMG message where the value from the list of identifiers is the ID as known to the referral request recipient. If not known, this value may be empty.
See the discussion on patient identifiers in section 3.4
 R2
XDR and XDM for Direct messaging)
submissionTimePoint in time, as defined at the initiator of the message, of when the submission set was created. Shall be a single value. R
(XDM and XDR for Direct Messaging)
uniqueIdGlobally unique ID for the submission set. The format is an OID per IHE, assigned by the message initiator. This ID MUST be different than the uniqueId for any documentEntry.Generated and assigned by message initiating technologyR
(XDM/XDR)
contentTypeCodeDescribes the content of the submissions set57133-1 LOINC code indicates that this is a referral requestR
(360X)

7.1.4.2 Document Entry for the HL7 V2 OMG^O19^OMG_O19 message (Referral Request)

The document for the initial referral request SHALL be the HL7 V2 order message OMG^O19^OMG_O19 defined in section 3.1.1 in the Closed Loop Referral Implementation Guide: HL7 V2 message Payload Definition in Appendix C. Example message can be found in that document.

The XD meta data for the document entry, based on the minimal XDR data set and extended as needed for 360X is defined below.

AttributePurpose within 360XRequired (Source of Requirement)Corresponding HL7 Field/Component/Subcomponent
authorIf supplied, MUST indicate the document's (order) author, which may be different from the message sender. For the order, this is the clinician who is requesting the referral.>R2
(XDR and XDM for Direct Messaging)
Ordering Provider in ORC-12
classCodeIdentifies the specific document type, in this case an HL7 V2 Order.
See also typeCode which further refines the class definition and should not be ambiguous
R
(360X)
(R2 XDR and XDM for Direct Messaging)
Message Type in MSH-9.1 (OMG)
confidentialityCodeIdentifies the confidentiality defined for the order.
Implementations SHOULD NOT use codes that reveal the specific trigger causes of confidentiality (e.g., ETH, HIV, PSY, SDV)
R2
(XDR and XDM for Direct Messaging)
Confidentiality Code in ORC-28
Implementations SHOULD constrain to values that do not reflect the cause of confidentiality such as:
V Very restricted
R Restricted
U Usual control
creationTimeDefines the creation time of the message (vs. the order)R2
(XDR and XDM for Direct Messaging)
Date/Time of Message in MSH-7
entryUUIDThe identifier used for referencing the Document Entry object within the metadataR
(XDR and XDM for Direct Messaging)
N/A

eventCodeListThis list of codes represents the main clinical acts which does not conflict with the class and type codes. In this case, extends the document type (classCode=OMG, type=O19) to define the specific service requested.O
(IHE XDR)
Universal Service Identifier in OBR-4, CWE_2.1
Where XDR classification scheme is name of coding system in CWE_2.3
formatCodeGlobally unique identifier specifying the format of the document (referral request/order) to allow systems to determine if / how to process. 
For 360X can be formed from 
MSH-9 Message Type
MSH-12 Version ID
MSH-21 MessageProfileIdentifier
R
(360X)
OMG^O19_2.5.1_360XReferralRequest
healthcareFacilityTypeCodeSee also practice setting type. This code represents the type of organizational setting of the clinical encounter during which the documented act occurred. Note that in context of 360X, this is the facility type of the Referral Request Initiator.R2
(XDR and XDM for Direct)
Should be derived from / mapped to the information in ORC-21 through 24  
languageCodeSpecifies the language of the document (order / referral request)R2
(XDR and XDM for Direct)
Principal Language of Message in MSH-19
mimeTypeThe MIME type of the document
(XDR and XDM for Direct Messaging)
x-application/hl7-v2+er7
patientIdSee also sourcePatientID.
patient ID MUST be the same as the patientID in the submission set (which, not does not include the sourcePatientID) and all document entries.
Per IHE, is the ID as known to the referral request recipient / target document registry, if known. 
R2
(360X)
(R2 XDR and XDM for Direct Messaging)
The patientID in context of the message recipient (referral request recipient), if known, from the PID-3 list in the order.
Referral request acceptance/responses will include a sourcePatientID (ID in context of referral request recipient) which the initiator shall use as patientID in subsequent transactions to aid in matching.
sourcePatientIdSee also Patient ID.
The sourcePatientID is the ID as known by the document submitter (in this case, the referral request initiator). This ID Shall be the same as that for the C-CDA document meta data.
R
(360X)
The patient ID in the PID-3 list that represents the referral request initiator’s patient ID.
sourcePatientInfoRelevant patient demographics such as last name, first name, sex, DOB that may help in matching (electronically or by a person) if IDs are insufficient.R2 per XDR, O per IHE??PID-5, PID-7, PID-8 content should be used.
practiceSettingCodeIdentifies the setting that created the order at a high granularity e.g., Cardiology, FamilyPractice. Should not create ambiguity as compared to healthcareFacilityTypeCode.R2
(XDR and XDM for Direct)
Should be derived from/mapped to the information in ORC-21 through 24
typeCodeFurther refines classCode and should not make ambiguous. Defines the specific HL7 V2 message event type, for this message it is O19R
(360X)
MSH-9.2^9.3
OMG^O19^OMG_O19
uniqueIdGlobally unique identifier assigned to the document by its creator.R
(XDR and XDM for Direct Messaging)
May be based on Message Control ID in MSH-10

7.1.4.3 Document Entry for C-CDA


The Document Entry metadata is usually derived from the C-CDA header, as shown in the table below:

AttributePurpose within 360XRequired (Source of Requirement)Corresponding C-CDA element
authorIf supplied, MUST indicate the document's author, which may be different from the message sender. For the order, this is the clinician who is requesting the referral.
Note that C-CDAs are often multi-authored and author may be defaulted in the document.
R2
(XDR and XDM for Direct Messaging)
Author entry in US Realm header.
classCodeIdentifies the specific document type, in this case a C-CDA template (e.g., CCD, SOEN, Referral Note).
See also typeCode which further refines the class definition and should not be ambiguous 
R
(360X)
(R2 XDR and XDM for Direct Messaging)
Type ID entry in US Realm header.
confidentialityCodeIdentifies the confidentiality defined for the document. 
Implementations SHOULD NOT use codes that reveal the specific trigger causes of confidentiality (e.g., ETH, HIV, PSY, SDV) 
R2
(XDR and XDM for Direct Messaging)
ConfidentialityCode in US Realm Header
creationTimeDefines the creation time of the document (vs. the message)R2
(XDR and XDM for Direct Messaging)
effectiveTime in US Realm Header
entryUUIDGlobally unique identifier UUID for the document as assigned by the message sender and used only in the XD* handling. R
(XDR and XDM for Direct Messaging)
N/A
formatCodeGlobally unique identifier specifying the format of the document to allow systems to determine if / how to process. R
(360X)
Per the C-CDA specificaiton
healthcareFacilityTypeCodeSee also practice setting type. This code represents the type of organizational setting of the clinical encounter during which the documented act occurred. Note that in context of 360X, this is the facility type of the Referral Request Initiator.R2
(XDR and XDM for Direct)
N/A
languageCodeSpecifies the language of the document (order / referral request)R2
(XDR and XDM for Direct)
languageCode of US Realm Header
mimeTypeThe MIME type of the document
(XDR and XDM for Direct Messaging)
Currently the MIME type for CDA documents is simply "text/xml"
patientIdSee also sourcePatientID.
patient ID MUST be the same as the patientID in the submission set (which, not does not include the sourcePatientID) and all document entries.
Per IHE, is the ID as known to the referral request recipient / target document registry, if known. 
R2
(360X)
(R2 XDR and XDM for Direct Messaging)
N/A
sourcePatientIdSee also Patient ID.
The sourcePatientID is the ID as known by the document submitter (in this case, the referral request initiator). This ID Shall be the same as that for the C-CDA document meta data.
R
(360X)
targetID in US Realm Header
sourcePatientInfoRelevant patient demographics such as last name, first name, sex, DOB that may help in matching (electronically or by a person) if IDs are insufficient.R2 per XDR, O per IHE??Elements in patient section of US Realm Header such as name, administrative sex, birth time, etc.
practiceSettingCodeIdentifies the setting that created the order at a high granularity e.g., Cardiology, FamilyPractice. Should not create ambiguity as compared to healthcareFacilityTypeCode.R2
(XDR and XDM for Direct)
Should be derived from/mapped to the information in ORC-21 through 24
typeCodeFurther refines classCode and should not make ambiguous. Defines the specific C-CDA document type such as
<code code="34133-9" displayName="Summarization of Episode Note" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" />
R
(360X)
Code element from the US realm header
uniqueIdGlobally unique identifier assigned to the document by its creator.R
(XDR and XDM for Direct Messaging)
Id element (Globally unique identifier) in US realm header

7.2 Accept

7.2.1 Accept Payload

The accept referral payload is one of two REQUIRED responses to the referral request in the referral process necessary to indicate the transfer of patient care. By accepting the referral, the receiver will be expected to perform the treatment and/or provide the requested input per the specified reason for referral in the referral request. Provided the receiver cannot fulfill this obligation, the referral SHOULD be declined. This payload will consist of a XDM package (containing an HL7 status update message and associated metadata) as described below.

<div class="clr-fig-caption">Figure 7.3: 360X compliant transport protocol and accept payload</div>

7.2.2 Meaningful Use Required Data Elements

Meaningful use content is not required for this step in the process.

7.2.3 XD Metadata Requirements

Submission Set

AttributeSourceExpectations
sourceIdMSH-4R
patientIdPID-3R


Document Entry

AttributeSourceExpectations
creationTimeMSH-7R
classCodeMSH-9 component 1R
formatCodeMSH-9 component 3R
typeCodeMSH-9 component 2R
sourcePatientId O (patientId as represented by the specialist)
sourcePatientInfo  
- patient identifierPID-3R
- patient namePID-5R
- patient DOBPID-7O
- patient genderPID-8R
- patient addressPID-11O
servicStartTime Do not send
serviceStopTime Do not send
uri Should match the name of the hl7 file in the xdm zip


Example:
XDM package for an Accept Response

7.2.4 HL7 v2.5.1 OSU Accept object

Example:

MSH|^~\&||^1.3.6.1.4.1.21367.2016.10.1.32^ISO||^1.3.6.1.4.1.21367.2016.10.1.21^ISO|20161003092015+0000||OSU^O51^OSU_O51|19882|P|2.5.1|||NE|NE|||||360X|
PID|1||T7190334^^^&1.3.6.1.4.1.21367.2016.10.1.21.5&ISO^MRN~L53HG67^^^&1.3.6.1.4.1.21367.2016.10.1.32.11&ISO^MRN||Packton^Peter^^^L||19580817|M|
ORC|OK|889342^^1.3.6.1.4.1.21367.2016.10.1.21.15^ISO|||IP||||||||

7.3 Decline

7.3.1 Decline Payload

The decline referral payload is the other possible REQUIRED response to the referral request in the referral process. It is necessary to indicate to the initiator that the transfer of patient care will not be occurring with the declining provider. By declining the referral, the receiver will NOT be expected to perform the treatment and/or provide the requested input per the specified reason for referral in the referral request. This payload will consist of a XDM package (containing an HL7 status update message and associated metadata) as described below.

<div class="clr-fig-caption">Figure 7.4: 360X compliant transport protocol and decline payload</div>

7.3.2 Meaningful Use Required Data Elements

Meaningful use content is not required for this step in the process.

7.3.3 XD Metadata Requirements

7.3.3.1 Submission Set

AttributeExpectations
sourceIdMSH-4
patientIdPID-3

7.3.3.4 Document Entry

AttributeSourceExpectations
creationTimeMSH-7R
classCodeMSH-9 component 1R
formatCodeMSH-9 component 3R
typeCodeMSH-9 component 2R
sourcePatientId O (patientId as represented by the specialist)
sourcePatientInfo  
- patient identifierPID-3R
- patient namePID-5R
- patient DOBPID-7O
- patient genderPID-8R
- patient addressPID-11O
servicStartTime Do not send
serviceStopTime Do not send
uri Should match the name of the hl7 file in the xdm zip

Example:

7.3.4 HL7 v2.5.1 OSU Decline object

Example

MSH|^~\&||^1.3.6.1.4.1.21367.2016.10.1.32^ISO||^1.3.6.1.4.1.21367.2016.10.1.21^ISO|20161003092015+0000||OSU^O51^OSU_O51|22882|P|2.5.1|||NE|NE|||||360X|
PID|1||T7190334^^^&1.3.6.1.4.1.21367.2016.10.1.21.5&ISO^MRN~L53HG67^^^&1.3.6.1.4.1.21367.2016.10.1.32.11&ISO^MRN||Packton^Peter^^^L||19580817|M|
ORC|UA|889342^^1.3.6.1.4.1.21367.2016.10.1.21.15^ISO|||CA||||20130629074500|||||||^Unable to schedule patient within the timeframe requested|


 

7.4 Scheduled Notification

Schedule
Required: Ref ID + “Schedule" status from requesting provider or referral provider + appt date / time

7.4.1 Scheduled Notification Payload

<div class="clr-fig-caption">Figure 7.5: 360X compliant transport protocol and scheduled notification payload</div>

7.4.2 MU2 Required Data Elements

Meaningful use content is not required for this step in the process.

7.4.3 XD Metadata Requirements

7.4.3.1 Submission Set

AttributeExpectations
sourceIdMSH-4
patientIdPID-3

   

7.4.3.2 Document Entry

AttributeSourceExpectations
creationTimeMSH-7R
classCodeMSH-9 component 1R
formatCodeMSH-9 component 3R
typeCodeMSH-9 component 2R
sourcePatientId O (patientId as represented by the specialist)
sourcePatientInfo  
- patient identifierPID-3R
- patient namePID-5R
- patient DOBPID-7O
- patient genderPID-8R
- patient addressPID-11O
servicStartTime Do not send
serviceStopTime Do not send
uri Should match the name of the hl7 file in the xdm zip

 Example:

7.4.4 HL7 v2 Scheduled Notification object

Example:

MSH|^~\&||^1.3.6.1.4.1.21367.2016.10.1.32^ISO||^1.3.6.1.4.1.21367.2016.10.1.21^ISO|20161004142352+0000||SIU^S12^SIU_S12|31882|P|2.5.1|||NE|NE|||||360X|
SCH||18467^^1.3.6.1.4.1.21367.2016.10.1.32.14^ISO||||57133-1^^LN||||||||||^Name^Registrar||||^Name^Enterer||||||889342^^1.3.6.1.4.1.21367.2016.10.1.21.15^ISO|
TQ1|||||||20161009140000+0000|20161009143000+0000|
PID|1||T7190334^^^&1.3.6.1.4.1.21367.2016.10.1.21.5&ISO^MRN~L53HG67^^^&1.3.6.1.4.1.21367.2016.10.1.32.11&ISO^MRN||Packton^Peter^^^L||19580817|M|
RGS|1|A|
AIP|1||^Brown^Beatrice|

7.5 No Show Notification

The no show referral payload is an optional response preceded by a scheduled event in the referral process. Its purpose is to indicate to the referral initiator that the patient did not show for the scheduled appointment with the referral recipient. By indicating a referral is a no show, the receiver will NOT be expected to perform the treatment and/or provide the requested input per the specified reason for referral in the referral request. However, there is the option for the referral recipient to reschedule the appointment. This payload will consist of a XDM package (containing a HL7 SIU and associated metadata) as described below.

7.5.1 No Show Notification Payload

360xNoShowPayload.jpg

<div class="clr-fig-caption">Figure 7.6: 360X compliant transport protocol and no show notification payload</div>



7.5.2 MU2 Required Data Elements
Meaningful use content is not required for this step in the process.

7.5.3 XD Metadata Requirements

7.5.3.1 Submission Set

AttributeSourceExpectations
sourceIdMSH-4R
patientIdPID-3R

7.5.3.2 Document Entry

AttributeSourceExpectations
creationTimeMSH-7R
classCodeMSH-9 component 1R
formatCodeMSH-9 component 3R
typeCodeMSH-9 component 2R
sourcePatientId O (patientId as represented by the specialist)
sourcePatientInfo  
- patient identifierPID-3R
- patient namePID-5R
- patient DOBPID-7O
- patient genderPID-8R
- patient addressPID-11O
servicStartTime Do not send
serviceStopTime Do not send
uri Should match the name of the hl7 file in the xdm zip

 Example:

7.5.4 HL7 v2 No Show notification object

HL7 SIU^S26 Example:

MSH|^~\&||^1.3.63.998.999.3^ISO||^1.3.63.5444.345.2.1^ISO|20161010172813+0000||SIU^S26^SIU_S26|25882|P|2.5.1|||NE|NE|||||360X|
SCH||18467^^1.3.6.1.4.1.21367.2016.10.1.32.14^ISO||||57133-1^^LN||||||||||^Name^Registrar||||^Name^Enterer||||||889342^^1.3.6.1.4.1.21367.2016.10.1.21.15^ISO|
TQ1|||||||20161009140000+0000|20161009143000+0000|
PID|1||T7190334^^^&1.3.6.1.4.1.21367.2016.10.1.21.5&ISO^MRN~L53HG67^^^&1.3.6.1.4.1.21367.2016.10.1.32.11&ISO^MRN||Packton^Peter^^^L||19580817|M|
RGS|1|D|

7.6 Interim Consultation Note

Visit Summary – Requires Clinical Content / Payload (MU2 C-CDA)
Required: Ref ID + “Consult report (Interim)” status

7.6.1 Interim Consultation Note Payload

<div class="clr-fig-caption">Figure 7.7: 360X compliant transport protocol and interim consultation note payload</div>

7.6.2 MU2 Required Data Elements

7.6.3 XD Metadata Requirements


7.6.3.3 Document Entry for C-CDA


The Document Entry metadata is usually derived from the C-CDA header, as shown in the table below:

AttributePurpose within 360XRequired (Source of Requirement)Corresponding C-CDA element
authorIf supplied, MUST indicate the document's author, which may be different from the message sender. For the order, this is the clinician who is requesting the referral.
Note that C-CDAs are often multi-authored and author may be defaulted in the document.
R2
(XDR and XDM for Direct Messaging)
Author entry in US Realm header.
classCodeIdentifies the specific document type, in this case a C-CDA template (e.g., CCD, SOEN, Referral Note).
See also typeCode which further refines the class definition and should not be ambiguous 
R
(360X)
(R2 XDR and XDM for Direct Messaging)
Type ID entry in US Realm header.
confidentialityCodeIdentifies the confidentiality defined for the document. 
Implementations SHOULD NOT use codes that reveal the specific trigger causes of confidentiality (e.g., ETH, HIV, PSY, SDV) 
R2
(XDR and XDM for Direct Messaging)
ConfidentialityCode in US Realm Header
creationTimeDefines the creation time of the document (vs. the message)R2
(XDR and XDM for Direct Messaging)
effectiveTime in US Realm Header
entryUUIDGlobally unique identifier UUID for the document as assigned by the message sender and used only in the XD* handling. R
(XDR and XDM for Direct Messaging)
N/A
eventCodeListContains a list of codes that reflect the clinical events occurring as the source of the information contained in the C-CDA documentR2 (360X)
O (IHE)
When the 360X transaction occurs in an environment tracking eCQM measure CMS50vN, the eventCodeList SHALL contain at least one of the SNOMED CT codes from value set Consultant Report (2.16.840.1.113883.3.464.1003.121.12.1006), AND at least one of the SNOMED CT codes from value set Referral (2.16.840.1.113883.3.464.1003.101.12.1046)
formatCodeGlobally unique identifier specifying the format of the document to allow systems to determine if / how to process. R
(360X)
Per the C-CDA specificaiton
healthcareFacilityTypeCodeSee also practice setting type. This code represents the type of organizational setting of the clinical encounter during which the documented act occurred. Note that in context of 360X, this is the facility type of the Referral Request Initiator.R2
(XDR and XDM for Direct)
N/A
languageCodeSpecifies the language of the document (order / referral request)R2
(XDR and XDM for Direct)
languageCode of US Realm Header
mimeTypeThe MIME type of the document
(XDR and XDM for Direct Messaging)
Currently the MIME type for CDA documents is simply "text/xml"
patientIdSee also sourcePatientId.
The patientId attribute MUST be the same as the patientId in the submission set, and all document entries.
Per IHE, it is the ID as known to the referral request initiator, and it MUST be the same as the sourcePatientId of the Referral Request that was sent by the referral initiator.
R
(360X)
(R2 XDR and XDM for Direct Messaging)
N/A
sourcePatientIdSee also Patient ID.
The sourcePatientID is the ID as known by the document submitter (in this case, the referral request recipient). This ID Shall be the same as that for the HL7v2 document entry meta data.
R2
(360X)
targetID in US Realm Header
sourcePatientInfoRelevant patient demographics such as last name, first name, sex, DOB that may help in matching (electronically or by a person) if IDs are insufficient.R2 per XDR, O per IHEElements in patient section of US Realm Header such as name, administrative sex, birth time, etc.
practiceSettingCodeIdentifies the setting that created the order at a high granularity e.g., Cardiology, FamilyPractice. Should not create ambiguity as compared to healthcareFacilityTypeCode.R2
(XDR and XDM for Direct)
Should be derived from/mapped to the information in ORC-21 through 24
typeCodeFurther refines classCode and should not make ambiguous. Defines the specific C-CDA document type such as
<code code="34133-9" displayName="Summarization of Episode Note" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" />
R
(360X)
Code element from the US realm header
uniqueIdGlobally unique identifier assigned to the document by its creator.R
(XDR and XDM for Direct Messaging)
Id element (Globally unique identifier) in US realm header


7.6.4 HL7 v2 Interim Consultation Note object

Example:

MSH|^~\&||^1.3.6.1.4.1.21367.2016.10.1.32^ISO||^1.3.6.1.4.1.21367.2016.10.1.21^ISO|20161010142311+0000||OSU^O51^OSU_O51|20882|P|2.5.1|||NE|NE|||||360X|
PID|1||T7190334^^^&1.3.6.1.4.1.21367.2016.10.1.21.5&ISO^MRN~L53HG67^^^&1.3.6.1.4.1.21367.2016.10.1.32.11&ISO^MRN||Packton^Peter^^^L||19580817|M|
ORC|SC|889342^^1.3.6.1.4.1.21367.2016.10.1.21.15^ISO|||A|||||||34225PC^Allen^Anthony^M^III^MD^^^&1.3.6.1.4.1.21367.2016.10.1.21.10&ISO^L^^DN|

7.7 Referral Summary (Close the Loop)

Referral Summary (End of Episode) – Requires Clinical Content /Payload (MU2 C-CDA)
Required: Ref ID + “Consult report (Final)” status

7.7.1 Referral Summary Payload


<div class="clr-fig-caption">Figure 7.8: 360X compliant transport protocol and referral summary payload</div>

7.7.2 MU2 Required Data Elements


7.7.3 XD Metadata Requirements

7.7.3.1 Submission Set

7.7.3.2 Document Entry for HL7v2 Status Update message

7.7.3.3 Document Entry for C-CDA



The Document Entry metadata is usually derived from the C-CDA header, as shown in the table below:


AttributePurpose within 360XRequired (Source of Requirement)Corresponding C-CDA element
authorIf supplied, MUST indicate the document's author, which may be different from the message sender. For the order, this is the clinician who is requesting the referral.
Note that C-CDAs are often multi-authored and author may be defaulted in the document.
R2
(XDR and XDM for Direct Messaging)
Author entry in US Realm header.
classCodeIdentifies the specific document type, in this case a C-CDA template (e.g., CCD, SOEN, Referral Note).
See also typeCode which further refines the class definition and should not be ambiguous 
R
(360X)
(R2 XDR and XDM for Direct Messaging)
Type ID entry in US Realm header.
confidentialityCodeIdentifies the confidentiality defined for the document. 
Implementations SHOULD NOT use codes that reveal the specific trigger causes of confidentiality (e.g., ETH, HIV, PSY, SDV) 
R2
(XDR and XDM for Direct Messaging)
ConfidentialityCode in US Realm Header
creationTimeDefines the creation time of the document (vs. the message)R2
(XDR and XDM for Direct Messaging)
effectiveTime in US Realm Header
entryUUIDGlobally unique identifier UUID for the document as assigned by the message sender and used only in the XD* handling. R
(XDR and XDM for Direct Messaging)
N/A
eventCodeListContains a list of codes that reflect the clinical events occurring as the source of the information contained in the C-CDA document

R2 (360X)

O (IHE)

When the 360X transaction occurs in an environment tracking eCQM measure CMS50vN, the eventCodeList SHALL contain at least one of the SNOMED CT codes from value set Consultant Report (2.16.840.1.113883.3.464.1003.121.12.1006), AND at least one of the SNOMED CT codes from value set Referral (2.16.840.1.113883.3.464.1003.101.12.1046)
formatCodeGlobally unique identifier specifying the format of the document to allow systems to determine if / how to process. R
(360X)
Per the C-CDA specificaiton
healthcareFacilityTypeCodeSee also practice setting type. This code represents the type of organizational setting of the clinical encounter during which the documented act occurred. Note that in context of 360X, this is the facility type of the Referral Request Initiator.R2
(XDR and XDM for Direct)
N/A
languageCodeSpecifies the language of the document (order / referral request)R2
(XDR and XDM for Direct)
languageCode of US Realm Header
mimeTypeThe MIME type of the document
(XDR and XDM for Direct Messaging)
Currently the MIME type for CDA documents is simply "text/xml"
patientIdSee also sourcePatientId.
The patientId attribute MUST be the same as the patientId in the submission set, and all document entries.
Per IHE, it is the ID as known to the referral request initiator, and it MUST be the same as the sourcePatientId of the Referral Request that was sent by the referral initiator.
R
(360X)
(R2 XDR and XDM for Direct Messaging)
N/A
sourcePatientIdSee also Patient ID.
The sourcePatientID is the ID as known by the document submitter (in this case, the referral request recipient). This ID Shall be the same as that for the HL7v2 document entry meta data.
R2
(360X)
targetID in US Realm Header
sourcePatientInfoRelevant patient demographics such as last name, first name, sex, DOB that may help in matching (electronically or by a person) if IDs are insufficient.R2 per XDR, O per IHEElements in patient section of US Realm Header such as name, administrative sex, birth time, etc.
practiceSettingCodeIdentifies the setting that created the order at a high granularity e.g., Cardiology, FamilyPractice. Should not create ambiguity as compared to healthcareFacilityTypeCode.R2
(XDR and XDM for Direct)
Should be derived from/mapped to the information in ORC-21 through 24
typeCodeFurther refines classCode and should not make ambiguous. Defines the specific C-CDA document type such as
<code code="34133-9" displayName="Summarization of Episode Note" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" />
R
(360X)
Code element from the US realm header
uniqueIdGlobally unique identifier assigned to the document by its creator.R
(XDR and XDM for Direct Messaging)
Id element (Globally unique identifier) in US realm header


7.7.4 HL7 v2 Referral Summary object



Example:

MSH|^~\&||^1.3.6.1.4.1.21367.2016.10.1.32^ISO||^1.3.6.1.4.1.21367.2016.10.1.21^ISO|20161012170822+0000||OSU^O51^OSU_O51|21882|P|2.5.1|||NE|NE|||||360X|
PID|1||T7190334^^^&1.3.6.1.4.1.21367.2016.10.1.21.5&ISO^MRN~L53HG67^^^&1.3.6.1.4.1.21367.2016.10.1.32.11&ISO^MRN||Packton^Peter^^^L||19580817|M|
ORC|SC|889342^^1.3.6.1.4.1.21367.2016.10.1.21.15^ISO|||CM||||||||

7.8 Request to Cancel the Referral

The request to cancel the referral payload is an optional action potentially performed by the referral initiator during the referral process. Its purpose is to indicate to the referral recipient that the originally requested treatment is no longer necessary. By initiating a cancel request, the referral initiator SHOULD NOT expect the referral receiver to cancel the referral nor should the referral initiator expect a cancel confirmation. This payload will consist of a XDM package (containing a HL7 status update and associated metadata) as described below.

7.8.1 Request to Cancel Payload

<div class="clr-fig-caption">Figure 7.9: 360X compliant transport protocol and request to cancel payload</div>

7.8.2 MU2 Required Data Elements

Meaningful use content is not required for this step in the process.

7.8.3 XD Metadata Requirements

7.8.3.1 Submission Set

AttributeSourceExpectations
sourceIdMSH-4R
patientIdPID-3R

7.8.3.2 Document Entry

AttributeSourceExpectations
creationTimeMSH-7R
classCodeMSH-9 component 1R
formatCodeMSH-9 component 3R
typeCodeMSH-9 component 2R
sourcePatientId O (patientId as represented by the specialist)
sourcePatientInfo  
- patient identifierPID-3R
- patient namePID-5R
- patient DOBPID-7O
- patient genderPID-8R
- patient addressPID-11O
servicStartTime Do not send
serviceStopTime Do not send
uri Should match the name of the hl7 file in the xdm zip

Example:

7.8.4 HL7 v2 Request to Cancel object

Example:

MSH|^~\&||^1.3.6.1.4.1.21367.2016.10.1.21^ISO||^1.3.6.1.4.1.21367.2016.10.1.32^ISO|20161007092857+0000||OSU^O51^OSU_O51|23882|P|2.5.1|||NE|NE|||||360X|
PID|1||T7190334^^^&1.3.6.1.4.1.21367.2016.10.1.21.5&ISO^MRN||Packton^Peter^^^L||19580817|M|
ORC|CA|889342^^1.3.6.1.4.1.21367.2016.10.1.21.15^ISO||||||||||34225PC^Allen^Anthony^M^III^MD^^^&1.3.6.1.4.1.21367.2016.10.1.21.10&ISO^L^^DN||||^Headache disappeared|

7.9 Cancel Confirmation

The cancel confirmation referral payload is an optional response preceded by a cancel request in the referral process. Its purpose is to indicate to the referral initiator that the treatment through the originally requested referral will not be completed. By indicating a referral is a canceled, the receiver will NOT be expected to perform the treatment and/or provide the requested input per the specified reason for referral in the referral request. This payload will consist of a XDM package (containing a HL7 status update and associated metadata) as described below.

7.9.1 Cancel Confirmation Payload

<div class="clr-fig-caption">Figure 7.10: 360X compliant transport protocol and cancel confirmation payload</div>

7.9.2 MU2 Required Data Elements

Meaningful use content is not required for this step in the process.

7.9.3 XD Metadata Requirements

7.9.3.1 Submission Set

AttributeSourceExpectations
sourceIdMSH-4R
patientIdPID-3R

7.9.3.2 Document Entry

AttributeSourceExpectations
creationTimeMSH-7R
classCodeMSH-9 component 1R
formatCodeMSH-9 component 3R
typeCodeMSH-9 component 2R
sourcePatientId O (patientId as represented by the specialist)
sourcePatientInfo  
- patient identifierPID-3R
- patient namePID-5R
- patient DOBPID-7O
- patient genderPID-8R
- patient addressPID-11O
servicStartTime Do not send
serviceStopTime Do not send
uri Should match the name of the hl7 file in the xdm zip

Example:

7.9.4 HL7 v2 Cancel Confirmation object

Example:

MSH|^~\&||^1.3.6.1.4.1.21367.2016.10.1.32^ISO||^1.3.6.1.4.1.21367.2016.10.1.21^ISO|20161008110543+0000||OSU^O51^OSU_O51|24882|P|2.5.1|||NE|NE|||||360X|
PID|1||T7190334^^^&1.3.6.1.4.1.21367.2016.10.1.21.5&ISO^MRN~L53HG67^^^&1.3.6.1.4.1.21367.2016.10.1.32.11&ISO^MRN||Packton^Peter^^^L||19580817|M|
ORC|CR|889342^^1.3.6.1.4.1.21367.2016.10.1.21.15^ISO|||CA|||||||34225PC^Allen^Anthony^M^III^MD^^^&1.3.6.1.4.1.21367.2016.10.1.21.10&ISO^L^^DN||||^Glad to hear that|