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