Chapter Chair/Editor: |
Mark
Shafarman |
Chapter Chair/Editor: |
Larry
Reis |
Chapter Chair/Editor: |
Mark
Tucker |
Additional Editors: |
Mike
Henderson |
Joann
Larson |
The
information in this chapter was relocated from Appendix C in the preceding
(2.3.1) revision of the standard. It had previously been entitled Network
Management, and has been renamed to more accurately describe the purpose of the
messages described herein. This chapter does not specify a protocol for
managing networks, à la TCP/IP SNMP. Rather, its messages provide a
means to manage HL7-supporting applications over a network.
Because this chapter was originally named "Network Management," the messages
and segments have labels beginning with the letter "N." These labels are
retained for backward compatibility.
As a technical chapter, this information is now normative with respect to the
HL7 standard. It is anticipated that additional messages and message content
will be added to this chapter in the near future.
The
N01 event signifies when the NMQ (Application Management Query) message is used
by one application to make application control-level requests for information
or action to another application. It has three segments, the NCK segment
(system clock), the NST segment (application control-level statistics), and the
NSC segment (application control-level status change). At least one of these
three segments must be present in the NMQ message. If a segment is present in
the NMQ message, the corresponding segment needs to be present in the NMR
message to return the requested data or status.
a) The purpose of the NCK segment is to allow the various applications on the
network to synchronize their system clocks (system date and time).
b) The purpose of the NST segment is to allow application control-level
statistical information to be passed between the various applications on the
network. Although some of the fields in this segment refer to portions of
lower level protocols, they contain information that can be used by system
management applications monitoring the state of various networked applications.
All the data fields in the NST (application control-level statistics) are
optional, and the fields maintained by any application are to be negotiated at
a particular site.
c) The purpose of the NSC segment is to request the start-up, shut-down, and/or
migration (to a different CPU or file-server/file-system) of a particular
application.
NMQ^N01^NMQ_N01 |
Application Management Query |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
[QRD |
Query Definition |
5 |
[QRF]] |
Query Filter |
5 |
{[NCK] |
System Clock |
14 |
[NST] |
Application control-level Statistics |
14 |
[NSC]} |
Application Status Change |
14 |
NMR^N01^NMR_N01 |
Application Management Response |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgement |
2 |
[ERR] |
Error |
2 |
[QRD] |
Query Definition |
5 |
{[NCK] |
System Clock |
14 |
[{NTE}] |
Notes and Comments |
2 |
[NST] |
Application control-level Statistics |
14 |
[{NTE}] |
Notes and Comments |
2 |
[NSC] |
Application Status Change |
14 |
[{NTE}] } |
Notes and Comments |
2 |
This
segment is defined in Chapter 5. It is optional in the NMQ message. If
present, QRD-1-Query date/time, QRD-2-Query format code, QRD-3-Query
priority, QRD-9-What subject filter, and QRD-12-What department
data code should be used.
Suggested values for QRD-9-What subject filter are NCK, NST, or NSC. If
NSC is used, then suggested values for QRD-12-what department data code
should be taken from the user-defined table for NSC-1-Application change
type.
Since these are application management transactions, QRD-2-Query format
code should be R (record oriented), QRD-3-Query priority
should be I (immediate).
The other fields in this segment are optional.
The
N02 event signifies when an unsolicited update (UU) Application Management Data
message (NMD) is created by on application to transmit application management
information to other applications. In this case, the initiating application
sends an NMD message as an unsolicited update (UU) containing application
management information to a receiving application, which responds with a
generic acknowledgement message (ACK).
For example, an application going down for backups (or starting up again after
backups) might issue such a message to one or more other applications. An
application switching to another CPU or file-server may also need to use this
transaction to notify other systems.
NMD^N02^NMD_N02 |
Application Management Data |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
{ |
||
[NCK |
System Clock |
14 |
[{NTE}] |
Notes and Comments |
2 |
] |
||
[NST |
Application control-level Statistics |
14 |
[{NTE}] |
Notes and Comments |
2 |
] |
||
[NSC |
Application Status Change |
14 |
[{NTE}] |
Notes and Comments |
2 |
] |
||
} |
ACK^N02 |
Generic Acknowledgement |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgement |
2 |
The
NCK segment is used to allow the various applications on the network to
synchronize their system clocks (system date and time).
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
26 |
TS |
R |
01172 |
System Date/Time |
Definition: This field contains an HL7 time stamp. It is strongly recommended that seconds be included. If the message contains an NST or NSC segment, the NCK segment is optional. If the NCK segment is present, this field is required. If present in the NMQ message, or the unsolicited NMD message, it contains the system date/time of the sending system. If present in the NMR response message, it contains the responding system's date/time.
If
this message is to be used to automatically reset/correct system clocks, it is
recommended that the system or administrative personnel initiating the NMQ with
the NCK segment have the authority to correct the clock (system date and time)
for the other systems on the network. This is important in order to avoid the
obvious confusion of multiple systems attempting to resynchronize each other's
clocks.
If this message is used only to gather information on the various systems'
clocks, it is still important for an administrative procedure to be worked out
to avoid conflicts when resetting clocks.
The
NSC segment is used to inform (NMR query response) or announce (NMD unsolicited
update) the start-up, shut-down, and/or migration (to a different cpu or
file-server/file-system) of a particular application.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
IS |
R |
0409 |
01188 |
Application Change Type |
|
2 |
30 |
ST |
01189 |
Current CPU |
|||
3 |
30 |
ST |
01190 |
Current Fileserver |
|||
4 |
30 |
HD |
01191 |
Current Application |
|||
5 |
30 |
HD |
01192 |
Current Facility |
|||
6 |
30 |
ST |
01193 |
New CPU |
|||
7 |
30 |
ST |
01194 |
New Fileserver |
|||
8 |
30 |
HD |
01195 |
New Application |
|||
9 |
30 |
HD |
01196 |
New Facility |
Definition:
This field contains the type of change being requested (if NMR query) or
announced (if NMD unsolicited update). Refer to User-defined Table 0409
- Application change type for suggested values. It is assumed that "new"
version starts up with no loss or duplication of data as old one is shutting
down (if possible).
Value |
Description |
|---|---|
SU |
Start up |
SD |
Shut down |
M |
Migrates to different CPU |
Definition: This field contains a site-specific name for the current CPU.
Definition: This field contains a site-specific name for the current fileserver or file system used by this application.
Components:
<namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type
(ID)>
Definition: This field contains a site-specific name used to identify the
"current" application process for interfacing with lower level protocols. To
be used in conjunction with the sending/receiving system and facility values in
the MSH. Entirely site-defined. User-defined Table 0361-Sending/receiving
application is used as the user-defined table of values for the first
component.
Note: By site agreement, implementors 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 contains a site-specific name for the current facility
used by this application. To be used in conjunction with the values for the
sending/receiving system and facility values in the MSH. This field further
describes the current application, NSC-5-current application. With the
promotion of this field to an HD data type, the usage has been broadened to
include not just the current facility but other organizational entities such as
a) the organizational entity responsible for current 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.
Note: By site agreement, implementors may continue to use
user-defined table 0300 - Namespace ID for the first component.
Definition: This field contains a site-specific name for the new CPU.
Definition: This field contains a site-specific name for the new fileserver or file system used by this application.
Components:
<namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type
(ID)>
Definition: This field contains a site-specific name used to identify "new"
application processes for interfacing with lower level protocols. To be used
in conjunction with the sending/receiving system and facility values in the
MSH. Entirely site-defined. User-defined Table 0361-Sending/receiving
application is used as the user-defined table of values for the first
component.
Note: By site agreement, implementors 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 contains a site-specific name for the new facility used
by this application. To be used in conjunction with the values for the
sending/receiving system and facility values in the MSH.
This field further describes the new application, NSC-8-new application.
With the promotion of this field to an HD data type, the usage has been
broadened to include not just the new facility but other organizational
entities such as a) the organizational entity responsible for new 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.
Note: By site agreement, implementors may continue to use
user-defined table 0300 - Namespace ID for the first component.
Fields
2-9. These are not applicable ("n/a") when the type of change being requested
or reported is start-up or shut-down. If the change is of type "M", at least
one of fields 2-5 must be different from its corresponding field in range
6-9.
Fields 4-5, 8-9. See definitions for the MSH, message header segment, in
Chapter 2, (Control Section), for fields 3-4, for system and facility.
"Application" is available for interfacing with lower level protocols.
"Facility" is entirely site-defined.
Fields 2-3, 6-7. Entirely site-defined.
The
NST segment allows application control-level statistical information to be
passed between the various systems on the network. Some fields in this segment
refer to portions of lower level protocols; they contain information that can
be used by application management applications monitoring the state of various
network links.
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
1 |
ID |
R |
0136 |
01173 |
Statistics Available |
|
2 |
30 |
ST |
01174 |
Source Identifier |
|||
3 |
3 |
ID |
0332 |
01175 |
Source Type |
||
4 |
26 |
TS |
01176 |
Statistics Start |
|||
5 |
26 |
TS |
01177 |
Statistics End |
|||
6 |
10 |
NM |
01178 |
Receive Character Count |
|||
7 |
10 |
NM |
01179 |
Send Character Count |
|||
8 |
10 |
NM |
01180 |
Messages Received |
|||
9 |
10 |
NM |
01181 |
Messages Sent |
|||
10 |
10 |
NM |
01182 |
Checksum Errors Received |
|||
11 |
10 |
NM |
01183 |
Length Errors Received |
|||
12 |
10 |
NM |
01184 |
Other Errors Received |
|||
13 |
10 |
NM |
01185 |
Connect Timeouts |
|||
14 |
10 |
NM |
01186 |
Receive Timeouts |
|||
15 |
10 |
NM |
01187 |
Application control-level Errors |
Definition:
This field indicates the availability of statistics. Refer to HL7 table
0136 - Yes/no indicator for valid values.
N - the responding application does not keep any statistics. If the value "N"
is specified, the response message is used to signify to the initiating
application that the communication link between the initiating application and
the responding application is operational (and fields 2-15 are empty in the
response message).
Y - the responding application does keep statistics, fields 4 and 5 are
required, (and the response message contains one or more non-null fields in the
range 2-3, 6-15).
Definition: This field identifies a particular lower level link (e.g., a port number).
Definition:
This field identifies (in certain systems) whether a lower level source
identifier is an initiate or accept type. Refer to HL7 Table 0332 -
Source type for valid values.
Value |
Description |
|---|---|
I |
Initiate |
A |
Accept |
Definition: This field contains the date/time stamp of the start of the collection of the statistics reported in fields 6-15 of this segment. It is strongly recommended that this value include seconds.
Definition: This field contains the date/time stamp of the end of the statistics collection period reported in fields 6-15 of this segment. It is strongly recommended that this value include seconds.
Definition: This field contains the number of characters received.
Definition: This field contains the number of characters sent.
Definition: This field contains the number of messages received.
Definition: This field contains the number of messages sent.
Definition: This field contains the number of messages received with checksum errors.
Definition: This field contains the number of messages received with length errors.
Definition: This field contains the number of "other" invalid messages received (excluding length and checksum errors).
Definition: This field contains the number of connect timeout errors.
Definition: This field contains the number of timeouts while waiting for a response to an initiated message.
Definition: This field contains the number of application control-level errors in response to an initiated message.
Fields 2-15. These are all marked optional since the statistics kept on a particular link and negotiated between the two systems in question will vary. Not all values will apply to each system. Some values are concerned with the type of port, and some values pertain to the lower level protocol.
None.