18.29.1 Order Entry: Pharmacy/Treatment, Vaccination (99.1.4)

19 A.Order Entry: Pharmacy/Treatment, Vaccination (4A)

4

Hans BuitendijkCerner Corporation

Co-Chair:

Co-Chair:

Robert HausamHausam Consulting

Ken McCaslinAccenture

Co-Chair:

Co-Chair:Chapter Chair:

Co-Chair:
Co-Chair:	David BurgessLabCorp
	Lorraine ConstableConstable Consulting
Co-Chair:
Co-Chair:	Patrick LoydICode Solutions
	Riki MerrickVernetzt, LLC
	JD Nolen Children’s Mercy Hospital
Editor	Scott RobertsonKaiser Permanente
Sponsoring Committee:	Orders & Observations
List Server:	ord@lists.hl7.org

19.1 Chapter 4A contents (4A.1)

19.2 Purpose (4A.2)

This extension of chapter 4 was created because as of version 2.6 it had become too large to edit without great difficulty. Thus, the sections specific to pharmacy and vaccines were excised from that chapter and now comprise the content of this chapter.

19.2.1 Preface (organization of this chapter) (4A.2.1)

This chapter is organized into two major sections, Pharmacy, and Vaccine. Each section contains the trigger events, message definitions, segments and examples for the specific type of order messages. Each section about a type of order is organized into background and overview, message structure, and message segments (that are specific to the order class in question). Special discussions of the use of fields, segments or messages, and examples are included. Segments are introduced in order of occurrence in a message. A list of allowable values for a field is included in the body of the text, along with the field definition for easier reference.

Section 4A.3 to 4A.6Covers pharmacy/treatment trigger events & messages, pharmacy/treatment segments, pharmacy/treatment message examples and pharmacy/treatment message flow diagrams.

Sections 4A.7 to 4A.6Covers vaccine trigger events & message definitions, vaccine segments and vaccine message examples.

19.3 Pharmacy/Treatment Trigger Events & Messages (4A.3)

19.3.1 Usage notes for pharmacy/treatment messages (4A.3.1)

For the RDS (pharmacy/treatment dispense), RGV (pharmacy/treatment give) and RAS (pharmacy/treatment administration) messages, the placer and filler order numbers are those of the parent RDE (pharmacy/treatment encoded order) message. In these messages, the filler order number does not provide a unique identification of the instance of the pharmacy/treatment action (dispense, give or administer). To correct this problem, each of the defining segments (RXD, RXG, and RXA) has an appropriately named sub-ID field (dispense sub-ID counter, give sub-ID counter, and administration sub-ID counter). The combination of the filler order number (including its application ID component) and the appropriate sub-ID counter uniquely identifies the instance of the pharmacy/treatment action(s) present in these messages.

Although the default order control code for the RDE, RDS, RGV and RAS messages is "RE," there are cases in which the pharmacy or treatment system and the receiving system must communicate changes in state. Depending on whether the pharmacy or treatment supplier's relationship to the receiving system is that of placer or filler, the appropriate order control code may be substituted for the default value of RE. The receiving system can also use an appropriate order control code to report status back to the pharmacy or treatment system.

For example, suppose that a pharmacy or treatment system is sending RGV messages to a nursing system which will administer the medication and that the pharmacy or treatment system needs to request that several instances of a give order be discontinued. To implement this request, the RGV message may be sent with a "DC" order control code (discontinue request), and the appropriate RXG segments whose give sub-ID fields identify the instances to be discontinued. If a notification back to the pharmacy or treatment supplier is needed, the nursing system can initiate an RGV message with a "DR" order control code (discontinue as requested), and containing RXG segments whose give sub-ID fields identify the discontinued instances.

19.3.2 IV solution groups (4A.3.2)

An order for a group of IV solutions to be given sequentially can be supported in two similar ways: Parent/Child and Separate Orders. This HL7 Standard supports both methods of ordering. The method used at a particular site must be negotiated between the site institution and the various application vendors. See Chapter 2, section 2.A.53 OSD Order Sequence Definition, "Use Case 1 Cyclic placer order groups," for further details.

19.3.3 OMP - Pharmacy/Treatment Order Message (Event O09) (4A.3.3)

19.3.4 ORP - Pharmacy/Treatment Order Acknowledgment (Event O10) (4A.3.4)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

19.3.5 RDE/RRE - pharmacy/treatment encoded order message (O01/O02) (4A.3.5)

Attention: The use of RDE with the trigger of O01 and RRE with the trigger O02 is maintained for backward compatibility as of v 2.4 and is withdrawn as of v 2.7. Refer to RDE with trigger O11 and RRE with trigger O12 instead.

19.3.6 RDE - Pharmacy/Treatment Encoded Order Message (Event O11) (4A.3.6)

This message communicates the pharmacy or treatment application's encoding of the pharmacy/treatment order ,OMP, message. It may be sent as an unsolicited message to report on either a single order or multiple pharmacy/treatment orders for a patient.

The RDE/RRE message pair can also be used to communicate a refill authorization request; however, a specific trigger event has been assigned. See section 4A.3.13 "RDE - Pharmacy/Treatment Refill Authorization Request Message (Event O25)." As a site-specific variant, the original order segments (RXO, RXRs, associated RXCs, and any NTEs) may be sent optionally (for comparison).

The event O11 represents an encoding of an order. To communicate explicit dispense requests, which are different event types, the RDE^O11/RRE^O12 message pair is also used, but the event O49 is preferred. See section 4A.3.23 "RDE - Pharmacy/Treatment Dispense Request Message (Event O49)." As a site-specific variant, the original order segments (RXO, RXRs, associated RXCs, and any NTEs) may be sent optionally (for comparison).

19.3.7 RRE - Pharmacy/Treatment Encoded Order Acknowledgment (Event O12) (4A.3.7)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

19.3.8 RDS - Pharmacy/Treatment Dispense Message (Event O13) (4A.3.8)

The RDS message may be created by the pharmacy/treatment application for each instance of dispensing a drug or treatment to fill an existing order or orders. In the most common case, the RDS messages would be routed to a Nursing application or to some clinical application, which needs the data about drugs dispensed or treatments given. As a site-specific variant, the original order segments (RXO, RXE and their associated RXR/RXCs) may be sent optionally (for comparison).

The ORC must have the filler order number and the order control code RE. The RXE and associated RXCs may be present if the receiving application needs any of their data. The RXD carries the dispense data for a given issuance of medication: thus it may describe a single dose, a half-day dose, a daily dose, a refill of a prescription, etc. The RXD is not a complete record of an order. Use the RXO and RXE segments if a complete order is needed. It is a record from the pharmacy or treatment supplier to the Nursing application (or other) with drug/treatment dispense and administration instructions.

The FT1 segment is optional and repeating in order to accommodate multiple charge, benefit and pricing situations. Example use cases demonstrating zero, one and two FT1 segments follow:

In the case where the RDS message represents a dispense event that is in process (i.e., has not been received by the patient), the financial transactions associated with the dispense do not yet exist. Until the financial transactions associated with the dispense event have been completed, no FT1 segment may exist in the message.

In the case where the RDS message represents a dispense event that has been received by the patient, and thus all financial transactions have been completed, the RDS message may contain one or more FT1 segments. Examples of single and multiple FT1 segments follow.

Payment for the dispense event completed by a single payor:

MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|2006082911150700||RDS^O13^RDS_O13|...

PID|...

ORC|RE|...

RXD|1|00310-0131-10^LISINOPRIL 10MG TABLET^NDC|200607150830|100|TAB|...

FT1|1|||200607151035||PY|00310-0131-10^LISINOPRIL 10MG TABLET^NDC|||100|125.43&USD|...

Payment for the dispense event involves multiple payment sources:

MSH|^&~\|Pharm|GenHosp|CIS|GenHosp|2006082213000700||RDS^O13^RDS_O13|...

PID|...

ORC|RE|...

RXD|1|00340-0241-10^VERAPAMIL 120MG TABLET^NDC|200607200940|100|TAB|...

FT1|1|||200607211055||CD|00340024110^VERAPAMIL 120MG TABLET ^NDC|||100|55.43&USD|... (amount paid by insurance)

FT1|2|||200607211055||CP|00340024110^VERAPAMIL 120MG TABLET ^NDC|||100|5.00&USD|... (copay paid by patient)

Note: The use of RDS with the trigger of O01 and RRD with the trigger O02 is maintained for backward compatibility as of v 2.4 and is withdrawn as of v 2.7.

19.3.9 RRD - Pharmacy/Treatment Dispense Acknowledgement Message (Event O14) (4A.3.9)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

19.3.10 RGV/RRG - pharmacy/treatment give message (O01/O02) (4A.3.10)

Attention: The use of RGV with the trigger of O01 and RRG with the trigger O02 is maintained for backward compatibility as of v 2.4 and is withdrawn as of v 2.7. Refer to RGV with trigger O15 and RRG with trigger O16 instead.

19.3.11 RGV - Pharmacy/Treatment Give Message (Event O15) (4A.3.11)

When the "give" (i.e., administration) information needs to be transmitted from the pharmacy or treatment application to another application, it is done with the RGV message. The RGV message uses the RXG segment to record drug or treatment administration instructions, which is not contained in an RDS, dispense message. The RGV message may carry information about a single scheduled administration on a drug or treatment, or it may carry information about multiple administrations. If the pharmacy or treatment application (or some other application) needs to create an unambiguous MAR report where each administration is matched to a particular give date/time instruction, it may use the RGV message as described in the following way:

For each scheduled administration of the medication, the pharmacy/treatment issues either a single RGV message or a single RGV message with multiple RXG segments, one for each scheduled administration. The actual administrations (transmitted by one or more RAS messages) are matched against the scheduled ones by recording in each RXA segment the Give Sub-ID of the corresponding RXG segment. If more than one administration needs to be matched (as in the case of recording a change or rate of an IV solution) the administering application issues additional RXA segment(s) (corresponding to the same RXG segment). If no matching is needed, the Give Sub-ID of the RXA segments has the value zero (0).

When used for a scheduled administration or for the start of a continuous administration such as an IV fluid, the ORC must have the filler order number and the order control code RE.

When used for an update to a continuous administration which is currently in progress (e.g. change of rate of an IV fluid), the ORC must have the filler order number and the order control code XO. For these updates the value of RXG-1 Give Sub-ID Counter may be used to provide a unique reference (see section 4A.4.6.1).

The RXE and associated RXCs may be present if the receiving application needs any of their data. The RXG carries the scheduled administration data for either a single "give instruction" (single dose) of medication or for multiple "give instructions." The RXG is not a complete record of an order. Use the RXO and RXE segments if a complete order is needed. It is a record from the pharmacy or treatment application to the Nursing application (or other) with drug/treatment administration instructions.

19.3.12 RRG - Pharmacy/Treatment Give Acknowledgment Message (Event O16) (4A.3.12)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

19.3.13 RAS/RRA - pharmacy/treatment administration message (O01/O02) (4A.3.13)

Note: The use of RAS with the trigger of O01 and RRA with the trigger O02 is maintained for backward compatibility as of v2.4 and is withdrawn as of v2.7. Refer to RAS with trigger O17 and RRA with trigger O18 instead.

19.3.14 RAS - Pharmacy/Treatment Administration Message (Event O17) (4A.3.14)

The RAS message may 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/treatment for a given order with a single RAS message, each instance is reported by a separate (repeating) RXA segment. In addition, the administration records for a group of orders may be sent in a single message by creating repeating groups of segments at the ORC level.

In the most common case, the RAS messages would be sent from a nursing application to the pharmacy or treatment application (or to the ordering application or another clinical application), which could use the data to generate the medication administration reports. Multiple RXA segments, each corresponding to a separate administration instance for a given order, may be sent with a single ORC.

19.3.15 RRA - Pharmacy/Treatment Administration Acknowledgment Message (Event O18) (4A.3.15)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

19.3.16 RDE - Pharmacy/Treatment Refill Authorization Request Message (Event O25) (4A.3.16)

The RDE/RRE is used to communicate a refill authorization request originating with the pharmacy. This message replicates the standard RDE message with a different trigger event code to indicate the specific use case of a refill authorization request.

19.3.17 RRE - Pharmacy/Treatment Refill Authorization Request Acknowledgment (Event O26) (4A.3.17)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

19.3.18 ROR - Pharmacy/Treatment Order Response (4A.3.18)

Attention: This query/response pair was retained for backward compatibility only as of v2.4 and withdrawn as of v2.7. Please refer to Chapter 5 for detailed coverage of query/response methodology to be employed in Versions 2.4 and later.

19.3.19 RAR - Pharmacy/Treatment Administration Information (4A.3.19)

Attention:This query/response pair was retained for backward compatibility only as of v2.4 and withdrawn as of v2.7. Please refer to Chapter 5 for detailed coverage of query/response methodology to be employed in Versions 2.4 and later.

19.3.20 RDR - Pharmacy/Treatment Dispense Information (4A.3.20)

Attention: This query/response pair was retained for backward compatibility only as of v2.4 and withdrawn as of v2.7. Please refer to Chapter 5 for detailed coverage of query/response methodology to be employed in Versions 2.4 and later.

19.3.21 RER - Pharmacy/Treatment Encoded Order (4A.3.21)

Attention: This query/response pair was retained for backward compatibility only as of v2.4 and withdrawn as of v2.7. Please refer to Chapter 5 for detailed coverage of query/response methodology to be employed in Versions 2.4 and later.

19.3.22 RGR - Pharmacy/Treatment Dose Information (4A.3.22)

Attention: This query/response pair was retained for backward compatibility only as of v2.4 and withdrawn as of v2.7. Please refer to Chapter 5 for detailed coverage of query/response methodology to be employed in Versions 2.4 and later.

19.3.23 Pharmacy Query/Response Message Pair (4A.3.23)

Conformance Statement

QPD Input Parameter Specification

QPD Input Parameter Field Description and Commentary

19.3.23.1 Example (4A.3.23.0)

Example: The user wishes to know all the medications dispensed for the patient whose medical record number is "555444222111" for the period beginning 5/31/2005 and ending 5/31/2006. The following QBP message is generated.

MSH|^&~\|PCR|Gen Hosp|Pharm||200611201400-0800||QBP^Q31^QBP_Q11|ACK9901|P|2.8|

QPD|Q31^Dispense History^HL70471|Q001|555444222111^^^MPI^MR||20050531|20060531|

RCP|I|999^RD|

The pharmacy system identifies medical record number "555444222111" as belonging to Adam Everyman and locates 4 prescription dispenses for the period beginning 5/31/2005 and ending 5/31/2006 and returns the following RSP message:

MSH|^&~\|Pharm|Gen hosp|PCR||200611201400-0800||RSP^K31^RSP_K31|8858|P|2.8|

MSA|AA|ACK9901|

QAK|Q001|OK|Q31^Dispense History^HL70471|4|

QPD|Q31^Dispense History^HL70471|Q001|444-33-3333^^^MPI^MR||20050531|20060531|

PID|||444-33-3333^^^MPI^MR||Everyman^Adam||19600614|M||C|2222 Home Street ^^Anytown^US^12345||^^^^^555^5552004|

ORC|RE||89968665||||||200505121345-0700|||444-44-4444^HIPPOCRATES^HAROLD^^^^MD||^^^^^555^5551003|

RXE|1^BID^^20050529|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |120||mgm|

RXD|1|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |200505291115-0700|100|||1331665|3|

RXR|PO|

ORC|RE||89968665||||||200505291030-0700|||444-44-4444^HIPPOCRATES^HAROLD^^^^MD||^^^^^555^5551003|

RXE|1^^D100^^20070731^^^TAKE 1 TABLET DAILY --GENERIC FOR CALAN SR|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |100||180MG|TABLET SA|||G|||0|BC3126631^CHU^Y^L||213220929|0|0|19980821|

RXD|1|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |20050821|100|||213220929|0|TAKE 1 TABLET DAILY --GENERIC FOR CALAN SR|

RXR|PO|

ORC|RE||235134037||||||200509221330-0700|||444-44-4444^HIPPOCRATES^HAROLD^^^^MD||^^^^^555^5551003|

RXD|1|00172409660^BACLOFEN 10MG TABS^NDC|200509221415-0700|10|||235134037|5|AS DIRECTED|

RXR|PO|

ORC|RE||235134030||||||200510121030-0700|||222-33-4444^PUMP^PATRICK^^^^MD ||^^^^^555^5551027|

RXD|1|00054384163^THEOPHYLLINE 80MG/15ML SOLN^NDC|200510121145-0700|10|||235134030|5|AS DIRECTED|

RXR|PO|

19.3.24 RDE - Pharmacy/Treatment Dispense Request Message (Event O49) (4A.3.24)

This message communicates the request to dispense items. It may be sent as a consequence of an existing order. It may not follow the order immediately: The pharmacist receives clinical orders continuously, but may decide that the orders for dispense are sent periodically. This illustrates that there is a new event.

This message is also not required to contain the order in its entirety: for example if one RDE^O11 contains 3 medications order there are 3 dispensing locations, the pharmacist issues one RDE^O49 for each medication. Any supply aspects are handled through these new types of message, while the clinical order can be segregated from such supply constraints.

The order to dispense refers to the “clinical” order, the original RDE^O25 (or OMP^O09) by means of a parent-child hierarchy, where ORC-8 of the OXX message refers to the ORC-2 of the RDE^025 order.

19.3.25 RRE - Pharmacy/Treatment Encoded Order Acknowledgment (Event O50) (4A.3.25)

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

19.3.26 RCV - Pharmacy/Treatment Dispense Message (Event O59) (4A.3.26)

The RCV message may be created to communicate the reception of items. This message supports reception of items to fill an existing order or orders, or to stock refills. In the most common case, the RCV messages would be routed to the dispensing system that issued the RDS message. The RDS message informs of the items that have been sent, while the RCV informs about the effectively received items (thus supporting any change in quantities, status,e tc., derived from transport or from a mismatch between the actually sent items and the content of the RDS).

In typical cases, the RCV^O59 message is an “echo” of one RDS^O13, but this is not forcibly so: Since the shipment and reception are asynchronous events, and considering variants in delivery, it is expected that one RCV^OYY message is issued for each confirmation of a reception, independently of whether there was one shipment or several shipments.

The RXD segment carries the dispense data for a given reception of the received items.

The FT1 segment is optional and repeating in order to accommodate multiple charge, benefit and pricing situations. When a message of type RCV is used, the FT1 may be included in the RCV message. If the RCV^O59 message is not used by the implementation, then the RDS may contain the FT1 segment.