NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v2Segment6 min read

HL7 NST Segment: Application Control Level Statistics

The NST (Application Control Level Statistics) segment reports operational statistics about an interface link, such as how many messages and characters were sent and received and how many errors of various kinds occurred over a measurement window. It is used in application and network management messages to monitor the health and throughput of communication channels between cooperating systems.

Purpose

The NST segment carries the counters that let operators understand the performance and reliability of an interface. A statistics-available flag (NST-1) indicates whether figures follow, NST-2 and NST-3 identify and classify the source link, and NST-4 and NST-5 bound the measurement period. The remaining numeric fields tally received and sent characters and messages along with checksum, length, other, connect-timeout, receive-timeout, and application control-level error counts.

Used in

The NST segment is used in NMD application and network management messages alongside the NSC application status change segment and the NCK system clock segment. See the NMD message reference for how statistics are requested and reported.

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (NST 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.

SeqNameData TypeLengthReqRepeatTable #Description
NST-1Statistics AvailableidRFlag indicating whether statistics follow
NST-2Source IdentifierstOIdentifier of the link being reported
NST-3Source TypeidOClassification of the source link
NST-4Statistics StarttsOStart of the measurement window
NST-5Statistics EndtsOEnd of the measurement window
NST-6Receive Character CountnmOCharacters received over the window
NST-7Send Character CountnmOCharacters sent over the window
NST-8Messages ReceivednmOCount of messages received
NST-9Messages SentnmOCount of messages sent
NST-10Checksum Errors ReceivednmOMessages received with checksum errors
NST-11Length Errors ReceivednmOMessages received with length errors
NST-12Other Errors ReceivednmOOther receive errors counted
NST-13Connect TimeoutsnmOConnection attempt timeouts
NST-14Receive TimeoutsnmOReceive operation timeouts
NST-15Application control-level ErrorsnmOApplication-level error count

Most-used fields

  • NST-1 Statistics Available: signals whether the segment actually carries figures, so consumers know if counters follow.
  • NST-2 Source Identifier: names the link or channel the statistics describe.
  • NST-4 Statistics Start and NST-5 Statistics End: bound the measurement window for rate calculations.
  • NST-8 Messages Received and NST-9 Messages Sent: the core throughput counters for an interface.
  • NST-15 Application control-level Errors: highlights higher-level processing failures beyond transport errors.

Version differences (2.3 to 2.8.2)

  • 2.3: NST defined the statistics-available flag, source identifier and type, measurement window, and the character, message, and error counters.
  • 2.3.1 to 2.4: Structure remained stable; the numeric counter fields settled on the NM data type.
  • 2.5 and 2.5.1: The fifteen-field layout is confirmed, with timeout and application control-level error counters distinct from transport error counts.
  • 2.6 to 2.8.2: No material change to the field set; NST remains an application and network management statistics segment with no clinical content.

Common mistakes

  • Sending counters while NST-1 indicates no statistics are available, contradicting the flag.
  • Omitting the measurement window (NST-4 and NST-5), making the counts impossible to turn into rates.
  • Conflating transport-level error counters (checksum, length, timeouts) with application control-level errors in NST-15.
  • Reporting cumulative lifetime totals when the window fields imply an interval, skewing trend analysis.
  • Routing NST into clinical processing; it is operational telemetry, not patient data.

Examples

Minimal NST indicating statistics are not available:

NST|N

Fully populated NST reporting a measurement window:

NST|Y|LINK-ADT-01|TCP|20260610090000|20260610100000|184320|176410|512|498|2|1|0|0|3|1

Annotated breakdown of the fully populated example:

NST-1   Y                  Statistics Available (figures follow)
NST-2   LINK-ADT-01        Source Identifier (the reported link)
NST-3   TCP                Source Type
NST-4   20260610090000     Statistics Start
NST-5   20260610100000     Statistics End
NST-6   184320             Receive Character Count
NST-7   176410             Send Character Count
NST-8   512                Messages Received
NST-9   498                Messages Sent
NST-10  2                  Checksum Errors Received
NST-11  1                  Length Errors Received
NST-12  0                  Other Errors Received
NST-13  0                  Connect Timeouts
NST-14  3                  Receive Timeouts
NST-15  1                  Application control-level Errors

In-context excerpt 1: an NMD reporting hourly link statistics.

MSH|^~&|NETMGR|CENTRAL|MONITOR|OPS|20260610100000||NMD^N02^NMD_N02|NM55020|P|2.5.1
MSA|AA|NM55020
NST|Y|LINK-ADT-01|TCP|20260610090000|20260610100000|184320|176410|512|498|2|1|0|0|3|1

In-context excerpt 2: an NMD reporting a quiet link with no errors.

MSH|^~&|NETMGR|CENTRAL|MONITOR|OPS|20260610110000||NMD^N02^NMD_N02|NM55021|P|2.5.1
MSA|AA|NM55021
NST|Y|LINK-ORM-02|TCP|20260610100000|20260610110000|40960|39200|120|118|0|0|0|0|0|0

FHIR mapping

  • Source: NST segment.
  • Target: Not mapped at the segment level.
  • The v2-to-FHIR Implementation Guide does not publish a segment-level ConceptMap for NST. NST is application and network management infrastructure that reports interface telemetry rather than clinical or administrative data, so it has no direct FHIR resource equivalent. In a FHIR deployment such counters would be exposed through operational metrics, not a mapped resource.

Engine considerations

  • Check NST-1 first; do not parse counters when the flag indicates statistics are unavailable.
  • Use NST-4 and NST-5 to compute rates rather than treating raw counts as instantaneous values.
  • Separate transport error counters from the application control-level error count when alerting.
  • Persist statistics keyed by NST-2 source identifier so per-link trends can be charted.
  • Keep NST out of clinical routing; direct it to monitoring and observability pipelines.

How Vorro parses and produces NST

Vorro parses NST by reading NST-1 to decide whether counters are present, then loading the source identifier, source type, and measurement window into its telemetry model before mapping each numeric counter to a named metric. Transport errors (checksum, length, other, timeouts) and application control-level errors are kept as distinct series. When producing NST, Vorro sets the availability flag, stamps the window from its own measurement interval, and emits the character, message, and error counts gathered for the named link, routing the segment to operational monitoring rather than clinical channels.

Sources

← Back to HL7 v2 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 v2 Guides
HL7 NST Segment: Application Control Level Statistics | Vorro Academy | Vorro