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

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

Overview and Scope

</div>

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).