HL7 - REFACTORED

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	Vocabulary	DataType
NTE
1	00096	Set ID - NTE			[0..1]			SI
2	00097	Source of Comment			[0..1]	[1..1]	0105 Source of Comment	ID
3	00098	Comment	MAY True: False:	C	[1..1] [0..1]			FT
4	01318	Comment Type			[0..1]		0364 Comment Type	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..*]		0611	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.

Draft Website - For Review Purposes Only