1. Introduction
2. Control/Query
3. Patient Administration
4. Order Entry
5. Query
6. Financial Management
7. Observation Reporting
8. Master Files
9. Medical Records/Information Management
10. Schedule
11. Patient Referral
12. Patient Care
A. Data Definition Tables
B. Lower Layer Protocols
C. Network Management
D. V2.2 BNF Message Descriptions
E. Glossary

Appendix C. Network Management

C .
Network Management
- C.1 TRIGGER EVENTS AND MESSAGE DEFINITIONS
  - C.1.1 NMQ - Network management query message
  - C.1.2 NMD - Network management data message
- C.2 NETWORK MANAGEMENT SEGMENTS

C .
Network Management

Editor:

Karen Van Hentenryck
Health Level Seven

C.1 TRIGGER EVENTS AND MESSAGE DEFINITIONS

C.1.1 NMQ - Network management query message

One system needs network information from another system:
The NMQ (Network Management Query) message is used by one system to make system-level requests for information or action to another system. It has three segments, the NCK segment (network clock), the NST segment (network statistics), and the NSC segment (network status change). An example of the last type, NSC (network status change) would be an application or system startup/shut down request. 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 systems on the network to synchronize their system clocks (system date and time).
b) The purpose of the NST segment is to allow network statistical information to be passed between the various systems 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 be network management applications monitoring the state of various network links. All the data fields in the NST (network statistics) are optional, and the fields maintained by any system are to be negotiated at a particular site.
c) The NSC segment can be used to request the start-up, shut-down, and/or migration (to a different CPU or file-server/file-system) of a particular application. It can also be used in an unsolicited update from one system to another to announce the start-up, shut-down, or migration of an application.

`NMQ`	`Network Management Query`	`Chapter/ Appendix`
`MSH`	`Message Header`	2
`[QRD`	`Query Definition`	2
`[QRF]]`	`Query Filter`	2
`{[NCK]`	`Network System Clock`	C
`[NST]`	`Network Statistics`	C
`[NSC]}`	`Network Status Change`	C
`NMR`	`Network Management Response`	`Chapter/ Appendix`
`MSH`	`Message Header`	2
`MSA`	`Message Acknowledgement`	2
`[ERR]`	`Error`	2
`[QRD]`	`Query Definition`	2
`{[NCK]`	`System Clock`	C
`[{NTE}]`	`Notes and Comments`	2
`[NST]`	`Statistics`	C
`[{NTE}]`	`Notes and Comments`	2
`[NSC]`	`Network Status Change`	C
`[{NTE}] }`	`Notes and Comments`	2

C.1.2 NMD - Network management data message

One system creates an unsolicited update (UU) Network Management Data message (NMD) to transmit network management information to another system. In this case, the initiating system sends an NMD message as an unsolicited update (UU) containing network management information to a receiving system, which responds with a generic acknowledgement message (ACK).
For example, a system going down for backups (or starting up again after backups) might issue such a message to one or more applications. A system switching to another CPU or file-server may also need to use this transaction to notify other systems.

`NMD`	`Network Management Data`	`Chapter/ Appendix`
`MSH`	`Message Header`	2

`{`
`[NCK`	`System Clock`	C
`[{NTE}]`	`Notes and Comments`	2
`]`
`[NST`	`Statistics`	C
`[{NTE}]`	`Notes and Comments`	2
`]`
`[NSC`	`Network Status Change`	C
`[{NTE}]`	`Notes and Comments`	2
`]`
`}`
`ACK`	`Generic Acknowledgement`	`Chapter/ Appendix`

`MSH`	`Message Header`	2
`MSA`	`Message Acknowledgement`	2

C.2 NETWORK MANAGEMENT SEGMENTS

The following segments are needed by the network management messages.

C.2.1 NCK - system clock segment

The NCK segment is used to allow the various systems on the network to synchronize their system clocks (system date and time).

Figure C-1. NCK attributes

SEQ	LEN	DT	R/O	RP/#	TBL#	ITEM#	ELEMENT NAME
1	26	TS	R			01172	System Date/Time

C.2.1.0 NCK field definitions

C.2.1.1 System date/time (TS) 01172

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.

C.2.1.2 NCK use notes

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 system's clocks, it is still important for an administrative procedure to be worked out to avoid conflicts when resetting clocks.

C.2.2 NST - statistics segment

The NST segment allows network 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 network management applications monitoring the state of various network links.

Figure C-2. NST attributes

SEQ	LEN	DT	R/O	TBL#	ITEM#	ELEMENT NAME
1	1	ID	R	0136	01173	Statistics Available
2	30	ST			01174	Source Identifier
3	3	ID			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	Network Errors

C.2.2.0 NST field definitions

C.2.2.1 Statistics available (ID) 01173

Definition: This field contains an indicator if statistics are available. Refer to HL7 table 0136 - Yes/no indicator for valid values.
N - the responding system does not keep any statistics. If the value "N" is specified, the response message is used to signify to the initiating application that the particular link is operational (and fields 2-15 are empty in the response message).
Y - the responding system 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).

C.2.2.2 Source identifier (ST) 01174

Definition: This field identifies a particular lower level link (e.g., a port number).

C.2.2.3 Source type (ID) 01175

Definition: This field identifies (in certain systems) whether a lower level source identifier is an initiate or accept type. Refer to HL7 table 0332 - Network source type for valid values.

HL7 Table 0332 - Network source type

Value	Description
I	Initiate
A	Accept

C.2.2.4 Statistics start (TS) 01176

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.

C.2.2.5 Statistics end (TS) 01177

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.

C.2.2.6 Receive character count (NM) 01178

Definition: This field contains the number of characters received.

C.2.2.7 Send character count (NM) 01179

Definition: This field contains the number of characters sent.

C.2.2.8 Messages received (NM) 01180

Definition: This field contains the number of messages received.

C.2.2.9 Messages sent (NM) 01181

Definition: This field contains the number of messages sent.

C.2.2.10 Checksum errors received (NM) 01182

Definition: This field contains the number of messages received with checksum errors.

C.2.2.11 Length errors received (NM) 01183

Definition: This field contains the number of messages received with length errors.

C.2.2.12 Other errors received (NM) 01184

Definition: This field contains the number of "other" invalid messages received (excluding length and checksum errors).

C.2.2.13 Connect timeouts (NM) 01185

Definition: This field contains the number of connect timeout errors.

C.2.2.14 Receive timeouts (NM) 01186

Definition: This field contains the number of timeouts while waiting for a response to an initiated message.

C.2.2.15 Network errors (NM) 01187

Definition: This field contains the number of network errors in response to an initiated message.

C.2.2.16 NST use notes

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.

C.2.3 NSC - status change segment

The NSC segment can be used to request the start-up, shut-down, and/or migration (to a different cpu or file-server/file-system) of a particular application. It can also be used in an unsolicited update from one system to another to announce the start-up, shut-down, or migration of an application.

Figure C-3. NSC attributes

SEQ	LEN	DT	R/O	TBL#	ITEM#	ELEMENT NAME
1	4	IS	R	0333	01188	Network Change Type
2	30	ST			01189	Current CPU
3	30	ST			01190	Current Fileserver
4	30	ST			01191	Current Application
5	30	ST			01192	Current Facility
6	30	ST			01193	New CPU
7	30	ST			01194	New Fileserver
8	30	ST			01195	New Application
9	30	ST			01196	New Facility

C.2.3.0 NSC field definitions

C.2.3.1 Network change type (IS) 01188

Definition: This field contains the type of change being requested (if NMR query) or announced (if NMD unsolicited update). Refer to user-defined table 0333 - Network change type for suggested values. Implies that "new" version starts up with no loss or duplication of data as old one is shutting down (if possible).

User-defined Table 0333 - Network change type

Value	Description
SU	Start up
SD	Shut down
M	Migrates to different CPU

C.2.3.2 Current CPU (ST) 01189

Definition: This field contains a site-specific name for the current CPU.

C.2.3.3 Current fileserver (ST) 01190

Definition: This field contains a site-specific name for the current fileserver or file system used by this application.

C.2.3.4 Current application (ST) 01191

Definition: This field contains a site-specific name available to identify the "current" application process used for interfacing with lower level protocols. To be used in conjunction with the sending/receiving system and facility values in the MSH.

C.2.3.5 Current facility (ST) 01192

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.

C.2.3.6 New CPU (ST) 01193

Definition: This field contains a site-specific name for the new CPU.

C.2.3.7 New fileserver (ST) 01194

Definition: This field contains a site-specific name for the new fileserver or file system used by this application.

C.2.3.8 New application (ST) 01195

Definition: This field contains a site-specific name available to identify "new" application processes used for interfacing with lower level protocols. To be used in conjunction with the sending/receiving system and facility values in the MSH.

C.2.3.9 New facility (ST) 01196

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.

C.2.3.10 NSC use notes

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.

C.2.4 QRD - query definition segment usage

C.2.4.1 QRD use notes

This segment is defined in Chapter 2. 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-network change type.
Since these are network 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.