9. Medical Records/Information Management (Document Management)
9 . Medical record file / information management (file management)
Chapter Chair/Editor: The person in charge/editor of this chapter: | Wayne Tracy, MS Health Patterns, LLC |
---|---|
Chapter Chair/Editor: The person in charge/editor of this chapter: | Harry Rhodes American Health Information Management Association |
Note: No substantive changes were made to this chapter for Version 2.4.
Note: This chapter does not make many changes to version 2.4.
9.1 Chapter 9 Contents
9.1 Chapter 9 contents.............................................. .................................................. .............................................. 1
9.1 Chapter 9 Contents . 1
9.2 PURPOSES...................................... .................................................. .................................................. ..................... 4
9.2 Purpose 4
9.2.1 Definition of terms and concepts.......................................... .................................................. ...... 5
9.2.1 Definition of terms and concepts ....................................... .................................................. ............................................. 5
9.2.1.1 Addendum:............................................ .................................................. .................................................. ...... 5
9.2.1.1 Appendix :............................................ .................................................. .................................................. ............ 5
9.2.1.2 Archived:............................................. .................................................. .................................................. ........ 5
9.2.1.2 Complete archive :............................................ .................................................. .................................................. .............. 5
9.2.1.3 Canceled:............................................. .................................................. .................................................. ....... 5
9.2.1.3 Completed deletion :............................................ .................................................. .................................................. .............. 5
9.2.1.4 Composite document:............................................ .................................................. .............................. 5
9.2.1.4 Compound file :............................................ .................................................. .................................................. .............. 5
9.2.1.5 Document completion table:........................................... .................................................. ........... 6
9.2.1.5 File completion table : ... .................................................. .................................................. .......... 6
9.2.1.6 Authenticated:............................................. .................................................. ........................................... 6
9.2.1.6 Complete identification :............................................ .................................................. .................................................. .............. 6
9.2.1.6.1 Dictated:... .................................................. .................................................. .. 6
9.2.1.6.1 Completing the dictation : ... .................................................. .................................................. ....... 6
9.2.1.6.2 Documented:............................................ .................................................. ........................................... 6
9.2.1.6.2 Completion of filing :......................................... .................................................. .................................................. ........ 6
9.2.1.6.3 In progress/assigned:........................................ .................................................. .......................... 6
9.2.1.6.3 In operation / specified : .............................. .................................................. .................................................. ... 6
9.2.1.6.4 Incomplete:... .................................................. ............................................. 6
9.2.1.6.4 Unfinished :............................................ .................................................. .................................................. ........... 6
9.2.1.7 Legally authenticated:............................................ .................................................. ............ 7
9.2.1.7 Complete legal identification : ............................. .................................................. .................................................. .. 7
9.2.1.7.1 Pre-authenticated:......................................... .................................................. ............ 7
9.2.1.7.1 Before identification : ... .................................................. .................................................. ........... 7
9.2.1.8 Edited document:............................................ .................................................. ....................................... 7
9.2.1.8 Edit file : ............................. .................................................. .................................................. .............. 7
9.2.1.9 New or original document:.......................................... .................................................. ................. 7
9.2.1.9 New file or original file :......................................... .................................................. .................................................. ... 7
9.2.1.10 Obsolete:............................................. .................................................. .................................................. ... 7
9.2.1.10 abandoned : ............................................. .................................................. .................................................. .................. 7
9.2.1.11 Purged:............................................. .................................................. .................................................. ......... 7
9.2.1.11 Clear : ............................... .................................................. .................................................. .................. 7
9.2.1.12 Replacement document:............................................ .................................................. .................. 8
9.2.1.12 Replacement file :............................................ .................................................. .................................................. ......... 8
9.2.1.13 Restricted:............................................. .................................................. ................................................. 8
9.2.1.13 Restrictions : ............... .................................................. .................................................. .................. 8
9.2.1.14 Revised document:............................................ .................................................. ................................. 8
9.2.1.14 Revised file :............................................ .................................................. .................................................. ......... 8
9.2.1.15 Transcription:............................................. .................................................. ......................................... 8
9.2.1.15 Transcription : ............................. .................................................. .................................................. .................. 8
9.3 DOCUMENT MANAGEMENT SECTION.............................................. .................................................. ................ 8
9.3 File Management Section............................................ .................................................. .................................................. ...................... 8
9.4 ASSUMPTIONS...................................... .................................................. .................................................. ............ 9
9.4 Assumptions... .................................................. .................................................. .................................. 9
9.5 TRIGGER EVENTS AND MESSAGE DEFINITIONS............................................ ............................................... 9
9.5 Trigger event and information definition............................................ .................................................. .................................................. ..... 9
9.5.1 MDM/ACK-original document notification (event T01).................................... .......... 10
9.5.1 MDM/ACK- Original file notification ( event code T01) ... .................................................. .................... 10
9.5.2 MDM/ACK-original document notification and content (event T02)............. 11
9.5.2 MDM/ACK- Original file notification and content (event code T02 ) ................................. .................................................. . 11
9.5.3 MDM/ACK-document status change notification (event T03)............................... 12
9.5.3 MDM/ACK- File status change notification (event code T03 ) ........................ .................................................. 12
9.5.4 MDM/ACK-document status change notification and content (event T04) 13
9.5.4 MDM/ACK- File status change notification and content ( event code T04) ... ............................................. 13
9.5.5 MDM/ACK-document addendum notification (event T05).......................... ....... 14
9.5.5 MDM/ACK- File appendix notice (event code T05 ) ................................... .................................................. ........ 14
9.5.6 MDM/ACK-document addendum notification and content (event T06).......... 14
9.5.6 MDM/ACK- File appendix notice and content ( event code T06)... .................................................. ... 14
9.5.7 MDM/ACK-Document edit notification (event T07).................................... ................. 15
9.5.7 MDM/ACK- File Editing Notice ( Event Code T07)......................... .................................................. ............... 15
9.5.8 MDM/ACK-document edit notification and content (event T08)......................... 16
9.5.8 MDM/ACK- File Editing Notice and Content ( Event Code T08)... .................................................. ... 16
9.5.9 MDM/ACK-document replacement notification (event T09)........................ 17
9.5.9 MDM/ACK- File replacement notification (event code T09 ) ................................... .................................................. ........ 17
9.5.10 MDM/ACK-document replacement notification and content (event T10) 17
9.5.10 MDM/ACK- File replacement notice and content (event code T10 ) ................................. .............................................. 17
9.5.11 MDM/ACK-document cancel notification (event T11).................................... .............. 18
9.5.11 MDM/ACK- File deletion notification (event code T11 ) ................................... .................................................. ........ 18
9.6 MESSAGE SEGMENTS............................................... .................................................. ..............................................19
9.6 Information section... .................................................. .................................................. ............19
9.6.1 TXA-transcription document header segment......................................... ... 19
9.6.1 TXA- Transcription file header section ............................ .................................................. .......................................... 19
9.6.1.0 TXA field definitions............................................ .................................................. ......................... 21
9.6.1.0 TXA field definition ............................................ .................................................. ................................................. 21
9.6.1.1 TXA-1 Set ID-TXA (SI) 00914.................................... .................................................. ..................... 21
9.6.1.1 TXA-1 Set ID-TXA (SI) 00914.................................... .................................................. ................... 21
9.6.1.2 TXA-2 Document type (IS) 00915............................ ................................................. 21
9.6.1.2 TXA-2 File Type (IS) 00915...................................... .................................................. ................... 21
9.6.1.3 TXA-3 Document content presentation (ID) 00916... ....... 22
9.6.1.3 TXA-3 File Content Statement (ID) 00916... .................................................. .............. 22
9.6.1.4 TXA-4 Activity date/time (TS) 00917.................................... ............................................... 23
9.6.1.4 TXA-4 Event Date / Time (TS) 00917... .................................................. ................ 23
9.6.1.5 TXA-5 Primary activity provider code/name (XCN) 00918............................ 23
9.6.1.5 TXA-5 main activity provider code / name (XCN) 00918... ..................................... 23
9.6.1.6 TXA-6 Origination date/time (TS) 00919... .................................. 24
9.6.1.6 TXA-6 Creation Date / Time (TS) 00919... .................................................. ........... 24
9.6.1.7 TXA-7 Transcription date/time (TS) 00920.................................... ............................. 24
9.6.1.7 TXA-7 Transcription Date / Time (TS) 00920... .................................................. ........... 24
9.6.1.8 TXA-8 Edit date/time (TS) 00921.......................... .................................................. .... 24
9.6.1.8 TXA-8 Edit Date / Time (TS) 00921.......................... .................................................. ........... 24
9.6.1.9 TXA-9 Originator code/name (XCN) 00922.................................... .............................. 24
9.6.1.9 TXA-9 Creator Code / Name (XCN) 00922......................... .................................................. ... 24
9.6.1.10 TXA-10 Assigned document authenticator (XCN) 00923................................ 25
9.6.1.10 File authenticator (XCN) designated by TXA-10 00923 ... ................................................ 25
9.6.1.11 TXA-11 Transcriptionist code/name (XCN) 00924.................................... ......... 25
9.6.1.11 TXA-11 transcriber code / name (XCN) 00924................................... ............................................... 25
9.6.1.12 TXA-12 Unique document number (EI) 00925... .................... 26
9.6.1.12 TXA-12 unique file number (EI) 00925... .................................................. .. 26
9.6.1.13 TXA-13 Parent document number (EI) 00926... ................... 26
9.6.1.13 TXA-13 Original File Number (EI) 00926... .................................................. ..... 26
9.6.1.14 TXA-14 Placer order number (EI) 00216... ............................. 26
9.6.1.14 TXA-14 Placer instruction number (EI) 00216... .................................................. .. 26
9.6.1.15 TXA-15 Filler order number (EI) 00217... ............................... 27
9.6.1.15 TXA-15 Filler Command Number (EI) 00217... .................................................. .. 27
9.6.1.16 TXA-16 Unique document file name (ST) 00927.................................... ............... 28
9.6.1.16 TXA-16 unique archive file name (ST) 00927......................... ........................................... 28
9.6.1.17 TXA-17 Document completion status (ID) 00928... ......... 28
9.6.1.17 TXA-17 file completion status (ID) 00928... .................................................. ..... 28
9.6.1.18 TXA-18 Document confidentiality status (ID) 00929................................... 32
9.6.1.18 TXA-18 File Confidential Status (ID) 00929... .................................................. ..... 32
9.6.1.19 TXA-19 Document availability status (ID) 00930... ........... 33
9.6.1.19 TXA-19 File Validity Status (ID) 00930... .................................................. .......... 33
9.6.1.20 TXA-20 Document storage status (ID) 00932... ............ 34
9.6.1.20 TXA-20 file storage status (ID) 00932... .................................................. .......... 34
9.6.1.21 TXA-21 Document change reason (ST) 00933... ................... 35
9.6.1.21 Reason for TXA-21 File Change (ST) 00933........................... .................................................. ..... 35
9.6.1.22 TXA-22 Authentication person, time stamp (set) (PPN) 00934................. 35
9.6.1.22 TXA-22 authenticator, time stamp (setup) (PPN) 00934................................ ............................. 35
9.6.1.22.1 Authentication person (component) (XCN)... ... 36
9.6.1.22.1 Identifier (composition) (XCN)..................................... .................................................. ................................ 36
9.6.1.22.2 Authentication time stamp (component) (TS)... ................. 36
9.6.1.22.2 Identification time stamp (composition) (TS).................................... .................................................. ..................... 36
9.6.1.23 TXA-23 Distributed copies (XCN) 00935...................................... ............................... 36
9.6.1.23 Distribution of a copy of TXA-23 (XCN) 00935... .................................................. .. 36
9.6.2 OBX-observation segment usage.......................................... .................................................. ..... 37
9.6.2 OBX- Usage of Observation Report Segment ......................................... .................................................. .......................................... 37
9.7 EXAMPLE MESSAGE............................................... .................................................. ................................................38
9.7 Instance Information............................................ .................................................. .................................................. ....................... 38
9.8 QUERY................................................ .................................................. .................................................. ......................... 39
9.8 Interrogation procedure............................................ .................................................. .................................................. ....................... 39
9.8.1 QRY/DOC-document query (event T12)........................... .................................................. 39
9.8.1 QRY/DOC- File inquiry procedure ( event code T12) ... .................................................. ............... 39
9.8.1.1 Query usage notes............................................ .................................................. ................................... 40
9.8.1.1 Precautions for the use of the inquiry program ... .................................................. ..................................... 40
9.9 OUTSTANDING ISSUES............................................... .................................................. ............................40
9.9 Important Questions 40
-
- PURPOSE S
9.2 Purpose
This chapter currently supports document management. In the future, it is intended also to support the data exchange needs of applications supporting other medical record functions, including chart location and tracking, deficiency analysis, consents, and release of information. The main purpose of the medical record is to produce an accurate, legal, and legible document that serves as a comprehensive account of healthcare services provided to a patient.
Currently, this chapter supports the management of archives. In the future, it will also provide support for data exchange required by applications that support other medical record file functions, including chart positioning and tracking, lack of analysis, and information release. The main purpose of the medical record file is to produce a correct, legal and easy-to-read file as a comprehensive medical service description provided to the patient.
This chapter defines the transactions at the seventh level, ie, the abstract messages. Various schemes may be used to generate the actual characters that comprise the messages according to the communications environment. The HL7 Encoding Rules will be used where there is not a complete Presentation Layer. This is described in Chapter 1, Relationship to Other Protocols. The examples in this chapter were constructed using the HL7 Encoding Rules.
This chapter defines the processing items at the seventh layer (application layer), that is, abstract information. Various schemes are used to generate actual characters composed of information according to the communication environment. HL7 encoding rules will be used where the image layer is not complete. This is described in Chapter 1 "Relationship with Other Agreements". The examples provided in this chapter are based on the use of HL7 coding rules.
9.2.1 Definition of terms and concepts
This part provides definition of terms used throughout this chapter. The intent of this part is to provide clarification on use and interpretation.
This section provides definitions of terms used in this chapter. The intention of this part is to provide instructions on use and decoding.
9.2.1.1 Appendix:
An appendage to an existing document that contains supplemental information. The parent document remains in place and its content is unaltered.
An appendix refers to an existing file that contains additional information. The original file is kept in place, and its content has not been changed.
9.2.1.2 Complete archive:
A storage status in which a document has been stored off-line for long-term access.
Storage status refers to storing a file offline for long-term reading.
9.2.1.3 Complete deletion:
An availability status in which a document has been removed from a patient's record with no replacement. This is done when a document has been erroneously created or assigned to the incorrect patient.
The valid status in a file has been deleted from the patient's record and has not been replaced. This is performed when a file is incorrectly created or assigned to the wrong patient.
9.2.1.4 Compound file:
A document which consists of an original document and one or more addenda.
An archive contains the original archive and one or more appendices.
9.2.1.5 File completion table:
The following terms are used to describe the workflow progression of a document:
The following terms are used to describe the production process of an archive.
9.2.1.6 Complete identification:
A completion status in which a document or entry has been signed manually or electronically by one or more individuals who attest to its accuracy. No explicit determination is made that the assigned individual has performed the authentication. While the standard allows multiple instances of authentication, it would be typical to have a single instance of authentication, usually by the assigned individual.
The completed state means that a file or input has been handwritten or electronically signed by one or more individuals who have proven its correctness. No clear decision has been made for the designated individuals who have performed the authentication. While the standard allows multiple forms of authentication, it will typically have a single form of authentication, usually obtained by designated individuals.
9.2.1.6.1 Complete the dictation:
A completion status in which information has been orally recorded but not yet transcribed.
The completion status means that the information has been dictated but has not yet been transcribed.
9.2.1.6.1 Complete filing:
A completion status in which document content, other than dictation, has been received but has not been translated into the final electronic format. Examples include paper documents, whether hand-written or typewritten, and intermediate electronic forms, such as voice to text.
The completed status means that the content of the file has been received except for the oral part, but has not been converted into the final electronic format. Examples include handwritten or printed documents and intermediary electronic forms, for example, from voice to text.
9.2.1.6.3 In operation / specified: **
A workflow status in which the recipient has assigned the material to personnel to perform the task of transcription. The document remains in this state until the document is transcribed.
Process status means that the receiver has assigned materials to personnel to perform transcription tasks. The file remains in this state until the file is fully transcribed.
9.2.1.6.4 Unfinished:
A completion status in which information is known to be missing from a transcribed document.
Complete status refers to the loss of information in a transcribed file.
9.2.1.7 Complete legal authentication:
A completion status in which a document or entry has been signed manually or electronically by the individual who is legally responsible for that document or entry. This is the most mature state in the workflow progression.
Full status means that a file or input item has been manually or electronically signed by an individual who is legally responsible for the file or input item. This is the most mature state in an operational process.
9.2.1.7.1 Before identification:
A completion status in which a document is transcribed but not authenticated.
Full status refers to a file that has been transcribed but has not yet been identified.
9.2.1.8 Edit file:
A document that alters an existing document which had not been made available for patient care (see also Section 9.1.1.10, Replacement document ).
Change an existing file that is invalid for the patient's medical service. (Refer to Section 9.1.1.10 "Replace File")
9.2.1.9 New file or original file:
The first version of a document. The original may or may not be final or authenticated. An original document should have a set of associated statuses to define its current condition.
The first version of an archive. This original version may become the final version or be identified. An original file should have a set of associated states to define its current situation.
9.2.1.10 Obsolete:
An availability status in which a document has been replaced by a document which contains revised content.
Valid status means that a file has been replaced by a file containing revised content.
9.2.1.11 Clear:
A storage status in which a document is no longer available in this system.
Storage status means that a file is no longer valid in this system.
9.2.1.12 Replacement file:
A document that replaces an existing document. The original document becomes obsolete, but is still retained in the system for historical reference.
A file replaces an existing file. The original file was discarded, but it is still kept in the system as a historical record for reference.
9.2.1.13 Restrictions:
A confidentiality status in which access to a document has institutionally assigned limitations.
Confidential status means that restrictions on access to a certain file have been institutionalized.
9.2.1.14 Revised file:
This is not a supported trigger event. See Sections 9.1.1.6, Edited document , and 9.1.1.10 Replacement document .
This is not a supported trigger event. Refer to Section 9.1.1.6 "Edit File" and Section 9.1.1.10 "Replace File".
9.2.1.15 Transcription:
A process of transforming dictated or otherwise documented information into an electronic format.
The process of converting oral or other forms of documented information to an electronic format.
9.3 File Management Section
This section defines the Medical Document Management (MDM) transaction set. It supports transmission of new or updated documents or information about their status(es). The trigger events and messages may be divided into two broad categories, one which describes the statuses of documents , and one which both describes the statuses and contains the document content itself.
This section defines the medical record management (MDM) processing set. It supports the transmission of new or updated files or the status of information. Trigger events and information can be divided into two categories, one describes the status of the archive, and the other describes the status of the archive while also containing the content of the archive.
The document management section is concerned primarily with the management of those documents and entries which are created as a result of a transcription process. These documents are created in two distinct contexts, one of which is related to an order and describes the procedures or activities associated with that order, and another which occurs independent of the order process. The scope of this section also includes any document that contains data derived from orders or results but which must be treated as aggregate display data due to system limitations. This is a transition strategy to support integration of data across the continuum of care.
The archive management section is mainly related to the management of archives and input items created as a result of a transcription process. These files are created into two distinct parts. One part is related to the instruction and describes the procedures or activities associated with the instruction; the occurrence of the other part is independent of the operation of the instruction. This section also includes files containing data derived from instructions or results, but due to system limitations, these instructions or results must be displayed as a set of data. This is a transition strategy to support the integration of data throughout the medical service process.
The content of a document can be represented with one or more observation segments (OBX). Where headings or separations naturally exist within the text, it is preferred that each of these blocks be represented as a separate OBX record. Where systems are able to decompose the text into separate medical concepts, the most atomic level of granularity of content should be represented, ideally with each medical concept being represented in its own OBX segment . Many of these concepts can be represented as coded entities.
The content of an archive can be represented by one or more observation report segments (OBX). Where headers or separate parts naturally exist in the text, it is preferred that each data block be represented as a separate OBX record. Where the system can decompose the text into independent medical concepts, the minimum interval unit level of the content should be conceptually represented together with each medical concept expressed in its own OBX segment. Many of these concepts can be represented as coded entities.
9.4 Assumption
Within this section, we have created a single message whose contents vary predicated on the trigger event. The following assumptions are made when the Medical Document Management (MDM) message is used:
In this section, we have established a single message whose content has essentially changed in the trigger event. When using medical record management (MDM) information, set the following assumptions:
-
The application system is responsible for meeting all legal requirements (on the local, state, and federal levels) in the areas of document authentication, confidentiality, and retention.
-
The application system is responsible for meeting all legal requirements (at the local, state, and federal level) in the areas of file authentication, confidentiality, and preservation.
-
All documents are unique, and document numbers and file names are not reused.
-
All files are unique, and the file number and file name are not reused.
-
Documents may be associated with one or more orders.
-
The file can be associated with one or more commands.
9.5 Trigger event and information definition
Each triggering event is listed below, along with the applicable form of the message exchange. The notation used to describe the sequence, optionality, and repetition of segments is described in Chapter 2, Format for Defining Abstract Messages. There are two classes of events, those which contain notifications only, and those which contain both notifications and content (text contained in OBX segments).
Each trigger event is listed below along with the application format of the information exchange. The symbols used to describe the order, optionality, and copy of segments are described in Chapter 2 "Defining the Format of Abstract Information". There are two types of events, one type only contains symbols; the other type contains both symbols and the text content in the OBX segment.
These triggering events are mainly associated with documents or entries that will be or have been transcribed. The types and appearance of the transcribed documents can vary greatly within a healthcare organization and between organizations. However, the main purpose of the transcription process is to document patient care or diagnostic results in a legible manner; these documents then become part of the legal medical record. The conceptual purpose of document notification is to facilitate updating the receiving system(s) with information from the source system(s), typically dictation or transcription systems, to indicate that an electronic document has been created or altered. The document notification message can be attached to an entire document (ie, transcribed document) or can be transmitted stand-alone. In either case,the document notification is transmitted in the form of an unsolicited update or in response to a record-oriented query. A document notification message can be created under a variety of circumstances such as when: 1) dictation has been completed; 2) a document has been transcribed; or 3) the status of a document has been changed, for example, when a document has been authenticated.
These trigger events are mainly related to files or input items that will or have been transcribed. The type and layout of transcription files can be changed within and between a medical service organization. However, the main purpose of transcription is to document the results of patient medical services or diagnosis in a clear and readable manner, and these files become part of the legal medical record. The theoretical purpose of file notification is to promote the use of information from the original data system to update the receiving system, and point out that an electronic file has been created or changed. The typical original data system is an oral or transcription system. File notification information can be attached to a physical file (for example, a transcription file) or can be transmitted independently. In either case, the file notification was sent in an unsolicited update page or responded to a record-oriented inquiry process. A file notification information can be created in a variety of environments, such as: 1) when the dictation is completed; 2) when the transcription of a file is completed; 3) when the status of a file is changed, for example, when When the file has been authenticated.
9.5.1 MDM/ACK-original file notification (event code T01)
This is a notification of the creation of a document without the accompanying content. There are multiple approaches by which systems become aware of documents:
This is an announcement of the creation of an archive that does not include accompanying content. The system perceives that the file has multiple channels.
Scenario A: A document is dictated and chart tracking system is notified that it has been dictated and is awaiting transcription.
Scenario A: Oral A file, the chart tracking system is notified that the file has been dictated and is waiting for transcription.
Scenario B: Dictation is transcribed and chart tracking system is notified that the document exists and requires authentication.
Scenario B: The dictation is transcribed, and the chart tracking system is notified that the file exists and needs to be authenticated.
Scenario C: A provider orders a series of three X-rays. The radiologist dictates a single document which covers all three orders. Multiple placer numbers are used to identify each of these orders.
Option C: The medical provider issues a series of three X-ray orders. The radiation therapist dictated a single file covering all three sheets. Use multiple setting numbers to identify the three orders separately.
MDM^T01^MDM_T01 | Original Document Notification | Chapter |
---|---|---|
Original file notice | Chapters | |
MSH | Message Header | 2 |
Information header | ||
EVN | Event Type | 3 |
Event type | ||
PID | Patient Identification | 3 |
Patient identification | ||
PV1 | Patient Visit | 3 |
Patient visits | ||
TXA | Document Notification | 9 |
File notice |
ACK^T01^ACK | General Acknowledgment | Chapter |
---|---|---|
General confirmation | Chapters | |
MSH | Message Header | 2 |
Information header | ||
MSA | Message Acknowledgment | 2 |
Information confirmed | ||
[ERR] | Error | 2 |
Error message |
9.5.2 MDM/ACK- original file announcement and content (event code T02 )
This is a notification of the creation of a document with the accompanying content.
This is an announcement of the creation of an archive with accompanying content.
Scenario A: Dictation is transcribed and the chart tracking system is notified that the document exists and requires authentication. The content of the document is transmitted along with the notification.
Plan A: Transcribe the dictation, and the chart tracking system is notified that the file exists and needs to be authenticated. The content of the file is sent along with the announcement.
Scenario B: A provider orders a series of three X-rays. The radiologist's dictation is transcribed in a single document, which covers all three orders. Multiple placer numbers are used to identify each of the orders within the single document message. The notification and document content are transmitted.
Option B: The medical provider issues a series of three X-ray orders. The dictation of the radiation therapist in a single file covering all three sheets is transcribed. Multiple setting numbers are used to respectively identify the three lists in this single file information. The content of the file is sent along with the announcement.
MDM^T02^MDM_T02 | Original Document Notification & Content | Chapter |
---|---|---|
Original file notice and content | Chapters | |
MSH | Message Header | 2 |
Information header | ||
EVN | Event Type | 3 |
Event type | ||
PID | Patient Identification | 3 |
Patient identification | ||
PV1 | Patient Visit | 3 |
Patient visits | ||
TXA | Document Notification | 9 |
File notice | ||
{ OBX } | Observation/Result (one or more required) | 9 |
Observation report/result (required one or more) |
ACK^T02^ACK | General Acknowledgment | Chapter |
---|---|---|
General confirmation | Chapters | |
MSH | Message Header | 2 |
Information header | ||
MSA | Message Acknowledgment | 2 |
Information confirmed | ||
[ERR] | Error Information | 2 |
Error message |
9.5.3 MDM/ACK-File status change notification (event code T03)
This is a notification of a change in a status of a document without the accompanying content.
This is a change notification of a certain state of a file that does not contain accompanying content.
Scenario: A document is authenticated. Notification is sent to the chart tracking system and is used to update the document status from pre-authenticated to authenticated or legally authenticated.
Solution: Identify the A file. The notification is sent to the chart tracking system and is used to update the status of the file from before authentication to completion of authentication or completion of legal authentication.
A change in any of the following independent status characteristics would cause a message to be sent:
A message will be sent to any of the following independent status changes.
- Completion Status
- finished condition
- Confidentiality Status
- Confidential status
- Availability Status (the Availability Status of cancelled is supported in T11 (document cancel notification) or T03)
- Valid status (valid status supporting "deleted" in T11 (file deletion notice) or T03)
- Storage Status
- Storage state
MDM^T03^MDM_T01 | Document Status Change Notification | Chapter |
---|---|---|
File status change notice | Chapters | |
MSH | Message Header | 2 |
Information header | ||
EVN | Event Type | 3 |
Event type | ||
PID | Patient Identification | 3 |
Patient identification | ||
PV1 | Patient Visit | 3 |
Patient visits | ||
TXA | Document Notification | 9 |
File notice |
ACK^T03^ACK | General Acknowledgment | Chapter |
---|---|---|
General confirmation | Chapters | |
MSH | Message Header | 2 |
Information header | ||
MSA | Message Acknowledgment | 2 |
Information confirmed | ||
[ERR] | Error | 2 |
Error message |
9.5.4 MDM/ACK- File status change notification and content ( event code T04)
This is a notification of a change in a status of a document with the accompanying content.
This is a change notification of a certain state of a file containing accompanying content.
Scenario: A document is authenticated. Notification is sent to the chart tracking system and is used to update the document status from pre-authenticated to authenticated or legally authenticated. The document content is also transmitted.
Solution: Identify the A file. The notification is sent to the chart tracking system and is used to update the status of the file from before authentication to completion of authentication or completion of legal authentication. The content of the file is also transmitted.
MDM^T04^MDM_T02 | Document Status Change Notification & Content | Chapter |
---|---|---|
File status change notice and content | Chapters | |
MSH | Message Header | 2 |
Information header | ||
EVN | Event Type | 3 |
Event type | ||
PID | Patient Identification | 3 |
Patient identification | ||
PV1 | Patient Visit | 3 |
Patient visits | ||
TXA | Document Notification | 9 |
File notice | ||
{OBX} | Observation/Result (one or more required) | 7 |
Observation report/result (required one or more) |
ACK^T04^ACK | General Acknowledgment | Chapter |
---|---|---|
General confirmation | Chapters | |
MSH | Message Header | 2 |
Information header | ||
MSA | Message Acknowledgment | 2 |
Information confirmed | ||
[ERR] | Error | 2 |
Error message |
9.5.5 MDM/ACK- File appendix notice (event code T05 )
This is a notification of an addendum to a document without the accompanying content.
This is an announcement of an appendix to an archive that does not contain accompanying content.
Scenario: Author dictates additional information as an addendum to a previously transcribed document. A new document is transcribed. This addendum has its own new unique document ID that is linked to the original document via the parent ID. Addendum document notification is transmitted. This creates a composite document.
Scheme: The archive producer dictates supplementary information as an appendix to a transcribed archive. Transcribe a new file. This appendix has its own new unique file ID, which is linked to the original file by the original ID. The appendix file notice was sent. This creates a composite file.
MDM^T05^MDM_T01 | Document Addendum Notification | Chapter |
---|---|---|
File appendix notice | Chapters | |
MSH | Message Header | 2 |
Information header | ||
EVN | Event Type | 3 |
Event type | ||
PID | Patient Identification | 3 |
Patient identification | ||
PV1 | Patient Visit | 3 |
Patient visits | ||
TXA | Document Notification | 9 |
File notice |
ACK^T05^ACK | General Acknowledgment | Chapter |
---|---|---|
General confirmation | Chapters | |
MSH | Message Header | 2 |
Information header | ||
MSA | Message Acknowledgment | 2 |
Information confirmed | ||
[ERR] | Error | 2 |
Error message |
9.5.6 MDM/ACK- File appendix notice and content ( event code T06)
This is a notification of an addendum to a document with the accompanying content.
This is an announcement of an appendix to an archive containing accompanying content.
Scenario: Author dictates additional information as an addendum to a previously transcribed document. A new document is transcribed. This addendum has its own new unique document ID that is linked to the original document via the parent ID. Addendum document notification is transmitted, along with the document content. This creates a composite document.
Scheme: The archive producer dictates supplementary information as an appendix to a transcribed archive. Transcribe a new file. This appendix has its own new unique file ID, which is linked to the original file by the original ID. The appendix file notice is sent along with the file content. This creates a composite file.
MDM^T06^MDM_T02 | Document Addendum Notification & Content | Chapter |
---|---|---|
File appendix notice and content | Chapters | |
MSH | Message Header | 2 |
Information header | ||
EVN | Event Type | 3 |
Event type | ||
PID | Patient Identification | 3 |
Patient identification | ||
PV1 | Patient Visit | 3 |
Patient visits | ||
TXA | Document Notification | 9 |
File notice | ||
{OBX} | Observation/Result (one or more required) | 7 |
Observation report/result (required one or more) |
ACK^T06^ACK | General Acknowledgment | Chapter |
---|---|---|
General confirmation | Chapters | |
MSH | Message Header | 2 |
Information header | ||
MSA | Message Acknowledgment | 2 |
Information confirmed | ||
[ERR] | Error | 2 |
Error message |
9.5.7 MDM/ACK- File edit notification ( event code T07)
Note: The only valid use of this trigger event is for documents whose availability status is Unavailable, ie, the document has not been made available for patient care.
Note: The only valid application of this trigger event is when the valid status of the file is "invalid", for example, the file is invalid for the patient's medical service.
This is a notification of an edit to a document without the accompanying content.
This is a notice to edit a file that does not contain accompanying content.
Scenario: Errors, which need to be corrected, are discovered in a document. The original document is edited, and an edit notification is sent.
Solution: Find errors that need to be corrected in a file. Edit the original file and send an edit notice.
MDM^T07^MDM_T01 | Document Edit Notification | Chapter |
---|---|---|
File edit notice | Chapters | |
MSH | Message Header | 2 |
Information header | ||
EVN | Event Type | 3 |
Event type | ||
PID | Patient Identification | 3 |
Patient identification | ||
PV1 | Patient Visit | 3 |
Patient visits | ||
TXA | Document Notification | 9 |
File notice |
ACK^T07^ACK | General Acknowledgment | Chapter |
---|---|---|
General confirmation | Chapters | |
MSH | Message Header | 2 |
Information header | ||
MSA | Message Acknowledgment | 2 |
Information confirmed | ||
[ERR] | Error | 2 |
Error message |
9.5.8 MDM/ACK- File edit notice and content ( event code T08)
Note : The only valid use of this trigger event is for documents whose availability status is "Unavailable," ie, the document has not been made available for patient care.
Note: The only valid application of this trigger event is when the valid status of the file is "invalid", for example, the file is invalid for the patient's medical service.
This is a notification of an edit to a document with the accompanying content.
This is a notice to edit a file containing accompanying content.
Scenario: Errors, which need to be corrected, are discovered in a document. The original document is edited, and an edit notification and document content are sent.
Solution: Find errors that need to be corrected in a file. Edit the original file and send the edit notice and file content.
MDM^T08^MDM_T02 | Document Edit Notification & Content | Chapter |
---|---|---|
File edit notice and content | Chapters | |
MSH | Message Header | 2 |
Information header | ||
EVN | Event Type | 3 |
Event type | ||
PID | Patient Identification | 3 |
Patient identification | ||
PV1 | Patient Visit | 3 |
Patient visits | ||
TXA | Document Notification | 9 |
File notice | ||
{OBX} | Observation/Result (one or more required) | 7 |
Observation report/result (required one or more) |
ACK^T08^ACK | General Acknowledgment | Chapter |
---|---|---|
General confirmation | Chapters | |
MSH | Message Header | 2 |
Information header | ||
MSA | Message Acknowledgment | 2 |
Information confirmed | ||
[ERR] | Error | 2 |
Error message |
9.5.9 MDM/ACK- File replacement notification (event code T09 )
Note : This trigger event is generally used when the original document availability status is Available.
Note : This trigger event is usually used when the valid status of the original file is "valid".
This is a notification of replacement to a document without the accompanying content.
This is a notice to replace a file that does not contain accompanying content.
Scenario: Errors discovered in a document are corrected. The original document is replaced with the revised document. The replacement document has its own new unique document ID that is linked to the original document via the parent ID. The availability status of the original document is changed to Obsolete but the original document should be retained in the system for historical reference. Document replacement notification is sent.
Solution: Correct the errors found in an archive. The original file is replaced by the modified file. The replacement file has its own new and unique file ID, which is linked to the original file by the original ID. The effective status of the original file is changed to "abandoned", but the original file should be kept in the system for historical reference. The file replacement notice is sent.
MDM^T09^MDM_T01 | Document Replacement Notification | Chapter |
---|---|---|
File replacement notice | Chapters | |
MSH | Message Header | 2 |
Information header | ||
EVN | Event Type | 3 |
Event type | ||
PID | Patient Identification | 3 |
Patient identification | ||
PV1 | Patient Visit | 3 |
Patient visits | ||
TXA | Document Notification | 9 |
File notice |
ACK^T09^ACK | General Acknowledgment | Chapter |
---|---|---|
General confirmation | Chapters | |
MSH | Message Header | 2 |
Information header | ||
MSA | Message Acknowledgment | 2 |
Information confirmed | ||
[ERR] | Error | 2 |
Error message |
9.5.10 MDM/ACK- File replacement notice and content (event code T10 )
Scenario: Errors discovered in a document are corrected. The original document is replaced with the revised document. The replacement document has its own new unique document ID that is linked to the original document via the parent ID. The availability status of the original document is changed to Obsolete but the original document should be retained in the system for historical reference. Document replacement notification and document content are sent.
Solution: Correct the errors found in an archive. The original file is replaced by the modified file. The replacement file has its own new and unique file ID, which is linked to the original file by the original ID. The effective status of the original file is changed to "abandoned", but the original file should be kept in the system for historical reference. The file replacement notice and the file content are sent.
MDM^T10^MDM_T02 | Document Replacement Notification & Content | Chapter |
---|---|---|
File replacement notice and content | Chapters | |
MSH | Message Header | 2 |
Information header | ||
EVN | Event Type | 3 |
Event type | ||
PID | Patient Identification | 3 |
Patient identification | ||
PV1 | Patient Visit | 3 |
Patient visits | ||
TXA | Document Notification | 9 |
File notice | ||
{OBX} | Observation/Result (one or more required) | 7 |
Observation report/result (required one or more) |
ACK^T10^ACK | General Acknowledgment | Chapter |
---|---|---|
General confirmation | Chapters | |
MSH | Message Header | 2 |
Information header | ||
MSA | Message Acknowledgment | 2 |
Information confirmed | ||
[ERR] | Error | 2 |
Error message |
9.5.11 MDM/ACK- File deletion notification (event code T11 )
This is a notification of a cancellation of a document. This trigger event should be used only for an original document with an availability status of Unavailable. When a document has been made available for patient care, the process should be to replace the original document, which then becomes obsolete. The replacement document describes why the erroneous information exists.
This is a notice of file deletion. This trigger event should only be used for an original file whose valid status is "invalid". When a file has become effective for the patient s medical services, the process will replace the original file and the original file will be invalidated. The replacement file describes the reason for the error message.
Scenario: When the author dictated a document, the wrong patient identification was given, and the document was transcribed and sent to the wrong patient's record. When the error is discovered, a cancellation notice is sent to remove the document from general access in the wrong patient's record. In these cases, a reason should be supplied in the cancellation message. To protect patient privacy, the correct patient's identifying information should not be placed on the erroneous document that is retained in the wrong patient's record for historical reference. A new document notification and content will be created using a T02 (original document notification and content) event and sent for association with the correct patient's record.
Scenario: When the file maker dictated a file and gave the wrong patient identifier, the file was transcribed and sent to the wrong patient record. When this error is discovered, a deletion notice is sent to delete the files in the wrong patient record through the conventional means. In order to protect the privacy of patients, the correct patient identification information should not be placed in the wrong file, that is, it is still kept in the wrong patient record for historical reference. A new file notice and content will be created using event code T02 (original file notice and content) and will be linked to the correct patient record.
MDM^T11^MDM_T01 | Document Cancel Notification | Chapter |
---|---|---|
File deletion notice | Chapters | |
MSH | Message Header | 2 |
Information header | ||
EVN | Event Type | 3 |
Event type | ||
PID | Patient Identification | 3 |
Patient identification | ||
PV1 | Patient Visit | 3 |
Patient visits | ||
TXA | Document Notification | 9 |
File notice |
ACK^T11^ACK | General Acknowledgment | Chapter |
---|---|---|
General confirmation | Chapters | |
MSH | Message Header | 2 |
Information header | ||
MSA | Message Acknowledgment | 2 |
Information confirmed | ||
[ERR] | Error | 2 |
Error message |
9.6 Information segment
-
-
- TXA -transcription document header segment
-
9.6.1 TXA-Transcribe file header section
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 is used to update other healthcare systems 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.
The TXA segment contains information that is limited to a transcribed file, but does not include the text of the file. This information is created as a result of the status change of an archive. This information is used to update other medical service systems to identify valid reports in the transcription system. By retaining TXA information in these systems, it can be used when all the archive text is needed to construct the interrogation program for the transcription system.
HL7 Attribute Table TXA Transcription Document Header
HL7 attribute table-TXA-Transcription file title
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME |
---|---|---|---|---|---|---|---|
Ingredient name | |||||||
1 | 4 | SI | R | 00914 | Set ID- TXA | ||
Set ID- TXA | |||||||
2 | 30 | IS | R | 0270 | 00915 | Document Type | |
File type | |||||||
3 | 2 | ID | C | 0191 | 00916 | Document Content Presentation | |
File content statement | |||||||
4 | 26 | TS | O | 00917 | Activity Date/Time | ||
Event date/time | |||||||
5 | 250 | XCN | C | Y | 00918 | Primary Activity Provider Code/Name | |
Main event provider code/name | |||||||
6 | 26 | TS | O | 00919 | Origination Date/Time | ||
Creation date/time | |||||||
7 | 26 | TS | C | 00920 | Transcription Date/Time | ||
Transcription date/time | |||||||
8 | 26 | TS | O | Y | 00921 | Edit Date/Time | |
Edit date/time | |||||||
9 | 250 | XCN | O | Y | 00922 | Originator Code/Name | |
Creator code/name | |||||||
10 | 250 | XCN | O | Y | 00923 | Assigned Document Authenticator | |
Designated file authenticator | |||||||
11 | 250 | XCN | C | Y | 00924 | Transcriptionist Code/Name | |
Transcriber code/name | |||||||
12 | 30 | EI | R | 00925 | Unique Document Number | ||
Unique file number | |||||||
13 | 30 | EI | C | 00926 | Parent Document Number | ||
Original file number | |||||||
14 | 22 | EI | O | Y | 00216 | Placer Order Number | |
Placer instruction number | |||||||
15 | 22 | EI | O | 00217 | Filler Order Number | ||
Filler instruction number | |||||||
16 | 30 | ST | O | 00927 | Unique Document File Name | ||
Unique archive file name | |||||||
17 | 2 | ID | R | 0271 | 00928 | Document Completion Status | |
File completion status | |||||||
18 | 2 | ID | O | 0272 | 00929 | Document Confidentiality Status | |
File confidential status | |||||||
19 | 2 | ID | O | 0273 | 00930 | Document Availability Status | |
File valid status | |||||||
20 | 2 | ID | O | 0275 | 00932 | Document Storage Status | |
Archive storage status | |||||||
21 | 30 | ST | C | 00933 | Document Change Reason | ||
Reason for file change | |||||||
22 | 250 | PPN | C | Y | 00934 | Authentication Person, Time Stamp | |
Discriminator, time stamp | |||||||
23 | 250 | XCN | O | Y | 00935 | Distributed Copies (Code and Name of Recipients) | |
Distribution of copies (code and name of recipient) |
9.6.1.0 TXA field definition
-
-
-
- TXA-1 Set ID-TXA (SI) 00914
-
-
9.6.1.1 TXA-1 Set ID-TXA (SI) 00914
Definition: This field contains a number that uniquely identifies this transaction for the purpose of adding, changing, or deleting the transaction.
Definition: This field contains a number that uniquely identifies the addition, change, or deletion of this processing item.
-
-
-
- TXA-2 Document type (IS) 00915
-
-
9.6.1.2 TXA-2 File Type (IS) 00915
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.
Definition: This field identifies the type of archive (the same as defined in the transcription system). For related recommended values, please refer to User Definition Table 0270- File Type . Institutions are free to add more projects.
User-defined Table 0270 Document type
User Defined Form 0270-File Type
Value | Description |
---|---|
value | description |
AR | Autopsy report |
Autopsy report | |
CD | Cardiodiagnostics |
Cardiac diagnosis | |
CN | Consultation |
consultation | |
DI | Diagnostic imaging |
Diagnostic imaging | |
DS | Discharge summary |
Summary | |
ED | Emergency department report |
Emergency department report | |
HP | History and physical examination |
Medical records and physical examination | |
OP | Operative report |
Surgical report | |
PC | Psychiatric consultation |
Psychiatric Treatment Consultation | |
PH | Psychiatric history and physical examination |
Psychiatric history and physical examination | |
PN | Procedure note |
Program notes | |
PR | Progress note |
Progress notes | |
SP | Surgical pathology |
Surgical Pathology | |
TS | Transfer summary |
Summary of Transfer |
-
-
-
- TXA-3 Document content presentation (ID) 00916
-
-
9.6.1.3 TXA-3 File Content Statement (ID) 00916
Definition: This is a conditional field which is required whenever the message contains content as presented in one or more OBX. 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 is a conditional field. As long as the information contains one or more OBX segments, this field is required. This field identifies the method of obtaining or creating this file. Please refer to HL7 table 0191- valid values for the type of data referenced .
HL7 Table 0191-Type of referenced data
HL7 Form 0191-Type of data referenced
Value | Description |
---|---|
value | description |
AP | Other application data, typically uninterpreted binary data (HL7 V2.3 and later) |
Other application data, typical non-interpreted binary data (HL7 V2.3 and later versions) | |
AU | Audio data (HL7 V2.3 and later) |
Audio data (HL7 V2.3 and later versions) | |
FT | Formatted text (HL7 V2.2 only) |
Formatted text (HL7 V2.2 version only) | |
IM | Image data (HL7 V2.3 and later) |
Image data (HL7 V2.3 and later versions) | |
multipart | MIME multipart package |
MIME package | |
NS | Non-scanned image (HL7 V2.2 only) |
Unscanned image (HL7 V2.2 version only) | |
SD | Scanned document (HL7 V2.2 only) |
Scanned documents (HL7 V2.2 version only) | |
SI | Scanned image (HL7 V2.2 only) |
Scanned image (HL7 V2.2 version only) | |
TEXT | Machine readable text document (HL7 V2.3.1 and later) |
Machine-readable text documents (HL7 V2.3.1 and later versions) | |
TX | Machine readable text document (HL7 V2.2 only) |
Machine-readable text document (HL7 V2.2 version only) |
-
-
-
- TXA-4 Activity date/time (TS) 00917
-
-
9.6.1.4 TXA-4 Event Date/Time (TS) 00917
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 date/time identified in the archive as the date on which a procedure or activity was performed. This date can identify the date of surgery, non-proliferation procedures, consultations, and clinical examinations.
-
-
-
- TXA-5 Primary activity provider code/name (XCN) 00918
-
-
9.6.1.5 TXA-5 Main Event Provider Code/Name (XCN) 00918
Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second and further given names or initials thereof ( ST)> ^ <suffix (eg, JR or III) (ST)> ^ <prefix (eg, DR) (ST)> ^ <degree (eg, MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <name assembly order (ID)>
Composition: In 2.3 and later versions, replace the CN data type. <ID number (ST)> ^<Last name (FN)> ^ <First name (ST)> ^ <2.and other names or capital letters in the first name (ST)> ^ <Suffix (e.g. JR or III) (ST)> ^Prefix (e.g., DR) (ST)> ^ <Degree (e.g., Master) (IS)> ^ <Original Data Sheet (IS)> ^ <Authorization Certificate (HD)> ^ ****< Name Type Code (ID)> ^<Check Digit Identifier (ST)> ^ <Code to identify the adopted check digit scheme (ID)> ^ <Type Code Identifier (IS)> ^ <Designated Facilities (HD )> ^ <Name Representative Code (ID)> ^ <Name Environment (CE)> ^ <Name Valid Range (DR)> ^ <Name Assembly Order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
The composition of the authorization certificate: <site name ID (IS)> & <common ID (ST)> & <common ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Composition of designated facilities: <Place name ID (IS)> & <Universal ID (ST)> & <Universal ID type (ID)>
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 name of the person who is responsible for performing the procedure or activity identified in the file. This field includes the code and name (if valid) of the medical provider. The conditions established in this field are based on the existence of a certain value in TXA-4- Activity Date/ Time .
-
-
-
- TXA-6 Origination date/time (TS) 00919
-
-
9.6.1.6 TXA-6 Creation Date/Time (TS) 00919
Definition: This field contains the date and time the document was created (ie, dictated, recorded, etc.).
Definition: This field contains the date and time the archive was created (such as: dictation, recording, etc.).
-
-
-
- TXA-7 Transcription date/time (TS) 00920
-
-
9.6.1.7 TXA-7 Transcription Date/Time (TS) 00920
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 input was effectively transcribed. This field is conditionally established on the basis of the existence of a certain value in TXA-17- file completion status other than "dictation" .
-
-
-
- TXA-8 Edit date/time (TS) 00921
-
-
9.6.1.8 TXA-8 Edit Date/Time (TS) 00921
Definition: This field contains the date and time the document was edited.
Definition: This field contains the date and time when the file was edited.
-
-
-
- TXA-9 Originator code/name (XCN) 00922
-
-
9.6.1.9 TXA-9 Creator Code/Name (XCN) 00922
Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second and further given names or initials thereof ( ST)> ^ <suffix (eg, JR or III) (ST)> ^ <prefix (eg, DR) (ST)> ^ <degree (eg, MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <name assembly order (ID)>
Composition: In 2.3 and later versions, replace the CN data type. <ID number (ST)> ^<Last name (FN)> ^ <First name (ST)> ^ <2.and other names or capital letters in the first name (ST)> ^ <Suffix (e.g. JR or III) (ST)> ^Prefix (e.g., DR) (ST)> ^ <Degree (e.g., Master) (IS)> ^ <Original Data Sheet (IS)> ^ <Authorization Certificate (HD)> ^ ****< Name Type Code (ID)> ^<Check Digit Identifier (ST)> ^ <Code to identify the adopted check digit scheme (ID)> ^ <Type Code Identifier (IS)> ^ <Designated Facilities (HD )> ^ <Name Representative Code (ID)> ^ <Name Environment (CE)> ^ <Name Valid Range (DR)> ^ <Name Assembly Order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
The composition of the authorization certificate: <site name ID (IS)> & <common ID (ST)> & <common ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Composition of designated facilities: <Place name ID (IS)> & <Universal ID (ST)> & <Universal ID type (ID)>
Definition: This field identifies the person who originated (ie, dictated) the document. The document originator may differ from the person responsible for authenticating the document.
Definition: This field identifies the person who created the archive (eg dictation). The creator of the profile can be different from the person responsible for identifying the profile.
-
-
-
- TXA-10 Assigned document authenticator (XCN) 00923
-
-
9.6.1.10 File authenticator (XCN) designated by TXA-10 00923
Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second and further given names or initials thereof ( ST)> ^ <suffix (eg, JR or III) (ST)> ^ <prefix (eg, DR) (ST)> ^ <degree (eg, MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <name assembly order (ID)>
Composition: In 2.3 and later versions, replace the CN data type. <ID number (ST)> ^<Last name (FN)> ^ <First name (ST)> ^ <2.and other names or capital letters in the first name (ST)> ^ <Suffix (e.g. JR or III) (ST)> ^Prefix (e.g., DR) (ST)> ^ <Degree (e.g., Master) (IS)> ^ <Original Data Sheet (IS)> ^ <Authorization Certificate (HD)> ^ ****< Name Type Code (ID)> ^<Check Digit Identifier (ST)> ^ <Code to identify the adopted check digit scheme (ID)> ^ <Type Code Identifier (IS)> ^ <Designated Facilities (HD )> ^ <Name Representative Code (ID)> ^ <Name Environment (CE)> ^ <Name Valid Range (DR)> ^ <Name Assembly Order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
The composition of the authorization certificate: <site name ID (IS)> & <common ID (ST)> & <common ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Composition of designated facilities: <Place name ID (IS)> & <Universal ID (ST)> & <Universal ID type (ID)>
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 responsible for identifying the file. This person can be different from the person who created the file. There can be multiple people responsible for identification, especially in teaching institutions. Undefined numbers that allow this field to be repeated a number of times.
-
-
-
- TXA-11 Transcriptionist code/name (XCN) 00924
-
-
9.6.1.11 TXA-11 transcriber code/name (XCN) 00924
Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second and further given names or initials thereof ( ST)> ^ <suffix (eg, JR or III) (ST)> ^ <prefix (eg, DR) (ST)> ^ <degree (eg, MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <name assembly order (ID)>
Composition: In 2.3 and later versions, replace the CN data type. <ID number (ST)> ^<Last name (FN)> ^ <First name (ST)> ^ <2.and other names or capital letters in the first name (ST)> ^ <Suffix (e.g. JR or III) (ST)> ^Prefix (e.g., DR) (ST)> ^ <Degree (e.g., Master) (IS)> ^ <Original Data Sheet (IS)> ^ <Authorization Certificate (HD)> ^ ****< Name Type Code (ID)> ^<Check Digit Identifier (ST)> ^ <Code to identify the adopted check digit scheme (ID)> ^ <Type Code Identifier (IS)> ^ <Designated Facilities (HD )> ^ <Name Representative Code (ID)> ^ <Name Environment (CE)> ^ <Name Valid Range (DR)> ^ <Name Assembly Order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
The composition of the authorization certificate: <site name ID (IS)> & <common ID (ST)> & <common ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Composition of designated facilities: <Place name ID (IS)> & <Universal ID (ST)> & <Universal ID type (ID)>
Definition: This field identifies the person transcribing the document. This is a conditional value; it is required on all transcribed documents.
Definition: This field identifies the person who transcribed the archive. This is a conditional value and is required in all files that are transcribed.
-
-
-
- TXA-12 Unique document number (EI) 00925
-
-
9.6.1.12 TXA-12 unique file number (EI) 00925
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (st)> ^ <universal ID type (ID)>
Composition: <Entity Identifier (ST)> ^ <Place Name ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>
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 2, Section 2.9.55, 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 unique file identification number assigned by the sending system. This file number is used to assist the receiving system to match future updates to the file and to identify the file in an interrogation process. When the vendor does not provide a unique archive ID number, certain types of archive identifiers should be entered here, or a unique archive file name should be used. See Chapter 2, Section 2.9.55 "XTN-Extended Electrical Signal?". Usually where the system does not have a file fill symbol code, this number can also be used as that value.
-
-
-
- TXA-13 Parent document number (EI) 00926
-
-
9.6.1.13 TXA-13 Original File Number (EI) 00926
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>
Composition: <Entity Identifier (ST)> ^ <Place Name ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>
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: This field contains an archive number that identifies the original archive of the archive. The original file number can be used to assist the receiving system to match future updates to the file. This is a conditional field. This field is always required in event codes T05 (Archive appendix notice), T06 (Archive appendix notice and content), T09 (Archive replacement notice), and T10 (Archive replacement notice and content).
-
-
-
- TXA-14 Placer order number (EI) 00216
-
-
9.6.1.14 TXA-14 Placer instruction number (EI) 00216
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>
Composition: <Entity Identifier (ST)> ^ <Place Name ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>
Definition: This field is the placer application's order number.
Definition: This field is the instruction number of the placer application.
This is a composite field. The first component is a string of characters that identifies an individual order (eg, 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.
This is a compound field. The first component is a string of characters (such as OBR) that identifies a single command. It is specified by the placer (instruction application). It uniquely identifies an instruction from all instructions in a particular instruction application program. The second to fourth components include assignment permissions (fillers) for placing applications. Assignment permission (filler) is the only string of characters connected to an application. The organization should establish a unique list of applications that can be potential placers, fillers, and designated unique entity identifiers. These components are separated by component separators.
-
-
-
- TXA-15 Filler order number (EI) 00217
-
-
9.6.1.15 TXA-15 Filler Command Number (EI) 00217
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>
Composition: <Entity Identifier (ST)> ^ <Place Name ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>
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 (eg, OBR). This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (eg, 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.
Definition: This field is the instruction number connected to the filling application. Where transcription services or similar organizations create files and use an internally unique identifier, the number should be inserted in this field. Its first component is a string of characters that identifies an instruction detail section (such as OBR). This string of characters must uniquely identify the instruction (as specified in the instruction details section) from other instructions in a special filling application (such as: transcription service). The uniqueness must last over time. Where a number is used overtime again, attach a date 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.
The second to fourth components include assignment permissions (fillers). The assignment permission (filler) is a string of characters that uniquely defines an application in other applications on the network. The second to fourth components of the filler instruction number always identify the current filler of an instruction.
For further details, please see the definitions provided in Chapter 4.
Please refer to the definitions provided in Chapter 4 for more detailed information.
-
-
-
- TXA-16 Unique document file name (ST) 00927
-
-
9.6.1.16 TXA-16 unique archive file name (ST) 00927
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 contains a unique name for the archive specified by the sending system. The file name is used to assist the receiving system to match future updates to the file.
-
-
-
- TXA-17 Document completion status (ID) 00928
-
-
9.6.1.17 TXA-17 file completion status (ID) 00928
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.
Definition: This field identifies the current completion status of the archive. This is a required field. Please refer to HL7 table 0271- valid value of file completion status .
HL7 Table 0271-Document completion status
HL7 Form 0271-File Completion Status
Value | Description |
---|---|
value | description |
DI | Dictated |
Complete dictation | |
DO | Documented |
Complete filing | |
IP | In Progress |
In operation | |
IN | Incomplete |
undone | |
PA | Pre-authenticated |
Before identification | |
AU | Authenticated |
Complete identification | |
LA | Legally authenticated |
Complete legal authentication |
Figure 9-1. Document completion status state transition table
Figure 9-1. State transition table of file completion state
Transition (Action) | Old State | New State |
---|---|---|
Conversion (method) | Old state | New state |
T01 Original Notification T01 Original Notification and Content T02 Original Notification and Content T01 Original Notification and Content | NA | Dictated completes the dictation In Progress operation, Incomplete does not complete Pre-authenticated authentication, Authenticated completes authentication before Legally authenticated completes legal authentication |
T03 Status Change Notification T03 Status Change Notification and Content T04 Status Change Notification and Content T04 Status Change Notification and Content | Dictated complete dictation | In the In Progress operation, the Incomplete did not complete the Pre-authenticated authentication before the Authenticated completes the authentication, the Legally authenticated completes the legal authentication |
In Progress | Incomplete, Pre-authenticated, Authenticated before, Legally authenticated, Legally authenticated | |
Incomplete | Pre-authenticated Authenticated completes authentication before authentication Legally authenticated completes legal authentication | |
Before pre-authenticated | Authenticated completes authentication Legally authenticated completes legal authentication | |
Authenticated | Legally authenticated complete legally authenticated | |
Legally authenticated complete legally authenticated | NA | |
Documented completes the documentation | Pre-authenticated Authenticated completes authentication before authentication Legally authenticated completes legal authentication | |
T05 Addendum Notification T05 Addendum Notification and Content T06 Addendum Notification and Content T06 Addendum Notification and Content T06 Addendum Notification and Content | NA | Dictated completes the dictation In Progress operation, Incomplete does not complete Pre-authenticated authentication, Authenticated completes authentication before Legally authenticated completes legal authentication |
T07 Edit Notification T07 Edit Notification and Content T08 Edit Notification and Content T08 Edit Notification and Content | Dictated complete dictation | In the In Progress operation, the Incomplete did not complete the Pre-authenticated authentication before the Authenticated completes the authentication, the Legally authenticated completes the legal authentication |
In Progress | Incomplete, Pre-authenticated, Authenticated before, Legally authenticated, Legally authenticated | |
Incomplete | Pre-authenticated Authenticated completes authentication before authentication Legally authenticated completes legal authentication | |
Before pre-authenticated | Authenticated completes authentication Legally authenticated completes legal authentication | |
Authenticated | Legally authenticated complete legally authenticated | |
Legally authenticated complete legally authenticated | NA | |
Documented completes the documentation | Pre-authenticated Authenticated completes authentication before authentication Legally authenticated completes legal authentication | |
T09 Replacement Notification T09 Replacement Notification and Content T10 Replacement Notification and Content T10 Replacement Notification and Content | NA | Dictated completes the dictation In Progress operation, Incomplete does not complete Pre-authenticated authentication, Authenticated completes authentication before Legally authenticated completes legal authentication |
T11 Cancel Notification | Dictated completes the dictation of the In Progress operation, Incomplete does not complete the Pre-authenticated and Availability status of "Unavailable" and "Invalid" | Canceled |
Note : NA means not applicable. Document confidentiality status (ID) 00929
Note : NA means not applicable. File confidential status (ID) 00929
-
-
-
- TXA-18 Document confidentiality status (ID) 00929
-
-
9.6.1.18 TXA-18 File Confidential Status (ID) 00929
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 that identifies the specific level of confidentiality protection that information should be protected. It is up to the medical service organization to determine the designation of these types of data elements. Please refer to HL7 Table 0272- Valid Values of File Confidentiality Status .
HL7 Table 0272-Document confidentiality status
HL7 Form 0272-File Confidentiality Status
Value | Description |
---|---|
value | description |
V | Very restricted |
Very confidential | |
R | Restricted |
confidential | |
U | Usual control |
General control |
-
-
-
- TXA-19 Document availability status (ID) 00930
-
-
9.6.1.19 TXA-19 file valid status (ID) 00930
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 toHL7 table 0273-Document availability status for valid values.
Definition: This is an optional field that identifies the effectiveness of a file for patient medical services. If an organization's operating rules allow a file to be used for patient medical services before being authenticated, the value of this field should be set to "AV" at this time. If a file has been set up and is effective for the patient's medical services, the file cannot be changed or deleted. If a wrong file has been set up as valid and the replacement file is not applicable, as in the case where the file is assigned to the wrong patient, the file can be marked as "deleted" and deleted. Additional information must be provided through an appendix file which is individually identified and date/time stamped. If it is necessary to modify the content of an archive whose status is marked as "valid", this is done by sending a replacement archive, which is individually identified and date/time stamped. Please refer to HL7 Table 0273- Valid Value of File Validity Status .
HL7 Table 0273-Document availability status
HL7 Form 0273-File Valid Status
Value | Description |
---|---|
value | description |
AV | Available for patient care |
Effective for patient medical treatment | |
CA | Deleted |
delete | |
OB | Obsolete |
Abandoned | |
UN | Unavailable for patient care |
Medically ineffective for patients |
Figure 9-2. Document availability status state transition table
Chart 9-2. The state transition table of the effective state of the file
Transition (Action) | Old State | New State | Notes |
---|---|---|---|
Conversion (method) | Old state | New state | note |
T01 Original Notification T01 Original Notification and Content T02 Original Notification and Content T02 Original Notification and Content | NA | Unavailable invalid Available valid | |
T03 Status Change Notification T03 Status Change Notification and Content T04 Status Change Notification and Content T04 Status Change Notification and Content | Unavailable invalid | Unavailable invalid Available valid Obsolete obsolete | |
Available valid | Available valid Obsolete obsolete | ||
Obsolete obsolete | NA | ||
T05 Addendum Notification T05 Addendum Notification and Content T06 Addendum Notification and Content T06 Addendum Notification and Content T06 Addendum Notification and Content | NA | Unavailable invalid Available valid | |
T07 Edit Notification T07 Edit Notification and Content T08 Edit Notification and Content T08 Edit Notification and Content | Unavailable invalid | Unavailable invalid Available valid | |
T09 Replacement Notification T09 Replacement Notification and Content T10 Replacement Notification and Content T10 Replacement Notification and Content | NA | Unavailable invalid Available valid | Set parent document to "obsolete" |
T11 Cancel T11 delete | Unavailable invalid | Delete |
Note : NA means not applicable.
Note: NA means not applicable.
-
-
-
- TXA-20 Document storage status (ID) 00932
-
-
9.6.1.20 TXA-20 file storage status (ID) 00932
Definition: This optional field identifies the storage status of the document. Refer to HL7 table 0275-Document storage status for valid values.
Definition: This optional field identifies the storage state of the document. Please refer to HL7 Table 0275- Valid Values of File Storage Status .
HL7 Table 0275-Document storage status
HL7 Form 0275-Archive Storage Status
Value | Description |
---|---|
value | description |
AC | Active |
current | |
AA | Active and archived |
Current and archived | |
AR | Archived (not active) |
Archived (not current) | |
PU | Purged |
Clear |
-
-
-
- TXA-21 Document change reason (ST) 00933
-
-
9.6.1.21 TXA-21 File Change Reason (ST) 00933
Definition: This free text field (limited to 30 characters) contains the reason for document status change.
Definition: This free text field (limited to 30 characters) contains the reason for the document status change.
-
-
-
- TXA-22 Authentication person, time stamp (set) (PPN) 00934
-
-
9.6.1.22 TXA-22 Authenticator, time stamp (setup) (PPN) 00934
Components: <ID number (ST)> ^ <family name (FN)> ^ <given name (ST) ^ <second and further given names or initials thereof (ST)>^ <suffix (eg, JR or III) (ST )> ^ <prefix (eg, DR) (ST)> ^ <degree (eg, MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code(ID) > ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID )> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <date/time action performed (TS) > ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <name assembly order (ID)>
Composition: In 2.3 and later versions, replace the CN data type. <ID number (ST)> ^<Last name (FN)> ^ <First name (ST)> ^ <2.and other names or capital letters in the first name (ST)> ^ <Suffix (e.g. JR or III) (ST)> ^Prefix (e.g., DR) (ST)> ^ <Degree (e.g., Master) (IS)> ^ <Original Data Sheet (IS)> ^ <Authorization Certificate (HD)> ^ ****< Name Type Code (ID)> ^<Check Digit Identifier (ST)> ^ <Code to identify the adopted check digit scheme (ID)> ^ <Type Code Identifier (IS)> ^ <Designated Facilities (HD )> ^ <Name Representative Code (ID)> ^ <Name Environment (CE)> ^ <Name Valid Range (DR)> ^ <Name Assembly Order (ID)>
Definition: This is a conditional field. When the status of TXA-17-Document completion status is equal to AU (authenticated) or LA (legally authenticated), all components are required. This field contains a set of components describing by whom and when authentication was performed. Whenever any one of the ID number-Name type code components is valued, the when authenticated component, which is time stamp, must be valued as non-null. If the time component of a set is valued as non-null , the person component becomes required. These subcomponents are normally delimited by an ampersand (&). See Chapter 2.
Definition: This is a conditional field. When the status of TXA-17- file completion status is the same as AU (authentication completed) or LA (authentication completed legally), all components are required. This field contains a group of components that describe the person and time when the authentication is performed. As long as any code component of ID number and name type is assigned, when to identify the component, and time stamp, it must be assigned a non-zero value. If the time component set is assigned a non-zero value, the personnel component is required. These sub-components are usually bounded by signs (&). See Chapter 2.
9.6.1.22.1 Identifier (composition) (XCN)
Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second and further given names or initials thereof ( ST)> ^ <suffix (eg, JR or III) (ST)> ^ <prefix (eg, DR) (ST)> ^ <degree (eg, MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <name assembly order (ID)>
Composition: In 2.3 and later versions, replace the CN data type. <ID number (ST)> ^<Last name (FN)> ^ <First name (ST)> ^ <2.and other names or capital letters in the first name (ST)> ^ <Suffix (e.g. JR or III) (ST)> ^Prefix (e.g., DR) (ST)> ^ <Degree (e.g., Master) (IS)> ^ <Original Data Sheet (IS)> ^ <Authorization Certificate (HD)> ^ ****< Name Type Code (ID)> ^<Check Digit Identifier (ST)> ^ <Code to identify the adopted check digit scheme (ID)> ^ <Type Code Identifier (IS)> ^ <Designated Facilities (HD )> ^ <Name Representative Code (ID)> ^ <Name Environment (CE)> ^ <Name Valid Range (DR)> ^ <Name Assembly Order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
The composition of the authorization certificate: <site name ID (IS)> & <common ID (ST)> & <common ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Composition of designated facilities: <Place name ID (IS)> & <Universal ID (ST)> & <Universal ID type (ID)>
Definition: This component identifies the person who has authenticated the document (either manually or electronically).
Definition: This component identifies the person who authenticates the file (either handwritten or electronically).
9.6.1.22.2 Identification time stamp (composition) (TS)
Definition: This component contains the date and time the document was authenticated (either manually or electronically).
Definition: This component contains the date and time (either handwritten or electronically) when the file was identified.
-
-
-
- TXA-23 Distributed copies (XCN) 00935
-
-
9.6.1.23 Distribution of copies of TXA-23 (XCN) 00935
Components: In Version 2.3 and later, use instead of the CN data type. <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second and further given names or initials thereof ( ST)> ^ <suffix (eg, JR or III) (ST)> ^ <prefix (eg, DR) (ST)> ^ <degree (eg, MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <name assembly order (ID)>
Composition: In 2.3 and later versions, replace the CN data type. <ID number (ST)> ^<Last name (FN)> ^ <First name (ST)> ^ <2.and other names or capital letters in the first name (ST)> ^ <Suffix (e.g. JR or III) (ST)> ^Prefix (e.g., DR) (ST)> ^ <Degree (e.g., Master) (IS)> ^ <Original Data Sheet (IS)> ^ <Authorization Certificate (HD)> ^ ****< Name Type Code (ID)> ^<Check Digit Identifier (ST)> ^ <Code to identify the adopted check digit scheme (ID)> ^ <Type Code Identifier (IS)> ^ <Designated Facilities (HD )> ^ <Name Representative Code (ID)> ^ <Name Environment (CE)> ^ <Name Valid Range (DR)> ^ <Name Assembly Order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
The composition of the authorization certificate: <site name ID (IS)> & <common ID (ST)> & <common ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Composition of designated facilities: <Place name ID (IS)> & <Universal ID (ST)> & <Universal ID type (ID)>
Definition: This field identifies the persons who received a copy of this document.
Definition: This field identifies the recipient of the copy of the file.
-
-
- OBX -observation segment usage
-
9.6.2 OBX-Observation Report Segment Usage
The OBX segment is documented in its entirety in Chapter 7. Its usage as it applies to Medical Records/Information Management is documented here for clarity.
The OBX segment is documented in its project in Chapter 7. It is filed here to clarify its usage for medical records/information management.
HL7 Attribute Table-OBX Observation Segment
HL7 Attribute Sheet-OBX-Observation Report Segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME |
---|---|---|---|---|---|---|---|
Ingredient name | |||||||
1 | 4 | SI | R | 00569 | Set ID- OBX | ||
Set ID- OBX | |||||||
2 | 2 | ID | R | 0125 | 00570 | Value Type | |
Value type | |||||||
3 | 250 | CE | O | 00571 | Observation Identifier | ||
Observation report identifier | |||||||
4 | 20 | ST | O | 00572 | Observation Sub-Id | ||
Observation Report Sub-Id | |||||||
5 | * | * | C/R | 00573 | Observation Value | ||
Observation report value | |||||||
6 | 250 | CE | O | 00574 | Units | ||
unit | |||||||
7 | 60 | ST | O | 00575 | References Range | ||
Reference range | |||||||
8 | 5 | ID | O | Y/5 | 0078 | 00576 | Abnormal Flags |
Abnormal mark | |||||||
9 | 5 | NM | O | 00577 | Probability | ||
Probability | |||||||
10 | 2 | ID | O | 0080 | 00578 | Nature of Abnormal Test | |
Types of abnormal inspections | |||||||
11 | 1 | ID | R/NA | 0085 | 00579 | Observation Result Status | |
Observe the report result status | |||||||
12 | 26 | TS | C | 00580 | Date Last Observation Normal Values | ||
Recently observed and reported normal values | |||||||
13 | 20 | ST | C | 00581 | User Defined Access Checks | ||
User-defined database verification | |||||||
14 | 26 | TS | O | 00582 | Date/Time of Observation | ||
Date/time of observation report | |||||||
15 | 250 | CE | C | 00583 | Producer's ID | ||
Producer ID | |||||||
16 | 250 | XCN | O | Y | 00584 | Responsible Observer | |
Responsible Observer | |||||||
17 | 250 | CE | O | Y | 00936 | Observation Method | |
Observation report method |
C = For fields OBX-12, OBX-13, and OBX-15, the field should be valued conditionally. These fields should be valued only when the result (OBX-5-observation value) contains a single concept. This is typically true when the result type is numeric, ID, or CE. When multiple medical concepts are expressed, the values of these three fields are ambiguous.* = 256 K or site negotiated
C = For fields OBX-12, OBX-13 and OBX-15, this field should be assigned conditionally. When the result (OBX-5-observation report value) contains a single concept, only these fields should be assigned values. This is a typical state when the result type is numeric, ID, or CE. When multiple medical opinions are expressed, the values of these three fields are ambiguous. * = 256 K or negotiated position
Specialized usage: Observation Identifier/Observation Sub-ID have been used as optional fields that are not required in unstructured text where the nature of the document has been identified in TXA-2-Document type , which is a required field, but is expressly allowed in the richer structured documentation. An example includes cases where anatomic reports may have separate OBXs for gross examination, microscopic examination, clinical impression, and final diagnosis. Another possible use includes imbedding non-textual observations within textual reports.
Special usage: Observation report identifier/observation report sub ID has been used as optional fields. These fields are not needed in unstructured text. The file type in those texts has been identified in TXA-2- file type However, these fields are especially needed in complex documentation. An example includes the case where an anatomical report may separate multiple OBXs for overall examination, microscopic examination, clinical analysis, and final diagnosis. Another possible usage includes embedding non-textual observation reports in the original report.
9.7 Instance Information
The following is an example of an original transmission of a history and physical examination which has been authenticated prior to this message being initiated:
The following is an example of the initial transmission of medical records and physical examinations prior to starting information:
MSH|...<cr>
EVN|T02|19960215154405||04|097220^Smith^Frederick^A^Jr^Dr^MD^| <cr>
PID|...<cr>
PR1|...<cr>
TXA|0001|HP^history & physical|TX^text|19960213213000|099919^Tracy^Wayne^R^III^Mr^MS^|
19960213153000|19960215134500||099919^Tracy^Wayne^R^III^Mr^MS^ |097220^Smith^Frederick^A^Jr^Dr^MD^|01234567^Baxter^Catherine^S^Ms|1996021500001^transA|||example.doc|LA|UC|AV||AC|||||097220 ^Smith^Frederick^A^Jr^Dr^MD^| <cr>
OBX|1|CE|2000.40^CHIEF COMPLAINT|| ... <cr>
OBX|2|ST|2000.01^SOURCE||PATIENT <cr>
OBX|3|TX|2000.02^PRESENT ILLNESS||SUDDEN ONSET OF CHEST PAIN. 2 DAYS, PTA ASSOCIATED WITH NAUSEA, VOMITING & SOB. NO RELIEF WITH ANTACIDS OR NTG. NO OTHER SX. NOT PREVIOUSLY ILL.<cr>
.
.
and so on.
and many more.
9.8 Interrogation procedures
A query may be used to retrieve a list of documents or a specific document. See Chapter 5 for details of queries.
An interrogation program can be used to retrieve a list of archives or a particular archive. Refer to Chapter 5 for details of the inquiry procedure.
9.8.1 QRY/DOC- File inquiry procedure (event code T12 )
QRY^T12 | Document Query | Chapter |
---|---|---|
File inquiry procedure | Chapters | |
MSH | Message Header | 2 |
Information header | ||
QRD | Query Definition | 2 |
Query program definition | ||
[QRF] | Query Filter | 2 |
Interrogation program screening |
DOC^T12 | Document Response | Chapter |
---|---|---|
File response | Chapters | |
MSH | Message Header | 2 |
Information header | ||
MSA | Message Acknowledgement | 2 |
Information confirmed | ||
[ERR] | Error | 2 |
Error message | ||
[QAK] | Query Acknowledgement | 5 |
Ask for program confirmation | ||
QRD | Query Definition | 2 |
Query program definition | ||
{ | ||
[EVN] | Event Type | 3 |
Event type | ||
PID | Patient Identification | 3 |
Patient identification | ||
PV1 | Patient Visit | 3 |
Patient visits | ||
TXA | Document Notification | 9 |
File notice | ||
[{OBX}] | Observation | 7 |
} | Observation report | |
[DSC] | Continuation Pointer | 2 |
Continuous indicator |
-
-
-
- hiddentext
- Query usage notes
-
-
9.8.1.1 Inquiry about the precautions of program usage
The QRD and QRF segments are defined in Chapter 5, Sections 5.10.5.3, QRD-original style query definition segment, and 5.10.5.4, QRF-original style query filter segment.
The QRD and QRF segments are defined in Chapter 5, Section 5.10.5.3, "QRD-Original Type of Interrogation Program Definition Segment" and Section 5.10.5.4, "QRD-Original Type of Interrogation Program Screening Segment".
The subject filters contained in the QRD and QRF segments describe the kind of information that is required to satisfy the request. They are defined by local agreement between the inquiring system and the ancillary system. See the Implementation Guide for detailed examples of the use of query filter fields.
The topic screening in the QRD and QRF segments describes the type of information needed to meet the requirements. They are defined by the local agreement between the consulting system and the subsystem. Refer to the execution guide for specific examples of using the filter field of the interrogator.
The Set ID fields in the various segments (including PID) are used to count the number of segments of one kind transmitted at one level of the hierarchy.
Use the setting ID field in various segments (including PID) to calculate the number of certain types of segments transmitted in a level of the hierarchy.
QRD-12-Query results level determines the amount of data requested. See Chapter 2, Section 5.10.5.3.12, Query results level.
QRD-12- Interrogation program result level determines the amount of data required. See Chapter 2, Section 5.10.5.3.12, "Interrogation Program Results Level".
9.9 Important questions
None.
no.