The Demo site for our new HL7 Version 2+ (plus) Standard
visit the hl7 website

Draft Website - For Review Purposes Only

NTE - Notes And Comments Segment

The NTE segment is defined here for inclusion in messages defined in other chapters. It is commonly used for sending notes and comments.

The work groups define the meaning of the NTE segments within the context of the messages in their chapters. For each NTE, the description in the message attribute table SHOULD include an indication of the segment associated with the NTE, for example "Notes and Comments for the PID".

NOTE: While sending of segments with no content has been historically used for display messages to indicate blank lines this is not best practice. Senders SHOULD NOT send empty NTEs to indicate blank lines. When blank lines are required senders SHOULD use the functionality of the FT datatype in section Formatting codes.


HL7 Attribute Table - NTE - notes and comments segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
NTE
1 00096 Set ID - NTE [0..1] SI
2 00097 Source of Comment [0..1] [1..1] ID
3

00098 Comment MAY
True:
False:
C
[1..1]
[0..1]
FT
4 01318 Comment Type [0..1] CWE
5 00224 Entered By [0..1] XCN
6 00661 Entered Date/Time [0..1] DTM
7 01004 Effective Start Date [0..1] DTM
8 02185 Expiration Date [0..1] DTM
9 03495 Coded Comment [0..*] CWE

NTE-1: Set ID - NTE (SI) 00096

Definition: This field MAY be used where multiple NTE segments are included in a message. Their numbering must be described in the application message definition.

NTE-2: Source of Comment (ID) 00097

Definition: This field is used when source of comment must be identified. This table MAY be extended locally during implementation. Refer to HL7 Table 0105 - Source of Comment in Chapter 2C, Code Tables, for valid values.

NTE-3: Comment (FT) 00098

Definition: This field contains the comment contained in the segment.

Conditionality Predicate: In support of backwards compatibility, when NTE-9 is populated, the sending system SHALL also populate a human-readable version of the comment in NTE-3. When NTE-9 is not populated then NTE-3 MAY be populated.

Note: NTE-3 has been left blank for the use cases where legacy systems are sending a blank NTE as a line feed.


Note: As of v2.2, this field uses the FT rather than a TX data type. Since there is no difference between an FT data type without any embedded formatting commands, and a TX data type, this change is compatible with the previous version.


NTE-4: Comment Type (CWE) 01318

Definition: This field contains a value to identify the type of comment text being sent in the specific comment record. Refer to User-Defined Table 0364 - Comment Type in Chapter 2C, Code Tables, for suggested values.

Note:    A field already exists on the NTE record that identifies the Sources of Comment (e.g., ancillary, placer, other). However some applications need to support other types of comment text (e.g., instructions, reason, remarks, etc.). A separate NTE segment can be used for each type of comment (e.g., instructions are on one NTE and remarks on another NTE).


NTE-5: Entered By (XCN) 00224

(Definition from NTE.5 in Ch. 2)

Definition: This field contains the identity of the person who actually keyed the comment into the application. It provides an audit trail in case the comment is entered incorrectly and the ancillary department needs to clarify the comment. By local agreement, either the ID number or name component MAY be omitted.

(Definition from ORC.10 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.

(Definition from ACC.7 in Ch. 6)

Definition: This field identifies the person entering the accident information.

(Definition from MFE.7 in Ch. 8)

Definition: This field contains the identity of the person who actually keyed the master file entry into the application. It provides an audit trail in case the request is entered incorrectly and the ancillary department needs to clarify the request.

(Definition from OM7.20 in Ch. 8)

Note: This field is deprecated and retained for backward compatibility as of v 2.8.

Definition: This field contains the identity of the person who actually keyed the service item into the application. It provides an audit trail in case the request is entered incorrectly and the ancillary department needs to clarify the request.

NTE-6: Entered Date/Time (DTM) 00661

(Definition from NTE.6 in Ch. 2)

Definition: This field contains the actual date the comment was keyed into the application.

(Definition from MFI.4 in Ch. 8)

Definition: This field contains the date/time for the file-level event on originating system.

(Definition from MFE.6 in Ch. 8)

Definition: This field contains the date and time of the last change of the record.

NTE-7: Effective Start Date (DTM) 01004

(Definition from NTE.7 in Ch. 2)

Definition: This field contains the date the comment becomes or became effective.

(Definition from PRC.11 in Ch. 8)

Definition: This field contains the date/time when this CDM entry becomes effective.

NTE-8: Expiration Date (DTM) 02185

Definition: This field contains the date the comment becomes or became non-effective.

NTE-9: Coded Comment (CWE) 03495

Definition: This field contains a value to identify a codified comment being sent in the specific comment record. If this field is valued, NTE-3 will be populated with text from this field. In support of backwards compatibility, when NTE-9 is populated, the sending system SHALL also populate a human-readable version of the comment in NTE-3. Refer to Table 0611 - Coded Comment in Chapter 2C for valid values.