Note: Used only in the LA1 data type. Retained for backward compatibility as of v2.6. Replaced elsewhere by the XAD data type as of v2.3.

Example:

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

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

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

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

Attention: _Retained for backward compatibility onlyas of v 2.7_. This is used only in the waveform message, CHM category, which has been retained for backward compatibility only in v 2.7.

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

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

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

Example:

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

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

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

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

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

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

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

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

Example:

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

Examples:

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

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

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

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

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

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

[#CWE_UsageNote .anchor]##Usage Notes: The CWE data type should be used for coded fields with one or more of the following characteristics:

• The identifier code (CWE.1) component is optional

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

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

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <table border="1"> <tr> <th>Identifier Code Status </th> <th>Identifier Code (CWE.1) </th> <th>Descriptive Text (CWE.2) </th> <th>Coding System (CWE.3)</th> </tr> <tr> <td>Contained in model value set </td> <td>Populated </td> <td>May be populated </td> <td>Must be populated with model coding system, or (not recommended) site-specific coding system that is a superset containing model values.</td> </tr> <tr> <td>Contained in site-specific extensions to model value set </td> <td>Populated </td> <td>May be populated </td> <td>Site-specific coding system.</td> </tr> <tr> <td>Contained in neither model nor extended value sets </td> <td>Not populated </td> <td>May be populated with the identifier code, free-text description, or a concatenation of the two. Should be human interpretable. </td> <td>Must not be populated.</td> </tr> <tr> <td>Not supplied; but descriptive text is supplied. </td> <td>Not populated </td> <td>May be populated with descriptive text. </td> <td>Must not be populated.</td> </tr> </table>

As an example, consider “currency” codes where:

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

• The value set is extended on site to include the code HL7 – “HL7 Drink Ticket”, and

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

And so the value set used on site is:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <table border="1"> <tr> <th>Identifier Code Status </th> <th>Identifier Code </th> <th>Descriptive Text</th> </tr> <tr> <td>Model values from ISO 4217 external table </td> <td>AED </td> <td>United Arab Emirates, Dirhams</td> </tr> <tr> <td> </td> <td>AFA </td> <td>Afghanistan, Afghanis</td> </tr> <tr> <td> </td> <td>ALL </td> <td>Albania, Leke</td> </tr> <tr> <td> </td> <td>&hellip; </td> </tr> <tr> <td> </td> <td>ZAR </td> <td>South Africa, Rand</td> </tr> <tr> <td> </td> <td>ZMK </td> <td>Zambia, Kwacha</td> </tr> <tr> <td> </td> <td>ZWD </td> <td>Zimbabwe, Zimbabwe Dollars</td> </tr> <tr> <td>Site-specific extension </td> <td>HL7 </td> <td>HL7 Events, Drink Ticket</td> </tr> </table>

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <table border="1"> <tr> <th>Entered by user </th> <th> </th> <th>Sent in CWE </th> <th> </th> </tr> <tr> <td>Code </td> <td>Descriptive Text </td> <td>Identifier Code (CWE.1) </td> <td>Descriptive Text (CWE.2) </td> <td>Coding System (CWE.3)</td> </tr> <tr> <td>GBP </td> <td>Great Britain, Pound </td> <td>GBP </td> <td>Great Britain, Pound </td> <td>ISO4217</td> </tr> <tr> <td> </td> <td> </td> <td>GBP </td> <td>Great Britain, Pound </td> <td>99CUR (This option is NOT recommended)</td> </tr> <tr> <td>HL7 </td> <td>HL7 Drink Ticket </td> <td>HL7 </td> <td>HL7 Drink Ticket </td> <td>99CUR</td> </tr> <tr> <td>XXX </td> <td>&lt;Bogus entry&gt; </td> <td>Must not be populated </td> <td>XXX </td> <td>Must not be populated.</td> </tr> <tr> <td> </td> <td> </td> <td>Must not be populated </td> <td>Bogus entry </td> <td>Must not be populated.</td> </tr> <tr> <td> </td> <td> </td> <td>Must not be populated </td> <td>XXX: Bogus entry </td> <td>Must not be populated.</td> </tr> <tr> <td> </td> <td> </td> <td>Must not be populated </td> <td>anything &ndash; or nothing. </td> <td>Must not be populated.</td> </tr> <tr> <td> </td> <td>Dollar </td> <td>Must not be populated </td> <td>Dollar </td> <td>Must not be populated.</td> </tr> <tr> <td> </td> <td> </td> <td>Valued from HL7 Table 0353 (e.g., &ldquo;U&rdquo; for unknown) </td> <td>Dollar </td> <td>HL70353</td> </tr> </table>

Notes:

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

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

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

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

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

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

Example:

Abstract base for complex data types

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

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

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

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

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

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

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

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

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

Note: If used in the Error segment (ERR) in Error Location (ERR-2), then it defines where the error has occurred. If used in the Access Restrictions segment (ARV) in Access Restricted HL7.Message Elements (ARV-8) then it identifies the data, the security labels as defined in other attributes of the same ARV segment apply to.

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

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

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

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

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

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

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

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

Examples:

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

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

Example 2: A UUID example

Example 3: A DNS example

Local examples:

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

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

Example 5: Local identifier using components 2 and 3 only [.underline]#(Deprecated as of v2.8 and will be withdrawn in V2.10)#

An alternate way to encode the previous example, illustrating the use of the third component value of "M" (see file:///E:\V2\v2.9%20final%20Nov%20from%20Frank\V29CH02C_Tables.docx#HL70301[_HL7 Table 0301 - Universal ID type] below) to identify a locally-defined identifier set. The second component has the same value as the previous example but is now defined to be a member of a set of allowable values defined by a site for the identifier set “M”. [.underline]#The use of local coding schemes as Universal ID Types is deprecated as of v 2.8; assigning authorities should be identified with true Universal IDs.#

Example 6: local identifier and universal ID types:

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.

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

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

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

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

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

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

Use Case: Commercial EEG instruments

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

Example 2: 1 channel, 11 time-samples

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

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

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

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

Example 1: vector of 8 numbers

Example 2: 3 x 3 array of numbers

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

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

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

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

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

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

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

Example:

Note: In original mode, OG.1 plus OBX-3 provides uniqueness; in enhanced mode OG.2 and OG.3 plus OBX-3 will provide uniqueness; OG.4 may not be present.

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

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

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

Note: This data type contains several location identifiers that should be thought of in the following order from the most general to the most specific: facility, building, floor, point of care, room, bed. +

Additional data about any location defined by these components can be added in the following components: person location type, location description and location status.

Example: Nursing Unit

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

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

Example: Clinic

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

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

Example: Home

The patient was treated at his home.

^^^^^H^^^

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

Usage Note: This data type is applied only to OBR-26 - Parent Result where it serves to make information available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29 - Parent, uniquely identifies the parent result’s OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports. For example, if the current battery is an antimicrobial susceptibility, the parent results identified OBX contains a result that identifies the organism on which the susceptibility was run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization.

We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs.

This field is present only when the parent result is identified by OBR-29 - Parent and the parent spawns child orders for each of many results. See Chapter 7, "Observations", for more details about this linkage.

Note: Replaces the CM data type used in sections 4.5.3.26 - OBR-26 and 7.4.1.26 - OBR-26 as of v 2.5.

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

Example:

Note: This field conveys the same information as the "WHERE" clause in the corresponding SQL expression of the query, but is formatted differently.

Example:

Example: This defines a column containing the value of the "last name" component of PID-5, expressed as a ST data type with a maximum width of 20.

Note: Replaces the CM data type used in sections 8.8.4.6 - OM2-6, 8.8.4.7 - OM2-7 and 8.8.4.8 - OM2-8 as of v 2.5.

Examples:

{empty}a) A range that applies unconditionally, such as albumin, is transmitted as:

{empty}b) A normal range that depends on sex, such as Hgb, is transmitted as:

{empty}c) A normal range that depends on age, sex, and race (a concocted example) is:

When no value is specified for a particular component, the range given applies to all categories of that component. For example, when nothing is specified for race/species, the range should be taken as the human range without regard to race. If no age range is specified, the normal range given is assumed to apply to all ages.

Note: The reader is referred to the link:#a.2.67-rpt-repeat-pattern[RPT – Repeat pattern] data type, which provides a more rigorous framework for defining repeating time intervals.

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

When using the RPT, if an application doesn't recognize the code in component 1, then it may attempt to determine the appropriate frequency using the remaining components. If the application does recognize the code in component 1, the application is not required to determine the frequency from the remaining components.

Use Case: The use case supporting this proposal is the need to define repeat patterns on the fly while placing an order. The TQ data type did not have the capability to define the meaning of a repeat pattern on the fly. To get around this problem, vendors have implemented a variety of solutions to solve this issue. One way was to add Z-components to the TQ data type to transmit information about the repeat pattern. Another solution was to attempt to parse the repeat pattern code in an attempt to decipher what the code meant.

Examples:

Note: Appears ONLY in the XAD data type

For use only with the scheduling chapter.

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

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

Example: In a tabular response query, where the return data is known by column name, the SRT might look like:

Example: In a segment response query, where the return data is known by segment and offset, the SRT field would use segment field name notation:

This data type is used to convey information defined by CMS or other regulatory agencies. It corresponds to UB fields 46A, 47A, 48A, 49A, 46B, 47B, 48B, and 49B and UB92 fields 39a, 39b, 39c, 39d, 40a, 40b, 40c, 40d, 41a, 41b, 41c, and 41d.

Note: Replaces the CM data type used in sections 6.5.10.10 UB1-10 and 6.5.11.6 UB2-6, as of v 2.5.

The most common semi-private room rate is used in instances where the patient is placed in a private room at their request but their insurance only covers a semi-private room rate, which can be calculated using the 01-most common semi-private room rate.

Example:

Note: Replaces the CM data type used in 5.10.5.3.11 QRD-11 as of v 2.5.

The VR differs from the Numeric Range (NR) data type only in that the values are not restricted to numbers. If the range is not numeric, the set must be orderable in some intuitive way such as alpha or the order must be defined in the field where the data type is used.

Example 1:

Example 2: Colors of the rainbow

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

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

Attention: _Retained for backward compatibility only in v2.7._ It is used only in the CD Channel Definition data type, which has been retained for backward compatibility only in v2.7.

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

Note: Replaces the AD data type as of v2.3.

Example of usage for US:

This would be formatted for postal purposes as

1000 Hospital Lane

Ste. 123

Ann Arbor MI 99999

Example of usage for Australia:

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

14th Floor

1000 Hospital Lane

Sidney QLD 9999

International note: Countries typically have a standard method of formatting addresses. This data type does not specify the formatting usages, only the components of a postal address.

Note: Replaces CN data type as of v 2.3.

This data type is used extensively appearing in the PV1, ORC, RXO, RXE, OBR and SCH segments, as well as others, where there is a need to specify the ID number and name of a person.

Example without assigning authority and assigning facility:

Examples with assigning authority and assigning facility:

Dr. Harold Hippocrates’ provider ID was assigned by the Provider Master and was first issued at Good Health Hospital within the Community Health and Hospitals System. Since IS table values (first component of the HD) were not used for assigning authority and assigning facility, components 2 and 3 of the HD data type are populated and demoted to sub-components as follows:

12188^Hippocrates^Harold^H^IV^Dr^^^&Provider Master.Community Health and Hospitals&L^L^9^M10^DN^&Good Health Hospital.Community Health and Hospitals&L^A

Ludwig van Beethoven's medical record number was assigned by the Master Patient Index and was first issued at Fairview Hospital within the University Hospitals System.

10535^van Beethoven&van^Ludwig^A^III^Dr^^^&MPI.Community Health and Hospitals&L^L^3^M10^MR^& Good Health Hospital.Community Health and Hospitals&L^A

This data type is used in fields (e.g., PV2-23, NK1-13, PD1-3, OBR-44) to specify the name and ID number of an organization.

Example 1:

The ID for Good Health Hospital was assigned by the Community Health and Hospitals enterprise’s Hospital Master and was first issued at the Central Offices.

Good Health Hospital^L^716^9^M10^&Hospital Master.Community Health and Hospitals&L^XX^&Central Offices.Community Health and Hospitals&L^A

Example 2:

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

Good Health Hospital^L^4544^3^M10^CMS^XX^^A

Note: Replaces PN data type as of v 2.3.

Internationalization Note: In countries using ideographic or syllabic (phonetic) character sets, it is sometimes necessary to send the name in one or both of these formats, as well as an alphabetic format. The switching between the different character sets can be accomplished using a character set such as JIS X 0202 - ISO 2022 which provides an escape sequence for switching among different character sets and among single-byte and multi-byte character representations. When the name field is repeated, the different repetitions of the name may be represented by these different character sets. The details are as follows. (See also Section 2.9.2, “Escape sequences supporting multiple character sets for PN, XPN, XCN, XON, XAD, FT, ST and TX data types.”)

HL7 supports the following standards for Japanese characters:

JIS X 0201 for ISO-IR 13 (Japanese Katakana)

JIS X 0201 for ISO-IR 14 (Japanese Romaji)

JIS X 0208 for ISO-IR 87 (Japanese Kanji, Hiragana and Katakana)

JIS X 0212 for ISO-IR 159 (supplementary Japanese Kanji)

HL7 supports the following standards for European characters:

ISO 8859 (1-9) for ISO-IR 100, 101, 109, 110, 144,127, 126, 138 and 148.

Character sets are referenced in HL7 as ASCII, 8859/1,8859/2, ISO IR14, ISO IR87, and ISO IR159. DICOM uses codes laid out in ISO 2375, of the form 'ISO-IR xxx'. HL7 supports this naming as well, to facilitate interoperability.

HL7 uses the Basic G0 Set of the International Reference Version of ISO 646:1990 (ISO IR-6) as the default character repertoire for character strings. This is a single-byte character set, identical to ASCII.

Each repetition of a XPN, XON, XCN, or XAD field is assumed to begin with the default character set. If another character set is to be used, the HL7 defined escape sequence used to announce that character set must be at the beginning of the repetition, and the HL7 defined escape sequence used to start the default character set must be at the end of the repetition. Note also that several character sets may be intermixed within a single repetition as long as the repetition ends with a return to the default character set.

An application must specify which character sets it supports in the field MSH-18 Character Sets and which character set handling scheme it supports in the field MSH-20 Alternate Character Set Handling Scheme. It is assumed that the sending and receiving applications are aware of how to map character set names (i.e., ISO-IR xxx) to escape sequences.

For example, in many Japanese messages there is a mix of Romaji (i.e., Roman characters), Katakana (phonetic representation of foreign words), Hiragana (phonetic representation of Japanese words) and Kanji (pictographs). Such a message would require 4 character sets be specified in the MSH.

References for Internationalization of Name

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <table border="1"> <tr> <th> </th> <th>Reference </th> <th>Description</th> </tr> <tr> <td>1. </td> <td>&ldquo;Understanding Japanese Information Processing&rdquo; by Ken Lunde, O&rsquo;Reilly Press </td> </tr> <tr> <td>2. </td> <td>NEMA PS3.5 - DICOM Part 5: Data Structure and Semantics </td> </tr> <tr> <td>3. </td> <td>ANSI X3.4:1986 </td> <td>ASCII character set</td> </tr> <tr> <td>4. </td> <td>ISO 646:1990 </td> <td>Information Processing - ISO 7-bit coded character set for information interchange</td> </tr> <tr> <td>5. </td> <td>ISO/IEC 2022:1994 </td> <td>Information Technology - Character code structure and extension techniques</td> </tr> <tr> <td>6. </td> <td>ISO 2375:1986 </td> <td>Data Processing - Procedure for the registration of escape sequences</td> </tr> <tr> <td>7. </td> <td>ISO 6429:1990 </td> <td>Information Processing - Control functions for 7-bit and 8-bit coded character sets</td> </tr> <tr> <td>8. </td> <td>ISO 8859 (1-9) </td> <td>Information Processing - 8-bit single-byte coded graphic character sets - parts 1-9</td> </tr> <tr> <td>9. </td> <td>ENV 41 503:1990 </td> <td>Information systems interconnection - European graphic character repertoires and their coding</td> </tr> <tr> <td>10. </td> <td>ENV 41 508:1990 </td> <td>Information systems interconnection - East European graphic character repertoires and their coding</td> </tr> <tr> <td>11. </td> <td>JIS X 0201-1976 </td> <td>Code for Information Exchange</td> </tr> <tr> <td>12. </td> <td>JIS X 0212-1990 </td> <td>Code of the supplementary Japanese Graphic Character set for information interchange</td> </tr> <tr> <td>13. </td> <td>JIS X 0208-1990 </td> <td>Code for the Japanese Graphic Character set for information interchange</td> </tr> <tr> <td>14. </td> <td>RFC 1468 </td> <td>Japanese Character Encoding for Internet Messages</td> </tr> </table>

Character Repertoires supported by DICOM are defined in Part 5, section 6.1. The DICOM Standard is available free on the Internet at http://medical.nema.org/[http://medical.nema.org/].

Examples of names requiring only one iteration of the field where the XPN is applied:

Example 1: Adam A. Everyman III PhD

Example 2: Ludwig van Beethoven

Example 3: Hermann Egon Mayer zur alten Schildesche

Example 4: Sister Margot

Example 5: Dr Harold Henry Hippocrates AO. MBBS. ASCTS. A physician who holds an Honorarium, an academic degree and a board certificate. Professional suffixes are displayed as concatenated. (AO = Order of Australia (Honorarium), MBBS = Bachelor of Medicine and Bachelor of Surgery, ASCTS = Australian Society of Cardiothoracic Surgeons

Example 6: Nancy N. Nightingale, RN, PHN, BSN, MSN. A registered nurse who is a Public Health Nurse with 2 academic degrees, BSN and MSN.

Example 7: H.Horrace Helper Jr., RN, CNP. A registered nurse who is a certified nurse practitioner.

Example 8: Mevrouw Irma Jongeneel de Haas.

An individual whose birth name (geboortenaam) is de Haas and whose partner's name is Jongeneel.

Examples of names requiring more than one iteration of the field where the XPN is applied:

Example 9: Herr Prof. Dr. med. Joachim W. Dudeck

Example 10: Herr Dr. Otto Graf Lambsdorff mdB a.D.

According to German law “Adelstitel” like “Graf” or “Baron” belongs to the family name and therefore must be encoded in the family name field separated by blanks.

Example 11: Walter Kemper genannt (named) Mölleken

Example 12: Herr Dr. med. Dr. h.c. Egon Maier

Example 13: Herr Dipl.Ing. Egon Maier

Example 14: Frau Gerda Müller geb. Maier, verheiratet seit 16.2.2000

Example 15: President Adam A Everyman III, president from 1997 until 2001, aka Sonny Everyman

Example 16: Michio Kimura

This example doesn’t use title and degrees, but shows the repetition of this name for different purposes. The first iteration is the legal name in Kanji; the second, Katakana; the third, alphabetic.

image:extracted-media/media/image1.png[extracted-media/media/image1]

Example 1: A Work fax number

^WPN^FX^^^734^6777777

Example 2: Telephone number with extension

^WPN^PH^^^734^6777777^1

Example 2: Telephone number with internal code. In this example, assume that a corporation's telephone system supports a full external telephone number (area code and telephone number). It also supports internal dialing standards that assign a code to each facility and an extension to each telephone (which happens to be the last 4 digits of the external telephone number, by convention).

So, if the Los Angeles facility were assigned code 333, and if the "outside" telephone number at the LA office is (626) 555-1234, the components would be:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <table border="1"> <tr> <th>Component </th> <th>Value</th> </tr> <tr> <td>area/city code </td> <td>626</td> </tr> <tr> <td>phone number </td> <td>555-1234</td> </tr> <tr> <td>extension </td> <td>1234</td> </tr> <tr> <td>extension prefix </td> <td>333</td> </tr> </table>

The field would be transmitted as follows:

^WPN^PH^^^626^5551234^1234^333

Example 3: speed dial. In this example, assume that a corporation's telephone system supports speed dialing numbers. For example, suppose that a corporation has a contract with a travel agency, whose external number is 1-610-555-1234. Since it is so frequently dialed, the company assigns a speed code: #6098. The components would be:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <table border="1"> <tr> <th>Component </th> <th>Value</th> </tr> <tr> <td>Area/city code </td> <td>610</td> </tr> <tr> <td>Phone number </td> <td>555-1234</td> </tr> <tr> <td>Speed Dial </td> <td>#6098</td> </tr> </table>

The field would be transmitted as follows:

^WPN^PH^^^610^5551234^^^#6098

Example 4: home e-mail address. In this example, assume that a person has a primary home e-mail address such as someone@somewhere.com. The components would be:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <table border="1"> <tr> <th>Component </th> <th>Value</th> </tr> <tr> <td>Telecommunication Use Code </td> <td>PRN</td> </tr> <tr> <td>Telecommunication Equipment Type </td> <td>Internet</td> </tr> <tr> <td>Communication Address </td> <td>someone@somewhere.com</td> </tr> </table>

The field would be transmitted as follows:

^PRN^Internet^someone@somewhere.com

Example 5: work e-mail address. In this example, assume that a person has a work e-mail address such as someone@somewhere.com. The components would be:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> <table border="1"> <tr> <th>Component </th> <th>Value</th> </tr> <tr> <td>Telecommunication Use Code </td> <td>WPN</td> </tr> <tr> <td>Telecommunication Equipment Type </td> <td>Internet</td> </tr> <tr> <td>Communication Address </td> <td>someone@somewhere.com</td> </tr> </table>

The field would be transmitted as follows:

^WPN^Internet^someone@somewhere.com

Rules that are true for all complex data type definitions

Rules that are true for all primitive type definitions

FIXME

FIXME

FIXME

FIXME

FIXME

FIXME

FIXME add from v2

FIXME add from v2

FIXME

FIXME add from v2

FIXME

FIXME

HL7 v2 Complex Data Type URLs

HL7 v2 Complex Data Types

HL7 v2 Primitive Data Type URLs

HL7 v2 Primitive Data Types

All HL7 v2 Data Types

HL7 v2 Complex Data Types

v2 Complex Data Type URLs

v2 Primitive Data Type URLs

HL7 v2 Primitive Data Types