7.1.1 Purpose

The Patient Referral chapter defines the message set used in patient referral communications between mutually exclusive entities. These referral transactions frequently occur between entities with different methods and systems of capturing and storing data. Such transactions frequently traverse a path connecting primary care providers, specialists, payers, government agencies, hospitals, labs, and other healthcare entities. The availability, completeness, and currency of information for a given patient will vary greatly across such a spectrum.

The referral in this specification is viewed from the perspective of the provider as an individual, irrespective of his/her affiliation with a specific institution or campus. Events triggering this kind of message are not restricted to a hospital environment, but have a community-wide area of impact in which more extensive identification of patients and healthcare providers is needed. Therefore, a referral must contain adequate identification information to meet the broadly varying requirements of the dissimilar systems within the community.

This chapter describes the various events and resulting transactions that make up the referral message set. Examples have been provided to demonstrate the use of this specification within the events described. Each event example centers on a primary care provider's encounter with a patient.

7.1.2 Australian Localisation

The Australian Referral Message has both constrained and also extended the HL7 International version to allow transmission of a full patient history in one message including referral information, patient summary, allergies, medication history and patient care (HL7 2.4 Chapter 12); problems, goals and pathways. It also allows the inclusion of procedure reports, laboratory results and radiology reports. The message itself is a packaging format and the data it contains could be transmitted in other messages, for example ORU messages and medication messages. It is intended that recipients will unpack the contents and place data in the relevant sections of their own system. Referral messages do not equate to clinical data and much of the data that could be included could be transmitted in a batch of HL7 messages containing other message types. It does however create a single unit of transmission. This specification also includes the details required to transmit a patient summary as atomic data and use of this format would allow recipient systems to populate a patient history based on the senders information.

This specification covers the specifics of the referral message but the details of the segments containing the actual Observation data are specified in Chapter 4 - Observation Reporting of this Orders and Observations standard. The structure and display rules of the Orders and Observations standard apply to the Referral Standard observations and Patient summary and the clinical content of ORU messages can be inserted directly in a referral message. In fact a referral message should be considered a Referral header (the RF1 segment), details of providers (PRD segments), a collection of ORU message content (ORC,OBR,OBX segments) (Clinical, laboratory, radiology etc), a medication summary message and patient care messages covering problems, goals and pathways. Together this content provides for the transmission of a comprehensive patient summary for the purposes of referral, discharge summary and transfer of care etc.

Appendix 8 defines a simplified referral profile. Section 7 Patient Referral defines a number of segments which allow more complex referral interactions but also have a significantly higher level of difficulty and use of this functionality will require negotiation with endpoints. For most purposes the simplified referral messages is recommended. Appendix 8 makes reference to this section for details.

7.1.2.1 Addressing

The provider or facility identifier (in PRD-7) for the PRD marked with IR meaning "Intended Recipient" (in PRD-1) is used to address each instance of the message to an endpoint. Appendix 10 defines field mapping for addressing individual instances of a REF message to a provider or healthcare facility when using the Australian Profile for Provider Directory Services.

7.1.3 Patient referral and responses

When a patient is referred by one healthcare entity (e.g., a primary care provider) to another (e.g., a specialist or lab) or when a patient inquiry is made between two separate entities, little is known about the information each party requires to identify or codify the patient. The receiving entity may have no knowledge of the patient and may require a full set of demographics, subscriber and billing information, eligibility/coverage information, pre-authorization information, and/or clinical data to process the referral. If the receiving entity already has a record of the patient, the precise requirements for identifying that patient record will vary greatly from one entity to another. The existing record of a patient residing in the database of a specialist, a lab, or a hospital may require updating with more current information. In addition, providers receiving a referral often require detailed information about the provider making the referral, such as a physician’s name and address.

7.1.3.1 Patient referral

There are clear distinctions between a referral and an order. An order is almost always an intra-enterprise transaction and represents a request from a patient’s active provider to supporting providers for clearly defined services and/or results. While the supporting provider may exercise great discretion in the performance of an order, overall responsibility for the patient’s plan of treatment remains with the ordering provider. As such, the ordering provider retains significant control authority for the order and can, after the fact, cause the order to be canceled, reinstated, etc. Additionally, detailed results produced by the supporting provider are always reported back to the ordering provider, who remains ultimately responsible for evaluating their value and relevance. A referral, on the other hand, can be either an intra- or an inter enterprise transaction and represents not only a request for additional provider support but also a transfer of a portion or all of the responsibility for the patient’s plan of treatment. Once the referral is made, the referring provider, during the transfer period, retains almost no control of any resulting actions. The referred-to provider becomes responsible for placing any additional orders and for evaluating the value and relevance of any results, which may or may not be automatically passed back to the referring provider. A referred-to provider may, in turn, also become a referring provider.

A referral message is used to support transactions related to the referral of a patient from one healthcare provider to another. This kind of message will be particularly useful from the perspective of a primary care provider referring a patient to a specialist. However, the application of the message should not be limited to this model. For example, a referral may be as simple as a physician sending a patient to another physician for a consultation or it may be as complex as a primary care provider sending a patient to a specialist for specific medical procedures to be performed and attaching the payor authorizations for those requested procedures as well as the relevant clinical information on the patient's case.

In a community model, stringent security requirements will need to be met when dealing with the release of clinical information. This message set facilitates the proper qualification of requests because the message packet will contain all the data required by any application in the community, including the necessary patient demographic information and the proper identification of the party requesting the information.

7.1.3.2 Responding to a patient referral

When a patient is referred by one provider to another or is pre-admitted, there is a great likelihood that sub sequent transactions will take place between the initiating entity (the referring or admitting physician) and the responding entity (the specialist or hospital). The subsequent transactions might include a variety of queries, orders, etc. Within those subsequent transactions, there must be a way for the initiating system to refer to the patient. The “generic” patient information included in the original referral or the pre-admit Patient Identification (PID) segment may not be detailed enough to locate the patient in the responding facility’s database, unless the responding facility has assigned a unique identifier to the new patient. Similarly, the responding system may not have record retrieval capabilities based on any of the unambiguous, facility neutral data elements (like the Social Security Number) included in the original referral or pre-admit PID
segment. This problem could result in the responding system associating subsequent orders or requests with the wrong patient. One solution to this potential problem is for the responding system to utilize the RRI message and return to the initiating system the unique internal identifier it assigns to the patient, and with which it will primarily (or even exclusively) refer to that patient in all subsequent update operations. However, the intent of the RRI message is that it will supply the originator of the referral type message with sufficient patient demographic and/or clinical information to properly process continued transactions.

7.1.4 Application roles and data process

7.1.4.1 Application roles

This Australian Standard assumes that there are three roles^* that an application can take on: a referring or referred-by provider application role, a referred-to provider application role, a querying application role, and an auxiliary application role.  These application roles define the interactions an application will have with other applications in the messaging environment. In many environments, any single application may take on more than one application role.

This Standard’s definition of application roles does not intend to define or limit the functionality of specific products developed by vendors of such applications. Instead, this information is provided to help define the model used to develop this Standard, and to provide an unambiguous way for applications to communicate with each other.

*Variance: The International Standard has 4 roles. the additional roles is: querying application role.

7.1.4.2  The referring provider application role

A referring provider application requests the services of another healthcare provider (a referred-to provider) application. There may or may not be any association between the referring provider application and the receiving entity. Although in most cases a referral environment will be inter-enterprise in nature, it is not limited to that model and applies to intra-enterprise situations also. Because the referring provider application cannot exert any control over the referred-to provider application, it must send requests to modify the status of the referred-to provider application. The referring provider application will often assume an auxiliary application role once a patient has been accepted by another application. Once this happens, the referring provider application may receive unsolicited status updates from the referred-to provider application concerning the care of a patient.

The analog of a referring provider application in a non-automated environment might be a primary care provider diagnosing a patient with a problem that must in turn be referred to a specialist for a service. The primary care provider would contact the specialist and refer the patient into his care. Often, the specialist may not receive the patient into his care, preferring instead to refer the patient to another healthcare provider. The referring provider will indicate the diagnosis and any requested services, and the specialist to whom the patient is referred will indicate whether the referral will be accepted as specified. Once a patient referral has been accepted by the specialist, the specialist may send out updates to the primary care provider concerning the status of the patient as regards any tests performed, their outcomes, etc.

7.1.4.3 The referred-to provider application role

A referred-to provider application, in the referral model, is one that performs one or more services requested by another healthcare provider (referring provider). In other words, a referred-to provider application exerts control over a certain set of services and defines the availability of those services. Because of this control, no other application has the ability to accept, reject, or otherwise modify a referral accepted by a particular referred-to provider application.

Other applications can, on the other hand, make requests to modify the status of an accepted referral “owned by” the referred-to provider application. The referred-to provider application either grants or denies requests for information, or otherwise modifies the referrals for the services over which it exerts control.

Finally, the referred-to provider application also provides information about the referral encounter to other applications. The reasons that an application may be interested in receiving such information are varied. An application may have previously requested the status of the referral encounter, or it may simply be in terested in the information for its own clinical reporting or statistical purposes. There are two methods whereby the referred-to provider applications disseminate this information: by issuing unsolicited information messages to auxiliary applications, or by responding to queries made by querying applications.

The analog of a referred-to provider application in a non-automated environment might be a specialist such as a cardiologist. A patient does not generally go to a cardiologist for routine health care. Instead, a patient generally goes to a primary care provider, who may diagnose the patient with a heart ailment and refer that patient to a cardiologist. The cardiologist would review the information provided with the referral request and determine whether or not to accept the patient into his care. Once the cardiologist accepts the patient, anyone needing information on the status of the patient must then make requests to the cardiologist. In addition, the cardiologist may forward unsolicited information regarding the treatment of the patient back to the primary care provider. Once the cardiologist accepts the referred patient, he/she may determine that additional information regarding the patient is needed. It will often take the role of a querying application by sending a query message to the patient’s primary care provider and requesting additional information on demographics, insurance information, laboratory test results, etc.

7.1.4.4 The querying application role

This is unspecified in this Australian localisation but may be implemented by site-site negotiation.

Refer to section 11.2.2.4 in the HL7 2.4 Standard.

7.1.4.5 The auxiliary application role

Like querying applications, an auxiliary application neither exerts control over nor requests changes to a referral or a referred patient. They, too, are only concerned with gathering information about a particular referral. An auxiliary application is considered an “interested third-party,” in that it is interested in any changes to a particular referral or referred patient, but has no interest in changing it or controlling it in any way. An auxiliary application passively collects information by receiving unsolicited updates from a provider application.

The analog of an auxiliary application in a non-automated environment might be any person receiving reports containing referral information. For example, an insurance company may need information about the activities a patient experiences during specific referral encounters. Primary care providers may need to forward information regarding all referred patients to a payor organization.

In turn, a primary care provider may have the ability to track electronically a patient’s medical record. She or he would then be very interested in receiving any information regarding the patient (s)he has referred to a specialist.

7.1.5 Glossary

7.1.5.1 Benefits

The services payable under a specific payor plan. They are also referred to as an insurance product, such as professional services, prescription drugs, etc.

7.1.5.2 Clinical information

Refers to the data contained in the patient record. The data may include such things as problem lists, lab results, current medications, family history, etc. For the purposes of this chapter, clinical information is limited to diagnoses (DG1& DRG), results reported (OBX/OBR), and allergies (AL1).

7.1.5.3 Dependent

Refers to a person who is affiliated with a subscriber, such as spouse or child.

7.1.5.4 Eligibility/coverage

Refers to the period of time a subscriber or dependent is entitled to benefits.

7.1.5.5 Encounter

Refers to a meeting between a covered person and a healthcare provider whose services are provided.

7.1.5.6 Guarantor

Refers to a person who has financial responsibility for the payment of a patient account.

7.1.5.7 Healthcare provider

Refers to a person licensed, certified or otherwise authorized or permitted by law to administer health care in the ordinary course of business or practice of a profession, including a healthcare facility.
 

7.1.5.8 Payor

Indicates a third-party entity who pays for or underwrites coverage for healthcare expenses. A payor may be an insurance company, a health maintenance organization (HMO), a preferred provider organization (PPO), a government agency or an agency such as a third-party administrator (TPA).

7.1.5.9 Pre-authorization

Refers to the process of obtaining prior approval as to the appropriateness of a service. Pre-authorization does not guarantee coverage.
 

7.1.5.10 Primary care provider

Indicates the provider responsible for delivering care as well as authorizing and channeling care to specialists and other providers in a gatekeeper system. The provider is also referred to as a case manager or a gatekeeper

 7.1.5.11 Referral

Means a provider’s recommendation that a covered person receive care from a different provider.

7.1.5.12 Referring provider

Indicates the provider who requests services from a specialist or another primary care provider. A referring provider may, in fact, be a specialist who is referring a patient to another specialist.

7.1.5.13 Referred-to-provider

Typically indicates a specialty care provider who provides services at the request of a primary care provider or another specialty care provider.

7.1.5.14 Specialist

Means a provider of services which are beyond the capabilities or resources of the primary care provider. A specialist is also known as a specialty care provider who provides services at the request of a primary care provider or another specialty care provider.

7.1.5.15 Subscriber

Refers to a person who elects benefits and is affiliated with an employer or insurer.

7.2 Message Definitions

7.2.1 Patient Referral Message Structure (REF_I12)

The patient referral is carried in the follow in message structure. 

REF^I12^REF_I2 Message Structure

Note: Australian localisation of the REF_I12 message structure is at variance from HL7 International V2.4 REF_I12 definition.

7.2.2 Patient Referral Acknowledgement Message structure (RRI_I12)

On receiving a REF^I12 message a system must produce a RRI^I12 response with the following message structure. The purpose of this message is to inform the originating referrer of the RF1-11 External Referral Identifier (EI) allocated by the receiving system. 

RRI^I12^RRI_I12 Referral response Information message structure

Receivers must not return clinical information to the originating referrer such as reports or results in the Referral Response Information (RRI). 

The RF1, PID, and PRD  segments must echo what was received in the referral message (REF).

Note that the RRI may contain personally identified information, therefore the handling of the message must account for the potentially sensitive nature and that RF1, PID, PRD group has been made optional for backward compatibility.

7.3 Segments

7.3.1 MSH - Message Header segment

7.3.1.0 Field definitions

Refer to 2.1.9 MSH - message header segment.

7.3.1.9 MSH-9 Message type (CM)

Refer to 2.1.9.9 MSH-9 Message type (CM).

For the patient referral message this field must be valued as:

REF^I12^REF_I12

For the referral response indication message this must be valued as

  RRI^I12^RRI_I12

7.3.2 RF1 - Referral Information segment

7.3.2.0 RF1 field definitions

† Australian variation to HL7 V2.4.

†† RF1-6, RF1-11 have been increased length to 250 characters. Australian variation to HL7V2.4. 

The RF1 segment contains the data elements that describe the nature of the referral or record transfer. The referral message has many potential uses and this segment helps clarify the purpose of the message.

7.3.2.1 RF1-1 Referral status (CE)

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field contains the status of the referral as defined by either the referred-to or the referred by provider. Refer to User-defined Table 0283 - Referral status for allowed values in the Australian context.

User Defined Table 0283

Additional Values for use in Notifications only (i.e. RF1-3 Referral type is 'NOT') 

When a corrected referral snapshot is sent, all information from the previous snapshot identified by the same RF1-6 Originating referral identifier (EI) must be replaced with the current snapshot. e.g. Allergies, Medication, Results, etc.

See section 7.6 Correcting referrals sent in error.

7.3.2.2 RF1-2 Referral priority (CE)

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

Definition: This field contains the urgency of the referral. Refer to User-defined Table 0280 - Referral priority for suggested values.

User Defined Table 0280

7.3.2.3 RF1-3 Referral type (CE)

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
Definition: This field contains the type of referral. It is loosely associated with a clinical specialty or type of resource. Refer to User-defined Table 0281 - Referral type for allowed values in the Australian context.

User-defined Table 0281 - Referral type

7.3.2.4 RF1-4 Referral disposition (CE)

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: This field contains the type of response or action that the referring provider would like from the referred-to provider. Refer to User-defined Table 0282 - Referral disposition for allowed values in the Australian context.

User-defined Table 0282 - Referral disposition

7.3.2.5 RF1-5 Referral category (CE)

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: This field contains the location at which the referral will take place. Refer to User-defined Table 0284 - Referral category for allowed values in the Australian context.

User-defined Table 0284 - Referral category

7.3.2.6 RF1-6 Originating referral identifier (EI)

Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>
Definition: This field contains the originating application’s permanent identifier for the referral. This is a composite field.

The first component is a string that identifies an individual referral. It is assigned by the originating application, and it identifies a referral, and the subsequent referral transactions, uniquely among all such referrals from a particular processing application. This field is similar to the Filler order number in ORU messages and will uniquely identify this referral message across all organisations and the identifier is scoped but the 2nd to 4th components which must reflect the HD of the originating organisation. This may differ from the MSH Sending Application values if the message is sent on by a third party.

Note: The field length of 250 characters is a variation to the HL7 International standard which has a length of 30 characters.

7.3.2.7 RF1-7 Effective date (TS)

Definition: This field contains the date on which the referral is effective.

7.3.2.8 RF1-8 Expiration date (TS)

Definition: This field contains the date on which the referral expires.

7.3.2.9 RF1-9 Process date (TS)

Definition: This field contains the date on which the referral originated. It is used in cases of retroactive approval.

7.3.2.10 RF1-10 Referral reason (CE)

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: This field contains the reason for which the referral will take place. Refer to User-defined Table 0336 - Referral reason for allowed values in the Australian context.

User-defined Table 0336 - Referral reason

Note the value 'S' includes second, third and other opinions.

7.3.2.11 RF1-11 External referral identifier (EI)

Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

Definition: This field contains an external application’s permanent identifier for the referral. That is, this referral identifier does not belong to the application that originated the referral and assigned the originating referral identifier.

The first component is a string that identifies an individual referral. It is typically assigned by the referred-to provider application responding to a referral originating from a referring provider application, and it identifies a referral, and the subsequent referral transactions, uniquely among all such referrals for a particular referred-to provider processing application. For example, when a primary care provider (referring provider) sends a referral to a specialist (referred-to provider), the specialist’s application system may accept the referral and assign it a new referral identifier which uniquely identifies that particular referral within the specialist’s application system. This new referral identifier would be placed in the external referral identifier field when the specialist responds to the primary care physician.

Note: The field length of 250 characters is a variation to the HL7 International standard which has a length of 30 characters.

7.3.3 PRD - Provider Data segment

7.3.3.0 PRD field definitions