| Data Type |
Description |
| ST |
String Data:
String data is left justified with trailing blanks optional. Any displayable (printable) ACSII characters (hexadecimal values between 20 and 7E, inclusive).
|almost any data| |
| TX |
Text data:
String data meant for user display (on a terminal or printer). Such data would not necessarily be left justified since leading spaces may contribute greatly to the clarity of the presentation to the user. Because this type of data is intended for display, it may contain certain escape character sequences designed to control the display. Escape sequence formatting is defined later in this chapter in Section 2.4.6. Leading spaces should be included. Trailing spaces should be removed.
Since TX data is intended for display purposes, the repeat delimiter, when used with a TX data field, implies a series of repeating lines to be displayed on a printer or terminal. Therefore, the repeat delimiters are regarded as paragraph terminators or hard carriage returns (e.g., they would display as though a CR/LF were inserted in the text).
A receiving system would word-wrap the text between repeat delimiters in order to fit it into an arbitrarily sized display window but start any line beginning with a repeat delimiter on a new line.
| leading spaces are allowed.|
|
| FT |
Formatted text data:
This data type is derived from the string data type by allowing the addition of embedded formatting instructions. These instructions are limited to those that are intrinsic and independent of the circumstances under which the field is being used. The actual instructions and their representation are described later in this chapter. The differences from a string data field and an FT field is of arbitrary length (up to 65k) and may contain formatting commands enclosed in escape characters.
|.sp(skip one vertical line)| |
| NM |
Numeric data:
A number represented as a series of ASCII numeric characters consisting of an optional leading sign (+ or -), the digits and an optional decimal point. In the absence of a sign, the number is assumed to be positive. If there is no decimal point the number is assumed to be an integer.
Leading zeros, or trailing zeros after a decimal point, are not significant. The two values 01.20 and 1.2 are identical. Except for the optional leading sign (+ or -) and the optional decimal point (.), no non-numeric ASCII characters are allowed. Thus, the value <12 should be encoded as a string data type.
|999|
|-123.792|
|
| DT |
Date data:
Always in the format YYYYMMDD.
|19880704| |
| TM |
Time data:
Always in the format HHMM[SS[.SSSS]][+/-ZZZZ] using a 24 hour clock notation. The seconds designation (SS) is optional. If not present it will be interpreted as 00. The fractional seconds designation is likewise optional. If not present it will be interpreted as .0000. The fractional seconds could be sent by a transmitter who requires greater precision than whole seconds. Fractional representations of minutes, hours or other higher orders units of time are not permitted. The time zone of the sender may be sent optionally as an offset from the coordinated universal time (previously known as Greenwich Mean Time.) Where the time zone is not present in a particular TM field but is included as part of the date/time field in the MSH segment, the MSH value will be used as the default time zone. Otherwise, the time is understood to refer to the local time of the sender. Midnight is represented as 0000.
|235959+1130| 1 second before midnight in a time zone eleven and half hours ahead of Universal Coordinated Time (i.e., east of Greenwich).
|0800| Eight AM, local time of the sender.
|093544.2312| 44.2312 seconds after Nine thirty-five AM, local time of sender.
|
| TS |
Time Stamp data:
Contains the exact time of an event, including the date and time. Time stamp fields are always in the format:
YYYYMMDD[HHMM[SS[.SSSS]]][+/-ZZZZ]^<degree of precision>
The date portion of a time stamp follows the rules of a date field and the time portion follows the rules of a time field. When used as a birthdate, the HHMM portion is optional. If not present the HHMM portion will default to 0000, i.e., midnight of the day just beginning. The specific data representations used in the HL7 encoding rules are compatible with ISO 8824-1987(E). An optional second component indicates the degree of precision of the date (Y = year, L = month, D = day, H = hour, M = minute, S = second). (Maximum length of field is 26).
The HL7 Standard strongly recommends that all systems routinely send the time zone offset but does not require it. All HL7 systems are required to accept the time zone offset, but its implementation is application specific. For many applications the time of interest is the local time of the sender. For example, an application in the Eastern Standard Time zone receiving notification of an admission that takes place at 11:00 PM in San Francisco on December 11 would prefer to treat the admission as having occurred on December 11 rather than advancing the date to December 12.
One exception to this rule would be a clinical system that processed patient data collected in a clinic and a nearby hospital that happens to be in a different time zone. Such applications may choose to convert the data to a common representation. Similar concerns apply to the transitions to and from daylight saving time. HL7 supports such requirements by requiring that the time zone information be present when the information is sent. It does not, however, specify which of the treatments discussed here will be applied by the receiving system.
|17760704010159-0600| 1:01:59 on July 4, 1776 in the Eastern Standard Time zone.
|17760704010159-0500| 1:01:59 on July 4, 1776 in the Eastern Daylight Saving Time zone.
|198807050000| Midnight of the night extending from July 4 to July 5, 1988 in the local time zone of the sender.
|198807050000^D| Same as prior example, but precision extends only to the day. Could be used for a birth date.
|
| PN |
Person Name data:
<family name> ^ <given name> ^ <middle initial or name> ^ <suffix (e.g., JR or III)> ^ <prefix (e.g., DR)> ^ <degree (e.g., MD)>
A name includes multiple free text components as listed above. The maximum length of a PN field is 48 characters including component separators. The sending system may send upper- and lowercase or all uppercase. The receiving system may convert to all uppercase if required.
|SMITH^JOHN^J^III^DR^PHD|
|
| TN |
Telephone Number data:
For use in the United States and conforming countries, the telephone number is always in the form:
[NN] [(999)]999-9999[X99999][B99999][C any text]
The optional first two digits are the country code. The optional X portion gives an extension. The optional B portion gives a beeper code. The optional C portion may be used for comments like, After 6:00. While no explicit limit is placed on the text field, receiving systems may be expected to truncate values that are more than 10 characters long. To accommodate the variability of institutional phone systems, the length of the extension and beeper numbers may be extended by local agreement.
|(415)925-0121X305|
|234-4532CWEEKENDS|
|
| AD |
Address data:
<street address> ^ < other designation> ^ <city> ^ <state or province> ^ <zip or postal code >^ <country >^ <type> ^ <other geographic designation>
All components are ST data type. The street or mailing address of a person or institution. For use within North America:
- state or province should be represented by the official US Postal service two-letter codes
- zip takes the form 99999[-9999], Canadian postal code is 6 alpha-numeric characters
- the country code is assumed to be USA if null
- other geographic designation includes county, bioregion, SMSA, etc.
Type is optional and defined by table 0190 – address type.
|10 ASH LN^#3^LIMA^OH^48132^”"^|
Address Type:
C=Current or Temporary
P=Permanent
M=Mailing
B=Business
O=Office
H=Home
|
| ID |
ID coded value:
The value of such a field follows the formatting rules for an ST field except that it is drawn from a table of legal values. Examples of ID fields include religion and sex. |
| SI |
Sequence ID value:
A positive integer in the form of an NM field. The uses of this field are defined in the chapters defining the segments and messages in which it appears. |
| CM |
Composite data:
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. The use of this data type will be slowly phased out and new unique data types will be created.
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 . Note that since HL7 delimiters are not recursive, an HL7 data type containing components cannot be a sub-component. When this level of detail is needed, each component of the HL7 data type can be encoded as a separate subcomponent.
|
| CK |
Composite ID with check digit:
<ID number (NM)> ^ <check digit (NM)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigning facility ID (ST)>
This data type is used for certain fields that commonly contain check digits, e.g., PID-3-Patient ID (Internal ID). If a site is not using check-digits for a particular CK field, the second and third components are not valued.
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 indentifying number, this component should be valued null.
The assigning facility ID is a unique name (up to six characters in length) of the system that stores the data. It is an ST data type. It is equivalent to the application ID of the placer or filler order number .Assigning facility ID’s are unique across a given HL7 implementation.
Check digit scheme
M10=Mod 10 algorithm
M11=Mod 11 algorithm
The algorithm for calculating a Mod10 check digit is as follows:
Assume you have an identifier = 12345. Take the odd digit positions, counting from the right, i.e., 531, multiply this number by 2 to get 1062. Take the even digit positions, starting from the right (i.e., 42), prepend these to the 1062 to get 421062. Add all of these six digits together to get 15. Subtract this number from the next highest multiple of 10, i.e., 20 – 15 to get 5. The Mod10 check digit is 5. The Mod10 check digit for 401 is 0; for 9999, it’s 4; for 99999999, it’s 7.
The algorithm for calculating a Mod11 check digit is as follows:
Terms
d = digit of number starting from units digit, followed by 10′s position, followed by 100′s position, etc.
w = weight of digit position starting with the units position, followed by 10′s position, followed by 100′s position etc. Values for w = 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, etc. (repeats for each group of 6 digits)
c = check digit
Calculation
(Step 1) m = sum of (d * w) for positions 1, 2, etc. starting with units digit
for d = digit value starting with units position to highest order
for w = weight value from 2 to 7 for every six positions starting with units digit
(Step 2) c1 = m mod 11
(Step 3) if c1 = 0 then reset c1 = 1
(Step 4) c = (11 – c1) mod 10
Example:
if the number is 1234567, then the mod 11 check digit = 6
The calculations are:
M = (7*2)+(6*3)+(5*4)+(4*5)+(3*6)+(2*7)+(1*2)
= 14 + 18 + 20 + 20 + 18 + 14 + 2
= 106
c1 = 106 mod 11
= 7
c = (11-c1) mod 10
= 4 mod 10
= 4
Other variants of these check digit algorithms exist and may be used by local bilateral site agreement.
|128952^6^M11^ADT01|
|
| CN |
Composite ID number and name:
<ID Number >^ <family name> ^ <given name> ^ <middle initial or name> ^ <suffix (e.g., JR or III) >^ p<refix (e.g., DR)> ^ <degree (e.g., MD)> ^ <source table>
All components are ST data type. A field identifying a person both as a coded value and with a text name. The first component is the coded ID according to a site-specific table. The second through the seventh components are the person’s name as a PN field. The eighth component specifies the source table used for the first component. For specific fields, individual sites may elect to omit the ID or the name.
|12372^RIGGINS^JOHN^”"^”"^”"^MD^ADT1|
|12372|
|^RIGGINS^JOHN^”"^”"^”"^MD|
|
| CQ |
Composite Quantity with units:
<quantity> ^ <units>
The first component is a quantity and the second is the units in which the quantity is expressed. Field by field, default units may be defined within the specifications. When the observation is measured in the default units, the units need not be transmitted. If the measure is recorded in units different from the default, the measurement units must be transmitted as the second component. If the units are ISO+ units, then units should be recorded as lowercase abbreviations as specified in Chapter 7. If the units are ANSI or local, the units and the source table must be recorded as specified in Chapter 7. But in these cases the component separator should be replaced by the subcomponent delimiter.
|123.7^kg| kilograms is an ISO unit
|150^lb&&ANS+|weight in pounds is a customary US unit
defined within ANSI+.
|
| CE |
Coded Element:
This data type transmits codes and the text associated with the code. This type has six components arranged in two groups as follows:
<identifier >^ <text >^ <name of coding system> ^ <alternate identifier> ^ <alternate text> ^ <name of alternate coding system>
To allow all six components of a CE data type to be valued, the minimum length of this data type is 60.
identifier: Sequence of characters (the code) that uniquely identifies the item being referenced by the . Different coding schemes will have different elements here.
text: Name or description of the item in question. E.g., myocardial infarction or x-ray impression. Its data type is string (ST).
name of coding system: Each coding system will be 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. For backward compatibility, if this component is absent, it will be taken to mean the CPT-4 with ASTM extensions, i.e., AS4. Other coding systems that might appear here are ICD-9, ICD-10, SNOMED, etc. Each system will be given a unique identifying string. The current ASTM 1238-88 diagnostic/procedure/observation/drug ID/health outcomes coding systems are identified in the tables below. Others may be added as needed.
alternate components: 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.
|54.21^Laparoscopy^I9^42112^^AS4| |
| CF |
Coded element with formatted values:
This data type transmits codes and the formatted text associated with the code. This data type can be used to transmit for the first time the formatted text for the canned text portion of a report, for example, a standard radiologic description for a normal chest x-ray. The receiving system can store this information and in subsequent messages only the identifier need be sent. Another potential use of this data type is transmitting master file records that contain formatted text.
This data type has six components arranged in two groups as follows:
<identifier>^ <formatted text> ^ <name of coding system>^ <alternate identifier> ^ <alternate formatted text> ^ <name of alternate coding system>
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.
OBX||CF|71020^CXR^CPMC||79989^
HDescription:N\.sp\ti+4Heart is not enlarged.
There is no evidence of
pneumonia, effusion, pneumothorax or any mass
es..sp+3\HImpression:
N\.sp\.ti+4Negative chest.^CPMC
|
| RP |
Reference Pointer:
This data type transmits information about data stored on another system. It contains a reference pointer that uniquely identifies the data on the other system, the identity of the other system, and the type of data. This information is transmitted in three components arranged as follows:
<pointer> ^ <application ID >^ <type of data>
pointer: A unique key assigned by the system that stores the data. The key, which is an ST data type, is used to identify and access the data.
application ID: A unique name (up to 6 characters in length) of the system that stores the data. It is an ST data type. It is equivalent to the application ID of the placer or filler order number (see Chapter 4). Application ID’s must be unique across a given HL7 implementation.
type of data: A code that represents the type of data being stored. It is an ID data type.
SI=FT Scanned image
NS=Non-scanned image
SD=Scanned document
TX=Machine readable text document
FT=Formatted text
|
| TQ |
Timing Quantity:
Describes when a service should be performed and how frequently. |
| MO |
<quantity> ^ %lt;denomenation%gt;
The first component is a quantity and the second is the denomination in which the quantity is expressed. The values for the denomination component are those specified in ISO- 4217. If the denomination is not specified, MSH-17-country code is used to determine the default.
|99.50^USD| where USD is the ISO 4217 code for the U.S. American dollar.
|
