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. 

MSH                                Message Header 
RF1                                Referral Information
{PRD}                              Provider Data
PID                                Patient Identification
[PD1]                              Patient Additional Demographic
[{NK1}]                            Next of Kin/Associated Parties
[IN1]                              Insurance
[{DG1}]                            Diagnosis
[{AL1}]                            Allergy Information
[{IAM}]                            Patient Adverse Reaction Information
[{
	OBR                            Observation Request
	[{OBX}]                        Observation/Result
}]
PV1                                Patient Visit
[PV2]                              Patient Visit Additional Info
[{                            
    ORC                            Common Order 
    [
	    RXO                        Pharmacy/Treatment Order
	    {RXR}                      Pharmacy/Treatment Route
	    [{RXC}]                    Pharmacy/Treatment Component Order
        [{OBX}]                    Observation/Result
    ]
    [
	    RXE                        Pharmacy/Treatment Encoded Order
    	{RXR}                      Pharmacy/Treatment Route
	    [{RXC}]                    Pharmacy/Treatment Component Order
        [{OBX}]                    Observation/Result
    ]
    [
	    RXD                        Pharmacy/Treatment Dispense
	    {RXR}                      Pharmacy/Treatment Route
	    [{RXC}]                    Pharmacy/Treatment Component Order
    ]
    [
	    {RXA}                      Pharmacy/Treatment Administration
	    RXR                        Pharmacy/Treatment Route
    ]
}]
[{
    PRB                            Problem
    [VAR]                          Variance
    [
      ROL                          Role
      [VAR]                        Variance  
    ]
}]
[{
    GOL                            Goal
    [VAR]                          Variance
    [
      ROL                          Role
      [VAR]                        Variance  
    ]
}]
[{
    PTH                            Pathway
    [VAR]                          Variance
    [
      ROL                          Role
      [VAR]                        Variance  
    ]
}]

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. 

MSH                               Message Header 
MSA                               Message Acknowledgment
[ERR]                             Error
[
  RF1                               Referral Information
  {PRD}                             Provider Data
  PID                               Patient Identification
]

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

Components: <message type (ID)> ^ <trigger event (ID)> ^ <message structure (ID)>

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

† ALERT: Variance with HL7 2.4 International. Provider details are required in the PRD segment that is addressing a message (i.e. when PRD-1 includes an "Intended Recipient" - IR).

7.3.3.1 PRD-1 Provider role (CE) 01155 

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 contact role that defines the relationship of the person described in this segment to the patient being referred. When a referral is inter-enterprise in nature, there are several important relationships that must be identified. For example, the proper identification of both the referring and the referred-to provider is critical for proper processing of a referral. In addition, some enterprises may want information regarding a consulting provider or the identity of the person who actually prepared the referral. This contact role may also expand to represent affiliated persons to whom information regarding this referral must be forwarded or copied. Refer to User-defined Table 0286 - Provider role for allowed values in the Australian context.

User-defined Table 0286- Provider role

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

When sending a referral message to another provider, the intended recipient for the instance of that message must be identified. Only one PRD segment may be marked the intended recipient (IR) specified in the provider role field.

Note that provider role is a repeating field so a provider may have multiple roles.

There must only be one PRD with a PRD-1 value of "AP" (Authoring Provider) in the REF message. (See HL7au:00104.1.1)

There must only be one PRD with a PRD-1 value of "IR" (Intended Recipient) in the REF message. (See HL7au:00104.2.1)

7.3.2.2 PRD-2 Provider name (XPN) 01156

Components: In Version 2.3, replaces the PN data type. <family name (FN)> ^ <given name (ST)> ^ <second and further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <name type code (ID) > ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <name assembly order (ID)>

Subcomponents of family name (FN): <surname (ST)> & <own surname prefix (ST)> & <own surname (ST)> & <surname prefix from partner/spouse (ST)> & <surname from partner/spouse (ST)>

Definition: This field contains the name of the provider identified in this segment. Generally, this field will describe a physician associated with the referral. However, it is not limited to physicians. This field may contain the name of any valid healthcare provider associated with this referral. If this Provider Name is a physician’s name, you may refer to PRD-7-Provider identifiers for the physician identifier.

7.3.3.3 PRD-3 Provider address (XAD) 01157

Components: In Version 2.3 and later, replaces the AD data type. <street address (SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ < address type (ID)> ^ <other geographic designation (ST)> ^ <county/parish code (IS)> ^ <census tract (IS)> ^ <address representation code (ID)> ^ <address validity range (DR)> 

Definition: This field contains the mailing address of the provider identified in this segment. One of the key components to completing the “circle of care” and provider/institution bonding is the issuance of follow-up correspondence to the referring provider.

7.3.3.4 PRD-4 Provider location (PL) 01158

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)> 

Subcomponents of facility: <namespace ID (IS) & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field contains the location of the provider as needed when a provider that may be external to a given enterprise must be referenced. For example, if this provider represented the referred-to physician, the PRD-4-Provider location must identify the clinic of the physician or provider to whom this referral has been sent. The identification of the provider’s location is specified by an application and facility identifier carried in the facility field. The application ID and facility ID would be used in the same manner as their corresponding fields in the MSH segment (MSH-3-Sending application, MSH-5-Receiving application, MSH-4-Sending facility, MSH-6-Receiving facility). That is, the facility field will contain an application identifier and facility identifier which describe the location of this provider. However, it should be noted that they may describe a different location because the provider location being referenced in this field may not be the location from which the message originated, which is being described by the MSH.

7.3.3.5 PRD-5 Provider communication information (XTN) 01159

Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>

Definition: This field contains information, such as the phone number or electronic mail address, used to communicate with the provider or organization.

7.3.3.6 PRD-6 Preferred method of contact - provider (CE) 00684

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 preferred method to use when communicating with the provider. Refer to HL7 Table 0185 - Preferred method of contact for allowed values in the Australian context.

HL7 Table 0185 - Preferred method of contact

7.3.3.7 PRD-7 Provider identifiers (CM) 01162

Components: <ID number (ST)> ^ <type of ID number (IS)> ^ <other qualifying info (ST)>

Definition: This repeating field contains the provider’s unique identifiers such as UPIN, Medicare and Medicaid numbers. Refer to PRA-6-Practitioner ID numbers in Chapter 8 (Section 8.6.3.6, “Practitioner ID numbers”) for suggested values.

The field allows for multiple identifiers (in repeats of the field), for the same provider, but at least the first must be populated (HL7au:00104.7.0). Each identifier must be a qualified provider identifier (meaning that the identifier is specific to a location or indicates what organisation the provider is part of). The field must not be populated with non-location/organisation specific identifiers such as Medicare HPI-I (see HL7au:00104.7.1.3). 

<ID number (ST)> is the location or organisationally scoped provider identifier and must be valued. (see HL7au:00104.7.1.2)

<type of ID number (IS)> must be valued from User-defined Table 0363 - Assigning Authority. (see HL7au:00104.7.2.1). Table 0363 values may be extended to allow for secure messaging vendor assigning authorities.

<other qualifying info (ST)> must be a valued from HL7 Table 0203 - Identifier Type. (see HL7au:00104.7.3.1)

National identifiers must be used where available, and registered/agreed secure messaging vendor identifiers may also be used where national identifiers are unavailable. Secure messaging vendor allocated identifiers must use "VDI" as the value for <other qualifying info (ST)>.

Table 7.3.3.7.1 - Valid PRD-7 component matches

For an <type of ID number (IS)> the appropriate matching <type of ID number (IS)> and <other qualifying info (ST)> must be used. The table above shows this mapping.

7.3.3.8 PRD-8 Effective start date of provider role (TS) 01163

Definition: This field contains the date that the role of the provider effectively began. For example, this date may represent the date on which a physician was assigned as a patient’s primary care provider.

7.3.3.9 PRD-9 Effective end date of provider role (TS) 01164

Definition: This field contains the date that the role of the provider effectively ended. For example, this date may represent the date that a physician was removed as a patient’s primary care provider.

7.3.4 PID - Patient Identification segment

Refer to 2.2.1 PID - patient identification segment

7.3.5 PD1 - patient additional demographic segment

Refer to HL7 Standard Version 2.4 section 3.4.10 PD1 - PATIENT ADDITIONAL DEMOGRAPHIC SEGMENT page 3-120 .

7.3.6 NK1 - Next of kin / associated parties segment

Refer to HL7 Standard Version 2.4 section 3.4.5 NK1 - NEXT OF KIN / ASSOCIATED PARTIES SEGMENT page 3-102.

7.3.7 IN1 - Insurance segment

Refer to HL7 Standard Version 2.4 section 6.5.6 IN1 – INSURANCE SEGMENT page 6-43.

7.3.8 DG1 - Diagnosis segment

Refer to HL7 Standard Version 2.4 section 6.5.2 DG1 – DIAGNOSIS SEGMENT page 6-21.

7.3.9 AL1 - Patient allergy information segment

Refer to 2.2.4 AL1 - Patient allergy information segment.

7.3.10 IAM - Patient adverse reaction information segment

The IAM segment contains person/patient adverse reaction information of various types. Most of this information will be derived from user-defined tables. Each IAM segment describes a single person/patient adverse reaction. This segment is used in lieu of the AL1 - Patient allergy information segment to support
action code/unique identifier mode update definition of repeating segments as defined in 2.14.4.2. The AL1 segment is used to support Snapshot mode update definition as defined in 2.14.4.1. 

HL7 Attribute Table – IAM – Patient adverse reaction information – unique identifier

7.3.10.0 IAM field definitions

7.3.10.1 IAM-1 Set ID - IAM (SI) 01612

Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment, the sequence number shall be one, for the second occurrence, the sequence number shall be two, etc.

7.3.10.2 IAM-2 Allergen type code (CE) 00204

Definition: This field indicates a general allergy category (drug, food, pollen, etc.). Refer to User-defined 

Table 0127 - Allergen type for suggested values.

7.3.10.3 IAM-3 Allergen code/mnemonic/description (CE) 00205

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 uniquely identifies a particular allergen. This element may conform to some external, standard coding system (that must be identified), or it may conform to local, largely textual or mnemonic descriptions.

If a system maintains allergen codes as it's unique identifier for a particular allergy, and two systems have agreed to process the IAM using update mode, then this field can be used as the unique identifier instead of IAM-8 - Allergy Unique Identifier. This does not preclude using allergen codes for unique identifiers for snapshot processing.

7.3.10.4 IAM-4 Allergy severity code (CE) 00206

Definition: This field indicates the general severity of the allergy. Refer to User-defined Table 0128 - Allergy severity code for suggested values.

7.3.10.5 IAM-5 Allergy reaction code (ST) 00207

Definition: This field identifies the specific allergic reaction that was documented. This element may conform to some external, standard coding system, or it may conform to a local, largely textual or mnemonic descriptions (e.g., convulsions, sneeze, rash, etc.).

7.3.10.6 IAM-6 Allergy action code (CNE) 01551

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

Definition: This field contains a code defining the status of the record. It allows allergy messages to be sent to delete or update previously sent allergy messages. Refer to HL7 Table 0323 - Action code for suggested values.

HL7 Table 0323 - Action code

7.3.10.7 IAM-7 Allergy unique identifier (EI) 01552

Components: <entity identifier (ST)> ^ <assigning authority (HD)> Subcomponents of assigning authority: <application identifier 1 (IS)> & <universal identifier (UI)>

Definition: This field contains a value that uniquely identifies a single allergy for a person. It is unique across all segments and messages for a person. If a system maintains allergen codes as a unique identifier for a particular allergy, then this field should not be used.

This field is conditionally required. The surrogate field to use is IAM-3 - Allergen Code/Mnemonic/Description, if that field can uniquely identify the allergy on the receiving system.

7.3.10.8 IAM-8 Action reason (ST) 01553

Definition: This field contains the reason for the action indicated in the IAM-6 - Allergy action code field.

7.3.10.9 IAM-9 Sensitivity to Causative Agent code (CE) 01554

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 why the patient should not be exposed to a substance. Refer to User-defined Table 0436 - Sensitivity to causative Agent code for suggested values.

User-defined Table 0436 - Sensitivity to Causative Agent code

7.3.10.10 IAM-10 Allergen group code/mnemonic/description (CE) 01555

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 code, mnemonic, or description used to uniquely identify an allergen group when both a detailed allergy (IAM-3) and group level (IAM-11) need to be communicated. In cases where systems want to communicate both a specific drug allergy and the group of drugs to which the specific drug belongs (i.e., Bactrim and Sulfa drugs; Ceclor and Penicillins/Cephalosporins) then the specific drug allergy is sent in IAM-3 and the group level is sent in IAM-11. However, if only a group level is being communicated, then it can be sent in IAM-3 as the primary identifier of the allergy.

7.3.10.11 IAM-11 Onset date (DT) 01556

Definition: This field contains the actual date of the first reaction.

7.3.10.12 IAM-12 Onset date text (ST) 01557

Definition: This field contains a text description of the time period of the first reaction when an exact date is not known. (e.g., adolescence, childhood, spring 1990).

7.3.10.13 IAM-13 Reported date/time (TS) 01558

Definition: This field contains the date/time the allergy was reported to a caregiver.

7.3.10.14 IAM-14 Reported by (XPN) 01559

Components: In Version 2.3, replaces the PN data type. <family name (FN)> ^ <given name (ST)> ^ <second and further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <name type code (ID) > ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <name assembly order (ID)>

Subcomponents of family name: <family name (ST)> & <own family name prefix (ST)> & <own family name (ST)> & <family name prefix from partner/spouse (ST)> & <family name from partner/spouse (ST)>

Definition: This field contains the name of the person reporting the allergy to a caregiver at the time reported in IAM-14 - reported date/time.

7.3.10.15 IAM-15 Relationship to patient code (CE) 01560

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 personal relationship that the person reporting the allergy has to the patient. It uses the same table as that used by NK1-3. Refer to User-defined Table 0063 - Relationship for suggested values. Examples include: brother, sister, mother, father, friend, spouse, etc.

7.3.10.16 IAM-16 Alert device code (CE) 01561

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 describes any type of allergy alert device the patient may be carrying or wearing. 

Refer to User-defined Table 0437 - Alert device for suggested values.

User-defined Table 0437 - Alert device code

7.3.10.17 IAM-17 Allergy clinical status code (CE) 01562

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 indicates the verification status for the allergy. Refer to User-defined Table 0438 - Allergy clinical status for suggested values.

User-defined Table 0438 - Allergy clinical status

7.3.10.18 IAM-18 Statused by person (XCN) 01563

Components: <ID number (ST)> ^ <family name (ST) > & < last_name_prefix (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code(ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID )> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ < name representation code(ID)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)> 

Definition: This field identifies the provider who assigned the clinical status to the allergy. (e.g. ...|Smith^John^J^III^DR^MD|...).

In the Australian context, where possible, this XCN data must be populated using the method described in A10.1.2.1 XCN Datatype.

7.3.10.19 IAM-19 Statused by organization (XON) 01564

Components: <organization name (ST)> ^ <organization name type code (IS)> ^ <ID number (NM)> ^ <check digit (NM)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code (IS)> ^ <assigning facility ID (HD)> ^ <name representation code(ID)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Definition: This field contains the name of the organization providing the update to the allergy (e.g. General Hospital).

7.3.10.20 IAM-20 Statused at date/time (TS) 01565

Definition: The date and time that this allergy was last statused by the IAM-19 - Statused by person in the IAM-20 - Statused by organization.

7.3.11 ORC - Common Order segment

Refer to 5.4.1 ORC - common order segment.

The following subsections provide extra detail for use in the context of a patient referral message.

7.3.11.1 ORC-1 Order control (ID) 00215

HL7 Table 0119 - Order control codes applicable to REF^I12

The above table is a subset of HL7 Table 0119 which apply only to the patient referral message.

7.3.11.7 ORC-7 Quantity/timing (TQ) 00221

Components: <quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <priority (ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^ <total occurrences (NM)>

Refer to 5.4.1.7 ORC-7 Quantity/timing (TQ) 00221.

<quantity CQ> component should indicate the dosing quantity. Refer to  3.25 TQ - timing quantity

<interval (CM)> component should indicate the dosing interval. Refer to 3.25.2 Interval component (CM)

7.3.11.9 ORC-9 Date/time of transaction (TS) 00223

This is the date/time that the medication was recorded in the application. Refer also to ORC-15-order effective data/time.

7.3.11.12 ORC-12 Ordering provider (XCN) 00226

This field identifies the practitioner who prescribed the medication if known. If a medication history was taken but the prescribing practitioner was not recorded then it should be left unvalued.

Components: <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)

<ID number (ST)> component should be either the prescriber number or a in the case of a prescribing pharmacist their pharmacy board registration number, or a Medicare provider number or HPI-I, or if patient self prescribed valued as 'SELFPRESC'.

<family name (FN)> component must be the prescriber's surname

<given name (ST)> component must be the prescriber's first name

<second or further given names or initials thereof (ST)> component should be valued by the prescriber's initials if known

<prefix (e.g., DR) (ST)> component should be valued as the prescribers title eg. Dr

<degree (e.g., MD) (IS)> component should be the prescribers qualifications if known

<assigning authority (HD)> component must be valued as:

'AUSHIC' if a Medicare prescriber is valued in <ID number (ST)>

'AUSHICPR' if a Medicare provider number is valued in <ID number (ST)>

'<STATE>PB' if a Pharmacy board registration number is valued in <ID number (ST)>. eg. NSWPB, QLDPB, etc

'L' if <ID number (ST)> is 'SELFPRESC'

<identifier type code (IS)> component must be valued as:

'PRES' if <ID number (ST)> is a prescriber number

'PHARM' if <ID number (ST)> is a pharmacy board registration number.

'SELFPRESC' if <ID number (ST)> is 'SELFPRESC'. This means that the patient has self prescribed.

In the Australian context, where possible, this XCN data must be populated using the method described in A10.1.2.1 XCN Datatype.

7.3.11.13 ORC-13 Enterer’s location (PL) 00227

Note for the ordering provider's location use ORC-21 to ORC-24.

Refer to 5.4.1.13 ORC-13 Enterer's location (PL) 00227

7.3.11.15 ORC-15 Order effective date/time (TS) 00229

Refer to 5.4.1.15 ORC-15 Order effective date/time (TS) 00229

This field should be valued with the date and time that the prescriber certified or signed by the prescription. If unknown leave blank.

7.3.11.24 ORC-24 Ordering provider address (XAD) 01314

This field should not be used. Use ORC-22 for the address of the prescriber's facility.

7.3.12 OBR - Observation Request segment

Refer to 4.4.1 OBR - Observation Request Segment.

7.3.13 OBX - Observation/Result segment

Refer to 4.4.2 OBX - Observation/Result segment.

7.3.14 PV1 - Patient Visit segment 

Refer to 2.2.2 PV1 - patient visit segment.

7.3.15 PV2 - Patient visit - additional information segment

Refer to 2.2.3 PV2 - patient visit - additional information segment.

7.3.16 RXO - pharmacy/treatment order segment

This is the “master” pharmacy/treatment order segment. It contains order data not specific to components or additives. Unlike the OBR, it does not contain status fields or other data that are results-only.

It can be used for any type of pharmacy order, including inpatient (unit dose and compound unit dose), out patient, IVs, and hyperalimentation IVs (nutritional IVs), as well as other nonpharmacy treatments, e.g., respiratory therapy, oxygen, and many nursing treatments.

In addition to the pharmaceutical/treatment information, this segment contains additional data such as provider and text comments.

A quantity/timing field is not needed in the RXO segment. The ORC segment contains the requested ORC-7-quantity/timing of the original order which does not change as the order is encoded, dispensed, or administered.

7.3.16.0 RXO field definitions

7.3.16.1 RXO-1 Requested give code (CE) 00292

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 identifies the treatment product or treatment ordered to be given to the patient; it is analogous to OBR-4-universal service ID in function. Examples of treatments products include medications and certain devices or supplies, e.g., inhaler spacers, blood glucose monitors, syringes, infusion sets, which might require prescription.

Often the coded entry implies dosage form and a dosage form is required in addition to the product name. When the give code does not include the dosage form, use RXO-5-requested dosage form. When the give code does not include the strength, use RXO-18-requested give strength and the RXO-19-requested give units Realize that strengths do not apply to some such orders.

The RXO-1, RXO-2 and RXO-4 are mandatory unless the prescription/treatment is transmitted as free text using RXO-6, then RXO-1, RXO-2, and RXO-4 may be blank and the first subcomponent of RXO-6 must be blank.

Use of the RXO-6.2 versus the RXO-1.2 for a free text order is dependent on whether or not the free text describes a product or if it is more commentary in nature.

Please refer to the request –to-dispense fields RXO-10, RXO-11, and RXO-12 for a discussion of the inter relationship with the request-to-give fields.

Usage notes:

<identifier (ST)> component should be the code number

  For Australian Medicines Terminology (AMT) 

  For MIMS trade products packs (TPP) codes construct should be constructed as per the description of the code system name "mims-codes" as defined in the HL7 OID registry: http://www.hl7.org/oid/index.cfm?Comp_OID=1.2.36.1.2001.1005.11.1

1. The mims-codes format is a triplet of between 5 and 9 digits, comprising of all the following in order:
1. Product code: 1 to 5 digits
2. Form code: 2 digits (padded with leading 0 if <10)
3. Pack code: 2 digits (padding with leading 0 if <10)

    eg. 12930102^Pulmicort 200 mcg/ dose Turbuhaler 200 dose^mims-codes

<text (ST)> component should be the product's trade name  should always be transmitted along with the code.

<name of coding system (IS)> component should be 'EAN' or 'mims-codes' or 'AMT' appropriate to the <identifier (ST)> component.

<alternate identifier (ST)> component should be a code from an Australian medication coding system

<alternate text (ST)> component should be an Australian drug brand or generic name, if available.

<name of alternate coding system (IS)> component should be a recognised coding system such as 'mims-codes', 'AMT'

Where AMT codes are available for a product, they should be sent in the Alternative code components of the CE field.

Additional MIMS notes (informative):

• For MIMS decision support, it's recommended to use the VirtualEntities mapping file to map MIMS pack code to the FastTrack GUID. This file is included in MIMS monthly updates.
• MIMS ASCII data model has no analog for the AMT MPP concepts.
• There are some stability concerns with use of MIMS codes:
  1. MIMS pack codes are not guaranteed to be 100% immutable.
  2. Product code may change when the manufacturer elects to split the brand by formulation. In such cases, the old code will be marked as 'off-market' and new codes being issued.
  3. Form code and pack codes are currently 2 digits each. In the event, that more than 99 packs have to be created due to the PBS changes, a new form will be created. The old packs will be marked as 'off market'. This could introduce an issue when trying to re-prescribe a pack.

7.3.16.2 RXO-2 Requested give amount - minimum (NM) 00293

Definition: This field is the ordered amount. In a variable dose order, this is the minimum ordered amount. In a non-varying dose order, this is the exact amount of the order.

The RXO-1, RXO-2 and RXO-4 are mandatory unless the prescription/treatment is transmitted as free text using RXO-6, then RXO-1, RXO-2, and RXO-4 may be blank and the first subcomponent of RXO-6 must be blank.

Note: This field is not a duplication of the first component of the quantity/timing field, since in non-pharmacy/treatment orders, that component can be used to specify multiples of an ordered amount.
Another way to say this is that, for pharmacy/treatment orders, the quantity component of the quantity/timing field refers to what is to be given out at each service interval; thus, in terms of the RX order, that first component always defaults to 1. Hence, in the actual execution of the order, the value of 1 in the first component of the quantity/timing field always refers to one administration of the amount specified in this field (the Requested Give Amount field).

Usage notes:

Ensure RXO-4 is valued if this field is valued.

7.3.16.3 RXO-3 Requested give amount - maximum (NM) 00294

Definition: In a variable dose order, this is the maximum ordered amount. In a non-varying dose order, this field is not used.

7.3.16.4 RXO-4 Requested give units (CE) 00295

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 indicates the units for the give amount.

The RXO-1, RXO-2 and RXO-4 are mandatory unless the prescription is transmitted as free text using RXO-6, then RXO-1, RXO-2, and RXO-4 may be blank and the first subcomponent of RXO-6 must be
blank.

Note: These units can be a “compound quantity”; i.e., the units may contain the word “per.” For example, micrograms per KG (micg/kg) is an acceptable value, which means that the units are micrograms per KG (of body weight).

A table of standard units is needed to define standard abbreviations for compound units. Until such a table is agreed on, a user-defined table is needed for each site. If the interpretation of a compound unit requires knowledge of some observation results (such as body weight or height), these results can be sent in the
same order message using the optional OBX segments.

Usage notes:

Ensure RXO-2 is valued if this field is valued.

<identifier (ST)> component must be valued with the units provided by drug information database, such as MIMS.  TGA and UCUM  may units may be used if no drug database is used.

<text (ST)> component must be valued with a suitable display representation as provided by the system drug database

<name of coding system (IS)> component must be valued to indicate the units of measurement code system used in <identifier (ST)>. For MIMS, use "MIMS-UNITS".

<alternate identifier (ST)> component should be valued with the units of an alternate code system such as TGA or UCUM where available.

<alternate text (ST)> component should be valued with the units of an alternate display text from system such as TGA or UCUM appropriate for the <alternate identifier (ST)>.

<name of alternate coding system (IS)> component should be valued with the units of 

UCUM units are available at unitsofmeasure.org

The TGA units can be obtained from the following web site:

https://www.ebs.tga.gov.au/ and select Public TGA information/Code Tables/Units of Proportion

TGA does not permit the abbreviation of microgram as 'mcg' to avoid ambiguity.

TGA permits the abbreviation IU, however this could be a safety risk and the full term 'international units' or 'units' should be used.

Compound unit dosing is unsupported (e.g. mg per kg body weight) .

7.3.16.5 RXO-5 Requested dosage form (CE) 00296

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 indicates the manner in which the treatment is aggregated for dispensing, e.g., tab lets, capsules suppositories. In some cases, this information is implied by the dispense/give code in RXO-1-requested give code or RXO-10-Requested dispense code. Required when both RXO-1-Requested give code and RXO-10-Requested dispense code do not specify the drug/treatment form. Optionally included otherwise.

<identifier (ST)> component should be the products trade name dose form code

<text (ST)> component should be the products trade name dose form text for the user to see

<name of coding system (IS)> component should be the code system from which the trade name for code belongs. 

For MIMS, use "MIMS-FORM".

<alternate identifier (ST)> component should be the TGA 

<alternate text (ST)> component should be the TGA approved dosage form name

<name of alternate coding system (IS)> should be TGAAAN

TGA dosage form <alternate identifier (ST)> values are available at the following web site:

https://www.tga.gov.au/other-terminology-describe-medicines#dosage

7.3.16.6 RXO-6 Provider’s pharmacy/treatment instructions (CE) 00297

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 identifies the ordering provider’s instructions to the pharmacy or the non-pharmacy treatment provider (e.g., respiratory therapy). If coded, a user-defined table must be used. If transmitted as a free text field, place a null in the first component and the text in the second, e.g., |^this is a free text treatment instruction|. If the prescription is transmitted as free text using RXO-6, then RXO-1, RXO-2, and RXO-4 may be blank and the first subcomponent of RXO-6 must be blank. Otherwise, RXO-1, RXO-2 and RXO-4 are mandatory.

Usage: This field need not be used in patient referral. 

If the field is used,

the <identifier (ST)> component should be left blank,

and the <text (ST)> component should contain additional instructions that were provided to the dispenser when the medication was prescribed. 

For example "

the <name of coding system (IS)> should be blank

7.3.16.7 RXO-7 Provider’s administration instructions (CE) 00298

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 identifies the ordering provider’s instructions to the patient or to the provider administering the drug or treatment. If coded, a user-defined table must be used. If transmitted as free text, place a null in the first component and the text in the second, e.g., |^this is a free text administration instruction|.

Usage: <text (ST)> should be the free text representation of medication directions.

NB. Written words should be used in place of fractions and numbers. Plain English should be used in place of abbreviations.

an example of <text (ST)>:

NB. TQ1 should be used for numeric representation of dosing quantity and interval.

7.3.16.8 RXO-8 Deliver-to location (CM) 00299

Components: <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <patient location type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <address (AD)>

Subcomponents of facility (HD): <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

Subcomponents of address (AD): <street address (ST)> & < other designation (ST)> & <city (ST)> & <state or province (ST)> & <zip or postal code (ST)> & <country (ID)> & <address type (ID)> & <other geographic designation (ST)>

Definition: The first components, modeled after the PL data type, contain the inpatient or outpatient location to which the pharmacy provider or treatment supplier is to deliver the drug or treatment device (if applicable). The default (null) value is the current census location for the patient. This component has the same form as PV1-3-assigned patient location. The last component can be used to specify an address.

This could be used to fill mail orders to a patient or provider, or to account for home health care.

7.3.16.9 RXO-9 Allow substitutions (ID) 00300

Definition: Following are the values:

HL7 Table 0161 - Allow substitution

Usage: 

In the context of patient referral this field should be populated with a value indicating what type of substitutions were allowed when the medication was prescribed.

If this is unknown the field should be left blank.

If the field is blank receivers of the message should consider it possible that substitutions could have been made.

7.3.16.10 RXO-10 Requested dispense code (CE) 00301

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 indicates what is to be/was dispensed; it is analogous to OBR-4-universal service ID in function. It may be present in the order or not, depending on the application. If not present, and values are given for RXO-11-requested dispense amount and RXO-12-requested dispense units, the RXO-1- requested give code is assumed. If the requested dispense code does not include the dosage form, then RXO-5-requested dosage form is required

Note on request-to-dispense fields:
Sometimes an order will be written in which the total amount of the drug or treatment requested to be dispensed has no direct relationship with the give amounts and schedule. For example, an outpatient pharmacy/treatment order might be take four tablets a day of <drug name, value>, Q6H (every 6 hours) -- dispense 30 tablets. An inpatient order might be NS/D5W (normal saline with 5% dextrose) at 1000cc/hour—dispense 3 1-litre bottles of NSD5W solution. The request-to-dispense fields support this common style of ordering.

7.3.16.11 RXO-11 Requested dispense amount (NM) 00302

Definition: This field specifies the amount to be dispensed. See above note.

7.3.16.12 RXO-12 Requested dispense units (CE) 00303

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 identifies the units for the dispense amount. This must be in simple units that reflect the actual quantity of the substance to be dispensed. It does not include compound units. See above note.

7.3.16.13 RXO-13 Number of Repeats (NM) 00304

Definition: This field defines the number of times the requested dispense amount can be given to the patient, subject to local regulation. Refers to outpatient only.

Usage:

This field is optional for patient referral, but may be populated with information used when the medication was prescribed.

NB: The name of this field is changed to use the word repeat instead of the word "refill" which is an American term.

Note that hand written or printed scripts are not written this way, by convention, scripts are written with the number of repeats in addition to the initial dispense (repeats are one less than the total number to be dispensed).

7.3.16.14 RXO-14 Ordering provider’s DEA number (XCN) 00305

Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)

Definition: This field identifies the provider’s controlled substance number, if required, by site. It is defined as conditional because it is required when the substance being requested is a controlled substance (e.g., a narcotic).

Usage:

This field is not relevant for patient referral.

In the Australian context, where possible, this XCN data must be populated using the method described in A10.1.2.1 XCN Datatype.

7.3.16.15 RXO-15 Pharmacist/treatment supplier’s verifier ID (XCN) 00306

Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second or further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ < name assembly order (ID)>

Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)

Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)

Definition: This field is the provider ID of the pharmacist/treatment supplier verifier. Use if required by the pharmacy or treatment application or site on orders (or some subgroup of orders), in addition to ORC- 11-verified by.

Example:

The site requires a “verified by” provider (such as a nurse) and a “verifying pharmacist/treatment supplier” on the order. In this case the first field, ORC-11-verified by, is already present; but the second field, RXO-15-pharmacist/treatment supplier’s verifier ID, is needed.

Usage: 

This field is not required for patient referral.

In the Australian context, where possible, this XCN data must be populated using the method described in A10.1.2.1 XCN Datatype.

7.3.16.16 RXO-16 Needs human review (ID) 00307

Definition: This field uses HL7 table 0136 - Yes/no indicator. The values have the following meaning for this field:

Y Yes - Indicates that the pharmacist or non-pharmacist treatment supplier filling the order needs to
pay special attention to the text in the RXO-6-provider’s pharmacy/treatment instructions. A
warning is present.

N No - No warning is present. This is the equivalent default (null) value.

An example of the use of this field is given by the following case:

A smart Order Entry application knows of a possible drug or treatment interaction on a certain order, but the provider issuing the order wants to override the condition. In this case, the pharmacy or treatment application receiving the order will want to have a staff pharmacist or non-pharmacist treatment supplier review the interaction and contact the ordering physician.

Usage: 

This field is not required for patient referral.

7.3.16.17 RXO-17 Requested give per (time unit) (ST) 00308

Definition: This field identifies the time unit to use to calculate the rate at which the pharmaceutical is to be administered.

Format:
S<integer> = <integer> seconds
M<integer> = <integer> minutes
H<integer> = <integer> hours
D<integer> = <integer> days
W<integer> = <integer> weeks
L<integer> = <integer> months

Note: This is the same as the format specified for the DURATION component of the quantity/timing field, excluding the“X” specification.

This field is defined as conditional because it is required when the ordered substance is to be administered continuously at a prescribed rate (e.g., certain IVs). For example, if the “give amount/units” are 300 ml and the “give per” time unit is H1, the rate is 300ml/hr and the duration of this dose is 1 hour. Thus the give amount and give per time unit define the duration of the service.

This field is distinct from the “interval” component of the quantity/timing field, but it could be used in conjunction with it, as in give 300ml of NS per hr for 1 hour, repeat twice a day.

7.3.16.18 RXO-18 Requested give strength (NM) 01121

Definition: Required when RXO-1-requested give code does not specify the strength. Optionally included otherwise. This is the numeric part of the strength, used in combination with RXO-19-requested give strength units. 

The need for strength and strength unit fields in addition to the amount and amount units fields included in various RX_ segments requires explanation. Physicians can write a prescription for a drug such as Ampicillin in two ways. One way would be: “Ampicillin 250 mg capsules, 2 capsules four times a day.” In this case the give amount would be 2, the give units would be capsules, the strength would be 250 and the strength units would milligrams.

However, the provider could also write the pharmaceutical treatment as “Ampicillin 500 mg four times a day.” In this case the give amount would be 500 and the give units would be milligrams. The strength would not be reported in the RXO segment because it is not specified; the drug could be given in two 250 mg caps or one 500 mg cap. But the pharmacist would dispense a specific capsule size and would record the strength in the RXE segment as 250 or 500, depending upon which capsule size was dispensed.

Some coding systems imply the strength, units, route of administration, and manufacturer of substances within a single instructional code. NDC codes, for example, usually imply not only the medical substance, but also the strength, the units, and the form, e.g., 0047-0402-30^Ampicillin 250 MG CAPS^NDC. So all of this information can also be completely specified in RXO-1-requested give code and in the analogous CE fields in other pharmacy/treatment segments. In this case, it is not necessary to use the strength and strength units fields to specify this information.

7.3.16.19 RXO-19 Requested give strength units (CE) 01122

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

Definition: Required when both RXO-1-requested give code and RXO-10-requested dispense code do not specify the strength. Optionally included otherwise. This is the unit of the strength, used in combination with RXO-18-requested give strength.

Note: These units can be a “compound quantity;” i.e., the units may express a quantity per unit of time. For example, micrograms per hour (mg/h) is an acceptable value. These compound units are contained in the ISO+ table. See Chapter 7 for full definition of ISO+ units.

Refer to RXO-4 for instructions on how to use this field.

7.3.16.20 RXO-20 Indication (CE) 01123

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 identifies the condition or problem for which the drug/treatment was prescribed. May repeat if multiple indications are relevant.

7.3.16.21 RXO-21 Requested give rate amount (ST) 01218

Definition: This field contains the rate at which to administer a treatment, e.g., 150 ml/hr (for an IV) or 4 liters/min for nasal oxygen.

7.3.16.22 RXO-22 Requested give rate units (CE) 01219

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 units in which RXO-21-requested give rate amount is denominated.

Refer to RXO-4 for instructions on how to use this field.

7.3.16.23 RXO-23 Total daily dose (CQ) 00329

Components: <quantity (NM)> ^ <units (CE)>

Subcomponents of units: <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 total daily dose for this particular pharmaceutical as expressed in terms of actual dispense units.

7.3.16.24 RXO-24 Supplementary code (CE) 01476

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

This field accommodates the identification of any codes that might be associated with the pharmaceutical substance. Common codes include: the Generic Product Identifier (GPI), Generic Code Number_Sequence Number (GCN_SEQNO), National Drug Code (NDC).

7.3.17 RXR - Pharmacy/treatment route segment

The Pharmacy/Treatment Route segment contains the alternative combination of route, site, administration device, and administration method that are prescribed as they apply to a particular order. The pharmacy, treatment staff and/or nursing staff has a choice between the routes based on either their professional judgment or administration instructions provided by the physician.

7.3.17.0 RXR field definitions 

HL7 Attribute Table – RXR – Pharmacy/Treatment Route

7.3.17.1 RXR-1 Route (CE) 00309

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 is the route of administration.

Some current “route codes,” such as some of the NDC-derived codes include the site already. In such cases, the entire code can be included in this field as a “locally-defined code” for the CE data type. Refer to HL7 Table 0162 - Route of administration for valid values. 

HL7 Table 0162 - Route of administration

*used primarily for respiratory therapy and anesthesia delivery

7.3.17.2 RXR-2 Administration site (CE) 00310

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 site of the administration route. Refer to HL7 Table 0163 – Body Site for valid values.

As a CE data type, this field may be extended to cover a wide variety of body site codes (e.g., when SNOMED is used as the table source).

7.3.17.3 RXR-3 Administration device (CE) 00311

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 mechanical device used to aid in the administration of the drug or other treatment. Common examples are IV-sets of different types. Refer to HL7 Table 0164 - Administration device for valid entries.

HL7 Table 0164 - Administration device

7.3.17.4 RXR-4 Administration method (CE) 00312

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 identifies the specific method requested for the administration of the drug or treatment to the patient. Refer to HL7 Table 0165 - Administration method for valid values.

HL7 Table 0165 - Administration method

7.3.17.5 RXR-5 Routing instruction (CE) 01315

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 provides instruction on administration routing, especially in cases where more than one route of administration is possible. A typical case would be designating which IV line should be used when more than one IV line is a possible route for injection.

7.3.18 RXC - Pharmacy/treatment component order segment

If the drug or treatment ordered with the RXO segment is a compound drug OR an IV solution, AND there is not a coded value for OBR-4-universal service ID, which specifies the components (base and all additives), then the components (the base and additives) are specified by two or more RXC segments. The policy of the pharmacy or treatment application on substitutions at the RXC level is identical to that for the RXO level.

7.3.18.0 RXC field definitions

HL7 Attribute Table – RXC – Pharmacy/Treatment Component Order

7.3.18.1 RXC-1 RX component type (ID) 00313

Definition: Following are the values for this field:

HL7 Table 0166 - RX component type

For the non-IV case, the “B” value may still apply. For example, if a custom dermatologic salve is being prepared, the “B” item might be a standard base ointment into which other components are mixed.

The amount of the “base” specified in the “B” segment(s) is defined to be the quantity into which amounts specified in the “A” components are mixed. Thus the RXC segments as a group define the “recipe” for a particular amount (defined by the base segment(s)). The give amount, as defined in the RXO, does not need to correspond to this base amount. For example, the RXC segments may specify a recipe for a liter of a standard type of saline with 1 gram of a particular antimicrobial, while the give amount (from the RXO) may specify the administration of 2 liters of this IV-solution every 24 hours.

The amount specified in each “A” segment is defined to be the quantity to be added to the amount of the base as specified in its RXC segment.

If any “base” components are present then these should be transmitted first. The first “base” component in the transmission should be considered the “primary base” if such a distinction is necessary. Similarly, the first “additive” in the transmission should be considered the “primary additive” if such a distinction is necessary.

7.3.18.2 RXC-2 Component code (CE) 00314

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 is equivalent to OBR-4-universal service ID. It defines the base or component in the same manner as the give and dispense codes. As with the give and dispense codes, it may contain text only, code only, text + code, or text + code + units (implied or explicit). As with the give and dispense codes, if RXC-4-component units is present, this overrides the units implied by the code. If only text is present, the pharmacy or treatment application must include a manual review or reentering of the component drug or treatment.

Usage notes:

<identifier (ST)> component should be the code number

  For Australian Medicines Terminology (AMT) 

  For MIMS form use the MIMS Gencode

    e.g. 714^Beclomethasone dipropionate^MIMS-GENCODE

<text (ST)> component should be the full textual description of the generic ingredient and should always be transmitted.

 <name of coding system (IS)> component should be a 'MIMS-GENCODE', or 'AMT' appropriate to the <identifier (ST)> component.

<alternate identifier (ST)> component should be a code for an Australian approved generic name

<alternate identifier (ST)> component should be an Australian approved generic name

<name of alternate coding system (IS)> component should be a recognised generic coding system such as 'MIMS-GENCODE', 'AMT'

Addition notes for MIMS use (informative):

1. For MIMS ASCII distribution the text component should come from MIMS GENDAT table tfgeneric field.
2. Stability concern: Generics are subject to changes due to the TGA international name harmonisation exercise.

7.3.18.3 RXC-3 Component amount (NM) 00315

Definition: This field identifies the amount of this component to be added to the specified amount of the base.

7.3.18.4 RXC-4 Component units (CE) 00316

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 identifies the units for the component amount. If present, this overrides the units implied by RXC-2-component code. This must be in simple units that reflect the actual quantity of the component being added. It does not include compound units.

Refer to RXO-4 for instructions on how to use this field.

7.3.18.5 RXC-5 Component strength (NM) 01124

Definition: Use when RXC-2-component code does not specify the strength. This is the numeric part of the strength, used in combination with RXC-6-component strength units.

7.3.18.6 RXC-6 Component strength units (CE) 01125

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

Definition: Use when RXC-2-component code does not specify the strength. This is the unit of the strength, used in combination with RXC-5-component strength.

Note: These units can be a “compound quantity;” i.e., the units may express a quantity per unit of time. For example, micrograms per hour (ug/h) is an acceptable value. These compound units are contained in the ISO+ table. See Chapter 7 for full definition of ISO+ units.

Refer to RXO-4 for instructions on how to use this field.

7.3.18.7 RXC-7 Supplementary code (CE) 01476

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

This field accommodates the identification of any codes that might be associated with the pharmaceutical or other treatment substance. Common codes include: the Generic Product Identifier (GPI), Generic Code Number_Sequence Number (GCN_SEQNO), National Drug Code (NDC).

7.3.19 RXE - Pharmacy/treatment encoded order segment

Refer to HL7 Standard Version 2.4 section 4.14.4 RXE - PHARMACY/TREATMENT ENCODED ORDER SEGMENT page 4-99. Refer also to AS4700.3-2005.

7.3.20 RXD - Pharmacy/treatment dispense segment

Refer to HL7 Standard Version 2.4 section  4.14.5 RXD - PHARMACY/TREATMENT DISPENSE SEGMENT page 4-106. Refer also to AS4700.3-2005.

7.3.21 RXA - Pharmacy/treatment administration segment

Refer to HL7 Standard Version 2.4 section 4.14.7 RXA - PHARMACY/TREATMENT ADMINISTRATION SEGMENT page 4-115. Refer also to AS4700.3-2005.

7.3.22 PRB - PROBLEM DETAIL SEGMENT PRB

Refer to HL7 Standard Version 2.4 section 12.4.2 PRB - PROBLEM DETAIL SEGMENT PRB page 12-20.

7.3.23 VAR - Variance segment

Refer to HL7 Standard Version 2.4 section 12.4.5 VAR - VARIANCE SEGMENT page 12-28.

7.3.24 ROL - Role segment

Refer to HL7 Standard Version 2.4 section 12.4.3 ROL - ROLE SEGMENT page 12-24.

7.3.25 GOL - Goal segment

Refer to HL7 Standard Version 2.4 section 12.4.1 GOL - GOAL DETAIL SEGMENT page 12-17.

7.3.26 PTH - Pathway segment

Refer to HL7 Standard Version 2.4 section 12.4.4 PTH - PATHWAY SEGMENT page 12-27.

7.3.27 MSA - Message acknowledgement segment

Refer to 2.1.8 MSA - message acknowledgment segment.

7.3.28 ERR - Error segment 

Refer to 2.1.5 ERR - error segment

7.4 Representation of Clinical Information

7.4.1 Overview

Patient referral messages carry clinical information and history about the patient concerned in a structured format. 

Medication and allergies have segments groups which are designed specifically to carry that information.

Referral messages should have their information structured according to the Appendix 9 HL7v2 Virtual Medical Record (Normative) which specifies how to structure the OBX segments of a message where specific segments are not provided. 

The referral information should be indicated by an OBR-4 Universal service identifier (CE) value as per section 4.4.1.4.1 OBR-4 codes in referral messages. This indicates that this OBR and following OBX segments in that group contains clinical history and potentially contains structured VMR related data.

Patient referrals containing structured HL7v2 VMR information should contain an OBX as follows which acts as a header. Note that the OBX-4 sub-ID field is the dotted decimal root value that structured child elements must belong. In the example below this is 1 but may be another number. The LOINC value "74028-2^^LN" in OBX-3 Observation Identifier indicates that this OBX is defining the report template ID which can be found in OBX-5 Observation Value (RP).

OBX|1|RP|74028-2^^LN|1|HL7V2-VMR.v1^HL7V2 VMR&99A-9AAC5A649D18B6F2&L^TX^Octet-stream||||||F

A minimal referral should include some notes. Note that the OBX-4 sub ID (ST) contains the value 1.1.3. This value has a dotted decimal root value of "1" with the remainder of the sub-ID value being ".1.3". It therefore belongs to the report template defined in the above example which specifies "HL7V2-VMR-v1" as the report template ID.

OBX|5|FT|8251-1^Notes^LN|1.1.3|headache\.br\present for a week||||||F

7.4.2 Disallowed segments

The following segments which are must not be used by senders. Senders cannot assume that the receiver will process this information. Receivers may reject messages containing these segments using the HL7 acknowledgment protocol.

• ACC
• AUT
• CTD
• DRG
• DSC
• DSP
• GT1
• IN2
• NTE
• PR1

7.4.3 Fields for clinical history

Referral communications normally carry clinical information and history.

Clinical information is structured as grouped segments and states the occurrence or intent of the information.

Clinical history elements have an OBR-4 value as specified by 4.4.1.4.1 OBR-4 codes in referral messages.

The procedure (PR1) segment should not be used as it been deemed clinically inexpressive instead procedures should be represented in OBX segments using the procedure nodes of the VMR.

Allergies and Medications should be atomically encoded into the AL1 and RXO/RXR/RXC segments. 

For transmitting atomic history, refer to Appendix 9 HL7v2 Virtual Medical Record (Normative) which details how to structure medical record information into a series of OBX which should fall under the the Clinical Information OBR/OBX group.

7.5 Display Segments

Please refer to section 4.5 Display Segments.

Since patient referral messages may contain multiple OBR groups, each group should contain its own set of display segments for each desired rendering format.

The main body of the referral indicated by the first OBR segment with an OBR-4 value as specified in section 4.4.1.4.1 OBR-4 codes in referral messages. This OBR/OBX group should include in its rendering the atomic data contained (in atomic OBX segments including HL7 v2 VMR) from within it, plus a display representation of all atomic data content in AL1 segments (allergy), and medication data contained in RXO segment groups.

Referral messages may contain multiple display segments.

7.6 Correcting referrals sent in error

No delete mechanism exists for REF messages and if a report has been sent in error, then this should be stated in a correction to the original message with the same RF1-6 Originating Referral Identifier. Use Correction status in RF1-1 to indicate this.