This page is used by 360X Payload Workgroup participants to iterate an implementation guide. Please contact Brett Andriesen if you have any trouble editing this page.

Note for editors: remember to click on the special edit icon in order to be able to edit the various sections (including this top-level organizing document).

 

360X Project - Closed Loop Referral - Implementation Guide

1.0 Preface and Introduction

Preface and Introduction

 

 

To more fully realize the benefits of EHRT/HIT (electronic health record technology/health IT) the Office of the National Coordinator for Health Information Technology (ONC), through the State HIE Program, instantiated the 360Exchange (360X) Project to accelerate interoperable health care data exchange in heterogeneous EHRT environments. In particular, the 360X Project seeks to enable providers—using existing health data exchange standards and technologies—to exchange:

  • Referral requests containing relevant patient clinical information
  • Result of referral containing relevant patient clinical information

from within their EHRT workflow, regardless of the EHRT used. This will allow providers to communicate electronically the related patient information even if utilizing different EHRT/HIT. This scope indicates that the 360X Project includes defining the transport and content of:

  • the Referral Request
  • the Result of Referral
  • additional information to facilitate the referral process and the closing the loop.

This scope is intended to enable improved care coordination between providers utilizing different EHRT/HIT. The following presentation gives a high-level overview of the project.

1.1 Terms and Definitions

The following terms and definitions are used in this document. Note that these definitions apply within the scope and context of this document in order to provide a common understanding for readers and that they may be defined differently outside the scope of this document.

Closed loop referral: Communication failure between a provider initiating a referral request (the referral initiator) and the provider receiving the referral (the referral recipient) is likely to cause gaps in the care process. That is, referral requests may not be received, adequately understood, or satisfactorily performed to the detriment of the patient. A closed loop referral process is desired to reduce these gaps in service by providing the mechanisms to exchange pertinent information at key points during the referral process.

Transition of Care is defined as the cooperative provision of care by multiple providers, where each provider has part of the responsibility for the patient's wellness. The scope of this document is limited to the referral request and referral outcome between two providers, as a subset of transitions of care.

Referral Request is defined as a request from one provider (referral initiator) to another provider (referral recipient). The request includes a description of the services the referral initiator wants for a patient (i.e., the reason for referral and the specific questions asked). For example, a primary care provider (PCP) may make a referral request to a cardiologist for diagnostic services. In practice, referrals usually cross care venues or practices (e.g., between acute and ambulatory or ambulatory specialists), whereas consults may imply within a venue (e.g., between two providers within an acute setting). Generally, with a referral both referral initiator and referral recipient remain responsible for overall patient care. In the scope of this document, referral requests are between two providers using different EHRT.

Related health information is defined as the patient information that is relevant to the referral request or status of the request. For example, the referral initiator may have performed assessments/tests of the patient and documented a current problem, medication, allergy list, blood test results, history and physical, etc. and that information may be relevant to and useful for the provision of services by the referral recipient. The referral initiator may send that related health information to the referral recipient with the referral request for improved care coordination.

Result of referral is defined as the referral recipient's findings, conclusions, interpretations, and/or impressions of the service performed for the patient. The results are sent from the referral recipient to the referral initiator at the end of care.

End of Care (EOC) is when a referral recipient determines that no more care is needed to satisfy the referral reason; it is when the result of referral is sent to the referral initiator.

Referral Outcome extends the result of referral to include situations where the requisite care was not rendered or was ended before completion. Possible Referral Outcomes include:
  • The referral initiator Cancels the referral request (a) before care began or (b) while care was being rendered, but before the care is completed.
  • The referral recipient Declines the referral request (a) before beginning to render care or (b) before care has been completed.
  • The referral recipient completes the care and submits the Result of referral.

‍‍‍‍‍‍‍‍‍‍Referral request state ‍‍‍‍‍‍‍‍‍‍is defined as the result of interim communications which are sent between the referral recipient and the referral initiator to inform each other of the current state of the request of patient service. A list of states such as acknowledged, declined, etc. are provided herein.

Message status is defined as a communication of the electronic receipt or error of a transaction.  This does not reflect provider status of the referral request.

1.2 General Guiding Principles

The following list presents five general principles that are guiding decisions regarding 360X-compliant EHRT capability requirements.
  • In a medical home/neighborhood, where closed-loop referrals take place:
    • The maximum possible number of clinicians’ EHRTs should be able to implement 360X, so even EHRTs with minimal capabilities should be able to implement key components of 360X
    • The referral process should be as easy and useful as possible for all clinicians
  • For transport, all three Direct transport capabilities (as described in MU requirements) are included:
    • Required transport capability: “Simple SMTP” (no XDM/XDR)
    • Optional transport capability: SMTP + XDM
    • Optional transport capability: SOAP + XDR (only when both sides agree to this communication method)
  • Payload requirements should be minimal:
    • C-CDA content: Require as little patient data and metadata as is useful for transition of care, e.g., using a TOC (or other) template/profile that includes reason for referral
    • HL7 content: Include generic order in HL7 that is packaged in XDM to be consumed by EHRTs that can handle XDM and HL7
    • A second C-CDA that is not stored in the XDM is included for EHRTs that cannot handle 360X requirements
  • Required workflow functions and related payload content depend on EHRT capabilities:
    • HL7 content necessary for 360X workflow automation must be included in the payload by EHRTs that can handle XDM and HL7
    • EHRTs that cannot handle XDM or HL7 will have no 360X automated workflow capabilities beyond the required ability to create and display C-CDAs, as well as send and receive them via Direct
    • EHRTs that can handle XDM and HL7 must consume them and use them to automate defined 360X workflows
    • Implementers are encouraged to develop workflow capabilities that add value beyond the workflow requirements defined in this Implementation Guide; these value-add capabilities are product advantages.
  • 360X processes are designed to improve coordination of care in patient-centered medical homes (PCMHs) and other such care coordination models by, for example:
    • Fostering care team collaboration around patients through information sharing
    • Notifying care teams when specific patients move across settings
    • Enabling wide-spread interoperability
    • Providing referral data that supports reporting and decision-making.

 

2.0 Overview and Scope

Overview and Scope

This Implementation Guide describes common patterns of exchange and content/payload standards for the secure and interoperable sharing of clinical data for the purposes of referrals. This document represents guidance for vendor use of the referenced standards in order to electronically communicate:

  • a referral request from one provider (referral initiator) to another (referral recipient) across EHRT
  • updates to the progress of the referral
  • the outcome of the referral, including relevant patient data as part of the successful completion of the closed loop.


Within the 360X Project, the use case focuses on the exchange of this referral related information between two providers using disparate EHRT where the referral is for outpatient services such as from PCP to specialist or specialist to specialist. It is important to note that the care venue of the actors may be immaterial; for example, the specialist actor may be hospital based or clinic based.

The material aspects of the scope of the actors are that they are:

  • requesting outpatient services (vs. requesting admissions)
  • using different EHRT


The use case includes ongoing, related coordination activities between the actors (e.g., providing interim consultation reports, communicating patient’s missed/canceled/rescheduled appointments, etc.) and provision of the outcome of the referral. The primary goal is to enable electronic exchange to support improvement in the quality and timeliness of information available to both the referral initiator and referral recipient throughout the referral life cycle.

To effectively implement the secure electronic exchange of referral request, status, relevant health information, and result, it is important to have appropriate interoperability standards as well as clear implementation guidance for their use in context of this use case. In order to promote rapid adoption, the 360 Exchange Project has chosen to base its requirements on standards identified in the 2014 Edition Meaningful Use certification criteria and mature HL7 specifications. The combination of these two standards provide the ability to raise the bar from simple data sharing in the form of a C-CDA per 2014 Edition Meaningful Use certification to managing workflow with the addition of HL7 messages.

2.1 Relationship 360X to ONC Certification Criteria and the Meaningful Use (MU) Incentive Program

2.1.1 Meaningful Use Incentive Program Provider Process Requirements

MU Stage 2 Transition of Care (TOC) objective and measure focuses on the use case for electronic exchange of patient data from one care venue to the intended recipient of a requested patient transfer or referral. The NPRM for MU Stage 3 proposes to continue this objective and increase the threshold for electronic exchange. The electronic information exchange does not require any messaging of the actual transfer or referral requests, counting of each/all request, nor any status or result of same. The request, acceptance of the request, status, and result are managed manually or via non-specified means. The program only requires that a C-CDA (Summary of Episode or Referral Note) containing an ONC-specified data set be sent, via an ONC-specified protocol, from the referral initiator to the referral recipient who will perform the requested care.

360X seeks to extend this capability with the capability to electronically transmit the request itself, request status, and result of request. This extension will provide providers needed process flow support and allow tracking of each request.

2.1.2 ONC Certification Requirements

The ONC 2014 Edition, 45 CFR 170.314(b)(2), requires CEHRT to demonstrate the ability to create a C-CDA with the Common MU data set and enable a user to electronically transmit in accordance with Direct. The details of the requisite data can be found in the Companion Guide produced by the S&I framework. The 2014R2 Edition and the 2015 Edition supporting MU Stage 3 maintain the premise of Stage 2 in that they do require electronic transmission of the C-CDA. These editions also extend the 2014 Edition to update the Common MU Data Set to a Common Clinical Data Set (CCDS), introduce Edge Protocols that can be used instead of or in addition to Direct, and update the HL7 standard for the C-CDA to v2.1.

360X seeks to support these MU requirements and to introduce the ability for EHRT to manage the referral request process itself with the introduction of the electronic communication of the HL7 v2.x order payload. 360X also seeks to support both MU stages and ONC Certification Editions and, therefore will remain agnostic regarding C-CDA HL7 IG versions and compliance with the ONC-specified data sets. Therefore, a system will be compliant with 360X by complying with the requirements of this Implementation Guide, however that may introduce the need to augment or constrain C-CDA content that is otherwise compliant with aforementioned CMS/ONC requirements.

2.2 In Scope

Electronic communication across EHRT instances between two providers, specifically the Referral Initiator and the Referral Recipient for the:

  • Referral Request
  • Coordination information
  • Referral Outcome


For each, via reference to and guidance on the standards, the physical, data, network, transport, session and presentation layers including:

  • Selection of appropriate transmission protocol(s), as well as implementation guidance necessary to ensure interoperability.
  • Selection of appropriate clinical summary information standard(s) and support for any additional content types that are necessary to ensure that implementations in support of this use case are clinically relevant and useful, as well as implementation guidance necessary to ensure the widespread adoption of such standards.
  • In the absence of specific local, state, or national policy or regulatory requirements, agreeing to common ‘rules of the road’ to bridge such gaps in order to facilitate interoperability while ensuring adequate levels of security, privacy, and trust.

2.3 Out of Scope

  • Application functionality within the EHRT for managing and displaying the processes related to referrals. Note that a referral request may proceed through multiple steps to achieve an initiation readiness state such as confirmation of eligibility, patient coordination for desired locations/providers, etc. These preparation steps are very important but not within the scope of this guidance which starts with an initiation ready request.
  • Functionality designed explicitly to support clinicians not using EHRT (though valuable, the focus of this project is on EHR-to-EHR interoperability)
  • Processes and transactions related to the administrative and financial aspects of referrals such as eligibility and claims handling.
  • Occurrence handling. This guide assumes one request, one Accept and Complete or Decline. Any recurrent pattern of patient encounters the referral initiator may need is not managed by the scope of this document and is within the referral initators' discretion.
  • Defining or modifying existing clinical medicine practices
  • Provider - Patient communication use cases
  • Continuity of care use cases outside of the single referral request handling between two providers. For example, "courtesy copy" or "referral forward" use cases to communicate among a broader set of providers.
  • Privacy and Security policies and processes such as consent handling.
  • Person (provider, patient) identity matching capabilities
  • Relevant but tangential processes covered elsewhere such as HPD+ (or other) enabler of provider directories used for efficient addressing and routing.
  • Referrals/consults within a single EHRT such as consult orders from and attending to a specialist or between two providers using the same EHRT instance.
  • How the C-CDA content is rendered to a user. Based on the various certification requirements, it is expected that the EHRT receiving a C-CDA document is able to present it in its entirety to the appropriate users. Additional rendering help (e.g. XSLT stylesheets) may or may not be provided by the sender, therefore the receiver may not rely on the presence of such. If the sender provides rendering help, the receiver is not required to use it, and if they chose to use it, proper precautions must be made to alleviate any security risks presented by applying executable code of foreign origin. The C-CDA specification provides a stylesheet, and there are projects under way to provide other freely available stylesheets to help with rendering the content.
  • Use Cases concerning intermediary communications ("chatter"), "forking" the conversation through other means, such as forwarding or carbon copying or any other internal processes that are desired to add additional observers. This includes interim status updates that do not have any accompanying patient clinical formation (unless specifically defined in this Implementation Guide).

3.0 Assumptions and Constraints for Transport and Payload

Assumptions and Constraints for Transport and Payload

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.

4.0 Referral Workflow


Referral Workflow

This section is intended to provide the reader with an overview of the 360X Use Cases and how the transactions that will be detailed in subsequent sections are used for those Use Cases. At the end of this section, the reader should understand the functional flows and be familiar with the details of each transaction.

4.1 360X Use Case

As described in the Scope section, this use case focuses on the exchange of data between a pair of initiating and recipient providers' EHRT to request a referral, obtain the status of the referral request, transmit relevant data related to the request, and to transmit the result of the request. While this process may exist between any pair of clinical actors, the following narrative description focuses on the most common example of a transition between a primary care provider ("Referral Initiator") and a specialty care provider ("Referral Recipient").

4.1.1 Actors

ActorRole

Referral Initiator (Clinician, Provider Organization);
Referral Initiator's EHRT

Referral Initiator (source of referral)

Referral Recipient (Clinician, Provider Organization);
Referral Recipient's EHRT

Referral Recipient (provider of referral services)

Table 4.1: 360X Use Case Actors

4.1.2 Use Case Transaction Flow Summary Overview

The following sections describe a referral process flow. The following diagram is intended to orient the reader to that flow and summarize the transaction flow that results. This diagram is not intended to be a comprehensive transaction flow; specifically, this diagram represents a serial process whereas status changes may not occur serially (please see state diagram below) and the diagram only reflects a subset of possible alternative paths (please see status section below).

Figure 4.1: Process Flow and Transaction High Level Summary
Source

4.1.3 Setting 1: Referral Initiator’s office

Sends Referral Request and Related Health Information to Referral Recipient.

A PCP, for example, is in the middle of an encounter (office visit) with a patient and determines that the patient needs to be referred to a specialist. The PCP is documenting the encounter in the EHRT and within the EHRT orders the referral. This implementation guide does not make any other assumptions about the internal processes at the referral initiator's office. In some cases there might be additional steps or actions performed by the PCP or by other clinicians or office staff, however that is outside the scope of this guide. The result of the PCP's order and these internal processes is a completed Referral Request package (request and any related health information) for the specialist. The message is addressed to the appropriate specialist, specialty or provider organization (Referral Recipient) and is sent to the Referral Recipient’s address / EHRT.

The referral request must always include the Request information (defined below) such as patient identification, referral request identification, referral recipient identification, and the related health information to help optimize the referral recipient’s knowledge of the patient, efficiency in referral recipient data collection such as allergies, medications, problems, recent test results, and/or other data. Within the scope of this document, when related health information is sent, it should be sent with the request for optimal care coordination.

Future versions of this guide, based on implementation feedback, may include a two-step request process, where the related health information may be communicated between providers via alternate means (mutual access to to a common HIE, query based access to clinical data, etc.)

4.1.4 Setting 2: Referral Recipient’s office

Receives Referral Request and relevant health information, from Referral Initiator.

The referral request is processed according to the specific context of the referral and in accordance with the referral recipient's practice’s clinical and administrative policies and workflows.

These may include:

  • The referral recipient may need to review the request and determine if he will accept or decline the referral request. The referral recipient's acceptance or decline of the referral request is a mandatory communication to the referral initiator
  • Upon acceptance, the provider may order additional tests to be performed on the patient prior to the office visit.
  • The patient will generally be registered and scheduled in accordance with practice policies and workflow prior to the clinical encounter. The referral recipient EHRT may optionally communicate this status to the referral initiator.
  • Data from the request and any additional content from within the related health information may be promoted and/or transcribed to and/or stored in total in the referral recipient's EHRT.
  • The referral recipient provider may also query other available EHRT, such as a regional HIE for additional information.

Once the referral recipient provider has seen the patient, in accordance with practice policies and workflow, he or she documents the encounter in the EHRT and prepares either an interim or final consultation summary (result of referral) for the PCP. Once the summary is prepared, it is communicated to the referral initiator indicating that the requested service has been performed and the request is completed, thus closing the loop in care coordination. The communication includes the result of referral in the form of a referral summary / summary of care document. Optionally, and depending on practice, the provider may send a preliminary, final, and/or corrected/amended document.

4.1.5 Setting 1: Return to Referral Initiator’s office

Receive result of referral from Referral Recipient.

The referral request completion status and the interim or final referral result is received by the the Referral Initiator's EHRT.

Once received, additional activities may occur within the Referral Initiator's practice:

  • The result of referral may be reviewed and appropriately made available for access; e.g. incorporated in the referral initiator's EHRT
  • Support staff may update the EHRT work queue for appropriate distribution to other staff members’ work queues
  • In accordance with practice policies and EHRT functionality, discrete data elements from within the referral result may be reconciled, promoted, and/or transcribed to the PCP’s EHRT. For example, the PCP may review, reconcile and update the active medication, allergy and/or problem lists.
  • The result of referral, and any additional content, may be retained in its entirety as a permanent part of the patient’s record.
  • In accordance with administrative and clinical practices, the patient may be contacted for subsequent follow-up, diagnostics, and/or procedures.

4.1.6 Referral Outcomes

Once a given patient referral between a Referral Initiator and a Referral Recipient is accepted by the referral recipient, in order to "close the loop", the referral request MUST end by:

  • the referral initiator sending the referral recipient a request for cancellation and the referral recipient confirming the cancellation, or
  • the referral recipient sending the referral initiator a decline for the referral (e.g as a result of a patient no-show), or
  • the referral recipient sending the referral initiator a request completed transaction with the result of referral

4.2 Referral State Diagram (Comprehensive)

The following diagram describes a variety of states associated with the 360X Project’s closed loop referral use case. The 360X Project’s Payload Workgroup developed this state diagram to represent a series of generalizable workflow steps found in outpatient provider settings and then utilized this diagram to define a series of transactions to support a diverse range of possible workflow sequences.

While 360X compatible systems are expected to support the derived set of required and (if implemented) optional transactions, EHRT is not expected to necessarily share a given state throughout the lifecycle of a consultation. Likewise, the 360X Project does not cover the presentation layer scope of referral handling implementation; it does not have specific requirements for how these states are to be externalized/displayed (if at all) within a given EHRT’s end user interface. For example, once a newly "Created" referral package has been sent to the Referral Recipient, it may be shown as "pending" in the Referral Initiator's EHRT and may be displayed in the work queue of the Referral Recipient 's EHRT as "new" or some other suitable status. In this way, the 360X implementation guide provides a mechanism by which disparate EHRT may infer the state/status of a referral based on prior messages while retaining the ability to integrate this flexibility into a given application's workflow.

The same state diagram is shown from the point of view (POV) of the referral initiator, and from the point of view of the referral recipient:

Fig. 4.2: 360X State Diagram, Initiator's Point of View
Source

 

Fig. 4.3: 360X State Diagram, Recipient's Point of View
Source

4.3 Referral Workflow Events/Transactions

The following table lists the transactions described in this implementation guide.The following rules apply for various classifications:

  • For the sender,
    • when the transaction is marked as "Required", it means the sender must be able to send this transaction as part of their workflow from every state where this transaction occurs in the diagrams of section 4.2.
    • when a transaction is marked as "Conditional", the sender must support the ability to send that transaction, however, they can chose at which point it may be sent.
  • For the receiver,
    • when a transaction is marked as "Required", they must act on that transaction when received in any of the states in the diagrams in section 4.2.
    • when the transaction is marked as "Conditional", the receiver must be able to act on the transaction in at least one of the states it is received, but under certain conditions, they may chose not to act on it.
  • When a transaction is marked as "End", that means that the referral workflow ends after this transaction (implies that the receiver must act on it within their own system).
  • Optional transactions may or may not be supported at all by either side, however, the receiver must not error out if they receive an optional transaction.

Sender

(R)equired/
(C)onditional/
(O)ptional/

Event / Transaction

Receiver

(R)equired To Take Action/
(C)onditional/(O)ptional/
(E)nd

Referral Initiator

R

Send Referral Request

Referral Recipient

R

Referral Recipient

R

Send Acceptance (of Referral Request)

Referral Initiator

R

Referral Recipient

R/C

Send Decline (of Referral Request)

Referral Initiator

E

Referral Recipient

R

Send Referral Outcome

Referral Initiator

E

Referral Initiator

C

Send Request for Cancellation (of the referral)

Referral Recipient

C

Referral Recipient

C

Send Cancellation Confirmation (of the referral)

Referral Initiator

E

Referral Recipient

O

Send Interim Consultation Note

Referral Initiator

R

Referral Recipient

O

Send "Scheduled Appointment" Notification

Referral Initiator

O

Referral Recipient

O

Send "No Show" Notification

Referral Initiator

O

Note: The Referral Recipient must be able to send a Decline as a response to an initial referral request. The ability to send a decline from any other state is conditional upon local policies and workflow rules. That is why this transaction is marked as R/C for the sender.

4.3.1 Send Referral Request and Respond to Referral Request

Functional requirements:

To initiate a referral request, the Referring Physician (referral initiator) MUST transmit a Referral Request to the Referral Recipient. The Referral Request MUST be sent via the mechanism(s) set forth by the 360X Transport Protocol. The Referral Request MUST contain the content specified by the Referral Request Payload.

In response to a Referral Request, the Referral Recipient provider MUST transmit either an Accept or a Decline of the referral. This response SHOULD be sent in a timely manner consistent with the Referral Recipient's existing clinical and administrative practices.

Narrative description:

To start the referral process, the initiating organization may have to take a variety of steps to determine that the patient requires a referral, the type and timing of the referral care needed, the specific provider/provider organization to which the patient wants or needs to be directed, the eligibility of the patient for the referral, the desired timing of the needed care, what if any information the referral recipient needs about this patient that is relevant to the requested care, and many other factors. Once those factors are resolved, the referral request package containing the request details and any associated information can be addressed to the referral recipient and sent by the referral initiator. The referral recipient would then evaluate the referral request through a variety of steps and either accept the request or decline the request. Acceptance indicates the referral recipient's intent to continue the referral process and perform the requested service. A referral recipient's decline of the request informs the referral initiator that the care requested will not be performed by the referral recipient and the referral initiator may need to evaluate next steps such as initiating a new request to an alternate provider.

A Decline ends that referral request.

4.3.2 Send Accept for the Referral Request

Functional requirements:

If the Referral Recipient is able and willing to accept a specific referral, the Referral Recipient MUST transmit an Accept to the Referral Initiator. The Accept MUST be sent via the mechanism(s) set forth by the 360X Transport Protocol. The Accept MUST contain the content specified by the Accept Payload.

Narrative description:

If the Referral Recipient is able to meet the conditions of a referral request (i.e., provide the requested care within the specified time period, if any) and is willing to treat the patient, the Consulting Physician (referral recipient) will send an accept to the Referral Initiator to acknowledge their intent to initiate an episode of care associated with this referral.

An Accept acknowledges the referral recipient's intent to proceed with the rest of the referral process.

4.3.3 Send Decline of the Referral Request

Functional requirements:

If the Referral Recipient is unable or unwilling to accept a specific referral, the Referral Recipient MUST transmit a Decline to the Referral Initiator. The Referral Recipient MAY also Decline a previously accepted referral to indicate that an episode of care will not be initiated. If the Referral Recipient has had one or more encounters with the patient for a given referral, the Referral Recipient MAY send a Decline and an Interim Consultation Note MAY be sent to indicate the end of the episode of care. The Decline MUST be sent via the mechanism(s) set forth by the 360X Transport Protocol. The Decline MUST contain the content specified as the Decline Payload.

Narrative description:

If the Referral Recipient is unable to meet the conditions of a referral request (i.e., not provide the requested care and/or not do so within the specified time period, if any) and/or is unwilling to treat the patient, the Referral Recipient will send a Decline to the Referral Initiator to acknowledge their intent to not initiate an episode of care associated with this referral. For a variety of valid reasons prior to a patient encounter, a Referral Recipient may also Decline a previously accepted referral request.

A Decline ends this referral request.

4.3.4 Send Result of Referral

Functional requirements:

The referral recipient SHALL provide the Referral Initiator a Result of the care provided. The Result MUST be sent via the mechanism(s) set forth by the 360X Transport Protocol and MUST contain the content specified by the Referral Summary Payload specification. If the Result of Referral is sent in an eCQM-enabled environment where the Closing the Referral Loop measure CMS50vN is being tracked, 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) SHALL be sent in the eventCodeList attribute for the Document Entry representing the C-CDA in the Referral Summary Payload.

Narrative description:

After care has been provided, the referral recipient may create a record of the result of that care. The result may include a narrative conclusion of the care/patient condition, a diagnosis and/or any number of conclusionary and related health information such as an updated patient problem list, new or revised medications, new or revised record of allergies, new or revised patient instructions, new or revised plan for ongoing care, diagnostic tests performed and their result values, diagnostic images, etc. Any or all of this information may be relevant to the Referral Initiator. In context of this IG, electronic communication of the Result of Referral is required and supported by the transport and payload definitions.

In future versions of this guide, based on implementation feedback, there may be additional mechanisms to make any or all of this information available to the referral initiator and/or other patient care givers through a variety of means such as query or direct user access to the referral recipient's EHRT, communication to a mutually accessible HIE, and/or providing copies to the patient for any distribution to caregivers.

Note that the Result of Referral is the final transaction for the referral. The interim Consultation Note transaction may be used for sending preliminary information. The Referral Recipient may send one or more results.

The Result of Referral closes the loop of coordination of care between Referral Initiator and Referral Recipient for the referral request.

4.3.5 Send Cancellation Request and Respond to Cancellation Request

Functional requirements:

To request the cancellation of a referral, the Referral Initiator MUST transmit a Cancellation Request to the Referral Recipient. The Cancellation Request MUST be sent via the mechanism(s) set forth by the 360X Transport Protocol. The Cancellation Request MUST contain the content specified by the Cancel Request Payload.

In response to the Cancellation Request, the Referral Recipient MUST respond either with a Cancellation Confirmation or with a Result of Referral (in the event the request was already performed). Therefore, the Referring Physician MUST assume that an episode of care is ongoing until advised otherwise by the Referral Recipient.

Narrative description:

For a variety of clinical and administrative reasons (e.g., the patient is admitted to an inpatient care setting, the patient's insurance coverage changes, etc.), a Referral Initiator may choose to issue a cancellation request to a Referral Recipient for a specific referral. This request may be issued prior to or during an episode of care between the patient and Referral Recipient. Given the variability in timing and other circumstances, the Referral Recipient may decide to accept the cancellation request or may determine that he/she is unable to end the anticipated/ongoing episode of care for equally valid reasons, and complete the Episode of Care with a subsequent Result of Referral transaction.

A Cancellation Confirmation or a Result of Referral ends that referral request.

4.3.6 Send Cancellation Confirmation

Functional requirements:

Upon receipt of a Cancellation Request from the Referral Initiator, the Referral Recipient MAY respond with a Cancellation Confirmation that signifies that the Referral Recipient will either not initiate or end the episode of care associated with this particular referral at the request of the Referral Initiator. The Cancellation Confirmation MUST be sent via the mechanism(s) set forth by the 360X Transport Protocol. The Cancellation Confirmation MUST contain the content specified by the Cancel Confirmation Payload.

Narrative description:

A Cancellation Confirmation ends this referral request.

4.3.7 Send Interim Consultation Note

Functional requirements:

Following a patient encounter but prior to the end of an episode of care, the Referral Recipient MAY provide the Referral Initiator relevant health information about the patient such as a preliminary result or consultation notes. The Interim Consultation Note MUST be sent via the mechanism(s) set forth by the 360X Transport Protocol. The Interim Consultation Note MUST contain the content specified by the Interim Consultation Note Payload. If the Interim Relevant Health Information is sent in an eCQM-enabled environment where the Closing the Referral Loop measure CMS50vN is being tracked, 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) SHALL be sent in the eventCodeList attribute for the Document Entry representing the C-CDA in the Interim Consultation Note Payload.

Narrative description:

In accordance with the Referral Recipient's clinical practices and office procedures, the Referral Recipient may provide one or more interim consultation notes during a patient’s episode of care to the Referral Initiator. This relevant patient information may inform the referral initiator about observations the provider has made, test results, preliminary findings, planned next steps, new problems found, medication changes, or any relevant information related to the referral request. Under this implementation guide, Referral Recipients are not required to send interim consultation reports. However, Referral Recipients are encouraged to utilize this functionality as dictated by standards of clinical practice, professional obligations, and/or to enhance the coordination of a patient’s care.

Referral Initiators should not anticipate interim consultation notes from all referrals. However, the Referral Initiator’s electronic system should be able to receive and store the interim consultation notes to the patient’s record in accordance with the Referring Physician’s clinical and administrative practices.

4.3.8 Send "Scheduled Appointment" Notification

Functional requirements:

The request recipient MAY send one or more notifications that patient care has been scheduled for the request. The notification MUST be sent via the mechanism(s) set forth by the 360X Transport Protocol and MUST contain the content specified by the Schedule Payload specification.

Narrative description:

The Referral Recipient may schedule one or more appointments for the patient to perform the request. Any one appointment may be performed and/or rescheduled. The referral recipient EHRT may send the Referral Initiator notification of each appointment and/or appointment reschedule to signal progress against the request.

4.3.9 Send "Patient No Show" notification

Functional requirements:

If a patient fails to attend an appointment without notification and/or rescheduling, the Referral Recipient MAY provide a “No Show” Notification to the Referral Initiator. The “No Show” Notification MUST be sent via the mechanism(s) set forth by the 360X Transport Protocol. The “No Show” Notification MUST contain the content specified by the “No Show” Notification Payload.

Narrative description:

In accordance with the Referral Recipient’s clinical and administrative practices, the Referral Recipient may send a “No Show” Notification to the Referral Initiator. The “No Show” Notification is intended for circumstances in which the patient has failed to attend an appointment and has not rescheduled it. If the Referral Recipient chooses to send a "No Show" Notification, they must then either send a Decline, or reschedule the appointment and send another "Scheduled Appointment" notification. The Referral recipient must also be able to receive a Cancellation Request from the Referral Initiator.

The Referral Initiator should handle “No Show” Notifications in accordance with their clinical and administrative practices, as well as based upon the capabilities of their electronic systems. The Referral Initiator may choose to send a Cancellation Request in response to the "No Show" notification.

4.4 Example Workflow Flowcharts

The flowchart in this section demonstrates one possible way to handle the workflow once the referral is accepted. It indicates the necessary messages based on the referral state; it provides additional details to the previous Referral State diagram and refers to the IG's Exceptions flowchart when required messages fail or are late.

Fig. 4.4: Appointment Scheduled to End of Care

4.5 Exceptions Flowchart

The flowchart in this section shows one possible way to handle a variety of exceptions, from failure to get a response in a timely manner, to possible communications issues. The handling of these exceptions will vary based on configuration, system capabilities, or clinical and administrative practices.

Fig. 4.5: Possible Handling of Exceptions
Source

5.0 Package Structure and Transport

Package Structure and Transport

The following diagrams are provided to help orient the reader to the sections that will follow. The Guide will define and provide examples for the transport protocol and the contents of the payload: XDM request package wrapper, and request package contents for the order, status, result and associated patient information.

An effort has been made in this specification to define the transactions in a way that is most consistent with current application behaviors and existing standards to ease implementation and speed adoption. Most systems manage requests for consultation internally as request items managed on a worklist or other means. When the application logic determines that the request is for a destination to another system, but within the environs of the enterprise network, the request is translated to an HL7 order and is managed between systems with order status updates, scheduling messages, and / or result transactions. Patient information needed with the order is usually limited because the primary patient data is available to requester and request recipient inside the enterprise environs. To keep that behavior consistent but extend it to disparate systems across enterprise environs where networks may be public and where comprehensive, latest patient data may not be available from the requester's system; this Guide seeks to reuse the HL7 order concepts, augment them with robust associated clinical data, and wrap and transport them via accepted transport protocols to support network scalability.

The first diagram intends to depict this concept of a processing and transaction "onion" for requester and recipient processing. It is not intended as a design diagram or to drive application function, but simply to illustrate the point that layers are added to the base request to handle each processing complexity that is added with the requirement to manage the request outside a single system, between disparate environs, over public networks.

 

Figure 5.1: Processing and Transaction Concepts

 

Figure 5.1 can then be elaborated in the context of the requester:

 

Figure 5.2: Processing and Transaction Detail

 

This processing flow leads us to the payload component summary below:

 

Figure 5.3: Payload Overview

5.1 Transport Protocol

The 360X Project relies upon the Direct standard, as defined by the Applicability Statement for Secure Health Transport, as its vehicle for information exchange. All message exchanges between disparate systems MUST be transported using the Direct transport specification.

The Direct transport defines the input and output of the STA as an Internet Message Format document conforming to RFC5322 with a valid MIME body. As such, all payloads MUST be enveloped within a RFC5322 message. A message contains two parts: header section and a body with content described by the message’s Content-Type header.

5.1.1 Certificate Discovery

When the location of an X509 certificate associated to a Direct address (either address or organizationally bound) is unknown, all STA attempts to dynamically locate the certificate SHOULD use the discovery methodology described in the S&I framework’s Implementation Guide for Certificate Discovery to facilitate universal interoperability. STAs MAY use alternate or out of band methods to discover or exchange certificates.

5.1.2 Quality of Service

The Applicability Statement for Secure Health Transport only requires a positive acknowledgement of message receipts when an STA successfully decrypts a message and validates trust; it provides little to no guidance on failed message exchange. To promote consistent transport behavior and provide higher levels of message delivery assurance, message transport MUST comply with the implementation guide for delivery notification. Consequently, the sending edge client MAY set the header with the expectation of receiving an MDN. However, the receiving STA MUST honor the request and send an MDN upon receiving the custom header from the edge client.

5.1.3 SMTP Message Headers

The header section of the RFC5322 message MUST contain the required headers as specified in the applicability statement. These consist of:

  • to
  • from
  • orig-data
  • message-id
  • subject (While not specified in the applicability statement, the 360x message MUST contain a message subject header with text containing the substring "XDM/1.0/DDM+360x")

The header section of the RFC 5322 message, which is in reference to a previous message for the same referral, SHOULD also contain the following headers:

  • in-reply-to
  • references

The message MAY contain additional headers as needed for appropriate routing and transport context.

5.2 SMTP Message Body

The message body consists of the actual payload content. Payloads MAY be broken into one or more content parts with each part containing either human readable content or an attachment. Although a message may consist of only a single part, the Content-Type of the message SHALL be multipart/mixed consisting of one or more body parts. The message SHALL contain a human readable part even if it contains no content.

Generally, most mail packages and rendering engines can handle multipart/mixed messages even if only a single human readable part or attachment exists.

Given that the message content type is multipart/mixed, the message body must conform to the multipart media type as described by RFC 2046 section 5.1. The body parts are not ordinal meaning that the sequence in which each part appears in the message is irrelevant.

5.2.1 Human Readable Text

The message body MAY contain human readable text. If there is human readable text, the Content-Type SHALL be one of the following three types:

  •  text/plain – Content type for representing plain, non marked up text.
  • multipart/alternative – Content type when the content may be represented in multiple formats. If the type is multipart/alternative, text/plain MUST be one of the alternative types.
  • text/html – Content type for representing marked up text (HTML file)

While human readable text may be included in body parts beyond the 360X payload package, this implementation guide is silent on the use of this option, and there is no expectation regarding the presentation and conveyance of the human readable text to a user. Implementers are encouraged to utilize fields available within the 360X messages and documents to convey narrative information and are cautioned that content outside of the 360X specified payload may not be displayed and/or may be discarded by receiving systems. As such, implementers are advised to limit the use of such additional body parts to informational updates of a non-urgent, non-clinical nature only.

5.2.2 Non Human Readable Text

The message body SHALL contain one body part, containing the required minimal structured content as determined by the 360X Project, and MAY contain additional structured or non-structured parts.

5.3 Content Representation

The following sections specify how certain use case specific content should be represented in an RFC5322 message.

5.3.1 XDM

At the time of writing, an IANA registered MIME content type for XDM zip files does not exist. XDM files MUST be represented by a message body part of type application/zip.

The Cross-enterprise Document Media Interchange (XDM) profile is defined by IHE (see ITI Technical Framework, Volume 2, section 32) and provides the overall packaging structure for the 360X Payload, as recommended in the Direct specification (see page 7 in the Applicability Statement for Secure Health Transport), and in conformance with the XDR and XDM for Direct Messaging Specification.

The XDM package is a single ZIP file with the following structure:

XDM_SAMPLE.ZIP+--README.TXT
              |
              +--INDEX.HTM
              |
              +--IHE_XDM-------SUBSET01+--DOC00001.XML
              |                        |
              |                        +--DOC00002.HL7
              |                        |
              |                        +--METADATA.XML
              |                        |
              |                        + ... (may contain other files, not referenced in the METADATA.XML file)
              |
              + ... (any other files and directories may be present)

The XDM structure as defined by IHE is generic, and allows for multiple Submission Sets to be present (inside the IHE_XDM directory). For the purposes of the Direct protocol, and in particular for the 360X project, the XDM package shall contain exactly one submission set.

The IHE XDM profile also mentions "multipart" documents within the submissions set. This structure SHALL NOT be used in a 360X conformant XDM package.

The purpose and requirements for the README.TXT and INDEX.HTM files are described on pages 95-96 of the IHE ITI Technical Framework, Vol. 2b.

Requirements:

PS01: The XDM package shall contain a single submission set. The submission set shall contain information for a single patient.

5.3.2 CDA Documents

At the time of writing, an IANA registered MIME content type for CDA or any specific types of CDA documents (C-CDA, CCD, etc) does not exist. CDA based documents MUST be represented by a MIME type of text/xml.

5.3.3 HL7 Files

HL7 Version 2.x is a messaging standard for the exchange of healthcare information. The standard has several versions, with the latest being 2.8.2, which was published in 2015. There are several messages from HL7 Version 2.5.1 already required in the 2014 and 2015 Certification Edition. This implementation guide will also use HL7 Version 2.5.1 messages to represent various state transitions and workflow information, while borrowing a few details from newer versions. This common practice is already in use in the ONC Certification Edition requirements for laboratory orders and laboratory results. The HL7 messages will be part of the XDM package as illustrated in sections 6.1.1 and 7.1.1. HL7 files MUST be represented by a MIME type of x-application/hl7-v2+er7 in the XD Metadata

The HL7 messages MUST be formatted according to Appendix C.


6.0 Content Structure and Data Representation

Content Structure and Data Representation

This implementation guide uses existing standards and specifications to enable the sharing of clinical content and minimal workflow information for the closed-loop referral use case.

6.1 XDM Metadata Requirements

The XDR and XDM for Direct Messaging Specification and IHE IT Infrastructure Technical Framework collectively provide the 360x baseline set of expectations in regards to the metadata requirements. This applies for all payloads produced throughout the lifecycle of a referral. This baseline starts with, but is not limited to, the minimal metadata definition as reflected in the following tables. While the information below serves as the comprehensive list of attributes, the use of these will vary based on the context of the payload being delivered. Instances in which the context impacts the origin or consumption expectations of the attributes, supplemental information will be provided in the payload specific sections. Please note the areas marked with an "*" as they require values to be populated beyond the minimal metadata definition or conflict with the aforementioned specifications.

6.1.1 XDM Base Data Types

The following XDM data types represent a single value, and can be referenced directly from within a field in a given attribute, or they can be components of a complex data type. When viewing the attribute descriptions below, the expansion stops at a base data type.

 

6.1.2 Submission Set Requirements

6.1.3 Document Entry Requirements

 

6.2 C-CDA Clinical Document Requirements

360x requires a C-CDA be transmitted at minimum with the referral request and with the referral closure, according to the HL7 C-CDA R2.1 implementation guide.

Data and Section requirements for 360x: 360X requires a valid C-CDA per HL7 C-CDA R2.1 IG and, therefore, the section conventions that that IG defines take precedence. The only requirement that 360X levies on the referral request and the request closure documents beyond the HL7 C-CDA R2.1 IG is that:

  • Every referral request must have a non-null reason for referral section (R)
  • Every closure of a request must have a non-null response to the question asked in the reason for referral and the recommendation is to include that content in the Results section.

Data and Section information: We have provided Appendix B for document types and sections in support of your development to 360X and comparison of it to any development toward the ONC 2015 Edition specifications. This is for information only. Three document types are reviewed:

  • Referral Note
  • Consultation Note
  • Summarization of Episode CCD

For the Referral note, 3 columns are provided:

  1. Summary of requirements for data/sections per HL7 C-CDA R2.1 IG
  2. Summary of requirements for data/sections per HL7 C-CDA R2.1 IG as augmented by ONC 2015 Edition CCDS
  3. Summary of requirements for data/sections per HL7 C-CDA R2.1 IG as augmented by the American Medical Association (AMA).

We suggest that the ONC CCDS and the AMA inputs be used to consider best practices for implementation of this document type (or any alternative document type) for 360X implementation that also meets the program requirements that utilize the ONC 2015 Edition specifications as well as clinician input from the AMA for usability.

For the Consultation note, only two columns are provided; HL7 IG and AMA input, since the ONC 2015 Edition does not define a Consultation Note as a required document template.

Since the ONC 2015 Edition also requires the general Summarization of Episode Note CCD, that could also be augmented with the 360X reason for referral, and this might be a highly used document in context of the programs that use these specifications, we’ve provided a summary of those requirements. Note that the SOEN CCD is summarized only in the case of HL7 C-CDA R2.1 IG with the ONC CCDS as that will be the likely incarnation of this document.

The clinically relevant content is following the Consolidated Clinical Document Architecture (C-CDA) specification. The following structures describe the most commonly used components of the base C-CDA specification.

6.2.1 Document Templates

((Take the spreadsheets and pull out the tables, similar to V2))

6.2.2 Section and Entry Templates

((Take the spreadsheets and pull out the tables, similar to V2))

6.3 HL7 Version 2.x Messages

The complete specification for the HL7 Version 2.x messages is in Appendix C. The following is a summary of the messages used in the various transactions. This section contains the required content according to this implementation guide. It is intended as a summary reference.

 

Proposal (Hans Buitendijk): Change MSH-4 and MSH-6 optional; pre-adopt MSH-22 and MSH-23 where MSH-22 is R and MSH-23 is RE.  This will allow distinction between physical facility vs. organization where we know organization to send the request/etc., but not the facility.

6.3.1 Base Data Types

The following data types represent a single value, and can be referenced directly from within a field in a given segment, or they can be components of a complex data type. When viewing the message and segment descriptions below, the expansion stops at a base data type.

6.3.2 Message OMG^O19_OMG_O19

6.3.3 Message OSU^O51^OSU_O51

6.3.4 Message SIU^S12^SIU_S12

6.3.5 Message SIU^S26^SIU_S12


7.0 Transaction Contents


Transaction Contents

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.

  

Figure 7.1: 360X compliant transport protocol and referral request payload

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.  

Figure 7.2: 360X compliant application providing a single message to accommodate both 360X compliant and legacy recipients

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


docs.google.com

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

  • the submission set
  • the HL7 V2 order document entry of the payload
  • the C-CDA document entry of the payload

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

Figure 7.3: 360X compliant transport protocol and accept payload

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.

Figure 7.4: 360X compliant transport protocol and decline payload

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

Figure 7.5: 360X compliant transport protocol and scheduled notification payload

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

Figure 7.6: 360X compliant transport protocol and no show notification payload



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

Figure 7.7: 360X compliant transport protocol and interim consultation note payload

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 documentR 
(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


Figure 7.8: 360X compliant transport protocol and referral summary payload

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 documentR 
(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

Figure 7.9: 360X compliant transport protocol and request to cancel payload

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

Figure 7.10: 360X compliant transport protocol and cancel confirmation payload

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|

Appendices

Appendix A - XD* Metadata

Appendix A - XD Metadata

The Metadata for Document Sharing (XD Metadata) is defined by IHE and serves to

  • provide context for the clinical information being exchanged
  • provide information about the type of clinical activity that resulted in the creation of the exchanged objects
  • assist with storing, organizing, and locating documents

A.1 XD Metadata Objects and Associations

The XD Metadata is organized in objects. The relationships of the objects with each other, the overall structure, and the unit of exchange, is the Submission Set. It contains Document Entries, Folders and Associations. Each of the underlying objects and structures (except for Slots) are identified by an id XML attribute, which must be either a globally unique identifier like an OID or UUID, or a symbolic identifier, unique within the submissions set.

A Document Entry represents a document, or content structure of a particular type, and a Folder is a logical collection of document entries.

Associations link a source to a target. Has Member associations describe a Contains type of relationship from source to target. Only a Submission Set or a Folder can be the source. A Submission Set is never a target. Associations from Folder to a Document Entry can be a target of a Has Member association themselves.

A.2 XD Metadata Components

The metadata for an object consists of several building blocks. The XD Metadata makes use mostly of Slots, Classifications and External Identifiers.

A.2.1 Slot

A Slot is a named string list that provides metadata for an object in a name/value list pair. The characteristics of a slot are:

  • Contains a name, and one or more values
  • Name is a string without spaces
  • Value is limited to 256 characters

Example:

<rim:Slot name="slotName">
     <rim:ValueList>
          <rim:Value>String, no longer than 256 characters</rim:Value>
     </rim:ValueList>
</rim:Slot>

A.2.2 Classification

Classifications are used to represent either coded information from a given terminology (e.g. submission set content type code), or a logical structure (e.g. submission set author). When a classification is used to represent a code from a given terminology, it contains the following components

  • classificationScheme – what kind of information is represented by the code (e.g. content type); a pre-defined UUID
  • nodeRepresentation – the actual code
  • Name – the display name of the code
  • codingScheme – a slot, designating the terminology

Example: content type code for the Submission Set, using LOINC code 57133-1

<!-- classificationScheme attribute defines this as a content type code -->
<Classification id="Class01" 
 objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" 
 classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
 classifiedObject="Submission01" 
 nodeRepresentation="57133-1">
     <Slot name="codingScheme">
          <ValueList>
               <!-- The OID describes LOINC as the source of the code -->
               <Value>2.16.840.1.113883.6.1</Value>
          </ValueList>
     </Slot>
     <Name>
          <!-- The human readable description of the code -->
          <LocalizedString value="Referral" />
     </Name>
</Classification>

A.2.3 External Identifier

External Identifiers are used to provide globally unique identifiers for the metadata objects and some of their attributes. They contain the following components:

  • identificationScheme – what kind of object is being identified (e.g. document unique ID); a pre-defined UUID
  • registryObject - what metadata object this identifier is related to (e.g. the submissions set, a specific document entry). The content of this XML attribute is the value of theid of that object.
  • value - the actual unique identifier
  • Name - a predefined symbolic name for the identifier

Example: Document unique ID

<ExternalIdentifier id="d951d9a3-bf18-4fd0-a2cc-a949b403b024" registryObject="Document01" 
 identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
 value="1.2.840.114350.1.13.328.1.7.8.688883.43394">
     <Name>
          <LocalizedString xml:lang="en-us" charset="UTF-8" value="XDSDocumentEntry.uniqueId" />
     </Name>
</ExternalIdentifier>

A.3 XD Metadata Attributes

The following sections describe all metadata attributes and provide context for their use. Please refer to section 6 for an overview of the implementation requirements for 360X.

A.3.1 Submission Set - the packing slip

Metadata AttributePurpose within 360x360x SourceValueInformation
authorRepresents the provider (person or institution) that authored the document.R(*)This attribute does not have a simple value but contains sub-attributes.If present, according to the IHE framework, the authorPerson sub-attribute is required. According to the XDR and XDM specification, the authorTelecommunication is required and MUST represent the message sender. This guide requires that the authorTelecommunication be populated with the address by which subsequent communications are sent. In addition, the authorPerson OR authorInstitution MUST be populated.
intendedRecipientRepresents the provider (person OR institution) for which the referral is intended (Referral Recipient).RMUST contain a string of type XON|XCN|XTN of which the XTN portion being required. Max length is 256 characters.MUST indicate the one and only one message receiver. While this attribute allows multiple values, support for additional recipients may vary and is not guaranteed to be supported.
patientIdThe patientId as known to the recipient organization, which is used to match patients and/or referral content across disparate systems.R(*)Single Value with two components (Id Number and Assigning Authority). The required format is IdNumber^^^&OIDofAA&ISO.Represents the primary subject of care whose longitudinal records is being reflected. MUST be identical to the Document Entry patientId. The patientId is typically the patientId as known to the recipient organization of the payload. This attribute is absolutely necessary for improving the ability to automate the workflow. Based on the complexity with this attribute, the contextual examples should be used to populate this value appropriately.
referenceIdListThe referralId (Order Number).
MUST be present to uniquely identify 360x referral.		R(*)Single Value. The value shall contain the referral ID and the Assigning Authority. For example:
201300001^^^1.2.3.4.5.6^urn:ihe:iti:xds:2013:referral		Uniquely identifies the referral in an attempt to "thread" the various communications necessary to close the loop.
contentTypeCodeIndicates this is a referral request, progress note, or summary.R(*)57133-LOINC codeThe code specifying the type of clinical activity that resulted in placing these XDS Documents in this XDS-Submission Set. When available, implementations SHOULD draw from HITSP C80, version 2.0.1 table 2-144.
sourceIdIdentifies the instance of the creating entity (i.e. source system) that contributed the SubmissionSet.RSingle Value. OID.Per the IHE specification, if a "broker" is involved or the system that constructs the message vs. generates the content, the sourceId shall be different from the entity that contributed the document(s). This implementation guide suggests keeping these identifiers equal regardless if a broker is involved.
entryUUIDA globally unique identifier primarily intended for internal document management purposes.RUUIDMust be a unique value internal to this transaction.
submissionTimePoint in time when the Submission Set was created.RUTC date/time
YYYYMMDDhhmmss. Max length is 256 characters.		SHOULD be the value of the Date header.
uniqueIdGlobally unique ID for the submission set assigned by the creating entity.ROIDSHOULD use a unique ID extracted from the content, if a single value can be determined. If not, implementations SHOULD use a UUID generated from the transaction. This value must be different than the uniqueId specified on the Document.
titleSubject of the message.OText. MUST contain the substring "XDM/1.0/DDM+360x". Less than 256 characters.Recommended to be the Subject of the message
commentsNot neededOFree form text. Unbounded max length.Comments associated with the submission set. Use specific to XDS affinity domain
availabilityStatusNot neededOIf available, the value should always be
"urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"		The lifecycle status of the submission set.
homeCommunityIdNot neededO64 character OID in URI syntaxA globally unique identifier for a community.
limitedMetadataIndicates whether the submission set was created using the less rigorous requirements of metadata.OUUID 

A.3.2 Document Entry - metadata object representing and describing the document or content (i.e. C-CDA or HL7)

Metadata AttributePurpose within 360x360x SourceXDS SourceMinimal Metadata SourceValueInformation
authorRepresents the provider (person or institution) that authored the document.R2R2R2This attribute does not have a simple value but contains sub-attributes. These sub-attributes include: authorInstitution, authorPerson, authorRole, authorSpecialty and authorTelecommunication.If supplied, MUST indicate the document's author, which may be different from the message sender. At least an authorPerson, authorTelecommunication, or authorInstitution sub-attribute shall be present when the author attribute is included in the metadata.

* This is only required when the document is a C-CDA.
availabilityStatusNot neededOOOIf available, the value should always be: "urn:oasis:names:tc:ebxml
-regrep:StatusType:Approved"		The lifecycle status of the DocuentEntry. No mention in the Direct specs
classCodeSpecifies the particular type of document (e.g. Consultation note, Subsequent evaluation note, etc. for C-CDAs).R(*)RR2Code. Single value.SHOULD draw values from HITSP C80, version 2.0.1, table 2-144.
commentsComments associated with the document.OOOFree form text. Unbounded max length.No mention in the Direct specs
confidentialityCodeCode specifying the level of confidentiality of the documentOR2R2Code. Multiple Values.SHOULD draw values from HITSP C80, version 2.0.1, table 2-150. Implementations SHOULD NOT use codes that reveal the specific trigger causes of confidentiality (e.g., HIV).
creationTimeRepresents the time the author created the document.R(*)R2R2UTC date/time
YYYYMMDDhhmmss. Single Value. Max length of 256 characters.		MUST NOT use transaction-related dates/times, including the value of the RFC 5322 Date header. Implementers should look to use the header values for C-CDAs or the time in the messsage header for HL7.
entryUUIDA globally unique identifier used to identify and manage the document entry internally.RRRUUID. Unbounded max length.Must be a unique value internal to this transaction.
eventCodeListRepresents the main clinical acts being documented.OOOCode. Multiple Values.List of codes representing the main clinical acts being documented. No mention in the Direct specs. In some cases, the event is inherent in the typeCode. An event can further specialize the act inherent in the typeCode. When defining the value sets for eventCodes, they should not conflict with the values inherent in the classCode, practiceSettingCode or typeCode as such a conflict would create an ambiguous situation. 
formatCodeGlobally unique code specifying the format of the document.R(*)R2R2Code. Single Value. Any valid URN may be used as a formatCode.SHOULD draw values from HITSP C80, version 2.0.1, table 2-152, when the specific listed codes apply
HashHash key of the document which can be used to determine if the document has been altered.OROCalculated with SHA1 algorithm. Single Value. Max length is 256 characters. The endcoding is the Lexical representation of hexBinary([0-9a-fA-F]). RFC 3174.The value is coded as a case-insenstivite single value within an ebRIM Slot in the DocumentEntry. No mention in the Direct specs.
healthcareFacilityTypeCodeRepresents the type of organizational setting of the clinical encounter during which the documented act occurred. The healthcareFacilityTypeCode shall be equivalent to or further specialize the value inherent in the typeCode.OR2R2Code. Single Value.SHOULD draw values from HITSP C80, version 2.0.1, table 2-146. Implementations SHOULD populate mapped by configuration to sending organization.
homeCommunityIdGlobally unique identifier for a communityOOOOID. URN. Unbounded max length.No mention in the Direct specs
languageCodeSpecifies the human language of the character data in the documentOR2R2Code. Single Value. Max length is 256 characters.
The values of the attribute are language identifiers as described by the IETF (Internet Engineering Task Force) RFC 5646.		Coded identifiers as described by the IETF RFC 3066, conformant with IHE requirements.
legal AuthenticatorRepresents a participant within the authorInstitution who has legally authenticated or attested the document.OOOXCN (e.g., ^Welby^Marcus^^^Dr^MD). Single Value. Max length is 256 characters.No mention in the Direct specs
limitedMetadataIndicates whether the document entry was created using the less rigorous requirements of metadataRORSingle Value.No mention in the Direct specs
mimeTypeMIME type of the document.RRRString. Single Value. Unbounded max length.The C-CDA MUST have a MIME type of text/xml. The HL7 document MUST have a MIME type of x-application/hl7-v2+er7
objectTypeThe type of DocumentEntry. For 360x purposes, the value will always be StableRRRUUID. Max length is unbounded.Expected value: urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1
patientIdThe subject of care of the document. Shall match the value of the patientId attribute in the SubmissionSetR2R2R2Single Value. Contains an assigning authority domain id and an id from the assigning authority.Formatted as a HL7 CX as described in ITI TF-3 Table 4.1-3

As a conditional value, the patientId is only expected to be set on return messages (those generated by the receiving provider). The patientId should always be equal to the value sent in the sourcePatientId of the original referral request.
practiceSettingCodeSpecifies the clinical specialty where the act that resulted in the document was performed.OR2R2Code. Single value.SHOULD draw from HITSP C80, version 2.0.1, table 2-149 which is a list of members of the value set in table 2-148. These are typically SNOMED CT codes vs. NUCC codes.
referenceIdListThe referral ID.OOOSupports multiple values but there should never be more than one value. Max length is 256 characters for each value.This list is intended to contain internal and external CXi encoded identifiers. No mention in the Direct specs.
repositoryUniqueIdThe globally unique identifier of the repository where the document is stored.OOOOID. Single Value. Max length is 64 characters.The globally unique, immutable, identifier of the repository where the document is stored. No mention in the Direct specs
serviceStartTimeRepresents the start time the service being documented took place.OR2R2UTC date/time
YYYYMMDDhhmmss. Single Value. Max length is 256 characters.		This may be the same as the encounter time in case the service was delivered during an encounter. No mention in the Direct specs
serviceStopTimeRepresents the stop time the service being documented took place.OR2R2UTC date/time
YYYYMMDDhhmmss. Single Value. Max length is 256 characters. The serviceStartTime <= serviceStopTime.		This may be the same as the encounter time in case the service was delivered during an encounter. No mention in the Direct specs
SizeSize in bytes of the documentOROInteger. Single Value. Max length is 256 characters.No mention in the Direct specs
sourcePatientIdRepresents the subject of care medical record Identifier(e.g., PatientId) in the local patient Identifier Domain of the document source.R2R2R2Single Value. Shall contain zero or one value. Contains an assigning authority domain id and an id from the assigning authority. Max length is 256 characters.Formatted as a HL7 CX as described in ITI TF-3 Table 4.1-3. This field is only required for the first communication by each side. Subsequent communications do not require this field to be populated.
sourcePatientInfoDemographics information of the source patient at the time of submission.OR2R2Multiple Values. Max length is 256 characters for each value. Shall contain zero or one value list of demographic elements, where each element in the list is identified by fields from the HL7 PID segmentThis information typically includes: patient first and last name, sex, and birth date. Formatted as defined in ITI TF-3 Table 4.1-5
TitleTitle of the documentOOOFree form text with max length of 128 characters.The title is often supplemented with the classCode. Represented in ebXML as the "value" attribute of the LocalizedString element within the ebRIM Name structure. There can be only one ebRIM Name structure per DocumentEntry. No mention in the Direct specs.
typeCodeSpecifies the precise kind of document.R(*)R2R2Code. Single value.

Values should consist of: 34133-9, 11488-4, 34117-2, 18842-5, 11504-8, 28570-0, or 11506-3 for C-CDAs. 019, 041, S12, or S26 for HL7 documents.		SHOULD draw values from HITSP C80, version 2.0.1, table 2-144 and SHOULD be the same value as classCode.
uniqueIdThe globally unique identifier assigned by the document creator to this document.RRROID. Single value. Max length is 256 characters.SHOULD use a unique ID extracted from the content, if a single such value can be determined. If not, implementations SHOULD use a UUID URN, generated for the transaction. This value MUST be different from the uniqueId specified on the Submission Set
URIThe URI for the document, which consists of a relative path in the XDM structure to the file.R(*)ROString. URI. Single value. Max length is 256 characters. RFC 2616..No mention in the Direct specs

Appendix B - Consolidated CDA


Appendix B - Consolidated CDA

The Consolidated CDA Implementation Guide (C-CDA IG) is developed by US stakeholders through the HL7 standardization process. Version 1.1 of the Implementation guide is a requirement for Certified EHRT in the Meaningful Use Stage 2 program, and version 2.1 is required for MU3 and newer regulations.

The C-CDA Implementation Guide is organized in a hierarchy of templates. The top-level templates are the document-level templates, which contain a header template, and several section templates. Some section-level templates are only described as narrative templates, with no associated discrete data entries. Other section-level templates contain either optional or required discrete data entries. The following sections contain an overview of the relevant templates.

B.1 Document Templates

The document template used is NOT required and the implementer can use any appropriate valid document template type from the HL7 C-CDA R2.1 IG. The reasons we are not requiring a specific document type:

  • The ONC 2015 Edition specifications that support the MU Incentive program among other programs, does not mandate specific templates for transitions and referrals. That rule allows for and requires a minimum set of document templates: Summarization of Episode Note CCD, Referral Note, Discharge Summary (inpatient setting only). This means that EH/CAH/EP participants in the programs that utilize the 2015 Edition may be sending any one of these document types upon patient transition/referral and/or at the end of an encounter generally or specifically in response to a referral. To maximize synergy between this federal program and the requirements of 360x, 360x allows any template to be used.
  • The ONC 2015 Edition imposes the “common clinical data set” (CCDS) to be included in all of the document types. The CCDS greatly extends the minimum requirements of any one document type and makes all of them very much the same.
  • The Reason for Referral is required per 360X on any referral request which would be an acceptable extension of any document type (required for Referral Note) and allow it to be classified as a referral request
  • The C-CDA that is most appropriate for the completion of a referral, may be a generic document such as a summarization of episode CCD or it may be a document type specific to the type of referral; e.g., Consultation note, Diagnostic Imaging Report, Procedure Report. Therefore, constraining 360X compliance to a single document type, regardless of referral type, would be an artificial, limiting constraint


Convention/Legend: While the HL7 C-CDA IG nor the ONC CCDS or AMA, do not explicitly have these conventions, all have similar designations so we summarize them as:

  • R = section is required and may not be null. Per HL7 C-CDA IG, the non-null / entries required template would be used. Per ONC or AMA, the data should be populated if available and an assertion of “no data available” should be populated if not available.
  • RE = section is required but may be empty. Per HL7 C-CDA IG, the entries required template may be used with null indicators or entries optional template may be used. Per ONC or AMA, the data should be populated if available, appropriate, and not covered elsewhere in the document.
  • O = section and data are both optional.
  • * (required or optional) Addition to template means that this section or data is not explicitly listed in the HL7 C-CDA IG at all or at least as part of the document definition. The C-CDA architecture is defined so that additional sections may be added, but the rows marked as addition to template would require that addition outside the defined template definition.

 

Appendix C - Use of HL7 V2 Messages

Appendix C - Use of HL7 Version 2.x Messages

The details for the individual HL7 V2 messages used in this specification are in the following document. It includes a general overview of HL7 Version 2 messaging, and the full message structure of each message used. The parts that are required are also presented in section 6 in order to make the specification more concise and easier to understand.

View Source

Appendix D - Data Used in the Examples

Appendix D - Data Used in the Examples

The examples in this specification are based on the following patient story:

Peter Packton comes in to see his primary care provider, Dr. Anthony Allen, for an annual check-up. Dr. Allen sees Mr. Packton on September 2nd. The patient has a BMI of 30, no history of smoking, occasional chest pain with exertion, no physical signs of respiratory and cardiac problems, and a family history of coronary artery disease where his dad died of a heart attack at age 53. Dr. Allen diagnoses Mr. Packton with hypertension and an elevated LDL and decides to refer him to a cardiologist, requesting a consultation within a month. Dr. Allen sends a referral to a cardiologist, Dr. Charles Carlyle, but since Dr. Carlyle is unable to accept Mr. Packton's insurance, the referral is returned the next day to Dr. Allen's office with a reason of "Insurance out of network". Dr. Allen then sends the referral to another cardiologist, Dr. Beatrice Brown, who accepts the referral, and her practice schedules an appointment with Mr. Packton for September 8th. After seeing the patient, Dr. Brown sends her consultation report to Dr. Allen, sharing her findings, and letting him know that a CT Angiography is scheduled. The procedure is performed on September 21st, and the diagnosis of coronary artery disease is confirmed. Dr. Brown has a follow-up appointment with Mr. Packton on September 28th and sends the CTA report, including a summary of care with a proposed plan of care, which closes the referral loop.

D.1 Administrative Information

Administrative information includes demographics, various identifiers, and other administrative data which are used in the examples above.

Patient

First namePeter
Middle NamePrince
Family NamePackton
DOBAugust 17, 1958
Address8823 Harmon Avenue, Apartment 3C
CItyAnytown
StateNew Jersey
Zip66666
Patient ID
with provider A		ID: T7190334
CX Data Type: T7190334^^^&1.3.6.1.4.1.21367.2016.10.1.21.5&ISO^MRN
II Data Type: <id root="1.3.6.1.4.1.21367.2016.10.1.21.5" extension="T7190334">
Patient ID
with provider B		ID: L53HG67
CX Data Type: L53HG67^^^&1.3.6.1.4.1.21367.2016.10.1.32.11&ISO^MRN
II Data Type: <id root="1.3.6.1.4.1.21367.2016.10.1.32.11" extension="L53HG67">

Provider A

First NameAnthony
Family NameAllen
TitleMD
NPI5556667777
Organization nameNeighborhood Health Clinic
Organization OID1.3.6.1.4.1.21367.2016.10.1.21
OID for patient ID assignment1.3.6.1.4.1.21367.2016.10.1.21.5
OID for provider ID assignment1.3.6.1.4.1.21367.2016.10.1.21.10
OID for referral orders assignment1.3.6.1.4.1.21367.2016.10.1.21.15
Provider ID within
the organization		34225PC
Direct addressaallen@direct.nhc.example.org

Provider B

First NameBeatrice
Family NameBrown
TitleMD
NPI2223334444
Organization nameCardiology Partners
Organization OID1.3.6.1.4.1.21367.2016.10.1.32
OID for patient ID Assignment1.3.6.1.4.1.21367.2016.10.1.32.11
OID for provider ID assignment1.3.6.1.4.1.21367.2016.10.1.32.13
OID for appointment ID assignment1.3.6.1.4.1.21367.2016.10.1.32.17
Provider ID within
the organization		42334DG
Direct addressbbrown@direct.cpart.example.org

Provider C

First NameCharles
Family NameCarlyle
TitleMD
NPI8889990000
Organization nameCardiology Associates
Organization OID1.3.6.1.4.1.21367.2016.10.1.62
OID for patient ID Assignment1.3.6.1.4.1.21367.2016.10.1.62.12
OID for provider ID assignment1.3.6.1.4.1.21367.2016.10.1.62.14
OID for appointment ID assignment1.3.6.1.4.1.21367.2016.10.1.62.18
Provider ID within
the organization		94893CC
Direct addressccarlyle@direct.cpart.example.org

D.2 Clinical Data

Height5' 9"
Weight205 lbs
BMI30.3
Blood Pressure195/122
LDL200
CT Angiograph Impression40% stenosis of left anterior descending artery

Work in progress

To be included in an informative appendix on possible variations:

===========

In all cases, the C-CDA SHALL include the reason for referral from the OMG object. It is important for system processing that the Order (referral request) and the associated clinical information (e.g., C-CDA) be related. Four (4) means of relationship were evaluated:

  1. The order (referral request) is aware of the associated clinical data (C-CDA) and the C-CDA XML is embedded in the OBX segment of the OMG^O19; the XDM metadata would then contain just the order ID. This provides the tightest link but may have the most challenging implementation in current systems as extracting and storing C-CDAs would be part of order processing..
  2. The order (referral request) is aware of the associated clinical data (C-CDA) and the C-CDA document instance identifier is embedded as a reference pointer in the order’s OBX segment, but the C-CDA XML is separate in the XDM; the XDM would contain both the order ID and the document ID. This would slightly ease implementation on receiving systems and preserve the tight link.
  3. The associated clinical data (C-CDA) is aware of the order and puts the order’s Provider Order ID in the C-CDA US Realm Header; the XDM would contain both the order ID and the document ID. This would ease implementation on both sending and receiving systems and preserve the link but C-CDA specification is not defined to semantically represent placer order ID properly.
  4. Neither the order (referral request) nor the associated clinical data (C-CDA) are aware of each other and the XDM meta data includes both the Provider Order ID from the order and the C-CDA document ID from the US realm header. This eases implementation on sending and receiving systems but provides the loosest link between the request and associated clinical information.
============

 


Intended recipient structure

 

Intended Recipient 
<Slot name="intendedRecipient">
<ValueList>
<Value>Bernstein Clinic^^^^^&1.2.840.114350.1.13.321.1.7.3.688884.100.8&ISO^^^^1.2.840.114350.1.13.321.1.7.3.688884.100.8|</Value>
</ValueList>
</Slot>

 

Example metadata

Metadata Example 
<ns3:SubmitObjectsRequest xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0">
  <RegistryObjectList>
    <ExtrinsicObject objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" mimeType="text/xml" id="Document01">
      <Slot name="creationTime">
        <ValueList>
          <Value>20051224000000</Value>
        </ValueList>
      </Slot>
      <Slot name="languageCode">
        <ValueList>
          <Value>en-us</Value>
        </ValueList>
      </Slot>
      <Slot name="serviceStartTime">
        <ValueList>
          <Value>20041223080000</Value>
        </ValueList>
      </Slot>
      <Slot name="serviceStopTime">
        <ValueList>
          <Value>20041223080100</Value>
        </ValueList>
      </Slot>
      <Slot name="sourcePatientId">
        <ValueList>
          <Value> 998777350^^^&amp;2.16.840.1.113883.13.47&amp;ISO</Value>
        </ValueList>
      </Slot>
      <Slot name="sourcePatientInfo">
        <ValueList>
          <Value> PID-3|998777350^^^&amp;2.16.840.1.113883.13.47&amp;ISO</Value>
          <Value>PID-5|Jackson^Paul^^^</Value>
          <Value>PID-7|19620308</Value>
          <Value>PID-8|M</Value>
          <Value>PID-11|3754 SAMUEL STREET</Value>
        </ValueList>
      </Slot>
      <Name>
        <LocalizedString value="Physical"/>
      </Name>
      <Description/>
      <Classification id="cl01" classifiedObject="Document01" classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" nodeRepresentation="">
        <Slot name="authorPerson">
          <ValueList>
            <Value> |direct@medibridge.net^Richard^Braman^^^^^^&amp;2.16.840.1.113883.13.47&amp;ISO</Value>
          </ValueList>
        </Slot>
        <Slot name="authorInstitution">
          <ValueList>
            <Value>Cleveland Clinic</Value>
            <Value>Parma Community</Value>
          </ValueList>
        </Slot>
        <Slot name="authorRole">
          <ValueList>
            <Value>Attending</Value>
          </ValueList>
        </Slot>
        <Slot name="authorSpecialty">
          <ValueList>
            <Value>Orthopedic</Value>
          </ValueList>
        </Slot>
      </Classification>
      <Classification id="cl02" classifiedObject="Document01" classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" nodeRepresentation="34133-9">
        <Slot name="codingScheme">
          <ValueList>
            <Value>2.16.840.1.113883.6.1</Value>
          </ValueList>
        </Slot>
        <Name>
          <LocalizedString value="Summarization of patient data"/>
        </Name>
      </Classification>
      <Classification id="cl03" classifiedObject="Document01" classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" nodeRepresentation="N">
        <Slot name="codingScheme">
          <ValueList>
            <Value>2.16.840.1.113883.5.25</Value>
          </ValueList>
        </Slot>
        <Name>
          <LocalizedString xml:lang="en-us" value="Normal" charset="UTF-8"/>
        </Name>
      </Classification>
      <Classification id="cl04" classifiedObject="Document01" classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" nodeRepresentation="urn:ihe:pcc:xds-ms:2007">
        <Slot name="codingScheme">
          <ValueList>
            <Value>1.3.6.1.4.1.19376.1.2.3</Value>
          </ValueList>
        </Slot>
        <Name>
          <LocalizedString xml:lang="en-us" value="Medical Summaries" charset="UTF-8"/>
        </Name>
      </Classification>
      <Classification id="cl05" classifiedObject="Document01" classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" nodeRepresentation="225732001">
        <Slot name="codingScheme">
          <ValueList>
            <Value>2.16.840.1.113883.6.96</Value>
          </ValueList>
        </Slot>
        <Name>
          <LocalizedString value="Hospital-community"/>
        </Name>
      </Classification>
      <Classification id="cl06" classifiedObject="Document01" classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" nodeRepresentation="HOSP">
        <Slot name="codingScheme">
          <ValueList>
            <Value>2.16.840.1.113883.6.96</Value>
          </ValueList>
        </Slot>
        <Name>
          <LocalizedString value="Hospital"/>
        </Name>
      </Classification>
      <ExternalIdentifier id="ei01" value="998777350^^^&amp;2.16.840.1.113883.13.47&amp;ISO" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" registryObject="Document01">
        <Name>
          <LocalizedString value="XDSDocumentEntry.patientId"/>
        </Name>
      </ExternalIdentifier>
      <ExternalIdentifier id="ei02" value="2.16.840.1.113883.13.4721367.2005.3.9999.3" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" registryObject="Document01">
        <Name>
          <LocalizedString value="XDSDocumentEntry.uniqueId"/>
        </Name>
      </ExternalIdentifier>
    </ExtrinsicObject>
    <RegistryPackage id="SubmissionSet01">
      <Slot name="submissionTime">
        <ValueList>
          <Value>20041225235050</Value>
        </ValueList>
      </Slot>
      <Slot name="intendedRecipient">
        <ValueList>
          <!--Value>|john.smith@happyvalleyclinic.nhindirect.org^Smith^John^^^Dr^^^&amp;1.3.6.1.4.1.21367.3100.1&amp;ISO</Value-->
          <Value> |rbraman@medibridge.net^Smith^John^^^Dr^^^&amp;1.3.6.1.4.1.21367.3100.1&amp;ISO</Value>
        </ValueList>
      </Slot>
      <Name>
        <LocalizedString value="Physical"/>
      </Name>
      <Description>
        <LocalizedString value="Annual physical"/>
      </Description>
      <Classification id="cl08" classifiedObject="SubmissionSet01" classificationScheme="urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d" nodeRepresentation="">
        <Slot name="authorPerson">
          <ValueList>
            <Value>Sherry Dopplemeyer</Value>
          </ValueList>
        </Slot>
        <Slot name="authorInstitution">
          <ValueList>
            <Value>Cleveland Clinic</Value>
            <Value>Berea Community</Value>
          </ValueList>
        </Slot>
        <Slot name="authorRole">
          <ValueList>
            <Value>Primary Surgon</Value>
          </ValueList>
        </Slot>
        <Slot name="authorSpecialty">
          <ValueList>
            <Value>Orthopedic</Value>
          </ValueList>
        </Slot>
      </Classification>
      <Classification id="c109" classifiedObject="SubmissionSet01" classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" nodeRepresentation="History and Physical">
        <Slot name="codingScheme">
          <ValueList>
            <Value>Connect-a-thon contentTypeCodes</Value>
          </ValueList>
        </Slot>
        <Name>
          <LocalizedString value="History and Physical"/>
        </Name>
      </Classification>
      <ExternalIdentifier id="ei03" value="2.16.840.1.113883.13.47.2005.3.9999.34" identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8" registryObject="SubmissionSet01">
        <Name>
          <LocalizedString value="XDSSubmissionSet.uniqueId"/>
        </Name>
      </ExternalIdentifier>
      <ExternalIdentifier id="ei04" value="2.1" identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832" registryObject="SubmissionSet01">
        <Name>
          <LocalizedString value="XDSSubmissionSet.sourceId"/>
        </Name>
      </ExternalIdentifier>
      <ExternalIdentifier id="ei05" value="998777350^^^&amp;2.16.840.1.113883.13.47&amp;ISO" identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446" registryObject="SubmissionSet01">
        <Name>
          <LocalizedString value="XDSSubmissionSet.patientId"/>
        </Name>
      </ExternalIdentifier>
    </RegistryPackage>
    <Classification id="cl10" classifiedObject="SubmissionSet01" classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"/>
    <Association id="as01" targetObject="Document01" sourceObject="SubmissionSet01" associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember">
      <Slot name="SubmissionSetStatus">
        <ValueList>
          <Value>Original</Value>
        </ValueList>
      </Slot>
    </Association>
  </RegistryObjectList>
</ns3:SubmitObjectsRequest>

 

 

  • No labels