Ascend HL7 Interface Specification

Documentation Version: 5-5-2010

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

Standard (Preferred) Interface Specifications

Other options

Standard Incoming or Outgoing Message Types

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, as implemented by our standard interfaces
• HL7 Messages and their segment combinations, as supported by our standard interfaces
• Detailed information about each support segment, including field descriptions and requirements

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).

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).

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.

* 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.

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.

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.

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.

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.]

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. 

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.

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.

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)

ORM - Pharmacy Prescription Order messages (Non-perfected)

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

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

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.

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:

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

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.

Acknowledgment code

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.

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.

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.

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.

Patient class

Field values:

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.

Allergy Type

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

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.

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.

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

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.

Order Control

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

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.

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:

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.

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: 

• Some vendors use the "TextDescription" component. In this case, the field is masked with eight zeros "00000000", the 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". 
• Other vendors use a third subcomponent of the "Interval" component of the Quantity/Timing field in the RXE segment. This subcomponent might be called "Schedule Interval."  It is indicated by including a second "&", followed by "QJ" and then numbers indicating the days of the week. (e.g., 1=Monday 2=Tuesday 3=Wednesday 4=Thursday 5=Friday 6=Saturday 7=Sunday).  So an order for BID at 8:00 AM and 10:00 PM every Tuesday, Thursday, & Saturday, would contain the following "Interval" component:

  BID QJ246&0800,2200

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.

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:

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).

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.

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

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.

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".

This field is ignored by the interface.

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"). 

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

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). 

Component type

Values for this field include:

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.

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

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.

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

Record-level event code

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

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.

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.

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

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.