HL7 NTE Notes and Comments
HL7 field reference NTE fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
NTE is the small segment that carries notes and comments. It looks harmless, and usually it is, but it can become a real mess if it is used as a dumping ground for anything that would not fit somewhere else. I think of NTE as the sticky note of HL7: useful, readable, and best kept attached to the thing it is actually talking about.
The key to NTE is context. An NTE after a PID is a patient-level note. An NTE after an ORC is about order control. An NTE after an OBR is about the observation request or report group. An NTE after an OBX is usually about that individual result. Move the same text to a different place in the message and you may have changed its meaning.
Use NTE for human-readable comments that genuinely are comments. Do not hide structured data in here if the receiver needs to calculate with it, route on it, trend it, code it, or reconcile it. If you put a mini language inside NTE-3 and ask the next interface to parse it, congratulations, you have invented a private standard and a future maintenance job. If that parsing has to exist anyway, make the rule explicit in Integration Soup and keep the raw NTE visible for troubleshooting.
There is also a boring but useful formatting rule: NTE-3 is FT, formatted text. If you need line breaks, use the FT formatting capability instead of sending empty NTE segments just to create blank lines. Empty NTEs as fake line spacing have been seen in the wild, of course, because the wild is like that, but it is not the best habit.
So let's go through each of the NTE fields and talk about how they tend to behave in real interfaces.
Numbering is only useful because comments can repeat. If you have several NTE segments attached to the same parent segment, this field can count them: 1, 2, 3. That helps preserve the order in which a human should read the notes.
I would not use this as a note identifier. It is not a database key, comment ID, accession number, or audit trail. It is just a set ID for the NTE segments in that local spot in the message. If a new OBX starts and its own comments follow, it is perfectly reasonable for the numbering to start again.
The source tells us who the comment came from in broad terms. P is the placer or orderer side. L is the ancillary or filler department, such as the lab or performing service. O means some other system. It is a small field, but it can change how the note is displayed or trusted.
For example, a patient instruction from the ordering side is not the same thing as a lab remark about a hemolyzed specimen. Both may be text. Both may be true. But they came from different parts of the workflow and should not be blended together as if they were the same voice. If your receiving system displays comments in different places, this field is one of the clues it can use.
This is where the actual comment lives. The data type is FT, so ordinary text is fine, and formatted text is also possible when the sender uses HL7 formatting commands. Remember that HL7 separators still matter. A pipe, caret, tilde, ampersand, or backslash inside the comment needs to be escaped correctly, otherwise your lovely note may suddenly become several broken fields.
The temptation is to put everything here, because text is easy. Try to resist that. A result value belongs in OBX-5. A diagnosis belongs in DG1. An allergy belongs in AL1. A specimen source belongs in the specimen fields or SPM. NTE is best for the sentence that helps a human interpret the structured data, not for replacing the structured data.
NTE-3 can repeat in this v2.5.1 definition, but repeating the field and repeating the segment are not always interchangeable. If you have one comment that needs several text parts, repeats can be fine if your receiver handles them. If you have different comments, different sources, different comment types, or comments attached to different parents, use separate NTE segments and keep them close to the segment they explain.
Comment type gives the text a little more shape. Values include patient instructions, ancillary instructions, general instructions, remarks, reasons, and duplicate or interaction reasons. This is different from source. Source says who the comment came from. Type says what kind of comment it is.
Use it when the receiver cares. A patient instruction might need to print on discharge paperwork. An ancillary instruction might belong in a work queue. A remark might simply display under a result. If every NTE is sent as a plain untyped comment, the receiver can still show it, but it has much less chance of doing something intelligent with it.
When the type changes, I prefer a separate NTE segment. Mixing instructions, reasons, and remarks into one long paragraph makes life easier for the sender for about five minutes, then harder for everyone else for years.