|
Chapter Co-Chair |
Calvin Beebe |
|
Chapter Co-Chair |
Gay Dolin |
|
Chapter Co-Chair |
Benjamin Flessner |
|
Chapter Co-Chair |
Austin Kreisler |
|
Chapter Co-Chair |
Sean McIlvenna |
|
Chapter Co-Chair |
Andrew Statler |
|
Editor |
Anthony Julian |
|
Editor Emeritus |
Peter Gilbert |
|
Sponsoring Committee |
Structured Documents |
|
List Server |
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.
Document/reports supported in this chapter will meet the criteria as described in Chapter 7, "Observations" (section 7.2 – Purpose). The appropriate use of MDM messages versus ORU message has been clarified in 7.2.
This section provides definitions 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 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 Section9.2.1.9, "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.2.1.5, "Edited Document:", and 9.2.1.9 "Replacement Document:".
A process of transforming dictated or otherwise documented information into an electronic format.
In most cases in the health field, consent must be "informed" consent. This means that the consenting individual must understand and appreciate the implications of what he or she is consenting to. Most consent processes involve providing background material describing the reasons for the proposed service, expected benefits and potential risks. It is important to have a record of what information was presented to the subject at the time of consent.
There may arise situations in which an action must be performed without patient consent (i.e., retrieving an unconscious patient's drug history, performing life saving surgery, etc.). This field indicates the rationale for accessing information without obtaining the required consent.
Related to the above, there also needs to be a record of the time the subject actually made their consent decision.
Identifies whether the subject was provided with information on the full background information on the procedure the subject is giving consent to; i.e., has all information needed for 'informed' consent been provided.
For informed consent, a knowledgeable person must discuss the ramifications of consent with the subject. In some instances, this discussion is required to take place prior to the provision of consent. This ensures that the subject has sufficient time to consider the ramifications of his or her decision. To ensure that guidelines are followed, it is imperative to record when the consent information was initially discussed with the subject.
Not all consents take effect at the time the consent decision is made. They may not become effective for some time, or in certain circumstances they may even be retroactive. Use this field to record the effective time.
For most programs requiring voluntary participation, the decision to participate is not final and therefore may be revoked in the future. Therefore, when a patient makes the decision to revoke his or her consent, the date and time on which the decision was made must be recorded in order to provide a complete history of the consent. Alternatively, the initial consent may only have been granted for a limited period of time (i.e., 24 hours, 1 week, 1 year). If Consent End Date/Time is null, this should be interpreted as 'indefinite.'
Some institutions may have a set of pre-defined consent forms. Identifying the specific form identifies the details the subject is consenting to, as well as what information is on the form.
The manner in which consent can be given may vary greatly within a specific program, from program to program, or from organization to organization. Therefore, the standard must allow applications to identify how consent was obtained (i.e., verbally, written, etc.).
Identifies why information was withheld from the patient (i.e., telling the patient may cause a worse outcome than performing the procedure).
The issue of patient consent has become more important, particularly in the tracking of consent for the release of or exchange of information. The pieces of information recorded when dealing with a patient consent tend to be similar, regardless of the purpose of the consent. This segment combines these pieces of information so that they can be used for consents of any type.
Consent can be pending (subject hasn't been asked yet), given, refused, revoked or even completely bypassed. Consent Status identifies what the status of a subject's consent is (or was at a given point in time).
When recording consents electronically it is important to know the specific text that was presented to the consenting person.
In concert with giving consent, some programs may allow patients to request varying degrees of participation in a given program. I.e., if a consent program relates to a patient's entire medical record being available online they might have the opportunity to only reveal certain portions of that history, such as the drug history only.
As part of the informed consent process, additional material in the form of pamphlets, books, brochures, videos, etc., may be provided to the patient. An indication of whether this has been done is required. (Details on the materials provided will be sent using a separate segment.)
One of the issues involved in informed consent is whether the subject is judged to be competent to provide consent on his or her own behalf. Factors involve age, mental capacity, and current state of health/awareness. A professional judgment about whether the subject is deemed competent must be made and recorded.
At the time of consent, the subject may wish to make modifications or add limitations to his or her consent. These modifications and limitations must be recorded.
The reasons, expected benefits and risks may vary from subject to subject. It may be necessary to inform the subject of background information that only applies to his or her particular circumstance.
Sometimes consent forms have areas where details of the procedure or information distribution that are specific to a given consent instance are recorded, i.e., a variation on a common procedure, or an explicit listing of documents to be released. As this is part of the consent document, it needs to be recorded. It is helpful to keep this information separate from the standard 'template' consent text, as in most circumstances people viewing the consent will want to know "What's different from usual?"
To obtain informed consent, the patient must understand what he or she is consenting to. For subjects who do not understand the commonly used language of the institution, or who are unable to hear/read/speak, translation services may be required. An indication of what type(s) of translation were/will be performed is required.
To obtain informed consent, the patient must understand what he or she is consenting to. For subjects who do not understand the commonly used language of the institution, or who are unable to hear/read/speak, translation services may be required.
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 status of a document only and the other that describes the status 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. Documents may be represented as a CDA document. See ANSI/HL7 CDA R2.0-2005 Section 3 for the correct method of transmitting CDA documents within an MDM message. 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 independently of the order process. In this version we have added the ORC, OBR and associated NTE segments in order to provide full ordering context when appropriate for document management messages. 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.
A patient decides to participate in a voluntary electronic drug history program. The patient records this decision in writing (Consent Mode) on a pre-designed consent form (Consent Form ID and Version) after the patient's health care service provider has explained the benefits and drawbacks of their participation (Consent Discussion Date/Time). In providing consent, the patient can also decide on the degree to which he or she will participate in the program (Consent Type). The consent decision (Consent Status) is recorded under the patient's name (use ROL segment) and the number of the paper-based form that the patient signed is recorded in the electronic consent gathering function (Consent Number). The patient's consent is effective from the day of the decision (Consent Effect Date/Time), but this consent can be terminated at the patient's discretion at a given date in the future (Consent End Date/Time). Several months later the patient is rushed into an emergency health care facility with what appears to be a drug reaction. While checking the patient's drug history, health care service providers find that the patient's drug history has controlled access. The patient is unable to provide access to this information given that patient's physical state, so the health care service provider circumvents the consent process (Non-consent Access Reason) in the interests of the patient's immediate well-being.
Example 2: A patient is seeking a therapeutic abortion. Because she is under 18, the practitioner must evaluate her competence to provide consent. The patient is deemed to be competent (Patient Competence Indicator). Local legislation mandates that the patient be counseled at least 24 hours prior to receiving the procedure. The patient is counseled, and the time recorded (Consent Discussion Date/Time). She is also given a pamphlet to take home and read (Informational Material Supplied Indicator). She returns the following day and signs the consent form (Consent Decision Date/Time).
Example 3: A deaf patient is admitted for labor and delivery. It becomes apparent the patient will require a cesarean section. A translator is required (Translator Assistance Indicator) who can translate sign language (Translation Type). The translator explains the details of the procedure the patient is being asked to consent to (Consent Text), the intention to use epidural anesthetic (Subject-specific Consent Text), the general risks associated with doing the procedure, as well as those with not doing the procedure (Background Text) and benefits associated with the epidural (Subject-specific Background Text). The patient agrees to the procedure, subject to the condition that she not be given any blood products for religious reasons (Subject-imposed Limitations).
Example 4: An employee signs a consent form authorizing (Consent Status) a hospital to request the employee's driving records from the local Department of Motor Vehicles (Consent Type).
Example 5: A patient signs a consent form to have basic diagnostic and billing information sent to that patient's insurer. The consent indicates that information may only be given to parties that are bound by HIPPA guidelines (Trust Agreement Restriction Type).
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).
Note: Note that the event is encapsulated in MSH-9 and the event segment is deprecated for all MDM message cases as of version 2.5.
When -MSH-9 is valued, the value of EVN-1 must be the same.
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, i.e., when a document has been authenticated.
Also, the orders represented by the ORC/OBR segments must be wholly and exclusively satisfied by the TXA/OBX content. "Wholly satisfied" means there are no other orders related to the TXA/OBX content other than those specified by the ORC/OBR segments. "Exclusively satisfied" means that the actions described by the ORC/OBR segments do not contain actions not addressed by the TXA/OBX content. Thus, the TXA/OBX context must satisfy all instances of ORC/OBR as indicated by ORC-7 Quantity/Timing, OBR-27 Quantity/Timing or the TQ1/ TQ2 segments.
The placer order number may exist in the ORC, OBR and TXA. If valued in the ORC or OBR and the TXA is present, it should not be valued. If TXA is valued it should be ignored.
The filler order number may exist in the ORC, OBR and TXA. If valued in the ORC or OBR and the TXA is present, it should not be valued. If TXA is valued it should be ignored.
Generally the OBR-32 Principal interpreter and the TXA–22.1 Authentication person are conceptually the same. Normally only the TXA-22.1 should be valued. If both are valued, the TXA-22.1 takes precedence.
The OBR-35 Transcriptionist and the TXA–11 Transcriptionist are conceptually the same. Normally only the TXA-11 should be valued. If both are valued, the TXA-11 takes precedence.
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.
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
MDM_T01
|
|||
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
EVN
|
1..1 | Yes | B, v2.5 |
|
PID
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
PV1
|
1..1 | Yes | |
|
PRT
|
0..* | ||
COMMON_ORDER
|
0..* | ||
ORC
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
OBR
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
TIMING
|
0..* | ||
TQ1
|
1..1 | Yes | |
TQ2
|
0..* | ||
|
TXA
|
1..1 | Yes | |
|
CON
|
0..* | ||
Send Immediate Ack: ACK^T01^ACK
When the MSH-15 value of a MDM^T01^MDM_T01 message is AL or ER or SU, an ACK^T01^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MDM^T01^MDM_T01 message is NE, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MDM^T01^MDM_T01 message is AL or ER or SU, an ACK^T01^ACK message SHALL be sent as an application ack.
When the MSH-16 value of a MDM^T01^MDM_T01 message is NE, an application ack SHALL NOT be sent.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T01^ACK |
| NE | (none) | |
| MSH-16 | AL, ER, SU | application ack: ACK^T01^ACK |
| NE | (none) |
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
ACK
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
MSA
|
1..1 | Yes | |
|
ERR
|
0..* | ||
Send Immediate Ack: ACK^T01^ACK
When the MSH-15 value of an ACK^T01^ACK message is AL or ER or SU, an ACK^T01^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of an ACK^T01^ACK message is NE, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T01^ACK |
| NE | (none) | |
| MSH-16 | NE | (none) |
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.
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
MDM_T02
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
EVN
|
1..1 | Yes | B, v2.5 |
|
PID
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
PV1
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
COMMON_ORDER
|
0..* | ||
|
ORC
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
OBR
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
|
TIMING
|
0..* | ||
|
TQ1
|
1..1 | Yes | |
|
TQ2
|
0..* | ||
|
TXA
|
1..1 | Yes | |
|
CON
|
0..* | ||
|
|
1..* | Yes | |
|
OBX
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
Send Immediate Ack: ACK^T02^ACK
When the MSH-15 value of a MDM^T02^MDM_T02 message is AL or ER or SU, an ACK^T02^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MDM^T02^MDM_T02 message is NE, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MDM^T02^MDM_T02 message is AL or ER or SU, an ACK^T02^ACK message SHALL be sent as an application ack.
When the MSH-16 value of a MDM^T02^MDM_T02 message is NE, an application ack SHALL NOT be sent.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T02^ACK |
| NE | (none) | |
| MSH-16 | AL, ER, SU | application ack: ACK^T02^ACK |
| NE | (none) |
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
ACK
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
MSA
|
1..1 | Yes | |
|
ERR
|
0..* | ||
Send Immediate Ack: ACK^T02^ACK
When the MSH-15 value of an ACK^T02^ACK message is AL or ER or SU, an ACK^T02^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of an ACK^T02^ACK message is NE, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T02^ACK |
| NE | (none) | |
| MSH-16 | NE | (none) |
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
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
MDM_T01
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
EVN
|
1..1 | Yes | B, v2.5 |
|
PID
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
PV1
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
COMMON_ORDER
|
0..* | ||
|
ORC
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
OBR
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
|
TIMING
|
0..* | ||
|
TQ1
|
1..1 | Yes | |
|
TQ2
|
0..* | ||
|
TXA
|
1..1 | Yes | |
|
CON
|
0..* | ||
Send Immediate Ack: ACK^T03^ACK
When the MSH-15 value of a MDM^T03^MDM_T01 message is AL or ER or SU, an ACK^T03^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MDM^T03^MDM_T01 message is NE, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MDM^T03^MDM_T01 message is AL or ER or SU, an ACK^T03^ACK message SHALL be sent as an application ack.
When the MSH-16 value of a MDM^T03^MDM_T01 message is NE, an application ack SHALL NOT be sent.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T03^ACK |
| NE | (none) | |
| MSH-16 | AL, ER, SU | application ack: ACK^T03^ACK |
| NE | (none) |
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
ACK
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
MSA
|
1..1 | Yes | |
|
ERR
|
0..* | ||
Send Immediate Ack: ACK^T03^ACK
When the MSH-15 value of an ACK^T03^ACK message is AL or ER or SU, an ACK^T03^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of an ACK^T03^ACK message is NE, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T03^ACK |
| NE | (none) | |
| MSH-16 | NE | (none) |
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.
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
MDM_T02
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
EVN
|
1..1 | Yes | B, v2.5 |
|
PID
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
PV1
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
COMMON_ORDER
|
0..* | ||
|
ORC
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
OBR
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
|
TIMING
|
0..* | ||
|
TQ1
|
1..1 | Yes | |
|
TQ2
|
0..* | ||
|
TXA
|
1..1 | Yes | |
|
CON
|
0..* | ||
|
|
1..* | Yes | |
|
OBX
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
Send Immediate Ack: ACK^T04^ACK
When the MSH-15 value of a MDM^T04^MDM_T02 message is AL or ER or SU, an ACK^T04^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MDM^T04^MDM_T02 message is NE, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MDM^T04^MDM_T02 message is AL or ER or SU, an ACK^T04^ACK message SHALL be sent as an application ack.
When the MSH-16 value of a MDM^T04^MDM_T02 message is NE, an application ack SHALL NOT be sent.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T04^ACK |
| NE | (none) | |
| MSH-16 | AL, ER, SU | application ack: ACK^T04^ACK |
| NE | (none) |
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
ACK
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
MSA
|
1..1 | Yes | |
|
ERR
|
0..* | ||
Send Immediate Ack: ACK^T04^ACK
When the MSH-15 value of an ACK^T04^ACK message is AL or ER or SU, an ACK^T04^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of an ACK^T04^ACK message is NE, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T04^ACK |
| NE | (none) | |
| MSH-16 | NE | (none) |
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.
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
MDM_T01
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
EVN
|
1..1 | Yes | B, v2.5 |
|
PID
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
PV1
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
COMMON_ORDER
|
0..* | ||
|
ORC
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
OBR
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
|
TIMING
|
0..* | ||
|
TQ1
|
1..1 | Yes | |
|
TQ2
|
0..* | ||
|
TXA
|
1..1 | Yes | |
|
CON
|
0..* | ||
Send Immediate Ack: ACK^T05^ACK
When the MSH-15 value of a MDM^T05^MDM_T01 message is AL or ER or SU, an ACK^T05^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MDM^T05^MDM_T01 message is NE, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MDM^T05^MDM_T01 message is AL or ER or SU, an ACK^T05^ACK message SHALL be sent as an application ack.
When the MSH-16 value of a MDM^T05^MDM_T01 message is NE, an application ack SHALL NOT be sent.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T05^ACK |
| NE | (none) | |
| MSH-16 | AL, ER, SU | application ack: ACK^T05^ACK |
| NE | (none) |
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
ACK
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
MSA
|
1..1 | Yes | |
|
ERR
|
0..* | ||
Send Immediate Ack: ACK^T05^ACK
When the MSH-15 value of an ACK^T05^ACK message is AL or ER or SU, an ACK^T05^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of an ACK^T05^ACK message is NE, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T05^ACK |
| NE | (none) | |
| MSH-16 | NE | (none) |
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.
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
MDM_T02
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
EVN
|
1..1 | Yes | B, v2.5 |
|
PID
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
PV1
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
COMMON_ORDER
|
0..* | ||
|
ORC
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
OBR
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
|
TIMING
|
0..* | ||
|
TQ1
|
1..1 | Yes | |
|
TQ2
|
0..* | ||
|
TXA
|
1..1 | Yes | |
|
CON
|
0..* | ||
|
|
1..* | Yes | |
|
OBX
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
Send Immediate Ack: ACK^T06^ACK
When the MSH-15 value of a MDM^T06^MDM_T02 message is AL or ER or SU, an ACK^T06^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MDM^T06^MDM_T02 message is NE, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MDM^T06^MDM_T02 message is AL or ER or SU, an ACK^T06^ACK message SHALL be sent as an application ack.
When the MSH-16 value of a MDM^T06^MDM_T02 message is NE, an application ack SHALL NOT be sent.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T06^ACK |
| NE | (none) | |
| MSH-16 | AL, ER, SU | application ack: ACK^T06^ACK |
| NE | (none) |
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
ACK
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
MSA
|
1..1 | Yes | |
|
ERR
|
0..* | ||
Send Immediate Ack: ACK^T06^ACK
When the MSH-15 value of an ACK^T06^ACK message is AL or ER or SU, an ACK^T06^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of an ACK^T06^ACK message is NE, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T06^ACK |
| NE | (none) | |
| MSH-16 | NE | (none) |
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.
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
MDM_T01
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
EVN
|
1..1 | Yes | B, v2.5 |
|
PID
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
PV1
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
COMMON_ORDER
|
0..* | ||
|
ORC
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
OBR
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
|
TIMING
|
0..* | ||
|
TQ1
|
1..1 | Yes | |
|
TQ2
|
0..* | ||
|
TXA
|
1..1 | Yes | |
|
CON
|
0..* | ||
Send Immediate Ack: ACK^T07^ACK
When the MSH-15 value of a MDM^T07^MDM_T01 message is AL or ER or SU, an ACK^T07^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MDM^T07^MDM_T01 message is NE, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MDM^T07^MDM_T01 message is AL or ER or SU, an ACK^T07^ACK message SHALL be sent as an application ack.
When the MSH-16 value of a MDM^T07^MDM_T01 message is NE, an application ack SHALL NOT be sent.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T07^ACK |
| NE | (none) | |
| MSH-16 | AL, ER, SU | application ack: ACK^T07^ACK |
| NE | (none) |
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
ACK
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
MSA
|
1..1 | Yes | |
|
ERR
|
0..* | ||
Send Immediate Ack: ACK^T07^ACK
When the MSH-15 value of an ACK^T07^ACK message is AL or ER or SU, an ACK^T07^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of an ACK^T07^ACK message is NE, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T07^ACK |
| NE | (none) | |
| MSH-16 | NE | (none) |
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.
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
MDM_T02
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
EVN
|
1..1 | Yes | B, v2.5 |
|
PID
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
PV1
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
COMMON_ORDER
|
0..* | ||
|
ORC
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
OBR
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
|
TIMING
|
0..* | ||
|
TQ1
|
1..1 | Yes | |
|
TQ2
|
0..* | ||
|
TXA
|
1..1 | Yes | |
|
CON
|
0..* | ||
|
|
1..* | Yes | |
|
OBX
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
Send Immediate Ack: ACK^T08^ACK
When the MSH-15 value of a MDM^T08^MDM_T02 message is AL or ER or SU, an ACK^T08^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MDM^T08^MDM_T02 message is NE, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MDM^T08^MDM_T02 message is AL or ER or SU, an ACK^T08^ACK message SHALL be sent as an application ack.
When the MSH-16 value of a MDM^T08^MDM_T02 message is NE, an application ack SHALL NOT be sent.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T08^ACK |
| NE | (none) | |
| MSH-16 | AL, ER, SU | application ack: ACK^T08^ACK |
| NE | (none) |
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
ACK
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
MSA
|
1..1 | Yes | |
|
ERR
|
0..* | ||
Send Immediate Ack: ACK^T08^ACK
When the MSH-15 value of an ACK^T08^ACK message is AL or ER or SU, an ACK^T08^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of an ACK^T08^ACK message is NE, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T08^ACK |
| NE | (none) | |
| MSH-16 | NE | (none) |
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.
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
MDM_T01
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
EVN
|
1..1 | Yes | B, v2.5 |
|
PID
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
PV1
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
COMMON_ORDER
|
0..* | ||
|
ORC
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
OBR
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
|
TIMING
|
0..* | ||
|
TQ1
|
1..1 | Yes | |
|
TQ2
|
0..* | ||
|
TXA
|
1..1 | Yes | |
|
CON
|
0..* | ||
Send Immediate Ack: ACK^T09^ACK
When the MSH-15 value of a MDM^T09^MDM_T01 message is AL or ER or SU, an ACK^T09^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MDM^T09^MDM_T01 message is NE, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MDM^T09^MDM_T01 message is AL or ER or SU, an ACK^T09^ACK message SHALL be sent as an application ack.
When the MSH-16 value of a MDM^T09^MDM_T01 message is NE, an application ack SHALL NOT be sent.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T09^ACK |
| NE | (none) | |
| MSH-16 | AL, ER, SU | application ack: ACK^T09^ACK |
| NE | (none) |
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
ACK
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
MSA
|
1..1 | Yes | |
|
ERR
|
0..* | ||
Send Immediate Ack: ACK^T09^ACK
When the MSH-15 value of an ACK^T09^ACK message is AL or ER or SU, an ACK^T09^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of an ACK^T09^ACK message is NE, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T09^ACK |
| NE | (none) | |
| MSH-16 | NE | (none) |
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.
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
MDM_T02
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
EVN
|
1..1 | Yes | B, v2.5 |
|
PID
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
PV1
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
COMMON_ORDER
|
0..* | ||
|
ORC
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
OBR
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
|
TIMING
|
0..* | ||
|
TQ1
|
1..1 | Yes | |
|
TQ2
|
0..* | ||
|
TXA
|
1..1 | Yes | |
|
CON
|
0..* | ||
|
|
1..* | Yes | |
|
OBX
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
Send Immediate Ack: ACK^T10^ACK
When the MSH-15 value of a MDM^T10^MDM_T02 message is AL or ER or SU, an ACK^T10^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MDM^T10^MDM_T02 message is NE, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MDM^T10^MDM_T02 message is AL or ER or SU, an ACK^T10^ACK message SHALL be sent as an application ack.
When the MSH-16 value of a MDM^T10^MDM_T02 message is NE, an application ack SHALL NOT be sent.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T10^ACK |
| NE | (none) | |
| MSH-16 | AL, ER, SU | application ack: ACK^T10^ACK |
| NE | (none) |
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
ACK
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
MSA
|
1..1 | Yes | |
|
ERR
|
0..* | ||
Send Immediate Ack: ACK^T10^ACK
When the MSH-15 value of an ACK^T10^ACK message is AL or ER or SU, an ACK^T10^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of an ACK^T10^ACK message is NE, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T10^ACK |
| NE | (none) | |
| MSH-16 | NE | (none) |
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.
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
MDM_T01
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
EVN
|
1..1 | Yes | B, v2.5 |
|
PID
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
PV1
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
COMMON_ORDER
|
0..* | ||
|
ORC
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
OBR
|
1..1 | Yes | |
|
PRT
|
0..* | ||
|
NTE
|
0..* | ||
|
TIMING
|
0..* | ||
|
TQ1
|
1..1 | Yes | |
|
TQ2
|
0..* | ||
|
TXA
|
1..1 | Yes | |
|
CON
|
0..* | ||
Send Immediate Ack: ACK^T11^ACK
When the MSH-15 value of a MDM^T11^MDM_T01 message is AL or ER or SU, an ACK^T11^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MDM^T11^MDM_T01 message is NE, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MDM^T11^MDM_T01 message is AL or ER or SU, an ACK^T11^ACK message SHALL be sent as an application ack.
When the MSH-16 value of a MDM^T11^MDM_T01 message is NE, an application ack SHALL NOT be sent.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T11^ACK |
| NE | (none) | |
| MSH-16 | AL, ER, SU | application ack: ACK^T11^ACK |
| NE | (none) |
| Segment | Cardinality | Must Implement | Status |
|---|---|---|---|
|
ACK
|
|||
|
MSH
|
1..1 | Yes | |
|
SFT
|
0..* | ||
|
UAC
|
0..1 | ||
|
MSA
|
1..1 | Yes | |
|
ERR
|
0..* | ||
Send Immediate Ack: ACK^T11^ACK
When the MSH-15 value of an ACK^T11^ACK message is AL or ER or SU, an ACK^T11^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of an ACK^T11^ACK message is NE, an immediate ack SHALL NOT be sent.
Never send an application ack in enhanced mode.
| Field | Value | Send Response |
|---|---|---|
| MSH-15 | AL, ER, SU | immediate ack: ACK^T11^ACK |
| NE | (none) | |
| MSH-16 | NE | (none) |
This segment identifies patient consent information relating to a particular message. It can be used as part of existing messages to convey information about patient consent to procedures, admissions, information release/exchange or other events discussed by the message. It may also be used in messages focusing on recording or requesting consent and for consents related to employees or service providers.
The segment will be used in conjunction with various other segments to identify the practitioner (PRA/STF) or patient (PID) the consent is for, the various individuals involved in the consent (ROL) as witnesses, consenting person (not always the patient), translators, consulting providers, etc., and the specific procedures being proposed (PR1).
| Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
|---|---|---|---|---|---|---|---|---|---|
|
CON
|
|||||||||
|
1
|
01776 | Set ID - CON | SHALL | [1..1] | [1..4] | SI | |||
|
2
|
01777 | Consent Type | [0..1] | CWE | |||||
|
3
|
01778 | Consent Form ID and Version | [0..1] | ST | |||||
|
4
|
01779 | Consent Form Number | [0..1] | EI | |||||
|
5
|
01780 | Consent Text | [0..*] | FT | |||||
|
6
|
01781 | Subject-specific Consent Text | [0..*] | FT | |||||
|
7
|
01782 | Consent Background Information | [0..*] | FT | |||||
|
8
|
01783 | Subject-specific Consent Background Text | [0..*] | FT | |||||
|
9
|
01784 | Consenter-imposed limitations | [0..*] | FT | |||||
|
10
|
01785 | Consent Mode | [0..1] | CNE | |||||
|
11
|
01786 | Consent Status | SHALL | [1..1] | CNE | ||||
|
12
|
01787 | Consent Discussion Date/Time | [0..1] | DTM | |||||
|
13
|
01788 | Consent Decision Date/Time | [0..1] | DTM | |||||
|
14
|
01789 | Consent Effective Date/Time | [0..1] | DTM | |||||
|
15
|
01790 | Consent End Date/Time | [0..1] | DTM | |||||
|
16
|
01791 | Subject Competence Indicator | [0..1] | [1..1] | ID | ||||
|
17
|
01792 | Translator Assistance Indicator | [0..1] | [1..1] | ID | ||||
|
18
|
01793 | Language Translated To | [0..1] | CWE | |||||
|
19
|
01794 | Informational Material Supplied Indicator | [0..1] | [1..1] | ID | ||||
|
20
|
01795 | Consent Bypass Reason | [0..1] | CWE | |||||
|
21
|
01796 | Consent Disclosure Level | [0..1] | [1..1] | ID | ||||
|
22
|
01797 | Consent Non-disclosure Reason | [0..1] | CWE | |||||
|
23
|
01798 | Non-subject Consenter Reason | [0..1] | CWE | |||||
|
24
|
01909 | Consenter ID | SHALL | [1..*] | XPN | ||||
|
25
|
01898 | Relationship to Subject | SHALL | [1..*] | CWE | ||||
Definition: This field contains the number that identifies this segment instance within the message. For the first occurrence of the segment, the sequence number shall be one; for the second occurrence, the sequence number shall be two; etc.
Definition: This field describes what the subject is consenting to, i.e., what type of service, surgical procedure, information access/release or other event. For values see User-Defined Table 0496 – Consent Type.
Definition: Identifies a specific version of a consent form used to record the consent. A given version of a consent form implies a particular set of wording that appears on the form.
Definition: Uniquely identifies a specific recorded consent. This may be the number assigned to an electronic consent, or may be the number on a printed consent form.
Definition: Describes the specific procedures/information releases/events the subject is consenting to.
Definition: Describes any additions or variations to the standard procedures/information releases/events from a standard consent that are applicable to the subject whose consent is sought.
Definition: Describes any additional information relating to the procedure/information release/event that needs to be understood by the subject for informed consent. May include the reason for the service, the expected benefit, risks, etc.
Definition: Describes any additions or variations to the standard additional information that needs to be understood by the patient for informed consent. May include a description of benefits and risks that are specific to the subject from whom consent is sought. May also include an indication that there are no subject-specific risks/benefits.
Definition: Describes any restrictions or limitations placed on their consent by the subject.
Definition: The method in which a subject provides consent. For values see HL7 Table 0497 – Consent Mode.
Definition: Indicates whether consent has been sought and granted. For values see HL7 Table 0498 – Consent Status.
Definition: Identifies the time when consent was discussed with the subject. This should only be specified if this differs from the time the consent decision is made.
Definition: Identifies the time when the decision to grant/refuse consent was made. In the case of written consent, this is the time the consent form is signed.
Definition: The time the consent becomes/became effective. This only needs to be specified if the time differs from the Consent Decision Date/Time
Definition: The time the consent becomes ineffective. If not specified, the consent is assumed to be indefinite. For consents relating to information release, the end date/time is the date by which the released information must be returned/destroyed.
Definition: Identifies whether the subject was deemed competent to provide consent. Refer to table HL7 Table 0136 – Yes/No Indicator.
Definition: Identifies whether translation was (or will be) required to obtain informed consent from the subject. Refer to table HL7 Table 0136 – Yes/No Indicator.
Definition: Identifies the language the consent material must be translated to. Refer to User Defined table 0296 – Primary Language which contains no suggested values. This table may be populated with values similar to those that may be found in ISO table 639 – Language Codes.
Definition: Identifies whether additional educational or reference material was provided to the subject as part of the consent process. Refer to table HL7 Table 0136 – Yes/No Indicator.
Definition: Identifies why the subject's consent was not sought. This field must be populated when CON-11 - Consent Status is B – Bypassed. Refer to User Defined table 0499 – Consent Bypass Reason for suggested values.
Definition: Identifies how much information was disclosed to the subject as part of the informed consent process. Refer to table HL7 Table 0500 – Consent Disclosure Level.
Definition: Identifies why the subject did not receive full disclosure. . Refer to User-Defined Table 0501 – Consent Non-Disclosure Reason for suggested values.
Definition: Identifies why consent was granted by a person other than the subject of the consent. Refer to User-defined Table 0502 – Non-Subject Consenter Reason for suggested values.
Definition: Identification of the individual(s) who is (are) consenting.
Definition: Identification of the relationship of the consenter to the subject. Receivers are required to inspect the Coding System component of the CWE data type to accurately interpret the meaning of the code. Senders transmitting messages to Receivers on earlier version of the standard may elect to negotiate business rules to ensure that expected data is not lost. HL7 does not assign positional meaning to user-defined codes. Refer to User-Defined Table 0548 – Signatory's Relationship to Subject for suggested values.
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.
NOTE: The attribute table definition for the OBX Segment has been removed as of 2.8. The reader is directed to the Chapter 7..
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 TXA segment contains information specific to a transcribed document but does not include the text of the document. The message is created as a result of a document status change. This information updates other healthcare systems and allows them to identify reports that are available in the transcription system. By maintaining the TXA message information in these systems, the information is available when constructing queries to the transcription system requesting the full document text.
| Seq# | DataElement | Description | Must Implement | Flags | Cardinality | Length | C.LEN | Vocabulary | DataType |
|---|---|---|---|---|---|---|---|---|---|
|
TXA
|
|||||||||
|
1
|
00914 | Set ID- TXA | SHALL | [1..1] | [1..4] | SI | |||
|
2
|
00915 | Document Type | SHALL | [1..1] | CWE | ||||
|
3
|
00916 | Document Content Presentation |
MAY
True:
False:
|
C |
[1..1] [0..1] |
ID | |||
|
4
|
00917 | Activity Date/Time | [0..1] | DTM | |||||
|
5
|
00918 | Primary Activity Provider Code/Name |
MAY
True:
False:
|
C |
[1..1] [0..1] |
XCN | |||
|
6
|
00919 | Origination Date/Time | [0..1] | DTM | |||||
|
7
|
00920 | Transcription Date/Time |
MAY
True:
False:
|
C |
[1..1] [0..1] |
DTM | |||
|
8
|
00921 | Edit Date/Time | [0..*] | DTM | |||||
|
9
|
00922 | Originator Code/Name | [0..*] | XCN | |||||
|
10
|
00923 | Assigned Document Authenticator | [0..*] | XCN | |||||
|
11
|
00924 | Transcriptionist Code/Name |
MAY
True:
False:
|
C |
[1..1] [0..1] |
XCN | |||
|
12
|
00925 | Unique Document Number | SHALL | [1..1] | EI | ||||
|
13
|
00926 | Parent Document Number |
MAY
True:
False:
|
C |
[1..1] [0..1] |
EI | |||
|
14
|
00216 | Placer Order Number | [0..*] | EI | |||||
|
15
|
00217 | Filler Order Number | [0..1] | EI | |||||
|
16
|
00927 | Unique Document File Name | [0..1] | ST | |||||
|
17
|
00928 | Document Completion Status | SHALL | [1..1] | [2..2] | ID | |||
|
18
|
00929 | Document Confidentiality Status | [0..1] | [1..1] | ID | ||||
|
19
|
00930 | Document Availability Status | [0..1] | [2..2] | ID | ||||
|
20
|
00932 | Document Storage Status | [0..1] | [2..2] | ID | ||||
|
21
|
00933 | Document Change Reason | [0..1] | ST | |||||
|
22
|
00934 | Authentication Person, Time Stamp |
MAY
True:
False:
|
C |
[1..1] [0..1] |
PPN | |||
|
23
|
00935 | Distributed Copies | [0..*] | XCN | |||||
|
24
|
02378 | Folder Assignment | [0..*] | CWE | |||||
|
25
|
03301 | Document Title | [0..*] | ST | |||||
|
26
|
03302 | Agreed Due Date/Time | [0..1] | DTM | |||||
|
27
|
02413 | Creating Facility | [0..1] | HD | |||||
|
28
|
02414 | Creating Specialty | [0..1] | CWE | |||||
Definition: This field contains a number that uniquely identifies this transaction for the purpose of adding, changing, or deleting the transaction.
Definition: This field identifies the type of document (as defined in the transcription system). Refer to User-Defined Table 0270 - Document Type for suggested values. The organization is free to add more entries. Receivers are required to inspect the Coding System component of the CWE data type to accurately interpret the meaning of the code. Senders transmitting messages to Receivers on earlier version of the standard may elect to negotiate business rules to ensure that expected data is not lost. HL7 does not assign positional meaning to user-defined codes.
Definition: This is a conditional field which is required whenever the message contains content as presented in one or more OBX segments. This field identifies the method by which this document was obtained or originated. Refer to HL7 Table 0191 – Type of Referenced Data for valid values.
Definition: This field contains the date/time identified in the document as the date a procedure or activity was performed. This date can identify date of surgery, non-invasive procedure, consultation, examination, etc.
Definition: This field contains the name of the person identified in the document as being responsible for performing the procedure or activity. This field includes the code and name (if available) of the caregiver. This field is conditional based upon the presence of a value in TXA-4-Activity Date/Time.
Definition: This field contains the date and time the document was created (i.e., dictated, recorded, etc.).
Definition: This field contains the date and time the input was actually transcribed. This field is conditional based upon the presence of a value in TXA-17-Document Completion Status of anything except "dictated."
Definition: This field contains the date and time the document was edited.
Definition: This field identifies the person who originated (i.e., dictated) the document. The document originator may differ from the person responsible for authenticating the document.
Definition: This field identifies the person(s) responsible for authenticating the document, who may differ from the originator. Multiple persons may be responsible for authentication, especially in teaching facilities. This field is allowed to repeat an undefined number of times.
Definition: This field identifies the person transcribing the document. This is a conditional value; it is required on all transcribed documents.
TXA-11 - Condition: If TXA-11 is valued and the corresponding OBR segment is present in the message OBR-35 must be blank. If OBR-35 is valued while TXA-11 is valued, OBR-35 shall be ignored. See message definitions including TXA for further guidanceon which ORC/OBR pairs to consider.
Definition: This field contains a unique document identification number assigned by the sending system. This document number is used to assist the receiving system in matching future updates to the document, as well as to identify the document in a query. When the vendor does not provide a unique document ID number, some type of document identifier should be entered here, or the Unique Document File name should be utilized. See Chapter 2A, section 2.A.89, "XTN - extended telecommunication number." Where the system does not customarily have a document filler number, this number could serve as that value, as well.
Definition: This field contains a document number that identifies the parent document to which this document belongs. The parent document number can be used to assist the receiving system in matching future updates to this document. This is a conditional field that is always required on T05 (document addendum notification), T06 (document addendum notification and content), T09 (document replacement notification), and T10 (document replacement notification and content) events.
(Definition from ORC.2 in Ch. 4)
Definition: This field is the placer application's order number.
This field is a case of the Entity Identifier data type (See Section 2.A.28, "EI – Entity Identifier"). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.
There are three situations in which the true placer is somewhat arbitrary (and thus not unique):
in ORC-1-order control value of RO, following an RU replacement;
in ORC-1-order control value of CH (child orders); and
in ORC-1-order control value of SN (send number).
See the Table Notes under ORC-1-order control for the details of how the ORC-2-placer order number is assigned in these cases.
The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). Note that if both ORC-2 and OBR-2 are valued then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number for the placer order number when a new order is placed or a unique number for the filler order number when an unsolicited result is initially communicated.
These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).
(Definition from OBR.2 in Ch. 4)
Definition: This field is identical to ORC-2-Placer Order Number.
This field is a special case of the Entity Identifier data type (Chapter 2A, section 2.A.28). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.
See ORC-2-placer order number (section 4.5.1.2) for information on when this field must be valued.
A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.
These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).
(Definition from OBR.2 in Ch. 7)
Definition: This field is identical to ORC-2-Placer Order Number.
This field is a special case of the Entity Identifier data type (Chapter 2A, section 2.A.28). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (section 2.A.36, "HD – Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.
See ORC-2-placer order number (section 4.5.1.2) for information on when this field must be valued.
A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.
These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).
(Definition from TXA.14 in Ch. 9)
Definition: This field is the placer application's order number.
This is a composite field. The first component is a string of characters that identifies an individual order (i.e., OBR). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the (filler) assigning authority of the placing application. The (filler) assigning authority is a string of characters that will be uniquely associated with an application. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique entity identifiers. The components are separated by component delimiters.
TXA-14 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-2 or OBR-2 is valued, this field must be blank. If TXA-14 is valued while ORC-2 or OBR-2 is valued it shall be ignored. See message definitions including TXA for further guidance on which ORC/OBR pairs to consider.
(Definition from ARQ.24 in Ch. 10)
Definition: This field is the placer application's order number for the order associated with this scheduling request.
This field is described in detail in Chapter 4, section 4.5.1.2, "ORC-2 – Placer Order Number." It is an optional field, but if a Placer order number is present, then a Filler order number (ARQ-25 – Filler Order Number) must also be present.
(Definition from SCH.26 in Ch. 10)
Definition: This field is the placer application's order number for the order associated with this scheduling filler application response.
This field is described in detail in Section 4.5.1.2. It is an optional field, but if a Placer order number is present, then a Filler order number (Section 10.6.2.27) must also be present. Both this field and the Filler order number below may have been sent as part of the appointment request in the ARQ segment or they may be assigned by the scheduling filler application only.
(Definition from ORC.3 in Ch. 4)
Definition: This field is the order number associated with the filling application. It is a case of the Entity Identifier data type (Section 2.A.28). Its first component is a string that identifies an order detail segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filler (receiving) application. This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.
The second through fourth components contain the filler application ID, in the form of the HD data type (see Section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.
A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third- party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the filler application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). Note that if both ORC-2 and OBR-2 are valued, then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments. It is recommended that the initiating system should provide a unique number for the placer order number when a new order is placed or a unique number for the filler order number when an unsolicited result is initially communicated.
The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.
Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.
(Definition from OBR.3 in Ch. 4)
Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI – entity identifier").
The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.
The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.
See ORC-3-filler order number for information on when this field must be valued.
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.
The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.
Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.
(Definition from FT1.23 in Ch. 6)
Definition: This field is used when the billing system is requesting observational reporting justification for a charge. This is the number used by a filler to uniquely identify a result. See Chapter 4 for a complete description.
(Definition from OBR.3 in Ch. 7)
Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI – entity identifier").
The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.
The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.
See ORC-3-filler order number for information on when this field must be valued.
The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.
From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.
If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.
It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.
The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.
Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.
(Definition from TXA.15 in Ch. 9)
Definition: This field is the order number associated with the filling application. Where a transcription service or similar organization creates the document and uses an internally unique identifier, that number should be inserted in this field. Its first component is a string of characters that identifies an order detail segment (i.e., OBR). This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (i.e., transcription service). This uniqueness must persist over time. Where a number is reused over time, a date can be affixed to the non-unique number to make it unique.
The second through fourth components contains the (filler) assigning authority. The (filler) assigning authority is a string of characters that uniquely defines the application from other applications on the network. The second through fourth components of the filler order number always identify the actual filler of an order.
TXA-15 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-3 or OBR-3 is valued, this field must be blank. If TXA-14 is valued while ORC-3 or OBR-3 is valued it shall be ignored. See message definitions including TXA for further guidanceon which ORC/OBR pairs to consider.
For further details, please see the definitions provided in Chapter 4, "Orders".
(Definition from ARQ.25 in Ch. 10)
Definition: This field is the order number assigned by the filler application for the order associated with this scheduling request.
This field is described in detail in Chapter 4, section 4.5.1.3, "ORC-3 – Filler Order Number.” It is conditionally mandatory depending on the presence of the Placer order number (ARQ-24 – Placer Order Number). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the filler application before scheduling the resources associated with that order.
(Definition from SCH.27 in Ch. 10)
Definition: This field is the order number assigned by the filler application for the order associated with this scheduling filler response.
This field is described in detail in Chapter 4, Orders, section 4.5.1.3. It is conditionally mandatory depending on the presence of the placer order number (section 10.6.2.26). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the order filler application before scheduling the resources associated with that order.
Definition: This field contains a unique name assigned to a document by the sending system. The file name is used to assist the receiving system in matching future updates to the document.
Definition: This field identifies the current completion state of the document. This is a required, table-driven field. Refer to HL7 Table 0271 - Document Completion Status for valid values.
Figure 9-1. Document completion status state transition table
|
Transition (Action) |
Old State |
New State |
|
T01 Original Notification T02 Original Notification and Content |
NA |
Dictated In Progress Incomplete Pre-authenticated Authenticated Legally authenticated |
|
T03 Status Change Notification T04 Status Change Notification and Content |
Dictated |
In Progress Incomplete Pre-authenticated Authenticated Legally authenticated |
|
In Progress |
Incomplete Pre-authenticated Authenticated Legally authenticated |
|
|
Incomplete |
Pre-authenticated Authenticated Legally authenticated |
|
|
Pre-authenticated |
Authenticated Legally authenticated |
|
|
Authenticated |
Legally authenticated |
|
|
Legally authenticated |
NA |
|
|
Documented |
Pre-authenticated Authenticated Legally authenticated |
|
|
T05 Addendum Notification T06 Addendum Notification and Content |
NA |
Dictated In Progress Incomplete Pre-authenticated Authenticated Legally authenticated |
|
T07 Edit Notification T08 Edit Notification and Content |
Dictated |
In Progress Incomplete Pre-authenticated Authenticated Legally authenticated |
|
In Progress |
Incomplete Pre-authenticated Authenticated Legally authenticated |
|
|
Incomplete |
Pre-authenticated Authenticated Legally authenticated |
|
|
Pre-authenticated |
Authenticated Legally authenticated |
|
|
Authenticated |
Legally authenticated |
|
|
Legally authenticated |
NA |
|
|
Documented |
Pre-authenticated Authenticated Legally authenticated |
|
|
T09 Replacement Notification T10 Replacement Notification and Content |
NA |
Dictated In Progress Incomplete Pre-authenticated Authenticated Legally authenticated |
|
T11 Cancel Notification |
Dictated |
Canceled |
Definition: This is an optional field which identifies the degree to which special confidentiality protection should be applied to this information. The assignment of data elements to these categories is left to the discretion of the healthcare organization. Refer to HL7 Table 0272 - Document Confidentiality Status for valid values.
Definition: This is an optional field which identifies a document's availability for use in patient care. If an organization's business rules allow a document to be used for patient care before it is authenticated, the value of this field should be set to "AV." If a document has been made available for patient care, it cannot be changed or deleted. If an erroneous document has been made available at any point in time and a replacement is not appropriate, then it may be marked as "Canceled" and removed, as in the case of a document being assigned to the wrong patient. Additional information must be provided via an addendum, which is separately authenticated and date/time stamped. If the content of a document whose status is "Available" must be revised, this is done by issuing a replacement, which is separately authenticated and date/time stamped. Refer to HL7 Table 0273 - Document Availability Status for valid values.
Figure 9-2. Document availability status state transition table
|
Transition (Action) |
Old State |
New State |
Notes |
|
T01 Original Notification T02 Original Notification and Content |
NA |
Unavailable Available |
|
|
T03 Status Change Notification T04 Status Change Notification and Content |
Unavailable |
Unavailable Available Obsolete |
|
|
Available |
Available Obsolete |
||
|
Obsolete |
NA |
||
|
T05 Addendum Notification T06 Addendum Notification and Content |
NA |
Unavailable Available |
|
|
T07 Edit Notification T08 Edit Notification and Content |
Unavailable |
Unavailable Available |
|
|
T09 Replacement Notification T10 Replacement Notification and Content |
NA |
Unavailable Available |
Set parent document to "obsolete" |
|
T11 Cancel |
Unavailable |
Delete |
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.
Definition: This free text field (limited to 30 characters) contains the reason for document status change.
Definition: This field contains a set of components describing by whom and when authentication was performed (either manually or electronically). The Date/Time Action Performed component describes the date/time of the authentication (Authentication Time Stamp). The remaining components identify the person performing the authentication (Authentication Person). If either of the Authenticating Person or the Authentication Time Stamp is valued as non-null, then both must be valued as non-null.
TXA-22 - Condition: If TXA-22 is valued and the corresponding OBR segment is present in the message OBR-32 must be blank. If OBR-32 is valued while TXA-22 is valued, OBR-32 shall be ignored. See message definitions including TXA for further guidanceon which ORC/OBR pairs to consider.
Definition: This field identifies the persons who received a copy of this document.
Definition: This field is used to assign documents to folders. These folders are not nested; a document may either be part of none or several folders. In practice this can be used to separate the documents into domain specific types (e.g., cardiology reports, radiology reports), organizational types (e.g., administrational document, billing document), body region types (e.g., chest CT, leg CT), or something else. Furthermore, this information can be combined. This usually depends on the system involved and therefore it must be up to the user to define it. The systems can use the information to define workflows or manage access to the document. Receivers are required to inspect the Coding System component of the CWE data type to accurately interpret the meaning of the code. Senders transmitting messages to Receivers on earlier version of the standard may elect to negotiate business rules to ensure that expected data is not lost. HL7 does not assign positional meaning to user-defined codes. Refer to Table 0791 - Folder Assignment in Chapter 2C for valid values.
Definition: This field supports the identification of the document title. When communicating the meta information without the document contents you may submit the document title as well.
Definition: This field contains the date and time the document is or will be due back to the original author or dictator from the transcriptionist.
Definition: This field identifies the facility in which this document has been created.
Definition: This field identifies the specialty of the provider which created this document. Refer to Table 0792 - Creating Specialty in Chapter 2C for valid values.
Note: There are on suggested values for speciality.
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^Seven^Henry^L^ ^Dr^MD^| <cr>
PID|...<cr>
PR1|...<cr>
TXA|0001|HP^history & physical|TX^text|19960213213000|099919^Everyman^Adam^A^ ^Mr^MS^|
19960213153000|19960215134500||099919^Everyman^Adam^A^III^Mr^MS^|097220^Seven^Henry^L^ ^Dr^MD^|01234567^Contact^Carrie^C^Ms|1996021500001^transA|||example.doc|LA|UC|AV||AC|||||097220^Seven^Henry^L^ ^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.
Hospital A creates a psychiatric report. It sends a notification to hospital B.
MSH|^~VALUEamp;|SENDAPP|SENDFAC|RECAPP|RECFAC|200411261008||MDM^T01^MDM_T01|167865|P|2.9
EVN|T01|200811261007|200811261007|60012|10107
PID|1|1011684|1011684||Jurgensen^Antoine^^||197710220000|F|||Hubertweg^^Stuttgart^^70173^DE|||||M|CAT||4390271065||||Karlsruhe|N||
PV1|1|I|STATION^^^3200^^13372100|A^^301||||||||||||N|||0460005110||K|||||||||||||||||||||||200811160916|||||
TXA|1|Psychiatric Disabilities Report|PDF|||||20081126100756 ||||570531^SENDFAC||||1081007_2874942_570531_26100756.PDF|DO|||||||PSY^psychiatric document^^1.2.4481222~WEB^web document^^1.2.4481223
Hospital B receives the document. Hospital A and B have negotiated the folder definitions in the form of a catalog (the exchange is out of scope of this document). Therefore, Hospital B knows the document should only be accessible to psychiatrists and should be available in the patient's personal web access. This is only an example; document folder interpretation is up to the systems and out of scope of this proposal.
A query may be used to retrieve a list of documents or a specific document. See Chapter 5, "Queries", for details of queries.
Withdrawn in v2.7 and later; refer to Chapter 5, "Queries", section 5.4 instead.
This version of the standard clarifies the use of MDM message as opposed to ORU messages. Refer to Chapter 7, "Observations".
®© HL7.org 2019+. HL7 v2+ generated on December 11, 2020
Links:
Version History
|
Propose a change
|
License
The Demo site for our new HL7 Version 2+ (plus) Standard
