The NSC (Application Status Change) segment communicates that an application or interface is changing operational state, such as starting up, shutting down, or migrating between hosts. It is used in application and network management messages to describe both the current and the intended new location of an application across CPU, fileserver, application, and facility identifiers.
Purpose
The NSC segment lets a system announce or request a change in the status of an application instance. NSC-1 names the kind of change, while the remaining fields describe where the application runs now (current CPU, fileserver, application, facility) and where it is moving to (new CPU, fileserver, application, facility). This supports controlled failover, relocation, and start/stop coordination between cooperating interface engines and applications.
Used in
The NSC segment is used in NMD application and network management messages alongside the NST statistics segment and the NCK system clock segment. See the NMD message reference for the unsolicited and query forms of network management exchanges.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (NSC segment). Length is not asserted by the javadoc and is shown as —. Required and Table # are taken from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| NSC-1 | Application Change Type | is | — | R | — | HL70409 | Kind of application status change requested |
| NSC-2 | Current CPU | st | — | O | — | — | CPU the application currently runs on |
| NSC-3 | Current Fileserver | st | — | O | — | — | Fileserver the application currently uses |
| NSC-4 | Current Application | hd | — | O | — | — | Current application identifier |
| NSC-5 | Current Facility | hd | — | O | — | — | Current facility identifier |
| NSC-6 | New CPU | st | — | O | — | — | CPU the application will move to |
| NSC-7 | New Fileserver | st | — | O | — | — | Fileserver the application will move to |
| NSC-8 | New Application | hd | — | O | — | — | New application identifier |
| NSC-9 | New Facility | hd | — | O | — | — | New facility identifier |
Most-used fields
- NSC-1 Application Change Type: the required code naming the status change, such as a start, stop, or migration action.
- NSC-2 Current CPU: identifies the host currently running the application before the change.
- NSC-4 Current Application: the current application identifier being acted upon.
- NSC-6 New CPU: the target host for a migration or failover.
- NSC-8 New Application: the new application identifier when the instance is relocated or renamed.
Version differences (2.3 to 2.8.2)
- 2.3: NSC defined the change type plus current and new CPU, fileserver, application, and facility fields for status transitions.
- 2.3.1 to 2.4: Structure remained stable; the application and facility fields settled on the HD hierarchic designator data type.
- 2.5 and 2.5.1: NSC-1 Application Change Type references HL7 table 0409, and the current/new field pairs are confirmed as nine fields total.
- 2.6 to 2.8.2: No material change to the field set; NSC remains an application and network management control segment with no clinical content.
Common mistakes
- Leaving NSC-1 empty or sending an uncoded value, so the receiver cannot tell what kind of change is intended.
- Confusing the current fields (NSC-2 to NSC-5) with the new fields (NSC-6 to NSC-9) when describing a migration.
- Populating new-location fields for a simple stop action where no target host exists.
- Sending plain CPU or fileserver names in the application or facility HD fields, mixing data types.
- Treating NSC as a clinical event; it is infrastructure signaling and should not drive patient-level processing.
Examples
Minimal NSC announcing a simple status change:
NSC|RESTART
Fully populated NSC describing an application migration:
NSC|MIGRATE|CPU-EAST-01|FS-EAST-01|ADTFEED^^L|NORTHGEN^^L|CPU-WEST-02|FS-WEST-02|ADTFEED^^L|WESTGEN^^L
Annotated breakdown of the fully populated example:
NSC-1 MIGRATE Application Change Type (relocate the instance)
NSC-2 CPU-EAST-01 Current CPU
NSC-3 FS-EAST-01 Current Fileserver
NSC-4 ADTFEED^^L Current Application
NSC-5 NORTHGEN^^L Current Facility
NSC-6 CPU-WEST-02 New CPU
NSC-7 FS-WEST-02 New Fileserver
NSC-8 ADTFEED^^L New Application
NSC-9 WESTGEN^^L New Facility
In-context excerpt 1: an unsolicited NMD announcing an application restart.
MSH|^~&|NETMGR|CENTRAL|MONITOR|OPS|20260610100000||NMD^N02^NMD_N02|NM55010|P|2.5.1
MSA|AA|NM55010
NSC|RESTART|CPU-EAST-01|FS-EAST-01|ADTFEED^^L|NORTHGEN^^L
In-context excerpt 2: an NMD describing a planned failover migration.
MSH|^~&|NETMGR|CENTRAL|MONITOR|OPS|20260610100500||NMD^N02^NMD_N02|NM55011|P|2.5.1
MSA|AA|NM55011
NSC|MIGRATE|CPU-EAST-01|FS-EAST-01|ADTFEED^^L|NORTHGEN^^L|CPU-WEST-02|FS-WEST-02|ADTFEED^^L|WESTGEN^^L
FHIR mapping
- Source: NSC segment.
- Target: Not mapped at the segment level.
- The v2-to-FHIR Implementation Guide does not publish a segment-level ConceptMap for NSC. NSC is application and network management infrastructure that signals interface status changes rather than clinical or administrative data, so it has no direct FHIR resource equivalent. Operational state of an application would, in a FHIR deployment, be surfaced through infrastructure monitoring rather than a mapped resource.
Engine considerations
- Validate NSC-1 against the application change type table before acting on a status transition.
- Distinguish current versus new location fields so a migration routes traffic to the correct target host.
- Avoid letting NSC messages enter clinical processing queues; they belong to operational tooling.
- Log status changes with timestamps from the surrounding MSH so failover history is auditable.
- For stop or restart actions, accept that the new-location fields may legitimately be empty.
How Vorro parses and produces NSC
Vorro parses NSC by reading NSC-1 to classify the requested status change and then mapping the current fields (NSC-2 to NSC-5) and new fields (NSC-6 to NSC-9) into its internal application-location model. HD-typed application and facility identifiers are decomposed into namespace, universal ID, and type components. When producing NSC, Vorro sets the change type, populates the current location of the affected instance, and fills the new-location fields only when the action involves a relocation or failover, leaving them empty for simple start and stop signals. NSC traffic is routed through Vorro's operational channel rather than clinical message flows.
