HL7 CNS Segment: Clear Notification

The CNS (Clear Notification) segment instructs a receiving system to clear a range of notifications that were previously communicated. Rather than carrying clinical content, CNS is a control segment: it identifies a contiguous span of notifications by reference number, date/time, or notification code so the receiver can mark them as cleared. It is used in notification-management workflows where a sender retracts or acknowledges a block of earlier alerts.

Purpose

CNS exists to clear a bounded range of notifications in one operation. Notification systems can accumulate large volumes of alerts; CNS lets a sender express "clear everything from this starting point through this ending point" using three independent range dimensions, the reference number range, the date/time range, and the notification code range. Receivers use whichever bounds are populated to determine which notifications fall inside the range and should be cleared.

Used in

CNS is used in clear-notification workflows to clear a range of notifications previously transmitted. It is notification-control infrastructure and appears in messages whose trigger is to retract or settle a span of notifications rather than to convey clinical study data. For the related unsolicited study-data message that carries the clinical-study segment group, see the CSU reference.

CSU — Unsolicited Study Data: see /academy/hl7/messages/csu

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (CNS.html). Length 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
CNS-1	Starting Notification Reference Number	nm	—	R	—	—	First reference number in cleared range
CNS-2	Ending Notification Reference Number	nm	—	O	—	—	Last reference number in cleared range
CNS-3	Starting Notification Date/Time	ts	—	O	—	—	Start of date/time range to clear
CNS-4	Ending Notification Date/Time	ts	—	O	—	—	End of date/time range to clear
CNS-5	Starting Notification Code	ce	—	O	—	—	First notification code in cleared range
CNS-6	Ending Notification Code	ce	—	O	—	—	Last notification code in cleared range

Most-used fields

CNS-1 Starting Notification Reference Number: the required start of the reference-number range to clear.
CNS-2 Ending Notification Reference Number: the upper bound of the reference-number range.
CNS-3 Starting Notification Date/Time: the start of an alternative date/time range to clear.
CNS-4 Ending Notification Date/Time: the end of the date/time range.
CNS-5 / CNS-6 Starting and Ending Notification Code: bound the range by coded notification type.

Version differences (2.3 to 2.8.2)

CNS supports notification-management trigger events and is a control segment, distinct from the clinical-study group.
Across 2.3 through 2.5.1, the six-field range structure of CNS remained stable, with the starting reference number as the anchor.
The coded fields CNS-5 and CNS-6 use CE in 2.5.1 as published in the HAPI javadocs.
From 2.6 onward, coded fields across the standard trend toward CWE; partners on 2.7 through 2.8.2 may express CNS-5 and CNS-6 as CWE rather than CE.
No fields have been added to or removed from CNS across these releases; the changes are data-type normalization only.

Common mistakes

Omitting CNS-1 Starting Notification Reference Number, which anchors the range; the standard expects a starting point.
Sending an ending bound (CNS-2, CNS-4, or CNS-6) that precedes its starting bound, producing an empty or invalid range.
Mixing range dimensions inconsistently, for example a reference-number start with a date/time end, without agreeing on receiver semantics.
Assuming an absent ending bound clears only a single notification when a partner interprets it as open-ended.
Treating CNS-5 and CNS-6 as free text rather than coded notification types.
Dropping the timezone on CNS-3 and CNS-4, which shifts the cleared date/time window.

Examples

Minimal CNS (clear from a single starting reference number):

CNS|100045

Fully populated CNS (clear a range across all three dimensions):

CNS|100045|100099|20260601000000|20260610235959|NOTIF-A^Routine Alert^L|NOTIF-Z^Critical Alert^L

Annotated breakdown:

CNS-1  Starting Notification Reference Number .. 100045
CNS-2  Ending Notification Reference Number .... 100099
CNS-3  Starting Notification Date/Time ......... 2026-06-01 00:00:00
CNS-4  Ending Notification Date/Time ........... 2026-06-10 23:59:59
CNS-5  Starting Notification Code .............. NOTIF-A Routine Alert
CNS-6  Ending Notification Code ................ NOTIF-Z Critical Alert

In context, a clear-notification message clearing a reference-number range:

MSH|^~&|NOTIFY|SENDER|INBOX|RECEIVER|20260611080000||MFN^M16^MFN_M16|MSG07710|P|2.5.1
CNS|100045|100099

A second in-context excerpt clearing a date/time and code range:

MSH|^~&|NOTIFY|SENDER|INBOX|RECEIVER|20260611081500||MFN^M16^MFN_M16|MSG07744|P|2.5.1
CNS|200010||20260601000000|20260610235959|NOTIF-A^Routine Alert^L|NOTIF-A^Routine Alert^L

FHIR mapping

CNS is not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR IG for CNS. CNS is notification-control infrastructure with no direct FHIR resource; it expresses an instruction to clear a range of prior notifications rather than a clinical entity. Where FHIR-based systems model notifications as Communication or Subscription-driven events, clearing a range is an application-level operation, not a normalized resource mapping. Any alignment is an implementer convention, not a published mapping.

Engine considerations

Treat CNS as a control segment; ensure CNS-1 is populated before routing, since it anchors the range.
Validate range coherence (ending bound not before starting bound) for whichever dimensions are present.
Decide and document how an absent ending bound is interpreted: single notification versus open-ended range.
Preserve TS timezone offsets on CNS-3 and CNS-4 so the cleared window is unambiguous.
When transforming CE to CWE for a 2.7+ partner, map identifier, text, and coding-system components for CNS-5 and CNS-6.

How Vorro parses and produces CNS

Vorro reads CNS positionally per the HAPI v2.5.1 structure and requires CNS-1 on parse; a missing starting reference number raises a validation event.
The three range dimensions (reference number, date/time, code) are parsed independently so a message using only one dimension is handled cleanly.
CNS-3 and CNS-4 are normalized to a primary internal timestamp form with timezone retained and re-rendered to HL7 TS on output.
CNS-5 and CNS-6 are parsed as coded elements; Vorro can emit them as CE or transform to CWE for partners on 2.7 or later via a configurable rule.
Range coherence is checked on production so an emitted CNS never carries an ending bound that precedes its starting bound.

/academy/hl7/segments/csr
/academy/hl7/segments/css
/academy/hl7/messages/csu

Sources

← Back to HL7 v2 Guide