This implementation guide is based on HL7 Messaging Standard V2.5.1, but pre-adopts from select V2.8.2 capabilities to support the Closed Loop Referral process. Additionally it draws on industry standard vocabulary.

HL7 V2.5.1 through V2.8.2 Messaging (www.HL7.org)
SNOMED (www. http://www.ihtsdo.org/snomed-ct)
LOINC (http://loinc.org)
UCUM (http://unitsofmeasure.org)
OIDS (http://www.hl7.org/oid)

Conventions

This guide adheres to the following conventions:

The guide is constructed assuming the implementer has access to the 2.5.1 through 2.8.2 versions of the HL7 Standard. Where there are variations from 2.5.1 the version that is used is referenced. Although some information from the standard is included in this implementation guide, much information from the standard has not been repeated here.
The rules outlined in HL7 2.8.2, Chapter 2B, Section 2B5, Conformance Using Message Profiles, were used to document the use case for, and constraints applied to, the messages described in this guide.
Data types have been described separately from the fields that use the data types.
No conformance information is provided for optional message elements (“O”) or unsupported (“X”). This includes cardinality, value sets and descriptive information. Implementers who want to use optional message elements should refer to the base HL7 V2.5.1 Standard to determine how these optional message elements will be used. Conformance information is provided when a conditional predicate resolves to an “R” or “RE” on either the “a” or “b” part of the expression, regardless of the opposite value, e.g., C(R/O).
This guide uses “X” as a conformance usage indicator very sparingly. Where the underlying standard indicates the segments/field/component is present for backwards compatibility (“B”) or withdrawn ("W") an “X” will be used. A small number of other message elements that are clearly out of scope for the use case have been given the "X" usage. All other message elements have either been further constrained to R/RE/C(a/b) or have been left as "O" to enable trading partners to explore additional capabilities. Note that without a clearly agreed to complementary profile between trading partners, systems do not have to send nor receive any elements marked as an "O". Neither trading partner can mandate the other to accept any such complementary profiles to enable basic referrals interfacing "out-of-the-box". The recipient should not return an error unless there is a clinical or regulatory impact as a result of discarding optional information.

Message Element Attributes

The following table describes the various attributes used by this guide to document data type attribute tables, message structure attribute tables and segment attribute tables. Not all attributes apply to all attribute tables.

Table 2-1. Message Element Attributes
Attribute	Definition
SEQ	Sequence of the elements as numbered in the HL7 message element. The SEQ attribute applies to the data type attribute table and the segment attribute table.
Component Name	Short name for the component.
Segment	Three-character code for the segment and the abstract syntax (e.g., the square and curly braces). [ XXX ] Optional and singular { XXX } Required and may repeat XXX Required and singular [{ XXX }] Optional and may repeat Note that for segment groups there is no segment code present, but the square and curly braces will still be present. The Segment attribute only applies to the Message attribute table.
DT	Data type used by this profile for HL7 element. The data type attribute applies to data type attribute tables and segment attribute tables.
Usage	Usage of the message element for this profile. Indicates whether the message element (segment, segment group, field, component, or subcomponent) is R, RE, O, X or C(a/b) in the corresponding message element. Usage applies to the message attribute table, data type attribute table and the segment attribute table, see Section 1.1.5 Usage Conformance Testing Recommendations.
Cardinality	Minimum and maximum number of times the element may appear. [0..0] Element never present. [0..1] Element may be omitted and can have, at most, one occurrence. [1..1] Element must have exactly one occurrence. [0..n] Element may be omitted or may repeat up to n times. [1..n] Element must appear at least once, and may repeat up to n times. [0..] Element may be omitted or repeat an unlimited number of times. [1..] Element must appear at least once, and may repeat unlimited number of times. [m..n] Element must appear at least m, and at most, n times. Cardinality applies only to message attribute tables and segment attribute tables.
Value Set	The set of coded values to be used with the field. The value set attribute applies only to the data type attribute tables and the segment attribute tables. The value set may equate with an entire code system part of a code system, or codes drawn from multiple code systems.
Name	HL7 descriptor of the message element. Name applies to the message attribute table, data type attribute table and the segment attribute table.
Description/Comments	Context and usage for the element. Description/Comments applies to the message attribute table, data type attribute table and the segment attribute table.

Keywords

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119^[1]. The following definitions are excerpted from the RFC:

“MUST” or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

“MUST NOT” or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.

“SHOULD” or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

“SHOULD NOT” or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

“MAY” or the adjective "OPTIONAL", mean that an item is truly optional. One software supplier may choose to include the item to enable certain capabilities while another software supplier may omit the same item. In either case, the communication partner cannot be expected to either provide it (sender) or process it (receiver) without clear and voluntary agreement between the partners.

Any further constraining of optional segments/fields/components must be agreed to by both parties and cannot be made pre-requisite to sending/receiving messages to achieve the basic interoperability described in this guide. Therefore, a sender shall not require a receiver to accept any segments/fields/components marked as optional to successfully send a message. Likewise, a receiver shall not require a sender to send any segment/fields/components marked as optional to successfully receive such a message.

Usage Conformance Testing Recommendations

The following text is pre-adopted from the HL7 V2.8.2 Conformance (Chapter 2B, 2.B.7.5). Please refer to the base standard documentation for a full explanation of conformance concepts. Usage is described here as it introduces the revised approach to conditional element handling; upon successful ballot and publication this material will be replaced with a reference to the normative documentation.

---------- start citation---------

2.B.7.5 Usage

Message content is governed by the cardinality specification associated (explicitly or implicitly) with each element of an HL7 message. Usage rules govern the expected behavior of the sending application and receiving application with respect to the element. The usage codes expand/clarify the optionality codes defined in the HL7 standard. Usage codes are employed in a message profile to constrain the use of elements defined in the standard. The usage code definitions are given from a sender and receiver perspective and specify implementation and operational requirements.

The standard allows broad flexibility for the message structures that HL7 applications must be able to receive without failing. But while the standard allows that messages may be missing data elements or may contain extra data elements, it should not be inferred from this requirement that such messages are conformant. In fact, the usage codes specified in a message profile place strict conformance requirements on the behavior of the application.

Definition of Conditional Usage

The conditional usage is defined as follows:

C(a/b) - “a” and “b” in the expression are placeholders for usage codes representing the true (“a”) predicate outcome and the false (“b”) predicate outcome of the condition. The condition is expressed by a conditional predicate associated with the element (“See section 2.b.7.9, "Condition predicate"). “a” and “b” shall be one of “R”, “RE”, “O” and/or “X”. The values of “a” and “b” can be the same.

The example C(R/RE) is interpreted as follows. If the condition predicate associated with the element is true then the usage for the element is R-Required. If the condition predicate associated with the element is false then the usage for the element is RE-Required but may be empty.

There are cases where it is appropriate to value “a” and “b” the same. For example, the base standard defines the usage of an element as “C” and the condition predicate is dependent on the presence or non-presence of another element. The profile may constrain the element that the condition is dependent on to X; in such a case the condition should always evaluate to false. Therefore, the condition is profiled to C(X/X) since the desired effect is for the element to be not supported. Note it is not appropriate to profile the element to X since this breaks the rules of allowable usage profiling (see table HL7 Optionality and Conformance Usage).

Usage Rules for a Sending Application

Optionality/Usage Indicator	Description	Implementation Requirement	Operational Requirement
R	Required	The application shall implement “R” elements.	The application shall populate “R” elements with a non-empty value.
RE	Required but may be empty	The application shall implement “RE” elements.	The application shall populate “RE” elements with a non-empty value if there is relevant data. The term “relevant” has a confounding interpretation in this definition.^[2]
C(a/b)	Conditional	An element with a conditional usage code has an associated condition predicate (See section 2.B.7.9, “Condition predicate” that determines the operational requirements (usage code) of the element. If the condition predicate associated with the element is true, follow the rules for a which shall be one of “R”, “RE”, “O” or X”: If the condition predicate associated with the element is false, follow the rules for b which shall be one of “R”, “RE”, “O” or X”. a and b can be valued the same.
X	Not supported	The application (or as configured) shall not implement “X” elements.	The application shall not populate “X” elements.
O	Optional	None. The usage indicator for this element has not yet been defined. For an implementation profile all optional elements must be profiled to R, RE, C(a/b), or X.	Not Applicable.

Usage Rules for a Receiving Application

Optionality/Usage Indicator	Description	Implementation Requirement	Operational Requirement
R	Required	The application shall implement “R” elements.	The receiving application shall process (save/print/archive/etc.) the information conveyed by a required element. A receiving application shall raise an exception due to the absence of a required element. A receiving application shall not raise an error due to the presence of a required element,
RE	Required but may be empty	The application shall implement “RE” elements.	The receiving application shall process (save/print/archive/etc.) the information conveyed by a required but may be empty element. The receiving application shall process the message if the element is omitted (that is, an exception shall not be raised because the element is missing).
C(a/b)	Conditional	The usage code has an associated condition predicate true (See section 2.B.7.9, “Condition predicate"). If the condition predicate associated with the element is true, follow the rules for a which shall one of “R”, “RE”, “O” or X”: If the condition predicate associated with the element is false, follow the rules for b which shall one of “R”, “RE”, “O” or X”. a and b can be the same.
X	Not supported	The application (or configured) shall not implement “X” elements.	None, if the element is not sent. If the element is sent the receiving application may process the message, shall ignore the element, and may raise an exception. The receiving application shall not process (save/print/archive/etc.) the information conveyed by a not-supported element.
O	Optional	None. The usage indicator for this element has not yet been defined. For an implementation profile all optional elements must be profiled to R, RE, C(a/b), or X.	None.

--------- end citation ---------

1.2. Key Technical Decisions

One of the primary features of this implementation guide is its focus on key points of broad interoperability. The HL7 implementation guides in Section 1.1. have informed the content of this specification as analysis indicated that none of the candidate guides could satisfy the use case requirements without some adjustment. This guide is the result of combining the best practices from the current body of work while making further adjustment to meet the needs of referral management interoperability across systems.

Use of ISO Object Identifier (OID)

OIDs, or Object Identifiers, provide a strong identifier that uniquely identifies the object in question and is global in scope. Examples of information that OIDs can identify are items about patients, orders, providers and organizations. This means the identifier includes enough information to remain unique when taken out of the context within which the identifier was created. The ISO OID specification (ISO/IEC 8824:1990(E)) is the globally accepted technology for this purpose and is recommended as the means to satisfy the requirement for a universally unique identifier.

HL7 has developed an implementation guide for the use of OIDs, “HL7 Implementation Guidance for Unique Object Identifiers (OIDs), Release 1”^[3], which provides guidance on how organizations can use and manage OIDs.

Use of Vocabulary Standards

This guide calls for specific vocabulary standards for the exchange of referral information such as LOINC and SNOMED CT. Standard vocabularies, enable automated decision support for patient healthcare, as well as for public health surveillance of populations. Terminology is updated periodically and it is best practice to use the most current version of the coding system.

Snapshot Mode

All messages are considered in snapshot mode.

Field Length and Truncation

This guide is silent as to the field length definition conventions, lengths, and truncation rules and directs the reader to HL7 Version 2.8.2, Chapter 2 Control for informative guidance.

The sole exception to truncation guidance in the base specification is that OBX-5 (Observation Value) SHALL NOT be truncated.

Conformance Statements

This guide includes conformance statements to clarify the requirements that will be tested to determine conformance to this guide and the profiles it defines; note the following conventions are followed in this guide:

Conformance IDs have the naming convention of CLR-NN where NN is a number to uniquely identify the statement from all others.
Conformance ID numbers are not reused, and they do not imply any sequence.
Conformance statements are aggregated at the end of this IG and are grouped by the component and profile to which they apply.
Fields that are constrained by a conformance statement include a reference to the conformance statement in the table where they are described.

2. Conformance to this Guide

Establish a base Closed Loop Referral profile OID and consider the following.

2.1. Common Profile Components

The closed loop referral profile components that can be assembled into Profiles are:

CLR_Common_Component – ID: nnnnn

This profile component indicates that the message adheres to the rules set out in this implementation guide.

Note: This profile component sets the minimum constraints on the base specification for all profiles defined by this guide and may be further constrained by additional profile components.

CLR_XO_Component – ID: NNNN

One of the basic premises of this guide is to enable senders to compose transactions that may satisfy multiple purposes, e.g., multiple implementation guides that share the same required fields and vocabulary. They therefore may populate any of the fields/components marked O (optional). At the same time this implementation guide wants to expressly reinforce that if data is sent in optional fields/segments, the receiver can completely ignore those. Therefore, the usage code X is used sparingly, while the usage code O is mostly used when the field/component is not necessary for the use case at hand. The rationale is that according to the definition of X per the base standard is "For conformant sending applications, the element shall not be sent. Conformant receiving applications may ignore the element if it is sent, or may raise an application error."

However to accommodate those implementations where the population of any optional fields remaining is not desirable, the CLR_XO_Component is defined to indicate that all of the remaining optional segments and fields that are marked O (Optional) are now considered to be marked with an X (Not Supported). Its use yields, in combination with the other profile components, a fully implementable Profile in accordance with Chapter 2B. Note though that this profile component is strictly voluntary and its use cannot be mandated by either trading partner to enable a successful results transaction.

2.2. Extended Profile Use

The sender may create other profile components or Profiles that are defined outside of this implementation guide for use in conjunction with the Profiles and profile components defined in this guide. However, those Profiles and profile components are strictly voluntary and shall be properly constrained against the base standard and the Profiles and profile components defined in Sections 2. Neither the sender nor the receiver shall require the use of any additional Profiles and profile components in combination with the profiles and profile components defined in this guide as a pre-requisite to achieve a successful send or receive of referrals. They can only be used for additional, optional capabilities.

2.3. Scope of Implementation

The base standard indicates that receiving applications “…SHALL process (save/print/archive/etc.)…”. For referral-specific data segments, e.g., OBR, OBX, this typically means saving that data. For other segments, e.g., MSH, the receiving application may not always have to save the data as the segment is focused on ensuring the results-specific data arrives in the appropriate place and therefore may have shorter-term value. Definition of a functional edge-behavior guide to further clarify these responsibilities will be addressed in a future release.

3. Messages

The following sections detail the structure of each message, including segment name, usage, cardinality and description, as well as the definition of each segment used in the message structure.

Note that the first column (Segment) is listing the cardinality and optionality according to the base standard, the second column (Name) provides the segment or group name from the base standard, while the remaining columns (Usage, Cardinality, Description) define the constraints for this implementation guide. It is therefore possible that the base standard defines a segment as optional with a cardinality of 0 or 1, while this implementation guide defines the segment in the Usage column as R, thus a cardinality of [1..1].

By providing the complete message structure in this document, the implementation guide allows an implementer can see the full capabilities of each message, even though the constraints make use of only a small subset of the message. Section 6 of the implementation guide provides the more focused extract of the message structure that contains only the required parts.

3.1. Initial Messages

OMG^O19^OMG_O19

The OMG^O19 message is constrained for transmitting referral requests to the Referral Recipient.

Table 3-1. OMG^O19^OMG_O19 Abstract Message Syntax

Segment	Name	Usage	Cardinality	Description
MSH	Message Header	R	[1..1]	The message header (MSH) segment contains information describing how to parse and process the message. This includes identification of message delimiters, sender, receiver, message type, timestamp, etc.
[{SFT}]	Software Segment	O
[{NTE}]	Notes and Comments (for Header)	O
[	PATIENT Begin	R	[1..1]
⇨PID	Patient Identification	R	[1..1]	The patient identification (PID) segment is used to provide basic demographics regarding the subject of the referral request. The subject shall be a person.
⇨[PD1]	Additional Demographics	O
⇨[{NTE}]	Notes and Comments for PID	O
⇨[{NK1}]	Next of Kin/Associated Parties	O
⇨[	PATIENT_VISIT Begin	O
⇨⇨PV1	Patient Visit	R	[1..1]	HL7 requires that the patient visit (PV1) segment be present if the VISIT group is present.
⇨⇨[PV2]	Patient Visit – Additional Information	O
⇨]	PATIENT_ VISIT End
⇨[{	INSURANCE Begin	O
⇨⇨IN1	Insurance	R	[1..1]	HL7 requires that the insurance (IN1) segment be present if the INSURANCE group is present.
⇨⇨[IN2]	Insurance Additional Info	O
⇨⇨[IN3]	Insurance Add’l Info – Cert	O
⇨}]	INSURANCE End
⇨[GT1]	Guarantor	O
⇨[{AL1}]	Allergy Information	X		All allergy information must go into the C-CDA document associated with this referral request.
]	PATIENT End
{	ORDER Begin	R	[1..1]	The ORDER is required and restricted to only one order per referral request.
⇨ORC	Common Order	R	[1..1]	The common order (ORC) segment identifies basic information about the referral request.
⇨[{	TIMING_QTY Begin	RE	[0..1]	This is valued when the ordering provider specifies timing constraints.
⇨⇨TQ1_1	Timing/Quantity	R	[1..1]	Uses the TQ1_1 flavor of TQ1.
⇨⇨[{TQ2}]	Timing/Quantity Order Sequence	O
⇨}]	TIMING_QTY End
⇨OBR	Observations Request	R	[1..1]	The observation request (OBR) segment identifies the type of observation or testing to be performed, and ties that information to the order for the testing. In the case of closed loop referral, it provides the reason for referral.
⇨[{NTE}]	Notes and Comments for OBR	O
⇨[CTD]	Contact Data	O
⇨[{DG1}]	Diagnosis	X		Any diagnosis and problem documentation must be part of the C-CDA.
⇨[{	OBSERVATION Begin	RE	[0..*]
⇨⇨OBX	Observation related to OBR	R	[1..1]	The primary reason for the study is in OBR-31. The following applies: If there is one reason for referral (or “referral question”), it SHALL be sent in OBR-31 If there are more than one reasons for referral (or “referral questions”) then: If there is at least one reason for referral , which is coded, then a coded reason for referral SHALL be present in OBR-31. The rest of the reasons for referral (coded or free text) SHALL be present in subsequent OBX segments. If all reasons for referral (or “referral questions”) are free text, then one SHALL be present in OBR-31, and the rest SHALL be present in subsequent OBX segments. Note that in this case, because of the nature of free text inquiries, it is possible that all the questions can be provided in OBR-31 without the use of OBX segments.
⇨⇨[{NTE}]	Notes and Comments	O
⇨}]	OBSERVATION End
⇨[{	SPECIMEN Begin	X
⇨⇨SPM	Specimen	R	[1..1]	HL7 requires that the specimen container (SAC) segment be present if the CONTAINER group is present.
⇨⇨[{OBX}]	Observation/Result	O
⇨⇨[{	CONTAINER Begin	O
⇨⇨⇨SAC	Specimen Container	R	[1..1]	HL7 requires that the specimen container (SAC) segment be present if the CONTAINER group is present.
⇨⇨⇨[{OBX}]	Observation/Result	O
⇨⇨}]	CONTAINER End
⇨}]	SPECIMEN End
⇨[SGH]	Segment Group Header	X		Pre-adopted from V2.8.2 to ensure that when someone uses prior results it does not get confused with the referral request data.
⇨⇨[{	PRIOR_RESULT Begin	X
⇨⇨⇨[	PATIENT_PRIOR Begin	O
⇨⇨⇨⇨PID	Patient Identification – previous result	R		HL7 requires that the patient identification (PID) segment be present if the PATIENT_PRIOR group is present.
⇨⇨⇨⇨[PD1]	Additional Demographics – previous result	O
⇨⇨⇨]	PATIENT_PRIOR End
⇨⇨⇨[	PATIENT_VISIT_PRIOR Begin	O
⇨⇨⇨⇨PV1	Patient Visit – previous result	R		HL7 requires that the patient visit (PV1) segment be present if the PATIENT_VISIT_PRIOR group is present.
⇨⇨⇨⇨[PV2]	Patient Visit Add. Info – previous result	O
⇨⇨⇨]	PATIENT_VISIT_PRIOR End
⇨⇨⇨[{AL1}]	Allergy Information – previous result	O
⇨⇨⇨{	ORDER_PRIOR Begin	R		HL7 requires that the ORDER_PRIOR group be present if the PRIOR_RESULT group is present.
⇨⇨⇨⇨[ORC]	Common Order – previous result	O
⇨⇨⇨⇨OBR	Order Detail – previous result	R	[1..1]
⇨⇨⇨⇨[{	TIMING_PRIOR Begin	O
⇨⇨⇨⇨⇨TQ1	Timing/Quantity	R	[1..1]	HL7 requires that the timing/quantity (TQ1) segment be present if the TIMING_PRIOR group is present.
⇨⇨⇨⇨⇨[{TQ2}]	Timing/Quantity Order Sequence	O
⇨⇨⇨⇨}]	TIMING_PRIOR End
⇨⇨⇨⇨[{NTE}]	Notes and Comments – previous result	O
⇨⇨⇨⇨[CTD]	Contact Data – previous result	O
⇨⇨⇨⇨{	OBSERVATION_PRIOR Begin
⇨⇨⇨⇨⇨OBX	Observation/Result – previous result	R
⇨⇨⇨⇨⇨[{NTE}]	Notes and Comments - previous result	O
⇨⇨⇨⇨}	OBSERVATION_PRIOR End
⇨⇨⇨}	ORDER_PRIOR End
⇨⇨}]	PRIOR_RESULT End
⇨[SGT]	Segment Group Trailer	X		Pre-adopted from V2.8.2 to ensure that when someone uses prior results it does not get confused with the referral request data.
⇨[{FT1}]	Financial Transaction	X		Consider making this an X. Not needed if we have a slot for authorization number.
⇨[{CTI}]	Clinical Trial Identification	O
⇨[ BLG ]	Billing Segment	X		Consider making this an X. Not needed if we have a slot for authorization number.
}	ORDER End

Conformance Statements: Message level OMG^O19^OMG_O19

CLR-1: MSH-9 (Message Type) SHALL contain OMG^O19^OMG_O19

CLR-2: There SHALL be one instance each of the PID, ORC, and OBR segments

CLR-3: The value of ORC-2 (Placer Order Number) SHALL be identical to the value of OBR-2 (Placer Order Number)

CLR-4: The value of ORC-12 (Ordering Provider) SHALL be identical to the value of OBR-16 (Ordering Provider)

CLR-5: The value of OBR-4 (Universal Service Identifier) SHALL be the LOINC code "57133-1" for "Referral Note"

OSU^O51^OSU_O51

The OSU^O51 will be used for various status updates, including the one to indicate the order is complete when the results (C-CDA) are available. Note that this works and does not require an ORU since the frequency of the order will only be 1. If that scope changes in the future we may need to consider using the ORU in some instance.

Table 3-2. OSU^O51^OSU_O51 Abstract Message Syntax

Segment	Name	Usage	Cardinality	Description
MSH	Message Header	R	[1..1]	Using the V2.5.1 definition, even though this is a V2.9 message structure.
[{ SFT }]	Software	O		Using the V2.5.1 definition, even though this is a V2.9 message structure.
[ UAC ]	User Authentication Credential	O		Using the V2.5.1 definition, even though this is a V2.9 message structure.
[{ NTE }]	Notes and Comments (for Header)	O		Using the V2.5.1 definition, even though this is a V2.9 message structure.
[ PID ]	Patient Identification	R	[1..1]	Using the V2.5.1 definition, even though this is a V2.9 message structure.
[{PRT}]	Participation	O		Since the message using V2.5.1 as the base, this segment is not needed, even though the message structure is from V2.9.
[{ARV}]	Access Restrictions	O		Using the V2.5.1 definition, even though this is a V2.9 message structure.
{	ORDER_STATUS Begin	R
⇨ORC	Common Order	R	[1..1]	Using the V2.5.1 definition, even though this is a V2.9 message structure.
⇨{[ PRT ]}	Participation	O		Since the message using V2.5.1 as the base, this segment is not needed, even though the message structure is from V2.9.
}	ORDER_STATUS End

Conformance Statements: Message level OSU^O51^OSU_O51

CLR-6: MSH-9 (Message Type) SHALL contain OSU^O51^OSU_O51

CLR-7: There SHALL be one instance each of the PID, and ORC segments

SIU^S12^SIU_S12

The SIU^S12, SIU^S13, and the SIU^S15 messages will be used in the transaction to communicate the state of a scheduled appointment as a consequence of the referral request. This may be upon receipt of the initial request, reschedule after a no show, follow-up visit, etc.

Note that S14, and S16 through S24 are out of scope and not allowed at all.

Table 3-3. SIU^S12^SIU_S12 Abstract Message Syntax

Segment	Name	Usage	Cardinality	Description
MSH	Message Header	R
SCH	Schedule Activity Information	R
[ { TQ1_2 } ]	Timing/Quantity	R	[1..1]	This uses the TQ1_2 flavor of TQ1.
[ { NTE } ]	Notes and Comments for the SCH	O
[{	PATIENT Begin	R	[1..1]
⇨PID	Patient Identification	R	[1..1]
⇨[ PD1 ]	Additional Demographics	O
⇨[ PV1 ]	Patient Visit	O
⇨[ PV2 ]	Patient Visit - Additional Info	O
⇨[{OBX}]	Observation/Result	X
⇨[{DG1}]	Diagnosis	X
}]	PATIENT End
{	RESOURCES Begin	R	[1..*]	HL7 requires that the RESOURCES group is present.
⇨RGS	Resource Group Segment	R	[1..1]
⇨[{	SERVICE Begin	O	[0..*]
⇨⇨AIS	Appointment Information - Service	R	[1..1]
⇨⇨[{NTE}]	Notes and Comments for the AIS	O
⇨}]	SERVICE End
⇨[{	GENERAL_RESOURCE Begin	O
⇨⇨AIG	Appointment Information - General Resource	R	[1..1]	HL7 requires that the appointment information general resource (AIG) segment be present if the GENERAL_RESOURCE group is present.
⇨⇨[{NTE}]	Notes and Comments for the AIG	O
⇨}]	GENERAL_RESOURCE End
⇨[{	LOCATION_RESOURCE Begin	O
⇨⇨AIL	Appointment Information - Location Resource	R	[1..1]	HL7 requires that the appointment information location resource (AIL) segment be present if the LOCATION_RESOURCE group is present.
⇨⇨[{NTE}]	Notes and Comments for the AIL	O
⇨}]	LOCATION_RESOURCE End
⇨[{	PERSONNEL_RESOURCE Begin	RE	[0..*]	Use this segment group if you want to specify certain clinicians or other staff to be explicitly part of the appointment.
⇨⇨AIP	Appointment Information - Personnel Resource	R	[1..1]	HL7 requires that the appointment information personnel resource (AIP) segment be present if the PERSONNEL_RESOURC group is present.
⇨⇨[{NTE}]	Notes and Comments for the AIP	O
⇨}]	PERSONNEL_RESOURCE End
}	RESOURCE End

Conformance Statements: Message level SIU^S12,S13,S15^SIU_S12

CLR-10: MSH-9 (Message Type) SHALL contain SIU^S12^SIU_S12 for new appointment, SIU^S13^SIU_S12 for appointment reschedule, and SIU^S15^SIU_S12 for appointment cancel

CLR-11: There SHALL be one instance each of the SCH, TQ1, PID, and RGS segments

CLR-12: The value of RGS-2 SHALL be A for a new appointment (SIU^S12), or U, if an appointment is rescheduled (SIU^S13), or D, if appointment is cancelled (SIU^S15)

CLR-13: The value of AIP-2, if present, SHALL match the value of RGS-2

SIU^S26^SIU_S12

The SIU^S26 transaction is used to communicate a no show regarding the patient. It is expected that a scheduled appointment notification has been already sent via an SIU^S12^SIU_S12 message, and this no-show message is related to the already scheduled visit.

Note that S13 through S24 are out of scope and not allowed at all.

Table 3-4. SIU^S26^SIU_S12 Abstract Message Syntax

Segment	Name	Usage	Cardinality	Description
MSH	Message Header	R
SCH	Schedule Activity Information	R
[ { TQ1_2 } ]	Timing/Quantity	R	[1..1]	This uses the TQ1_2 flavor of TQ1.
[ { NTE } ]	Notes and Comments for the SCH	O
[{	PATIENT Begin	R	[1..1]
⇨PID	Patient Identification	R	[1..1]
⇨[ PD1 ]	Additional Demographics	O
⇨[ PV1 ]	Patient Visit	O
⇨[ PV2 ]	Patient Visit - Additional Info	O
⇨[{OBX}]	Observation/Result	X
⇨[{DG1}]	Diagnosis	X
}]	PATIENT End
{	RESOURCES Begin	R	[1..*]	HL7 requires that the RESOURCES group is present.
⇨RGS	Resource Group Segment	R	[1..1]	We will populate with least amount of data, preferably fixed.
⇨[{	SERVICE Begin	O
⇨⇨AIS	Appointment Information - Service	R	[1..1]
⇨⇨[{NTE}]	Notes and Comments for the AIS	O
⇨}]	SERVICE End
⇨[{	GENERAL_RESOURCE Begin	X
⇨⇨AIG	Appointment Information - General Resource	R	[1..1]	HL7 requires that the appointment information general resource (AIG) segment be present if the GENERAL_RESOURCE group is present.
⇨⇨[{NTE}]	Notes and Comments for the AIG	O
⇨}]	GENERAL_RESOURCE End
⇨[{	LOCATION_RESOURCE Begin	X
⇨⇨AIL	Appointment Information - Location Resource	R	[1..1]	HL7 requires that the appointment information location resource (AIL) segment be present if the LOCATION_RESOURCE group is present.
⇨⇨[{NTE}]	Notes and Comments for the AIL	O
⇨}]	LOCATION_RESOURCE End
⇨[{	PERSONNEL_RESOURCE Begin	O
⇨⇨AIP	Appointment Information - Personnel Resource	R	[1..1]	HL7 requires that the appointment information personnel resource (AIP) segment be present if the PERSONNEL_RESOURC group is present.
⇨⇨[{NTE}]	Notes and Comments for the AIP	O
⇨}]	PERSONNEL_RESOURCE End
}	RESOURCE End

Conformance Statements: Message level SIU^S26^SIU_S12

CLR-14: MSH-9 (Message Type) SHALL contain SIU^S26^SIU_S12

CLR-15: There SHALL be one instance each of the SCH, TQ1, PID, and RGS segments

CLR-16: The value of RGS-2 SHALL be D

3.2. Acknowledgement Messages

Although the payload contains a full V2 message to manage the state of the referral request and schedule, the system level acknowledgement will not be required. Future versions with enhancements to address non-Direct exchange of referral data is likely to introduce the additional acknowledgement messages, with the corresponding changes to fields MSH-15 and MSH-16.

Error handling

Definitions:

Hard Error – stop; suspend processing and notify sender, do not commit info to patient record
Soft Error – notify (as directed) but can continue to process message unless a hard error is encountered prior to end of message processing; may commit data to patient record while informing sender of soft errors.

Data errors, which lead to inability to respond to the referral request, can be relayed in a Referral Decline transaction via the OSU^O51 message. Once a referral is accepted, however, errors will need to be handled out of band.

4. Segment and Field Descriptions

This messaging guide provides notes for required (non-optional) fields for each of the non-optional segments. For each segment the segment table defines the applicable constraints on usage for its fields for this implementation guide (see Message Element Attributes for a description of the columns in the Segment Attribute Tables.) All the relevant conformance statements and general usage notes are located at the end of each table.

Note that any optional segments that are brought forward from the base will have to be used within the constraints set forth in this guide, e.g., agreement about which CWE data type to use needs to be reached.

MSH – Message Header Segment

Table 4‑1 Message Header Segment (MSH)

SEQ	Element Name	DT	Usage	Cardinality	Value Set	Description/Comments
1	Field Separator	ST	R	[1..1]		Constrained to be the single character '\|'
2	Encoding Characters	ST	R	[1..1]		Constrained to the literal values '^~\&' or '^~\&#', always appearing in the same order.
3	Sending Application	HD_1	O
4	Sending Facility	HD_1	R	[1..1]		If acknowledgments are in use, this facility will receive any related acknowledgment message. Note that the Direct XDM Source value reflects the Sending Facility in OMG. Also note that when C-CDA and OMG reference the same OID, then HD-1 value (when present) and the corresponding C-CDA component must be valued the same.
5	Receiving Application		O
6	Receiving Facility	HD_1	RE	[0..1]		If acknowledgments are in use, this facility originates any related acknowledgment message. Note this may be included in the intended recipient metadata as the intended recipient's facility.
7	Date/Time Of Message	DTM_1	R	[1..1]		If the time zone offset is included in MSH-7 it becomes the default time zone for the message instance and applies to all other date/time fields in that same message instance where a time zone offset is not valued.
8	Security		O
9	Message Type	MSG	R	[1..1]
10	Message Control ID	ST	R	[1..1]		String that identifies the message instance from the sending application. Example formats for message control IDs include GUID, timestamp plus sequence number, OID plus sequence number, or just a sequence number. The important point is that care must be taken to ensure that the message control id is unique within the system originating the message. Although desired to be unique "forever", it at least must be unique for a reasonable amount of time before it is recycled, e.g., months.
11	Processing ID	PT	R	[1..1]
12	Version ID	VID	R	[1..1]	US_CLR_HL70104	HL7 version number used to interpret format and content of the message. Constrained to the literal value ‘2.5.1’. Note that receivers must examine MSH-21 (Message Profile Identifier) to understand which message profile the message instance conforms with.
13	Sequence Number		O
14	Continuation Pointer		O
15	Accept Acknowledgment Type	ID	R	[1..1]	US_CLR_HL70155	Set to "NE". Other values may become possible in the future when alternative communication methods are added to the specification.
16	Application Acknowledgment Type	ID	R	[1..1]	US_CLR_HL70155	Set to "NE". Other values may become possible in the future when alternative communication methods are added to the specification.
17	Country Code		O
18	Character Set		O
19	Principal Language Of Message		O
20	Alternate Character Set Handling Scheme		O
21	Message Profile Identifier	EI	R	[1..*]		The "root" OID comes from IHE.

Usage Note

The MSH-21 field shall identify the base closed loop referral interface profile. Additional compatible profiles or components can be present in MSH-21; for example, if a CLR profile or component is further constrained. MSH-21 shall not be populated with conflicting CLR profiles or CLR components.

The sequence of the elements in MSH-21 is not important and cannot be relied on. To improve readability, implementers are encouraged to start with the base lab result ID followed by additional profiles and/or profile component IDs that add constraints.

Conformance Statements: MSH Segment

CLR-17: MSH-1 (Field Separator) SHALL contain the constant value ‘|’.

CLR-18: MSH-2 (Encoding Characters) SHALL contain the constant value ‘^~\&’ or the constant value ‘^~\&#’.

CLR-19: MSH-12.1 (Version ID) SHALL contain the constant value ‘2.5.1’.

CLR-20: MSH-21 (Message Profile Identifier) SHALL contain one of the following values:

MSH 21 Acknowledgment Profile (Component) Combinations
360X Profile	Pre-Coordinated OID	Component OIDs	Component Name
To be completed

Example: REF_Common_Component OIDs

MSH…|||||REF_Common_Component^^to be provided

PID – Patient Identification Segment

Table 4‑2. Patient Identification Segment (PID)

SEQ	Element Name	DT	Usage	Cardinality	Value Set	Description/Comments
1	Set ID – PID	SI	R	[1..1]		Constrained to the literal value ‘1’.
2	Patient ID		X			Excluded for this Implementation Guide, see Conventions in Section 1
3	Patient Identifier List	CX	R	[1..*]		At minimum as known to the source. Possibly additionals as known to the destination or a common identifier.
4	Alternate Patient ID – PID		X			Excluded for this Implementation Guide, see Conventions in Section 1
5	Patient Name	XPN	R	[1..*]
6	Mother’s Maiden Name		O
7	Date/Time of Birth	DTM_2	RE	[0..1]
8	Administrative Sex	IS	R	[1..1]	US_CLR_HL70001	Patient’s gender. NOTE: Make sure it is in the XDM/C-CDA metadata
9	Patient Alias		X			Excluded for this Implementation Guide, see Conventions in Section 1
10	Race		O
11	Patient Address		O
12	County Code		X			Excluded for this Implementation Guide, see Conventions in Section 1
13	Phone Number – Home		O
14	Phone Number – Business		O
15	Primary Language		O
16	Marital Status		O
17	Religion		O
18	Patient Account Number		O
19	SSN Number – Patient		X			Excluded for this Implementation Guide, see Conventions in Section 1
20	Driver’s License Number – Patient		X			Excluded for this Implementation Guide, see Conventions in Section 1
21	Mother’s Identifier		O
22	Ethnic Group		O
23	Birth Place		O
24	Multiple Birth Indicator		O
25	Birth Order		O
26	Citizenship		O
27	Veterans Military Status		O
28	Nationality		X			Excluded for this Implementation Guide, see Conventions in Section 1. Suggest to go to Optional.
29	Patient Death Date and Time		O
30	Patient Death Indicator		O
31	Identity Unknown Indicator		O
32	Identity Reliability Code		O
33	Last Update Date/Time		O
34	Last Update Facility		O
35	Species Code		O
36	Breed Code		X			Excluded for this Implementation Guide, see Conventions in Section 1
37	Strain		X			Excluded for this Implementation Guide, see Conventions in Section 1
38	Production Class Code		X			Excluded for this Implementation Guide, see Conventions in Section 1
39	Tribal Citizenship		O

Usage Note

PID-5 (Patient Name): This Guide pre-adopts the concept that nothing is implied by the sequence of repeats, i.e., the first occurrence cannot be assumed to be the legal name; each repeat of PID-5 must have an accompanying PID-5.7 (Name Type Code). However, lacking any other mechanism to declare otherwise, it is assumed that the first occurrence sent in an OMG message is the name that will appear on the accompanying C-CDA, regardless of the value of PID-5.7.

Conformance Statements: PID segment

CLR-21: PID-1 (Set ID - PID) SHALL be valued with the constant value ‘1’.

ORC – Common Order Segment

Table 4‑3. Common Order Segment (ORC)

SEQ	Element Name	DT	Usage	Cardinality	Value Set	Description/Comments
1	Order Control	ID	R	[1..1]	US_CLR_HL70119
2	Placer Order Number	EI	R	[1..1]		Represents the Referral Identifier.
3	Filler Order Number		O
4	Placer Group Number		O
5	Order Status	ID	Varies	[0..1]	US_CLR_HL70038	In OMG^O19^OMG_O19 = Optional In OSU^O51^OSU_O51 = Required
6	Response Flag		O
7	Quantity/Timing		X			Excluded for this Implementation Guide, see Conventions in Section 1.
8	Parent		O
9	Date/Time of Transaction		O
10	Entered By		O
11	Verified By		O
12	Ordering Provider	XCN_1	Varies	[1..1]		OMG = R OSU = X This is the referrig provider. Providers should be identified using their NPI. Matches the Submission Set author in the metadata of the referral request.
13	Enterer's Location		O
14	Call Back Phone Number		O
15	Order Effective Date/Time		O
16	Order Control Code Reason		RE
17	Entering Organization		O
18	Entering Device		O
19	Action By		O
20	Advanced Beneficiary Notice Code		X			Excluded for this Implementation Guide, see Conventions in Section 1. Suggest to go to Optional.
21	Ordering Facility Name		O
22	Ordering Facility Address		O
23	Ordering Facility Phone Number		O
24	Ordering Provider Address		O
25	Order Status Modifier		O
26	Advanced Beneficiary Notice Override Reason		C(X/X)			Excluded for this Implementation Guide, see Conventions in Section 1.
27	Filler's Expected Availability Date/Time		O
28	Confidentiality Code		O
29	Order Type		O
30	Enterer Authorization Mode		O
31	Parent Universal Service Identifier		X

TQ1_1 – Timing/Quantity Segment

This segment is used to convey an urgent request for consultation. If there is a time limit by which the patient must be seen by the referral recipient, that date is sent in TQ1-8. If a system uses a set of priority flags (e.g. U(rgent), A(SAP)), these flags must be converted to a date based on local policies and settings. The flags themselves may be sent in TQ1-9 in addition to the date in TQ1-8, however this implementation guide does not specify any particular values for TQ1-9.

If there is no specific urgency in the referral beyond normally expected turnaround times, this segment SHOULD be omitted from the OMG^O19_OMG_O19 message.

Table 4‑4. Timing/Quantity Segment for Order Group (TQ1)

SEQ	Element Name	DT	Usage	Cardinality	Value Set	Description/Comments
1	Set ID - TQ1		O
2	Quantity		O
3	Repeat Pattern		O
4	Explicit Time		O
5	Relative Time and Units		O
6	Service Duration		O
7	Start date/time		O			If used, the start date should be the earliest date/time after which the patient can be seen.
8	End date/time	DTM_3	R	[1..1]		The end date reflects the date/time by which the patient should have been seen at least once.
9	Priority		O
10	Condition text		O
11	Text instruction		O
12	Conjunction		X			Excluded for this Implementation Guide, see Conventions in Section 1
13	Occurrence duration		O
14	Total occurrences		O

TQ1_2 – Timing/Quantity Segment

This segment is used in the SIU^S12^SIU_S12 message to indicate the start of the appointment in TQ1-7. If the appointment is with a specific duration, and the end time is known, it SHOULD be conveyed in TQ1-8.

Table 4‑5. Timing/Quantity Segment for Schedule Information (TQ1)

SEQ	Element Name	DT	Usage	Cardinality	Value Set	Description/Comments
1	Set ID - TQ1		O
2	Quantity		O
3	Repeat Pattern		O
4	Explicit Time		O
5	Relative Time and Units		O
6	Service Duration		O
7	Start date/time	DTM_4	R	[1..1]
8	End date/time	DTM_4	RE	[0..1]
9	Priority		O
10	Condition text		O
11	Text instruction		O
12	Conjunction		X			Excluded for this Implementation Guide, see Conventions in Section 1
13	Occurrence duration		O
14	Total occurrences		O

OBR – Observation Request Segment

The OBR segment is required in the base standard for the OMG^O19_OMG_O19. It contains some of the same information as the ORC segment, but also provides a place to indicate the reason for referral in OBR-31.

Table 4‑6. Observation Request Segment (OBR)

SEQ	Element Name	DT	Usage	Cardinality	Value Set	Description/Comments
1	Set ID ‑ OBR		O
2	Placer Order Number	EI	R	[1..1]		Must be in sync with ORC.
3	Filler Order Number		O
4	Universal Service Identifier	CWE_2	R	[1..1]	LOINC	Shall be valued to "57133-1" for "Referral Note".
5	Priority – OBR		X			Excluded for this Implementation Guide, see Conventions in Section 1
6	Requested Date/Time		X			Excluded for this Implementation Guide, see Conventions in Section 1
7	Observation Date/Time		O
8	Observation End Date/Time		O
9	Collection Volume		O
10	Collector Identifier		O
11	Specimen Action Code		O
12	Danger Code		O
13	Relevant Clinical Information		X			Excluded for this Implementation Guide, see Conventions in Section 1. Such data should always use the OBX under the OBR or the Prior Results segment group.
14	Specimen Received Date/Time		X			Excluded for this Implementation Guide, see Conventions in Section 1
15	Specimen Source		X			Excluded for this Implementation Guide, see Conventions in Section 1
16	Ordering Provider	XCN_1	R	[1..1]		This is the referring provider. Providers should be identified using their NPI. Note that field ORC-12 is constrained to contain the same value as this field.
17	Order Call-back Phone Number		O
18	Placer Field 1		O
19	Placer Field 2		O
20	Filler Field 1		O
21	Filler Field 2		O
22	Results Rpt/Status Chng - Date/Time		O
23	Charge to Practice		O
24	Diagnostic Service Sect ID		O
25	Result Status		O
26	Parent Result		X
27	Quantity/Timing		X			Excluded for this Implementation Guide, see Conventions in Section 1.
28	Result Copies To		O
29	Parent		O
30	Transportation Mode		O
31	Reason for Study	CWE_3	R			This field is used to convey the primary reason for the study. This represents the Reason for Study in the C-CDA payload for LOINC 42349-1 If the primary reason is coded, SNOMED CT [Problem Value Set urn:oid:2.16.840.1.113883.3.88.12.3221.7.4 ] is the preferred value set to use, while the OBX segment in the Observation group can be used for additional reasons (coded reasons only). If the primary reason is free text then use OBR-31.2, while the Observation group cannot be used.
32	Principal Result Interpreter		O
33	Assistant Result Interpreter		O
34	Technician		O
35	Transcriptionist		O
36	Scheduled Date/Time		O
37	Number of Sample Containers		O
38	Transport Logistics of Collected Sample		O
39	Collector's Comment		O
40	Transport Arrangement Responsibility		O
41	Transport Arranged		O
42	Escort Required		O
43	Planned Patient Transport Comment		O
44	Procedure Code		O
45	Procedure Code Modifier		O
46	Placer Supplemental Service Information		O
47	Filler Supplemental Service Information		O
48	Medically Necessary Duplicate Procedure Reason		O
49	Result Handling		O
50	Parent Universal Service Identifier		X			Excluded for this Implementation Guide, see Conventions in Section 1

OBX – Observation/Result Segment

The OBX segment can be used to convey an extended “referral question” - when multiple points of inquiry are sought from the specialist. The use of the OBX segment will likely vary by specialty, and in most cases it may be omitted.

Note that in future versions of this specifications an instance of the OBX segment could be used to contain a pointer to, or even the complete C-CDA document with the relevant clinical information for the referral request.

Table 4‑7. Observation Result Segment (OBX)

SEQ	Element Name	DT	Usage	Cardinality	Value Set	Description/Comments
1	Set ID – OBX	SI	R	[1..1]
2	Value Type	ID	R	[1..1]	US_CLR_HL70125	Restricted to ST for the referral question(s). Value set comes from V2.8.2
3	Observation Identifier	CWE_2	R	[1..1]	LOINC	Restricted to LOINC xyz for the referral question. Need a value for xyz. Hans to check with Clem, Dan for a value, or create a new one.
4	Observation Sub-ID	ST	C(R/O)	[0..1]		Condition Predicate: If there are multiple OBX segments associated with the same OBR segment that have the same OBX-3 values for (OBX-3.1 and OBX-3.3) or (OBX-3.4 and OBX-3.6).
5	Observation Value	Varies	R	[1..1]
6	Units		X
7	References Range		O
8	Abnormal Flags		O
9	Probability		O
10	Nature of Abnormal Test		O
11	Observation Result Status	ID	R	[1..1]	US_CLR_HL70085	Set to "O". Value set from (V2.8.2)
12	Effective Date of Reference Range		O
13	User-Defined Access Checks		O
14	Date/Time of the Observation		X			Suggest to go to Optional.
15	Producer’s Reference		O
16	Responsible Observer		O
17	Observation Method		O
18	Equipment Instance Identifier		O
19	Date/Time of the Analysis		X			Suggest to go to Optional.
20	Observation Site		O			Pre-adopted from V2.8.2.
21	Observation Instance Identifier		O			Pre-adopted from V2.8.2.
22	Mood Code		C(O/X)			Pre-adopted from V2.8.2. Condition predicate: Can only be used with OSU.
23	Performing Organization Name		O
24	Performing Organization Address		O
25	Performing Organization Medical Director		O
26	Patient Results Release Category		O
27	Root Cause		O
28	Local Process Control		O
29	Observation Type		X			Suggest to go to Optional.
30	Observation Sub-Type		X			Suggest to go to Optional.

Conformance statements: OBX Segment

CLR-22: The value of OBX-1 (Set ID – OBX) SHALL be valued sequentially starting the value ‘1’ within a given segment group.

SCH – Schedule Activity Information Segment

The SCH segment contains the information about an appointment, including a unique appointment identifier in SCH-2, which can be used to refer to this specific appointment in future exchanges. It also links to the referral via the Placer Order Number (SCH-26).

Table 4‑8. Schedule Activity Information Segment (SCH)

SEQ	Element Name	DT	Usage	Cardinality	Value Set	Description/Comments
1	Placer Appointment ID	EI	X	[1..1]		According to the base standard, one of SCH-1 or SCH-2 is required, and there is no such thing as a Placer Appointment ID for this implementation guide.
2	Filler Appointment ID	EI	R	[1..1]		A unique identifier for the appointment, which allows subsequent updates regarding this particular appointment
3	Occurrence Number		O			Multiple occurrences are out of scope of this IG. Only 1 occurrence is considered in this version of the guide.
4	Placer Group Number		O
5	Schedule ID		O
6	Event Reason	CWE_3	R			Use the LOINC code "57133-1" for Referral Note and leave SCH-6.2 blank.
7	Appointment Reason		O
8	Appointment Type		O
9	Appointment Duration		X			Excluded in accordance with the base standard.
10	Appointment Duration Units		X			Excluded in accordance with the base standard.
11	Appointment Timing Quantity		X			Excluded in accordance with the base standard.
12	Placer Contact Person		O
13	Placer Contact Phone Number		O
14	Placer Contact Address		O
15	Placer Contact Location		O
16	Filler Contact Person	XCN_2	R	[1..1]		Required in the base standard. For the purposes of 360X, the name of the referral coordinator is a good match, however the name (and optionally other details) of any person who can serve as a contact at the recipientents organization regarding that appointment is appropriate.
17	Filler Contact Phone Number		O
18	Filler Contact Address		O
19	Filler Contact Location		O
20	Entered by Person	XCN_2	R	[1..1]		Required by the base standard. It should conatin the name (and optionally other details) of the person who created the appointment in the recipient's system. In the case where an appointment is created automatically in some fashion, it is acceptable to put the string "SYSTEM" as the last name in this field.
21	Entered by Phone Number		O
22	Entered by Location		O
23	Parent Placer Appointment ID		O
24	Parent Filler Appointment ID		X
25	Filler Status Code		O
26	Placer Order Number	EI	R	[1..1]		Must be valued the same as ORC-2 Order Placer Number in the OMG as this represents the Referral ID
27	Filler Order Number		X

RGS – Resource Group Segment

The RGS segment is required by the base standard. It provides a way to indicate changes (updates or deletions) of existing appointments via the value of RGS-2.

Table 4‑9. Resource Group Segment (RGS)

SEQ	Element Name	DT	Usage	Cardinality	Value Set	Description/Comments
1	Set ID - RGS	SI	R	[1..1]
2	Segment Action Code	ID	R	[1..1]	US_CLR_HL70206	If S12 = A (new appointment) or U (reschedule or other updates to the schedule data) If S26 = D
3	Resource Group ID		X

Conformance Statements: RGS segment

CLR-23: RGS-1 (Set ID - RGS) SHALL be valued with the constant value ‘1’.

AIP – Personnel Resource Segment

The AIP segment provides the ability to send the information about the provider(s) with whom the appointment is scheduled.

Table 4‑12. Appointment Information - Personnel Resource Segment (AIP)

SEQ	Element Name	DT	Usage	Cardinality	Value Set	Description/Comments
1	Set ID - AIP	SI	R	[1..1]
2	Segment Action Code	ID	O	[0..1]	US_CLR_HL70206	If S12 = A (new appointment) or U (reschedule or other updates to the schedule data) Must match RGS-2
3	Personnel Resource ID	XCN_2	R	[1..1]		The person with whom this appointment is scheduled
4	Resource Type	CWE	O	[0..1]
5	Resource Group	CWE	O	[0..1]
6	Start Date/Time	DTM	O	[0..1]
7	Start Date/Time Offset	NM	O	[0..1]
8	Start Date/Time Offset Units	CNE	O	[0..1]
9	Duration	NM	O	[0..1]
10	Duration Units	CNE	O	[0..1]
11	Allow Substitution Code	CWE	O	[0..1]
12	Filler Status Code	CWE	O	[0..1]

Conformance statements: AIP Segment

CLR-24: The value of AIP-1 (Set ID – AIP) SHALL be valued sequentially starting the value ‘1’ within a given resource group.

5. Data Types

Data types are further defined in this implementation guide for all fields that have a usage of ‘R’, ‘RE’, or ‘C(a/b)’. Data types used only for optional fields, or where this IG does not further constrain the base, are not included. Please refer to the base standard for those data types.

Depending on the profile components used, the usage of data type components for some data types varies. To clearly indicate when to use specific data type components, each data type that has a varying definition based on profile components will be documented with multiple variations, e.g., CWE_1 and CWE_2. Composite data types indicate which variety of the component's data type is applicable, while the data type of a field is marked as "varies" where the comment indicates the data type choices based on the declared profile or component.

5.1. Base Data Types

The base data types are those with a single component. Bothe segment fields and composite data types reference the base data types. The ones in the table below are referenced by required segment fields or composite data type components.

Table 5-1. Base Data Types

Abbr.	Name	Description
ID	Coded value for HL7 defined tables	The value of the ID data type follows the formatting rules for an ST field except that it is drawn from a table of legal values. There shall be an HL7 table number associated with ID data types.
IS	Coded value for user-defined tables	The value of the IS data type follows the formatting rules for a ST field except that it is drawn from a site-defined (or user-defined) table of legal values. There shall be an HL7 table number associated with IS data types. The only approved use of this data type is for the components of HD (HD.1), EI (EI.2) and PL (PL.6)
SI	Sequence ID	A non-negative integer between 0 and 9999
ST	String Data	The ST data type is used for text data when the appearance of text does not bear meaning. String data is left justified (i.e., no leading blank space) with trailing blanks optional. It is intended for short strings (less than 1000 characters). In this implementation guide, the only allowed escape sequences are those allowed in HL7 Version 2.5.1, Chapter 2, Section 2.7.4 - Special Characters.
TX	Text Data	String data meant for user display. Such data would not necessarily be left justified since leading spaces may contribute greatly to the clarity of the presentation to the user, therefore leading spaces should be included. Trailing spaces should be removed. Since TX data is intended for display purposes, the repeat delimiter, when used with a TX data field, implies a series of repeating lines to be displayed. Therefore, the repeat delimiters are regarded as paragraph terminators or hard new lines. A receiving system would word-wrap the text between repeat delimiters in order to fit it into an arbitrarily sized display window but start any line beginning with a repeat delimiter on a new line. In this implementation guide, the only allowed escape sequences are those allowed in HL7 Version 2.5.1, Chapter 2, Section 2.7.4 - Special Characters. These are the escape sequences for the message delimiters (i.e., \|^&~\ or \|^&~\#).

5.2. Composite Data Types

Composite data types contain components, which are either base data types, or composite data types whose components in turn are only base data types.

This implementation guide uses data type “flavors” to manage the requirements of specific segment field or data type component use. The data type flavors are constraints on the composite data type as defined in the base standard.

CWE_1 – Coded with Exceptions

Note: Components 10-22 are pre-adopted from V2.7.1 CWE.

Table 5-2. Coded with Exceptions – Flavor 1

SEQ	Component Name	DT	Usage	Value Set	Comments
1	Identifier	ST	R
2	Text	ST	RE		It is strongly recommended that text be sent to accompany any identifier.
3	Name of Coding System	ID	R	US_CLR_HL70396
4	Alternate Identifier		X
5	Alternate Text		X
6	Name of Alternate Coding System	ID	X
7	Coding System Version ID	ST	C(RE/O)		Condition Predicate: If CWE_1.3 (Name of Coding System) is not an HL7 defined table.
8	Alternate Coding System Version ID		O
9	Original Text	ST	O
10	Second Alternate Identifier		X
11	Second Alternate Text		X
12	Second Name of Alternate Coding System		X
13	Second Alternate Coding System Version ID		X
14	Coding System OID		O
15	Value Set OID		O
16	Value Set Version ID		O
17	Alternate Coding System OID		X
18	Alternate Value Set OID		X
19	Alternate Value Set Version ID		X
20	Second Alternate Coding System OID		X
21	Second Alternate Value Set OID		X
22	Second Alternate Value Set Version ID		X

Usage Note
The CWE_1 data type flavor is used where it is necessary to communicate a code, coding system, and the version of the coding system if the code was drawn from and alternate codes drawn from another coding system. Alternate identifiers are expressly prohibited to foster consistency in vocabulary when communicating referral requests. All other CWE components could be considered for individual implementations but do not require support.

CWE_2 – Coded with Exceptions

Note: Components 10-22 are pre-adopted from V2.7.1 CWE.

Table 5-3. Coded with Exceptions – Flavor 2

SEQ	Component Name	DT	Usage	Value Set	Comments
1	Identifier	ST	R
2	Text	ST	RE		It is strongly recommended that text be sent to accompany any identifier.
3	Name of Coding System	ID	R	US_CLR_HL70396
4	Alternate Identifier		X
5	Alternate Text		X
6	Name of Alternate Coding System	ID	X
7	Coding System Version ID	ST	C(RE/O)		Condition Predicate: If CWE_2.3 (Name of Coding System) is not an HL7 defined table. For OBR-4 this is RE.
8	Alternate Coding System Version ID		O
9	Original Text	ST	O
10	Second Alternate Identifier		X
11	Second Alternate Text		X
12	Second Name of Alternate Coding System		X
13	Second Alternate Coding System Version ID		X
14	Coding System OID	ST	R		Coding system for LOINC in OBR-4.
15	Value Set OID		O
16	Value Set Version ID		O
17	Alternate Coding System OID		X
18	Alternate Value Set OID		X
19	Alternate Value Set Version ID		X
20	Second Alternate Coding System OID		X
21	Second Alternate Value Set OID		X
22	Second Alternate Value Set Version ID		X

Usage Note
The CWE_2 data type flavor is used where it is necessary to communicate a code, coding system, and the version of the coding system if the code was drawn from and alternate codes drawn from another coding system, as well as the coding system OID. Alternate identifiers are expressly prohibited to foster consistency in vocabulary when communicating referral requests. All other CWE components could be considered for individual implementations but do not require support.

CWE_3 – Coded with Exceptions

Note: Components 10-22 are pre-adopted from V2.7.1 CWE.

Table 5-4. Coded with Exceptions – Flavor 3

SEQ	Component Name	DT	Usage	Value Set	Comments
1	Identifier	ST	RE
2	Text	ST	C(R/O)		Condition Predicate: If CWE_3.1 is not valued.
3	Name of Coding System	ID	RE	US_LAB_HL70396
4	Alternate Identifier		X
5	Alternate Text		X
6	Name of Alternate Coding System	ID	X
7	Coding System Version ID	ST	C(RE/O)		Condition Predicate: If CWE_3.3 (Name of Coding System) is not an HL7 defined table.
8	Alternate Coding System Version ID		O
9	Original Text	ST	O
10	Second Alternate Identifier		X
11	Second Alternate Text		X
12	Second Name of Alternate Coding System		X
13	Second Alternate Coding System Version ID		X
14	Coding System OID	ST	C(R/X)		Condition Predicate: If CWE_3.1 is valued.
15	Value Set OID		O
16	Value Set Version ID		O
17	Alternate Coding System OID		X
18	Alternate Value Set OID		X
19	Alternate Value Set Version ID		X
20	Second Alternate Coding System OID		X
21	Second Alternate Value Set OID		X
22	Second Alternate Value Set Version ID		X

Usage Note
The CWE_3 data type flavor is used where it is necessary to communicate either the code, coding system, and the version of the coding system if the code was drawn from and alternate codes drawn from another coding system, as well as the coding system OID, or a free text value. Alternate identifiers are expressly prohibited to foster consistency in vocabulary when communicating referral requests. All other CWE components could be considered for individual implementations but do not require support.

CX – Extended Composite ID with Check Digit

Table 5-5. Extended Composite ID with Check Digit (CX)

SEQ	Component Name	DT	Usage	Value Set	Comments
1	ID Number	ST	R
2	Check Digit		X
3	Check Digit Scheme		X
4	Assigning Authority	HD_2	R		The Assigning Authority component is used to identify the system, application, organization, etc. that assigned the ID Number in component 1.
5	Identifier Type Code	ID	R	US_CLR_HL70203
6	Assigning Facility		O
7	Effective Date		O
8	Expiration Date		O
9	Assigning Jurisdiction		O
10	Assigning Agency or Department		O

Usage Note
The CX data type is used to carry identifiers. The assigning authorities is required to accompany all identifiers and all identifiers carry an identifier type. This method allows the exchange of universally unique identifiers for the associated object across organizational and enterprise boundaries, enabling broad interoperability.
Although the Identifier Type Code component is required, it is not a part of the actual identifier. Rather, it is metadata about the identifier. The ID Number and Assigning Authority component, together, constitute the actual identifier.

DTM_1 - Date/Time

Table 5-6. Date/Time (DTM) – Flavor 1

SEQ	Component Name	DT	Usage	Value Set	Comments
	YYYY	ST	R
	MM	ST	R
	DD	ST	R
	HH	ST	R
	MM	ST	R
	SS	ST	R
	[.S[S[S[S]]]]	ST	O
	+/- ZZZZ	ST	R		Set to "0000" always.

Usage Note

This flavor of the DTM datatype is used for timestamps, when the time resolution is at least down to the second level. Timestamps are always expressed in UTC

DTM_2 - Date/Time

Table 5-7. Date/Time (DTM) – Flavor 2

SEQ	Component Name	DT	Usage	Value Set	Comments
	YYYY	ST	R
	MM	ST	RE
	DD	ST	RE
	HH	ST	O
	MM	ST	O
	SS	ST	O
	[.S[S[S[S]]]]	ST	O
	+/- ZZZZ	ST	O		Set to "0000" when hours or minutes are present.

Usage Note

This flavor of the DTM datatype is used for birth dates, when at least the year is known, and the month and day are usually known. In cases like neo-natal care, the birth time can also be expressed.

DTM_3 - Date/Time

Table 5-8. Date/Time (DTM) – Flavor 3

SEQ	Component Name	DT	Usage	Value Set	Comments
	YYYY	ST	R
	MM	ST	R
	DD	ST	R
	HH	ST	O
	MM	ST	O
	SS	ST	O
	[.S[S[S[S]]]]	ST	O
	+/- ZZZZ	ST	O		Set to "0000" when hour or minutes are present.

Usage Note

This flavor of the DTM datatype is used for expressing dates, when year, month and day are always known.

DTM_4 - Date/Time

Table 5-9. Date/Time (DTM) – Flavor 4

SEQ	Component Name	DT	Usage	Value Set	Comments
	YYYY	ST	R
	MM	ST	R
	DD	ST	R
	HH	ST	RE
	MM	ST	RE
	SS	ST	O
	[.S[S[S[S]]]]	ST	O
	+/- ZZZZ	ST	O		Set to "0000" when hour or minutes are present.

Usage Note

This flavor of the DTM datatype is used for expressing appointments times, when usually the year, month, day, hour and minute are known.

EI - Entity Identifier

Table 5-10. Entity Identifier (EI)

SEQ	Component Name	DT	Usage	Value Set	Comments
1	Entity Identifier	ST	R		For MSH-21: "360X"; For ORC-2: referral ID
2	Namespace ID	IS	X
3	Universal ID	ST	R		For MSH-21: "12.3whatever" For ORC-2: issuing organization's or system's OID
4	Universal ID Type	ID	R		Fixed to “ISO”.

FN - Family Name

Table 5-11. Family name (FN)

SEQ	Component Name	DT	Usage	Value Set	Comments
1	Surname	ST	R
2	Own Surname Prefix		O
3	Own Surname		O
4	Surname Prefix From Partner/Spouse		O
5	Surname From Partner/Spouse		O

HD_1 - Hierarchic Designator

Table 5-12. Hierarchic Designator (HD) – Flavor 1

SEQ	Component Name	DT	Usage	Value Set	Comments
1	Namespace ID	IS	RE		The value of HD.1 reflects a local code that represents the combination of HD.2 and HD.3. For MSH-4: readable string For MSH-6: readable string
2	Universal ID	ST	R		For MSH-4: OID For MSH-6: OID
3	Universal ID Type	ID	R		Fixed to “ISO”.

HD_2 - Hierarchic Designator

Table 5-13. Hierarchic Designator (HD) – Flavor 2

SEQ	Component Name	DT	Usage	Value Set	Comments
1	Namespace ID	IS	X
2	Universal ID	ST	R		XCN.9: OID for the assigning authority.
3	Universal ID Type	ID	R		Fixed to “ISO”.

MSG - Message Type

Table 5-14. Message Type (MSG)

SEQ	Component Name	DT	Usage	Value Set	Comments
1	Message Code	ID	R	US_CLR_HL70076
2	Trigger Event	ID	R	US_CLR_HL70003
3	Message Structure	ID	R	US_CLR_HL70354

PT - Processing Type

Table 5-15. Processing Type (PT)

SEQ	Component Name	DT	Usage	Value Set	Comments
1	Processing ID	ID	R	US_CLR_HL70103
2	Processing Mode		X

VID - Version Identifier

Table 5-16. Version Identifier (VID)

SEQ	Component Name	DT	Usage	Value Set	Comments
1	Version ID	ID	R	US_CLR_HL70104
2	Internationalization Code		X
3	International Version ID		X

XCN_1 - Extended Composite ID Number and Name for Persons

Table 5-17. Extended Composite ID Number and Name for Persons (XCN) – Flavor 1

SEQ	Component Name	DT	Usage	Value Set	Comments
1	ID Number	ST	RE		The ID Number component combined with the Assigning Authority (XCN.9) must uniquely identify the associated person. Note:Despite the component being named “ID Number” this component is an ST string data type, not numeric, so the component is not limited to just numbers.
2	Family Name	FN	RE
3	Given Name	ST	RE		I.e., first name.
4	Second and Further Given Names or Initials Thereof	ST	RE
5	Suffix (e.g., JR or III)	ST	RE
6	Prefix (e.g., DR)	ST	RE
7	Degree (e.g., MD)	IS	X		Excluded for this Implementation Guide, see Section 1.1.1.
8	Source Table		O
9	Assigning Authority	HD_2	C(R/X)		Condition Predicate: If XCN.1 (ID Number) is valued, XCN.9 is required The Assigning Authority component is used to identify the system, application, organization, etc. that assigned the ID Number in component 1.
10	Name Type Code	ID	RE	US_CLR_HL70200
11	Identifier Check Digit		O
12	Check Digit Scheme		X
13	Identifier Type Code	ID	C(R/X)	US_CLR_HL70203	Condition Predicate: If XCN.1 (ID Number) is valued.
14	Assigning Facility		O
15	Name Representation Code		O
16	Name Context		O
17	Name Validity Range		X		Excluded for this Implementation Guide, see Section 1.1.1.
18	Name Assembly Order		O
19	Effective Date		O
20	Expiration Date		O
21	Professional Suffix		O
22	Assigning Jurisdiction		O
23	Assigning Agency or Department		O

XCN_2 - Extended Composite ID Number and Name for Persons

Table 5-18. Extended Composite ID Number and Name for Persons (XCN) – Flavor 2

SEQ	Component Name	DT	Usage	Value Set	Comments
1	ID Number		O
2	Family Name	FN	C(R/O)		Condition Predicate: If XCN.3 is not valued.
3	Given Name	ST	C(R/O)		Condition Predicate: If XCN.2 is not valued.
4	Second and Further Given Names or Initials Thereof		O
5	Suffix (e.g., JR or III)		O
6	Prefix (e.g., DR)		O
7	Degree (e.g., MD)		X		Excluded for this Implementation Guide, see Section 1.1.1.
8	Source Table		O
9	Assigning Authority		O
10	Name Type Code		O
11	Identifier Check Digit		O
12	Check Digit Scheme		X
13	Identifier Type Code	ID	C(R/X)	US_CLR_HL70203	Condition Predicate: If XCN.1 (ID Number) is valued.
14	Assigning Facility		O
15	Name Representation Code		O
16	Name Context		O
17	Name Validity Range		X		Excluded for this Implementation Guide, see Section 1.1.1.
18	Name Assembly Order		O
19	Effective Date		O
20	Expiration Date		O
21	Professional Suffix		O
22	Assigning Jurisdiction		O
23	Assigning Agency or Department		O

EI - Extended Person Name

Table 5-19. Extended Person Name (XPN)

SEQ	Component Name	DT	Usage	Value Set	Comments
1	Family Name	FN	RE
2	Given Name	ST	RE		I.e., first name.
3	Second and Further Given Names or Initials Thereof	ST	RE
4	Suffix (e.g., JR or III)	ST	RE
5	Prefix (e.g., DR)		O
6	Degree (e.g., MD)		X		Excluded for this Implementation Guide, see Section 1.1.1.
7	Name Type Code	ID	R	US_CLR_HL70200
8	Name Representation Code		O
9	Name Context		O
10	Name Validity Range		X		Excluded for this Implementation Guide, see Section 1.1.1.
11	Name Assembly Order		O
12	Effective Date		O
13	Expiration Date		O
14	Professional Suffix		O

[1] http://www.ietf.org/rfc/rfc2119.txt

[2] There are multiple interpretations of “RE” when a value is known. One is “the capability must always be supported and a value is sent if known”, the other is “the capability must always be supported and a value may or may not be sent even when known based on a condition external to the profile specification. The condition may be noted in the profile but cannot be processed automatically”. This is what can be interpreted from the “relevant” part of the definition. Regardless of the interpretation the “RE” usage code, a set of test circumstances can be developed to sufficiently test the “RE” element. See the “Conformity Assessment of Conformance Constructs” section for more details.

[3] The current version of the HL7 Implementation Guidance for Unique Object Identifiers (OIDs), Release 1 is available from HL7 (www.hl7.org). Members may obtain a copy without charge in the Members-only area of the site, others may purchase a copy for a nominal fee via the HL7 Store