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

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 1: Process Flow and Transaction High Level Summary

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:

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.

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: 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. 5: Possible Handling of Exceptions