Draft Website - For Review Purposes Only

The TXA segment contains information specific to a transcribed document but does not include the text of the document. The message is created as a result of a document status change. This information updates other healthcare systems and allows them to identify reports that are available in the transcription system. By maintaining the TXA message information in these systems, the information is available when constructing queries to the transcription system requesting the full document text.

HL7 Attribute Table - TXA - Transcription Document Header Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
TXA
1	00914	Set ID- TXA	SHALL		[1..1]	[1..4]			SI
2	00915	Document Type	SHALL		[1..1]			0270 Document Type	CWE
3	00916	Document Content Presentation	MAY True: False:	C	[1..1] [0..1]			0191 Type of Referenced Data	ID
4	00917	Activity Date/Time			[0..1]				DTM
5	00918	Primary Activity Provider Code/Name	MAY True: False:	C	[1..1] [0..1]				XCN
6	00919	Origination Date/Time			[0..1]				DTM
7	00920	Transcription Date/Time	MAY True: False:	C	[1..1] [0..1]				DTM
8	00921	Edit Date/Time			[0..*]				DTM
9	00922	Originator Code/Name			[0..*]				XCN
10	00923	Assigned Document Authenticator			[0..*]				XCN
11	00924	Transcriptionist Code/Name	MAY True: False:	C	[1..1] [0..1]				XCN
12	00925	Unique Document Number	SHALL		[1..1]				EI
13	00926	Parent Document Number	MAY True: False:	C	[1..1] [0..1]				EI
14	00216	Placer Order Number			[0..*]				EI
15	00217	Filler Order Number			[0..1]				EI
16	00927	Unique Document File Name			[0..1]				ST
17	00928	Document Completion Status	SHALL		[1..1]	[2..2]			ID
18	00929	Document Confidentiality Status			[0..1]	[1..1]		0272 Document Confidentiality Status	ID
19	00930	Document Availability Status			[0..1]	[2..2]			ID
20	00932	Document Storage Status			[0..1]	[2..2]		0275 Document Storage Status	ID
21	00933	Document Change Reason			[0..1]				ST
22	00934	Authentication Person, Time Stamp	MAY True: False:	C	[1..1] [0..1]				PPN
23	00935	Distributed Copies			[0..*]				XCN
24	02378	Folder Assignment			[0..*]			0791	CWE
25	03301	Document Title			[0..*]				ST
26	03302	Agreed Due Date/Time			[0..1]				DTM
27	02413	Creating Facility			[0..1]				HD
28	02414	Creating Specialty			[0..1]			0792	CWE

Definition: This field contains a number that uniquely identifies this transaction for the purpose of adding, changing, or deleting the transaction.

Definition: This field identifies the type of document (as defined in the transcription system). Refer to User-Defined Table 0270 - Document Type for suggested values. The organization is free to add more entries. Receivers are required to inspect the Coding System component of the CWE data type to accurately interpret the meaning of the code. Senders transmitting messages to Receivers on earlier version of the standard may elect to negotiate business rules to ensure that expected data is not lost. HL7 does not assign positional meaning to user-defined codes.

Definition: This is a conditional field which is required whenever the message contains content as presented in one or more OBX segments. This field identifies the method by which this document was obtained or originated. Refer to HL7 Table 0191 – Type of Referenced Data for valid values.

Definition: This field contains the date/time identified in the document as the date a procedure or activity was performed. This date can identify date of surgery, non-invasive procedure, consultation, examination, etc.

Definition: This field contains the name of the person identified in the document as being responsible for performing the procedure or activity. This field includes the code and name (if available) of the caregiver. This field is conditional based upon the presence of a value in TXA-4-Activity Date/Time.

Definition: This field contains the date and time the document was created (i.e., dictated, recorded, etc.).

Definition: This field contains the date and time the input was actually transcribed. This field is conditional based upon the presence of a value in TXA-17-Document Completion Status of anything except "dictated."

Definition: This field contains the date and time the document was edited.

Definition: This field identifies the person who originated (i.e., dictated) the document. The document originator may differ from the person responsible for authenticating the document.

Definition: This field identifies the person(s) responsible for authenticating the document, who may differ from the originator. Multiple persons may be responsible for authentication, especially in teaching facilities. This field is allowed to repeat an undefined number of times.

Definition: This field identifies the person transcribing the document. This is a conditional value; it is required on all transcribed documents.

TXA-11 - Condition: If TXA-11 is valued and the corresponding OBR segment is present in the message OBR-35 must be blank. If OBR-35 is valued while TXA-11 is valued, OBR-35 shall be ignored. See message definitions including TXA for further guidanceon which ORC/OBR pairs to consider.

Definition: This field contains a unique document identification number assigned by the sending system. This document number is used to assist the receiving system in matching future updates to the document, as well as to identify the document in a query. When the vendor does not provide a unique document ID number, some type of document identifier should be entered here, or the Unique Document File name should be utilized. See Chapter 2A, section 2.A.89, "XTN - extended telecommunication number." Where the system does not customarily have a document filler number, this number could serve as that value, as well.

Definition: This field contains a document number that identifies the parent document to which this document belongs. The parent document number can be used to assist the receiving system in matching future updates to this document. This is a conditional field that is always required on T05 (document addendum notification), T06 (document addendum notification and content), T09 (document replacement notification), and T10 (document replacement notification and content) events.

(Definition from ORC.2 in Ch. 4)

Definition: This field is the placer application's order number.

This field is a case of the Entity Identifier data type (See Section 2.A.28, "EI – Entity Identifier"). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.

There are three situations in which the true placer is somewhat arbitrary (and thus not unique):

1. in ORC-1-order control value of RO, following an RU replacement;

2. in ORC-1-order control value of CH (child orders); and

3. in ORC-1-order control value of SN (send number).

See the Table Notes under ORC-1-order control for the details of how the ORC-2-placer order number is assigned in these cases.

The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). Note that if both ORC-2 and OBR-2 are valued then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number for the placer order number when a new order is placed or a unique number for the filler order number when an unsolicited result is initially communicated.

These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).

(Definition from OBR.2 in Ch. 4)

Definition: This field is identical to ORC-2-Placer Order Number.

This field is a special case of the Entity Identifier data type (Chapter 2A, section 2.A.28). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.

See ORC-2-placer order number (section 4.5.1.2) for information on when this field must be valued.

A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.

These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).

(Definition from OBR.2 in Ch. 7)

Definition: This field is identical to ORC-2-Placer Order Number.

This field is a special case of the Entity Identifier data type (Chapter 2A, section 2.A.28). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.

See ORC-2-placer order number (section 4.5.1.2) for information on when this field must be valued.

A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.

These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).

(Definition from TXA.14 in Ch. 9)

Definition: This field is the placer application's order number.

This is a composite field. The first component is a string of characters that identifies an individual order (i.e., OBR). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the (filler) assigning authority of the placing application. The (filler) assigning authority is a string of characters that will be uniquely associated with an application. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique entity identifiers. The components are separated by component delimiters.

TXA-14 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-2 or OBR-2 is valued, this field must be blank. If TXA-14 is valued while ORC-2 or OBR-2 is valued it shall be ignored. See message definitions including TXA for further guidance on which ORC/OBR pairs to consider.

(Definition from ARQ.24 in Ch. 10)

Definition: This field is the placer application's order number for the order associated with this scheduling request.

This field is described in detail in Chapter 4, section 4.5.1.2, "ORC-2 – Placer Order Number." It is an optional field, but if a Placer order number is present, then a Filler order number (ARQ-25 – Filler Order Number) must also be present.

(Definition from SCH.26 in Ch. 10)

Definition: This field is the placer application's order number for the order associated with this scheduling filler application response.

This field is described in detail in Section 4.5.1.2. It is an optional field, but if a Placer order number is present, then a Filler order number (Section 10.6.2.27) must also be present. Both this field and the Filler order number below may have been sent as part of the appointment request in the ARQ segment or they may be assigned by the scheduling filler application only.

(Definition from ORC.3 in Ch. 4)

Definition: This field is the order number associated with the filling application. It is a case of the Entity Identifier data type (Section 2.A.28). Its first component is a string that identifies an order detail segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filler (receiving) application. This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see Section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third- party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the filler application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). Note that if both ORC-2 and OBR-2 are valued, then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments. It is recommended that the initiating system should provide a unique number for the placer order number when a new order is placed or a unique number for the filler order number when an unsolicited result is initially communicated.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

(Definition from OBR.3 in Ch. 4)

Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI – entity identifier").

The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

See ORC-3-filler order number for information on when this field must be valued.

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

(Definition from FT1.23 in Ch. 6)

Definition: This field is used when the billing system is requesting observational reporting justification for a charge. This is the number used by a filler to uniquely identify a result. See Chapter 4 for a complete description.

(Definition from OBR.3 in Ch. 7)

Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI – entity identifier").

The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

See ORC-3-filler order number for information on when this field must be valued.

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

(Definition from TXA.15 in Ch. 9)

Definition: This field is the order number associated with the filling application. Where a transcription service or similar organization creates the document and uses an internally unique identifier, that number should be inserted in this field. Its first component is a string of characters that identifies an order detail segment (i.e., OBR). This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (i.e., transcription service). This uniqueness must persist over time. Where a number is reused over time, a date can be affixed to the non-unique number to make it unique.

The second through fourth components contains the (filler) assigning authority. The (filler) assigning authority is a string of characters that uniquely defines the application from other applications on the network. The second through fourth components of the filler order number always identify the actual filler of an order.

TXA-15 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-3 or OBR-3 is valued, this field must be blank. If TXA-14 is valued while ORC-3 or OBR-3 is valued it shall be ignored. See message definitions including TXA for further guidanceon which ORC/OBR pairs to consider.

For further details, please see the definitions provided in Chapter 4, "Orders".

(Definition from ARQ.25 in Ch. 10)

Definition: This field is the order number assigned by the filler application for the order associated with this scheduling request.

This field is described in detail in Chapter 4, section 4.5.1.3, "ORC-3 – Filler Order Number.” It is conditionally mandatory depending on the presence of the Placer order number (ARQ-24 – Placer Order Number). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the filler application before scheduling the resources associated with that order.

(Definition from SCH.27 in Ch. 10)

Definition: This field is the order number assigned by the filler application for the order associated with this scheduling filler response.

This field is described in detail in Chapter 4, Orders, section 4.5.1.3. It is conditionally mandatory depending on the presence of the placer order number (section 10.6.2.26). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the order filler application before scheduling the resources associated with that order.

Definition: This field contains a unique name assigned to a document by the sending system. The file name is used to assist the receiving system in matching future updates to the document.

Definition: This field identifies the current completion state of the document. This is a required, table-driven field. Refer to HL7 Table 0271 - Document Completion Status for valid values.

Figure 9-1. Document completion status state transition table

Transition (Action)	Old State	New State
T01 Original Notification T02 Original Notification and Content	NA	Dictated In Progress Incomplete Pre-authenticated Authenticated Legally authenticated
T03 Status Change Notification T04 Status Change Notification and Content	Dictated	In Progress Incomplete Pre-authenticated Authenticated Legally authenticated
	In Progress	Incomplete Pre-authenticated Authenticated Legally authenticated
	Incomplete	Pre-authenticated Authenticated Legally authenticated
	Pre-authenticated	Authenticated Legally authenticated
	Authenticated	Legally authenticated
	Legally authenticated	NA
	Documented	Pre-authenticated Authenticated Legally authenticated
T05 Addendum Notification T06 Addendum Notification and Content	NA	Dictated In Progress Incomplete Pre-authenticated Authenticated Legally authenticated
T07 Edit Notification T08 Edit Notification and Content	Dictated	In Progress Incomplete Pre-authenticated Authenticated Legally authenticated
	In Progress	Incomplete Pre-authenticated Authenticated Legally authenticated
	Incomplete	Pre-authenticated Authenticated Legally authenticated
	Pre-authenticated	Authenticated Legally authenticated
	Authenticated	Legally authenticated
	Legally authenticated	NA
	Documented	Pre-authenticated Authenticated Legally authenticated
T09 Replacement Notification T10 Replacement Notification and Content	NA	Dictated In Progress Incomplete Pre-authenticated Authenticated Legally authenticated
T11 Cancel Notification	Dictated In Progress Incomplete Pre-authenticated and Availability status of "Unavailable"	Canceled

Definition: This is an optional field which identifies the degree to which special confidentiality protection should be applied to this information. The assignment of data elements to these categories is left to the discretion of the healthcare organization. Refer to HL7 Table 0272 - Document Confidentiality Status for valid values.

Definition: This is an optional field which identifies a document's availability for use in patient care. If an organization's business rules allow a document to be used for patient care before it is authenticated, the value of this field should be set to "AV." If a document has been made available for patient care, it cannot be changed or deleted. If an erroneous document has been made available at any point in time and a replacement is not appropriate, then it may be marked as "Canceled" and removed, as in the case of a document being assigned to the wrong patient. Additional information must be provided via an addendum, which is separately authenticated and date/time stamped. If the content of a document whose status is "Available" must be revised, this is done by issuing a replacement, which is separately authenticated and date/time stamped. Refer to HL7 Table 0273 - Document Availability Status for valid values.

Figure 9-2. Document availability status state transition table

Transition (Action)	Old State	New State	Notes
T01 Original Notification T02 Original Notification and Content	NA	Unavailable Available
T03 Status Change Notification T04 Status Change Notification and Content	Unavailable	Unavailable Available Obsolete
	Available	Available Obsolete
	Obsolete	NA
T05 Addendum Notification T06 Addendum Notification and Content	NA	Unavailable Available
T07 Edit Notification T08 Edit Notification and Content	Unavailable	Unavailable Available
T09 Replacement Notification T10 Replacement Notification and Content	NA	Unavailable Available	Set parent document to "obsolete"
T11 Cancel	Unavailable	Delete

Definition: This optional field identifies the storage status of the document. Refer to HL7 Table 0275 - Document Storage Status for valid values.

Definition: This free text field (limited to 30 characters) contains the reason for document status change.

Definition: This field contains a set of components describing by whom and when authentication was performed (either manually or electronically). The Date/Time Action Performed component describes the date/time of the authentication (Authentication Time Stamp). The remaining components identify the person performing the authentication (Authentication Person). If either of the Authenticating Person or the Authentication Time Stamp is valued as non-null, then both must be valued as non-null.

TXA-22 - Condition: If TXA-22 is valued and the corresponding OBR segment is present in the message OBR-32 must be blank. If OBR-32 is valued while TXA-22 is valued, OBR-32 shall be ignored. See message definitions including TXA for further guidanceon which ORC/OBR pairs to consider.

Definition: This field identifies the persons who received a copy of this document.

Definition: This field is used to assign documents to folders. These folders are not nested; a document may either be part of none or several folders. In practice this can be used to separate the documents into domain specific types (e.g., cardiology reports, radiology reports), organizational types (e.g., administrational document, billing document), body region types (e.g., chest CT, leg CT), or something else. Furthermore, this information can be combined. This usually depends on the system involved and therefore it must be up to the user to define it. The systems can use the information to define workflows or manage access to the document. Receivers are required to inspect the Coding System component of the CWE data type to accurately interpret the meaning of the code. Senders transmitting messages to Receivers on earlier version of the standard may elect to negotiate business rules to ensure that expected data is not lost. HL7 does not assign positional meaning to user-defined codes. Refer to Table 0791 - Folder Assignment in Chapter 2C for valid values.

Definition: This field supports the identification of the document title. When communicating the meta information without the document contents you may submit the document title as well.

Definition: This field contains the date and time the document is or will be due back to the original author or dictator from the transcriptionist.

Definition: This field identifies the facility in which this document has been created.

Definition: This field identifies the specialty of the provider which created this document. Refer to Table 0792 - Creating Specialty in Chapter 2C for valid values.