Class TbsAD_28 |
Address |
Class TbsAUI_28 |
Authorization Information |
Class TbsCCD_28 |
Charge Code And Date |
Class TbsCCP_28 |
Channel Calibration Parameters |
Class TbsCD_28 |
Channel Definition |
Class TbsCF_28 |
Coded Element With Formatted Values |
Class TbsCNE_28 |
Coded With No Exceptions |
Class TbsCNN_28 |
Composite Id Number And Name Simplified |
Class TbsCP_28 |
Composite Price |
Class TbsCQ_28 |
Composite Quantity With Units |
Class TbsCSU_28 |
Channel Sensitivity And Units |
Class TbsCWE_28 |
Coded With Exceptions |
Class TbsCX_28 |
Extended Composite Id With Check Digit |
Class TbsDDI_28 |
Daily Deductible Information |
Class TbsDIN_28 |
Date And Institution Name |
Class TbsDLD_28 |
Discharge To Location And Date |
Class TbsDLN_28 |
Driver's License Number |
Class TbsDLT_28 |
Delta |
Class TbsDR_28 |
Date/time Range |
Class TbsDT_28 |
|
Class TbsDTM_28 |
|
Class TbsDTN_28 |
Day Type And Number |
Class TbsED_28 |
Encapsulated Data |
Class TbsEI_28 |
Entity Identifier |
Class TbsEIP_28 |
Entity Identifier Pair |
Class TbsERL_28 |
Error Location |
Class TbsFC_28 |
Financial Class |
Class TbsFN_28 |
Family Name |
Class TbsFT_28 |
|
Class TbsGTS_28 |
|
Class TbsHD_28 |
Hierarchic Designator |
Class TbsICD_28 |
Insurance Certification Definition |
Class TbsID_28 |
|
Class TbsIS_28 |
|
Class TbsJCC_28 |
Job Code/class |
Class TbsMA_28 |
Multiplexed Array |
Class TbsMO_28 |
Money |
Class TbsMOC_28 |
Money And Code |
Class TbsMOP_28 |
Money Or Percentage |
Class TbsMSG_28 |
Message Type |
Class TbsNA_28 |
Numeric Array |
Class TbsNDL_28 |
Name With Date And Location |
Class TbsNM_28 |
|
Class TbsNR_28 |
Numeric Range |
Class TbsOCD_28 |
Occurrence Code And Date |
Class TbsOSP_28 |
Occurrence Span Code And Date |
Class TbsPIP_28 |
Practitioner Institutional Privileges |
Class TbsPL_28 |
Person Location |
Class TbsPLN_28 |
Practitioner License Or Other Id Number |
Class TbsPPN_28 |
Performing Person Time Stamp |
Class TbsPRL_28 |
Parent Result Link |
Class TbsPT_28 |
Processing Type |
Class TbsPTA_28 |
Policy Type And Amount |
Class TbsQIP_28 |
Query Input Parameter List |
Class TbsQSC_28 |
Query Selection Criteria |
Class TbsRCD_28 |
Row Column Definition |
Class TbsRFR_28 |
Reference Range |
Class TbsRI_28 |
Repeat Interval |
Class TbsRMC_28 |
Room Coverage |
Class TbsRP_28 |
Reference Pointer |
Class TbsRPT_28 |
Repeat Pattern |
Class TbsSAD_28 |
Street Address |
Class TbsSCV_28 |
Scheduling Class Value Pair |
Class TbsSI_28 |
|
Class TbsSN_28 |
Structured Numeric |
Class TbsSNM_28 |
|
Class TbsSPD_28 |
Specialty Description |
Class TbsSRT_28 |
Sort Order |
Class TbsST_28 |
|
Class TbsTM_28 |
|
Class TbsTX_28 |
|
Class TbsUVC_28 |
Ub Value Code And Amount |
Class Tbsvaries_28 |
|
Class TbsVH_28 |
Visiting Hours |
Class TbsVID_28 |
Version Identifier |
Class TbsVR_28 |
Value Range |
Class TbsWVI_28 |
Channel Identifier |
Class TbsWVS_28 |
Waveform Source |
Class TbsXAD_28 |
Extended Address |
Class TbsXCN_28 |
Extended Composite Id Number And Name For Persons |
Class TbsXON_28 |
Extended Composite Name And Identification Number For Organizations |
Class TbsXPN_28 |
Extended Person Name |
Class TbsXTN_28 |
Extended Telecommunication Number |
Class TbsABS_28 |
Abstract This segment was created to communicate patient abstract information used for billing and reimbursement purposes. “Abstract” is a condensed form of medical history created for analysis, care planning, etc. |
Class TbsACC_28 |
Accident The ACC segment contains patient information relative to an accident in which the patient has been involved. |
Class TbsADD_28 |
Addendum The ADD segment is used to define the continuation of the prior segment in a continuation message. See Section 2.10.2, "Continuation messages and segments," for details. |
Class TbsADJ_28 |
Adjustment This segment describes Provider and/or Payer adjustments to a Product/Service Line Item or Response Summary. These include surcharges such as tax, dispensing fees and mark ups. X12 REF: Similar to CAS segment, with a few new fields. |
Class TbsAFF_28 |
Professional Affiliation The AFF segment adds detailed information regarding professional affiliations with which the staff member identified by the STF segment is/was associated. |
Class TbsAIG_28 |
Appointment Information - General Resource The AIG segment contains information about various kinds of resources (other than those with specifically defined segments in this chapter) that can be scheduled. Resources included in a transaction using this segment are assumed to be controlled by a schedule on a schedule filler application. Resources not controlled by a schedule are not identified on a schedule request using this segment. Resources described by this segment are general kinds of resources, such as equipment, that are identified with a simple identification code. |
Class TbsAIL_28 |
Appointment Information - Location Resource The AIL segment contains information about location resources (meeting rooms, operating rooms, examination rooms, or other locations) that can be scheduled. Resources included in a transaction using this segment are assumed to be controlled by a schedule on a schedule filler application. Resources not controlled by a schedule are not identified on a schedule request using this segment. Location resources are identified with this specific segment because of the specific encoding of locations used by the HL7 specification. |
Class TbsAIP_28 |
Appointment Information - Personnel Resource The AIP segment contains information about the personnel types that can be scheduled. Personnel included in a transaction using this segment are assumed to be controlled by a schedule on a schedule filler application. Personnel not controlled by a schedule are not identified on a schedule request using this segment. The kinds of personnel described on this segment include any healthcare provider in the institution controlled by a schedule (for example: technicians, physicians, nurses, surgeons, anesthesiologists, or CRNAs). |
Class TbsAIS_28 |
Appointment Information The AIS segment contains information about various kinds of services that can be scheduled. Services included in a transaction using this segment are assumed to be controlled by a schedule on a schedule filler application. Services not controlled by a schedule are not identified on a schedule request using this segment. |
Class TbsAL1_28 |
Patient Allergy Information The AL1 segment contains patient allergy information of various types. Most of this information will be derived from user-defined tables. Each AL1 segment describes a single patient allergy. |
Class TbsAPR_28 |
Appointment Preferences The APR segment contains parameters and preference specifications used for requesting appointments in the SRM message. It allows placer applications to provide coded parameters and preference indicators to the filler application, to help determine when a requested appointment should be scheduled. An APR segment can be provided in conjunction with either the ARQ segment or any of the service and resource segments (AIG, AIS, AIP, and AIL). If an APR segment appears in conjunction with an ARQ segment, its parameters and preference indicators pertain to the schedule request as a whole. If the APR segment appears with any of the service and resource segments, then its parameters and preferences apply only to the immediately preceding service or resource. |
Class TbsARQ_28 |
Appointment Request The ARQ segment defines a request for the booking of an appointment. It is used in transactions sent from an application acting in the role of a placer. |
Class TbsARV_28 |
Access Restriction The ARV segment is used to communicate the requested/required type of access restrictions from system to system, at both the person/patient and the encounter/visit level. Examples: A person/patient may have the right to object to any or all of his/her information to be disclosed. In addition, the patient may request that protected information not be disclosed to family members or friends who may be involved in their care or for notification purposes. A realm or organization may have certain privacy policies. A patient may have the right to opt out of being included on facility directories. In an international context, a physician may be culturally obligated to protect the patient's privacy. Any "opt-in" or "opt-out" restrictions are communicated in ARV-3 - Access Restriction Value. This segment replaces PD1-12 and PV2-22, which have been deprecated in V2.6. The ARV segment is optional and is sent after the PID/PD1 segments to describe access restrictions associated with the person/patient. The ARV segment is optional and is sent after the PV1/PV2 segments to describe access restrictions associated with that specific encounter. Usage Notes: The individual system security may want to utilize the Access Restriction Value along with the Access Restriction Reason (and/or with the Confidentiality Code from another segment, e.g., OM1-30 or other data) in order to implement the appropriate type of protection for the person, patient, visit and/or visit data. Each system has the flexibility to incorporate/map the access values into their security system appropriately; the actual implementation for access to protected data is determined by the individual system. The Access Restriction Values supported by an enterprise/system would be defined and determined by that organization. It is expected that these access restriction values would be utilized in combination with other system security information (e.g., patient locations, user department, caregiver-patient relationships, other access restriction parameters) to determine user access. System implementers should carefully control access to the restriction codes and values, as they themselves hold sensitive information. |
Class TbsAUT_28 |
Authorization Information This segment represents an authorization or a pre-authorization for a referred procedure or requested service by the payor covering the patient's health care. |
Class TbsBHS_28 |
Batch Header The BHS segment defines the start of a batch. |
Class TbsBLC_28 |
Blood Code The BLC segment contains data necessary to communicate patient abstract blood information used for billing and reimbursement purposes. This segment is repeating to report blood product codes and the associated blood units. |
Class TbsBLG_28 |
Billing The BLG segment is used to provide billing information, on the ordered service, to the filling application. |
Class TbsBPO_28 |
Blood Product Order Blood product order messages require additional information that is not available in other standard HL7 order messages. Blood product order messages need to contain accompanying details regarding the blood product component, such as special processing requirements (e.g., irradiation and leukoreduction) and the amount of the blood product to be administered. |
Class TbsBPX_28 |
Blood Product Dispense Status In the processing of blood products, it is necessary for the transfusion service and the placer system to communicate information. The status messages need to contain additional information regarding the blood products requested, such as the unique donation ID, product code, blood type, expiration date/time of the blood product, and current status of the product. This segment is similar to an OBX segment, but contains additional attributes. The BP prefix in the element name indicates that the attribute pertains to any type of blood product. A blood product is defined as any type of blood component or commercially prepared blood product that is prepared and dispensed from the transfusion service. The BC prefix in the element name indicates that the attribute pertains only to blood components. A blood component is defined as the whole or any part of a blood donation. For example, from one whole blood donation, the unit of whole blood can be fractionated into red blood cells, plasma and platelets with each component contained in separate bags. These types of blood products are assigned a unique donation identification number as well as a product code that indicates the type of component contained in the bag. The CP prefix in the element name indicates that the attribute pertains only to Commercial Products. A commercial product is defined as a commercially manufactured product, such as blood derivatives ( Rh Immune Globulin, Factor VIII Concentrate or Blood Recipient Sets or Filters). These types of products are tracked by manufacturer and lot number and are not necessarily assigned a unique donation number. |
Class TbsBTS_28 |
Batch Trailer The BTS segment defines the end of a batch. |
Class TbsBTX_28 |
Blood Product Transfusion/disposition The BP prefix in the element name indicates that the attribute pertains to any type of blood product. A blood product is defined as any type of blood component or commercially prepared blood product that is prepared and dispensed from the transfusion service. The BC prefix in the element name indicates that the attribute pertains only to blood components. A blood component is defined as any part or all of a whole blood donation. For example, from one whole blood donation, the unit of whole blood can be fractionated into red blood cells, plasma and platelets with each component contained in separate bags. These types of blood products are always assigned a unique donation identification number as well as a product code that indicates the type of component contained in the bag. The CP prefix in the element name indicates that the attribute pertains only to Commercial Products. A commercial product is defined as a commercially manufactured product, such as blood derivatives (Rh Immune Globulin, Factor VIII Concentrate or Blood Recipient Sets or Filters). These types of products are tracked by manufacturer and lot number and are not necessarily assigned a unique donation number. |
Class TbsBUI_28 |
Blood Unit information Segment The intent of this segment is to describe the information associated with a blood unit, one example of which is one or more blood unit(s) resulting from a donation |
Class TbsCDM_28 |
Charge Description Master The CDM segment contains the fields for identifying anything which is charged to patient accounts, including procedures, services, supplies. It is intended to be used to maintain a list of valid chargeable utilization items. Its purpose is to keep billing codes synchronized between HIS, Patient Accounting, and other departmental systems. It is not intended to completely support materials management, inventory, or complex pricing structures for which additional complex fields would be required. Given an identifying charge code, the associated fields in the charge description master file will provide basic pricing and billing data. All the additional information necessary for patient accounting systems to do billing and claims is not intended to be included in this segment; those should be part of insurance or billing profile tables. The CDM segment contains the fields which, for one chargeable item, remain the same across facilities, departments, and patient types. The following PRC segment contains the fields which, for the same chargeable item, vary depending upon facility or department or patient type. |
Class TbsCDO_28 |
Cumulative Dosage The Cumulative Dosage segment allows for the communication of cumulative dosage limits that administrations against this medication order should stay within. As part of one of the pharmacy messages, one may want to indicate one or more limits that apply, e.g., limit for the duration of the order, lifetime limit, or weekly limit |
Class TbsCER_28 |
Certificate Detail The CER segment adds detailed information regarding the formal authorizations to provide a service (e.g. licenses, certificates) held by the health professional identified by the STF segment. |
Class TbsCM0_28 |
Clinical Study Master The Clinical Study Master (CM0) segment contains the information about the study itself. The sending application study number for each patient is sent in the CSR segment. The optional CM0 enables information about the study at the sending application that may be useful to the receiving systems. All of the fields in the segment describe the study status at the sending facility unless otherwise agreed upon. |
Class TbsCM1_28 |
Clinical Study Phase Master Each Clinical Study Phase Master (CM1) segment contains the information about one phase of a study identified in the preceding CM0. This is an optional structure to be used if the study has more than one treatment or evaluation phase within it. The identification of study phases that the patient enters are sent in the CSP segment: sequence 2. The CM1 segment describes the phase in general for the receiving system. |
Class TbsCM2_28 |
Clinical Study Schedule Master The Clinical Study Schedule Master (CM2) contains the information about the scheduled time points for study or phase-related treatment or evaluation events. The fact that a patient has data satisfying a scheduled time point is sent in the CSS segment, sequence 2. The CM2 segment describes the scheduled time points in general. |
Class TbsCNS_28 |
Clear Notification The clear equipment notification segment contains the data necessary to allow the receiving equipment to clear any associated notifications. |
Class TbsCON_28 |
Consent Segment 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). |
Class TbsCSP_28 |
Clinical Study Phase The CSP segment contains information on a patient’s status for a particular phase of the study. This segment is optional and is useful when a study has different evaluation intervals within it. (See section 7.7.1, "HL7 Attribute Table - CSR - Clinical Study Registration," and section 7.5.1.2, "Phase of a clinical trial:.") The CSP segment is implemented on a study-specific basis for messaging purposes. The fact that the patient has entered a phase of the study that represents a certain treatment approach may need to be messaged to other systems, like pharmacy, nursing, or order entry. It is also important to sponsors and data management centers for tracking patient progress through the study and monitoring the data schedule defined for each phase. It may subsume OBR and OBX segments that follow it to indicate that these data describe the phase. |
Class TbsCSR_28 |
Clinical Study Registration The CSR segment will contain fundamental administrative and regulatory information required to document a patient’s enrollment on a clinical trial. This segment is all that is required if one needs to message another system that an enrollment has taken place, i.e., from clinical trials to pharmacy, accounting, or order entry systems. The CSR segment may also be used to identify that OBR, OBX, RXA, and RXR segments that follow represent data applicable to the identified study. |
Class TbsCSS_28 |
Clinical Study Data Schedule Segment The Clinical Study Data Schedule (CSS) segment is optional depending on whether messaging of study data needs to be linked to the scheduled data time points for the study. (See Section 7.5.1.3, "Data schedule:".) The CSS segment enables communication of data schedules and adherence that ranges from the basic to the elaborate. Use of the segment must be planned for each implementation. Each CSS segment will subsume observation and drug administration segments that follow, indicating that they satisfy this scheduled time point. |
Class TbsCTD_28 |
Contact Data The CTD segment may identify any contact personnel associated with a patient referral message and its related transactions. The CTD segment will be paired with a PRD segment. The PRD segment contains data specifically focused on provider information in a referral. While it is important in an inter-enterprise transaction to transmit specific information regarding the providers involved (referring and referred-to), it may also be important to identify the contact personnel associated with the given provider. For example, a provider receiving a referral may need to know the office manager or the billing person at the institution of the provider who sent the referral. This segment allows for multiple contact personnel to be associated with a single provider. |
Class TbsCTI_28 |
Clinical Trial Identification The CTI segment is an optional segment that contains information to identify the clinical trial, phase and time point with which an order or result is associated. |
Class TbsDB1_28 |
Disability The disability segment contains information related to the disability of a person. This segment was created instead of adding disability attributes to each segment that contains a person (to which disability may apply). This is an optional segment that can be used to send disability information about a person already defined by the Patient Administration Chapter. The disabled person code and identifier allow for the association of the disability information to the person. |
Class TbsDG1_28 |
Diagnosis The DG1 segment contains patient diagnosis information of various types, for example, admitting, primary, etc. The DG1 segment is used to send multiple diagnoses (for example, for medical records encoding). It is also used when the FT1-19 - Diagnosis Code - FT1 does not provide sufficient information for a billing system. This diagnosis coding should be distinguished from the clinical problem segment used by caregivers to manage the patient (see Chapter 12, Patient Care). Coding methodologies are also defined. |
Class TbsDMI_28 |
Drg Master File Information The DMI segment contains the DRG related basic information, for example, relative weight, etc. The DMI segment is used to send the fixed information assigned to a specific DRG. |
Class TbsDON_28 |
Donation Segment The intent of this segment is to describe the actual donation procedure. |
Class TbsDRG_28 |
Diagnosis Related Group The DRG segment contains diagnoses-related grouping information of various types. The DRG segment is used to send the DRG information, for example, for billing and medical records encoding. |
Class TbsDSC_28 |
Continuation Pointer The DSC segment is used in the continuation protocol. |
Class TbsDSP_28 |
Display Data The DSP segment is used to contain data that has been preformatted by the sender for display. The semantic content of the data is lost; the data is simply treated as lines of text. |
Class TbsECD_28 |
Equipment Command The equipment command segment contains the information required to notify the receiving component what is to happen. |
Class TbsECR_28 |
Equipment Command Response The equipment command response segment contains the receiving component's response to the previously received command. |
Class TbsEDU_28 |
Educational Detail The EDU segment adds detailed educational information to the staff member identified by the STF segment. An EDU segment may optionally follow an STF segment. An EDU segment must always have been preceded by a corresponding STF segment. |
Class TbsEQP_28 |
Equipment/log Service The equipment log/service segment is the data necessary to maintain an adequate audit trail of events that have occurred on a particular piece of equipment. |
Class TbsEQU_28 |
Equipment Detail The equipment detail segment contains the data necessary to identify and maintain the equipment that is being used throughout the Laboratory Automation System. |
Class TbsERR_28 |
Error The ERR segment is used to add error comments to acknowledgment messages. Use Cases: Severity: A receiving application needs to communicate 2 "error or exception statements." One is an "error;" the other is a "warning". To accomplish this, an acknowledgement message with 2 ERR segments is sent. Upon receipt, the sending application can display both, including the appropriate severity, to the user. Application Error Code: A receiving application generates an error that reports an application error code and returns this information in its response. This code in turn is used by helpdesk staff to pinpoint the exact cause of the error, or by the application to prompt an appropriate response from the user. (Ex. Deceased date must be greater than or equal to birth date). Application Error Parameter: A receiving application encounters an error during processing of a transaction. In addition to an error code, the application provides an error parameter that gives greater detail as to the exact nature of the error. The receiving application looks up the message corresponding to the error code, substitutes in the parameter, and displays the resulting message to the user. Diagnostic Information: While processing a transaction, a receiving application encounters an exception. When the exception is thrown, it provides a volume of detailed information relating to the error encountered. The receiving application captures the information and sends it in its response. The user reports the error to the help desk, and on request, faxes a copy of the diagnostic information to assist analyzing the problem. User Message: A user executes an application function that generates a transaction that is sent to another application for further processing. During this processing, the receiving application encounters an error and, as part of the error handling routine, retrieves a User Message that it returns in its response. The originating application receives the error and displays it to the end user with the intent that the error condition can be resolved and the user can re-execute the function without error. Inform Person Code: After submitting a dispense transaction, a response is returned to the user indicating that the patient may be abusing drugs. Given the sensitivity of this warning, the error is returned with an indicator stating that the patient should not be informed of the error with the implication that steps should be taken to rule out or confirm the warning. Override Type: If a business rule states that a prescription on hold cannot be dispensed, an override type might be "Dispense Held Prescription" to allow the prescription to be dispensed in exception to the rule. Override Reason Codes: A patient is given a prescription; however, before completing the prescription, the remaining pills are spoiled. The patient returns to their pharmacy and explains the situation to their pharmacist. The pharmacist decides to replace the spoiled drugs; however, when attempting to record the event, a message is returned indicating that the dispense would exceed the maximum amount prescribed. The pharmacist overrides the rule and specifies an Override Reason Code indicating a replacement of lost product. Help Desk Contact: Help desk contact information is stored in a database. When an application error is encountered, the database is queried and the most current help desk contact information is returned in the error message. This is displayed to the user by the receiving application. Better Error Location Information: Receiving system detects an error with the 3rd repetition of the ROL.4 (Role Person - XCN).16 (Name Context - CE).4(Alternate Identifier - CWE). The application identifies the specific repetition and component when raising the error, simplifying diagnosis of the problem. Support for multiple Error Locations: Two fields are marked as conditional, with the condition that one of the two must be specified. The sending application leaves both blank. The receiving application detects the problem, and sends back a single error indicating that one of the fields must be filled in. The ERR segment identifies both positions within the message that relate to the error. |
Class TbsEVN_28 |
Event Type The EVN segment is used to communicate necessary trigger event information to receiving applications. Valid event types for all chapters are contained in HL7 Table 0003 - Event Type. |
Class TbsFAC_28 |
Facility This segment is maintained for backwards compatibility only as of V2.7. |
Class TbsFHS_28 |
File Header The FHS segment is used to head a file (group of batches) as defined in Section 2.10.3, "HL7 batch protocol". |
Class TbsFT1_28 |
Financial Transaction The FT1 segment contains the detail data necessary to post charges, payments, adjustments, etc., to patient accounting records. |
Class TbsFTS_28 |
File Trailer The FTS segment defines the end of a file. |
Class TbsGOL_28 |
Goal Detail The goal detail segment contains the data necessary to add, update, correct, and delete the goals for an individual. |
Class TbsGP1_28 |
Grouping/reimbursement - Visit These fields are used in grouping and reimbursement for CMS APCs. Please refer to the "Outpatient Prospective Payment System Final Rule" ("OPPS Final Rule") issued by CMS. The GP1 segment is specific to the US and may not be implemented in non-US systems. |
Class TbsGP2_28 |
Grouping/reimbursement - Procedure Line Item This segment is used for items that pertain to each HCPC/CPT line item. The GP2 segment is specific to the US and may not be implemented in non-US systems |
Class TbsGT1_28 |
Guarantor The GT1 segment contains guarantor (e.g., the person or the organization with financial responsibility for payment of a patient account) data for patient and insurance billing applications. |
Class TbsHxx_28 |
Any Hl7 Segment |
Class TbsIAM_28 |
Patient Adverse Reaction Information The IAM segment contains person/patient adverse reaction information of various types. Most of this information will be derived from user-defined tables. Each IAM segment describes a single person/patient adverse reaction. This segment is used in lieu of the AL1 - Patient Allergy Information Segment to support action code/unique identifier mode update definition of repeating segments as defined in 2.10.4.2 in chapter 2, section 2.4.10, "Protocol for interpreting repeating segments or segment groups in an update Message." The AL1 segment is used to support Snapshot mode update definition as defined in 2.10.4.1. |
Class TbsIAR_28 |
Allergy Reaction The IAR segment is used to transmit a single reaction and information associated with this single reaction occurrence for a particular patient allergy (IAM - patient adverse reaction). |
Class TbsIIM_28 |
Inventory Item Master The Inventory Item Master segment (IIM) contains information about the stock of product that can be used to fulfill an ordered test/service. All of the fields in this segment describe the test/service and other basic attributes pertaining to Service Item defined within an Other Observation/Service Item master file. This segment is related to centrally stocked or supply management concerns. |
Class TbsILT_28 |
Material Lot The Material Lot segment (ILT) contains material information specific to a lot within an inventory location associated with the item in the IVT segment. This segment is similar to the IIM segment used with the limited inventory item master message. Note that on-hand quantities do NOT refer to a continuously updated quantity. The expectation is for periodic physical inventory. |
Class TbsIN1_28 |
Insurance The IN1 segment contains insurance policy coverage information necessary to produce properly pro-rated and patient and insurance bills. |
Class TbsIN2_28 |
Insurance Additional Information The IN2 segment contains additional insurance policy coverage and benefit information necessary for proper billing and reimbursement. Fields used by this segment are defined by CMS or other regulatory agencies. |
Class TbsIN3_28 |
Insurance Additional Information, Certification The IN3 segment contains additional insurance information for certifying the need for patient care. Fields used by this segment are defined by CMS, or other regulatory agencies. |
Class TbsINV_28 |
Inventory Detail The inventory detail segment is the data necessary to track the inventory of substances (e.g. reagent, tips, waste) on equipment. |
Class TbsIPC_28 |
Imaging Procedure Control Segment The IPC segment contains information about tasks that need to be performed in order to fulfill the request for imaging service. The information includes location, type and instance identification of equipment (acquisition modality) and stages (procedure steps). Note: References, field names and definitions in this section were developed in collaboration with DICOM with the goal of keeping HL7 transmission of imaging procedure control information consistent with the DICOM Standard, available at http://medical.nema.org. |
Class TbsIPR_28 |
Invoice Processing Results The Invoice Processing Results (IPR) segment provides summary information about an adjudicated Product/Service Group or Product/Service Line Item. |
Class TbsISD_28 |
Interaction Status Detail The interaction detail segment contains information about the status of specific interaction (e.g., processing — see section Glossary) on the specific equipment. |
Class TbsITM_28 |
Material Item The Material Item segment (ITM) contains information about inventory supply items (stocked or non-stocked). |
Class TbsIVC_28 |
Invoice Segment The Invoice segment is used for HealthCare Services Invoices and contains header style information for an invoice including invoice numbers, Provider Organization and Payer Organization identification. |
Class TbsIVT_28 |
Material Location The Material Location segment (IVT) contains information specific to an inventory location for the inventory supply item in the Material Item (ITM) segment. |
Class TbsLAN_28 |
Language Detail The LAN segment adds detailed language information to the staff member identified by the STF segment. An LAN segment may optionally follow an STF segment. An LAN segment must always have been preceded by a corresponding STF segment. |
Class TbsLCC_28 |
Location Charge Code The optional LCC segment identifies how a patient location room can be billed by a certain department. A department can use different charge codes for the same room or bed, so there can be multiple LCC segments following an LDP segment. |
Class TbsLCH_28 |
Location Characteristic The LCH segment is used to identify location characteristics which determine which patients will be assigned to the room or bed. It contains the location characteristics of the room or bed identified in the preceding LOC segment. There should be one LCH segment for each attribute. When the LCH segment appears immediately following the LOC segment, it communicates characteristics which are the same across multiple departments that may use the same room. When the LCH segment appears immediately following the LDP segment, it communicates characteristics which differ for different departments that may use the same room. For example, the following characteristics are more likely to vary by which department is using the room: teaching, gender, staffed, set up, overflow, whereas the other characteristics are likely to remain the same. |
Class TbsLDP_28 |
Location Department The LDP segment identifies how a patient location room is being used by a certain department. Multiple departments can use the same patient location, so there can be multiple LDP segments following an LOC segment. There must be at least one LDP segment for each LOC segment. This is not intended to include any current occupant information. |
Class TbsLOC_28 |
Location Identification The LOC segment can identify any patient location referenced by information systems. This segment gives physical set up information about the location. This is not intended to include any current occupant or current use information. There should be one LOC segment for each patient location. If desired, there can also be one LOC segment for each nursing unit and room. |
Class TbsLRL_28 |
Location Relationship The LRL segment is used to identify one location's relationship to another location, the nearest lab, pharmacy, etc. |
Class TbsMFA_28 |
Master File Acknowledgment |
Class TbsMFE_28 |
Master File Entry |
Class TbsMFI_28 |
Master File Identification |
Class TbsMRG_28 |
Merge Patient Information The MRG segment provides receiving applications with information necessary to initiate the merging of patient data as well as groups of records. It is intended that this segment be used throughout the Standard to allow the merging of registration, accounting, and clinical records within specific applications. The assigning authority, the fourth component of the patient identifiers, is an HD data type that is uniquely associated with the assigning authority that originally assigned the number. A given institution, or group of intercommunicating institutions, should establish a list of assigning authorities that may be potential assignors of patient identification (and other important identification) numbers. The list will be one of the institution's master dictionary lists. Since third parties (other than the assignors of patient identification numbers) may send or receive HL7 messages containing patient identification numbers, the assigning authority in the patient identification numbers may not be the same as those of the sending and receiving systems identified in the MSH. The assigning authority must be unique across applications at a given site. This field is required in HL7 implementations that have more than a single Patient Administration application assigning such numbers. |
Class TbsMSA_28 |
Message Acknowledgment The MSA segment contains information sent while acknowledging another message. |
Class TbsMSH_28 |
Message Header The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. |
Class TbsNCK_28 |
System Clock The NCK segment is used to allow the various applications on the network to synchronize their system clocks (system date and time). Usage Notes: If this message is to be used to automatically reset/correct system clocks, it is recommended that the system or administrative personnel initiating the NMQ with the NCK segment have the authority to correct the clock (system date and time) for the other systems on the network. This is important in order to avoid the obvious confusion of multiple systems attempting to resynchronize each other's clocks. If this message is used only to gather information on the various systems' clocks, it is still important for an administrative procedure to be worked out to avoid conflicts when resetting clocks. |
Class TbsNDS_28 |
|
Class TbsNK1_28 |
Next Of Kin / Associated Parties The NK1 segment contains information about the patient's other related parties. Any associated parties may be identified. Utilizing NK1-1 - set ID, multiple NK1 segments can be sent to patient accounts. If a person or organization fulfills multiple contact roles, for example, a person is an emergency contact and a next of kin, it is recommended to send a NK1 segment for each contact role (field 7). |
Class TbsNPU_28 |
Bed Status Update The NPU segment allows the updating of census (bed status) data without sending patient-specific data. An example might include changing the status of a bed from "housekeeping" to "unoccupied." |
Class TbsNSC_28 |
Application Status Change The NSC segment is used to inform (NMR query response) or announce (NMD unsolicited update) the start up, shut down, and/or migration (to a different CPU or file server/file system) of a particular application. Usage Notes: Fields 2-9. These are not applicable ("n/a") when the type of change being requested or reported is start-up or shut-down. If the change is of type "M", at least one of fields 2-5 must be different from its corresponding field in range 6-9. Fields 4-5, 8-9. See definitions for the MSH, message header segment, in Chapter 2, "Control Section," for fields 3-4, for system and facility. "Application" is available for interfacing with lower level protocols. "Facility" is entirely site-defined. Fields 2-3, 6-7: entirely site-defined. |
Class TbsNST_28 |
Application Control Level Statistics The NST segment allows application control-level statistical information to be passed between the various systems on the network. Some fields in this segment refer to portions of lower level protocols; they contain information that can be used by application management applications monitoring the state of various network links. Usage Notes: Fields 2-15. These are all marked optional since the statistics kept on a particular link and negotiated between the two systems in question will vary. Not all values will apply to each system. Some values are concerned with the type of port, and some values pertain to the lower level protocol. |
Class TbsNTE_28 |
Notes And Comments The NTE segment is defined here for inclusion in messages defined in other chapters. It is commonly used for sending notes and comments. The technical committees define the meaning of the NTE segments within the context of the messages in their chapters. For each NTE, the description in the message attribute table should include an indication of the segment associated with the NTE, for example "Notes and Comments for the PID". |
Class TbsOBR_28 |
Observation Request The Observation Request (OBR) segment is used to transmit information specific to an order for a diagnostic study or observation, physical exam, or assessment. The Observation Request segment defines the attributes of a particular request for diagnostic services (e.g., laboratory, EKG) or clinical observations (e.g., vital signs or physical exam). When a placer requests a given set of observations, always include an order segment. For lab tests, the information in the order segment usually applies to a single specimen. However, there is not a one-to-one relationship between specimen and tests ordered. Different test batteries will usually require their own order segments even when they can be performed on a single specimen. In this case, the specimen information must be duplicated in each of the order segments that employ that specimen. For other diagnostic studies, e.g., chest X-ray, a separate order segment will usually be generated for each diagnostic study. Though multiple observation batteries can be ordered on a single order segment, the observation filler shall generate a separate order segment for each battery that it processes independently, e.g., electrolyte, CBC, vital signs. When reporting the observations, the filling service shall copy the appropriate order (specimen) information from the original order segment into each of the new order segments so that a separate "order" segment is returned to the placer as a "header" for each separate battery of observations. In the event that an ordered battery of observations cannot be performed, e.g., because of hemolysis on a blood sample, an order segment will be returned to the placer with OBR-25-result status equal to X (to indicate that the study was not performed). In this case, no observation segments will be transmitted. When observations are successfully completed, the message returned to the placer will include the order segment (OBR) followed by observation (OBX) segments for each distinct observation generated by the order (see Chapter 7). The number of such observation segments will depend upon the number of individual measurements performed in the process. OBX segments can be sent by the placer along with an order to provide the filling service with clinical data needed to interpret the results. (See Chapter 7 for OBX details.) The daggered (+) items in this segment are created by the filler, not the placer. They are valued by the filler as needed when the OBR segment is returned as part of a report. The starred (*) fields are only relevant when an observation is associated with a specimen. These are completed by the placer when the placer obtains the specimen. They are completed by the filler when the filler obtains the specimen. OBR-7-observation date/time and OBR-8-observation end date/time (flagged with #) are the physiologically relevant times. In the case of an observation on a specimen, they represent the start and end of the specimen collection. In the case of an observation obtained directly from a subject (e.g., BP, Chest X-ray), they represent the start and end time of the observation. In the reporting of clinical data, the OBR serves as the report header. It identifies the observation set represented by the following atomic observations. It includes the relevant ordering information when that applies. It contains many of the attributes that usually apply to all of the included observations. When a set of observations is ordered, the order message contains an OBR segment. However, observations can be collected and reported without an antecedent order. When observations are reported, the report message also includes one or more OBR segments. So, the OBR segment is like a turn-around document. Some fields in the OBR segment apply only to the ordering message and some to the reporting message. To those familiar with healthcare procedures, these should be obvious from their names (e.g., transcriptionist or principal result interpreter could only apply to the reporting phase). However, we have also flagged them in the OBR HL7 Attribute Table to indicate whether placer, filler, or both may send data in a given field. |
Class TbsOBX_28 |
Observation/result The OBX segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a report. The OBX segment can also contain encapsulated data, e.g., a CDA document or a DICOM image. Its principal mission is to carry information about observations in report messages. But the OBX can also be part of an observation order (see Chapter 4, section 4.4, "General Trigger Events & Message Definitions"). In this case, the OBX carries clinical information needed by the filler to interpret the observation the filler makes. For example, an OBX is needed to report the inspired oxygen on an order for a blood oxygen to a blood gas lab, or to report the menstrual phase information which should be included on an order for a pap smear to a cytology lab. Appendix 7A includes codes for identifying many of pieces of information needed by observation producing services to properly interpret a test result. OBX is also found in other HL7 messages that need to include patient clinical information. When using the OBX for the TIM category, OBX-2 Value Type should be valued to DTM. Consequently, OBX-5 Observation Value should have a length of 26 given the format of the DTM data type. Note the expectations on which fields are required as well as the fields that should not be valued. When using the OBX for the CHN category, OBX-2 Value Type should be valued to CD. Consequently, OBX-5 Observation Value could have a length of up to 65536 given the format of the CD data type. Note the expectations on which fields are required as well as the fields that should not be valued. When using the OBX for the WAV category, OBX-2 can be valued as either NA or MA. The length of OBX-5 Observation Value depends on the data type chosen. NA is a repeating data type, and the length will depend on the number of repeats. Note the expectations on which fields are required as well as the fields that should not be valued. When using the OBX for the ANO category, OBX-2 Value Type should be valued to CWE. Consequently, OBX-5 Observation Value could have a length of up the 65536 given the format of the data types. Note the expectations on which fields are required as well as the fields that should not be valued. |
Class TbsODS_28 |
Dietary Orders, Supplements, And Preferences The ORC sequence items of interest to ODS are ORC-1-order control, ORC-2-placer order number, ORC-3-filler order number, ORC-7-quantity/timing, ORC-9-date/time of transaction, ORC-10-entered by, and ORC-11-verified by. For ORC-1-order control, the values may be New (NW), Cancel (CA), Discontinue Order Request (DC), Change (XO), Hold Order Request (HD), and Release Previous Hold (RL). The HD and RL codes could stop service for a specified length of time. ORC-7-quantity/timing should be used to specify whether an order is continuous or for one service period only. It is also useful for supplements which are part of a diet but only delivered, say, every day at night. Example: |1ˆQPMˆˆ20010415|. |
Class TbsODT_28 |
Diet Tray Instructions This segment addresses tray instructions. These are independent of diet codes, supplements, and preferences and therefore get separate order numbers. |
Class TbsOM1_28 |
General Segment The OM1 segment contains the attributes that apply to the definition of most observations. This segment also contains the field attributes that specify what additional segments might also be defined for this observation. |
Class TbsOM2_28 |
Numeric Observation This segment contains the attributes of observations with continuous values (including those with data types of numeric, date, or time stamp). It can be applied to observation batteries of type A and C (see OM1-18 - Nature of Service/Test/Observation). |
Class TbsOM3_28 |
Categorical Service/test/observation This segment applies to free text and other non-numeric data types. |
Class TbsOM4_28 |
Observations That Require Specimens This segment applies to observations/batteries that require a specimen for their performance. When an observation or battery requires multiple specimens for their performance (e.g., creatinine clearance requires a 24-hour urine specimen and a serum specimen), multiple segments may be included, one for each specimen type. OM4 is a repeating segment. It allows multiple specimens per Order Code and accommodates for multiple alternate specimen for each preferred specimen. In some cases an Order Code can require multiple specimens. In many cases there are preferred specimens and for each preferred it is possible to have one or more alternative specimens. The alternative specimen will carry in OM4-17 the Sequence Number - Test/Observation Master File (OM4-1) of the preferred specimen. |
Class TbsOM5_28 |
Observation Batteries (sets) This segment contains the information about batteries and supersets (a nature code of F, P or S, as described in OM1-18 - Nature of Service/Test/Observation). |
Class TbsOM6_28 |
Observations That Are Calculated From Other Observations This segment contains the information about quantities that are derived from one or more other quantities or direct observations by mathematical or logical means. |
Class TbsOM7_28 |
Additional Basic Attributes The OM7 segment contains additional basic attributes that apply to the definition of most observations/services |
Class TbsORC_28 |
Common Order The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). There is some overlap between fields of the ORC and those in the order detail segments. These are described in the succeeding sections. ORC use notes a |
Class TbsORG_28 |
Practitioner Organization Unit The ORG segment relates a practitioner to an organization unit and adds detailed information regarding the practitioner's practicing specialty in that organization unit. An ORG segment may optionally follow an STF segment. An ORG segment must always have been preceded by a corresponding STF segment. If no organization unit is specified, this segment is used to relate practitioners with their practicing specialties, including effective and end dates. When it is not necessary to record organization unit or dates associated with the practicing specialty, this data is recorded in PRA-3-Practitioner Category. |
Class TbsOVR_28 |
Override Segment This segment allows a sender to override specific receiving application's business rules to allow for processing of a message that would normally be rejected or ignored. In many instances, business rules will be set as guidelines relative to patient care. In some instances it is in the patient's better interest to circumvent these guidelines. In other cases, business rules may exist to support normal process flow, but which may be bypassed or ignored under certain special circumstances. This segment is linked to the proposed ERR segment changes in that the first attempt to process a transaction that violates a business rule may result in an error that must be overridden. The ERR provides a mechanism to identify errors that may be overridden, as well as the allowed override codes. Use case #1: A patient has received a prescription with a duration of 30 days and receives the full amount at their pharmacy. While at home the patient accidentally spills the container and spoils a significant proportion of the prescription. The patient returns to their pharmacy and explains the situation to the pharmacy technician. The technician consults with their supervising pharmacist. Knowing the patient, thepharmacist decides to override the business rule stating that the dispensed amount for a prescription may not exceed the prescribed amount. In recording the decision, the pharmacy technician specifies that the Override Type is a "Compassionate Refill" and that the Override Code, or reason for the override, is "Spoilage". The technician also provides Override Comments to provide an explanation of the situation for future reference. While recording the decision, the technician's user ID is automatically stored in an Override Recorded By field. The pharmacist's ID is stored in the Override Responsible Provider field. Use case #2:A hospital wishes to submit an invoice to an insurer who is providing secondary coverage. The invoice is being submitted over a week after the service was performed, which is outside the insurer's normal accept time window. The insurer would normally reject the invoice. However, the submitter includes an Override Type of "late submission" as well as an Override Code indicating that the invoice is late due to delays with the primary payor. The secondary insurer examines the override reason and accepts the invoice. Usage Note: The override segment should be included in messages adjacent to the segment(s) containing the information that would trigger the business rule(s) that needs to be overridden. The segment should be optional (you shouldn't always need to override business rules), and should be allowed to repeat in circumstances where there may be more than one business rule overridden at the same time. Committees may wish to provide suggested values for override types or codes for use with the OVR segment in different messages. |
Class TbsPAC_28 |
Shipment Package The intent of this segment is to describe the information associated with the shipping package specimens are sent in. |
Class TbsPCE_28 |
Patient Charge Cost Center Exceptions The Patient Charge Cost Center Exception segment identifies the Patient Price associated with Cost Center and Patient Charge Identifier combinations that should be used in an instance that the item is billed to a patient. The grouping of Cost Center accounts, Patient Charge Identifier, and Patient Price is unique. |
Class TbsPCR_28 |
Possible Causal Relationship The PCR segment is used to communicate a potential or suspected relationship between a product (drug or device) or test and an event with detrimental effect on a patient. This segment identifies a potential causal relationship between the product identified in this segment and the event identified in the PEO segment. More than one PCR segment can be included in the message if more than one product is possibly causally related to the event. |
Class TbsPD1_28 |
Patient Additional Demographic The patient additional demographic segment contains demographic information that is likely to change about the patient. |
Class TbsPDA_28 |
Patient Death And Autopsy This segment carries information on a patient's death and possible autopsy. |
Class TbsPDC_28 |
Product Detail Country This segment is maintained for backwards compatibility only as of V2.7. |
Class TbsPEO_28 |
Product Experience Observation Details related to a particular clinical experience or event are embodied in the PEO segment. This segment can be used to characterize an event which might be attributed to a product to which the patient was exposed. Products with a possible causal relationship to the observed experience are described in the following PCR (possible causal relationship) segments. The message format was designed to be robust and includes many optional elements which may not be required for a particular regulatory purpose but allow a complete representation of the drug experience if needed. A PEX message can contain multiple PEO segments if the patient experienced more than one event but must contain at least one PEO segment. |
Class TbsPES_28 |
Product Experience Sender |
Class TbsPID_28 |
Patient Identification The PID segment is used by all applications as the primary means of communicating patient identification information. This segment contains permanent patient identifying and demographic information that, for the most part, is not likely to change frequently. It should be noted that from V2.4 onwards the demographics of animals can also be sent in the PID segment (see PID-35 to PID-38). The assigning authority, the fourth component of the patient identifiers, is a HD data type that is uniquely associated with the assigning authority that originally assigned the number. A given institution, or group of intercommunicating institutions, should establish a list of assigning authorities that may be potential assignors of patient identification (and other important identification) numbers. The list will be one of the institution's master dictionary lists. Since third parties (other than the assignors of patient identification numbers) may send or receive HL7 messages containing patient identification numbers, the assigning authority in the patient identification numbers may not be the same as the sending and receiving systems identified in the MSH. The assigning authority must be unique across applications at a given site. This field is required in HL7 implementations that have more than a single Patient Administration application assigning such numbers. The assigning authority and identifier type codes are strongly recommended for all CX data types. With HL7 V2.3, the nomenclature for the fourth component of the patient identifiers was changed from "assigning facility ID" to "assigning authority". While the identifier may be unique to a given healthcare facility (for example, a medical record assigned by facility A in Hospital XYZ), the identifier might also be assigned at a system level (for example a corporate person index or enterprise number spanning multiple facilities) or by a government entity, for example a nationally assigned unique individual identifier. While a facility is usually an assigning authority, not all assigning authorities are facilities. Therefore, the fourth component is referred to as an assigning authority, but retains backward compatibility using the construct of the HD data type (see the note in chapter 2). Additionally, CX data types support the use of assigning facility (HD) as the sixth component. |
Class TbsPKG_28 |
Item Packaging This segment contains the type of packaging available for the inventory supply item to be ordered and/or issued to a department or other supply location for a specified Purchasing Vendor. It would be recommended to send this segment in descending unit of measure order corresponding with the ascending Set ID. |
Class TbsPMT_28 |
Payment Information This segment contains information that describes a payment made by a Payer organization. |
Class TbsPR1_28 |
Procedures The PR1 segment contains information relative to various types of procedures that can be performed on a patient. The PR1 segment can be used to send procedure information, for example: Surgical, Nuclear Medicine, X-ray with contrast, etc. The PR1 segment is used to send multiple procedures, for example, for medical records encoding or for billing systems. |
Class TbsPRA_28 |
Practitioner Detail The PRA segment adds detailed medical practitioner information to the personnel identified by the STF segment. A PRA segment may optionally follow an STF segment. A PRA segment must always have been preceded by a corresponding STF segment. The PRA segment may also be used for staff who work in healthcare who are not practitioners but need to be certified, e.g., "medical records staff." |
Class TbsPRB_28 |
Problem Details The problem detail segment contains the data necessary to add, update, correct, and delete the problems of a given individual. |
Class TbsPRC_28 |
Pricing The PRC segment contains the pricing information for the preceding CDM segment's chargeable item. It contains the fields which, for the same chargeable item, might vary depending upon facility or department or patient type. The preceding CDM segment contains the fields which, for one chargeable item, remain the same across facilities, departments, and patient types. |
Class TbsPRD_28 |
Provider Data This segment will be employed as part of a patient referral message and its related transactions. The PRD segment contains data specifically focused on a referral, and it is inter-enterprise in nature. The justification for this new segment comes from the fact that we are dealing with referrals that are external to the facilities that received them. Therefore, using a segment such as the current PV1 would be inadequate for all the return information that may be required by the receiving facility or application. In addition, the PV1 does not always provide information sufficient to enable the external facility to make a complete identification of the referring entity. The information contained in the PRD segment will include the referring provider, the referred to provider, the referred to location or service, and the referring provider clinic address. |
Class TbsPRT_28 |
Participation Information The Participation Information segment contains the data necessary to add, update, correct, and delete from the record persons, organizations, or locations (participants) participating in the activity being transmitted. In general, the PRT segment is used to describe a participant playing a particular role within the context of the message. In OO, for example, in the results messages the PRT segment may be used to provide the performing provider, whether a person or organization. In a specimen shipment message it may be the waypoint location relevant for the shipment. The positional location of the PRT segment indicates the relationship. When the segment is used following the OBX segment, then the participations relate to the relevant participations in the result. |
Class TbsPSG_28 |
Product/service Group The Product/Service Group segment is used to form a logical grouping of Product/Service Line Items, Patients and Response Summaries for a particular Invoice. For example, a Product/Service Group can be used to group all Product/Service Line Items that must be adjudicated as a group in order to be paid. |
Class TbsPSH_28 |
Product Summary Header This segment is maintained for backwards compatibility only as of V2.7. |
Class TbsPSL_28 |
Product/service Line Item The Product/Service Line Item segment is used to identify individual product/service items that typically are aggregated into an Invoice. Each instance of a Product/Service Line Item corresponds to a unique product delivered or service rendered. |
Class TbsPSS_28 |
Product/service Section The Product/Service Section segment is used to form a logical grouping of Product/Service Group segments, Patients and Response Summaries for a particular Invoice. |
Class TbsPTH_28 |
Pathway The pathway segment contains the data necessary to add, update, correct, and delete from the record pathways that are utilized to address an individual's health care. |
Class TbsPV1_28 |
Patient Visit The PV1 segment is used by Registration/Patient Administration applications to communicate information on an account or visit-specific basis. The default is to send account level data. To use this segment for visit level data PV1-51 - Visit Indicator must be valued to "V". The value of PV-51 affects the level of data being sent on the PV1, PV2, and any other segments that are part of the associated PV1 hierarchy (e.g., ROL, DG1, or OBX). The facility ID, the optional fourth component of each patient location field, is a HD data type that is uniquely associated with the healthcare facility containing the location. A given institution, or group of intercommunicating institutions, should establish a list of facilities that may be potential assignors of patient locations. The list will be one of the institution's master dictionary lists. Since third parties other than the assignors of patient locations may send or receive HL7 messages containing patient locations, the facility ID in the patient location may not be the same as that implied by the sending and receiving systems identified in the MSH. The facility ID must be unique across facilities at a given site. This field is required for HL7 implementations that have more than a single healthcare facility with bed locations, since the same <point of care> ˆ <room> ˆ <bed> combination may exist at more than one facility. |
Class TbsPV2_28 |
Patient Visit - Additional Information The PV2 segment is a continuation of information contained on the PV1 segment. |
Class TbsPYE_28 |
Payee Information This segment is used to define payee information. |
Class TbsQAK_28 |
Query Acknowledgment The QAK segment contains information sent with responses to a query. The QAK segment may appear as an optional segment placed after the (optional) ERR segment in any query response (message) to any original mode query |
Class TbsQID_28 |
Query Identification The QID segment contains the information necessary to uniquely identify a query. Its primary use is in query cancellation or subscription cancellation |
Class TbsQPD_28 |
Query Parameter Definition The QPD segment defines the parameters of the query |
Class TbsQRD_28 |
Withdrawn |
Class TbsQRF_28 |
Withdrawn |
Class TbsQRI_28 |
Query Response Instance The QRI segment is used to indicate the weight match for a returned record (where the responding system employs a numeric algorithm) and/or the match reason code (where the responding system uses rules or other match options). Examples of the use of this segment appear in Chapter 3, "Patient Administration," section 3.3.57, "Find Candidates and Response." |
Class TbsRCP_28 |
Response Control Parameter The RCP segment is used to restrict the amount of data that should be returned in response to query. |
Class TbsRDF_28 |
Table Row Definition The RDF segment defines the content of the row data segments (RDT) in the tabular response (RTB). - As an optional segment in a query either a QBP or QBS, this segment can be used to limit the number of columns returned and to specify what column positions the fields occupy (where supported, these features can be used to override the defaults for the particular query). If omitted, all fields defined for the query are returned in their default column order. - As a required segment in a tabular response (RTB) to either a QBP or QBS, this segment defines the contents of the table row data (RDT) segments that follows. It is not necessarily an echo back of the segment as it appeared in the query. |
Class TbsRDT_28 |
Table Row Data The RDT segment contains the row data of the tabular data response message (TBR). |
Class TbsREL_28 |
Clinical Relationship Segment The Clinical Relationship segment contains the data necessary to relate two data elements within and/or external to the message at run-time. It also includes information about the relationship. Relationships are constrained to being between explicit segments of messages rather than beween the identities of entities they reference. Segments are available within the message but related persistent information may not be. Because of the transient nature of messages applications must manage the associations with entities which persist outside or across messages. Examples: - Problem is a consequence of a diagnosis. - Diagnosis is supported by observation. - Observation is a manifestation of a diagnosis. - Complication is a consequence of a procedure. |
Class TbsRF1_28 |
Referral Information This segment represents information that may be useful when sending referrals from the referring provider to the referred-to provider. |
Class TbsRFI_28 |
Request For Information |
Class TbsRGS_28 |
Resource Group The RGS segment is used to identify relationships between resources identified for a scheduled event. This segment can be used, on a site specified basis, to identify groups of resources that are used together within a scheduled event, or to describe some other relationship between resources. To specify related groups of resources within a message, begin each group with an RGS segment, and then follow that RGS with one or more of the Appointment Information segments (AIG, AIL, AIS, or AIP). If a message does not require any grouping of resources, then specify a single RGS in the message, and follow it with all of the Appointment Information segments for the scheduled event. (At least one RGS segment is required in each message - even if no grouping of resources is required - to allow parsers to properly understand the message.) |
Class TbsRMI_28 |
Risk Management Incident The RMI segment is used to report an occurrence of an incident event pertaining or attaching to a patient encounter. |
Class TbsROL_28 |
Role The role segment contains the data necessary to add, update, correct, and delete from the record persons involved, as well as their functional involvement with the activity being transmitted. In general, the ROL segment is used to describe a person playing a particular role within the context of the message. In PM, for example, in the Grant Certificate/Permission message (B07), the ROL segment is used to describe the roles a person may perform pertinent to the certificate in the message. The positional location of the ROL segment in ADT and Finance messages indicates the relationship. When the segment is used following the IN3 segment, and the role-ROL value is PP or FHCP, the PP or FHCP is related to the health plan. When the segment is used following the PID segment, and the role-ROL value is PP or FHCP, the PP or FHCP is related to the person. When the segment is used following the PV2 segment, and the role-ROL value is PCP or FHCP, the PP or FHCP is related to the patient visit. |
Class TbsRQ1_28 |
Requisition Detail-1 RQ1 contains additional detail for each non-stock requisitioned item. This segment definition is paired with a preceding RQD segment. |
Class TbsRQD_28 |
Requisition Detail RQD contains the detail for each requisitioned item. |
Class TbsRXA_28 |
Pharmacy/treatment Administration The ORC must have the filler order number and the order control code RE. As a site-specific variant, the RXO and associated RXCs and/or the RXE (and associated RXCs) may be present if the receiving application needs any of their data. The RXA carries the administration data. |
Class TbsRXC_28 |
Pharmacy/treatment Component Order If the drug or treatment ordered with the RXO segment is a compound drug OR an IV solution, AND there is not a coded value for OBR-4-universal service ID, which specifies the components (base and all additives), then the components (the base and additives) are specified by two or more RXC segments. The policy of the pharmacy or treatment application on substitutions at the RXC level is identical to that for the RXO level. |
Class TbsRXD_28 |
Pharmacy/treatment Dispense |
Class TbsRXE_28 |
Pharmacy/treatment Encoded Order The RXE segment details the pharmacy or treatment application's encoding of the order. It also contains several pharmacy-specific order status fields, such as RXE-16-number of refills remaining, RXE-17-number of refills/doses dispensed, RXE-18-D/T of most recent refill or dose dispensed, and RXE-19-total daily dose. Note that ORC-7-quantity/timing has a different meaning from RXE-1-quantity/timing and RXG-3-quantity/timing. The pharmacy or treatment department has the "authority" (and/or necessity) to schedule dispense/give events. Hence, the pharmacy or treatment department has the responsibility to encode this scheduling information in RXE-1-quantity/timing and RXG-3-quantity/timing. ORC-7-quantity/timing does not change: it always specifies the requested give/dispense schedule of the original order. |
Class TbsRXG_28 |
Pharmacy/treatment Give |
Class TbsRXO_28 |
Pharmacy/treatment Order This is the "master" pharmacy/treatment order segment. It contains order data not specific to components or additives. Unlike the OBR, it does not contain status fields or other data that are results-only. It can be used for any type of pharmacy order, including inpatient (unit dose and compound unit dose), outpatient, IVs, and hyperalimentation IVs (nutritional IVs), as well as other non-pharmacy treatments, e.g., respiratory therapy, oxygen, and many nursing treatments. In addition to the pharmaceutical/treatment information, this segment contains additional data such as provider and text comments. A quantity/timing field is not needed in the RXO segment. The ORC segment contains the requested ORC-7-quantity/timing of the original order which does not change as the order is encoded, dispensed, or administered. |
Class TbsRXR_28 |
Pharmacy/treatment Route The Pharmacy/Treatment Route segment contains the alternative combination of route, site, administration device, and administration method that are prescribed as they apply to a particular order. The pharmacy, treatment staff and/or nursing staff has a choice between the routes based on either their professional judgment or administration instructions provided by the physician. |
Class TbsRXV_28 |
Pharmacy/Treatment Infusion The RXV segment details the pharmacy or treatment application’s encoding of specific infusion order parameters |
Class TbsSAC_28 |
Specimen Container Detail The container detail segment is the data necessary to maintain the containers that are being used throughout the Laboratory Automation System. The specimens in many laboratories are transported and processed in containers (e.g., sample tubes). When SPM and SAC are used in the same message, then the conceptually duplicate attributes will be valued only in the SPM. This applies to SAC-6 Specimen Source, SAC-27 Additives, and SAC-43 Special Handling Considerations. |
Class TbsSCD_28 |
Anti-microbial Cycle Data The SCD segment contains cycle data representing an instance of a sterilization or decontamination. |
Class TbsSCH_28 |
Scheduling Activity Information The SCH segment contains general information about the scheduled appointment. |
Class TbsSCP_28 |
Sterilizer Configuration (anti-microbial Devices) The sterilization configuration segment contains information specific to configuration of a sterilizer or washer for processing sterilization or decontamination loads. |
Class TbsSDD_28 |
Sterilization Device Data The SDD segment contains the attributes of an instance of a cycle that provides sterilization or decontamination of medical supplies. |
Class TbsSFT_28 |
Software Segment This segment provides additional information about the software product(s) used as a Sending Application. The primary purpose of this segment is for diagnostic use. There may be additional uses per site-specific agreements. Implementers are encouraged to use message profile identifiers (as found in 2.14.9.21, "MSH-21 Message Profile Identifier (EI) 01598") to control the behavior of the receiving application rather than relying on application or version information in the SFT segment. For example, if software product A has versions 9 and 10 deployed in different Enterprise locations, the fact that they use different message types, segments, or fields should be reflected via their message profiles (see section 2B, "Conformance Using Message Profiles"). If there is an upgrade from version 10 to 10.1, this would be reflected in the SFT segment, but changes to the message contents should be reflected via a new/different conformance profile. Use Case: An external application has been customized to communicate with a centralized patient drug history system. However, due to certain, known characteristics of the external software package, the centralized system must modify its behavior in order to process transactions correctly. In one example, the external application may have multiple versions in production. As such, the centralized application will need to know the name of the Software Vendor Organization, the Software Release Number, the Software Product Name, and the Software Binary ID so that it can correctly identify the software submitting the transaction and modify its behavior appropriately. While preparing a transaction for submission to a centralized system the sending application specifies its Software Install Date and its configuration settings (Software Product Information). While processing the transaction, the centralized system encounters an error. Upon examination of the error, install date and configuration of the software that sent the message, helpdesk staff are able to determine the sending application has not been updated to reflect recent application changes. Use Case: In circumstances where a message is manipulated or modified by multiple systems, a repetition of this segment may be appended by each system. |
Class TbsSHP_28 |
Shipment The intent of this segment is to describe the information associated with the transportation of the shipment. |
Class TbsSID_28 |
Substance Identifier The Substance Identifier segment contains data necessary to identify the substance (e.g., reagents) used in the production of analytical test results. The combination of these fields must uniquely identify the substance, i.e., depending on the manufacturer all or some fields are required (this is the reason the optionality is 'C' (conditional)). If the analysis requires multiple substances, this segment is repeated for each substance. The segment(s) should be attached to the TCD segment. Another purpose of this segment is to transfer the control manufacturer, lot, etc., information for control specimens. In this case the SID segment should be attached to the SAC segment describing the container with the control specimen. |
Class TbsSLT_28 |
Sterilization Lot The SLT segment defines requests, responses, and notifications of sterilization lots and supply item descriptions. This message may be used for CPD (Central Supply) and OR (Sub-sterile area outside of an Operating Room) mode. |
Class TbsSPM_28 |
Specimen The intent of this segment is to describe the characteristics of a specimen. It differs from the intent of the OBR in that the OBR addresses order-specific information. It differs from the SAC segment in that the SAC addresses specimen container attributes. An advantage afforded by a separate specimen segment is that it generalizes the multiple relationships among order(s), results, specimen(s) and specimen container(s). A specimen is defined as "A physical entity that is an individual, a group, an item, or a part representative of a larger group, class or whole that is the target of an observation or analysis for the purpose of drawing conclusions about the group, class, or whole." Note that any physical entity in the universe has the potential to become a specimen A specimen is collected or obtained from a source and may be representative of the source, or may represent a deviation within the source. A specimen may be wholly or partially consumed during an observation and any remaining portion of the specimen is persistent and can be stored. This segment may also be used in limited cases to describe a "virtual" specimen. In particular, to identify the characteristics required for a specimen in the context of a specific observation or test. In summary, SPM represents the attributes specific and unique to a specimen. |
Class TbsSTF_28 |
Staff Identification The STF segment can identify any personnel referenced by information systems. These can be providers, staff, system users, and referring agents. In a network environment, this segment can be used to define personnel to other applications, for example, order entry clerks, insurance verification clerks, admission clerks, as well as provider demographics. When using the STF and PRA segments in the Staff/Practitioner Master File message, MFE-4-primary key value is used to link all the segments pertaining to the same master file entry. Therefore, in the MFE segment, MFE-4-primary key value must be filled in. Other segments may follow the STF segment to provide data for a particular type of staff member. The PRA segment (practitioner) is one such. It may optionally follow the STF segment in order to add practitioner-specific data. Other segments may be defined as needed. When using the segments included in this chapter for other then Staff/Practitioner Master File messages, disregard references to MFE-4 - primary key value. |
Class TbsSTZ_28 |
Sterilization Parameter The STZ segment contains sterilization-specific attributes of a supply item. |
Class TbsTCC_28 |
Test Code Configuration The test (e.g., analyte) code configuration segment is the data necessary to maintain and transmit information concerning the test entity codes that are being used throughout the "automated system." |
Class TbsTCD_28 |
Test Code Detail The test code detail segment contains the data necessary to perform operations or calculations, or execute decisions by the laboratory automation system, and which are not supported by the original HL7 segments related to orders (ORC, OBR). For detail of use see messages of laboratory orders and observations in chapters 4 and 7. |
Class TbsTQ1_28 |
Timing/quantity The TQ1 segment is used to specify the complex timing of events and actions such as those that occur in order management and scheduling systems. This segment determines the quantity, frequency, priority and timing of a service. By allowing the segment to repeat, it is possible to have service requests that vary the quantity, frequency and priority of a service request over time. Use cases showing when TQ1 may need to repeat: a |
Class TbsTQ2_28 |
Timing/quantity Relationship The TQ2 segment is used to form a relationship between the service request the TQ1/TQ2 segments are associated with, and other service requests. The TQ2 segment will link the current service request with one or more other service requests. There are many situations, such as the creation of a service request for a group of intravenous (IV) solutions, where the sequence of the individual intravenous solutions (each a service in itself) needs to be specified, e.g., hyperalimentation with multi-vitamins in every third bottle. There are other situations where part of the service request's instructions contains a results condition of some type, such as "PRN pain." There is currently a free text "condition" field of TQ1-10 - Condition text which allows any condition to be specified. However, to support a fully encoded version of service request sequencing, or results condition, the TQ2, Timing/Quantity Relationship segment has been defined. TQ2 Usage notes: a |
Class TbsTXA_28 |
Transcription Document Header 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. |
Class TbsUAC_28 |
User Authentication Credential Segment This optional segment provides user authentication credentials, a Kerberos Service Ticket or SAML assertion, to be used by the receiving system to obtain user identification data. Refer to HL7 Table 0615 - User Authentication Credential Type Code. It is to be used in when the receiving application system requires the sending system to provide end-user identification for accountability or access control in interactive applications. Since user authentication implementations often limit the time period for validity of the session authentication credentials, this segment is not intended for use in non-interactive applications. It is possible that various user authentication credential standards' data may be communicated. Kerberos and SAML are two such standards. A user authentication credential is an encapsulated data (ED type) element, as defined by standards, with no HL7-relevant structure. Note: The UAC segment is defined for use within simple protocols, such as MLLP, that do not have user authentication semantics. Implementations that use WSDL/SOAP, or similar protocols, to envelope HL7 should employ the user authentication semantics and data structures available within the scope of those protocols rather than the UAC segment. If the receiving system accepts the user credentials in the UAC segment, no specific acknowledgement is required. However, if the receiving system detects an error while processing the UAC segment, its acknowledgment message shall report it to the sender via an MSA and ERR segment pair: - The ERR-3 (error code) field value is 207 to signify an application error - The ERR-7 (diagnostic information) field reports the specific error. Examples of possible errors are: - User credentials expected but not provided - User credentials invalid - User credentials expired - User credentials from an unknown or untrusted source - User unknown - User not allowed to create or access data on the receiving system. - User not allowed to initiate a processing function on the receiving system. When an MSA and ERR segment pair is reported to the sender, an application data response shall not occur. In such cases it is correct to assume that the sending application's user is not authorized to get the data. The processing rules for the ERR segment are outside of HL7's scope. |
Class TbsUB1_28 |
Ub82 The UB1 segment contains data specific to the United States. Only billing/claims fields that do not exist in other HL7 defined segments appear in this segment. The codes listed as examples are not an exhaustive or current list. Attention: UB1-2 was deprecated as of v2.3 and the detail was withdrawn and removed from the standard as of v 2.6. |
Class TbsUB2_28 |
Uniform Billing Data The UB2 segment contains data necessary to complete UB92 bills specific to the United States. Realms outside the US are referred to chapter 16. Only Uniform Billing fields that do not exist in other HL7 defined segments appear in this segment. For example, Patient Name and Date of Birth are required; they are included in the PID segment and therefore do not appear here. Uniform Billing field locators are provided in parentheses ( ). The UB codes listed as examples are not an exhaustive or current list; refer to a UB specification for additional information. |
Class TbsURD_28 |
Results/Update Definition |
Class TbsURS_28 |
Results/Update Selection Criteria |
Class TbsVAR_28 |
Variance The variance segment contains the data necessary to describe differences that may have occurred at the time when a healthcare event was documented. |
Class TbsVND_28 |
Purchasing Vendor This segment contains purchasing vendors that supply the inventory supply item specified in the ITM segment. |
Class TbsZL7_28 |
(proposed Example Only) |
Class TbsZxx_28 |
Any Z Segment |