Washington, DC 20036-4510,<PHONE_NUMBER>
basic
= ISDN PCM audio data
Telephone quality audio data, encoded as 8-bit ISDN mu-law Pulse Code
Modulation sampled at 8 kHz, according to CCITT Fascicle III.4, Recommendation
G.711. This subtype may be used for voice mail messages as well as voice
dictation.
octet-stream
= uninterpreted binary data
This subtype is for binary data which has none of the other standard formats as
given by Section <IP_ADDRESS>, "Type of data (ID)." Its interpretation by the
system utilizing the data must be mutually agreed upon by sending and receiving
parties.
PostScript = PostScript program
A PostScript language program typically representing a formatted document for
printing on a PostScript printer, or for display on a computer screen via a
PostScript interpreter.
PostScript consists of the original specification, PostScript level 1,
described in "PostScript Language Reference Manual," Addison-Wesley, 1985, and
a more advanced variant, PostScript level 2, described in "PostScript Language
Reference Manual," Addison-Wesley, Second Edition, 1990. PostScript is a
registered trademark of Adobe Systems, Inc. Use of the subtype "PostScript"
implies recognition of that trademark and all the rights it entails.
Other types may be added as needed.
Example:
|1234A321634BC^EFC^SD|
Components:
<street or mailing address (ST)> ^ <street name (ST)> ^
<dwelling number (ST)>
Note: Appears ONLY in the XAD data type
The street or mailing address of a person or institution. When referencing an institution, this first component is used to specify the institution name. When used in connection with a person, this component specifies the first line of the address.
Components:
<parameter class (IS)> ^ <parameter value (ST)>
For use only with the scheduling chapter.
Definition: This data type is used to communicate parameters and preferences
to the filler application regarding the selection of an appropriate time
slot, resource, location, or filler override criterion for an appointment.
The
first component of this field is a code identifying the parameter or preference
being passed to the filler application. Refer to
User-defined
ta
ble
0294 Time selection criteria parameter class codes for suggested
values.
Parameter Class |
Description: Valid Values |
|---|---|
Prefstart |
The preferred start time for the appointment request, service or resource. Any legal time specification in the format HHMM, using 24-hour clock notation |
Prefend |
The preferred end time for the appointment request, service or resource. Any legal time specification in the format HHMM, using 24-hour clock notation |
Mon |
An
indicator that Monday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Tue |
An
indicator that Tuesday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Wed |
An
indicator that Wednesday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Thu |
An
indicator that Thursday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Fri |
An
indicator that Friday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Sat |
An
indicator that Saturday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
Sun |
An
indicator that Sunday is or is not preferred for the day on which the
appointment will occur. OK = Preferred appointment day |
The
second component is the actual data value for that parameter.
For example, if a filler application allows preference parameters to be passed
to specify a preferred start time, a preferred end time, and preferred days of
the week for the appointment, it may define the following parameter class codes
and valid data sets.
A non-negative integer in the form of a NM field. The uses of this data type are defined in the chapters defining the segments and messages in which it appears.
Components:
<comparator (ST)> ^ <num1 (NM)> ^ <separator/suffix (ST)> ^
<num2 (NM)>
The structured numeric data type is used to unambiguously express numeric
clinical results along with qualifications. This enables receiving systems to
store the components separately, and facilitates the use of numeric database
queries. The corresponding sets of values indicated with the
<comparator> and <separator/suffix> components are intended to be
the authoritative and complete set of values. If additional values are needed
for the <comparator> and <separator/suffix> components, they
should be submitted to HL7 for inclusion in the Standard.
If <num1> and <num2> are both non-null, then the separator/suffix
must be non-null. If the separator is "-", the data range is inclusive; e.g.,
<num1> - <num2> defines a range of numbers x, such that:
<num1> <=x<= <num2>.
Defined
as greater than, less than, greater than or equal, less than or equal, equal,
and not equal, respectively (= ">" or "<" or ">=" or "<=" or "="
or "<>"
If this component is not valued, it defaults to equal ("=").
A number.
"-"
or "+" or "/" or "." or ":"
Examples:
|>^100| (greater than 100)
|^100^-^200| (equal to range of 100 through 200)
|^1^:^228| (ratio of 1 to 128, e.g., the results of a serological test)
|^2^+| (categorical response, e.g., occult blood positivity)
A number or null depending on the measurement.
Components:
<sort-by field(ST)> ^ <sequencing (ID)>
Specifies those parameters by which the response will be sorted and by what
method.
Example: In a tabular response query, where the return data is known by column
name, the SRT might look like
|LastName^A~FirstName^A|Example: In a segment response query, where the return
data is known by segment and offset, the SRT field would use segment field name
notation,
|PID.3.1^A~PID.3.2|
Identifies
the field by which the response will be sorted. In a tabular response , this
will be the column name to sort by. In the Segment Pattern and the Display
Response, this will be the segment field name to sort by. (see QIP in Section
<IP_ADDRESS>, "Segment field name (ST)" for segment field name definition.)
See Chapter 5, "Query", for a complete discussion of queries and their responses.
Identifies
how the field or parameter will be sorted; and, if sorted, whether the sort
will be case sensitive (the default) or not. Refer to HL7 Table 0
397
-
Sequencing for valid values
Value |
Description |
|---|---|
A |
Ascending |
AN |
Ascending, case insensitive |
D |
Descending |
DN |
Descending, case insensitive |
N |
None |
String
data is left justified with trailing blanks optional. Any displayable
(printable) ACSII characters (hexadecimal values between 20 and 7E, inclusive,
or ASCII decimal values between 32 and 126), except the defined escape
characters and defined delimiter characters. Example:
|almost any data at all|
To include any HL7 delimiter character (except the segment terminator) within a
string data field, use the appropriate HL7 escape sequence (see Section 2.10.1,
"Formatting codes").
Usage note: The ST data type is intended for short strings (e.g., less
than 200 characters). For longer strings the TX or FT data types should be
used (see Sections 2.9.48, "TX - text data" or 2.9.20, "FT - formatted text
data").
Alternate character set note: ST - string data may also be used to
express other character sets. See Section <IP_ADDRESS>, "Character set", and
Section <IP_ADDRESS>, "Alternate character set handling" for details.
Format:
HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ]
In prior versions of HL7, this data type was always specified to be in the
format HHMM[SS[.SSSS]][+/-ZZZZ] using a 24 hour clock notation. In the current
and future versions, the precision of a time may be expressed by limiting the
number of digits used with the format specification as shown above. By
site-specific agreement, HHMM[SS[.SSSS]][+/-ZZZZ] may be used where backward
compatibility must be maintained.
Thus, HH is used to specify a precision of "hour," HHMM is used to specify a
precision of "minute," HHMMSS is used to specify a precision of seconds, and
HHMMSS.SSSS is used to specify a precision of ten-thousandths of a second.
In each of these cases, the time zone is an optional component. The fractional
seconds could be sent by a transmitter who requires greater precision than
whole seconds. Fractional representations of minutes, hours or other
higher-order units of time are not permitted.
Note: The time zone [+/-ZZZZ], when used, is restricted to
legally-defined time zones and is represented in HHMM format.
The time zone of the sender may be sent optionally as an offset from the
coordinated universal time (previously known as Greenwich Mean Time). Where
the time zone is not present in a particular TM field but is included as part
of the date/time field in the MSH segment, the MSH value will be used as the
default time zone. Otherwise, the time is understood to refer to the local
time of the sender. Midnight is represented as 0000. Examples:
|235959+1100| 1 second before midnight in a time zone eleven
hours
ahead of Universal Coordinated Time (i.e.,
east of Greenwich).
|0800| Eight AM, local time of the sender.
|093544.2312| 44.2312 seconds after Nine thirty-five AM, local time
of
sender.
|13| 1pm (with a precision of hours), local time of sender.
For
use in the United States and conforming countries, the telephone number is
always in the form:
Format: [NN] [(999)]999-9999[X99999][B99999][C any text]
Note: Replaced by XTN data type as of v 2.3
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. Examples:
|(415)925-0121X305|
|234-4532CWEEKENDS|
Describes when a service should be performed and how frequently. See Chapter 4 (Section 4.3, "QUANTITY/TIMING (TQ) DEFINITION") for a complete description of this data type.
Format:
YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]^<degree of
precision>
Contains the exact time of an event, including the date and time. The date
portion of a time stamp follows the rules of a date field and the time portion
follows the rules of a time field. The time zone (+/-ZZZZ) is represented as
+/-HHMM offset from UTC (formerly Greenwich Mean Time (GMT)), where +0000 or
-0000 both represent UTC (without offset). The specific data representations
used in the HL7 encoding rules are compatible with ISO 8824-1987(E).
In prior versions of HL7, an optional second component indicates the degree of
precision of the time stamp (Y = year, L = month, D = day, H = hour, M =
minute, S = second). This optional second component is retained only for
purposes of backward compatibility.
By site-specific agreement, YYYYMMDD[HHMM[SS[.S[S[S[S]]]]]][+/-ZZZZ]^<degree
of precision> may be used where backward compatibility must be
maintained.
In the current and future versions of HL7, the precision is indicated by
limiting the number of digits used, unless the optional second component is
present. Thus, YYYY is used to specify a precision of "year," YYYYMM specifies
a precision of "month," YYYYMMDD specifies a precision of "day," YYYYMMDDHH is
used to specify a precision of "hour," YYYYMMDDHHMM is used to specify a
precision of "minute," YYYYMMDDHHMMSS is used to specify a precision of
seconds, and YYYYMMDDHHMMSS.SSSS is used to specify a precision of ten
thousandths of a second. In each of these cases, the time zone is an optional
component. Note that if the time zone is not included, the timezone defaults
to that of the local time zone of the sender. Also note that a TS valued field
with the HHMM part set to "0000" represents midnight of the night extending
from the previous day to the day given by the YYYYMMDD part (see example
below). Maximum length of the time stamp is 26. Examples:
|19760704010159-0500|
1:01:59 on July 4, 1976 in the Eastern Standard Time zone (USA).
|19760704010159-0400|
1:01:59 on July 4, 1976 in the Eastern Daylight Saving Time zone (USA).
|198807050000|
Midnight of the night extending from July 4 to July 5, 1988 in the local time
zone of the sender.
|19880705|
Same as prior example, but precision extends only to the day. Could be used
for a birthdate, if the time of birth is unknown.
|19981004010159+0100|
1:01:59 on October 4, 1998 in Amsterdam, NL. (Time zone=+0100).
The HL7 Standard strongly recommends that all systems routinely send the time
zone offset but does not require it. All HL7 systems are required to accept
the time zone offset, but its implementation is application specific. For many
applications the time of interest is the local time of the sender. For
example, an application in the Eastern Standard Time zone receiving
notification of an admission that takes place at 11:00 PM in San Francisco on
December 11 would prefer to treat the admission as having occurred on December
11 rather than advancing the date to December 12.
Note: The time zone [+/-ZZZZ], when used, is restricted to
legally-defined time zones and is represented in HHMM format.
One exception to this rule would be a clinical system that processed patient
data collected in a clinic and a nearby hospital that happens to be in a
different time zone. Such applications may choose to convert the data to a
common representation. Similar concerns apply to the transitions to and from
daylight saving time. HL7 supports such requirements by requiring that the
time zone information be present when the information is sent. It does not,
however, specify which of the treatments discussed here will be applied by the
receiving system.
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.10 "Use of escape sequences in text fields."
Leading spaces should be included. Trailing spaces should be removed.
Example:
| leading spaces are allowed.|
Since TX data is intended for display purposes, the repeat delimiter, when used
with a TX data field, implies a series of repeating lines to be displayed on a
printer or terminal. Therefore, the repeat delimiters are regarded as
paragraph terminators or hard carriage returns (e.g., they would display as
though a CR/LF were inserted in the text (DOS type system) or as though a LF
were inserted into the text (UNIX style system)).
A receiving system would word-wrap the text between repeat delimiters in order
to fit it into an arbitrarily sized display window but start any line beginning
with a repeat delimiter on a new line.
Length: 65536
To include alternative character sets, use the appropriate escape sequence.
See Section <IP_ADDRESS>, "MSH-18 Character set (ID) 00692", and Section
<IP_ADDRESS>, "MSH-20 Alternate character set handling scheme (ID) 01317."
Components:
<start day range (ID)> ^ <end day range (ID)> ^ <start hour
range (TM)> ^ <end hour range (TM)>
Definition: This data type contains the hours when a patient location is open
for visiting. Refer to HL7 Table 0267 - Days of
the
week for valid values for the first two components.
Starting day of visiting hours range. See HL7 Table 0267 - Days of the week for valid values.
Ending
day of visiting hours range. Starting day of visiting hours range. See
HL7 Table 0267 - Days of the week for valid values
Value |
Description |
|---|---|
SAT |
Saturday |
SUN |
Sunday |
MON |
Monday |
TUE |
Tuesday |
WED |
Wednesday |
THU |
Thursday |
FRI |
Friday |
Starting hour on starting day of visiting hours range (see first component, <IP_ADDRESS>, "Start day range (ID)").
Ending hour on ending day of visiting hours range (see second component, <IP_ADDRESS>, "End day range (ID)").
Components: <version ID (ID)> ^ <internationalization code (CE)> ^ <international version ID (CE)
Used to identify the HL7 version. Refer to HL7 Table 0104 - V ersion ID for valid values.
Used
to identify the international affiliate country code. The values to be used are
those of ISO 3166 -1:1977. The ISO 3166 table has three separate forms of the
country code: HL7 specifies that the 3-character (alphabetic) form be used for
the country code.
Refer to HL7 Table 0
399
- Country code for the 3-character codes as defined by ISO 3166 table.
This field component identifies international affiliate's version; it is especially important when the international affiliate has more than a single local version associated with a single US version.
Components:
<street address (SAD)> ^ <other designation (ST)> ^ <city
(ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^
<country (ID)> ^ < address type (ID)> ^ <other geographic
designation (ST)> ^ <county/parish code (IS)> ^ <census
tract (IS)> ^ <address representation code (ID)> ^ <address
validity range (DR)>
Subcomponents of street address (SAD): <street or mailing address
(ST)> & <street name (ST)> & <dwelling number
(ST)>Subcomponents of address validity range (DR): <date range start
date/time (TS)> & <date range end date/time (TS)>
Note: Replaces the AD data type as of v 2.3.
Length: 250
Example of usage for US:
|1234 Easy St.^Ste. 123^San Francisco^CA^95123^USA^B^^SF^|
This would be formatted for postal purposes as
1234 Easy St.
Ste. 123
San Francisco CA 95123
Example of usage for Australia:
|14th Floor^50 Paterson St^Coorparoo^QLD^4151|
This would be formatted for postal purposes using the same rules as for the
American example as
14th Floor
50 Paterson St
Coorparoo QLD 4151
International note: Countries typically have a standard method of
formatting addresses. This data type does not specify the formatting usages,
only the components of a postal address.
See section 2.9.38, "SAD - street address" for description of components.
Second line of address. In US usage, it qualifies address. Examples: Suite 555 or Fourth Floor. When referencing an institution, this component specifies the street address.
This may be the name of the city, or district or place depending upon the national convention for formatting addresses for postal usage.
State or province should be represented by the official postal service codes for that country.
Zip or postal codes should be represented by the official codes for that country. In the US, the zip code takes the form 99999[-9999], while the Canadian postal code takes the form A9A9A9, and the Australian Postcode takes the form 9999
Defines the country of the address. ISO 3166 provides a list of country codes that may be used. The ISO 3166 table has three separate forms of the country code: HL7 specifies that the 3-character (alphabetic) form be used for the country code. HL7 Table 0399 - Country code is defined to contain these 3-character codes.
Address type is optional and defined by HL7 Table 0190 - Address type.
Other geographic designation includes county, bioregion, SMSA, etc.
A
code that represents the county in which the specified address resides.
User-defined Table 0289 - County/parish is used as the HL7
identifier for the user-defined table of values for this component. When this
component is used to represent the county (or parish), component 8 <other
geographic designation> should not duplicate it (i.e., the use of <other
geographic designation> to represent the county is allowed only for the
purpose of backward compatibility, and should be discouraged in this and future
versions of HL7).
Allowable values: codes defined by government.
Value |
Description |
|---|---|
No suggested values defined |
A
code that represents the census tract in which the specified address
resides. User-defined Table 0288 - Census tract is
used as the HL7 identifier for the user-defined table of values for this
component.
Allowable Values: codes defined by government.
Value |
Description |
|---|---|
No suggested values defined. |
Different
<name/address types> and representations of the same name/address should
be described by repeating of this field, with different values of the
<name/address type> and/or <name/address representation>
component.
Note: Also note that this new component remains in "alphabetic"
representation with each repetition of the fields using these data types. I.e.
even though the address may be represented in an ideographic character set,
this component will remain represented in an alphabetic character set.
Refer to HL7 table 0465 - Name/address representation for valid
values.
In general this component provides an indication of the representation provided
by the data item. It does not necessarily specify the character sets used.
Thus, even though the representation might provide an indication of what to
expect, the sender is still free to encode the contents using whatever
character set is desired. This component provides only hints for the receiver,
so it can make choices regarding what it has been sent and what it is capable
of displaying.
This component contains the start and end date/times which define the period in which this address was valid
Components:
<ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^
<second and further given names or initials thereof (ST)> ^ <suffix
(e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g.,
MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^
<name type code (ID)> ^ <identifier check digit (ST)> ^ <code
identifying the check digit scheme employed (ID)> ^ <identifier type code
(IS)> ^ <assigning facility (HD)> ^ <name representation code
(ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^
<name assembly order (ID)>
Subcomponents of family name: <surname (ST)> & <own surname
prefix (ST)> & <own surname (ST)> & <surname prefix from
partner/spouse (ST)> & <surname from partner/spouse (ST)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of name context: <identifier (ST)> & <text
(ST)> & <name of coding system (IS)> & <alternate
identifier (ST)> & <alternate text (ST)> & <name of
alternate coding system (IS)>
Subcomponents of name validity range: <date range start date/time
(TS)> & <date range end date/time (TS)>
Note: Replaces CN data type as of v 2.3.
Length: 250
This data type is used extensively appearing in the PV1, ORC, RXO, RXE, OBR and
SCH segments , as well as others, where there is a need to specify the ID
number and name of a person.
Example without assigning authority and assigning facility:
|1234567^Smith^John^J^III^DR^PHD^ADT01^^L^4^M11^MR|
Examples with assigning authority and assigning facility:
Dr. Samuel Semmelweiss's provider ID was assigned by the Provider Master and
was first issued at Fairview Hospital within the University Hospitals System.
Since IS table values (first component of the HD) were not used for assigning
authority and assigning facility, components 2 and 3 of the HD data type are
populated and demoted to sub-components as follows:
12188^Semmelweiss^Samuel^S^IV^Dr^MD^^&Provider Master.University
Hospitals&L^L^9^M10^DN^&Fairview Hospital.University
Hospitals&L^A
Ludwig van Beethoven's medical record number was assigned by the Master Patient
Index and was first issued at Fairview Hospital within the University Hospitals
System.
10535^van Beethoven&van^Ludwig^A^III^Dr^PHD^^&MPI.University
Hospitals&L^L^3^M10^MR^&Fairview Hospital.University Hospitals&L^A
This string refers to the coded ID according to a user-defined table, defined by the 9th component. If the first component is present, either the source table or the assigning authority must be valued.
This component allows full specification of the surname of a person. Where appropriate, it differentiates the person's own surname from that of the person's partner or spouse, in cases where the person's name may contain elements from either name. It also permits messages to distinguish the surname prefix (such as "van" or "de") from the surname root. See section 2.9.19, " FN - family name".
First name.
Multiple middle names may be included by separating them with spaces.
Used to specify a name suffix (e.g., Jr. or III).
Used to specify a name prefix (e.g., Dr.).
Used to specify an educational degree (e.g., MD). Refer to User-defined Table 0 360 - Degree for suggested values.
User-defined Table 0297 - CN ID source is used as the HL7 identifier for the user-defined table of values for this component. Used to delineate the first component.
The
assigning authority is a unique identifier of the system (or organization or
agency of department) that creates the data. User-defined Table 0363 -
Assigning
authority is used as the HL7 identifier for the user-defined table of
values for the first sub-component of the HD component, <namespace
ID>.
Note: When the HD data type is used in a given segment as a component
of a field of another data type, User-defined Table 0300 - Namespace
I
D
(referenced by the first sub-component of the HD component) may be re-defined
(given a different user-defined table number and name) by the technical
committee responsible for that segment.
By site agreement,
implementers may continue to use User-defined Table 0300 - Namespace
ID for the first sub-component.
A code that represents the type of name. Refer to HL7 Table 0200 - Name type for valid values (see Section <IP_ADDRESS>, "Name type code (ID)").
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.
Refer to HL7 Table 0061 - Check digit scheme for valid values.
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.
The
place or location identifier where the identifier was first assigned to the
person. This component is not an inherent part of the identifier but rather
part of the history of the identifier: as part of this data type, its existence
is a convenience for certain intercommunicating systems.
Note: When the HD data type is used in a given segment as a component
of a field of another data type, User-defined Table 0300 - Namespace
ID (referenced by the first sub-component of the HD component) may be
re-defined (given a different user-defined table number and name) by the
technical committee responsible for that segment.
Different
<name/address types> and representations of the same <name/address>
should be described by repeating of this field, with different values of the
<name/address type> and/or <name/address representation>
component.
Note: This new component remains in "alphabetic" representation with
each repetition of the field using these data types. I.e.. even though the name
may be represented in an ideographic character set, this component will remain
represented in an alphabetic character set.
Refer to HL7 Table 0465 - Name/address representation for valid
values.
In general this component provides an indication of the representation provided
by the data item. It does not necessarily specify the character sets used.
Thus, even though the representation might provide an indication of what to
expect, the sender is still free to encode the contents using whatever
character set is desired. This component provides only hints for the receiver,
so it can make choices regarding what it has been sent and what it is capable
of displaying.
This
component is used to designate the context in which a name is used. The main
use case is in Australian healthcare for indigenous patients who prefer to use
different names when attending different healthcare institutions. Another use
case occurs in the US where health practitioners can be licensed under slightly
different names and the reporting of the correct name is vital for
administrative purposes. Refer to User-defined Table 0448 - Name
context for suggested values.
Value |
Description |
|---|---|
No suggested values defined |
This component contains the start and end date/times that define the period during which this name was valid. See section 2.9.14, "DR - date/time range" for description of subcomponents.
A code that represents the preferred display order of the components of this person name. Refer to HL7 Table 0444 - Name assembly order for valid values
Components:
<organization name (ST)> ^ <organization name type code (IS)> ^
<ID number (NM)> ^ <check digit (NM)> ^ <code identifying the
check digit scheme employed (ID)> ^ <assigning authority (HD)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code(ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Length: 250
This data type is used in fields (e.g., PV2-23, NK1-13, PD1-3, OBR-44) to
specify the name and ID number of an organization.
Example 1:
The ID for Fairview Hospital was assigned by the University Hospital
enterprise's Hospital Master and was first issued at the Central Offices.
Fairview Hospital^L^716^9^M10^&Hospital Master.University
Hositals&L^XX^&Central Offices.University Hospitals&L^A
Example 2:
Fairview Hospital has another ID that was issued by HCFA. Assigning Authority,
HCFA, values only the first HD component, an IS data type and assigning
facility is not relevant. This information might be transmitted
accordingly:
Fairview Hospital^L^4544^3^M10^HCFA^XX^^A
The name of the specified organization.
A
code that represents the type of name i.e., legal name, display name. Refer to
User-defined
Table 0204 - Organizational name type for suggested values.
Value |
Description |
|---|---|
A |
Alias name |
L |
Legal name |
D |
Display name |
SL |
Stock exchange listing name |
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.
The check digit scheme codes are defined in HL7 Table 0061 - Check digit scheme.
The
assigning authority is a unique identifier of the system (or organization or
agency or department) that creates the data. Assigning authorities are unique
across a given HL7 implementation. User-defined Table 0363 - Assigning
authority is used as the HL7 identifier for the user-defined table of
values for the first sub-component of the HD component <namespace ID>.
Note: When the HD data type is used in a given segment as a component
of a field of another data type, User-defined Table 0300
-
Namespace ID (referenced by the first sub-component of the HD component)
may be re-defined (given a different user-defined table number and name) by the
technical committee responsible for that segment.
By site agreement,
implementors may continue to use User-defined Table 0300 - Namespace
ID for the first sub-component.
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.
The
place or location identifier where the identifier was first assigned to the
person. This component is not an inherent part of the identifier but rather
part of the history of the identifier: as part of this data type, its existence
is a convenience for certain intercommunicating systems.
Note: When the HD data type is used in a given segment as a component of
a field of another data type, User-defined Table 0300 - Name
space
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.
Different
<name/address types> and representations of the same <name/address>
should be described by repeating of this field, with different values of the
<name/address type> and/or <name/address representation>
component.
Note: This new component remains in "alphabetic" representation with
each repetition of the field using these data types, i.e. even though the name
may be represented in an ideographic character set, this component will remain
represented in an alphabetic character set.
Refer to HL7 Table 0465 - Name/address representation code for valid
values.
In general this component provides an indication of the representation provided
by the data item. It does not necessarily specify the character sets used.
Thus, even though the representation might provide an indication of what to
expect, the sender is still free to encode the contents using whatever
character set is desired. This component provides only hints for the receiver,
so it can make choices regarding what it has been sent and what it is capable
of displaying.
Components: In Version 2.3, replaces the PN data type. <family name
(FN)> ^ <given name (ST)> ^ <second and further given names or
initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix
(e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <name type
code (ID) > ^ <name representation code (ID)> ^ <name context
(CE)> ^ <name validity range (DR)> ^ <name assembly order
(ID)>
Subcomponents of family name: <surname (ST)> ^ <own surname
prefix (ST)> ^ <own surname (ST)> ^ <surname prefix from
partner/spouse (ST)> ^ <surname from partner/spouse (ST)>
Subcomponents of name context: <identifier (ST)> & <text
(ST)> & <name of coding system (IS)> & <alternate
identifier (ST)> & <alternate text (ST)> & <name of
alternate coding system (IS)>
Subcomponents of name validity range: <date range start date/time
(TS)> & <date range end date/time (TS)>
Length: 250
Note: Replaces PN data type as of v 2.3.
Example:
|Smith^John^J^III^DR^PHD^L|
This component allows full specification of the surname of a person. Where appropriate, it differentiates the person's own surname from that of the person's partner or spouse, in cases where the person's name may contain elements from either name. It also permits messages to distinguish the surname prefix (such as "van" or "de") from the surname root. See section 2.9.19, "FN - family name".
First name.
Multiple middle names may be included by separating them with spaces.
Used to specify a name suffix (e.g., Jr. or III).
Used to specify a name prefix (e.g., Dr.).
Used
to specify an educational degree (e.g., MD). Refer to User-defined
Table
0360
- Degree
for suggested values.
Value |
Description |
|---|---|
AAS |
Associate of Applied Science |
AA |
Associate of Arts |
ABA |
Associate of Business Administration |
AE |
Associate of Engineering |
AS |
Associate of Science |
BA |
Bachelor of Arts |
BBA |
Bachelor of Business Administration |
BE |
Bachelor or Engineering |
BFA |
Bachelor of Fine Arts |
BN |
Bachelor of Nursing |
BS |
Bachelor of Science |
BSL |
Bachelor of Science - Law |
BT |
Bachelor of Theology |
CER |
Certificate |
DIP |
Diploma |
DBA |
Doctor of Business Administration |
DED |
Doctor of Education |
PharmD |
Doctor of Pharmacy |
PHE |
Doctor of Engineering |
PHD |
Doctor of Philosophy |
PHS |
Doctor of Science |
MD |
Doctor of Medicine |
DO |
Doctor of Osteopathy |
HS |
High School Graduate |
JD |
Juris Doctor |
MA |
Master of Arts |
MBA |
Master of Business Administration |
MCE |
Master of Civil Engineering |
MDI |
Master of Divinity |
MED |
Master of Education |
MEE |
Master of Electrical Engineering |
ME |
Master of Engineering |
MFA |
Master of Fine Arts |
MME |
Master of Mechanical Engineering |
MS |
Master of Science |
MSL |
Master of Science - Law |
MT |
Master of Theology |
NG |
Non-Graduate |
SEC |
Secretarial Certificate |
TS |
Trade School Graduate |
A
code that represents the type of name. Refer to HL7 Table 0200 - Name
type for valid values.
Value |
Description |
|---|---|
A |
Alias Name |
B |
Name at Birth |
C |
Adopted Name |
D |
Display Name |
I |
Licensing Name |
L |
Legal Name |
M |
Maiden Name |
N |
Nickname /"Call me" Name/Street Name |
P |
Name of Partner/Spouse (retained for backward compatibility only) |
R |
Registered Name (animals only) |
S |
Coded Pseudo-Name to ensure anonymity |
T |
Indigenous/Tribal/Community Name |
U |
Unspecified |
Note: The content of Legal Name is country specific. In the US the legal name is the same as the current married name.
Different
<name/address types> and representations of the same <name/address>
should be described by repeating of this field, with different values of the
<name/address type> and/or <name/address representation>
component.
Note: This new component remains in "alphabetic" representation with
each repetition of the field using these data types. I.e. even though the name
may be represented in an ideographic character set, this component will remain
represented in an alphabetic character set.
Refer to HL7 Table 0465 - Name/address representation for valid
values.
In general this component provides an indication of the representation provided
by the data item. It does not necessarily specify the character sets used.
Thus, even though the representation might provide an indication of what to
expect, the sender is still free to encode the contents using whatever
character set is desired. This component provides only hints for the receiver,
so it can make choices regarding what it has been sent and what it is capable
of displaying.
Subcomponents
of name context: <identifier (ID)> & <text (ST)> &
<name of coding system (IS)> & <alternate identifier (ID)>
& <alternate text (ST)> & <name of alternate coding system
(IS)>
This component is used to designate the context in which a name is used. The
main use case is in Australian healthcare for indigenous patients who prefer to
use different names when attending different healthcare institutions. Another
use case occurs in the US where health practitioners can be licensed under
slightly different names and the reporting of the correct name is vital for
administrative purposes. Refer to User-defined Table 0448 - Name
context for suggested values.
This component contains the start and end date/times which define the period during which this name was valid. See section 2.9.14, "DR - date/time range" for description of subcomponents.
A code that represents the preferred display order of the components of this person name. Refer to HL7 0444 - Name assembly order for valid values.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^
<telecommunication use code (ID)> ^ <telecommunication equipment type
(ID)> ^ <email address (ST)> ^ <country code (NM)> ^
<area/city code (NM)> ^ <phone number (NM)> ^ <extension
(NM)> ^ <any text (ST)>
Note: Replaces TN data type as of v 2.3
Length: 250
Example:
(415)555-3210^ORN^FX^
Defined as the TN data type (see Section 2.9.45, "TN - telephone number"), except that the length of the country access code has been increased to three.
A
code that represents a specific use of a telecommunication number.
Refer to HL7 Table 0201 - Telecommunication use code for
valid values.
Value |
Description |
|---|---|
PRN |
Primary Residence Number |
ORN |
Other Residence Number |
WPN |
Work Number |
VHN |
Vacation Home Number |
ASN |
Answering Service Number |
EMR |
Emergency Number |
NET |
Network (email) Address |
BPN |
Beeper Number |
A
code that represents the type of telecommunication equipment. Refer
to HL7 Table 0202 - Telecommunication equipment type for
valid values.
Value |
Description |
|---|---|
PH |
Telephone |
FX |
Fax |
MD |
Modem |
CP |
Cellular Phone |
BP |
Beeper |
Internet |
Internet Address: Use Only If Telecommunication Use Code Is NET |
X.400 |
X.400 email address: Use Only If Telecommunication Use Code Is NET |
Internationalization
note: To make this data type interoperate with CEN's Telecommunication data
attribute group, we allow use of the second component for email addresses. The
presence of an email address is specified by the addition of the value
NET to the Phone Use Code table, and the type of Internet address is
specified with the values Internet and X.400 to the Phone
Equipment Type table. When used for an Internet address, the first component
of the XTN data type will be null. If the @-sign is being used as a
subcomponent delimiter, the HL7 subcomponent escape sequence may be used when
encoding an Internet address (see Section 2.10.1, "Formatting codes").
Note: Components five through nine reiterate the basic function of the
first component in a delimited form that allows the expression of both local
and international telephone numbers. In Version 2.3, the recommended form for
the telephone number is to use the delimited form rather than the unstructured
form supported by the first component (which is left in for backward
compatibility only).
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 escape character is whatever display ASCII character is specified in the
<escape character> component of MSH-2-encoding characters. For
purposes of this section, 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:
\H\ |
start highlighting |
\N\ |
normal text (end highlighting) |
\F\ |
field separator |
\S\ |
component separator |
\T\ |
subcomponent separator |
\R\ |
repetition separator |
\E\ |
escape character |
\Xdddd...\ |
hexadecimal data |
\Zdddd...\ |
locally defined escape sequence |
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.
The
following HL7 escape sequences are defined to support multiple character sets
for fields, components and sub-components that are defined as data types FT,
ST, and TX. They allow HL7 parsers to use escape codes (defined in the
standards used below), without breaking, and without being non-conformant to
the HL7 escape paradigm defined in this section.
\Cxxyy\ single-byte character set escape sequence with two hexadecimal values,
xx and yy, that indicate the escape sequence defined for one of the character
repertoires supported for the current message (i.e., ISO-IR xxx).
\Mxxyyzz\ multi-byte character set escape sequence with three hexadecimal
values, xx, yy and zz. zz is optional.
Common character set escape sequences include the following which are defined
in the standards mentioned:
Single-byte character sets:
\C2842\ |
ISO-IR6 G0 (ISO 646 : ASCII) |
\C2D41\ |
ISO-IR100 (ISO 8859 : Latin Alphabet 1) |
\C2D42\ |
ISO-IR101 (ISO 8859 : Latin Alphabet 2) |
\C2D43\ |
ISO-IR109 (ISO 8859 : Latin Alphabet 3) |
\C2D44\ |
ISO-IR110 (ISO 8859 : Latin Alphabet 4) |
\C2D4C\ |
ISO-IR144 (ISO 8859 : Cyrillic) |
\C2D47\ |
ISO-IR127 (ISO 8859 : Arabic) |
\C2D46\ |
ISO-IR126 (ISO 8859 : Greek) |
\C2D48\ |
ISO-IR138 (ISO 8859 : Hebrew) |
\C2D4D\ |
ISO-IR148 (ISO 8859 : Latin Alphabet 5) |
\C284A\ |
ISO-IR14 (JIS X 0201 -1976: Romaji) |
\C2949\ |
ISO-IR13 (JIS X 0201 : Katakana) |
Multi-byte
codes:
\M2442\ |
ISO-IR87 (JIS X 0208 : Kanji, hiragana and katakana) |
\M242844\ |
ISO-IR159 (JIS X 0212 : Supplementary Kanji) |
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 color 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.
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|
^----------------^
When the hexadecimal escape sequence (\Xdddd...\) is used the X should be followed by 1 or more pairs of hexadecimal digits (0, 1, . . . , 9, A, . . . , F). Consecutive pairs of the hexadecimal digits represent 8-bit binary values. The interpretation of the data is entirely left to an agreement between the sending and receiving applications that is beyond the scope of this Standard.
If
the field is of the formatted text (FT) data type, 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. Note that for purposes of compatibility with previous versions of HL7, "^\.sp\" is equivalent to "\.br\." |
.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 no-wrap 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. |
The
component separator that marks each line defines the extent of the temporary
indent command (.ti), and the beginning of each line in the no-wrap mode (.nf).
Examples of formatting instructions that are NOT included in this data type
include: width of display, position on page or screen, and type of output
devices.
Figure 2-3 is an example of the FT data type from a radiology impression
section of a radiology report:
| \.in+4\\.ti-4\ 1. The cardiomediastinal silhouette is now within normal limits.^\.sp\\.ti-4\ 2. Lung fields show minimal ground glass appearance.^\.sp\\.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\| |
Figure
2-4 shows one way of presenting the data in Figure 2-3. The receiving
system can create many other interpretations by varying the right margin.
1.
The cardiomediastinal silhouette is now within normal limits. |
When the local escape sequence (\Zdddd...\) is used the Z should be followed by characters that are valid in a TX field. The interpretation of the data is entirely left to an agreement between the sending and receiving applications that is beyond the scope of this Standard.
Note:
These message construction rules define the standard HL7 encoding rules,
creating variable length delimited messages. Although only one set of encoding
rules is defined as a standard in HL7 Version 2.3, other encoding rules are
possible (but since they are non-standard, they may only be used by a
site-specific agreement).
Step 1 Construct the segments in the order defined for the message. Each
message is constructed as follows:
a) the first three characters are the segment ID code
b) each data field in sequence is inserted in the segment in the following
manner:
1) a field separator is placed in the segment
2) if the value is not present, no further characters are required
3) if the value is present, but null, the characters "" (two consecutive double
quotation marks) are placed in the field
4) otherwise, place the characters of the value in the segment. As many
characters can be included as the maximum defined for the data field. It is
not necessary, and is undesirable, to pad fields to fixed lengths. Padding to
fixed lengths is permitted. Encode the individual data fields as shown in
Section 2.9, "Data types."
5) if the field definition calls for a field to be broken into components, the
following rules are used:
i. if more than one component is included they are separated by the component
separator
ii. components that are present but null are represented by the characters
""
iii. components that are not present are treated by including no characters in
the component
iv. components that are not present at the end of a field need not be
represented by component separators. For example, the two data fields are
equivalent:
|ABC^DEF^^| and |ABC^DEF|.
6) if the component definition calls for a component to be broken into
subcomponents, the following rules are used:
i. if more than one subcomponent is included they are separated by the
subcomponent separator
ii. subcomponents that are present but null are represented by the characters
""
iii. subcomponents that are not present are treated by including no characters
in the subcomponent
iv. subcomponents that are not present at the end of a component need not be
represented by subcomponent separators. For example, the two data components
are equivalent:
^XXX&YYY&&^ and ^XXX&YYY^.
7) if the field definition permits repetition of a field, the repetition
separator is used only if more than one occurrence is transmitted. In such a
case, the repetition separator is placed between occurrences. If three
occurrences are transmitted, two repetition separators are used.)
In the example below, two occurrences of telephone number are being sent:
|234-7120~599-1288B1234|
c) repeat Step 1b while there are any fields present to be sent. If all the
data fields remaining in the segment definition are not present there is no
requirement to include any more delimiters.
d) end each segment with an ASCII carriage return character
Step 2 Repeat Step 1 until all segments have been generated.
The following rules apply to receiving HL7 messages and converting their
contents to data values:
a) ignore segments, fields, components, subcomponents, and extra repetitions of
a field that are present but were not expected
b) treat segments that were expected but are not present as consisting entirely
of fields that are not present
c) treat fields and components that are expected but were not included in a
segment as not present.
If a segment is to be continued across messages, use the extended encoding rules. These rules are defined in terms of the more general message continuation protocol (see Section 2.15.2, "Continuation messages and segments").
The
above rules for receiving HL7 messages and converting their contents to data
values allow the following definition of a backward compatibility requirement
between the 2.x versions of HL7:
a) New messages may be introduced.
b) New segments may be introduced to an existing message. In general these
will be introduced at the end of a message, but they may be introduced
elsewhere within the message if the segment hierarchy makes this necessary.
c) New fields may be added at the end of a segment, new components may be added
at the end of a field, new subcomponents may be added at the end of a
component, and a non-repeating field may be made repeating.
d) Existing optional segments, fields, components, and subcomponents may be
made conditional or required.
If a non-repeating field is made repeating, the first instance of that
repeating field must have the same meaning as the non-repeating field had in
the prior version of HL7.
For existing fields in existing segments, data types may be changed by the
above rule in point "c" if the leftmost (prior version) part of the field has
the same meaning as it had in the prior version of HL7. In other words, if the
new parts of the field (those that are part of the new data type) are ignored,
what remains is the old field (defined by the old data type), which has the
same meaning as it had in the prior version of HL7. When optional elements are
made required or conditional, what remains for older versions is not changed.
Subsequent
chapters of this document describe messages that are exchanged among
applications in functionally-specific situations. Each chapter is organized as
follows:
a) purpose. This is an overview describing the purpose of the chapter,
general information and concepts.
b) trigger events and messages. There is a list of the trigger events.
For each trigger event the messages that are exchanged when the trigger event
occurs are defined using the HL7 abstract message syntax as follows:
Each message is defined in special notation that lists the segment IDs in the
order they would appear in the message. Braces, { . . . }, indicate one or
more repetitions of the enclosed group of segments. (Of course, the group may
contain only a single segment.) Brackets, [ . . . ], show that the enclosed
group of segments is optional. If a group of segments is optional and may
repeat it should be enclosed in brackets and braces, { [ . . . ] }.
Note: [{...}] and {[...]} are equivalent.
Whenever braces or brackets enclose more than one segment ID a special
stylistic convention is used to help the reader understand the hierarchy of
repetition. For example, the first segment ID appears on the same line as the
brace, two columns to the right. The subsequent segment IDs appear under the
first. The closing brace appears on a line of its own in the same column as
the opening brace. This convention is an optional convenience to the user. If
there is conflict between its use and the braces that appear in a message
schematic, the braces define the actual grouping of segments that is
permitted.
A choice of one segment from a group of segments is indicated by using angle
brackets to delimit the group and vertical bar delimiters between the several
segments.
Example: The ORM^O01, as described in chapter 4 section 4.4.1, allows a choice
of order detail segments. The choice would be represented as follows:
<OBR|RQD|RQ1|RXO|ODS|ODT>
c) message segments. The segments defined in a chapter are then listed
in a functional order designed to maximize conceptual clarity.
d) examples. Complete messages are included.
e) implementation considerations. Special supplementary information is
presented here. This includes issues that must be addressed in planning an
implementation.
f) outstanding issues. Issues still under consideration or requiring
consideration are listed here.
Consider the hypothetical triggering event a widget report is requested.
It might be served by the Widget Request (WRQ) and Widget Report (WRP)
messages. These would be defined in the Widget chapter (say Chapter XX). The
Widget Request message might consist of the following segments: Message Header
(MSH), Widget ID (WID). The Widget Report message might consist of the
following segments: Message Header (MSH), Message acknowledgment (MSA), one or
more Widget Description (WDN) Segments each of which is followed by a single
Widget Portion segment (WPN) followed by zero or more Widget Portion Detail
(WPD) segments.
The
schematic form for this hypothetical exchange of messages is shown in Figure 2-5:
WRQ |
Widget Request |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
WID |
Widget ID |
XX |
WRP |
Widget Report |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
{ WDN |
Widget Description |
XX |
WPN |
Widget Portion |
XX |
} |
The
WID, WDN, WPN, and WPD segments would be defined by the widget committee in the
widget chapter, as designated by the Arabic numeral XX in the right column.
The MSH and MSA segments, although included in the widget messages, are defined
in another chapter. They are incorporated by reference into the widget chapter
by the chapter number XX.
On the other hand, the widget committee might decide that the WPN and WPD
segments should appear in pairs, but the pairs are optional and can repeat.
Then the schematic for the WRP message would be as shown in Figure 2-6.
WRF |
Widget Report |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
{ WDN |
Widget Description |
XX |
[ { WPN |
Widget Portion |
XX |
WPD |
Widget Portion Detail |
XX |
} ] |
||
} |
If
the widget committee determined that at least one pair of WPN and WPD segments
must follow a WDN, then the notation would be as shown in Figure 2-7.
WRP |
Widget Report |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
{ WDN |
Widget Description |
XX |
{ WPN |
Widget Portion |
XX |
WPD |
Widget Portion Detail |
XX |
} |
||
} |
The
processing rules described here apply to all exchanges of messages, whether or
not the HL7 encoding rules or Lower Layer Protocols are used. They represent
the primary message processing mode. Certain variants are documented in
Section 2.13.2, "Application (level 7) processing rules, deferred processing
two phase reply (original acknowledgment mode only)." These include:
a) the application processing rules for a special processing mode, deferred
processing. This mode remains in the specification only for backward
compatibility.
b) an optional sequence number protocol
c) an optional protocol for continuing a very long message
The processing rules were extended in Version 2.2 of the Standard. The
extensions provide a greater degree of flexibility in the way that messages can
be acknowledged, as specified by several new fields in the Message Header
segment. To provide backward compatibility with prior versions, the absence of
these fields implies that the extended processing rules are not used. In the
remainder of this section the extended mode is called the enhanced
acknowledgment mode; the prior version is called the original acknowledgment
mode.
Because the protocol describes an exchange of messages, it is described in
terms of two entities, the initiating and responding systems. Each is both a
sender and receiver of messages. The initiating system sends first and then
receives, while the responding system receives and then sends.
In overview this exchange proceeds as follows:
Step 1 the initiating system constructs an HL7 message from application data
and sends it to the responding system
Step 2 responder receives message and
2.1 when the original acknowledgment rules apply:
a) validates the message syntactically and against the detailed rules described
in Section <IP_ADDRESS>.1, If it fails, a reject message is constructed by the
protocol software and returned to the initiator; if it does not fail, continue
to the next step (2.1,b)
b) passes the message to the application, which:
1) creates a response message, or
2) creates an error message, or
3) creates a reject message
c) sends the response, error, or reject message
Initiator passes the message to the initiating application.
2.2 when enhanced acknowledgment rules apply:
See section <IP_ADDRESS>.2
a) the responding system receives the message and commits it to safe storage.
This means that the responding system accepts the responsibility for the
message in a manner that releases the sending system from any obligation to
resend the message. The responding system now checks the message header record
to determine whether or not the initiating system requires an accept
acknowledgment message indicating successful receipt and secure storage of the
message. If it does, the accept acknowledgment message is constructed and
returned to the initiator.
b) at this point, the requirements of the applications involved in the
interface determine whether or not more information needs to be exchanged.
This exchange is referred to as an application acknowledgment and includes
information ranging from simple validation to a complex application-dependent
response. If the receiving system is expected to return application-dependent
information, it initiates another exchange when this information is available.
This time, the roles of initiator and responder are reversed.
The details follow.
The
initiating application creates a message with data values as defined in the
appropriate chapter of this Standard. The fields shown below should be valued
in the MSH segment (as defined under the MSH segment definition of this
chapter). The message is encoded according to the applicable rules and sent to
the lower level protocols, which will attempt to deliver it to the responding
application. (For definitions of the MSH fields see Section 2.16.9, "MSH -
message header segment")
Field |
Notes |
|---|---|
MSH-3-sending application |
|
MSH-4-sending facility |
|
MSH-5-receiving application |
|
MSH-6-receiving facility |
|
MSH-7-date/time of message |
|
MSH-9-message type |
|
MSH-10-message control ID |
Unique identifier used to relate the response to the initial message. |
MSH-11-processing ID |
|
MSH-12-version ID |
|
MSH-13-sequence number |
|
MSH-14-continuation pointer |
Used in implementation of message continuation protocol. See Section 2.15.2, "Continuation messages and segments". Also see chapter 5. |
Certain
other fields in the MSH segment are required for the operation of the HL7
encoding rules; they will not be relevant if other encoding rules are
employed.
The event code in the second component of MSH-9-message type is
redundantly shown elsewhere in some messages. For example, the same
information is in the EVN segment of the ADT message. This is for
compatibility with prior versions of the HL7 protocol. Newly-defined messages
should only show the event code in MSH-9-message type.
The protocol software in the responding system does one of the following:
Note:
Both MSH-15-accept acknowledgment type and MSH-16-application acknowledgment
type are null or not present.
a) accepts the message
b) validates it against at least the following criteria:
1) the value in MSH-9-message type is one that is acceptable to the
receiver
2) the value in MSH-12-version ID is acceptable to the receiver
3) the value in MSH-11-processing ID is appropriate for the application
process handling the message
If any of these edits fail, the protocol software rejects the message. That
is, it creates an ACK message with AR in MSA-1-acknowledgment
code.
c) if the message passes the edits, the message is passed to the receiving
application, which performs one of these functions:
1) process the message successfully, generating the functional response message
with a value of AA in MSA-1-acknowledgment code.
-OR-
2) send an error response, providing error information in functional segments
to be included in the response message with a value of AE in
MSA-1-acknowledgment code.
-OR-
3) fail to process (reject) the message for reasons unrelated to its content or
format (system down, internal error, etc.). For most such problems it is
likely that the responding system will be able to accept the same message at a
later time. The implementers must decide on an application-specific basis
whether the message should be automatically sent again. The response message
contains a value of AR in MSA-1-acknowledgment code.
d) passes the message to the initiating system
e) the protocol software in the initiating system passes the response message
to the initiating application
In all the responses described above the following values are put in the MSA
segment. Note that the field definitions for the MSA segment fields are in
Section 2.16.8, "MSA - message acknowledgment segment":
Field |
Notes |
MSA-1-acknowledgment code |
As described above. |
MSA-2-message control ID |
MSH-10-message control ID from MSH segment of incoming message. |
MSA-3-text message |
Text description of error. |
MSA-4-expected sequence number |
As described in Section 2.15.1, "Sequence number protocol," (if the sequence number protocol is being used). |
MSA-5-delayed acknowledgment type |
For use only as described in Section Application (level 7) processing rules, deferred processing two phase reply (original acknowledgment mode only)." |
The MSH segment in the response is constructed anew following the rules used to create the initial message described above. In particular, MSH-7-date/time of message and MSH-10-message control ID refer to the response message; they are not echoes of the fields in the initial message. MSH-5-receiving application, MSH-6-receiving facility, and MSH-11-processing ID contain codes that are copied from MSH-3-sending application, MSH-4-sending facility and MSH-11-processing ID in the initiating message.
Note:
At least one of MSH-15-accept acknowledgment type or MSH-16-application
acknowledgment type is not null.
a) accepts the message
b) makes an initial determination as to whether or not the message can be
accepted, based on factors such as:
1) the status of the interface
2) the availability of safe storage onto which the message can be saved
3) the syntactical correctness of the message, if the design of the receiving
system includes this type of validation at this phase
4) the values of MSH-9-message type, MSH-12-version ID, and
MSH-11-processing ID, if the design of the receiving system includes
this type of validation at this phase
c) examines the Message Header segment (MSH) to determine whether or not the
initiating system requires an accept acknowledgment.
If it does, the
responding system returns a general acknowledgment message (ACK) with:
1) a commit accept (CA) in MSA-1-acknowledgment code if the message can
be accepted for processing
2) a commit reject (CR) in MSA-1-acknowledgment code if the one of the
values of MSH-9-message type, MSH-12-version ID or
MSH-11-processing ID is not acceptable to the receiving application
3) a commit error (CE) in MSA-1-acknowledgment code if the message
cannot be accepted for any other reason (e.g., sequence number
error)
For this response, the following values are put in the MSA
segment. Note that the field definitions for the MSA segment fields are in
Section 2.16.8, "MSA - message acknowledgment segment":
Field |
Notes |
MSA-2-message control ID |
MSH-10-message control ID from the incoming message. |
MSA-1-acknowledgment code |
As described above. |
MSA-3-text message |
Text description of error. |
MSA-4-expected sequence number |
As described in Section 2.15.1, "Sequence number protocol" (if the sequence number protocol is being used). |
The
MSH segment in the response is constructed anew following the rules used to
create the initial message described above. In particular, MSH-7-date/time
of message and MSH-10-message control ID refer to the response
message; they are not echoes of the fields in the initial message.
MSH-5-receiving application, MSH-6-receiving facility, and
MSH-11-processing ID contain codes that are copied from MSH-3-sending
application, MSH-4-sending facility and MSH-11-processing ID
in the initiating message.
Note: MSH-15-accept acknowledgment type and MSH-16-application
acknowledgment type are not valued (not present or null). At this point, the
accept portion of this message exchange is considered complete.
d) If the message header segment indicates that the initiating system also
requires an application acknowledgment, this will be returned as the initial
message of a later exchange.
For this response, the following values are put in the MSA segment. Note that
the field definitions for the MSA segment fields are in Section 2.16.8, "MSA -
message acknowledgment segment":
Field |
Notes |
MSA-2-message control ID |
Identifies the initial message from the original initiating system as defined in Section <IP_ADDRESS>, "Initiation". |
MSA-1-acknowledgment code |
Uses the application (processing) acknowledgment codes as described in Section <IP_ADDRESS>.1, "When the original acknowledgment rules apply" |
MSA-3-text message |
Text description of error. |
For
this message, the receiving system acts as the initiator. Since the message it
sends is application-specific, the layouts of these application-level response
messages are defined in the relevant application-specific chapter. If needed,
this application acknowledgment message can itself require (in MSH-15-accept
acknowledgment type) an accept acknowledgment message (MSA).
MSH-16-application acknowledgment type, however, is always null, since
the protocol does not allow the application acknowledgment message to have an
application acknowledgment.
At this point, the application acknowledgment portion of this message exchange
is considered complete.
If the processing on the receiving system goes through multiple stages,
chapter-defined messages may be used to relay status or informational changes
to other systems (including the original initiating system). Such messages are
not part of the acknowledgment scheme for the original message, but are
considered to be independent messages triggered by events on the (original)
responding system.
Note: The original acknowledgment protocol is equivalent to the
enhanced acknowledgment protocol with MSH-15-accept acknowledgment type
= NE and MSH-16-application acknowledgment type = AL, and with the
application acknowledgment message defined so that it never requires an accept
acknowledgment (MSH-15-accept acknowledgment type = NE).
(This
section remains in the specification only for reasons of providing backward
compatibility: it is to be used only with the original acknowledgment protocol.
For the original acknowledgment protocol, it creates a generic form of an
asynchronous application level acknowledgment, the MCF message.)
The application processing rules for deferred processing are described here.
In this mode the responding system sends an acknowledgment to the initiating
system that means the message has been placed in some type of secure
environment (e.g., disk storage), and the receiving system commits to
processing it within a reasonable amount of time, if a) the message contains
the necessary information, and b) nothing causes the message's request for
action to be canceled before the responding system processes the request.
Note: Neither of these two conditions is completely checked at the time
of the first acknowledgment. They are both checked at the time of
processing.
The receipt of the first delayed acknowledgment by the initiating system means
that the responding system has taken responsibility for the subsequent
processing of the message. This also implies that the initiating system no
longer needs to keep the particular message in its current form to send out
later. For example, if the sending system were maintaining a queue of outgoing
messages, the particular message could be deleted from the output queue at this
point.
The receipt of the second delayed acknowledgment message informs the initiating
application of either: a) the application's successful processing of the
initial message, or b) an error that prevented its processing. If the
receiving application needs to return detailed change of status information, an
application-specific message will be used. An example of the latter is the
General Order message (ORM) described in Chapter 4.
The general delayed acknowledgment protocol is implemented on a site-specific
and application-specific basis as needed. At a particular site, for a given
transaction type the choices are:
a) do not allow deferred acknowledgments
b) all messages will have a deferred acknowledgment
c) only exceptional cases (errors) will receive the deferred acknowledgment
In overview the processing for options b) and c) proceeds as follows:
Initiator receives message from sending application and sends it to the
responding system.
The responding system receives the message from the initiating system and
a) partially validates it syntactically and against the detailed rules
described in Section 2.13.1, "Original and enhanced processing rules." This
validation need not be complete but should be sufficient to determine the
application that will ultimately respond to the message. If this validation
fails, a reject message is constructed by the protocol software and returned to
the initiator.
b) (if the message passes this validation) stores it and constructs a response
message that simply acknowledges receipt. MSA-5-delayed acknowledgment
type then has a value of D.
c) subsequently passes the message to the application, which:
1) creates a response message, or
2) creates an error message, or
3) creates a reject message
d) The protocol software sends the response, error, or reject message to the
initiating system as an unsolicited update with no value present in
MSA-5-delayed acknowledgment type.
The protocol software of the initiating system responds to the response, error,
or reject message with simple acknowledgment and passes it to the initiating
application.
The details follow.
The rules for creating the initial message are exactly as defined in Section 2.13.1, "Original and enhanced processing rules," for the original acknowledgment rules.
The
processing in the responding system follows this pattern:
a) the protocol software accepts the message and validates it against at least
the following criteria:
1) the value in MSH-9-message type is one that is acceptable to the
receiver
2) the value in MSH-12-version ID is acceptable to the receiver
3) the value in MSH-11-processing ID is appropriate for the application
process handling the message
If any of these edits fail, the protocol software rejects the message. That
is, it creates an ACK message with AR in MSA-1-acknowledgment
code.
b) If the message passes the edits, the protocol software stores it and
generates a response message of type ACK with a value of AA in
MSA-1-acknowledgment code and D in MSA-5-delayed
acknowledgment type.
c) Subsequently the protocol software passes the message to the application,
which performs one of these functions:
1) processes the message successfully, generating the functional response
message (message type MCF) with a value of AA in MSA-1-acknowledgment
code.
- OR -
2) creates an error response, providing error information in functional
segments to be included in the response message, which has a value of AE
in MSA-1-acknowledgment code.
- OR -
3) fails to process (rejects) the message for reasons unrelated to its content
or format (system down, internal error, etc.) For most such problems it is
likely that the responding system will be able to accept the same message at a
later time. The implementors must decide on an application-specific basis
whether the message should be automatically sent again. The MSA segment of the
response message contains a value of AR in MSA-1-acknowledgment
code.
d) the application passes the message to the protocol software, which
constructs a message of type MCF with F in MSA-5-delayed
acknowledgment type.
e) the protocol software passes the message to the initiating system as an
unsolicited update.
f) the protocol software in the initiating system passes the response message
to the initiating application and generates a simple ACK message. No value is
present in MSA-5-delayed acknowledgment type.
All other values are put in the MSA segment as described in Section 2.13.1,
"Original and enhanced processing rules."
Acknowledgment messages may be defined on an application basis. However the simple general acknowledgment message (ACK) may be used where the application does not define a special message (application level acknowledgment) and in other cases as described in Section 2.13.1, "Original and enhanced processing rules." The MCF message is included only for backward compatibility with HL7 Version 2.1 (see Section 2.12.2, "Application (level 7) processing rules, deferred processing two phase reply (original acknowledgment mode only)").
The
simple general acknowledgment (ACK) can be used where the application does not
define a special application level acknowledgment message or where there has
been an error that precludes application processing. It is also used for
accept level acknowledgments. The details are described in Section 2.13.1,
"Original and enhanced processing rules."
ACK^varies^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
Note: For the general acknowledgment (ACK) message, the value of MSH-9-2-Trigger event is equal to the value of MSH-9-2-Trigger event in the query message being acknowledged. The value of MSH-9-3-Message structure for the general acknowledgment message is always ACK.
This
message remains in the specification only for reasons of backward compatibility
with HL7 Version 2.1. It is used as part of the protocol which creates
a generic form of an asynchronous application level acknowledgment, the MCF
message. See Section <IP_ADDRESS>, "Response."
The first MCF message, sent after the initial receipt has the following
structure.
MCF^varies^ACK |
Delayed Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
The
second MCF message, sent after application processing, has this structure:
MCF^varies^ACK |
Delayed Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
This section contains several extensions to the basic HL7 message protocol. These extensions represent implementation choices, and are to be used on a site-specific and application-specific basis as needed.
For
certain types of data transactions between systems the issue of keeping
databases synchronized is critical. An example is an ancillary system such as
lab, which needs to know the locations of all inpatients to route stat results
correctly. If the lab receives an ADT transaction out of sequence, the
census/location information may be incorrect. Although it is true that a
simple one-to-one acknowledgment scheme can prevent out-of-sequence
transactions between any two systems, only the use of sequence numbers can
prevent duplicate transactions.
Note: Although this sequence number protocol is limited to the use of
sequence numbers on a single transaction stream between two applications, this
sequencing protocol is sufficiently robust to allow the design of
HL7-compatible store-and-forward applications.
a) initial conditions:
1) the system receiving the data stream is expected to store the sequence
number of the most recently accepted transaction in a secure fashion before
acknowledging that transaction. This stored sequence number allows comparison
with the next transaction's sequence number, and the implementation of
fault-tolerant restart capabilities.
2) the initiating system keeps a queue of outgoing transactions indexed by the
sequence number. The length of this queue must be negotiated as part of the
design process for a given link. The minimum length for this queue is one.
3) the sequence number is a positive (non-zero) integer; and it is incremented
by one (by the initiating system) for each successive transaction.
b) starting the link:
1) the value of 0 (zero) for a sequence number is reserved: it is allowed only
when the initiating system (re-)starts the link.
2) if the receiving system gets a transaction with a 0 (zero) in the sequence
number field, it should respond with a general acknowledgment message whose MSA
contains a sequence number one greater than the sequence number of the last
transaction it accepted in the Expected Sequence Number field. If this value
does not exist (as on the first startup of a given link), the MSA should
contain a sequence number of -1, meaning that the receiving system will use the
positive, non-zero sequence number of the first transaction it accepts as its
initial sequence number (see resynching the link, item e below).
3) the initiating system then sends the transaction indexed by the expected
sequence number (if that expected transaction is still on its queue).
Otherwise the link is frozen until an operator intervenes.
c) normal operation of the link:
As it accepts each transaction, the receiving system securely stores the
sequence number (which agrees with its expected sequence number), and then
acknowledges the message by echoing the sequence number in MSA-4-expected
sequence number.
d) error conditions (from point of view of initiating system). These are
generated by the receiving system, by its comparison of the sequence number
sent out (with the MSH in MSH-13-sequence number) with the expected
sequence number (MSA-4-expected sequence number received with the
MSA).
1) expected sequence number is one greater than current value. The
previous acknowledgment was lost. That transaction was sent again. Correct by
sending next transaction.
2) expected sequence number less than current value. Initiating system
can try starting again by issuing a transaction with a sequence number of zero;
or freeze the link for operator intervention.
3) other errors: freeze the link for operator intervention
e) forcing resynchronization of sequence numbers across the link. The value of
-1 for a sequence number is reserved: it is allowed only when the initiating
system is resynching the link. Thus if the receiving system gets a value of -1
in the sequence number field, it should return a general acknowledgment message
with a -1 in the expected sequence number field. The receiving system then
resets its sequence number, using the non-zero positive sequence number of the
next transaction it accepts.
f) notes
When the initiating system sends a message with a sequence number of 0
or -1 (see b or e above), the segments beyond the MSH need not be
present in the message, or, if present, all fields can be null. In terms of
the responding system, for these two cases, only a General acknowledgment
message is needed.
Sometimes,
implementation limitations require that large messages or segments be broken
into manageable chunks. We use the term "fragmentation" to describe how a
logical message is broken into one or more separate HL7 messages. HL7
consciously identifies two situations where this may happen.
* First, a single segment may be too large. HL7 uses the "ADD" segment to
handle breaking a single segment into several smaller segments.
* Second, a single HL7 message may be too large. HL7 uses the DSC segment and
the continuation protocol to handle message fragmentation.
Note: HL7 does not define what "too large" means. Acceptable values
are subject to site negotiations.
See chapter 5 for a discussion of the continuation pointer segment and the
continuation pointer field, and their use in the continuation of responses to
queries and in the continuation of unsolicited update messages.
Beginning
with version 2.4, the ADD segment can be used within a message to break
a long segment into shorter segments within a single HL7 message.
Note: Unless some explicit agreement exists between systems, a receiving
application should not infer semantic meaning from the placement of the ADD
segment.
To break a large segment,
a) the segment being continued (call it ANY for this example) is ended at an
arbitrary character position and terminated with the standard segment
terminator (carriage return).
b) the following segment is the ADD segment. All characters after the ADD and
field separator ("|") are logically part of the preceding segment. All
succeeding consecutive ADD segments contribute characters to the ANY segment
until a non ADD segment is found.
c) An ADD segment with no field separator takes on special meaning. See
Section <IP_ADDRESS>, "Segment fragmentation across messages."
For example, segment "C" can be fragmented within an HL7 message as follows
A|1
B|2
C|34
ADD|5|678|
ADD|90
D|1
This is logically the same as
A|1
B|2
C|345|678|90
D|1
Note that the "|" at the end of the first ADD segment is part of the value,
while the first "|" of each ADD is not.
When
a message itself must be fragmented and sent as several HL7 messages, the DSC
segment is used.
a) First, the logical message is broken after an arbitrary segment.
b) Next, a DSC segment is sent. The DSC-1-Continuation pointer field
will contain a unique value which is used to match a subsequent message with
this specific value.
c) The DSC terminates the first fragment of the logical message.
d) A subsequent message will contain in MSH-14-Continuation pointer, a
value which matches the value from DSC-1. (The presence of a value in MSH-14
indicates that the message is a fragment of an earlier message.). Each
subsequent message will have its own unique value for MSH-10-Message control
ID. Coordination between DSC-1-Continuation pointer and the
subsequent message's MSH-14-Continuation pointer is used to link the
fragments in their proper order.
e) The logical message is the concatenation of the contents of the first
message (which while having no value in MSH-14, did end with DSC, and hence was
actually a message fragment), plus all subsequent fragments (as identified by
values in MSH-14).
f) If enhanced mode acknowledgments are used to request an accept ACK, then the
receiver will acknowledge each fragment with an ACK message. Since each
fragment has its own Message Control ID, each fragment level accept ACK will
use the Message Control ID from the fragment it is acknowledging.
g) If enhanced mode acknowledgments are used to request an application level
ACK, then the receiver will send an acknowledgment after receiving the final
fragment.
Note: The application level ACK should refer to the message by the
Message Control ID of the first fragment.
Note: The receiver can tell that a given incoming message is a
fragment by the presence of the trailing DSC. Subsequent HL7 messages are
identified as fragments by the presence of an MSH-14 value. The presence of a
DSC in a fragment indicates that more fragments are to follow.
It is a protocol error to end a message with DSC, and then never send a
fragment.
For example, a single logical message may be fragmented into three HL7
messages.
---- Sender HL7 message (incomplete,fragment1)---
MSH|||||||||1001||2.4|123||..
A|...
B|...
DSC|W4xy
---- Sender HL7 message (fragment 2)---
MSH|||||||||2106||2.4|124|W4xy|
C|...
D|...
DSC|V292
----- another HL7 message(fragment 3, final)---
MSH|||||||||2401||2.4|125|V292
E|...
Such a sequence is logically the same as the single message
MSH|....|2.4|123||..
A|...
B|...
C|...
D|...
E|...
See example in section
2.18.4
for a more elaborate example.
If
the last segment of a fragment itself needs to be broken, then the following
idiomatic use of ADD shall apply.
a) the segment being continued (call it ANY for this example) is ended at an
arbitrary character position and terminated with the standard segment
terminator (carriage return).
b) the following segment is the ADD segment. It will contain no characters
other than "ADD". (The lack of characters signals the receiver that ANY will be
continued.)
c) The second following segment will be the DSC, used as described above in
Section <IP_ADDRESS>, "Segment fragmentation/continuation using the DSC segment
".
d) The first segment of the following fragment will be an ADD segment. The
characters of this ADD segment are logically part of the ANY segment of the
previous fragment.
For example
MSH|...|2.4|
A|12
ADD
DSC|JR97
--------- (fragment 2)
MSH|...|2.4|JR97
ADD|345
is logically the same as
MSH|...|2.4
A|12345
e) transaction flow for a continued unsolicited message with a continued
segment. first unsolicited message and acknowledgment:
MSH |
|
URD |
|
[ URS ] |
|
{DSP} |
(last DSP is incomplete) |
ADD |
(contains no fields) |
DSC |
(Continuation segment) |
MSH |
(General acknowledgment) |
MSA |
|
[ ERR ] |
f)
second unsolicited message and acknowledgment:
MSH |
(contains continuation pointer from DSC segment of prior message) |
ADD |
(contains remainder of data from continued DSP segment from prior message) |
{DSP} |
Note: This second message could itself be continued with a second DSC
and (if needed) a second ADD segment prior to it.
MSH |
(General acknowledgment) |
MSA |
|
[ERR] |
There are instances when it is convenient to transfer a batch of HL7 messages. Common examples would be a batch of financial posting detail transactions (DFT's) sent from an ancillary to a financial system. Such a batch could be sent online using a common file transfer protocol, or offline via tape or diskette.
The
structure of an HL7 batch file is given by the following (using the HL7
abstract message syntax)
[FHS] |
(file header segment) |
{ [BHS] |
(batch header segment) |
{ [MSH |
(zero or more HL7 messages) |
.... |
|
.... |
|
.... |
|
] } |
|
[BTS] |
(batch trailer segment) |
} |
|
[FTS] |
(file trailer segment) |
Notes:
The sequence numbering protocol has a natural application in batch transfers.
See the discussion of batch acknowledgments that follows.
Although a batch will usually consist of a single type of message, there is
nothing in the definition that restricts a batch to only one message type.
The HL7 file and batch header and trailer segments are defined in exactly the
same manner as the HL7 message segments. Hence the HL7 message construction
rules of Section 2.11, "Message construction rules," can be used to encode and
decode HL7 batch files.
There are only two cases in which an HL7 batch file may contain zero HL7
messages:
a) a batch containing zero HL7 messages may be sent to meet a requirement for
periodic submission of batches when there are no messages to send.
b) a batch containing zero negative acknowledgment messages may be sent to
indicate that all the HL7 messages contained in the batch being acknowledged
are implicitly acknowledged. See Section <IP_ADDRESS>, "Acknowledging batches."
The
following segments defined in Section 2.16, "MESSAGE CONTROL SEGMENTS" relate
to the HL7 Batch Protocol:
BHS Batch Header
BTS Batch Trailer
FHS File Header
FTS File Trailer
The BTS segment contains a field, BTS-3-batch totals, which may have one
or more totals drawn from fields within the individual messages. The method
for computing such totals will be determined on a site or application basis
unless explicitly stated in a functional chapter.
In
general, the utility of sending batches of data is that the data is accepted
all at once, with errors processed on an exception basis. However, it is a
permissible application of HL7 to acknowledge all messages. Several options
for acknowledgment are given and will be chosen on an application basis. In
these cases, the sequence numbering protocol can be useful to the applications
processing the batch.
The options are:
a) all messages are acknowledged in the response batch.
b) the receiving system prints some form of batch control report, which is then
dealt with manually by personnel at the sending system. No acknowledgments are
performed by the protocol software.
c) an automated acknowledgment batch is created containing acknowledgment
messages only for those messages containing errors. In this mode an empty
acknowledgment batch may be created (i.e., an HL7 batch file without any HL7
acknowledgment messages).
In each case where there is a response batch, its format is a batch of
individual messages. Each individual message is in the format defined for an
online response in the chapters. Consider, for example, a batch that might be
constructed to respond to a batch of Detailed Financial Transactions (Chapter
6). The messages in the response batch would consist entirely of ACK messages,
since ACK is the response shown in Chapter 6.
When batches are retransmitted after the correction of errors,
BHS-12-reference batch control ID should contain the batch control ID of
the original batch.
The
HL7 query also can be used to query for a batch in the following manner:
a) use the value BB or BL of QRD-5-deferred response type to specify a
batch response. The query will be acknowledged with a general acknowledgment
as in the Deferred Access example above (see chapter 5)
b) in addition, insert into the batch file the QRD and QRF segments as
follows:
[FHS] |
(file header segment) |
{ [BHS] |
(batch header segment) |
[QRD] |
(the QRD and QRF define the |
[QRF] |
query that this batch is a response to) |
{ MSH |
(one or more HL7 messages) |
.... |
|
.... |
|
.... |
|
} |
|
[BTS] |
(batch trailer segment) |
} |
|
[FTS] |
(file trailer segment) |
c) the acknowledgment of a batch is described in this chapter (see Section <IP_ADDRESS>, "Acknowledging batches").
When
groups of repeating segments appear within a message it is not obvious from the
basic HL7 abstract message syntax how best to apply the new group of repeating
segments on the receiving system. HL7 suggests two methods: the "snapshot" mode
and the "action code/unique identifier" mode.
Background:
The segments which repeat in HL7 messages Patient Administration
(ADT)/Financial Information messages (AL1, DG1, PR1, GT1, IN1, IN2, IN3, NK1,
NTE) present a problem if the requirement is to update only part of the
information previously sent. Prior to Version 2.3 of the Standard, all such
repeating segments had to be sent again in the update, because there was no way
to indicate which ones changed and which ones did not. For example, if two DG1
segments were sent originally (containing a primary and secondary diagnosis),
and then if a tertiary diagnoses needed to be sent, the sending system had to
send all diagnoses which were currently valid, that is, three DG1 segments
(containing primary, secondary and tertiary diagnosis). This way of doing
things is referred to as the "snapshot" mode. In this mode, everything (all
repeating segments) must be sent with every subsequent message in the series of
messages.
In the Order Entry, Observation Reporting, and Master Files chapters, action
codes (e.g., order control codes and result status codes) and unique
identifiers (e.g., placer and filler numbers) are currently specified as part
of the ORC, OBR, OBX and MFE segments. So, except for the NTE segments, this
problem exists mainly for the Patient Administration and Financial Management
chapter segments.
For systems implementing Version 2.3 or higher, if a particular repeating
segment can be updated by either of these two modes, the parties concerned will
determine by agreement on a site-specific basis whether an interface will use
the "snapshot" mode or the "action code/unique identifier" mode.
In
the "snapshot" mode, the group of repeating segments from the incoming message
replaces the prior group of repeating segments on the receiving system. This
is equivalent to a deletion of the prior group followed by the addition of the
new group. The snapshot mode is the usual mode in Version 2.2 and 2.1
implementations of HL7, but it is also available for Version 2.3 and future
versions. To specify "delete all of the segments in this repeating group" in
the snapshot mode, send a single segment with "delete data" indicated for all
fields.
For example, if the following DG1 segment is in an ADT update message (for an
inpatient stay):
DG1|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""|""<cr>
and the snapshot mode is being used, this indicates that all
previously-transmitted diagnoses for this inpatient stay should be deleted.
In
the "action code/unique identifier" mode, each member of a repeating group of
segments must have a unique identifier (equivalent to the filler number in
observational reports messages). The choice of delete/update/insert is
determined by the action code (equivalent to the result status in observational
reports messages). Refer to HL7 Table 0206 - Segment actio
n
code for valid values.
Value |
Description |
|---|---|
A |
Add/Insert |
D |
Delete |
U |
Update |
The
unique identifier is defined in a general manner as follows: it uniquely
identifies one of multiple repetitions of the primary entity defined by the
repeating segment in a way that does not change over time. It is not dependent
on any particular message identifier level (MSH) fields; it functions across
messages, not just within a message. The unique identifier will be
chosen on a segment-specific basis, depending on the primary entity referenced
by the segment. For some cases, such as a diagnosis code, it may be a CE data
type. For others, such as a person identifier, it may be a CX data type. For
others it may be an EI (entity identifier) data type.
Note: This mode is available for use only for new segments for Version
2.3 and for new segments in future versions
The
following segments are necessary to support the functionality described in this
chapter.
Note: The HL7 message construction rules define the standard HL7
encoding rules, creating variable length delimited messages from the segments
defined below. Although only one set of encoding rules is defined as a
standard in HL7 Version 2.3, other encoding rules are possible (but since they
are non-standard, they may only used by a site-specific agreement).
The segments in this section are listed in alphabetical order. The following
chart shows a summary of the segments listed by category.
Segment Category |
Segment Name |
HL7 Section Reference |
Control |
||
ADD |
2.16.1 |
|
BHS |
2.16.2 |
|
BTS |
2.16.3 |
|
DSC |
2.16.4 |
|
ERR |
2.16.5 |
|
FHS |
2.16.6 |
|
FTS |
2.16.7 |
|
MSA |
2.16.8 |
|
MSH |
2.16.9 |
|
General Purpose |
||
NTE |
2.16.10 |
|
Query |
||
All query segments have been moved to chapter 5 |
The
ADD segment is used to define the continuation of the prior segment in a
continuation message. See Section2.15.2, "Continuation messages and segments,"
for details.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1-n |
65536 |
ST |
O |
00066 |
Addendum Continuation Pointer |
Definition: This field is used to define the continuation of the prior segment in a continuation message. See section 2.15.2, "Continuation messages and segments" for details. When the ADD is sent after the segment being continued, it contains no fields. It is only a marker that the previous segment is being continued in a subsequent message. Thus fields 1-N are not present. The sequence designation, 1-N, means the remainder of the fields in the segment being continued. These remainder of the segment being continued fields are present only when the ADD is sent with a continuation message.
The
BHS segment defines the start of a batch.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
1 |
ST |
R |
00081 |
Batch Field Separator |
||
2 |
3 |
ST |
R |
00082 |
Batch Encoding Characters |
||
3 |
15 |
ST |
O |
00083 |
Batch Sending Application |
||
4 |
20 |
ST |
O |
00084 |
Batch Sending Facility |
||
5 |
15 |
ST |
O |
00085 |
Batch Receiving Application |
||
6 |
20 |
ST |
O |
00086 |
Batch Receiving Facility |
||
7 |
26 |
TS |
O |
00087 |
Batch Creation Date/Time |
||
8 |
40 |
ST |
O |
00088 |
Batch Security |
||
9 |
20 |
ST |
O |
00089 |
Batch Name/ID/Type |
||
10 |
80 |
ST |
O |
00090 |
Batch Comment |
||
11 |
20 |
ST |
O |
00091 |
Batch Control ID |
||
12 |
20 |
ST |
O |
00092 |
Reference Batch Control ID |
Definition: This field contains the separator between the segment ID and the first real field, BHS-2-batch encoding characters. As such it serves as the separator and defines the character to be used as a separator for the rest of the message. Recommended value is |,(ASCII 124).
Definition: This field contains the four characters in the following order: the component separator, repetition separator, escape characters, and subcomponent separator. Recommended values are ^~\& (ASCII 94, 126, 92, and 38, respectively). See Section 2.8, "MESSAGE DELIMITERS."
Definition: This field uniquely identifies the sending application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined.
Definition: This field contains the address of one of several occurrences of the same application within the sending system. Absent other considerations, the Medicare Provider ID might be used with an appropriate sub-identifier in the second component. Entirely user-defined.
Definition: This field uniquely identifies the receiving applications among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. Entirely site-defined.
Definition: This field identifies the receiving application among multiple identical instances of the application running on behalf of different organizations. See comments BHS-4-batch sending facility. Entirely site-defined.
Definition: This field contains the date/time that the sending system created the message. If the time zone is specified, it will be used throughout the message as the default time zone.
Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified.
Definition: This field can be used by the application processing the batch. It can have extra components if needed.
Definition: This field is a comment field that is not further defined in the HL7 protocol.
Definition: This field is used to uniquely identify a particular batch. It can be echoed back in BHS-12-reference batch control ID if an answering batch is needed.
Definition: This field contains the value of BHS-11-batch control ID when this batch was originally transmitted. Not present if this batch is being sent for the first time. See definition for BHS-11-batch control ID.
The
BTS segment defines the end of a batch.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
10 |
ST |
O |
00093 |
Batch Message Count |
||
2 |
80 |
ST |
O |
00090 |
Batch Comment |
||
3 |
100 |
NM |
O |
Y |
00095 |
Batch Totals |
Definition: This field contains the count of the individual messages contained within the batch.
Definition: This field is a comment field that is not further defined in the HL7 protocol.
Definition:
We encourage new users of this field to use the HL7 Version 2.3 data type of
NM and to define it as "repeating." This field contains the batch total. If
more than a single batch total exists, this field may be repeated.
This field may be defined as a CM data type for backward compatibility with HL7
Versions 2.2 and 2.1 with each total being carried as a separate component.
Each component in this case is an NM data type.
The
DSC segment is used in the continuation protocol.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
180 |
ST |
O |
00014 |
Continuation Pointer |
||
2 |
1 |
ID |
O |
0398 |
01354 |
Continuation Style |
Definition: This field contains the continuation pointer. In an initial query, this field is not present. If the responder returns a value of null or not present, then there is no more data to fulfill any future continuation requests. For use with continuations of unsolicited messages, see chapter 5 and section 2.15.2, "Continuation messages and segments." Note that continuation protocols work with both display- and record-oriented messages.
Definition:
Indicates whether this is a fragmented message (see Section 2.15.2,
"Continuation messages and segments"), or if it is part of an interactive
continuation message (see Section 5.6.3, "Interactive continuation of response
messages").
Refer to HL7 Table 0398 - Continuation style code
for valid values.
Value |
Description |
|---|---|
F |
Fragmentation |
I |
Interactive Continuation |
The
ERR segment is used to add error comments to acknowledgment messages.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
80 |
CM |
R |
Y |
00024 |
Error Code and Location |
Components:
<segment ID (ST)> ^ <sequence (NM)> ^ <field position (NM)>
^ <code identifying error (CE)>
Definition: This field identifies an erroneous segment in another message. The
second component is an index if there is more than one segment of type
<segment ID>. For systems that do not use the HL7 Encoding Rules, the
data item number may be used for the third component. The fourth component
(which references HL7 Table 0357 - Message error c
ondition
codes, (as a CE data type)) is restricted from having any subcomponents
as the subcomponent separator is now the CE's component separator.
Note: See section <IP_ADDRESS>, MSA-6-error condition, for a
listing of this table.
The
FHS segment is used to head a file (group of batches) as defined in Section
2.15.3, "HL7 batch protocol."
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
1 |
ST |
R |
00067 |
File Field Separator |
||
2 |
4 |
ST |
R |
00068 |
File Encoding Characters |
||
3 |
15 |
ST |
O |
00069 |
File Sending Application |
||
4 |
20 |
ST |
O |
00070 |
File Sending Facility |
||
5 |
15 |
ST |
O |
00071 |
File Receiving Application |
||
6 |
20 |
ST |
O |
00072 |
File Receiving Facility |
||
7 |
26 |
TS |
O |
00073 |
File Creation Date/Time |
||
8 |
40 |
ST |
O |
00074 |
File Security |
||
9 |
20 |
ST |
O |
00075 |
File Name/ID |
||
10 |
80 |
ST |
O |
00076 |
File Header Comment |
||
11 |
20 |
ST |
O |
00077 |
File Control ID |
||
12 |
20 |
ST |
O |
00078 |
Reference File Control ID |
Definition: This field has the same definition as the corresponding field in the MSH segment.
Definition: This field has the same definition as the corresponding field in the MSH segment.
Definition: This field has the same definition as the corresponding field in the MSH segment.
Definition: This field has the same definition as the corresponding field in the MSH segment.
Definition: This field has the same definition as the corresponding field in the MSH segment.
Definition: This field has the same definition as the corresponding field in the MSH segment.
Definition: This field has the same definition as the corresponding field in the MSH segment.
Definition: This field has the same definition as the corresponding field in the MSH segment.
Definition: This field can be used by the application processing file. Its use is not further specified.
Definition: This field contains the free text field, the use of which is not further specified.
Definition: This field is used to identify a particular file uniquely. It can be echoed back in FHS-12-reference file control ID.
Definition: This field contains the value of FHS-11-file control ID when this file was originally transmitted. Not present if this file is being transmitted for the first time.
The
FTS segment defines the end of a file.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
10 |
NM |
O |
00079 |
File Batch Count |
||
2 |
80 |
ST |
O |
00080 |
File Trailer Comment |
Definition: This field contains the number of batches contained in this file.
Definition: The use of this free text field is not further specified.
The
MSA segment contains information sent while acknowledging another message.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
2 |
ID |
R |
0008 |
00018 |
Acknowledgment Code |
|
2 |
20 |
ST |
R |
00010 |
Message Control ID |
||
3 |
80 |
ST |
O |
00020 |
Text Message |
||
4 |
15 |
NM |
O |
00021 |
Expected Sequence Number |
||
5 |
1 |
ID |
B |
0102 |
00022 |
Delayed Acknowledgment Type |
|
6 |
250 |
CE |
O |
0357 |
00023 |
Error Condition |
Definition:
This field contains an acknowledgment code, see message processing rules.
Refer to HL7 Table 0008 - Acknowledgment code for valid values.
Value |
Description |
|---|---|
AA |
Original mode: Application Accept - Enhanced mode: Application acknowledgment: Accept |
AE |
Original mode: Application Error - Enhanced mode: Application acknowledgment: Error |
AR |
Original mode: Application Reject - Enhanced mode: Application acknowledgment: Reject |
CA |
Enhanced mode: Accept acknowledgment: Commit Accept |
CE |
Enhanced mode: Accept acknowledgment: Commit Error |
CR |
Enhanced mode: Accept acknowledgment: Commit Reject |
Definition: This field contains the message control ID of the message sent by the sending system. It allows the sending system to associate this response with the message for which it is intended.
Definition:
This optional field further describes an error condition. This text may be
printed in error logs or presented to an end user.
Use of MSA-3-text message and MSA-6-error condition are
deprecated in favor of ERR-1-Error code and location. The ERR
segment allows for richer descriptions of the erroneous conditions.
Definition: This optional numeric field is used in the sequence number protocol.
Definition:
This field has been retained for backward compatibility. This
field is used only as described above, in Section 2.13.2, "Application (level
7) processing rules, deferred processing two phase reply (original
acknowledgment mode only)." Otherwise this field is not used.
Value |
Description |
|---|---|
D |
Message received, stored for later processing |
F |
acknowledgment after processing |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field allows the acknowledging system to use a user-defined
error code to further specify AR or AE type acknowledgments. This field is a
generalized replacement for MSA-3-text message.
Use of MSA-3-text message and MSA-6-error condition are
deprecated in favor of ERR-1-Error code and location. The ERR
segment allows for richer descriptions of the erroneous conditions.
The Message Error Condition codes are defined by HL7 Table 0357 - Message
error condition codes.
Error Condition Code |
Error Condition Text |
Description/Comment |
|---|---|---|
Success |
||
0 |
Message accepted |
Success. Optional, as the AA conveys success. Used for systems that must always return a status code. |
Errors |
||
100 |
Segment sequence error |
The message segments were not in the proper order, or required segments are missing. |
101 |
Required field missing |
A required field is missing from a segment |
102 |
Data type error |
The field contained data of the wrong data type, e.g. an NM field contained "FOO". |
103 |
Table value not found |
A field of data type ID or IS was compared against the corresponding table, and no match was found. |
Rejection |
||
200 |
Unsupported message type |
The Message Type is not supported. |
201 |
Unsupported event code |
The Event Code is not supported. |
202 |
Unsupported processing id |
The Processing ID is not supported. |
203 |
Unsupported version id |
The Version ID is not supported. |
204 |
Unknown key identifier |
The ID of the patient, order, etc., was not found. Used for transactions other than additions, e.g. transfer of a non-existent patient. |
205 |
Duplicate key identifier |
The ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.). |
206 |
Application record locked |
The transaction could not be performed at the application storage level, e.g. database locked. |
207 |
Application internal error |
A catchall for internal errors not explicitly covered by other codes. |
The
MSH segment defines the intent, source, destination, and some specifics of the
syntax of a message.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
1 |
ST |
R |
00001 |
Field Separator |
||
2 |
4 |
ST |
R |
00002 |
Encoding Characters |
||
3 |
180 |
HD |
O |
0361 |
00003 |
Sending Application |
|
4 |
180 |
HD |
O |
0362 |
00004 |
Sending Facility |
|
5 |
180 |
HD |
O |
0361 |
00005 |
Receiving Application |
|
6 |
180 |
HD |
O |
0362 |
00006 |
Receiving Facility |
|
7 |
26 |
TS |
R |
00007 |
Date/Time Of Message |
||
8 |
40 |
ST |
O |
00008 |
Security |
||
9 |
13 |
CM |
R |
0076/ 0003 |
00009 |
Message Type |
|
10 |
20 |
ST |
R |
00010 |
Message Control ID |
||
11 |
3 |
PT |
R |
00011 |
Processing ID |
||
12 |
60 |
VID |
R |
0104 |
00012 |
Version ID |
|
13 |
15 |
NM |
O |
00013 |
Sequence Number |
||
14 |
180 |
ST |
O |
00014 |
Continuation Pointer |
||
15 |
2 |
ID |
O |
0155 |
00015 |
Accept Acknowledgment Type |
|
16 |
2 |
ID |
O |
0155 |
00016 |
Application Acknowledgment Type |
|
17 |
3 |
ID |
O |
0399 |
00017 |
Country Code |
|
18 |
16 |
ID |
O |
Y |
0211 |
00692 |
Character Set |
19 |
250 |
CE |
O |
00693 |
Principal Language Of Message |
||
20 |
20 |
ID |
O |
0356 |
01317 |
Alternate Character Set Handling Scheme |
|
21 |
10 |
ID |
O |
Y |
0449 |
01598 |
Conformance Statement ID |
Definition: This field contains the separator between the segment ID and the first real field, MSH-2-encoding characters. As such it serves as the separator and defines the character to be used as a separator for the rest of the message. Recommended value is |, (ASCII 124).
Definition: This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. Recommended values are ^~\& (ASCII 94, 126, 92, and 38, respectively). See Section 2.8, "MESSAGE DELIMITERS."
Components:
<namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type
(ID)>
Definition: This field uniquely identifies the sending application among all
other applications within the network enterprise. The network enterprise
consists of all those applications that participate in the exchange of HL7
messages within the enterprise. Entirely site-defined. User-defined Table
0361-Sending/receiving application is used as the user-defined table of
values for the first component.
Value |
Description |
|---|---|
No suggested values defined |
Note: By site agreement, implementors may continue to use User-defined Table 0 300 - Namespace ID for the first component.
Components:
<namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type
(ID)>
Definition: This field further describes the sending application,
MSH-3-sending application. With the promotion of this field to an HD
data type, the usage has been broadened to include not just the sending
facility but other organizational entities such as a) the organizational entity
responsible for sending application; b) the responsible unit; c) a product or
vendor's identifier, etc. Entirely site-defined. User-defined Table 0362
- Sending/receiving facility is used as the HL7 identifier for
the user-defined table of values for the first component.
Value |
Description |
|---|---|
No suggested values defined |
Note: By site agreement, implementers may continue to use User-defined Table 0300 - Namespace ID for the first component.
Components:
<namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type
(ID)>
Definition: This field uniquely identifies the receiving application among all
other applications within the network enterprise. The network enterprise
consists of all those applications that participate in the exchange of HL7
messages within the enterprise. Entirely site-defined. User-defined
Table 0361-Sending/receiving application is used as the HL7 identifier
for the user-defined table of values for the first component.
Note: By site agreement, implementers may continue to use
User-defined Table 0300 - Nam
espace
ID for the first component.
Components:
<namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type
(ID)>
Definition: This field identifies the receiving application among multiple
identical instances of the application running on behalf of different
organizations. User-defined Table 0362 - Sending/rec
eiving
facility is used as the HL7 identifier for the user-defined table of
values for the first component. Entirely site-defined.
Note: By site agreement, implementers may continue to use
User-defined Table 0300 - Namespa
ce
I
D
for the first component.
Definition:
This field contains the date/time that the sending system created the message.
If the time zone is specified, it will be used throughout the message as the
default time zone.
Note: This field was made required in version 2.4. Messages with
versions prior to 2.4 are not required to value this field. This usage
supports backward compatibility.
Definition: In some applications of HL7, this field is used to implement security features. Its use is not yet further specified.
Components:
<message type (ID)> ^ <trigger event (ID)> ^ <message structure
(ID)>
Definition: This field contains the message type, trigger event, and the
message structure ID for the message.
The first component is the message type code defined by HL7 Table
0076
- Mes
sage
type. This table contains values such as ACK, ADT, ORM, ORU etc. See
section 2.17.1 or Appendix A for complete listing.
The second component is the trigger event code defined by HL7 Table 0003
- Event type. This table contains values like A01, O01, R01 etc. See
section 2.17.2 or Appendix A for a complete listing
The third component is the abstract message structure code defined by HL7
Table 0354 - Message structure. This table has two columns. The first
column contains the value of this code, which describes a particular HL7
"abstract message structure definition" in terms of segments, as defined in
sections 2.12, "CHAPTER FORMATS FOR DEFINING HL7 MESSAGES" and 2.12.1, "HL7
abstract message syntax example". The second column of table 0354 lists the
various HL7 trigger events that use the particular abstract message definition.
For example, the message structure code ADT_A01 describes the single abstract
message structure used by the trigger events A01, A04, A05, A08, A13, A14, A28
and A31. See section 2.17.3 or Appendix A for a complete listing.
The receiving system uses this field to recognize the data segments, and
possibly, the application to which to route this message. For certain queries,
which may have more than a single response event type, the second component
may, in the response message, vary to indicate the response event type. See
the discussion of the display query variants in chapter 5. The second component
is not required on response or acknowledgment messages.
Definition: This field contains a number or other identifier that uniquely identifies the message. The receiving system echoes this ID back to the sending system in the Message acknowledgment segment (MSA).
Components:
<processing ID (ID)> ^ <processing mode (ID)>
Definition: This field is used to decide whether to process the message as
defined in HL7 Application (level 7) Processing rules. The first component
defines whether the message is part of a production, training, or debugging
system (refer to HL7 Table 0103 - Proce
ssing
ID for valid values). The second component defines whether the message
is part of an archival process or an initial load (refer to HL7
Table 0207 - Processi
ng
mode for valid values). This allows different priorities to be
given to different processing modes.
Value |
Description |
|---|---|
D |
Debugging |
P |
Production |
T |
Training |
Value |
Description |
|---|---|
A |
Archive |
R |
Restore from archive |
I |
Initial load |
T |
Current processing, transmitted at intervals (scheduled or on demand) |
Not present |
Not present (the default, meaning current processing) |
Components:
<version ID (ID)> ^ <internationalization code (CE)> ^
<internal version ID (CE)>
Definition: This field is matched by the receiving system to its own version
to be sure the message will be interpreted correctly. Beginning with Version
2.3.1, it has two additional "internationalization" components, for use by HL7
international affiliates. The <internationalization code> is CE data type
(using the ISO country codes where appropriate) which represents the HL7
affiliate. The <internal version ID> is used if the HL7 Affiliate has
more than a single `local' version associated with a single US version. The
<internal version ID> has a CE data type, since the table values vary for
each HL7 Affiliate.
Value |
Description |
Date |
|---|---|---|
2.0 |
Release 2.0 |
September 1988 |
2.0D |
Demo 2.0 |
October 1988 |
2.1 |
Release 2. 1 |
March 1990 |
2.2 |
Release 2.2 |
December 1994 |
2.3 |
Release 2.3 |
March 1997 |
2.3.1 |
Release 2.3.1 |
May 1999 |
2.4 |
Release 2.4 |
November 2000 |
Definition: A non-null value in this field implies that the sequence number protocol is in use. This numeric field is incremented by one for each subsequent value.
Definition:
This field is used to define continuations in application-specific ways.
Only the sender of a fragmented message values this field.
Definition: This field identifies the conditions under which accept acknowledgments are required to be returned in response to this message. Required for enhanced acknowledgment mode. Refer to HL7 Table 0155 - Accept/application ack nowledgment conditions for valid values.
Definition:
This field contains the conditions under which application acknowledgments are
required to be returned in response to this message. Required for enhanced
acknowledgment mode.
The following table contains the possible values for MSH-15-accept
acknowledgment type and MSH-16-application acknowledgment type:
Value |
Description |
|---|---|
AL |
Always |
NE |
Never |
ER |
Error/reject conditions only |
SU |
Successful completion only |
Note: If MSH-15-accept acknowledgment type and MSH-16-application acknowledgment type are omitted (or are both null), the original acknowledgment mode rules are used.
Definition:
This field contains the country of origin for the message. It will be used
primarily to specify default elements, such as currency denominations. The
values to be used are those of ISO 3166, which are reprinted here upon written
approval from ANSI.[2]. The ISO 3166 table has
three separate forms of the country code: HL7 specifies that the 3-character
(alphabetic) form be used for the country code.
Refer to HL7 Tabl
e
0399 - Country code for the 3-character codes as defined by ISO 3166
table.
Value |
Description |
|---|---|
ABW |
ARUBA |
AFG |
AFGHANISTAN |
AFT |
FRENCH SOUTHERN TERRITORIES |
AGO |
ANGOLA |
AIA |
ANGUILLA |
ALB |
ALBANIA |
AND |
ANDORRA |
ANT |
NETHERLANDS ANTILLES |
ARE |
UNITED ARAB EMIRATES |
ARG |
ARGENTINA |
ARM |
ARMENIA |
ASM |
AMERICAN SAMOA |
ATA |
ANTARCTICA |
ATG |
ANTIGUA AND BARBUDA |
AUS |
AUSTRALIA |
AUT |
AUSTRIA |
AZE |
AZERBAIJAN |
BDI |
BURUNDI |
BEL |
BELGIUM |
BEN |
BENIN |
BFA |
BURKINA FASO |
BGD |
BANGLADESH |
BGR |
BULGARIA |
BHR |
BAHRAIN |
BHS |
BAHAMAS |
BIH |
BOSNIA AND HERZEGOVINA |
BLR |
BELARUS |
BLZ |
BELIZE |
BMU |
BERMUDA |
BOL |
BOLIVIA |
BRA |
BRAZIL |
BRB |
BARBADOS |
BRN |
BRUNEI DARUSSALAM |
BTN |
BHUTAN |
BVT |
BOUVET ISLAND |
BWA |
BOTSWANA |
CAF |
CENTRAL AFRICAN REPUBLIC |
CAN |
CANADA |
CCK |
COCOS (KEELING) ISLANDS |
CHE |
SWITZERLAND |
CHL |
CHILE |
CHN |
CHINA |
CIV |
COTE D'VOIRE |
CMR |
CAMEROON |
COD |
CONGO, THE DEMOCRATIC REPUBLIC OF THE |
COG |
CONGO |
COK |
COOK ISLAND |
COL |
COLOMBIA |
COM |
COMOROS |
CPV |
CAPE VERDE |
CRI |
COSTA RICA |
CUB |
CUBA |
CXR |
CHRISTMAS ISLAND |
CYM |
CAYMAN ISLANDS |
CYP |
CYPRUS |
CZE |
CZECH REPUBLIC |
DEU |
GERMANY |
DJI |
DJIBOUTI |
DMA |
DOMINICA |
DNK |
DENMARK |
DOM |
DOMINICAN REPUBLIC |
DZA |
ALGERIA |
ECU |
ECUADOR |
EGY |
EGYPT |
ERI |
ERITREA |
ESH |
WESTERN SAHARA |
ESP |
SPAIN |
EST |
ESTONIA |
ETH |
ETHIOPIA |
FIN |
FINLAND |
FJI |
FIJI |
FLK |
FALKLAND ISLANDS (MALVINAS) |
FRA |
FRANCE |
FRO |
FAROE ISLANDS |
FSM |
MICRONESIA, FEDERATED STATES OF |
GAB |
GABON |
GBR |
UNITED KINGDOM |
GEO |
GEORGIA |
GHA |
GHANA |
GIB |
GIBRALTAR |
GIN |
GUINEA |
GLP |
GUADELOUPE |
GMB |
GAMBIA |
GNB |
GUINEA-BISSAU |
GNQ |
EQUATORIAL GUINEA |
GRC |
GREECE |
GRD |
GRENADA |
GRL |
GREENLAND |
GTM |
GUATEMALA |
GUF |
FRENCH GUIANA |
GUM |
GUAM |
GUY |
GUYANA |
HKG |
HONG KONG |
HMD |
HEARD ISLAND AND MCDONALD ISLANDS |
HND |
HONDURAS |
HRV |
CROATIA |
HTI |
HAITI |
HUN |
HUNGARY |
IDN |
INDONESIA |
IND |
INDIA |
IOT |
BRITISH INDIAN OCEAN TERRITORY |
IRL |
IRELAND |
IRN |
IRAN, ISLAMIC REPUBLIC OF |
IRQ |
IRAQ |
ISL |
ICELAND |
ISR |
ISRAEL |
ITA |
ITALY |
JAM |
JAMAICA |
JOR |
JORDAN |
JPN |
JAPAN |
KAZ |
KAZAKSTAN |
KEN |
KENYA |
KGZ |
KYRGYZSTAN |
KHM |
CAMBODIA |
KIR |
KIRIBATI |
KNA |
SAINT KITTS AND NEVIS |
KOR |
KOREA, REPUBLIC OF |
KWT |
KUWAIT |
LAO |
LAO PEOPLE'S DEMOCRATIC REPUBLIC |
LBN |
LEBANNON |
LBR |
LIBERIA |
LBY |
LIBYAN ARAB JAMAHIRIYA |
LCA |
SAINT LUCIA |
LIE |
LIECHTENSTEIN |
LKA |
SRI LANKA |
LSO |
LESOTHO |
LTU |
LITHUANIA |
LUX |
LUXEMBOURG |
LVA |
LATIVA |
MAC |
MACAU |
MAR |
MOROCCO |
MCO |
MONACO |
MDA |
MOLDOVA, REPUBLIC OF |
MDG |
MADAGASCAR |
MDV |
MALDIVES |
MEX |
MEXICO |
MHL |
MARSHALL ISLANDS |
MKD |
MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF |
MLI |
MALI |
MLT |
MALTA |
MMR |
MYANMAR |
MNG |
MONGOLIA |
MNP |
NORTHERN MARIANA ISLANDS |
MOZ |
MOZAMBIQUE |
MRT |
MAURITANIA |
MSR |
MONTSERRAT |
MTQ |
MARTINIQUE |
MUS |
MAURITUS |
MWI |
MALAWI |
MYS |
MALAYSIA |
MYT |
MAYOTTE |
NAM |
NAMIBIA |
NCL |
NEW CALEDONIA |
NER |
NIGER |
NFK |
NORFOLK ISLAND |
NGA |
NIGERIA |
NIC |
NICARAGUA |
NIU |
NIUE |
NLD |
NETHERLANDS |
NOR |
NORWAY |
NPL |
NEPAL |
NRU |
NAURU |
NZL |
NEW ZEALAND |
OMN |
OMAN |
PAK |
PAKISTAN |
PAN |
PANAMA |
PCN |
PITCAIRN |
PER |
PERU |
PHL |
PHILIPPINES |
PLW |
PALAU |
PNG |
PAPUA NEW GUINEA |
POL |
POLAND |
PRI |
PUERTO RICO |
PRK |
KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF |
PRT |
PORTUGAL |
PRY |
PARAGUAY |
PYF |
FRENCH POLYNESIA |
QAT |
QATAR |
REU |
REUNION |
ROM |
ROMANIA |
RUS |
RUSSIAN FEDERATION |
RWA |
RWANDA |
SAU |
SAUDI ARABIA |
SDN |
SUDAN |
SEN |
SENEGAL |
SGP |
SINGAPORE |
SGS |
SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS |
SHN |
SAINT HELENA |
SJM |
SVALBARD AND JAN MAYEN |
SLB |
SOLOMON ISLANDS |
SLE |
SIERRA LEONE |
SLV |
EL SALVADOR |
SMR |
SAN MARINO |
SOM |
SOMALIA |
SPM |
SAINT PIERRE AND MIQUELON |
STP |
SAO TOME AND PRINCIPE |
SUR |
SURINAME |
SVK |
SLOVAKIA |
SVN |
SLOVENIA |
SWE |
SWEDEN |
SWZ |
SWAZILAND |
SYC |
SEYCHELLES |
SYR |
SYRIAN ARAB REPUBLIC |
TCA |
TURKS AND CAICOS ISLANDS |
TCD |
CHAD |
TGO |
TOGO |
THA |
THAILAND |
TJK |
TAJIKISTAN |
TKL |
TOKELAU |
TKM |
TURKMENISTAN |
TMP |
EAST TIMOR |
TON |
TONGA |
TTO |
TRINIDAD AND TOBAGO |
TUN |
TUNISIA |
TUR |
TURKEY |
TUV |
TUVALU |
TWN |
TAIWAN, PROVINCE OF CHINA |
TZA |
TANZANIA, UNITED REPUBLIC OF |
UGA |
UGANDA |
UKR |
UKRAINE |
UMI |
UNITED STATES MINOR OUTLYING ISLANDS |
URY |
URUGUAY |
USA |
UNITED STATES |
UZB |
UZBEKISTAN |
VAT |
HOLY SEE (VATICAN CITY STATE) |
VCT |
SAINT VINCENT AND THE GRENADINES |
VEN |
VENEZUELA |
VGB |
VIRGIN ISLANDS, BRITISH |
VIR |
VIRGIN ISLANDS, U.S. |
VNM |
VIET NAM |
VUT |
VANUATU |
WLF |
WALLIS AND FUTUNA |
WSM |
SAMOA |
YEM |
YEMEN |
YUG |
YUGOSLAVIA |
ZAF |
SOUTH AFRICA |
ZMB |
ZAMBIA |
ZWE |
ZIMBABWE |
Definition:
This field contains the character set for the entire message. Refer to
HL7 Table 0211 - Alternate character sets for valid values.
Value |
Description |
|---|---|
ASCII |