3 Datatypes

This section covers the datatypes in use in Australia. It omits datatypes that are deprecated from earlier versions of the standard as these should not be used in the Australian context. All data in an HL7 V2 message is encoded as text and every field required escaping/unescaping of HL7 delimiters and care should be taken to ensure that producers and consumers of this data ensure this is performed.

Datatypes can occur at several levels in a message. When a datatype is used in a field it will use the component separator (^), but when the datatype is embedded in another datatype a sub-component separator (&) may be used. Some datatypes are conceptually a combination of other datatypes e.g. an EI data type is a combination of a string (ST) identifier and a Hierarchical Designator (HD). This allows for an organization to provide a unique identifier within their namespace. In messages the HD component of an EI datatype will appear in other places in the message as a HD data type to identify the organization uniquely. If binary or non ASCII data is used it will be encoded, usually using base64  encoding.

3.1 Introduction

The following data types are those used in the Australian context.

Figure 3-1  HL7 data types by category

*  for subcomponents of these elements please refer to the definition in the text.

3.1.1   USE OF ESCAPE SEQUENCES IN TEXT FIELDS

3.1.1.1 Formatting codes

When a field of type TX, FT, or CF is being encoded, the escape character may be used to signal certain special characteristics of portions of the text field. The character \ will be used to represent the character so designated in a message. An escape sequence consists of the escape character followed by an escape code ID of one character, zero (0) or more data characters, and another occurrence of the escape character. The following escape sequences are defined:

The escape sequences for field separator, component separator, subcomponent separator, repetition separator, and escape character are also valid within an ST data field.
No escape sequence may contain a nested escape sequence.

3.1.1.3 Highlighting

In designating highlighting, the sending application is indicating that the characters that follow somehow should be made to stand out, but leaving the method of doing so to the receiving application. Depending on device characteristics and application style considerations, the receiving application may choose reverse video, boldface, underlining, blink, an alternate colour or another means of highlighting the displayed data.

For example the message fragment:
DSP| TOTAL CHOLESTEROL \H\240*\N\ [90 - 200]
might cause the following data to appear on a screen or report:
TOTAL CHOLESTEROL 240* [90 - 200]
whereas another system may choose to show the 240* in red.

3.1.1.4 Special character

The special character escape sequences (\F\, \S\, \R\, \T\, and \E\) allow the corresponding characters to be included in the data in a text field, though the actual characters are reserved.

For example, the message fragment
DSP| TOTAL CHOLESTEROL 180 \F\90 - 200\F\
DSP| \S\----------------\S\
would cause the following information to be displayed, given suitable assignment of separators:
TOTAL CHOLESTEROL 180 |90 - 200|
^----------------^

3.1.1.5 Hexadecimal

Variance to HL7 International. The hexadecimal escape sequence (\Xdddd...\) must not be used.

3.1.1.6 Escape sequences supporting multiple character sets for FT, ST, and TX data types

Variance to HL7 International. The single-byte character escape sequence \Cxxyy\ and multi-byte character escape sequence \Mxxyyzz\ must not be used.

3.2 CD - channel definition

This data type is used for labeling of digital waveform data.

Components: <channel identifier (CM)> ^ <waveform source (CM)> ^ <channel sensitivity/units (CM)> ^<channel calibration parameters (CM)> ^ <channel sampling frequency (NM)> ^ <minimum/maximum data values (CM)>

Subcomponents of channel identifier: <channel number (NM)> & <channel name (ST)>

Subcomponents of waveform source: <Source name 1 (ST)> & <Source name 2 (ST)>

Subcomponents of channel sensitivity/units: <channel sensitivity (NM)> & < unit of measure identifier (ST)> & < unit of Measure Description (ST)> & < unit of Measure Coding System(IS)> & <alternate unit of measure identifier (ST)> & <alternate unit of Measure Description (ST)> &<alternate unit of Measure Coding System (IS)>

Subcomponents of channel calibration parameters: < channel calibration sensitivity correction factor (NM)> & < channel calibration baseline (NM)> & < channel calibration time skew (NM)> Subcomponents of minimum/maximum data values: < minimum data value (NM)> & <maximum data value (NM)>

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:

3.2.1 Channel identifier (CM)

Subcomponents: <channel number (NM)> & <channel name (ST)>
Definition: Two subcomponents separated by subcomponent delimiters (&) which identify the channel, consisting of a channel number (required, maximum 4 characters, data type NM)and a channel name (optional, maximum 17 characters, data type ST).

3.2.2 Channel number (NM)

The channel number identifies the recording channel associated with a specified value in a time sample of data. It generally defines its position in a multichannel display.

3.2.3 Channel name (ST)

Definition: The channel name is a text string used as a label in waveform data displays. If this name is not present, the channel label displayed is <source1>-<source2>, where <source1> and <source2> are the names of the two waveform sources connected to this channel, or, if only one waveform sources <source1> is specified, the channel label displayed when the channel name is not given is <source1>.

3.2.4 Waveform source (CM)

Subcomponents: <Source name 1 (ST)> & <Source name 2 (ST)>

Definition: Identifies the source of the waveform connected to the channel. Two names (each maximum of 8 characters, data type ST) separated by a subcomponent delimiter (&) 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). (NOTE: Although the SIG voted to make waveform source a coded entry, this is not syntactically possible. We do not have a sub-sub-component delimiter available to separate the sub-fields of the proposed coded entry. Therefore, waveform source remains a string data type.).

3.2.4.1 Source name 1 (ST)

Definition: Identifies the first input for the waveform source.

3.2.4.2 Source name 2 (ST)

Definition: Identifies the second input for the waveform source.

3.2.5 Channel sensitivity and units (CM)

Subcomponents: <channel sensitivity (NM)> & < unit of measure identifier (ST)> & < unit of Measure Description (ST)> & < unit of Measure Coding System (IS)> & <alternate unit of measure identifier (ST)> & <alternate unit of Measure Description (ST)> & <alternate unit of Measure Coding System (IS)>

Definition: This CM data type defines the channel sensitivity (gain) and the units in which it is measured. This component consists of up to seven subcomponents, separated from each other by subcomponent delimiters (&). The first subcomponent specifies the sensitivity, while the remaining six subcomponents are used to specify the units of the sensitivity, using a format similar to the components of the coded entry (CE) data type. The subcomponents of the channel sensitivity and units are as follows:

3.2.5.1 Channel sensitivity (NM)

Defines the nominal value (maximum 20 characters, data type NM) 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. The sensitivity incorporates both the amplifier gain and the actual ADC resolution. It does not, however, relate to the vertical scaling of a waveform display (it is, for example, a measure of voltage, not voltage per unit distance). For channels recording potential differences between two electrodes using a differential amplifier, a positive sensitivity indicates that a number in the waveform data which is greater than the channel baseline represents a potential at the first electrode which is more positive than that at the second electrode. A negative sensitivity indicates that a number in the waveform data which is greater than the channel baseline corresponds to a potential at the first electrode which is more negative than that at the second electrode.

3.2.5.2 Unit of measure identifier (ST)

Definition: A units designation (for example, mol, N, Pa, m or s). Codes from The Unified Code for Units of Measure (UCUM) are presented at http://unitsofmeasure.org/trac. Although ISO+ is recommended in HL7 International documentation, UCUM is used in the Australian context as it facilitates unambiguous communication of quantities together with their units with the focus on electronic communication rather communication between humans. 

3.2.5.3 Unit of measure description (ST)

Definition: The full text name of the unit of measure identifier (for example, microvolt, millivolt, volt, pascal or millimeters of mercury) from a designated system of units.

3.2.5.4 Unit of measure coding system (IS)

Definition: The designated system of units. Refer to User-defined table 0396 – Coding System for suggested values.

3.2.5.5 Alternate unit of measure identifier (ST)

Definition: An alternate units designation (for example, uv, mv, v, pal, or mm(hg) . 

3.2.5.6 Alternate unit of measure description (ST)

Definition: The full text name of the alternate unit of measure identifier (for example, microvolt, millivolt, volt, pascal or millimeters of mercury) from a designated system of units.

3.2.5.7 Alternate unit of measure coding system (IS)

Definition: The alternate designated system of units. Refer to User-defined table 0396 – Coding System for suggested values.

3.2.6 Channel calibration parameters (CM)

Subcomponents: < channel calibration sensitivity correction factor (NM)> & < channel calibration baseline (NM)> & < channel calibration time skew (NM)>

Definition: This component consists of three optional subcomponents (each a maximum of 20 characters, data type NM), separated from each other by subcomponent delimiters (&), which define corrections to  channel sensitivity, baseline, and channel time skew which may be derived from a calibration procedure.

The three subcomponents are as follows:

3.2.6.1 Channel calibration sensitivity correction factor (NM)

Definition: 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.

3.2.6.2 Channel calibration baseline (NM)

Definition: 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.

3.2.6.3 Channel calibration time skew (NM)

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

3.2.7 Channel sampling frequency (NM)

Definition: Defines the sampling frequency in hertz of the channel, that is, the reciprocal of the time in seconds between successive samples (maximum 20 characters, data type NM). 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.)

3.2.8 Minimum and maximum data values (CM)

Subcomponents: < minimum data value (NM)> & <maximum data value (NM)>

Definition: 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 (each maximum of 20 characters, data type NM), and also specifies whether or not nonintegral 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 nonintegral as well as integral data values may be used in this channel. The minimum and maximum data values are separated by a component delimiter (&).

3.2.8.1 Minimum data value (NM)

Definition: Defines the minimum data value that can occur in this channel in the digital waveform data, and also specifies whether or not nonintegral data values may occur in this channel in the waveform data. 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 = -2^{^n-1}
H = 2^{^(n-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 = 2^{^(n-1)}
H = 2^{^n} - 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)

3.2.8.2 Maximum data value (NM)

Definition: Defines the maximum data value that can occur in this channel in the digital waveform data, and also specifies whether or not nonintegral data values may occur in this channel in the waveform data. 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 = -2^{^n}-1
H = 2^{^(n-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 = 2^{^(n-1)}
H = 2^{^n} - 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)

3.3 CE - coded element

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

Length:  250

This data type transmits codes and the text associated with the code.

Example: 

Component requirements:

When an <identifier (ST)> component is specified, the <name of the coding system> must also be specified.

If no <identifier (ST)> component is specified then no <name of coding system> (primary coding system) should be specified

<text (ST)> component is usually valued and this should be what is intended for display to the user. In some locations user display is not intended and the text may be blank.

When multiple codes are used Loinc codes (LN) should be placed first using the identifier rather than the alternate identifier. 

When an <alternate identifier (ST)> component is specified, the <name of alternate coding system> must also be specified.

If no <alternate identifier (ST)> component is specified then no <name of alternate coding system> should be specified

Both <identifer> and <alternative identifier> must reflect the same concept in each of the primary and alternate coding system respectively. Each code may reflect differing levels of granularity within each coding system as the level of granularity differs between coding systems.

Alternate coding system must be a different from the primary coding system. As the 2 codes should describe the same concept the alternate text is optional.

3.3.1 Identifier (ST)

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

3.3.2 Text (ST)

Name or description of the item in question. E.g., myocardial infarction or X-ray impression. Its data type is string (ST).

3.3.3 Name of coding system (IS)

Each coding system is assigned a unique identifier. This component will serve to identify the coding scheme being used in the identifier component. The combination of the identifier  and name of coding system components will be a unique code for a data item. Each system has a unique identifier. User-defined Table 0396 – Coding system contains the allowable values. 

NOTE 1: These are the more commonly used code systems in the Australian context.  For the international code systems available refer to http://www.hl7.org/special/committees/vocab/table_0396/index.cfm.

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 CE 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 ISO nnnn, where nnnn is the ISO table number.

This table is not exhaustive and other non-standard coding schemes may be used.

NOTE 2: HL7 message validation tools should raise a warning when a code from a coding system above cannot be resolved from their respective terminology data source. Similarly, code systems encountered not found in this table should also raise a warning.

3.3.4 Alternate identifier (ST)

For explanation, see 3.3.1

3.3.5 Alternate text (ST)

For explanation, see 3.3.2. In many cases this can be left blank as the text is the same as 3.3.2

3.3.6 Name of alternate coding system (IS)

Note on the Alternate components (4, 5, 6) (for components 1, 2, 3)

These three components are defined analogously to the above for the alternate or local coding system. If the alternate text  component is absent, and the alternate identifier is present, the alternate text  will be taken to be the same as the text  component. If the alternate coding system  component is absent, it will be taken to mean the locally-defined system.

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

Refer to User-defined Table 0396 - Coding system  for valid values. When an HL7 table is used for a CE data type, the name of coding system   component is defined as HL7nnnn   where nnnn   is the HL7 table number. 

3.4 CM - composite

A field that is a combination of other meaningful data fields. Each portion is called a component . The specific components of CM fields are defined within the field descriptions. Certain other composites have been separately identified and are described below.

No new CMs are allowed after HL7 version 2.2.

The CM data type is maintained strictly for backward compatibility and may not be used for the definition of new fields.

Wherever a component of an HL7 field is itself an HL7 data type which contains components, its delimiters are demoted by one. Thus a component designated as a CE data type should be encoded as <identifier & text & name of coding system> (see CE - coded element). Note that since HL7 delimiters are not recursive, an HL7 data type containing components cannot be a subcomponent. When this level of detail is needed, each component of the HL7 data type can be encoded as a separate subcomponent. For an example of this, see the encoding of the filler order number in the order sequencing component of the Timing/Quantity data type.

3.5 CNE – coded with no exceptions

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

Length: 250

Component requirements:

An <identifier (ST)> component is specified, the <name of the coding system> must also be specified.

If no <identifier (ST)> component is specified then no <name of coding system> should be specified

<text (ST)> component must be valued and this should be what is intended for display to the user.

When an <alternate identifier (ST)> component is specified, the <name of alternate coding system> must also be specified.

If no <alternate identifier (ST)> component is specified then no <name of alternate coding system> should be specified

<alternate text (ST)> component must be valued and this should be what is intended for display to the user.

3.5.1 Identifier (ST)

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

3.5.2 Text (ST)

Name or description of the item in question. E.g., myocardial infarction or X-ray impression. Its data type is string (ST). This is the corresponding text assigned by the coding system to the identifier.

3.5.3 Name of coding system (IS)

Each coding system is assigned a unique identifier. This component will serve to identify the coding scheme being used in the identifier component. The combination of the identifier  and name of coding system components will be a unique code for a data item. Each system has a unique identifier.

User-defined Table 0396 - Coding system contains the allowable values. The table includes ASTM E1238-94, Diagnostic, procedure, observation, drug ID, and health outcomes coding systems as identified in the tables in Appendix 4 Others may be added as needed.

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

3.5.4 Alternate identifier (ST)

Analogous to “Identifier” above. See 3.5.10 Usage notes:” for further description.

3.5.5 Alternate text (ST)

Analogous to “Text” above. See 3.5.10, “Usage notes:” for further description.

3.5.6 Name of alternate coding system (IS)

Analogous to “Name of Coding System” above. See 3.5.10, “Usage notes:” for further description.

3.5.7 Coding system version ID (ST)

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

3.5.8 Alternate coding system version ID (ST)

This is the version ID for the coding system identified by components 4-6. It belongs conceptually to the group of Alternate components (see note 3.3.6) and appears here only for reasons of backward compatibility.

3.5.9 Original text (ST)

The original text that was available to an automated process or a human before a specific code was assigned. This component is optional.

3.5.10 Usage notes:

Components 1-3 and 7: The identifier  is required and must be a valid code. Coding system  must either be present and have a value from the set of allowed coding systems or if not present it will be interpreted to have the same meaning as if it had been valued with the code meaning “HL7 coding system.” User-defined Table 0396 - Coding system contains the allowable values. If the coding system is any system other than “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.

Component 9: This is the original text that was available to an automated process or a human before a specific code was assigned. This component is optional.

Components 3-6 and 8: These components are optional. They are used to represent the local or user seen code as described. If present, components 3-6 and 8 obey the same rules of use and interpretation as described for components 1-3 and 7. 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.

CNE usage note: The CNE data type should be used when a required or mandatory coded field is needed.

 User-defined Table 0396 - Coding system contains the allowable values. The table includes ASTM E1238-94, diagnostic, procedure, observation, drug and health outcomes coding systems. When an HL7 table is used for a CE data type, the name of coding system   component is defined as HL7nnnn   where nnnn is the HL7 table number. 

3.6 CWE – coded with exceptions

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

Length:  250

Component requirements:

When an <identifier (ST)> component is specified, the <name of the coding system> must also be specified.

If no <identifier (ST)> component is specified then no <name of coding system> should be specified

<text (ST)> component must be valued and this should be what is intended for display to the user.

When an <alternate identifier (ST)> component is specified, the <name of alternate coding system> must also be specified.

If no <alternate identifier (ST)> component is specified then no <name of alternate coding system> should be specified

<alternate text (ST)> component must be valued and this should be what is intended for display to the user.

3.6.1 Identifier (ST)

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

3.6.2 Text (ST)

Name or description of the item in question. E.g., myocardial infarction or X-ray impression.

3.6.3 Name of coding system (IS)

Each coding system is assigned a unique identifier. This component will serve to identify the coding scheme being used in the identifier component. The combination of the identifier  and name of coding system components will be a unique code for a data item. Each system has a unique identifier.

User-defined Table 0396 - Coding system contains the allowable values. The table includes ASTM E1238-94, Diagnostic, procedure, observation, drug ID, and health outcomes coding systems as identified in the tables in Appendix 4 Others may be added as needed.

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

3.6.4 Alternate identifier (ST)

Analogous to “Identifier” above. 

3.6.5 Alternate text (ST)

Analogous to “Text” above.

3.6.6 Name of alternate coding system (IS)

Analogous to “Name of Coding System” above. 

3.6.7 Coding system version ID (ST)

This is the version ID for the coding system identified by components 1-3. It belongs conceptually to the group of component 1-3 and appears here only for reasons of backward compatibility.

3.6.8 Alternate coding system version ID (ST)

This is the version ID for the coding system identified by components 4-6. It belongs conceptually to the group of alternate components

Name of alternate coding system (IS)”) and appears here only for reasons of backward compatibility.

3.6.9 Original text (ST)

The original text that was available to an automated process or a human before a specific code was assigned

3.6.10 Usage notes:

This is a field that is generally sent using a code, but where the code may be omitted in exceptional instances or by site agreement. Exceptional instances arise when the coding system being used does not have a code to describe the concept in the text.

Components 1-3 & 7 are used in one of three ways:

1) Coded:  The identifier contains a valid code from a coding system. The coding system must either be present and have a value from the set of allowed coding systems, or if not present, it will be interpreted to have the same meaning as if it had been valued with the code meaning “HL7 coding system.”

 User-defined Table 0396 - Coding system contains the allowable values. The table includes ASTM E1238-94, Diagnostic, procedure, observation, drug ID, and health outcomes coding systems as identified in the table in Appendix 4. If the coding system is any system other than “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 is optional, but its use should be encouraged to aid in readability of the message during testing and debugging.

Example 1a: OBX segment where the observation identifier is a LOINC code and the observation value is being sent as a CWE value, and the value is taken from SNOMED International.

OBX|1|CWE|883-9^ABO Group^LN|1|F-D1250^Type O^SNM3^^^^3.4|||N||F<cr>

Example 1b: OBX segment where the observation identifier is a LOINC code and the observation value is being sent as an CWE value, and the value is taken from a (currently hypothetical) HL7 table.

OBX|1|CWE|883-9^ABO Group^LN|1|O^Type O^HL74875^^^^2.3.1|||N||F<cr>

2) Uncoded:  Text is valued, the identifier has no value, and coding system and version ID follow the same rules as discussed for option 1.

Example 2: OBX segment where the observation identifier is a LOINC code and the observation value is being sent as an CWE value, and the value is sent as text because the correct clinical value, “Wesnerian” was not found in the set of allowed values.

OBX|1|CWE|883-9^ABO Group^LN|1|^Wesnerian^SNM3^^^^3.4|||A||F<cr>

3) Data missing:  The name of the coding system is “HL7 CE Status,” version ID is either a real version, or if not present it has the same meaning as the version in the message header, and the identifier takes its value from one of the allowed CE field statuses. The codes for the allowed CE field statuses are shown below and will be maintained in a table as part of the HL7 vocabulary. Text description of code is optional.

Example 3: OBX segment where the observation identifier is a LOINC code and the observation value is being sent as an LCE value, and no value can be sent because the test was not done.

OBX|1|CWE|883-9^ABO Group^LN|1|NAV^Not Available^HL70353^^^^2.3.1|||N||F<cr>

Component 9: This is the original text that was available to an automated process or a human before a specific code was assigned. This field is optional.

Components 3-6 & 8: Components 3-6 & 8 are optional. They are used to represent the local or user seen code. If present, components 3-6 & 8 obey the same rules of use and interpretation as described for components 1-3 & 7 (of the CWE data type). 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.

Example 4: OBX segment where the observation identifier is a LOINC code and the observation value is being sent as an CWE value, and the value is taken from SNOMED International. The user seen fields are being used to represent a local coding system (99LAB) used in the sending system.

OBX|1|CWE|883-9^ABO Group^LN|1|F-D1250^Type O^SNM3^O^O Type Blood^99LAB^3.4^|||||F<cr>

Summary of CWE usage notes with table of status values for various states without values:

The CWE data type should be used for coded fields that are optional or where it is permissible to send text for items that are not yet a part of the approved value set. In the normal situation, the identifier is valued with the code from the value set. If the value of the field is known, but is not part of the value set, then the value is sent as text, and the identifier has no value. If the field has an unknown status, then third form of the field is used (see Data missing above), and the appropriate status for the field is selected from the table of allowed statuses. When no code exists, use values from HL7 Table 0353 - CWE statuses.

HL7 Table 0353 - CWE statuses

Where a text modifier might accompany a code, the “field” in the HL7 message would be of data type CWE and would be allowed to repeat. The first instance of the field would be used, as per option 1; i.e. the identifier would have a valid code. The second instance of the repeating field would be used, as per option 2, that is, the text description would take the value of the free text modifier.

3.7 CX - extended composite ID with check digit

Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (ID)> ^ < assigning facility (HD) ^ <effective date (DT)> ^ <expiration date (DT)>

Length:  250

Example:  

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

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

Component requirements:

<ID (ST)> component must be specified and valid according to the identifier scheme of selected by the Identifier type code and Assigning Authority components.

<assigning authority (HD)> component must be valued and valid.

<identifier type code (ID)> component should be valued with a valid value from HL7 Table 0203 - Identifier type.

3.7.1 ID (ST)

Definition: The value of the identifier itself. It is similar to the CK data type except that a ST data type is used instead of a NM data type.

3.7.2 Check digit (ST)

The check digit in this data type is not an add-on produced by the message processor. It is the check digit that is part of the identifying number used in the sending application. If the sending application does not include a self-generated check digit in the identifying number, this component should be valued null. Many identifiers (e.g. Australian provider numbers) have check digits built into the identifier and this field is not used in that case.

3.7.3 Code identifying the check digit scheme employed (ID)

This field is not usually used in Australia. The international standard defines several check digit scheme codes than can be used when the ID is numeric. The use of this field in Australia is by site specific agreement.

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

3.7.4 Assigning authority (HD)

The assigning authority is a unique name of the system (or organization or agency or 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.

For Medicare provider numbers use "|AUSHICPR|"

3.7.5 Identifier type code (ID)

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.

3.7.6 Assigning facility (HD)

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

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.

3.7.7 Effective date (DT)

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

3.7.8 Expiration date (DT)

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

3.8 DR - date/time range

Components: <range start date/time (TS)> ^ <range end date/time (TS)>

Subcomponents of range start date/time and range stop date/time:  YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ] 

3.8.1 Range start date/time (TS)

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

3.8.2 Range end date/time (TS)

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

3.9 DT - date

Format: YYYY[MM[DD]]

In the current and future versions, the precision of a date may be expressed by limiting the number of digits used with the format specification YYYY[MM[DD]]. Thus, YYYY is used to specify a precision of “year,” YYYYMM specifies a precision of “month,” and YYYYMMDD specifies a precision of “day.”

Examples: 

|19880704|

|199503|

3.10 ED - encapsulated data

Components: <source application (HD) > ^ <type of data (ID)> ^ <data subtype (ID)> ^ <encoding (ID)> ^ <data (ST)>

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

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 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 (refer to the RP - reference pointer section for discussion of MIME types).

Required components:

<type of data (ID)> must be valued.

<data subtype (ID)> must be valued.

<encoding (ID)> must be valued.

<data (ST)> must be valued.

3.10.1 Source application (HD)

A unique name that identifies the system which was the source of the data. Identical format and restrictions as in reference pointer (see Section 3.20.2, “Application ID (HD)”).

3.10.2 Type of data (ID)

Identical to “type of data” component in the reference pointer (RP) data type. (See Section 3.20.3, “Type of data (ID)”). Refer to HL7 Table 0191 - Type of referenced data  for valid values.

Note that when MIME type is used in Type of data that readers must treat the values case insensitively as per RFC 2045.

3.10.3 Data subtype (ID)

Identical to “subtype” component in the reference pointer (RP) data type. (See Section 3.20.4, “Subtype (ID)”).

Refer to HL7 Table 0291 - Subtype of referenced data  for valid values.

When this component is valued with a MIME <Subtype (ID)> value, then the corresponding MIME type must be used in the <Type of data (ID)> component.

3.10.4 Encoding (ID)

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

HL7 Table 0299 - Encoding

Base64 is defined as follows (adapted from MIME Internet standard RFC 1521, which has precedence over this description). Proceeding from left to right across a 24-bit input group (three octets), each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the encoded string. These characters are shown in HL7 Table 0290 - MIME base64 encoding characters ,and are selected so as to be universally representable.

Special processing is performed if fewer than 24 bits are available in an input group at the end of data. A full encoding quantum is always completed at the end of data. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups.

Output character positions which are not required to represent actual input data are set to the character “=”. Since all canonically encoded output is an integral number of octets, only the following cases can arise: (1) the final quantum of input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no “=” padding, (2) the final quantum of input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two “=”padding characters, or (3) the final quantum of input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one “=” padding character.

Receivers must evaluate this field in a case insensitive manner.

HL7 Table 0290 - MIME base64 encoding characters

The interpretation of the encoded octets by any of the encoding methods, beyond what is either implicit or specified in the represented data type (such as their ordering within 16-bit or 32-bit binary words on the destination application), is determined by the destination application and is beyond the scope of this Standard.

3.10.5 Data (ST)

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 ST - string data and, if encoded binary, are encoded according to the method of Section 3.10.2, “Type of data (ID).”

If the encoding component (see Section 3.10.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 HL7 International v2.4 section 2.10, “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 (see Section 3.10.4, “Encoding (ID)”) 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’, ‘decode’.

3.11 EI - entity identifier

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

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 HD - hierarchic designator. Hierarchic designators (HD) are unique across a given HL7 implementation.

3.11.1 Entity identifier (ST)

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 HD - hierarchic designator.)

3.11.2 Namespace ID (IS)

See Section 3.13.1, “Namespace ID (IS)” for definition.

The assigning authority is a unique identifier of the system (or organization or agency or 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 this component.

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.

3.11.3 Universal ID (ST)

See Section 3.14.2, “Universal ID (ST)” for definition.

3.11.4 Universal ID type (ID)

Refer to HL7 Table 0301 - Universal ID type  for valid values. See Section 3.14.3, “Universal ID type (ID)”, for definition.

3.12 FC - financial class

Components: <financial class (IS)> ^ <effective date (TS)>

3.12.1 Financial class (IS)

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.

3.12.2 Effective date (TS)

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

3.13 FT - formatted text data

This data type is derived from the string data type by allowing the addition of embedded formatting instructions in addition to escaping of the HL7 delimiters. These instructions are limited to those that are intrinsic and independent of the circumstances under which the field is being used.

The FT field is of arbitrary length (up to 64k)   and may contain formatting commands enclosed in escape characters.

Note: In the Australian context text results other than short phrases, on a single line, of less than 50 characters(which can use data type of ST) should be transmitted using OBX-2 data type of FT.

Many systems do not escape the HL7 delimiters when building messages and fail to unescape them when data is extracted. The HL7 delimiters i.e.: “|^~\&” need to be escaped in every field and in Free Text fields the Free text formatting characters also need to be handled. Failure to do this correctly makes transmitting data unreliable and breaks the interoperability of systems. Text data containing a ‘|” character could cause serious truncation of reports. Rich Text Format (RTF) contains many “\” characters and can be escaped but is better base 64 encoded as RTF can contain binary data and HL7V2 is generally restricted to the printable characters.

The special character escape sequences (\F\, \S\, \R\, \T\, and \E\) allow the corresponding characters to be included in the data in a text field, though the actual characters are reserved. For example, the message fragment

DSP| TOTAL CHOLESTEROL 180 \F\90 - 200\F\
DSP| \S\----------------\S\

would cause the following information to be displayed, given suitable assignment of separators:

TOTAL CHOLESTEROL 180 |90 - 200|
^----------------^

The escape sequences indicated above can occur in any field in a message, but are also valid in FT fields.

In formatted text (FT) data type fields, formatting commands also may be surrounded by the escape character. Each command begins with the . (period) character. The following formatting commands are available:

\.sp <number>\ End current output line and skip <number> vertical spaces. <number> is a positive integer or absent. If <number> is absent, skip one space. The horizontal character position remains unchanged. 

\.br\ Begin new output line. Set the horizontal position to the current left margin and increment the vertical position by 1.

\.fi\ Begin word wrap or fill mode. This is the default state. It can be changed to a nowrap mode using the .nf command.

\.nf\ Begin no-wrap mode.

\.in <number>\ Indent <number> of spaces, where <number> is a positive or negative integer. This command cannot appear after the first printable character of a line.

\.ti <number>\ Temporarily indent <number> of spaces where number is a positive or negative integer. This command cannot appear after the first printable character of a line.

\.sk < number>\ Skip <number> spaces to the right.

\.ce\ End current output line and center the next line.

This is an example of the FT data type from a radiology impression section of a radiology report:

\.in+4\\.ti-4\ 1. The cardio-mediastinal silhouette is now within normal limits.\.br\\.ti-4\ 2. Lung fields show minimal ground glass appearance.\.br\\.ti-4\ 3. A loop of colon visible in the left upper quadrant is distinctly abnormal with the appearance of mucosal effacement suggesting colitis.\.in-4\

1. The cardio-mediastinal silhouette is now within normal limits.

2. Lung fields show minimal ground glass appearance.


3. A loop of colon visible in the left upper quadrant is distinctly abnormal 
   with the appearance of mucosal effacement suggesting colitis.

Character sets:
In order to support formatting of tables it is necessary to allow an extended character set. A character set should be specified in MSH-18. It must be either 8859/1 (extended ascii) or UTF-8 Optional support for UTF-8 should only be assumed for receivers where this is noted in a agreed capability register. Support for 8859/1 is mandatory. However, only ASCII characters shall be used in the MSH segment. The HL7 escape sequences \M and \C shall not be used. If MSH-18 is unvalued the ASCII character set is assumed.

Implementation of escaping and un-escaping must be done with considerable rigor. In particular it was noted that un-escaping cannot be done with search and replace. and is especially difficult with RTF which is a reason to use Base-64 encoding in an ED datatype to transmit RTF.  Characters below Space (&20) are illegal and tabs (&09) should not be used (use eg. \.sk 8\ or spaces). FT data must be displayed using a non-proportionally spaced font for tables to work. Senders should limit intended display line lengths to 80 characters and receivers should ensure that 80 characters of text (using a non-proportional font) can be displayed without word wrapping the line of text. 

For both senders and receivers the FT datatype provides all capabilities of the TX datatype. FT supports formatting sequences for tab, line break and other layout control. The TX datatype shall therefore not be used

3.14 HD - hierarchic designator

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

Example: "ACME Pathology^2184^AUSNATA"

The HD is designed to be 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) 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.

In the case where a 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 a 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.

3.14.1 Namespace ID (IS)

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

User-defined Table 0300 – Namespace ID

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.

3.14.2 Universal ID (ST)

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

3.14.3 Universal ID type (ID)

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.

HL7 Table 0301 - Universal ID type

† -  Australian extensions to table 0301.

Note:  X400, X500, and DNS are not technically universally valid for all time. Names can be de-registered from an existing user and registered to a new user.

Examples: 

The usual Universal ID type in Australian Pathology is AUSNATA

         ACME Pathology^2184^AUSNATA

Alternatively when SMD is used the HPI-O can be used as follows

         ACME Pathology^1.2.36.1.2001.1003.0.8003621566684455^ISO

Universal ID examples with only the 2nd and 3rd components valued:

^1.2.344.24.1.1.3^ISO

A HD consisting only of an ISO UID.

^1.2.34.4.1.5.1.5.1,1.13143143.131.3131.1^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 (“.”) and comma (“,”) in the second component are part of the ISO syntax, but are legal by the definition of the HL7 ST data type.

^14344.14144321.4122344.14434.654^GUID

^falcon.iupui.edu^DNS

An internet example

^40C983F09183B0295822009258A3290582^RANDOM

An example of a RANDOM UID

Local examples:

LAB1

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

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.

RX.PIMS.SystemB.KP.CA.SCA

Local use only: a HD that looks like an IS data type. Again, 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.

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

Examples containing both local and universal ID types:

LAB1^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.

3.15 ID - coded value for HL7 defined tables

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 examples of an ID field is OBR-25-result status. This data type should be used only for HL7 tables. The reverse is not true, since in some circumstances it is more appropriate to use the CE data type for HL7 tables.

3.16 IS - coded value for user-defined tables

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. 

This data type should be used only for user-defined tables. The reverse is not true, since in some circumstances, it is more appropriate to use the CE data type for user-defined tables as it allows the text related to the code to be transmitted.

3.17A  MA - multiplexed array

<sample 1 from channel 1>^<sample 1 from channel 2>^<sample 1 from channel 3> ...~
<sample 2 from channel 1>^<sample 2 from channel 2>^<sample 2 from channel 3> ...~
...

Definition: This data type is used to represent channel-multiplexed waveform data, (e.g., the digitized values from an analog-to-digital converter or other digital data source). Each value is of type NM, and represents a time sample from a channel. This segment may contain data from one or more channels. The waveform data is in channel-multiplexed format (that is, the values for all channels for the first time sample are transmitted, then the values for the next time sample, and so on until the requisite number of time samples have been transmitted). Time samples are separated by repeat delimiters (~), and channels within a sample are separated by component delimiters (^). The time between samples (the sampling interval) is the reciprocal of the digitization frequency as specified using the CD data type.

Examples:
|0^0^0~1^1^1~2^2^2~3^3^3~4^4^4~5^5^5| 3 channels (identical), 5 time-samples

|0~1~2~3~4~5~6~7~8~9~10| 1 channel, 11 time-samples

3.17 NA - numeric array

This data type is used to represent a series (array) of numeric values, each one having a data type of NM. 

<value1> ^ <value2> ^ <value3> ^ <value4> ^ ...

Definition: This data type is used to represent a series (array) of numeric values, each one having a data type of NM. 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 which 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). The maximum number of values in one repetition of an NA format field is determined by the maximum field length.

Examples:
|125^34^-22^-234^569^442^-212^6|                  vector of 8 numbers

|1.2^-3.5^5.2~2.0^3.1^-6.2~3.5^7.8^-1.3|          3 x 3 array of numbers

|^2^3^4~5^^^8~9^10~~17^18^19^20|               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

3.18 NM - numeric

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.

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.

Note: In the Australian context numeric results should be transmitted using OBX-2 data types of NM or SN and not ST or FT.

3.19 PL - person location

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

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.

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 persons within a healthcare setting.

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^^^

3.19.1 Point of care (IS)

Conditional on person location type (e.g., nursing unit or department or clinic). After floor, most general patient location designation. User-defined Table 0302 - Point of care is used as the HL7 identifier for the user-defined table of values for this component.

User-defined Table 0302 – Point of care

3.19.2 Room (IS)

Patient room. After point of care, most general person location designation. User-defined Table 0303 - Room is used as the HL7 identifier for the user-defined table of values for this component.

User-defined Table 0303 – Room

3.19.3 Bed (IS)

Patient bed. After room, most general person location designation. User-defined Table 0304 - Bed is used as the HL7 identifier for the user-defined table of values for this component.

User-defined Table 0304 – Bed

3.19.4 Facility (HD)

Subject to site interpretation but generally describes the highest level physical designation of an institution, medical centre or enterprise. Most general person location designation. (See 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.

3.19.5 Location status (IS)

Location (e.g., Bed) status. User-defined Table 0306 - Location status is used as the HL7 identifier for the user-defined table of values for this component.

User-defined Table 0306 – Location status

3.19.6 Person location type (IS)

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. Usually includes values such as nursing unit, department, clinic, SNF, physician’s office. User-defined Table 0305 - Person location type is used as the HL7 identifier for the user-defined table of values for this component.

User-defined Table 0305 – Person location type

3.19.7 Building (IS)

After facility, most general person location designation. User-defined Table 0307 - Building is used as the HL7 identifier for the user-defined table of values for this component.

User-defined Table 0307 – Building

3.19.8 Floor (IS)

After building, most general person location designation. User-defined Table 0308 - Floor is used as the HL7 identifier for the user-defined table of values for this component.

User-defined Table 0308 – Floor

3.19.9 Location description (ST)

A free text description of the location.

3.20 RP - reference pointer

Components: <pointer (ST) > ^ < application ID (HD)> ^ <type of data (ID)> ^ <subtype (ID)>

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.

3.20.1 Pointer (ST)

A unique key assigned by the system that stores the data. The key, which is a ST data type, is used to identify and access the data.

3.20.2 Application ID (HD)

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

A unique designator of the system that stores the data. It is a HD data type (See HD - hierarchic designator). Application ID’s must be unique across a given HL7 implementation.

3.20.3 Type of data (ID)

An ID data type that declares the general type of data. Refer to HL7 Table 0191 - Type of referenced data for valid values.

Example field: OBX-5.3  Observation Value => Type of Data 

An ID data type declaring the format for the data of subcomponent <main type>. Refer to HL7 Table 0291- Subtype of referenced data for valid values.

3.20.4 Subtype (ID)

HL7 Table 0291—Subtype of Referenced Data

Example field: OBX-5.4  Observation Value => Type of Data 

3.20.5 Type-subtype combinations

Possible subtypes are specific to main types (though in principle the same subtype could be used for more than one main type), and so are defined under their main types.

Additional subtypes may be added to this Standard. In addition, private, non-standard subtypes may be defined by agreement between cooperating parties. All private, non-standard subtypes should begin with the letter Z  to distinguish them from the standard subtypes.

3.20.5.1 Image subtypes

TIFF = TIFF image data

TIFF (Tagged Image File Format) is one of the common formats for scanned images. Its first version was developed in 1986 by Aldus Corporation as a standard for encoding scanned images. The official version of the TIFF standard is now maintained by Adobe Corporation. TIFF format is specified in the document “TIFF, Revision 6.0.” Adobe Systems Incorporated, 1585 Charleston Road, P.O. Box 7900, Mountain View, CA 94039-7900. (415) 961-4400 The subtype “TIFF” implies recognition of that trademark and all the rights it entails.

PICT = PICT format image data

PICT is one of the common formats for scanned images. PICT is a graphics format developed by Apple Computer, Inc., Cupertino, California. PICT format is officially defined in the book set “Inside Macintosh,” published by Addison-Wesley Publishing Company, Reading, Massachusetts.

DICOM = the Digital Imaging and Communications in Medicine (DICOM) standard

DICOM is the format developed jointly by the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) as the standard for interchange of radiological images and ancillary data. It is standardized as NEMA PS3, and is available from: NEMA, 2101 L Street NW, Washington, DC 20037.

DICOM specifies a complete communications standard, including a generic messaging service for two-way exchange of imaging-related information between applications, as well as transfer of the actual images. In HL7, the use of DICOM data is limited to images only. 

Images in this subtype shall be encoded according to the Generic DICOM File Format defined in DICOM Part 10, Media Storage and File Format (NEMA PS3.10). This shall be in accordance with the Image Information Object Definitions of DICOM Part 3 (NEMA PS3.3), Data Structure and Semantics of DICOM Part 5 (NEMA PS3.5), and the Data Dictionary of DICOM Part 6 (NEMA PS3.6).

The Generic DICOM File Format consists of two parts: a DICOM File Meta Information Header, immediately followed by a DICOM Data Set. The DICOM Data Set contains the image or images specified according to DICOM Part 10. The DICOM File Meta Information Header contains, among other information, a Transfer Syntax UID (Unique Identifier) which completely specifies the encoding of the Data Set according to DICOM Part 5. This encoding defines big endian vs. little endian byte ordering, as well as image compression via the JPEG (Joint Photographics Experts Group) standard (ISO/IS 10918-1 and 10918-2). The transfer syntax of the File Meta Information Header itself is little endian byte ordered, as required by DICOM Part 10.

FAX = facsimile data

Facsimile data as specified by CCITT standards F1.60, F1.80, F1.82, and F1.84.

Jot = electronic ink data, as specified by the Jot 1.0 standard

The JOT standard, proposed jointly by Slate Corporation, Microsoft, Apple, Lotus, GO, and General Magic, allows handwritten notes, sketches, signatures and other free-form written data to be transmitted. It is the standard by which portable pen computers or workstations equipped with stylus-input tablets can represent and exchange information.

It represents electronic ink as a series of stylus strokes, and therefore contains necessary information for potential automatic handwriting recognition, which would be lost if converted to other image representations. It may, however, be readily converted to another image representation for purposes of printing or display.

The JOT 1.0 standard is available from: Software Publishers Association, 1730 M Street Northwest, Suite 700 Washington, DC 20036-4510, (202) 452-1600

3.20.5.2 Audio subtypes

basic = ISDN PCM audio data

Telephone quality audio data, encoded as 8-bit ISDN mu-law Pulse Code Modulation sampled at 8 kHz, according to CCITT Fascicle III.4, Recommendation G.711. This subtype may be used for voice mail messages as well as voice dictation.

3.20.5.3 Application subtypes

octet-stream = uninterpreted binary data

This subtype is for binary data which has none of the other standard formats as given by Section 3.20.3, “Type of data (ID)”. Its interpretation by the system utilizing the data must be mutually agreed upon by sending and receiving parties.

PostScript = PostScript program

A PostScript language program typically representing a formatted document for printing on a PostScript printer, or for display on a computer screen via a PostScript interpreter. PostScript consists of the original specification, PostScript level 1, described in “PostScript Language Reference Manual,” Addison-Wesley, 1985, and a more advanced variant, PostScript level 2, described in “PostScript Language Reference Manual,” Addison-Wesley, Second Edition, 1990. PostScript is a registered trademark of Adobe Systems, Inc. Use of the subtype “PostScript” implies recognition of that trademark and all the rights it entails.

Other types may be added as needed.

Example:

|1234A321634BC^EFC^SD|

3.21 SI - sequence ID

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.

3.22 SN - structured numeric

Components: <comparator (ST)> ^ <num1 (NM)> ^ <separator/suffix (ST)> ^ <num2 (NM)>

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

3.22.1 Comparator (ST)

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 (“=”).

3.22.2 Num1 (NM)

A number.

3.22.3 Separator/suffix (ST)

“-” or “+” or “/” or “.” or “:”

Examples:

|>^100| (greater than 100)

|^100^-^200| (equal to range of 100 through 200)

|^1^:^128| (ratio of 1 to 128, e.g., the results of a serological test)

|^2^+| (categorical response, e.g., occult blood positivity)

3.22.4 Num2 (NM)

A number or null depending on the measurement.

3.23 ST - string data

String data is left justified 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: |almost any data at all|

To include any HL7 delimiter character (except the segment terminator) within a string data field, use the appropriate HL7 escape sequence.

Usage note: The ST data type is intended for short strings (e.g., less than 50 characters). For longer strings the  FT data types should be used.

The ST data should use the same character set as specified in the message header and not use alternative character sets.

3.24 TM - time

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

In prior versions of HL7, this data type was always specified to be in the format HHMM[SS[.SSSS]][+/-ZZZZ] using a 24 hour clock notation. In the current and future versions, the precision of a time should be expressed by limiting the number of digits used with the format specification as shown above. By site specific agreement, HHMM[SS[.SSSS]][+/-ZZZZ] may be used where backward compatibility must be maintained.

Thus, HH is used to specify a precision of “hour,” HHMM is used to specify a precision of “minute,” HHMMSS is used to specify a precision of seconds, and HHMMSS.SSSS is used to specify a precision of ten-thousandths of a second.

In each of these cases, the time zone is an optional component. 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. Midnight is represented as 0000. Examples:

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

3.25 TQ - timing quantity

Describes when a service should be performed and how frequently.

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

Definition: Quantity/timing (ORC-7, OBR-27)  provides a means of specifying when the service described by the order segment is to be performed and how frequently. It is a complex multicomponent field that can have repeats; i.e., more than one quantity/timing specification, separated by repeat delimiters, may appear. It is a distinct data type. The components of a single quantity/timing specification are described here.

3.25.1 Quantity component (CQ)

Subcomponents: <quantity (NM) & units (CE)>

Definition: This field specifies the quantity of the service that should be provided at each service interval.

For example, if two blood cultures are to be obtained every 4 hours, the quantity would be 2. If three units of blood are to be typed and cross-matched, the quantity would be 3. The default value is 1. When units are required, they can be added, specified by a subcomponent delimiter.

Note: The component delimiter in this CQ is demoted to a subcomponent delimiter.

3.25.2 Interval component (CM)

Subcomponents: <repeat pattern (IS)> & <explicit time interval (ST)>

Definition: This field determines the interval between repeated services. The default is one time only, the first subcomponent is the repeat pattern, and the second subcomponent is the explicit time at which pattern is to be executed.

Note: The component delimiter in this CQ is demoted to a subcomponent delimiter.

3.25.2.1 Repeat pattern

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. The following is preferred syntax for repeat patterns:

User-defined Table 0335 - Repeat pattern

The first subcomponent may repeat, with repeat values separated by a space. The repeats are interpreted as connected by logical ANDs.

E.g., 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. If a free text frequency, such as “Twice a day, every other day” is to be sent, use the text component (component 8).

3.25.2.2 Explicit time interval

Definition: This field explicitly lists the actual times referenced by the code in the first subcomponent, in the following format: HHMM,HHMM,HHMM,.… This second subcomponent will be used to clarify the first subcomponent in cases where the actual administration times vary within an institution. If the time of the order spans more than a single day, this new subcomponent 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 subcomponent 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.

Ex: 2nd component of quantity/timing field:   ...^QID&0230,0830,1430,2030^...

3.25.3 Duration component (ST)

Definition: This field indicates how long the service should continue after it is started. The default is INDEF (do indefinitely). This component is coded as follows:

S<integer> = <integer> seconds

M<integer> = <integer> minutes

H<integer> = <integer> hours

D<integer> = <integer> days

W<integer> = <integer> weeks

L<integer> = <integer> months

X<integer> = <integer> times at interval specified in the order. A request for 2 blood cultures Q2H X3 would imply obtaining 2 blood cultures 3 different times at 2-hour intervals for a total of 6 blood cultures.

T<integer> = at the interval and amount stated until a total of <integer> “DOSAGE” is accumulated. Units would be assumed to be the same as in the QUANTITY field.

INDEF =  do indefinitely - also the default

3.25.4 Start date/time component (TS)

Definition: This field may be specified by the orderer, in which case it indicates the earliest date/time at which the services should be started. In many cases, however, the start date/time will be implied or will be defined by other fields in the order record (e.g., urgency - STAT). In such a case, this field will be empty.

The filling service will often record a value in this field after receipt of the order, however, and compute an end time on the basis of the start date/time for the filling service’s internal use.

3.25.5 End date/time component (TS)

Definition: When filled in by the requester of the service, this field should contain the latest date/time that the service should be performed. If it has not been performed by the specified time, it should not be performed at all. The requester may not always fill in this value, yet the filling service may fill it in on the basis of the instruction it receives and the actual start time.

Regardless of the value of the end date/time, the service should be stopped at the earliest of the date/times specified by either the duration or the end date/time.

3.25.6 Priority component (ST)

Definition: This field describes the urgency of the request. The following values are suggested (the default for Priority is R):

S = Stat With highest priority

A = ASAP Fill after S orders

R = Routine Default

P = Preop

C = Callback

T = Timing critical A request implying that it is critical to come as close as possible to the requested time, e.g., for a trough antimicrobial level.

PRN = As needed

If using the value “T” (timing critical), the degree of criticality can be specified thus:

Format:

TS<integer> =  timing critical within <integer> seconds

TM<integer> =  timing critical within <integer> minutes

TH<integer> =  timing critical within <integer> hours

TD<integer> =  timing critical within <integer> days

TW<integer> =  timing critical within <integer> weeks

TL<integer> =  timing critical within <integer> months

For the sequential orders specification, these values specify the time criticality with which the predecessor order must be followed by the given order.

The priority component may repeat; separate repeating values with a space.

3.25.7 Condition component (ST)

Definition: This is a free text field that describes the conditions under which the drug is to be given. For example,

PRN pain , or to keep blood pressure below 110 . The presence of text in this field should be taken to mean that human review is needed to determine the how and/or when this drug should be given.

3.25.8 Text component (TX)

Definition: This field is a full text version of the instruction (optional).

3.25.9 Conjunction component (ID)

Definition: This non-null component indicates that a second timing specification is to follow using the repeat delimiter. This field can take three values as shown in HL7 table 0472 - TQ Conjunction ID.

HL7 table 0472 - TQ Conjunction ID

3.25.10 Order sequencing component (CM)

Definition: There are many situations, such as the creation of an order for a group of intravenous (IV) solutions, where the sequence of the individual intravenous solutions (each a service in itself) needs to be specified, e.g., hyperalimentation with multi-vitamins in every third bottle.

There are other situations where part of the order’s instructions contains a results condition of some type, such as “PRN pain.” There is currently a free text “condition” component of ORC-7-quantity/timing  which allows any condition to be specified. However, to support a fully encoded version of order sequencing, or results condition, we have defined in the following paragraphs a 10th component of ORC-7-quantity/timing.

The sequencing conditions supported by this 10th component are based on the completion of a predecessor service.

3.25.10.1 Subcomponents of sequences

To define a sequence condition, the 10th component of the quantity/timing field component is divided into the subcomponents described in Figure 3-2.

Figure 3-2. Subcomponents of order sequences

Use notes:

Suppose the following:

The predecessor order is defined by the OE1000&OrdEnt as the placer order number, in subcomponents 2 and 3 of component 10 of ORC-7-quantity/timing .

The successor order, this order, has the placer order number OE1001^OrdEnt in the ORC segment.

The following sequence condition values have the following meanings:

3.25.10.2 Cyclic placer order groups

For the special case where there is a cycle of orders that must be repeated, the first order to be executed will have a “sequence condition value” whose first character must be an asterisk (*). The last order to be executed may have a “sequence condition value” whose first character must be a pound sign (#).

Example:

Note:  This requires that the ordering application be able to specify the placer order number of the last order in the cycle in the first order’s quantity/timing specification.

To implement a cyclic group of four IV orders using the parent/child paradigm, the parent specifies a custom group of IVs, and the following occurs:

ORC-7-quantity/timing of the second child order specifies that it follows the first child order.

ORC-7-quantity/timing of the third child order specifies that it follows the second child order.

ORC-7-quantity/timing of the fourth child order specifies that it follows the third order.

To repeat the group of four child orders in a cyclic manner, the following occurs:

ORC-7-quantity/timing of the first child order specifies that it is to be executed once without any dependence on the completion of other orders.

Its second execution follows the completion of the fourth order. See example in HL7 International v2.4 Section 4.15.2, “RXO segment field examples

This scheme allows the following to be tracked:

The status of the whole group of orders to be reported back at the level of the parent order.

The status for each individual IV order by following the status of the corresponding child order.

Separate Orders example:

The same group of orders can be sent as a group of four orders (without a common parent), linked only by the data in their quantity/timing fields. In this case, there is no convenient HL7 method of transmitting the order status of the group as a whole without transmitting the status of each of the four separate orders.

3.25.10.3 Inheritance of order status

Cancellation/discontinuation/hold order control events:

This logic implies the normal execution of the referenced predecessor order. Thus a cancel (or discontinuation or hold) of a predecessor order implies the cancellation (or discontinuation or hold) of all  subsequent orders in the chain.

If the referenced order has been cancelled (or discontinued or held), the current order inherits that same status.

In the case of hold, the removal of the hold of the predecessor implies a removal of the hold for the given order (which can then be executed according to the specification in the 10th component).

3.25.11 Occurrence duration component (CE) )

Subcomponents: <identifier (ST)> & <text (ST)> & <name of coding system (IS)> & <alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding system>

Definition: This field contains the duration for a single performance of a service, e.g., whirlpool twenty minutes three times per day for three days. It is optional within TQ and does not repeat.

Note: The component delimiter in this CQ is demoted to a subcomponent delimiter.

3.25.12 Total occurrences component (NM) )

Definition: This field contains the total number of occurrences of a service that should result from this order. It is optional within TQ and does not repeat. If both the end date/time and the total occurrences are valued and the occurrences would extend beyond the end date/time, then the end date/time takes precedence. Otherwise the number of occurrences takes precedence.

3.25.13 Examples of quantity/timing usage

3^Once

Perform the service at one point in time, e.g., order 3 units of blood to be given once.

1^QHS^X2

Perform the service twice at bedtime, e.g., give a unit of blood at bedtime on two sequential nights.

1^C^D3

Do a service continuously for 3 days.

1^Q1H^X4^^^^PVCs>10/min

Perform an EKG every hour up to a maximum of 4 EKGs, if patient is having more than 10 PVCs per minute.

1^Q1J2^^200005231432

Perform a service every Tuesday at 2:32 p.m. starting on 05/23/2000.

1^^^^198911210800

Perform a test before 11/21/89 0800, e.g., some preop laboratory tests.

1^Q1H^X5^198911051030

Perform a service every hour for 5 hours starting at 10:30 a.m. 11/5/89, e.g., draw a blood glucose.

1^QAM^X3^^^^^^S~1^QOD^D4^^^^if K+>5.5

Perform a service every morning for 3 days and then do it every other day for 4 days (i.e., max twice) if the serum potassium is greater than 5.5.

^^^198812120800^^T^^Trough specimen for MIC^C~^^^^^R

The first repeat instructs to draw a blood specimen exactly at 8:00 a.m. on 12/12/1988. The second repeat specifies to report results routinely.

1^QD^D7^^^^^^^^M20

Whirlpool ankle for twenty minutes once a day for one week.

1^^^19990301^19990331^^^^^^H1^3

Three one hour home health nursing visits within the next month.

3.26 TS - time stamp

Format: YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of precision>

Contains the exact time of an event, including the date and time. The date portion of a time stamp follows the rules of a date field and the time portion follows the rules of a time field. The time zone (+/-ZZZZ) is represented as +/-HHMM offset from 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).

In prior versions of HL7, an optional second component indicates the degree of precision of the time stamp (Y = year, L = month, D = day, H = hour, M = minute, S = second). This optional second component is retained only for purposes of backward compatibility and should not be used in Australia except by site agreement.

By site-specific agreement, YYYYMMDD[HHMM[SS[.S[S[S[S]]]]]][+/-ZZZZ]^<degree of precision> may be used where backward compatibility must be maintained.

In the current and future versions of HL7, the precision is indicated by limiting the number of digits used, unless the optional second component is present. Thus, YYYY is used to specify a precision of “year,” YYYYMM specifies a precision of “month,” YYYYMMDD specifies a precision of “day,” YYYYMMDDHH is used to specify a precision of “hour,” YYYYMMDDHHMM is used to specify a precision of “minute,” YYYYMMDDHHMMSS is used to specify a precision of seconds, and YYYYMMDDHHMMSS.SSSS is used to specify a precision of ten thousandths of a second. In each of these cases, the time zone is an optional component. 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 TS 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). Maximum length of the time stamp is 26.

If a precision of Hour or greater is used a time zone should be specified.

Examples:

|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 birthdate, 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.

3.27 VID – version identifier

Components: <version ID (ID)> ^ <internationalization code (CE)> ^ <international version ID (CE)

Refer to MSH-12 Version ID (VID) 00012.

3.27.1 Version ID (ID)

Used to identify the HL7 version. Refer to HL7 Table 0104 - Version ID  for valid values.

3.27.2 Internationalization code (CE)

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 for the 3-character codes as defined by ISO 3166 table.

3.27.3 International version ID (CE)

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.

3.28 XAD - extended address

Components: <street address (SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ < address type (ID)> ^ <other geographic designation (ST)> ^ <county/parish code (IS)> ^ <census tract (IS)> ^ <address representation code (ID)> ^ <address validity range (DR)>

Subcomponents of street address (SAD): <street or mailing address (ST)> & <street name (ST)> & <dwelling number (ST)>Subcomponents of address validity range (DR): <date range start date/time (TS)> & <date range end date/time (TS)>

Note: Replaces the AD data type as of v 2.3.

Length: 250

Example of usage for US:

|1234 Easy St.^Ste. 123^San Francisco^CA^95123^USA^B^^SF^|

This would be formatted for postal purposes as

1234 Easy St.

Ste. 123

San Francisco CA 95123

Example of usage for Australia:

|14th Floor^50 Paterson St^Coorparoo^QLD^4151|

This would be formatted for postal purposes using the same rules as for the American example as

14th Floor

50 Paterson St

Coorparoo QLD 4151

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.

3.28.1 Street address (SAD)

Components: <street or mailing address (ST)> ^ <street name (ST)> ^ <dwelling number (ST)>
Note: Appears ONLY in the XAD data type

Note that in the context of an XAD the delimiters of SAD must appear as & subcomponents. i.e. <street or mailing address (ST)> & <street name (ST)> & <dwelling number (ST)>

3.28.1.1 Street or mailing address (ST)

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.

3.28.1.2 Street name (ST)

3.28.1.3 Dwelling number (ST)

3.28.2 Other designation (ST)

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.

3.28.3 City (ST)

This may be the name of the city, or district or place depending upon the national convention for formatting addresses for postal usage.

3.28.4 State or province (ST)

State or province should be represented by the official postal service codes for that country.

3.28.5 Zip or postal code (ST)

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.

3.28.6 Country (ID)

Defines the country of the address. ISO 3166 provides a list of country codes that may be used. 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. HL7 Table 0399 - Country code  is defined to contain these 3-character codes.

3.28.7 Address type (ID)

Address type is optional and defined by HL7 Table 0190 - Address type.

3.28.8 Other geographic designation (ST)

Other geographic designation includes county, bioregion, SMSA, etc.

3.28.9 County/parish code (IS)

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.

User-defined Table 0289 – County/parish

3.28.10 Census tract (IS)

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.

User-defined Table 0288 – Census tract

3.28.11 Address representation code (ID)

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.

3.28.12 Address validity range (DR)

This component contains the start and end date/times which define the period in which this address was valid

3.28.12.1 Date range start date/time (TS)

3.28.12.2 Date range end date/time (TS)

3.29 XCN - extended composite ID number and name for persons

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

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

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

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

Subcomponents of name context: <identifier (ST)> & <text (ST)> & <name of coding system (IS)> & <alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding system (IS)>

Subcomponents of name validity range: <date range start date/time (TS)> & <date range end date/time (TS)>

Note: Replaces CN data type as of v 2.3.

Length: 250

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^Smith^John^J^III^DR^PHD^ADT01^^L^4^M11^MR|

Examples with assigning authority and assigning facility:

Dr. Samuel Semmelweiss's provider ID was assigned by the Provider Master and was first issued at Fairview Hospital within the University 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^Semmelweiss^Samuel^S^IV^Dr^MD^^&Provider Master.University Hospitals&L^L^9^M10^DN^&Fairview Hospital.University 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.University Hospitals&L^L^3^M10^MR^&Fairview Hospital.University Hospitals&L^A

The XCN data type is used for doctor references including the referring doctor (PV1-8) Referring doctor, the receiving doctor (PV1-9) Consulting doctor and result copies to (OBR-28) Result copies to.

In the Australian context, where possible, XCN data must be populated using the method described in Appendix 10 Addressing messages using Australian Profile for Provider Directory Services (Normative).

Example:  

|7654321A^Brown^Julie^^^Dr^^^AUSHICPR|

The key identifier for doctors is the Medicare Provider Number as it is specific for a particular address and it must be included for all doctors if possible. Although pathology providers maintain their own doctor addressing data tables, the Medicare Provider Number is key for determination of entitlements and addressing.

Component requirements:

<ID (ST)> component must be specified and valid according to the identifier scheme of selected by the Identifier type code and Assigning Authority components.

<assigning authority (HD)> component must be valued and valid.

<name type code (ID)> component should be valued and valid from HL7 Table 200.

<identifier type code (ID)> component should be valued with a valid value from HL7 Table 203.

<family name (FN)> :<surname (ST)> sub-component should to be valued.

<given name (ST)> should to be valued.

3.29.1 ID number (ST)

This string refers to the coded ID according to a user-defined table, defined by the 9th component. If the first component is present, either the source table or the assigning authority must be valued.

3.29.2 Family name (FN)

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. 

3.29.3 Given name (ST)

First name.

3.29.4 Second and further given names or initials thereof (ST)

Multiple middle names may be included by separating them with spaces.

3.29.5 Suffix (ST)

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

3.29.6 Prefix (ST)

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

3.29.7 Degree (IS)

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

3.29.8 Source table (IS)

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.

User-defined Table 0297 – CN ID source

3.29.9 Assigning authority (HD)

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

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.

3.29.10 Name type code (ID)

A code that represents the type of name. Refer to HL7 Table 0200 - Name type for valid values.

3.29.11 Identifier check digit (ST)

The check digit in this data type is not an add-on produced by the message processor. It is the check digit that is part of the identifying number used in the sending application. If the sending application does not include a self-generated check digit in the identifying number, this component should be valued null.

3.29.12 Code identifying the check digit scheme employed (ID)

Refer to HL7 Table 0061 - Check digit scheme for valid values.

HL7 Table 0061 - Check digit scheme 

3.29.13 Identifier type code (IS)

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.

3.29.14 Assigning facility (HD)

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.

3.29.15 Name representation code (ID)

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.

HL7 Table 0465 - Name/address representation

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.

3.29.16 Name context (CE)

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 is for hinting that a XCN may represent a healthcare service or practitioner role to support Australian Profile for Provider Directory Services reverse lookups. 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.

User-defined Table 0448 – Name context

3.29.17 Name validity range (DR)

This component contains the start and end date/times that define the period during which this name was valid. See DR - date/time range for description of subcomponents.

3.29.18 Name assembly order (ID)

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.

HL7 Table 0444 – Name assembly order 

3.30 XON - extended composite name and identification number for organizations

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

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

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

Length: 250

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 Fairview Hospital was assigned by the University Hospital enterprise’s Hospital Master and was first issued at the Central Offices.

 Fairview Hospital^L^716^9^M10^&Hospital Master.University Hositals&L^XX^&Central Offices.University Hospitals&L^A

Example 2:

Fairview Hospital has another ID that was issued by HCFA. Assigning Authority, HCFA, values only the first HD component, an IS data type and assigning facility is not relevant. This information might be transmitted accordingly:

Fairview Hospital^L^4544^3^M10^HCFA^XX^^A

3.30.1 Organization name (ST)

The name of the specified organization.

3.30.2 Organization name type code (IS)

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.

User-defined Table 0204 - Organizational name type

3.30.3 ID number (NM)

3.30.4 Check digit (NM)

The check digit in this data type is not an add-on produced by the message processor. It is the check digit that is part of the identifying number used in the sending application. If the sending application does not include a self-generated check digit in the identifying number, this component should be valued null.

3.30.5 Code identifying the check digit scheme employed (ID)

The check digit scheme codes are defined in HL7 Table 0061 - Check digit scheme.

3.30.6 Assigning authority (HD)

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. 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, implementers may continue to use User-defined Table 0300 - Namespace ID for the first sub-component.

3.30.7 Identifier type code (IS)

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.

3.30.8 Assigning facility ID (HD)

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.

3.30.9 Name representation code (ID)

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.

3.31 XPN - extended person name

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

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

Subcomponents of name context: <identifier (ST)> & <text (ST)> & <name of coding system (IS)> &<alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding system (IS)>

Subcomponents of name validity range: <date range start date/time (TS)> & <date range end date/time (TS)>

Length: 250

Note: Replaces PN data type as of v 2.3.

Example:

 |Smith^John^J^III^DR^PHD^L|

3.31.1 Family name (FN )

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. 

3.31.2 Given name (ST)

First name.

3.31.3 Second and further given names or initials thereof (ST)

Multiple middle names may be included by separating them with spaces.

3.31.4 Suffix (ST)

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

3.31.5 Prefix (ST)

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

3.31.6 Degree (IS)

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

User-defined Table 0360 - Degree

 3.31.7 Name type code (ID)

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.

3.31.8 Name representation code (ID)

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.

3.31.9 Name context (CE)

Subcomponents of name context: <identifier (ID)> & <text (ST)> & <name of coding system (IS)> & <alternate identifier (ID)> & <alternate text (ST)> & <name of alternate coding system (IS)>

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.

User-defined Table 0448 – Name context

3.31.10 Name validity range (DR)

This component contains the start and end date/times which define the period during which this name was valid. See "DR - date/time range" for description of subcomponents.

3.31.11 Name assembly order (ID)

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.

3.32 XTN - extended telecommunication number

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

Note: Replaces TN data type as of v 2.3

Length: 250

Example:

(415)555-3210^ORN^FX^

3.32.1 [(999)] 999-9999 [X99999] [C any text]

Defined as the TN data type (see HL7 International v2.4 Section 2.9.45, “TN - telephone number”), except that the length of the country access code has been increased to three.

3.32.2 Telecommunication use code (ID)

A code that represents a specific use of a telecommunication number. Refer to HL7 Table 0201 - Telecommunication use code for valid values.

HL7 Table 0201 - Telecommunication use code

3.32.3 Telecommunication equipment type (ID)

A code that represents the type of telecommunication equipment. Refer to HL7 Table 0202 - Telecommunication equipment type for valid values.

HL7 Table 0202 - Telecommunication equipment type

3.32.4 Email address (ST)

Internationalization note:  To make this data type interoperate with CEN’s Telecommunication data attribute group, we allow use of the second component for email addresses. The presence of an email address is specified by the addition of the value NET  to the Phone Use Code table, and the type of Internet address is specified with the values Internet  and X.400  to the Phone Equipment Type table. When used for an Internet address, the first component of the XTN data type will be null. If the @-sign is being used as a subcomponent delimiter, the HL7 subcomponent escape sequence may be used when encoding an Internet address (see HL7 International v2.4 Section 2.10.1, “Formatting codes”).

Note: Components five through nine reiterate the basic function of the first component in a delimited form that allows the expression of both local and international telephone numbers. In Version 2.3, the recommended form for the telephone number is to use the delimited form rather than the unstructured form supported by the first component (which is left in for backward compatibility only).