2. Control (continued)


Contents



2 .A Control (continued)

2.A DATA TYPES

The data types in this section are listed in alphabetical order.

The data type examples in this Standard are given using the standard HL7 encoding rules, with the delimiter values from Figure 2-1 of Chapter 2, "Control", section 2.5.4, "Message delimiters". Although only one set of encoding rules is defined as a standard in HL7 Version 2.4, other encoding rules are possible (but since they are non-standard, they may only be used by a site-specific agreement).

In this chapter, square brackets, "[" and "]", are used to specify optional parts of a string. For instance, the format of a date field is "YYYY[MM[DD]]" which denotes that the field may contain four, six, or eight characters respectively. The characters may further constrain the possible contents of the string - this will be documented at the point of use.

2.A.1 AD - address

2.A.1.1 Street Address (ST)

Definition: This component specifies the street or mailing address of a person or institution. When referencing an institution, this first component is used to specify the institution name. When used in connection with a person, this component specifies the first line of the address.

2.A.1.2 Other Designation (ST)

Definition: This component specifies the second line of address. In general, it qualifies address. Examples: Suite 555 or Fourth Floor. When referencing an institution, this component specifies the street address.

2.A.1.3 City (ST)

Definition: This component specifies the city, district or place where the addressee is located depending upon the national convention for formatting addresses for postal usage.

2.A.1.4 State or Province (ST)

Definition: This component specifies the state or province where the addressee is located. State or province should be represented by the official postal service codes for that country.

2.A.1.5 Zip or Postal Code (ST)

Definition: This component specifies the zip or postal code where the addressee is located. Zip or postal codes should be represented by the official codes for that country. In the US, the zip code takes the form 99999[-9999], while the Canadian postal code takes the form A9A9A9 and the Australian Postcode takes the form 9999.

2.A.1.6 Country (ID)

Definition: This component specifies the country where the addressee is located. HL7 specifies that the 3-character (alphabetic) form of ISO 3166 be used for the country code. Refer to HL7 Table 0399 - Country Code for valid values.

2.A.1.7 Address Type (ID)

Definition: This component specifies the kind or type of address. Refer to HL7 Table 0190 - Address Type for valid values.

2.A.1.8 Other Geographic Designation (ST)

Definition: This component specifies any other geographic designation that may be necessary. It includes county, bioregion, SMSA, etc.

2.A.2 AUI - authorization information

HL7 Component Table - AUI - Authorization Information

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
30= ST O
Authorization Number
2.A.75 DB
2

DT O
Date
2.A.21 DB
3
199# ST O
Source
2.A.75 DB

Definition: This data type specifies the identifier or code for an insurance authorization instance and its associated detail.

Note: Replaces the CM data type used in sections 6.5.6.14 IN1-14, as of v2.5.

2.A.2.1 Authorization Number (ST)

Definition: Identifier assigned to the authorization.

2.A.2.2 Date (DT)

Definition: Date of authorization.

2.A.2.3 Source (ST)

Definition: Source of authorization.

2.A.3 CCD - charge code and date

HL7 Component Table - CCD - Charge Code and Date

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1 1..1
ID R 0100 Invocation Event
2.A.35 DB
2

DTM O
Date/time
2.A.22 DB

Definition: Specifies whether a charge action is based on an invocation event or is time-based.

Note: Replaces the CM data type used in section 4.5.2.1 BLG-1, as of v2.5.

2.A.3.1 Invocation Event (ID)

Definition: Specifies the code for the event precipitating/triggering the charge activity. Refer to HL7 Table 0100 - Invocation event for valid values.

2.A.3.2 Date/time (DTM)

Definition: The second component is used to express the exact time to charge for the ordered service; it is used only when the CCD.1 value is T. When used, it is expressed as a DTM data type.

2.A.4 CCP - channel calibration parameters

Attention: Retained for backward compatibility only in version 2.7. This is used only in the CD Channel Definition data type, which has been retained for backward compatibility only in v2.7.

HL7 Component Table - CCP - Channel Calibration Parameters

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
6# NM O
Channel Calibration Sensitivity Correction Factor
2.A.47 DB
2
6# NM O
Channel Calibration Baseline
2.A.47 DB
3
6# NM O
Channel Calibration Time Skew
2.A.47 DB

Definition: This data type identifies the corrections to channel sensitivity, the baseline, and the channel time skew when transmitting waveform results.

Note: Replaces the CM data type used in 7.14.1.5 OBX-5.3 where OBX-5 Observation value (*) is data type CD as of v 2.5.

2.A.4.1 Channel Calibration Sensitivity Correction Factor (NM)

Definition: This component defines a correction factor for channel sensitivity, which may be derived from the last calibration procedure performed. The actual channel sensitivity is the nominal channel sensitivity given in the previous component multiplied by the unitless correction factor.

2.A.4.2 Channel Calibration Baseline (NM)

Definition: This component defines the actual channel baseline (the data value which corresponds to a nominal input signal of zero). The actual baseline may differ from the ideal because of a dc offset in the amplifier connected to the ADC. The actual baseline values for all channels (which need not be integers) may be determined at the time of calibration as the average digitized values obtained when a zero input signal is connected to each channel.

2.A.4.3 Channel Calibration Time Skew (NM)

Definition: This component defines the time difference between the nominal sampling (digitization) time (which would be the same for all channels) and the actual sampling time of the channel, in seconds (or fractions thereof). This value will differ from zero when all channels in the montage are not sampled simultaneously, as occurs in systems, which sample successive channels at regular time intervals. This value may be determined from a calibration procedure in which an identical time-varying signal is applied to all channels and interchannel time differences are estimated, or more commonly it may be taken from the manufacturer's specifications for the digitizing system used. For example, for a system which samples successive channels at regular time intervals t, the time skew of channel number n would be (n-1)t. The actual time of sampling (digitization) of sample number m of channel number n in such a system would be R + (m-1)/f + (n-1)t, where R is the reference time at the start of the epoch and f is the channel sampling frequency (t < 1/f).

2.A.5 CD - channel definition

Attention: Retained for backward compatibility only in version 2.7. This is used only in the waveform message, CHM category, which has been retained for backward compatibility only in version 2.7.

HL7 Component Table - CD - Channel Definition

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

WVI O
Channel Identifier
2.A.84 DB
2

WVS O
Waveform Source
2.A.85 DB
3

CSU O
Channel Sensitivity and Units
2.A.12 DB
4

CCP O
Channel Calibration Parameters
2.A.4 DB
5
6# NM O
Channel Sampling Frequency
2.A.47 DB
6

NR O
Minimum and Maximum Data Values
2.A.48 DB

Definition: This data type is used for labeling of digital waveform data. It defines a recording channel, which is associated with one of the values in each time sample of waveform data. Each channel has a number (which generally defines its position in a multichannel display) and an optional name or label (also used in displays). One or two named waveform sources may also be associated with a channel (providing for the use of differential amplifiers with two inputs). The other components of the channel definition data type are optional. The individual components are defined as follows:

2.A.5.1 Channel Identifier (WVI)

Definition: This component specifies the number and name of the recording channel where waveform data is transmitted.

2.A.5.2 Waveform Source (WVS)

Definition: This component identifies the source of the waveform connected to the channel. Two names may be specified if it is necessary to individually identify the two inputs for a waveform. Only one name need be specified if the channel is connected to a single input. For example, in EKG recordings typically only one name is used (such as I or II); in electroencephalography, two names are typically used, one for each input of the differential amplifier (such as F3 and C3).

2.A.5.3 Channel Sensitivity and Units (CSU)

Definition: This component defines the channel sensitivity (gain) and the units in which it is measured.

2.A.5.4 Channel Calibration Parameters (CCP)

Definition: This component identifies the corrections to channel sensitivity, the baseline, and the channel time skew.

2.A.5.5 Channel Sampling Frequency (NM)

Definition: This component defines the sampling frequency in hertz of the channel, that is, the reciprocal of the time in seconds between successive samples. Note that this is the frequency of transmitted data, which may or may not be the actual frequency at which the data was acquired by an analog-to-digital converter or other digital data source (i.e. the data transmitted may be subsampled, or interpolated, from the originally acquired data.)

2.A.5.6 Minimum and Maximum Data Values (NR)

Definition: This component defines the minimum and maximum data values which can occur in this channel in the digital waveform data, that is, the range of the ADC, and also specifies whether or not non-integral data values may occur in this channel in the waveform data. If the minimum and maximum values are both integers (or not present), only integral data values may be used in this channel. If either the minimum or the maximum value contains a decimal point, then non-integral as well as integral data values may be used in this channel. For an n-bit signed ADC, the nominal baseline B = 0, and the minimum (L) and maximum (H) values may be calculated as follows:

L = -2n-1

H = 2n-1 - 1

For an unsigned n-bit ADC, the minimum value L = 0, and the nominal baseline value (B) and maximum value (H) may be calculated from the formulas,

B = 2n-1

H = 2n - 1

The actual signal amplitude A (for differentially amplified potential measurements, the potential at electrode number one minus that at electrode number two) may be calculated from the value D (range L to H) in the waveform data using the actual baseline value B and the nominal sensitivity S and actual sensitivity correction factor C by the formula,

A = SC(D-B)

2.A.6 WITHDRAWN (CE - coded entry)

Attention: The CE data type has been replaced by the CWE and CNE data types and the detail was withdrawn and removed from the standard as of v 2.6.

2.A.7 CF - coded element with formatted values

As of v2.7 a third tuple, formerly known as triplet, has been added to the CF data type. Additionally, 3 new components were added to each tuple such that each tuple now has a total of 7 components. The Original Text component applies to the CF as a whole.

HL7 Component Table - CF - Coded Element with Formatted Values

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
20= ST O
Identifier
2.A.75 DB
2

FT O
Formatted Text
2.A.31 DB
3 1..12
ID C 0396 Name of Coding System
2.A.35 DB
4
20= ST O
Alternate Identifier
2.A.75 DB
5

FT O
Alternate Formatted Text
2.A.31 DB
6 1..12
ID C 0396 Name of Alternate Coding System
2.A.35 DB
7
10= ST C
Coding System Version ID
2.A.75 DB
8
10= ST O
Alternate Coding System Version ID
2.A.75 DB
9
199# ST O
Original Text
2.A.75 DB
10
20= ST O
Second Alternate Identifier
2.A.75 DB
11

FT O
Second Alternate Formatted Text
2.A.75 DB
12 1..12
ID O 0396 Name of Second Alternate Coding System
2.A.35 DB
13
10= ST C
Second Alternate Coding System Version ID
2.A.75 DB
14
199= ST C
Coding System OID
2.A.75 DB
15
199= ST O
Value Set OID
2.A.75 DB
16
8= DTM C
Value Set Version ID
2.A.75 DB
17
199= ST C
Alternate Coding System OID
2.A.75 DB
18
199= ST O
Alternate Value Set OID
2.A.75 DB
19
8= DTM C
Alternate Value Set Version ID
2.A.75 DB
20
199= ST C
Second Alternate Coding System OID
2.A.75 DB
21
199= ST O
Second Alternate Value Set OID
2.A.75 DB
22
8= DTM C
Second Alternate Value Set Version ID
2.A.75 DB

Note: The Vocabulary TC is the steward of the CF data type.

Definition: This data type transmits codes and the formatted text associated with the code. This data type can be used to transmit for the first time the formatted text for the canned text portion of a report, for example, a standard radiological description for a normal chest X-ray. The receiving system can store this information and in subsequent messages only the identifier need be sent. Another potential use of this data type is transmitting master file records that contain formatted text. This data type has six components as follows:

The components, primary and alternate, are defined exactly as in the CE data type with the exception of the second and fifth components, which are of the formatted text data type.

Example:

OBX||CF|71020^CXR^99CPMC||79989^\H\Description:\N\\.sp\\ti+4\Heart is not enlarged. There is no evidence of pneumonia, effusion, pneumothorax or any masses. \.sp+3\\H\Impression:\N\\.sp\\.ti+4\Negative chest.^99CPMC

2.A.7.1 Identifier (ST)

Definition: Sequence of characters (the code) that uniquely identifies the item being referenced by the <text>. Different coding schemes will have different elements here.

2.A.7.2 Formatted Text (FT)

Definition: Name or description of the item in question with the addition of embedded formatting instructions.

2.A.7.3 Name of Coding System (ID)

Definition: Contains the name of the coding system employed.

Refer to HL7 Table 0396 - Coding System in Chapter 2, "Control", section 2.16.4, "Coding System Table" for valid values.

As of v2.7 this component is required when CF.1 is populated and CF.14 is not populated. Both CF.3 and CF.14 may be populated. Receivers should not identify a code based on its position within the tuples (Identifier, Alternate Identifier, or Second Alternate Identifier) or position within a repeating field. Instead, the receiver should always examine the coding system as specified in CF.3 and/or CF.14, the Coding System component or the Coding System OID, for the tuple.

2.A.7.4 Alternate Identifier (ST)

Definition: A sequence of characters that uniquely identifies an alternate code. Analogous to CF-1 Identifier.

Usage Notes: The Alternate Identifier is used to represent the local or user seen code as described. If present, it obeys the same rules of use and interpretation as described for component 1. If both are present, the identifiers in component 4 and component 1 should have exactly the same meaning, i.e., they should be exact synonyms.

2.A.7.5 Alternate Formatted Text (FT)

Definition: Name or description of the alternate identifier in question with the addition of embedded formatting instructions. Analogous to CF.2 Formatted Text.

2.A.7.6 Name of Alternate Coding System (ID)

Definition: Contains the name of the coding system employed for the alternate identifier. Analogous to CF.3 Name of Coding System.

Refer to HL7 Table 0396 - Coding System in Chapter 2C, "Code Tables", for valid values.

As of v2.7 this component is required when CF.4 is populated and CF.17 is not populated. Both CF.6 and CF.17 may be populated. Receivers should not identify a code based on its position within the tuples (Identifier, Alternate Identifier, or Second Alternate Identifier) or position within a repeating field. Instead, the receiver should always examine the coding ystem as specified in CF.6 and/or CF.17, the Coding System component or the Coding System OID, for the tuple.

2.A.7.7 Coding System Version ID (ST)

Definition: This component carries the version for the coding system identified by components 1-3. If CF.3 is populated with a value other than HL7nnnn or is of table type user-defined, version ID must be valued with an actual version ID. If CF.3 is populated with a value of HL7nnnn and nnnn is of table type HL7, version ID may have an actual value or it may be absent. If version ID is absent, it will be interpreted to have the same value as the HL7 version number in the message header.

2.A.7.8 Alternate Coding System Version ID (ST)

Definition: This component carries the version for the coding system identified by components 4-6. Analogous To CF.7 Coding System Version ID.

2.A.7.9 Original Text (ST)

Definition: The text as seen and/or selected by the user who entered the data. Original text can be used in a structured user interface to capture what the user saw as a representation of the code on the data input screen, or in a situation where the user dictates or directly enters text, it is the text entered or uttered by the user. In a situation where the code is assigned sometime after the text was entered, original text is the text or phrase used as the basis for assigning the code.

2.A.7.10 Second Alternate Identifier (ST)

Definition: A sequence of characters that uniquely identifies an alternate code. Analogous to CF.1 Identifier.

2.A.7.11 Second Alternate FormattedText (FT)

Definition: The descriptive or textual name of the Second Alternate Identifier. Analogous to CF.2 Formatted Text.

2.A.7.12 Name of Second Alternate Coding System (ID)

Definition: Identifies the coding scheme being used in the Second Alternate Identifier component. Analogous to CF. Name of Coding System.

This component is required when CF.10 is populated and CF.20 is not populated. Both CF.10 and CF.20 may be populated. Receivers should not identify a code based on its position within the tuples (Identifier, Alternate Identifier, or Second Alternate Identifier) or position within a repeating field. Instead, the receiver should always examine the coding ystem as specified in CF.12 and/or CF.20 the Coding System component or the Coding System OID for the tuple.

2.A.7.13 Second Alternate Coding System Version ID (ST)

Definition: This component carries the version for the coding system identified by components 10-12. Analogous To CF.7 Coding System Version ID.

2.A.7.14 Coding System OID (ST)

Definition: This component contains the ISO Object Identifier (OID) for the coding system or value set named in CNE.3. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined code systems the OID registered in the HL7 OID registry SHALL be used.

This component is required when CF.1 is populated and CF.3 is not populated. Both CF.3 and CF.14 may be populated.

2.A.7.15 Value Set OID (ST)

Definition: This component contains the ISO Object Identifier (OID) to allow identification of the value set from which the value in CWE.1 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined value sets, the OID registered in the HL7 OID registry SHALL be used.

A value set may or need not be present irrespective of other fields. Note that if a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Applications SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set/ value set version ID.

2.A.7.16 Value Set Version ID (DTM)

Definition: This component carries the version for the value set identified by CF.15. The version is a date. The date is the date/time that the value set being used was published.

Value set version ID is required if CF.15 is populated.

2.A.7.17 Alternate Coding System OID (ST)

Definition: This component contains the ISO Object Identifier (OID) for the coding system or value set named in CF.6. Analogous To CF.14 Coding System OID.

The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined code systems the OID registered in the HL7 OID registry SHALL be used.

This component is required when CF.4 is populated and CF.6 is not populated. Both CF.6 and CF.17 may be populated.

2.A.7.18 Alternate Value Set OID (ST)

Definition: This component contains the ISO Object Identifier (OID) to allow identification of the value set from which the value in CF.4 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined value sets, the OID registered in the HL7 OID registry SHALL be used.

A value set may or need not be present irrespective of other fields. Note that if a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Applications SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set/ value set version ID.

2.A.7.19 Alternate Value Set Version ID (DTM)

Definition: This component carries the version for the value set identified by CF.18. The version is a date. The date is the date/time that the value set being used was published.

Value set version ID is required if CF.18 is populated.

2.A.7.20 Second Alternate Coding System OID (ST)

Definition: This component contains the ISO Object Identifier (OID) for the coding system or value set named in CF.12. Analogous To CF.14 Coding System OID.

The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined code systems the OID registered in the HL7 OID registry SHALL be used.

This component is required when CF.10 is populated and CF.12 is not populated. Both CF.12 and CF.20 may be populated.

2.A.7.21 Second Alternate Value Set OID (ST)

Definition: This component contains the ISO Object Identifier (OID) to allow identification of the value set from which the value in CF.10 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined value sets, the OID registered in the HL7 OID registry SHALL be used.

A value set may or need not be present irrespective of other fields. Note that if a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Applications SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set/ value set version ID.

2.A.7.22 Second Alternate Value Set Version ID (DTM)

Definition: This component carries the version for the value set identified by CF.21. The version is a date. The date is the date/time that the value set being used was published.

Value set version ID is required if CF.21 is populated.

2.A.8 CNE - coded with no exceptions

As of v2.7 a third tuple, formerly known as triplet, has been added to the CNE data type. Additionally, 3 new components were added to each tuple such that each tuple now has a total of 7 components. The Original Text component applies to the CNE as a whole.

HL7 Component Table - CNE - Coded with No Exceptions

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
20= ST R
Identifier
2.A.75 DB
2
199# ST O
Text
2.A.75 DB
3 1..12
ID O 0396 Name of Coding System
2.A.35 DB
4
20= ST O
Alternate Identifier
2.A.75 DB
5
199# ST O
Alternate Text
2.A.75 DB
6 1..12
ID O 0396 Name of Alternate Coding System
2.A.35 DB
7
10= ST C
Coding System Version ID
2.A.75 DB
8
10= ST O
Alternate Coding System Version ID
2.A.75 DB
9
199# ST O
Original Text
2.A.75 DB
10
20= ST O
Second Alternate Identifier
2.A.75 DB
11
199# ST O
Second Alternate Text
2.A.75 DB
12 1..12
ID O 0396 Name of Second Alternate Coding System
2.A.35 DB
13
10= ST C
Second Alternate Coding System Version ID
2.A.75 DB
14
199= ST C
Coding System OID
2.A.75 DB
15
199= ST O
Value Set OID
2.A.75 DB
16
8= DTM C
Value Set Version ID
2.A.22 DB
17
199= ST C
Alternate Coding System OID
2.A.75 DB
18
199= ST O
Alternate Value Set OID
2.A.75 DB
19
8= DTM C
Alternate Value Set Version ID
2.A.22 DB
20
199= ST C
Second Alternate Coding System OID
2.A.75 DB
21
199= ST O
Second Alternate Value Set OID
2.A.75 DB
22
8= DTM C
Second Alternate Value Set Version ID
2.A.22 DB

Note: The Vocabulary TC is the steward of the CNE data type.

Definition: Specifies a coded element and its associated detail. The CNE data type is used when a required or mandatory coded field is needed. The specified HL7 table or imported or externally defined coding system must be used and may not be extended with local values. Text may not replace the code. A CNE field must have an HL7 defined or external table associated with it. A CNE field may be context sensitive such that a choice of explicit coding systems might be designated. This allows for realm and other types of specificity. Every effort will be made to enumerate the valid coding system(s) to be specified in the 3rd component, however, the standards body realizes that this is impossible to fully enumerate.

Note: The presence of two sets of equivalent codes in this data type is semantically different from a repetition of a CNE-type field. With repetition, several distinct codes (with distinct meanings) may be transmitted.

Example 1: The drug must be coded and must be taken from the specified coding system. The coding system is an external coding system. Example is derived from FT1-26.

|0006-0106-58^Prinivil 10mg oral tablet^NDC|

Example 2: Consent mode must be coded and must be taken from the specified coding system. The coding system is an HL7 code table. Example is taken from CON-10.

|V^Verbal^HL70497^^^^2.7|

2.A.8.1 Identifier (ST)

Definition: The first component contains the sequence of characters (the code) that uniquely identifies the item being referenced by the CNE.2. Different coding schemes will have different elements here.

Usage Note: The identifier is required and must be a valid code.

2.A.8.2 Text (ST)

Definition: The second component contains the descriptive or textual name of the identifier, e.g., myocardial infarction or X-ray impression. This is the corresponding text assigned by the coding system to the identifier.

Usage Note: Text description of code is optional but its use should be encouraged since it makes messages easier to review for accuracy, especially during interface testing and debugging.

2.A.8.3 Name of Coding System (ID)

Definition: The third component contains the code for the name of the coding system from which the value in CNE.1 is obtained. Refer to HL7 Table 0396 - Coding Systems in Chapter 2C, section "Coding System Table" for valid values. Each coding system is assigned a unique identifier.

As of v2.7 this component is required when CNE.1 is populated and CNE.14 is not populated. Both CNE.3 and CNE.14 may be populated. Receivers should not identify a code based on its position within the tuples (Identifier, Alternate Identifier, or Second Alternate Identifier) or position within a repeating field. Instead, the receiver should always examine the codingSystem as specified in CNE.3 and/or CNE.14 the Coding System component or the Coding System OID for the tuple.The combination of the identifier and name of coding system represent a unique concept for a data item.

Some organizations that publish code sets author more than one. The coding system, then, to be unique, is a concatenation of the name of the coding authority organization and the name of its code set or table. When an HL7 table is used for a CNE data type, the name of coding system component is defined as HL7nnnn where nnnn is the HL7 table number. Similarly, ISO tables will be named ISOnnnn, where nnnn is the ISO table number.

Usage Note: The following statement is retained for backward compatibility as of v2.7. Best practice would recommend that this component always be populated. However, if the field narrative explicitly states "Refer to HL7 Table nnnn for valid values", and, if the sending and receiving systems are HL7 compliant, the coding system would be known from the standard. This would be similar to a field with an ID data type, except that there is a second triplet in which to express an alternate code.

2.A.8.4 Alternate Identifier (ST)

Definition: A sequence of characters that uniquely identifies an alternate code. Analogous to CNE.1 Identifier.

Usage Notes: The Alternate Identifier is used to represent the local or user seen code as described. If present, it obeys the same rules of use and interpretation as described for component 1. If both are present, the identifiers in component 4 and component 1 should have exactly the same meaning, i.e., they should be exact synonyms.

2.A.8.5 Alternate Text (ST)

Definition: The descriptive or textual name of the alternate identifier. Analogous to CNE.2 Text.

Usage Notes: If present, CNE.5 obeys the same rules of use and interpretation as described for CNE.2.

2.A.8.6 Name of Alternate Coding System (ID)

Definition: Identifies the coding scheme being used in the alternate identifier component. Analogous to CNE.3 Name of Coding System. Refer to HL7 Table 0396 - Coding Systems in Chapter 2C, section "Coding System Table", for valid values.

As of v2.7 this component is required when CNE.4 is populated and CNE.17 is not populated. Both CNE.6 and CNE.17 may be populated. Receivers should not identify a code based on its position within the tuples (Identifier, Alternate Identifier, or Second Alternate Identifier) or position within a repeating field. Instead, the receiver should always examine the codingSystem as specified in CNE.6 and/or CNE.17, the "Coding System" component or the "Coding System OID", for the tuple.

Usage Notes: If present, CNE.6 obeys the same rules of use and interpretation as described for CNE.3.

2.A.8.7 Coding System Version ID (ST)

Definition: the version ID for the coding system identified by CNE.3. It belongs conceptually to components 1-3 and appears here only for reasons of backward compatibility.

Usage Note: If the coding system is any system other than an "HL7 coding system," version ID must be valued with an actual version ID. If the coding system is "HL7 coding system," version ID may have an actual value or it may be absent. If version ID is absent, it will be interpreted to have the same value as the HL7 version number in the message header. Text description of code is optional but its use should be encouraged since it makes messages easier to review for accuracy, especially during interface testing and debugging.

2.A.8.8 Alternate Coding System Version ID (ST)

Definition: the version ID for the coding system identified by CNE.6. It belongs conceptually to the group of Alternate components (see note 2.A.1) and appears here only for reasons of backward compatibility. Analogous to CNE.7 Coding System Version ID.

Usage Notes: If present, CNE.8 obeys the same rules of use and interpretation as described for CNE.7.

2.A.8.9 Original Text (ST)

Definition: The text as seen and/or selected by the user who entered the data. Original text can be used in a structured user interface to capture what the user saw as a representation of the code on the data input screen, or in a situation where the user dictates or directly enters text, it is the text entered or uttered by the user. In a situation where the code is assigned sometime after the text was entered, original text is the text or phrase used as the basis for assigning the code.

2.A.8.10 Second Alternate Identifier (ST)

Definition: A sequence of characters that uniquely identifies a second alternate code. Analogous to CN-1 Identifier.

2.A.8.11 Second Alternate Text (ST)

Definition: The descriptive or textual name of the Second Alternate Identifier. Analogous to CNE.2 Text.

2.A.8.12 Name of Second Alternate Coding System (ID)

Definition: Identifies the coding scheme being used in the Second Alternate Identifier component. Analogous to CNE.3 Name of Coding System. Refer to HL7 Table 0396 - Coding Systems in Chapter 2C, section "Coding System Table", for valid values.

As of v2.7 this component is required when CNE.10 is populated and CNE.20 is not populated. Both CNE.12 and CNE.20 may be populated. Receivers should not identify a code based on its position within the tuples (Identifier, Alternate Identifier, or Second Alternate Identifier) or position within a repeating field. Instead, the receiver should always examine the codingSystem as specified in CNE.12 and/or CNE.20, the "Coding System" component or the "Coding System OID", for the tuple.

2.A.8.13 Second Alternate Coding System Version ID (ST)

Definition: This component carries the version for the coding system identified by components 10-12. Analogous to CNE.7 Coding System Version ID.

2.A.8.14 Coding System OID (ST)

Definition: This component contains the ISO Object Identifier (OID) for the coding system or value set named in CNE.3. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined code systems the OID registered in the HL7 OID registry SHALL be used.

This component is required when CNE.1 is populated and CNE.3 is not populated. Both CNE.3 and CNE.14 may be populated.

2.A.8.15 Value Set OID (ST)

Definition: This component contains the ISO Object Identifier (OID) to allow identification of the value set from which the value in CNE.1 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined value sets, the OID registered in the HL7 OID registry SHALL be used.

A value set may or need not be present irrespective of other fields. Note that if a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Applications SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set/ value set version ID.

2.A.8.16 Value Set Version ID (DTM)

Definition: This component carries the version for the value set identified by CNE.15. The version is a date. The date is the date/time that the value set being used was published.

Value set version ID is required if CNE.15 is populated.

2.A.8.17 Alternate Coding System OID (ST)

Definition: This component contains the ISO Object Identifier (OID) for the coding system or value set named in CNE.6. Analogous to CNE.14 OID for Coding System.

The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined code systems the OID registered in the HL7 OID registry SHALL be used.

This component is required when CNE.4 is populated and CNE.6 is not populated. Both CNE.6 and CNE.17 may be populated.

2.A.8.18 Alternate Value Set OID (ST)

Definition: This component contains the ISO Object Identifier (OID) to allow identification of the value set from which the value in CNE.4 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined value sets, the OID registered in the HL7 OID registry SHALL be used.

A value set may or need not be present irrespective of other fields. Note that if a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Applications SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set/ value set version ID.

2.A.8.19 Alternate Value Set Version ID (DTM)

Definition: This component carries the version for the value set identified by CNE.18. The version is a date. The date is the date/time that the value set being used was published.

Value set version ID is required if CNE.18 is populated.

2.A.8.20 Second Alternate Coding System OID (ST)

Definition: This component contains the ISO Object Identifier (OID) from which the value in CNE.12 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined numbers, the OID registered in the HL7 OID registry should be used.

This component is required when CNE.4 is populated and neither CNE.6 nor CNE.18 is populated. In short either the CNE.6 or the CNE.14 or CNE.17 must be populated when CNE.4 is populated.

2.A.8.21 Second Alternate Value Set OID (ST)

Definition: This component contains the ISO Object Identifier (OID) to allow identification of the value set from which the value in CNE.10 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined value sets, the OID registered in the HL7 OID registry SHALL be used.

A value set may or need not be present irrespective of other fields. Note that if a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Applications SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set/ value set version ID.

2.A.8.22 Second Alternate Value Set Version ID (DTM)

Definition: This component carries the version for the value set identified by CNE.21. The version is a date. The date is the date/time that the value set being used was published.

Value set version ID is required if CNE.21 is populated.

2.A.9 CNN - composite ID number and name simplified

Attention: Retained for backward compatibility only in version 2.6. Fields associated with this data type have been replaced by the ROL segment.

HL7 Component Table - CNN - Composite ID Number and Name Simplified

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
15= ST O
ID Number
2.A.75 DB
2
50# ST O
Family Name
2.A.75 DB
3
30# ST O
Given Name
2.A.75 DB
4
30# ST O
Second and Further Given Names or Initials Thereof
2.A.75 DB
5
20# ST O
Suffix (e.g., JR or III)
2.A.75 DB
6
20# ST O
Prefix (e.g., DR)
2.A.75 DB
7
5= IS O 0360 Degree (e.g., MD)
2.A.36 DB
8
4= IS C 0297 Source Table
2.A.36 DB
9
20= IS C 0363 Assigning Authority - Namespace ID
2.A.36 DB
10
199= ST C
Assigning Authority - Universal ID
2.A.75 DB
11 1..6
ID C 0301 Assigning Authority - Universal ID Type
2.A.35 DB

Definition: Specifies a person using both an identifier and the person's name. Retained for backward compatibility only as of v2.6.

Note: Restores the original data type CN as was initially implementable in the CM used in sections 4.5.3.32 and 7.4.1.32 - (OBR-32), 4.5.3.33 and 7.4.1.33 - ( OBR-33), 4.5.3.34 and 7.4.1.34 - ( OBR-34), 4.5.3.35 and 7.4.1.35 - (OBR-35). Components 7 and 8, however, have been promoted to data type IS to be consistent with current practice without violating backward compatibility.

2.A.9.1 ID Number (ST)

Coded ID according to a user-defined table. If the first component is present, either CNN.8 or CNN.9, or both CNN.10 and CNN.11, must be valued.

2.A.9.2 Family Name (ST)

This component contains the person's family name in a string format.

2.A.9.3 Given Name (ST)

Used to specify a first name.

2.A.9.4 Second and Further Given Names or Initials Thereof (ST)

2.A.9.5 Suffix (ST)

Used to specify a name suffix (e.g., Jr. or III).

2.A.9.6 Prefix (ST)

Used to specify a name prefix (e.g., Dr.).

2.A.9.7 Degree (IS)

Used to specify an educational degree (e.g., MD). Refer to User-defined Table 0360 - Degree/license/certificate for suggested values.

2.A.9.8 Source Table (IS)

Refer to User-defined Table 0297 - CN ID source for suggested values. Used to delineate the first component. If component 1 is valued, either CNN.8 or CNN.9, or both CNN.10 and CNN.11, must be valued.

2.A.9.9 Assigning Authority - Namespace ID (IS)

See section, 2.A.14.4, "Assigning Authority (HD)" for definition. Refer to User-defined Table 0363 - Assigning Authority for suggested values. Assigning Authority is normally expressed as an HD data type, but has been flattened to 3 components here (CNN.9, CNN.10 and CNN.11) in this data type so that it may be fully expressed. Also note that if additional components are added to the HD data type in the future, adjustment will need to be made accordingly to this data type.

If component 1 is valued, either CNN.8 or CNN.9, or both CNN.10 and CNN.11, must be valued.

2.A.9.10 Assigning Authority - Universal ID (ST)

See section, 2.A.14.4, "Assigning Authority (HD)" for definition.

If CNN.11 is valued, this component must be valued. If component 1 is valued, either CNN.8 or CNN.9, or both CNN.10 and CNN.11, must be valued.

2.A.9.11 Assigning Authority - Universal ID Type (ID)

See section, 2.A.14.4, "Assigning Authority (HD)" for definition. If this component is a known UID refer to HL7 Table 0301 - Universal ID type for valid values.

If CNN.10 is valued, this component must be valued. If component 1 is valued, either CNN.8 or CNN.9, or both CNN.10 and CNN.11, must be valued.

2.A.10 CP - composite price

HL7 Component Table - CP - Composite Price

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

MO R
Price
2.A.41 DB
2 1..2
ID O 0205 Price Type
2.A.35 DB
3
= NM O
From Value
2.A.47 DB
4
= NM O
To Value
2.A.47 DB
5

CWE C
Range Units
2.A.13 DB
6 1..1
ID O 0298 Range Type
2.A.35 DB

Note: This data type is often used to define a repeating field within a given segment.

Example:

|100.00&USD^UP^0^9^min^P~50.00&USD^UP^10^59^min^P~10.00&USD^UP^60^999^P~50.00&USD^AP~200.00&USD^PF

~80.00&USD^DC|

2.A.10.1 Price (MO)

Definition: The only required component; usually containing a decimal point. Note that each component of the MO data type (Section 2.A.41, "MO - money") is a subcomponent here.

2.A.10.2 Price Type (ID)

Definition: A coded value, data type ID. Refer to HL7 Table 0205 - Price Type for valid values.

2.A.10.3 From Value (NM)

Definition: The number specifying the lower limit or boundary of the range. This component, together with the CP.4 component, specifies the "price range". The range can be defined as either time or quantity. For example, the range can indicate that the first 10 minutes of the procedure has one price. Another repetition of the data type can use the range to specify that the following 10 to 60 minutes of the procedure is charged at another price per; a final repetition can specify that the final 60 to N minutes of the procedure at a third price.

Note that, if the CP.2 Price Type component is TP, both CP.3 and CP.4 may be null.

2.A.10.4 To Value (NM)

Definition: The number specifying the high limit or boundary of the range.

2.A.10.5 Range Units (CWE)

Definition: This component describes the units associated with the range, e.g., seconds, minutes, hours, days, quantity (i.e., count). As of v2.7 the Externally-defined Unified Code for Units of Measure (UCUM) case sensitive code is the required code for units of measure. Refer to the externally-defined table "Unified Code for Units of Measure" (UCUM) [http://aurora.rg.iupui.edu/UCUM] for valid values. Local codes may be transmitted in addition to UCUM codes.

This component is required if CP.3 From Value and/or CP.4 To Value are present.

2.A.10.6 Range Type (ID)

Definition: Refer to HL7 Table 0298 - CP Range Type for valid values.

2.A.11 CQ - composite quantity with units

HL7 Component Table - CQ -Composite Quantity with Units

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

NM O
Quantity
2.A.47 DB
2

CWE O 9999 Units
2.A.13 DB

Note: CQ cannot be legally expressed when embedded within another data type. Its use is constrained to a segment field.

Examples:

|123.7^kg| kilograms is an ISO unit

|150^lb&&ANSI+| weight in pounds is a customary US unit defined within ANSI+.

2.A.11.1 Quantity (NM)

Definition: This component specifies the numeric quantity or amount of an entity.

2.A.11.2 Units (CWE)

Definition: This component species the units in which the quantity is expressed. As of v2.7 the externally-defined Unified Code for Units of Measure (UCUM) case sensitive code is the required code for units of measure. Refer to the external table "Unified Code for Units of Measure" (UCUM) [http://aurora.rg.iupui.edu/UCUM] for valid values. Local codes may be transmitted in addition to UCUM codes.

2.A.12 CSU - channel sensitivity and units

Attention: Retained for backward compatibility only in version 2.7. This is used only in the CD Channel Definition data type, which has been retained for backward compatibility only in version 2.7.

As of v2.7 a third tuple, formerly known as triplet, has been added to the CSU data type. Additionally, 3 new components were added to each tuple such that each tuple now has a total of 7 components. The Original Text component applies to the CSU as a whole.

HL7 Component Table - CSU - Channel Sensitivity and Units

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

NM R
Channel Sensitivity
2.A.47 DB
2
20= ST C
Unit of Measure Identifier
2.A.75 DB
3
199# ST C
Unit of Measure Description
2.A.75 DB
4 1..12
ID C 0396 Unit of Measure Coding System
2.A.35 DB
5
20= ST O
Alternate Unit of Measure Identifier
2.A.75 DB
6
199# ST O
Alternate Unit of Measure Description
2.A.75 DB
7 1..12
ID C 0396 Alternate Unit of Measure Coding System
2.A.35 DB
8
10= ST C
Unit of Measure Coding System Version ID
2.A.75 DB
9
10= ST O
Alternate Unit of Measure Coding System Version ID
2.A.75 DB
10 199 199# ST O
Original Text
2.A.75 DB
11
20= ST O
Second Alternate Unit of Measure Identifier
2.A.75 DB
12
199# ST O
Second Alternate Unit of Measure Text
2.A.75 DB
13 1..12
ID O 0396 Name of Second Alternate Unit of Measure Coding System
2.A.35 DB
14
10= ST C
Second Alternate Unit of Measure Coding System Version ID
2.A.75 DB
15
199= ST C
Unit of Measure Coding System OID
2.A.75 DB
16
199= ST O
Unit of Measure Value Set OID
2.A.75 DB
17
8= DTM C
Unit of Measure Value Set Version ID
2.A.75 DB
18
199= ST C
Alternate Unit of Measure Coding System OID
2.A.75 DB
19
199= ST O
Alternate Unit of Measure Value Set OID
2.A.75 DB
20
8= DTM C
Alternate Unit of Measure Value Set Version ID
2.A.75 DB
21
199= ST C
Alternate Unit of Measure Coding System OID
2.A.75 DB
22
199= ST O
Alternate Unit of Measure Value Set OID
2.A.75 DB
23
8= ST C
Alternate Unit of Measure Value Set Version ID
2.A.75 DB

Definition: This data type defines the channel sensitivity (gain) and the units in which it is measured in a waveform result.

Note: Replaces the CM data type used in 7.14.1.5 OBX-5.3 where OBX-5 Observation value (*) is data type CD as of v 2.5.

2.A.12.1 Channel Sensitivity (NM)

Definition: This component transmits the nominal value that corresponds to one unit in the waveform data, that is, the effective resolution of the least significant bit of the ADC, and the polarity of the channel.

2.A.12.2 Unit of Measure Identifier (ST)

Definition: The unit designation for the channel sensitivity. This field is required if the unit of measure description is not present.

2.A.12.3 Unit of Measure Description (ST)

Definition: The full text name of the unit of measure identifier. This field is required if the unit of measure identifier is not present.

2.A.12.4 Unit of Measure Coding System (ID)

Definition: Specifies the designated system of units. Refer to HL7 Table 0396 - Coding System in Chapter 2C, section "Coding System Table" for valid values. This component is required if the CSU.2 Unit of Measure Identifier is present.

Both CSU.4 and CSU.15 may be populated. Receivers should not identify a code based on its position within the tuples (Identifier, Alternate Identifier, or Second Alternate Identifier) or position within a repeating field. Instead, the receiver should always examine the codingSystem as specified in CSU.4 and/or CSU.15, the "Coding System" component or the "Coding System OID" for the tuple.

2.A.12.5 Alternate Unit of Measure Identifier (ST)

Definition: A sequence of characters that uniquely identifies an alternate units designation for the channel sensitivity. Analogous to CSU.2 Unit of Measure Identifier.

Usage Notes: The Alternate Identifier is used to represent the local or user seen code as described. If present, it obeys the same rules of use and interpretation as described for component 1. If both are present, the identifiers in component 4 and component 1 should have exactly the same meaning, i.e., they should be exact synonyms.

2.A.12.6 Alternate Unit of Measure Description (ST)

Definition: The full text name of the alternate unit of measure identifier. Analogous to CSU.3 Unit of Measure Description.

2.A.12.7 Alternate Unit of Measure Coding System (ID)

Definition: Specifies the coding system for the alternate unit of measure. Refer to HL7 Table 0396 - Coding System in Chapter 2C, section "Coding System Table" for valid values. Analogous to CSU.4 Unit of Measure Coding System.

This field is required if the CSU.5 Alternate Unit of Measure Identifier is present. Both CSU.7 and CSU.18 may be populated. Receivers should not identify a code based on its position within the tuples (Identifier, Alternate Identifier, or Second Alternate Identifier) or position within a repeating field. Instead, the receiver should always examine the codingSystem as specified in CSU.7 and/or CSU.18, the "Coding System" component or the "Coding System OID" for the tuple.

2.A.12.8 Unit of Measure Coding System Version ID (ST)

Definition: This component carries the version for the coding system identified by components 2-4. If CSU.4 is populated with a value other than HL7nnnn or is of table type user-defined, version ID must be valued with an actual version ID. If CSU.4 is populated with a value of HL7nnnn and nnnn is of table type HL7, version ID may have an actual value or it may be absent. If version ID is absent, it will be interpreted to have the same value as the HL7 version number in the message header.

2.A.12.9 Alternate Unit of Measure Coding System Version ID (ST)

Definition: This component carries the version for the coding system identified by components 5-7. Analogous to CSU.8 Unit of Measure Coding System Version ID.

2.A.12.10 Original Text (ST)

Definition: The text as seen and/or selected by the user who entered the data. Original text can be used in a structured user interface to capture what the user saw as a representation of the code on the data input screen, or in a situation where the user dictates or directly enters text, it is the text entered or uttered by the user. In a situation where the code is assigned sometime after the text was entered, original text is the text or phrase used as the basis for assigning the code.

2.A.12.11 Second Alternate Unit of Measure Identifier (ST)

Definition: A sequence of characters that uniquely identifies a second alternate units designation for the channel sensitivity. Analogous to CSU.2 Unit of Measure Identifier.

2.A.12.12 Second Alternate Unit of Measure Text (ST)

Definition: The descriptive or textual name of the second alternate identifier. Analogous to CSU.3 Unit of Measure Description.

2.A.12.13 Name of Second Alternate Unit of Measure Coding System (ID)

Definition: Specifies the coding system for the second alternate unit of measure. Analogous to CSU.4 Unit of Measure Coding System. Refer to HL7 Table 0396 - Coding System in Chapter 2C, section "Coding System Table" for valid values.

This component is required when CSU.11 is populated. Both CSU.13 and CSU.21 may be populated. Receivers should not identify a code based on its position within the tuples (Identifier, Alternate Identifier, or Second Alternate Identifier) or position within a repeating field. Instead, the receiver should always examine the codingSystem as specified in CSU.13 and/or CSU.21 the Coding System component or the Coding System OID for the tuple.

2.A.12.14 Second Alternate Unit of Measure Coding System Version ID (ST)

Definition: This component carries the version for the coding system identified by components 11-13. Analogous to CSU.8 Unit of Measure Coding System Version ID.

2.A.12.15 Unit of Measure Coding System OID (ST)

Definition: This component contains the ISO Object Identifier (OID) for the coding system or value set named in CSU.4. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined code systems the OID registered in the HL7 OID registry SHALL be used.

This component is required when CSU.2 is populated and CSU.4 is not populated. Both CSU.4 and CSU.15 may be populated.

2.A.12.16 Unit of Measure Value Set OID (ST)

Definition: This component contains the ISO Object Identifier (OID) to allow identification of the value set from which the value in CSU.2 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined value sets, the OID registered in the HL7 OID registry SHALL be used.

A value set may or need not be present irrespective of other fields. Note that if a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Applications SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set/ value set version ID.

2.A.12.17 Unit of Measure Value Set Version ID (DTM)

Definition: This component carries the version for the value set identified by CSU.16. The version is a date. The date is the date/time that the value set being used was published.

Value set version ID is required if CSU.16 is populated.

2.A.12.18 Alternate Unit of Measure Coding System OID (ST)

Definition: This component contains the ISO Object Identifier (OID) for the coding system or value set named in CSU.7. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined code systems the OID registered in the HL7 OID registry SHALL be used.

This component is required when CSU.5 is populated and CSU.7 is not populated. Both CSU.7 and CSU.18 may be populated.

2.A.12.19 Alternate Unit of Measure Value Set OID (ST)

Definition: This component contains the ISO Object Identifier (OID) to allow identification of the value set from which the value in CSU.5 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined value sets, the OID registered in the HL7 OID registry SHALL be used.

A value set may or need not be present irrespective of other fields. Note that if a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Applications SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set/ value set version ID.

2.A.12.20 Alternate Unit of Measure Value Set Version ID (DTM)

Definition: This component carries the version for the value set identified by CSU.19. The version is a date. The date is the date/time that the value set being used was published.

Value set version ID is required if CSU.19 is populated.

2.A.12.21 Second Alternate Unit of Measure Coding System OID (ST)

Definition: This component contains the ISO Object Identifier (OID) for the coding system or value set named in CSU.13. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined code systems the OID registered in the HL7 OID registry SHALL be used.

This component is required when CSU.11 is populated and CSU.13 is not populated. Both CSU.13 and CSU.21 may be populated.

2.A.12.22 Second Alternate Unit of Measure Value Set OID (ST)

Definition: This component contains the ISO Object Identifier (OID) to allow identification of the value set from which the value in CSU.11 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined value sets, the OID registered in the HL7 OID registry SHALL be used.

A value set may or need not be present irrespective of other fields. Note that if a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Applications SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set/ value set version ID.

2.A.12.23 Second Alternate Unit of Measure Value Set Version ID (ST)

Definition: This component carries the version for the value set identified by CSU.22. The version is a date. The date is the date/time that the value set being used was published.

Value set version ID is required if CSU.22 is populated.

2.A.13 CWE - coded with exceptions

As of v2.7 a third tuple, formerly known as triplet, has been added to the CWE data type. Additionally, 3 new components were added to each tuple such that each tuple now has a total of 7 components. The Original Text component applies to the CWE as a whole.

HL7 Component Table - CWE - Coded with Exceptions

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
20= ST O
Identifier
2.A.75 DB
2
199# ST O
Text
2.A.75 DB
3 1..12
ID C 0396 Name of Coding System
2.A.35 DB
4
20= ST O
Alternate Identifier
2.A.75 DB
5
199# ST O
Alternate Text
2.A.75 DB
6 1..12
ID C 0396 Name of Alternate Coding System
2.A.35 DB
7
10= ST C
Coding System Version ID
2.A.75 DB
8
10= ST O
Alternate Coding System Version ID
2.A.75 DB
9
199# ST O
Original Text
2.A.75 DB
10
20= ST O
Second Alternate Identifier
2.A.75 DB
11
199# ST O
Second Alternate Text
2.A.75 DB
12 1..12
ID C 0396 Name of Second Alternate Coding System
2.A.35 DB
13
10= ST O
Second Alternate Coding System Version ID
2.A.75 DB
14
199= ST C
Coding System OID
2.A.75 DB
15
199= ST O
Value Set OID
2.A.75 DB
16
8= DTM C
Value Set Version ID
2.A.22 DB
17
199= ST C
Alternate Coding System OID
2.A.75 DB
18
199= ST O
Alternate Value Set OID
2.A.75 DB
19
8= DTM C
Alternate Value Set Version ID
2.A.75 DB
20
199= ST C
Second Alternate Coding System OID
2.A.75 DB
21
199= ST O
Second Alternate Value Set OID
2.A.75 DB
22
8= DTM C
Second Alternate Value Set Version ID
2.A.22 DB

Note: The Vocabulary TC is the steward of the CWE data type.

Definition: Specifies a coded element and its associated detail. The CWE data type is used when 1) more than one table may be applicable or 2) the specified HL7 or externally defined table may be extended with local values or 3) when text is in place, the code may be omitted.

The presence of two sets of equivalent codes in this data type is semantically different from a repetition of a CWE-type field. With repetition, several distinct codes (with distinct meanings) may be transmitted.

Usage Notes: The CWE data type should be used for coded fields with one or more of the following characteristics:

The identifier code (CWE.1) component is optional

The set of allowable values from which the identifier code is drawn may be extended on a site-specific basis

An exception identifier code may be encountered; that is, a code that is not defined in the value set (either model or site-extended).

This is in contrast to the CNE data type, which requires a code from a non-extendable value set be sent in the identifier code component (CNE.1) in all cases (except, of course, if the entire field is empty and defined as optional at the segment level).

The rules for populating CWE components are governed by the status of the identifier code:

Identifier Code Status

Identifier Code (CWE.1)

Descriptive Text (CWE.2)

Coding System (CWE.3)

Contained in model value set

Populated

May be populated

Must be populated with model coding system, or (not recommended) site-specific coding system that is a superset containing model values.

Contained in site-specific extensions to model value set

Populated

May be populated

Site-specific coding system.

Contained in neither model nor extended value sets

Not populated

May be populated with the identifier code, free-text description, or a concatenation of the two. Should be human interpretable.

Must not be populated.

Not supplied; but descriptive text is supplied.

Not populated

May be populated with descriptive text.

Must not be populated.

As an example, consider "currency" codes where:

The model values are defined by the ISO 4217 value set,

The value set is extended on site to include the code HL7 - "HL7 Drink Ticket", and

The data entry screen on the sending system does not enforce any edits for the currency code.

And so the value set used on site is:

Identifier Code Status

Identifier

Code

Descriptive Text

Model values from ISO 4217 external table

AED

United Arab Emirates, Dirhams

AFA

Afghanistan, Afghanis

ALL

Albania, Leke

...

ZAR

South Africa, Rand

ZMK

Zambia, Kwacha

ZWD

Zimbabwe, Zimbabwe Dollars

Site-specific extension

HL7

HL7 Events, Drink Ticket

Collectively, this value set must be referred to with a local coding system ID, because "HL7" does not exist in ISO 4217. According to the rules, the site assigns the coding system ID "99CUR" to the value set.

Based on the code and descriptive text entered by the user on the sending system, the CWE would be populated as follows:

Entered by user

Sent in CWE

Code

Descriptive Text

Identifier Code (CWE.1)

Descriptive Text (CWE.2)

Coding System (CWE.3)

GBP

Great Britain, Pound

GBP

Great Britain, Pound

ISO4217

GBP

Great Britain, Pound

99CUR (This option is NOT recommended)

HL7

HL7 Drink Ticket

HL7

HL7 Drink Ticket

99CUR

XXX

<Bogus entry>

Must not be populated

XXX

Must not be populated.

Must not be populated

Bogus entry

Must not be populated.

Must not be populated

XXX: Bogus entry

Must not be populated.

Must not be populated

anything - or nothing.

Must not be populated.

Dollar

Must not be populated

Dollar

Must not be populated.

Valued from HL7 Table 0353 (e.g., "U" for unkown)

Dollar

HL70353

Notes:

Where multiple valid options for sending the entered data exist, each alternative is depicted as a separate row.

CWE.2 - Descriptive Text is never required, and there are no hard and fast rules on what text may be sent in this component. Of course, common sense suggests that if valued, the text should complement the identifier code of CWE.1.

It follows that where CWE.1 cannot be valued because the entered code does not exist in the value set, the entered code may be sent in CWE.2; with or without additional descriptive text. However, this is not required by HL7.

The example with GBP shows two options for the code set: ISO4217 or 99CUR. While it is now technically possible to send 99CUR on the basis that this code may exist on its own in the extended local code set, HL7 urges that where a code is a member of the standard code set, that code set should be named in CWE.3. HL7 intends to mandate this in a future release.

While there are no formal rules regarding the valuation of CWE.2 - Descriptive Text, it is expected that any value contained therein be meaningful to a human reader.

2.A.13.1 Identifier (ST)

Definition: The first component contains the sequence of characters (the code) that uniquely identifies the item being referenced by the CWE.2. Different coding schemes will have different elements here.

In the context of "Data Missing", described above in the Usage Note, refer to HL7 Table 0353 - CWE Statuses for valid values.

HL7 Table 0353 - CWE statuses

Code Description Comment
U Unknown
UASK Asked but Unknown
NAV Not available
NA Not applicable
NASK Not asked

Refer to section 2.5.5.5 in Chapter 2, Control, for some discussion on the length of this component.

2.A.13.2 Text (ST)

Definition: The second component contains the descriptive or textual name of the identifier, e.g., "myocardial infarction" or "X-ray impression".

2.A.13.3 Name of Coding System (ID)

Definition: The third component contains the code for the name of the coding system from which the value in CWE.1 is obtained. Each coding system is assigned a unique identifier. As of v2.7 this component is required when CWE.1 is populated and CWE.14 is not populated. Both CWE.3 and CWE.14 may be populated. Receivers should not identify a code based on its position within the tuples (Identifier, Alternate Identifier, or Second Alternate Identifier) or position within a repeating field. Instead, the receiver should always examine the codingSystem as specified in CWE.3 and/or CWE.14, the "Coding System" component or the "Coding System OID" for the tuple.

Refer to HL7 Table 0396 - Coding System in Chapter 2C, section "Coding System Table" for valid values.

Refer to section 2.A.8.3, "Name of Coding System (ID)" for a discussion of coding system conventions.

2.A.13.4 Alternate Identifier (ST)

Definition: A sequence of characters that uniquely identifies an alternate code. Analogous to CWE.1- Identifier.

Usage Notes: The Alternate Identifier is used to represent the local or user seen code as described. If present, it obeys the same rules of use and interpretation as described for component 1. If both are present, the identifiers in component 4 and component 1 should have exactly the same meaning, i.e., they should be exact synonyms.

2.A.13.5 Alternate Text (ST)

Definition: The descriptive or textual name of the alternate identifier. Analogous to CWE.2 - Text. See usage note in section introduction.

2.A.13.6 Name of Alternate Coding System (ID)

Definition: Identifies the coding scheme being used in the alternate identifier component. Analogous to CWE.3 - Name of Coding System. See usage note in section introduction.

As of v2.7 this component is required when CWE.4 is populated and CWE.17 is not populated. Both CWE.6 and CWE.17 may be populated. Receivers should not identify a code based on its position within the tuples (Identifier, Alternate Identifier, or Second Alternate Identifier) or position within a repeating field. Instead, the receiver should always examine the coding System as specified in CWE.6 and/or CWE.17, the "Coding System" component or the "Coding System OID", for the tuple.

2.A.13.7 Coding System Version ID (ST)

Definition: This component carries the version for the coding system identified by components 1-3. If CWE.3 is populated with a value other than HL7nnnn or is of table type user-defined, version ID must be valued with an actual version ID. If CWE.3 is populated with a value of HL7nnnn and nnnn is of table type HL7, version ID may have an actual value or it may be absent. If version ID is absent, it will be interpreted to have the same value as the HL7 version number in the message header.

2.A.13.8 Alternate Coding System Version ID (ST)

Definition: This component carries the version for the coding system identified by components 4-6. Analogous To CWE.7 - Coding System Version ID.

2.A.13.9 Original Text (ST)

Definition: The text as seen and/or selected by the user who entered the data. Original text can be used in a structured user interface to capture what the user saw as a representation of the code on the data input screen, or in a situation where the user dictates or directly enters text, it is the text entered or uttered by the user. In a situation where the code is assigned sometime after the text was entered, original text is the text or phrase used as the basis for assigning the code.

2.A.13.10 Second Alternate Identifier (ST)

Definition: A sequence of characters that uniquely identifies a second alternate code. Analogous to CWE.1- Identifier.

2.A.13.11 Second Alternate Text (ST)

Definition: The descriptive or textual name of the alternate identifier. Analogous to CWE.2 - Text. See usage note in section introduction.

2.A.13.12 Name of Second Alternate Coding System (ID)

Definition: Identifies the coding scheme being used in the alternate identifier component. Analogous to CWE.3 Name of Coding System. See usage note in section introduction.

As of v2.7 this component is required when CWE.10 is populated and CWE.20 is not populated. Both CWE.6 and CWE.17 may be populated. Receivers should not identify a code based on its position within the tuples (Identifier, Alternate Identifier, or Second Alternate Identifier) or position within a repeating field. Instead, the receiver should always examine the coding System as specified in CWE.12 and/or CWE.20, the "Coding System" component or the "Coding System OID", for the tuple.

2.A.13.13 Second Alternate Coding System Version ID (ST)

Definition: This component carries the version for the coding system identified by components 10-12. Analogous to CWE.7 - Coding System Version ID.

2.A.13.14 Coding System OID (ST)

Definition: This component contains the ISO Object Identifier (OID) for the coding system or value set named in CWE.3. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined code systems the OID registered in the HL7 OID registry SHALL be used.

This component is required when CWE.1 is populated and CWE.3 is not populated. Both CWE.3 and CWE.14 may be populated.

2.A.13.15 Value Set OID (ST)

Definition: This component contains the ISO Object Identifier (OID) to allow identification of the value set from which the value in CWE.1 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined value sets, the OID registered in the HL7 OID registry SHALL be used.

A value set may or need not be present irrespective of other fields. Note that if a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Applications SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set/ value set version ID.

2.A.13.16 Value Set Version ID (DTM)

Definition: This component carries the version for the value set identified by CWE.15. The version is a date. The date is the date/time that the value set being used was published.

Value set version ID is required if CWE.15 is populated.

2.A.13.17 Alternate Coding System OID (ST)

Definition: This component contains the ISO Object Identifier (OID) for the coding system or value set named in CWE.6. Analogous to CWE.14 Coding System OID.

The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined code systems the OID registered in the HL7 OID registry SHALL be used.

This component is required when CWE.4 is populated and CWE.6 is not populated. Both CWE.6 and CWE.17 may be populated.

2.A.13.18 Alternate Value Set OID (ST)

Definition: This component contains the ISO Object Identifier (OID) to allow identification of the value set from which the value in CWE.4 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined value sets, the OID registered in the HL7 OID registry SHALL be used.

A value set may or need not be present irrespective of other fields. Note that if a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Applications SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set/ value set version ID.

2.A.13.19 Alternate Value Set Version ID (DTM)

Definition: This component carries the version for the value set identified by CWE.18. The version is a date. The date is the date/time that the value set being used was published.

Value set version ID is required if CWE.18 is populated.

2.A.13.20 Second Alternate Coding System OID (ST)

Definition: This component contains the ISO Object Identifier (OID) for the coding system or value set named in CWE.12. Analogous to CWE.14 - Coding System OID.

The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined code systems the OID registered in the HL7 OID registry SHALL be used.

This component is required when CWE.10 is populated and CWE.12 is not populated. Both CWE.12 and CWE.20 may be populated.

2.A.13.21 Second Alternate Value Set OID (ST)

Definition: This component contains the ISO Object Identifier (OID) to allow identification of the value set from which the value in CWE.10 is obtained. The value for this component is 2.16.840.1.113883.12.#### where "####" is to be replaced by the HL7 table number in the case of an HL7 defined or user defined table. For externally defined value sets, the OID registered in the HL7 OID registry SHALL be used.

A value set may or need not be present irrespective of other fields. Note that if a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Applications SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set/ value set version ID.

2.A.13.22 Second Alternate Value Set Version ID (DTM)

Definition: This component carries the version for the value set identified by CWE.21. The version is a date. The date is the date/time that the value set being used was published.

Value set version ID is required if CWE.21 is populated.

2.A.14 CX - extended composite ID with check digit

HL7 Component Table - CX - Extended Composite ID with Check Digit

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
15= ST R
ID Number
2.A.75 DB
2
4= ST O
Identifier Check Digit
2.A.75 DB
3 3..3
ID O 0061 Check Digit Scheme
2.A.35 DB
4

HD C 0363 Assigning Authority
2.A.33 DB
5 2..5
ID R 0203 Identifier Type Code
2.A.35 DB
6

HD O
Assigning Facility
2.A.33 DB
7

DT O
Effective Date
2.A.21 DB
8

DT O
Expiration Date
2.A.21 DB
9

CWE C
Assigning Jurisdiction
2.A.13 DB
10

CWE C
Assigning Agency or Department
2.A.13 DB
11
4= ST O
Security Check
2.A.74 DB
12 3..3
ID O 0904 Security Check Scheme
2.A.35 DB

Definition: This data type is used for specifying an identifier with its associated administrative detail.

Note: The check digit and check digit scheme are null if ID is alphanumeric.

Example:

|1234567^4^M11^ADT01^MR^University Hospital|

2.A.14.1 ID (ST)

Definition: The value of the identifier itself.

2.A.14.2 Identifier Check Digit (ST)

Definition: A digit, or digits, exclusive of the identifier in CX.1, calculated by applying an algorithm to all or some of the digits in the number, which may be used to test validity of the non-check-digit identifier.

2.A.14.3 Check Digit Scheme (ID)

Definition: Contains the code identifying the check digit scheme employed.

Refer to HL7 Table 0061 - Check Digit Scheme for valid values.

The algorithm for calculating a Mod10 check digit is as follows:

Assume you have an identifier - 12345. Take the odd digit positions, counting from the right, i.e., 531, multiply this number by 2 to get 1062. Take the even digit positions, starting from the right (i.e., 42), prepend these to the 1062 to get 421062. Add all of these six digits together to get 15. Subtract this number from the next highest multiple of 10, i.e., 20 - 15 to get 5. The Mod10 check digit is 5. The Mod10 check digit for 401 is 0; for 9999, it's 4; for 99999999, it's 8.

The algorithm for calculating a Mod11 check digit is as follows:

Terms

d

=

digit of number starting from units digit, followed by 10's position, followed by 100's position, etc.

w

=

weight of digit position starting with the units position, followed by 10's position, followed by 100's position etc. Values for w = 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, etc. (repeats for each group of 6 digits)

c

=

check digit

Calculation

(Step 1) m

=

sum of (d * w) for positions 1, 2, etc. starting with units digit

for d = digit value starting with units position to highest order

for w = weight value from 2 to 7 for every six positions starting with units digit

(Step 2) c1

=

m mod 11

(Step 3) if c1

=

0 then reset c1 = 1

(Step 4)

=

(11 - c1) mod 10

Example:

If the number is 1234567, then the mod 11 check digit = 4

The calculations are:

M = (7*2)+(6*3)+(5*4)+(4*5)+(3*6)+(2*7)+(1*2)

= 14 + 18 + 20 + 20 + 18 + 14 + 2

= 106

c1 = 106 mod 11

= 7

c = (11-c1) mod 10

= 4 mod 10

= 4

Other variants of these check digit algorithms exist and may be used by local bilateral site agreement.

Note: The check digit and code identifying check digit scheme are null if ID is alphanumeric.

2.A.14.4 Assigning Authority (HD)

The assigning authority is a unique name of the system (or organization or agency or department) that creates the data. As of v2.7, CX.4 Assigning Authority is required if neither CX.9 nor CX.10 are populated. Best practice is to always send an OID in the Assigning Authority component

Refer to User-defined Table 0363 - Assigning Authority for suggested values.

The reader is referred to the CX.9 and the CX.10 if there is a need to transmit values with semantic meaning for an assigning jurisdiction or assigning department or agency in addition to, or instead of, an assigning authority. However, all 3 components may be valued. If, in so doing, it is discovered that the values in CX.9 and/or CX.10 conflict with CX.4, the user would look to the Message Profile or other implementation agreement for a statement as to which takes precedence.

Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component) may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment. By site agreement, implementers may continue to use User-defined Table 0300 - Namespace ID for the first sub-component.

2.A.14.5 Identifier Type Code (ID)

A code corresponding to the type of identifier. As of v2.7, CX.5 Identifier Type Code is required. Refer to HL7 Table 0203 - Identifier Type for suggested values.

2.A.14.6 Assigning Facility (HD)

Definition: The place or location identifier where the identifier was first assigned to the patient. This component is not an inherent part of the identifier but rather part of the history of the identifier: as part of this data type, its existence is a convenience for certain intercommunicating systems.

Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component), may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment.

2.A.14.7 Effective Date (DT)

Definition: The first date, if known, on which the identifier is valid and active.

2.A.14.8 Expiration Date (DT)

Definition: The last date, if known, on which the identifier is valid and active.

2.A.14.9 Assigning Jurisdiction (CWE)

Definition: The geo-political body that assigned the identifier in component 1. As of v2.7, Assigning Jurisdiction is required if neither CX.4 nor CX.10 are populated.

The reader is referred to the CX.4 if there is a need to transmit this information as an OID.

2.A.14.10 Assigning Agency or Department (CWE)

Definition: The agency or department that assigned the identifier in component 1. As of v2.7, Assigning Agency or Department is required if neither CX.4 nor CX.9 are populated.

Refer to User-defined Table 0530 - Organizations, agency, department for suggested values if the administrative unit under whose jurisdiction the identifier was issued is an organization, agency or department. This is populated with site-specific assigning authorities. It also should contain national or international codes when CX.5 Identifier Type Code may be assigned by more than one authority within a governmental or organizational unit. For example, a federal government may have 2 departments that assign a military identifier, its Veterans Affairs department and its Department of Defense. It is not recommended to include values for entities such as Social Security Administration (SSA), Immigration and Naturalization Service (INS), Center for Medicare and Medicaid Services (CMS) because they are included in the identifier type table. In these cases the name of the country plus the identifier type yields the correct interpretation of the identifier in component 1. Likewise, entries like department of motor vehicles (DMV) and licensing boards are not recommended for inclusion because the combination of state and identifier type yields the correct interpretation of the identifier in component 1. This approach is not to be confused with the detailed information provided in the Chapter 15 segments that have provision for specifying the precise granting body and issuing body information needed in personnel management messages.

Example 1: <Identifier> plus <Visa> yields a unique identifier.

Example 2: <identifier> plus <state> plus <DLN> yields a unique driver's license number.

Example 3: <identifier> plus <country> plus <INS> yields a unique immigration number.

The reader is referred to the CX.4, if there is a need to transmit this information as an OID.

2.A.14.11 Security Check (ST)

Definition: This component is used to communicate a version code that may be assigned to the value given in CX.1 ID.

2.A.14.12 Security Check Scheme (ID)

Definition: This component is used to transmit information intended to validate the veracity of the supplied identifier or the presenter of the identifier. For example, this component may be used to ensure that the presenter of a credit card is an authorized user of that card.

Refer to HL7 Table 0904 - Security Check Scheme for valid values.

2.A.15 DDI - daily deductible information

HL7 Component Table - DDI - Daily Deductible Information

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
3= NM O
Delay Days
2.A.47 DB
2

MO R
Monetary Amount
2.A.41 DB
3
4= NM O
Number of Days
2.A.47 DB

Definition: This data type specifies the detail information for the daily deductible.

Note: Replaces the CM data type used in section 6.5.7.30 IN2-30, as of v 2.5.

2.A.15.1 Delay Days (NM)

Definition: The number of days after which the daily deductible begins.

2.A.15.2 Monetary Amount (MO)

Definition: The monetary amount of the deductible.

2.A.15.3 Number of Days (NM)

Definition: The number of days to apply the deductible. If this component is not populated, it means that the number of days is indefinite.

2.A.16 DIN - date and institution name

HL7 Component Table - DIN - Date and Institution Name

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

DTM R
Date
2.A.22 DB
2

CWE R 0531 Institution Name
Error! Reference source not found. DB

Definition: Specifies the date and institution information where a staff member became active or inactive.

Note: Replaces the CM data type used in sections 15.4.6.12 STF-12 and 15.4.6.14 STF-13, as of v 2.5.

2.A.16.1 Date (DTM)

Definition: Specifies the date when a staff member became active or inactive.

2.A.16.2 Institution Name (CWE)

Definition: Specifies the institution where a staff member is or was active. Refer to User-Defined Table 0531 - Institution for suggested values.

2.A.17 DLD - discharge to location and date

HL7 Component Table - DLD - Discharge to Location and Date

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE R 0113 Discharge to Location
2.A.36 DB
2

DTM O
Effective Date
2.A.22 DB

Definition: Specifies the healthcare facility to which the patient was discharged and the date.

Note: Replaces the CM data type used in section 3.4.3.37 PV1-37, as of v 2.5.

2.A.17.1 Discharge to Location (CWE)

Definition: This component specifies the healthcare facility to which the patient was discharged. Refer to User-defined Table 0113 - Discharged to Location for suggested values.

2.A.17.2 Effective Date (DTM)

Definition: Specifies the date on which the patient was discharged to a healthcare facility.

2.A.18 DLN - driver's license number

HL7 Component Table - DLN - Driver's License Number

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
20= ST R
License Number
2.A.75 DB
2

CWE O 0333 Issuing State, Province, Country
2.A.36 DB
3

DT O
Expiration Date
2.A.21 DB

Definition: This field contains the driver's license information. For state or province refer to official postal codes for that country; for country refer to ISO 3166 for codes.

2.A.18.1 Driver's License Number (ST)

Definition: This field contains the driver's license number.

2.A.18.2 Issuing State, Province, Country (CWE)

Definition: Issuing authority for driver's license. For state or province, refer to official postal codes for that country; for country, refer to ISO 3166 for codes. The ISO 3166 table has three separate forms of the country code: HL7 specifies that the 3-character (alphabetic) form be used for the country code. User-defined Table 0333 - Driver's License Issuing Authority is used as the HL7 identifier for the user-defined table of values for this component.

2.A.18.3 Expiration Date (DT)

Definition: Expiration date (DT) for driver's license.

2.A.19 DLT - delta

HL7 Component Table - DLT - Delta

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

NR O
Normal Range
2.A.48 DB
2
4# NM O
Numeric Threshold
2.A.47 DB
3

ID O 0523 Change Computation
2.A.75 DB
4
4# NM O
Days Retained
2.A.47 DB

Definition: Describes the information that controls delta check warnings.

Note: Replaces the CM data type used in section 8.8.4.9 - OM2-9, as of v 2.5.

2.A.19.1 Normal Range (NR)

Definition: Specifies the normal interval of the reference data.

2.A.19.2 Numeric Threshold (NM)

Definition: The numeric threshold of the change that is detected.

For example the threshold may be set to 10.

2.A.19.3 Change Computation (ID)

Definition: Specifies if the change is computed as a percent change or as an absolute change. Refer to HL7 Table 0523 - Computation Type for valid values.

2.A.19.4 Days Retained (NM)

Definition: The length of time in days that the value is retained for computing delta checks.

2.A.20 DR - date/time range

HL7 Component Table - DR - Date/Time Range

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

DTM O
Range Start Date/Time
2.A.22 DB
2

DTM O
Range End Date/Time
2.A.22 DB

Note: DR cannot be legally expressed when embedded within another data type. Its use is constrained to a segment field.

2.A.20.1 Range Start Date/Time (DTM)

Definition: The first component contains the earliest date/time (time stamp) in the specified range.

2.A.20.2 Range End Date/Time (DTM)

The second component contains the latest date/time in the specified range. Note that the DTM (time stamp) data type allows the specification of precision.

2.A.21 DT - date

HL7 Component Table - DT - Date

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.

(4..8) 8


Date

DB

Definition: Specifies the century and year with optional precision to month and day.

Minimum Length: 4

Maximum Length: 8

The number of digits populated specifies the precision using the format specification YYYY[MM[DD]]. Thus:

  1. only the first four digits are used to specify a precision of "year"

  2. the first six are used to specify a precision of "month"

  3. the first eight are used to specify a precision of "day"

Examples:

|19880704|

|199503|

The DT data type does not follow the normal truncation pattern, and the truncation character is never valid in the DT data type. Instead, the truncation behavior is based on the semantics of dates.

Unless specified in the context where the DT type is used, the DT type may not be truncated. When a DT is truncated, the truncated form SHALL still be a valid DT type. Systems should always be able to persist full dates. Refer to Chapter 2, section 2.5.5.2 "Truncation Pattern" for further information.

Note: Prior to v2.3, this data type was specified in the format YYYYMMDD. As of v2.3, month and days are no longer required. By site-specific agreement, YYYYMMDD may be used where backward compatibility must be maintained.

2.A.22 DTM - date/time

HL7 Component Table - DTM - Date/Time

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.

4..24 8#


Date/Time

DB

Definition: Specifies a point in time using a 24-hour clock notation.

Minimum Length: 4

Maximum Length: 24

The number of characters populated (excluding the time zone specification) specifies the precision.

Format: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ].

Thus:

only the first four are used to specify a precision of "year"

the first six are used to specify a precision of "month"

the first eight are used to specify a precision of "day"

the first ten are used to specify a precision of "hour"

the first twelve are used to specify a precision of "minute"

the first fourteen are used to specify a precision of "second"

the first sixteen are used to specify a precision of "one tenth of a second"

the first nineteen are used to specify a precision of " one ten thousandths of a second"

Example: |199904| specifies April 1999.

The time zone (+/-ZZZZ) is represented as +/-HHMM offset from Coordinated Universal Time (UTC) (formerly Greenwich Mean Time (GMT)), where +0000 or -0000 both represent UTC (without offset). The specific data representations used in the HL7 encoding rules are compatible with ISO 8824-1987(E).

Note that if the time zone is not included, the time zone defaults to that of the local time zone of the sender. Also note that a DTM valued field with the HHMM part set to "0000" represents midnight of the night extending from the previous day to the day given by the YYYYMMDD part (see example below). Examples:

Example Description
|19760704010159-0500| 1:01:59 on July 4, 1976 in the Eastern Standard Time zone (USA)
|19760704010159-0400| 1:01:59 on July 4, 1976 in the Eastern Daylight Saving Time zone (USA).
|198807050000| Midnight of the night extending from July 4 to July 5, 1988 in the local time zone of the sender.
|19880705| Same as prior example, but precision extends only to the day. Could be used for a birth date, if the time of birth is unknown.
|19981004010159+0100| 1:01:59 on October 4, 1998 in Amsterdam, NL. (Time zone=+0100).

The HL7 Standard strongly recommends that all systems routinely send the time zone offset but does not require it. All HL7 systems are required to accept the time zone offset, but its implementation is application specific. For many applications the time of interest is the local time of the sender. For example, an application in the Eastern Standard Time zone receiving notification of an admission that takes place at 11:00 PM in San Francisco on December 11 would prefer to treat the admission as having occurred on December 11 rather than advancing the date to December 12.

Note: The time zone [+/-ZZZZ], when used, is restricted to legally-defined time zones and is represented in HHMM format.

One exception to this rule would be a clinical system that processed patient data collected in a clinic and a nearby hospital that happens to be in a different time zone. Such applications may choose to convert the data to a common representation. Similar concerns apply to the transitions to and from daylight saving time. HL7 supports such requirements by requiring that the time zone information be present when the information is sent. It does not, however, specify which of the treatments discussed here will be applied by the receiving system.

The DTM data type does not follow the normal truncation pattern, and the truncation character is never valid in the DTM data type. Instead, the truncation behavior is based on the semantics of dates and times.

Unless otherwise specified in the context where the DTM type is used, the DTM type may be truncated to a day. When a DTM is truncated, the truncated form SHALL still be a valid DTM type. Systems should always be able to persist full date / time information including the timezone. Refer to Chapter 2, section 2.5.5.2 "Truncation Pattern" for further information.

2.A.23 DTN - day type and number

HL7 Component Table - DTN - Day Type and Number

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE R 0149 Day Type
2.A.36 DB
2
3# NM R
Number of Days
2.A.47 DB

Definition: This data type specifies the type and number of days for which a certification is valid.

Note: Replaces the CM data type used in section 6.5.8.11 IN3-11, as of v2.5.

2.A.23.1 Day Type (CWE)

Definition: Specifies whether the days are denied, pending, or approved.

Refer to User-defined Table 0149 - Day Type for suggested values.

2.A.23.2 Number of Days (NM)

Definition: Specifies the number of days for which the certification is valid.

2.A.24 ED - encapsulated data

HL7 Component Table - ED - Encapsulated Data

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

HD O
Source Application
2.A.33 DB
2 4..11
ID R 0834 Type of Data
2.A.35 DB
3
32= ID O 0291 Data Subtype
2.A.35 DB
4 1..6
ID R 0299 Encoding
2.A.35 DB
5

TX R
Data
2.A.79 DB

Definition: This data type transmits encapsulated data from a source system to a destination system. It contains the identity of the source system, the type of data, the encoding method of the data, and the data itself. This data type is similar to the RP (reference pointer) data type of Section 2.A.65, "RP - reference pointer," except that instead of pointing to the data on another system, it contains the data which is to be sent to that system.

2.A.24.1 Source Application (HD)

Definition: A unique name that identifies the system which was the source of the data. Identical format and restrictions as in reference pointer (see Section 2.A.65.2, "Application ID (HD)").

2.A.24.2 Type of Data (ID)

Definition: Identical to "type of data" component in the reference pointer (RP) data type. See Section 2.A.65.3, "Type of Data (ID)".

Refer to Imported Table 0834 - MIME Types for valid values.

2.A.24.3 Data Subtype (ID)

Definition: Identical to "subtype" component in the reference pointer (RP) data type. See Section 2.A.65.4, "Subtype (ID)".

Refer to External Table 0291 - Subtype of Referenced Data for valid values.

2.A.24.4 Encoding (ID)

Definition: The type of encoding used to represent successive octets of binary data as displayable ASCII characters. Refer to HL7 Table 0299 - Encoding for valid values.

2.A.24.5 Data (TX)

Definition: Displayable ASCII characters which constitute the data to be sent from source application to destination application. The characters are limited to the legal characters of the ST data type, as defined in Section 2.A.75, "ST - string data," and, if encoded binary, are encoded according to the method of Section 2.A.24.2, "Type of Data (ID)".

If the encoding component (see Section 2.A.24.4, "Encoding (ID)") = "A" (none), then the data component must be scanned before transmission for HL7 delimiter characters, and any found must be escaped by using the HL7 escape sequences defined in Section 2.7 - "Use of escape sequences in text fields." On the receiving application, the data field must be de-escaped after being parsed.

If the encoding component ED.4 does not equal "A", then, after encoding, the (encoded) data must be scanned for HL7 delimiter characters, and any found must be escaped by using the HL7 escape sequences. Only then can the component be added to the HL7 segment/message. On the receiving application, the data field must be de-escaped after being parsed out of the message before being decoded. This can be expressed as "encode", "escape", "parse", "de-escape" or "decode".

2.A.25 EI - entity identifier

HL7 Component Table - EI - Entity Identifier

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
199= ST O
Entity Identifier
2.A.75 DB
2
20= IS O 0363 Namespace ID
2.A.36 DB
3
199= ST C
Universal ID
2.A.75 DB
4 1..6
ID C 0301 Universal ID Type
2.A.35 DB

Definition: The entity identifier defines a given entity within a specified series of identifiers.

The EI is appropriate for, but not limited to, machine or software generated identifiers. The generated identifier goes in the first component. The remaining components, 2 through 4, are known as the assigning authority; they identify the machine/system responsible for generating the identifier in component 1.

The specified series, the assigning authority, is defined by components 2 through 4. The assigning authority is of the hierarchic designator (HD) data type, but it is defined as three separate components in the EI data type, rather than as a single component as would normally be the case. This is in order to maintain backward compatibility with the EI's use as a component in several existing data fields. Otherwise, the components 2 through 4 are as defined in Section 2.A.33, "HD - hierarchic designator". Hierarchic designators (HD) are unique across a given HL7 implementation.

2.A.25.1 Entity Identifier (ST)

Definition: The first component, <entity identifier>, is usually defined to be unique within the series of identifiers created by the <assigning authority>, defined by a hierarchic designator, represented by components 2 through 4. See Section 2.A.33, "HD - hierarchic designator".

2.A.25.2 Namespace ID (IS)

Definition: See Section 2.A.33.1, "Namespace ID (IS)" for definition. The component intentionally remains associated with the IS data type in v2.7.

The assigning authority is a unique identifier of the system (or organization or agency or department) that creates the data. Refer to User-defined Table 0363 - Assigning Authority for suggested values.

Note: When the HD is used as a part of another data type, in this case as part of the EI data type, this table may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment.

By site agreement, implementers may continue to use User-defined Table 0300 - Namespace ID for the first component

2.A.25.3 Universal ID (ST)

Definition: See Section 2.A.33.2, "Universal ID (ST)" for definition.

2.A.25.4 Universal ID Type (ID)

Definition: Refer to HL7 Table 0301 - Universal ID Type for valid values. See Section 2.A.33.3, "Universal ID Type (ID)," for definition.

2.A.26 EIP - entity identifier pair

HL7 Component Table - EIP - Entity Identifier Pair

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

EI O
Placer Assigned Identifier
2.A.25 DB
2

EI O
Filler Assigned Identifier
2.A.25 DB

Definition: Specifies an identifier assigned to an entity by either the placer or the filler system. If both components are populated the identifiers must refer to the same entity.

Note: Replaces the CM data type used in sections 4.5.1.8 - ORC-8, 4.5.3.29 - OBR-29, 7.3.1.29 - OBR-29, as of v 2.5.

2.A.26.1 Placer Assigned Identifier (EI)

Definition: Specifies an identifier assigned to an entity by the placer system.

For example, the component might be used to convey the following:

placer order number of the parent order.

the specimen identifier as assigned by the placer.

a location identifier assigned (or used by) the placer.

2.A.26.2 Filler Assigned Identifier (EI)

Definition: Specifies an identifier assigned to an entity by the filler system.

For example, the component might convey the following:

filler order number of the parent order.

the specimen identifier as assigned by the filler.

a location identifier assigned (or used by) the filler.

2.A.27 WITHDRAWN (ELD - error location and description)

Attention: The ELD data type was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7. Refer to ERR-2 and ERR-3 instead.

2.A.28 ERL - error location

HL7 Component Table - ERL - Error Location

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1 3..3 = ST R
Segment ID
2.A.75 DB
2
= NM R
Segment Sequence
2.A.47 DB
3
= NM O
Field Position
2.A.47 DB
4
= NM O
Field Repetition
2.A.47 DB
5
= NM O
Component Number
2.A.47 DB
6
= NM O
Sub-Component Number
2.A.47 DB

Definition: This data type identifies the segment and its constituent where an error has occurred.

2.A.28.1 Segment ID (ST)

Definition: Specifies the 3-letter name for the segment.

2.A.28.2 Segment Sequence (NM)

Definition: Identifies the segment occurrence within the message.

2.A.28.3 Field Position (NM)

Definition: Identifies the number of the field within the segment. The first field is assigned a number of 1. Field number should not be specified when referring to the entire segment.

2.A.28.4 Field Repetition (NM)

Definition: Identifies the repetition number of the field. The first repetition is counted as 1. If a Field Position is specified, but Field Repetition is not, Field Repetition should be assumed to be 1. If Field Position is not specified, Field Repetition should not be specified.

2.A.28.5 Component Number (NM)

Definition: Identifies the number of the component within the field. The first component is assigned a number of 1. Component number should not be specified when referring to the entire field.

2.A.28.6 Sub-Component Number (NM)

Definition: Identifies the number of the sub-component within the component. The first sub-component is assigned a number of 1. Sub-component number should not be specified when referring to the entire component.

2.A.29 FC - financial class

HL7 Component Table - FC- Financial Class

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE R 0064 Financial Class Code
2.A.36 DB
2

DTM O
Effective Date
2.A.22 DB

2.A.29.1 Financial Class Code (CWE)

Definition: This component contains the financial class assigned to a person. User-defined Table 0064 - Financial Class is used as the HL7 identifier for the user-defined table of values for this component.

2.A.29.2 Effective Date (DTM)

Definition: This component contains the effective date/time of the person's assignment to the financial class specified in the first component.

2.A.30 FN - family name

HL7 Component Table - FN - Family Name

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
50# ST R
Surname
2.A.75 DB
2
20# ST O
Own Surname Prefix
2.A.75 DB
3
50# ST O
Own Surname
2.A.75 DB
4
20# ST O
Surname Prefix from Partner/Spouse
2.A.75 DB
5
50# ST O
Surname from Partner/Spouse
2.A.75 DB

Definition: This data type allows full specification of the surname of a person. Where appropriate, it differentiates the person's own surname from that of the person's partner or spouse, in cases where the person's name may contain elements from either name. It also permits messages to distinguish the surname prefix (such as "van" or "de") from the surname root.

Note: Appears ONLY in the PPN, XCN and XPN.

2.A.30.1 Surname (ST)

Definition: The atomic element of the person's family name. In most Western usage, this is the person's last name.

2.A.30.2 Own Surname Prefix (ST)

Definition: Internationalization usage for Germanic languages. This component is optional. An example of a <surname prefix> is the "van" in "Ludwig van Beethoven". Since the <surname prefix> doesn't sort completely alphabetically, it is reasonable to specify it as a separate sub-component of the PN and extended PN data types (XPN and XCN).

Note: Subcomponents <own surname prefix>, <own surname>, <surname prefix from partner/spouse> and <surname from partner/spouse> decompose complex Germanic names such as "Martha de Mum-van Beethoven". If these subcomponents are valued, the <surname> subcomponent should still be fully valued for backward compatibility, i.e., ^de Mum-van Beethoven&de&Mum&van&Beethoven^. Also, for clarity, the <last name prefix> has been renamed to <own surname prefix>.

2.A.30.3 Own Surname (ST)

Definition: The portion of the surname (in most Western usage, the last name) that is derived from the person's own surname, as distinguished from any portion that is derived from the surname of the person's partner or spouse. This component is optional.

If the person's surname has legally changed to become (or incorporate) the surname of the person's partner or spouse, this is the person's surname immediately prior to such change. Often this is the person's "maiden name".

2.A.30.4 Surname Prefix from Partner/Spouse (ST)

Definition: Internationalization usage for Germanic languages. This component is optional. An example of a <surname prefix> is the "van" in "Ludwig van Beethoven". Since the <surname prefix> doesn't sort completely alphabetically, it is reasonable to specify it as a separate sub-component of the PN and extended PN data types (XPN and XCN).

Note: Subcomponents <own surname prefix>, <own surname>, <surname prefix from partner/spouse> and <surname from partner/spouse> decompose complex Germanic names such as "Martha de Mum-van Beethoven". If these subcomponents are valued, the <surname> subcomponent should still be fully valued for backward compatibility, i.e., ^de Mum-van Beethoven&de&Mum&van&Beethoven^." Also, for clarity, the <last name prefix> has been renamed to <own surname prefix>.

2.A.30.5 Surname from Partner/Spouse (ST)

Definition: The portion of the person's surname (in most Western usage, the last name) that is derived from the surname of the person's partner or spouse, as distinguished from the part derived from the person's own surname. This component is optional.

If no portion of the person's surname is derived from the surname of the person's partner or spouse, this component is not valued. Otherwise, if the surname of the partner or spouse has legally changed to become (or incorporate) the person's surname, this is the surname of the partner or spouse immediately prior to such change.

2.A.31 FT - formatted text data

HL7 Component Table - FT - Formatted Text Data

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.






Formatted Text Data

DB

Minimum Length: 1

Maximum Length:

Definition: This data type is derived from the TX data type by allowing the addition of embedded formatting instructions. These instructions are limited to those that are intrinsic and independent of the circumstances under which the field is being used. The actual instructions and their representation are described in section 2.7.6, "Usage and Examples of Formatted Text". The FT field is of arbitrary length (up to 64k) and may contain formatting commands enclosed in escape characters.

Example:

|\.sp\(skip one vertical line)|

For additional examples of formatting commands see Section 2.7, "Use of Escape Sequences in Text Fields".

To include alternative character sets, use the appropriate escape sequence. See Chapter 2, "Control", section 2.15.9.18, "Character set" and section 2.14.9.20, "Alternate character set handling scheme".

This specification applies no limit to the length of the FT data type, either here where the data type is defined, or elsewhere where the data type is used. While there is no intrinsic reason to limit the length of this data type for semantic or syntactical reasons, it is expected that some sort of limitation will be imposed for technical reasons in implementations. HL7 recommends that implementation length limits are published in implementation profiles. The contents of an FT field may be truncated, but the truncation pattern does not apply.

2.A.32 GTS - general timing specification

HL7 Component Table - GTS - General Timing Specification

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.


199=


General Timing Specification

DB

Definition: The General Timing Specification data type is used to communicate complex inter-related information Timing information. The value of such a field follows the formatting rules for a ST field. The string data will be structured according to the rules set forth in the "Version 3 Data Types Part II Unabridged Specification" for the General Timing Specification (GTS) data type.

Minimum Length: 1

Maximum Length:

There is no technical limit to the length of a GTS expression - the expression may be as long as logically required. The conformance length of 199 caters for all the common expressions. GTS expressions are not to be truncated.

2.A.33 HD - hierarchic designator

HL7 Component Table - HD - Hierarchic Designator

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
20= IS O 0300 Namespace ID
2.A.36 DB
2
199= ST C
Universal ID
2.A.75 DB
3 1..6
ID C 0301 Universal ID Type
2.A.35 DB

Definition: The basic definition of the HD is that it identifies an (administrative or system or application or other) entity that has responsibility for managing or assigning a defined set of instance identifiers (such as placer or filler number, patient identifiers, provider identifiers, etc.). This entity could be a particular health care application such as a registration system that assigns patient identifiers, a governmental entity such as a licensing authority that assigns professional identifiers or drivers' license numbers, or a facility where such identifiers are assigned.

The HD is designed to be a more powerful and more general replacement for the application identifier of HL7 versions 2.1 and 2.2. It adds two additional components, the <universal ID> and the <universal ID type> to the former application ID (which is renamed more generically to be the namespace ID).

In the case where an HD identifies an entity that assigns/creates instance identifiers such as a particular patient registration system, it defines an "assigning authority". In the case where an HD identifies a location where instance identifiers are given out (although they may be created by another entity at another location) such as a particular "department of motor vehicles office location," it defines an "assigning facility". These two different uses of the HD appear in many of the extended data types.

The "assigning authority" defined by the HD is similar in its role to the coding system (and version) part of the coded element data types: both identify a set of more discrete instance identifiers. The difference is that the set of HD-defined discrete instances contain identifiers of "real-world" things such as patient or clinical orders, while the coded element-defined set of discrete instances contains concept identifiers (codes).

The HD is designed to be used either as a local identifier (with only the <namespace ID> valued) or a publicly-assigned identifier, a UID (<universal ID> and <universal ID type> both valued). Syntactically, the HD is a group of two identifiers: a local identifier defined by the first component and a universal identifier defined by the second and third components. HDs that have defined third components (defined UID types) must have a second component that is unique within the series of IDs defined by that component.

Note: The HD is used in fields that in earlier versions of HL7 used the IS data type. Thus, a single component HD (only the first component valued) will look like a simple IS data type for older systems expecting a single component in the place of the HD data type.

If the first component for the HD data type is present, the second and third components are optional. If the third component is present, then the second must also be present (although in this case the first is optional). The second and third components must either both be valued (both non-null), or both be not valued (both null).

This means that if all three components of the HD are valued, the entity identified by the first component is the same as the entity identified by components two and three taken together. However, implementers may choose, by site agreement, to specify that if all three components of the HD are valued, the first component defines a member in the set defined by the second and third components.

Examples:

Example 1: ISO example with only the 2nd and 3rd components valued:

|^2.16.840.1.113883.19^ISO|

The syntax of the second component is defined by the ISO standard for object identifiers, not by HL7 (for which the second component is of the ST data type). Thus the periods (".") in the second component are part of the ISO syntax, and are legal by the definition of the HL7 ST data type.

Example 2: A UUID example

|^478A0114-EBF0-7701-A023-6841FF05731A^UUID|

Example 3: A DNS example

|^falcon.iupui.edu^DNS|

Local examples:

Example 4: Local use only: a HD that looks like an IS data type

|LAB1|

|RX.PIMS.SystemB.KP.CA.SCA|

Note that the syntax of the first component is not defined by HL7 but by the site according to its own needs: the only requirement is that the first component's structure is allowed by the HL7 string (ST) data type, which is used for values by the IS data type.

Example 5: Local identifier using components 2 and 3 only

|^RX.PIMS.SystemB.CA.SCA^M|

An alternate way to encode the previous example, illustrating the use of the third component value of "M" (see HL7 Table 0301 - Universal ID type below) to identify a locally-defined identifier set. The second component has the same value as the previous example but is now defined to be a member of a set of allowable values defined by a site for the identifier set "M".

Example 6: Local identifier with 2nd and 3rd components populated.

|PathLab^PL.UCF.UC^L|

The 'PathLab' application is identified by the namespace component but it is also identified by the 2nd and 3rd components, (i.e., by the locally-defined UID system "L"). The two identifiers are equivalent.

This is a more complex HD in which the middle component, which is locally defined, is itself structured. As with the ISO example above, the middle component's structure is not defined by HL7 but by the site according to its own needs: the only requirement is that the middle component's structure is allowed by the HL7 string (ST) data type.

Example 7: local identifier and universal ID types:

|LAB1^2.16.840.1.113883.19.1.2.3.3.4.6.7^ISO|

A HD with an ISO "object Identifier" as a UID and a locally defined system name. Both the first component and the second and third (taken together) refer to the same entity. This example shows that the local value and the universal ID value may be transmitted with a single HD field.

2.A.33.1 Namespace ID (IS)

Definition: The local coded item for the entity. The component intentionally remains associated with the IS data type in v2.7.

User-defined Table 0300 - Namespace ID is used as the HL7 identifier for the user-defined table of values for this component.

Note: When the HD is used in a given segment (either as a field or as a component of another data type) this table may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment.

2.A.33.2 Universal ID (ST)

Definition: The HD's second component, <universal ID> (UID), is a string formatted according to the scheme defined by the third component, <universal ID type> (UID type). The UID is intended to be unique over time within the UID type. It is rigorously defined. Each UID must belong to one of the specifically enumerated schemes for constructing UIDs (defined by the UID type). The UID (second component) must follow the syntactic rules of the particular universal identifier scheme (defined by the third component). Note that these syntactic rules are not defined within HL7 but are defined by the rules of the particular universal identifier scheme (defined by the third component).

2.A.33.3 Universal ID Type (ID)

Definition: The third component governs the interpretation of the second component of the HD. If the third component is a known UID refer to HL7 Table 0301 - Universal ID type for valid values, then the second component is a universal ID of that type.

2.A.34 ICD - insurance certification definition

HL7 Component Table - ICD - Insurance Certification Definition

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE O 0150 Certification Patient Type
2.A.36 DB
2 1..1
ID R 0136 Certification Required
2.A.35 DB
3

DTM O
Date/Time Certification Required
2.A.22 DB

Definition: This data type specifies whether insurance certification is required for particular patient types, and the time window for obtaining the certification.

Note: Replaces the CM data type used in section 6.5.8.20 IN3-20, as of v2.5.

2.A.34.1 Certification Patient Type (CWE)

Definition: Specifies the category or type of patient for which this certification is requested. Refer to User-defined Table 0150 - Certification patient type for suggested values.

2.A.34.2 Certification Required (ID)

Definition: Specifies whether or not a certification is required. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.

2.A.34.3 Date/Time Certification Required (DTM)

Definition: The date/time by which the certification must be obtained.

2.A.35 ID - coded value for HL7 defined tables

HL7 Component Table - ID - Coded Value for HL7 Defined Tables

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.

1.. 15=


Coded Value for HL7-Defined Tables

DB

Note: The Vocabulary TC is the steward of the ID data type.

Minimum Length: â?¥ 1- Varies - dependent on length of shortest code in code set.

Maximum Length: Varies - dependent on length of longest code in code set.

Definition: The value of such a field 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. An example of an ID field is OBR-25 Result Status. This data type should be used only for HL7 tables (see Chapter 2C, section 2.C.1.2, "HL7 Tables"). The reverse is not true, since in some circumstances it is more appropriate to use the CNE or CWE data type for HL7 tables.

The minimum and maximum lengths are specified in the context in which the ID data type is used. The longest HL7 defined legal value is 15 characters, but there are a few circumstances where the legal values are taken from code systems defined by other bodies (such as IANA mime types). In these cases, a different conformance length may be specified where the ID data type is used. It is never acceptable to truncate an ID value.

2.A.36 IS - coded value for user-defined tables

HL7 Component Table - IS - Coded Value for User-Defined Tables

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.

1.. 20=


Coded Value for User-Defined Tables

DB

Note: The Vocabulary TC is the steward of the IS data type.

Minimum Length: â?¥ 1- Varies - dependent on length of shortest code in code set.

Maximum Length: Varies - dependent on length of longest code in code set.

As of v2.7, the only approved use of the IS data type is in the HD.1, EI.2 and PL.6 plus a limited number of fields where a determination could not readily be made as to whether the item is an identifier or an actual coded item. Additionally, in accordance with chapter 2 rules, any field or data type component marked as "Retained for backward compatibility" will retain any IS data type.

The value of such a field 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. An example of an IS field is the Event reason code defined in Chapter 3, "Patient Administration", section 3.4.1.4, "Event reason code". This data type should be used only for user-defined tables (see Chapter 2C, "Code Tables", section 2.C.1.1, "User-defined Tables"). The reverse is not true, since in some circumstances, it is more appropriate to use the CWE data type for user-defined tables.

It is never acceptable to truncate an IS value.

2.A.37 JCC - job code/class

HL7 Component Table - JCC- Job Code/Class

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE O 0327 Job Code
2.A.36 DB
2

CWE O 0328 Job Class
2.A.36 DB
3

TX O
Job Description Text
2.A.79 DB

Example 1: Codified job (where 1 represents the code for Administrator and F represents full time)

|1^F^Administrator|

Example 2: Uncodified job (where job codes are not codified and PT represents part time)

|^PT^Analyst|.

2.A.37.1 Job Code (CWE)

Definition: This component contains the person's job code. User-defined Table 0327 - Job Code is used as the HL7 identifier for the user-defined table of values for this component.

2.A.37.2 Job Class (CWE)

Definition: This component contains the person's employee classification. Refer to User-defined Table 0328 - Employee Classification for suggested values.

2.A.37.3 Job Description Text (TX)

Definition: This component contains the text of the job description. This will accommodate systems where job descriptions are not codified.

2.A.38 LA1 - location with address variation 1

Attention: Retained for backward compatibility only in v2.6. Fields associated with this data type have been replaced by 4 new fields in the RXO and RXE segments.

HL7 Component Table - LA1 - Location with Address Variation 1

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
20= IS O 0302 Point of Care
2.A.36 DB
2
20= IS O 0303 Room
2.A.36 DB
3
20= IS O 0304 Bed
2.A.36 DB
4

HD O
Facility
2.A.33 DB
5
20= IS O 0306 Location Status
2.A.36 DB
6
20= IS O 0305 Patient Location Type
2.A.36 DB
7
20= IS O 0307 Building
2.A.36 DB
8
20= IS O 0308 Floor
2.A.36 DB
9

AD O
Address
2.A.1 DB

Definition: Specifies a location and its address.

Note: Replaces the CM data type used in 4.14.1.8 RXO-8 and 4.14.4.8 RXE-8 as of v 2.5. Retained for backward compatibility only as of v 2.5.

2.A.38.1 Point of Care (IS)

Definition: This component specifies the code for the point where patient care is administered. It is conditional on person location type (e.g., nursing unit or department or clinic). After floor, it is the most general patient location designation. Refer to User-defined Table 0302 - Point of Care for suggested values.

2.A.38.2 Room (IS)

Definition: This component specifies the code for the patient room. After point of care, it is the most general person location designation. Refer to User-defined Table 0303 - Room for suggested values.

2.A.38.3 Bed (IS)

Definition: This component specifies the code for the patient bed. After room, it is the most general person location designation. Refer to User-defined Table 0304 - Bed for suggested values.

2.A.38.4 Facility (HD)

Definition: This component is subject to site interpretation but generally describes the highest level physical designation of an institution, medical center or enterprise. It is the most general person location designation.

2.A.38.5 Location Status (IS)

Definition: This component specifies the code for the status or availability of the location. For example, it may convey bed status. Refer to User-defined Table 0306 - Location Status for suggested values.

2.A.38.6 Patient Location Type (IS)

Definition: Person location type is the categorization of the person's location defined by facility, building, floor, point of care, room or bed. Although not a required field, when used, it may be the only populated field. It usually includes values such as nursing unit, department, clinic, SNF, physician's office. Refer to User-defined Table 0305 - Person Location Type for suggested values.

2.A.38.7 Building (IS)

Definition: This component specifies the code for the building where the person is located. After facility, it is the most general person location designation. Refer to User-defined Table 0307 - Building for suggested values.

2.A.38.8 Floor (IS)

Definition: This component specifies the code for the floor where the person is located. After building, it is the most general person location designation. Refer to User-defined Table 0308 - Floor for suggested values.

2.A.38.9 Address (AD)

Definition: This component specifies the address of a location.

2.A.39 LA2 - location with address variation 2

Attention: Retained for backward compatibility only in v2.6. Fields associated with this data type have been replaced by 2 new fields in the RXD, RXG and RXA segments.

HL7 Component Table - LA2 - Location with Address Variation 2

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
20= IS O 0302 Point of Care
2.A.36 DB
2
20= IS O 0303 Room
2.A.36 DB
3
20= IS O 0304 Bed
2.A.36 DB
4

HD O
Facility
2.A.33 DB
5
20= IS O 0306 Location Status
2.A.36 DB
6
20= IS O 0305 Patient Location Type
2.A.36 DB
7
20= IS O 0307 Building
2.A.36 DB
8
20= IS O 0308 Floor
2.A.36 DB
9
20# ST O
Street Address
2.A.75 DB
10
120# ST O
Other Designation
2.A.75 DB
11
50# ST O
City
2.A.75 DB
12
50# ST O
State or Province
2.A.75 DB
13
12= ST O
Zip or Postal Code
2.A.75 DB
14 3..3
ID O 0399 Country
2.A.35 DB
15 1..3
ID O 0190 Address Type
2.A.35 DB
16
50# ST O
Other Geographic Designation
2.A.75 DB

Definition: Specifies a location and its address.

Note: Replaces the CM data type used in 4.14.5.13 RXD-13, 4.14.6.11 RXG-11 and 4.14.7.11 RXA-11 as of v 2.5. Retained for backward compatibility only as of v 2.5,

2.A.39.1 Point of Care (IS)

Definition: This component specifies the code for the point where patient care is administered. It is conditional on Patient Location Type (e.g., nursing unit or department or clinic). After floor, it is the most general patient location designation. Refer to User-defined Table 0302 - Point of Care for suggested values.

2.A.39.2 Room (IS)

Definition: This component specifies the code for the patient room. After point of care, it is the most general person location designation. Refer to User-defined Table 0303 - Room for suggested values.

2.A.39.3 Bed (IS)

Definition: This component specifies the code for the patient's bed. After room, it is the most general person location designation. Refer to User-defined Table 0304 - Bed for suggested values.

2.A.39.4 Facility (HD)

Definition: This component is subject to site interpretation but generally describes the highest level physical designation of an institution, medical center or enterprise. It is the most general person location designation.

2.A.39.5 Location Status (IS)

Definition: This component specifies the code for the status or availability of the location. For example, it may convey bed status. Refer to User-defined Table 0306 - Location Status for suggested values.

2.A.39.6 Patient Location Type (IS)

Definition: Patient location type is the categorization of the patient's location defined by facility, building, floor, point of care, room or bed. Although not a required field, when used, it may be the only populated field. It usually includes values such as nursing unit, department, clinic, SNF, physician's office. Refer to User-defined Table 0305 - Person Location Type for suggested values.

2.A.39.7 Building (IS)

Definition: This component specifies the code for the building where the person is located. After facility, it is the most general person location designation. Refer to User-defined Table 0307 - Building for suggested values.

2.A.39.8 Floor (IS)

Definition: This component specifies the code for the floor where the person is located. After building, it is the most general person location designation. Refer to User-defined Table 0308 - Floor for suggested values.

2.A.39.9 Street Address (ST)

Definition: This component specifies the street or mailing address of a person or institution. When referencing an institution, it is used to specify the institution name. When used in connection with a person, it specifies the first line of the address.

2.A.39.10 Other Designation (ST)

Definition: This component specifies the second line of an address. In general, it qualifies address. Examples: Suite 555 or Fourth Floor. When referencing an institution, this component specifies the street address.

2.A.39.11 City (ST)

Definition: This component specifies the city, or district or place where the person or institution is located depending upon the national convention for formatting addresses for postal usage. City should be represented by the official postal service codes for that state.

2.A.39.12 State or Province (ST)

Definition: This component specifies the state or province where the person or institution is located. State or province should be represented by the official postal service codes for that country.

2.A.39.13 Zip or Postal Code (ST)

Definition: This component specifies the zip or postal code where the person or institution is located. Zip or postal codes should be represented by the official codes for that country. In the US, the zip code takes the form 99999[-9999], while the Canadian postal code takes the form A9A9A9 and the Australian Postcode takes the form 9999.

2.A.39.14 Country (ID)

Definition: This component specifies the country where the person or institution is located. ISO 3166 provides a list of country codes that may be used. HL7 specifies that the 3-character (alphabetic) form of ISO 3166 be used for the country code. Refer to HL7 Table 0399 - Country Code in section 2.C.2.313 ISO-3166.

2.A.39.15 Address Type (ID)

Definition: This component specifies the kind or type of address. Refer to HL7 Table 0190 - Address Type for valid values.

2.A.39.16 Other Geographic Designation (ST)

Definition: This component specifies any other geographic designation that may be necessary. It includes county, bioregion, SMSA, etc.

2.A.40 MA - multiplexed array

HL7 Component Table - MA - Multiplexed Array

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

NM O
Sample Y From Channel 1
2.A.47 DB
2

NM O
Sample Y From Channel 2
2.A.47 DB
3

NM O
Sample Y From Channel 3
2.A.47 DB
4

NM O
Sample Y From Channel 4
2.A.47 DB
...







DB

Definition: This data type is used to represent channel-multiplexed waveform data. Assuming that fields that utilize this data type repeat and that Y represents the specific repetition, the components of the repetition will reflect sample Y from each channel.

Usage Note: The MA data type is preferred when the signal recording device outputs the waveform data by time (all signal amplitudes at time sample 1, followed by all signal amplitudes at time sample 2, followed by all signal amplitudes at time sample 3, etc.). The typical count is 32, 64, or 128 channels. At the time of this writing, the MA data type is the one used by most commercial EEG instruments, while other electrophysiological instruments (such as evoked potential instruments) may use the NA data type. The MA data type is the "natural" one for multi-channel EEG instruments since the signal acquisition process involves digitizing each channel in succession as rapidly as possible, then after a fixed interval (like 0.004 seconds) digitizing all the channels again in succession, and repeating this every 0.004 seconds as long as the recording continues.

Conversion of one format to another is often not possible or desirable in near-real-time applications. For example, a long-term EEG recording may go on for 24, 48, 72, or more hours and implementations cannot wait until the recording is ended to transmit the data because physicians need to review the waveforms as the recording is in progress; this is why it only makes sense to organize the data by the MA data type which sends the data one time sample after the next.

Note that, visually, the NA and MA data types are indistinguable: they both appear as a series of numeric components. They are distinguished by context, particularly when used in OBX.5 where the data type is specified in OBX.3.

Use Case: Commercial EEG instruments

Example 1: 3 channels (identical), 6 time-samples

|0^0^0~1^1^1~2^2^2~3^3^3~4^4^4~5^5^5|

Example 2: 1 channel, 11 time-samples

|0~1~2~3~4~5~6~7~8~9~10|

2.A.41 MO - money

HL7 Component Table - MO - Money

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
= NM O
Quantity
2.A.47 DB
2 3..3
ID O 0913 Denomination
2.A.35 DB

Definition: This data type specifies an amount of money and the denomination in which it is expressed.

2.A.41.1 Quantity (NM)

Definition: The first component is a quantity.

2.A.41.2 Denomination (ID)

Definition: The second component is the denomination in which the quantity is expressed. The values for the denomination component are the three-character codes specified in ISO-4217. See Externally-defined Table 0913 - Monetary Denomination Code.

If the denomination is not specified, "MSH-17-country code", in Chapter 2, section 2.14.9.17, is used to determine the default. Example,

|99.50^USD|

where USD is the ISO 4217 code for the U.S. American dollar.

2.A.42 MOC - money and charge code

HL7 Component Table - MOC - Money and Code

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

MO O
Monetary Amount
2.A.41 DB
2

CWE O
Charge Code
2.A.13 DB

Definition: Transmits monetary information and the associated charge code for services performed.

Note: Replaces the CM data type used in sections 4.5.3.23 OBR-23 and 7.4.1.23- OBR-23 as of v 2.5.

2.A.42.1 Monetary Amount (MO)

Definition: The amount and denomination of money associated with the charge code.

2.A.42.2 Charge Code (CWE)

Definition: The code identifying the charge to the ordering entity for the services performed.

2.A.43 MOP - money or percentage

HL7 Component Table - MOP - Money or Percentage

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

ID R 0148 Money or Percentage Indicator
2.A.35 DB
2
= NM R
Money or Percentage Quantity
2.A.47 DB
3 3..3
ID O 0913 Monetary Denomination
2.A.35 DB

Definition: This data type specifies an amount that may be either currency or a percentage. It is a variation on the MO data type that is limited to currency.

Note: Replaces the CM data type used in section 6.5.8.5 IN3-5, as of v 2.5. This data type is restricted to this field.

Example: USD is the ISO 4217 code for the U.S. American dollar.

|AT^99.50^USD|

2.A.43.1 Money or Percentage Indicator (ID)

Definition: Specifies whether the amount is currency or a percentage.

Refer to HL7 Table 0148 - Money or Percentage Indicator for valid values.

2.A.43.2 Money or Percentage Quantity (NM)

Definition: Specifies the currency or percentage quantity.

2.A.43.3 Currency Denomination (ID)

Definition: the denomination in which the quantity is expressed where the amount is currency. The values for the denomination component are the three-character codes specified in ISO-4217. See Externally-defined Table 0913 - Monetary Denomination Code.

If the denomination is not specified, the context of the message or MSH-17 Country Code, in Chapter 2, section 2.14.9.17, is used to determine the default.

2.A.44 MSG - message type

HL7 Component Table - MSG - Message Type

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1 3..3
ID R 0076 Message Code
2.A.35 DB
2 3..3
ID R 0003 Trigger Event
2.A.35 DB
3 3,7
ID R 0354 Message Structure
2.A.35 DB

Definition: This field contains the message type, trigger event, and the message structure ID for the message.

Note: Replaces the CM data type used in 2.16.9.9 MSH-9 as of v 2.5.

2.A.44.1 Message Code (ID)

Definition: Specifies the message type code. Refer to HL7 Table 0076- Message Type for valid values.

This table contains values such as ACK, ADT, ORM, ORU etc.

See Chapter 2, "Control", section 2.5.1, "Messages" for further discussion.

2.A.44.2 Trigger Event (ID)

Definition: Specifies the trigger event code. Refer to HL7 Table 0003- Event Type for valid values.

This table contains values like A01, O01, R01 etc.

See Chapter 2, "Control", section 2.3.1, "Trigger Events" for further discussion.

2.A.44.3 Message Structure (ID)

Definition: Specifies the abstract message structure code. Refer to HL7 Table 0354 - Message Structure for valid values.

2.A.45 NA - numeric array

HL7 Component Table - NA - Numeric Array

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

NM O
Value1
2.A.47 DB
2

NM O
Value2
2.A.47 DB
3

NM O
Value3
2.A.47 DB
4

NM O
Value4
2.A.47 DB
...







DB

Definition: This data type is used to represent a series (array) of numeric values. A field of this type may contain a one-dimensional array (vector or row) of numbers. Also, by allowing the field to repeat, a two-dimensional array (table) of numbers may be transmitted using this format, with each row of the table represented as one repetition of the field. Arrays that have one or more values not present may be transmitted using this data type. "Not present" values are represented as two adjacent component delimiters. If the absent values occur at the end of a row, the trailing component delimiters may be omitted. If an entire row of a table has no values, no component delimiters are necessary (in this case, there will be two adjacent repetition delimiters).

Example 1: vector of 8 numbers

|125^34^-22^-234^569^442^-212^6|

Example 2: 3 x 3 array of numbers

|1.2^-3.5^5.2~2.0^3.1^-6.2~3.5^7.8^-1.3|

Example 3: 5 x 4 array of numbers with the values in positions (1,1), (2,2), (2,3), (3,3), (3,4), (4,1), (4,2), (4,3), and (4,4) not present

|^2^3^4~5^^^8~9^10~~17^18^19^20|

2.A.46 NDL - name with date and location

Attention: Retained for backward compatibility only in v2.6. Fields associated with this data type have been replaced by the ROL segment.

HL7 Component Table - NDL - Name with Date and Location

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CNN O
Name
2.A.9 DB
2

DTM O
Start Date/time
2.A.22 DB
3

DTM O
End Date/time
2.A.22 DB
4
20= IS O 0302 Point of Care
2.A.36 DB
5
20= IS O 0303 Room
2.A.36 DB
6
20= IS O 0304 Bed
2.A.36 DB
7

HD O
Facility
2.A.33 DB
8
20= IS O 0306 Location Status
2.A.36 DB
9
20= IS O 0305 Patient Location Type
2.A.36 DB
10
20= IS O 0307 Building
2.A.36 DB
11
20= IS O 0308 Floor
2.A.36 DB

Definition: Specifies the name of the person performing a service, when the person performed the service and where the person performed the service. Retained for backward compatibility as of v2.6.

Note: Replaces the CM data type used in sections 4.5.3.32 and 7.4.1.32-( OBR-32), 4.5.3.33 and 7.4.1.33 - ( OBR-33) 4.5.3.34 and 7.4.1.34 - ( OBR-34) 4.5.3.35 and 7.4.1.35 - ( OBR-35) as of v 2.5.

2.A.46.1 Name (CNN)

Definition: This component specifies the name of the person performing a service.

2.A.46.2 Start date/time (DTM)

Definition: This component specifies the starting date and time for when the person is performing the service.

2.A.46.3 End Date/time (DTM)

Definition: This component specifies the ending date and time for when the person is performing the service.

2.A.46.4 Point of Care (IS)

Definition: This component specifies the code for the point where patient care is administered. It is conditional on NDL.9 - Patient Location Type (e.g., nursing unit or department or clinic). After floor, it is the most general patient location designation. Refer to User-defined Table 0302 - Point of care for suggested values.

2.A.46.5 Room (IS)

Definition: Patient room. After point of care, it is the most general location designation. Refer to User-defined Table 0303 - Room for suggested values.

2.A.46.6 Bed (IS)

Definition: This component specifies the code for the patient's bed. After room, it is the most general location designation. Refer to User-defined Table 0304 - Bed for suggested values.

2.A.46.7 Facility (HD)

Definition: This component is subject to site interpretation but generally describes the highest level physical designation of an institution, medical center or enterprise. It is the most general location designation.

2.A.46.8 Location Status (IS)

Definition: This component specifies the code for the status or availability of the location. For example, it may convey bed status. Refer to User-defined Table 0306 - Location Status for suggested values.

2.A.46.9 Patient Location Type (IS)

Definition: Location type is the categorization of the location defined by facility, building, floor, point of care, room or bed. Although not a required field, when used, it may be the only populated field. Usually includes values such as nursing unit, department, clinic, SNF, physician's office. Refer to User-defined Table 0305 - Person Location Type for suggested values.

2.A.46.10 Building (IS)

Definition: This component specifies the code for the building where the person is located. After facility, it is the most general location designation. Refer to User-defined Table 0307 - Building for suggested values.

2.A.46.11 Floor (IS)

Definition: This component specifies the code for the floor where the person is located. After building, it is the most general location designation. Refer to User-defined Table 0308 - Floor for suggested values.

2.A.47 NM - numeric

HL7 Component Table - NM - Numeric

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.

1..16



Numeric

DB

Definition: A number represented as a series of ASCII numeric characters consisting of an optional leading sign (+ or -), the digits and an optional decimal point. In the absence of a sign, the number is assumed to be positive. If there is no decimal point the number is assumed to be an integer.

Minimum Length: 1

Maximum Length: 16

Examples:

|999|

|-123.792|

Leading zeros, or trailing zeros after a decimal point, are not significant. For example, the following two values with different representations, "01.20" and "1.2," are identical. Except for the optional leading sign (+ or -) and the optional decimal point (.), no non-numeric ASCII characters are allowed. Thus, the value <12 should be encoded as a structured numeric (SN) (preferred) or as a string (ST) (allowed, but not preferred) data type.

The NM data type does not follow the normal truncation pattern, and the truncation character is never valid in the NM data type. Instead, the truncation behavior is based on the semantics of numbers.

Values of type NM may always have leading zeros truncated. Note that HL7 recommends that leading zeros not be used. Unless NM is used to represent a monetary amount, implementations may truncate trailing zeros after the decimal point up to the first non-zero digit or the decimal point, which ever comes first. Any digits to the left of the decimal point may never be truncated (other than leading zeros).

Example: 1.0200 may be truncated to 1.02, but not to 1.0.

2.A.48 NR - numeric range

HL7 Component Table - NR - Numeric Range

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

NM O
Low Value
2.A.47 DB
2

NM O
High Value
2.A.47 DB

Definition: Specifies the interval between the lowest and the highest values in a series of data. In the case where a numeric range is unbounded on one side, the component of the unbounded side is null. Whether the end points are included in the range is defined in the usage note for the field.

Note: Replaces the CM data type used in sections 8.8.4.6.1- OM2-6.1, 8.8.4.6.3- OM2-6.3and 8.8.4.6.4- OM2-6.4, as of v 2.5.

2.A.48.1 Low Value (NM)

Definition: The number specifying the lower limit or boundary of the range.

2.A.48.2 High Value (NM)

Definition: The number specifying the high limit or boundary of the range.

2.A.49 OCD - occurrence code and date

HL7 Component Table - OCD - Occurrence Code and Date

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CNE R 0350 Occurrence Code
2.A.8 DB
2
8= DT R
Occurrence Date
2.A.21 DB

Definition: The code and associated date defining a significant event relating to a bill that may affect payer processing.

Note: Replaces the CM data type used in sections 6.5.10.10 UB1-16 and 6.5.11.7 UB2-7, as of v 2.5.

This data type carries data defined by CMS or other regulatory agencies. It corresponds to UB82 Fields 28-32 and UB92 fields 32a, 32b, 33a, 33b, 34a, 34b, 35a, and 35b. Refer to a UB specification for additional information.

Use Case: A Medicare beneficiary was confined in hospital from January 1, 1992 to January 10, 1992, however, his Medicare Part A benefits were exhausted as of January 8, 1992, and he was not entitled to Part B benefits. Therefore, Form Locator 32 should contain code 23 and the date 010892.

Example:

|23&Benefits Exhausted&NUBC^19920108|

2.A.49.1 Occurrence Code (CNE)

Definition: The NUBC code for the event or occurrence relating to a bill that may affect payer processing.

Refer to HL7-defined Table 0350 - Occurrence Code for valid values.

Values for this component need to come from National Uniform Billing Committee (NUBC). No extensions are allowed.

2.A.49.2 Occurrence Date (DT)

Definition: The date the event, relating to a bill that may affect payer processing, occurred.

2.A.50 Withdrawn (OSD - order sequence definition)

Attention: The OSD data type was retained for backward compatibility only as of v2.5 and the detail was withdrawn and removed from the standard as of v 2.7. The reader is referred to the TQ1 and TQ2 segments for sequencing levels.

2.A.51 OSP - occurrence span code and date

HL7 Component Table - OSP - Occurrence Span Code and Date

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CNE R 0351 Occurrence Span Code
2.A.8 DB
2
8= DT C
Occurrence Span Start Date Either start or stop date or both must be present. 2.A.21 DB
3
8= DT C
Occurrence Span Stop Date Either start or stop date or both must be present. 2.A.21 DB

Definition: A code and the related dates that identify an event that relates to the payment of the claim. For example, Prior Stay Dates which is the from/through dates given by the patient of any hospital stay that ended within 60 days of this hospital or SNF admission.

Note: Replaces the CM data type used in section 6.5.11.8 UB2-8, as of v 2.5.

Use case: The patient was admitted for minor surgery (1/6/03) and discharged the following day (1/7/03). Complications ensured and the patient was readmitted the following day (1/8/03). When the claim for 1/8/03 is filed, the prior stay dates (1/6/03-1/7/03) must be reported (per the Health Plan) using Occurrence Span Code and Dates 71 - Prior Stay Date. Example:

|71&Prior Stay Date&NUBC^20030106^20030107|

2.A.51.1 Occurrence Span Code (CNE)

Definition: The NUBC code itself that identifies an event that relates to the payment of a claim.

Refer to HL7 Table 0351 - Occurrence Span for valid values. Values for this component need to come from National Uniform Billing Committee (NUBC). No extensions are allowed.

2.A.51.2 Occurrence Span Start Date (DT)

Definition: The date an event started that relates to the payment of a claim.

2.A.51.3 Occurrence Span Stop Date (DT)

Definition: The date an event ended that relates to the payment of a claim.

2.A.52 PIP - practitioner institutional privileges

HL7 Component Table - PIP - Practitioner Institutional Privileges

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE R 0525 Privilege
2.A.13 DB
2

CWE O 0526 Privilege Class
2.A.13 DB
3
8= DT O
Expiration Date
2.A.21 DB
4
8= DT O
Activation Date
2.A.21 DB
5

EI O
Facility
2.A.25 DB

Definition: This data type specifies the institutional privileges with associated detail granted to a provider.

Note: Replaces the CM data type used in 15.4.5.7 PRA-7 as of v 2.5.

2.A.52.1 Privilege (CWE)

Definition: Specifies the institutional privilege itself. Refer to User-defined Table 0525 - Privilege for suggested values.

2.A.52.2 Privilege Class (CWE)

Definition: Specifies the class category of institutional privilege. Refer to User-defined Table 0526 - Privilege Class for suggested values.

2.A.52.3 Expiration Date (DT)

Definition: Specifies the date the institutional privilege is/was no longer valid.

2.A.52.4 Activation Date (DT)

Definition: Specifies the date the institutional privilege became/becomes valid.

2.A.52.5 Facility (EI)

Definition: Specifies the facility in which the institutional privilege is/was valid.

2.A.53 PL - person location

HL7 Component Table - PL- Person Location

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

HD C 0302 Point of Care
2.A.36 DB
2

HD O 0303 Room
2.A.36 DB
3

HD O 0304 Bed
2.A.36 DB
4

HD O
Facility
2.A.33 DB
5
20= IS O 0306 Location Status
2.A.36 DB
6
20= IS O 0305 Person Location Type
2.A.36 DB
7

HD O 0307 Building
2.A.36 DB
8

HD O 0308 Floor
2.A.36 DB
9
199# ST O
Location Description
2.A.75 DB
10

EI O
Comprehensive Location Identifier
2.A.25 DB
11

HD O 0363 Assigning Authority for Location
2.A.33 DB

Definition: This data type is used to specify a patient location within a healthcare institution. Which components are valued depends on the needs of the site. For example for a patient treated at home, only the person location type is valued. It is most commonly used for specifying patient locations, but may refer to other types of locations within a healthcare setting.

Note: This data type contains several location identifiers that should be thought of in the following order from the most general to the most specific: facility, building, floor, point of care, room, bed. Additional data about any location defined by these components can be added in the following components: person location type, location description and location status.

Example: Nursing Unit

A nursing unit at Community Hospital: 4 East, room 136, bed B

4E^136^B^CommunityHospital^^N^^^

Example: Clinic

A clinic at University Hospitals: Internal Medicine Clinic located in the Briones building, 3rd floor.

InternalMedicine^^^UniversityHospitals^^C^Briones^3^

Example: Home

The patient was treated at his home.

^^^^^H^^^

2.A.53.1 Point of Care (HD)

Definition: This component specifies the code for the point where patient care is administered. It is conditional on PL.6 Person Location Type (e.g., nursing unit or department or clinic). After floor, it is the most general patient location designation. Refer to User-defined Table 0302 - Point of Care for suggested values.

2.A.53.2 Room (HD)

Definition: This component specifies the code for the patient's room. After point of care, it is the most general person location designation. Refer to User-defined Table 0303 - Room for suggested values.

2.A.53.3 Bed (HD)

Definition: This component specifies the code for the patient's bed. After room, it is the most general person location designation. Refer to User-defined Table 0304 - Bed for suggested values.

2.A.53.4 Facility (HD)

Definition: This component is subject to site interpretation but generally describes the highest level physical designation of an institution, medical center or enterprise. It is the most general person location designation.

See Section 2.A.33, "HD - hierarchic designator" for discussion of data type.

Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component) may be redefined (given a different user-defined table number and name) by the technical committee responsible for that segment.

2.A.53.5 Location Status (IS)

Definition: This component specifies the code for the status or availability of the location. For example, it may convey bed status. Refer to User-defined Table 0306 - Location Status for suggested values.

2.A.53.6 Person Location Type (IS)

Definition: Person location type is the categorization of the person's location defined by facility, building, floor, point of care, room or bed. Although not a required field, when used, it may be the only populated field. It usually includes values such as nursing unit, department, clinic, SNF, physician's office. Refer to User-defined Table 0305 - Person location type for suggested values.

2.A.53.7 Building (HD)

Definition: This component specifies the code for the building where the person is located. After facility, it is the most general person location designation. Refer to User-defined Table 0307 - Building for suggested values.

2.A.53.8 Floor (HD)

Definition: This component specifies the code for the floor where the person is located. After building, it is the most general person location designation. Refer to User-defined Table 0308 - Floor for suggested values.

2.A.53.9 Location Description (ST)

Definition: This component describes the location in free text.

2.A.53.10 Comprehensive Location Identifier (EI)

Definition: The unique identifier that represents the physical location as a whole without regard for the individual components. This accommodates sites that may have a different method of defining physical units or who may code at a less granular level. For example, point of care, room, and bed may be 1 indivisible code.

2.A.53.11 Assigning Authority for Location (HD)

Definition: The entity that creates the data for the individual physical location components. If populated, it should be the authority for all components populated. Refer to User-defined Table 0363 - Assigning Authority for suggested values for the first sub-component of the HD component, <namespace ID>.

This component makes it possible for codes to be differentiated when the field in which this data type is used repeats.

Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component) may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment.

By site agreement, implementors may continue to use User-defined Table 0300 - Namespace ID for the first sub-component.

2.A.54 PLN - practitioner license or other Id number

HL7 Component Table - PLN - Practitioner License or Other ID Number

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
20= ST R
ID Number
2.A.75 DB
2

CWE R 0338 Type of ID Number
2.A.36 DB
3
62# ST O
State/other Qualifying Information
2.A.75 DB
4
8= DT O
Expiration Date
2.A.21 DB

Definition: This data type specifies a practitioner's license number, or other ID number such as UPIN, Medicare and Medicaid number, and associated detail.

Note: Replaces the CM data type used in 15.4.5.6 PRA-6, 11.6.3.7 PRD-7 and 11.6.4.7 CTD-7 as of v 2.5.

2.A.54.1 ID Number (ST)

Definition: Specifies the license number or other ID number such as UPIN, Medicare and Medicaid number.

2.A.54.2 Type of ID Number (CWE)

Definition: Specifies the type of number.

Refer to User-defined Table 0338 - Practitioner ID Number Type for suggested values.

2.A.54.3 State/other Qualifying Information (ST)

Definition: Specifies the state or province in which the license or ID is valid, if relevant, or other qualifying information. It is recommended that state qualifications use the abbreviations from the postal service of the country.

2.A.54.4 Expiration date (DT)

Definition: Specifies the date when the license or ID is no longer valid.

2.A.55 PPN - performing person time stamp

HL7 Component Table - PPN - Performing Person Time Stamp

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
15= ST O
Person Identifier
2.A.75 DB
2

FN O
Family Name
2.A.30 DB
3
30# ST O
Given Name
2.A.75 DB
4
30# ST O
Second and Further Given Names or Initials Thereof
2.A.75 DB
5
20# ST O
Suffix (e.g., JR or III)
2.A.75 DB
6
20# ST O
Prefix (e.g., DR)
2.A.75 DB
7


W
Degree (e.g., MD) Withdrawn as of v2.7 2.A.36 DB
8

CWE B 0297 Source Table
2.A.36 DB
9

HD C 0363 Assigning Authority
2.A.33 DB
10 1..5
ID O 0200 Name Type Code
2.A.35 DB
11
4= ST O
Identifier Check Digit
2.A.75 DB
12 3..3
ID C 0061 Check Digit Scheme
2.A.35 DB
13 1..5
ID O 0203 Identifier Type Code
2.A.35 DB
14

HD O
Assigning Facility
2.A.33 DB
15

DTM O
Date/Time Action Performed
2.A.22 DB
16 1..1
ID O 0465 Name Representation Code
2.A.35 DB
17

CWE O 0448 Name Context
2.A.13 DB
18


W
Name Validity Range withdrawn as of v2.7. 2.A.20 DB
19 1..1
ID O 0444 Name Assembly Order
2.A.35 DB
20

DTM O
Effective Date
2.A.22 DB
21

DTM O
Expiration Date
2.A.22 DB
22
199# ST O
Professional Suffix
2.A.75 DB
23

CWE O
Assigning Jurisdiction
2.A.13 DB
24

CWE O
Assigning Agency or Department
2.A.13 DB
25
4= ST O
Security Check
2.A.74 DB
26 3..3
ID O 0904 Security Check Scheme
2.A.35 DB

This data type is the equivalent of an XCN data type joined with a DTM data type. However, the XCN data type has been flattened to allow legal expression of its embedded complex data types HD, CWE and CWE.

2.A.55.1 Person Identifier (ST)

Definition: This component carries the Person Identifier itself. PPN.1, in conjunction with PPN.9, uniquely identifies the entity/person.

2.A.55.2 Family Name (FN)

Definition: This component allows full specification of the surname of a person. Where appropriate, it differentiates the person's own surname from that of the person's partner or spouse, in cases where the person's name may contain elements from either name. It also permits messages to distinguish the surname prefix (such as "van" or "de") from the surname root. See section 2.A.30, "FN - Family Name".

2.A.55.3 Given Name (ST)

Definition: First name.

2.A.55.4 Second and Further Given Names or Initials Thereof (ST)

Definition: Multiple middle names may be included by separating them with spaces.

2.A.55.5 Suffix (ST)

Definition: Used to specify a name suffix (e.g., Jr. or III).

2.A.55.6 Prefix (ST)

Definition: Used to specify a name prefix (e.g., Dr.).

2.A.55.7 Degree

Attention: The PPN.7 component was deprecated as of v2.5 and the detail was withdrawn and removed from the standard as of v2.7 See PPN.22 - Professional Suffix.

2.A.55.8 Source Table (CWE)

Attention: Retained for backwards compatibility only as of v2.7. The reader is referred to PPN.9 instead.

User-defined Table 0297 - CN ID Source is used as the HL7 identifier for the user-defined table of values for this component. Used to delineate the first component.

2.A.55.9 Assigning Authority (HD)

Definition: The assigning authority is a unique identifier of the system (or organization or agency of department) that creates the data. It is a HD data type. User-defined Table 0363 - Assigning Authority is used as the HL7 identifier for the user-defined table of values for the first sub-component of the HD component, <namespace ID>.

Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component) may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment.

By site agreement, implementors may continue to use User-defined Table 0300 - Namespace ID for the first sub-component.

Attention: As of v2.7, the Assigning Authority is conditional. It is required if PPN.1 is populated and neither PPN.23 nor PPN.24 are populated. All 3 components may be populated. No assumptions can be safely made based on position or sequence. Best practice is to send an OID in this component when populated.

The reader is referred to the PPN.23 and the PPN.24 if there is a need to transmit values with semantic meaning for an assigning jurisdiction or assigning department or agency in addition to, or instead of, an assigning authority. However, all 3 components may be valued. If, in so doing, it is discovered that the values in PPN.23 and/or PPN.24 conflict with PPN.9, the user would look to the Message Profile or other implementation agreement for a statement as to which takes precedence.

2.A.55.10 Name Type Code (ID)

Definition: A code that represents the type of name. Refer to HL7 Table 0200 - Name Type for valid values (see Section 2.A.89, "XPN - extended person name").

2.A.55.11 Identifier Check Digit (ST)

Definition: A digit, or digits, exclusive of the identifier in CX.1, calculated by applying an algorithm to all or some of the digits in the number, which may be used to test validity of the non-check-digit identifier.

2.A.55.12 Check Digit Scheme (ID)

Definition: Contains the code identifying the check digit scheme employed.

Refer to HL7 Table 0061 - Check Digit Scheme for valid values.

2.A.55.13 Identifier Type Code (ID)

Definition: A code corresponding to the type of identifier. In some cases, this code may be used as a qualifier to the "Assigning authority" component. Refer to HL7 Table 0203 - Identifier Type for suggested values.

2.A.55.14 Assigning Facility (HD)

Definition: The place or location identifier where the identifier was first assigned to the patient. This component is not an inherent part of the identifier but rather part of the history of the identifier: as part of this data type, its existence is a convenience for certain intercommunicating systems.

Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component) may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment.

2.A.55.15 Date/Time Action Performed (DTM)

This component describes when the activity was performed.

Note: If this field is not null, both the performing person and the time stamp must be valued.

2.A.55.16 Name Representation Code (ID)

Definition: Different name/address types and representations of the same name/address should be described by repeating of this field, with different values of the Name/Address Type and/or Name/Address Representation component.

Note: This new component remains in "alphabetic" representation with each repetition of the field using these data types. That is, even though the name may be represented in an ideographic character set, this component will remain represented in an alphabetic character set.

In general this component provides an indication of the representation provided by the data item. It does not necessarily specify the character sets used. Thus, even though the representation might provide an indication of what to expect, the sender is still free to encode the contents using whatever character set is desired. This component provides only hints for the receiver, so it can make choices regarding what it has been sent and what it is capable of displaying.

2.A.55.17 Name Context (CWE)

Definition: This component is used to designate the context in which a name is used. The main use case is in Australian healthcare: indigenous patients who prefer to use different names when attending different healthcare institutions. Another use case occurs in the US where health practitioners can be licensed under slightly different names and the reporting of the correct name is vital for administrative purposes. Refer to chapter 3, section 3.4.2.6 for more detailed information on how to use this table. Refer to User-defined Table 0448 - Name Context for suggested values.

2.A.55.18 Name Validity Range

Attention: The PPN.18 component was deprecated as of v2.5 and the detail was withdrawn and removed from the standard as of v 2.7. Refer to PPN.20 Effective Date and PPN.21 Expiration Date.

2.A.55.19 Name Assembly Order (ID)

Definition: A code that represents the preferred display order of the components of this person name. Refer to HL7 Table 0444 - Name Assembly Order for valid values.

2.A.55.20 Effective Date (DTM)

Definition: The first date, if known, on which the person name is valid and active.

2.A.55.21 Expiration Date (DTM)

Definition: The last date, if known, on which the person name is valid and active.

2.A.55.22 Professional Suffix (ST)

Definition: Used to specify an abbreviation, or a string of abbreviations, denoting qualifications that support the person's profession, (e.g., licenses, certificates, degrees, affiliations with professional societies, etc.). The Professional Suffix normally follows the Family Name when the Person Name is used for display purposes. Please note that this component is an unformatted string and is used for display purposes only. Detailed information regarding the contents of Professional Suffix is obtained using appropriate segments in Chapter 15, "Personnel Management".

2.A.55.23 Assigning Jurisdiction (CWE)

Definition: The geo-political body that assigned the identifier in component 1.

See section 2.A.14.9, "Assigning Jurisdiction (CWE)" for further detail.

2.A.55.24 Assigning Agency or Department (CWE)

Definition: The agency or department that assigned the identifier in component 1.

See section 2.A.14.10, "Assigning Agency or Department (CWE)" for further details.

2.A.55.25 Security Check (ST)

Definition: This component is used to communicate a version code that may be assigned to the value given in PPN.1 - Person Identifier.

2.A.55.26 Security Check Scheme (ID)

Definition: This component is used to transmit information intended to validate the veracity of the supplied identifier or the presenter of the identifier. For example, this component may be used to ensure that the presenter of a credit card is an authorized user of that card.

Refer to HL7 Table 0904 - Security Check Scheme for valid values.

2.A.56 PRL - parent result link

HL7 Component Table - PRL - Parent Result Link

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE R
Parent Observation Identifier Defined in the OBX-3 of the parent result. 2.A.13 DB
2
20= ST O
Parent Observation Sub-identifier Defined in the OBX-4 of the parent result. 2.A.75 DB
3

TX O
Parent Observation Value Descriptor Taken from the OBX-5 of the parent result. 2.A.79 DB

Definition: Uniquely identifies the parent result's OBX segment related to the current order, together with the information in OBR-29 - Parent.

Usage Note: This data type is applied only to OBR-26 - Parent Result where it serves to make information available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29 - Parent, uniquely identifies the parent result's OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports. For example, if the current battery is an antimicrobial susceptibility, the parent results identified OBX contains a result that identifies the organism on which the susceptibility was run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization.

We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs.

This field is present only when the parent result is identified by OBR-29 - Parent and the parent spawns child orders for each of many results. See Chapter 7, "Observations", for more details about this linkage.

Note: Replaces the CM data type used in sections 4.5.3.26 - OBR-26 and 7.4.1.26 - OBR-26 as of v 2.5.

2.A.56.1 Parent Observation Identifier (CWE)

Definition: Contains the unique identifier of the parent observation as defined in the OBX-3 of the parent result. The value is the same as the OBX-3 of the parent.

2.A.56.2 Parent Observation Sub-identifier (ST)

Definition: Contains the sub-ID of the parent result as defined in the OBX-4 of the parent result. The value is the same as the OBX-4 of the parent.

2.A.56.3 Parent Observation Value Descriptor (TX)

Definition: Contains a descriptor of the parent observation value as specified in the OBX-5 of the parent result.

As an example, the third component may be used to record the name of the microorganism identified by the parent result directly. The organism in this case should be identified exactly as it is in the parent culture.

2.A.57 PT - processing type

HL7 Component Table - PT - Processing Type

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1 1..1
ID R 0103 Processing ID
2.A.35 DB
2 1..1
ID O 0207 Processing Mode
2.A.35 DB

Definition: This data type indicates whether to process a message as defined in HL7 Application (level 7) Processing rules.

2.A.57.1 Processing ID (ID)

Definition: A value that defines whether the message is part of a production, training, or debugging system. Refer to HL7 Table 0103 - Processing ID for valid values.

2.A.57.2 Processing Mode (ID)

Definition: A value that defines whether the message is part of an archival process or an initial load. Refer to HL7 Table 0207 - Processing Mode for valid values.

2.A.58 PTA - policy type and amount

HL7 Component Table - PTA - Policy Type and Amount

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE R 0147 Policy Type
2.A.36 DB
2

CWE O 0193 Amount Class
2.A.36 DB
3


W
Money or Percentage Quantity Withdrawn as of v2.7. 2.A.47 DB
4

MOP R
Money or Percentage
2.A.43 DB

Definition: This data type specifies the policy type and amount covered by the insurance.

Note: Replaces the CM data type used in section 6.5.7.29 IN2-29, as of v 2.5.

2.A.58.1 Policy Type (CWE)

Definition: Specifies the policy type.

Refer to User-defined Table 0147 - Policy Type for suggested values.

2.A.58.2 Amount Class (CWE)

Definition: Specifies the amount quantity class.

Refer to User-defined Table 0193 - Amount Class for suggested values.

2.A.58.3 Money or Percentage Quantity

Attention: The PTA.3 component was deprecated as of v2.5 and the detail was withdrawn and removed from the standard as of v 2.7. Refer to PTA.4 instead.

2.A.58.4 Money or Percentage (MOP)

Definition: specifies an amount that may be either currency or a percentage.

2.A.59 QIP - query input parameter list

HL7 Component Table - QIP - Query Input Parameter List

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1 6..12
ST R
Segment Field Name
2.A.75 DB
2
199# ST R
Values
2.A.75 DB

Definition: This data type contains a segment field name and the list of values to be passed to the query processor.

Example:

|@PID.5.1^EVANS|

2.A.59.1 Segment Field Name (ST)

Definition: This component contains the segment field name.

Naming conventions:

Segment field names are designated by the "@" symbol concatenated with the HL7 segment ID followed by the sequence number for the field separated by a period. See sections 2.5.2, "Segments and segment groups" and 2.5.3.1, "Position (sequence within the segment)" for a definition of segment ID and sequence number. If the field is divided into components, the designation may be suffixed with ".nn", to identify a particular component (a suffix of ".3" indicates the third component of the field); otherwise, the whole field is assumed. If the field is further divided into subcomponents, the designation is suffixed with ".nn.mm", which identifies the component and subcomponent requested by relative position.

Site-specific segment field names may be used. In this case, the site-specific segment ID (if the field is not being added to an existing HL7 segment) and the sequence number must be defined so that they do not conflict with existing HL7 segment IDs and field sequence numbers.

Values for this field are defined in the function-specific chapters of this specification.

Note: If the "@" is being used as one of the delimiter characters defined in MSH-2-encoding characters, it must be "escaped." See Section 2.7.1, "Formatting Codes".

2.A.59.2 Values (ST)

Definition: This component contains the field value or values in the form "value1& value2 & value3..."

A single-valued parameter contains only a single subcomponent in the second component, thus no subcomponent delimiters are needed (e.g., <segment field name> ^ <value>). A simple list of values (i.e., a one-dimensional array) may be passed instead of a single value by separating each value with the subcomponent delimiter (e.g., <segment field name> ^ <value1 & value2 &...>).

2.A.60 QSC - query selection criteria

HL7 Component Table - QSC - Query Selection Criteria

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

ST R
Segment Field Name
2.A.75 DB
2 2..2
ID O 0209 Relational Operator
2.A.35 DB
3
199# ST O
Value
2.A.75 DB
4 3..3
ID O 0210 Relational Conjunction
2.A.35 DB

Definition: This field indicates the conditions that qualify the rows to be returned in the query response. Note that this field conveys the same information as the "WHERE" clause in the corresponding SQL expression of the query, but is formatted differently.

Example:

|@PID.5.1^EQ^EVANS|

2.A.60.1 Segment Field Name (ST)

Definition: The name of the field that is participating as a qualifier (usually the "key"). Refer to Section 2.A.59.1, "Segment Field Name (ST)," for segment field name conventions.

2.A.60.2 Relational Operator (ID)

Definition: Refer to HL7 Table 0209 - Relational Operator for valid values.

2.A.60.3 Value (ST)

Definition: The value to which the field will be compared.

2.A.60.4 Relational Conjunction (ID)

Definition: Refer to HL7 Table 0210 - Relational Conjunction for valid values. The relational conjunction is defined as follows: If more than one comparison is to be made to select qualifying rows, a conjunction relates this repetition of the field to the next.

2.A.61 RCD - row column definition

HL7 Component Table - RCD - Row Column Definition

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1 6..12
ST O
Segment Field Name
2.A.75 DB
2 2..3
ID O 0440 HL7 Data Type
2.A.35 DB
3 1..5
NM O
Maximum Column Width
2.A.47 DB

Definition: This specifies the format of a column in terms of a segment field name, a data type, and a maximum length.

Example: This defines a column containing the value of the "last name" component of PID-5, expressed as a ST data type with a maximum width of 20.

|@PID.5.1^ST^20|

2.A.61.1 Segment Field Name (ST)

Definition: The HL7 segment field name, which identifies the field occupying the column. Refer to Section 2.A.59.1, "Segment Field Name (ST)," for segment field name definition conventions.

2.A.61.2 HL7 Data Type (ID)

Definition: The two or three character HL7 data type. Refer to HL7 Table 0440 - Data Types for valid values.

2.A.61.3 Maximum Column Width (NM)

Definition: The maximum width of the column, as dictated by the responding system. This may vary from the HL7-defined maximum field length.

2.A.62 RFR - reference range

HL7 Component Table - RFR - Reference Range

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

NR R
Numeric Range
2.A.48 DB
2

CWE O 0001 Administrative Sex
2.A.36 DB
3

NR O
Age Range
2.A.48 DB
4

NR O
Gestational Age Range
2.A.48 DB
5
20= ST O
Species
2.A.75 DB
6
20= ST O
Race/subspecies
2.A.75 DB
7

TX O
Conditions
2.A.79 DB

Definition: Describes a reference range and its supporting detail.

Note: Replaces the CM data type used in sections 8.8.4.6 - OM2-6, 8.8.4.7 - OM2-7 and 8.8.4.8 - OM2-8 as of v 2.5.

Examples:

  1. A range that applies unconditionally, such as albumin, is transmitted as:

|3.0&5.5|

  1. A normal range that depends on sex, such as Hgb, is transmitted as:

|13.5&18^M~12.0 & 16^F|

  1. A normal range that depends on age, sex, and race (a concocted example) is:

|10&13^M^0&2^^^B11&13.5^M^2&20^^^B~12&14.5^M^20&70^^^B~13&16.0^M^70&^^^B|

When no value is specified for a particular component, the range given applies to all categories of that component. For example, when nothing is specified for race/species, the range should be taken as the human range without regard to race. If no age range is specified, the normal range given is assumed to apply to all ages.

2.A.62.1 Numeric Range (NR)

Definition: This component specifies the numeric interval of the reference data. Range is taken to be inclusive (i.e., the range includes the end points). Units are context sensitive and are defined in the usage note for the field where this data type is used.

2.A.62.2 Administrative Sex (CWE)

Definition: This component specifies which gender for which the reference range is valid. Refer to User-defined Table 0001 - Administrative Sex in Chapter 2C, section 3.4.2.8, "Administrative Sex" for suggested values.

2.A.62.3 Age Range (NR)

Definition: This component specifies the age range for which the reference range is valid. Ages of less than one year should be specified as a fraction (e.g., 1 month = 0.0830, 1 week = 0.01920, 1 day = 0.0027300). However, for most purposes involving infants, the gestational age (measured in weeks) is preferred. The lower end of the range is not indicated; the upper end is, assuring that series of ranges do not overlap.

2.A.62.4 Gestational Age Range (NR)

Definition: This component specifies the gestational age range for which the reference range is valid. Gestational age is relevant only when the reference range is influenced by the stage of pregnancy. The gestational age is measured in weeks from conception. For example, |1&4| implies that the normals apply to gestational ages from 1 week to 4 weeks inclusive. The lower end of the range is not included; the upper end is, assuring that series of age ranges do not overlap.

2.A.62.5 Species (TX)

Definition: This component specifies the species for which the reference range is valid. Species is assumed to be human unless otherwise stated. Example values are rabbit, mouse, and rat.

2.A.62.6 Race/subspecies (ST)

Definition: This component specifies the race or subspecies for which the reference range is valid. In the case of humans (the default species), the race is specified when race influences the reference range. When normal ranges for animals are being described, this component can be used to describe subspecies or special breeds of animals.

2.A.62.7 Conditions (TX)

Definition: This component specifies any arbitrary condition for which the reference range is valid. This may include such conditions as phase of menstrual cycle or dose of a particular drug. It is provided as a way to communicate the normal ranges for special conditions. It does not allow automatic checking of these text conditions.

2.A.63 RI - repeat interval

HL7 Component Table - RI - Repeat Interval

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE O 0335 Repeat Pattern
2.A.36 DB
2
199# ST O
Explicit Time Interval
2.A.75 DB

Definition: contains the interval between repeated services.

Note: The reader is referred to the RPT - Repeat pattern data type, which provides a more rigorous framework for defining repeating time intervals.

2.A.63.1 Repeat Pattern (CWE)

Definition: The repeating frequency with which the treatment is to be administered. It is similar to the frequency and SIG code tables used in order entry systems.

Refer to User-defined Table 0335 - Repeat Pattern for suggested values.

The first component may repeat, with repeat values separated by a space. The repeats are interpreted as connected by logical ANDs.

Example:

Twice per day, every other day: BID QOD

Three times per day, Monday Wednesday and Friday: TID QJ135

Because of this syntax, repeat values should never contain blanks.

2.A.63.2 Explicit Time Interval (ST)

Definition: This component explicitly lists the actual times referenced by the code in the first component, in the following format: HHMM,HHMM,HHMM,.... This second component will be used to clarify the first component in cases where the actual times vary within an institution. If the time of the order spans more than a single day, this new component is only practical if the same times of administration occur for each day of the order. If the actual start time of the order (as given by the fourth component of the quantity/timing field) is after the first explicit time, the first administration is taken to be the first explicit time after the start time. In the case where the patient moves to a location having a different set of explicit times, the existing order may be updated with a new quantity/timing field showing the changed explicit times.

Example: 2nd component of quantity/timing field:

|QID^0230,0830,1430,2030|

2.A.64 RMC - room coverage

HL7 Component Table - RMC - Room Coverage

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE R 0145 Room Type
2.A.36 DB
2

CWE O 0146 Amount Type
2.A.36 DB
3


W
Coverage Amount Withdrawn as of v2.7. 2.A.47 DB
4

MOP R
Money or Percentage
2.A.43 DB

Definition: This data type specifies insurance coverage detail for a room.

Note: Replaces the CM data type used in section 6.5.7.28 IN2-28, as of v 2.5.

2.A.64.1 Room Type (CWE)

Definition: Specifies the room type.

Refer to User-defined Table 0145 - Room Type for suggested values.

2.A.64.2 Amount Type (CWE)

Definition: Specifies amount quantity type.

Refer to User-defined Table 0146 - Amount Type for suggested values.

2.A.64.3 Coverage Amount Quantity (NM)

Attention: The PTA.3 component was deprecated as of v2.5 and the detail was withdrawn and removed from the standard as of v2.7. Refer to 2.A.64.4, "Money or Percentage".

2.A.64.4 Money or Percentage (MOP)

Definition: specifies an amount that may be either currency or a percentage.

2.A.65 RP - reference pointer

HL7 Component Table - RP - Reference Pointer

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
999# ST O
Pointer
2.A.75 DB
2

HD O
Application ID
2.A.33 DB
3 4..11
ID O 0834 Type of Data
2.A.35 DB
4
32= ID O 0291 Subtype
2.A.35 DB

Definition: This data type transmits information about data stored on another system. It contains a reference pointer that uniquely identifies the data on the other system, the identity of the other system, and the type of data.

2.A.65.1 Pointer (ST)

Definition: A key to the referenced data assigned by the system that stores the data. The key, which is an ST data type, is used to identify and access the data, either as an object identifier, or as a hierarchical name or query string.

2.A.65.2 Application ID (HD)

Definition: A unique designator of the system that stores the data. It is an HD data type (See Section 2.A.33, "HD - hierarchic designator"). Application ID's must be unique across a given HL7 implementation.

Usage Note: The Application ID together with the Pointer may form a Uniform Resource Identifier (URI) in accordance with RFC 2396. In this case the Application ID shall include the Scheme and Authority parts of the URI, and the Path part if that points to an application. The Pointer shall include the Query part of the URI, or the Path part if that points to an object. All delimiters between URI parts (":", "/", "?") should be included in the components.

Referenced data may be obtained by a mechanism not defined in the HL7 standard. The Scheme part of a URI in the Application ID specifies the access protocol, e.g., HTTP or FTP.

Example 1: A CDA document accessed by FTP:

|/cdasvc/u28864099/s9076500a/e77534/d55378.xml^&ftp://www.saintelsewhere.org&URI^text^x-hl7-cda-level-one|

Example 2: A DICOM image accessed by HTTP and converted to JPEG (using the ISO/DICOM WADO standard); note that ampersands in the Pointer string are escaped to "\T\" to avoid conflict with the sub-component delimiter:

|?requestType=WADO\T\study=1.2.840.113848.5.22.9220847989\T\series=1.2.840.113848.5.22.922084798.4\T\object=1.2.840.113848.5.22.922084798.4.5^&https://www.pacs.poupon.edu/wado.jsp&URI^image^jpeg|

2.A.65.3 Type of Data (ID)

Definition: An ID data type that declares the general type of data. Refer to Imported Table 0834 - MIME Types for valid values. Table 0834 comprises the values of MIME media types established in accordance with RFC 2046 (http://ietf.org/rfc/rfc2046.txt) and registered with the Internet Assigned Numbers Authority (http://www.iana.org/numbers.html). Note that the MIME media type values are case-insensitive, in accordance with RFC 2045.

Note: HL7 Table 0191- Type of Referenced Data is retained for backward compatibility as of v2.6.

2.A.65.4 Subtype (ID)

Definition: An ID data type declaring the format for the referenced. Refer to Externally-defined Table 0291 - Subtype of Referenced Data for valid values. Table 0291 comprises the values of MIME media subtypes established in accordance with RFC 2046 (http://ietf.org/rfc/rfc2046.txt) and registered with the Internet Assigned Numbers Authority (http://www.iana.org/numbers.html). Note that the MIME media subtype values are case-insensitive, in accordance with RFC 2045.

HL7 approved "standard" extensions as defined in table 0291 are allowed.

Additional subtypes may be added to this Standard. All subtypes registered by IANA may be used by implementation agreement between cooperating parties. In addition, private, non-standard subtypes may be defined by agreement between cooperating parties. All private, non-standard subtypes should begin with the character combination "X-" to distinguish them from the standard subtypes, in accordance with RFC 2045.

2.A.66 RPT - repeat pattern

HL7 Component Table - RPT - Repeat Pattern

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE R 0335 Repeat Pattern Code
2.A.13 DB
2 2..2
ID O 0527 Calendar Alignment
2.A.35 DB
3
10= NM O
Phase Range Begin Value
2.A.47 DB
4
10= NM O
Phase Range End Value
2.A.47 DB
5
10= NM O
Period Quantity
2.A.47 DB
6

CWE C
Period Units
2.A.36 DB
7 1..1
ID O 0136 Institution Specified Time
2.A.35 DB
8 2..3
ID O 0528 Event
2.A.35 DB
9
10= NM O
Event Offset Quantity
2.A.47 DB
10

CWE C
Event Offset Units
2.A.36 DB
11

GTS O
General Timing Specification
2.A.32 DB

Definition: The repeat pattern data type should be used where it is necessary to define the frequency at which an event is to take place. This data type provides a way to define repeat pattern codes "on the fly". The repeat pattern code is equivalent to the TQ data type, component 2, sub-component 1 (repeat pattern). The additional components define the meaning of the repeat pattern code. Components 2 - 10 are used to define relatively simple repeat patterns. Component 11 is provided to define complex repeat patterns. This data type forms a bridge between the 2.x Repeat Pattern concept from Quantity/Timing, and the Version 3.0 GTS General Timing Specification. Component 1 is the 2.x concept of repeat pattern. Components 2-7 are derived from the version 3.0 data type PIVL. Components 8-10 are derived from the version 3.0 EIVL data type. If a repeat pattern cannot be defined using components 2-10, then component 11, General Timing Specification is provided. This allows the full literal form of the version 3.0 GTS to be specified.

When using the RPT, if an application doesn't recognize the code in component 1, then it may attempt to determine the appropriate frequency using the remaining components. If the application does recognize the code in component 1, the application is not required to determine the frequency from the remaining components.

Use Case: The use case supporting this proposal is the need to define repeat patterns on the fly while placing an order. The TQ data type did not have the capability to define the meaning of a repeat pattern on the fly. To get around this problem, vendors have implemented a variety of solutions to solve this issue. One way was to add Z-components to the TQ data type to transmit information about the repeat pattern. Another solution was to attempt to parse the repeat pattern code in an attempt to decipher what the code meant.

Examples:

|Q1H&Every 1 Hour&HL7xxx^^^^1^h|

|Q2J2&Every second Tuesday&HL7xxx^DW^2^^2^wk|

|BID&Twice a day at institution specified times&HL7xxx^^^^12^h^Y|

|QAM&Every morning at the institution specified time&HL7xxx^HD^00^11^1^d^Y|

|QHS&Every day before the hours of sleep&HL7xxx^^^^1^d^^AHS|

|ACM&Before Breakfast&HL7xxx^^^^^^^ACM|

2.A.66.1 Repeat Pattern Code (CWE)

Definition: A code representing the repeat pattern defined by the other components of this data type. Refer to User-defined Table 0335 - Repeat Pattern for suggested values.

2.A.66.2 Calendar Alignment (ID)

Definition: Specifies an alignment of the repetition to a calendar (e.g., to distinguish every 30 days from "the 5th of every month"). Refer to HL7 Table 0527 - Calendar Alignment for valid values.

2.A.66.3 Phase Range Begin Value (NM)

Definition: Used for Calendar aligned repeat patterns to determine the amount of time from the beginning of particular RPT.2 - Calendar Alignment to the beginning of the phase. If Calendar Alignment is DW (days of week), then this would be the offset from the beginning of the week.

If Phase Range Begin Value is populated, but Phase Range End Value is not populated, then this component defines when the period (RPT.5, 6) begins.

If both Phase Range Begin Value and Phase Range End Value are populated, then this component defines the earliest point in time at which the period (RPT.5, 6) will begin.

The units of measure for this component are derived from the Calendar Alignment value in RPT.2. See HL7 Table 0527 - Calendar Alignment for the units of measure associated with a particular calendar alignment.

2.A.66.4 Phase Range End Value (NM)

Definition: Used for Calendar aligned repeat patterns to determine the amount of time from the beginning of particular RPT.2 - Calendar Alignment to the end of the phase.

If Phase Range End Value is populated, but Phase Range Begin Value is not populated, then this component defines when the timing period (RPT.5, 6) begins.

If both Phase Range Begin Value and Phase Range End Value are populated, then this component defines the latest point in time at which the period (RPT.5, 6) will begin.

The units of measure for this component are derived from the Calendar Alignment value in RPT.2. See HL7 Table 0527 - Calendar Alignment for the units of measure associated with a particular calendar alignment.

2.A.66.5 Period Quantity (NM)

Definition: A time duration specifying the frequency at which the periodic interval repeats. RPT.6 - Period Units defines the units of time for this component.

2.A.66.6 Period Units (CWE)

Definition: Defines the units used for RPT.5 - Period Quantity. Constrained to units of time. Best practice is to use UCUM. Refer to External table the Unified Code for Units of Measure (UCUM) [http://aurora.rg.iupui.edu/UCUM] for valid values.

Condition Rule: This component is required if RPT.5 - Period Quantity is populated.

2.A.66.7 Institution Specified Time (ID)

Definition: A code that indicates whether the exact timing is up to the party executing the schedule (e.g., to distinguish "every 8 hours" from "3 times a day"). Refer to HL7 Table 0136 - Yes/No Indicator for valid values.

2.A.66.8 Event (ID)

Definition: A code for a common (periodical) activity of daily living. Refer to HL7 Table 0528 - Event-Related Period for valid values.

2.A.66.9 Event Offset Quantity (NM)

Definition: An interval that marks the offsets for the beginning, width and end of the event-related periodic interval measured from the time each such event actually occurred. A positive numeric value indicates the amount of time after the event in RPT.8. A negative numeric value indicates the amount of time prior to the event in RPT.8. RPT.10 - Event Offset Units defines the units of time for this component.

Usage Note: This component should not be valued unless there is a value in RPT-8 (Event).

2.A.66.10 Event Offset Units (CWE)

Definition: Defines the units used for RPT-9 (Event Offset Quantity). Constrained to units of time. The codes for unit of measure are specified in the Unified Code for Units of Measure (UCUM) [http://aurora.rg.iupui.edu/UCUM].

Condition Rule: This component is required if RPT.9 - Event Offset Quantity is populated.

2.A.66.11 General Timing Specification (GTS)

Definition: The General Timing Specification as defined by the Version 3 Data Types document.

2.A.67 SAD - street address

HL7 Component Table - SAD - Street Address

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
120# ST O
Street or Mailing Address
2.A.75 DB
2
50# ST O
Street Name
2.A.75 DB
3
12# ST O
Dwelling Number
2.A.75 DB

Definition: This data type specifies an entity's street address and associated detail.

Note: Appears ONLY in the XAD data type

2.A.67.1 Street or Mailing Address (ST)

Definition: This component specifies the street or mailing address of a person or institution. When referencing an institution, this first component is used to specify the institution name. When used in connection with a person, this component specifies the first line of the address.

2.A.67.2 Street Name (ST)

2.A.67.3 Dwelling Number (ST)

2.A.68 SCV - scheduling class value pair

HL7 Component Table - SCV - Scheduling Class Value Pair

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE O 0294 Parameter Class
2.A.13 DB
2
20= ST O
Parameter Value
2.A.75 DB

Definition: This data type is used to communicate parameters and preferences to the filler application regarding the selection of an appropriate time slot, resource, location, or filler override criterion for an appointment.

For use only with the scheduling chapter.

2.A.68.1 Parameter Class (CWE)

Definition: The first component of this field is a code identifying the parameter or preference being passed to the filler application. Refer to User-defined Table 0294 - Time Selection Criteria Parameter Class Codes for suggested values.

2.A.68.2 Parameter Value (ST)

Definition: The second component is the actual data value for that parameter.

For example, if a filler application allows preference parameters to be passed to specify a preferred start time, a preferred end time, and preferred days of the week for the appointment, it may define the following parameter class codes and valid data sets.

2.A.69 SI - sequence ID

HL7 Component Table - SI - Sequence ID

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.

1..4 4=


Sequence ID

DB

Definition: A non-negative integer in the form of a NM field. The uses of this data type are defined in the chapters defining the segments and messages in which it appears.

Minimum Length: 1

Maximum Length: 4.

This allows for a number between 0 and 9999 to be specified.

2.A.70 SN - structured numeric

HL7 Component Table - SN - Structured Numeric

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1 1..2
ST O
Comparator
2.A.75 DB
2

NM O
Num1
2.A.47 DB
3 1..1
ST O
Separator/Suffix
2.A.75 DB
4

NM O
Num2
2.A.47 DB

Definition: The structured numeric data type is used to unambiguously express numeric clinical results along with qualifications. This enables receiving systems to store the components separately, and facilitates the use of numeric database queries. The corresponding sets of values indicated with the <comparator> and <separator/suffix> components are intended to be the authoritative and complete set of values. If additional values are needed for the <comparator> and <separator/suffix> components, they should be submitted to HL7 for inclusion in the Standard.

If <num1> and <num2> are both non-null, then the separator/suffix must be non-null. If the separator is "-", the data range is inclusive; e.g., <num1> - <num2> defines a range of numbers x, such that: <num1> <=x<= <num2>.

2.A.70.1 Comparator (ST)

Definition: Defined as greater than, less than, greater than or equal, less than or equal, equal, and not equal, respectively (= ">" or "<" or ">=" or "<=" or "=" or "<>".

If this component is not valued, it defaults to equal ("=").

2.A.70.2 Num1 (NM)

Definition: A number.

2.A.70.3 Separator/Suffix (ST)

Definition: "-" or "+" or "/" or "." or ":"

Examples:

|>^100| (greater than 100)

|^100^-^200| (equal to range of 100 through 200)

|^1^:^228| (ratio of 1 to 128, e.g., the results of a serological test)

|^2^+| (categorical response, e.g., occult blood positivity)

2.A.70.4 Num2 (NM)

Definition: A number or null depending on the measurement.

2.A.71 SNM - string of telephone number digits

HL7 Component Table - SNM - String of Telephone Number Digits

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.

1..



String of telephone number digits

DB

Definition: A string whose characters are limited to "+" and/or the decimal digits 0 through 9. As a string, leading zeros are always considered significant.

Used only in the XTN data type as of v2.7.

Minimum Length: 1

Maximum Length: Not specified for the type. May be specified in the context of use

SNM is used for telephone numbers, so it is never appropriate to truncate values of type SNM.

2.A.72 SPD - specialty description

HL7 Component Table - SPD - Specialty Description

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
50= ST R
Specialty Name
2.A.75 DB
2
50= ST O
Governing Board
2.A.75 DB
3 1..1
ID O 0337 Eligible or Certified
2.A.35 DB
4

DT O
Date of Certification
2.A.21 DB

Definition: This data type specifies the practitioner's specialty and related information.

Note: Replaces the CM data type used in 15.4.5.5 PRA-5 as of v 2.5.

2.A.72.1 Specialty Name (ST)

Definition: Identifies the provider's specialty.

2.A.72.2 Governing Board (ST)

Definition: Identifies the governing body providing for the specialty.

2.A.72.3 Eligible or Certified (ID)

Definition: Specifies the certification status. Refer to HL7 Table 0337 - Certification Status for valid values.

2.A.72.4 Date of Certification (DT)

Definition: Specifies when certification occurred.

2.A.73 Withdrawn (SPS - specimen source)

Attention: The SPS data type was retained for backward compatibility only as of v2.5 and the detail was withdrawn and removed from the standard as of v2.7. The reader is referred to the SPM segment in Chapter 7, "Observations".

2.A.74 SRT - sort order

HL7 Component Table - SRT - Sort Order

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1 6..12
ST R
Sort-by Field
2.A.75 DB
2 1..2
ID O 0397 Sequencing
2.A.35 DB

Definition: Specifies those parameters by which the response will be sorted and by what method.

Example: In a tabular response query, where the return data is known by column name, the SRT might look like:

|LastName^A~FirstName^A|

Example: In a segment response query, where the return data is known by segment and offset, the SRT field would use segment field name notation:

|PID.3.1^A~PID.3.2|

2.A.74.1 Sort-by Field (ST)

Definition: Identifies the field by which the response will be sorted. In a tabular response, this will be the column name to sort by. In the Segment Pattern and the Display Response, this will be the segment field name to sort by. See QIP in Section 2.A.59.1, "Segment Field Name (ST)" for segment field name definition.

See Chapter 5, "Query", for a complete discussion of queries and their responses.

2.A.74.2 Sequencing (ID)

Definition: Identifies how the field or parameter will be sorted; and, if sorted, whether the sort will be case sensitive (the default) or not. Refer to HL7 Table 0397 - Sequencing for valid values

2.A.75 ST - string data

HL7 Component Table - ST - String Data

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.






String Data

DB

Definition: The String data type is used for text data when the appearance of text does not bear meaning. This is true for formalized text, symbols and formal expressions, and all kinds of names intended for machine processing (e.g., sorting, querying, indexing, etc.).

String data is left justified (i.e., no leading blank space) with trailing blanks optional. Any displayable (printable) ACSII characters (hexadecimal values between 20 and 7E, inclusive, or ASCII decimal values between 32 and 126), except the defined escape characters and defined delimiter characters.

Example 1: A textual ST field:

|almost any data at all|

Example 2: URL encoded in an ST component:

^http://www.pacs.poupon.edu/wado.jsp^

Example 3: ISO OID encoded in an ST subcomponent:

&2.16.840.1.113883.1.1&

To include any HL7 delimiter character (except the segment terminator) within a string data field, use the appropriate HL7 escape sequence (see Section 2.7.1, "Formatting Codes").

Minimum Length: Not specified for the type. May be specified in the context of use. Defaults to 1

Maximum Length: Not specified for the type. May be specified in the context of use

ST has no inbuilt semantics - these are assigned where the ST is used. In each case where ST is used, minimum, maximum, and conformance lengths may be specified. Unless specified in the context of use, values of type ST may not be truncated.

Usage note: The ST data type is intended for short strings (e.g., less than 1000 characters). For longer strings the TX or FT data types should be used (see Sections 2.A.79, "TX - text data" or 2.A.31, "FT - formatted text data").

Alternate character set note: ST - string data may also be used to express other character sets. See Section 2.15.9.18, "Character set," and Section 2.15.9.20, "Alternate character set handling" for details.

2.A.76 TM - time

HL7 Component Table - TM -Time

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.

2..16 13#


Time

DB

Definition: Specifies the hour of the day with optional minutes, seconds, fraction of second using a 24-hour clock notation and time zone.

As of v 2.3, the number of characters populated (excluding the time zone specification) specifies the precision.

Format: HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ]

Thus:

the first two are used to specify a precision of "hour"

the first four are used to specify a precision of "minute"

the first six are used to specify a precision of "second"

the first eight are used to specify a precision of "one tenth of a second"

the first eleven are used to specify a precision of " one ten thousandths of a second"

Example: |0630| specifies 6: 30 AM.

The fractional seconds could be sent by a transmitter who requires greater precision than whole seconds. Fractional representations of minutes, hours or other higher-order units of time are not permitted.

Note: The time zone [+/-ZZZZ], when used, is restricted to legally-defined time zones and is represented in HHMM format.

The time zone of the sender may be sent optionally as an offset from the coordinated universal time (previously known as Greenwich Mean Time). Where the time zone is not present in a particular TM field but is included as part of the date/time field in the MSH segment, the MSH value will be used as the default time zone. Otherwise, the time is understood to refer to the local time of the sender.

Examples:

Time Description
|0000| midnight
|235959+1100| 1 second before midnight in a time zone eleven hours ahead of Universal Coordinated Time (i.e., East of Greenwich).
|0800| Eight AM, local time of the sender.
|093544.2312| 44.2312 seconds after Nine thirty-five AM, local time of sender.
|13| 1pm (with a precision of hours), local time of sender.

Prior to v 2.3, this data type was specified in the format HHMM[SS[.SSSS]][+/-ZZZZ]. As of v 2.3 minutes are no longer required. By site-specific agreement, HHMM[SS[.SSSS]][+/-ZZZZ] may be used where backward compatibility must be maintained.This corresponds a minimum length of 4.

The TM data type does not follow the normal truncation pattern, and the truncation character is never valid in the TM data type. Instead, the truncation behavior is based on the semantics of times.

Unless otherwise specified in the context where the DTM type is used, the DTM type may be truncated to a particular minute. When a TM is truncated, the truncated form SHALL still be a valid TM type. Refer to Chapter 2, section 2.5.5.2, "Truncation Pattern", for further information.

2.A.77 Withdrawn (TQ - timing/quantity)

Attention: The TQ data type was retained for backward compatibility only as of v2.5 and the detail was withdrawn and removed from the standard as of v 2.7. The reader is referred to the TQ1 and TQ2 segments in Chapter 4, "Order Entry".

2.A.78 Withdrawn (TS - timestamp)

Attention: The TS data type has been replaced by the DTM data type and the detail was withdrawn and removed from the standard as of v 2.6.

2.A.79 TX - text data

HL7 Component Table - TX - Text Data

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.






Text Data

DB

Definition: String data meant for user display (on a terminal or printer). Such data would not necessarily be left justified since leading spaces may contribute greatly to the clarity of the presentation to the user. Because this type of data is intended for display, it may contain certain escape character sequences designed to control the display. Escape sequence formatting is defined in Section 2.7, "Use of escape sequences in text fields". Leading spaces should be included. Trailing spaces should be removed.

Example:

| leading spaces are allowed.|

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 on a printer or terminal. Therefore, the repeat delimiters are regarded as paragraph terminators or hard carriage returns (e.g., they would display as though a CR/LF were inserted in the text (DOS type system) or as though a LF were inserted into the text (UNIX style system)).

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.

To include alternative character sets, use the appropriate escape sequence. See Chapter 2, section 2.14.9.18, "MSH-18 - Character Set" and section 2.14.9.20, "MSH-20 - Alternate Character Set Handling Scheme".

This specification applies no limit to the length of the TX data type, either here where the data type is defined, or elsewhere where the data type is used. While there is no intrinsic reason to limit the length of this data type for semantic or syntactical reasons, it is expected that some sort of limitation will be imposed for technical reasons in implementations. HL7 recommends that implementation length limits be published in implementation profiles.

2.A.80 UVC - UB value code and amount

HL7 Component Table - UVC - UB Value Code and Amount

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

CWE R 0153 Value Code
2.A.8 DB
2

MO O
Value Amount
2.A.41 DB
3

NM O
Non-Monetary Value Amount / Quantity
2.A.47 DB
4

CWE O
Non-Monetary Value Amount / Units
2.A.46 DB

Definition: A code structure to relate amounts or values to identified data elements necessary to process this claim as qualified by the payer organization.

This data type is used to convey information defined by CMS or other regulatory agencies. It corresponds to UB fields 46A, 47A, 48A, 49A, 46B, 47B, 48B, and 49B and UB92 fields 39a, 39b, 39c, 39d, 40a, 40b, 40c, 40d, 41a, 41b, 41c, and 41d.

Note: Replaces the CM data type used in sections 6.5.10.10 UB1-10 and 6.5.11.6 UB2-6, as of v 2.5.

The most common semi-private room rate is used in instances where the patient is placed in a private room at their request but their insurance only covers a semi-private room rate, which can be calculated using the 01-most common semi-private room rate.

Example:

|01&most common semi private rate&NUBC^750&USD|

2.A.80.1 Value Code (CWE)

Definition: Specifies the National Uniform Billing Committee (NUBC) code itself.

Refer to External Table 0153 - Value Code for valid values. In the United States, values for this component need to come from National Uniform Billing Committee (NUBC); no extensions are allowed.

Other realms should determine the precise set appropriate for their realm.

2.A.80.2 Value Amount (MO)

Definition: Specifies the numeric amount when needed to pair with the value when it is monetary.

2.A.80.3 Non-Monetary Value Amount / Quantity (NM)

Definition: Specifies the numeric amount when needed to pair with the value when it is non-monetary.

2.A.80.4 Non-Monetary Value Amount / Units (CWE)

Definition: This component species the units in which the non-monetary quantity is expressed. Refer to the Unified Code for Units of Measure (UCUM) for valid values [http://aurora.rg.iupui.edu/UCUM].

2.A.81 VH - visiting hours

HL7 Component Table - VH - Visiting Hours

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1 3..3
ID O 0267 Start Day Range
2.A.35 DB
2 3..3
ID O 0267 End Day Range
2.A.35 DB
3

TM O
Start Hour Range
2.A.76 DB
4

TM O
End Hour Range
2.A.76 DB

Definition: This data type contains the hours when a patient location is open for visiting. Refer to HL7 Table 0267 - Days of the Week for valid values for the first two components.

2.A.81.1 Start Day Range (ID)

Definition: Starting day of visiting hours range. See HL7 Table 0267 - Days of the Week for valid values.

2.A.81.2 End Day Range (ID)

Definition: Ending day of visiting hours range. Starting day of visiting hours range. See HL7 Table 0267 - Days of the Week for valid values.

2.A.81.3 Start Hour Range (TM)

Definition: Starting hour on starting day of visiting hours range. See first component, 2.A.81.1, "Start Day Range (ID)".

2.A.81.4 End Hour Range (TM)

Definition: Ending hour on ending day of visiting hours range. See second component, 2.A.81.2, "End Day Range (ID)".

2.A.82 VID - version identifier

HL7 Component Table - VID - Version Identifier

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1 3..5
ID R 0104 Version ID
2.A.35 DB
2

CWE O 0399 Internationalization Code
2.A.13 DB
3

CWE O
International Version ID
2.A.13 DB

2.A.82.1 Version ID (ID)

Definition: Used to identify the HL7 version. Refer to HL7 Table 0104 - Version ID in Chapter 2C for valid values.

2.A.82.2 Internationalization Code (CWE)

Definition: Used to identify the international affiliate country code. The values to be used are those of ISO 3166 -1:1977. The ISO 3166 table has three separate forms of the country code: HL7 specifies that the 3-character (alphabetic) form be used for the country code.

Refer to HL7 Table 0399 - Country Code in Chapter 2C for the 3-character codes as defined by ISO 3166 table.

2.A.82.3 International Version ID (CWE)

Definition: This field component identifies international affiliate's version; it is especially important when the international affiliate has more than a single local version associated with a single US version.

2.A.83 VR - value range

HL7 Component Table - VR - Value Range

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
6= ST O
First Data Code Value
2.A.75 DB
2
6= ST O
Last Data Code Value
2.A.75 DB

Definition: This data type contains the lower bound value and upper bound values that constitute a range. Either or both components may be populated.

Note: Replaces the CM data type used in 5.10.5.3.11 QRD-11 as of v 2.5.

The VR differs from the Numeric Range (NR) data type only in that the values are not restricted to numbers. If the range is not numeric, the set must be orderable in some intuitive way such as alpha or the order must be defined in the field where the data type is used.

Example 1:

|+^+++|

Example 2: Colors of the rainbow

|violet^red|

2.A.83.1 First Data Code Value (ST)

Definition: Specifies the lower bound value.

2.A.83.2 Last Data Code Value (ST)

Definition: Specifies the upper bound value.

2.A.84 WVI - channel identifier

Attention: Retained for backward compatibility only in v 2.7. This is used only in the CD Channel Definition data type, which has been retained for backward compatibility only in v2.7.

HL7 Component Table - WVI - Channel Identifier

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
4= NM R
Channel Number
2.A.47 DB
2
17# ST O
Channel Name
2.A.75 DB

Definition: This data type specifies the number and name of the recording channel where waveform data is transmitted.

Note: Replaces the CM data type used in 7.14.1.3.1 OBX-5.1 where OBX-5 Observation value (*) is data type CD as of v 2.5.

2.A.84.1 Channel Number (NM)

Definition: This component specifies the number of the recording channel.

2.A.84.2 Channel Name (ST)

Definition: This component specifies the name of the recording channel.

2.A.85 WVS - waveform source

Attention: Retained for backward compatibility only in v2.7. It is used only in the CD Channel Definition data type, which has been retained for backward compatibility only in v2.7.

HL7 Component Table - WVS - Waveform Source

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
8= ST R
Source One Name
2.A.75 DB
2
8= ST O
Source Two Name
2.A.75 DB

Definition: This data type identifies the source of the waveform connected to a channel.

Note: Replaces the CM data type used in 7.14.1.4 OBX-5.2 where OBX-5 Observation value (*) is data type CD as of v 2.5.

2.A.85.1 Source One Name (ST)

Definition: This component identifies the first input for the waveform source.

2.A.85.2 Source Two Name (ST)

Definition: This component identifies the second input for the waveform source if a differential input is used.

2.A.86 XAD - extended address

HL7 Component Table - XAD - Extended Address

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

SAD O
Street Address
2.A.67 DB
2
120# ST O
Other Designation
2.A.75 DB
3
50# ST O
City
2.A.75 DB
4
50# ST O
State or Province
2.A.75 DB
5
12= ST O
Zip or Postal Code
2.A.75 DB
6 3..3
ID O 0399 Country
2.A.35 DB
7 1..3
ID C 0190 Address Type
2.A.35 DB
8
50# ST O
Other Geographic Designation
2.A.75 DB
9

CWE O 0289 County/Parish Code
2.A.36 DB
10

CWE O 0288 Census Tract
2.A.36 DB
11 1..1
ID O 0465 Address Representation Code
2.A.35 DB
12


W
Address Validity Range Withdrawn as of v2.7.
DB
13
8= DTM O
Effective Date
2.A.22 DB
14
8= DTM O
Expiration Date
2.A.22 DB
15

CWE O 0616 Expiration Reason
2.A.13 DB
16 1..1
ID O 0136 Temporary Indicator
2.A.35 DB
17 1..1
ID O 0136 Bad Address Indicator
2.A.35 DB
18 1..1
ID O 0617 Address Usage
2.A.35 DB
19
199# ST O
Addressee
2.A.75 DB
20
199# ST O
Comment
2.A.75 DB
21
2= NM O
Preference Order
2.A.47 DB
22

CWE O 0618 Protection Code
2.A.13 DB
23

EI O
Address Identifier
2.A.25 DB

Definition: This data type specifies the address of a person, place or organization plus associated information.

Note: Replaces the AD data type as of v2.3.

Example of usage for US:

|1000 Hospital Lane^Ste. 123^Ann Arbor ^MI^99999^USA^B^^WA^|

This would be formatted for postal purposes as

1000 Hospital Lane

Ste. 123

Ann Arbor MI 99999

Example of usage for Australia:

|14th Floor^1000 Hospital Lane^Sidney^QLD^9999|

This would be formatted for postal purposes using the same rules as for the American example as

14th Floor

1000 Hospital Lane

Sidney QLD 9999

International note: Countries typically have a standard method of formatting addresses. This data type does not specify the formatting usages, only the components of a postal address.

2.A.86.1 Street Address (SAD)

Definition: This component contains the house number, apartment number, street name, street direction, P.O. Box number, and similar address information.

2.A.86.2 Other Designation (ST)

Definition: This component contains the second line of address. In US usage, it qualifies address. Examples: Suite 555 or Fourth Floor. When referencing an institution, this component specifies the street address.

2.A.86.3 City (ST)

Definition: This component specifies the city, or district or place where the addressee is located depending upon the national convention for formatting addresses for postal usage.

2.A.86.4 State or Province (ST)

Definition: This component specifies the state or province where the addressee is located. State or province should be represented by the official postal service codes for that country.

2.A.86.5 Zip or Postal Code (ST)

Definition: This component specifies the zip or postal code where the addressee is located. Zip or postal codes should be represented by the official codes for that country. In the US, the zip code takes the form 99999[-9999], while the Canadian postal code takes the form A9A9A9, and the Australian Postcode takes the form 9999.

2.A.86.6 Country (ID)

Definition: This component specifies the country where the addressee is located. HL7 specifies that the 3-character (alphabetic) form of ISO 3166 be used for the country code. Refer to HL7 Table 0399 - Country Code for valid values.

2.A.86.7 Address Type (ID)

Definition: This component specifies the kind or type of address. Refer to HL7 Table 0190 - Address Type for valid values.

XAD.7 is required if there are multiple occurrences of XAD in a field.

2.A.86.8 Other Geographic Designation (ST)

Definition: This component specifies any other geographic designation. It includes county, bioregion, SMSA, etc.

2.A.86.9 County/Parish Code (CWE)

Definition: A code that represents the county in which the specified address resides. User-defined Table 0289 - County/parish is used as the HL7 identifier for the user-defined table of values for this component. When this component is used to represent the county (or parish), component 8 <other geographic designation> should not duplicate it (i.e., the use of <other geographic designation> to represent the county is allowed only for the purpose of backward compatibility, and should be discouraged in this and future versions of HL7).

Allowable values: codes defined by government.

2.A.86.10 Census Tract (CWE)

Definition: A code that represents the census tract in which the specified address resides. User-defined Table 0288 - Census Tract is used as the HL7 identifier for the user-defined table of values for this component.

Allowable Values: codes defined by government.

2.A.86.11 Address Representation Code (ID)

Definition: Different <name/address types> and representations of the same name/address should be described by repeating of this field, with different values of the <name/address type> and/or <name/address representation> component.

Note: Also note that this new component remains in "alphabetic" representation with each repetition of the fields using these data types. I.e. even though the address may be represented in an ideographic character set, this component will remain represented in an alphabetic character set.

Refer to HL7 Table 0465 - Name/address Representation for valid values.

In general this component provides an indication of the representation provided by the data item. It does not necessarily specify the character sets used. Thus, even though the representation might provide an indication of what to expect, the sender is still free to encode the contents using whatever character set is desired. This component provides only hints for the receiver, so it can make choices regarding what it has been sent and what it is capable of displaying.

2.A.86.12 Address Validity Range (DR)

Attention: The XAD.12 component was retained for backward compatibility as of v2.5 and the detail was withdrawn and removed from the standard as of v2.7. Refer to 2.A.86.13, "Effective Date (DTM)" and 2.A.86.14, "Expiration Date (DTM)" components.

2.A.86.13 Effective Date (DTM)

Definition: The first date, if known, on which the address is valid and active for the 'owning' entity.

2.A.86.14 Expiration Date (DTM)

Definition: The last date, if known, on which the address is valid and active for the 'owning' entity.

2.A.86.15 Expiration Reason (CWE)

Definition: This identifies why this address was marked as "ended". Refer to User-defined Table 0616 - Address Expiration Reason for valid values.

2.A.86.16 Temporary Indicator (ID)

Definition: If "Y" this indicates that the address is considered temporary. Refer to HL7 Table 0136 - Yes/No Indicator.

2.A.86.17 Bad Address Indicator (ID)

Definition: If "Y", this indicates that it is not possible to contact the "owning" entity at this address. Refer to HL7 Table 0136 - Yes/No Indicator.

2.A.86.18 Address Usage (ID)

Definition: This indicates how the address is intended to be used. Refer to User-defined Table 0617 - Address Usage for valid values.

2.A.86.19 Addressee (ST)

Definition: Identifies the name of the person or organization that should appear as part of the address. This is also known as the "Care of" or "C/O" line.

2.A.86.20 Comment (ST)

Definition: Descriptive information about the use of the address.

Example: "Do not ring bell."

2.A.86.21 Preference Order (NM)

Definition: For an entity having multiple addresses, indicates which is the 'most preferred' (lowest number) to 'least preferred' (highest number).

If the preference order is unique across all usages for a given type, then it indicates the preference across all usages, (e.g., first try my home address, then my business address). Otherwise, the preference order is assumed to only apply within a specific usage.

Preference order numbers need not be sequential (i.e., four addresses with the priority orders of 10, 1, 5 and 15 are legitimate). The preference order numbers must be non-negative.

2.A.86.22 Protection Code (CWE)

Definition: Identifies that an address needs to be treated with special care or sensitivity.

The specific set of codes and appropriate handling of such addresses will vary by jurisdiction and is subject to site-specific negotiation. For example, a provider address marked as 'unlisted' might not be printed in an internal address listing. Refer to User-defined Table 0618 - Protection Code for valid values.

2.A.86.23 Address Identifier (EI)

Definition: A unique identifier for the address.

This component allows an address to be uniquely identified, and enables the linking of a single address to multiple people and contexts. For example, each member of a family living at the same location would share the same address, having the same identifier. A correction to the address of one family member could be automatically propagated to other members of the family.

2.A.87 XCN - extended composite ID number and name for persons

HL7 Component Table - XCN - Extended Composite ID Number and Name for Persons

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
15= ST C
Person Identifier
2.A.75 DB
2

FN C
Family Name
2.A.30 DB
3
30# ST O
Given Name
2.A.75 DB
4
30# ST O
Second and Further Given Names or Initials Thereof
2.A.75 DB
5
20# ST O
Suffix (e.g., JR or III)
2.A.75 DB
6
20# ST O
Prefix (e.g., DR)
2.A.75 DB
7


W
Degree (e.g., MD) withdrawn as of v2.7 2.A.36 DB
8

CWE B 0297 Source Table
2.A.36 DB
9

HD C 0363 Assigning Authority
2.A.33 DB
10 1..5
ID C 0200 Name Type Code
2.A.35 DB
11 1..4
ST O
Identifier Check Digit
2.A.75 DB
12 3..3
ID C 0061 Check Digit Scheme
2.A.35 DB
13 2..5
ID C 0203 Identifier Type Code
2.A.35 DB
14

HD O
Assigning Facility
2.A.33 DB
15 1..1
ID O 0465 Name Representation Code
2.A.35 DB
16

CWE O 0448 Name Context
2.A.13 DB
17


W
Name Validity Range withdrawn as of v2.7 2.A.20 DB
18 1..1
ID O 0444 Name Assembly Order
2.A.35 DB
19
8= DTM O
Effective Date
2.A.22 DB
20
8= DTM O
Expiration Date
2.A.22 DB
21
199# ST O
Professional Suffix
2.A.75 DB
22

CWE C
Assigning Jurisdiction
2.A.13 DB
23

CWE C
Assigning Agency or Department
2.A.13 DB
24
4= ST O
Security Check
2.A.74 DB
25 3..3
ID O 0904 Security Check Scheme
2.A.35 DB

Note: Replaces CN data type as of v 2.3.

This data type is used extensively appearing in the PV1, ORC, RXO, RXE, OBR and SCH segments, as well as others, where there is a need to specify the ID number and name of a person.

Example without assigning authority and assigning facility:

|1234567^Everyman^Adam^A^III^DR^PHD^ADT01^^L^4^M11^MR|

Examples with assigning authority and assigning facility:

Dr. Harold Hippocrates' provider ID was assigned by the Provider Master and was first issued at Good Health Hospital within the Community Health and Hospitals System. Since IS table values (first component of the HD) were not used for assigning authority and assigning facility, components 2 and 3 of the HD data type are populated and demoted to sub-components as follows:

12188^Hippocrates^Harold^H^IV^Dr^MD^^&Provider Master.Community Health and Hospitals&L^L^9^M10^DN^&Good Health Hospital.Community Health and Hospitals&L^A

Ludwig van Beethoven's medical record number was assigned by the Master Patient Index and was first issued at Fairview Hospital within the University Hospitals System.

10535^van Beethoven&van^Ludwig^A^III^Dr^PHD^^&MPI.Community Health and Hospitals&L^L^3^M10^MR^& Good Health Hospital.Community Health and Hospitals&L^A

2.A.87.1 PerPerson Identifier (ST)

Definition: This component carries the Person Identifier itself. XCN.1, in conjunction with XCN.9 uniquely identifies the entity/person.

XCN.1 is required if XCN.2 is not populated. Both may be populated.

2.A.87.2 Family Name (FN)

Definition: This component allows full specification of the surname of a person. Where appropriate, it differentiates the person's own surname from that of the person's partner or spouse, in cases where the person's name may contain elements from either name. It also permits messages to distinguish the surname prefix (such as "van" or "de") from the surname root. See section 2.A.30, "FN - family name".

XCN.2 is required if XCN.1 is not populated. Both may be populated.

2.A.87.3 Given Name (ST)

Definition: First name.

2.A.87.4 Second and Further Given Names or Initials Thereof (ST)

Definition: Multiple middle names may be included by separating them with spaces.

2.A.87.5 Suffix (ST)

Definition: Used to specify a name suffix (e.g., Jr. or III).

2.A.87.6 Prefix (ST)

Definition: Used to specify a name prefix (e.g., Dr.).

2.A.87.7 Degree

Attention: The XCN-7 component was deprecated as of v2.5 and the detail was withdrawn and removed from the standard as of v27.. Refer to XCN.21 Professional Suffix.

2.A.87.8 Source Table (CWE)

Attention: Retained for backwards compatibility only as of v2.7. The reader is referred to XCN.9 instead.

User-defined Table 0297 - CN ID source is used as the HL7 identifier for the user-defined table of values for this component. Used to delineate the first component.

2.A.87.9 Assigning Authority (HD)

Definition: The assigning authority is a unique identifier of the system (or organization or agency of department) that creates the data. User-defined Table 0363 - Assigning Authority is used as the HL7 identifier for the user-defined table of values for the first sub-component of the HD component, <namespace ID>.

As of v2.7, the Assigning Authority is conditional. It is required if XCN.1 is populated and neither XCN.22 nor XCN.23 are populated. All 3 components may be populated. No assumptions can be safely made based on position or sequence. Best practice is to send an OID in this component when populated.

The reader is referred to XCN.22 and XCN.23 if there is a need to transmit values with semantic meaning for an assigning jurisdiction or assigning department or agency in addition to, or instead of, an assigning authority. However, all 3 components may be valued. If, in so doing, it is discovered that the values in XCN.22 and/or XCN.23 conflict with XCN.9, the user would look to the Message Profile or other implementation agreement for a statement as to which takes precedence.

Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component) may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment.

By site agreement, implementors may continue to use User-defined Table 0300 - Namespace ID for the first sub-component.

2.A.87.10 Name Type Code (ID)

Definition: A code that represents the type of name. Refer to HL7 Table 0200 - Name Type for valid values. See Section 2.A.89.7, "Name Type Code (ID)".

As of v2.7, XCN.10 is conditional. It is required if XCN.2 is populated.

2.A.87.11 Identifier Check Digit (ST)

Definition: This component contains the digit, or digits, exclusive of the identifier in XCN.1, calculated by applying an algorithm to all or some of the digits in the number, which may be used to test validity of the non-check-digit identifier.

2.A.87.12 Check Digit Scheme (ID)

Definition: Contains the code identifying the check digit scheme employed.

Refer to HL7 Table 0061 - Check Digit Scheme for valid values.

2.A.87.13 Identifier Type Code (ID)

Definition: A code corresponding to the type of identifier. In some cases, this code may be used as a qualifier to the <assigning authority> component. Refer to HL7 Table 0203 - Identifier Type for suggested values.

As of v2.7, XCN.13 is conditional. It is required if XCN.1 is populated.

2.A.87.14 Assigning Facility (HD)

Definition: The place or location identifier where the identifier was first assigned to the person. This component is not an inherent part of the identifier but rather part of the history of the identifier: as part of this data type, its existence is a convenience for certain intercommunicating systems.

Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component) may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment.

2.A.87.15 Name Representation Code (ID)

Definition: Different <name/address types> and representations of the same <name/address> should be described by repeating of this field, with different values of the <name/address type> and/or <name/address representation> component.

Note: This new component remains in "alphabetic" representation with each repetition of the field using these data types. I.e., even though the name may be represented in an ideographic character set, this component will remain represented in an alphabetic character set.

Refer to HL7 Table 0465 - Name/address Representation for valid values.

In general this component provides an indication of the representation provided by the data item. It does not necessarily specify the character sets used. Thus, even though the representation might provide an indication of what to expect, the sender is still free to encode the contents using whatever character set is desired. This component provides only hints for the receiver, so it can make choices regarding what it has been sent and what it is capable of displaying.

2.A.87.16 Name Context (CWE)

Definition: This component is used to designate the context in which a name is used. The main use case is in Australian healthcare for indigenous patients who prefer to use different names when attending different healthcare institutions. Another use case occurs in the US where health practitioners can be licensed under slightly different names and the reporting of the correct name is vital for administrative purposes. Refer to User-defined Table 0448 - Name Context for suggested values.

2.A.87.17 Name Validity Range

Attention: The XCN.17 component was deprecated as of v2.5 and the detail was withdrawn and removed from the standard as of v 2.7. Refer to XCN.19 Effective Date and XCN.20 Expiration Date instead.

This component contains the start and end date/times that define the period during which this name was valid.

2.A.87.18 Name Assembly Order (ID)

Definition: A code that represents the preferred display order of the components of this person name. Refer to HL7 Table 0444 - Name Assembly Order for valid values.

2.A.87.19 Effective Date (DTM)

Definition: The first date, if known, on which the person name is valid and active.

2.A.87.20 Expiration Date (DTM)

Definition: The last date, if known, on which the person name is valid and active.

2.A.87.21 Professional Suffix (ST)

Definition: Used to specify an abbreviation, or a string of abbreviations denoting qualifications that support the person's profession, (e.g., licenses, certificates, degrees, affiliations with professional societies, etc.). The Professional Suffix normally follows the Family Name when the Person Name is used for display purposes. Please note that this component is an unformatted string and is used for display purposes only. Detailed information regarding the contents of Professional Suffix is obtained using appropriate segments in Chapter 15, "Personnel Management".

2.A.87.22 Assigning Jurisdiction (CWE)

Definition: The geo-political body that assigned the identifier in XCN.1.

See section, 2.A.14.9, "Assigning Jurisdiction (CWE)" for further detail.

As of v2.7, the Assigning Jurisdiction is conditional. It is required if XCN.1 is populated and neither XCN.9 nor XCN.23 are populated. All 3 components may be populated. The reader is referred to XCN.9 if there is a need to transmit this information as an OID.

2.A.87.23 Assigning Agency or Department (CWE)

Definition: The agency or department that assigned the identifier in XCN.1.

See section 2.A.14.10, "Assigning Agency or Department (CWE)" for further details.

As of v2.7, the Assigning Jurisdiction is conditional. It is required if XCN.1 is populated and neither XCN.9 nor XCN.22 are populated. All 3 components may be populated. The reader is referred to XCN.9 if there is a need to transmit this information as an OID.

2.A.87.24 Security Check (ST)

Definition: This component is used to communicate a version code that may be assigned to the value given in XCN.1 Person Identifier.

2.A.87.25 Security Check Scheme (ID)

Definition: This component is used to transmit information intended to validate the veracity of the supplied identifier or the presenter of the identifier. For example, this component may be used to ensure that the presenter of a credit card is an authorized user of that card.

Refer to HL7 Table 0904 - Security Check Scheme for valid values

2.A.88 XON - extended composite name and identification number for organizations

HL7 Component Table - XON - Extended Composite Name and Identification Number for Organizations

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1
50# ST O
Organization Name
2.A.75 DB
2

CWE O 0204 Organization Name Type Code
2.A.36 DB
3


W
ID Number Withdrawn as of v2.7.
DB
4
4= NM O
Identifier Check Digit
2.A.47 DB
5 3..3
ID O 0061 Check Digit Scheme
2.A.35 DB
6

HD O 0363 Assigning Authority
2.A.33 DB
7 2..5
ID O 0203 Identifier Type Code
2.A.35 DB
8

HD O
Assigning Facility
2.A.33 DB
9 1..1
ID O 0465 Name Representation Code
2.A.35 DB
10
20= ST O
Organization Identifier
2.A.75 DB

This data type is used in fields (e.g., PV2-23, NK1-13, PD1-3, OBR-44) to specify the name and ID number of an organization.

Example 1:

The ID for Good Health Hospital was assigned by the Community Health and Hospitals enterprise's Hospital Master and was first issued at the Central Offices.

Good Health Hospital^L^716^9^M10^&Hospital Master.Community Health and Hospitals&L^XX^&Central Offices.Community Health and Hospitals&L^A

Example 2:

Good Health Hospital has another ID that was issued by CMS. Assigning Authority, CMS, values only the first HD component, an IS data type and assigning facility is not relevant. This information might be transmitted accordingly:

Good Health Hospital^L^4544^3^M10^CMS^XX^^A

2.A.88.1 Organization Name (ST)

Definition: The name of the specified organization.

2.A.88.2 Organization Name Type Code (CWE)

Definition: A code that represents the type of name i.e., legal name, display name. Refer to User-defined Table 0204 - Organizational Name Type for suggested values.

2.A.88.3 ID Number

Attention: The XON.3 component was deprecated as of v2.5 and the detail was withdrawn and removed from the standard as of v 2.7. Refer to XON.10 Organization Identifier.

2.A.88.4 Identifier Check Digit (NM)

Definition: This component contains the digit, or digits, exclusive of the identifier in XON.1, usually calculated by applying an algorithm to all or some of the digits in the number, which may be used to test validity of the non-check-digit identifier.

This component may also be used to transmit information intended to validate the veracity of the supplied identifier or the presenter of the identifier. For example, this component may be used to ensure that the presenter of a credit card is an authorized user of that card.

2.A.88.5 Check Digit Scheme (ID)

Definition: Contains the code identifying the check digit scheme employed.

The check digit scheme codes are defined in HL7 Table 0061 - Check Digit Scheme.

2.A.88.6 Assigning Authority (HD)

Definition: The assigning authority is a unique identifier of the system (or organization or agency or department) that creates the data. Assigning authorities are unique across a given HL7 implementation. Refer to User-defined Table 0363 - Assigning Authority for suggested values.

Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component) may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment. By site agreement, implementers may continue to use User-defined Table 0300 - Namespace ID for the first sub-component.

2.A.88.7 Identifier Type Code (ID)

Definition: A code corresponding to the type of identifier. In some cases, this code may be used as a qualifier to the "Assigning authority" component. Refer to HL7 Table 0203 - Identifier Type for suggested values.

2.A.88.8 Assigning Facility ID (HD)

Definition: The place or location identifier where the identifier was first assigned to the person. This component is not an inherent part of the identifier but rather part of the history of the identifier: as part of this data type, its existence is a convenience for certain intercommunicating systems.

Note: When the HD data type is used in a given segment as a component of a field of another data type, User-defined Table 0300 - Namespace ID (referenced by the first sub-component of the HD component) may be re-defined (given a different user-defined table number and name) by the technical committee responsible for that segment.

2.A.88.9 Name Representation Code (ID)

Definition: Different <name/address types> and representations of the same <name/address> should be described by repeating of this field, with different values of the <name/address type> and/or <name/address representation> component.

Note: This new component remains in "alphabetic" representation with each repetition of the field using these data types, i.e. even though the name may be represented in an ideographic character set, this component will remain represented in an alphabetic character set.

Refer to HL7 Table 0465 - Name/address Representation Code for valid values.

In general this component provides an indication of the representation provided by the data item. It does not necessarily specify the character sets used. Thus, even though the representation might provide an indication of what to expect, the sender is still free to encode the contents using whatever character set is desired. This component provides only hints for the receiver, so it can make choices regarding what it has been sent and what it is capable of displaying.

2.A.88.10 Organization identifier (ST)

Definition: This component contains the sequence of characters (the code) that uniquely identifies the item being referenced by XON.1 Organization Name. This component replaces XON.3 ID Number as of v 2.5.

Note: The check digit and code identifying check digit scheme are null if Organization identifier is alphanumeric.

2.A.89 XPN - extended person name

HL7 Component Table - XPN- Extended Person Name

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1

FN RE
Family Name
2.A.30 DB
2
30# ST O
Given Name
2.A.75 DB
3
30# ST O
Second and Further Given Names or Initials Thereof
2.A.75 DB
4
20# ST O
Suffix (e.g., JR or III)
2.A.75 DB
5
20# ST O
Prefix (e.g., DR)
2.A.75 DB
6


W
Degree (e.g., MD) withdrawn as of v2.7
DB
7 1..5
ID O 0200 Name Type Code
2.A.35 DB
8 1..1
ID O 0465 Name Representation Code
2.A.35 DB
9

CWE O 0448 Name Context
2.A.13 DB
10


W
Name Validity Range Withdrawn as of v2.7.
DB
11 1..1
ID O 0444 Name Assembly Order
2.A.35 DB
12

DTM O
Effective Date
2.A.22 DB
13

DTM O
Expiration Date
2.A.22 DB
14
199# ST O
Professional Suffix
2.A.75 DB
15
30# ST O
Called By

DB

Note: Replaces PN data type as of v 2.3.

Internationalization Note: In countries using ideographic or syllabic (phonetic) character sets, it is sometimes necessary to send the name in one or both of these formats, as well as an alphabetic format. The switching between the different character sets can be accomplished using a character set such as JIS X 0202 - ISO 2022 which provides an escape sequence for switching among different character sets and among single-byte and multi-byte character representations. When the name field is repeated, the different repetitions of the name may be represented by these different character sets. The details are as follows. (See also Section 2.9.2, "Escape sequences supporting multiple character sets for PN, XPN, XCN, XON, XAD, FT, ST and TX data types.")

HL7 supports the following standards for Japanese characters:

JIS X 0201 for ISO-IR 13 (Japanese Katakana)

JIS X 0201 for ISO-IR 14 (Japanese Romaji)

JIS X 0208 for ISO-IR 87 (Japanese Kanji, Hiragana and Katakana)

JIS X 0212 for ISO-IR 159 (supplementary Japanese Kanji)

HL7 supports the following standards for European characters:

ISO 8859 (1-9) for ISO-IR 100, 101, 109, 110, 144,127, 126, 138 and 148.

Character sets are referenced in HL7 as ASCII, 8859/1,8859/2, ISO IR14, ISO IR87, and ISO IR159. DICOM uses codes laid out in ISO 2375, of the form 'ISO-IR xxx'. HL7 supports this naming as well, to facilitate interoperability.

HL7 uses the Basic G0 Set of the International Reference Version of ISO 646:1990 (ISO IR-6) as the default character repertoire for character strings. This is a single-byte character set, identical to ASCII.

Each repetition of a XPN, XON, XCN, or XAD field is assumed to begin with the default character set. If another character set is to be used, the HL7 defined escape sequence used to announce that character set must be at the beginning of the repetition, and the HL7 defined escape sequence used to start the default character set must be at the end of the repetition. Note also that several character sets may be intermixed within a single repetition as long as the repetition ends with a return to the default character set.

An application must specify which character sets it supports in the field MSH-18 Character Sets and which character set handling scheme it supports in the field MSH-20 Alternate Character Set Handling Scheme. It is assumed that the sending and receiving applications are aware of how to map character set names (i.e., ISO-IR xxx) to escape sequences.

For example, in many Japanese messages there is a mix of Romaji (i.e., Roman characters), Katakana (phonetic representation of foreign words), Hiragana (phonetic representation of Japanese words) and Kanji (pictographs). Such a message would require 4 character sets be specified in the MSH.

References for Internationalization of Name


Reference Description
1. "Understanding Japanese Information Processing" by Ken Lunde, O'Reilly Press
2. NEMA PS3.5 - DICOM Part 5: Data Structure and Semantics

3. ANSI X3.4:1986 ASCII character set
4. ISO 646:1990 Information Processing - ISO 7-bit coded character set for information interchange
5. ISO/IEC 2022:1994 Information Technology - Character code structure and extension techniques
6. ISO 2375:1986 Data Processing - Procedure for the registration of escape sequences
7. ISO 6429:1990 Information Processing - Control functions for 7-bit and 8-bit coded character sets
8. ISO 8859 (1-9) Information Processing - 8-bit single-byte coded graphic character sets - parts 1-9
9. ENV 41 503:1990 Information systems interconnection - European graphic character repertoires and their coding
10. ENV 41 508:1990 Information systems interconnection - East European graphic character repertoires and their coding
11. JIS X 0201-1976 Code for Information Exchange
12. JIS X 0212-1990 Code of the supplementary Japanese Graphic Character set for information interchange
13. JIS X 0208-1990 Code for the Japanese Graphic Character set for information interchange
14. RFC 1468 Japanese Character Encoding for Internet Messages

Character Repertoires supported by DICOM are defined in Part 5, section 6.1. The DICOM Standard is available free on the Internet at http://medical.nema.org/.

Examples of names requiring only one iteration of the field where the XPN is applied:

Example 1: Adam A. Everyman III PhD

|Everyman^Adam^A^III^DR^^L^^^^^^^PHD|

Example 2: Ludwig van Beethoven

|Beethoven&van^Ludwig^^^^^L|

Example 3: Hermann Egon Mayer zur alten Schildesche

|Mayer^Hermann^Egon^zur alten Schildesche|

Example 4: Sister Margot

|^Margot^^^Sister^^C|

Example 5: Dr Harold Henry Hippocrates AO. MBBS. ASCTS. A physician who holds an Honorarium, an academic degree and a board certificate. Professional suffixes are displayed as concatenated. (AO = Order of Australia (Honorarium), MBBS = Bachelor of Medicine and Bachelor of Surgery, ASCTS = Australian Society of Cardiothoracic Surgeons

|Hippocrates^Harold^Henry^^^^L^^^^^^^AO.MBBS.ASCTS|

Example 6: Nancy N. Nightingale, RN, PHN, BSN, MSN. A registered nurse who is a Public Health Nurse with 2 academic degrees, BSN and MSN.

|Nightingale^Nancy^N^^^^^^^^^^^RN, PHN, BSN, MSN|

Example 7: H.Horrace Helper Jr., RN, CNP. A registered nurse who is a certified nurse practitioner.

|Helper^H^Horrace^Jr^^^^^^^^^^ RN, CNP|

Example 8: Mevrouw Irma Jongeneel de Haas. An individual whose birth name (geboortenaam) is de Haas and whose partner's name is Jongeneel.

| Jongeneel-de Haas&de&Haas&&Jongeneel^Irma^^^Mevrouw^^L |

Examples of names requiring more than one iteration of the field where the XPN is applied:

Example 9: Herr Prof. Dr. med. Joachim W. Dudeck

|Dudeck^Joachim^W.^^Dr.med.^^L^^^^^^^ MD ~Dudeck^J.W.^^^Herr Prof.Dr.^^D|

Example 10: Herr Dr. Otto Graf Lambsdorff mdB a.D. According to German law "Adelstitel" like "Graf" or "Baron" belongs to the family name and therefore must be encoded in the family name field separated by blanks.

|Graf Lambsdorff&Graf&Lambsdorff^Otto^^^Dr.^^L~Graf Lambsdorff&Graf&Lambsdorff^Otto^^mdB a.D.^Herr Dr.^^D|

Example 11: Walter Kemper genannt (named) Mölleken

|Kemper^Walter^^^^^L~Mölleken^Walter^^^^^A|

Example 12: Herr Dr. med. Dr. h.c. Egon Maier

|Maier^Egon^^^Dr.med. Dr.h.c.^^L^^^^^^^MD~Maier^Egon^^^Herr Dr.med. Dr.h.c^^D|

Example 13: Herr Dipl.Ing. Egon Maier

|Maier^Egon^^^^^L^^^^^^^ DIPL~Maier^Egon^^^Herr Dipl.Ing.^^D|

Example 14: Frau Gerda Müller geb. Maier, verheiratet seit 16.2.2000

|Müller^Gerda^^^Frau^^L^^^^^20000216~Maier^Gerda^^^Frau^^M|

Example 15: President Adam A Everyman III, president from 1997 until 2001, aka Sonny Everyman

|Everyman^Adam^A.^III^President^^L~^^^^Mr. President^^D^^^^^19970816^20010320~Everyman^Sonny^^^^^A|

Example 16: Michio Kimura

This example doesn't use title and degrees, but shows the repetition of this name for different purposes. The first iteration is the legal name in Kanji; the second, Katakana; the third, alphabetic.

2.A.89.1 Family Name (FN)

Definition: This component allows full specification of the surname of a person. Where appropriate, it differentiates the person's own surname from that of the person's partner or spouse, in cases where the person's name may contain elements from either name. It also permits messages to distinguish the surname prefix (such as "van" or "de") from the surname root. See section 2.A.30, "FN - family name".

XPN.1 will be empty when XPN.7 is MSK. It MAY be empty when XPN.7 is NAV.

Usage Note: If a person's name has only one component, that name will be sent in XPN.1 Family Name. This is common practice in some countries such as Indonesia. This note does not cover the case where only one part of a person's multi-part name is known (e.g., only know "John" of "John Doe").

2.A.89.2 Given Name (ST)

Definition: First name.

2.A.89.3 Second and Further Given Names or Initials Thereof (ST)

Definition: Multiple middle names may be included by separating them with spaces.

2.A.89.4 Suffix (ST)

Definition: Used to specify a name suffix (e.g., Jr. or III).

2.A.89.5 Prefix (ST)

Definition: Used to specify a name prefix (e.g., Dr.).

2.A.89.6 Degree

Attention: The XPN-6 component was deprecated as of v2.5 and the detail was withdrawn and removed from the standard as of v 2.7. See XPN.14 Professional Suffix.

2.A.89.7 Name Type Code (ID)

Definition: A code that represents the type of name. Refer to HL7 Table 0200 - Name Type for valid values.

Note: The content of Legal Name is country specific. In the US the legal name is the same as the current married name.

2.A.89.8 Name Representation Code (ID)

Definition: Different <name/address types> and representations of the same <name/address> should be described by repeating of this field, with different values of the <name/address type> and/or <name/address representation> component.

Note: This new component remains in "alphabetic" representation with each repetition of the field using these data types, i.e., even though the name may be represented in an ideographic character set, this component will remain represented in an alphabetic character set.

Refer to HL7 Table 0465 - Name/address Representation for valid values.

In general this component provides an indication of the representation provided by the data item. It does not necessarily specify the character sets used. Thus, even though the representation might provide an indication of what to expect, the sender is still free to encode the contents using whatever character set is desired. This component provides only hints for the receiver, so it can make choices regarding what it has been sent and what it is capable of displaying.

2.A.89.9 Name Context (CWE)

Definition: This component is used to designate the context in which a name is used. The main use case is in Australian healthcare for indigenous patients who prefer to use different names when attending different healthcare institutions. Another use case occurs in the US where health practitioners can be licensed under slightly different names and the reporting of the correct name is vital for administrative purposes. Refer to User-defined Table 0448 - Name Context for suggested values.

2.A.89.10 Name Validity Range

Attention: The XPN.10 component was deprecated as of v2.5 and the detail was withdrawn and removed from the standard as of v2.7. Refer to 2.A.89.12, "Effective date (DTM)" and 2.A.89.13, "Expiration date (DTM)" components.

2.A.89.11 Name Assembly Order (ID)

Definition: A code that represents the preferred display order of the components of this person name. Refer to HL7 0444 - Name Assembly Order for valid values.

2.A.89.12 Effective date (DTM)

Definition: The first date, if known, on which the person name is valid and active.

2.A.89.13 Expiration date (DTM)

Definition: The last date, if known, on which the person name is valid and active.

2.A.89.14 Professional Suffix (ST)

Definition: Used to specify an abbreviation, or a string of abbreviations denoting qualifications that support the person's profession, (e.g., licenses, certificates, degrees, affiliations with professional societies, etc.). The Professional Suffix normally follows the Family Name when the Person Name is used for display purposes. Please note that this component is an unformatted string and is used for display purposes only. Detailed information regarding the contents of Professional Suffix is obtained using appropriate segments in Chapter 15, Personnel Management.

2.A.89.15 Called By (ST)

Definition: A "called by" name is the name that is preferred when a person is directly addressed; sometimes known as a nickname.

Note: The called by component contains a name that could be categorized as a nickname using the name usage types in HL7 Table 0200 - Name type. Its use is reserved for instances in which the nickname is a single name part that is provided in addition to a name that has some other type, such as legal. It is understood that the "called by" name is not part of the full name. Where a nickname has more parts, possibly including a family name, a different XPN with a type of nickname should instead be used.

Examples:

James Robert Smith is Called By Jim Bob

James Robert Smith is Called By JR

Peter Richard Smith is Called By Richard

Mary Margaret Elizabeth Jones is Called By Meg.

2.A.90 XTN - extended telecommunication number

HL7 Component Table - XTN - Extended Telecommunication Number

SEQ LEN C.LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF. DB Ref.
1


W
Telephone Number
2.A.75 DB
2 3..3
ID O 0201 Telecommunication Use Code
2.A.35 DB
3 2..8
ID R 0202 Telecommunication Equipment Type
2.A.35 DB
4
199= ST C
Communication Address
2.A.75 DB
5
3= SNM O
Country Code
2.A.47 DB
6
3= SNM O
Area/City Code
2.A.47 DB
7
9= SNM C
Local Number
2.A.47 DB
8
5= SNM C
Extension
2.A.47 DB
9
199# ST O
Any Text
2.A.75 DB
10
4= ST O
Extension Prefix
2.A.75 DB
11
6= ST O
Speed Dial Code
2.A.75 DB
12
199# ST C
Unformatted Telephone number
2.A.75 DB
13

DTM O
Effective Start Date
2.A.22 DB
14

DTM O
Expiration Date
2.A.22 DB
15

CWE O 0868 Expiration Reason
2.A.13 DB
16

CWE O 0618 Protection Code
2.A.13 DB
17

EI O
Shared Telecommunication Identifier
2.A.25 DB
18
2= NM O
Preference Order
2.A.47 DB

Example 1: A Work fax number

^WPN^FX^^^734^6777777

Example 2: Telephone number with extension

^WPN^PH^^^734^6777777^1

Example 2: Telephone number with internal code. In this example, assume that a corporation's telephone system supports a full external telephone number (area code and telephone number). It also supports internal dialing standards that assign a code to each facility and an extension to each telephone (which happens to be the last 4 digits of the external telephone number, by convention).

So, if the Los Angeles facility were assigned code 333, and if the "outside" telephone number at the LA office is (626) 555-1234, the components would be:

Component Value
area/city code 626
phone number 555-1234
extension 1234
extension prefix 333

The field would be transmitted as follows:

^WPN^PH^^^626^5551234^1234^333

Example 3: speed dial. In this example, assume that a corporation's telephone system supports speed dialing numbers. For example, suppose that a corporation has a contract with a travel agency, whose external number is 1-610-555-1234. Since it is so frequently dialed, the company assigns a speed code: #6098. The components would be:

Component Value
Area/city code 610
Phone number 555-1234
Speed Dial #6098

The field would be transmitted as follows:

^WPN^PH^^^610^5551234^^^#6098

Example 4: home e-mail address. In this example, assume that a person has a primary home e-mail address such as someone@somewhere.com. The components would be:

Component Value
Telecommunication Use Code PRN
Telecommunication Equipment Type Internet
Communication Address someone@somewhere.com

The field would be transmitted as follows:

^PRN^Internet^someone@somewhere.com

Example 5: work e-mail address. In this example, assume that a person has a work e-mail address such as someone@somewhere.com. The components would be:

Component Value
Telecommunication Use Code WPN
Telecommunication Equipment Type Internet
Communication Address someone@somewhere.com

The field would be transmitted as follows:

^WPN^Internet^someone@somewhere.com

2.A.90.1 Telephone Number

Attention: The XTN-1 component was deprecated as of v2.3 and the detail was withdrawn and removed from the standard as of v2.6.

2.A.90.2 Telecommunication Use Code (ID)

Definition: A code that represents a specific use of a telecommunication number. Refer to HL7 Table 0201 - Telecommunication Use Code for valid values. This component along with XTN.3 describes the nature of the telecommunication data that follows. Best practice requires the population of XTN.2 when XTN.4 or XTN.7 is populated.

2.A.90.3 Telecommunication Equipment Type (ID)

Definition: A code that represents the type of telecommunication equipment. Refer to HL7 Table 0202 - Telecommunication Equipment Type for valid values. This component along with XTN.2 describes the nature of the telecommunication data that follows and is necessary to accurately interpret it.

2.A.90.4 Communication Address (ST)

This component is required if, and only allowed if, XTN.7 or XTN.12 are not populated. Note: If any of the HL7 delimiters are found in the Communication Address, such as @, the appropriate HL7 escape sequence SHALL be used when encoding an Internet address (see Chapter 2, "Control", section 2.7.1, "Formatting Codes").

2.A.90.5 Country Code (SNM)

Definition: The numeric code assigned by the International Telecommunication Union in standard E.164 to access telephone services in another country. For example, "+1" is the country code for the United States, "+49" is the code for Germany.

2.A.90.6 Area/city Code (SNM)

Definition: The numeric code to access telephone services in another area/city within a country. This number historically needs not be dialed if the caller is located in the same area/city as the phone number of the called party.

The use and size of area/city codes is however country specific: some countries do not use area/city codes, or the use of area/city codes may be mandatory when dialing, or area/city codes may be used to group phone numbers based on other criteria than geographic location, such as cell-phone area/city-codes, or free information numbers (e.g., 800 numbers).

Most countries have a prefix for Area/City codes which only has to be dialed if one doesn't use a country code. This prefix (mostly "0", sometimes "9") should be omitted from the content of this field. If the prefix for the Area/Code is also mandatory if one uses the country code (e.g., in Italy) then this field should also contain the prefix.

2.A.90.7 Local Number (SNM)

Definition: The numeric code used to contact the called party, exclusive of country and area/city codes. The Local Number is required when, and allowed only if, XTN.4 and XTN.12 are not populated.

The size of the Local Number is country specific.

Note that the Local Number does not include the numeric codes that have to be dialed once a connection has been established. Examples include (automated) organizational phone systems which allow external callers to dial additional numeric codes. These additional numeric codes should be specified as an extension.

2.A.90.8 Extension (SNM)

Definition: The numeric code to contact the called party used within an organization, e.g., the number used if both caller and called party are located within the same organization. The extension is often the same as the last few digits of the Local Number. The use of extensions is country and site specific, and may depend on the type of phone system (PBX) used by the organization.

2.A.90.9 Any Text (ST)

Definition: Contains comments with respect to the telephone number.

Example: |^^^^^^^^Do not use after 5PM|

2.A.90.10 Extension Prefix (ST)

Definition: The characters established within a company's internal telephone system network used as a prefix to the Extension component for internal dialing. Note that the use of Extension Prefix requires that the Extension component be valued and that digits, as well as special characters (e.g., *, #) may be used.

2.A.90.11 Speed Dial Code (ST)

Definition: The characters established within a company's internal telephone system used in place of the (external) telephone number to facilitate calling because its length is shorter than that of the telephone number. Note that digits, as well as special characters (e.g., *, #) may be used.

2.A.90.12 Unformatted Telephone Number (ST)

Definition: An expression of the telephone number as an unparsable string. The Unformatted Telephone number is required when, and allowed only if, XTN.4 and XTN.7 are not populated.

The phone number was entered as free text and sending system does not know how to parse it.

Example: |^^^^^^^^^^^1-800-Dentist|

2.A.90.13 Effective Start Date (DTM)

Definition: The first date, if known, on which the telecommunication number is valid and active.

2.A.90.14 Expiration Date (DTM)

Definition: The last date, if known, on which the telecommunication number is valid and active.

2.A.90.15 Expiration Reason (CWE)

Definition: Indicates why this contact number/e-mail was marked as "ended". Refer to User-defined Table 0868 - Telecommunication Expiration Reason for valid values.

2.A.90.16 Protection Code (CWE)

Definition: Indicates whether this information is considered sensitive or should be protected in some way. Refer to User-defined table 0618 - Protection Code for suggested values.

The specific set of codes and appropriate handling of such telecommunications addresses will vary by jurisdiction and is subject to site-specific negotiation. For example, a provider address marked as 'unlisted' might not be printed in an internal address listing.

2.A.90.17 Shared Telecommunication Identifier (EI)

Definition: A unique identifier for the phone number or e-mail address.

This component allows a phone number to be uniquely identified, and enables the linking of a single phone number to multiple people and contexts. For example, each member of a family living at the same location would share the same phone number, having the same identifier. A correction to the phone number of one family member could be automatically propagated to other members of the family.

HL7 does not assume responsibility for the processing rules for this component.

2.A.90.18 Preference Order (NM)

Definition: For an entity having multiple telecommunication addresses, indicates which is the "most preferred" (lowest number) to "least preferred" (highest number).

If the preference order is unique across all usages for a given type, then it indicates the preference across all usages, (e.g. first try my home number, then my business number). If the preference order is unique across all usages and types, then it indicates the preference across all types of telecommunication addresses. (E.g., first try my phone; if that doesn't work, use my pager.) Otherwise, the preference order is assumed to only apply within a specific type and usage.

Preference order numbers need not be sequential (i.e., three numbers with the priority orders of 0, 5 and 15 are legitimate). The preference order numbers must be non-negative.