Rx-Link For Windows HL7 Interface Specification
[pic]
HL7 Interface Specification
Crown Software, Inc.
186 Lonely Oaks
Killeen, TX 76542
Ph. (254) 526-5364
Fax: (254) 526-8008
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 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.
HL7 User Interface 6
HL7 Interface Configuration Screen 8
HL7 Error Logs 14
Security Menu 16
Reports 16
Rx-Link HL7 Message Processing 17
ADT Events 18
DFT (Detailed Financial Transaction) Trigger Events 18
RXO (Pharmacy Order) Trigger Events 18
O01 – Order Message 18
O02 – Order Response Message 19
RAS (Pharmacy/Treatment Administration) Trigger Events 19
O01 – Order Message 19
MFN (Formulary Maintenance) Trigger Events 20
ZPM Vending Machine Pocket Messages 21
ACK Message Processing 21
ADT Transaction Processing 22
Processing of Patient Classes and Patient Types 22
Admission Transactions (A01) 22
Transfer Patient (A02) 23
Discharge Patient (A03) 23
Register Patient (A04) 23
Pre-Admit Patient (A05) 23
Transfer Outpatient To Inpatient (A06) 23
Transfer Inpatient To Outpatient (A07) 23
Update Patient Information (A08) 23
Reverse Discharge (A13) 24
Merge Patient Information (A18) 24
Change MRN (A34/A47) 25
Change Account Number (A35/A49) 25
Move Account Information/Patient Account Number (A44 25
Sample ADT Transactions 26
Admit (A01) 26
Transfer Patient (A02) 26
Discharge Patient (A03) 26
Transfer Outpatient to Inpatient (A06) 26
Transfer Inpatient to Outpatient (A07) 27
Update Patient Information (A08) 27
Sample A08 Message for Allergy Inactivation 27
Reverse Discharge (A13) 27
Merge Patient Information (A18) 28
Change Patient ID (A34/A47) 28
Change Patient Account Number (A35/A49) 28
Move Patient Account Information (A44) 28
Detailed Financial Transaction Processing 29
Override Charge Processing 30
Sample DFT Transactions 31
Sample Override Transaction 32
Order Transaction Processing 33
Identification of Ordered Substances 34
Detailed Discussion of Order Transaction Processing 35
Single Component Medication Order 41
Single Component IV Order 41
IV Orders with more than one component 41
Text Order message 41
Sample Piggyback Order 41
Pharmacy/Treatment Administration Messages 42
Medication Administration: 43
Primary IV: 43
Piggy-back IV 43
Multiple Order Administration Message 43
Multiple Administrations For a Single Order 44
Vending System Pocket Message Processing 45
Pocket Load 46
Pocket Unload 46
Pocket Fill 46
Pocket Content/Count 46
HL7 Message Segments 47
MSH Segment Definition 47
MSA Segment Definition 48
Acknowledgment Codes 48
ERR Segment Definition 48
EVN Segment Definition 49
PID Segment Definition 50
PV1 Segment Definition 51
AL1 Segment Definition 52
MRG Segment Definition 55
DG1 Segment Definition 56
FT1 Financial Transaction Segment 57
NTE Notes and Comments Segment 58
OBX Observation/Result Segment 59
ORC Common Order Segment 60
RXA Pharmacy/Treatment Administration Segment 63
RXR Pharmacy/Treatment Route Segment 68
RXO Pharmacy/Treatment Order Segment 69
RXE Pharmacy/Treatment Encoded Order Segment 74
MFI - Master File Identifier Segment 78
MFE Master File Entry Segment 79
ZFM Formulary Maintenance Segment 81
Sample ZFM Segment 82
ZPM Segment 83
Other Segments 84
ZAD Segment Definition 84
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:
[pic]
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
[pic]
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)
[pic]
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.
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.
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 or (0x0d). Many vendors choose to terminate message segments with a carriage return-linefeed combination 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.
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.
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.
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 Charge
CD Credit
PY Payment
AJ 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.
HL7 Error Logs
[pic]
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.
Double-clicking on a particular message opens up a window like the one below.
[pic]
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.
[pic]
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.
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.
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.
ADT Events
The following ADT trigger events are processed by the Crown Software HL7 Interface:
A01 – Admit a Patient
A02 – Transfer a Patient
A03 – Discharge a Patient
A04 – Register Patient (Treated as A01)
A05 – Pre-admit Patient (Treated as A01)
A06 – Transfer an outpatient to an inpatient
A07 – Transfer an inpatient to an outpatient
A08 – 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 Information
A34/A47 – Change Medical Record Number
A35/A49 – Change Account Number
A44 – 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.
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.
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/Update
MDL – 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|AL
MFI|0001^FORMULARY||UPD|20070523085841|20070523085841|NE
MFE|MAD
ZFM|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
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.
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.
ELSE
Do nothing
END IF
END 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 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)
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.
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.)
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|
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 Inactivation
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||
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||
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|
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 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 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||||||||22
FT1|2|||20020218|20020218|CG|000510547-2^TradeName^CHGCODE^185^GenericName^DRUGID ||3|1||||||||||||||||
ZPM|C|PYXISRX|UnitA|1|B|000510547-2|DrugName||||||||22
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.
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.)
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^CHGCODE
Or
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.
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|NE
MSA|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 Group
ORC|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|AL
PID|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|NE
MSA|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 Group
ORC|DR|OE1234|14667||DC|N|||20071005123648|||||||DR^Discontinued As Requested|^LHC Group
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|AL
EVN|O01|20071005123734
PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC Group
ORC|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 Group
RXE|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|1
RXR|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|AL
PID|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|NE
MSA|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 Group
ORC|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|AL
EVN|O01|20071005123433
PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC Group
ORC|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 Group
RXE|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|1
RXR|PO^Oral^HL7 Table 0162
[pic]
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|AL
EVN|O01|20071005125552
PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC Group
ORC|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.
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|AL
EVN|O01|20071005123152
PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC Group
ORC|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 Group
RXE|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|1
RXR|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|AL
EVN|O01|20071005123151
PID|1||123456^^^RXLINK^MR^LHC Group||Duck^Daffey^^^^^L||19541006|M|||^^^ ^^^H|||||||123456789^^^RXLINK^AN^LHC Group
ORC|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 Group
RXE|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|1
RXR|PO^Oral^HL7 Table 0162
[pic]
Sample Order Messages
Single Component Medication Order
MSH|^~\&|||||200210091347||ORM^O01|200411101340|P|2.3|||AL|AL
PID|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 Order
MSH|^~\&|||||200210091347||ORM^O01|200411101347|P|2.3|||AL|AL
PID|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^ML
RXR|IV
IV Orders with more than one component
MSH|^~\&|||||200210091347||ORM^O01|200411101347|P|2.3|||AL|AL
PID|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/HR
RXR|IV|LA|IV-SET01^^L
RXC|B|05177106^DEXTROSE/SODIUM CHLORIDE|1000|ml
RXC|A|05107948^POTASSIUM CHLORIDE|20|MEQ
Text Order message
MSH|^~\&|||||200210091347||ORM^O01|200411101347|P|2.3|||AL|AL
PID|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 Order
MSH|^~\&|||||200210091347||ORM^O01|200411101347|P|2.3|||AL|AL
PID|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^^L
RXC|B|05177077^DEXTROSE/SODIUM CHLORIDE|50|CC
RXC|A|05107199^CEFAZOLIN SODIUM|1|GM
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.
Sample Administration Messages
Medication Administration:
MSH|^~\&|PHARM||CROWN SOFTWARERX||200706270854|1005|RAS^O01|1005|P|2.3|1||AL|AL
EVN|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^Marilee
RXA|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|AL
EVN|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^Marilee
RXA|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|AL
EVN|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^Marilee
RXA|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|AL
EVN|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^Marilee
RXA|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^Marilee
RXA|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^Marilee
RXA|1|1|20070628220000|20070628220000|2500050^Normal Saline^CHGCODE|1|^EA|^SOL||4156356^Nurse^Sally|||1000|^ML||||||CP||
Multiple Administrations For a Single Order
MSH|^~\&|PHARM||CROWN SOFTWARERX||200706270854|1012|RAS^O01|1012|P|2.3|1||AL|AL
EVN|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^Marilee
RXA|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||
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 pocket
Messages 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
Sample Pocket Messages
Pocket Load
MSH|^~\&|VendingSystemName||RXLINK||20041029093600||ZPM|200410290001|P|2.3|||AL|AL
ZPM|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|AL
ZPM|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|AL
ZPM|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|AL
ZPM|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.
HL7 Message Segments
MSH Segment Definition
|field |element nAME |lENGTH |rEQUIRED |noTES |
|1 |Field Separator |1 |R || |
|2 |Encoding Characters |4 |R |^~\& |
|3 |Sending Application |180 | | |
|4 |Sending Facility |180 | | |
|5 |Receiving Application |180 | | |
|6 |Receiving Facility |180 | | |
|7 |Date/Time of Message |26 | | |
|8 |Security |40 | | |
|9 |Message Type |7 |R |^ |
|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.3 |
|13 |Sequence Number |15 | | |
|14 |Continuation Pointer |180 | | |
|15 |Accept Acknowledgement Type |2 | |AL – Always |
| | | | |NE – Never |
| | | | |ER – Error/reject conditions only |
| | | | |SU – Successful Completion only |
|16 |Application Acknowledgement Type |2 | |AL – Always |
| | | | |NE – Never |
| | | | |ER – Error/reject conditions only |
| | | | |SU – Successful Completion only |
|17 |Country Code |2 | | |
|18 |Character Set | | | |
|19 |Principal Language of Message |60 | | |
|20 |Alternate Character Set Handling Scheme |20 | | |
Crown Software’s HL7 interface will not recognize any other characters as field separators or encoding characters.
MSA Segment Definition
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |Acknowledgement Code |2 |R |See Acknowledgement Code Definitions |
|2 |Message Control ID |20 |R |Must be unique |
|3 |Text Message |80 |O | |
|4 |Expected Sequence Number |15 |O | |
|5 |Delayed Acknowledgment Type |1 |B | |
|6 |Error Condition |100 |O | |
Acknowledgment Codes
AA Original Mode: Application Accept
Enhanced Mode: Application acknowledgment – Accept
AE Original Mode: Application Error
Enhanced Mode: Application acknowledgment – Error
AR Original Mode: Application Reject
Enhanced Mode: Application acknowledgment – Reject
CA Enhanced Mode: Accept acknowledgment – Commit Accept
CE Enhanced Mode: Accept acknowledgment – Commit Error
CR 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 |NOTES |
|1 |Error Code and Location |80 |R | |
EVN Segment Definition
|field |element nAME |lENGTH |rEQUIRED |noTES |
|1 |Event Type Code |3 |B | |
|2 |Recorded Date/Time |26 |R | |
|3 |Date/Time Planned Event |26 | | |
|4 |Event Reason Code |3 | | |
|5 |Operator ID |60 | | |
|6 |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.
PID Segment Definition
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |Set ID |4 |R |PID |
|2 |Patient ID |20 | | |
|3 |Patient Identifier List |20 |R |Must contain the patient’s account number only|
|4 |Alternate Patient ID |20 |R |Must contain the patient’s Medical Record |
| | | | |Number |
|5 |Patient Name |48 |R | |
|6 |Mother’s Maiden Name |48 | | |
|7 |Date/Time of Birth |26 | | |
|8 |Sex |1 | |F - Female |
| | | | |M - Male |
| | | | |O - Other |
| | | | |U – Unknown |
|9 |Patient Alias |48 | | |
|10 |Race |80 | | |
|11 |Patient Address |106 | | |
|12 |County Code |4 | | |
|13 |Phone Number – Home |40 | | |
|14 |Phone Number – Business |40 | | |
|15 |Primary Language |60 | | |
|16 |Marital Status |80 | | |
|17 |Religion |80 | | |
|18 |Patient Account Number |20 | |If populated, must be the same as PID:3 |
| | | | |(patient’s account number) |
|19 |SSN Number – Patient |16 | | |
|20 |Driver’s License Number – Patient |25 | | |
|21 |Mother’s Identifier |20 | | |
|22 |Ethnic Group |80 | | |
|23 |Birth Place |60 | | |
|24 |Multiple Birth Indicator |1 | | |
|25 |Birth Order |2 | | |
|26 |Citizenship |80 | | |
|27 |Veterans Military Status |60 | | |
|28 |Nationality |80 | | |
|29 |Patient Death Date/Time |26 | | |
|30 |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.
PV1 Segment Definition
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |SET ID |4 |R |PV1 |
|2 |Patient Class |1 |R |I – Inpatient |
| | | | |(See discussion below) |
|3 |Assigned Patient Location |80 | |Unit^Room^Bed (See Note) |
|4 |Admission Type |2 | | |
|5 |Preadmit Number |20 | | |
|6 |Prior Patient Location |80 | |Unit^Room^Bed (required when |
| | | | |Patient is transferred from one bed to |
| | | | |another.) |
|7 |Attending Doctor |60 | | |
|8 |Referring Doctor |60 | | |
|9 |Consulting Doctor |60 | | |
|10 |Hospital Service |3 | | |
|11 |Temporary Location |80 | | |
|12 |Preadmit Test Indicator |2 | | |
|13 |Re-admission Indicator |2 | | |
|14 |Admit Source |3 | | |
|15 |Ambulatory Status |2 | | |
|16 |VIP Indicator |2 | | |
|17 |Admitting Doctor |60 | | |
|18 |Patient Type |2 | |(See discussion below) |
|19 |Visit Number |20 | | |
|20 |Financial Class |50 | | |
|21 |Charge Price Indicator |2 | | |
|22 |Courtesy Code |2 | | |
|23 |Credit Rating |2 | | |
|24 |Contract Code |2 | | |
|25 |Contract Effective Date |8 | | |
|26 |Contract Amount |12 | | |
|27 |Contract Period |3 | | |
|28 |Interest Code |2 | | |
|29 |Transfer to Bad Debt Code |1 | | |
|30 |Transfer to Bad Debt Date |8 | | |
|31 |Bad Debt Agency Code |10 | | |
|32 |Bad Debt Transfer Amount |12 | | |
|33 |Bad Debt Recovery Amount |12 | | |
|34 |Delete Account Indicator |1 | | |
|35 |Delete Account Date |8 | | |
|36 |Discharge Disposition |3 | | |
|37 |Discharged To Location |25 | | |
|38 |Diet Type |80 | | |
|39 |Servicing Facility |2 | | |
|40 |Bed Status |1 | | |
|41 |Account Status |2 | | |
|42 |Pending Location |80 | | |
|43 |Prior Temporary Location |80 | | |
|44 |Admit Date/time |26 | | |
|45 |Discharge Date/Time |26 | | |
|46 |Current Patient Balance |12 | | |
|47 |Total Charges |12 | | |
|48 |Total Adjustments |12 | | |
|49 |Total Payments |12 | | |
|50 |Alternate Visit ID |20 | | |
|51 |Visit Indicator |1 | | |
|52 |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 Emergency
I Inpatient
O Outpatient
P Preadmit
R Recurring
B Obstetrics
At a minimum, the admitting system must send either “I” or “O” in PV1:2.
[pic]
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. | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
AL1 Segment Definition
|field |element nAME |lENGTH |rEQUIRED |noTES |
|1 |Set ID |4 |R | |
|2 |Allergy Type |2 | | |
|3 |Allergy Code/Mnemonic/Description |60 |R |Coded Element |
|4 |Allergy Severity |2 | | |
|5 |Allergy Reaction |16 | | |
|6 |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.
MRG Segment Definition
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |Prior Patient Identifier List |20 |R |Patient Medical Record Number |
|2 |Prior Alternate Patient ID |20 | |Not Used |
|3 |Prior Patient Account Number |20 |C |Patient Account Number |
|4 |Prior Patient ID |20 |C |Patient Medical Record Number |
|5 |Prior Patient Visit Number |20 | |Not Used |
|6 |Prior Alternate Visit ID |20 | |Not Used |
|7 |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.
DG1 Segment Definition
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |SET ID |4 |R |DG1 |
|2 |Diagnosis Coding Method |2 |(B)R | |
|3 |Diagnosis Code |60 |R |Coded Element |
|4 |Diagnosis Description |40 |O | |
|5 |Diagnosis Date/Time |26 |O | |
|6 |Diagnosis Type |2 |R |A – Admitting |
| | | | |W – Working |
| | | | |F - Final |
|7 |Major Diagnostic Category |60 | | |
|8 |Diagnostic Related Group |60 | | |
|9 |DRG Approval Indicator |2 | | |
|10 |DRG Group Review Code |2 | | |
|11 |Outlier Type |60 | | |
|12 |Outlier Days |3 | | |
|13 |Outlier Cost |12 | | |
|14 |Grouper Version And Type |4 | | |
|15 |Diagnosis Priority |2 | | |
|16 |Diagnosing Clinician |60 | | |
|17 |Diagnosis Classification |3 | | |
|18 |Confidential Indicator |1 | | |
|19 |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.
FT1 Financial Transaction Segment
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |Set ID |4 |R | |
|2 |Transaction ID |12 | | |
|3 |Transaction Batch ID |10 | |If the HL7 is configured to send batch |
| | | | |charges, we send the batch ID here |
|4 |Transaction Date |26 |R | |
|5 |Transaction Posting Date |26 | | |
|6 |Transaction Type |8 |R |Use HL7 Configuration to set these values |
|7 |Transaction Code |80 |R |ChargeCode^Drug Name^CHGCODE^Drug |
| | | | |Id^DrugName^DRUGID |
|8 |Transaction Description |40 | | |
|9 |Transaction Description – Alt |40 | | |
|10 |Transaction Quantity |6 |R | |
|11 |Transaction Amount – Extended |12 | | |
|12 |Transaction Amount – Unit |12 | | |
|13 |Department Code |60 | | |
|14 |Insurance Plan ID |60 | | |
|15 |Insurance Amount |12 | | |
|16 |Assigned Patient Location |80 | | |
|17 |Fee Schedule |1 | | |
|18 |Patient Type |2 | | |
|19 |Diagnosis Code – FT1 |60 | | |
|20 |Performed By Code |120 | | |
|21 |Ordered By Code |120 | | |
|22 |Unit Cost |12 | | |
|23 |Filler Order Number |22 |R |If the charge is from a vending system |
|24 |Entered By Code |120 | | |
|25 |Procedure Code |80 | | |
|26 |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.
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 |noTES |
|1 |Set ID |4 | | |
|2 |Source Of Comment |8 | | |
|3 |Comment |64K | | |
|4 |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.
OBX Observation/Result Segment
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |SET ID |10 |R | |
|2 |Value Type |3 | | |
|3 |Observation Identifier |590 | |Coded Element |
|4 |Observation Sub-ID |20 | | |
|5 |Observation Value |65536 | |Coded Element |
|6 |Units |60 | |Coded Element |
|7 |References Range |60 | | |
|8 |Abnormal Flags |5 | | |
|9 |Probability |5 | | |
|10 |Nature Of Abnormal Test |2 | | |
|11 |Observation Result Status |1 | | |
|12 |Date Last Observed Normal Values |26 | | |
|13 |User Defined Access Checks |20 | | |
|14 |Date/Time of Observation |26 | | |
|15 |Producer’s ID |60 | | |
|16 |Responsible Observer |80 | | |
|17 |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.1
Patient 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.
ORC Common Order Segment
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |Order Control |2 |R | |
|2 |Placer Order Number |22 |R | |
|3 |Filler Order Number |22 |C | |
|4 |Placer Group Number |22 | | |
|5 |Order Status |2 |C | |
|6 |Response Flag |1 |C | |
|7 |Quantity and Timing |200 |R |HL7 TQ Data Type |
|8 |Parent |200 | | |
|9 |Date/Time of Transaction |26 |R | |
|10 |Entered By |120 |R |HL7 XCN Data Type |
|11 |Verified By |120 |C |HL7 XCN Data Type |
|12 |Ordering Provider |120 |R |HL7 XCN Data Type |
|13 |Enterer’s Location |80 |C |HL7 PL Data Type |
|14 |Call Back Phone Number |40 |C | |
|15 |Order Effective Date/Time |26 | | |
|16 |Order Control Code Reason |200 | | |
|17 |Entering Organization |60 | | |
|18 |Entering Device |60 | | |
|19 |Action By |120 | | |
|20 |Advanced Beneficiary Notice Code |40 | | |
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 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:
HL7
Value Event Description Comment
NW O01 New Order
OK O02 Order Accepted
UA O02 Unable To Accept Order
CA O01 Cancel Order Request Treated as DC
DC O01 Discontinue Order Request
OD O01 Order Discontinued Discontinued In Rx-Link
DR O02 Discontinued As Requested
RE O01 Observations To Follow Use to report administrations
SC O01 Status Changed Pharmacy coded order
UD O02 Unable To Discontinue
XO O01 Change Order Request Used to renew orders
XX O01 Order Change, Unsol. Order was changed in Rx-Link
UX O02 Unable To Change
XR 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.
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.
RXA Pharmacy/Treatment Administration Segment
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |Give Sub-ID Counter | |R | |
|2 |Administration Sub-ID Counter | |R | |
|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 Form |60 |O |^Dosage Form^ |
|9 |Administration Notes |200 |O |^Notes^ |
|10 |Administering Provider |200 |R |EmployeeID^LastName^FirstName |
|11 |Administered At Location |200 |O |Crown Software will not use this |
|12 |Administered Per |20 |C | |
|13 |Administered Strength | |O | |
|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 this |
|20 |Completion Status |2 |R |CP – Complete |
| | | | |RE – Refused |
| | | | |NA – Not Administered |
| | | | |PA – Partially Administered |
|21 |Action Code – RXA |2 |O |Crown Software will not use this |
|22 |System Entry Date/Time |26 |R | |
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.
Substance Lot Number – Not used
Substance 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 – Complete
RE – Refused
NA – Not Administered
PA – Partially Administered
Action Code – Not used
System Entry Date/Time – Required. Reflects the time the administration record was actually entered into the administering system.
RXC Pharmacy/Treatment Component Order Segment
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |RX Component Type |1 |R |B – Base or A – Additive |
|2 |Component Code |100 |R |Coded Element |
|3 |Component Amount |20 |R | |
|4 |Component Units |60 |R |Coded Element |
|5 |Component Strength |20 | | |
|6 |Component Strength Units |60 | |Coded Element |
|7 |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
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.
RXR Pharmacy/Treatment Route Segment
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |Route |60 |R |Coded Element |
|2 |Site |60 | |Coded Element |
|3 |Administration Device |60 | |Coded Element |
|4 |Administration Method |60 | |Coded Element |
|5 |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 Description
AP Apply Externally B Buccal DT Dental
EP Epidural ET Endotrachial Tube GTT Gastronomy Tube
GU GU Irrigant IA Intra-arterial IB Intrabursal
IC Intracardiac ICV Intracervical (Uterus) ID Intradermal
IH Inhalation IHA Intrahepatic IM Intramuscular
IMR Immerse(Soak) Body IN Intranasal IO Intraocular
IP Intraperitoneal IS Intrasynovial IT Intrathecal
IU Intrauterine IV Intravenous MM Mucous
MTH Mouth/Throat NA Unknown/Not Applicable NG Nasogastric
NP Nasal Prongs NS Nasal NT Nasotrachial Tube
OP Ophthalmic OT Otic OTH Other/Miscellaneous
PF Perfusion PO Oral PR Rectal
RM Rebreather Mask SC Subcutaneous SD Soaked Dressing
SL Sublingual TD Transdermal TL Translingual
TP Topical TRA Tracheostomy UR Urethral
VG Vaginal VM Ventimask WND Wound
RXO Pharmacy/Treatment Order Segment
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |Requested Give Code |100 |R |Coded Element |
|2 |Requested Give Amount Minimum |20 |R | |
|3 |Requested Give Amount Maximum |20 | | |
|4 |Requested Give Units |60 |R |Coded Element |
|5 |Requested Dosage From |60 |R |Coded Element |
|6 |Provider’s Pharmacy Treatment |200 | |Coded Element |
| |Instructions | | | |
|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 |1 | | |
|10 |Requested Dispense Code |100 | |Coded Element |
|11 |Requested Dispense Amount |20 | | |
|12 |Requested Dispense Units |60 | |Coded Element |
|13 |Number Of Refills |3 | | |
|14 |Ordering Provider’s DEA Number |60 | |XCN |
|15 |Verifier ID |60 | |XCN |
|16 |Needs Human Review |1 | | |
|17 |Requested Give Per (Time Unit) |20 | | |
|18 |Requested Give Strength |20 | | |
|19 |Requested Give Strength Units |60 | |Coded Element |
|20 |Indication |200 | |Coded Element |
|21 |Requested Give Rate Amount |6 | | |
|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.
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
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 substitutions
T 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.
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 = seconds
M = minutes
H = hours
D = days
W = weeks
L = 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.
Total Daily Dose contains the total daily dose for this particular pharmaceutical as expressed in terms of actual dispense units.
RXE Pharmacy/Treatment Encoded Order Segment
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |Quantity/Timing |200 |R |TQ |
|2 |Give Code |100 |R |CE |
|3 |Give Amount – Minimum |20 |R | |
|4 |Give Amount – Maximum |20 | | |
|5 |Give Units |60 |R |CE |
|6 |Give Dosage Form |60 | |CE |
|7 |Provider’s Administration Instructions |200 | | |
|8 |Deliver To Location |200 | | |
|9 |Substitution Status |1 | | |
|10 |Dispense Amount |20 | | |
|11 |Dispense Units |60 | |CE |
|12 |Number Of Refills |3 | |Not Implemented |
|13 |Ordering Provider’s DEA Number |60 | |XCN |
|14 |Pharmacist Verifier ID |60 | |XCN |
|15 |Prescription Number |20 | |Rx-Link generated Order Number |
|16 |Refills Remaining |20 | |Not Implemented |
|17 |Refills/Doses Dispensed |20 | |Not Implemented |
|18 |Date of Most Recent Refill or Dose |26 | |Not Implemented |
| |Dispensed | | | |
|19 |Total Daily Dose |10 | | |
|20 |Needs Human Review |1 | |Defaults to Y |
|21 |Dispensing Instructions |200 | | |
|22 |Give Per (Time Unit) |20 |C | |
|23 |Give Rate Amount |6 |C | |
|24 |Give Rate Units |60 |C |CE |
|25 |Give Strength |20 | | |
|26 |Give Strength Units |60 | |CE |
|27 |Give Indication |200 | | |
|28 |Dispense Package Size |20 | | |
|29 |Dispense Package Size Unit |60 | |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.
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.
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 = seconds
M = minutes
H = hours
D = days
W = weeks
L = months
T = at the interval and amount stated until a total of
“DOSAGE” is accumulated. Units are assumed to be the
Same 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 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.
MFI - Master File Identifier Segment
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |Master File Identifier |60 |R |CE |
|2 |Master File Application Identifier |180 |O |HD |
|3 |File-Level Event Code |3 |R |ID |
|4 |Entered Date/Time |26 |O |TS |
|5 |Effective Date/Time |26 |O |TS |
|6 |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 |Description |
|CDM |Charge description master file |
|CMA |Clinical study with phases and scheduled master file |
|CMB |Clinical study without phases but with scheduled master file |
|LOC |Location master file |
|OMA |Numerical observation master file |
|OMB |Categorical observation master file |
|OMC |Observation batteries master file |
|OMD |Calculated observations master file |
|PRA |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 |Description |
|REP |Replace current version of this master file with the version contained in this |
| |message |
|UPD |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.
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 |Description |
|NE |Never. No application-level response needed |
|ER |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 |NOTES |
|1 |Record-Level Event Code |3 |R |ID |
|2 |MFN Control ID |20 |C |20 |
|3 |Effective Date/Time |26 |O |TS |
|4 |Primary Key Value |200 |R |Varies |
|5 |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 |Description |
|MAD |Add record to master file |
|MDL |Delete record from master file |
|MUP |Update record for master file |
|MDC |Deactivate: discontinue using record in master file, but do not delete from database |
|MAC |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.
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.
ZFM Formulary Maintenance Segment
NOTE: The definition of the ZPM segment was take from the Pyxis HL7 Interface specification.
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |Formulary Code |1 |R |A, C, or D (add, change, delete) |
|2 |Item ID |15 |R |Code identifying item |
|3 |Generic Name |50 |R | |
|4 |Item Class |2 |R | |
|5 |Alternate Item ID |15 |O | |
|6 |Facility Code |15 |R/O |Optional in a single facility |
|7 |Brand Name |50 |O | |
|8 |Dosage Form |10 |R | |
|9 |Strength |12 |O |Numeric strength of drug |
|10 |Strength Units |10 |O | |
|11 |Volume |10 |O |Numeric volume of drug |
|12 |Volume Units |5 |O | |
|13 |Alternate Item ID2 |30 |O | |
|14 |Therapeutic Class |10 |O | |
|15 |Cost |14 |O | |
|16 |Charge |10 |O | |
|17 |Manufacturer |35 |O | |
|18 |Units of Issue |10 |O | |
|19 |Units of Order From Supplier |10 |O | |
|20 |Display Option |1 |O |On, Off or default |
|21 |Pick Area |25 |O |Storage location for this area |
|22 |Billable Flag |1 |O |1 = Billable 0 = Non billable |
|23 |Medication Name |30 |O |For system 1000 compatibility |
|24 |Item Flags |8 |O | |
|25 |Box Ratio |4 |O | |
|26 |Pick Area Location |25 |O | |
|27 |Long Med Name |60 |O | |
|28 |Reorder Ratio |4 |O | |
|29 |Cost Per Unit of Issue |14 |O | |
|30 |Cost Per Unit of Order |14 |O | |
|31 |NDC Primary |11 |O | |
|32 |NDC Secondary |11 |O | |
|33 |NDC tertiary |11 |O | |
|34 |Drug Strength |20 |O |This field was added by Crown Software since |
| | | | |some vending system require it. |
|35 |Cost Per Dose |14 |O | |
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |COMMENT |
|36 |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 Segment
ZFM|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
ZPM Segment
|FIELD |ELEMENT NAME |LENGTH |REQUIRED |NOTES |
|1 |Pocket Code |1 |R |See explanation |
|2 |Vending System |10 |R |Identifies vending system |
|3 |Station Name |10 |R |Vending Station Name |
|4 |Drawer Number |3 |R |There is a hard limit of 200 drawers. RxLink |
| | | | |For Windows cannot handle more than this. |
|5 |Pocket Descriptor |5 |R | |
|6 |Item ID |25 |R/O | |
|7 |Item Name |50 |R | |
|8 |Item Class |2 |R | |
|9 |EBC |8 |R |Expected Begin Count |
|10 |ABC |8 |R |Actual Begin Count |
|11 |Transaction Amount |8 |R |Used for Fill |
|12 |User ID |10 |R | |
|13 |User Name |20 |R | |
|14 |Witness ID |10 |O | |
|15 |Witness Name |20 |O | |
|16 |Total Count of Item In Station |8 |O | |
|17 |Alternate Item ID |25 |O | |
|18 |Facility Code |15 |R/O |See explanation |
|19 |Alternate Item ID 2 |30 |O | |
|20 |Nursing Unit |25 |O | |
|21 |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 load |
|23 |Par Count In Pocket |8 |R | |
|24 |Transaction date/time |12 |O | |
|25 |Lot Number |30 |O | |
|26 |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.
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 count
L Pocket Load Adds a new drug to a cabinet and establishes the
Initial pocket count
U Pocket Unload Removes a drug from a pocket
F Pocket Fill Updates the pocket count with the original count
Plus the number of items being added to the pocket
E Expired Medication Not supported by Crown Software
B Empty Return Bin Not supported by Crown Software
X Cancel Transaction Not supported by Crown Software
V Vend Item Updates the pocket count
W Waste Item Updates the pocket count
R 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
ZAD Segment Definition
|field |element nAME |lENGTH |rEQUIRED |noTES |
|1 |Set ID |4 |R | |
|2 |Allergy Type |2 | | |
|3 |Allergy Code/Mnemonic/Description |60 |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.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- references for volume i of tobias and johnston veterinary
- department of veterans affairs inpatient medications
- med list yola
- ชื่อยา ความแรง
- laboratory va hdr hl7 interface specification
- capital health nova scotia
- neonatal intensive care drug manual
- onscreen editor template version 2 5
- duke university medical center
- the use of gmdn codes for ivd medical devices in australia
Related searches
- windows gadgets for windows 10 64 bit
- download link for onenote 2016
- windows gadgets for windows 7 64 bit
- windows 7 gadgets for windows 10
- windows gadgets for windows 7
- windows 7 calculator for windows 10
- rx coupons for prescriptions
- download windows update troubleshooter for windows 10
- best rx cards for uninsured
- rx discounts for seniors
- rx drops for pink eye
- class link for polk county