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.

 

  • No labels