Technical Framework Supplement Hospital Medication Workflow

Integrating the Healthcare Enterprise

5 IHE Pharmacy Technical Framework Supplement

10 Hospital Medication Workflow (HMW)

15 Trial Implementation

20 Date: September 27, 2012 Author: José Costa Teixeira, Orlando Rodrigues, Hugo Santos, Marc Robberecht Email: [email protected]

Foreword 25 This is a supplement to the forthcoming IHE Pharmacy Technical Framework. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks. This supplement is submitted for Trial Implementation as of September 27, 2012 and will be available for testing at subsequent IHE Connectathons. The supplement may be amended based 30 on the results of testing. Following successful testing it will be incorporated into the forthcoming Pharmacy Technical Framework. Comments are invited and may be submitted at http://www.ihe.net/pharmacy/pharmacycomments.cfm or by email to [email protected]. This supplement introduces a new forthcoming technical framework and where indicated amends text by addition (bold underline) or removal (bold strikethrough), as well as addition of large 35 new sections introduced by editor’s instructions to “add new text” or similar, which for readability are not bolded or underlined. “Boxed” instructions like the sample below indicate to the Volume Editor how to integrate the relevant section(s) into the relevant Technical Framework volume:

40 Replace Section X.X by the following:

General information about IHE can be found at: www.ihe.net Information about the IHE Pharmacy domain can be found at: http://www.ihe.net/Domains/index.cfm 45 Information about the structure of IHE Technical Frameworks and Supplements can be found at: http://www.ihe.net/About/process.cfm and http://www.ihe.net/profiles/index.cfm The current version of IHE Technical Frameworks can be found at: http://www.ihe.net/Technical_Framework/index.cfm

CONTENTS

INTRODUCTION ...... 6 PROFILE ABSTRACT ...... 6 55 OPEN ISSUES...... 6 CLOSED ISSUES...... 8 VOLUME 1 – INTEGRATION PROFILES ...... 12 1.N COPYRIGHT PERMISSION ...... 12 2.1 DEPENDENCIES AMONG INTEGRATION PROFILES ...... 12 60 2.7 HISTORY OF ANNUAL CHANGES ...... 12 3 INTEGRATION PROFILES OVERVIEW ...... 13 3.1 PHARMACY INTEROPERABILITY MODEL ...... 13 4 INTRA-HOSPITAL WORKFLOW INTEGRATION PROFILE ...... 14 4.1 ACTORS/ TRANSACTIONS ...... 14 65 4.2 INTRA-HOSPITAL WORKFLOW INTEGRATION PROFILE OPTIONS ...... 15 4.2.1 Option: Advance Prescription Notification ...... 16 4.3 INTRA-HOSPITAL WORKFLOW PROCESS FLOW ...... 16 4.3.1 Scope...... 16 4.3.2 Workflow ...... 18 70 4.4 PHARMACY MESSAGING CONTENT ...... 20 4.4.1 Common Data ...... 23 4.4.2 Prescription Order ...... 24 4.4.3 Pharmacy Validated Order ...... 25 4.4.4 Medication Preparation Report ...... 26 75 4.4.5 Administration Report ...... 27 4.5 ORDER STATUS MANAGEMENT...... 28 4.5.1 Prescription, Validation, Dispense and Administration Status ...... 28 5 CONVENTIONS ...... 31 5.1 TECHNICAL FRAMEWORK CROSS-REFERENCES...... 31 80 5.2 THE GENERIC IHE TRANSACTION MODEL ...... 31 5.3 HL7 PROFILING CONVENTIONS...... 32 5.3.1 Static Definition - Message Level ...... 32 5.3.2 Static Definition - Segment Level...... 34 5.4 HL7 IMPLEMENTATION NOTES ...... 34 85 5.4.1 Network Guidelines ...... 34 5.4.2 Message Granularity ...... 34 5.4.3 Empty Fields ...... 35 5.4.4 Acknowledgement Modes ...... 35 5.4.5 IHE Pharmacy Technical Framework Acknowledgement Policies ...... 35 90 5.4.6 HL7 Data Types ...... 36 5.4.7 Scenario without a Pharmaceutical Adviser ...... 39 VOLUME 2 - TRANSACTIONS ...... 42 5.5 PRESCRIPTION ORDER – PHARM-H1 ...... 42 5.5.1 Scope...... 42 95 5.5.2 Use Case Roles ...... 42

5.5.3 Referenced Standard ...... 43 5.5.4 Interaction Diagram ...... 43 5.5.5 Security Considerations ...... 50 5.5.6 Security Audit Considerations ...... 50 100 5.5.7 Actor Specific Security Considerations ...... 50 5.5.8 Message Static Definitions ...... 51 5.6 VALIDATED ORDER – PHARM-H2 ...... 53 5.6.1 Scope...... 53 5.6.2 Use Case Roles ...... 53 105 5.6.3 Referenced Standard ...... 53 5.6.4 Interaction Diagram ...... 54 5.6.5 Security Considerations ...... 63 5.6.6 Message Static Definitions ...... 64 5.7 MEDICATION PREPARATION REPORT – PHARM-H3 ...... 67 110 5.7.1 Scope...... 67 5.7.2 Use Case Roles ...... 67 5.7.3 Referenced Standard ...... 68 5.7.4 Interaction Diagram ...... 68 5.7.5 Message Static Definitions ...... 72 115 5.8 ADMINISTRATION REPORT – PHARM-H4 ...... 75 5.8.1 Scope...... 75 5.8.2 Use Case Roles ...... 75 5.8.3 Referenced Standard ...... 76 5.8.4 Interaction Diagram ...... 77 120 5.8.5 Security Considerations ...... 80 5.8.6 Message Static Definitions ...... 81 5.9 ADVANCE PRESCRIPTION NOTIFICATION PHARM-H5 ...... 83 5.9.1 Scope...... 83 5.9.2 Use Case Roles ...... 83 125 5.9.3 Referenced Standard ...... 84 5.9.4 Interaction Diagram ...... 84 5.9.5 Security Considerations ...... 85 5.9.6 Message Static Definitions ...... 85 5.10 VALIDATED ORDER CONFIRMATION PHARM-H6 ...... 86 130 5.10.1 Scope ...... 86 5.10.2 Use Case Roles ...... 86 5.10.3 Referenced Standard ...... 86 5.10.4 Interaction Diagram ...... 87 5.10.5 Security Considerations ...... 88 135 5.10.6 Message Static Definitions ...... 88 5.11 EXCEPTIONAL CASES ...... 89 5.11.1 Cancel Prescription in advanced workflow ...... 89 5.11.2 Cancel Validation in advanced workflow ...... 92 APPENDIX A - COMMON HL7 MESSAGE SEGMENTS FOR IHE HMW TF ...... 96 140 A.1 MSH - MESSAGE HEADER SEGMENT ...... 96 A.2 NTE - NOTES AND COMMENT SEGMENT ...... 100 A.3 PID - PATIENT IDENTIFICATION SEGMENT ...... 102 A.4 PV1 - PATIENT VISIT SEGMENT ...... 108 A.5 ORC COMMON ORDER SEGMENT ...... 110 145 A.6 TQ1 - TIMING QUANTITY SEGMENT ...... 119 A.7 TQ2 - TIMING/QUANTITY RELATIONSHIP ...... 122 A.8 RXO - PHARMACY/TREATMENT ORDER SEGMENT ...... 122 ______4 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

A.9 RXR - PHARMACY/TREATMENT ROUTE SEGMENT ...... 126 A.10 RXC - PHARMACY/TREATMENT COMPONENT ORDER SEGMENT ...... 128 150 A.11 RXE - PHARMACY/TREATMENT ENCODED ORDER SEGMENT ...... 129 A.12 OBX - OBSERVATION/RESULT SEGMENT ...... 134 A.13 RXG - PHARMACY/TREATMENT GIVE SEGMENT ...... 138 A.14 RXA - PHARMACY/TREATMENT ADMINISTRATION SEGMENT ...... 143 A.15 AL1 - PATIENT ALLERGY INFORMATION SEGMENT ...... 147 155 A.16 IN1 - INSURANCE SEGMENT ...... 148 A.17 IN2 - INSURANCE ADDITIONAL INFORMATION SEGMENT ...... 149 A.18 IN3 - INSURANCE ADDITIONAL INFORMATION, CERTIFICATION SEGMENT ...... 151

160

Introduction This supplement is written for Trial Implementation. It is written as a first version of the IHE Pharmacy – Hospital Medication Workflow. This document is a detailed description of the 165 generic implementation structure defined in the Common Parts document1.

Profile Abstract This Profile describes the interoperability and the transactions present in a typical hospital workflow concerning the prescription, dispensing, distribution and administration of medication. It describes the transactions between the Prescription Placer, the Pharmaceutical Adviser, the 170 Medication Dispenser, and the Medication Administration Informer to establish an end-to-end operational workflow.

Open Issues 1. Prescription ID vs. Ordering session ID - ORC-4 • IHE will use the notion of "physician ordering session ID" (or anything similar) as 175 an order group, not only the prescription. • IHE recommends that each implementation chooses the meaning of that ID (it's the prescription number, or the order session, or...) and uses that consistently across the flow. • If "order session" and "prescription" have different meanings, and both must be 180 used in an implementation, IHE currently supports only one of these concepts within the Hospital Medication Workflow

2. Profession and specialty of Health Care Practitioners: Decided to abandon the Profession as a mandatory field in the messages. 185 Previous status: The profession of a prescribing physician was to be supported in ORC-12-21 – Professional prefix. Rationale: This information was meant to be for display purposes only, as specified in the XCN data type definition. The use of ORC-21 – Ordering Facility Name – which is a repeatable field, can convey 190 information about the specialty of the prescription placer.

1 This document is part of the IHE Pharmacy domain and can be obtained from the IHE web site. ______6 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

Reason for change: In implementations where ORC-12-21 is used for other specific purposes, additional details of the profession cannot be sent in ORC-12-21. The same applies for RXE-14 (for the 195 pharmacist), RXA-10 Profession (nurse).

IHE_Pharmacy acknowledged the functional need for this field, but this field may be present in the applications without the need to convey it in a message, in intra-institutional applications: 200 Example: Certain drugs are only available for prescription by certain specialties – this is personnel metadata, and does not need to be in a prescription message, only needs to be in the system upon the creation of the prescription. 205 When applications are unable to filter this list of available drugs, or the message is to be sent across sites where the rules may change, the pharmacist may indeed need to consult the profession of the prescriber. In this case, the personnel metadata may also be available without being conveyed in the message. Since there may be no guarantee of personnel data synchronicity between the 2 systems, this 210 item must be addressed when IHE covers additional scenarios

3. Dispense and Preparation of Medication: In the current scope of this profile, the medication dispense had to include all the steps before administration, and therefore the dispense (assigning medication to a patient) and 215 preparation (assigning medication to an expected administration event) were considered as part of the “Medication Dispense” class of actions. The designation of the messages currently refers to the “dispenser” that “prepares” medication. This inconsistency is to be addressed when, in later editions of this profile, the Dispense and Preparation/Give are clearly distinguished. In practical terms, this means that the concept of Dispense, which is 220 expected to be used in many current implementations (RDS message), is left out of the scope, and the “dispense” actions that are indicated in this document are including preparation, so the implementations that do not have a concept of preparation will not have any impact due to this.

225 Closed Issues 1. HL7 version - The preferred version for adoption of this profile is 2.6, for current scope (without supply chain) only 2.5 is needed.

2. “Medication Availability”  “Dispense Report ” 230 3. Definition: For the purpose of IHE – Hospital Medication Workflow, Dispense is reserved for the assignment of a medication unit to a patient. This means that [Medication Dispenser] = Pharmacy or Ward, whoever is responsible for delivering/assigning medication to a specific patient – i.e., the first time in the circuit that 235 the medication receives a patient name. This means that there are stock movements before and after the dispense, but the dispense is a unique defining moment. After this, there is a step of assigning a medication to a specific planned administration, an in the current scope this is the information that is sent from the dispenser to the administration informer as the Medication Preparation Report 240 4. When transmitting a code (e.g., - and especially- in the case of the Product Code), the identification of the coding system must be transmitted, including the version, if available: e.g., for a particular medication, the product code (e.g., 90000212) must be transmitted, but also the name of the coding systems to ensure that the data consistency 245 across systems can be ensured. For example, in data type CWE, the component Name of Coding System. These codes must be agreed upon for each specific implementation. This may be related to the need for referentials or metadata.

5. Each prescription item (prescription line) is associated with an ORC segment. ORC-2 250 should be different for each prescription line. In case a prescription line is replaced by another, ORC-2 of the new order line is also different from the replaced order line.

6. When an order is to be replaced by another, the mechanism to be used is as stated in HL7 v2.5, 4.5.1.1.1 d). For each order line to be replaced, use an ORC-1-order control value of 255 RP (from placer) or RU (by Pharmaceutical Advisor, Dispenser, or Administration Informer). The ORC segment may be followed by its original order detail segment. These ORC segments (with RP or RU) must be followed by an ORC segment with an ORC-1-order control value of RO (indicating the replacement order). The ORC with the RO value shall be followed by an order detail segment if needed. This is not the same as 260 for example the pharmacy replacing the quantities or products, as in this case the RXO remains the same, but the RXE will add the products recommended by the pharmacy.

(abandoned alternative – always use DC + NW) – reason for abandoning – the use of DC / NW remains supported, meaning that an application that sends DC + NW will not stop working – Use of DC = NW will not be interpreted by an IHE-compliant as a strict 265 replacement, but a discontinuation and a new order.)

7. When an order is to be replaced by another, only the changed order line needs to be sent. Abandoned alternative – send the complete prescription again. It will be up to the applications to keep track of the complete prescription, even if messages send only 270 partial data.

8. In a perfusion administration, an RAS message is to be sent at any time there is a change in the administration status – at the beginning, at the change of the components, and at the end of the administration. 275 9. Since the nurse can also accumulate functions to dispense medication, in case where a nurse is the dispenser, and the actions dispense+administration are tightly associated, the system must 1. Set the order status to Dispensed 280 2. Optionally, be able to additionally trigger transaction PHARM-H3 (Dispense, Message RGV) to the Pharmaceutical Advisor and to the Prescription Placer. The RGV message is Optional because the dispenser being the administering nurse, and the dispense being associated with the act of administration, the RAS message contains the same information expected by the other actors. 285 10. Substances and product codes: It is assumed that association between prescribed substance or product, and the corresponding dispensed/administered product can be done by the actors as needed by the implementation. The prescription placer can use RXO segment indicating a product or 290 substance ID in RXO-1, or simply provide a text indication in RXO-6. If RXO-1 is provided, it is assumed that the receiving applications will be able to understand the code provided and associate it with the products as needed. Examples: • The doctor prescribes a substance in RXO-1, and the pharmacist associates a product with that order in RXE-2. 295 • The doctor prescribes a substance X (Paracetamol) in RXO-1, and for example, due to tends of offers for drugs, the Pharmacists has had to change across the hospital the reference of substance “Paracetamol“ by product “Dafalgan”. But in all the transactions the code X for dafalgan is used.

• It is also acceptable for the Prescription to be non-encoded (free text) , which requires that 300 the receiving application can determine the products for this.

11. Prescription status management: ORC-5 is stating the prescription status. Details of dispense, administration and validation are orthogonal to the prescription state and between themselves. ORC-25 will be used to convey detailed status of these activities. 305 12. Encoding [3 per day]  [1 at 7h, one at 15h, one at 23h] is to be done by possibly any of the actors, or a set of them.

13. The Pharmaceutical advice can be added to a prescription. Only the final validation sets 310 the validated status to complete in ORC-25.

14. Validation information for all the prescription (concerning the complete set of prescription lines) is sent in the NTE segment after RXE, and the ORC-25 is updated to “Prescription Validation complete”. 315 15. Message type for Medication Dispensed (Medication Availability) is RGV. This message is sent at the point that the medication is associated with a patient.

16. Administrations “to no one” for resupply purposes are not in scope, as they will be 320 supply-chain related messages.

17. Deletion of data Chosen Option: In the IHE Hospital Medication Workflow, handling of a null value – indicated by two 325 double-quotes between the delimiters (i.e., |""|) is done by agreement on the implementations – at this point, IHE Pharmacy – Hospital Medication Workflow – does not impose constraints or recommendations at this time. Please refer to HL7 section 2.10.4.1 for deleting of data. Abandoned alternative: 330 In the IHE Hospital Medication Workflow, a null value for a field means that all components of the field are to be nullified. To nullify only one of the components, the separators before the other components must be specified, so that it is clear that they are deliberately left empty.

A null component followed by empty components, – e.g., when removing the Order Parent 335 Placer Assigned Identifier, ORC-8.1 is null and ORC-8-2, is to be coded by leaving 8.2.1 blank and placing double quotes in ORC-8., i.e., ORC|...|...|...|...| ...|“”^|...

340 18. Diagnosis can be in RXE-27 and RXG-22. If RXO-20 is present, these fields will have the same value.

19. IN1 segment is only available in v2.6 – IHE Pharmacy uses IN1 for insurance data Implementations are free to pre-adopt IN1 in v2.5, but IHE does not use other specific 345 fields to convey Insurance information – if Insurance data is to be sent, it must be in the IN1 segments, requiring forward v2.6 compatibility.

20. Description of Order Status is detailed in ORC-25 – Order Status Modifier. A simple coding conveys separately the status of prescription, validation, dispensing and 350 administration. These statuses are not expected to always be sequential, so a strict numbering scheme was not selected – i.e., normally the prescription precedes administration, but this will not always be the case. A numbered scheme that respects this separation is presented in 4.5.1 - Prescription, Validation, Dispense and Administration Status (page 28). 355 21. For scope clarification, in this present edition, IHE –Pharmacy covers the administration of medication until a successful or unsuccessful administration of the medication, and related aspects. After that – e.g., Adverse drug events, other reactions that happen later than the event of administration – are not yet covered in detail in the scenarios explored in this first release of the profile, so IHE-Pharmacy makes no constraints or 360 recommendations at this moment.

22. “Dispense Report”  “Medication Preparation Report” The dispense itself is the supply of drugs for a patient and must be addressed in future editions. 365

Volume 1 – Integration Profiles

1.n Copyright Permission Health Level Seven Inc. has granted permission to IHE to reproduce tables from the HL7 370 standard. The HL7 tables in this document are copyrighted by Health Level Seven Inc. All rights reserved. IHE grants permission to Health Level Seven Inc. and its affiliate organizations to reproduce either parts of this document or the document in its entirety. Add the following to sections 1.n:

375 2.1 Dependencies among Integration Profiles

2.7 History of Annual Changes Add the following bullet to the end of the bullet list in section 1.7 • Added the Hospital Medication Workflow which supports the Medication workflows in a hospital setting. 380

Add Section 3

3 Integration Profiles Overview

3.1 Pharmacy Interoperability Model 385 The Profile described in this document is based upon the Pharmacy Interoperability Model shown below. This model shows the classes of actors that support the Pharmacy model and the interactions between these actors. The Pharmacy Interoperability model effectively combines (orthogonally) the supply path from the care path; the current scope excludes the supply path, only focusing on the clinical messages. 390 The model shows classes of actors, rather than actors: the Pharmaceutical Adviser can be a series of cascading Adviser, and the Medication Dispenser is a class of actors that will be defined in later editions of this framework. Dotted lines indicate messages that are still out of scope, but are indicated as they are part of the model. 395

Prescription Pharmacy – Order Validated Order

Prescription Pharmacy Pharmacy Distribution/ Prescription Pharmacy Administration orderorder entry entry ValidationValidation Distribution Preparation

Pharmacy – Preparation Validated Order Report

Administration Stock Report Status / Availability

Stock Management Dispense Dispense

Delivery Distribution Report

Stock Status / Availability

Resupply

Stock Status / Availability

ResupplyResupply

Medication Dispenser

Figure 3.1-1: Pharmacy Interoperability Model

4 Intra-Hospital Workflow Integration Profile This integration profile instantiates the interoperability model to the Hospital - basic inpatient 400 scenario.

4.1 Actors/ Transactions Figure 4.1-1 shows the actors directly involved in the Hospital Medication Workflow Integration Profile and the relevant transactions between them. Other actors that may be indirectly involved due to their participation in other related profiles are not necessarily shown.

Prescription Placer

↓ Medication Order ↓ Advance Prescription [PHARM-H1] Notification [PHARM-H5]

Pharmaceutical Adviser

Pharmacy Validated Order [PHARM-H2] ↓

Validated Order Confirmation [PHARM-H6] ↓

Medication Dispenser

Dispense Report ↑ Administration [PHARM-H3] ↓ Report [PHARM-H4]

Medication Administrator Informer

405

Figure 4.1-1: Hospital Pharmacy Actor Diagram

Table 4.1-1 lists the transactions for each actor directly involved in the Pharmacy Profile. In order to claim support of this Integration Profile, an implementation must perform the required 410 transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of options defined by this Integration Profile and that implementations may choose to support is listed in Volume 1, Section 4.2.

Table 4.1-1 Intra-Hospital Workflow Integration Profile - Actors and Transactions Actors Transactions Optionality Section in Vol. 2 Prescription Placer Medication Order [PHARM-1] R 5.6 Advance prescription notification [PHARM-H5] O 5.10 Validated Order [PHARM-H2] R 5.7 Medication Preparation Report [PHARM-H3] R 5.8 Administration Report [PHARM-H4] R 5.9 Pharmaceutical Adviser Medication Order [PHARM-1] R 5.6 Validated Order [PHARM-H2] R 5.7 Medication Preparation Report [PHARM-H3] R 5.8 Validated Order Confirmation [PHARM-H6] O 5.11 Administration Report [PHARM-H4] R 5.9 Medication Dispenser Advance prescription notification [PHARM-H5] O 5.10 Validated Order [PHARM-H2] R 5.7 Medication Preparation Report [PHARM-H3] R 5.8 Administration Report [PHARM-H4] R 5.9 Medication Administration Medication Preparation Report [PHARM-H3] R 5.8 Informer Administration Report [PHARM-H4] R 5.9 Advance prescription notification [PHARM-H5] O 5.10 Validated Order Confirmation [PHARM-H6] O 5.11

415 Note: Conditions and optionality are described in the section corresponding to each message.

4.2 Intra-Hospital Workflow Integration Profile Options Options that may be selected for this Integration Profile are listed in the table 4.2-1 along with the Actors to which they apply. Dependencies between options when applicable are specified in notes. 420 Table 4.2-1: Intra-Hospital Workflow - Actors and Options Actor Options Vol & Section Prescription Placer Advance Prescription Notification 2 – 5.10 Pharmaceutical Adviser Validated Order Confirmation 2 – 5.11 Medication Dispenser Advance Prescription Notification 2 – 5.10

Actor Options Vol & Section Medication Administration Informer Advance Prescription Notification 2 – 5.10, Validated Order Confirmation 2 – 5.11

4.2.1 Option: Advance Prescription Notification This option is used to inform in advance the actors of a prescription, so that preparation of the 425 medication and of the patient can be triggered before the Pharmaceutical Advice is completed. Since any actor that receives the prescription notification will also need to receive the indication when it’s validated, this option includes transactions Advance Prescription Notification [PHARM-H5] and Validated Order Confirmation [PHARM-H6]. Using this option requires that both these transactions are used. 430 With this option, it may be that there are cases where there are differences between the original Prescription Order and the actual Validated Prescription. In these cases, the content of the Validated Prescription should prevail over the original prescription. It is also expectable that upon detecting such inconsistency, the Medication Administration Informer or the Medication Dispenser will notify the Pharmaceutical Adviser. 435 The information in transactions PHARM-H1 to PHARM-H4 is prevailing over PHARM-H5: If there are unsolvable discrepancies between the information in PHARM-H2 and PHARM-H5, the Medication Dispenser must inform the Pharmaceutical Adviser and the Prescription Placer (with a status “UA – Unable to Accept”). If there are unsolvable discrepancies between the information in PHARM-H3 and PHARM-H5, 440 the Medication Administration Informer must inform the Pharmaceutical Adviser and the Prescription Placer (with a status “UA – Unable to Accept”)

4.3 Intra-Hospital Workflow Process Flow

4.3.1 Scope

4.3.1.1 Supply Chain management 445 In the first year, IHE Pharmacy does not cover the supply chain of medication, only the clinical flow of information is covered. In many implementations both clinical and supply flows will be present, which will require supply and inventory messages, which are not covered in the current release of the profile. To provide guidance for the use of this profile, not constraining the supply chain aspects, a brief 450 description of the foreseen supply chain messaging follows: • The dispense starts with the RDE message, which is the message that circulates in the pharmacy until the dispenser. This message may contain more or less detailed information, according to the implementation: for example, the pharmacy technician may receive an RDE

from the pharmaceutical advisor stating “3 times per day” and he/she will change this to “one 455 at 8h00, one at 16h00, one at 24h00”, depending on the local pharmacy rules. After this, he will send it to the dispenser (which may be in the pharmacy or in the ward). • The dispenser of medication (pharmacy, a ward) receives an order for dispense (triggered by a validated prescription) and proceeds with dispensing it (generating the RGV message when the medication is assigned to a specific administration). 460 • For supply management, the dispenser may also report that a certain amount of medication has been dispensed for a patient, and the corresponding report transports quantity and inventory information (e.g., “21 units of Dafalgan® have been dispensed for patient X”), eventually also “with the lot number XXX and expiry date dddddddd”. This information is transmitted through an RDS message. 465 • If the dispenser also has some basic stock management functionality, it may determine that the resupply is needed. In these cases, an OMS message is sent from the Dispenser to a medication supplier. This message may be also nominative (expliciting the patient name) or not. • This chain, involving the use of “Resupply” functional blocks, and the use of OMS and RDS 470 messages, with or without Patient information, and inventory information, allows for supply networks to be created for each implementation. • The “clinical” actors may be interested in updates of the supply process, for example a doctor may want to know that the 21 units of Dafalgan® have finally been dispensed for his/her patient. 475 • Each supplier of medication may also inform others about the current inventory. This is achieved by means of an MFN^M16 message (only available as of HL7 v2.6) and may be used for example in situations where the local or remote availability can be used to advise on the best medication to dispense. • The supply messages described above can be communicated to each of the actors directly or 480 through repositories (see next section for use of repositories)

4.3.1.2 Use of messages and repositories In the current scope, this profile foresees the direct message exchange between the actors. IHE Pharmacy expects that information such as administration reports, dispense and preparation reports, etc. are available on hospital-wide repositories, and not associated specifically with each 485 actor. For example, the Medication Administration Informer may send the Administration reports to a repository, to which the Prescription Placer and the Pharmaceutical Advisor are consumers. This also allows the communication with external repositories. This is, however, outside of the current scope of this document, and may be described in later editions of the Hospital Medication Workflow Integration Profile.

490 4.3.2 Workflow IHE supports the range of workflows present in hospital pharmacies. The current scope is based on the basic patient scenario, depicted in Figure 4.3.2-1 Basic Process Flow in Intra-hospital Profile below.

HOSPITAL

Prescription Placer Pharmaceutical Adviser Medication Dispenser Med. Administration Informer

Advance Prescription Notification

Medication Order

Pharmacy Validated Order Validated Order Confirmation

Pharmacy Validated Order

Med. Preparation Report Med. Preparation Report

Administration report 1

-Fin1 -Fin2

* *

Administration report N

495 Figure 4.3.2-1: Basic Process Flow in Intra-hospital Profile

The workflow is summarized as follows: The prescription placer enters and submits a prescription. A message is sent to the pharmaceutical adviser, who is to take care of the validation of the prescription according to site rules. This validation can be for legal, clinical, or stock reasons. 500 When the prescription is validated by the pharmaceutical advisor, a message is sent to the Medication Dispenser, containing the original prescription and also the medication that is expected to be dispensed (in the case where the pharmacy must specify this, for example, determining what is the package that is to be dispensed or if there is a change generated by the validation). 505 The dispenser receives the message and ensures all the necessary actions to assign the medication to the patient, making it available for administration. This can consist of a chain of actions, but it is currently out of scope to detail these actions. After each preparation event, the Medication Dispenser sends a report to the Administration Informer mentioning that the medication or its alternative is available, and also forwarding the 510 original prescription and the pharmacy validation. When a medication is administered, or when there is a change in the administration of a medication (e.g., start of an IV perfusion, change of rate of a perfusion, break of vial, patient rejecting the medication immediately upon administration, etc.), the Medication Administration Informer sends a message (per administration event). This message contains the original 515 prescription, the pharmacy validation, and the preparation report.

4.4 Pharmacy Messaging Content The general structure of the message content in the IHE Pharmacy is as follows: 1. There is a common part for the patient and order data – this is to be used by all actors. In the use cases currently covered by IHE, it is created by the prescription placer 520 application. In the HL7 messages, this consists of segments PID [ PD1 ] [{ NTE }] [ PV1 [ PV2 ] ] [{ IN1 [ IN2 ] [ IN3 ] }] [ GT1 ] [{ AL1 }]]{ORC [{ TQ1 [{ TQ2 }] }]

[ --- PATIENT begin PID Patient Identification [ PD1 ] Additional Demographics [{ NTE }] Notes and Comments (for Patient ID) [ --- PATIENT_VISIT begin PV1 Patient Visit [ PV2 ] Patient Visit – Additional Info ] --- PATIENT_VISIT end [{ --- INSURANCE begin IN1 Insurance [ IN2 ] Insurance Additional Information [ IN3 ] Insurance Additional Information, Certification }] --- INSURANCE end ______20 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

[ GT1 ] Guarantor [{ AL1 }] Allergy Information ] --- PATIENT end { --- ORDER begin ORC Common Order [{ --- TIMING begin TQ1 Timing/Quantity [{ TQ2 }] Timing/Quantity Order Sequence }] --- TIMING end

2. Prescription Order – created and maintained at the prescription placer. In an HL7 525 message, it consists of segments RXO [{NTE}] {RXR} [{RXC [{NTE }] }]

RXO Pharmacy/Treatment Order [{ NTE }] Notes and Comments (for RXO) { RXR } Pharmacy/Treatment Route [{ --- COMPONENT begin RXC Pharmacy/Treatment Component [{ NTE }] Notes and Comments (for each RXC) }] --- COMPONENT end

3. Pharmaceutical Advice – created and maintained at the pharmaceutical adviser. In an HL7 message, it consists of segments RXE [{ NTE }] { TQ1 [{ TQ2 }] } {RXR} 530 [{RXC}] RXE Pharmacy/Treatment Encoded Order [{ NTE }] Notes and Comments (for RXE) { --- TIMING_ENCODED begin TQ1 Timing/Quantity [{ TQ2 }] Timing/Quantity Order Sequence } --- TIMING_ENCODED end { RXR } Pharmacy/Treatment Route [{ RXC }] Pharmacy/Treatment Component (for RXE)

4. Medication Preparation Information– created and maintained at the medication dispenser class of actors. In an HL7 message, it consists of segments RXG{TQ1 [{ TQ2 }]}{ RXR } [{ RXC }]{ [ OBX ] [{ NTE }]} { --- GIVE begin RXG Pharmacy/Treatment Give { --- TIMING_GIVE begin TQ1 Timing/Quantity [{ TQ2 }] Timing/Quantity Order Sequence } --- TIMING_GIVE end { RXR } Pharmacy/Treatment Route [{ RXC }] Pharmacy/Treatment Component { --- OBSERVATION begin

[ OBX ] Observation/Results [{ NTE }] Notes and Comments (for OBX) } --- OBSERVATION end } --- GIVE end 535 5. Administration Information – created and maintained at the medication administration informer. In HL7 message, it consists of segments {RXA} RXR [{OBX [{NTE}]}]

{ --- ADMINISTRATION begin { RXA } Pharmacy/Treatment Administration RXR Pharmacy/Treatment Route [{ --- OBSERVATION begin OBX Observation/Result [{ NTE }] Notes and Comments (for OBX) }] --- OBSERVATION end } --- ADMINISTRATION end

540 To preserve the integrity and ownership of prescription data and allow for interoperability and flexibility, these boundaries are maintained throughout the system: • The Prescription Placer creates prescription data. • The Pharmaceutical Adviser takes the prescription data and appends to this prescription data his/her advice, not changing the prescription data. 545 • The Medication Dispenser takes the Validated Order data (Prescription + Pharmaceutical Advice) and appends to this the Dispense and Preparation Information, not changing the prescription nor validation data. • The Medication Administration Informers take the data available in the Preparation Report (Prescription + Pharmaceutical Advice+ Medication Preparation Report) and appends to this 550 the Medication Administration information, not changing the prescription, validation nor dispense/preparation data.

Table 4.4-1: Hospital Messages content and data ownership – basic inpatient scenario Medication Prescription Pharmaceutical Medication HL7 Administration Placer Adviser Dispenser segments Informer Common data Master Inherit Inherit Inherit ORC, RXO

Prescription Master Inherit Inherit Inherit RXO… Order

Validated Master Inherit Inherit RXE… order Medication Dispense Master Inherit RXG… Report

Administration Master RXA… Report

HL7 Message OMP RDE RGV RAS type sent

555 Complete message structures for both request and response messages are displayed throughout chapter 5:

Transaction name HL7 message type HMW table

Prescription Order (PHARM-H1) OMP^O09 (Request), ORP^O10 (Response) 5.5.8.1-1 5.5.8.2-1

Validated Order (PHARM-H2) RDE^O11 (Request), RRE^O12 (Response) 5.6.6.1-1 5.6.6.2-1

Medication Dispense Report (PHARM-H3) RGV^O15 (Request), RRG^O16 (Response) 5.7.5.1-1 5.7.5.2-1

Administration Report (PHARM-H4) RAS^O17 (Request), RRA^O18 (Response) 5.8.6.1-1 5.8.6.2-1

Advance Prescription Notification (PHARM-H5) same as PHARM-H1

Validated Order Confirmation (PHARM-H6) same as PHARM-H2

4.4.1 Common Data The common data is common to all the transactions, and is to be coded in the segments 560 PID [ PD1 ] [{ NTE }] [ PV1 [ PV2 ] ] [{ IN1 [ IN2 ] [ IN3 ] }] [ GT1 ] [{ AL1 }]]

and in the OBX segment. Table 4.4.1-1: Common Pharmacy Order data Parameter Required HL7 element Repeatable Patient.Name R PID-5 Y Patient.Personal Identification R PID-3 Y Patient.Administrative Sex R PID-8 Patient.Date of Birth R PID-7 Patient.Address O PID-11 Y Patient.Contact Information O PID-13 Y Patient.Guardian contact information RE NTE Y Patient.Guardian Name RE NTE Y Patient.Guardian Relationship RE NTE Y Patient.Marital Status O PID-16 Patient.Race O PID-10 Y Patient.Ethnicity O PID-22 Y Patient.Religious Affiliation O PID-17 Patient.Encounter.EncounterID RE PV1-19 Patient.Encounter.Patient Location RE PV1-3 Patient.Encounter.Organization.Name R ORC-21-1 Y Patient.Encounter.Organization.Address R ORC-22 Y Patient.Encounter.Organization.Organization Identifier R ORC-21-10 Y Patient.Encounter.Organization.Contact Information R ORC-23 Y Patient.Payers RE IN1, IN2, IN3 Y Patient.Coded Vital Signs O OBX Y Patient.Allergies and Drug Sensitivities O AL1 Y Patient.Active Problems O OBX Y Patient.Resolved Problems O OBX Y Patient.Immunizations O OBX Y Patient.Pregnancy History O OBX Y Prescription.Prescriber.Name R ORC-12-2..6 Y Prescription.Prescriber.Address O ORC-24 Y Prescription.Prescriber.HCP Identification R ORC-12-1 Y Prescription.Prescriber.Contact Information O ORC -14 Prescription.Prescriber.Speciality R ORC -12-21 Prescription.PrescriptionID R ORC-4

4.4.2 Prescription Order 565 In the Basic inpatient Scenario, the Prescription data is required in all the transactions, and is to be coded in the segments

RXO [{NTE}] {RXR} [{RXC [{NTE }] }]

Table 4.4.2-1: Prescription Order data Parameter Req’d HL7 field Repeatable Prescription.Prescription_Item.Date/Time of prescription R ORC-9 Prescription.Prescription_Item.Item ID R ORC-2 Prescription.Prescription_Item.Frequency/Posology RE TQ1 Y Prescription.Prescription_Item.Route R RXR-1 Prescription.Prescription_Item.Site RE RXR-2 Prescription.Prescription_Item.Dose RE RXO-2 Prescription.Prescription_Item.Dose Units RE RXO-4 Prescription.Prescription_Item.Rate RE RXO-21 Prescription.Prescription_Item.Instructions RE RXO-6 Y Prescription.Prescription_Item.Fulfilment instructions RE RXO-7 Y Prescription.Prescription_Item.Medication.Code RE RXO-1-1 Prescription.Prescription_Item.Medication.Coding system RE RXO-1-3 Prescription.Prescription_Item.Medication.Name RE RXO-1-2 Prescription.Prescription_Item.Medication.Form code RE RXO-5 Prescription.Prescription_Item.Medication.Form coding system RE RXO-5 Prescription.Prescription_Item.Medication.Active Ingredients RE RXC-2 Prescription.Prescription_Item.Medication.substitution allowed R RXO-9 Prescription.Prescription_Item.Medication.Observations.Obs RE NTE Y Prescription.Diagnosis R RXO-20 Y Prescription Status R ORC-25 570

4.4.3 Pharmacy Validated Order The validated order data is to be coded in the segments RXE [{ NTE }] { TQ1 [{ TQ2 }] } {RXR} [{RXC}]

575 Table 4.4.3-1: Pharmacy Validated Order data Parameter Req’d HL7 field Repeatable Prescription.PrescriptionID R RXE-15 Pharmaceutical_Advice.Pharmacist.Name R RXE-14 Y Pharmaceutical_Advice.Pharmacist.Address O Pharmaceutical_Advice.Pharmacist.HCP Identification R RXE-14-1 Pharmaceutical_Advice.Pharmacist.Department O Pharmaceutical_Advice.Pharmacist.Contact Information O

Parameter Req’d HL7 field Repeatable Pharmaceutical_Advice.Obs RE NTE Y Pharmaceutical_Advice.Date/Time of advice R ORC-9 Pharmaceutical_Advice.problems RE NTE Y Pharmaceutical_Advice.Summary of physician/pharmacist discussion RE NTE Y Pharmaceutical_Advice.Status: (Open | Closed) R ORC-25 Pharmaceutical_Advice.Decision R ORC-1 Pharmaceutical_Advice.Validated_Item.Item ID R ORC-2 Pharmaceutical_Advice.Validated_Item.Frequency R TQ1-3 Pharmaceutical_Advice.Validated_Item.Route R RXR-1 Pharmaceutical_Advice.Validated_Item.Site RE RXR-2 Pharmaceutical_Advice.Validated_Item.Dose R RXE-3 Pharmaceutical_Advice.Validated_Item.Rate RE RXE-23 Pharmaceutical_Advice.Validated_Item.Administration Instructions RE RXE-7 Y Pharmaceutical_Advice.Validated_Item.Advice RE NTE Y Pharmaceutical_Advice.Validated_Item.Dispense instructions RE RXE-21 Y Pharmaceutical_Advice.Validated_Item.Medication.Code R RXE-2-1 Pharmaceutical_Advice.Validated_Item.Medication.Coding system R RXE-2-3 Pharmaceutical_Advice.Validated_Item.Medication.Name R RXE-2-2 Pharmaceutical_Advice.Validated_Item.Medication.Form code O RXE-6 Pharmaceutical_Advice.Validated_Item.Medication.Form coding system O RXE-6 Pharmaceutical_Advice.Validated_Item.Medication.Active Ingredients O RXC-2 Pharmaceutical_Advice.Validated_Item.Medication.substitution status R RXE-9

4.4.4 Medication Preparation Report The common data is common to all the transactions, and is to be coded in the segments RXG{TQ1 [{ TQ2 }]}{ RXR } [{ RXC }]{ [ OBX ] [{ NTE }]}

580 Table 4.4.4-1: Medication Preparation Report data Parameter Req’d HL7 field Repeatable Preparation.Dispenser.Name R ORC-19 Y Preparation.Dispenser.HCP Identification R ORC-19 Preparation.Dispense_Item.Quantity/Timing R TQ1 Preparation.Dispense_Item.Code R RXG-4 Preparation.Dispense_Item.Coding system R RXG-4 Preparation.Dispense_Item.Name RE RXG-4 Preparation.Dispense_Item.Give Amount – Minimum R RXG-5 Preparation.Dispense_Item.Give Amount – Maximum RE RXG-6 Preparation.Dispense_Item.Give Units code R RXG-7

Parameter Req’d HL7 field Repeatable Preparation.Dispense_Item.Give Units coding system R RXG-7 Preparation.Dispense_Item.Form code RE RXG-8 Preparation.Dispense_Item.Form coding system RE RXG-8 Preparation.Dispense_Item.OBS RE RXG-13 Y Preparation.Barcode RE RXG-25 Administration instructions RE RXG-9 Y

4.4.5 Administration Report The common data is common to all the transactions, and is to be coded in the segments {RXA} RXR 585 Table 4.4.5-1: Administration Report data Parameter Req’d HL7 field Repeatable Administration.Ward_Staff.Name R RXA-10 Y Administration.Ward_Staff.Address RE RXA-10 Y Administration.Ward_Staff.HCP Identification R RXA-10 Y Administration.Ward_Staff.Department O RXA-10 Y Administration.Administered_Item.Effective start date/time of administration R RXA-3 Administration.Administered_Item.Effective end date/time of administration RE RXA-4 Administration.Administered_Item.Administration Location RE RXA-11 Administration.Administered_Item.Expiration date RE RXA-16 Y Administration.Administered_Item.Batch number RE RXA-15 Y Administration.Administered_Item.Quantity administered (may be later updated e.g., following patient vomiting, extravasation …) RE RXA-6 Administration.Administered_Item.Code R RXA-5 Administration.Administered_Item.Name R RXA-5 Administration.Administered_Item.Units R RXA-7 Administration.Administered_Item.Form RE RXA-8 Administration.Administered_Item.Administration comments RE RXA-9 Y Administration.Administered_Item.Reason for non-administration (for instance patient refused medicine, medicine is not available…) RE RXA-18 Y Administration.Administered_Item.Reaction RE OBX Y Administration.Administered_Item.Route of administration R RXR-1 Administration.Administered_Item.Administration Status R RXA-20 Administration.Administered_Item.Barcode RE RXA-25

4.5 Order Status Management

4.5.1 Prescription, Validation, Dispense and Administration Status The status of the prescription is described in the Common parts Document. In addition to the prescription status, the hospital system may desire to track the status of the validation, dispense, 590 and administration. Since the prescription may be decomposed into additional lines, each of which may trigger several medication preparation reports, and each of which may trigger several administration reports, the status of these activities must be detailed. To refer to these statuses, the following structure is used – A prefix is used for 595 P-Prescription, V-Validation/Advice, D-Dispense, A-Administration For each of these, the status can be 0 (not started), 1 (Planned), 2 (in Progress), 3 (completed) and 9 (cancelled). To detail the status, we append the prefix and the status number. These 4 parts are separated by a semicolon (“;”). A field that is not mentioned is considered as “0- Not started”; each actor should 600 fill in this information for its part of the workflow – for example, the prescription placer updates the Administration part, the administration informer updates the Administration part, etc. The status of the prescription “In progress” can relate to a few sub-statuses:

Table 4.5.1-1: Detailed order status Action Prescription Validation Dispense Administration Order Order status status status status Status Status becomes… (ORC-5) Detail (ORC- 25) Prescription Placed N/A N/A N/A IP P3;V0;D0; (2 items, for A0 a week) is placed for validation Pharmacist In Progress In Progress N/A N/A IP P3;V2;D0; validates A0 prescription Dispenser In Progress Completed In progress N/A IP P3;V3;D2; dispenses one A0 of the 2 products, for a week Dispenser In Progress Completed In Progress N/A IP P3;V3;D2; dispenses the A0 other product for 5 days

Action Prescription Validation Dispense Administration Order Order status status status status Status Status becomes… (ORC-5) Detail (ORC- 25) Dispenser In Progress Completed Completed N/A IP P3;V3;D3; dispenses the A0 other product for the other 2 days Nurse In Progress Completed Completed In Progress IP P3;V3;D3; administers A2 one dose of each medication line Nurse Completed Completed Completed Completed CM P3;V3;D3; finishes A3 administering the last dose of all the lines Cancel Cancelled N/A N./A N/A CA P9;V0;D0; Prescription A0 before validation Cancel Cancelled Completed N./A N/A CA P9;V3;D0; Prescription A0 after validation Cancel Cancelled Completed In Progress N/A CA P9;V3;D2; Prescription or A0 or after dispense P9;V3;D3; Completed A0 Cancel Cancelled Completed In Progress In Progress CA P9;V3;D2; Prescription or or A2 after Completed Completed P9;V3;D3; administratio A2 n P9;V3;D3; A3 Prescription Completed Completed N/A N/A DC P3;V3;D0; is refused by A0 Pharmacist Validation Completed Cancelled N/A N/A DC P3;V9;D0; cancelled by A0 Pharmacist before dispense Validation Completed Cancelled In Progress N/A DC P3;V9;D2; cancelled by or A0 Pharmacist Completed P3;V9;D3; after dispense A0

Action Prescription Validation Dispense Administration Order Order status status status status Status Status becomes… (ORC-5) Detail (ORC- 25)

Validation Completed Cancelled In Progress In Progress DC P3;V9;D2; cancelled by or or A2 Pharmacist Completed Completed P3;V9;D3; after A2 administratio n P3;V9;D3; A3 Cancellation Completed Completed In Progress Cancelled DC P3;V3;D2; of an or A9 administratio Completed P3;V3;D3; n A9

605 In addition to this, the status of each prescription line, dispense line and administration line can be tracked. Example: The prescription requests 21 units of Paracetamol 500 mg, the pharmacy can dispense 15 at a time. After the first dispense of 15 units, the status of the dispense line “Paracetamol 500 mg, 21 610 units” is “In Progress”, and so is the status of the overall dispense. This also applies for the administration – each prescription item’s administration is in progress until every planned administration of that prescription item is complete; a prescription line is in progress until all instances of administration of all lines are administered.

615

5 Conventions

5.1 Technical Framework Cross-references When references are made to another section within a Technical Framework volume, a section 620 number is used by itself. When references are made to other volumes or to a Technical Framework in another domain, the following format is used: TF-:

, where is a short designator for the IHE domain (ITI = IT Infrastructure, PCC = Patient Care Coordination, LAB = Laboratory, PHARM-HMW is the Hospital Medication 625 Workflow) is the applicable volume within the given Technical Framework (e.g., 1, 2, 3),

is the applicable section number. For example: ITI TF-1: 3.1 refers to Section 3.1 in volume 1 of the IHE IT Infrastructure. When references are made to Transaction numbers in the Technical Framework, the following 630 format is used: [-], where is the transaction number within the specified domain. For example: [LAB-1] refers to Transaction 1 from the IHE Laboratory Technical Framework, [ITI-30] refers to Transaction 30 from the IT Infrastructure Technical Framework.

635 5.2 The generic IHE Transaction Model Transaction descriptions are provided in Section 3. In each transaction description the actors, the roles they play, and the transactions between them are presented as use cases. The generic IHE transaction description includes the following components: • Scope: a brief description of the transaction. 640 • Use case roles: textual definitions of the actors and their roles, with a simple diagram relating them, e.g.,:

Actor Actor

Transaction

• Referenced Standards: the standards (stating the specific parts, chapters or sections thereof) to be used for the transaction. 645 • Interaction Diagram: a graphical depiction of the actors and messages that support the transaction, with related processing within an Actor shown as a rectangle and time progressing downward, similar to:

The interaction diagrams used in the IHE Hospital Medication Workflow Technical 650 Framework are modeled after those described in Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, ISBN 0-201-57168-4. Simple acknowledgment messages are often omitted from the diagrams for brevity. One or more messages may be required to satisfy a transaction. Each message is represented as an arrow starting from the Actor initiating the message. 655 • Message definitions: descriptions of each message involved in the transaction, the events that trigger the message, its semantics, and the actions that the message triggers in the receiver.

5.3 HL7 Profiling Conventions The messages used by each transaction are described in this document using static definitions of "HL7 constrainable message profiles". Refer to HL7 v2.5, chapter 2B, section 2.B.6. The static 660 definition of each message is represented within tables. At the message level, a table represents the message structure and its definition in terms of segments. At the segment level, a table details one segment and its definition in terms of fields.

5.3.1 Static Definition - Message Level The table describing a message contains 5 columns: 665 • Segment: gives the segment name, and places the segment within the hierarchy of the HL7message structure. Segments or segment groups not required appear between square brackets. Repeatable segments or segment groups appear between braces. • Meaning: Meaning of the segment as defined by HL7

• Usage: Coded usage of the segment, as defined by this static definition built for the context 670 of this particular transaction within IHE Hospital Medication Workflow Technical Framework. The coded values used in this document are: R: Required: A compliant sending application shall populate all "R" elements with a non- empty value. A compliant receiving application shall process (save/print/archive/etc.) or ignore the information conveyed by required elements. A compliant receiving 675 application shall not raise an error due to the presence of a required element, but may raise an error due to the absence of a required element.

RE: Required if available. The element may be missing from the message, but shall be sent by the sending application if there is relevant data. A conformant sending application shall be capable of providing all "RE" elements. If the conformant sending 680 application knows the required values for the element, then it shall send that element. If the conformant sending application does not know the required values, then that element may be omitted. Receiving applications will be expected to process (save/print/archive/etc.) or ignore data contained in the element, but shall be able to successfully process the message if the 685 element is omitted (no error message should be generated if the element is missing).

O: Optional. IHE Hospital Medication Workflow Technical Framework has not yet defined usage requirements for this field.

C: Conditional. This usage has an associated condition predicate. (See HL7 v2.5 section 2.12.6.6 "Condition Predicate"). 690 If the predicate is satisfied: A compliant sending application shall always send the element. A compliant receiving application shall process or ignore data in the element. It may raise an error if the element is not present. If the predicate is NOT satisfied: A compliant sending application shall NOT send the element. A compliant receiving application shall NOT raise an error if the condition 695 predicate is false and the element is not present, though it may raise an error if the element IS present.

X: Not supported. For conformant sending applications, the element will not be sent. Conformant receiving applications may ignore the element if it is sent, or may raise an application error. 700 • Cardinality: Within square brackets, minimum and maximum number of occurrences authorized for this segment, in this static definition of the message, built for the context of this particular transaction within IHE Hospital Medication Workflow Technical Framework. • HL7 chapter: Reference of the HL7 v2.5 chapter that describes this segment.

705

Table 5.3.1-1: Example: Initial segments of a message description Segment Meaning Usage Card. HL7 chapter MSH Message Header R [1..1] 2 [ --- PATIENT begin O [0..1] PID Patient Identification R [1..1] 3 [ --- PATIENT VISIT begin RE [0..1] PV1 Patient Visit R [1..1] 3

5.3.2 Static Definition - Segment Level The table describing a segment and its definition in terms of fields contains 7 columns: • SEQ: Position (sequence) of the field within the segment. 710 • LEN: Maximum length of the field • DT: Field Data Type • Usage: Usage of the field in this particular context of IHE Hospital Medication Workflow Technical Framework. Same coded values as in the message level: R, RE, C, O, X • Cardinality: Minimum and maximum number of occurrences for the field in this particular 715 context of IHE Hospital Medication Workflow Technical Framework. Same meaning as in the message level. • TBL#: Table reference (for fields using a set of defined values) • ITEM#: HL7 unique reference for this field • Element Name: Name of the field. 720

5.4 HL7 Implementation Notes

5.4.1 Network Guidelines The IHE Hospital Medication Workflow Technical Framework makes these recommendations: An application that wants to send a message (initiate a transaction) will initiate a network 725 connection (if one does not already exist) to start the transaction. The receiver application will respond with an acknowledgement or response to query but will not initiate new transactions on this network connection.

5.4.2 Message Granularity A message is generated from one trigger event in the real world. Therefore a message is related 730 to one single business object.

5.4.3 Empty Fields According to HL7 standard, if the value of a field is not present, the receiver shall not change corresponding data in its database. However, if the sender defines the field value to be the explicit NULL value (i.e., two double quotes ""), it shall be used, causing removal of any values 735 for that field in the receiver's database. This convention is applied by the IHE Hospital Medication Workflow Technical Framework. In the IHE Hospital Medication Workflow, a null value for a field means that the first component of that field is to be nullified. To nullify all components in a field, these fields must be explicitly nullified.

740 5.4.4 Acknowledgement Modes For the IHE Hospital Medication Workflow Technical Framework, applications that receive HL7 messages shall send acknowledgements using the HL7 acknowledgement mode as defined in HL7 v2.5 chapter 2, 2.9.2. An OMP message shall be acknowledged by one single ORP message. These acknowledgements 745 are application-level acknowledgements (i.e., not accept acknowledgements) and must be generated by the receiving application after it has parsed the message and processed its content. The receiving application shall automatically generate the application acknowledgement messages without waiting for human approval of the contents of the message that was received.

5.4.5 IHE Pharmacy Technical Framework Acknowledgement Policies 750 The Enhanced acknowledgement mode in HL7 refers two types of acknowledgement that can be used in IHE: Accept and Application acknowledgements. Event-triggered messages flow in one direction and accept of application acknowledgement messages related to those event-triggered messages flow in the other direction. IHE- Hospital Medication Workflow does not impose constraints on the Acknowledgement 755 Policies.

5.4.5.1 Application Acknowledgement It may take the receiving system a while (seconds, minutes) to acknowledge a message or send a response. If the connection is broken whilst the sending application is still waiting for an acknowledgement, the sending application shall initiate a new connection and resend the 760 message. The application acknowledgement shall only be created by an application that is able to examine a message at the semantic / business-process level. Intermediate message brokers do not have this capacity and therefore shall not be used to generate the contents of application acknowledgements.

765 5.4.6 HL7 Data Types This section describes the IHE constraints on some HL7 data types.

5.4.6.1 CX – Extended Composite ID with Check Digit The constraints below particularly apply to the Patient Identifiers (PID segment).

770 HL7 Component Table - CX – Extended Composite ID with Check Digit SEQ LEN DT Usage CARD TBL# COMPONENT NAME 1 15 ST R [1..1] ID Number 2 1 ST O [0..1] Check Digit 3 3 ID O [0..1] 0061 Check Digit Scheme 4 227 HD R [1..1] 0363 Assigning Authority 5 5 ID R [0..1] 0203 Identifier Type Code 6 227 HD O [0..1] Assigning Facility 7 8 DT O [0..1] Effective Date 8 8 DT O [0..1] Expiration Date 9 705 CWE O [0..1] Assigning Jurisdiction 10 705 CWE O [0..1] Assigning Agency or Department The data type has been constrained because the IHE Framework regards the Assigning Authority and the Identifier Type Code as essential components.

5.4.6.2 EI – Entity Identifier The constraints below particularly apply to the following fields: placer group number, placer 775 order number, filler order number and specimen number.

HL7 Component Table - EI – Entity Identifier SEQ LEN DT Usage CARD TBL# COMPONENT NAME 1 199 ST R [1..1] Entity Identifier 2 20 IS C [0..1] 0363 Namespace ID 3 199 ST C [0..1] Universal ID 4 6 ID C [0..1] 0301 Universal ID Type

Component 1 is required. Either component 2 or both components 3 and 4 are required. 780 Components 2, 3 and 4 may be all present. The EI is appropriate for machine or software generated identifiers. The generated identifier goes in the first component. The remaining components, 2 through 4, are known as the assigning

authority; they can also identify the machine/system responsible for generating the identifier in component 1. 785 Example 1: AB12345^RiversideHospital Example 2: AB12345^^1.2.840.45.67^ISO Example 3: AB12345^RiversideHospital^1.2.840.45.67^ISO IHE requires component 2 “Namespace ID” to be filled in all cases. Particularly when there are several concurrent assigning authorities within the healthcare enterprise, this Namespace ID will 790 indicate which assigning authority provided this number. This happens for instance, when there are several Order Placer actors within the enterprise, each one assigning placer order numbers and placer group numbers. Example 4: Placer order number and placer group number assigned by two different Order Placer actors.

795 In message 1: ORC|NW|9876543^Nephro||777^Nephro|... In message 2: ORC|SC|9876543^Urology||555^Urology |... This also commonly happens when there are several Order Filler actors within the enterprise, each one assigning its own filler order numbers and specimen numbers. Example 5: Filler order number and specimen number assigned by the Order Filler actor 800 operated by the clinical laboratory of cytology. SPM|1|45611^Cytology|...... OBR|1|456^Cytology|... 5.4.6.3 HD – Hierarchic Designator SEQ LEN DT Usage CARD TBL# COMPONENT NAME 1 20 IS R [1..1] 0300 Namespace ID 2 199 ST C Universal ID 3 6 ID C 0301 Universal ID Type 805 This Integration Profile requires that a field of Data Type HD be populated with: • Either the first component “Namespace ID” alone, which in this case contains a local identifier of the object. • Or with all three components, “Namespace ID” containing the name of the object, “Universal ID” containing its universal OID, and “Universal ID Type” containing the value ISO. 810 This data type is particularly used in this technical framework to identify facilities, applications and assigning authorities: sending and receiving applications, sending and receiving facilities, last update facility, assigning authority of an identifier, etc.

5.4.6.4 CWE – coded with exceptions SEQ LEN DT Usage CARD TBL# COMPONENT NAME 1 20 ST R [1..1] Identifier 2 199 ST C [0..1] Text 3 20 ID C [0..1] 0396 Name of Coding System 4 20 ST O [0..1] Alternate Identifier 5 199 ST O [0..1] Alternate Text 6 20 ID C [0..1] 0396 Name of Alternate Coding System 7 10 ST O [0..1] Coding System Version ID 8 10 ST O [0..1] Alternate Coding System Version ID 9 199 ST O [0..1] Original Text The data type has been constrained because the IHE Framework regards the Name of Coding 815 System and the Name of Alternate Coding System Assigning as essential components • If the “Identifier” is present, the Name of Coding System is required. • If the “Alternate Identifier” is present, the Name of Alternate Coding System is required. • In cases described in this document, the CWE.2 may contain a free-text indication, and in this case, CWE-1 and CWE-3 may be empty, if CWE-2 contains the information. 820

5.4.7 Scenario without a Pharmaceutical Adviser The Pharmaceutical Adviser (PA) actor is not always a mandatory role in a hospital medication workflow. For a system that implements a Prescription Placer (PP) actor, it is recommended that both 825 transactions PHARM-H1 (Prescription Order) and PHARM-H2 (Validated Order) be implemented, in order to be able to work in both scenarios, with and without separate PA, respectively. This kind of system may implement either or both, the PP’s optional PHARM-H5 (Advance Prescription Notification) and the PA’s optional PHARM-H6 (Validated Order Confirmation) transactions. 830 Implementations of a Medication Dispenser (MD) actor, in compliance with the IHE HMW profile, shall always implement the PHARM-H2 transaction and be able to respond to an incoming RDE^O11 request message with an outgoing RRE^O12 response message. As a consequence, since the PA is missing, no new information is generated for the RXE segment. Therefore the required fields of the RXE segment should be filled with corresponding 835 values from the RXO segment of the prescription, e.g.:

RXE field Optionality Description Source field

RXE-2 R Give Code RXO-1

RXE-3 R Give Amount minimum RXO-2

RXE-5 R Give Units RXO-4

RXE-14 R Pharmacist/Treatment Supplier’s Verification ID ORC-12

etc.

Moreover, it is recommended that the optional RXO segment be included in an RDE^O11 message. 840

Glossary Add the following terms to the Glossary: 845 Encounter: An encounter happens between a patient and a care provider who can be an individual or an organization. Treatment or medication regime: a treatment or medication regime is a series of medications intended to heal the patient or to improve the health status or to diagnose a disease. Prescription: a prescription is an order given by a clinician (usually physicians and in some 850 particular cases pharmacists, nurses, etc.), for a medication to be dispensed to the patient according to an established pattern. The prescription includes the name of the drugs, their dosages, instructions to the patient for the intake, etc. Medication record: A list of all medication-related data for a specific patient, including prescriptions (including (partially) fulfilled ones), dispenses and possibly administrations. 855 Pharmaceutical analysis: the action performed by a pharmacist to approve/modify or reject a prescription before it is given out to the patient. Pharmaceutical advice: the outcome of the pharmaceutical analysis. Healthcare Professional (HCP): a specially trained individual who provides healthcare services like a GP, specialist, nurse, midwife, dentist, physiotherapist, pharmacist etc. 860 System actor: information system that supports a particular function in the pharmacy domain. Human actor: individual (physician, pharmacist, etc.) that usually makes use of a system actor to perform an activity in the e-pharmacy domain. Dispensing: the act of assigning a medication to a patient, normally as indicated in the corresponding prescription. Since prescriptions can span long periods of time, a single 865 prescription may result in medicines dispensed several times. Nominative Distribution: a mode of distributing medication in which the pharmacy dispenses the medication to each patient. Globalized Distribution: a mode of dispensing mode in which the pharmacy distributes the medication to the wards and the nurses then dispense the medication to each patient as needed. 870 Order encoding: The Prescription Placer may fill in the prescription with a free-text description of the treatment details (as simple as Paracetamol 1000 mg oral, as needed, max 3 times a day). This description has to be translated (encoded) into products, and the quantities may have to be determined for the Pharmaceutical Analysis, Dispensing and Administration to take place. This is modeled as an “encoding” sub-task. 875 Medication Preparation: the act of making medication items available for a specific intended administration action.

Pharmacy validated order: this term is used to indicate that a medication order (in the current case, a medication prescription) is considered valid after some pharmaceutical analysis. This may require (or not) some review by one or more healthcare professionals, e.g., pharmacists or 880 physicians.

Volume 2 - Transactions Add section 5.5

5.5 Prescription Order – PHARM-H1 This section corresponds to Transaction PHARM-H1 of the IHE Technical Framework. 885 Transaction PHARM-H1 is used by the Prescription Placer and Pharmaceutical Adviser actors.

5.5.1 Scope This transaction is used by the Prescription Placer to issue a prescription that is sent to the Pharmaceutical Adviser. An Order accepted by the Pharmaceutical Adviser is acknowledged to the Prescription Placer as 890 in progress: Order Status ORC-5 = “IP” (In Progress) Prescription Placer (and, depending on local implementations, also the Pharmaceutical Adviser) may update or cancel an existing Order. Update consists in replacing some prescription lines or the complete prescription. IHE Pharmacy uses the field ORC-4 to keep the ordering group reference (usually the 895 prescription number), so that integrity of the order session (prescription) can be kept along the workflow. To place an additional medication in an existing Order Group the Prescription Placer places a new Order added to this Order Group (same ORC-4). It is expected that the pharmacy can regroup orders for supply purposes, and this will be dealt with in later versions of IHE – HMW.

900 5.5.2 Use Case Roles

Prescription Pharmaceutical Placer Advisor

Prescription

Actor: Prescription Placer Role: Creates prescriptions, Updates prescriptions, Cancels prescriptions, receives acceptance or rejection from the Pharmaceutical Adviser, Receives prescription order Content Changes, and 905 Status Changes.

Actor: Pharmaceutical Adviser Role: Accepts prescriptions. Notifies acceptance or rejection to the Prescription Placer, Notifies Prescription Placer of prescription content and status changes. Notifies Medication Dispenser of New prescription orders. Notifies Medication dispenser of changes to ongoing prescription 910 orders.

5.5.3 Referenced Standard HL7 version 2.5: • Chapter 2: "Control"  generic segments and data types • Chapter 3: "ADT"  PID and PV1 segments 915 • Chapter 6: "Financial Management"  IN1, IN2, IN3 segments • Chapter 4: "Order Entry"  OMP, OMP messages, other segments • Chapter 7: “Observation Reporting”  OBX segment

5.5.4 Interaction Diagram

Prescription Pharmaceutical Placer Adviser

OMP^O09 New Order: ORC-1 = NW

ORP^O10 New Order: ORC-1 = OK

920

5.5.4.1 New Prescription This message is used by the prescription placer to inform the pharmaceutical Adviser that a new prescription is ready for validation. This is a message of type OMP.

5.5.4.1.1 Trigger Events 925 The New Prescription message is triggered when the Prescription Placer submits the prescription. Depending on the particular implementation, this message can be sent when prescriptions are either: • validated by a physician 930 • validated and signed by a physician • entered and validated by a person that is transcribing paper-based prescriptions • … When an implementation supports option Advance Prescription Notification, transaction PHARM-H5 must be triggered by the same events as PHARM-H1, which means that the 935 Advance Prescription Notification is sent to the Medication Dispenser and Administration Informer at the same time as the Prescription Order.

5.5.4.1.2 Message Semantics One Prescription Order will be related to one patient, and may refer to a particular encounter (visit). It will contain one prescription, and this prescription refers one prescriber, and contains 940 zero or more prescription items. A prescription item contains one medication item and zero or more observations. The common data is common to all the transactions, and is to be coded in the segments: PID [ PD1 ] [{ NTE }] [ PV1 [ PV2 ] ] [{ IN1 [ IN2 ] [ IN3 ] }] [ GT1 ] [{ AL1 }]] Prescription data is to be coded in segments: 945 RXO [{NTE}] {RXR} [{RXC [{NTE }] }] A Placer Order Number (ORC-2) is assigned by the prescription placer system. The Filler Order number is not assigned yet, so it will be empty. Additional cases where the Filler Order number is needed a priori are not yet addressed. For a new prescription, ORC-1 is “NW”. 950 Encoded vs. Non-encoded Prescription Orders: There are several levels of prescription encoding (see HL7 2.5, section 4.15.1). The Prescription Order Placer is free to select the level of encoding that best suits the particular implementation needs.

To support proper semantic interoperability, IHE Pharmacy strongly recommends that encoded 955 medication orders are always used, when possible. As a concrete example on a different level of encoding an order, the same example where Dr. Hippocrates prescribes Doliprane® 1000 mg tablets, 1 orally three times a day for the duration of the inpatient hospitalization, can be sent as: Non-encoded (text description in RXO-6) 960 ORC|NW|1000^OE||||E|... RXO||||||1000 mg Paracetamol TID until discharge |... Encoded (RXO-1, 2 and 4 required) ORC|NW|1000^OE||||E|^TID^^^^R|... 965 RXO|RX1001^Doliprane 1000 mg TAB^ZZZ|1000||MG^^YYY|||||Y... RXR|PO|...

5.5.4.1.3 Expected Actions Upon receiving this message, the Pharmaceutical Adviser is expected to initiate the process of 970 validating. This validating may be done • Manually by a pharmacist and/or • (semi-)automatically by using a rules engine. Particular implementations may require patient data that is outside of the prescription order message.

975 In any of the above cases, it is expected that the Pharmaceutical Adviser has access to the medical record of the patient. It is expected that there are several systems that can work to validate the same prescription. In this case, the Prescription Order can be forwarded to other applications, which will also implement the role of Pharmaceutical Adviser. The management of this workflow is left to the 980 applications. To support expansions (cascading of clinical reviews and validation), parameter “Clinical Validation Status” should be considered The pharmaceutical Advice can also consist of substitution of the requested medication for another. This is frequent, and it is necessary in the case of Active Substance Prescription. 985 Note: In case the administration has already taken place, it is not possible for the medication to be substituted or re- encoded.

5.5.4.1.4 Response – ORP Message Semantics After the pharmaceutical advisor application processes the New Prescription item, a message of type ORP is sent confirming the status of the Order items. 990 For each ORC segment / group in the OMP message, an ORC will be sent in the ORP (response) message. The Status of the Order becomes “in Progress”. In the response, ORC-1 is “OK”, ORC- 5 is “In Progress”, and ORC-25 will show the status of the prescription as “Validation in Progress”.

5.5.4.1.5 Expected Actions 995 The Prescription Placer will update its internal prescription status to “in Progress”

5.5.4.2 Replacement of a Prescription Order Item

Prescription Pharmaceutical Placer Adviser

OMP^O09 Replaced Order: ORC-1 = RP OMP^O09 New Order: ORC-1 = RO

ORP^O10 Replaced Order ORC-1 = RQ ORP^O10 New Order: ORC-1 = OK

5.5.4.2.1 Trigger Events 1000 This message tells the Pharmaceutical Adviser that the prescription is cancelled by the Prescription Placer. It is triggered by an action in the Prescription Placer application.

5.5.4.2.2 Message Semantics In a message to replace one prescription item, an OMP message is sent containing two Order segments. The first ORC segment refers to the order that is to be replaced – the old order – with 1005 an ORC-1 value of “RP” – Replace request. The second ORC segment refers to the new order – the replacement, which has an ORC-1 value of RO – Replacement Order.

5.5.4.2.3 Expected Actions The pharmaceutical adviser application will send a confirmation message and will replace the prescribed item, also further notifying the other actors of this change.

1010 5.5.4.2.4 Response – ORP Message Semantics In response to a message to replace one prescription item, a message of type ORP is sent containing the two Order segments. The first ORC segment refers to the order that was requested to be replaced – the old order – with an ORC-1 value of “RQ” – Replaced as Requested Update. The second ORC segment refers 1015 to the new order – the replacement, which has an ORC-1 also value of OK.

5.5.4.2.5 Expected Actions The prescription placer considers the order as effectively replaced as of the moment that the response message is read.

5.5.4.3 Discontinuation of a Prescription Order Item 1020 Prescription Pharmaceutical Placer Adviser

OMP^O09 Replaced Order: ORC-1 = DC

ORP^O10 acknowledgement ORC-1 = DR

5.5.4.3.1 Trigger Events This message tells the Pharmaceutical Adviser that the prescription item is discontinued by the Prescription Placer. It is triggered by an action in the Prescription Placer application.

1025 5.5.4.3.2 Message Semantics In a message to discontinue one prescription item, an OMP message is sent containing the discontinued item. The ORC segment refers to the order that is to be discontinued– the old order – with an ORC-1 value of “DC” – Discontinue order request.

5.5.4.3.3 Expected Actions 1030 The pharmaceutical adviser application will send a confirmation message and will discontinue any subsequent action for the discontinued item, also further notifying the other actors of this change.

5.5.4.3.4 Response – ORP Message Semantics In response to a message to replace one prescription item, a message of type ORP is sent. 1035 The ORC segment referring to the order that was requested to be discontinued will have and ORC-1 value of “DR” – Discontinued as Requested.

5.5.4.3.5 Expected Actions The prescription placer considers the order as effectively discontinued as of the moment that the response message is read.

1040 5.5.4.4 Cancelation of a Prescription Order Item before validation

Prescription Pharmaceutical Placer Adviser

OMP Canceled Order: ORC-1 = CA

ORP acknowledgement ORC-1 = CR

5.5.4.4.1 Trigger Events This message tells the Pharmaceutical Adviser that the Prescription Item is canceled by the Prescription Placer. It is triggered by an action in the Prescription Placer application.

1045 5.5.4.4.2 Message Semantics In a message to cancel one Prescription Item, an OMP message is sent containing the canceled item. The ORC segment refers to the order that is to be canceled – the old order – with an ORC-1 value of “CA” – Cancel order request. ORC-5 has a value "CA" and ORC-25 = "P9;V0;D0;A0".

1050 5.5.4.4.3 Expected Actions The Pharmaceutical Adviser application will send a confirmation message.

5.5.4.4.4 Response – ORP Message Semantics In response to a message to replace one Prescription Item, a message of type ORP is sent.

The ORC segment referring to the order that was requested to be canceled will have and ORC-1 1055 value of “CR” – Canceled as Requested.

5.5.4.4.5 Expected Actions The Prescription Placer considers the order as effectively canceled as of the moment that the response message is read.

5.5.4.5 Rejection of a refusal from the Pharmaceutical Adviser

Prescription Pharmaceutical Placer Adviser

OMP^O09 Updated Order: ORC-1 = SC

ORP^O10 acknowledgement ORC-1 = OK

1060 5.5.4.5.1 Trigger Events This message is sent out to the Pharmaceutical Adviser when the Prescription Placer rejects a refusal of the Pharmaceutical Adviser (cfr. 5.6.4.9 Refusal of Prescription by the Pharmaceutical Adviser).

1065 5.5.4.5.2 Message Semantics This message is a re-initiation of the initial prescription. The Prescription Placer can include arguments why the refusal is rejected. ORC-1= “SC” – Status Change ORC-5 – Order Status = "IP", "In progress" 1070 ORC-25 is updated/reset to “P3;V0;D0;A0”

5.5.4.5.3 Expected Actions The Pharmaceutical Adviser is expected to take notice of the rejection of the refusal and act depending on the evaluation of the rejection: • The Pharmaceutical Adviser accepts the override and continues as validating a new 1075 prescription.

• The Pharmaceutical Adviser refuses the rejection and follows up with a new refusal, possibly with additional arguments.

5.5.4.6 Response – accepted rejection – ORP Message In response to a message informing of a rejection, a message of type ORP is sent back to the 1080 Prescription Placer.

5.5.4.6.1 Trigger Events This message is sent out after the Pharmaceutical Adviser acknowledges and accepts the rejection of the refusal of the prescription order item.

5.5.4.6.2 Message Semantics 1085 The ORC segment referring to the order is “OK”.

5.5.4.6.3 Expected Actions The Prescription Placer waits for the acknowledgement of the acceptation of the message by the Pharmaceutical Adviser, before effectively setting the updated status on the prescription item.

5.5.5 Security Considerations 1090 Intentionally left blank

5.5.6 Security Audit Considerations Intentionally left blank

5.5.7 Actor Specific Security Considerations Intentionally left blank 1095

5.5.8 Message Static Definitions

5.5.8.1 Prescription Order (request) - OMPÔ09 static definition for transaction PHARM-H1 1100 Table 5.5.8.1-1: OMPÔ09 static definition for Transaction PHARM-H1 OMPÔ09ÔMP_O09 Pharmacy/treatment Order Message Chapter

MSH Message Header 2 [{ SFT }] Software 2 [{ NTE }] Notes and Comments (for Header) 2 [ --- PATIENT begin PID Patient Identification 3 [ PD1 ] Additional Demographics 3 [{ NTE }] Notes and Comments (for Patient ID) 2 [ --- PATIENT_VISIT begin PV1 Patient Visit 3 [ PV2 ] Patient Visit – Additional Info 3 ] --- PATIENT_VISIT end [{ --- INSURANCE begin IN1 Insurance 6 [ IN2 ] Insurance Additional Info 6 [ IN3 ] Insurance Add'l Info - Cert. 6 }] --- INSURANCE end [ GT1 ] Guarantor 6 [{ AL1 }] Allergy Information 3 ] --- PATIENT end { --- ORDER begin ORC Common Order 4 [{ --- TIMING begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 }] --- TIMING end RXO Pharmacy/Treatment Order 4 [{ NTE }] Notes and Comments (for RXO) 2 { RXR } Pharmacy/Treatment Route 4 [{ --- COMPONENT begin RXC Pharmacy/Treatment Component 4 [{ NTE }] Notes and Comments (for each RXC) 2 }] --- COMPONENT end [{ --- OBSERVATION begin OBX Observation/Result 7 [{ NTE }] Notes and Comments (for OBX) 2 }] --- OBSERVATION end [{ FT1 }] Financial Transaction 6 [ BLG ] Billing Segment 6 } --- ORDER end

5.5.8.2 Prescription Order (response - ORP^O10 static definition for transaction PHARM-H1

1105 Table 5.5.8.2-1: ORPÔ10 static definition for Transaction PHARM-H1 ORPÔ10ÔRP_O10 Description Chapter

MSH Message Header 2 MSA Message Acknowledgment 2 [{ ERR }] Error 2 [{ SFT }] Software 2 [{ NTE }] Notes and Comments (for Response Header) 2 [ --- RESPONSE begin [ --- PATIENT begin PID Patient Identification 3 [{ NTE }] Notes and Comments (for Patient ID) 2 ] --- PATIENT end { --- ORDER begin ORC Common Order 4 [{ --- TIMING begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 }] --- TIMING end [ --- ORDER_DETAIL begin RXO Pharmacy/Treatment Order 4 [{ NTE }] Notes and Comments (for RXO) 2 { RXR } Pharmacy/Treatment Route 4 [{ --- COMPONENT begin RXC Pharmacy/Treatment Component 4 [{ NTE }] Notes and Comments (for each RXC) 2 }] --- COMPONENT end ] --- ORDER_DETAIL end } --- ORDER end ] --- RESPONSE end

Add Section 5.6

5.6 Validated Order – PHARM-H2 1110 This section corresponds to Transaction PHARM-H2 of the IHE Technical Framework. Transaction PHARM-H2 is used by the Pharmaceutical Adviser and Prescription Placer and Medication Dispenser actors.

5.6.1 Scope

5.6.2 Use Case Roles

Pharmaceutical Prescription Adviser Placer

Validated Order 1115

Pharmaceutical Medication Adviser Dispenser

Validated Order

Actor: Pharmaceutical Adviser 1120 Role: Validate Prescriptions, replace (substitute) prescription lines, receive replaced prescription lines Actor: Prescription Placer Role: Accept validations, accepted changed prescriptions Actor: Medication Dispensers 1125 Role: Receive new validated orders

5.6.3 Referenced Standard HL7 version 2.5:

• Chapter 2: "Control"  generic segments and data types 1130 • Chapter 3: "ADT"  PID and PV1 segments • Chapter 6: "Financial Management"  IN1, IN2, IN3 segments • Chapter 4: "Order Entry"  other segments • Chapter 7: “Observation Reporting”  OBX segment

1135 5.6.4 Interaction Diagram

Prescription Pharmaceuti Medication Placer cal Adviser Dispenser

RDE^O11 Validated Order: ORC-1 = SC RDE^O11 New Validated Order: ORC-1 = NW

RRE^O12 acknowledgement ORC-1 = OK RRE^O12 acknowledgement ORC-1 = OK

1140 5.6.4.1 Validated Order - Accepted This message contains the validation of a prescription and additional information provided by the pharmacist concerning the validation. It is used to indicate to the Prescription Placer that the order is in progress. Prescription Pharmaceutical Placer Adviser

RDE^O11 Validated Order: ORC-1 = SC

RRE^O12 acknowledgement ORC-1 = OK

1145

5.6.4.1.1 Trigger Events This message is sent out after the pharmaceutical adviser provides advice for a new prescription order.

5.6.4.1.2 Message Semantics 1150 When sending the Validated Order, the Pharmaceutical Advisor will append the advice to the existing prescription information. This advice will be for the complete prescription, and also for each prescription line. The validated order data is to be coded in the segments RXE [{ NTE }] { TQ1 [{ TQ2 }] } {RXR} [{RXC}]. 1155 ORC-1= “SC” – Status Change ORC-5 – Order Status = “In Progress” ORC-25 is updated to “Validation in Progress”, or “Validation Complete” (see Table 4.5.1-1 Detailed order status) If the pharmaceutical advice is complete and the prescription is validated, then ORC-25 is 1160 updated.

5.6.4.1.3 Expected Actions The Prescription placer is expected to take notice of the status of the message.

5.6.4.2 Response – RRE Message

5.6.4.2.1 Trigger Events 1165 This message is sent out after the prescription placer acknowledges the advice for the prescription order.

5.6.4.2.2 Message Semantics The ORC segment referring to the order has ORC-1 = “OK”.

5.6.4.2.3 Expected Actions 1170 The pharmaceutical adviser acknowledges that the prescription placer has received the validation information, and decides whether to wait or not for the acknowledgement of the status change by the prescription placer, before sending the messages for dispensing.

5.6.4.3 Substitution by the Pharmaceutical Adviser

Prescription Pharmaceutical Placer Adviser

RDE^O11 Validated Order: ORC-1 = SC

RRE^O12 acknowledgement ORC-1 = OK

1175 5.6.4.3.1 Trigger Events This message is sent out after the pharmaceutical adviser provides advice for a new prescription order, substituting the medication.

5.6.4.3.2 Message Semantics When sending the Validated Order, the Pharmaceutical Advisor will append the advice to the 1180 existing prescription information and use the segment RXE to detail the medication that will be used as substitution for the prescription order items. ORC-1= “SC” – Status Change ORC-5 – Order Status = “In Progress” ORC-25 is updated to “Validation in Progress”, or “Validation Complete” (see Table 4.5.1-1 1185 Detailed order status) If the pharmaceutical advice is complete and the prescription is validated, then ORC-25 is updated.

5.6.4.3.3 Expected Actions The prescription placer is expected to take notice of the status of the message.

1190 5.6.4.4 Response – accepted substitution – RRE Message In response to a message informing of a substitution, a message of type RRE is sent back to the Pharmaceutical Adviser.

5.6.4.4.1 Trigger Events This message is sent out after the prescription placer acknowledges and accepts the substitution 1195 of the prescription order item.

5.6.4.4.2 Message Semantics The ORC segment referring to the order is “OK”.

5.6.4.4.3 Expected Actions According to local rules, the pharmaceutical adviser decides whether to wait or not for the 1200 acknowledgement of the status change by the prescription placer, before sending the messages for dispensing.

1205 5.6.4.5 New Validated Order

Pharmaceutical Medication Adviser Dispenser

RDE^O11 New Validated Order: ORC-1 = NW

RRE^O12 acknowledgement ORC-1 = OK

5.6.4.5.1 Trigger Events 1210 This message is sent out when the pharmaceutical advisor submits the prescription order for dispensing – which may or not be the same trigger as for message Validated Order - Accepted.

5.6.4.5.2 Message Semantics The ORC segment referring to the order has ORC-1 = “NW”, as it is a new order for dispense. ORC-5 – Order Status = “In Progress” 1215 ORC-25 is updated to “Dispense in Progress” (see Table 4.5.1-1 Detailed order status)

5.6.4.5.3 Expected Actions The medication dispenser is expected to trigger the dispensing of that medication and take the necessary actions for delivering the medication to the patient.

5.6.4.5.4 Response – accepted dispensing – RRE Message 1220 In response to a message informing of a substitution, a message of type RRE is sent back to the Pharmaceutical Adviser.

5.6.4.5.5 Trigger Events This message is sent out after the medication dispenser acknowledges the dispense of the prescription order item. 1225

5.6.4.5.6 Message Semantics The medication dispenser accepts the validated order for dispensing with an ORC-1 value of “OK”.

5.6.4.5.7 Expected Actions 1230 The pharmaceutical advisor acknowledges the beginning of the dispensing process.

5.6.4.6 Replacement of a Prescription Order Item

Pharmaceutical Medication Adviser Dispenser

RDE^O11 Replaced Order: ORC-1 = RU RDE^O11 New Order: ORC-1 = RO

RRE^O12 Replaced Order ORC-1 = RQ RRE^O12 New Order: ORC-1 = OK

5.6.4.6.1 Trigger Events 1235 This message is sent out when the pharmaceutical advisor requests the replacement of an existing order item that had previously been sent to the dispenser.

5.6.4.6.2 Message Semantics The first ORC segment refers to the order that is to be replaced – the old order – with an ORC-1 value of “RU” – Replaced Unsolicited. The second ORC segment refers to the new order – the 1240 replacement, which has an ORC-1 value of RO – Replacement Order.

5.6.4.6.3 Expected Actions The medication dispenser is expected to trigger the dispensing of the new medication order item, and discontinue the dispensing of the replaced (old) medication order item.

5.6.4.7 Response – accepted dispensing – RRE Message 1245 In response to a message informing of a replacement, a message of type RRE is sent back to the Pharmaceutical Adviser.

5.6.4.7.1 Trigger Events This message is sent out after the medication dispenser acknowledges the dispense of the 1250 prescription order item.

5.6.4.7.2 Message Semantics The medication dispenser accepts the new order item for dispensing with an ORC-1 value of “OK”. The old order item is reported back with the status “RQ” – replaces as requested.

5.6.4.7.3 Expected Actions 1255 The pharmaceutical advisor acknowledges the beginning of the dispensing process.

5.6.4.8 Discontinuation of a Prescription Order Item

Pharmaceutical Medication Adviser Dispenser

RDE^O11 Replaced Order: ORC-1 = DC

RRE^O12 acknowledgement ORC-1 = DR

5.6.4.8.1 Trigger Events 1260 This message tells the Medication Dispenser that the prescription item is discontinued. It is triggered by an action in the Pharmaceutical Adviser, possibly as a reaction to a similar request from the Prescription Placer application.

5.6.4.8.2 Message Semantics In a message to discontinue one prescription item, an RDE message is sent containing the 1265 discontinued item. The ORC segment refers to the order that is to be discontinued– the old order – with an ORC-1 value of “DC” – Discontinue order request.

5.6.4.8.3 Expected Actions The Medication Dispenser application will send a confirmation message and will discontinue any subsequent action for the discontinued item, also further notifying the other actors of this change. 1270

5.6.4.8.4 Response – RRE Message Semantics In response to a message to replace one prescription item, a message of type RRE is sent. The ORC segment referring to the order will have and ORC-1 value of “DR” – Discontinued as Requested.

1275 5.6.4.8.5 Expected Actions The Pharmaceutical Adviser considers the order as effectively discontinued as of the moment that the response message is read.

5.6.4.9 Refusal of Prescription by the Pharmaceutical Adviser

Prescription Pharmaceutical Placer Adviser

RDE^O11 Validated Order: ORC-1 = SC

RRE^O12 Acknowledgement ORC-1 = OK

1280 5.6.4.9.1 Trigger Events This message is sent out to the Prescription Placer after the Pharmaceutical Adviser refuses the Medication Order.

5.6.4.9.2 Message Semantics When sending the Validated Order, the Pharmaceutical Adviser will append the reason for 1285 refusal to the existing prescription information. ORC-1= “SC” – Status Change ORC-5 – Order Status = "DC", the status proposed by the Pharmacist ORC-25 is updated to “Validation Complete”.

5.6.4.9.3 Expected Actions 1290 The Prescription Placer is expected to take notice of the status of the message.

5.6.4.10 Response – accepted refusal – RRE Message In response to a message informing of a refusal, a message of type RRE is sent back to the Pharmaceutical Adviser.

5.6.4.10.1 Trigger Events 1295 This message is sent out after the Prescription Placer acknowledges and accepts the refusal of the Prescription Order Item. If the Prescription Placer wants to order the Prescription Item again, a new Medication Order should be sent.

5.6.4.10.2 Message Semantics 1300 The ORC segment referring to the order is “OK”.

5.6.4.10.3 Expected Actions The Pharmaceutical Adviser waits for the acknowledgement of the status change by the Prescription Placer, before effectively setting the refusal status (discontinued) on the Prescription Item.

1305 5.6.4.11 Change of validation by a second Pharmaceutical Adviser

Prescription Pharmaceutical Pharmaceutical Placer Adviser Adviser

RDE^O11 Validated Order: ORC-1 = SC

RRE^O12 Acknowledgement ORC-1 = OK

RDE^O11 Validated Order: ORC-1 = SC

RRE^O12 Acknowledgement ORC-1 = OK

5.6.4.11.1 Trigger Events This message is sent out to the first Pharmaceutical Adviser and optionally to the Prescription Placer after the Pharmaceutical Adviser changes the initial validation.

1310 5.6.4.11.2 Message Semantics When sending the change in validation, the Pharmaceutical Adviser will append the reason for this change to the existing prescription information. ORC-1= “SC” – Status Change ORC-5 – Order Status = "IP", "In progress" 1315 ORC-25 is updated to “P3;V2;D0;A0” if it is not the final validation or “P3;V3;D0;A0” if it is the final validation.

5.6.4.11.3 Expected Actions The first Pharmaceutical Adviser and optionally the Prescription Placer are expected to take notice of the status of the message.

1320 5.6.4.12 Response – change validation accepted – RRE Message In response to a message informing of a change in validation, a message of type RRE is sent back to the second Pharmaceutical Adviser.

5.6.4.12.1 Trigger Events This message is sent out from the first Pharmaceutical Adviser or Prescription Placer 1325 acknowledges and accepts the change in validation of the prescription order item.

5.6.4.12.2 Message Semantics The ORC segment referring to the order is “OK”.

5.6.4.12.3 Expected Actions The second Pharmaceutical Adviser waits for the acknowledgement of the status change by the 1330 first Pharmaceutical Adviser or Prescription Placer, before effectively setting the new validation status on the Prescription Item.

5.6.5 Security Considerations Intentionally left blank

5.6.5.1 Security Audit Considerations 1335 Intentionally left blank

5.6.5.2 Actor Specific Security Considerations Intentionally left blank

5.6.6 Message Static Definitions

5.6.6.1 Validated Order (request) - RDE^O11 static definition for transaction 1340 PHARM-H2

Table 5.6.6.1-1 RDE^O11 static definition for Transaction PHARM-H2 RDE^O11^RDE_O11 Pharmacy/Treatment Encoded Order Chapter Message

MSH Message Header 2 [{ SFT }] Software 2 [ UAC ] User Authentication Credential 2 [{ NTE }] Notes and Comments (for Header) 2 [ --- PATIENT begin PID Patient Identification 3 [ PD1 ] Additional Demographics 3 [{ NTE }] Notes and Comments (for Patient ID) 2 [ --- PATIENT_VISIT begin PV1 Patient Visit 3 [ PV2 ] Patient Visit – Additional Info 3 ] --- PATIENT_VISIT end [{ --- INSURANCE begin IN1 Insurance [ IN2 ] Insurance Additional Information 6 [ IN3 ] Insurance Additional Information, 6 Certification }] --- INSURANCE end [ GT1 ] Guarantor 6 [{ AL1 }] Allergy Information 3 ] --- PATIENT end { --- ORDER begin ORC Common Order 4 [{ --- TIMING begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 }] --- TIMING end [ --- ORDER_DETAIL begin RXO Pharmacy/Treatment Prescription Order 4 [{ NTE }] Notes and Comments (for RXO) 2 { RXR } Pharmacy/Treatment Route 4 [{ --- COMPONENT begin RXC Pharmacy/Treatment Component (for RXO) 4 [{ NTE }] Notes and Comments (for each RXC) 2 }] --- COMPONENT end ] --- ORDER_DETAIL end RXE Pharmacy/Treatment Encoded Order 4 [{ NTE }] Notes and Comments (for RXE) 2

RDE^O11^RDE_O11 Pharmacy/Treatment Encoded Order Chapter Message

{ --- TIMING_ENCODED begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 } --- TIMING_ENCODED end { RXR } Pharmacy/Treatment Route 4 [{ RXC }] Pharmacy/Treatment Component (for RXE) 4 [{ --- OBSERVATION begin OBX Results 7 [{ NTE }] Notes and Comments (for OBX) 2 }] --- OBSERVATION end [{ FT1 }] Financial Detail 6 [ BLG ] Billing Segment 4 [{ CTI }] Clinical Trial Identification 7 } --- ORDER end

5.6.6.2 Validated Order (response) - RRE^O12 static definition for transaction 1345 PHARM-H2

Table 5.6.6.2-1: RRE^O12 static definition for Transaction PHARM-H2 RRE^O12^RRE_O12 Pharmacy/Treatment Encoded Order Chapter Acknowledgment Message

MSH Message Header 2 MSA Message Acknowledgment 2 [{ ERR }] Error 2 [{ SFT }] Software 2 [ UAC ] User Authentication Credential 2 [{ NTE }] Notes and Comments (for Header) 2 [ --- RESPONSE begin [ --- PATIENT begin PID Patient Identification 3 [{ NTE }] Notes and Comments (for PID) 2 ] --- PATIENT end { --- ORDER begin ORC Common Order 4 [{ --- TIMING begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 }] --- TIMING end [ --- ENCODING begin RXE Pharmacy/Treatment Encoded Order 4 [{ NTE }] Notes and Comments (for RXE) 2 { --- TIMING_ENCODED begin TQ1 Timing/Quantity 4 ______65 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

RRE^O12^RRE_O12 Pharmacy/Treatment Encoded Order Chapter Acknowledgment Message

[{ TQ2 }] Timing/Quantity Order Sequence 4 } --- TIMING_ENCODED end { RXR } Pharmacy/Treatment Route 4 [{ RXC }] Pharmacy/Treatment Component 4 ] --- ENCODING end } --- ORDER end ] --- RESPONSE end

1350 5.7 Medication Preparation Report – PHARM-H3 This section corresponds to Transaction PHARM-H3 of the IHE Technical Framework. Transaction PHARM-H3 is used by the Medication Dispenser and Medication Administration Informer and Prescription Placer and Pharmaceutical Adviser actors.

5.7.1 Scope 1355 This transaction informs, after a dispensing event, the Prescription Placer, Pharmaceutical Adviser and Medication Administration informer about the dispense availability for the requested medication.

5.7.2 Use Case Roles

Medication Prescription Dispenser Placer

Dispensed Medication

Medication Pharmaceutical Dispenser Adviser

Dispensed Medication 1360

Medication Medication Dispenser Administration Informer

Dispensed Medication

Actor: Prescription Placer Role: Accept dispense events 1365 Actor: Pharmaceutical Adviser Role: Accept dispense events Actor: Medication Dispenser ______67 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

Role: Send medication preparation reports, Send dispense events Actor: Medication Administration Informer 1370 Role: Accept new medication preparation reports

5.7.3 Referenced Standard HL7 version 2.5: • Chapter 2: "Control"  generic segments and data types • Chapter 3: "ADT"  PID and PV1 segments 1375 • Chapter 6: "Financial Management"  IN1, IN2, IN3 segments • Chapter 4: "Order Entry"  other segments • Chapter 7: “Observation Reporting”  OBX segment

5.7.4 Interaction Diagram

Prescription Pharmaceutical Medication Administration Placer Adviser Dispenser Informer

RGV^O15 New Dispense Report: ORC-1 = SC RGV^O15 New Dispense Report : ORC-1 = NW

RRG^O16 acknowledgement ORC-1 = OK RRG^O16 acknowledgement ORC-1 = OK

RGV^O15 New Dispense Report: ORC-1 = SC

RRG^O16 acknowledgement ORC-1 = OK

1380

5.7.4.1 Preparation Event (RGV)

Prescription Medication Placer Dispenser

RGV^O15 New Dispense Report: ORC-1 = SC

RRG^O16 acknowledgement ORC-1 = OK

1385 5.7.4.1.1 Trigger Events When medication becomes available for a patient, and is ready to be administered, a message of type RGV is sent to the Prescription Placer.

5.7.4.1.2 Message Semantics The ORC segment referring to the order has ORC-1 = “SC”, to inform that the existing order is 1390 updated. ORC-5 – Order Status = “In Progress”; ORC-25 is updated to “Dispense in Progress”, or “Dispense Complete” (see Table 4.5.1-1 Detailed order status) The content about the medication effectively dispensed is within segments RXG{TQ1 [{ TQ2 }]}{ RXR } [{ RXC }]{ [ OBX ] [{ NTE }]}.

1395 5.7.4.1.3 Expected Actions Upon receiving the message, the Prescription Placer will update the status of the prescription item to “Dispensed”, if the Dispense is complete. The Pharmaceutical Adviser also updates the state of the prescription. The Medication Application Informer associates the specific medication (physical product) to the 1400 (scheduled) administration event. Both the Prescription Order Placer, the Medication Dispenser and the Medication Administration informer will be informed of any insufficient (partial) dispensing. The actions to be taken in this case depend on the particular implementations.

5.7.4.2 Preparation Event Response (RRG)

1405 5.7.4.2.1 Trigger Events Upon accepting the Medication Preparation Report which contains the updated prescription order, the Pharmaceutical Adviser will send a response message.

5.7.4.2.2 Message Semantics Since this is an acknowledgement message, ORC-1 = “OK”.

1410 5.7.4.2.3 Expected Actions The Medication Dispenser accepts the order status update.

5.7.4.3 Preparation Event (RGV)

Pharmaceutical Medication Adviser Dispenser

RGV^O15 New Dispense Report: ORC-1 = SC

RRG^O16 acknowledgement ORC-1 = OK

5.7.4.3.1 Trigger Events 1415 When medication becomes available for a patient, and is ready to be administered, a message of type RGV is sent to the Pharmaceutical Adviser.

5.7.4.3.2 Message Semantics The ORC segment referring to the order has ORC-1 = “SC”, to inform that the existing order is updated. 1420 ORC-5 – Order Status = “In Progress”; ORC-25 is updated to “Dispense in Progress”, or “Dispense Complete” (see Table 4.5.1-1 Detailed order status) The content about the medication effectively dispensed is within segments RXG{TQ1 [{ TQ2 }]}{ RXR } [{ RXC }]{ [ OBX ] [{ NTE }]}.

5.7.4.3.3 Expected Actions 1425 Upon receiving the message, the Pharmaceutical Adviser will update the status of the prescription item to “Dispensed”, if the Dispense is complete.

5.7.4.4 Preparation Event Response (RRG)

5.7.4.4.1 Trigger Events 1430 Upon accepting the Medication Preparation Report which contains the updated prescription order, the Pharmaceutical Adviser will send a response message.

5.7.4.4.2 Message Semantics Since this is an acknowledgement message, ORC-1 = “OK”.

5.7.4.4.3 Expected Actions 1435 The Medication Dispenser accepts the order status update.

5.7.4.5 New Medication Preparation Report (RGV)

Medication Administration Dispenser Informer

RGV^O15 New Dispense Report : ORC-1 = NW

RRG^O16 acknowledgement ORC-1 = OK

5.7.4.5.1 Trigger Events 1440 When medication becomes available for a patient, and is ready to be administered, a message of type RGV is sent to the Administration Informer.

5.7.4.5.2 Message Semantics The ORC segment referring to the order has ORC-1 = “NW”, as it is a new order for dispense. ORC-5 – Order Status = “In Progress” 1445 ORC-25 is updated to “Dispense in Progress”, or “Dispense Complete” (see Table 4.5.1-1 Detailed order status) The content about the medication effectively dispensed is associated with segments RXG{TQ1 [{ TQ2 }]}{ RXR } [{ RXC }]{ [ OBX ] [{ NTE }]}.

1450 5.7.4.5.3 Expected Actions The Medication Administration Informer associates the specific medication (physical product) to the (scheduled) administration event.

5.7.4.6 Preparation Event Response (RRG)

5.7.4.6.1 Trigger Events 1455 Upon accepting the Medication Preparation Report which contains the new prescription order, the Medication Administration Informer will prepare and schedule the administration of the medication and send a response message.

5.7.4.6.2 Message Semantics Order Item status (ORC-25) is updated to “Administration Planned” or “Administration in 1460 Progress”.

5.7.4.6.3 Expected Actions The Medication Dispenser accepts the order status update.

5.7.5 Message Static Definitions

5.7.5.1 Medication Dispense Report (request) - RGV^O15 static definition for 1465 transaction PHARM-H3

Table 5.7.5.1-1: RGV^O15 static definition for Transaction PHARM-H3 RGV^O15^RGV_O15 Pharmacy/Treatment Give Chapter

MSH Message Header 2 [{ SFT }] Software 2 [{ NTE }] Notes and Comments (for Header) 2 [ --- PATIENT begin PID Patient Identification 3 [{ NTE }] Notes and Comments (for PID) 2 [{ AL1 }] Allergy Information 2 [ --- PATIENT_VISIT begin PV1 Patient Visit 3 [ PV2 ] Patient Visit – Additional Info 3 ] --- PATIENT_VISIT end ] --- PATIENT end { --- ORDER begin ORC Common Order 4 [{ --- TIMING begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 ______72 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

RGV^O15^RGV_O15 Pharmacy/Treatment Give Chapter

}] --- TIMING end [ --- ORDER_DETAIL begin RXO Pharmacy /Treatment Order 4 [ --- ORDER_DETAIL_SUPPLEMENT begin [{ NTE }] Notes and Comments (for RXO) 2 { RXR } Pharmacy/Treatment Route 4 [{ --- COMPONENTS begin RXC Pharmacy/Treatment Component 4 [{ NTE }] Notes and Comments (for each RXC) 2 }] --- COMPONENTS end ] --- ORDER_DETAIL_SUPPLEMENT end ] --- ORDER_DETAIL end [ --- ENCODING begin RXE Pharmacy/Treatment Encoded Order 4 { --- TIMING_ENCODED begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 } --- TIMING_ENCODED end { RXR } Pharmacy/Treatment Route 4 [{ RXC }] Pharmacy/Treatment Component 4 ] --- ENCODING end { --- GIVE begin RXG Pharmacy/Treatment Give 4 { --- TIMING_GIVE begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 } --- TIMING_GIVE end { RXR } Pharmacy/Treatment Route 4 [{ RXC }] Pharmacy/Treatment Component 4 { --- OBSERVATION begin [ OBX ] Observation/Results 7 [{ NTE }] Notes and Comments (for OBX) 2 } --- OBSERVATION end } --- GIVE end } --- ORDER end

5.7.5.2 Medication Dispense Report (response) - RRG^O16 static definition for 1470 transaction PHARM-H3

Table 5.7.5.2-1: RRG^O16 static definition for Transaction PHARM-H3 RRG^O16^RRG_O16 Pharmacy/Treatment Give Chapter Acknowledgment Message

MSH Message Header 2 MSA Message Acknowledgment 2 [{ ERR }] Error 2 [{ SFT }] Software 2 [{ NTE }] Notes and Comments (for Header) 2 [ --- RESPONSE begin [ --- PATIENT begin PID Patient Identification 3 [{ NTE }] Notes and Comments (for PID) 2 ] --- PATIENT end { --- ORDER begin ORC Common Order 4 [{ --- TIMING begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 }] --- TIMING end [ --- GIVE begin RXG Pharmacy/Treatment Give 4 { --- TIMING_GIVE begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 } --- TIMING_GIVE end

{ RXR } Pharmacy/Treatment Route 4 [{ RXC }] Pharmacy/Treatment Component 4 ] --- GIVE end } --- ORDER end ] --- RESPONSE end 1475

5.8 Administration Report – PHARM-H4 This section corresponds to Transaction PHARM-H4 of the IHE Technical Framework. Transaction PHARM-H4 is used by the Medication Administration Informer, Prescription Placer, Medication Dispenser and Pharmaceutical Adviser actors. 1480 The current scope of IHE-HMW only includes the events triggered upon administration itself. After this – e.g., Adverse Drug Events or other complications – are not yet covered by this profile. If several medications from a same prescription are given at the same time to one patient, then the Administration Report may send out more than one Administration Lines, but this is not 1485 recommended. Example: if a prescription is for Alprazolam, 3 times a day, and Paracetamol 500 mg per needed, when the nurse administers Alprazolam and also the Paracetamol (because the patient needed it) at 8 am, the same message could contain the two administration lines. It is however recommended that 2 messages are generated. 1490 If, for example, the nurse records in a single round the administration for all the patients in a ward room, then one message must be sent per patient for that single round. It is up to the application to split the administration events in separate messages. While this message can be used to inform the supply chain of the use of a medication (for example, in the case where the nurse administers a drug from the ER or the OR stock before a 1495 prescription), this message should not be used for informing the supply chain about, for example, dropped or lost medication.

5.8.1 Scope The currently defined scope is the simple inpatient scenario described in Volume 1, 4.3 - Intra- Hospital Workflow Process Flow.

1500 5.8.2 Use Case Roles

Medication Prescription Administration Placer Informer

Administration Report

Medication Medication Administration Dispenser Informer

Administration Report

Actor: Prescription placer 1505 Role: Receive administration reports, send acknowledgements Actor: Medication Dispenser Role: Receive administration reports, send acknowledgements Actor: Medication Administration Informer Role: Send administration reports, receive acknowledgements 1510

5.8.3 Referenced Standard HL7 version 2.5: • Chapter 2: "Control"  generic segments and data types • Chapter 3: "ADT"  PID and PV1 segments 1515 • Chapter 6: "Financial Management"  IN1, IN2, IN3 segments • Chapter 4: "Order Entry"  other segments • Chapter 7: “Observation Reporting”  OBX segment

5.8.4 Interaction Diagram

Prescription Medication Administration Placer Dispenser Informer

RAS^O17 New Administration Report: ORC-1 = SC

RRA^O18 acknowledgement ORC-1 = OK

RAS^O17 New Administration Report: ORC-1 = SC

RRA^O18 acknowledgement ORC-1 = OK

1520 5.8.4.1 New Administration Report

5.8.4.1.1 Trigger Event When the nurse has administered a treatment, this transaction is triggered. This transaction is triggered for each administration moment, for each prescription. 1525 If for a single patient there are medications from two concurrent prescriptions, the application must also send different messages for the administrations concerning each prescription.

5.8.4.1.2 Message Semantics The Administration Report contains ORC-1 = “SC” and the detailed status will mention that Administration is In Progress. 1530 ORC-5 will be “IP” – In Progress, or “CM” if all the administration needed for the prescription has been given. In the case of Per Needed medication, since it may be impossible for the nurse to determine whether the patient will need more medication, the status is “in Progress”.

5.8.4.1.3 Expected Actions The Prescription Placer and Medication Dispenser will receive this information and update the 1535 status of the prescription.

5.8.4.2 Response

5.8.4.2.1 Trigger Events After the message has been received by the Prescription Placer, a response message (RRA) is sent back to the Medication Administration Informer.

1540 5.8.4.2.2 Message Semantics The Administration Report contains ORC-1 = “OK” and the detailed status will mention that Administration is In Progress, or complete. If the prescription placer determines that the administration was the last one of the prescription order item, then the status of the order item is set to complete and ORC-5 = “CM”.

1545 5.8.4.2.3 Expected Actions The Medication Administration Informer will notice and update the status change of the administration and of the prescription, if any.

5.8.4.3 Update Administration

5.8.4.3.1 Trigger Events 1550 This message is triggered when a previously administered item is to be updated. This can happen in case of some event in the administration itself (change of site, rejection by the patient), or in the case of changes in a continuous administration (like change of perfusion rate, etc.

5.8.4.3.2 Message Semantics The Administration Report contains ORC-1 = “OK” and the detailed status will mention that 1555 Administration is In Progress, or complete.

5.8.4.3.3 Expected Actions The Prescription Placer and Medication Dispenser will receive this information and update the status of the prescription.

5.8.4.4 Response

1560 5.8.4.4.1 Trigger Events After the message has been received by the Prescription Placer, a response message (RRA) is sent back to the Medication Administration Informer.

5.8.4.4.2 Message Semantics The Administration Report contains ORC-1 = “OK” and the detailed status will mention that 1565 Administration is In Progress, or complete. If the prescription placer determines that the administration was the last one of the prescription order item, then the status of the order item is set to complete and ORC-5 = “CM”.

5.8.4.4.3 Expected Actions The Medication Administration Informer will notice and update the status change of the 1570 administration and of the prescription, if any.

5.8.4.5 Cancel Administration

Prescription Medication Administration Placer Dispenser Informer

RAS^O17 New Administration Report: ORC-1 = OC

RRA^O18 acknowledgement ORC-1 = OK

RAS^O17 New Administration Report: ORC-1 = OC

RRA^O18 acknowledgement ORC-1 = OK

1575 5.8.4.5.1 Trigger Events This message is triggered when a previously administered item is canceled. This can happen in case of some event in the administration itself (change of site, rejection by the patient).

5.8.4.5.2 Message Semantics The Administration Report contains ORC-1 = “OC”, Service Canceled and the detailed status 1580 will mention that Administration is canceled. ORC-5 has the value "CA" and ORC-25 = "P3;V3;D2;A9" or "P3;V3;D3;A9", depending on the status of the dispense status.

5.8.4.5.3 Expected Actions The Prescription Placer and Medication Dispenser will receive this information and update the 1585 status of the administration.

5.8.4.6 Response

5.8.4.6.1 Trigger Events After the message has been received by the Prescription Placer, a response message (RRA) is sent back to the Medication Administration Informer.

1590 5.8.4.6.2 Message Semantics The Administration Report contains ORC-1 = “OK” and the detailed status will mention that Administration is canceled.

5.8.4.6.3 Expected Actions The Medication Administration Informer will notice and update the status change of the 1595 administration and of the prescription, if any.

5.8.5 Security Considerations Intentionally left blank

5.8.5.1 Security Audit Considerations Intentionally left blank

1600 5.8.5.2 Actor Specific Security Considerations Intentionally left blank

1605 5.8.6 Message Static Definitions

5.8.6.1 Administration Report (request) - RAS^O17 static definition for transaction PHARM-H4

Table 5.8.6.1-1: RAS^O17 static definition for Transaction PHARM-H4 RAS^O17^RAS_O17 Pharmacy/Treatment Administration Chapter

MSH Message Header 2 [{ SFT }] Software 2 [ UAC ] User Authentication Credential 2 [{ NTE }] Notes and Comments (for Header) 2 [ --- PATIENT begin PID Patient Identification 3 [ PD1 ] Additional Demographics 3 [{ NTE }] Notes and Comments (for PID) 2 [{ AL1 }] Allergy Information 2 [ --- PATIENT_VISIT begin PV1 Patient Visit 3 [ PV2 ] Patient Visit – Additional Info 3 ] --- PATIENT_VISIT end ] --- PATIENT end { --- ORDER begin ORC Common Order 4 [{ --- TIMING begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 }] --- TIMING end [ --- ORDER_DETAIL begin RXO Pharmacy /Treatment Order 4 [ --- ORDER_DETAIL_SUPPLEMENT begin [{ NTE }] Notes and Comments (for RXO) 2 { RXR } Pharmacy/Treatment Route 4 [{ --- COMPONENTS begin RXC Pharmacy/Treatment Component 4 [{ NTE }] Notes and Comments (for each RXC) 2 }] --- COMPONENTS end ] --- ORDER_DETAIL_SUPPLEMENT end ] --- ORDER_DETAIL end [ --- ENCODING begin RXE Pharmacy/Treatment Encoded Order 4 { --- TIMING_ENCODED begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 } --- TIMING_ENCODED end { RXR } Pharmacy/Treatment Route 4

RAS^O17^RAS_O17 Pharmacy/Treatment Administration Chapter

[{ RXC }] Pharmacy/Treatment Component 4 ] --- ENCODING end { --- ADMINISTRATION begin { RXA } Pharmacy/Treatment Administration 4 RXR Pharmacy/Treatment Route 4 [{ --- OBSERVATION begin OBX Observation/Result 7 [{ NTE }] Notes and Comments (for OBX) 2 }] --- OBSERVATION end } --- ADMINISTRATION end [{ CTI }] Clinical Trial Identification 7 } --- ORDER end

1610 5.8.6.2 Administration Report (response) - RRA^O18 static definition for transaction PHARM-H4

Table 5.8.6.2-1: RRA^O18 static definition for Transaction PHARM-H4 RRA^O18^RRA_O18 Pharmacy/Treatment Administration Chapt Acknowledgment Message er

MSH Message Header 2 MSA Message Acknowledgment 2 [{ ERR }] Error 2 [{ SFT }] Software 2 [ UAC ] User Authentication Credential 2 [{ NTE }] Notes and Comments (for Header) 2 [ --- RESPONSE begin [ --- PATIENT begin PID Patient Identification 3 [{ NTE }] Notes and Comments (for PID) 2 ] --- PATIENT end { --- ORDER begin ORC Common Order 4 [{ --- TIMING begin TQ1 Timing/Quantity 4 [{ TQ2 }] Timing/Quantity Order Sequence 4 }] --- TIMING end [ --- ADMINISTRATION begin { RXA } Pharmacy/Treatment Administration 4 RXR Pharmacy/Treatment Route 4 ] --- ADMINISTRATION end } --- ORDER end ] --- RESPONSE end

1615 5.9 Advance Prescription Notification PHARM-H5 This section corresponds to Transaction PHARM-H5 of the IHE Technical Framework. Transaction PHARM-H5 is used for the Prescription Placer to notify the Medication Dispenser and Administration Informer or a prescription order, to allow for preparation in advance.

5.9.1 Scope 1620 This transaction is used when the Prescription Placer informs the Medication Administrator Informer and Medication Dispenser. This order contains the information concerning the treatment that is to be administered to a patient, e.g., for the Medication Administration Informer to populate the nurse worklist and to prepare the patient. It does not trigger the preparation and/or picking of the medication at the 1625 patient care location: in this case, as the nurse is the dispenser, the Validated Order is responsible to do so.

5.9.2 Use Case Roles

Prescription Medication Placer Administrator Informer

Administration Order

Prescription Medication Placer Dispenser

Administration Order 1630

Actor: Prescription Placer Role: Creates Administration Order, Updates Administration Orders, Cancels Administration Orders, receives acceptance or rejection from the Medication Administration Informer, Receives 1635 Administration Orders order Content Changes, and Status Changes.

Actor: Medication Administration Informer Role: Accepts Administration Orders. Notifies acceptance or rejection to the Prescription Placer, Notifies Prescription Placer of Administration Orders content and status changes.

5.9.3 Referenced Standard 1640 HL7 version 2.5: • Chapter 2: "Control"  generic segments and data types • Chapter 3: "ADT"  PID and PV1 segments • Chapter 6: "Financial Management"  IN1, IN2, IN3 segments • Chapter 4: "Order Entry"  other segments 1645 • Chapter 7: “Observation Reporting”  OBX segment

5.9.4 Interaction Diagram

Prescription Medication Administration Placer Dispenser Informer

OMP^O09 Advance Prescription: ORC-1 = NW

ORP^O10 acknowledgement ORC-1 = OK

OMP^O09 Advance Prescription: ORC-1 = NW

ORP^O10 acknowledgement ORC-1 = OK

1650 5.9.4.1 New Prescription - Administration Order

5.9.4.1.1 Trigger Event This transaction is triggered optionally when a prescription order is submitted. It is similar to 5.6.4.1 - New Prescription

5.9.4.1.2 Message Semantics 1655 The semantics are identical to 5.6.4.1 - New Prescription

5.9.4.1.3 Expected Actions The Medication Administration Informer is expected to populate the worklist and begin the preparation of the patient when appropriate.

5.9.4.2 Response – ORP Message

1660 5.9.4.2.1 Trigger Events This message is sent out after the Medication Administration Informer acknowledges the new prescription order.

5.9.4.2.2 Message Semantics The ORC segment referring to the order has ORC-1 = “OK”. ORC-25 does not assume or 1665 change the validation or dispense status.

5.9.4.2.3 Expected Actions The Prescription Placer acknowledges that the Medication Administration Informer has received the prescription.

5.9.5 Security Considerations 1670 Intentionally left blank

5.9.5.1 Security Audit Considerations Intentionally left blank

5.9.5.2 Actor Specific Security Considerations Intentionally left blank

1675 5.9.6 Message Static Definitions See 5.6.8 - Message Static Definitions for transaction PHARM-H1

5.10 Validated Order Confirmation PHARM-H6 This section corresponds to Transaction PHARM-H6 of the IHE Technical Framework. 1680 Transaction PHARM-H6 is used for the Pharmaceutical Adviser to notify the Medication Administration Informer that the prescription order is validated, to allow for administration preparation.

5.10.1 Scope This Validated Order confirmation contains the information that the prescription has been 1685 validated and therefore the nurse worklist can be populated, and the patient prepared. It triggers the final preparation at the patient care location.

5.10.2 Use Case Roles

Pharmaceutical Medication Adviser Administrator Informer

Administration Order

1690 Actor: Pharmaceutical Adviser Role: Creates new confirmation of order validation, receives acceptance or rejection of order validation. Actor: Medication Administration Informer Role: Receives new confirmation of order validation, accepts or rejects confirmation of order 1695 validation.

5.10.3 Referenced Standard HL7 version 2.5: • Chapter 2: "Control"  generic segments and data types • Chapter 3: "ADT"  PID and PV1 segments 1700 • Chapter 6: "Financial Management"  IN1, IN2, IN3 segments • Chapter 4: "Order Entry"  other segments • Chapter 7: “Observation Reporting”  OBX segment

5.10.4 Interaction Diagram

Pharmaceutical Administration Adviser Informer

RDE^O11 New Validated Order: ORC-1 = SC

RRE^O12 acknowledgement ORC-1 = OK

1705 5.10.4.1 New Validated Order

5.10.4.1.1 Trigger Events This message is sent out when the pharmaceutical advisor submits the prescription order for dispensing.

1710 5.10.4.1.2 Message Semantics The ORC segment referring to the order has ORC-1 = “SC”, as it is understood that the Medication Administration Informer has received the order. ORC-5 – Order Status = “In Progress” ORC-25 is updated to “Validation Complete” (see Table 4.5.1-1 Detailed order status)

1715 5.10.4.1.3 Expected Actions The nurse worklist is to be populated and preparation can be started. If there are detected differences between the instructions in transaction PHARM-H6 and Pharm-H3, the instructions in PHARM-H3 shall prevail. The Medication Administration Informer is free to accept the validated order or to reply with an 1720 error message.

5.10.4.1.4 Response – accepted validated order – RRE Message A message of type RRE is sent back to the Pharmaceutical Adviser.

5.10.4.1.5 Trigger Events This message is sent out after the Medication Administration Informer acknowledges the 1725 reception of the validated order item.

5.10.4.1.6 Message Semantics The medication dispenser accepts the validated order with an ORC-1 value of “OK”.

5.10.4.1.7 Expected Actions The pharmaceutical advisor acknowledges the beginning of the preparation.

1730 5.10.4.1.8 Response – Unable to accept validated order– RRE Message A message of type RRE is sent back to the Pharmaceutical Adviser.

5.10.4.1.9 Trigger Events This message is sent out after the Medication Administration Informer acknowledges the reception of the validated order item.

1735 5.10.4.1.10 Message Semantics The medication dispenser informs of the impossibility to accept the validated order with an ORC-1 value of “UA”.

5.10.4.1.11 Expected Actions The pharmaceutical advisor must determine the corrective actions to the validated order.

1740 5.10.5 Security Considerations Intentionally left blank

5.10.5.1 Security Audit Considerations Intentionally left blank

5.10.5.2 Actor Specific Security Considerations 1745 Intentionally left blank

5.10.6 Message Static Definitions See 5.7.6 - Message Static Definitions for transaction PHARM-H2

5.11 Exceptional Cases

1750 5.11.1 Cancel Prescription in advanced workflow

5.11.1.1 Cancel Prescription after validation, dispense or administration

Prescription Pharmaceutical Medication Administration Placer Adviser Dispenser Informer

OMP^O09 Canceled Order: ORC-1 = CA

ORP^O10 acknowledgement: ORC-1 = CR

RDE^O11 Canceled Order: ORC-1 = SC

RRE^O12 acknowledgement: ORC-1 = OK

RGV^O15 Canceled Order: ORC-1 = SC

RRG^O16 acknowledgement: ORC-1 = OK

5.11.1.1.1 Trigger Events This message is sent out from the Prescription Placer to the Pharmaceutical Adviser when the 1755 Prescription Placer cancels the prescription, after validation but before the completion of the last administration. Depending on the last status of the order, this canceling is propagated towards the last involved actor: • after validation: up to the Medication Dispenser, 1760 • after dispense or administration: up to the Administration Informer.

5.11.1.1.2 Message Semantics The initial message from Prescription Placer to Pharmaceutical Adviser is a cancel of a Prescription Item, sent by an OMP message containing the canceled item. The ORC segment refers to the order that is to be canceled with: 1765 ORC-1 = “CA” – Cancel order request. ORC-5 = “CA” ORC-25 is updated to a new value, depending on the last status of the order at the moment of canceling: • after validation: to “P9;V3;0;0”, 1770 • after dispense: to “P9;V3;D2;0” after partial dispense, “P9;V3;D3;0” after complete dispense • after administration: to “P9;V3;D3;A2”, as the administration isn't completed yet. Propagation of the cancelation is done by means of: ______89 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

• a RDE message from the Pharmaceutical Adviser to the Medication Dispenser, having ORC- 1 = “SC”, ORC-5 = “CA” and ORC-25 the status of the order as received in the OMP 1775 message. • a RGV message from the Medication Dispenser to the Administration Informer, if the dispense has already been performed, having ORC-1 = “SC”, ORC-5 = “CA” and ORC-25 the status of the order as received in the RDE message.

5.11.1.1.3 Expected Actions 1780 The Pharmaceutical Adviser is expected to take notice of the cancelation and send an acknowledgement. He will also propagate the cancelation of the prescription to the Medication Dispenser, as a status change of the order to "Canceled". The Medication Dispenser will take notice of the cancelation, send an acknowledgement and 1785 propagate the cancelation to the Administration Informer, if dispense or administration has already started. The Administration Informer in his turn will take notice of the cancelation and send an acknowledgement message to the Medication Dispenser.

5.11.1.2 Response – accepted cancel – ORP/RRE/RRG Message 1790 In response to the message indicating the cancelation of a Prescription Item, the Pharmaceutical Adviser responds with an ORP as acknowledgement. The ORC segment referring to the order that was requested to be canceled will have an ORC-1 value of “CR” – Canceled as Requested. The acknowledgments on the propagations are acknowledgements on the received status updates, having ORC-1 = “OK”: 1795 • from the Medication Dispenser to the Pharmaceutical Adviser this is an RRE message, • from the Administration Informer to the Medication Dispenser this is an RRG message.

5.11.1.2.1 Trigger Events This message is sent out after the Pharmaceutical Adviser, Medication Informer or Administration Informer acknowledges and accepts the cancelation of the Prescription Order 1800 Item.

5.11.1.2.2 Expected Actions The Prescription Placer waits for the acknowledgement of the acceptation of the message by the Pharmaceutical Adviser, before effectively setting the updated status on the Prescription Item.

5.11.1.3 Cancel Prescription after validation, dispense or administration with 1805 Advance Prescription Notification

Prescription Pharmaceutical Medication Administration Placer Adviser Dispenser Informer

OMP^O09 Canceled Order: ORC-1 = CA

ORP^O10 acknowledgement: ORC-1 = CR

OMP^O09 Canceled Order: ORC-1 = CA

ORP^O10 acknowledgement: ORC-1 = CR

OMP^O09 Canceled Order: ORC-1 = CA

ORP^O10 acknowledgement: ORC-1 = CR

5.11.1.3.1 Trigger Events This message is sent out from the Prescription Placer to the Pharmaceutical Adviser, Medication 1810 Dispenser and/or Administration Informer when the Prescription Placer cancels a prescription. To the Prescription Placer this is part of the PHARM-H1 transaction, to the Medication Dispenser and/or the Administration Informer this is an optional message in scope of the PHARM-H5 transaction.

5.11.1.3.2 Message Semantics 1815 The message sent by the Prescription Placer, is a cancel of a Prescription Item, being an OMP message containing the canceled item. The ORC segment refers to the order that is to be canceled with: ORC-1 = “CA” – Cancel order request. ORC-5 = “CA” 1820 ORC-25 is updated to a new value, depending on the last status of the order at the moment of canceling: • after validation: to “P9;V3;0;0”, • after dispense: to “P9;V3;D2;0” after partial dispense, “P9;V3;D3;0” after complete dispense • after administration: to “P9;V3;D3;A2”, as the administration isn't completed yet.

1825 5.11.1.3.3 Expected Actions The Pharmaceutical Adviser, Medication Dispenser and Administration Informer are expected to take notice of the cancelation and send an acknowledgement.

5.11.1.4 Response – accepted cancel – ORP Message In response to the message indicating the cancelation of a Prescription Item, the Pharmaceutical 1830 Adviser, Medication Dispenser and Administration Informer respond with an ORP as acknowledgement. The ORC segment referring to the order that was requested to be canceled will have an ORC-1 value of “CR” – Canceled as Requested.

5.11.1.4.1 Trigger Events This message is sent out after the Pharmaceutical Adviser, Medication Informer or 1835 Administration Informer acknowledges and accepts the cancelation of the Prescription Order Item.

5.11.1.4.2 Expected Actions The Prescription Placer waits for the acknowledgement of the acceptation of the message by the Pharmaceutical Adviser, Medication Dispenser and Administration Informer, before effectively 1840 setting the updated status on the Prescription Item.

5.11.2 Cancel Validation in advanced workflow

5.11.2.1 Cancel validation after dispense or administration

Prescription Pharmaceutical Medication Administration Placer Adviser Dispenser Informer

RDE^O11 Validated Order: ORC-1 = SC RDE^O11 Validated Order: ORC-1 = SC

RRE^O12 acknowledgement: ORC-1 = OK RRE^O12 acknowledgement: ORC-1 = OK

RGV^O15 Dispense Report: ORC-1 = SC

RRG^O16 acknowledgement: ORC-1 = OK

5.11.2.1.1 Trigger Events 1845 This message is sent out from the Pharmaceutical Adviser to Prescription Placer and the Medication Dispenser when the validation of a prescription item is canceled, after dispense but before the completion of the last administration. This canceling is propagated by the Medication Dispenser towards the Administration Informer.

5.11.2.1.2 Message Semantics 1850 The initial message from the Pharmaceutical Adviser to the Prescription Placer and the Medication Dispenser is the cancelation of the validation, sent by an RDE message containing ______92 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

the Prescription Item for which the validation is canceled. The ORC segment refers to the order that is to be canceled with: ORC-1 = “SC” – Status Changed 1855 ORC-5 = “DC” – Discontinue ORC-25 is updated to a new value, depending on the last status of the order at the moment of canceling: • after dispense: to “P3;V9;D2;0” after partial dispense, “P3;V9;D3;0” after complete dispense • after administration: to “P3;V9;D3;A2”, as the administration isn't completed yet. 1860 Propagation of the cancelation is done by means of: • a RGV message from the Medication Dispenser to the Administration Informer, if the dispense has already been performed, having ORC-1 = “SC”, ORC-5 = “DC” and ORC-25 the status of the order as received in the RDE message.

5.11.2.1.3 Expected Actions 1865 The Prescription Placer and Medication Dispenser are expected to take notice of the cancelation and send an acknowledgement. The Medication Dispenser will also propagate the cancelation of the prescription to the Administration Informer, as a status change of the order to "Discontinued".

5.11.2.2 Response – accepted cancel – RRE/RRG Message 1870 In response to the message indicating the cancelation of the validation of a Prescription Item, the Prescription Placer and Medication Dispenser respond with an RRE as acknowledgement. The ORC segment referring to the order for which the validation that was requested to be canceled will have an ORC-1 value of “OK”. The acknowledgment from the Administration Informer to the Medication Dispenser, on the 1875 propagation, is an RRG message, having ORC-1 = “OK”.

5.11.2.2.1 Trigger Events This message is sent out after the Prescription Placer, Medication Informer or Administration Informer acknowledges and accepts the cancelation of the validation of the Prescription Order Item.

1880 5.11.2.2.2 Expected Actions The Pharmaceutical Adviser waits for the acknowledgement of the acceptation of the message by the Prescription Placer and the Medication Dispenser, before effectively setting the updated validation status on the Prescription Item.

1885 5.11.2.3 Cancel validation after dispense or administration with Validated Order Confirmation

Prescription Pharmaceutical Medication Administration Placer Adviser Dispenser Informer

RDE^O11 Validated Order: ORC-1 = SC RDE^O11 Validated Order: ORC-1 = SC

RRE^O12 acknowledgement: ORC-1 = OK RRE^O12 acknowledgement: ORC-1 = OK

RDE^O11 Validated Order: ORC-1 = SC

RRE^O12 acknowledgement: ORC-1 = OK

5.11.2.3.1 Trigger Events This message is sent out from the Pharmaceutical Adviser to the Prescription Placer, Medication 1890 Dispenser and/or Administration Informer when the Prescription Placer cancels the validation of a Prescription Item. To the Prescription Placer this is part of the PHARM-H2 transaction, to the Medication Dispenser and/or the Administration Informer this is an optional message in scope of the PHARM-H6 transaction.

1895 5.11.2.3.2 Message Semantics The message sent by the Pharmaceutical Adviser, is a cancelation of a validation of a prescription item, being an RDE message containing the canceled item. The ORC segment refers to the order that is to be canceled with: ORC-1 = “SC” – Status Changed. 1900 ORC-5 = “DC” – Discontinued. ORC-25 is updated to a new value, depending on the last status of the order at the moment of canceling: • after dispense: to “P3;V9;D2;0” after partial dispense, “P3;V9;D3;0” after complete dispense • after administration: to “P3;V9;D3;A2”, as the administration isn't completed yet.

1905 5.11.2.3.3 Expected Actions The Prescription Placer, Medication Dispenser and Administration Informer are expected to take notice of the cancelation and send an acknowledgement.

5.11.2.4 Response – accepted cancel – ORP Message In response to the message indicating the cancelation of a Prescription Item, the Prescription 1910 Placer, Medication Dispenser and Administration Informer respond with an RRE as acknowledgement. The ORC segment referring to the order for which the validation was requested to be canceled will have an ORC-1 value of “OK”.

5.11.2.4.1 Trigger Events This message is sent out after the Prescription Placer, Medication Informer or Administration 1915 Informer acknowledges and accepts the cancelation of the validation of the Prescription Item.

5.11.2.4.2 Expected Actions The Pharmaceutical Adviser waits for the acknowledgement of the acceptation of the message by the Prescription Placer, Medication Dispenser and Administration Informer, before effectively setting the updated status on the Prescription Item. 1920

Add Appendix A to Volume 2

Appendix A - Common HL7 Message Segments for IHE HMW TF 1925 This section describes the common message segments used by the transactions IHE Hospital Medication Workflow. Each table represents a segment. Below the table are commented only the fields for which IHE Hospital Medication Workflow Technical Framework brings some precision on usage. The optional fields are not shown in the table, unless they require a particular comment within the 1930 context of the IHE Framework.

A.1 MSH - Message Header Segment HL7 v2.5: chapter 2 (2.15 Message control) This segment defines the intent, source, destination, and some specifics of the syntax of a message. 1935 Table A.1-1: MSH - Message Header SEQ LEN DT Usage Card. TBL# ITEM # ELEMENT NAME 1 1 ST R [1..1] 00001 Field Separator 2 4 ST R [1..1] 00002 Encoding Characters 3 227 HD O [0..1] 0361 00003 Sending Application 4 227 HD R [1..1] 0362 00004 Sending Facility 5 227 HD O [0..1] 0361 00005 Receiving Application 6 227 HD R [1..1] 0362 00006 Receiving Facility 7 26 TS R [1..1] 00007 Date/Time Of Message 8 40 ST X [0..0] 00008 Security 9 15 MS R [1..1] 00009 Message Type G 10 20 ST R [1..1] 00010 Message Control ID 11 3 PT R [1..1] 00011 Processing ID 12 60 VID R [1..1] 00012 Version ID 13 15 NM O [0..1] 00013 Sequence Number 14 180 ST X [0..0] 00014 Continuation Pointer 15 2 ID O [0..1] 0155 00015 Accept Acknowledgment Type 16 2 ID O [0..1] 0155 00016 Application Acknowledgment Type 7 3 ID RE [1..1] 0399 00017 Country Code 18 16 ID C [0..1] 0211 00692 Character Set 19 250 CE RE [0..1] 00693 Principal Language Of Message 20 20 ID C [0..1] 0356 01317 Alternate Character Set Handling Scheme 21 427 EI RE [0..*] 01598 Message Profile Identifier

MSH-1 Field Separator, required: The IHE Hospital Medication Workflow Technical Framework requires that applications support HL7-recommended value that is | (ASCII 124).

1940 MSH-2 Encoding Characters, required: This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. The IHE Hospital Medication Workflow Technical Framework requires that applications support HL7-recommended values ^~\& (ASCII 94, 126, 92, and 38, respectively). 1945 The use of the encoding characters as a part of a field requires the use of escape sequence (see Section Country Code (NM).

MSH-4 Sending Facility (HD), required: Components: ^ ^ 1950 The IHE Hospital Medication Workflow Technical Framework requires that this field be populated with: First component (required): Namespace ID. The name of the organizational entity responsible for the sending application. Second component (optional): The URI (OID) of the organizational entity responsible for the 1955 sending application. Third component (optional): The type of identification URI provided in the second component of this field. The codification of these three components is entirely site-defined. It may be detailed in the national extensions of this framework.

1960 MSH-6 Receiving Facility (HD), required: Components: ^ ^ The IHE Hospital Medication Workflow Technical Framework requires that this field be populated with: First component (required): Namespace ID. The name of the organizational entity responsible 1965 for the receiving application. Second component (optional): The URI (e.g., OID) of the organizational entity responsible for the receiving application. Third component (optional): The type of identification URI provided in the second component of this field. The codification of these three components is entirely site-defined. It may be 1970 detailed in the national extensions of this framework.

MSH-9 Message Type (MSG), required: Components: ^ ^ This field contains the message type, trigger event, and the message structure ID for the message. All three components are required. 1975 Its content is defined within each transaction-specific section of this document.

MSH-10 Message Control Id (ST), required: This field contains a number or other identifier that uniquely identifies the message. Each message should be given a unique identifier by the sending system. The receiving system will 1980 echo this ID back to the sending system in the Message Acknowledgment segment (MSA). The combination of this identifier and the name of the sending application (MSH-3) should be unique across the Healthcare Enterprise.

MSH-11 Processing ID (PT), required: 1985 Components: ^ HL7 definition: This field indicates whether to process a message as defined in HL7 Application (level 7) Processing rules. This IHE Hospital Medication Workflow Technical Framework mandates only the first component, with permitted values listed in HL7 table 0103 – Processing ID: 1990 HL7 Table 0103: Processing ID Value Meaning Comment D Debugging P Production T Training

MSH-12 Version ID (VID), required: Components: ^ ^ This field is matched by the receiving system to its own version to be sure the message will be interpreted correctly. The IHE Hospital Medication Workflow Technical framework requires the first component to be populated with a value starting with the character string "2.6" representing HL7 major release 2000 2.6. Release 2.5 and minor releases, like the release 2.5.1, are also supported by the Hospital Medication Workflow Technical Framework.

Valid examples: |2.6| |2.5.1| MSH-15 Accept Acknowledgment Type (ID), optional. IHE –Pharmacy can use the HL7 original or enhanced acknowledgement mode. 2005 MSH-16 Application Acknowledgment Type (ID), not supported for the same reason.

MSH-17 Country Code (ID), required if available. This field contains the country of origin for the message. The values to be used are those of ISO 2010 3166, with the 3-character (alphabetic form). Refer to HL7 Table 0399 - Country code Examples of valid values: JPN = Japan, USA = United States, GBR = United Kingdom, ITA = Italy, FRA = France, NLD = Netherlands.

2015 MSH-18 Character Set (ID), conditional. This field contains the character set for the entire message. Refer to HL7 table 0211 - Alternate character sets for valid values. Examples of valid values: ASCII: The printable 7-bit ASCII character set. 2020 8859/1: The printable characters from the ISO 8859/1 Character set used by Western Europe. This character set can still be used, but 8859/15 should be used by preference. This character set is the forward-compatible version of 8859/1 and includes new characters such as the Euro currency symbol. ISO IR87: Code for the Japanese Graphic Character set for information interchange (JIS X 0208- 2025 1990). UNICODE UTF-8: UCS Transformation Format, 8-bit form. Condition predicate: This field shall only be valued if the message uses a character set other than the 7-bit ASCII character set. Though the field is repeatable in HL7, IHE authorizes only one occurrence (i.e., one character set). The character set specified in this field is used for the 2030 encoding of all of the characters within the message. IHE - HMW does not recommend any character set; however, implementations must ensure the use of a character set that can satisfy the interoperability needs within each transaction.

2035 MSH-19 Principal Language of Message (CE), required if available. Coded from ISO 639. Examples: DE = German, EN = English, ES=Spanish, JA = Japanese, FR = French, NL = Dutch, IT = Italian

MSH-20 Alternate Character Set Handling Scheme (ID), conditional: 2040 HL7 definition: When any alternative character sets are used (as specified in the second or later iterations of MSH-18 character sets), and if any special handling scheme is needed, this component is to specify the scheme used, according to HL7 Table 0356- Alternate character set handling scheme as defined below: HL7 Table 0356 - Alternate character set handling scheme Value Description Comment ISO This standard is titled "Information This standard specifies an escape sequence from basic one byte 2022- Technology - Character Code Structure and character set to specified other character set, and vice versa. The 1994 Extension Technique". . escape sequence explicitly specifies what alternate character set to be evoked. Note that in this mode, the actual ASCII escape character is used as defined in the referenced ISO document. As noted in 1.7.1, escape sequences to/from alternate character set should occur within HL7 delimiters. In other words, HL7 delimiters are basic one byte characters only, and just before and just after delimiters, character encoding status should be the basic one byte set. 2.3 The character set switching mode specified in Note that the escape sequences used in this mode do not use the HL7 2.5, section2.7.2, “Escape sequences ASCII "esc" character, as defined in ISO 2022-1994. They are supporting multiple character sets” and section "HL7 escape sequences" as first defined in HL7 2.3, sec. 2.9.2. 2.A.46, "XPN – extended person name". (Also, note that sections 2.8.28.6.1and 2.9.2 in HL7 2.3 correspond to sections 2.16.93 and 2.7.2 in HL7 2. 5.) This is the default, indicating that there is no This is the default. character set switching occurring in this message. 2045 Condition predicate: This field shall be valued for messages using more than one character set.

MSH-21 Message Profile Identifier (EI), required if available. For IHE Hospital Medication Workflow Technical Framework, this field shall only be valued in the messages for which a Message Profile has been officially defined and identified. When 2050 multiple message profiles are listed in this field they should be (vendor specific, country specific) constraints of the IHE Hospital Medication Workflow Profile. Note that the overriding of IHE Hospital Medication Workflow Profile constraints is only allowed in national extensions to this framework.

A.2 NTE - Notes and Comment Segment 2055 HL7 v2.5: chapter 2 (2.15 Message control) This segment is used for sending notes and comments.

Information that can be coded in OBX segments or OBR segments shall not be sent in a NTE segment.

2060 Table A.2-1: NTE - Notes and Comment segment SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 4 SI R [1..1] 00096 Set ID – NTE 2 8 ID RE [0..1] 00097 Source of Comment 3 65536 FT RE [0..1] 00098 Comment 4 250 CE RE [0..1] 01318 Comment Type

NTE-1 Set ID - NTE (SI), required.

NTE-2 Source of Comment (ID), required if existing. 2065 IHE Hospital Medication Workflow Technical Framework populates this field with one of these values:

Table A.2-2: Source of Comment Value Meaning Comment L The source of the comment is the Pharmaceutical Advisor, Medication Dispenser, or the Administration Informer P Order Placer is the source of the comment O Other system is the source of the comment

2070 NTE-3 Comment (FT), required if available: This field contains the text of the comment. This text may be formatted. In order to delete an existing comment, the field shall contain a null value - empty quotation marks: “”. Comment text of identical type (NTE-4) and source (NTE-2) shall be included in the same occurrence of an NTE segment, and not be split over multiple segments. 2075 NTE-4 Comment Type (CE), required if available. The IHE Hospital Medication Workflow Technical Framework populates this field with one of these values:

2080

Table A.2-3: Comment Type Value Description Comment PA Prescription-wide Advice notes IA Prescription Item Advice notes PI Patient Instructions RE Remark PI Patient Instructions GI General Instructions

A.3 PID - Patient Identification Segment HL7 v2.5: chapter 3 (3.4.2) The PID segment is used by all applications as the primary means of communicating patient 2085 identification information. This segment contains permanent patient identifying and demographic information that, for the most part, is not likely to change frequently.

Table A.3-1: PID - Patient Identification segment SEQ LEN DT Usage Card. TBL# ITEM# ELEMENT NAME 1 4 SI O [0..1] 00104 Set ID – PID 2 20 CX X [0..0] 00105 Patient ID 3 250 CX R [1..*] 00106 Patient Identifier List 4 20 CX X [0..0] 00107 Alternate Patient ID - PID 5 250 XPN R [1..*] 00108 Patient Name 6 250 XPN O [0..*] 00109 Mother’s Maiden Name 7 26 TS RE [0..1] 00110 Date/Time of Birth 8 1 IS R [1..1] 0001 00111 Administrative Sex 9 250 XPN X [0..0] 00112 Patient Alias 10 250 CE O [0..*] 0005 00113 Race 11 250 XAD O [0..*] 00114 Patient Address 12 4 IS X [0..0] 0289 00115 County Code 13 250 XTN O [0..*] 00116 Phone Number - Home 14 250 XTN O [0..*] 00117 Phone Number - Business 15 250 CE O [0..1] 0296 00118 Primary Language 16 250 CE O [0..1] 0002 00119 Marital Status 17 250 CE O [0..1] 0006 00120 Religion 18 250 CX RE [0..1] 00121 Patient Account Number 19 16 ST O [0..1] 00122 SSN Number - Patient 20 25 DLN O [0..1] 00123 Driver's License Number - Patient 21 250 CX O [0..*] 00124 Mother's Identifier 22 250 CE O [0..1] 0189 00125 Ethnic Group

SEQ LEN DT Usage Card. TBL# ITEM# ELEMENT NAME 23 250 ST O [0..1] 00126 Birth Place 24 1 ID O [0..1] 0136 00127 Multiple Birth Indicator 25 2 NM O [0..1] 00128 Birth Order 26 250 CE O [0..1] 0171 00129 Citizenship 27 250 CE O [0..1] 0172 00130 Veterans Military Status 28 250 CE X [0..0] 0212 00739 Nationality 29 26 TS O [0..1] 00740 Patient Death Date and Time 30 1 ID O [0..1] 0136 00741 Patient Death Indicator 31 1 ID RE [0..1] 0136 01535 Identity Unknown Indicator 32 20 IS RE [0..1] 0445 01536 Identity Reliability Code 33 26 TS C [0..1] 01537 Last Update Date/Time 34 241 HD C [0..1] 01538 Last Update Facility 35 250 CE 0446 01539 Species Code 36 250 CE 0447 01540 Breed Code 37 80 ST 01541 Strain 38 250 CE 0429 01542 Production Class Code 39 250 CWE 0171 01840 Tribal Citizenship

2090 The specific usage of these fields, especially those fields with usage "O" (optional) in the table above, is explained in the national extensions.

PID-3 Patient Identifier List (CX), required, repeatable

Components: ^ ^ ^ 2095 ^ ^ ^ ^ ^ ^

Subcomponents for Assigning Authority (HD): & &

2100 Subcomponents for Assigning Facility (HD): & &

Subcomponents for Assigning Jurisdiction (CWE): & & & & & & & &

Subcomponents for Assigning Agency or Department (CWE): & & & & & & & &

This field contains the list of identifiers (one or more) used by the healthcare facility to uniquely identify a patient (e.g., medical record number, billing number, birth registry, national unique individual identifier, etc.). In Canada, the Canadian Provincial Healthcare Number should be 2115 sent in this field. The arbitrary term of “internal ID” has been removed from the name of this field for clarity. This field contains the Patient Identifier(s) as used by the hospital. The Assigning Authority and Identifier Type Code are mandatory.

2120 PID-5 Patient Name (XPN), required, repeatable This field contains the Patient Identifier(s) as used by the hospital. The Assigning Authority and Identifier Type Code are mandatory.

2125 Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 2130 ^ Repetition of this field is allowed for representing the same name in different character sets. Note that “last name prefix” is synonymous to “own family name prefix” of previous versions of HL7, as is “second and further given names or initials thereof” to “middle initial or name”. Multiple given names and/or initials are separated by spaces.

2135 HL7 Table 0200 - Name Type Value Description Comment A Alias Name B Name at Birth C Adopted Name D Display Name I Licensing Name L Legal Name M Maiden Name N Nickname /”Call me” Name/Street Name P Name of Partner/Spouse - obsolete Deprecated in V2.4 R Registered Name (animals only) S Coded Pseudo-Name to ensure anonymity T Indigenous/Tribal/Community Name U Unspecified

PID-7 Date/Time of Birth (TS), required if available

Components: ^ This field contains the patient’s date and time of birth. 2140 PID-8 Administrative Sex (IS), required This field contains the patient’s sex. Supported values are defined in User-defined Table 0001:

2145 User-defined Table 0001 - Administrative Sex Value Description Comment F Female M Male O Other U Unknown A Ambiguous N Not applicable

PID-10 Race (CE), optional, repeatable

Components: ^ ^ ^ ^ ^ This field refers to the patient’s race. Refer to User-defined Table 0005 - Race for suggested values. The second triplet of the CE data type for race (alternate identifier, alternate text, and name of alternate coding system) cannot be filled.

User-defined Table 0005 - Race Value Description Comment 1002-5 American Indian or Alaska Native 2028-9 Asian 2054-5 Black or African American 2076-8 Native Hawaiian or Other Pacific Islander 2106-3 White 2131-1 Other Race 2155 PID-11 Patient Address (XAD), optional, repeatable

Components: ^ ^ ^ ^ ^ ^

^ ^

2160 (IS)> ^ ^

^ ^ The Hospital Medication Workflow Technical Framework does not constrain the usage of this field, but reserves it for the patient’s main address. 2165 PID-13 Phone Number - Home (XTN), optional

Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ This field contains the patient’s personal phone numbers. All personal phone numbers for the patient are sent in the following sequence. The first sequence is considered the primary number (for backward compatibility). If the primary number is not sent, then a repeat delimiter is sent in 2175 the first sequence. Supported values for Fields Telecommunication Use Code are described in HL7 table 0201 HL7 Table 0201 - Telecommunication use code Value Description Comment PRN Primary Residence Number ORN Other Residence Number WPN Work Number VHN Vacation Home Number ASN Answering Service Number EMR Emergency Number NET Network (email) Address BPN Beeper Number

Supported values for Fields Telecommunication equipment type are described in HL7 table 0202 2180 HL7 Table 0202 - Telecommunication equipment type Value Description Comment PH Telephone FX Fax MD Modem CP Cellular Phone BP Beeper Internet Internet Address: Use Only If Telecommunication Use Code Is NET X.400 X.400 email address: Use Only If Telecommunication Use Code Is NET TDD Telecommunications Device for the Deaf

Value Description Comment TTY Teletypewriter

PID-16 Marital Status (CE), optional

Components: ^ ^ ^ ^ ^ This field contains the patient’s marital (civil) status. Refer to User-defined Table 0002 - Marital Status for suggested values.

User-defined Table 0002 - Marital Status Value Description Comment A Separated D Divorced M Married S Single W Widowed C Common law G Living together P Domestic partner R Registered domestic partner E Legally Separated N Annulled I Interlocutory B Unmarried U Unknown O Other T Unreported 2190 PID-17 Religion (CE), optional

Components: ^ ^ ^ ^ ^ 2195 IHE Pharmacy reserves this field for the patient’s religion. IHE Pharmacy does not impose additional constraints on this field.

PID-22 Ethnic Group (CE), optional

IHE Pharmacy reserves this field for defining the patient’s ancestry. Refer to HL7 User-defined Table 0189 - Ethnic Group for suggested values. The second triplet of the CE data type for ethnic group (alternate identifier, alternate text, and name of alternate coding system) is reserved for governmentally assigned codes. See HL7 v2.5, chapter 3, section 3.4.2.22.

2205 A.4 PV1 - Patient Visit Segment HL7 v2.5: chapter 3 (3.4.3) The PV1 segment is used by Registration/Patient Administration applications to communicate information on an account or visit-specific basis. Table A.4-1: PV1 - Patient Visit segment SEQ LEN DT Usage Card. TBL# ITEM# ELEMENT NAME 1 4 SI O [0..1] 00131 Set ID - PV1 2 1 IS R [1..1] 0004 00132 Patient Class 3 80 PL RE [0..1] 00133 Assigned Patient Location 4 2 IS O [0..1] 0007 00134 Admission Type 5 250 CX O [0..1] 00135 Preadmit Number 6 80 PL O [0..1] 00136 Prior Patient Location 7 250 XCN O [0..*] 0010 00137 Attending Doctor 8 250 XCN O [0..*] 0010 00138 Referring Doctor 9 250 XCN X [0..0] 0010 00139 Consulting Doctor 10 3 IS O [0..1] 0069 00140 Hospital Service 11 80 PL O [0..1] 00141 Temporary Location 12 2 IS O [0..1] 0087 00142 Preadmit Test Indicator 13 2 IS O [0..1] 0092 00143 Re-admission Indicator 14 6 IS O [0..1] 0023 00144 Admit Source 15 2 IS O [0..*] 0009 00145 Ambulatory Status 16 2 IS O [0..1] 0099 00146 VIP Indicator 17 250 XCN O [0..*] 0010 00147 Admitting Doctor 18 2 IS O [0..1] 0018 00148 Patient Type 19 250 CX RE [0..1] 00149 Visit Number 20 50 FC O [0..*] 0064 00150 Financial Class 21 2 IS O [0..1] 0032 00151 Charge Price Indicator 22 2 IS O [0..1] 0045 00152 Courtesy Code 23 2 IS O [0..1] 0046 00153 Credit Rating 24 2 IS O [0..*] 0044 00154 Contract Code 25 8 DT O [0..*] 00155 Contract Effective Date 26 12 NM O [0..*] 00156 Contract Amount 27 3 NM O [0..*] 00157 Contract Period 28 2 IS O [0..1] 0073 00158 Interest Code

SEQ LEN DT Usage Card. TBL# ITEM# ELEMENT NAME 29 4 IS O [0..1] 0110 00159 Transfer to Bad Debt Code 30 8 DT O [0..1] 00160 Transfer to Bad Debt Date 31 10 IS O [0..1] 0021 00161 Bad Debt Agency Code 32 12 NM O [0..1] 00162 Bad Debt Transfer Amount 33 12 NM O [0..1] 00163 Bad Debt Recovery Amount 34 1 IS O [0..1] 0111 00164 Delete Account Indicator 35 8 DT O [0..1] 00165 Delete Account Date 36 3 IS O [0..1] 0112 00166 Discharge Disposition 37 47 DLD O [0..1] 0113 00167 Discharged to Location 38 250 CE O [0..1] 0114 00168 Diet Type 39 2 IS O [0..1] 0115 00169 Servicing Facility 40 1 IS X [0..0] 0116 00170 Bed Status 41 2 IS O [0..1] 0117 00171 Account Status 42 80 PL O [0..1] 00172 Pending Location 43 80 PL O [0..1] 00173 Prior Temporary Location 44 26 TS O [0..1] 00174 Admit Date/Time 45 26 TS O [0..*] 00175 Discharge Date/Time 46 12 NM O [0..1] 00176 Current Patient Balance 47 12 NM O [0..1] 00177 Total Charges 48 12 NM O [0..1] 00178 Total Adjustments 49 12 NM O [0..1] 00179 Total Payments 50 250 CX O [0..1] 0203 00180 Alternate Visit ID 51 1 IS O [0..1] 0326 01226 Visit Indicator 52 250 XCN X [0..1] 0010 01274 Other Healthcare Provider 2210 The specific usage of these fields may be elaborated upon in the national extensions. The only field mandatory in segment PV1 is PV1-2 “Patient Class”. PV1-2 Patient Class, Required This field is used by systems to categorize patients by site. It does not have a consistent 2215 industry-wide definition. It is subject to site-specific variations. Refer to User-defined Table 0004 - Patient Class for suggested values. If the sender of this message does not know the patient class, it SHALL value the field PV1-2 “U”, which stands for “patient class unknown”.

PV1-3 Assigned Patient Location (PL), required if available

2220 Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^

This field contains the patient’s assigned location or the location to which the patient is being 2225 moved. The first component may be the nursing station for inpatient locations, or clinic or department, for locations other than inpatient. If a value exists in the fifth component (location status), it supersedes the value in PV1-40 - Bed Status.

PV1-19 Visit Number (CX), required if available

2230 Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ IHE requires that implementations use the CX data type. This field contains the unique number 2235 assigned to the patient visit. If a value is present, the identifier type code is mandatory.

A.5 ORC Common Order Segment HL7 v2.5: chapter 4 (4.5.1).

Table A.5-1: ORC – Common Order segment

SEQ LEN DT Usage Card. TBL# ITEM# ELEMENT NAME 1 2 ID R [1..1] 0119 00215 Order Control 2 22 EI C [0..1] 00216 Placer Order Number 3 22 EI C [0..1] 00217 Filler Order Number 4 22 EI C [0..1] 00218 Placer Group Number 5 2 ID C [0..1] 0038 00219 Order Status 6 1 ID O [0..1] 0121 00220 Response Flag 7 200 TQ X [0..0] 00221 Quantity/Timing 8 200 EIP O [0..1] 00222 Parent 9 26 TS R [1..1] 00223 Date/Time of Transaction 10 250 XCN O [0..*] 00224 Entered By 11 250 XCN O [0..*] 00225 Verified By 12 250 XCN C [0..*] 00226 Ordering Provider 13 80 PL O [0..1] 00227 Enterer's Location 14 250 XTN O [0..*] 00228 Call Back Phone Number 15 26 TS O [0..1] 00229 Order Effective Date/Time 16 250 CE O [0..1] 00230 Order Control Code Reason 17 250 CE O [0..1] 00231 Entering Organization 18 250 CE O [0..1] 00232 Entering Device 19 250 XCN R [1..*] 00233 Action By 20 250 CE O [0..1] 0339 01310 Advanced Beneficiary Notice Code 21 250 XON R [1..*] 01311 Ordering Facility Name 22 250 XAD O [0..*] 01312 Ordering Facility Address 23 250 XTN R [1..*] 01313 Ordering Facility Phone Number 24 250 XAD O [0..*] 01314 Ordering Provider Address 25 250 CWE C [0..1] 01473 Order Status Modifier 26 60 CWE C [0..1] 0552 01641 Advanced Beneficiary Notice Override Reason 27 26 TS O [0..1] 01642 Filler's Expected Availability Date/Time 28 250 CWE O [0..1] 0177 00615 Confidentiality Code 29 250 CWE O [0..1] 0482 01643 Order Type 30 250 CNE O [0..1] 0483 01644 Enterer Authorization Mode

2240 ORC-1 Order Control (ID), required This field holds the status for the order. The subset of allowed values is described in the table below:

Table A.5-2: Order control codes Value1 Description Event/Message Type Originat Field or Note3 NW New order/service P l OMPÔ09ÔMP_O09 OK Order/service accepted & OK F l ORPÔ10ÔRP_O10 RREÔ12^RRE_O12 RRGÔ16^RRG_O16 RRAÔ18^RRA_O18 UA Unable to accept F n order/service ORPÔ10ÔRP_O10 RREÔ12^RRE_O12 RRGÔ16^RRG_O16 RRAÔ18^RRA_O18 CA Cancel order/service request P a OMPÔ09ÔMP_O09 OC Order/service canceled F RDEÔ11^RDE_O11 RGVÔ15^RGV_O15 RASÔ01^RAS_O01 CR Canceled as requested F ORPÔ10ÔRP_O10 UC Unable to cancel F b ORPÔ10ÔRP_O10 DC Discontinue order/service P c request OMPÔ09ÔMP_O09 OD Order/service discontinued F RDEÔ11^RDE_O11 RGVÔ15^RGV_O15 RASÔ01^RAS_O01 DR Discontinued as requested F ORPÔ10ÔRP_O10 UD Unable to discontinue F ORPÔ10ÔRP_O10 HD Hold order request P OMPÔ09ÔMP_O09 OH Order/service held F RDEÔ11^RDE_O11

Value1 Description Event/Message Type Originat Field or Note3 RGVÔ15^RGV_O15 RASÔ01^RAS_O01 UH Unable to put on hold F ORPÔ10ÔRP_O10 HR On hold as requested F ORPÔ10ÔRP_O10 RL Release previous hold P OMPÔ09ÔMP_O09 OE Order/service released F RDEÔ11^RDE_O11 RGVÔ15^RGV_O15 RASÔ01^RAS_O01 OR Released as requested F ORPÔ10ÔRP_O10 UR Unable to release F ORPÔ10ÔRP_O10 RP Order/service replace request P "e,d" OMPÔ09ÔMP_O09 RU Replaced unsolicited F "f,d" RDEÔ11^RDE_O11 RO Replacement order "P,F" "g,d" OMPÔ09ÔMP_O09 RDEÔ11^RDE_O11 RQ Replaced as requested F "d,e" ORPÔ10ÔRP_O10 UM Unable to replace F ORPÔ10ÔRP_O10 PA Parent order/service F I OMPÔ09ÔMP_O09 RDEÔ11^RDE_O11 RGVÔ15^RGV_O15 RASÔ01^RAS_O01 CH Child order/service "F,P" I RDEÔ11^RDE_O11 RGVÔ15^RGV_O15 RASÔ01^RAS_O01 XO Change order/service request P OMPÔ09ÔMP_O09 XX Order/service changed, unsol. F

Value1 Description Event/Message Type Originat Field or Note3 RDEÔ11^RDE_O11 RGVÔ15^RGV_O15 RASÔ01^RAS_O01 UX Unable to change F ORPÔ10ÔRP_O10 XR Changed as requested F ORPÔ10ÔRP_O10 DE Data errors "P,F" ORPÔ10ÔRP_O10 RREÔ12^RRE_O12 RRGÔ16^RRG_O16 RRAÔ18^RRA_O18 RE Observations/Performed "P,F" j Service to follow RDEÔ11^RDE_O11 RGVÔ15^RGV_O15 RASÔ01^RAS_O01

OMLÔ21ÔML_O21 SC Status changed "F,P" SN Send order/service number F l RDEÔ11^RDE_O11 NA Number assigned P l RREÔ12^RRE_O12 RF Refill order/service request F o OMPÔ09ÔMP_O09 RDEÔ11^RDE_O11 AF Order/service refill request P p approval RREÔ12^RRE_O12 DF Order/service refill request P q denied ORPÔ10ÔRP_O10 RREÔ12^RRE_O12 FU Order/service refilled, F r unsolicited RDEÔ11^RDE_O11 OF Order/service refilled as F s requested ORPÔ10ÔRP_O10

Value1 Description Event/Message Type Originat Field or Note3 UF Unable to refill F t ORPÔ10ÔRP_O10 LI Link order/service to patient u care problem or goal OMPÔ09ÔMP_O09 RDEÔ11^RDE_O11 RASÔ01^RAS_O01 UN Unlink order/service from u patient care problem or goal OMPÔ09ÔMP_O09 RDEÔ11^RDE_O11 RASÔ01^RAS_O01 OP Notification of order for OMPÔ09ÔMP_O09 P w outside dispense PY Notification of replacement OMPÔ09ÔMP_O09 P,F w order for outside dispense

2245 See HL7 v2.5, chapter 4, 4.5.1.1.1 for the field notes

ORC-2 Placer Order Number (EI), conditional This number is assigned by the prescription placer application or by another placer order number assigning system. IHE-Pharmacy requires that this number is present as from the moment that a 2250 prescription order is placed. In a prescription, this number has a meaning of the Prescription item ID.

ORC-3 Filler Order Number (EI), conditional This number is assigned by the pharmaceutical Advisor or by another filler order number 2255 assigning system. IHE-Pharmacy requires that this number is present as from the moment that a prescription order is validated, dispensed or administered, whichever comes first.

ORC-4 Placer Group Number (EI), conditional In transactions PHARM-H1, PHARM-H3, PHARM-H4, PHARM-H5, IHE-Pharmacy specifies 2260 that this field may contain an order grouping unique identifier. This is usually the prescription ID. It is required if the number described in ORC-2 is part of an order session (like a prescription) that must be identified. The order group may change within the supply chain, e.g., to allow the pharmacist to order all the medications of the same type, regardless of the prescriptions involved, and for this reason, in ______115 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

2265 supply messages (not in scope), this field may contain another group identifier, given that RXE-15 will contain the prescription identifier.

ORC-5 Order Status (ID), conditional Condition predicate: This field shall be valued in all OMP, RDE, RGV and RAS messages. It 2270 represents the status of the order. The allowed values for this field within IHE Hospital Medication Workflow Technical Framework are a subset from HL7 table 0038 - Order Status:

Table A.5-3: Order Status: IHE set for all transactions Value Description Comment A Some, but not all, results available CA Order was canceled CM Order is completed DC Order was discontinued ER Error, order not found HD Order is on hold IP In process, unspecified RP Order has been replaced SC In process, scheduled 2275 ORC-9 Date/Time of Transaction (TS), required This field contains the date and time of the event that initiated the current transaction as reflected in ORC-1 Order Control Code. This field is not equivalent to MSH-7 Date and Time of Message which reflects the date/time of the physical message. 2280 ORC-10 Entered By (XCN), optional, repeatable This field is used for the identification of the healthcare professional in charge of the first action concerning the prescription – i.e., usually the person entering the prescription, if different from the ordering physician (which is identified in ORC-12). 2285 ORC-12 Ordering Provider (XCN), conditional, repeatable

Components: ^ ^ ^ ^ ^ ^ ^ ^ 2290 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ______116 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

^ ^ ^ This field contains the identification of the physician responsible for the prescription order. If a prescription exists (i.e., always in the current scope, except in the cases where the prescription is created a posteriori), this field is mandatory in transaction PHARM-H1 and subsequent. 2300 ORC-14 Call Back Phone Number (XTN), optional This field contains the telephone number or contact of the prescription placer, to call for clarification of a request or other information regarding the order.

2305 ORC-17 Entering Organization (CE), required

Components: ^ ^ ^ ^ ^ This field identifies the organization that the enterer belonged to at the time he/she 2310 enters/maintains the order, such as medical group or department. The person who first entered the request is defined in ORC-10 -entered by.

ORC-21 Ordering Facility Name (XON), required

Components: ^ ^ 2315 ^ ^ ^ ^ ^ ^ ^ This field contains the name of the facility placing the order. If there is more than one facility, or 2320 there are different levels of detail (e.g., the facility, sub-facility, specialty), this field can be repeated.

ORC-19 Action By (XCN), required

Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^

Subcomponents for Family Name (FN): & & & &

Subcomponents for Assigning Authority (HD): & &

Subcomponents for Assigning Facility (HD): & 2340 &

Subcomponents for Name Context (CE): & & & & &

Subcomponents for DEPRECATED-Name Validity Range (DR): & 2345

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): &

Subcomponents for Expiration Date (TS): &

Subcomponents for Assigning Jurisdiction (CWE): & & & & & & & &

Subcomponents for Assigning Agency or Department (CWE): & & & & & & & & 2360 Definition: This field contains the identity of the person who initiated the event represented by the corresponding order control code. For example, if the order control code is CA (cancel order request), this field represents the person who requested the order cancellation. This person is typically a care provider but may not always be the same as ORC-12 ordering provider. For 2365 example, when a medication is prepared for a patient, this field has the identification of the medication dispenser.

ORC-22 Ordering Facility Address (XAD), optional This field is used to send the address of the facility responsible for the order. 2370 ORC-23 Ordering Facility Phone Number (XTN), required This field is used to send the contact information of the facility responsible for the order.

ORC-24 Ordering Provider Address (XAD), optional

2375 Components: ^ ^ ^ ^ ^ ^

^ ^ ^ ^

^ ^ ^ 2380 This field is used to send the address of the prescription placer. Its use is optional. ORC-25 Order Status Modifier (CWE), conditional This field is a refiner of the ORC-5-Order status field and shall be valued in all OMP, RDE, RGV and RAS messages. This is used to provide additional levels of specificity or additional 2385 information for the defined order status codes. Unlike the Order Status field, which is controlled by an HL7 defined table, this field is a CWE data type allowing applications to support an unlimited library of Order Status Modifier codes. See section 4.5 for the details about the different order, validation, dispense and administration status supported.

2390 A.6 TQ1 - Timing Quantity Segment This segment is used in messages OMP, RDE, RGV and RAS in different contexts: After an ORC segment (optional in all messages), it indicates the encoded timing/quantity of the medication prescribed for the patient. After an RXE segment (required in RDE, optional in all other messages), it indicates the encoded 2395 timing/quantity of the medication as determined by the pharmaceutical advisor. After an RXG segment (required in RGV, optional in all other messages), it indicates the encoded timing/quantity of the medication to be taken by the patient, as determined by the medication dispenser (this is the case when the dispenser is in charge of scheduling the nurse administration list – as is the case when a nurse daily dispenses medication for the patient for the 2400 whole day.) After an RXA segment (optional in all messages), it indicates the encoded timing/quantity of the medication taken by the patient. HL7 v2.5: chapter 4 (4.5.4)

2405 Table A.6-1: TQ1 - Timing Quantity Segment SEQ LEN DT Usage Card. TBL ITEM# Element name # 1 4 SI R [1..1] 01627 Set ID - TQ1 2 20 CQ R [1..1] 01628 Quantity 3 540 RPT R [1..*] 0335 01629 Repeat Pattern 4 20 TM O [0..*] 01630 Explicit Time 5 20 CQ O [0..*] 01631 Relative Time and Units 6 20 CQ O [0..1] 01632 Service Duration ______119 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

7 26 TS C [0..1] 01633 Start date/time 8 26 TS RE [0..1] 01634 End date/time 9 250 CWE O [0..*] 0485 01635 Priority 10 250 TX O [0..1] 01636 Condition text 11 250 TX O [0..1] 01637 Text instruction 12 10 ID C [0..1] 0427 01638 Conjunction 13 20 CQ O [0..1] 01639 Occurrence duration 14 10 NM O [0..1] 01640 Total occurrences

TQ1-1 Set ID - TQ1 (SI), required Definition: For the first timing specification transmitted, the sequence number shall be 1; for the second timing specification, it shall be 2; and so on. 2410 TQ1-2 Quantity (CQ), required

Components: ^

Subcomponents for Units (CE): & & & & & Definition: This field specifies the numeric quantity of the service that should be provided at each service interval. For example, if two capsules are to be administered every 4 hours, the quantity would be 2. The default value for this field is 1. If multiple identical services are to be requested, it is strongly recommended that multiple 2420 service requests be placed; giving each service request its own unique placer/filler number.

TQ1-3 Repeat Pattern (RPT), required

Components: ^ ^ ^ ^ 2425 ^ ^ ^ ^ ^ ^

Subcomponents for Repeat Pattern Code (CWE): & & & & & & & & Definition: The repeating frequency with which the treatment is to be administered. It is similar to the frequency and SIG code tables used in order entry systems. This field may be repeated to build up more complex repeat patterns. For example, daily at 2435 bedtime can be represent as "|QD~HS|".

When the quantity timing specification must change to a different repeat pattern after some period of time, a new TQ1 segment must be used to show the new repeat pattern. Note that the end date of the current TQ1 will show when the current timing specification ends, and the start date of the next TQ1 shows when the new timing specification begins. The Conjunction field, 2440 TQ1-12 determines if the next TQ1 segment is to be performed sequentially or in parallel.

TQ1-7 Start date/time (TS), conditional HL7 definition: This field may be specified by the requester, in which case it indicates the earliest date/time at which the services should be started. In many cases, however, the start 2445 date/time will be implied or will be defined by other fields in the service request record (e.g., urgency - STAT). In such a case, this field will be empty.

TQ1-8 End date/time (TS), required if available

2450 Definition: When filled in by the requester of the service, this field should contain the latest date/time that the service should be performed. If it has not been performed by the specified time, it should not be performed at all. Regardless of the value of the end date/time, the service should be stopped at the earliest of the date/times specified by either the duration or the end date/time. 2455 TQ1-9 Priority (CWE), required if available

Value Description Comment S Stat With highest priority A ASAP Fill after S orders R Routine Default P Preop C Callback T Timing critical A request implying that it is critical to come as close as possible to the requested time, e.g., for a trough antimicrobial level. TS Timing critical within seconds. TM Timing critical within minutes. TH Timing critical within hours. TD Timing critical within days. TW Timing critical within weeks. TL Timing critical within months. PRN As needed

This field is required by IHE-Pharmacy if a priority different than Routine is indicated.

A.7 TQ2 - Timing/Quantity Relationship 2460 HL7 v2.5: chapter 4 (4.5.5)

Table A.7-1: TQ2 – Timing/Quantity Relationship SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 4 SI O [0..1] 01648 Set ID - TQ2 2 1 ID O [0..1] 0503 01649 Sequence/Results Flag 3 22 EI C [0..*] 01650 Related Placer Number 4 22 EI C [0..*] 01651 Related Filler Number 5 22 EI C [0..*] 01652 Related Placer Group Number 6 2 ID C [0..1] 0504 01653 Sequence Condition Code 7 1 ID C [0..1] 0505 01654 Cyclic Entry/Exit Indicator 8 20 CQ O [0..1] 01655 Sequence Condition Time Interval 9 10 NM O [0..1] 01656 Cyclic Group Maximum Number of Repeats 10 1 ID C [0..1] 0506 01657 Special Service Request Relationship

A.8 RXO - Pharmacy/Treatment Order Segment 2465 The RXO segment is created and updated at the Prescription Placer. It is forwarded in the other messages, to trace back to the original Prescription Order. HL7 v2.5: chapter 4 (4.14.1)

Table A.8-1: RXO – Pharmacy/Treatment Order Segment SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 250 CE RE [0..1] 00292 Requested Give Code 2 20 NM C [0..1] 00293 Requested Give Amount - Minimum 3 20 NM O [0..1] 00294 Requested Give Amount - Maximum 4 250 CE C [0..1] 00295 Requested Give Units 5 250 CE C [0..1] 00296 Requested Dosage Form 6 250 CE RE [0..*] 00297 Provider's Pharmacy/Treatment Instructions 7 250 CE RE [0..*] 00298 Provider's Administration Instructions 8 200 LA1 O [0..1] 00299 Deliver-To Location 9 1 ID R [0..1] 0161 00300 Allow Substitutions 10 250 CE O [0..1] 00301 Requested Dispense Code 11 20 NM C [0..1] 00302 Requested Dispense Amount

SEQ LEN DT Usage Card. TBL# ITEM# Element name 12 250 CE C [0..1] 00303 Requested Dispense Units 13 3 NM O [0..1] 00304 Number Of Refills 14 250 XCN C [0..*] 00305 Ordering Provider's DEA Number 15 250 XCN C [0..*] 00306 Pharmacist/Treatment Supplier's Verifier ID 16 1 ID O [0..1] 0136 00307 Needs Human Review 17 20 ST C [0..1] 00308 Requested Give Per (Time Unit) 18 20 NM O [0..1] 01121 Requested Give Strength 19 250 CE O [0..1] 01122 Requested Give Strength Units 20 250 CE R [1..*] 01123 Indication 21 6 ST C [0..1] 01218 Requested Give Rate Amount 22 250 CE C [0..1] 01219 Requested Give Rate Units 23 10 CQ O [0..1] 00329 Total Daily Dose 24 250 CE O [0..*] 01476 Supplementary Code 25 5 NM O [0..1] 01666 Requested Drug Strength Volume 26 250 CWE O [0..1] 01667 Requested Drug Strength Volume Units 27 1 ID O [0..1] 0480 01668 Pharmacy Order Type 28 20 NM O [0..1] 01669 Dispensing Interval 2470 RXO-1 Requested Give Code (CE), conditional This field identifies the treatment product or treatment ordered to be given to the patient.

The RXO-1, RXO-2 and RXO-4 are mandatory unless the prescription/treatment is transmitted as free text using RXO-6, then RXO-1, RXO-2, and RXO-4 may be blank and the first 2475 subcomponent of RXO-6 must be blank. For semantic interoperability, use of encoded information is strongly recommended.

RXO-2 Requested Give Amount – Minimum (NM) , required if available This field is the ordered amount. In a variable dose order, this is the minimum ordered amount. 2480 In a non-varying dose order, this is the exact amount of the order.

The RXO-1, RXO-2 and RXO-4 are mandatory unless the prescription/treatment is transmitted as free text using RXO-6, then RXO-1, RXO-2, and RXO-4 may be blank and the first subcomponent of RXO-6 must be blank.

Note: This field is not a duplication of the first component of the quantity/timing field, since in 2485 non-pharmacy/treatment orders, that component can be used to specify multiples of an ordered amount. Another way to say this is that, for pharmacy/treatment orders, the quantity component of the

quantity/timing field refers to what is to be given out at each service interval; thus, in terms of the RX order, that first component always defaults to 1. Hence, in the actual execution of the 2490 order, the value of 1 in the first component of the quantity/timing field always refers to one administration of the amount specified in this field (the Requested Give Amount field).

RXO-4 Requested Give Units (CE), required if available

Components: ^ ^ ^ ^ ^ This field indicates the units for the give amount.

The RXO-1, RXO-2 and RXO-4 are mandatory unless the prescription is transmitted as free text using RXO-6, then RXO-1, RXO-2, and RXO-4 may be blank and the first subcomponent of RXO-6 must be blank.

2500 Note: These units can be a "compound quantity"; i.e., the units may contain the word "per." For example, micrograms per KG (micg/kg) is an acceptable value, which means that the units are micrograms per KG (of body weight). See Chapter 7 for full definition of ISO+ units.

RXO-5 Requested Dosage Form (CE), required if available

2505 Components: ^ ^ ^ ^ ^ This field indicates the manner in which the treatment is aggregated for dispensing, e.g., tablets, capsules suppositories. In some cases, this information is implied by the dispense/give code in RXO-1-requested give code or RXO-10-Requested dispense code. Required when both RXO-1- 2510 Requested give code and RXO-10-Requested dispense code do not specify the drug/treatment form. Optionally included otherwise.

RXO-6 Provider's Pharmacy/Treatment Instructions (CE), conditional This field identifies the ordering provider's instructions to the pharmacy or the non-pharmacy 2515 treatment provider (e.g., respiratory therapy). If coded, a user-defined table must be used. If transmitted as a free text field, place a null in the first component and the text in the second, e.g., |^this is a free text treatment instruction|.

If the prescription is transmitted as free text using RXO-6, then RXO-1, RXO-2, and RXO-4 may be blank and the first subcomponent of RXO-6 must be blank. Otherwise, RXO-1, RXO-2 2520 and RXO-4 are mandatory.

RXO-7 Provider's Administration Instructions (CE), required if available

This field identifies the ordering provider's instructions to the patient or to the provider administering the drug or treatment. If coded, a user-defined table must be used. If transmitted 2525 as free text, place a null in the first component and the text in the second, e.g., |^this is a free text administration instruction|.

RXO-9 Allow Substitution, required This field specifies if substitutions are allowed by the prescription placer. An empty field must 2530 always be interpreted as “no substitutions allowed”.

Value Description Comment N Substitutions are NOT authorized. (This is the default - null.) G Allow generic substitutions. T Allow therapeutic substitutions

Biosimilar substitution cannot be supported in HL7 v2.5 or v2.6. If the prescriber allows biosimilar substitution, then the value “G” should be used, and in the immediately next NTE 2535 segment the reference to Biosimilar substitution is sent. This means that receiving applications must parse this NTE segment when it exists.

RXO-10 Requested Dispense Code (CE), Optional This field indicates what is to be/was dispensed – in case the prescription placer wishes to inform 2540 the product to be dispensed – e.g., the box size, or commercial name - if the RXO-1 Requested Give Code refers to a generic substance name and the prescriber wants to also specify the dispensed product. In Option “Advance Prescription Notification”, RXO-10, RXO-11 and RXO-12 can be mandatory: if the Medication Dispenser or Administration Informer are not able to interpret the 2545 Requested Give Code – for example if this code refers to a substance – or if the order is sent as free text in RXO-6.

RXO-11 Requested Dispense Amount (NM), conditional This field must be used if RXO-10 Requested Dispense Code is used – to indicate the amount of 2550 dispensed units. Example: to dispense (2 boxes of 30 pills), if the code in RXO-10 refers to a box of 30 pills, this value is 2.

RXO-12 Requested Dispense Units (CE), conditional

This field must be used if RXO-10 Requested Dispense Code is used – to indicate the units of the 2555 dispense. Example: to dispense (2 boxes of 30 pills), if the code in RXO-10 refers to a box of 30 pills, this value can be “Box”.

RXO-20 Indication (CE), required, repeatable This field identifies the diagnosis, condition or problem for which the drug/treatment was 2560 prescribed. May repeat if multiple indications are relevant.

RXO-24 Supplementary Code (CE) This field accommodates the identification of any codes that might be associated with the pharmaceutical substance. Common codes include: the Generic Product Identifier (GPI), Generic 2565 Code Number_Sequence Number (GCN_SEQNO), National Drug Code (NDC).

A.9 RXR - Pharmacy/Treatment Route Segment HL7 v2.5: chapter 4 (4.14.2)

Table A.9-1: RXR - Pharmacy/Treatment Route Segment SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 250 CE R [1..1] 0162 00309 Route 2 250 CWE RE [0..1] 0163 00310 Administration Site 3 250 CE O [0..1] 0164 00311 Administration Device 4 250 CWE O [0..1] 0165 00312 Administration Method 5 250 CE O [0..1] 01315 Routing Instruction 6 250 CWE O [0..1] 0495 01670 Administration Site Modifier 2570 RXR-1 Route (CE), required This field is the route of administration. If after RXO, it is the intended route of administration. If after RXA, it is the effective route of administration. HL7 User-defined Table 0162 lists proposed routes of Administration.

2575 User-defined Table 0162 - Route of Administration Value Description Comment AP Apply Externally B Buccal DT Dental EP Epidural ET Endotrachial Tube* used primarily for respiratory ______126 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

Value Description Comment therapy and anesthesia delivery GTT Gastrostomy Tube GU GU Irrigant IMR Immerse (Soak) Body Part IA Intra-arterial IB Intrabursal IC Intracardiac ICV Intracervical (uterus) ID Intradermal IH Inhalation IHA Intrahepatic Artery IM Intramuscular IN Intranasal IO Intraocular IP Intraperitoneal IS Intrasynovial IT Intrathecal IU Intrauterine IV Intravenous MTH Mouth/Throat MM Mucous Membrane NS Nasal NG Nasogastric NP Nasal Prongs* used primarily for respiratory therapy and anesthesia delivery NT Nasotrachial Tube OP Ophthalmic OT Otic OTH Other/Miscellaneous PF Perfusion PO Oral PR Rectal RM Rebreather Mask* used primarily for respiratory therapy and anesthesia delivery SD Soaked Dressing SC Subcutaneous SL Sublingual TP Topical

Value Description Comment TRA Tracheostomy* used primarily for respiratory therapy and anesthesia delivery TD Transdermal TL Translingual UR Urethral VG Vaginal VM Ventimask WND Wound

RXR-2 Administration Site (CWE), required if available This field contains the site of the administration route. When using a post-coordinated code table in this field, RXR-6 Administration Site may be used to modify the meaning of this field. Refer 2580 to HL7 Table 0550 – Body Parts for valid values.

A.10 RXC - Pharmacy/Treatment Component Order Segment HL7 v2.5: chapter 4 (4.14.3)

Table A.10-1: RXC - Pharmacy/Treatment Component Order Segment SEQ LEN DT A.10 Card. TBL ITEM# Element name Usage # 1 1 ID R [1..1] 0166 00313 RX Component Type 2 250 CE R [1..1] 00314 Component Code 3 20 NM R [1..1] 00315 Component Amount 4 250 CE R [1..1] 00316 Component Units 5 20 NM O [0..1] 01124 Component Strength 6 250 CE O [0..1] 01125 Component Strength Units 7 250 CE O [0..*] 01476 Supplementary Code 8 5 NM O [0..1] 01671 Component Drug Strength Volume 9 250 CWE O [0..1] 01672 Component Drug Strength Volume Units 2585 RXC-2 Component Code, required if available IHE-Pharmacy uses this field to detail the component of a compound preparation, for example perfusions or components for a magistral preparation.

2590 RXC-3 Component Amount, required if available ______128 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

IHE-Pharmacy uses this field to detail the amount of the component of a compound preparation, for example perfusions or components for a magistral preparation.

RXC-4 Component Units, required if available 2595 IHE-Pharmacy uses this field to detail the units in which RXC-3 is expressed.

A.11 RXE - Pharmacy/Treatment Encoded Order Segment The RXE segment is created and updated at the Pharmaceutical Advisor. It is forwarded in the other messages, to trace back to the original Pharmaceutical Advice. 2600 HL7 v2.5: chapter 4 (4.14.4)

Table A.11-1: RXE - Pharmacy/Treatment Encoded Order Segment SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 200 TQ X [0..0] 00221 Quantity/Timing 2 250 CE R [1..1] 0292 / 00317 Give Code 0479 3 20 NM R [1..1] 00318 Give Amount – Minimum 4 20 NM O 00319 Give Amount – Maximum 5 250 CE R [1..1] 00320 Give Units 6 250 CE O [0..1] 00321 Give Dosage Form 7 250 CE O [0..*] 00298 Provider's Administration Instructions 8 200 LA1 X [0..0] 00299 Deliver-to Location 9 1 ID O [0..1] 0167 00322 Substitution Status 10 20 NM C [0..1] 00323 Dispense Amount 11 250 CE C [0..1] 00324 Dispense Units 12 3 NM O [0..1] 00304 Number of Refills 13 250 XCN C [0..*] 00305 Ordering Provider's DEA Number 14 250 XCN R [1..*] 00306 Pharmacist/Treatment Supplier's Verifier ID 15 20 ST C [0..1] 00325 Prescription Number 16 20 NM C [0..1] 00326 Number of Refills Remaining 17 20 NM C [0..1] 00327 Number of Refills/Doses Dispensed 18 26 TS C [0..1] 00328 D/T of Most Recent Refill or Dose Dispensed 19 10 CQ C [0..1] 00329 Total Daily Dose 20 1 ID O [0..1] 0136 00307 Needs Human Review 21 250 CE O [0..*] 00330 Pharmacy/Treatment Supplier's Special Dispensing Instructions

SEQ LEN DT Usage Card. TBL# ITEM# Element name 22 20 ST C [0..1] 00331 Give Per (Time Unit) 23 6 ST O [0..1] 00332 Give Rate Amount 24 250 CE O [0..1] 00333 Give Rate Units 25 20 NM O [0..1] 01126 Give Strength 26 250 CE O [0..1] 01127 Give Strength Units 27 250 CE O [0..*] 01128 Give Indication 28 20 NM O [0..1] 01220 Dispense Package Size 29 250 CE O [0..1] 01221 Dispense Package Size Unit 30 2 ID O [0..1] 0321 01222 Dispense Package Method 31 250 CE O [0..*] 01476 Supplementary Code 32 26 TS O [0..1] 01673 Original Order Date/Time 33 5 NM O [0..1] 01674 Give Drug Strength Volume 34 250 CWE O [0..1] 01675 Give Drug Strength Volume Units 35 60 CWE O [0..1] 0477 01676 Controlled Substance Schedule 36 1 ID O [0..1] 0478 01677 Formulary Status 37 60 CWE O [0..*] 01678 Pharmaceutical Substance Alternative 38 250 CWE O [0..1] 01679 Pharmacy of Most Recent Fill 39 250 NM O [0..1] 01680 Initial Dispense Amount 40 250 CWE O [0..1] 01681 Dispensing Pharmacy 41 250 XAD O [0..1] 01682 Dispensing Pharmacy Address 42 80 PL O [0..1] 01683 Deliver-to Patient Location 43 250 XAD O [0..1] 01684 Deliver-to Address 44 1 ID O [0..1] 0480 01685 Pharmacy Order Type

2605 RXE-1 Quantity/Timing (TQ), not used This field is not used. Quantity/timing information is sent in the TQ1 segment.

RXE-2 Give Code (CE), required

Components: ^ ^ ^ 2610 ^ ^ This field identifies the medical substance or treatment that has been ordered to be given to the patient, as encoded by the pharmacy or treatment supplier; It may be the same as RXO-1, if the pharmacist does not re-encode the item. In the RXE 2615 segment, this give code must be encoded. The dispense fields, which define the units and amount of what is to be issued to the patient (see RXE-10-dispense amount and RXE-11-

dispense units below), do not necessarily correlate with the instructions of what amount is to be "given" or administered with each dose, and may or may not be specified with the order.

2620 RXE-3 Give Amount - Minimum (NM), required This field contains the ordered amount as encoded by the pharmacy or treatment supplier. In a variable dose order, this is the minimum ordered amount. In a nonvarying dose order, this is the exact amount of the order.

2625 RXE-4 Give Amount - Maximum (NM) , required if available In a variable dose order, this is the maximum ordered amount. In a non-varying dose, this field is not used.

RXE-5 Give Units (CE), required

2630 Components: ^ ^ ^ ^ ^ This field contains the units for the give amount as encoded by the pharmacy or treatment (e.g., respiratory therapy) application. 2635 It is required when a quantity is transmitted in RXE-3 or RXE-4

RXE-6 Give Dosage Form (CE), optional

Components: ^ ^ ^ ^ ^ The dosage form indicates the manner in which the medication or treatment is aggregated for dispensing, e.g., tablets, capsules, suppositories. In some cases, this information is implied by the give code in RXE-2-Give Code. Use the RXE-6-Give Dosage Form when the give code does not specify the dosage form. 2645 RXE-7 Provider's Administration Instructions, Required if Available

Components: ^ ^ ^ ^ ^ 2650 This field contains the ordering provider's instructions to the patient or the provider administering the drug or treatment. If coded, a user-defined table must be used; if free text (describing a custom IV, mixture, or salve, for example), place the text in the second component, e.g., |^this is a free text administration instruction|.

2655 RXE-9 Substitution Status (ID), required Refer to HL7 Table 0167 - Substitution Status for valid values. If a substitution has been made, and a record of the original requested give code (RXO-1-requested give code) is needed, the optional RXO segment can be included in the RDE message.

HL7 Table 0167 - Substitution Status Value Description Comment N No substitute was dispensed. This is equivalent to the default (null) value. G A generic substitution was dispensed. T A therapeutic substitution was dispensed. 0 No product selection indicated 1 Substitution not allowed by prescriber 2 Substitution allowed - patient requested product dispensed 3 Substitution allowed - pharmacist selected product dispensed 4 Substitution allowed - generic drug not in stock 5 Substitution allowed - brand drug dispensed as a generic 7 Substitution not allowed - brand drug mandated by law 8 Substitution allowed - generic drug not available in marketplace 2660 RXE-10 Dispense Amount, Optional This field contains the amount to be dispensed as encoded by the pharmacy or treatment supplier.

RXE-11 Dispense Units (CE) 00324

2665 Components: ^ ^ ^ ^ ^ This field contains the units for the dispense amount as encoded by the pharmacy or treatment supplier. This field is required if the units are not implied by the actual dispense code. This must 2670 be in simple units that reflect the actual quantity of the substance dispensed. It does not include compound units.

RXE-14 Pharmacist/Treatment Supplier's Verifier ID, required, repeatable This field is used to identify the pharmacists that have validated the prescription. In case a 2675 prescription is validated by more than one system / pharmacist, the field is repeated. The difference between intermediate or final validations is that the field ORC-25 is to be set to indicate that the validation is complete.

RXE-15 Prescription Number (ST), required 2680 This field contains the prescription number as assigned by the pharmacy or treatment application. Equivalent in uniqueness to the pharmacy/treatment filler order number. At some sites, this may be the pharmacy or treatment system (internal) sequential form. At other sites, this may be an external form. This is a required field in RXE when used in pharmacy/treatment messages.

2685 RXE-21 Pharmacy/Treatment Supplier's Special Dispensing Instructions (CE), required if available Definition: This field contains the pharmacy or treatment supplier's provider-generated special instructions to the provider dispensing/administering the order.

2690 RXE-22 Give Per (Time Unit), required if available This field contains the time unit to use to calculate the rate at which the pharmaceutical is to be administered, as specified by the Pharmaceutical Advisor.

Format:

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 would be assumed to be the same as in the QUANTITY field. INDEF = do indefinitely - also the default This is the same as the format specified for the DURATION component of the quantity/timing 2695 field, excluding the "X" specification. This field is defined as conditional because it is required when the ordered substance is to be administered continuously at a prescribed rate (e.g., certain IVs). For example, if the "give amount/units" were 300 ml and the "give per" time unit were H1 (equivalent to one hour), the rate is 300ml/hr. 2700 RXE-23 Give Rate Amount (ST), required if available This field contains the rate at which the substance should be administered, as specified by the Pharmaceutical Advisor.

2705 RXE-24 Give Rate Units (CE), required if available

Components: ^ ^ ^ ^ ^ This field contains the units for RXE-23-give rate amount, as specified by the Pharmaceutical 2710 Advisor. May be composite. The ratio of the RXE-23-give rate amount and RXE-24-give rate units defines the actual rate of administration. Thus, if RXE-23-give rate amount = 100 and RXE-24-give rate units = ml/hr, the requested rate of administration is 100 ml/hr. (See ISO+ Figure 7-9 in Chapter 7 for possible compound units codes.)

2715 RXE-27 Give Indication (CE), required if existing

Components: ^ ^ ^ ^ ^ This field identifies the condition or problem for which the drug/treatment was prescribed. May 2720 repeat if multiple indications are relevant. If RXO-20 is present, RXE-27 has the same value as RXO-20.

RXE-28 Dispense Package Size (NM), required if existing This field contains the size of package to be dispensed. Units are transmitted in RXE-29- 2725 dispense package size unit.

RXE-29 Dispense Package Size Unit (CE), required if existing

Components: ^ ^ ^ ^ ^ This field contains the units in which RXE-28-dispense package size is denominated.

A.12 OBX - Observation/Result Segment HL7 v2.5.1: chapter 7 (7.4.2) The Observation segment is used to convey the following information. Each if these information 2735 types must be in a separate OBX segment: • Pregnancy history (Required, if the patient is currently pregnant) • Immunizations • Active Problems • Resolved Problems 2740 • Coded Vital Signs • Other patient data (weight, etc.) when relevant

Table A.12-1: Observation/Result Segment SEQ LEN DT Usage Card. TBL# ITEM# ELEMENT NAME 1 4 SI O [0..1] 00569 Set ID – OBX 2 2 ID C 0125 00570 Value Type 3 250 CE R 00571 Observation Identifier 4 20 ST C 00572 Observation Sub-ID 5 99999 varie C Y3 00573 Observation Value 2 s 6 250 CE O 00574 Units 7 60 ST O 00575 References Range 8 5 IS O Y 0078 00576 Abnormal Flags 9 5 NM O 00577 Probability 10 2 ID O Y 0080 00578 Nature of Abnormal Test 11 1 ID R 0085 00579 Observation Result Status 12 26 TS O 00580 Effective Date of Reference Range 13 20 ST O 00581 User Defined Access Checks 14 26 TS R 00582 Date/Time of the Observation 15 250 CE R 00583 Producer's ID 16 250 XCN R Y 00584 Responsible Observer 17 250 CE O Y 00936 Observation Method 18 22 EI O Y 01479 Equipment Instance Identifier 19 26 TS O 01480 Date/Time of the Analysis

2745 OBX-1 Set ID - OBX (SI), required. This field contains the sequence number of the OBX.

OBX-2 Value Type (ID), required 2750 Condition predicate: This field shall be valued since OBX-5 (Observation Value) is also populated. The Value Type field should be filled according to HL7 Version 2.5 standard (table 0125). For example, if the result is ">300" the Value Type "SN" (Structured Numeric) SHALL

2 The length of the observation field is variable, depending upon value type. See OBX-2 value type. 3 May repeat for multipart, single answer results with appropriate data types, e.g., CE, TX, and FT data types. ______135 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

be used instead of the "ST" (String) value type that was used in previous versions of HL7. See the details and the examples in the HL7 V2.5 (7.4.2). For an observation that consists of a time 2755 measurement (e.g., bleeding time) the TM Value Type is preferred to NM but this is not made mandatory. HL7 Table 0125 - Value type Value Description Comment AD Address CE Coded Entry CF Coded Element With Formatted Values CK Composite ID With Check Digit CN Composite ID And Name CP Composite Price CX Extended Composite ID With Check Digit DT Date ED Encapsulated Data FT Formatted Text (Display) MO Money NM Numeric PN Person Name RP Reference Pointer SN Structured Numeric ST String Data. TM Time TN Telephone Number TS Time Stamp (Date & Time) TX Text Data (Display) XAD Extended Address XCN Extended Composite Name And Number For Persons XON Extended Composite Name And Number For Organizations XPN Extended Person Name XTN Extended Telecommunications Number

OBX-3 Observation Identifier (CE), required 2760 The usage of LOINC® test codes for the identification of tests is strongly recommended. Details of this free vocabulary can be found at http://www.loinc.org . The first and third sub-fields “Identifier”, and “Name of Coding System” are required in all transactions. The value of the “Name of Coding System” in the case of LOINC is “LN”.

The last three sub-fields are optional in all transactions.OBX-4 Observation Sub-ID (ST), 2765 conditional. HL7 Definition: This field is used to distinguish between multiple OBX segments with the same observation ID organized under one OBR. Condition predicate: This field is required when the observations are appended/ changed after initial creation – each entry that changes the parameters has a new value of OBX-4. 2770 In all other situations this field is optional.

OBX-5 Observation Value (varies), required.

OBX-6 Units (CE), conditional. 2775 This field in required if the Value Type field (OBX-2) is valued either with "NM", or "SN". If valued, this field should identify SI or SI-derived units only.

OBX-7 References Range (ST), required if available. This field should be valued as described in HL7 V2.5 for all observations for which it is relevant. 2780 The References range that figures in this field is supposed to be related to age and sex of the patient or to other parameters such as number of weeks of pregnancy when applicable, which makes the OBX-10 field (nature of abnormal test) unnecessary.

OBX-8 Abnormal Flags (IS), required if available. 2785 This field is required when applicable. This field is not repeatable in the IHE Hospital Medication Worfklow Framework. Among the possible values listed for this field in HL7 table 0078, the actors of IHE Hospital Medication Worfklow Technical Framework should support the following values: HL7 table 0078 Value Description Comment L Below low normal H Above high normal LL Below lower panic limits HH Above upper panic limits N Normal (applies to non-numeric results) A Abnormal (applies to non-numeric results) AA Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units) Null No range defined, or normal ranges don't apply S Susceptible. Indicates for microbiology susceptibilities only.

Value Description Comment R Resistant. Indicates for microbiology susceptibilities only. I Intermediate. Indicates for microbiology susceptibilities only. MS Moderately susceptible. Indicates for microbiology susceptibilities only. VS Very susceptible. Indicates for microbiology susceptibilities only. 2790 The S, R, I, MS and VS values shall be used to indicate the interpreted result of susceptibilities in microbiology, in case the value field (OBX-5) contains a numeric value that represents the MIC (Minimum Inhibitive Concentration). In case the order filler only reports the interpreted result for susceptibilities, the S, R, I, MS and VS value could be filled in the value field (OBX-5) with a Value Type (OBX-2) set to "ST". 2795 Note: For reporting antimicrobial susceptibilities in microbiology see section 3.11 “Microbiology Reporting Rules” and the microbiology example in section 19.5)

OBX-14 Date/Time of the Observation (TS), required if available. This field should be valued when the OBX-5 field (Value field) is also valued. In all cases, the 2800 observation date-time is the physiologically relevant date-time or the closest approximation to that date-time.

OBX-16 Responsible Observer (XCN), required if available. This field is required when the observation result status (OBX-11) is valued with "D" or "R" or 2805 "P" or "F" or "C" or "X" and the Producer's ID field is not valued. It should contain the identity of the observer that causes the change of the observation result status. Only the first component (ID number) of this field is required, provided that it is possible to retrieve the full identity of responsible person with only this ID number.

2810 OBX-17 Observation Method (CE), conditional. Condition predicate: This field is required when the value of the result may be dependent of the Observation Method and the Observation Identifier does not permit to identify the Method. With some Observation Identifiers such as LOINC(r) Codes, the identifier also identifies the Method, in which case this field does not need to be valued.

2815 A.13 RXG - Pharmacy/Treatment Give Segment HL7 v2.5: chapter 4 (4.14.6) Table A.13-1: RXG - Pharmacy/Treatment Give Segment SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 4 NM R [1..1] 00342 Give Sub-ID Counter 2 4 NM O [0..1] 00334 Dispense Sub-ID Counter 3 200 TQ X [0..0] 00221 Quantity/Timing ______138 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

SEQ LEN DT Usage Card. TBL# ITEM# Element name 4 250 CE R [1..1] 0292 00317 Give Code 5 20 NM R [1..1] 00318 Give Amount – Minimum 6 20 NM O [0..1] 00319 Give Amount – Maximum 7 250 CE R [1..1] 00320 Give Units 8 250 CE O [0..1] 00321 Give Dosage Form 9 250 CE O [0..*] 00351 Administration Notes 10 1 ID O [0..1] 0167 00322 Substitution Status 11 200 LA2 O [0..1] 01303 Dispense-To Location 12 1 ID O [0..1] 0136 00307 Needs Human Review 13 250 CE O [0..*] 00343 Pharmacy/Treatment Supplier's Special Administration Instructions 14 20 ST C [0..1] 00331 Give Per (Time Unit) 15 6 ST C [0..1] 00332 Give Rate Amount 16 250 CE C [0..1] 00333 Give Rate Units 17 20 NM O [0..1] 01126 Give Strength 18 250 CE O [0..1] 01127 Give Strength Units 19 20 ST O [0..*] 01129 Substance Lot Number 20 26 TS O [0..*] 01130 Substance Expiration Date 21 250 CE O [0..*] 0227 01131 Substance Manufacturer Name 22 250 CE O [0..*] 01123 Indication 23 5 NM O [0..1] 01692 Give Drug Strength Volume 24 250 CWE O [0..1] 01693 Give Drug Strength Volume Units 25 60 CWE O [0..1] 01694 Give Barcode Identifier 26 1 ID O [0..1] 0480 01695 Pharmacy Order Type RXG-3 Quantity/Timing, Not used

2820 RXG-4 Give Code, required

Components: ^ ^ ^ ^ ^ This field is the identifier of the medical substance/treatment ordered to be given to the patient. 2825 RXG-5 Give Amount – Minimum, required This field contains the ordered amount as encoded by the pharmacy/treatment supplier. In a variable dose order, this is the minimum ordered amount. In a nonvarying dose order, this is the exact amount of the order. 2830 Note: This field is not a duplication of the first component of the quantity/timing field, since in non-pharmacy/treatment orders, that component can be used to specify multiples of an ordered amount.

Another way to say this is that, for pharmacy/treatment orders, the quantity component of the quantity/timing field refers to what is to be given out at each service interval; and thus, in terms of the RX order, that first component always defaults to 1. Hence, in the actual execution of the order, the value of 1 in the first component of the quantity/timing field always 2835 refers to one administration of the amount specified in this field (the requested Give Amount field).

RXG-6 Give Amount - Maximum, required if available In a variable dose order, this is the maximum ordered amount. In a nonvarying dose order, this field is not used. 2840 RXG-7 Give Units (CE), required

Components: ^ ^ ^ ^ ^ 2845 This field contains the units for the give amount.

Note: These units can be a "compound quantity;" i.e., the units may contain the word "per." For example, micrograms per KG (micg/kg) is an acceptable value, which means that the units are micrograms per KG (of body weight). A table of standard units that contains compound units is needed. Until such a table is agreed on, a user-defined table is needed for each site. 2850 RXG-8 Give Dosage Form, required if available

Components: ^ ^ ^ ^ ^ 2855 The dosage form indicates the manner in which the medication/treatment is aggregated for dispensing, e.g., tablets, capsules, suppositories. In some cases, this information is implied by the give code in RXG-4-Give Code. Use this field when the give code does not specify the dosage form, i.e., when an explicit indication of a specific dosage is available.

2860 RXG-9 Administration Notes, required if available

Components: ^ ^ ^ ^ ^ This field contains notes to the person administering the medication/treatment (may include the 2865 ordering provider's original notes, as well as any notes from the formulary or the pharmacy or treatment supplier). If coded, a user-defined table must be used. If free text, place a null in the first component and the text in the second, e.g., |^this is a free text administration note|.

2870 RXG-10 Substitution Status, Optional Refer to HL7 Table 0167 - Substitution Status for valid values.

Note: The next two fields are equivalent to the corresponding fields of the RXE segment. They are included (optionally) in the RXG so that it may "stand alone" as a "give" instruction segment. HL7 Table 0167 - Substitution Status Value Description Comment N No substitute was dispensed. This is equivalent to the default (null) value. G A generic substitution was dispensed. T A therapeutic substitution was dispensed. 0 No product selection indicated 1 Substitution not allowed by prescriber 2 Substitution allowed - patient requested product dispensed 3 Substitution allowed - pharmacist selected product dispensed 4 Substitution allowed - generic drug not in stock 5 Substitution allowed - brand drug dispensed as a generic 7 Substitution not allowed - brand drug mandated by law 8 Substitution allowed - generic drug not available in marketplace 2875 RXG-13 Pharmacy/Treatment Supplier's Special Administration Instructions, Optional

Components: ^ ^ ^ ^ ^ 2880 This field contains pharmacy/treatment supplier-generated special instructions to the provider administering the order.

RXG-14 Give Per (Time Unit), Conditional This field contains the time unit to use to calculate the rate at which the pharmaceutical/treatment 2885 is to be administered. Format:

This is the same as the format specified for the DURATION component of the quantity/timing field, excluding the "X" specification. Required when relevant (e.g., certain IVs). For example, if the "give amount/units" were 300 ml 2890 and the "give per" time unit were H1 (equivalent to one hour), the rate is 300ml/hr.

RXG-15 Give Rate Amount, Conditional This field contains the rate amount of substance/treatment to be administered. Required when relevant. 2895 RXG-16 Give Rate Units, Optional

Components: ^ ^ ^ ^ ^ 2900 This field contains the units for RXG-15-give rate amount. May be composite. The ratio of the RXG-15-give rate amount and RXG-16-give rate units fields define the actual rate of administration. Thus, if RXG-15-give rate amount = 100 and RXG-16-give rate units = ml/hr, the requested rate of administration is 100 ml/hr.

2905 RXG-19 Substance Lot Number, Optional This field contains the lot number of the medical substance administered. Note: The lot number is the number printed on the label attached to the container holding the substance and on the packaging which houses the container. If the substance is a vaccine, for example, and a diluent is required, a lot number may appear on the vial containing the diluent; however, any such identifier associated with a diluent is 2910 not the identifier of interest. The substance lot number should be reported, not that of the diluent.

RXG-20 Substance Expiration Date , Optional

Components: ^ This field contains the expiration date of the medical substance administered. 2915 Note: Vaccine expiration date does not always have a "day" component; therefore, such a date may be transmitted as YYYYMM.

RXG-22 Indication, Optional

Components: ^ ^ ^ 2920 ^ ^ This field contains the identifier of the condition or problem for which the drug/treatment was prescribed. May repeat if multiple indications are relevant. If RXO-20 is present, RXG-22 has the same value as RXO-20. ______142 Rev. 1.3 – 2012-09-27 Copyright © 2012: IHE International, Inc. IHE Pharmacy Technical Framework Supplement – Hospital Medication Workflow (HMW) ______

2925 A.14 RXA - Pharmacy/Treatment Administration Segment HL7 v2.5: chapter 4 (4.14.7) This segment is used in an RAS message, to inform about the medication that has been administered to the patient.

2930 Table A.14-1: RXA - Pharmacy/Treatment Administration Segment SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 4 NM R [1..1] 00342 Give Sub-ID Counter 2 4 NM R [1..1] 00344 Administration Sub-ID Counter 3 26 TS R [1..1] 00345 Date/Time Start of Administration 4 26 TS R [1..1] 00346 Date/Time End of Administration 5 250 CE R [1..1] 0292 00347 Administered Code 6 20 NM R [1..1] 00348 Administered Amount 7 250 CE C [0..1] 00349 Administered Units 8 250 CE RE [0..1] 00350 Administered Dosage Form 9 250 CE RE [0..*] 00351 Administration Notes 10 250 XCN R [0..*] 00352 Administering Provider 11 200 LA2 RE [0..1] 00353 Administered-at Location 12 20 ST C [0..1] 00354 Administered Per (Time Unit) 13 20 NM O [0..1] 01134 Administered Strength 14 250 CE O [0..1] 01135 Administered Strength Units 15 20 ST RE [0..*] 01129 Substance Lot Number 16 26 TS RE [0..*] 01130 Substance Expiration Date 17 250 CE O [0..*] 0227 01131 Substance Manufacturer Name 18 250 CE RE [0..*] 01136 Substance/Treatment Refusal Reason 19 250 CE O [0..*] 01123 Indication 20 2 ID R [0..1] 0322 01223 Completion Status 21 2 ID O [0..1] 0323 01224 Action Code – RXA 22 26 TS O [0..1] 01225 System Entry Date/Time 23 5 NM O [0..1] 01696 Administered Drug Strength Volume 24 250 CWE O [0..1] 01697 Administered Drug Strength Volume Units 25 60 CWE RE [0..1] 01698 Administered Barcode Identifier 26 1 ID O [0..1] 0480 01699 Pharmacy Order Type

RXA-1 Give Sub-ID Counter, Required

Use this field if matching this RXA segment to its corresponding RXG segment. If the two applications are not matching RXG and RXA segments, this field's value is zero (0). 2935 RXA-2 Administration Sub-ID Counter, Required This field starts with 1 the first time that medication/treatment is administered for this order. Increments by one with each additional administration the medication/treatment. Note: More than one RXA segment can be "matched" to a single RXG segment, as is the case when recording a change of the 2940 rate of administration of an IV solution.

RXA-3 Date/Time Start of Administration, Required

Components: ^ If the order is for a continuous administration (such as an IV), and the rate is changed at a certain 2945 time after the start, an RAS message can be issued to record the change. For such an RAS message, this field records the time the rate was changed to the new value recorded in the RXA- 12-administered per (time unit) of the same message.

RXA-4 Date/Time End of Administration (If Applies), Required

2950 Components: ^ This is the end time/date of the administration. If null, the date/time of RXA-3-Date/Time Start of Administration is assumed by the application to be also the end date/time. In case of a continuous administration like IV, this field refers to the expected end/date time, and will be updated in subsequent RAS messages, if there is a change in the rate, for example. 2955 RXA-5 Administered Code, Required

Components: ^ ^ ^ ^ ^ 2960 This field contains the identifier of the medical substance/treatment administered.

RXA-6 Administered Amount, Required This field contains the amount administered.

2965 RXA-7 Administered units, Conditional

Components: ^ ^ ^ ^ ^

This field is conditional because it is required if the administered amount code does not 2970 implicitly contain units. This field must be in simple units that reflect the actual quantity of the substance administered. It does not include compound units.

RXA-8 Administered Dosage Form, Optional

Components: ^ ^ ^ 2975 ^ ^ The dosage form indicates the manner in which the medication/treatment is aggregated for dispensing, e.g., tablets, capsules, suppositories. In some cases, this information is implied by the dispense/give code in RXA-5-Administered Code. Use this field when the administered code 2980 does not specify the dosage form. RXA-9 Administration Notes, Optional

Components: ^ ^ ^ ^ ^ 2985 This field contains notes from the provider administering the medication/treatment. If coded, requires a user-defined table. If free text (describing a custom IV, mixture, or salve, for example) place a null in the first component and the text in the second, e.g., |^this is a free text administration note|.

2990 RXA-10 Administering Provider, Required

Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 2995 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 3000 This field contains the provider ID of the person administering the pharmaceutical/treatment.

RXA-11 Administered-at Location, Optional

Components: ^ ^ ^ ^ 3005 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^

Subcomponents for Facility (HD): & & 3010

The first component contains the inpatient or outpatient location at which the drug or treatment was administered (if applicable). The default (null) value is the current census location for the patient.

3015 RXA-12 Administered Per (Time Unit), Conditional This field contains the rate at which this medication/treatment was administered as calculated by using RXA-6-administered amount and RXA-7-administered units. This field is conditional because it is required when a treatment is administered continuously at a prescribed rate, e.g., certain IV solutions. 3020

RXA-15 Substance Lot Number, Optional This field contains the lot number of the medical substance administered. Note: The lot number is the number printed on the label attached to the container holding the substance and on the packaging 3025 which houses the container. If the substance is a vaccine, for example, and a diluent is required, a lot number may appear on the vial containing the diluent; however, any such identifier associated with a diluent is not the identifier of interest. The substance lot number should be reported, not that of the diluent.

RXA-16 Substance Expiration Date, Optional

3030 Components: ^ This field contains the expiration date of the medical substance administered. Note: Vaccine expiration date does not always have a "day" component; therefore, such a date may be transmitted as YYYYMM.

3035 RXA-17 Substance Manufacturer Name, Optional

Components: ^ ^ ^ ^ ^ This field contains the manufacturer of the medical substance administered. 3040 Note: For vaccines, code system MVX may be used to code this field). This field may be used if the manufacturer of the substance is not identified by the code used in RXA-5- administered code.

RXA-18 Substance/Treatment Refusal Reason, Optional

Components: ^ ^ ^ 3045 ^ ^

This field contains the reason the patient refused the medical substance/treatment. Any entry in the field indicates that the patient did not take the substance.

3050 RXA-19 Indication, Optional

Components: ^ ^ ^ ^ ^ This field contains the identifier of the condition or problem for which the drug/treatment was 3055 prescribed. May repeat if multiple indications are relevant. If RXO segment is present, RXA-19 has the same value as RXO-20.

RXA-20 Completion Status, Optional Status of treatment administration event. Refer to HL7 Table 0322 - Completion Status for valid 3060 values. HL7 Table 0322 - Completion Status Value Description Comment CP Complete RE Refused NA Not Administered PA Partially Administered

RXA-25 Administered Barcode Identifier, Optional

Components: ^ ^ ^ 3065 ^ ^ ^ ^ ^ This field contains the pharmacy system's assigned barcode number for the give occurrence. For IV orders, many pharmacy systems generate a barcode number to identify a specific bag/bottle of 3070 the order. This number can be an instance identifier; unique for the patient, drug combination, and schedule instance or it may be just a drug identifier. The format and composition of the barcode information are not in scope of IHE, IHE relies on the barcode being uniquely identifiable as needed.

A.15 AL1 - Patient Allergy Information Segment 3075 This segment is used in all transactions and is used to send information about the patient’s allergies. IHE-HMW does not impose additional constraints on the use of this segment. HL7 v2.5: chapter 3 (3.4.6)

Table A.15-1: AL1 - Patient Allergy Information Segment SEQ LEN DT Usage Card. TBL# ITEM# Element name 1 4 SI R [1..1] 00203 Set ID - AL1 2 250 CE O [0..1] 0127 00204 Allergen Type Code 3 250 CE R [1..1] 00205 Allergen Code/Mnemonic/Description 4 250 CE O [0..1] 0128 00206 Allergy Severity Code 5 15 ST O [0..*] 00207 Allergy Reaction Code 6 8 DT X [0..0] 00208 Identification Date

3080 A.16 IN1 - Insurance Segment The IN1 segment contains insurance policy coverage information necessary to produce properly pro-rated and patient and insurance bills.

Table A.16-1: IN1 - Insurance Segment SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME 1 4 SI R 00426 Set ID - IN1 2 250 CE R 0072 00368 Insurance Plan ID 3 250 CX R Y 00428 Insurance Company ID 4 250 XON O Y 00429 Insurance Company Name 5 250 XAD O Y 00430 Insurance Company Address 6 250 XPN O Y 00431 Insurance Co Contact Person 7 250 XTN O Y 00432 Insurance Co Phone Number 8 12 ST O 00433 Group Number 9 250 XON O Y 00434 Group Name 10 250 CX O Y 00435 Insured’s Group Emp ID 11 250 XON O Y 00436 Insured’s Group Emp Name 12 8 DT O 00437 Plan Effective Date 13 8 DT O 00438 Plan Expiration Date 14 239 AUI O 00439 Authorization Information 15 3 IS O 0086 00440 Plan Type 16 250 XPN O Y 00441 Name Of Insured 17 250 CE O 0063 00442 Insured’s Relationship To Patient 18 26 TS O 00443 Insured’s Date Of Birth 19 250 XAD O Y 00444 Insured’s Address 20 2 IS O 0135 00445 Assignment Of Benefits 21 2 IS O 0173 00446 Coordination Of Benefits 22 2 ST O 00447 Coord Of Ben. Priority 23 1 ID O 0136 00448 Notice Of Admission Flag 24 8 DT O 00449 Notice Of Admission Date

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME 25 1 ID O 0136 00450 Report Of Eligibility Flag 26 8 DT O 00451 Report Of Eligibility Date 27 2 IS O 0093 00452 Release Information Code 28 15 ST O 00453 Pre-Admit Cert (PAC) 29 26 TS O 00454 Verification Date/Time 30 250 XCN O Y 00455 Verification By 31 2 IS O 0098 00456 Type Of Agreement Code 32 2 IS O 0022 00457 Billing Status 33 4 NM O 00458 Lifetime Reserve Days 34 4 NM O 00459 Delay Before L.R. Day 35 8 IS O 0042 00460 Company Plan Code 36 15 ST O 00461 Policy Number 37 12 CP O 00462 Policy Deductible 38 12 CP B 00463 Policy Limit - Amount 39 4 NM O 00464 Policy Limit - Days 40 12 CP B 00465 Room Rate - Semi-Private 41 12 CP B 00466 Room Rate - Private 42 250 CE O 0066 00467 Insured’s Employment Status 43 1 IS O 0001 00468 Insured’s Administrative Sex 44 250 XAD O Y 00469 Insured’s Employer’s Address 45 2 ST O 00470 Verification Status 46 8 IS O 0072 00471 Prior Insurance Plan ID 47 3 IS O 0309 01227 Coverage Type 48 2 IS O 0295 00753 Handicap 49 250 CX O Y 01230 Insured’s ID Number 50 1 IS O 0535 01854 Signature Code 51 8 DT O 01855 Signature Code Date 52 250 ST O 01899 Insured’s Birth Place 53 2 IS O 0099 01852 VIP Indicator

3085 A.17 IN2 - Insurance Additional Information Segment The IN2 segment contains additional insurance policy coverage and benefit information necessary for proper billing and reimbursement. Fields used by this segment are defined by CMS or other regulatory agencies.

Table A.17-1: IN2 - Insurance Additional Information Segment SEQ LEN DT OPT RP/ TBL# ITEM# ELEMENT NAME #

SEQ LEN DT OPT RP/ TBL# ITEM# ELEMENT NAME # 1 250 CX O Y 00472 Insured’s Employee ID 2 11 ST O 00473 Insured’s Social Security Number 3 250 XCN O Y 00474 Insured’s Employer’s Name and ID 4 1 IS O 0139 00475 Employer Information Data 5 1 IS O Y 0137 00476 Mail Claim Party 6 15 ST O 00477 Medicare Health Ins Card Number 7 250 XPN O Y 00478 Medicaid Case Name 8 15 ST O 00479 Medicaid Case Number 9 250 XPN O Y 00480 Military Sponsor Name 10 20 ST O 00481 Military ID Number 11 250 CE O 0342 00482 Dependent Of Military Recipient 12 25 ST O 00483 Military Organization 13 25 ST O 00484 Military Station 14 14 IS O 0140 00485 Military Service 15 2 IS O 0141 00486 Military Rank/Grade 16 3 IS O 0142 00487 Military Status 17 8 DT O 00488 Military Retire Date 18 1 ID O 0136 00489 Military Non-Avail Cert On File 19 1 ID O 0136 00490 Baby Coverage 20 1 ID O 0136 00491 Combine Baby Bill 21 1 ST O 00492 Blood Deductible 22 250 XPN O Y 00493 Special Coverage Approval Name 23 30 ST O 00494 Special Coverage Approval Title 24 8 IS O Y 0143 00495 Non-Covered Insurance Code 25 250 CX O Y 00496 Payor ID 26 250 CX O Y 00497 Payor Subscriber ID 27 1 IS O 0144 00498 Eligibility Source 28 82 RMC O Y 00499 Room Coverage Type/Amount 29 56 PTA O Y 00500 Policy Type/Amount 30 25 DDI O 00501 Daily Deductible 31 2 IS O 0223 00755 Living Dependency 32 2 IS O Y 0009 00145 Ambulatory Status 33 250 CE O Y 0171 00129 Citizenship 34 250 CE O 0296 00118 Primary Language 35 2 IS O 0220 00742 Living Arrangement 36 250 CE O 0215 00743 Publicity Code 37 1 ID O 0136 00744 Protection Indicator 38 2 IS O 0231 00745 Student Indicator

SEQ LEN DT OPT RP/ TBL# ITEM# ELEMENT NAME # 39 250 CE O 0006 00120 Religion 40 250 XPN O Y 00109 Mother’s Maiden Name 41 250 CE O 0212 00739 Nationality 42 250 CE O Y 0189 00125 Ethnic Group 43 250 CE O Y 0002 00119 Marital Status 44 8 DT O 00787 Insured’s Employment Start Date 45 8 DT O 00783 Employment Stop Date 46 20 ST O 00785 Job Title 47 20 JCC O 00786 Job Code/Class 48 2 IS O 0311 00752 Job Status 49 250 XPN O Y 00789 Employer Contact Person Name 50 250 XTN O Y 00790 Employer Contact Person Phone Number 51 2 IS O 0222 00791 Employer Contact Reason 52 250 XPN O Y 00792 Insured’s Contact Person’s Name 53 250 XTN O Y 00793 Insured’s Contact Person Phone Number 54 2 IS O Y 0222 00794 Insured’s Contact Person Reason 55 8 DT O 00795 Relationship to the Patient Start Date 56 8 DT O Y 00796 Relationship to the Patient Stop Date 57 2 IS O 0232 00797 Insurance Co. Contact Reason 58 250 XTN O 00798 Insurance Co Contact Phone Number 59 2 IS O 0312 00799 Policy Scope 60 2 IS O 0313 00800 Policy Source 61 250 CX O 00801 Patient Member Number 62 250 CE O 0063 00802 Guarantor’s Relationship to Insured 63 250 XTN O Y 00803 Insured’s Phone Number - Home 64 250 XTN O Y 00804 Insured’s Employer Phone Number 65 250 CE O 0343 00805 Military Handicapped Program 66 1 ID O 0136 00806 Suspend Flag 67 1 ID O 0136 00807 Copay Limit Flag 68 1 ID O 0136 00808 Stoploss Limit Flag 69 250 XON O Y 00809 Insured Organization Name and ID 70 250 XON O Y 00810 Insured Employer Organization Name and ID 71 250 CE O Y 0005 00113 Race 72 250 CE O 0344 00811 CMS Patient’s Relationship to Insured

3090 A.18 IN3 - Insurance Additional Information, Certification Segment

The IN3 segment contains additional insurance information for certifying the need for patient care. Fields used by this segment are defined by CMS, or other regulatory agencies.

Table A.18-1: IN3 - Insurance Additional Information, Certification Segment SEQ LEN DT OPT RP/# TBL ITEM# ELEMENT NAME # 1 4 SI R 00502 Set ID - IN3 2 250 CX O 00503 Certification Number 3 250 XCN O Y 00504 Certified By 4 1 ID O 0136 00505 Certification Required 5 23 MOP O 00506 Penalty 6 26 TS O 00507 Certification Date/Time 7 26 TS O 00508 Certification Modify Date/Time 8 250 XCN O Y 00509 Operator 9 8 DT O 00510 Certification Begin Date 10 8 DT O 00511 Certification End Date 11 6 DTN O 00512 Days 12 250 CE O 0233 00513 Non-Concur Code/Description 13 26 TS O 00514 Non-Concur Effective Date/Time 14 250 XCN O Y 0010 00515 Physician Reviewer 15 48 ST O 00516 Certification Contact 16 250 XTN O Y 00517 Certification Contact Phone Number 17 250 CE O 0345 00518 Appeal Reason 18 250 CE O 0346 00519 Certification Agency 19 250 XTN O Y 00520 Certification Agency Phone Number 20 40 ICD O Y 00521 Pre-Certification Requirement 21 48 ST O 00522 Case Manager 22 8 DT O 00523 Second Opinion Date 23 1 IS O 0151 00524 Second Opinion Status 24 1 IS O Y 0152 00525 Second Opinion Documentation Received 25 250 XCN O Y 0010 00526 Second Opinion Physician