Chapter Chair/Editor: |
Wayne
Tracy, MS |
Chapter Chair/Editor: |
Harry
Rhodes |
Note: No substantive changes were made to this chapter for Version 2.4.
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.
This chapter defines the transactions at the seventh level, i.e., 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 part provides definition of terms used throughout this chapter. The intent of this part is to provide clarification on use and interpretation.
An appendage to an existing document that contains supplemental information. The parent document remains in place and its content is unaltered.
A storage status in which a document has been stored off-line for long-term access.
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.
A document which consists of an original document and one or more addenda.
The following terms are used to describe the workflow progression of a document:
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.
A completion status in which information has been orally recorded but not yet transcribed.
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.
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.
A completion status in which information is known to be missing from a transcribed document.
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.
A completion status in which a document is transcribed but not authenticated.
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").
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.
An availability status in which a document has been replaced by a document which contains revised content.
A storage status in which a document is no longer available in this system.
A document that replaces an existing document. The original document becomes obsolete, but is still retained in the system for historical reference.
A confidentiality status in which access to a document has institutionally assigned limitations.
This is not a supported trigger event. See Sections 9.1.1.6, "Edited document", and 9.1.1.10 "Replacement document".
A process of transforming dictated or otherwise documented information into an electronic format.
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.
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 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.
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:
* 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.
* All documents are unique, and document numbers and file names are not
reused.
* Documents may be associated with one or more orders.
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).
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 (i.e.,
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.
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:
Scenario A: A document is dictated and chart tracking system is notified
that it has been dictated and is awaiting transcription.
Scenario B: Dictation is transcribed and chart tracking system is
notified that the document exists and requires authentication.
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.
MDM^T01^MDM_T01 |
Original Document Notification |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
PV1 |
Patient Visit |
3 |
TXA |
Document Notification |
9 |
ACK^T01^ACK |
General Acknowledgment |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
This
is a notification of the creation of a document with the 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.
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.
MDM^T02^MDM_T02 |
Original Document Notification & Content |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
PV1 |
Patient Visit |
3 |
TXA |
Document Notification |
9 |
{OBX} |
Observation/Result (one or more required) |
9 |
ACK^T02^ACK |
General Acknowledgment |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error Information |
2 |
This
is a notification of a change in a status of a document without the
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.
A change in any of the following independent status characteristics would cause
a message to be sent:
* Completion Status
* Confidentiality Status
* Availability Status (the Availability Status of "cancelled" is supported in
T11 (document cancel notification) or T03)
* Storage Status
MDM^T03^MDM_T01 |
Document Status Change Notification |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
PV1 |
Patient Visit |
3 |
TXA |
Document Notification |
9 |
ACK^T03^ACK |
General Acknowledgment |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
This
is a notification of a change in a status of a document with the 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.
MDM^T04^MDM_T02 |
Document Status Change Notification & Content |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
PV1 |
Patient Visit |
3 |
TXA |
Document Notification |
9 |
{OBX} |
Observation/Result (one or more required) |
7 |
ACK^T04^ACK |
General Acknowledgment |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
This
is a notification of an addendum to a document without the 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.
MDM^T05^MDM_T01 |
Document Addendum Notification |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
PV1 |
Patient Visit |
3 |
TXA |
Document Notification |
9 |
ACK^T05^ACK |
General Acknowledgment |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
This
is a notification of an addendum to a document with the 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.
MDM^T06^MDM_T02 |
Document Addendum Notification & Content |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
PV1 |
Patient Visit |
3 |
TXA |
Document Notification |
9 |
{OBX} |
Observation/Result (one or more required) |
7 |
ACK^T06^ACK |
General Acknowledgment |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
Note:
The only valid use of this trigger event is for documents whose
availability status is "Unavailable," i.e., the document has not been made
available for patient care.
This is a notification of an edit to a document without the 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.
MDM^T07^MDM_T01 |
Document Edit Notification |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
PV1 |
Patient Visit |
3 |
TXA |
Document Notification |
9 |
ACK^T07^ACK |
General Acknowledgment |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
Note:
The only valid use of this trigger event is for documents whose availability
status is "Unavailable," i.e., the document has not been made available for
patient care.
This is a notification of an edit to a document with the 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.
MDM^T08^MDM_T02 |
Document Edit Notification & Content |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
PV1 |
Patient Visit |
3 |
TXA |
Document Notification |
9 |
{OBX} |
Observation/Result (one or more required) |
7 |
ACK^T08^ACK |
General Acknowledgment |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
Note:
This trigger event is generally used when the original document availability
status is "Available."
This is a notification of replacement to a document without the 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.
MDM^T09^MDM_T01 |
Document Replacement Notification |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
PV1 |
Patient Visit |
3 |
TXA |
Document Notification |
9 |
ACK^T09^ACK |
General Acknowledgment |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
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.
MDM^T10^MDM_T02 |
Document Replacement Notification & Content |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
PV1 |
Patient Visit |
3 |
TXA |
Document Notification |
9 |
{OBX} |
Observation/Result (one or more required) |
7 |
ACK^T10^ACK |
General Acknowledgment |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
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.
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.
MDM^T11^MDM_T01 |
Document Cancel Notification |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
EVN |
Event Type |
3 |
PID |
Patient Identification |
3 |
PV1 |
Patient Visit |
3 |
TXA |
Document Notification |
9 |
ACK^T11^ACK |
General Acknowledgment |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgment |
2 |
[ERR] |
Error |
2 |
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.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
---|---|---|---|---|---|---|---|
1 |
4 |
SI |
R |
00914 |
Set ID- TXA |
||
2 |
30 |
IS |
R |
0270 |
00915 |
Document Type |
|
3 |
2 |
ID |
C |
0191 |
00916 |
Document Content Presentation |
|
4 |
26 |
TS |
O |
00917 |
Activity Date/Time |
||
5 |
250 |
XCN |
C |
Y |
00918 |
Primary Activity Provider Code/Name |
|
6 |
26 |
TS |
O |
00919 |
Origination Date/Time |
||
7 |
26 |
TS |
C |
00920 |
Transcription Date/Time |
||
8 |
26 |
TS |
O |
Y |
00921 |
Edit Date/Time |
|
9 |
250 |
XCN |
O |
Y |
00922 |
Originator Code/Name |
|
10 |
250 |
XCN |
O |
Y |
00923 |
Assigned Document Authenticator |
|
11 |
250 |
XCN |
C |
Y |
00924 |
Transcriptionist Code/Name |
|
12 |
30 |
EI |
R |
00925 |
Unique Document Number |
||
13 |
30 |
EI |
C |
00926 |
Parent Document Number |
||
14 |
22 |
EI |
O |
Y |
00216 |
Placer Order Number |
|
15 |
22 |
EI |
O |
00217 |
Filler Order Number |
||
16 |
30 |
ST |
O |
00927 |
Unique Document File Name |
||
17 |
2 |
ID |
R |
0271 |
00928 |
Document Completion Status |
|
18 |
2 |
ID |
O |
0272 |
00929 |
Document Confidentiality Status |
|
19 |
2 |
ID |
O |
0273 |
00930 |
Document Availability Status |
|
20 |
2 |
ID |
O |
0275 |
00932 |
Document Storage Status |
|
21 |
30 |
ST |
C |
00933 |
Document Change Reason |
||
22 |
250 |
PPN |
C |
Y |
00934 |
Authentication Person, Time Stamp |
|
23 |
250 |
XCN |
O |
Y |
00935 |
Distributed Copies (Code and Name of Recipients) |
Definition: This field contains a number that uniquely identifies this transaction for the purpose of adding, changing, or deleting the transaction.
Definition:
This field identifies the type of document (as defined in the transcription
system). Refer to User-defined Table 0270 - Document
type for suggested values. The organization is free to add more
entries.
Value |
Description |
---|---|
AR |
Autopsy report |
CD |
Cardiodiagnostics |
CN |
Consultation |
DI |
Diagnostic imaging |
DS |
Discharge summary |
ED |
Emergency department report |
HP |
History and physical examination |
OP |
Operative report |
PC |
Psychiatric consultation |
PH |
Psychiatric history and physical examination |
PN |
Procedure note |
PR |
Progress note |
SP |
Surgical pathology |
TS |
Transfer summary |
Definition:
This is a conditional field which is required whenever the message contains
content as presented in one or more OBX segments. This field identifies the
method by which this document was obtained or originated. Refer to
HL7 Table 0191 - Type of referenced data
for valid values.
Value |
Description |
---|---|
AP |
Other application data, typically uninterpreted binary data (HL7 V2.3 and later) |
AU |
Audio data (HL7 V2.3 and later) |
FT |
Formatted text (HL7 V2.2 only) |
IM |
Image data (HL7 V2.3 and later) |
multipart |
MIME multipart package |
NS |
Non-scanned image (HL7 V2.2 only) |
SD |
Scanned document (HL7 V2.2 only) |
SI |
Scanned image (HL7 V2.2 only) |
TEXT |
Machine readable text document (HL7 V2.3.1 and later) |
TX |
Machine readable text document (HL7 V2.2 only) |
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.
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 (e.g., JR or
III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., 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)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace 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 date and time the document was created (i.e., dictated, recorded, etc.).
Definition: This field contains the date and time the input was actually transcribed. This field is conditional based upon the presence of a value in TXA-17-Document completion status of anything except "dictated."
Definition: This field contains the date and time the document was edited.
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 (e.g., JR or
III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., 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)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the person who originated (i.e., dictated)
the document. The document originator may differ from the person responsible
for authenticating the document.
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 (e.g., JR or
III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., 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)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace 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.
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 (e.g., JR or
III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., 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)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace 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.
Components:
<entity identifier (ST)> ^ <namespace 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.
Components:
<entity identifier (ST)> ^ <namespace 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.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field is the placer application's order number.
This is a composite field. The first component is a string of characters that
identifies an individual order (e.g., 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.
Components:
<entity identifier (ST)> ^ <namespace 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 (e.g., OBR). This string must uniquely
identify the order (as specified in the order detail segment) from other orders
in a particular filling application (e.g., transcription service). This
uniqueness must persist over time. Where a number is reused over time, a date
can be affixed to the non-unique number to make it unique.
The second through fourth components contains the (filler) assigning authority.
The (filler) assigning authority is a string of characters that uniquely
defines the application from other applications on the network. The second
through fourth components of the filler order number always identify the actual
filler of an order.
For further details, please see the definitions provided in Chapter 4.
Definition: This field contains a unique name assigned to a document by the sending system. The file name is used to assist the receiving system in matching future updates to the document.
Definition:
This field identifies the current completion state of the document. This is a
required, table-driven field. Refer to HL7 table 0271 - Document
completion status for valid values.
Value |
Description |
---|---|
DI |
Dictated |
DO |
Documented |
IP |
In Progress |
IN |
Incomplete |
PA |
Pre-authenticated |
AU |
Authenticated |
LA |
Legally authenticated |
Transition (Action) |
Old State |
New State |
---|---|---|
T01
Original Notification |
NA |
Dictated |
T03
Status Change Notification |
Dictated |
In
Progress |
In Progress |
Incomplete |
|
Incomplete |
Pre-authenticated |
|
Pre-authenticated |
Authenticated |
|
Authenticated |
Legally authenticated |
|
Legally authenticated |
NA |
|
Documented |
Pre-authenticated |
|
T05
Addendum Notification |
NA |
Dictated |
T07
Edit Notification |
Dictated |
In
Progress |
In Progress |
Incomplete |
|
Incomplete |
Pre-authenticated |
|
Pre-authenticated |
Authenticated |
|
Authenticated |
Legally authenticated |
|
Legally authenticated |
NA |
|
Documented |
Pre-authenticated |
|
T09
Replacement Notification |
NA |
Dictated |
T11 Cancel Notification |
Dictated |
Canceled |
Note: NA means not applicable. Document confidentiality 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.
Value |
Description |
---|---|
V |
Very restricted |
R |
Restricted |
U |
Usual control |
Definition:
This is an optional field which identifies a document's availability for use
in patient care. If an organization's business rules allow a document to be
used for patient care before it is authenticated, the value of this field
should be set to "AV." If a document has been made available for patient care,
it cannot be changed or deleted. If an erroneous document has been made
available at any point in time and a replacement is not appropriate, then it
may be marked as "Canceled" and removed, as in the case of a document being
assigned to the wrong patient. Additional information must be provided via an
addendum, which is separately authenticated and date/time stamped. If the
content of a document whose status is "Available" must be revised, this is done
by issuing a replacement, which is separately authenticated and date/time
stamped. Refer to HL7 table 0273 - Document availability status
for valid values.
Value |
Description |
---|---|
AV |
Available for patient care |
CA |
Deleted |
OB |
Obsolete |
UN |
Unavailable for patient care |
Transition (Action) |
Old State |
New State |
Notes |
---|---|---|---|
T01
Original Notification |
NA |
Unavailable |
|
T03
Status Change Notification |
Unavailable |
Unavailable |
|
Available |
Available |
||
Obsolete |
NA |
||
T05
Addendum Notification |
NA |
Unavailable |
|
T07
Edit Notification |
Unavailable |
Unavailable |
|
T09
Replacement Notification |
NA |
Unavailable |
Set parent document to "obsolete" |
T11 Cancel |
Unavailable |
Delete |
Note: NA means not applicable.
Definition:
This optional field identifies the storage status of the document. Refer to
HL7 table 0275 - Document storage status for valid values.
Value |
Description |
---|---|
AC |
Active |
AA |
Active and archived |
AR |
Archived (not active) |
PU |
Purged |
Definition: This free text field (limited to 30 characters) contains the reason for document status change.
Components:
<ID number (ST)> ^ <family name (FN)> ^ <given name (ST) ^
<second and further given names or initials thereof (ST)>^ <suffix
(e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g.,
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)>
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 component s 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.
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 (e.g., JR or
III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., 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)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace 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 contains the date and time the document was authenticated (either manually or electronically).
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 (e.g., JR or
III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., 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)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field identifies the persons who received a copy of this
document.
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.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
---|---|---|---|---|---|---|---|
1 |
4 |
SI |
R |
00569 |
Set ID- OBX |
||
2 |
2 |
ID |
R |
0125 |
00570 |
Value Type |
|
3 |
250 |
CE |
O |
00571 |
Observation Identifier |
||
4 |
20 |
ST |
O |
00572 |
Observation Sub-Id |
||
5 |
* |
* |
C/R |
00573 |
Observation Value |
||
6 |
250 |
CE |
O |
00574 |
Units |
||
7 |
60 |
ST |
O |
00575 |
References Range |
||
8 |
5 |
ID |
O |
Y/5 |
0078 |
00576 |
Abnormal Flags |
9 |
5 |
NM |
O |
00577 |
Probability |
||
10 |
2 |
ID |
O |
0080 |
00578 |
Nature of Abnormal Test |
|
11 |
1 |
ID |
R/NA |
0085 |
00579 |
Observation Result Status |
|
12 |
26 |
TS |
C |
00580 |
Date Last Observation Normal Values |
||
13 |
20 |
ST |
C |
00581 |
User Defined Access Checks |
||
14 |
26 |
TS |
O |
00582 |
Date/Time of Observation |
||
15 |
250 |
CE |
C |
00583 |
Producer's ID |
||
16 |
250 |
XCN |
O |
Y |
00584 |
Responsible Observer |
|
17 |
250 |
CE |
O |
Y |
00936 |
Observation 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
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.
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:
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.
A query may be used to retrieve a list of documents or a specific document. See Chapter 5 for details of queries.
QRY^T12 |
Document Query |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
QRD |
Query Definition |
2 |
[ QRF ] |
Query Filter |
2 |
DOC^T12 |
Document Response |
Chapter |
---|---|---|
MSH |
Message Header |
2 |
MSA |
Message Acknowledgement |
2 |
[ERR] |
Error |
2 |
[QAK] |
Query Acknowledgement |
5 |
QRD |
Query Definition |
2 |
{ |
||
[EVN] |
Event Type |
3 |
PID |
Patient Identification |
3 |
PV1 |
Patient Visit |
3 |
TXA |
Document Notification |
9 |
[{OBX}] |
Observation |
7 |
} |
||
[DSC] |
Continuation Pointer |
2 |
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 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 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.
QRD-12-Query results level determines the amount of data requested. See
Chapter 2, Section 5.10.5.3.12, "Query results level."
None.