HL7^® Reference Guide

HL7 TXA Transcription Document Header

Examine the usage of every TXA field from experience.

HL7 field reference TXA 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

Field	Name	Required	Repeatable	Type	Table
TXA.1	Set ID - TXA	Yes	No	SI
TXA.2	Document Type	Yes	No	IS	0270
TXA.3	Document Content Presentation	No	No	ID	0191
TXA.4	Activity Date/Time	No	No	TS
TXA.5	Primary Activity Provider Code/Name	No	Yes	XCN
TXA.6	Origination Date/Time	No	No	TS
TXA.7	Transcription Date/Time	No	No	TS
TXA.8	Edit Date/Time	No	Yes	TS
TXA.9	Originator Code/Name	No	Yes	XCN
TXA.10	Assigned Document Authenticator	No	Yes	XCN
TXA.11	Transcriptionist Code/Name	No	Yes	XCN
TXA.12	Unique Document Number	Yes	No	EI
TXA.13	Parent Document Number	No	No	EI
TXA.14	Placer Order Number	No	Yes	EI
TXA.15	Filler Order Number	No	No	EI
TXA.16	Unique Document File Name	No	No	ST
TXA.17	Document Completion Status	Yes	No	ID	0271
TXA.18	Document Confidentiality Status	No	No	ID	0272
TXA.19	Document Availability Status	No	No	ID	0273
TXA.20	Document Storage Status	No	No	ID	0275
TXA.21	Document Change Reason	No	No	ST
TXA.22	Authentication Person, Time Stamp	No	Yes	PPN
TXA.23	Distributed Copies (Code and Name of Recipients)	No	Yes	XCN

TXA is the cover sheet for an HL7 document. It tells you what the document is, who created it, who signed it, which document ID to file it under, whether it is available for care, and how it relates to older versions. The actual document text or PDF usually lives in OBX. TXA is the metadata that lets the receiving system file the thing in the right chart without having to read the whole letter like a person.

You normally meet TXA inside Medical Document Management messages, the MDM family. An MDM^T01 can tell another system a document exists without sending the body. An MDM^T02 sends the document notification and content together. Then there are status changes, addenda, edits, replacements, and cancellations. That is the bit that makes TXA more subtle than it first looks. A document is not just "a blob arrived". It has a lifecycle.

In the real world this is used for discharge summaries, operative reports, radiology reports, scanned letters, referral documents, progress notes, procedure notes, and transcription-style reports that need signing. It can feel a lot like an OBR/OBX result feed, and plenty of document feeds are built that way, but TXA is better when the document itself is the thing being managed. If you need document status, replacement, authentication, and filing behaviour, TXA is the segment doing the serious work.

Notification, content, and the document lifecycle

The easy split is this: MDM messages with odd trigger events usually describe a document without sending the body, and the matching even trigger events include the content. T01 is original document notification, while T02 is original document notification and content. T03/T04 are status changes. T05/T06 are addenda. T07/T08 are edits before the document is available for patient care. T09/T10 are replacements once the old document has been made available. T11 is cancellation, usually for a document that should not have been filed as it was.

That distinction matters. If the document has already been made available for care, you normally should not silently edit the same document in place. You send a replacement or an addendum, preserve the historical record, and link the new document back to the old one. That is where TXA-12 and TXA-13 become very important. One identifies this document. The other identifies the parent document being added to or replaced. In Integration Soup, document replacement and addendum handling deserves its own clear branch so a correction does not accidentally look like a brand-new report.

TXA and OBX work together

The TXA segment does not carry the body. In an MDM^T02, T04, T06, T08, or T10, the body normally arrives in one or more OBX segments. That might be plain text, formatted text, a PDF in an ED value, a scanned image, or a MIME package. TXA-3 should agree with that content style, and OBX should carry the value in a way the receiver has actually agreed to parse. Open the sample in HL7 Soup Web and that split is much easier to explain to someone who is trying to find the PDF in TXA.

Large documents deserve a bit of engineering respect. A text discharge summary is easy. A multi-megabyte PDF or a set of embedded images can expose message size limits, MLLP timeouts, interface engine memory settings, and systems that thought "one OBX" meant one line of text. If you are sending scanned documents or binary payloads, agree the OBX-2 value type, the ED components, the encoding, max size, splitting rules, and what to do when the receiver cannot store the document.

So let's go through each of the TXA fields and talk about how they tend to behave in real interfaces.

Most document messages only have one TXA segment, so this is usually just 1. It is the set number for the segment inside this message, not the document number, not the version number, and not the patient-facing report ID.

If a profile allows more than one TXA, count them in order. Otherwise keep it boring. Nobody wants a support call because a receiver expected 1 and got a locally invented tracking value.

This is one of the fields that decides where the document lands. The base table gives values like DS for discharge summary, OP for operative report, DI for diagnostic imaging, SP for surgical pathology, CN for consultation, HP for history and physical, and PR for progress note. Those are good examples, but document type is still very local. The receiving EHR may have a filing cabinet full of local categories.

Try not to map everything to "report" because it is convenient. A discharge summary, psychiatric consultation, radiology report, referral letter, and procedure note often have different routing, display, privacy, retention, and patient portal rules. If you need local codes, send the coding system or assigning authority clearly enough that the receiver knows whose code set it is reading. A neat little DS is helpful only if both sides agree it really means the same thing.

When the message includes content in OBX, this field explains the general presentation of that content. TEXT is common for machine-readable text. AP may be used for application data or binary-style content, IM for image data, AU for audio, and multipart for a MIME package. It is about the content form, not whether the document is a discharge summary or an operative report.

The trap is letting TXA-3, OBX-2, and OBX-5 tell different stories. If TXA-3 says text but OBX-5 is an encoded PDF, the receiver has to decide which field is lying. For document content, make the TXA metadata and the OBX payload line up in the interface guide, especially when sending PDFs, scanned pages, CDA documents, or anything Base64 encoded.

This is the clinical date in the document: the date of surgery, procedure, consultation, examination, or activity being described. It is not automatically the message date, and it is not necessarily the dictation date.

For filing and clinical timelines, this date is often more useful than the time the document was transmitted. A discharge summary written today about a discharge yesterday should not appear on the clinical timeline as if the discharge happened today. If your receiver sorts documents by "service date", this is usually the field it is hoping you populated correctly.

The person who performed or was responsible for the activity belongs here. For an operative report it may be the surgeon. For a radiology document it may be the radiologist or clinician responsible for the study. For a consultation letter it may be the consulting provider.

This can be different from the person who dictated the document and different again from the person who authenticated it. That distinction is worth keeping. If you flatten all the provider names into one field, the receiving system might file the document under the wrong author, route it to the wrong sign-off queue, or show the wrong clinician on the patient portal.

This is when the document was created at source: dictated, recorded, typed, generated, or otherwise brought into being. It is the start of the document's life, not the clinical activity date and not the final signature time.

In older transcription workflows this was often the dictation time. In modern systems it may be the creation time of a note, report, scan, or generated correspondence. It is useful for turnaround-time reporting, especially when comparing activity date, origination, transcription, and authentication.

When there is actual transcription, this is the time the input was transcribed. It is a very practical field in dictation systems because it separates "doctor spoke the report" from "text became available for review".

If the document is generated directly by an EHR with no transcription step, this may be empty or treated as the document generation time by local agreement. Do not force a value just because the field is there. A made-up transcription time makes turnaround reports look tidy and wrong, which is the worst sort of tidy.

This repeatable field tracks edit times. It is most useful while the document is still being corrected, reviewed, or polished before it is made available for care.

Once a document is available, changing the same document in place becomes a governance issue, not just a technical update. Edits before availability are one thing. Addenda and replacements after availability are another. If your interface receives edit notifications, make sure you know whether they are true pre-release edits or a system trying to sneak a revised clinical document over the top of a signed one.

The originator is the person who originated the document, often the dictator or author. This may be the doctor who dictated the discharge summary, the clinician who created the note, or the provider who initiated the document.

Do not automatically treat this as the final signer. In teaching or team-based workflows, the resident may originate the note, an attending may be assigned to authenticate it, and a final electronic signature may happen later. TXA has separate fields for those because document authorship is not always one person doing one thing at one time.

This is the person, or people, expected to authenticate the document. It can repeat, which is important for co-signing, teaching facilities, consultant sign-off, or workflows where more than one provider needs to approve the document.

I think of this as a work-queue field. It says who should sign or verify the document, not necessarily who has already done so. When the signature actually happens, TXA-22 is the better place to say who authenticated it and when.

If a person transcribed the document, this is where that person can be identified. In older dictation environments this could be a real and useful audit field. In voice-recognition or generated-document workflows it may be empty, or it may identify a service rather than a human.

Use it where the receiver needs transcription audit or productivity data. Do not confuse it with the author, responsible clinician, or authenticator. A transcriptionist typed the words; they did not usually perform the clinical activity or sign the report.

This is the big identifier. It is required, and it is the value future document updates, status changes, queries, replacements, and addenda are likely to use for matching. If PID-3 is the patient identity habit you want in patient feeds, TXA-12 is the same kind of habit for document feeds: stable, unique, and carrying enough assigning authority to avoid guessing.

Use a real document ID from the document-producing system if you have one. A filename can help humans, but filenames move, get regenerated, collide, and sometimes contain environment-specific paths. The EI data type lets you carry the identifier and assigning authority, so DOC-000123^EHRDOC^CITYHOSP is already much better than 000123. When a system says "we do not have a document ID", that is a warning sign. You need some stable key or every later status message becomes a matching exercise.

Addenda and replacements need a family tree. TXA-13 points back to the parent document, so the receiving system can say "this new document belongs with that old document" or "this document replaces that one".

Use it deliberately for T05, T06, T09, and T10 style flows. A replacement document should usually have its own new TXA-12, with TXA-13 pointing back to the document being replaced. Do not reuse the old document ID for a new replacement unless the implementation guide has explicitly designed for that. It blurs audit history at exactly the moment you most need audit history to be clear.

When the document is tied to one or more orders, the placer order number can connect it back to the ordering system. A radiology report may cover several X-ray orders. A pathology document may relate to a requested procedure. A discharge document may not have an order at all.

If the message includes ORC or OBR and the placer number is already present there, follow the standard's advice and do not duplicate it here. Duplicate identifiers that disagree are worse than no duplicate at all. Use this field when TXA is the practical place the receiving system expects the order link, especially in document-only notifications.

The filler side of the order can also be linked here. In document workflows the filler may be the transcription system, imaging system, pathology system, or another application that produced or managed the report.

Again, do not fight ORC-3 or OBR-3 if those segments are present and already carry the filler order number. If this field is used, keep the assigning authority meaningful and do not reuse simple numbers over time unless you have a date or authority that makes them unique.

A filename can be helpful when the document exists as a file, scan, PDF, or exported text document. It can help a receiver or support person connect the HL7 message to the physical file that arrived on disk or in a document repository.

I would not make it the main identity of the document unless there is no better option. File names and paths are operational details. They change during migrations, exports, archiving, or environment moves. Also be careful not to leak internal paths or shared-drive structure to partners who do not need it. TXA-12 is usually the better long-term identifier.

This is required and very important. Typical values include DI for dictated, IP for in progress, IN for incomplete, PA for pre-authenticated, AU for authenticated, LA for legally authenticated, and DO for documented. It describes where the document sits in the completion workflow.

Do not confuse completion with availability. A document can be pre-authenticated, authenticated, or legally authenticated, but the receiving system still needs to know whether it is available for patient care. TXA-17 tells you completion/signing state. TXA-19 tells you availability. A document interface that only looks at one of them may display draft documents too early or hide signed documents too long.

Confidentiality is small in the segment and large in the real world. The common values are U for usual control, R for restricted, and V for very restricted. What those mean operationally is not universal. Your organisation and jurisdiction decide what extra protection applies.

Do not treat this as decoration. A restricted psychiatric consultation, sexual health document, substance-use document, domestic violence note, or other sensitive document may need special routing, masking, portal suppression, or consent-aware access. If the receiver cannot honour confidentiality, that is an interface design problem, not just a missing lookup table.

This field says whether the document is available for use in patient care. AV means available, UN means unavailable, OB means obsolete, and you may see cancellation/deletion style values depending on the version and implementation guide.

The best practical rule is to take AV seriously. Once a document has been made available for patient care, the standard's model pushes corrections toward addenda or replacement, not silent edits. If the wrong document was filed to the wrong patient before availability, cancellation may be appropriate. If the document was already available, a replacement trail is usually the cleaner and safer story.

Storage status is about where the document lives operationally: active, archived, active and archived, or purged. It is not the same as clinical availability. A document can be archived and still clinically visible, or purged from one repository while retained elsewhere by policy.

This is useful for document repositories, chart tracking, and long-term medical record management. Many simple feeds leave it empty because the receiver only cares about the document content and filing status. If you do send it, make sure the receiver knows whether it should change display behaviour, retrieval behaviour, or only metadata.

When a document status changes, a short reason can save a lot of detective work. Examples are things like "Corrected diagnosis", "Wrong patient", "Addendum", "Author correction", or "Final signature". The standard keeps this short, so it is not meant to be a full narrative.

Use it to explain the status change, not to carry the clinical correction itself. If the document has changed clinically, the revised document, addendum, or replacement content should say what changed. TXA-21 is the note on the filing action.

This is where the actual authentication event can be recorded: who authenticated the document and when it happened. It uses the PPN data type, so it carries person details and the time stamp together.

If you send one half, send the other. A signer without a time is weak, and a signature time without a signer is almost useless. This is especially important for e-signature workflows, medico-legal records, teaching co-signature, and anything where finalisation time matters. If OBR is also present, avoid duplicating the same authentication in OBR-32 and TXA-22 unless the interface guide has a clear rule for it.

This is the old but still understandable "copies sent to" idea. It can identify clinicians or recipients who received a copy of the document, much like the CC list on a letter.

Use it when the receiving system tracks distribution, correspondence copies, or provider notification history. Do not use it as a substitute for confidentiality or access control. Getting a copy and being allowed to view a restricted document are different concepts, and the interface should not blur them.

What about newer TXA fields?

Later HL7 references add fields after TXA-23, such as folder assignment, document title, due date, creating facility, and creating specialty. This page follows the v2.5.1 field list used in our local reference data, which stops at TXA-23. If a partner profile gives you TXA-24 or beyond, read that profile carefully because those extra fields are often used for local filing and display behaviour.