Ascend HL7 Interface Specification

Documentation Version: 5-5-2010

Mediware Information Systems
3510 Unocal Place, Suite 109
Santa Rosa, CA 95403
Voice: (707) 547-1711
Fax: (707) 547-1710
Email: sales@mediware.com
www.hosinc.com

This document describes the standard specifications for Hann's On Software (HOS) interfaces as of the version date above. Contact HOS for any information regarding interface support for new messages, features, etc. that may have been added to the interfaces, but not yet documented in these specifications.

General Specifications
HL7 Messages Supported
Admission Messages (ADT Message)
     Admit a patient (A01)
     Transfer a patient (A02)
     Discharge/End Visit (A03)
     Register an Outpatient/ER Patient (A04)
     Pre-admit a patient (A05)
     Change an Outpatient to an Inpatient (A06)
     Change an Inpatient to an Outpatient (A07)
     Update Patient Information (A08)
     Cancel Admission (A11)
     Cancel Transfer (A12)
     Cancel Discharge (A13)
     Swap Patients (A17)
     Merge Records (A18; for inbound messages only)
     Delete Record (A23; for inbound messages only)
     Update Person (A31; for inbound messages only)
     Change Patient Account Number (A35)
     Change Medical Record No and Account No (A36)
Order Messages"18">     RDE - Pharmacy Order Messages (Perfected)
     ORM - Pharmacy Order Messages (Non-Perfected)
Lab Messages
Formulary Messages
     MFN - Master File Notification message
Financial (Billing) Messages
     DFT - Detailed Financial Transaction message
HL7 Message Segment Detail
Segment ID
Segments Used for All Messages
     MSH - Message Header Segment
          Field separator
          Encoding characters
          Sending application
          Sending facility
          Receiving application
          Receiving facility
          Date/time of message
          Message type
          Message control ID
          Processing ID
          Version ID
     MSA - Message Acknowledgment Segment
          Acknowledgment code
          Message control ID
          Text message
Admissions Message Segments
     PID - patient identification segment
          Patient ID (Internal ID)
          Patient name
          Date/Time of birth
          Patient address
          Phone number - home
          Patient account number
     EVN - event type segment
          Event type code
          Recorded date/time
     PV1 - patient visit segment
          Patient class
          Assigned patient location
          Prior patient location
          Attending doctor
          Admitting doctor
          Patient type
     AL1 - patient allergy information segment
          Allergy Type
          Allergy description
     OBX - observation segment
          Value Type
          Observation Identifier
          Identifier Text Coding system
          Observation Value
          Units
     DG1 - diagnosis segment
          Diagnosis coding method
          Diagnosis code
          Diagnosis description
          Diagnosis/DRG type
     MRG - Merge Information
          Prior patient identification - Internal
          Prior patient account number
Pharmacy Order Segments
     ORC - common order segment
          Order Control
          Placer order number
          Timing/Quantity
          Transaction Date/Time
          Entered By
          Verified By
     RXE - pharmacy encoded order segment
          Quantity/Timing
               Quantity
               Interval
               Duration
               Start Date/Time
               End Date/Time
               Priority
               Condition
               Text Description
               Secondary Timing or Conjunction Component
               Order Sequencing
          Give code/drug ID
          Give amount minimum
          Give amount maximum
          Give Units
          Provider's administration instructions
          Pharmacist verifier ID
          Prescription Number/Rx Number
          Pharmacy Special Dispensing Instructions
          Give rate amount
          Give rate units
     RXO - pharmacy medication order segment
     RXR - pharmacy route segment
          Route
     RXC - pharmacy component segment
          Component type
          Component code
          Component amount
          Component units
          Component strength
          Component strength unit
Master File Maintenance Segments
     MFI - master file identification segment
          Master file identifier
          Master Files Application ID
          File-level event code
          Response Level Code
     MFE - master file entry segment
          Record-level event code
          Effective Date/Time
          Primary Key Value
     ZFM - drug formulary maintenance segment
          Generic Name
          Brand Name
          Hospital/Pharmacy drug code
          Route code
          Strength
          Strength units
          Volume
          Volume units
          NDC number
          Dosage
          Dosage units
          Dosage form
          Package Size
          AHFS number
          Default SIG
          Default comment
          Default label message
          Default IV rate
          Default expiration days
          Default expiration hours
          Bar code ID
          DEA/Schedule code
          AWP cost
          Acquisition cost
Detailed Financial Transaction Segments
    FT1 - financial transaction segment
             SetId -FT1
             Transaction date
             Transaction type
             Transaction code
             Transaction quantity
             Department code
             Patient type code
Non-HL7 Features - Notification
    

General Specifications

Standard (Preferred) Interface Specifications

Connectivity:    Network/Web connection
Protocol:    TCP/IP sockets (using Minimum Lower Layer Protocol)
Record format:    HL7 Version 2.2 or 2.3
 

Methods and examples:   

Send/Receive real-time, individual messages with acknowledgement of each message received before next message is sent. Supported messages include those for ADT, billing/charges, orders/profiling, drug formulary, and inventory control. 

Typically one socket/port number is dedicated to messages being sent in the same direction (i.e., inbound/outbound) and to/from the same IP address (e.g., typically the same vendor). Acknowledgements for received messages are transmitted back on the same socket/port they were received on.

For example, at one facility, incoming ADT and incoming order messages from the same CPOE vendor could share one socket, while outgoing billing messages to that vendor (i.e., an IP address) would use a second socket. Outbound ADT and order messages to an automated dispensing system vendor (i.e., a different IP address) could share a third socket, while inbound charges from that vendor would use a fourth socket/port number.

Other options

Charges/Billing Batch file (if TCP/IP protocol cannot be used as above)
Record format:
HL7 version 2.2 or 2.3 "batch file" format preferred; custom formats possible but less desirable 
Method:
Batch file creation on network drive or floppy disk

Standard Incoming or Outgoing Message Types

ADT (patient data): Admit, transfer, discharge, update, cancel admit, pre-admit, outpatient registration, outpatient pre-registration, outpatient discharge, cancel discharge, inpatient-to-outpatient and outpatient-to-inpatient status change, swap patients (beds), change Id (billing account number), and change patient ID (medical record number). (e.g., typically received from admissions systems, sent to automated dispensing systems, or sent to utilization review systems.)
Orders/profile: New order, discontinue order, hold order, cancel hold, update order (e.g., typically received from CPOE systems, sent to automated dispensing systems, or sent to utilization review systems.)
Formulary: Add medication, delete medication, update medication
Billing: Charge and credit transactions (e.g., typically sent to other financial or accounting systems, or received from automated dispensing systems)
Inventory control: Additions/removal from floor stock and usage (charges/credits) transactions received from some automated dispensing systems can be used by the interface to maintain floor stock inventory levels with some HOS applications.

Our standard interface uses typical HL7 Version 2.2 or 2.3 records, messages, fields, definitions and processing rules. This document will detail how we use HL7, particularly which messages are used and which fields are required/optional. Refer to documentation published elsewhere (i.e., the internet) for more general HL7 information.

The remaining documentation is organized as follows:

General HL7 Definitions and Rules

Sending and Receiving Systems; Inbound and Outbound Messages

In this document, the system transmitting a message may be referred to as the "sender" or "sending/pitcher/pitching" system and the system receiving and acknowledging the message as the "receiver" or "receiving/catcher/catching" system. Messages sent by an HOS interface may be referred to as "outbound" messages and those being received by an HOS interface may be referred to as "inbound" messages. Therefore, the terms "inbound" and "outbound" will refer to the direction of message travel from HOS's perspective.

HL7 Messages

A "message" is considered the minimal unit of data transferred between systems using HL7. For example, an admission transaction would be sent as an HL7 "ADT" message. Messages are comprised of two or more "segments" that act as building blocks for each message. Messages are delimited by a "start block" (HEX 0b ...or... ASCII/decimal 11) and an "end block" (HEX 1c plus HEX 0d ...or.... ASCII/decimal 28 plus ASCII/decimal 13).

Conceptual example: <Hex 0b><HL7 Message segments><Hex 1c><Hex 0d>

HL7 Segments

HL7 messages are comprised of several HL7 segments. Examples of segments include: the "message header segment", "patient identification segment", "pharmacy order segment" and "financial transaction segment" segments, among many others. Each message is terminated by Hex 0d (decimal 13; the "carriage return" character).

Conceptual example: <Hex 0b>
<Message header segment><Hex 0d>
<Event segment><Hex 0d>
<Patient Id segment><Hex 0d>
<Patient visit segment><Hex 0d>
<Diagnosis segment><Hex 0d>
<Allergy segment><Hex 0d>
<Hex 1c><Hex 0d>

Optional segments and fields will be enclosed in brackets [ ] e.g., [AL1] indicates that the allergy segment is optional. Some segments may, on an optional basis, be repeated within the message. Repeating message options will be displayed with curly brackets { }. For example, {AL1} indicates that the allergy segment may be repeated if needed. These may also be combined, e.g., [{AL1}] indicates the allergy segment is optional and that it may be repeated if needed. 

Some of the messages outlined below do not list all possible standard HL7 segments. These "unlisted" segments can be included within inbound HL7 messages, but will be ignored by the HOS interface. Unlisted segments are assumed to be optional, and will not be included in outbound transactions unless the vendor contacts HOS to make other arrangements.

Fields

Each segment begins with a unique 3 byte message identifier field (e.g., MSH for "message header", PID for "patient identification", etc.). Subsequent fields within the same segment are separated from one another by the field separator character, the "pipe" symbol, "|".

e.g., PID|field2|field3|field4|…..etc.|<Hex 0d>

Fields are transmitted as character strings. Refer to the "Data Types" table below for a listing of the types of data found in the fields. Although field lengths are listed in the message and segment definition tables below, the interface will not "pad" the field with spaces when sending messages. Although the interface can receive fields padded with spaces, the sending system is not required to pad fields with spaces. If fields are blank ( e.g., PID|||| i.e., field separators with nothing between them) then the sender has no new value for these fields and any previous values in the receiver’s system should be left "as is". If the sender transmits two double quote marks as a field value (e.g., |""| ), this null value should signal the receiving system to remove any previously held value. If all remaining fields in a segment have no data (and are all optional), the sending system may drop them and terminate the segment at that point. The receiving system should treat dropped fields as blank.

Field Components and Subcomponents

A few HL7 fields are defined as having more than one portion, each of which is separated by a component separator, "^". These field types are called "composite" fields. For example, the patient’s name field is usually sent as several components:

"….|last_name^first_name^initial^^|…."

Blank components are shown with two component separators with nothing between them: "^^". If all remaining components in a field definition have no data and are optional, the sending system may drop them. The receiving system should treat dropped components as blank.

Occasionally, components may divided into subcomponents, separated by the subcomponent separator, "&". Rules for their use are similar to those for the component separator.

The interface will usually not further subdivide fields below the "component" level unless otherwise noted. However, refer to standard HL7 documentation for standard subcomponent (and below) definitions if desired.

Data Types

The Data Type Category will appear in subsequent field definition tables to identify the format of the field or its components.

Data Type Code Data Type Name Notes/Format
String    
ST String  
Numeric    
CQ Composite quantity with units <quantity (NM)> ^ <units (CE)>
NM Numeric  
SI Sequence ID  
Identifier    
ID Coded values for HL7 tables  
IS Coded value for user-defined tables  
HD Hierarchic designator <application identifier (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)> Used only as part of EI and other data types.
EI Entity identifier <entity identifier (ST)> ^ <assigning authority (HD)>
RP Reference pointer <pointer (ST) > ^ < application ID (HD)> ^ <main type (ID)> & <subtype (ID)>
PL Patient location <point of care (IS )> ^ <room (IS )> ^ <bed (IS)> ^ <facility (HD)> ^ < location status (IS )> ^ <patient location type (IS)> ^ <building (IS )> ^ <floor (IS )>
PT Processing type <processing ID (ID)> ^ <processing mode (ID)>
Date/Time    
DT Date YYYY[MM[DD]]
TM Time HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ]
TS Time stamp YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ] ^ <degree of precision>
Coded Values    
CE Coded element <identifier (ID)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ID)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
CF Coded element with formatted values <identifier (ID)> ^ <formatted text (FT)> ^ <name of coding system (ST)>^<alternate identifier (ID)> ^ <alternate formatted text (FT)> ^ <name of alternate coding system (ST)>
CK Composite ID with check digit <ID number (NM)> ^ <check digit (NM)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)>
CN Composite ID number and name <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)>
CX Extended composite ID with check digit <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD) )> ^ <identifier type code (IS)> ^ < assigning facility (HD)
Generic    
CM Composite  
Demographics    
AD Address <street address (ST)> ^ < other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ <address type (ID)> ^ <other geographic designation (ST)>
PN Person name <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)>
TN Telephone number [NN] [(999)]999-9999[X99999]
Specialty    
CP Composite price <price (NM)> ^ <price type (ID)> ^ <from value (NM)> ^ <to value (NM)> ^ <range units (CE)> ^ <range type (ID)>
TQ Timing/quantity <quantity (CQ)> ^ <interval (*)> ^ <duration (*)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <priority (ID)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^ <order sequencing>

* for subcomponents, please refer to the definitions in the text.

Field Requirements

In this documentation, fields will be marked as follows: R = required, O= Optional, C = Conditional (if used, these will be explained) and B = included for backwards compatibility with previous versions. Unlisted standard HL7 fields are to be considered optional.

Receiver Processing Rules

The receiver should ignore any "extra" segments, fields, components, and subcomponents (i.e., that were transmitted but were not expected by the receiving system). The receiver should treat segments that were expected, but not present, as consisting entirely of fields that are blank. The receiver should treat fields, components and subcomponents that are expected, but not included in a segment, as blank.

The receiver should send one "ACK" (acknowledgement) message to the sender, following receipt of each message, as follows. After the receiver has received a properly delimited message, the receiver should check the message for the message type (MSH field 9), version ID (MSH field 12) and processing ID (MSH field 11). If any of these are unacceptable, the receiver should send back an HL7 acknowledgement message (ACK) containing an MSA segment, with field #1 containing the value "AR" (application reject).

Otherwise, the receiver should process the message. If the receiver is unable to process the message because of improper message format, missing required field data, or the like, the receiver should send back an HL7 acknowledgement message (ACK) containing an MSA segment, with field #1 containing the value "AE" (application error).

If the receiver is unable to process the message for reasons other than improper format, missing data, the system being down, or the like, the receiver should send back an HL7 acknowledgement message (ACK) containing an MSA segment, with field #1 containing the value "AR" (application reject).

HL7 Messages Supported by Our Standard Interfaces

Admission Messages

The "ADT" message type will be used to transmit admission/patient demographic information from the hospital/pharmacy system to the pharmacy database. Several (incoming) admission events are supported by the  interface. Many admission messages share the same message format. When a subsequent message shares the same segment combinations as a previous one, the user will be directed to refer to the earlier message for more detail. The "trigger event" or "event" code (e.g., A01 = admit) found in the Message Header Segment and in the Event Segment define the type of admission message (admission, transfer, discharge, etc.). These will be discussed in the "HL7 Message Segment Detail" section of this documentation. 

ADT - Admit a patient (A01)

An "admit patient" message (A01 "event") is used for "Admitted" patients only. These messages are sent as a result of patients beginning their stay in the healthcare facility. Normally, this information is entered in the hospital information system and broadcast to nursing units and ancillary systems. A admission message (A01 event) should be used to notify the pharmacy database of a patient’s arrival in the healthcare facility.

Segment Description
MSH Message Header
EVN Event Type
PID Patient Identification
PV1 Patient Visit
[{OBX}] Observation / Result
[{AL1}] Patient Allergy Information
[{DG1}] Diagnosis Information

Sample Message Sent From Hospital Information System:

MSH|^~\&|AccMgr|1|||20050110045504||ADT^A01|599102|P|2.3||| EVN|A01|20050110045502||||| PID|1||10006579^^^1^MRN^1||DUCK^DONALD^D||19241010|M||1|111 DUCK ST^^FOWL^CA^999990000^^M|1|8885551212|8885551212|1|2||40007716^^^AccMgr^VN^1|123121234|||||||||||NO NK1|1|DUCK^HUEY|SO|3583 DUCK RD^^FOWL^CA^999990000|8885552222||Y|||||||||||||| PV1|1|I|PREOP^101^1^1^^^S|3|||37^DISNEY^WALT^^^^^^AccMgr^^^^CI|||01||||1|||37^DISNEY^WALT^^^^^^AccMgr^^^^CI|2|40007716^^^AccMgr^VN|4|||||||||||||||||||1||G|||20050110045253|||||| GT1|1|8291|DUCK^DONALD^D||111^DUCK ST^^FOWL^CA^999990000|8885551212||19241010|M||1|123121234||||#Cartoon Ducks Inc|111^DUCK ST^^FOWL^CA^999990000|8885551212||PT| DG1|1|I9|71596^OSTEOARTHROS NOS-L/LEG ^I9|OSTEOARTHROS NOS-L/LEG ||A| IN1|1|MEDICARE|3|MEDICARE|||||||Cartoon Ducks Inc|19891001|||4|DUCK^DONALD^D|1|19241010|111^DUCK ST^^FOWL^CA^999990000|||||||||||||||||123121234A||||||PT|M|111 DUCK ST^^FOWL^CA^999990000|||||8291 IN2|1||123121234|Cartoon Ducks Inc|||123121234A|||||||||||||||||||||||||||||||||||||||||||||||||||||||||8885551212 IN1|2|NON-PRIMARY|9|MEDICAL MUTUAL CALIF.|PO BOX 94776^^HOLLYWOOD^CA^441414776||8003621279|PUBSUMB|||Cartoon Ducks Inc||||7|DUCK^DONALD^D|1|19241010|111 DUCK ST^^FOWL^CA^999990000|||||||||||||||||056269770||||||PT|M|111^DUCK ST^^FOWL^CA^999990000|||||8291 IN2|2||123121234|Cartoon Ducks Inc||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||8885551212 IN1|3|SELF PAY|1|SELF PAY|||||||||||5||1

Sample Message Sent From Ascend:

MSH|^~\&|Ascend|555|PYXIS|555|200501100455||ADT^A01|ADT66561|P|2.3||||||| PID|||10006579||DUCK^DONALD D||19241010|M|||111^DUCK ST^^FOWL^CA^99999^^R||8885551212|||||40007716|123121234||||||||||| PV1||I|PREOP^101^1||||37^DISNEY^WALT|||||||||||I||||||||||||||||||||||||||200501100452|||||||| DG1|1|||OSTEOARTHROS NOS-L/LEG|||||||||||||||^

ADT - Transfer a Patient (A02)

A "transfer patient" message (A02 event) should be sent to the interface when a patient is transferred to another ward, room or bed.

Segment Description
MSH Message Header
EVN Event Type
PID Patient Identification
PV1 Patient Visit

Sample Message Sent From Hospital Information System:

MSH|^~\&|AccMgr|1|||20050110114442||ADT^A02|59910287|P|2.3||| EVN|A02|20050110114442||||| PID|1||10006579^^^1^MRN^1||DUCK^DONALD^D||19241010|M||1|111^DUCK ST^^FOWL^CA^999990000^^M|1|8885551212|8885551212|1|2||40007716^^^AccMgr^VN^1|123121234|||||||||||NO PV1|1|I|IN1^214^1^1^^^S|3||PREOP^101^|37^DISNEY^WALT^^^^^^AccMgr^^^^CI|||01||||1|||37^DISNEY^WALT^^^^^^AccMgr^^^^CI|2|40007716^^^AccMgr^VN|4|||||||||||||||||||1||I|||20050110045253||||||

Sample Message Sent From Ascend:

MSH|^~\&|Ascend|555|PYXIS|555|200501101145||ADT^A02|ADT66738|P|2.3||||||| PID|||10006579||DUCK^DONALD D||19241010|M|||518 BURG ST^^FOWL^CA^99999^^R||8885551212|||||40007716|123121234||||||||||| PV1||I|IN1^214^1||||37^DISNEY^WALT|||||||||||I||||||||||||||||||||||||||200501100452|||||||| DG1|1|||OSTEOARTHROS NOS-L/LEG|||||||||||||||^ AL1|1|MA|^NKA|||

ADT - Discharge/End Visit (A03)

A "discharge patient" or "end visit" message (A03 event) should be sent when an inpatient’s stay in the healthcare facility is ended, or an outpatient or emergency room visit is ended. It signals that the patient’s status has changed to "discharged", that a discharge date/time has been assigned, and that the patient no longer requires services normally provided through the pharmacy database.

Segment Description
MSH Message Header
EVN Event Type
PID Patient Identification
PV1 Patient Visit

Sample Message Sent From Hospital Information System:

MSH|^~\&|AccMgr|1|||20050112154645||ADT^A03|59912415|P|2.3||| EVN|A03|20050112154642||||| PID|1||10006579^^^1^MRN^1||DUCK^DONALD^D||19241010|M||1|111^DUCK ST^^FOWL^CA^999990000^^M|1|8885551212|8885551212|1|2||40007716^^^AccMgr^VN^1|123121234|||||||||||NO PV1|1|I|IN1^214^1^1^^^S|3||IN1^214^1|37^DISNEY^WALT^^^^^^AccMgr^^^^CI|||01||||1|||37^DISNEY^WALT^^^^^^AccMgr^^^^CI|2|40007716^^^AccMgr^VN|4||||||||||||||||1|||1||P|||20050110045253|20050112152000|3115.89|3115.89|||

Sample Message Sent From Ascend:

MSH|^~\&|Ascend|555|PYXIS|555|200501121547||ADT^A03|ADT67504|P|2.3||||||| PID|||10006579||DUCK^DONALD D||19241010|M|||518 BURG ST^^FOWL^CA^99999^^R||8885551212|||||40007716|123121234||||||||||| PV1||I|IN1^214^1||||37^DISNEY^WALT|||||||||||I||||||||||||||||||||||||||200501100452|200501121520||||||| DG1|1|||OSTEOARTHROS NOS-L/LEG|||||||||||||||^ AL1|1|MA|^NKA|||

ADT - Register an Outpatient/ER Patient (A04)

A "register patient" message (A04 event) signals that the patient has arrived or checked in as an outpatient, recurring outpatient, or emergency room patient.  Note: Users may be able to configure their system to process, or not process (ignore), some (or all) outpatient and emergency room registrations; in either case an "application accept" acknowledgement will be returned to the sender.

This message uses the same segments as the "admit patient" (A01) message.

ADT - Pre-admit a Patient (A05)

A "pre-admission" message (A05 event) is sent to notify the interface of a patient pre-admission process. This message can also be used to pre-register an outpatient or emergency room patient. Note: Users may be able to configure their system to process, or not process (ignore), this message type; in either case an "application accept" acknowledgement will be returned to the sender.

This message uses the same segments as the "admit patient" (A01) message.

ADT - Change an Outpatient to an Inpatient (A06)

A "change outpatient to inpatient" message (A06 event) is sent when an outpatient or ER patient is being admitted as an inpatient. This message should signal the interface to changes a patient’s status from outpatient/ER to inpatient/admitted. If a patient is pre-registered (not registered) as an outpatient and then admitted as an inpatient, an "admission" message (A01 event) should be sent instead.

This message uses the same segments as the "admit patient" (A01) message.

ADT - Change an Inpatient to an Outpatient (A07)

A "change inpatient to outpatient" message (A07 event) is sent when an inpatient becomes an outpatient and is still receiving care/services.

This message uses the same segments as the "admit patient" (A01) message.

ADT - Update Patient Information (A08)

This message (A08 event) is used when any patient information has changed but when no other ADT event has occurred. For example, visit information updates.

This message uses the same segments as the "admit patient" (A01) message.

ADT - Cancel Admission (A11)

For inpatients, the "cancel admission" message (A11 event) is sent when an earlier "admission" message (A01 event) is canceled, either because of an erroneous entry or because of a revised decision to not admit the patient. For outpatients/ER patients, the message is sent when an earlier "register outpatient" message (A04 event) is canceled for similar reasons. If the patient has orders on file, the patient will be discharged by the application. If no orders are on file, the patient's record will be deleted.

This message uses the same segments as the "discharge patient" (A03) message.

ADT - Cancel Transfer (A12)

The "cancel transfer" message (A12 event) is intended to reverse an earlier "transfer" message, either because of an erroneous entry or because of a revised decision to not transfer the patient. This message uses the same segments as the "transfer patient" (A02) message and, for inbound messages, is treated as a second transfer. 

ADT - Cancel Discharge (A13)

The "cancel discharge" message (A13 event) is sent when an earlier "discharge patient" message (A03 event) is canceled, either because of erroneous entry or because of a revised decision to not discharge, or end the visit of, the patient.

This message uses the same segments as the "admit patient" (A01) message.

ADT - Swap Patients (A17)

The "swap patients" message (A17 event) is used to identify two patients that have exchanged beds. The interface will process inbound A17 events, but does not support this event for outbound messages.

Segment Description
MSH Message Header
EVN Event Type
PID Patient Identification (patient #1)
PV1 Patient Visit (patient #1)
PID Patient Identification (patient #2)
PV1 Patient Visit (patient #2)

ADT - Merge Records (A18)

For inbound messages, the "merge records" message (A18 event) is used to combine two patient records into one. This may be used if a second, unwanted record for the same patient has been created accidentally by the other system. The interface does not support A18 events for outbound messages. [Note: To update patient medical record numbers, the interface sends outbound A36 event messages; to update patient account numbers, outbound A35 event messages are sent.]

Segment Description
MSH Message Header
EVN Event Type
PID Patient Identification
MRG Merge Information
PV1 Patient Visit

ADT - Delete Record (A23)

The "delete record" message (A23 event) is recognized by the interface for inbound messages and processed in the same manner as a "cancel admission" (A11 event) message. The "delete record" (A23) event is not supported for outbound ADT messages. 

This message uses the same segments as the "discharge patient" (A03) message.

ADT - Update Person (A31)

The "update person" message (A31 event) is recognized by the interface for inbound messages and processed in the same manner as a "update patient information" (A08 event) message. The "update person" (A31) event is not supported for outbound ADT messages. 

Segment Description
MSH Message Header
EVN Event Type
PID Patient Identification
PV1 Patient Visit
[{OBX}] Observation / Result
[{AL1}] Patient Allergy Information

ADT - Change Patient Account Number (A35)

The "change account number" (A35 event) is used to update the patient's account number. This might be used if a patient record is entered with an incorrect account number.

Segment Description
MSH Message Header
EVN Event Type
PID Patient Identification
MRG Merge Information

ADT - Change Medical Record No and Account No (A36)

For inbound messages, the "change medical record no and account no" (A36 event) may be used to update the patient's medical record number and/or account number. For outbound messages, the interface uses this event to update medical record number only. Outbound updates to patient account number are done via a "change patient account number" message (A35 event).

This message uses that same segments as the "change patient account number" (A35 event) message.

Lab Messages

Inbound Lab messages can be received as ORU (Observation Result) messages and will be posted to the Labs tab on patient's profile in Ascend. These clinical lab messages contain patient information in the PID and PV1 segements and then the lab order(s) are contained in the ORC, OBR and OBX segments.

Segment Description
MSH Message Header
PID Patient Identification
PV1 Patient Visit Identification
ORC Common Order
NTE Notes and Comments
OBR Observation Request
OBX Observation/Result
NTE Notes and Comments

Sample Message:

MSH||Ascend|Lab|Ascend|Lab|20080826010407||ORU^R01|0000998398|P|2.4|1|||NE||ASCII||| PID|1|^^^^^^^|000000216490|^^^^^^^|Sample^Joe|^|19501010120000|M|||Sunny Acres^123 Green Acres^Santa Rosa^CA^95403^United States of America^H^^^^||(707)547-1711^PRN^^^^^^^~(707)547-1711^PRN^^^^^^|||||204411|||||||||||||||||||| ORC|RE|1138972^BIOHEMATOLOGY|^||CM|E|||20080826115200|^^||9584^FeelGood^Doctor||||||||||||100 Healing Way^^Santa Rosa^CA^95403^^M^^^^| NTE|1||^This requisition was edited and resaved on the:2008/08/26 12:09:08 PM|GR NTE|2||^This requisition was edited and resaved on the:2008/08/26 12:10:02 PM|GR OBR|1|1138972^BIOHEMATOLOGY|000000799869^BIOHEMATOLOGY|1843^CBC^^^^PANEL|S|20080826115200|20080826120900|||||||20080826120900|^^^^|^^||||||||||||||||||^^||||||||||||| OBX|1|ST|1843^CBC^^^^PANL|1|Result|||N|||F|||||^^||| OBR|2|1138972^BIOHEMATOLOGY|000000799871^BIOHEMATOLOGY|2604^CMP^^^^PANEL|S|20080826115200|20080826120900|||||||20080826120900|^^^^|^^||||||||||||||||||^^||||||||||||| OBX|1|ST|2604^CMP^^^^PANL|1|Result|||N|||F|||||^^||| OBR|3|1138972^BIOHEMATOLOGY|000000799874^BIOHEMATOLOGY|2701^INR^2703^^^TEST|S|20080826115200|20080826120900|||||||20080826120900|^^^^|^^||||||||||||||||||^^||||||||||||| NTE|1||^INRTherapeutic range for INR is 2.00 to 3.00 |GR OBX|1|NM|2701^INR^2703^^^TEST|1|1.03||0.76 - 1.28|N|||F|||||00040^FAKE^MELODY||| OBR|4|1138972^BIOHEMATOLOGY|000000799875^BIOHEMATOLOGY|2741^PTT^^^^TEST|S|20080826115200|20080826120900|||||||20080826120900|^^^^|^^||||||||||||||||||^^||||||||||||| OBX|1|NM|2741^PTT^^^^TEST|1|30|secs|23 - 40|N|||F|||||00040^FAKE^MELODY|||

Order Messages

There are two HL7 message types that can be used to transmit medication/pharmacy orders. These message types are used to transmit new orders, discontinue orders, update orders, and etc. The ORM message type is typically used to transmit "non-perfected" medication orders from a computerized physician order entry system (CPOE) to a pharmacy system. Upon validation/editing of the "non-perfected" order by a pharmacist, the order becomes a "perfected" order ready for dispensing/administration/billing. The RDE message type is typically used to transmit "perfected" medication orders from a pharmacy system to other vendors. For example, order messages sent by the pharmacy system to an automated dispensing system will use the RDE message type. The interface will accept inbound RDE and ORM messages.  

RDE - Pharmacy Encoded Order messages (Perfected)

Segment Description
MSH Message Header
PID Patient Identification
{[AL1]} Allergy
PV1 Patient Visit
ORC Common order
RXE Pharmacy Encoded 
{RXR} Pharmacy Order Route
{[RXC]} Pharmacy Order Component

ORM - Pharmacy Prescription Order messages (Non-perfected)

Segment Description
MSH Message Header
PID Patient Identification
{[AL1]} Allergy
PV1 Patient Visit
ORC Common order
RXO Pharmacy Prescription
{RXR} Pharmacy Order Route
{[RXC]} Pharmacy Order Component

Use of RXC segments   RXC segments are primarily used whenever more than one ingredient is contained in the order. The usual convention is to send the first ingredient in the RXE (or RXO) segment, and each additional ingredient (if any) in separate RXC segments. Therefore, only orders with multiple ingredients would require RXC segment(s).  Some vendors prefer to duplicate the first ingredient data in the first RXC segment even though it was included in the RXO/RXE segment. In such cases, all order messages will contain at least one RXC segment. Please notify HOS if you expect the first RXC segment ingredient to be a duplicate of the ingredient in the RXE (or RXO) segment in order messages you send or receive.

Formulary Messages

The MFN (Master file notification) message type may be used to transmit drug formulary data. This would allow for the automatic maintenance of many of the fields in the (BDidRx, or other vendor's) drug formulary table. Some fields will require manual entry in any case.  

MFN - Master file notification message

Segment Description
MSH Message Header
MFI Master File Identification
MFE Master File Entry
ZFM Formulary Maintenance

Financial Messages

The DFT (Detailed Financial Transaction) message type is used to transmit charges and/or credits to/from Hann's On Software to/from another vendor.  For outbound charges, the other vendor is typically a (hospital) financial system.  For inbound charges, the other vendor is typically an automated dispensing system. The AIP interface can be configured to send one FT1 segment, or multiple FT1 segments, with each DFT message.  

DFT - Detailed Financial Transaction message

Segment Description
MSH Message Header
{EVN} Event Type
PID Patient Identification
{PV1} Patient Visit
[FT1] Financial Transaction

HL7 Message Segment Detail

In this section of the documentation, we will detail the various HL7 segments that may be combined to form the messages supported by the interface. The section documents the fields that make up each of the message segments, and field requirements. Some detailed information will be provided regarding required fields, but optional fields will not usually be explained in detail. Fields that are listed in a table but not described/defined following the table, are not supported or used by the interface at this time.

The start block and end block characters that delimit each message (as discussed earlier) will not be included in the message descriptions below, but are never-the-less required for working interfaces. In addition, the carriage return character that terminates each segment will also not be included in the descriptions, but are also required for working interfaces.

Segment ID

Each segment must be preceded with an appropriate, unique 3 byte segment identifier (Segment ID). Although not treated as (or sequentially counted as) an official HL7 field, the segment ID is listed first in each of the following segment definition tables for easier reference.

Segments Used for All Messages

MSH - Message Header Segment

The MSH segment is required for all messages and will always be the first segment in the message. Thus every message will have at least two segments.

Seq Len Fmt Opt Field Name
0 3    R Segment ID = "MSH"
1 1 ST R Field Separator
2 4 ST R Encoding Characters
3 20 HD R Sending Application
4 20 HD R Sending Facility
5 20 HD R Receiving Application
6 20 HD R Receiving Facility
7 14 TS R Date/Time Of Message
8 40 ST O Security
9 7 CM R Message Type
10 20 ST R Message Control ID
11 3 PT R Processing ID
12 8 ID R Version ID
13 15 NM O Sequence Number
14 180 ST O Continuation Pointer
15 2 ID O Accept Acknowledgment Type
16 2 ID O Application Acknowledgment Type
17 2 ID O Country Code
18 6 ID O Character Set
19 60 CE O Principal Language Of Message

Field separator

This field contains the separator between the segment ID and the first real field. It serves as the separator and defines the character to be used as a field separator for the rest of the message. The interface will always use "|" (ASCII/decimal 124).

Encoding characters

This field contains four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. The interface uses "^~\&" respectively.

Sending application

This field defines which application sent the message. For messages sent by our standard interfaces, this will be user defined.  For messages sent by the BdidRx interface, this will be "BDIDRX".  For messages received by the interfaces, this field should be the other application’s ID. 

Sending facility

This field defines which facility sent the message. For messages sent by the interface, this will be user defined and unique to each installation. The other application should use the same "sending facility" ID to send messages to the interface. The "sending" and "receiving" facility should be the same.

Receiving application

This field uniquely identifies the receiving application among all other applications on the network. This field may be used to route messages through an interface engine. For messages received by the interface from the other system, this should be defined by the other application vendor. For messages received by a BDidRx interface from the other system, this should be "BDIDRX".  For messages sent by the interface to the other system, this will be user defined and specified by the other application vendor.

Receiving facility

This field should be the same as the "Sending facility" (above).

Date/time of message

This field contains the date/time that the message was created in the date/time format: YYYYMMDDHHMM[SS]. The "seconds" portion is optional.

Message type

This is a composite field which includes 2 components: <message type> ^ <trigger event>

Message types are always 3 bytes and are required components. The message types used by the interface include:

ACK General acknowledgment
ADT ADT message (patient admission, discharge, transfer, and etc.)
DFT Detailed financial transaction (billing transaction) *
MFN Master file notification (drug formulary record change)
RDE Pharmacy order

Trigger events are always 3 bytes. Trigger event codes also appear in the EVN (event) segment which is used to process many ADT messages. Recognized trigger events include:

Trigger Event Types

A01 Admit a patient
A02 Transfer a patient
A03 Discharge a patient
A04 Register an Outpatient
A05 Preadmit a patient
A06 Change an Outpatient to Inpatient
A07 Inpatient to outpatient "transfer"
A08 Update patient information
A11 Cancel admission 
A12 Cancel transfer
A13 Cancel discharge
A17 Swap patients
A23 Delete a patient record
A35 Patient ID change
A36 Medical record number change
P03 Post detailed financial transaction 

Message control ID

This field contains a value that uniquely identifies the message. The receiving system should echo this ID back to the sending system in the ACK message’s MSA segment. If a message is re-sent for any reason, the message control id will remain the same for each transmission of the identical message.

Processing ID

P = Production, D = Debugging, T = Training

Version ID

This is the HL7 version number in use. The interface will use version "2.2" in this field

MSA - message acknowledgment segment

The MSA segment is part of the "ACK" message type and is used to acknowledge a previously received message.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "MSA"
1 2 ID R Acknowledgment Code
2 20 ST R Message Control ID
3 80 ST O Text Message
4 15 NM O Expected Sequence Number
5 1 ID O Delayed Acknowledgment Type
6 100 CE O Error Condition

Acknowledgment code

AA Application Accept
AE Application Error
AR Application Reject

Message control ID

This field contains the same message control ID that was in the message created by the sending system. It allows the sending system to match the response to the original message.

Text message

This optional field further describes an error condition.

Admissions Message Segments

PID - patient identification segment

The PID segment contains information about the patient, and is used to specifically identify the patient in the Ascend-IP or BDidRx database.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "PID"
1 4 SI O Set ID - Patient ID
2 12 CX O Patient ID (External ID)
3 16 CX R Patient ID (Internal ID)
4 20 CX O Alternate Patient ID - PID
5 48 PN R Patient Name
6 48 PN O Mother’s Maiden Name
7 14 TS O Date/Time of Birth
8 1 IS O Sex
9 48 PN O Patient Alias
10 1 IS O Race
11 106 AD O Patient Address
12 4 IS O County Code
13 20 TN O Phone Number - Home
14 20 TN O Phone Number - Business
15 20 CE O Primary Language
16 1 IS O Marital Status
17 3 IS O Religion
18 12 CX R Patient Account Number
19 11 ST O SSN Number - Patient
20 25 ST O Driver's License Number - Patient
21 9 CX O Mother's Identifier
22 3 IS O Ethnic Group
23 20 ST O Birth Place
24 2 ID O Multiple Birth Indicator
25 2 NM O Birth Order
26 4 IS O Citizenship
27 60 CE O Veterans Military Status
28 80 CE O Nationality
29 8 TS O Patient Death Date and Time
30 1 ID O Patient Death Indicator

Patient ID (Internal ID)

This field should contain the patient’s medical record number. This number should be the same each time the same patient is admitted/registered. The interface will use this field a secondary identifier for the most recent admission (patient account number, field sequence #18, will be the primary identifier - see below). This field could be used by the interface to locate previous admission/order data for the patient. 

Unless otherwise specified, HOS preferentially accepts/sends the patient's medical record number in this field using a simplified format: i.e., as one component, including the check digit if one is employed (e.g., ...|12345678|...). This differs from the standard HL7 format which would have the check digit appear as a second component (e.g., ..|1234567^8|...  HOS will ignore any data following the first component of this field. Contact HOS if you are unable to send/accept this field in this simplified manner.

Patient name

This field contains one or more components. The first component is required. The last two components (suffix and prefix) are not used by the interface and will be ignored.

<family name (20)> ^ <given name (12)> ^ <middle initial or name> ^ <suffix> ^ <prefix>

Date/Time of birth

This field contains the patient’s date of birth (CCYYMMDD). Although this is an optional field, it is a highly desirable one and should be completed when possible.

Patient address

Although this field is optional, it is highly desirable for outpatient registrations/admissions. The field components and subcomponents include:

<street address> ^ <2nd street address line> ^ <city> ^ <state> ^ <zip/postal code> ^ <country> ^

Phone number - home

Although this field is optional, it is highly desirable for outpatient registrations/admissions. The area code is not required. Format: Components: [(999)]999-9999

Patient account number

This field contains the unique patient account number assigned by the hospital for each admission/registration. If the same patient is admitted/registered again, the number should be different each time. Typically, pharmacy charges for the patient (i.e., for this admission/registration) are posted to this number. This field will be the primary patient identifier for the interface.

Unless otherwise specified, HOS preferentially accepts/sends the patient account number field in a simplified format: i.e., as one component, including the check digit if one is employed (e.g., ...|12345678|...). This differs from the standard HL7 format which would have the check digit appear as a second component (e.g., ..|1234567^8|...  HOS will ignore any data following the first component of this field. Contact HOS if you are unable to send/accept this field in this simplified manner.

EVN - event type segment

The EVN segment specifies the type of event contained within the message. Not all HL7 messages will include the EVN.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "EVN"
1 3 ID R Event Type Code
2 14 TS R Recorded Date/Time
3 14 TS O Date/Time Planned Event
4 3 IS O Event Reason Code
5 10 CN O Operator ID
6 26 TS O Event Occurred

Event type code

This field indicates the specific type of message. It is most commonly used to send ADT messages to the interface. This field will contain the same data as the "trigger event" (i.e., the second component of the MSH segment’s "message type" field). Refer to the event table listed in the MSH-"message type" section above.

Recorded date/time

This contains the date and time that the event was triggered on the hospital/pharmacy system. The interface will recognize two formats:

(1) CCYYMMDDHHMMSS

(2) CCYYMMDDHHMM

PV1 - patient visit segment

The PV1 segment is used to convey additional information about the patient’s admission/registration that is unique to this visit.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "PV1"
1 4 SI O Set ID - PV1
2 1 IS R Patient Class
3 40 PL O Assigned Patient Location
4 2 IS O Admission Type
5 20 CX O Pre-admit Number
6 40 PL O Prior Patient Location
7 60 CN O Attending Doctor
8 60 CN O Referring Doctor
9 60 CN O Consulting Doctor
10 3 IS O Hospital Service
11 80 PL O Temporary Location
12 2 IS O Pre-admit test Indicator
13 2 IS O Readmission Indicator
14 3 IS O Admit Source
15 2 IS O Ambulatory Status
16 2 IS O VIP Indicator
17 60 CN O Admitting Doctor
18 2 IS O Patient Type
19 20 CX O Visit Number
20 4 FC O Financial Class
21 2 IS O Charge Price Indicator
22 2 IS O Courtesy Code
23 2 IS O Credit Rating
24 2 IS O Contract Code
25 8 DT O Contract Effective Date
26 12 NM O Contract Amount
27 3 NM O Contract Period
28 2 IS O Interest Code
29 1 IS O Transfer to Bad Debt Code
30 8 DT O Transfer to Bad Debt Date
31 10 IS O Bad Debt Agency Code
32 12 NM O Bad Debt Transfer Amt.
33 12 NM O Bad Debt Recovery Amt.
34 1 IS O Delete Account Indicator
35 8 DT O Delete Account Date
36 3 IS O Discharge Disposition
37 25 CM O Discharged to Location
38 2 IS O Diet Type
39 2 IS O Servicing Facility
40 1 IS O Bed Status
41 2 IS O Account Status
42 80 PL O Pending Location
43 80 PL O Prior Temporary Location
44 14 TS O Admit Date/Time
45 14 TS O Discharge Date/Time
46 12 NM O Current Patient Balance
47 12 NM O Total Charges
48 12 NM O Total Adjustments
49 12 NM O Total Payments
50 20 CX O Alternate Visit ID
51 1 IS O Visit Indicator
52 60 CN O Other Healthcare Provider

Patient class

Field values:

Value Description
E Emergency
I Inpatient
O Outpatient
P Pre-admit

Assigned patient location

This field identifies the current location of the patient. Components: <unit> ^ <room> > ^ <bed>

The first component may be the nursing station or ward. This field should normally be provided for inpatient admissions. The interface may be optionally configured to map certain patient classes or patent types to a pre-defined location, if the hospital/pharmacy system does not provide a location (e.g., map outpatients to a room called "OUTPAT", emergency room patients to "ER", etc.)

Prior patient location

For transfers, this field contains the patient’s prior location. Components: <unit> ^ <room> > ^ <bed)>

Attending doctor

This field contains the attending doctor’s data.

Components: <ID number> ^ <family name> ^ <given name> ^ <middle initial> ^ ^ ^ <degree>

Admitting doctor

This field contains the admitting doctor’s data.

Components: <ID number> ^ <family name> ^ <given name> ^ <middle initial> ^ ^ ^ <degree>

Patient type

This field will be used to pass hospital specific patient types to the interface. For example, if the patient class is "O" (outpatient), the patient type could be used to screen out unwanted "laboratory" or "radiology" patient types from being admitted to the database. Although normally optional, this field may therefore be required for some patient classes for some installations.

Servicing Facility

This field will be used to receive/pass the Facility Id field in the Facilities table for which the patient belongs. This field determines which facility the patient will be linked to. In order for the patient record to be correctly linked to a facility, you must pass the Facility Id in this field.

AL1 - patient allergy information segment

The AL1 segment is used to transmit patient allergy information. One AL1 segment is sent for each separate patient allergy. Therefore a series of (none, 1 or more) AL1 segment(s) may be included in ADT messages, or in pharmacy order (RDE) messages.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "AL1"
1 4 SI O Set ID - Internal
2 2 IS O Allergy type
3 60 CE R Allergy description
4 2 IS O Allergy severity
5 15 ST O Allergy reaction
6 8 DT O Identification Date

Allergy Type

This field indicates a general allergy category. See table below for possible values.

Value Description
DA Drug Allergy
FA Food Allergy
MA Miscellaneous Allergy

Allergy description

This field consists of several components as follows: <Allergy identifier>^<Text>^<Coding system>

If the hospital/pharmacy system uses First Databank DAA.DAT files, the allergy identifier would be the FDB assigned allergy code (Alphanumeric e.g.,00 to 98, A1, etc); the allergy text description would be in "Text" and the coding system would be "FDBDAA". Otherwise, allergies will be transmitted as free text in the "Text field" and the other two components are left blank.

OBX - observation segment

An OBX segment is used to transmit one observation (e.g., patient’s height) to the interface. Additional OBX segments are sent for separate observations. Patient height and weight are currently the only observations supported by the interface.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "OBX"
1 10 SI O Set ID - OBX
2 2 ID R Value Type
3 20 CE R Observation Identifier
4 20 ST O Observation Sub-ID
5 10 NM R Observation Value
6 20 CE R Units
7 10 ST O References Range
8 5 ID O Abnormal Flags
9 5 NM O Probability
10 2 ID O Nature of Abnormal Test
11 1 ID O Result Status
12 14 TS O Date of Last Normal Values
13 20 ST O User Defined Access Checks
14 14 TS O Date/Time of the Observation
15 60 CE O Producer's ID
16 80 CN O Responsible Observer
17 60 CE O Observation Method

Value Type

Always ‘ST’.

Observation Identifier

Components: <identifier> ^ <text> ^ <name of coding system>

The interface can use the following components:

Identifier Text Coding system

1010.3 HEIGHT AS4

1010.1 WEIGHT AS4

Observation Value

Actual height or weight value.

Units

Unit of measure. For height, use "CM" for centimeters or "IN" for inches. For weight, use "KG" for kilograms or "LB" for pounds.

Examples:

OBX||ST|1010.1^WEIGHT^AS4||65|KG<cr>

OBX||ST|1010.3^HEIGHT^AS4||180|CM<cr>

DG1 - diagnosis segment

The DG1 segment is used to transmit one patient diagnosis to the interface. Additional DG1 segments are sent for separate diagnoses. If there is a new diagnosis, or a change in any of the diagnoses, they should all be resent to the interface.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "DG1"
1 4 SI O Set ID - Diagnosis
2 2 ID R Diagnosis coding method
3 8 ID O Diagnosis code
4 40 ST R Diagnosis description
5 14 TS R Diagnosis date/time
6 2 ID R Diagnosis/DRG type
7 4 ST O Major diagnostic category
8 4 ID O Diagnosis related group (DRG)
9 2 ID O DRG approval indicator
10 2 ID O DRG grouper review code
11 2 ID O Outlier type
12 3 NM O Outlier days
13 12 NM O Outlier cost
14 4 ST O Grouper version and type

Diagnosis coding method

ICD9 is the only valid coding system supported by the interface. This field should contain "I9" if the diagnosis is an ICD9 coded diagnosis. Otherwise, the field should be omitted.

Diagnosis code

If the ICD9 code is available, it should be placed here.

Diagnosis description

This field should contain the diagnosis description (i.e., either the one related to the ICD9 code, or free text).

Diagnosis/DRG type

Valid types include "ADMITTING", "INTERIM" and "FINAL"

MRG - merge information

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "MRG"
1 16 CX R Prior Patient ID - Internal
2 20 CX O Prior Alternate Patient ID
3 12 CX R Prior Patient Account Number
4 12 CX O Prior Patient ID - External
5 20 CX O Prior Visit Number
6 20 CX O Prior Alternate Visit ID
7 48 PN O Patient Name

Prior Patient ID - Internal

This field will typically contain the incorrect medical record number. HOS will preferentially send/receive this field in a simplified format, as discussed under  PID - patient identification segment.

Prior Patient Account Number

This field will typically contain the incorrect patient account number. HOS will preferentially send/receive this field in a simplified format, as discussed under  PID - patient identification segment.

The interface ignores MRG segment fields 5-7 for inbound and outbound messages at this time.

Pharmacy Order Segments

Pharmacy order messages (RDE) include some segments that have already been discussed in the admissions area (e.g., PID, PV1, etc.). The remaining RDE segments are reviewed below.

ORC - common order segment

The ORC segment is used to transmit order data that is common to all order message types (e.g., laboratory, radiology, pharmacy, etc.). One ORC segment is sent for each pharmacy order. For pharmacy/medication orders, ORC segments are typically used with RDE (Pharmacy Encoded) "perfected" order messages and with ORM (Pharmacy Prescription) "non-perfected" order messages.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "ORC"
1 2 ST R Order control
2 25 CM R Placer order number
3 25 CM O Filler order number
4 30 CM O Placer group number
5 2 ST O Order status
6 1 ST O Response flag
7 200 CM O/R Timing / Quantity   (Required for ORM messages)
8 200 CM O Parent
9 14 TS R Transaction date/time
10 60 CN O Entered by
11 60 CN O Verified by
12 80 CN O Ordering provider
13 80 CM O Location for enterer
14 20 TN O Call back phone number
15 14 TS O Order effective date/time
16 200 CE O Order control reason
17 60 CE O Entering organization
18 60 CE O Entering device

Order Control

This field contains the purpose of the RDE order message. Values include:

Value Description
NW New order
CA Cancel order
DC Discontinue order
HD Hold order
RL Release/cancel previous hold
XO Change/update order

Placer order number

In general, the placer order number should identify the application that created or "placed" the order, whereas the filler order number (below) should identify the application that fulfills (dispenses/administers) the order. For example, a CPOE system would normally be the placer, and the pharmacy system receiving the order would normally be the filler. However, when no CPOE system is in use and the order is originally entered into the pharmacy system, then sent to an automated dispensing system, the pharmacy system would normally be the placer and the automated dispensing system the filler !!  Fortunately, vendors can come to an agreement that one of the applications is to always be placer and one is to always be filler, if desired. A new version of the Ascend interface (i.e., after 2/2004) provides table driven options to identify Ascend as the filler or placer for each vendor interface/connection.

The placer order number is a composite field. The first component is a string that uniquely identifies the order for the specified patient on the hospital/pharmacy system (the "placer"). The optional second component contains the Application ID of the application that placed the order.
    e.g., <Order number>^<Application ID>.

Filler order number

In general, the filler order number should identify the application fulfills the order (also see Placer order number above for a more detailed explanation).  The filler order number is a composite field. The first component is a string that uniquely identifies the order for the specified patient on the system that fullfills (dispenses/administers) the order. The optional second component contains the Application ID of the application.
    e.g., <Order number>^<Application ID>.

Timing/Quantity

For RDE "perfected" pharmacy order messages, this is an optional field since the Quantity/Timing field found in the RXE segment serves the same purpose. If provided, it must match the data in the corresponding RXE field. However, for inbound ORM "non-perfected" pharmacy orders, this composite field is required since the RXO segment does not provide a corresponding Quantity/Timing field. Refer to the RXE Quantity/Timing documentation for detailed information about this field, subcomponents and options.

Transaction Date/Time

This is the date and time that the transaction was entered into the hospital/pharmacy order entry system.

Entered By

This field identifies the person who entered the order into the hospital/pharmacy system. Since the RXE segment does not have a corresponding field for this data, this field should be included if the "entered by" data must appear in the database.

Verified By

This optional field identifies the person who verified the order (i.e., if the order was entered by somebody whose work needs to be checked by a pharmacist). This field can contain the same data as the RXE field "Pharmacist verifier ID".

RXE - pharmacy encoded  segment

The RXE segment is the "master" pharmacy order segment. It is used for all types of pharmacy orders including unit dose orders and IV solution orders. It will contain data about the primary ingredient only. Additional ingredients such as IV additives, are contained in associated RXC segments. RXE segments should only be used in Pharmacy Encoded Order messages (i.e., Perfected orders), whereas ORM messages (i.e., Pharmacy medication order, Non-perfected orders as might be received from a CPOE system) will use an RXO segment.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "RXE"
1 200 TQ R Quantity/Timing
2 100 CE R Give code/Drug identification
3 20 NM R Give amount/minimum
4 20 NM O Give amount/maximum
5 60 CE R Give units
6 60 CE O Give dosage form
7 200 ST R Providers administration instructions
8 12 ID O Deliver to location
9 1 ID O Substitution flag
10 20 NM O Dispense amount
11 60 CE O Dispense units
12 3 NM O Number of refills ordered
13 60 CN O Ordering doctor’s DEA number
14 60 CN O Pharmacist verifier ID
15 20 ST O Prescription number
16 20 NM O Number of refills remaining
17 20 NM O Number of refills/doses dispensed
18 26 TS O Date/time of most recent refill/dispense
19 10 CQ O Total daily dose
20 1 ID O Needs human review
21 200 ST O Pharmacy special dispensing instructions
22 20 ST O Give per (unit of time)
23 6 ST O Give rate amount  (for IV solution orders)
24 20 ST O Give rate units     (for IV solution orders)

Quantity/Timing

This composite field describes how much of the drug is to be administered, when it is to be administered and for how long. This field applies to the entire order. This field is required in the RXE segment whereas its counterpart in the ORC segment is optional. The quantity/timing data includes any changes (from the original doctor’s order) that the pharmacist may have made when reviewing the order.

The quantity/timing field has ten components:

Seq Len Fmt Opt Component Name
1 3 NM O Quantity
2 60 CM R Interval
3 10 CM O Duration
4 14 TS R Start date/time
5 14 TS R End date/time
6 2 CE O Priority
7 60 ST O Condition
8 60 ID O Text description
9 10 CM O Secondary timing or conjunction component
10 10 CM O Order sequencing

Quantity

This component specifies the number of tablets, capsules, etc. of the drug to administer at each scheduled time. If omitted, the assumed quantity is 1.

Interval

This component is comprised of 2 subcomponents (separated by the subcomponent separator "&"):

<SIG code> <Interval>&<Actual administration times>

Both of the two subcomponents are required if this is a scheduled order with fixed administration times. The actual administration times must be sent. The actual administration times should be in military time format and separated by commas.

e.g., ^TID&0800,1600,2200^"

On the other hand, scheduled orders with interval-based SIG Code must have the SIG code subcomponent and must include a start date/time but will not include actual (fixed) administration times. The SIG Code and interval are included since the interval may or may not be included in the Sig Code.

e.g., ^Q8H Q8H^"

e.g., ^DAILY Q24H^"

SIG codes normally include the common frequency codes found in pharmacy order entry systems (e.g., QD, BID, TID, QID, QOD, QintegerH [where integer is a number in hours; e.g., Q4H = every 4 hours], PRN, PRNxxx [where xxx can specify specific times e.g., PRNQ6H], and etc.).

To indicate specific days of the week: 

In some cases, an inbound order message includes "Interval" components that contain insufficient information to calculate how often to actually schedule each dose. This will result in an order with no doses scheduled. In such cases, the pharmacist will have to add more specific instructions to the order to generate a dosage schedule. An example is an Interval of "Continuous" for an IV solution order. Without an IV solution volume and a rate of administration and/or an interval, the order administration times (e.g., "hang times") cannot be calculated.

Duration

This component specifies how long the order is to remain active. If this component is not provided, the End date/time component must be provided. When both are provided, the interface will use the more restrictive value. The duration is specified as follows:

Value Description
S<number> Order is active for <number> seconds
M<number> Order is active for <number> minutes
H<number> Order is active for <number> hours
D<number> Order is active for <number> days
W<number> Order is active for <number> weeks
L<number> Order is active for <number> months
INDEF Order is active indefinitely

If the order duration is set to INDEF, the interface will apply a user defined number of days to keep the order active. (typically 15 to 30 days).

Start Date/Time

This field is used to specify the first date/time that the medication should be administered. It is a required field.

End Date/Time

This component is used to specify the date/time that the medication should be discontinued (not administered). If this component is not specified, then the duration must be provided. When both are provided, the interface will use the more restrictive value.

Priority

This component describes the urgency of the request and is not used by the interface.

Condition

This component describes the criteria for administering the drug. For example, "As needed for pain" or "to maintain systolic BP < 140". In the database, this will appear as part of the SIG.

Text Description

If this is a scheduled order, this field should be masked with eight zeros "00000000". he first zero representing Sunday and the seventh represent Saturday. The eight zero represents an every other day order. If an order were scheduled Monday, Wednesday and Friday then the "TextDescription" component would read "01010100". If an order were scheduled every other day then the "TextDescription" component would read "00000001".

For non-scheduled orders, this component can be used to describe the administration interval without using SIG codes. For example, "Take as needed".

Secondary Timing or Conjunction Component

This field is ignored by the interface.

Order Sequencing

This field is ignored by the interface.

Give code/drug ID

This field includes 3 components: <identifier>^<description>^<coding system>

The Give code identifies the drug ordered for the patient and must uniquely identify a drug from the drug formulary. The interface will usually use the hospital/pharmacy’s unique charge code for the drug as the identifier. The description is a text description of the drug. It may include the drug strength/volume and dosage form/route. The coding system should contain the value "CDM" if the charge code is being used, or "UNIQUE" if the unique drug formulary record reference number is used.

e.g., <54678990>^VANCOCIN 500MG INJECTION^CDM

Give amount minimum

For varying amount orders, this should be the minimum amount of medication to be given to the patient per dose. For non-varying order, it is the exact amount to be given with each dose. The give amount may refer to a strength, volume, or number of tablets/capsules, etc. For example, for a dosage of Tylenol 650mg, the patient might receive two 325mg tablets per dose. The give amount, in this case, could be "650" or "2". The unit of measure in each case (e.g., mg or tablets) will be defined in the "Give units" (see below).

Give amount maximum

In a varying amount order, this is the maximum ordered amount of medication to be given with each dose. In a non-varying dose order, this field can also contain the exact amount, but this is optional.  If the maximum dose is the same as the minimum dose, receiving vendors should interpret this as being an order with non-varying dosage amounts.  

HOS does not recommend using varying doses for one order to meet recent regulatory requirements and medication safety recommendations. Instead, several orders should be sent, each with a specific non-varying dose. For example, instead of sending one "variable dose" order for "DEMEROL INJ 50-100MG AS NEEDED FOR PAIN", three orders (one each for each available product strength: DEMEROL INJ 50MG, 75MG and 100MG) should be sent.

Give Units

This field clarifies the unit of measure for the "Give minimum/maximum" fields. The interface will append this value to the end of the "Give amount" for display/storage purposes. Typical units include: ML, MG, GM, L, UNITS, TABLETS, CAPSULES, PACKETS, BOTTLES, and etc.

Provider's administration instructions

The ordering provider’s instructions to the nurse or other person who will be administering the medication. This free text field should contain the entire SIG. e.g., "Give 200mg QID X 4 days"

Pharmacist verifier ID

This is the ID of the pharmacist who verified the order. If the verifying pharmacist is to be contained in the database, it must be provided here.

Prescription Number/Rx Number

This may be a unique number assigned to the order by the hospital/pharmacy system. This number may or may not be the same as the Placer order number in the ORC segment. In any case, the interface uses the ORC segment Placer order value to locate the hospital/pharmacy system’s order within the database

Pharmacy Special Dispensing Instructions

These are special instructions from the pharmacist to the nurse or other person administering the medication. For outbound data, the order's 'SIG' and 'Comments' fields are combined to populate this field. 

Give rate amount

This field should only be used for IV solutions, enteral solutions, irrigations, and similar "fluid" orders that can be properly described in milliliters per hour. Otherwise the field should not be sent.

Give rate units

If a Give rate is provided, the only units recognized by the interface at this time are "ML/HR"

RXO - pharmacy prescription segment

The RXO segment is the "master" pharmacy prescription segment found in ORM messages (i.e., Pharmacy medication orders as might be received from a CPOE system; "Non-perfected" orders that have not been checked or edited by a pharmacist) . The RXO will contain data about the primary ingredient only. Additional ingredients such as IV additives, are contained in associated RXC segments. 

After a "non-perfected" order (i.e., an ORM message containing an RXO segment) has been checked/edited by a pharmacist, the order becomes "perfected". Subsequent order messages containing "perfected" orders should use the RDE message format and contain an RXE segment. 

Also note that RXO segments do not have a Quantity/Timing field as found in the RXE segment. Inbound ORM messages also contain ORC segments, and the Quantity/Timing field in the ORC is intended to serve the same purpose as the Quantity/Timing field in the RXE segment.

RXO segments are very similar to RXE segments and share many of the same fields. Please refer back to the RXE segment definitions above for more information on corresponding RXO fields. In most cases, the RXO field names are the same as the RXE names except they have the word "Requested" appended to the front. (e.g., the RXE "Give Code" is the same as the RXO "Requested Give Code"). 

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "RXO"
1 100 CE R Requested Give code (Drug identification)
2 20 NM R Requested Give amount/minimum
3 20 NM O Requested Give amount/maximum
4 60 CE R Requested Give units
5 60 CE O Requested Give dosage form
6 200 ST R Pharmacy instructions
7 200 ST O Administration instructions
8 12 ID O Deliver to location
9 1 ID O Allow Substitution 
10 100 CE O Requested Dispense code
11 20 NM O Requested Dispense amount
12 60 CE O Requested Dispense units
13 3 NM O Number of refills ordered
14 60 CN O Ordering doctor’s DEA number
15 60 CN O Pharmacist verifier ID
16 1 ID O Needs human review
17 20 ST O Requested Give per (unit of time)
18 20 ST O Requested Give strength
19 20 ST O Requested Give strength units
20 200 CE O Indications
21 6 ST O Requested Give rate amount (for IV solution orders)
22 20 ST O Requested Give rate units (for IV solution orders)

RXR - pharmacy route segment

The RXR segment is used to specify the route or method of drug administration.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "RXR"
1 60 CE R Route
2 60 CE O Site
3 60 CE O Administration device
4 60 CE O Administration method

Route

The allowable route for administering this medication in the format: <Route code>^<Route description>

The interface expects all route codes to be 2 bytes. e.g., PO^BY MOUTH

RXC - pharmacy component segment

The optional RXC segment is used to convey information about additional ingredients, additives or components of the drug order that cannot be adequately conveyed by the ORC and RXE (or RXO) segments alone. RXC segments are primarily used whenever more than one ingredient is contained in the order. The usual convention is to send the first ingredient in an RXE (or RXO) segment, and each additional ingredient (if any) in separate RXC segments. Therefore, only orders with multiple ingredients would normally require RXC segment(s).  For example, for multi-ingredient orders such as IV solutions with additives, the interface will normally accept the first ingredient’s data (typically the base solution) in the RXE segment, and remaining ingredients/components (typically additives) in subsequent RXC segments.

Some vendors prefer to duplicate the first ingredient data in the first RXC segment even though it was included in the RXO/RXE segment. In such cases, all order messages will contain at least one RXC segment. Please notify HOS if you expect the first RXC segment ingredient to be a duplicate of the ingredient in the RXE (or RXO) segment in order messages you send or receive. In any case, the interface will assume that all received RXC segments are to be logically linked to the most recent ORC/RXE (or ORC/RXO) segments (i.e. part of the current RDE or ORM order message). 

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "RXC"
1 1 ID R Component type
2 100 CE R Component code
3 20 NM R Component amount
4 60 CE O Component units
5 20 NM O Component strength
6 60 CE O Component strength units

Component type

Values for this field include:

Value Description
B Base
A Additive

For IV orders, the "B" value would be used to identify the solution. For non-IV orders, the "B" value may apply to the primary (e.g., greater quantity) base ingredient into which other (lesser quantity) ingredients are mixed. (e.g., if a topical cream is being prepared). If "base" components are present, they should be sent first. The first "base" component should be considered the "primary base". The first "additive" sent should be the "primary additive".

Component code

This field defines the base or additive component in the same manner as the RXE "Give code". The data in the component code refers only to the individual ingredient, not to the entire order.

<identifier> ^ <description> ^ <coding system>

The interface will usually use the hospital/pharmacy’s unique charge code for the drug as the identifier. The description is a text description of the drug. It may include the drug strength/volume and dosage form/route. The coding system should contain the value "CDM" if the charge code is being used, or "UNIQUE" if the unique drug formulary record reference number is used..

e.g., <54678990>^AMPICILLIN 1GM IV^CDM

Component amount

This field identifies the amount of the component to be added. E.g., "500" (for 500MG), "10" (for 10ML), "1" (for 1 vial)

Component units

The units of measure for the component amount are described in this field. E.g., "MG" (for 500MG), "ML" (for 10 ML),"VIAL" (for 1 vial).

Component strength

If the component code description does not include a strength, it should be included here.

Component strength unit

If the component code description does not include the unit of measure, it should be included here. The interface may append the "strength units" to the end of the "strength" for display/storage purposes.

Master File Maintenance Segments

The following message segments are used to update the drug formulary table in the database.

MFI - master file identification segment

The MFI segment identifies which master file is to be updated, and the type of update being performed.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "MFI"
1 60 CE R Master file identifier
2 6 ID O Master file application ID
3 3 ID O File-level event code
4 14 TS O Entered date/time
5 14 TS O Effective date/time
6 6 ID O Response code

Master file identifier

Identifies a standard HL7 master file or a site-specific master file. The format is:

<identifier>^<text>^<name of coding system>^<alternate identifier>^<alternate text>^<name of alternate coding system>

For the interface, the identifier will usually be "ZFM", the text will be "FORMULARY" and the name of the coding system will usually be "CDM" (charge description master file), or "UNIQUE" (the unique drug formulary record reference number). 

Master Files Application ID

The name/code of the application responsible for maintaining the original file.

File-level event code

Currently only the value "UPD" is supported by the interface.

Response Level Code

The field should contain "NE" if it is provided.

MFE - master file entry segment

The MFE segment determines what type of record-level event (e.g. add, delete, modify, etc.) that is to occur.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "MFE"
1 60 CE R Record level event code
2 6 ID O MFN control ID
3 3 ID O Effective date/time
4 14 TS O Primary key value

Record-level event code

This field defines the record-level event that is to be applied to the master file.

Value Description
MAD Add record
MDL Delete record
MUP Update record

Effective Date/Time

The effective date/time for the record-level action.

Primary Key Value

The field which uniquely identifies the drug in the master file. The format for this field is:

<identifier>~<text>~<name of coding system>

The interface will usually use the hospital/pharmacy’s unique charge code for the drug as the identifier. The text is a description of the drug. It may include the drug strength/volume and dosage form/route. The coding system should contain the value "CDM",  or "UNIQUE" if the unique drug formulary record reference number is used.

e.g., 56745622^FERROUS SULFATE 300MG TABLET^CDM

ZFM - drug formulary maintenance segment

The ZFM segment is a special segment used by the interface to receive additional detail about a drug from the hospital/pharmacy system.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "ZFM"
1 30 ST R Generic name
2 30 ST O Brand name
3 20 ST R Hospital/Pharmacy drug code
4 2 ST O Route code
5 14 ST O Strength
6 10 ST O Strength units
7 14 ST O Volume
8 10 ST O Volume units
9 14 ST R NDC
10 10 ST O Dosage
11 10 ST O Dosage units
12 20 ST O Dosage form
13 20 CM O Package size
14 8 ST O AHFS number
15 100 ST O Default order SIG
16 50 ST O Default order comment
17 50 ST O Default label message
18 10 ST O Default IV rate
19 3 NM O Default expiration days
20 2 NM O Default expiration hours
21 30 ST O Bar code ID
22 2 ST O DEA schedule/code
23 10 NM O AWP cost per dosage
24 10 NM O Acquisition cost per dosage

Generic Name

This is the generic name for this medication. The name can include strength, volume, concentration, route and/or dosage form information. E.g., "MEPERIDINE 50MG/ML 2ML SYRINGE", "ACETAMINOPHEN 300MG SUPPOS".

Brand Name

This is the manufacturer’s proprietary name for the medication. The name can include strength, volume, concentration, route and/or dosage form information. E.g, "DEMEROL 100MG INJ", "TYLENOL".

Hospital/Pharmacy drug code

The hospital/pharmacy’s unique code, typically used to charge for this drug. This will be the unique code used by the interface to identify the drug used by the Hospital/Pharmacy system. The code must be unique to each drug to prevent identification of the wrong drug.

Route code

The route of administration for the medication expressed as a 2 byte code. The interface will preferentially utilize route codes defined by First Databank. If multiple routes are possible, leave this field blank.

Strength

The strength of the medication. E.g., "500" (for 500MG). If the strength is not included in the generic name, it should be included in this field. If a concentration is to be expressed, the numerator should be listed in this field and the denominator in the volume field. E.g., "40" (for 40MG / 2ML)

Strength units

The unit of measure for the strength. E.g., "MG" (for 500 MG) and "MG" (for 40MG / 2ML)

Volume

The volume of the medication. E.g., "5" (for 5ML). If the volume is not included in the generic name, it should be included in this field. If a concentration is to be expressed, the denominator should be listed in this field.

E.g., "2" (for 40MG / 2ML)

Volume units

The unit of measure for the volume. E.g., "ML" (for 5ML) and "ML" (for 40MG / 2ML)

NDC number

The National Drug Code number assigned to this medication. The number can be transmitted in "nnnnnnnnnnn" or "nnnnn-nnnn-nn" formats, however, exactly 11 numeric digits must be provided, including zeroes in the appropriate locations to create a "5-4-2" NDC pattern. This field is used to maintain the database with clinical screening data (e.g., for drug interactions) and other First Databank data.

Dosage

The total strength/volume of the medication dosage represented by the pharmacy drug code. For example, the NDC number for the drug might represent a 20ML multi-dose vial, but the pharmacy drug code and the generic name represent a smaller 5ML dosage. In this case, the dosage would be "5".

Dosage units

The unit of measure for the dosage. E.g., "MG" (for 500MG) and "ML" (for 5ML).

Dosage form

The form that the medication is dispensed as. E.g. tablet, patch, capsule, vial, and etc.

Package Size

This field can be used to transmit the package size and/or volume of the formulary item. This field has three components. The first contains the size and/or volume. The second specifies the units of measure. The third contains the package description. I.e., <size/volume>^<units>^<description>

AHFS number

This is the American Hospital Formulary Service number for this drug..

Default SIG

This field is not currently used by the interface.

Default comment

This field is not currently used by the interface.

Default label message

This field is not currently used by the interface.

Default IV rate

This field is not currently used by the interface.

Default expiration days

This field is not currently used by the interface.

Default Expiration hours

This field is not currently used by the interface.

Bar code ID

This is the unique bar code value that will be used to identify a packaged and labeled drug prior to administration to the patient. The value may, in many cases, be the same as the pharmacy drug code. However, it may also be a manufacturer’s bar code, or another user-defined value. 

Currently, this data is only used by the BDidRx interface. If this data cannot be supplied via the BDidRx interface, it will have to be entered directly into the database.

DEA/Schedule code

This is the DEA "narcotic" control schedule for the drug. DEA control/schedule number values range from 1-5.

AWP cost

This field is not currently used by the interface.

Acquisition cost

This field is not currently used by the interface.

Detailed Financial Transaction Segments

The Detailed Financial Transaction message (DFT) is used to send and/or receive charge and/or credit information to/from another vendor.  

If the AIP interface is used to transmit charges to another vendor (e.g., a hospital financial system), these charges are usually held until a predetermined time each day.  At that time, DFT charge messages are sent one-at-a-time, with each message acknowledged by the receiving system before the interface sends the next DFT message. (The interface marks each acknowledged charge with the "transmitted" date/time). This process continues until all non-transmitted charges for the current period have been transmitted, and starts again the next day at the designated time. The process can be launched automatically at a preset time, or manually (menu). 

Batch file creation/transmission of charges can also be done.  Contact HOS for more information on charge transaction batch files.

If the AIP interface is used to receive charges from another vendor (e.g., an automated dispensing system), these charges are usually received/processed throughout the day on a "real-time" basis.

FT1 - Financial Transaction segment

The FT1 segment contains the detail data necessary to post charges and credits to the Ascend database, to a hospital financial system's patient accounting record, and to similar databases.

For inbound DFT messages, fields that are marked as "R" (in the table below, under the Opt column) are required fields, whereas fields marked "O" are optional. In most cases, fields that are required by the receiving system can be provided even if they are marked as "optional" below.

Seq Len Fmt Opt Element Name
0 3    R Segment ID = "FT1"
1 4 SI O Set ID - FT1
2 12 ST O Transaction ID
3 10 ST O Transaction Batch ID
4 14 TS R Transaction Date
5 14 TS O Transaction Posting Date
6 8 IS R Transaction Type
7 80 ST R Transaction Code
8 30 ST O Transaction Description
9 30 ST O Transaction Description - Alternate
10 8 NM R Transaction Quantity
11 12 CP O Transaction Amount Extended
12 12 CP O Transaction Amount Unit
13 60 CE O Department Code
14 30 CE O Insurance Plan
15 12 CP O Insurance Amount
16 40 PL O Assigned Patient Location
17 1 IS O Fee Schedule
18 50 IS O Patient Type
19 60 CE O Diagnosis Code
20 120 XCN O Performed By Code
21 12 XCN O Ordered By Code
22 12 CP O Unit Cost
23 22 EI O Filler Order Number
24 120 XCN O Entered By Code
25 80 CE O Procedure Code

As of 10-29-2001, only fields 1-18 are supported for outbound DFT messages.  Inbound DFT messages may include fields 19-25, however they will be ignored by the interface.  Fields listed below may currently used by the interface for some inbound or outbound messages, depending upon the vendor. Fields that are not listed are not currently in use with any vendor.

Set ID - FT1 

For the first occurrence of the segment the sequence number would be 1, for the second occurrence it would be 2, etc. 

Transaction Date

This is the date the charge or credit occurred.  (For scheduled medications, this will also be the date the drug was scheduled to be administered). For outbound transactions the format will be CCYYMMDD.  For inbound transactions, the following formats will be accepted: CCYYMMDDHHMM; CCYYMMDDHHMMSS; CCYYMMDD.

Transaction Type 

These values are table driven.  The usual values are “CH” for charges and "CR" (or “CD”) for credits.

Transaction Code

For outbound DFT messages, this field will invariably contain the charge code number (a.k.a. CDM number) for the medication. 

For inbound DFT messages, charge code numbers may be used.  However, charge code numbers may not be unique (i.e., several items in the database may use the same charge code (CDM) value.  While this is usually not a problem for a financial system vendor receiving DFT messages, other vendors may send, or expect to receive, transaction codes based on unique values (such as NDC numbers, formulary record reference numbers, or other unique identifiers).  Contact HOS for more information if this is the case.

Transaction Quantity

This field must contain the quantity to be charged or credited. The quantity should not contain decimal places because most financial systems do not support partial quantities. 

Department Code

This optional field may contain the code representing which department the charges are for.

Patient Type Code

This field, when required by another vendor, will usually contain a code indicating which type of patient the charge/credit is for.

Sample message When configured to bundle all charges and credits for the same patient on the same day (notice there are multiple FT1s under one MSH):

MSH|^~\&|ASCEND|1|AccMgr|1|200501122200||DFT^P03|DFT48390|P|2.3|1|||||| EVN|P03|200501122200||||| PID|||10006579||DUCK^DONALD D||19241010|M|||111 DUCK ST^^FOWL^CA^99999||^^^^^^8885551212|||||40007716|139129819||||||||||| PV1||I|IN1^214^1||||59^BEAR^FOZZIE|||||||||||I|||||||||||||||||||||1|||||200501100452|200501121520||||||| FT1|1|48390||20050111|20050112|CH|66000230^AMLODIPINE BESYLATE|AMLODIPINE BESYLATE||1|||1|||||I||||||| FT1|2|48390||20050111|20050112|CH|66000780^CITALOPRAM HYDROBROMIDE|CITALOPRAM HYDROBROMIDE||1|||1|||||I||||||| FT1|3|48390||20050111|20050112|CH|66001700^FUROSEMIDE|FUROSEMIDE||4|||1|||||I||||||| FT1|4|48390||20050111|20050112|CH|66001990^HYDROCODONE/ACETAMINOPHEN|HYDROCODONE/ACETAMINOPHEN||5|||1|||||I||||||| FT1|5|48390||20050111|20050112|CH|66002650^LISINOPRIL|LISINOPRIL||1|||1|||||I||||||| FT1|6|48390||20050110|20050112|CH|66003750^OXYCODONE HCL SR tab|OXYCODONE HCL SR tab||1|||1|||||I||||||| FT1|7|48390||20050111|20050112|CH|66004070^POTASSIUM CHLORIDE CAP|POTASSIUM CHLORIDE CAP||4|||1|||||I||||||| FT1|8|48390||20050111|20050112|CH|66005630^WARFARIN SODIUM|WARFARIN SODIUM||1|||1|||||I||||||| FT1|9|48390||20050111|20050112|CH|66005690^ZOLPIDEM TARTRATE|ZOLPIDEM TARTRATE||1|||1|||||I||||||| FT1|10|48390||20050111|20050112|CH|66006020^SIMVASTATIN UD TAB|SIMVASTATIN UD TAB||1|||1|||||I||||||| FT1|11|48390||20050111|20050112|CH|66006230^DIGOXIN|DIGOXIN||2|||1|||||I||||||| FT1|12|48390||20050111|20050112|CH|66014830^FONDAPARINUX inj.|FONDAPARINUX inj.||1|||1|||||I|||||||

Sample message when configured to send each charge or credit in a separate message (notice each FT1 has its own MSH):

MSH|^~\&|ASCEND|1|AccMgr|1|200501122200||DFT^P03|DFT48390|P|2.3|1|||||| EVN|P03|200501122200||||| PID|||10006579||DUCK^DONALD D||19241010|M|||111 DUCK ST^^FOWL^CA^99999||^^^^^^8885551212|||||40007716|139129819||||||||||| PV1||I|IN1^214^1||||59^BEAR^FOZZIE|||||||||||I|||||||||||||||||||||1|||||200501100452|200501121520||||||| FT1|1|48390||20050111|20050112|CH|66000230^AMLODIPINE BESYLATE|AMLODIPINE BESYLATE||1|||1|||||I||||||| MSH|^~\&|ASCEND|1|AccMgr|1|200501122200||DFT^P03|DFT48391|P|2.3|1|||||| EVN|P03|200501122200||||| PID|||10006579||DUCK^DONALD D||19241010|M|||111 DUCK ST^^FOWL^CA^99999||^^^^^^8885551212|||||40007716|139129819||||||||||| PV1||I|IN1^214^1||||59^BEAR^FOZZIE|||||||||||I|||||||||||||||||||||1|||||200501100452|200501121520||||||| FT1|1|48390||20050111|20050112|CH|66000780^CITALOPRAM HYDROBROMIDE|CITALOPRAM HYDROBROMIDE||1|||1|||||I|||||||

Sample Pyxis ZPM Load Message:

MSH|^~\&|PYXISRX|PYXISPH|BILLING|BILLFAC|20070424142927||ZPM|EPL^04242007142927|P|2.2|||||| ZPM|L|console|DAYSURG|3|1|1234567|Acme Drug|2|0|0|12|AM1234|DUCK, DONALD|||48|1771856||||4|12|10|20070424142841||

Sample Pyxis ZPM Unload Message:

MSH|^~\&|PYXISRX|PYXISPH|BILLING|BILLFAC|20070423205633||ZPM|EPU^04232007205633|P|2.2|||||| ZPM|U|console|MS4|1|13|1234567|Acme Drug|U|13|13|13|AM1234|DUCK, DONALD|||0|1784263||||0|0|0|20070423205558||

Sample Unperfected Inbound Order Message:

MSH|^~\&|CPOE1|SITEA|ASCEND|SITEA|200802210600||ORM^O01|0221200806000626|P^|2.3|||||||| PID|1||16095||WILLY^CHILLY||19361206000000|M|||13901 ICEFLOW ST^^FARGO^ND^99999 |||||M||110151001|222-22-2222|||||||||||| OBX|1|ST|1010.1^Body Weight||80.74|KG| OBX|2|ST|1010.3^Height||166.37|CM| AL1|1|FA|^MILK ^||NAUSEA/VOMITING|| AL1|2||^^||Tongue swells|| AL1|3|MA|^LATEX^||RASH|| PV1|1|I |E ^301 ^1 ^CPOE HOSPITAL^A|3|||BIRDC^BIRD^CHEERY^F|FreeP^FREESTONE^PEACH^A|^^^|OS ||||1|||BIRDC^BIRD^CHEERY^F|020|1||||||||||||||||||||CPOE HOSPITAL|||||20080221055400||||||||| PV2||||RT TOTAL KNEE||||||||||||||||||||||||||||||||||| ORC|NW|342974^CPOESYS|^||||1&MCG^Once&^D30^20060221055800^^ROUTINE^ROUTINE^^^||20080221060005|||LINDJ^LIND^JENNY^EDELWEISS||||||| RXO|327000510^FENTANYL INJ^CDM|50||MCG|INJECTABLE||||||1&MCG||||||D30|50|MCG|||| RXR|IV ^Intravenous||||

Sample Perfected Outbound Order Message:

MSH|^~\&|ASCEND|SITEA|CPOE1|SITEA|200802210814||RDE^O01|RDE157750|P|2.3||||||| PID|||16095||WILLY^CHILLY||19361206|M|||13901 ICEFLOW ST^^FARGO^ND^99999^^R|||||||110151001|222222222||||||||||| PV1||020|E^301^301||||BIRDC^BIRD^CHEERY|||||||||||020||||||||||||||||||||||||||200802210554|||||||| OBX|1|ST|1010.3^HEIGHT^AS4||165.0|CM|||||M|||||| OBX|2|ST|1010.1^BODY WEIGHT^AS4||81.2|KG|||||M|||||| AL1|1|MA|^MILK||| AL1|2|MA|^LATEX||| AL1|3|MA|^COD||| AL1|4|MA|^SULFA||| ORC|NW|342974|203432||||^ONCE^^200802210558^200802210558^ROUTINE||200802210601||^FARMCIST^JOE|LINDJ^Lind^Jenny|PHARMACY||200802210558|||| RXE|^ONCE^^200802210558^200802210558^ROUTINE|327000510^FENTANYL INJ^CHARGE_CODE|50||MCG|BOTTLE^BOTTLE|^Once ROUTINE ; X 30 Days|||1|||||||||||||||||||| RXR|IV^intravenous||| RXC|A|327000510^FENTANYL INJ|50|MCG||

Non-HL7 Features - Notification

You can write an application to check the status of the interface. There are three values available: LastMessageReceived, LastConnectionTime and LastProgramTime. These values are stored in the INTERFACE.INI file located in the same directory as the interface application. They are stored in the [CONNECTION] section of the file.

LastMessageReceived is the last date/time an inbound message was received from the interface. The value is in mm/dd/yyyy hh:nn format.

LastConnectionTime is the last date/time a connection was confirmed and is updated every 60 seconds. The value is in mm/dd/yyyy hh:nn format.

LastProgramCheck is the last date/time the interface application was running and is updated every 60 seconds. NOTE: This does not mean the interface was connected and receiving transmission, only that the application was alive. The value is in mm/dd/yyyy hh:nn format.