HL7 Interface Specification

Crown Software, Inc.186 Lonely Oaks

Killeen, TX 76542Ph. (254) 526-5364

Fax: (254) 526-8008http://www.rx-link.com

1

INTRODUCTION

Crown Software currently has available the following HL7 interfaces to facilitate communications between Rx-Link for Windows and other hospital information systems:

Admissions, Discharges, and Transfers (ADT) (inbound and outbound)

Charges (DFT) (inbound and outbound)

Order Entry (inbound and outbound)

Vending Machine Formulary Maintenance (outbound)

Vending Machine Stocking Levels (ZPM) (inbound)

Key Features:

The HL7 interface runs as a service on Windows NT, Windows 2000, and Windows XP platforms.

Adheres, closely, to the HL7 v2.3.1 specification.

Tightly bound to the Rx-Link for Windows application.

Users do not have to be logged in for the interface to run.

Communicates with other HIS systems via TCP/IP.

Inbound and outbound interfaces are user-configurable providing a high degree of flexibility.

Error logging. Logs are accessible via the HL7 Interface configuration program. Real-time or batch charges to hospital billing systems via TCP/IP connection.

Service events are recorded in the Windows Event logs. All messages, inbound and outbound, utilize the A.A.U. approved Minimum Lower

Layer Protocol (MLLP) of message encapsulation (i.e., 0x0b <message> 0x1c 0x0d).

Service listens for all supported message types on a single TCP/IP port.

Service can be started and stopped via the conventional Windows Services Management Console.

2

HL7 User Interface..........................................................................................................................6HL7 Interface Configuration Screen 8HL7 Error Logs 14Security Menu 16Reports 16

Rx-Link HL7 Message Processing................................................................................................17ADT Events 18DFT (Detailed Financial Transaction) Trigger Events 18RXO (Pharmacy Order) Trigger Events 18

O01 – Order Message..........................................................................................................18O02 – Order Response Message.........................................................................................19

RAS (Pharmacy/Treatment Administration) Trigger Events 19O01 – Order Message..........................................................................................................19

MFN (Formulary Maintenance) Trigger Events 20ZPM Vending Machine Pocket Messages 21ACK Message Processing21

ADT Transaction Processing.........................................................................................................22Processing of Patient Classes and Patient Types 22Admission Transactions (A01) 22Transfer Patient (A02) 23Discharge Patient (A03) 23Register Patient (A04) 23Pre-Admit Patient (A05) 23Transfer Outpatient To Inpatient (A06)23Transfer Inpatient To Outpatient (A07)23Update Patient Information (A08) 23Reverse Discharge (A13) 24Merge Patient Information (A18) 24Change MRN (A34/A47) 25Change Account Number (A35/A49) 25Move Account Information/Patient Account Number (A44 25Sample ADT Transactions 26

Admit (A01)...........................................................................................................................26Transfer Patient (A02)...........................................................................................................26Discharge Patient (A03)........................................................................................................26Transfer Outpatient to Inpatient (A06)..................................................................................26Transfer Inpatient to Outpatient (A07)..................................................................................27Update Patient Information (A08).........................................................................................27Sample A08 Message for Allergy Inactivation.....................................................................27Reverse Discharge (A13).......................................................................................................27Merge Patient Information (A18)..........................................................................................28Change Patient ID (A34/A47)...............................................................................................28Change Patient Account Number (A35/A49)........................................................................28Move Patient Account Information (A44).............................................................................28

Detailed Financial Transaction Processing....................................................................................29

3

Override Charge Processing 30Sample DFT Transactions 31Sample Override Transaction 32

Order Transaction Processing........................................................................................................33Identification of Ordered Substances 34Detailed Discussion of Order Transaction Processing 35

Single Component Medication Order....................................................................................41Single Component IV Order..................................................................................................41IV Orders with more than one component............................................................................41Text Order message...............................................................................................................41Sample Piggyback Order.......................................................................................................41

Pharmacy/Treatment Administration Messages............................................................................42Medication Administration:...................................................................................................43Primary IV:............................................................................................................................43Piggy-back IV........................................................................................................................43Multiple Order Administration Message...............................................................................43Multiple Administrations For a Single Order........................................................................44

Vending System Pocket Message Processing................................................................................45Pocket Load...........................................................................................................................46Pocket Unload........................................................................................................................46Pocket Fill..............................................................................................................................46Pocket Content/Count............................................................................................................46

HL7 Message Segments................................................................................................................47MSH Segment Definition 47MSA Segment Definition 48

Acknowledgment Codes......................................................................................................48ERR Segment Definition 48EVN Segment Definition 49PID Segment Definition 50PV1 Segment Definition 51AL1 Segment Definition 52MRG Segment Definition55DG1 Segment Definition 56FT1 Financial Transaction Segment 57NTE Notes and Comments Segment 58OBX Observation/Result Segment 59ORC Common Order Segment 60RXA Pharmacy/Treatment Administration Segment 63RXR Pharmacy/Treatment Route Segment 68RXO Pharmacy/Treatment Order Segment 69RXE Pharmacy/Treatment Encoded Order Segment 74MFI - Master File Identifier Segment 78MFE Master File Entry Segment 79ZFM Formulary Maintenance Segment 81

Sample ZFM Segment...........................................................................................................82ZPM Segment 83

4

Other Segments..............................................................................................................................84ZAD Segment Definition 84

5

HL7 User Interface

The HL7 User Interface allows users a high degree of control over the way the HL7 interface is configured. In addition, the graphical user interface allows the user to:

The graphical user interface for the HL7 is secure in that, to use the application, a user must:

Have the application installed on their system. Have the ability to start and stop the HL7 service for configuration changes to take

effect. Be able to log in to the Rx-Link for Windows application as a valid user.

When the application is first launched, the user is presented with the following screen:

The user must enter a valid Rx-Link for Windows user name and password to get beyond this point. Once a valid user name and password are entered, the user is presented with the screen. The menu options allow the user to:

Configure the HL7 Interface View the HL7 Error Logs Run reports based on the error logs Log into or out of the application Exit the application

6

When a customer purchases an HL7 interface, all of the interfaces are installed. Only purchased interfaces are enabled. When a user desires to implement another interface, they simply contact Crown Software. A representative will connect to the machine where the service is running, temporarily stop the service, enable and configure the new interface, and restart the service.

Interfaces supported by the Crown Software Interface include:

Inbound and outbound patient administration messages (ADT) Inbound and outbound charges (DFT) Inbound pharmacy orders (RXO Outbound profiles for vending Systems (RXE) Outbound formulary maintenance messages for vending systems (MFN) Inbound vending messages to maintain vending machine pocket levels (ZPM)

7

HL7 Interface Configuration Screen

The settings at the top of the HL7 Configuration Dialog affect all of the enabled interfaces. Tabs exist to permit the user to configure individual interfaces.

Shared Settings:

Retain Error Records For ____ Days

Sets the number of day’s error logs the HL7 will maintain. Error log transactions that exceed this specified number of days in age are automatically purged from the log by the interface.

8

Receive Data On Port

Specifies the listening port to be used by the HL7 interface. All inbound transactions should be sent to this port by third-party systems. When a request for communication is received on this port, the service grants the request and opens another port to be used for the communication between the third-party system and the Rx-Link HL7 interface.

Error Printer

Any windows or network printer that the HL7 interface can print to. Some errors cannot be handled by the HL7 and are not appropriate to storage in the Windows event logs. These errors are deemed serious enough to warrant some form of notification being generated. These errors will be printed on the specified printer. It is recommended that this printer be located in the pharmacy so they can monitor it. This printer does not have to be dedicated for use by the HL7 interface. The interface simply needs to be told where to print error reports for transactions it could not process. These errors are exceptions and are not recorded in the HL7 Error Logs.

Start Block Character, End Block Character, End of Data Character

These setting specify the characters to be used for the MLLP encapsulation of all HL7 messages. The default settings are the settings most commonly used by UNIX, DataGate, and other systems to encapsulate TCP/IP message traffic.

The Rx-Link HL7 Interface will expect all inbound messages to be encapsulated with the specified characters. Likewise, all outbound messages generated by the interface will be encapsulated with the specified characters.

Print Notification Of Rejected Orders

This setting, when enabled, will cause the HL7 Interface to print rejected Order Requests to the printer identified in the Error Printer setting. The printout will consist of the raw HL7 message received by the interface and an explanation of why it was rejected by the interface.

Send Response Messages

This setting controls whether the HL7 will send response messages to an ordering system. It should only be enabled/checked when an ordering system is sending order requests to the HL7 Interface. Note that the Inbound frame for RDE messages contains a setting for and IP Address and Port. These settings must be completed before the HL7 can send response messages to the ordering system. None of the other inbound interfaces have these settings. The interface cannot depend upon the port on which the request was sent remaining open. Consequently, there must be a unique port identified to send response messages to.

9

For Order, Medications Will Be Identified By

When processing pharmacy order (RDE) messages, the Crown Software HL7 Interface can use either the medication’s charge code or the drug ID number assigned by Rx-Link For Windows to identify a medication. If the option to use the charge code to identify medications in order messages is selected, charge codes must be unique. Non-unique charge codes will result in order transactions being rejected by the HL7 Interface.

NOTE: This setting also affects the way medications are identified for charge transactions.

Interface Specific Configuration Settings

Keep Inbound/Outbound Socket Open Once Connected

The first inbound or outbound transaction will initiate a TCP/IP socket to handle the processing of the transaction. If this option is checked that socket will not be closed when the transaction processing is completed. It will remain open and all subsequent communications will take place using that socket. If the option is not checked, each new inbound or outbound transaction will create a new TCP/IP socket for processing the transaction. Once the transaction is processed, the socket is closed and destroyed. The default setting is to keep the socket open.

Segments Terminated By

The HL7 specification stipulates that message segments will be terminated by a carriage return <CR> or (0x0d). Many vendors choose to terminate message segments with a carriage return-linefeed combination <CR><LF> or (0x0d 0x0a). This often calls for reprogramming the interface to work with other vendors. Crown Software has made this user-configurable so, no matter how other vendors terminate segments in their HL7 messages, our HL7 can accommodate them.

Receive and Process Merge Transactions

HL7 merge transactions involve electronically updating, changing, or merging data such as medical record numbers and/or patient account numbers. This can cause problems when medical record number or account numbers are incorrectly merged. For this reason, some pharmacy directors prefer to handle these types of transactions manually. If this option is checked, these merge transactions are accepted and processed by the HL7. If it is unchecked, merge transactions will not be processed. No errors will result from merge transactions being sent to the interface when the option is not checked. Messages containing merge transactions are simply logged and ignored. The default setting is unchecked.

Receive and Process Test Messages

The purpose of this option is self-explanatory.

10

Sending/Receiving Facility

This field controls the information sent in MSH:4 or MSH:6 depending upon the direction the message is being sent. It defaults to the licensed facility name contained in the Hospital Configuration table. For example, if the licensed facility name is Crown Software Demo, this field will contain Crown Software Demo.

If for some reason, the data sent in MSH:4 or MSH:6 must be something other than the licensed facility name then changing the value in this field will cause the appropriate field to be populated with that data when a message is constructed. For example, if the receiving system must receive the Facility ID of 702 instead of the facility name in the MSH segment, placing 702 in this field will cause the MSH segment to contain the Facility ID.

This field cannot be left empty when the configuration for a message type is enabled by Crown Software, Inc.

Name of System Sending/Receiving Transactions

The name of the hospital information system that will send transactions to or receive messages from the Rx-Link HL7 interface. For the inbound interface, the setting should contain the name of the system that is sending messages to Rx-Link. The outbound interface setting should contain the name of the system Rx-Link is sending messages to.

Generate/Receive ACK/NAK Messages

TCP/IP communications have a low level ACK/NAK protocol that is supposed to ensure communications. The ACK/NAK referred to by this setting is the HL7 level ACK/NAK as described in the Application (Level 7) Processing Rules in Chapter 2 of the HL7 v2.3 specification. The Rx-Link HL7 interface utilizes the original processing rules.

Although HL7 level ACK/NAK activity increases network traffic, users are strongly encouraged to leave this feature enabled. The setting affects the interfaces ability to accurately reflect the success or failure of an HL7 transaction in the error logs. It also enables us to detect and signal communications failures between our interface and those of other vendors.

HL7 Will Always Receive Unique Medical Record Numbers

This setting affects how the HL7 processes ADT transactions, especially Admissions (A01) and Update (A08) transactions. By checking this option, the user asserts that all Medical Record Numbers received by the HL7 interface will be unique. In processing an A01 or A08 transaction, the HL7 will use the Medical Record Number alone to verify that a patient exists in the patient table. If this option is not checked, the HL7 interface will use a combination of the Medical Record Number and the patient’s name to determine whether a patient exists. The default, and recommended setting, for this option is unchecked.

11

If two different patients, John Doe and Sally Unknown, are admitted with a medical record number of 00000000000 and the option is checked, the HL7 will update the demographics which ever patient was admitted first. All stays associated with the medical record number 00000000000 will be attached to a single patient, regardless of patient name or other information.

Under the same circumstances, with the option unchecked, the default setting, before the interface will change anything, it checks both the medical record number and the patient name before changing anything. That way if all admissions come across with a medical record number of 00000000000, the system will check the patient’s name. If the names are different, a new patient record will be created and the new stay will be associated with the new patient record. This seems preferable to having all stays appear under a single patient record with the 000000000000 medical record number.

For this to work correctly, the following convention must be used when entering patient names so that patient names will match exactly.

No prefixes, (i.e., Dr., Mr., Mrs.), can be entered.

The first name field must contain the patient’s first name. If a middle name or initial is used, it must be in the first name field separated from the first name by a space character.

Any suffix associated with the patient name must appear in the last name field, after the last name. The last name and suffix (i.e., SR, JR, I, II, III) must be separated by a space character. No punctuation characters should be used.

Send To IP and Port

This is the TCP/IP address and port the HL7 interface should send outbound transactions to. (Your IS Department will normally know what these should be set to.)

The outbound charge interface has a couple of additional settings as follows:

Send Charges Real Time

If this option is checked, outbound charge transactions are generated real-time (when they occur). If the option is not checked, outbound transactions are generated in batch mode. That is, they are stored on the system and not sent until the interface is given a command to send batch charges or at midnight, depending upon which occurs first.

In batch mode, the messages are sent as individual charges. There are no FHS, BHS, BTS, or FTS segments, no batch counts, etc.

12

Financial Transaction Codes

There are four settings for financial transaction codes, two for inbound DFT transactions and two for outbound DFT transactions. These fields expect a two letter code. The code is used to identify whether the transaction is a debit or credit. The HL7 specification recommends the following codes to identify different financial transaction types:

CG ChargeCD CreditPY PaymentAJ Adjustment

Crown Software’s HL7 interface processes only debits and credits. Some facilities use different codes to identify charges or credits. For example, CR may indicate a credit and DR may be used to indicate a charge. The rule here is that the code must be two alphabetic characters and cannot include numbers or special characters.

13

HL7 Error Logs

Selecting HL7 Error log from the menu, displays a window similar to the one above. The user can view any combination of inbound, outbound, successful, and failed transactions based on the transaction type. The most recent transaction is shown at the top of the list. The user can also search for all transactions containing a specified medical record number that occurred between two user-specified dates. This is dependent upon the number of days that error logs are maintained as specified in the configuration.

The Search For text fields may be used to further refine the search. For example if you wanted to find an order for a specific medication, you could enter the medication primary or secondary name in the first search field. The system will look for orders containing the value entered. If all more than one of the text fields is populated, the system performs the search using AND logic. In other words, the message must contain String1 and String2.

14

Double-clicking on a particular message opens up a window like the one below.

In this window, the user can see whether or not the message was processed successfully and any minor errors associated with the message. If the user clicks on the View ACK Message, the acknowledgement message associated with the transaction will be displayed, providing the interface is configured to permit application-level ACK/NAK transactions.

Note that the user can also, edit the message text and, by clicking on the Resend Message button, the user can resend the message. If there was a problem with the original message and the originating system cannot correct the problem, this offers a means for doing so manually.

15

CAUTION: Resending messages after editing them is not recommended unless one has a thorough understanding of HL7 specifications and what the changes will do. Do not take this ability lightly!

Security Menu

The security menu allows a user to log into or log out of the HL7 User Interface application.

Reports

There are two reports supported by the HL7 Interface. The first prints the HL7 configuration. This report shows all current settings for the HL7. It is highly recommended that the user print this report after the HL7 is initially installed and anytime changes are made to the configuration. Should we ever need to rebuild the configuration, the report would be an invaluable resource.

The second report allows the user to get a hard copy of information contained in the HL7 Error Logs.

16

Rx-Link HL7 Message Processing

When the Rx-Link HL7 interface receives a message, it first tests to determine which type of message it received based upon the message type and trigger event contained in field 9 of the MSH segment (MSH:9). Message types that will be processed by the Rx-Link HL7 interface include:

ACK Acknowledgement Messages ADT Patient Administration, typically called Admissions, Discharges, and Transfers DFT Detailed Financial Transactions (charges) ORM Order Messages RDE Pharmacy Encoded Order Messages RAS Pharmacy/Treatment Administration Messages ZPM Vending Machine Pocket Messages

In addition to these inbound message types, Crown Software’s HL7 interface supports the sending of formulary maintenance messages and fully encoded pharmacy orders (RDE messages) to vending systems. All other HL7 message types are ignored by the Rx-Link HL7 interface. Once the message type is determined, the message is passed to the appropriate message handler to be processed.

Most HL7 message types have one or more associated trigger events to help identify the intent of the message. The Rx-Link HL7 interface does not process every trigger event for every message type. The processing of some trigger events, ADT merge transactions for example, may be disabled by the user while other trigger events are simply not supported.

Regardless of whether a message is successfully processed or not, Rx-Link will generate a

HL7 acknowledgement message, providing that this feature has not been disabled by the user. Users are strongly encouraged not to disable the ACK/NAK features of Crown Software’s HL7 Interface.

Processing errors are reported in one of three ways:

Recorded in the HL7 Error Logs Recorded in the Windows Event Logs Printed on the HL7 Error Printer

The HL7 interface processes messages in accordance with the original processing rules as defined in section 2.12 of the HL7 v2.3 specification.

17

ADT Events

The following ADT trigger events are processed by the Crown Software HL7 Interface:

A01 – Admit a PatientA02 – Transfer a PatientA03 – Discharge a PatientA04 – Register Patient (Treated as A01)A05 – Pre-admit Patient (Treated as A01)A06 – Transfer an outpatient to an inpatientA07 – Transfer an inpatient to an outpatientA08 – Update patient information (This is used to update patient demographics such as payer,

Patient name, age, date of birth, etc. It is not used to change or merge medical record numbers or account numbers)

A13 – Reverse Discharge (This is not the same as Re-admit a patient. It merely clears the discharge date and toggles the discharge status of an erroneously discharged patient stay.)

The processing of the following ADT trigger events is dependent upon the setting of the switch in the HL7 configuration controlling the processing of ADT merge transactions. Crown Software does not recommend allowing the HL7 interface to electronically merge patient records.

A18 – Merge Patient InformationA34/A47 – Change Medical Record NumberA35/A49 – Change Account NumberA44 – Move Patient Account Number

DFT (Detailed Financial Transaction) Trigger Events

The only DFT trigger event processed by Crown Software’s HL7 interface is the P03 – Post Detailed Financial Transaction trigger event.

RXO (Pharmacy Order) Trigger Events

O01 – Order Message

During all transaction processing, the interface makes every attempt not to reject the transaction. For example, if the interface is attempts to verify a physician and the physician is not found in the Rx-Link database, the interface will use a default “Unknown Physician”. If a patient location or room cannot be found in the database, the interface will use a default “Unknown Location”. If an insurance provider is not found, the interface assigns the payer “Unknown” rather than create new payers.

18

The interface will not add new drugs or schedules to the database. If the order entry interface is implemented and a drug or schedule specified by an order cannot be found in the database, the order transaction will be rejected.

If outbound interfaces are enabled and a transaction is processed successfully, an outbound message is generated and sent to downstream systems to keep their information current.

All transaction processing will generate the appropriate acknowledgement transaction if the ACK/NAK feature is enabled.

Multiple patients can be placed in the same inpatient location in Rx-Link. In other words, more than one patient can occupy a bed.

Inbound orders are treated as requests. They are placed in a table in Rx-Link for the pharmacist to review. Rx-Link will attempt to interpret the information in the tables and formulate an order if possible. If Rx-Link cannot formulate an order, the pharmacist will have to use the information to encode the order.

No inbound order is valid orders until a pharmacist reviews and validates it. Once an order is validated, the HL7 will generate two messages. One message, containing the Rx-Link prescription number, is sent to the ordering system. The second message, is a fully-encoded pharmacy order. It is sent to the vending system, if that interface is enabled.

OO1 events may also indicate that an order is to be discontinued or renewed. The HL7 interface processes these events automatically. These transactions also generate two messages. The first message is sent to the ordering system indicating that the requested action has been completed. The second message forwards the request to the vending system for processing.

O02 – Order Response Message

These messages are generated, to an ordering system, if the setting to Send Order Response Messages is enabled. These are ACK messages sent in response to order request messages from an ordering system.

RAS (Pharmacy/Treatment Administration) Trigger Events

O01 – Order Message

The Order Message (O01) trigger event should be used in the generation of administration messages from Order Entry systems to Rx-Link For Windows.

19

MFN (Formulary Maintenance) Trigger Events

Most vending systems receive formulary maintenance records using MSH, MFI, MFE, and ZFM segments. The Crown software HL7 interface supports the sending of formulary maintenance messages to vending systems using this convention. There are two trigger events associated with these messages.

MAD – Formulary Add/UpdateMDL – Formulary Delete

When a drug is added to or removed from the formulary in Rx-Link for Windows, the system checks to determine whether the vending interface is enabled. If it is, a SQL trigger is used to tell the HL7 to send the appropriate message. Note that these are one way messages meant to communicate formulary information to third party vending systems.

*** IMPORTANT ***

There are hard limits as to the number of Drawers, sub-drawers, and pockets that RxLink For Windows can process. Ignoring these limits will result in vending station pocket counts not being updated to reflect accurate inventory in Floor Stock.

Maximum Drawers = 200

Maximum Sub-Drawers per Drawer = 99

Maximum Pockets per Drawer or Sub-drawer = 99

Sample Formulary Maintenance Message

MSH|^~\&|RXLINK|Columbia Care Center|AACS|Sample Hospital|20070523085841||MFN^MAD|20075238584100816|P|2.3.1|1||AL|ALMFI|0001^FORMULARY||UPD|20070523085841|20070523085841|NEMFE|MADZFM|A|4005930|Aripiprazole|U|5||ABILIFY|Tablet|10|mg|1|Tablet||28:16.08|||BRISTOL-MYERS SQUIBB US MD GRP |||||1|||||||||59148-0010-13|||10 MG

20

ZPM Vending Machine Pocket Messages

Most vending systems communicate pocket levels as well as pocket load and unload events to pharmacy systems via their HL7 interface. These are one way messages. That is, Rx-Link does not send pocket messages of any type. The interface accepts messages of this type and uses them to update the floor stock levels maintained by each vending station. This enables pharmacy personnel to observe the medication levels that are currently available in each vending station using Rx-Link’s graphical interface.

When medications are added to or removed from a vending station, the vending system sends a pocket message to tell the pharmacy management system about the drug contained in the station. Additionally, some vending systems send pocket messages with every charge transaction. Consequently, Rx-Link’s floor stock levels should reflect the actual pocket counts maintained by the vending system.

Vending system pocket events that are supported by Rx-Link and the HL7 interface include pocket load (EPL), pocket count (EPC), and pocket unload (EPU), and pocket fill (EPF) events. Rx-Link and the HL7 do not support expired medication (EEM), empty bin (EEB), cancellation (EEC) events.

*** IMPORTANT ***

There are hard limits as to the number of Drawers, sub-drawers, and pockets that RxLink For Windows can process. Ignoring these limits will result in vending station pocket counts not being updated to reflect accurate inventory in Floor Stock.

Maximum Drawers = 200

Maximum Sub-Drawers per Drawer = 99

Maximum Pockets per Drawer or Sub-drawer = 99

ACK Message Processing

Acknowledgement messages, also known as ACK messages, are used to signal the application level success or failure of processing an HL7 message. Whether a message succeeds or fails, Crown Software’s HL7 interface will record the acknowledgement message in the HL7 Error Logs. The interface will not continue trying to send a failed message. Remember that application level ACK/NAK capability can be enabled or disabled by the user. Acknowledgement message processing is dependent upon how the user configured the interface.

21

ADT Transaction Processing

Processing of Patient Classes and Patient Types

Rx-Link for Windows contains a Patient Class Definition table. This table is used in the processing of ADT events A01, A02, A06, and A07. For this discussion, PV1:2 contains the Patient Class and PV1:18 contains the Patient Type. Inbound:IF PV1:2 <> I

IF PV1:18 <> “”Look up the patient class definition in the Patient Class table based on the value in PV1:18. (This looks at the Patient Type field)If one is found, use it to establish the stay information that is stored.

ELSE IF PV1:10 (Hospital Service) <> “”Look up the patient class definition based on the value in PV1:10. (This uses the patient type field in the table.If the value is found, set the patient class based upon the definition in the table and store it.

ELSEDo nothing

END IFEND IF

Outbound:When the patient class is selected above, the ID record for the Patient Class, from the Patient Class Table, is stored in the stay. When the stay retrieves the information, it uses the record ID, consequently we will construct the PV1 segment using the Patient Class associated with that record ID in PV1:2 and the Patient Type for the record in PV1:18.

Admission Transactions (A01)

When an A01 transaction is received, the interface performs the following actions:

1. Searches the patient table, using the medical record number, to determine if the patient exists. If the medical record is found, patient demographics such as name, date of birth, age, height, weight, and insurance provider, are updated; otherwise, the patient is added to the patient table.If more than one patient is found to have the same medical record number, the transaction is rejected and a NAK message is generated.

2. If the actions in step 1 succeeded, the interface uses the patient’s account number and the Rx-Link generated patient ID to determine if a stay already exists for the patient. If a stay, with the specified account number and patient ID, is not found, a new stay is created. If a stay, with the specified account number and patient ID is found, the stay

22

information is updated. If more than one stay is assigned the same account number and patient ID, the transaction is rejected and a NAK message is generated.

Transfer Patient (A02)

This transaction is used to transfer a patient from one inpatient location to another inpatient location. It is not used to make an inpatient an outpatient or to make an outpatient an inpatient. The A02 is not to be used to transfer a patient from one facility to another. A patient moving between facilities should be discharged from the original facility and admitted to the new facility. When an A02 transaction is received the interface does the following:

1. Verifies that the patient has a valid inpatient stay.2. Verifies that the new inpatient location exists. If the new location does not exist, the

HL7 will use the default “Unknown Location”.3. Updates the stay to associate so the patient appears in the new location in Rx-Link.

Discharge Patient (A03)

When a discharge transaction is received, the interface uses the account number to verify that there is a valid inpatient stay associated with the account number. If a valid, inpatient or outpatient stay exists, the patient is discharged by setting the discharge date associated with the stay to the discharge date specified in the transaction.

Register Patient (A04)

Processed same as A01.

Pre-Admit Patient (A05)

Processed same as A01.

Transfer Outpatient To Inpatient (A06)

When the interface receives an A06 transaction it verifies that the patient has a valid outpatient stay. If a valid outpatient stay is found to exist, the status of the stay is updated to reflect an inpatient status and the patient is placed in the specified inpatient location.

If a valid outpatient stay does not exist, the transaction is rejected.

Transfer Inpatient To Outpatient (A07)

When the interface receives an A07 transaction it verifies that the patient has a valid inpatient stay. If a valid inpatient stay is found to exist, the patient status is updated to outpatient and the patient’s location is updated to the specified location. If a valid inpatient stay does not exist, the transaction is rejected.

Update Patient Information (A08)

23

The A08 transaction is used to update patient demographic information. It will not change a patient’s medical record number or account number. When an A08 transaction is received, the interface will first verify that the patient exists in the Rx-Link system. If the patient does not exist, the A08 transaction is treated as an A01 transaction and the patient is admitted; otherwise, the patient’s demographics are updated.

Demographics include information such as patient name, physician, date of birth, gender, insurance provider, height, and weight. Demographics do not include patient status, patient location, account number, medical record number or other encounter related information.

No transaction, other than an A08 will update patient demographics such as height and weight. Suppose that the hospital patient administration system is used to admit patients; however, the patient’s height and weight information is transmitted from the hospital’s order entry system. The order entry system must generate an A08 transaction in order to update the patient’s height and weight. Crown Software’s HL7 interface does not support non-standard HL7 messages.

The A08 transaction may be used to inactivate patient allergies using the custom ZAD segment. Please refer to the example messages that follow and to the HL7 Segment Specifications.

Reverse Discharge (A13)

Upon receipt of an A13 transaction, the interface with verify that a discharged stay with the specified account number exists. If such a stay is found, the discharge date is cleared and the patient status is changed to reflect that the patient is an inpatient. No changes regarding patient location are made. This transaction should not be used to re-admit a patient.

The remaining ADT transactions that the Crown Software HL7 interface will process affect the changing and/or merging of patient medical record numbers and/or patient account numbers. Because of the confusion that is often associated with allowing an interface to make these types of changes, the HL7 configuration allows the user to determine whether these messages will be processed or not.

Crown Software’s HL7 interface does not use the patient list as defined in the HL7v2.3 specification for PID:3.

Merge Patient Information (A18)

This transaction has been retained for backward compatibility. It is used to merge current and previous patient identification numbers. (Refer to the PID Description). It is recommended that other transactions, such as A34, A35, A36, A39, A40, A41, and A42, be used to merge patient information rather than using the A18 merge transaction.

24

When merge transactions are generated the PID segment should contain the surviving patient ID information while the MRG segment should contain the non-surviving patient ID information. Failing to follow these guidelines for the construction of merge transactions may produce unpredictable results.

Change MRN (A34/A47)

The A34 transaction has been retained for backward compatibility. Either transaction will look for a patient with the Medical Record Number specified in the MRG segment and change the Medical Record Number associated with that patient to the one specified in the PID segment of the A34 or A47 transaction. If more than one patient record has a medical record number that matches medical record number specified in the MRG segment, no changes will be made and the message will be rejected with a NAK.

Change Account Number (A35/A49)

The A35 transaction has been retained for backward compatibility. Either transaction will look for a patient stay with the Account Number specified in the MRG segment and change the Account Number associated with the patient stay to the one specified in the PID segment of the A35 or A49 transaction. If more than one patient stay has the same account number as the one specified in the MRG segment, no change will be made and the message will be rejected with a NAK.

Move Account Information/Patient Account Number (A44

The A44 transaction is used when 2 medical record numbers legitimately exist for 2 different people and an account number is incorrectly assigned to the wrong medical record number. (Refer to the HL7 v2.3 specification, 3.2.44 for a more in depth explanation of the use of this transaction.)

25

Sample ADT Transactions

Admit (A01)MSH|^~\&|||||199903130854||ADT^A01|1001|P|2.3|EVN|A01|199903130850|PID|1||234567891|234561|Duck^Daffey^||19541006|M||||||||||234567891|PV1|1|I|Surg^801^A^Main||||100^Bement^Stephen||||||||||100^Bement^Stephen|IP||Other|||||||||||||||||||||||200107131430||OBX|1|ST|1010.1^Body Weight||95.45|Kg|OBX|2|ST|1010.3^Body Height||185.42|cm|AL1|1|DA|^Ampicillin Allergy|SV|Hives|19810131|AL1|2|DA|^Vallium Allergy|SV|||DG1|1|I1|C22.0^Liver cell CA^ICD9|||A|203|DG1|2|I1|C23.0^Some problem^ICD9|||A|204|

Transfer Patient (A02)MSH|^~\&|PHARM||CROWN SOFTWARERX||199903130854|1005|ADT^A02|1005|P|2.3|EVN|A02|199903130850|PID|1||123456||MOUSE^MICKEY^M||19541006|M||||||||||123456789|PV1|1|I|JustSick^401^B^Main|||Surg^801^A^Main|999^Holiday^John||||||||||999^Holiday^John|IP||Medicare||||||||||||||||||||||||200107131430||

Discharge Patient (A03)MSH|^~\&|PHARM||CROWN SOFTWARERX||199903130854|1006|ADT^A03|1006|P|2.3|EVN|A03|199903130850|PID|1||123456||MOUSE^MICKEY^M||19541006|M||||||||||123456789|PV1|1|I|JustSick^401^B^Main||||999^Holiday^John||||||||||999^Holiday^John|IP||Medicare||||||||||||||||01||||||||200107131430|200110021420|

Transfer Outpatient to Inpatient (A06)MSH|^~\&|PHARM||CROWN SOFTWARERX||199903130854||ADT^A06||P|2.3|EVN|A06|199903130850|PID|1||123456||Duck^Daffey^||19541006|M||||||||||123456789|PV1|1|I|Surg^801^A^Main||||999^Holiday^John||||||||||999^Holiday^John|IP||Medicare||||||||||||||||01||||||||200107131430|200110021420|

26

Transfer Inpatient to Outpatient (A07)MSH|^~\&|PHARM||CROWN SOFTWARERX||199903130854||ADT^A07||P|2.3|EVN|A07|199903130850|PID|1||123456||PIGG^PORKY^L||19541006|M||||||||||123456789|PV1|1|O|OutPatient^999^A^Main||||999^Holiday^John||||||||||999^Holiday^John|IP||Medicare||||||||||||||||01||||||||200107131430|200110021420|

Update Patient Information (A08)MSH|^~\&|MEDITECH||RX-LINK||199904250920|0807021557|ADT^A08|0807021557|P|2.3|EVN|A08|199903130850|PID|1||123456||Duck^Daffey^||19541006|M||||||||||123456789|PV1|1|I|Surg^802^A^Main||||100^Bement^Stephen||||||||||100^Bement^Stephen|IP||Medicaid||||||||||||||||||||||||200107131430||OBX||ST|1010.1^Body Weight|123|150|lb|OBX||ST|1010.3^Body Height|123|54|in|AL1|1|DA|^Ampicillin Allergy|SV|Hives|19810131|AL1|2|DA|^Vallium Allergy|SV|||DG1|1|I1|C22.0^Liver cell CA^ICD9|||A|203|DG1|2|I1|C23.0^Some problem^ICD9|||A|204|DG1|3|I1|C24.0^Another Problem^ICD9|||A|205|

Sample A08 Message for Allergy InactivationMSH|^~\&|MEDITECH||RX-LINK||199904250920|0807021557|ADT^A08|0807021557|P|2.3|EVN|A08|199903130850|PID|1||123456||Duck^Daffey^||19541006|M||||||||||123456789|PV1|1|I|Surg^802^A^Main||||100^Bement^Stephen||||||||||100^Bement^Stephen|IP||Medicaid||||||||||||||||||||||||200107131430||ZAD|1|DA|^Ampicillin Allergy

Reverse Discharge (A13)MSH|^~\&|PHARM||CROWN SOFTWARERX||199903130854||ADT^A13||P|2.3|EVN|A13|199903130850|PID|1||123456||PIGG^PORKY^L||19541006|M||||||||||123456789|PV1|1|I|JustSick^401^B^Main||||999^Holiday^John||||||||||999^Holiday^John|IP||Medicare|||||||||||||||||||||||200107131430||

27

Merge Patient Information (A18)MSH|^~\&|PHARM||CROWN SOFTWARERX||199903130854||ADT^A18||P|2.3|EVN|A18|199903130850|PID|1||123456||Duck^Daffey^||19541006|M||||||||||123456789|MRG|654321||987654321|||||

Change Patient ID (A34/A47)MSH|^~\&|PHARM||CROWN SOFTWARERX||199903130854||ADT^A06||P|2.3|EVN|A47|199903130850|PID|1||321456||Mouse^Mickey^M||19541006|M||||||||||123456789|PV1|1|I|Surg^801^A^Main||||999^Holiday^John||||||||||999^Holiday^John|IP||Medicare||||||||||||||||01||||||||200107131430|200110021420|MRG|123456||123456789|

Change Patient Account Number (A35/A49)MSH|^~\&|PHARM||CROWN SOFTWARERX||199903130854||ADT^A06||P|2.3|EVN|A49|199903130850|PID|1||123456||Mouse^Mickey^M||19541006|M||||||||||123456999|PV1|1|I|Surg^801^A^Main||||999^Holiday^John||||||||||999^Holiday^John|IP||Medicare||||||||||||||||01||||||||200107131430|200110021420|MRG|123456||123456789|

Move Patient Account Information (A44)MSH|^~\&|PHARM||CROWN SOFTWARERX||200201151430||ADT^A44||P|2.3|EVN|A44|200201151430|PID|1||123456||Duck^Daffey^||19541006|M||||||||||234567890|MRG|123457||234567890|

28

Detailed Financial Transaction Processing

Detailed financial transactions represent charges that are generated either by a vending system or by users of the Rx-Link for Windows application. Charges generated by vending systems can be sent to the interface in real time or as a batch. In either case, the charges from vending systems are expected to be sent via a TCP/IP connection. There is no facility for importing vending system generated charges from a file. Vending system charges are processed and stored in the Rx-Link database as are charges generated by users of Rx-Link for Windows.

Crown Software’s HL7 interface can send charges to a billing system in the following ways:

Real-time via a TCP/IP connection As a batch via a TCP/IP connection

In batch mode, the user determines when the charges are sent to the billing system. In batch mode, there are no FHS, BHS, BTS, or FTS segments as defined in the HL7 specification. The HL7 simply takes all of the charges that would make up the batch and sends them as individual charge transactions.

In real-time mode, charges are processed at a lower priority than ADT and order transactions. Real-time charges are sent during times when the HL7 is idle.

The only DFT transaction trigger event supported by Crown Software’s HL7 interface is the P03 trigger.

When a DFT is received from a vending system, the HL7 processes the message as follows:

1. Verify that the stay, identified by the account number in the PID segment, is valid. If it is, processing continues. If the stay is not valid, the message is rejected via a NAK message.

2. DFT transactions can contain multiple FT1 segments. The interface will process each FT1 segment individually in the following way:

a. The interface expects the prescription number generated by Rx-Link to be present in FT1:23. If FT1:23 is not populated, the interface will look for an active, validated order associated with the patient’s stay by using the information contained in FT1:9. If an active validated order is not found, the HL7 interface will look for an inactive validated order in the same way.

b. If an active, validated order or an inactive, validated order is found, the charge is entered in Rx-Link. If neither an active, validated order nor an inactive, validated order can be found, the charge transaction is rejected with a NAK message. The single exception to this is the processing of override charges from a vending system. See Override Charge Processing below.

c. If a prescription number was found in FT1:23, the order with the specified prescription is located and used to verify and generate charges for the order ingredients. If the prescription number cannot be found, the charge transaction is

29

rejected with a NAK message. The single exception to this is the processing of override charges from a vending system. See Override Charge Processing.

The HL7 will only charge for ingredients for which there is an FT1 transaction in the message. It will not charge based upon the prescription number. If an order has multiple ingredients, there must be an FT1 segment for each ingredient to be charged. Additionally, if the pocket count is to be updated, there must be a ZPM segment associated with each FT1 segment.

Override Charge Processing

Override charges occur when a medication is taken from a vending machine and given to a patient when there is no order recorded, in the vending system, for the patient. This usually happens after hours when there is no pharmacy staff on duty.

The HL7 interface has a switch that allows the user to select when override charges will be processed. The valid settings are NEVER, ALWAYS, and ONLY IF A STAY EXISTS. The consequence of selecting the NEVER option is obvious. Override charges are not processed.

If the ALWAYS option is selected, the HL7 interface will attempt to process the override charge regardless of whether a stay exists of not. Selecting this option can have adverse effects. For example, if a patient is not admitted through the normal admissions process, Rx-Link will have no record of the patient stay. To get the patient’s medications, the nurse keys an account number into the vending system and takes the medication. The vending system will generate an override charge transaction and the HL7 will process it. This effectively creates a patient stay in Rx-Link using the account number that was entered into the vending system.

When the patient is finally admitted though normal processes, an ADT A01 transaction is sent, by the admitting system, to Rx-Link via the HL7. The account number used, in the A01 transaction, to admit the patient may or may not match the account number associated with the override charge. If the account number used in the override charge and the account number used by the admitting system match, then all of the systems should be in sync. If the account numbers are different, the door is open for several problems.

The HL7 will send the new account number to the vending system as a result of the ADT A01 transaction received from the admitting system. Now Rx-Link and the vending system will have two records for the same patient – the one created by the admission and the one created by the override charge. Additionally, the HL7 will send the override charge to the billing system using the account number the charge was created with. Since the patient administration system does not know about this account number, the billing system will reject the charge. Since Crown Software’s HL7 processes transactions real-time, there is no way to avert this flow of information. These issues will have to be addressed manually by the pharmacy and business office.

The final option is to permit override charges only if the stay used to generate the override charge matches a stay in Rx-Link. The potential issue with this setting is that the

30

override charge, from the vending system, will be rejected. The account number, in the vending system, will have to be corrected by the pharmacy and they will have to instruct the vending system to re-send the charge with the correct account number. If this cannot be done, these charges may be lost unless the pharmacy enters the charge in Rx-Link manually. Any rejected transactions are recorded in the HL7 Error Log.

NOTE: There is a setting for orders that indicates whether drugs are identified by charge code or Drug ID. This same setting is used to establish the way drugs are identified for charging purposes. If drugs are identified by charge code, FT1:7 should be formatted as:

ChargeCode^BrandName^CHGCODE^DrugID^GenericName^DRUGID

If drugs are to be identified by DrugID, then FT1:7 should contain

ID of Drug^TradeName^DrugID^ChargeCode^GenericName^CHGCODE

Sample DFT Transactions

MSH|^~\&|PYXIS||RX-LINK||200201170800||DFT^P03|4444|P|2.3|EVN|P03|200201170800|PID|1||78946731||AVENELL^Chelsia^||19541006|M||||||||||99|FT1|1|||20020117|20020117|CG|000510790-6^TradeName^CHGCODE^185^GenericName^DRUGID||18|1||||||||||||||||ZPM|C|PYXISRX|UnitA|1|B|000510790-6|DrugName||||||||22

MSH|^~\&|PYXIS||RX-LINK||200201170900||DFT^P03|4444|P|2.3|EVN|P03|200201170900|PID|1||3456789||AGARD^KARAN^||19541006|F||||||||||3254979878465|FT1|1|||20020117|20020117|CD|000510227-8^TradeName^CHGCODE^185^GenericName^DRUGID |||1||||||||||||||||ZPM|C|PYXISRX|UnitA|1|B|000510227-8|DrugName||||||||22

MSH|^~\&|PYXIS||RX-LINK||200202180800||DFT^P03|4444|P|2.3|EVN|P03|200201180800|PID|1||666777||Aberg^Adamina^||19680101|F||||||||||3216794617761|FT1|1|||20020218|20020218|CG|000510416-6^TradeName^CHGCODE^185^GenericName^DRUGID ||3|1||||||||||||||||ZPM|C|PYXISRX|UnitA|1|B|000510416-6|DrugName||||||||22FT1|2|||20020218|20020218|CG|000510547-2^TradeName^CHGCODE^185^GenericName^DRUGID ||3|1||||||||||||||||ZPM|C|PYXISRX|UnitA|1|B|000510547-2|DrugName||||||||22

31

Sample Override Transaction

MSH|^~\&|PYXIS||RX-LINK||200201170800||DFT^P03|4444|P|2.3|EVN|P03|200201170800|PID|1||78946731||AVENELL^Chelsia^||19541006|M||||||||||99|FT1|1|||20020117|20020117|CG|000510790-6^TradeName^CHGCODE^185^GenericName^DRUGID ||18|1||||||||||||||||ZPM|C|PYXISRX|UnitA|1|B|000510790-6|DrugName||||||||22

If the Filler Order Number, located in FT1:23, is not numeric then Crown Software interprets the DFT transaction as an override charge. If the Filler Order Number is not provided in FT1:23, then Transaction Description – Alt, located in FT1:9 is evaluated. To be considered an override transaction when no Filler Order Number is provided in FT1:23, FT1:9 must either be empty or contain the word “OVERRIDE”.

In the above sample, the ZPM is a vending system defined segment that communicates pocket count information to Rx-Link. This segment is used to help maintain floor stock levels in Rx-Link. The pocket count from the vending system should agree with the floor stock levels in Rx-Link if these segments are being used to communicate pocket activity from the vending system. The segment is optional. If the segment is present and the processing of override charges and pocket messages is enabled in the HL7 configuration, the HL7 will use the information contained in ZPM segments to update floor stock levels in Rx-Link.

32

Order Transaction Processing

Crown Software’s HL7 interface will accept ORM messages containing pharmacy orders. Pharmacy orders must contain an MSH, PID, PV1, ORC, RXO, and RXR segment. For multi-component orders, such as IV orders, the order must also contain one or more RXC segments. For multi-component orders, no ingredients should be contained in the RXO or RDE segments. The RXO or RDE segment should indicate that this is a CUSTOM IV in accordance with the HL7 Specification. Each ingredient making up the order should be in a RXC segment. The RXC segment should reflect whether the ingredient is a base or additive.

The interface cannot interpret orders involving alternating schedules or alternating or diminishing doses. For orders of this type, individual orders will have to be entered by the ordering system. The ordering system will have to specify specific start dates and times and well as the ingredients involved with each order.

Orders received by the interface are treated as order requests. They are used to populate tables so a pharmacist can review and encode the order request. Once the order request is stored in the Rx-Link database, the HL7 will respond with an ORR message with an event of O02 with an Order Control Code of RR in the ORC segment. This indicates that Rx-Link has accepted responsibility for the message and is the proper ACK response for an order request. If the HL7 is unable to store the message as an order request, a NAK, in the form of an ORR with an event of O02 and an Order Control Code of UA in the ORC segment, indicating that the request has been rejected by Rx-Link.

Rejected order requests will also print an order reject notice on the error printer identified in the HL7 configuration, if the switch to print the notices is enabled. This is the only means by which the HL7 can notify the pharmacy that an order request has been rejected. It is strongly recommended that the Ordering System have some means of detecting whether an order request has been accepted or rejected and take measures to alert those using the ordering system if an order request is rejected by the interface.

For example, a typical pharmacy IV order might specify:

D5W with ½ NS with 20 MEQ KCL every third bottle starting with first with a new bottle

It is not a problem for a pharmacist to interpret this statement and enter an order that reflects what is to be done for the patient. An HL7 interface, on the other hand, cannot interpret this order. The ordering system would have to generate two (2) orders to communicate, via an HL7 interface, to the pharmacy what is to be done for the patient.

The first order would specify a 1-liter bag with 20 MEQ of KCL added to be administered at 100cc/hr to begin at a specified time, say 0800. (We know this bag would hang for 10 hours because that is how long it takes to dispense a liter flowing at 100 cc/hr.)

33

The second order would specify 2-liters of D5W with ½ NS to be administered at 100cc/hr with a start time of 1800 (10 hours after the start time for the first bag). The duration of treatment would be H20 since 2, 1-liter bags, hung in succession, would take 10 hours to dispense at 100cc/hr.

There is currently no way, either through the HL7 interface or in Rx-Link for Windows, to know that these two orders are related to each other in any way.

If the system receives an order for which there is either no patient or no stay or both, to avoid rejecting the order, the interface will attempt to add the patient and create an open stay for the patient. It will then process the order and associate it with the newly created patient stay. (NOTE: When creating patient and/or stay records, the system uses the same rules applied when processing A01 or A08 transactions.)

Identification of Ordered Substances

The HL7 specification states that a substance must be identified using a coded element. This means that there must be a drug identifier of some sort, the drug description, and an indication of what code is being used to identify the substance or drug. The fields are to be separated/delimited by a carat (^). An example of this type of encoding is as follows:

Drug identifier^trade or generic name^CHGCODEOr

Drug identifier^trade or generic name^DRUGID

NOTE: In the above examples, the coding system is identified as either CHGCODE or DRUGID. These are mandatory as they are the only encoding methods used by Crown Software’s HL7 Interface. In other words, the encoding method used in the coded element must be either CHGCODE or DRUGID.

If the encoding method is not specified, the interface will first attempt to identify the drug by charge code and then by Drug ID.

The encoded element identifying the substance is to be contained in RXO:1 for single component orders and RXC:2 for orders with multiple ingredients.

If a charge code or drug ID is not supplied to identify the substance, the interface will look for the first active drug that has a trade or generic name that matches the substance description, strength per dose matching the ordered amount, and strength per dose units that match the ordered amount units. If more than one formulary item meets the criteria, the interface will assume that the first item meeting the criteria is the one to be used.

If no match is found, the interface will look for an active formulary item with a trade or generic name that matches the description contained in the coded element. If more than one item is located, the interface will choose the first matching substance as the ordered substance. If no matching item is located, the description, ordered amount, and ordered amount units will be appended to the order text.

34

Note: The order text can hold a maximum of 200 characters. If the order text exceeds this length, the text will be truncated and an ellipsis will be appended as the last three characters in the text. This should indicate to the pharmacist encoding the order that there is more to the order than can be displayed. The pharmacist will have to view the original order request to interpret/encode the order.

Detailed Discussion of Order Transaction Processing

The following flow chart is provided to aid in the understanding of this complex topic. As shown, the interface will only accept order request messages that have NW, CA, XO, or DC as the Order Control Code in the ORC segment. Order requests containing any other Order Control Code will be rejected by the interface with a response message containing an Order Control Code of UA in the ORC Segment.

Note that the acceptance of an Order Request by the HL7 Interface does not mean that an order has been created for the patient. It means that the request has been received and is waiting to be coded by a pharmacist.

Sample Order Acceptance Response

MSH|^~\&||||LHC Group|20071005123025||ORR^O02|200710051230256003|P|2.3.1|1||NE|NEMSA|AA|200411101340|No Error Encountered.|||0^HL7 Service - No Error Encountered.PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC GroupORC|RR|OE1234||||N|||20071005123025|||||||RR^Request Received|^LHC Group

The above is an example of a response to an ordering system indicating acceptance of an order request. Had the HL7 Interface rejected the request, ORC:2 would contain an Order Control Code of UA and ORC:16 would contain UA^Unable To Accept.

Order Requests containing Order Control Codes of DC and CA are treated as discontinue requests by the HL7 Interface. These requests are not stored in the database. Instead, they are acted upon immediately by the HL7 Interface which will locate the order and update it to reflect that it has been discontinued. The following is a sample discontinuation request from an order entry system. Note that ORC:3 contains the Filler Order Number generated by Rx-Link when the order was encoded by the pharmacist. The second example is the response generated by the HL7 Interface to signal the ordering system that the order has been discontinued as requested.

Sample Discontinuation Request (DC)

MSH|^~\&|||||200210091347||ORM^O01|200411101340DC|P|2.3|||AL|ALPID|1||123456||Duck^Daffey^||19541006|M||||||||||123456789|PV1|1|I|Surg^801^A^Main||||100^Bement^Stephen||||||||||100^Bement^Stephen|IP||Other||||||||||||||||||||||||200107131430||ORC|DC|OE1234|14667||||1&EA^Q12H^D14^200411160800^200411300800||200411101400|^Nurse^Sally||100^Bement^Stephen|||||||RXO|5107734^Sectral^CHGCODE|400||MG^MG|CAP^Capsule||||N|||||||||400|mg^mg||||RXR|PO

Sample Response to Discontinuation Request

MSH|^~\&||||LHC Group|20071005123648||ORR^O02|200710051236486048|P|2.3.1|1||NE|NEMSA|AA|200411101340DC|No Error Encountered.|||0^HL7 Service - No Error Encountered.PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC GroupORC|DR|OE1234|14667||DC|N|||20071005123648|||||||DR^Discontinued As Requested|^LHC Group

35

Sample Discontinue Order Request sent to Vending System if outbound order interface is enabled.

MSH|^~\&|RXLINK|LHC Group|Vending System|LHC Group|20071005123734||RDE^O01|200710051237341248|P|2.3.1|1||AL|ALEVN|O01|20071005123734PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC GroupORC|DC|14675||||N|1^Q12h^H25276^20041116080000^20071005123648^R^0^11111110|||^Nurse^Sally^^^^^^^L^^^PN^LHC Group^A||^Robinson^Juliet^^^^^T_RXL_StaffMember^RXLINK^L^^^DN^LHC Group^A|Unknown^^^LHC Group|||DC^Discontinue Order Request|^LHC GroupRXE|400&MG^Q12h^H25276^20041116080000^20071005123648^R^0^11111110|5107734^SECTRAL 400 mg^Charge Code^2024^Acebutolol Hydrochloride 400 mg^Drug ID|400||MG^MG|CAP^Capsule| Order renewed by HL7 renewal request. Order discontinued by HL7 discontinuation request.|Unknown^999^99^LHC Group|N|1|Capsule^Capsule|||Developer^King^Bill^^^^^T_RXL_StaffMember^RXLINK^L^^^PN^LHC Group^A|14675|||||N|||||400|mg^mg||1|Capsule|UD|1RXR|PO^Oral^HL7 Table 0162

Order Requests containing an Order Control Code of XO indicate that the order is to be changed in some way. The only change allowed by Rx-Link is to renew the order. If an order is approaching its hard or soft stop dates, the physician may elect to continue the order rather than allowing it to be discontinued automatically. In this case, the ordering system would generate a request with the new stop date for the order. Note that in the following order request, the Quantity and Timing field of the ORC segment reflects the new stop date for the order. The subsequent response signals the ordering system that the order was changed as requested.

Sample Change Order Request (XO)

MSH|^~\&|||||200210091347||ORM^O01|200411101340RNW|P|2.3|||AL|ALPID|1||123456||Duck^Daffey^||19541006|M||||||||||123456789|PV1|1|I|Surg^801^A^Main||||100^Bement^Stephen||||||||||100^Bement^Stephen|IP||Other||||||||||||||||||||||||200107131430||ORC|XO|OE1234|14667||||1&EA^Q12H^D14^200411160800^200710300800||2007100400940|^Nurse^Sally||100^Bement^Stephen|||||||RXO|5107734^Sectral^CHGCODE|400||MG^MG|CAP^Capsule||||N|||||||||400|mg^mg||||RXR|PO

Sample Response to Change Order Request

MSH|^~\&||||LHC Group|20071005123432||ORR^O02|200710051234316687|P|2.3.1|1||NE|NEMSA|AA|200411101340RNW|No Error Encountered.|||0^HL7 Service - No Error Encountered.PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC GroupORC|XR|OE1234|14667||CM|N|||20071005123432|||||||XR^Changed As Requested|^LHC Group

Sample Change Order Request Sent to Vending System if the outbound order interface is enabled.

MSH|^~\&|RXLINK|LHC Group|Vending System|LHC Group|20071005123433||RDE^O01|200710051234331740|P|2.3.1|1||AL|ALEVN|O01|20071005123433PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC GroupORC|XO|14675||||N|1^Q12h^INDEF^20041116080000^20071030080000^R^0^11111110|||^Nurse^Sally^^^^^^^L^^^PN^LHC Group^A||^Robinson^Juliet^^^^^T_RXL_StaffMember^RXLINK^L^^^DN^LHC Group^A|Unknown^^^LHC Group|||XO^Change Order Request|^LHC GroupRXE|400&MG^Q12h^INDEF^20041116080000^20071030080000^R^0^11111110|5107734^SECTRAL 400 mg^Charge Code^2024^Acebutolol Hydrochloride 400 mg^Drug ID|400||MG^MG|CAP^Capsule| Order renewed by HL7 renewal request.|Unknown^999^99^LHC Group|N|1|Capsule^Capsule|||Developer^King^Bill^^^^^T_RXL_StaffMember^RXLINK^L^^^PN^LHC Group^A|14675|||||N|||||400|mg^mg||1|Capsule|UD|1RXR|PO^Oral^HL7 Table 0162

36

37

When an order request is processed by the pharmacist, the request may be rejected, by the pharmacist, because the pharmacist is unable to interpret the request or for some medical reason where it would be detrimental for the patient to receive the medication. Alternatively, the pharmacist can encode and verify the order request resulting in a pharmacy order for the patient being generated. The flow chart on the following page helps to clarify this process.

Again, an order request does not become a pharmacy order until the pharmacist has coded and verified the order. This point is illustrated by the first step in the flow chart.

If the pharmacist decides to reject the order request for some reason, a message similar to the following example will be sent to the ordering system. This message indicates that the pharmacist has rejected the order request and that no order exists for the patient. It is strongly recommended that ordering systems using this interface be able to recognize messages such as this and notify the users of the system that the order request has been rejected so they may take the appropriate action.

Sample of message sent to Ordering System when Pharmacist manually rejects an order request.

MSH|^~\&|RXLINK|LHC Group|Order Entry|LHC Group|20071005125552||RDE^O01|200710051255521506|P|2.3.1|1||AL|ALEVN|O01|20071005125552PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC GroupORC|XX|OE1237|||CA|N|||20071005125552|||||||XX^Order Rejected By Pharmacy|^LHC Group

When a pharmacist encodes and verifies an order, a status change message will be sent to the ordering system indicating that the order has been created. The message will contain the Filler Order Number generated by Rx-Link in ORC:3. The ordering system should store this number with the Placer Order Number generated by the ordering system, thereby marrying the order request and the actual order.

The HL7 interface will send an ACK message in response to an order request (RXO) message; however, this does not mean that the order has been processed by the pharmacy. The pharmacist must encode and verify the order for the request to be a valid order in the pharmacy system. Once the pharmacist completes this task, the HL7 will send a message to the ordering system formatted like the example below. The ORC segment will contain the Placer Order Number in field 2 and the pharmacy’s Order ID (Filler Order Number) in ORC:3. It is the responsibility of the ordering system to marry these two numbers for future communications in accordance with HL7 Specification Version 2.3.1. The marriage of the placer order number and filler order number reflects that the order is now a valid order in the pharmacy and ordering systems. The same type of response will be sent regardless of whether the order is a medication or IV order. The example provided below is a fully encoded pharmacy order (RDE) message.

Similar messages are sent to vending systems to inform them of the order. The difference is that the Pharmacy Order ID is sent in ORC:2 (Placer Order Number) when the message is sent to a vending system. The HL7 expects a response from the vending system containing the Filler Order Number assigned by the vending system.

To discontinue or renew this order, the ordering system must include the pharmacy’s Order ID in ORC:3 of the RXO.

38

Sample Order Status Message generated when the pharmacist codes and verifies an order request.

MSH|^~\&|RXLINK|LHC Group|Order Entry|LHC Group|20071005123152||RDE^O01|200710051231521135|P|2.3.1|1||AL|ALEVN|O01|20071005123152PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC GroupORC|SC|OE1234|14675||SC|N|1^Q12h^INDEF^20041116080000^20051116080000^R^0^11111110|||^Nurse^Sally^^^^^^^L^^^PN^LHC Group^A||^Robinson^Juliet^^^^^T_RXL_StaffMember^RXLINK^L^^^DN^LHC Group^A|Unknown^^^LHC Group|||SC^Order Status Changed|^LHC GroupRXE|400&MG^Q12h^INDEF^20041116080000^20051116080000^R^0^11111110|5107734^SECTRAL 400 mg^Charge Code^2024^Acebutolol Hydrochloride 400 mg^Drug ID|400||MG^MG|CAP^Capsule||Unknown^999^99^LHC Group|N|1|Capsule^Capsule|||Developer^King^Bill^^^^^T_RXL_StaffMember^RXLINK^L^^^PN^LHC Group^A|14675|||||N|||||400|mg^mg||1|Capsule|UD|1RXR|PO^Oral^HL7 Table 0162

When the pharmacist codes and verifies an order request, a new order request will be sent to the vending system if the outbound order interface is enabled. This order request takes the form of a fully encoded pharmacy order as displayed on the following page.

Sample Order Sent to Vending System when the pharmacist codes and verifies an order request.

MSH|^~\&|RXLINK|LHC Group|Vending System|LHC Group|20071005123151||RDE^O01|200710051231511051|P|2.3.1|1||AL|ALEVN|O01|20071005123151PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC GroupORC|NW|14675||||N|1^Q12h^INDEF^20041116080000^20051116080000^R^0^11111110|||^Nurse^Sally^^^^^^^L^^^PN^LHC Group^A||^Robinson^Juliet^^^^^T_RXL_StaffMember^RXLINK^L^^^DN^LHC Group^A|Unknown^^^LHC Group|||NW^New Order|^LHC GroupRXE|400&MG^Q12h^INDEF^20041116080000^20051116080000^R^0^11111110|5107734^SECTRAL 400 mg^Charge Code^2024^Acebutolol Hydrochloride 400 mg^Drug ID|400||MG^MG|CAP^Capsule||Unknown^999^99^LHC Group|N|1|Capsule^Capsule|||Developer^King^Bill^^^^^T_RXL_StaffMember^RXLINK^L^^^PN^LHC Group^A|14675|||||N|||||400|mg^mg||1|Capsule|UD|1RXR|PO^Oral^HL7 Table 0162

39

40

Sample Order Messages

Single Component Medication OrderMSH|^~\&|||||200210091347||ORM^O01|200411101340|P|2.3|||AL|ALPID|1||123456||Duck^Daffey^||19541006|M||||||||||123456789|PV1|1|I|Surg^801^A^Main||||100^Bement^Stephen||||||||||100^Bement^Stephen|IP||Other||||||||||||||||||||||||200107131430||ORC|NW|OE1234|||||1&EA^Q12H^D14^200411160800^200411300800||200411101400|^Nurse^Sally||100^Bement^Stephen|||||||RXO|5107734^Sectral^CHGCODE|400||MG^MG|CAP^Capsule||||N|||||||||400|mg^mg||||RXR|PO

Single Component IV OrderMSH|^~\&|||||200210091347||ORM^O01|200411101347|P|2.3|||AL|ALPID|1||123456||Duck^Daffey^||19541006|M||||||||||123456789|ORC|NW|OE1235|||||1&EA^C^^200411160800^||200411101400|^Nurse^Sally||100^Bement^Stephen|||||||RXO|05177106^DEXTROSE/SODIUM CHLORIDE|1000||ML^ML|IV^IV||||N||||||||H10||||100|ML^MLRXR|IV

IV Orders with more than one componentMSH|^~\&|||||200210091347||ORM^O01|200411101347|P|2.3|||AL|ALPID|1||123456||Duck^Daffey^||19541006|M||||||||||123456789|ORC|NW|OE1237|||||1&EA^C^D2^200411160800^200411180800^TM30||200411101400|^Nurse^Sally||100^Bement^Stephen|||||||RXO|||3|L^L|IV^IV||||N||||||||H10||||100|CC/HRRXR|IV|LA|IV-SET01^^LRXC|B|05177106^DEXTROSE/SODIUM CHLORIDE|1000|mlRXC|A|05107948^POTASSIUM CHLORIDE|20|MEQ

Text Order messageMSH|^~\&|||||200210091347||ORM^O01|200411101347|P|2.3|||AL|ALPID|1||123456||Duck^Daffey^||19541006|M||||||||||123456789|PV1|1|I|Surg^801^A^Main||||100^Bement^Stephen||||||||||100^Bement^Stephen|IP||Other||||||||||||||||||||||||200107131430||ORC|NW|OE1236|||||1&EA^C^D2^200411160800^200411180800^TM30||200411101400|^Nurse^Sally||100^Bement^Stephen|||||||RXO|||3|L^L|IV^IV|D5W WITH 1/2 NS WITH 20 MEQ KCL EVERY THIRD BOTTLE STARTING WITH First|||N||||||||H30|||||RXR|IV|LA|IV-SET01^^L

Sample Piggyback OrderMSH|^~\&|||||200210091347||ORM^O01|200411101347|P|2.3|||AL|ALPID|1||123456||Duck^Daffey^||19541006|M||||||||||123456789|PV1|1|I|Surg^801^A^Main||||100^Bement^Stephen||||||||||100^Bement^Stephen|IP||Other||||||||||||||||||||||||200107131430||ORC|NW|OE1238|||||1&EA^Q6H^^200411160800||200411101400|^Nurse^Sally||100^Bement^Stephen|||||||RXO||50||ML^ML|IV^IV||||N|||||||||||||RXR|IV|LA|IV-SET01^^LRXC|B|05177077^DEXTROSE/SODIUM CHLORIDE|50|CCRXC|A|05107199^CEFAZOLIN SODIUM|1|GM

41

Pharmacy/Treatment Administration Messages

Pharmacy/treatment administration (RAS) messages are generated by an order entry system and received by the HL7 interface for Rx-Link. Upon successful processing of these messages, the HL7 will enter a medication administration record for the appropriate order.

Rx-Link has a setting that permits a facility to charge patients only when a medication is administered to the patient. When this setting is enabled, an administration charge record is also created when an administration message is successfully processed. NOTE: Bulk medications are not charged for when an administration message is processed. The pharmacy must charge for bulk medications. This does not include IV solutions. For example, primary and piggy-back IV’s are charged when an administration message is successfully processed by the HL7.

An RAS message should be created by the administering application (e.g., nursing application) for each instance of administration for an existing order. If the administering application wants to report several administrations of medication for a given order with a single RAS message, each instance is reported by a separate (repeating) RXA segment. Additionally, administration records for a group of orders may be sent in a single message by creating repeating groups of segments at the ORC level.

If administration records for groups of orders are sent in a single message, all of the orders must be long to a single patient. Crown Software’s HL7 interface does not support batch processing of administration messages and the paragraph above is not interpreted to mean that the interface should or msut support batch processing of administration messages.

Multiple RXA segments, each corresponding to a separate administration instance for a given order, may be sent with a single ORC.

Crown Software’s HL7 Interface will send an acknowledgement message for each administration message received. The acknowledgement will contain the Message Control ID of the received message. If multiple RXA segments or multiple ORC and RXA segments are contained in a single message, some of the administrations may be processed and others fail to be processed. For example, it would be possible to process several mediation administrations and fail to process an administration for an IV that is contained in the same message. If charge on administration is being used, there is no what to detect that the IV was not charged for since the administration failed. Charges are only created for successful administrations when charge on administration is being used. For this reason, Crown Software strongly encourages the sending of one administration message for each administration instance.

The ORC Segment should contain an Order Control Code of RE (Observations To Follow) to report medication administrations to Rx-Link For Windows.

42

Sample Administration Messages

Medication Administration:

MSH|^~\&|PHARM||CROWN SOFTWARERX||200706270854|1005|RAS^O01|1005|P|2.3|1||AL|ALEVN|RAS|199903130850|PID|1||123456||Mouse^Mickey||19541006|M||||||||||1234567890|ORC|RE|OE1234|5407||||^1x Daily^^200706271039^||200706271100|Developer^King^Bill|Developer^King^Bill|500^Griswald^MarileeRXA|1|1|20070627110000|20070627110000|4000123^Fentanyl Patch 25MCG/HR^CHGCODE|1|^EA|^TDM||4156356^Nurse^Sally|||25|^MCG||||||CP||

Primary IV:

MSH|^~\&|PHARM||CROWN SOFTWARERX||200706270854|1007|RAS^O01|1007|P|2.3|1||AL|ALEVN|RAS|199903130850|PID|1||123456||Mouse^Mickey||19541006|M||||||||||1234567890|ORC|RE|OE1235|5408||||^C^^200706271039^||200706271100|Developer^King^Bill|Developer^King^Bill|500^Griswald^MarileeRXA|1|1|20070627110000|20070627110000|2500050^Normal Saline^CHGCODE|1|^EA|^SOL||4156356^Nurse^Sally|||1000|^ML||||||CP||

Piggy-back IV

MSH|^~\&|PHARM||CROWN SOFTWARERX||200706270854|1006|RAS^O01|1006|P|2.3|1||AL|ALEVN|RAS|199903130850|PID|1||123456||Mouse^Mickey||19541006|M||||||||||1234567890|ORC|RE|OE1236|5409||||^Q6H^^200706271039^||200706271100|Developer^King^Bill|Developer^King^Bill|500^Griswald^MarileeRXA|1|1|20070627110000|20070627110000|RXCUSIV^Custom IV^CHGCODE|1|^EA|^SOL||4156356^Nurse^Sally|||250|^ML||||||CP||

Multiple Order Administration Message

MSH|^~\&|PHARM||CROWN SOFTWARERX||200706282205|1010|RAS^O01|1010|P|2.3|1||AL|ALEVN|RAS|200706282205|PID|1||123456||Mouse^Mickey||19541006|M||||||||||1234567890|ORC|RE|OE1234|5407||||^1x Daily^^200706271039^||200706271100|Developer^King^Bill|Developer^King^Bill|500^Griswald^MarileeRXA|1|1|20070628220000|20070628220000|4000123^Fentanyl Patch 25MCG/HR^CHGCODE|1|^EA|^TDM||4156356^Nurse^Sally|||25|^MCG||||||CP||ORC|RE|OE1236|5409||||^Q6H^^200706271039^||200706271100|Developer^King^Bill|Developer^King^Bill|500^Griswald^MarileeRXA|1|1|20070628220000|20070628220000|RXCUSIV^Custom IV^CHGCODE|1|^EA|^SOL||4156356^Nurse^Sally|||250|^ML||||||CP||ORC|RE|OE1235|5408||||^C^^200706271039^||200706271100|Developer^King^Bill|Developer^King^Bill|500^Griswald^MarileeRXA|1|1|20070628220000|20070628220000|2500050^Normal Saline^CHGCODE|1|^EA|^SOL||4156356^Nurse^Sally|||1000|^ML||||||CP||

43

Multiple Administrations For a Single Order

MSH|^~\&|PHARM||CROWN SOFTWARERX||200706270854|1012|RAS^O01|1012|P|2.3|1||AL|ALEVN|RAS|199903130850|PID|1||123456||Mouse^Mickey||19541006|M||||||||||1234567890|ORC|RE|OE1238|5406||||^1x Daily^^200706271039^||200706271100|Developer^King^Bill|Developer^King^Bill|500^Griswald^MarileeRXA|1|1|20070625110000|20070625110000|3000328^Cardizem 30 mg^CHGCODE|1|^Tablet|^TAB||4156356^Nurse^Sally|||30|^MG||||||CP||RXA|2|2|20070626110000|20070626110000|3000328^Cardizem 30 mg^CHGCODE|1|^Tablet|^TAB||4156356^Nurse^Sally|||30|^MG||||||CP||RXA|3|3|20070627110000|20070627110000|3000328^Cardizem 30 mg^CHGCODE|1|^Tablet|^TAB||4156356^Nurse^Sally|||30|^MG||||||CP||RXA|4|4|20070628110000|20070628110000|3000328^Cardizem 30 mg^CHGCODE|1|^Tablet|^TAB||4156356^Nurse^Sally|||30|^MG||||||CP||

44

Vending System Pocket Message Processing

Pocket messages are received from vending systems to communicate pocket activity and consist of an MSH segment followed by a single ZPM segment. Vending systems use these messages to communicate the following:

Pocket Content or Count (Supported) Pocket Load (Supported) Pocket Fill (Supported) Pocket Unload (Supported) Expired Medications (Not Supported) Empty Bin (Not Supported) Cancel Transaction (Not Supported) System Configuration Information (Not Supported)

Crown Software’s implementation of the HL7 interface supports only those pocketMessages followed by (Supported) above.

Drug locations must be identified by a Vending Station (ZPM:3), Drawer (ZPM:4), Sub-drawer (ZPM:21), and Pocket (ZPM:5) in the ZPM segments. If a drawer contains no sub-drawers, the sub-drawer is identified by 0 or an empty sub-drawer field.

ZPM:11 reflects the transaction amount.

*** IMPORTANT ***

There are hard limits as to the number of Drawers, sub-drawers, and pockets that RxLink For Windows can process. Ignoring these limits will result in vending station pocket counts not being updated to reflect accurate inventory in Floor Stock.

Maximum Drawers = 200

Maximum Sub-Drawers per Drawer = 99

Maximum Pockets per Drawer or Sub-drawer = 99

45

Sample Pocket Messages

Pocket Load

MSH|^~\&|VendingSystemName||RXLINK||20041029093600||ZPM|200410290001|P|2.3|||AL|ALZPM|L|VendingSystemName|MEDVS|2|A1|623|IBUPROFEN|||||||||10||||MED|1|||||

The pocket load message is used to place a new drug in a pocket that is currently empty or to replace a drug that is already in the pocket. If the pocket already contains a drug, the drug is replaced by the drug identified in the ZPM segment and the quantity in the drawer is updated according to the ZPM segment. The full count from ZPM:22 is used for the quantity in the pocket.

Pocket Unload

MSH|^~\&| VendingSystemName ||RXLINK||20041029093600||ZPM|200410290013|P|2.3|||AL|ALZPM|U| VendingSystemName |MEDVS|2|A1|623|IBUPROFEN|||||||||10||||MED|1|||||

The unload message removes a drug from a vending system pocket and leaves the pocket empty.

Pocket Fill

MSH|^~\&| VendingSystemName ||RXLINK||20041029093600||ZPM|200410290005|P|2.3|||AL|ALZPM|F| VendingSystemName |MEDVS|2|A1|623|IBUPROFEN||||10|||||20||||MED|1|||||

The pocket fill message updates the number of items contained in a drawer. For example, the pocket identified in the ZPM segment is supposed to contain 20 Ibuprofen when it is full as indicated in ZPM:22 and currently contains 10. ZPM:11 indicates a transaction amount of 10 which means that the pharmacy is adding 10 more to the drawer. After processing the message, the current count will reflect that the drawer contained 10 and 10 were added so the current pocket count is 20 indicating that the pocket is full.

Pocket Content/Count

MSH|^~\&| VendingSystemName ||RXLINK||20041029093600||ZPM|200410290010|P|2.3|||AL|ALZPM|C| VendingSystemName |MEDVS|2|A2|622|IBUPROFEN||||15|||||15||||MED|1|||||

The pocket content or count message is generated when the pocket is inventoried and updates the total number of items contained in a pocket. If the drug identified in the ZPM segment is not the same as the drug believed to be in the drawer, the Pharmacy floor stock will be updated to reflect that the drug in the vending system is the drug identified in the ZPM segment. If the location specified in the ZPM segment does not exist, the HL7 interface will attempt to create the location and set the item count. The total used to update the pocket count should be in ZPM:22.

The above pocket messages are the only pocket messages supported by Crown Software’s implementation of this interface.

46

HL7 Message Segments

MSH Segment Definition

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Field Separator 1 R |2 Encoding Characters 4 R ^~\&3 Sending Application 1804 Sending Facility 1805 Receiving Application 1806 Receiving Facility 1807 Date/Time of Message 268 Security 409 Message Type 7 R <msgtype>^<trigger>10 Message Control ID 20 R Must uniquely identify the

message. No duplication allowed.

11 Processing ID 3 R T(raining) or P(roduction)12 Version ID R 2.313 Sequence Number 1514 Continuation Pointer 18015 Accept Acknowledgement

Type2 AL – Always

NE – NeverER – Error/reject conditions onlySU – Successful Completion only

16 Application Acknowledgement Type

2 AL – AlwaysNE – NeverER – Error/reject conditions onlySU – Successful Completion only

17 Country Code 218 Character Set19 Principal Language of

Message60

20 Alternate Character Set Handling Scheme

20

Crown Software’s HL7 interface will not recognize any other characters as field separators or encoding characters.

47

MSA Segment Definition

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Acknowledgement Code 2 R See Acknowledgement Code

Definitions2 Message Control ID 20 R Must be unique3 Text Message 80 O4 Expected Sequence

Number15 O

5 Delayed Acknowledgment Type

1 B

6 Error Condition 100 O

Acknowledgment Codes

AA Original Mode: Application AcceptEnhanced Mode: Application acknowledgment – AcceptAE Original Mode: Application ErrorEnhanced Mode: Application acknowledgment – ErrorAR Original Mode: Application RejectEnhanced Mode: Application acknowledgment – RejectCA Enhanced Mode: Accept acknowledgment – Commit AcceptCE Enhanced Mode: Accept acknowledgment – Commit ErrorCR Enhanced Mode: Accept acknowledgment – Commit Reject

Crown Software’s HL7 interface uses the original message processing rules.

The Message Control ID if field 2 contains the message control ID of the message sent by the sending system. It allows a sending system to associate this response with the message for which it is intended.

ERR Segment Definition

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Error Code and Location 80 R

48

EVN Segment Definition

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Event Type Code 3 B2 Recorded Date/Time 26 R3 Date/Time Planned Event 264 Event Reason Code 35 Operator ID 606 Event Occurred 26

The EVN segment is used to communicate necessary trigger event information to receiving applications. Crown Software’s HL7 interface with look for the trigger event in the second component of MSH:9. If it is not found there, it will look for the trigger event in the EVN segment. If the interface cannot find a valid trigger event in either location, the message will be rejected.

The EVN segment has been included in the HL7 interface for backward compatibility. It is only used if the trigger event is not contained in MSH:9.

49

PID Segment Definition

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Set ID 4 R PID2 Patient ID 203 Patient Identifier List 20 R Must contain the patient’s

account number only4 Alternate Patient ID 20 R Must contain the patient’s

Medical Record Number5 Patient Name 48 R6 Mother’s Maiden Name 487 Date/Time of Birth 268 Sex 1 F - Female

M - MaleO - OtherU – Unknown

9 Patient Alias 4810 Race 8011 Patient Address 10612 County Code 413 Phone Number – Home 4014 Phone Number – Business 4015 Primary Language 6016 Marital Status 8017 Religion 8018 Patient Account Number 20 If populated, must be the

same as PID:3 (patient’s account number)

19 SSN Number – Patient 1620 Driver’s License Number

– Patient25

21 Mother’s Identifier 2022 Ethnic Group 8023 Birth Place 6024 Multiple Birth Indicator 125 Birth Order 226 Citizenship 8027 Veterans Military Status 6028 Nationality 8029 Patient Death Date/Time 2630 Patient Death Indicator 1

The PID segment is used by all applications as the primary means of communicating patient identification information. This segment contains permanent patient identifying information that, for the most part, is not likely to change.

50

PV1 Segment Definition

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 SET ID 4 R PV12 Patient Class 1 R I – Inpatient

(See discussion below)3 Assigned Patient Location 80 Unit^Room^Bed (See Note)4 Admission Type 25 Preadmit Number 206 Prior Patient Location 80 Unit^Room^Bed (required

whenPatient is transferred from one bed to another.)

7 Attending Doctor 608 Referring Doctor 609 Consulting Doctor 6010 Hospital Service 311 Temporary Location 8012 Preadmit Test Indicator 213 Re-admission Indicator 214 Admit Source 315 Ambulatory Status 216 VIP Indicator 217 Admitting Doctor 6018 Patient Type 2 (See discussion below)19 Visit Number 2020 Financial Class 5021 Charge Price Indicator 222 Courtesy Code 223 Credit Rating 224 Contract Code 225 Contract Effective Date 826 Contract Amount 1227 Contract Period 328 Interest Code 229 Transfer to Bad Debt

Code1

30 Transfer to Bad Debt Date

8

31 Bad Debt Agency Code 1032 Bad Debt Transfer

Amount12

33 Bad Debt Recovery Amount

12

51

34 Delete Account Indicator 135 Delete Account Date 836 Discharge Disposition 337 Discharged To Location 2538 Diet Type 8039 Servicing Facility 240 Bed Status 141 Account Status 242 Pending Location 8043 Prior Temporary Location 8044 Admit Date/time 2645 Discharge Date/Time 2646 Current Patient Balance 1247 Total Charges 1248 Total Adjustments 1249 Total Payments 1250 Alternate Visit ID 2051 Visit Indicator 152 Other Healthcare Provider 60

NOTE: All patients in Rx-Link For Windows occupy a bed whether they are inpatients or not. This means that even locations that are usually outpatient locations such as ER must be associated with a room and bed. If the HL7 interface receives a location that contains only a UnitName, the interface will append 999 for a room number and 99 for a bed.

If the specified location cannot be located the the Rx-Link For Windows database, the patient will be admitted to the location “UNK-999-99”.

Discussion

According to HL7 Specification V2.3.1, the data contained in PV1:2 and PV1:18 is contained in user-defined tables. The recommended values for Patient Class (PV1:2) are as follows:

E EmergencyI InpatientO OutpatientP PreadmitR RecurringB Obstetrics

At a minimum, the admitting system must send either “I” or “O” in PV1:2.

52

RxLink For Windows uses the table shown above to hold these minimum recommended values. The values in Patient Class Code may not be duplicated; however, other values may be added to the table

Note that there are no entries in the Patient Type column. Patient Type represents the values contained in PV1:18.

If an admitting system can send only I or O in PV1:2, the HL7 will send I or O accordingly to any system we send ADT messages to. That means that your vending system will see only I or O if PV1:18 is empty. If more detail is required so that ER patients appear in the ER Vending Station and the admitting system sends ER in PV1:18, then the user should enter ER in the Patient Type field for the Patient Class Code of E.

The HL7 interface uses this table as, for ADT messages as follows:

If the value in PV1:2 is an O, look for data in PV1:18. If PV1:18 is blank, the patient is an outpatient. If PV1:18 is not blank, look for the entry in the Patient Type field of the above table. If it is found, use the Patient Type Code for that entry. This means that we received an O in PV1:2 but, we saved the patient record using a Patient Class of E for Emergency Room. In this way, the HL7 will send an E to downstream systems.

53

AL1 Segment Definition

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Set ID 4 R2 Allergy Type 23 Allergy

Code/Mnemonic/Description60 R Coded Element

4 Allergy Severity 25 Allergy Reaction 166 Identification Date 8

The Crown Software HL7 Interface will recognize Allergy Codes and/or Allergy Descriptions from the allergy table used by Rx-Link For Windows. The interface uses an HL7 coded element to describe the allergy. Rx-Link uses MicroMedix for allergy checking so the code in the coded element should be an MicroMedix code. The coding system identifier for MicroMedix is MDDX. This table can be exported to a comma-delimited text file from Rx-Link For Windows.

Each AL1 segment should have a unique Set ID beginning with 1. Subsequent AL1 segments will be numbered 2, 3, … etc.

The minimum entry in field 3 would be ^Allergy Description. If the sending system is able to support the sending of MicroMedix allergen codes, the field should be coded as follows:

MicroMedix Allergen Identifier^Allergy Description^MDDX

If the allergen identifier is not provided, the interface will attempt to match the allergy description with one of the MicroMedix allergens. If a match is made, the Allergy will be indicated on the patient allergy screen. If not match is made, the description provided in the AL1 segment will be recorded in the discussions for the patient. It will be the pharmacy’s responsibility to select the appropriate MicroMedix allergy and record it in the patient allergies before allergy checking will be done for prescribed medications.

54

MRG Segment Definition

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Prior Patient Identifier List 20 R Patient Medical Record

Number2 Prior Alternate Patient ID 20 Not Used3 Prior Patient Account

Number20 C Patient Account Number

4 Prior Patient ID 20 C Patient Medical Record Number

5 Prior Patient Visit Number 20 Not Used6 Prior Alternate Visit ID 20 Not Used7 Prior Patient Name 20 Not Used

The conditional fields are dependent upon the event being sent to perform the merge. The HL7 interface does not support merging both the Medical Record Number and the Account Number in a single transaction. Two transactions are required (one to merge the Medical Record Number and one to merge the account number.

55

DG1 Segment Definition

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 SET ID 4 R DG12 Diagnosis Coding Method 2 (B)R3 Diagnosis Code 60 R Coded Element4 Diagnosis Description 40 O5 Diagnosis Date/Time 26 O6 Diagnosis Type 2 R A – Admitting

W – WorkingF - Final

7 Major Diagnostic Category

60

8 Diagnostic Related Group 609 DRG Approval Indicator 210 DRG Group Review

Code2

11 Outlier Type 6012 Outlier Days 313 Outlier Cost 1214 Grouper Version And

Type4

15 Diagnosis Priority 216 Diagnosing Clinician 6017 Diagnosis Classification 318 Confidential Indicator 119 Attestation Date/Time 26

Each DG1 segment should have a unique Set Id. The Set ID of the first DG1 segment would be 1, the Set ID of the second would be 2, etc.Rx-Link uses MicroMedix to identify diagnoses. Field 3 is a coded element field. The MicroMedix diagnosis codes can be exported from Rx-Link. Rx-Link will also use ICD9 codes to attempt to identify a diagnosis. The codes are optional; however, if codes are not used, the diagnosis description should be preceded by a ^ in this field. The field should be formatted as follows:

MicroMedix Diagnosis Code^Description^MDDX^ICD9 Code^Description^ICD9

The minimum required in the field is: ^Diagnosis Description

If the diagnosis cannot be matched to a MicroMedix diagnosis, the information will appear in the Discussions for the patient so the pharmacist can code the diagnosis if they choose to do so.

56

FT1 Financial Transaction Segment

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Set ID 4 R2 Transaction ID 123 Transaction Batch ID 10 If the HL7 is configured to

send batch charges, we send the batch ID here

4 Transaction Date 26 R5 Transaction Posting Date 266 Transaction Type 8 R Use HL7 Configuration to set

these values7 Transaction Code 80 R ChargeCode^Drug

Name^CHGCODE^Drug Id^DrugName^DRUGID

8 Transaction Description 409 Transaction Description –

Alt40

10 Transaction Quantity 6 R11 Transaction Amount –

Extended12

12 Transaction Amount – Unit

12

13 Department Code 6014 Insurance Plan ID 6015 Insurance Amount 1216 Assigned Patient Location 8017 Fee Schedule 118 Patient Type 219 Diagnosis Code – FT1 6020 Performed By Code 12021 Ordered By Code 12022 Unit Cost 1223 Filler Order Number 22 R If the charge is from a

vending system24 Entered By Code 12025 Procedure Code 8026 Procedure Code Monitor 80

Each FT1 segment is required to have a unique set ID. If only one FT1 segment is sent in an HL7 message, the set ID must be 1. If multiple FT1 segments are sent in a single message, the set ID of the first FT1 should be 1 and subsequent FT1 segments should be numbered sequentially.

57

The HL7 interface does not accept batch charges from vending systems. It expects to receive real-time charges from all vending systems via a TCP/IP connection. Depending upon the interface needs of the hospital, the HL7 can send real-time charges to the hospital’s billing system or the HL7 can be configured to send the charges as a batch.

If the interface is configured to send charges as a batch, no charges are sent to the billing system until pharmacy personnel generate the charge batch in Rx-Link. This places a special trigger in an HL7 table signaling the HL7 to send a batch of charges. When Rx-Link generates a charge batch, all charges in the batch are given the same Batch ID.

The HL7 does not send the charges as a batch. Specifically, it does not send all of the charges enclosed by FHS, BHS, BTS, and FTS segments. The HL7 will send an individual charge message for each charge in the batch. The FT1 segment will contain the ID number for the batch in field 3.

The transaction code field is an HL7 Coded Element. The HL7 supports identifying substances either by charge code or by the Rx-Link Drug ID. The same setting that controls the way medications are identified for orders controls which identifier is used for financial transactions. A list of substances with their charge code and drug ID’s can be exported or printed from Rx-Link. The HL7 configuration permits the user to configure the primary identifier for medications.

If the charge code is selected as the primary identifier, the coded element should contain the following as a minimum: ChargeCode^DrugName^CHGCODE. If the Drug ID is chosen as the identifier, the Drug ID would replace the charge code in this string and the text after the second carat(^) should be DRUGID.

If Rx-Link is receiving charges from a vending system, the Rx-Link Prescription Number is required in field 23.

NTE Notes and Comments Segment

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Set ID 42 Source Of Comment 83 Comment 64K4 Comment Type 60

The NTE segment is the common format for sending notes and comments in HL7 messages. The HL7 interface supports NTE segments; however, Rx-Link does not support the storage of all of the comments that might be generated in an HL7 message. Comments attached to order messages are retained in the order comments.

Some systems send lab results in NTE segments. The HL7 interface does not support this use of the NTE segment.

58

OBX Observation/Result Segment

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 SET ID 10 R2 Value Type 33 Observation Identifier 590 Coded Element4 Observation Sub-ID 205 Observation Value 65536 Coded Element6 Units 60 Coded Element7 References Range 608 Abnormal Flags 59 Probability 510 Nature Of Abnormal Test 211 Observation Result Status 112 Date Last Observed

Normal Values26

13 User Defined Access Checks

20

14 Date/Time of Observation 2615 Producer’s ID 6016 Responsible Observer 8017 Observation Method 60

The only values that the HL7 interface uses the OBX segment for are the patient’s height and weight. All other values in OBX segments are ignored by the interface.

The interface will take height and weight measurements in either standard or metric format. The following values are used to identify whether the value contained in field 3 of the OBX segment is a height or weight:

Patient Weight Code - 1010.1Patient Height Code - 1010.3

No other values will be accepted by the HL7 interface.

Examples of valid OBX segments using metric measurements:

OBX|1|ST|1010.1^Body Weight||95.45|KG|OBX|2|ST|1010.3^Body Height||185.42|CM|

In the above examples, the units of measure could be replaced by the standard values of IN for inches and LB for pound. Naturally, the values would have to be adjusted as well.

Values not communicated in the above format will be ignored by the HL7 interface.

59

ORC Common Order Segment

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Order Control 2 R2 Placer Order Number 22 R3 Filler Order Number 22 C4 Placer Group Number 225 Order Status 2 C6 Response Flag 1 C7 Quantity and Timing 200 R HL7 TQ Data Type8 Parent 2009 Date/Time of Transaction 26 R10 Entered By 120 R HL7 XCN Data Type11 Verified By 120 C HL7 XCN Data Type12 Ordering Provider 120 R HL7 XCN Data Type13 Enterer’s Location 80 C HL7 PL Data Type14 Call Back Phone Number 40 C15 Order Effective

Date/Time26

16 Order Control Code Reason

200

17 Entering Organization 6018 Entering Device 6019 Action By 12020 Advanced Beneficiary

Notice Code40

The ORC segment is common to all order messages. The HL7 interface uses the data contained in field 7 of this segment to formulate the order schedule. It uses the Order Control in field 1 to determine what action to take (i.e., New Order, Discontinue Order, Renew Order, etc.).

The Placer Order Number in field 2 must contain a unique identifier generated by the ordering system. This unique identifier and the Rx-Link prescription number form a unique pair of identifiers that is used to identify the order in both the ordering system and Rx-Link.

Crown Software’s HL7 Interface treats all inbound order messages as requests. When the request is received, the HL7 will commit the request to a system table and respond to the message with and OK order control code to indicate that Rx-Link has accepted responsibility for the message or a UA order control code indicating that Rx-Link has not accepted responsibility for the message.

The HL7 will not attempt to encode an order. The information from the system table is displayed to the pharmacist, in Rx-Link, and it is the pharmacist’s responsibility to encode the order. Once a new order has been encoded and validated by a pharmacist, a trigger event tells the HL7 to send a change order notification (XX) to the ordering system. This message

60

communicates the Rx-Link prescription number to the ordering system and places the order in an active status. Until this process is completed, all new orders will be pending orders.

The only way that the HL7 is likely to reject a new order request is if a duplicate Placer Order Number is found to exist in Rx-Link.

Requests to discontinue, cancel, or renew orders are automatically handled by the HL7 interface provided that a matching order is found. A matching order is an order that already has its Placer Order Number recorded in Rx-Link. The appropriate success or failure response will be sent to the ordering system by the HL7.

NOTE: The only change that the HL7 will process is to renew the order. Renewing an order simply moves the order’s stop date to a date in the future. The new stop date should be in the Quantity and Timing field. The start date will not be changed.

You may not change the schedule, ingredients, or any other information about an order with a change order request. Changing anything other than the order’s stop date required the the order be discontinued and re-written. Also note that there is no DC and Rewrite functionality in the HL7 specification. DC and Rewrite operations require two separate actions.

HL7 table 0119 lists all of the order control codes identified in the specification. The HL7 interface uses a subset of the codes from this table. The order control codes supported by Crown Software’s HL7 interface are as follows:

HL7Value Event Description CommentNW O01 New OrderOK O02 Order AcceptedUA O02 Unable To Accept OrderCA O01 Cancel Order Request Treated as DCDC O01 Discontinue Order RequestOD O01 Order Discontinued Discontinued In Rx-LinkDR O02 Discontinued As RequestedRE O01 Observations To Follow Use to report administrationsSC O01 Status Changed Pharmacy coded orderUD O02 Unable To DiscontinueXO O01 Change Order Request Used to renew ordersXX O01 Order Change, Unsol. Order was changed in Rx-LinkUX O02 Unable To ChangeXR O02 Changed As Requested

Those fields marked as conditional in the above segment specification are dependent on the HL7 trigger event and the direction the message is being sent. Some of the data is only relevant if information about a validate order is being communicated to a vending system while other information is only relevant if the HL7 is responding to or communicating changes to the ordering system.

61

In all cases, the ORC segment reflects what was requested by the ordering system. When a validate order is sent to a vending system, the RXE segment communicates the pharmacy’s interpretation of the information contained in the ORC segment. Consequently, it is possible for the schedule information contained in the ORC segment to be different from the schedule information contained in the RXE segment. The RXE segment is part of a fully encoded pharmacy order and is covered elsewhere in this document.

Crown Software’s HL7 interface supports bi-directional communication with an ordering system in order to update the status of an order request.

The HL7 interface will not perform the following:

Send a new order entered directly in Rx-Link to an order entry system requesting a Placer Order Number

If an order is discontinued, cancelled, or renewed in Rx-Link, the interface will not send notification of these events to the ordering system.

The interface will send notification of these events to a vending system. The reason for this is that most order entry systems do not accept messages creating new orders from external systems.If this level of bi-directional communication is needed, we will attempt to implement it in a later version of the interface.

Only orders that have been validated, by a pharmacist, will be sent to a vending system.

Note that charges received from a vending system can create orders in Rx-Link. These are override charges as discussed earlier in this document. Orders created by override charges are not sent upstream to an order entry system so it is possible for a patient’s profile in Rx-Link to contain medication orders that are not reflected in an order entry system.

All orders created by override charges will be entered as one-time, un-validated orders. There is a menu option on the Pharmacist Menu that permits the review of these orders.

62

RXA Pharmacy/Treatment Administration Segment

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Give Sub-ID Counter R2 Administration Sub-

ID CounterR

3 Administration Start Date/Time

26 R

4 Administration End Date/Time

26 R

5 Administered Code R ChargeCode^Drug Name^CHGCODE^Drug Id^DrugName^DRUGID

6 Administered Amount

R

7 Administered Units 60 C ^Description^8 Administered Dosage

Form60 O ^Dosage Form^

9 Administration Notes 200 O ^Notes^10 Administering

Provider200 R EmployeeID^LastName^FirstName

11 Administered At Location

200 O Crown Software will not use this

12 Administered Per 20 C13 Administered

StrengthO

14 Administered Strength Units

60 O ^Strength Units^

15 Substance Lot Number

20 O Crown Software will not use this

16 Substance Expiration Date

26 O Crown Software will not use this

17 Substance Manufacturer Name

60 O Crown Software will not use this

18 Refusal Reason 200 O ^Refusal Reason^19 Indication 200 O Crown Software will not use this20 Completion Status 2 R CP – Complete

RE – RefusedNA – Not AdministeredPA – Partially Administered

21 Action Code – RXA 2 O Crown Software will not use this22 System Entry

Date/Time26 R

63

Give Sub-ID Counter – This field should be 0 since Rx-Link does not match RXG segments to RXA segments.

Administration Sub-ID Counter – Starts with 1 the first time a medication is administered for an order and increments by 1 with each additional administration of the medication.

Administration Start Date/Time – Date and time the administration was started.

Administration End Date/Time – Date and time the administration ended. This is a required field; however, it may be the same as the Administration Start Date/Time.

Administered Code – Identifies the medical substance administered. In the case of compounded substances, the field must contain RXCUSIV^Custom IV^CHGCODE.

Administered Amount – Contains the amount administered.

Administered Units – Required if the administered amount does not imply units. For example, 2 tablets were administered so the administered amount would be two and the Administered Units would contain tablets.

Administered Dosage Form – Indicates the manner in which the medication is aggregated for dispensing.

Administration Notes – Notes entered by the provider administering the medication. Useful for documenting reasons for partial administrations.

Administering Provider – Identifies the person administering the medication. Rx-Link requires this field. It should consist of the Employee ID entered in the Rx-Link Staff table followed by a carat(^) the person’s last name, a carat (^), and the person’s first name.

Example: 2006^Nurse^Sally

If the administering provider cannot be identified in Rx-Link, the administration record will be rejected and any charges resulting form Charge On Administration will not be generated.

Administered At Location – Not used.

Administered Per – Contains the rate at which a medication is administered. It is required for IV Orders.

Administered Strength – The strength of the substance administered.

Administered Strength Units – Identifies the Administered Strength Units. For example, a 30 mg tablet is administered. The Administered Strength would contain 30 and the Administered Strength Units would contain mg.

64

Substance Lot Number – Not usedSubstance Expiration Date – Not used

Substance Manufacturer Name – Not used

Substance Refusal Reason – Used to document the reason a patient refused the medication.

Indication – Not used

Completion Status – Status of treatment administration event. This is a required field and may contain one of the following values:

CP – CompleteRE – RefusedNA – Not AdministeredPA – Partially Administered

Action Code – Not used

System Entry Date/Time – Required. Reflects the time the administration record was actually entered into the administering system.

65

RXC Pharmacy/Treatment Component Order Segment

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 RX Component Type 1 R B – Base or A – Additive2 Component Code 100 R Coded Element3 Component Amount 20 R4 Component Units 60 R Coded Element5 Component Strength 206 Component Strength Units 60 Coded Element7 Charge Units 10 R/O See Explanation

If the drug or treatment ordered with the RXO segment is a compound drug or an IV solution and there is not a coded value for the Universal Service ID which specifies the components (base and all additives), then the components (the base and additives) are specified by two or more RXC segments.

For example, there is a unique charge code that identifies Tylenol 3 or Tylenol with codine. Consequently this medication can be ordered using the RXO segment and does not require the use of RXC segments to reflect a Base substance of Tylenol with an additive of codine.

On the other hand, there is no unique identifier or charge code for requesting 50 ml of D5W with 20 meq of KCL. These are unique components with their own unique charge code. An order of this type would require an RXO segment indicating that this is a Custom IV, an RXC segment identifying the 5 ml of D5W as the BASE component, and another RXC identifying the 20 meq of KCL as the additive.

Crown Software’s HL7 interface will reject any multiple ingredient order that attempts to identify an ingredient in the RXO segment. There must be an RXC segment for every ingredient to be included in an IV order and the RXO segment must specify that the order is for a Custom IV. This is in strict compliance with the HL7 specification.

The component code in field 2 uniquely identifies the requested substances. Substances may be identified by either charge code or the Rx-Link Drug ID. This is software configurable and the default is to identify substances using the charge code. Substances should be encoded as in the following example:

1234567^Some Drug^CHGCODE

Where 1234567 is the charge code for the substance, the second field contains the name of the substance, and CHGCODE identifies the coding method. If the Drug ID is used to identify substances, the coding method should be DRUGID.

Because coded elements allow for alternate codes and descriptions, messages sent to vending systems use the following format for the component code:

ChargeCode^TradeName^CHGCODE^DrugId^GenericName^DRUGID

66

Component Amount identifies the amount of the component to be added to the specified amount of the base. If 100 ml of a component is to be added to the base, this field would contain 100.

Component Units identifies the units for the component amount. If present, this field overrides the units implied by the component code in RXC:2. This must be simple units that reflect the actual quantity of the component being added. Using the above example of 100 ml, this field should contain ml^milliliters.

Note: The HL7 interface expects ml (milliliters). It will not use cc’s or L for liters. One liter of D5W must be ordered as 1000 ml.

Component Strength is used when RXC:2 does not specify the strength of the requested substance.

Component Strength Units is used when RXC:2 does not specify the strength of the requested substance.

Charge Units This field was added by Crown Software so we could tell the vending system the number of charge units for an order ingredient so a nurse would know how many items to remove from the pocket. For example, the pocket contains 325 mg Aspirin tablets. A patient is to receive 650 mg of aspirin. The nurse would need to pull 2 aspirin tablets for the patient so 2 is reflected in the Charge Units field. This field is required when Rx-Link sends a message containing an RXC segment to a vending system. It is not required when a system sends a message to Rx-Link.

67

RXR Pharmacy/Treatment Route Segment

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Route 60 R Coded Element2 Site 60 Coded Element3 Administration Device 60 Coded Element4 Administration Method 60 Coded Element5 Routing Instruction 60 Coded Element

Identifies the route by which a medication is to be administered. The only required field in this segment is the route. The route codes use by Rx-Link are:

Code Description Code Description Code DescriptionAP Apply Externally B Buccal DT DentalEP Epidural ET Endotrachial Tube GTT Gastronomy TubeGU GU Irrigant IA Intra-arterial IB IntrabursalIC Intracardiac ICV Intracervical (Uterus) ID IntradermalIH Inhalation IHA Intrahepatic IM IntramuscularIMR Immerse(Soak) Body IN Intranasal IO IntraocularIP Intraperitoneal IS Intrasynovial IT IntrathecalIU Intrauterine IV Intravenous MM MucousMTH Mouth/Throat NA Unknown/Not Applicable NG NasogastricNP Nasal Prongs NS Nasal NT Nasotrachial TubeOP Ophthalmic OT Otic OTH Other/MiscellaneousPF Perfusion PO Oral PR RectalRM Rebreather Mask SC Subcutaneous SD Soaked DressingSL Sublingual TD Transdermal TL TranslingualTP Topical TRA Tracheostomy UR UrethralVG Vaginal VM Ventimask WND Wound

68

RXO Pharmacy/Treatment Order Segment

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Requested Give Code 100 R Coded Element2 Requested Give Amount

Minimum20 R

3 Requested Give Amount Maximum

20

4 Requested Give Units 60 R Coded Element5 Requested Dosage From 60 R Coded Element6 Provider’s Pharmacy

Treatment Instructions200 Coded Element

7 Provider’s Administration Instructions

200 Coded Element

8 Deliver To Location 200 C If deliver to location is different than patient’s assigned location

9 Allow Substitutions 110 Requested Dispense Code 100 Coded Element11 Requested Dispense

Amount20

12 Requested Dispense Units 60 Coded Element13 Number Of Refills 314 Ordering Provider’s DEA

Number60 XCN

15 Verifier ID 60 XCN16 Needs Human Review 117 Requested Give Per (Time

Unit)20

18 Requested Give Strength 2019 Requested Give Strength

Units60 Coded Element

20 Indication 200 Coded Element21 Requested Give Rate

Amount6

22 Requested Give Rate Units

60 Coded Element

23 Total Daily Dose 10

This is the master pharmacy/treatment order segment. It contains order data not specific to components or additives. It can be used for any type of pharmacy order.

A quantity and timing field is not needed in the RXO segment. The ORC segment contains the requested quantity and timing in ORC:7. ORC:7 reflects the requested schedule for the order and this does not change as the order is encoded, dispensed, or administered.

69

Requested Give Code – identifies the substance to be given to the patient. For a single component order such as 250 mg of Pollycillen, where the charge code is used to identify the substance, this field would be encoded as:

ChargeCode^Pollycillen^CHGCODE

If the order is for an IV with multiple components, this field would be coded as:

RXCUSIV^Custom IV

The components making up the IV would be identified in RXC segments.

Requested Give Amount – Minimum reflects the ordered amount.

Requested Give Amount – Maximum In a variable dose order, this is the maximum amount ordered. Rx-Link does not currently support varying dose orders.

Requested Give Units – This field is expected to contain ml, mg, meq or some unit of measure.

In the case where the item is a bulk medication, such as an ointment or bottle of some single substance, the Requested Give Amount – Minimum would be 1 and the Requested Give Units could be Each, Bottle, Tube, etc.

If the substance is a tablet or injection where the amount to give quantity and units can be expressed in milligrams, grams, milliliters, etc., it is expected that the actual values be used. For example, if the substance is a 250 mg tablet, the Requested Give Minimum would be 250 and the Requested Give Units should be mg. If the substance is an injection such as 1 ml of Morphine and the patient is to receive 0.5 ml, of the substance, the Requested Give Minimum should be 0.5 and the Requested Give Units should be ml. In these instances, amounts and units should not be expressed as 1 tablet, 1 vial, etc.

Failure to code these fields correctly may result in medication errors.

Requested Dosage Form reflects how the medication is aggregated for dispensing, e.g., tablets, capsules, suppositories, etc. In some instances, this is implied by the Requested Give Code or Requested Dispense Code. For all IV orders, this field should contain IV. For all other orders, the field should contain the drug form from the Rx-Link Drug Master.

Provider’s Pharmacy/Treatment Instructions This field contains the provider’s instructions to the pharmacy. Although not the preferred method, the HL7 interface will accept orders such as:

GIVE D5W WITH ½ NS WITH 20 MEQ KCL EVERY THIRD BOTTLE STARTING WITH FIRST

70

An order written this way could have no RXC segments. This free text order is presented to the pharmacy, as is, by the Rx-Link application and it is up to the pharmacist to interpret and encode the order. This order would actually require two orders to be entered in Rx-Link.Provider’s Administration Instructions identifies the ordering provider’s instructions to the patient or to the provider administering the drug or treatment.

Deliver-to Location this is used if the location where the medication is to be delivered is different from the patient’s assigned location. For example, a patient’s assigned location is MED 101 A (Medical Floor, Room 101, Bed A); however, the patient is temporarily in the OR. Populating this field notifies the pharmacy that the medication needs to be sent to the OR rather than to MED 101 A.

Allow Substitutions indicates whether the pharmacy is permitted to substitute a similar medication in place of the prescribed medication. The HL7 looks for one of three values in this field:

N Substitutions not authorized (This is the default if no value is supplied)G Allow generic substitutionsT Allow therapeutic substitutions

Requested Dispense Code indicates what is to be dispensed. This value is not used in Crown Software’s implementation of the HL7 interface.

Requested Dispense Amount would normally be used for outpatient prescriptions or take home medications. If the provider wants the patient to receive 250 mg of Amoxicillen three times a day for 7 days, this field should reflect that the pharmacy should dispense 21.

Requested Dispense Units identifies the units for the dispense amount e.g., tablets, capsules, etc.

Number of Refills Not used in this implementation

Ordering Provider’s DEA Number identifies the provider’s controlled substance number. The HL7 specification indicates that this is required when the substance ordered is a controlled substance. Crown Software’s implementation of the interface does not enforce this requirement. If the information is present, we will attempt to use it. If it is not present, we will get the DEA number from the Rx-Link Physician table.

Pharmacist/treatment supplier’s verifier ID not implemented.

Needs Human Review indicates whether an order requires human review or not. Acceptable values are Y or N. The order validation process in Rx-Link enforces the policy that all orders require human review.

71

Requested Give Per (time unit) identifies the time unit used to calculate the rate at which the pharmaceutical is to be administered. This is a required entry when the ordered substance is to be administered continuously at a prescribed rate. Acceptable values for this field are:

S<integer> = <integer> secondsM<integer> = <integer> minutesH<integer> = <integer> hoursD<integer> = <integer> daysW<integer> = <integer> weeksL<integer> = <integer> months

Requested Give Strength Use this field when the value contained in RXO 1 does not specify the strength. This is the numeric part of the strength used in combination with the Requested Strength Units.

The need for strength and strength unit fields in addition to the amount and amount units fields included in various RX_ segments requires explanation. Physicians can write a prescription for a drug such as Ampicillin in two ways. One way would be: “Ampicillin 250 mg tabs, 2 tabs four times a day.” In this case the give amount would be 2, the give units would be tabs, the strength would be 250 and the strength units would milligrams. However, the provider could also write the prescription as “Ampicillin 500 mg four times a day.” In this case the give amount would be 500 and the give units would be milligrams. The strength would not be reported in the RXO segment because it is not specified; the drug could be given in two 250 mg caps or one 500 mg cap. But the pharmacist would dispense a specific pill size and would record the strength in the RXE segment as 250 or 500, depending upon which pill size was dispensed.

Requested Give Strength Units Used in conjunction with Requested Give Strength to determine the strength of the substance to be dispensed.

Indication identifies the condition or problem for which the drug was prescribed.

Requested Give Rate Amount identifies the rate at which to administer the treatment.

Requested Give Rate Units contains the units in which Requested Give Rate Amount is denominated.

For example, if 1000 ml of some substance is to be administered over 10 hours, the rate of administration would be 100 ml/hr. In this example, Requested Give Per Time should contain H10, Requested Give Rate Amount should contain 100, and Requested Give Rate Units should contain ml/hr.

72

Total Daily Dose contains the total daily dose for this particular pharmaceutical as expressed in terms of actual dispense units.

73

RXE Pharmacy/Treatment Encoded Order Segment

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Quantity/Timing 200 R TQ2 Give Code 100 R CE3 Give Amount – Minimum 20 R4 Give Amount –

Maximum20

5 Give Units 60 R CE6 Give Dosage Form 60 CE7 Provider’s Administration

Instructions200

8 Deliver To Location 2009 Substitution Status 110 Dispense Amount 2011 Dispense Units 60 CE12 Number Of Refills 3 Not Implemented13 Ordering Provider’s DEA

Number60 XCN

14 Pharmacist Verifier ID 60 XCN15 Prescription Number 20 Rx-Link generated Order

Number16 Refills Remaining 20 Not Implemented17 Refills/Doses Dispensed 20 Not Implemented18 Date of Most Recent

Refill or Dose Dispensed26 Not Implemented

19 Total Daily Dose 1020 Needs Human Review 1 Defaults to Y21 Dispensing Instructions 20022 Give Per (Time Unit) 20 C23 Give Rate Amount 6 C24 Give Rate Units 60 C CE25 Give Strength 2026 Give Strength Units 60 CE27 Give Indication 20028 Dispense Package Size 2029 Dispense Package Size

Unit60 CE

30 Dispense Package Method

2

31 Charge Units 10 R/O See explanation

Crown Software’s HL7 interface will accept RXE segments, rather than RXO segments, for inbound orders. The interface always sends RXE segments to vending systems.

74

The RXE segment details the pharmacy’s encoding of the order in Rx-Link. Note that ORC:7 quantity and timing has a different meaning from RXE:1 quantity and timing. The pharmacy has the authority to schedule dispense events. Consequently, the pharmacy has the responsibility to encode this scheduling information in RXE:1. The quantity and timing in ORC:7 reflects the requested schedule and does not change. RXE:1 reflects the actual schedule as encoded by the pharmacy.

Quantity/Timing reflects the schedule from Rx-Link. This may be different from the requested schedule in ORC:7. Refer to the HL7 specification for a complete description of the TQ data type.

Give Code identifies the substance to be given to the patient. For single component orders, this field will contain a coded element with the following information:

ChargeCode^TradeName^CHGCODE^DrugId^GenericName^DRUGID

For IV orders with more than one component, this field will contain the following coded element:

RXCUSIV^Custom IV^^RXCUSIV^Custom IV^

Give Amount – Minimum contains the ordered amount as encoded by the pharmacy. This field is not a duplication of the first component of the quantity/timing field.

Give Amount – Maximum contains the maximum ordered amount if applicable.

Give Units contains the units for the Give Amount fields.

Give Dosage Form For IV orders, this field contains IV. For all other orders, it contains the form of the drug from the Rx-Link Drug Master.

Provider’s Administration Instructions Not implemented

Deliver to Location If the location that the medication is to be delivered to is other than the patient’s assigned location, this field is populated.

Substitution Status Not Implemented. The default value is N indicating that no substitute was dispensed.

Dispense Amount indicates the amount of substance dispensed as coded by the pharmacy.

Dispense Units contains the units for the dispense amount.

Number of Refills Not Implemented.

75

Ordering Provider’s DEA Number (XCN data type) If the ordering provider’s DEA number is recorded in Rx-Link, this field will be populated with the DEA Number. If not, the field will be populated with the ordering provider’s Physician ID.Verifier ID (XCN data type) will be populated with the information about the pharmacist who validated the order in Rx-Link.

Prescription Number will contain the Rx-Link generated Order ID. The field is not populated if this is an order request from an order entry system.

Number Of Refills Remaining is not used.

Number Of Refills/Doses Dispensed is not used.

Date Of Most Recent Refill/Dose Dispensed is not used.

Total Daily Dose is not used.

Needs Human Review defaults to Y.

Pharmacy Dispensing Instructions is not used.

Give Per (Time Unit) identifies the time unit used to calculate the rate at which the pharmaceutical is to be administered. This is a required entry when the ordered substance is to be administered continuously at a prescribed rate. Acceptable values for this field are:

S<integer> = <integer> secondsM<integer> = <integer> minutesH<integer> = <integer> hoursD<integer> = <integer> daysW<integer> = <integer> weeksL<integer> = <integer> monthsT<integer> = at the interval and amount stated until a total of <integer>

“DOSAGE” is accumulated. Units are assumed to be theSame as the QUANTITY field

INDEF = Do indefinitely (This is the default value)

Give Rate Amount identifies the rate at which to administer the treatment.

Give Rate Units contains the units in which Requested Give Rate Amount is denominated.

For example, if 1000 ml of some substance is to be administered over 10 hours, the rate of administration would be 100 ml/hr. In this example, Requested Give Per Time should contain

76

H10, Requested Give Rate Amount should contain 100, and Requested Give Rate Units should contain ml/hr.

Give Strength this is the numeric part of the strength when RXE:2 does not reflect the strength.

Give Strength Units contains the units for Give Strength.

Give Indication identifies the condition or problem for which the drug was prescribed.

Dispense Package Size identifies the size of the package to be dispensed.

Dispense Package Size Units identifies the units associated with the Dispense Package Size.

Dispense Package Method contains the method by which the medication is dispensed. Values are taken from the following:

TR Traditional

UD Unit Dose

F Floor Stock

AD Automatic Dispensing

Charge Units This field was added by Crown Software so we could tell the vending system the number of charge units for an order ingredient so a nurse would know how many items to remove from the pocket. For example, the pocket contains 325 mg Aspirin tablets. A patient is to receive 650 mg of aspirin. The nurse would need to pull 2 aspirin tablets for the patient so 2 is reflected in the Charge Units field. This field is required when a message is sent to the vending system. It is not required when a system sends a message containing an RXE segment to Rx-Link.

77

MFI - Master File Identifier Segment

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Master File Identifier 60 R CE2 Master File Application

Identifier180 O HD

3 File-Level Event Code 3 R ID4 Entered Date/Time 26 O TS5 Effective Date/Time 26 O TS6 Response Level Code 2 R ID

Master File Identifier – This field contains a coded element data type that identifies a standard HL7 master file. Acceptable values are identified in the following table:

Value DescriptionCDM Charge description master file CMA Clinical study with phases and scheduled master fileCMB Clinical study without phases but with scheduled master fileLOC Location master fileOMA Numerical observation master fileOMB Categorical observation master fileOMC Observation batteries master fileOMD Calculated observations master filePRA Practitioner master file STF Staff master file

If the message is being sent to a vending system, this field contains "0001^FORMULARY".

Master File Application Identifier – Contains an optional code of up to 180 characters which uniquely identifies the application responsible for maintaining this file at a particular site. A group of intercommunicating applications may use more than a single instance of a master file of certain types. The particular instance of the file is identified by this field.

Crown Software does not send anything in this field.

File Level Event Code – The HL7 Specification, identifies two file level event codes for this segment in Chapter 8 as shown by the following table:

Value DescriptionREP Replace current version of this master file with the version contained in this

messageUPD Change file records as defined in the record-level event codes for each record

that follows

Vending systems look for the UPD event code so this is the only thing Crown Software will send in this field.

78

Entered Date/Time

Effective Date/Time – Date and time the change is supposed to become effective.

Response Level Code – Acceptable response codes are defined in the following table:

Value DescriptionNE Never. No application-level response neededER Error/Reject conditions only. Only MFA segments denoting errors

must be returned via the application-level acknowledgment for this message

AL Always. All MFA segments (whether denoting errors or not) must be returned via the application-level acknowledgment message

SU Success. Only MFA segments denoting success must be returned via the application-level acknowledgment for this message

Crown Software sends the NE response code in this field.

Sample MFI Segment

MFI|0001^FORMULARY||UPD|20070523085841|20070523085841|NE

MFE Master File Entry Segment

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Record-Level Event Code 3 R ID2 MFN Control ID 20 C 203 Effective Date/Time 26 O TS4 Primary Key Value 200 R Varies5 Primary Key Value Type 3 O ID

Record-Level Event Code – Defines the record-level event for the master file record identified by the MFI segment and the primary key field in this segment. Record-level event codes defined in the HL7 specification are as follows:

Value DescriptionMAD Add record to master fileMDL Delete record from master fileMUP Update record for master fileMDC Deactivate: discontinue using record in master file, but do not

delete from databaseMAC Reactivate deactivated record

Vending systems recognize MAD for both updating and adding records and MDL for deleting records. Consequently, those are the only codes used by Crown Software.

79

MFN Control ID – A number or other identifier that uniquely identifies this change to this record from the point of view of the originating system. When returned to the originating system via the MFA segment, this field allows the target system to precisely identify which change to this record is being acknowledged. It is only required if the MIF response level code requires responses at the record level (any value other than NE).

Since Crown Software sends NE in the MFI Response Level field, no value is required in this field.

Effective Date/Time –

Primary Key Value – Uniquely identifies the record of the master file (identified by the MIF segment) to be changed (as defined by the record-level event code).

Primary Key Value Type – Contains the HL7 data type used in MFE:4.

Sample MFE Segment

MFE|MAD

Fields not present in the above segment are not used by vending systems and are not sent by Crown Software.

80

ZFM Formulary Maintenance Segment

NOTE: The definition of the ZPM segment was take from the Pyxis HL7 Interface specification.

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Formulary Code 1 R A, C, or D (add, change,

delete)2 Item ID 15 R Code identifying item3 Generic Name 50 R4 Item Class 2 R5 Alternate Item ID 15 O6 Facility Code 15 R/O Optional in a single facility7 Brand Name 50 O8 Dosage Form 10 R9 Strength 12 O Numeric strength of drug10 Strength Units 10 O11 Volume 10 O Numeric volume of drug12 Volume Units 5 O13 Alternate Item ID2 30 O14 Therapeutic Class 10 O15 Cost 14 O16 Charge 10 O17 Manufacturer 35 O18 Units of Issue 10 O19 Units of Order From

Supplier10 O

20 Display Option 1 O On, Off or default21 Pick Area 25 O Storage location for this area22 Billable Flag 1 O 1 = Billable 0 = Non billable23 Medication Name 30 O For system 1000 compatibility24 Item Flags 8 O25 Box Ratio 4 O26 Pick Area Location 25 O27 Long Med Name 60 O28 Reorder Ratio 4 O29 Cost Per Unit of Issue 14 O30 Cost Per Unit of Order 14 O31 NDC Primary 11 O32 NDC Secondary 11 O33 NDC tertiary 11 O34 Drug Strength 20 O This field was added by

Crown Software since some vending system require it.

35 Cost Per Dose 14 O

81

FIELD ELEMENT NAME LENGTH REQUIRED COMMENT36 Is Diluent 1 R Contains an X if the IsDiluent

Flag is set in the RxLink Drug Master; otherwise, the field is empty

37 Location 20 O Added for Pyxis. See Note 1.

NOTES:

1. The reason for adding this is so that PYXIS can search this field to determine if a nurse should be able to access these medications. Currently the scheduled field (C-2 through C-5) , “None” and OTC (Over The Counter)) is the only thing that can set the users profile in PYXIS.  Now – if the user puts RESP or CPR or SURG in this field or any combination of those PYXIS can search this field and set the users rights so that they can only get respiratory meds (if they are a respiratory therapist) etc.

Sample ZFM SegmentZFM|A|4005930|Aripiprazole|U|5||ABILIFY|Tablet|10|mg|1|Tablet||28:16.08|||BRISTOL-MYERS SQUIBB US MD GRP |||||1|||||||||59148-0010-13|||10 MG

82

ZPM Segment

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Pocket Code 1 R See explanation2 Vending System 10 R Identifies vending system3 Station Name 10 R Vending Station Name4 Drawer Number 3 R There is a hard limit of 200

drawers. RxLink For Windows cannot handle more than this.

5 Pocket Descriptor 5 R6 Item ID 25 R/O7 Item Name 50 R8 Item Class 2 R9 EBC 8 R Expected Begin Count10 ABC 8 R Actual Begin Count11 Transaction Amount 8 R Used for Fill12 User ID 10 R13 User Name 20 R14 Witness ID 10 O15 Witness Name 20 O16 Total Count of Item In

Station8 O

17 Alternate Item ID 25 O18 Facility Code 15 R/O See explanation19 Alternate Item ID 2 30 O20 Nursing Unit 25 O21 Subdrawer 2 R There is a hard limit of 100

subdrawers per drawer. RxLink For Windows cannot handle more than this.

22 Full Count In Pocket 8 R Used for count and load23 Par Count In Pocket 8 R24 Transaction date/time 12 O25 Lot Number 30 O26 Serial Number 30 O

The ZPM segment is used by vending systems to transmit inventory information to a pharmacy system. They may be received as part of a detailed financial transaction or as an indicator of pocket activity. When used as an indicator of pocket activity, the only other segment used to construct the message containing the ZPM segment is the MSH segment.

83

Pocket Code – The pocket code is used by the vending system to identify the type of activity being communicated by the vending system. Pocket codes recognized by Crown Software’s HL7 interface are as follows:

C Pocket Count Updates the pocket countL Pocket Load Adds a new drug to a cabinet and establishes the

Initial pocket countU Pocket Unload Removes a drug from a pocketF Pocket Fill Updates the pocket count with the original count

Plus the number of items being added to the pocketE Expired Medication Not supported by Crown SoftwareB Empty Return Bin Not supported by Crown SoftwareX Cancel Transaction Not supported by Crown SoftwareV Vend Item Updates the pocket countW Waste Item Updates the pocket countR Return Item Updates the pocket count

Facility Code – This would be a unique code identifying the facility in which the vending station is located when a database supports multiple facilities. Rx-Link For Windows does not support multiple facilities so this field does not need be populated in the current implementation. Future versions of Rx-Link For Windows may support multiple facilities so this is subject to change.

Other Segments

Please NOTE that the ZAD segment is a proposed segment and is not yet implemented in Crown Software’s HL7 Interface.

The ZAD segment shown below is a custom segment created by Crown Software, Inc. to facilitate inactivating patient allergies via the HL7 interface since this capability is not facilitated in the HL7 standard.

*** IMPORTANT ***

There are hard limits as to the number of Drawers, sub-drawers, and pockets that RxLink For Windows can process. Ignoring these limits will result in vending station pocket counts not being updated to reflect accurate inventory in Floor Stock.

Maximum Drawers = 200

Maximum Sub-Drawers per Drawer = 99

Maximum Pockets per Drawer or Sub-drawer = 99

84

ZAD Segment Definition

FIELD ELEMENT NAME LENGTH REQUIRED NOTES1 Set ID 4 R2 Allergy Type 23 Allergy

Code/Mnemonic/Description60 R Coded Element

. If the allergy code or description matches an allergy that can be located in the MicroMedix database, the allergy will be changed to inactive. If an exact match cannot be made, the comment will be placed in the discussions for the patient. This is the same processing that takes place upon receipt of an AL1 Allergy segment.

This segment may not be used to toggle allergy information from active to inactive and visa versa. Once an allergy is made inactive with the ZAD segment, the only way to make the allergy active again is to send a new AL1 segment.

In processing a ZAD segment, the interface will not look for matching records in the discussions table. Any discontinuation notices appearing in the discussion table will appear on the “Missing Patient Information” report that is generated by RxLink For Windows and will have to be handled by pharmacy personnel.

85