Class TbsAD_231 |
Address |
Class TbsAUI_231 |
Authorization Information |
Class TbsCCD_231 |
Charge Time |
Class TbsCCP_231 |
Channel Calibration Parameters |
Class TbsCD_231 |
Channel Definition |
Class TbsCE_231 |
Coded Element |
Class TbsCF_231 |
Coded Element With Formatted Values |
Class TbsCK_231 |
Composite ID With Check Digit |
Class TbsCN_231 |
Composite ID Number And Name |
Class TbsCNE_231 |
Coded With No Exceptions |
Class TbsCNS_231 |
Composite ID Number And Name Simplified |
Class TbsCP_231 |
Composite Price |
Class TbsCQ_231 |
Composite Quantity With Units |
Class TbsCSU_231 |
Channel Sensitivity/units |
Class TbsCWE_231 |
Coded With Exceptions |
Class TbsCX_231 |
Extended Composite ID With Check Digit |
Class TbsDDI_231 |
Daily Deductible |
Class TbsDIN_231 |
Activation Date |
Class TbsDLD_231 |
Discharge Location |
Class TbsDLN_231 |
Driver's License Number |
Class TbsDLT_231 |
Delta Check |
Class TbsDR_231 |
Date/time Range |
Class TbsDT_231 |
|
Class TbsDTN_231 |
Day Type And Number |
Class TbsED_231 |
Encapsulated Data |
Class TbsEI_231 |
Entity Identifier |
Class TbsEIP_231 |
Parent Order |
Class TbsELD_231 |
Error |
Class TbsFC_231 |
Financial Class |
Class TbsFN_231 |
Family + Last Name Prefix |
Class TbsFT_231 |
|
Class TbsHD_231 |
Hierarchic Designator |
Class TbsID_231 |
|
Class TbsIS_231 |
|
Class TbsJCC_231 |
Job Code/class |
Class TbsLA1_231 |
|
Class TbsLA2_231 |
|
Class TbsMA_231 |
Multiplexed Array |
Class TbsMO_231 |
Money |
Class TbsMOC_231 |
Charge To Practise |
Class TbsMOP_231 |
Money Or Percentage |
Class TbsMSG_231 |
Message Type |
Class TbsNA_231 |
Numeric Array |
Class TbsNDL_231 |
Observing Practitioner |
Class TbsNM_231 |
|
Class TbsNR_231 |
Wertebereich |
Class TbsOCD_231 |
Occurence |
Class TbsOSD_231 |
Order Sequence |
Class TbsOSP_231 |
Occurence Span |
Class TbsPCF_231 |
Pre-certification Required |
Class TbsPI_231 |
Person Identifier |
Class TbsPIP_231 |
Privileges |
Class TbsPL_231 |
Person Location |
Class TbsPLN_231 |
Practitioner ID Numbers |
Class TbsPN_231 |
Person Name |
Class TbsPPN_231 |
Performing Person Time Stamp |
Class TbsPRL_231 |
Parent Result Link |
Class TbsPT_231 |
Processing Type |
Class TbsPTA_231 |
Policy Type |
Class TbsQIP_231 |
Query Input Parameter List |
Class TbsQSC_231 |
Query Selection Criteria |
Class TbsRCD_231 |
Row Column Definition |
Class TbsRFR_231 |
Reference Range |
Class TbsRI_231 |
Repeat Interval |
Class TbsRMC_231 |
Room Coverage |
Class TbsRP_231 |
Reference Pointer |
Class TbsSCV_231 |
Scheduling Class Value Pair |
Class TbsSI_231 |
|
Class TbsSN_231 |
Structured Numeric |
Class TbsSPD_231 |
Specialty |
Class TbsSPS_231 |
Specimen Source |
Class TbsST_231 |
|
Class TbsTM_231 |
|
Class TbsTN_231 |
|
Class TbsTQ_231 |
Timing Quantity |
Class TbsTS_231 |
Time Stamp |
Class TbsTX_231 |
|
Class TbsUVC_231 |
Value Code And Amount |
Class TbsVARIES_231 |
|
Class TbsVH_231 |
Visiting Hours |
Class TbsVID_231 |
Version Identifier |
Class TbsVR_231 |
Value Qualifier |
Class TbsWVI_231 |
Channel Identifier |
Class TbsWVS_231 |
Wavefrom Source |
Class TbsXAD_231 |
Extended Address |
Class TbsXCN_231 |
Extended Composite ID Number And Name For Persons |
Class TbsXON_231 |
Extended Composite Name And Identification Number For Organizations |
Class TbsXPN_231 |
Extended Person Name |
Class TbsXTN_231 |
Extended Telecommunication Number |
Class TbsACC_231 |
Accident segment The ACC segment contains patient information relative to an accident in which the patient has been involved. |
Class TbsADD_231 |
Addendum segment The ADD segment is used to define the continuation of the prior segment in a continuation message. See Section 2.23.2, Continuation messages and segments, for details. |
Class TbsAIG_231 |
Appointment information - general resource segment 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_231 |
Appointment information - location resource segment 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_231 |
Appointment information - personnel resource segment 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_231 |
Appointment information - service segment 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_231 |
Patient allergy information segment 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_231 |
Appointment preferences segment 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_231 |
Appointment request segment 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 TbsAUT_231 |
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 TbsBLG_231 |
Billing segment The BLG segment is used to provide billing information, on the ordered service, to the filling application. |
Class TbsCDM_231 |
Charge description master segment 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. |
Class TbsCM0_231 |
Clinical study master segment 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_231 |
Clinical study phase master segment 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_231 |
Clinical study schedule master segment 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 TbsCSP_231 |
|
Class TbsCSR_231 |
Clinical study registration segment 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_231 |
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_231 |
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_231 |
Clinical trial identification segment 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_231 |
Disability segment 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_231 |
Diagnosis segment 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-diagnosiscode-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 TbsDRG_231 |
Diagnosis related group segment 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_231 |
Continuation pointer segment The DSC segment is used in the continuation protocol. |
Class TbsDSP_231 |
Display data segment 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 TbsEQL_231 |
Embedded query language segment The EQL segment is used to define queries using select statements based on the query language of choice (e.g., SQL). Refer to the functional chapters for the lists of HL7-defined EQL select statements. |
Class TbsERQ_231 |
Event replay query segment The ERQ segment is used to issue queries where the desired response is formatted as an event replay response message. This enables the querying application to request detailed event data from an application that supports this feature, such that it may no longer be necessary for it to capture and store all event information at the time of the original trigger event. |
Class TbsERR_231 |
Error segment The ERR segment is used to add error comments to acknowledgment messages. |
Class TbsEVN_231 |
Event type segment 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_231 |
Facility segment Figure 7-25. FAC attributes |
Class TbsFT1_231 |
Financial transaction segment The FT1 segment contains the detail data necessary to post charges, payments, adjustments, etc. to patient accounting records. |
Class TbsGOL_231 |
Goal Detail The goal detail segment contains the data necessary to add, update, correct, and delete the goals for an individual. |
Class TbsGT1_231 |
Guarantor segment 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 TbsIAM_231 |
Patient adverse reaction information - unique iden |
Class TbsIN1_231 |
Insurance segment The IN1 segment contains insurance policy coverage information necessary to produce properly pro-rated and patient and insurance bills. |
Class TbsIN2_231 |
Insurance additional information segment 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 HCFA or other regulatory agencies. |
Class TbsIN3_231 |
Insurance additional information, certification segment The IN3 segment contains additional insurance information for certifying the need for patient care. Fields used by this segment are defined by HCFA, or other regulatory agencies. |
Class TbsLCC_231 |
Location charge code segment 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_231 |
Location characteristic segment 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. |
Class TbsLDP_231 |
Location department segment 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_231 |
Location identification segment 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_231 |
Location relationship segment The LRL segment is used identify one location's relationship to another location, the nearest lab, pharmacy, etc. |
Class TbsMFA_231 |
Master file acknowledgment segment The MFA segment contains the following fields as defined in Figure 8-3 - MFA attributes. |
Class TbsMFE_231 |
Master file entry segment Figure 8-2. MFE attributes |
Class TbsMFI_231 |
Master file identification segment The fields in the MFI segment are defined in Figure 8-1 - MFI attributes . |
Class TbsMRG_231 |
Merge patient information segment- 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. |
Class TbsMSA_231 |
Message acknowledgment segment The MSA segment contains information sent while acknowledging another message. |
Class TbsMSH_231 |
Message header segment The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. |
Class TbsNCK_231 |
System Clock |
Class TbsNK1_231 |
Next of kin / associated parties segment 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. |
Class TbsNPU_231 |
Bed status update segment 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_231 |
Application status change |
Class TbsNST_231 |
Application control level statistics |
Class TbsNTE_231 |
Notes and comments segment The NTE segment is defined here for inclusion in messages defined in other chapters. It is a common format for sending notes and comments. |
Class TbsOBR_231 |
Observation request segment General (taken from ASTM E1238) |
Class TbsOBX_231 |
Observation/result segment The OBX segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a report. Its structure is summarized in Figure 7-5. |
Class TbsODS_231 |
Dietary orders, supplements, and preferences segment 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: |
Class TbsODT_231 |
Diet tray instructions segment This segment addresses tray instructions. These are independent of diet codes, supplements, and preferences and therefore get separate order numbers. |
Class TbsOM1_231 |
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_231 |
Numeric observation segment 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 test/observation ). |
Class TbsOM3_231 |
Categorical test/observation segment This segment applies to free text and other non-numeric data types. |
Class TbsOM4_231 |
Observations that require specimens segment 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. |
Class TbsOM5_231 |
|
Class TbsOM6_231 |
Observations that are calculated from other observations segment 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 TbsORC_231 |
Common order segment The Common Order segment (ORC) is used to transmit fields that are common to all orders (all types of services that are requested). The ORC segment is required in the Order (ORM) message. ORC is mandatory in Order Acknowledgment (ORR) messages if an order detail segment is present, but is not required otherwise. |
Class TbsPCR_231 |
Possible causal relationship segment 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. |
Class TbsPD1_231 |
Patient Additional Demographic The patient additional demographic segment contains demographic information that is likely to change about the patient. |
Class TbsPDC_231 |
Product detail country segment Figure 7-24. PDC attributes |
Class TbsPEO_231 |
Product experience observation segment 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. |
Class TbsPES_231 |
Product experience sender segment Figure 7-20. PES attributes |
Class TbsPID_231 |
Patient identification segment 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. |
Class TbsPR1_231 |
Procedures segment 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_231 |
Practitioner detail segment 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_231 |
Problem Detail The problem detail segment contains the data necessary to add, update, correct, and delete the problems of a given individual. |
Class TbsPRC_231 |
Pricing segment 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_231 |
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 TbsPSH_231 |
Product summary header segment Figure 7-23. PSH attributes |
Class TbsPTH_231 |
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_231 |
Patient visit segment The PV1 segment is used by Registration/Patient Administration applications to communicate information on a visit-specific basis. This segment can be used to send multiple-visit statistic records to the same patient account or single-visit records to more than one account. Individual sites must determine the use for this segment. |
Class TbsPV2_231 |
Patient visit - additional information segment The PV2 segment is a continuation of visit-specific information contained on the PV1 segment. |
Class TbsQAK_231 |
Query Acknowledgement The QAK segment contains information sent with responses to a query. Although the QAK segment is required in the responses to the enhanced queries (see section 2.19), it may appear as an optional segment placed after the (optional) ERR segment in any query response (message) to any original mode query. |
Class TbsQRD_231 |
Original-style query definition segment The QRD segment is used to define a query. |
Class TbsQRF_231 |
Original style query filter segment The QRF segment is used with the QRD segment to further refine the content of an original style query. |
Class TbsRDF_231 |
Table row definition segment The RDF segment defines the content of the row data segments (RDT) in the Tabular Data Response Message (TBR). It is used in two ways: |
Class TbsRDT_231 |
Table row data segment The RDT segment contains the row data of the tabular data response message (TBR). |
Class TbsRF1_231 |
Referral Infomation This segment represents information that may be useful when sending referrals from the referring provider to the referred-to provider. |
Class TbsRGS_231 |
Resource group segment 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). |
Class TbsROL_231 |
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. |
Class TbsRQ1_231 |
Requisition detail-1 segment RQ1 contains additional detail for each nonstock requisitioned item. This segment definition is paired with a preceding RQD segment. |
Class TbsRQD_231 |
Requisition detail segment RQD contains the detail for each requisitioned item. See assumptions above. |
Class TbsRXA_231 |
Pharmacy/treatment administration segment 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_231 |
Pharmacy/treatment component order segment 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_231 |
Pharmacy/treatment dispense segment Figure 4-17. RXD attributes |
Class TbsRXE_231 |
Pharmacy/treatment encoded order segment 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. |
Class TbsRXG_231 |
Pharmacy/treatment give segment Figure 4-18. RXG attributes |
Class TbsRXO_231 |
Pharmacy/treatment order segment 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. |
Class TbsRXR_231 |
Pharmacy/treatment route segment The Pharmacy/Treatment Route segment contains the alternative combination of route, site, administration device, and administration method that are prescribed. 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 TbsSCH_231 |
Schedule activity information segment The SCH segment contains general information about the scheduled appointment. |
Class TbsSPR_231 |
Stored procedure request definition segment The SPR segment is used to issue queries using stored procedure calls. Refer to the functional chapters for the lists of HL7-defined stored procedure names, input parameters and output tables. |
Class TbsSTF_231 |
Staff identification segment 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. 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. |
Class TbsTXA_231 |
Document notification segment The TXA segment contains information specific to a transcribed document but does not include the text of the document. The message is created as a result of a document status change. This information is used to update other healthcare systems to identify reports that are available in the transcription system. By maintaining the TXA message information in these systems, the information is available when constructing queries to the transcription system requesting the full document text. |
Class TbsUB1_231 |
UB82 data segment The UB1 segment contains the data necessary to complete UB82 bills. Only UB82 fields that do not exist in other HL7 defined segments appear in this segment. Patient Name and Date of Birth are required for UB82 billing; however, they are included in the PID segment and therefore do not appear here. The UB codes listed as examples are not an exhaustive or current list. Refer to a UB specification for additional information. |
Class TbsUB2_231 |
UB92 data segment The UB2 segment contains data necessary to complete UB92 bills. Only UB92 fields that do not exist in other HL7 defined segments appear in this segment. Just as with the UB82 billing, Patient Name and Date of Birth are required; they are included in the PID segment and therefore do not appear here. When the field locators are different on the UB92, as compared to the UB82, the element is listed with its new location 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_231 |
Results/update definition segment The URD segment is used in sending unsolicited updates about orders and results. Its purpose is similar to that of the QRD segment, but from the results/unsolicited update point of view. Some of the fields have parallels in the QRD segment. |
Class TbsURS_231 |
Unsolicited selection segment The URS segment is identical with the QRF segment, except that if the name of any field contains Query (of QRY), this word has been changed to Results (see URS-5-R/U other results subject definition). |
Class TbsVAR_231 |
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 TbsVTQ_231 |
Virtual table query request segment The VTQ segment is used to define queries that are responded to with the Tabular Data Message (TBR). The VTQ query message is an alternate method to the EQQ query message that some systems may find easier to implement, due to its use of HL7 delimiters that separate components of the selection definition, and its limited selection criteria. Queries involving complex selection criteria (nested operators, etc.) may need to be formatted as an EQL segment. |