The NCK (System Clock) segment reports or requests a host's current system date and time. It is the simplest of the network management segments, consisting of a single required field that carries a timestamp. NCK is used in application and network management messages to compare or synchronize clocks between cooperating systems.
Purpose
The NCK segment exists so one system can report its current clock reading to another, supporting clock comparison and time synchronization across an interface. Because timestamp drift between systems can corrupt ordering and audit trails, exchanging the system date/time allows operators and engines to detect and correct skew. The segment carries exactly one field, NCK-1 System Date/Time.
Used in
The NCK segment is used in NMD application and network management messages alongside the NSC application status change segment and the NST statistics segment. See the NMD message reference for the query and unsolicited forms of network management exchanges.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (NCK 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 |
|---|---|---|---|---|---|---|---|
| NCK-1 | System Date/Time | ts | — | R | — | — | Current system clock reading of the host |
Most-used fields
- NCK-1 System Date/Time: the single required field, carrying the host's current clock reading as a timestamp used for comparison or synchronization.
Version differences (2.3 to 2.8.2)
- 2.3: NCK was defined with a single System Date/Time field carrying the host clock reading.
- 2.3.1 to 2.4: Structure remained stable; the field continued to use the TS timestamp data type.
- 2.5 and 2.5.1: The single-field layout is retained, with NCK-1 System Date/Time as the only and required element.
- 2.6 to 2.8.2: No material change; NCK remains a one-field application and network management segment with no clinical content.
Common mistakes
- Sending NCK-1 without a timezone offset, leaving clock comparisons ambiguous across regions.
- Truncating the timestamp to date precision when second-level precision is needed for skew detection.
- Treating NCK as an event that should drive clinical processing rather than operational time sync.
- Reporting a formatted local string instead of a valid TS value, breaking parsers.
- Assuming NCK adjusts the clock; it conveys a reading and does not itself perform synchronization.
Examples
Minimal NCK reporting a system time:
NCK|20260610100000
Fully populated NCK with second precision and timezone offset:
NCK|20260610100000.000-0500
Annotated breakdown of the fully populated example:
NCK-1 20260610100000.000-0500 System Date/Time
20260610 date: 2026-06-10
100000.000 time: 10:00:00.000
-0500 timezone offset from UTC
In-context excerpt 1: an NMD reporting the host clock.
MSH|^~&|NETMGR|CENTRAL|MONITOR|OPS|20260610100000||NMD^N02^NMD_N02|NM55030|P|2.5.1
MSA|AA|NM55030
NCK|20260610100000.000-0500
In-context excerpt 2: an NMD reporting a clock that has drifted from the requester.
MSH|^~&|NETMGR|CENTRAL|MONITOR|OPS|20260610100500||NMD^N02^NMD_N02|NM55031|P|2.5.1
MSA|AA|NM55031
NCK|20260610100437.500-0500
FHIR mapping
- Source: NCK segment.
- Target: Not mapped at the segment level.
- The v2-to-FHIR Implementation Guide does not publish a segment-level ConceptMap for NCK. NCK is application and network management infrastructure that conveys a host clock reading rather than clinical or administrative data, so it has no direct FHIR resource equivalent. System time would, in a FHIR deployment, be handled by infrastructure time services rather than a mapped resource.
Engine considerations
- Require a timezone offset on NCK-1 so cross-region clock comparisons are unambiguous.
- Preserve sub-second precision when present to enable accurate skew measurement.
- Compare NCK-1 against the receiving system's own clock and alert when drift exceeds tolerance.
- Do not route NCK into clinical processing; it is operational time telemetry.
- Remember that NCK reports a reading and does not by itself set or correct any clock.
How Vorro parses and produces NCK
Vorro parses NCK by reading the single NCK-1 field into its internal timestamp model, preserving date, time, sub-second, and timezone components, then comparing it against the local clock to compute drift. When producing NCK, Vorro emits the current host time as a fully qualified TS value including a timezone offset and second-level precision, and routes the segment through its operational channel rather than clinical message flows.
