Attachment 4 CMOP Data Interface Control V2.1.30 Document.doc

Consolidated Mail Outpatient Pharmacy (CMOP)

Electronic Data Interface (EDI) Guidelines

Version 2.1.30

January 2020 1 Table of Contents 1Version 2.1.30

Table of Contents

51.11 Revision Version 2.1.11

51.12 Revision Version 2.1.12

51.13 Revision Version 2.1.13

51.14 Revision Version 2.1.14

51.15 Revision Version 2.1.15

61.16 Revision Version 2.1.16

61.17 Revision Version 2.1.17

81.18

- Revision Version 2.1.18

81.19

- Revision Version 2.1.19

81.20

- Revision Version 2.1.20 – Mail Consolidator additions

91.21 Revision Version 2.1.21

91.22 Revision Version 2.1.22

91.23 Revision Version 2.1.23

91.24 Revision Version 2.1.24

101.25 Revision Version 2.1.25

101.26 Revision Version 2.1.26

101.27 Revision Version 2.1.27

111.28 Revision Version 2.1.28

111.29 Revision Version 2.1.29

121.30 Revision Version 2.1.30

13GENERAL HL7 INFORMATION

131.

Introduction

Key Terms

Message Rules

Segment Rules

Field Rules

Message Construction Rules

166.1 The following rules apply to receiving HL7 messages and converting their contents to data values:

Communication Protocol

Socket-to-Socket TCP/IP Message Processing

178.1.1 Daily Common Segment Messages

188.1.2 MSH – Message Header Segment – Required segment

198.1.3 MFI – Master File Identification - Required segment

198.1.4 MFE – Master File Entry – Required segment

208.1.5 ZP1 – Pharmacy Information – Required segment

208.1.6 ZR3 – Order Instructions Text – Optional segment

228.2 Patient Prescription Messages

238.2.1

248.2.2 PID – Patient Identification Segment – Required segment

258.2.3 ZSL – Suspense Label Segment – Optional segment

258.2.4 ORC – Common Order Segment – Required segment

268.2.5 RXE – Pharmacy/Treatment Encoded Order Segment – Required segment

278.2.6 ZS7 – Additional Medication Instructions Segment – Optional segment

298.2.7 ZR1 – Rx Order Additional Information Segment – Required segment

318.2.8 ZW1– Special Medication Instructions Segment – Optional segment

328.2.9 ZC1– Special Instructions Comment Segment – Optional segment

338.2.10 ZC2– Cancelation Comment Segment – Optional segment

348.3 CMOP Message Acknowledgment/Non Acknowledgement

348.3.1

358.3.2 MSA – Message Acknowledgement Segment – Required segment

368.4 Prescription Fulfillment Messages

378.4.1

388.4.2 ZP1 – Pharmacy Information – Mail Consolidator Only Required

398.4.3

408.4.4 ORC – Common Order Segment – Required segment

408.4.5 RXD – Pharmacy/Treatment Dispense Segment – Required segment

428.4.6 ZX1 Additional Lot Numbers and Expiration Dates

438.4.7 ZR2 – Release Data Additional Information Segment – Conditional Segment Outsource Vendors only

468.5 Prescription Fulfillment Acknowledgement

468.5.1

478.5.2

478.6 Prescription Package Tracking Messages

488.6.1

498.6.2

498.6.3 ORC – Common Order Segment – Required segment - Mail Consolidator not Used

508.6.4 ZR4 – Package Tracking Data – Required segment

538.7 Prescription Package Tracking Acknowledgement

538.7.1

548.7.2

568.8 Patient Query Message

568.8.1

578.8.2 ZRQ – Rx Order Query – Required segment

588.9 Package Recall Messages - Mail Consolidator

588.9.1

598.9.2 ZP1 – Pharmacy Information – Mail Consolidator Only Required

608.9.3

618.9.4 ZR6 – Release Data Additional Information Segment –

628.10 Package Recall Acknowledgement - Mail Consolidator

628.10.1

638.10.2

638.11 Package Recall Status Messages - Mail Consolidator

648.11.1

658.11.2

668.11.3 ZR8 – Release Data Additional Information Segment

678.12 Package Recall Status Acknowledgement - Mail Consolidator

678.12.1

688.12.2

69Appendix A: ISO Table 639 Language Codes:

70Appendix B: ZRQ Query Type Codes:

76Appendix C: Reject Reason Code Table:

82Appendix D: HL7 Escape sequences:

1.1 Revision Version 2.1.11

· Spelling corrections and Sample corrections.

1.2 Revision Version 2.1.12

· Graphic in section 8.4 to represent that the ZR2 segment can repeat.

· Section 8.4.6 First paragraph revise to include that the ZR2 can repeat.

· Section 8.4.6 Table (row Package Tracking Number) includes “or Reference ID used with a mail consolidator”

· Section 8.4.6 Examples to include multiple ZR2 segments.

· Appendix C: Reject Reason Code Table:: Reject reason 200, 201 and 202

1.3 Revision Version 2.1.13

· Wording has been changed to accommodate the communication to other entities besides Direct to Patient Vendors (DTP).

· the MSH Field sequence 3 and sequence 5 CMOP will be using “CMOP – CDB”.

· 8.2.12 ZC1– Special Instructions Comment Segment addition to document

· 8.2.13 ZC2– Cancelation Comment Segment - addition to document

· 8.4.5 ZX1 Additional Lot Numbers and Expiration Dates- addition to document

· 8.6 Prescription Package Tracking- addition to document

· 8.7 Prescription Package Tracking Acknowledgment addition to document

· Appendix C: Reject Reason Code Table: Added Error codes in Reject Reason Codes 122 to 159

1.4 Revision Version 2.1.14

· Corrected Example Language type in 8.2.12 ZC2– Cancelation Comment Segment

· Graphic in section 8.2 addition of the ZPD Alternate Address Segment

· 8.2.3 ZPD – Alternate Address - addition to document

· 8.2.4 ZA8 – Additional Patient Street Address - change to handle primary and alternate address.

1.5 Revision Version 2.1.15

· Corrected Example Language type in 8.2.13 ZC2– Cancelation Comment Segment

· Added to the Description in table for 8.2.13 ZC2– Cancelation Comment Segment

· Added to the Description in table for 8.2.12 ZC1– Cancelation Comment Segment

· Corrected the graphic for 8.2 Patient Prescription Messages

· Added Field 3 of the ORC Segment in 8.2.7, 8.4.3 and 8.6.3.

1.6 Revision Version 2.1.16

· Section 8, 4th Paragraph. Reference ORC-4 (8.2.4) should be ORC-4 (8.2.7)

· Section 8, 4th Paragraph Query Type (8.6 and Appendix B). Should be Query Type (8.8 and Appendix B).

· Section 8.1.4 Field Sequence 2 changed from Conditional to Required.

· Section 8.4.3 ORC Field Sequence 2 changed from Optional to Required.

· Section 8.4.5 ZX1 Field Sequence 2 changed from Optional to Required.

· Section 8.4.5 ZX1 Field Sequence 3 changed from Optional to Required.

· Section 8.6.4 ZR4 Field Sequence 4 changed from Required to Optional.

· Section 8.6.4 ZR4 Field Sequence 5 changed from Required to Optional.

· Section 8.6.4 ZR4 Field Sequence 6 changed from Required to Optional.

· Section 8.6.4 ZR4 Field Sequence 7 changed from Required to Optional.

· Section 8.6.4 ZR4 Field Sequence 8 changed from Required to Optional.

· Section 8.6.4 ZR4 Field Sequence 9 changed from Required to Optional.

· Section8.3.2.1 ADDITIONAL FIELD NOTES removed reference of -0 to indicate error within the batch information.

· Section8.5.2.1 ADDITIONAL FIELD NOTES removed reference of -0 to indicate error within the batch information.

· Section8.7.2.1 ADDITIONAL FIELD NOTES removed reference of -0 to indicate error within the batch information.

· Section8.8 ZRQ Messages removed reference of -0 to indicate error within the batch information.

· Section 8.4.4 RXD Field Sequence 10 Pharmacist who filled it.

· Section 8.6.2 ZR4 Field Sequence 3 description removed reference of the RXD segment.

· Section 8.6.2 ZR4 Example changed Segment label ZR2 to ZR4.

· Section 8.2.8 RXE Field Sequence 7 Removed the size of 80 characters.

· Changed Revision History Labeling.

1.7 Revision Version 2.1.17

· Section 8.2.6 Drug Name size changed to 100.

· Section 8.2.11 added to first paragraph “The first Zw1 segment will always be number 1 for each language.”

· ZX1 Additional Lot Numbers and Expiration Dates example did not have the ZX1 on the example.

· Section 8.2.13 ZC2– Cancelation Comment Segment in the table the Type stated one (99). Should be Ninety-Nine (99).

· Section 8.2.2 PID – Patient Identification Segment Address type change from AD to XAD, Description change and examples changed.

· Section 8.4.2 PID – Patient Identification Segment Address type change from AD to XAD, Description change and examples changed.

· Section 8.2.3 ZPD – Alternate Address Removed as it is incorporated into the XAD structure of the PID.

· Section 8.2.4 ZA8 Additional Patient Street Address Information Removed as it is incorporated into the XAD structure of the PID.

· Section 8.2.5 ORC – Common Order Segment sequence 2 - Placer Order Number, The RxIndex was removed and prescription number defined for the item and updated the Examples.

· Section 8.2.6 RXE – Pharmacy/Treatment Encoded Order Segment Sequence 15 - Prescription Number RxIndex was removed and Prescription number defined and updated the Examples.

· Section 8.2.7 ZS7 – Additional Medication Instructions Segment Sequence 2 - Prescription Number RxIndex was removed and Prescription number defined and updated the Examples.

· Section 8.2.8 ZR1 – Rx Order Additional Information Segment Sequence 1 - Prescription Number RxIndex was removed and Prescription number defined and updated the Examples.

· Section 8.2.9 ZW1– Special Medication Instructions Segment Sequence 2 - Prescription Number RxIndex was removed and Prescription number defined and updated the Examples.

· Section 8.2.10 ZC1– Special Instructions Comment Segment Sequence 2 - Prescription Number RxIndex was removed and Prescription number defined and updated the Examples.

· Section 8.2.11 ZC2– Special Instructions Comment Segment Sequence 2 - Prescription Number RxIndex was removed and Prescription number defined and updated the Examples.

· Section 8.3.2 MSA – Message Acknowledgement Segment Sequence 3- Text Message RxIndex was removed and Cerner DISPENSE HISTORY ID in its place and updated the Examples.

· Section 8.4.3 ORC – Common Order Segment sequence 2 - Placer Order Number, The RxIndex was removed and prescription number defined for the item and updated the Examples.

· Section 8.6. ZR2 – Release Data Additional Information Segment sequence 3 – Prescription Number, The RxIndex was removed and Cerner DISPENSE HISTORY ID in its place and updated the Examples.

· Section 8.5.2 MSA – Message Acknowledgement Segment Sequence 2- Prescription Number RxIndex was removed and Cerner DISPENSE HISTORY ID in its place and updated the Examples.

· Section 8.6.2 PID – Patient Identification Segment Address type change from AD to XAD, Description change and examples changed.

· Section 8.6.3 ORC – Common Order Segment sequence 2 - Placer Order Number, The RxIndex was removed and prescription number defined for the item and updated the Examples.

· Section 8.6.4 ZR4 – Package Tracking Data sequence 3 – Prescription Number, The RxIndex was removed and Cerner DISPENSE HISTORY ID in its place and updated the Examples.

· Section 8.7.2 MSA – Message Acknowledgement Segment Sequence 2- Prescription Number RxIndex was removed and Cerner DISPENSE HISTORY ID in its place and updated the Examples.

· Section 8.8.2 ZRQ – Rx Order Query Sequence 2- Rx Number RxIndex was removed and Cerner DISPENSE HISTORY ID in its place and updated the Examples.

· Appendix C: Reject Reason Code Table – Deprecated ZA8 and PID 11 error codes. Added PID XAD 11 error codes

1.8 - Revision Version 2.1.18

· Section 8.4.3 ORC Field Sequence 12 Ordering Provider Size from 80 to 401.

· Section 8.2.6 RXE Field Sequence 2 changed size from 100 to 200.

· Section 8.2.8 ZR1 Field Sequence 7 changed size from 40 to 60.

· Section 8.2.2 PID Field Sequence 5 Changed the size to 411.

· Section 8.4.2 PID Field Sequence 5 Changed the size to 411.

· Section 8.6.2 PID Field Sequence 5 Changed the size to 411.

1.18a

· Section 8.2.3 Removed all ZML Messages.

1.9 - Revision Version 2.1.19

· Section 8.2.7 ZR1 – Field Sequence 2 Rx Patient Status Removed

· Section 8.2.7 ZR1 – Field Sequence 7 Clinic Removed

· Appendix C: Reject Reason Code Table – Error code 52 and 57 deprecated.

· Section 8.2.7 ZR1 – Field Sequence 13 PMI -Clarification that VistA uses First Data bank and Cerner uses Multum.

· Section 8.2.5 RXE – Pharmacy/Treatment Encoded Order Segment Field 21 added - Pharmacy/Treatment Supplier's Special Dispensing Instructions Value is 1^SCRIPT_TALK

1.10 - Revision Version 2.1.20 – Mail Consolidator additions

· Section 8.4.5 RXD – Pharmacy/Treatment Dispense Segment field 25 Supplement added to the description “This is the 11-digit NDC. NDC will be in the format of 5 dash 4 dash 2, example 12345-1234-12”

· Section 8.4 Prescription Fulfillment Messages – Defined the three use case of fulfillment segments used when the communication is VA internal, Outsource Vender and Mail Consolidator. Updated graphics for each use case.

· Section 8.2.6 Release Data Additional Information Segment added Field 10 Billing CMOP

· Section 8.2.6 Release Data Additional Information Segment added Field 11 Package Reference Number

· Section 8.1.5 ZP1 Title changed from Sending Pharmacy Information to Pharmacy Information.

· Section 8.4.2 was added as ZP1 Pharmacy Information. Mail Consolidator use only

· Section 8.4.2 becomes Section 8.4.3

· Section 8.4.3 becomes Section 8.4.4

· Section 8.4.4 becomes Section 8.4.5

· Section 8.4.5 becomes Section 8.4.6

· Section 8.4.6 becomes Section 8.4.7

· Section 8.4.3 PID – Patient Identification Segment field 11 added to the description that only one address will be sent.

· Section 8.4.7 ZR2 fields 1,4,5, and 7 added wording that the Mail consolidator value is null.

· Section 8.4.7 ZR2 fields 2, 6, and 9 added wording that the value is null.

· Section 8.4.7 ZR2 Updated examples to the new fields.

· Section 8.6.6 ZR4 Release Data Additional Information Segment added Field 10 Billing CMOP.

· Section 8.6.6 ZR4 Release Data Additional Information Segment added Field 11 Package

· Section 8.6.6 ZR4 Release Data Additional Information Segment added Field 12 Text – package not shipped reason.

· Section 8.6.6 ZR4 Release Data Additional Information Segment removed any reference to a cancelled prescription.

· Added error message for the new fields in ZR2 and ZR4 error values 176 to 179

· Added error message for the new fields in ZR6 and ZR8 error values 180 to 189

· Added error message for the new fields in ZR4, ZR6 and ZR8 error values 190 to 192

· Added Section 8.9 Package Recall Message

· Added Section 8.10 Package Recall Acknowledgment.

1.11 Revision Version 2.1.21

· 8.2.7 ZR1 – Rx Order Additional Information Segment- Sequence 13. The PMSI Data is spit into subfields. The first field is for VistA PMI or the MNDC of Multum and the second subfield is for the DNUM.

1.12 Revision Version 2.1.22

· Correct the 1.21 revision version corrected “8.2.7 ZR1 – Rx Order Additional Information Segment- Sequence 13. The PMSI Data is spit into subfields. The first field is for VistA PMI or the MNDC of Multum and the second subfield is for the DNUM.”

· Corrected the example for DNUM on page 26 and added the additional information of the MNDC and DNUM definition on the PMSI field.

1.13 Revision Version 2.1.23

· Correct the 1.22 revision version corrected “8.2.7 ZR1 – Rx Order Additional Information Segment- Sequence 13. Updated the DNUM example “d0011”.

· Corrected the example for DNUM on page 26 and added the additional information of the MNDC and DNUM definition on the PMSI field.

· 8.4.7 ZR2 segment added Delivery confirmation used for Mail Consolidator.

· 8.4.7 ZR2 segment added Signature confirmation used for Mail Consolidator.

· 8.4.7 ZR2 updated the examples for mail consolidator.

· 8.6.4 ZR4 added Over 84" Flag, Over 108" Flag and Non-Machinable Outside, Parcel Process Date Time, Parcel Shipping Zone, Delivery Confirmation, Confirmation Surcharge, and NMO Surcharge.

· 8.6.4 ZR4 updated the examples of the Mail Consolidator.

1.14 Revision Version 2.1.24

· 8.4.7 ZR2 segment Signature confirmation ZR4.13 corrected the field name to Signature confirmation.

· 8.6.4 ZR4 The graphic was changed to indicate ZR4.16 will be returned to Cerner.

· 8.6.4 ZR4 – ZR4.16 Parcel Process Date Time was updated to specify it will be returned to Cerner.

· 8.6.4 ZR4 updated the examples.

· 8.4.5 RXD – Pharmacy/Treatment Dispense Segment RXD.25 Supplement Code defined the third element that defines what the data value represents (NDC or UPC).

· 8.4.5 RXD – Pharmacy/Treatment Dispense - updated examples for the third element.

1.15 Revision Version 2.1.25

· 8.2.5 RXE in the note section the field 15 defines the RXINDEX for VistA.

· 8.2.5 RXE in the note section the field 15 Give Amount - Updates the description that the amount to be picked unless a conversion factor needs to be applied. In that case This field is the original Quantity on the sending system. The ZR1 Field 22 (Pack Size) is the conversion factor and ZR1 Field 23 (Qty to Pick) is quantity to be picked.

· 8.2.7 ZR1 Field 22 Pack Size – updated the description that this is the conversion factor is to applied

· 8.2.7 ZR1 Field 23 Pack Size – updated the description that this is the actual amount to be picked. The calculation is RXE.1/ZR1.22 = ZR1.23.

· 8.2.7 ZR1 Updates examples.

· 8.2.4 ORC updated the examples to include the DISP_HIST_ID.

1.16 Revision Version 2.1.26

· 8.3.1 MSH – Message Header Segment field 10 Control ID description added text that the value is the same value that is in 8.2.1 MSH Field 10.

· 8.3.2 MSA – Message Acknowledgement Segment - Message Control ID was updated to be the DISP_HIST_ID consistent with the document.

· 8.3.2 MSA – Message Acknowledgement Segment – Text Message was updated removing the DISP_HIST_ID as it was moved into the Message Control ID consistent with the document.

· 8.2.4 ORC – Common Order Segment updated the example specifically the Rx number to be more representative of a Cerner Rx number. Internal site number-Rx Number.

· 8.4.4 ORC – Common Order Segment - updated the example specifically the Rx number to be more representative of a Cerner Rx number. Internal site number-Rx Number.

· 8.6.3 ORC – Common Order Segment updated the example specifically the Rx number to be more representative of a Cerner Rx number. Internal site number-Rx Number.

· 8.2.7 ZR1 – Rx Order Additional Information Segment – updated the Cerner Examples to reflect closer to Cerner defined RX Number.

· 8.2.5 RXE – Pharmacy/Treatment Encoded Order Segment - Give Amount – Minimum is removed from the specification only RXE.1 will be used.

· 8.2.7 ZR1 – Rx Order Additional Information Segment – changed the reference form RXE.3 to RXE.1

1.17 Revision Version 2.1.27

· 8.2.10 ZC2– Cancelation Comment Segment updated the description fields 6 to the cancelled information that was sent by CMOP.

· 8.4.1 MSH – Message Header Segment field – removed the information about the Mail consolidator making the field consistent with MSH 10 segments.

· 8.9.1 MSH – Message Header Segment field – removed the information about the Mail consolidator making the field consistent with MSH 10 segments.

· 8.10.1 MSH – Message Header Segment field – removed the information about the Mail consolidator making the field consistent with MSH 10 segments

· 8.11.1 MSH – Message Header Segment field – removed the information about the Mail consolidator making the field consistent with MSH 10 segments.

· 8.12.1 MSH – Message Header Segment field – removed the information about the Mail consolidator making the field consistent with MSH 10 segments.

· 8.4.1 PID – Patient Identification Segment – clarified the use of the XAD structure for three line address.

· 8.2.9 ZC1– Special Instructions Comment Segment – updated Examples.

· 8.2.10 ZC2– Cancelation Comment Segment– updated Examples.

1.18 Revision Version 2.1.28

· Addition of Error Codes For third address as defined by the XAD structure Error code 205 to 212.

· Addition of Error Codes Script Pro Error code 213 and 214

· Addition of Error Codes for MSA Error code 215 to 218.

· Deprecated Error code Value Zero (0) MSA 3 to now Error Code 217 and 218.

· Addition of Error Codes For ZR3 Error code 225 to 230.

· Deprecated Error code Value 12, 13, and 14 SEGMENT-SEQUENCE now Error Code 228 , 229 and 230. XE “Outpatient Pharmacy HL7 Interface Specification” \b Revision Version 2.1.28

1.19 Revision Version 2.1.29

· 8.2.2 PID – Patient Identification Segment – Required segment had a sequence 4 added

· The sequence 4 is an alternate patient identifier. It will hold the SSN of the patient the record relates to.

· There is no guarantee that it will be an SSN or that it will be sent to VA partners. See note section.

· PID sequence 3 had the description text to reflect it will always be an ICN.

· Examples updated for PID.

· 8.4.3 PID – Patient Identification Segment – Required segment had a sequence 4 added

· The sequence 4 is an alternate patient identifier. It will hold the SSN of the patient the record relates to.

· There is no guarantee that it will be an SSN or that it will be sent to VA partners. See note section.

· PID sequence 3 had the description text to reflect it will always be an ICN.

· Examples updated for PID.

· 8.6.2 PID – Patient Identification Segment – Required segment had a sequence 4 added

· The sequence 4 is an alternate patient identifier. It will hold the SSN of the patient the record relates to.

· There is no guarantee that it will be an SSN or that it will be sent to VA partners. See note section.

· PID sequence 3 had the description text to reflect it will always be an ICN.

· Examples updated for PID.

· 8.9.3 PID – Patient Identification Segment – Required segment had a sequence 4 added

· The sequence 4 is an alternate patient identifier. It will hold the SSN of the patient the record relates to.

· There is no guarantee that it will be an SSN or that it will be sent to VA partners. See note section.

· PID sequence 3 had the description text to reflect it will always be an ICN.

· Examples updated for PID

· 8.11.2 PID – Patient Identification Segment – Required segment had a sequence 4 added

· The sequence 4 is an alternate patient identifier. It will hold the SSN of the patient the record relates to.

· There is no guarantee that it will be an SSN or that it will be sent to VA partners. See note section.

· PID sequence 3 had the description text to reflect it will always be an ICN.

· Examples updated for PID

· Reject Reason Code Table added code 231 for PID-4.

· Removed the highlighted dates in the example of the ZC2 segments.

· Updated the Revision to January 2020 2.1.29 on cover page.

1.20 Revision Version 2.1.30

· Updated the ZRQ MSH control ID as a three part xxx-yyyyyyyy-zzz. Only items that are two part control ID is QRO01 and QRA00.

· Changed the table in Appendix B: ZRQ Query Type Codes: for the QRA01 to only represent the control id as three part xxx-yyyyyyyy-zzz.

· CMOP HL7 Interface Specification GENERAL HL7 INFORMATION XE “GENERAL HL7 INFORMATION” \b

1. Introduction

This document defines the standard electronic data interface (EDI) used by Department of Veteran Affairs Consolidated Mail Outpatient Pharmacy (CMOP) system for Contract Vendors. This specification is based upon the Health Level 7 Standard (HL7) Version Batch: 2.5.1, MLLP: 2.5. The term “Level 7” refers to the highest level of the Open System Interconnection (OSI) model of the International Standards Organization (ISO). The OSI model is divided into seven levels or layers. The HL7 Standard is primarily focused on what happens within the seventh or application layer. The definitions of the data to be exchanged, the timing of the exchanges, and the communication of certain application specific errors occur at this layer. In simple terms HL7 is a health industry standard communications protocol used to exchange data between disparate systems. The CMOP uses this standard to exchange data in the following situations:

a. Contract Vendors and the CMOP Core National system 2 Key Terms Prescription Order Data: This the data needed by the filling agency to dispense and mail the Rx to the patient.

Prescription Fulfillment Data: This is the data that is returned by the dispensing vendor to the VA to show that the Rx was either dispensed and mailed or returned as not-dispensed.

Station Number: A unique number assigned to each originating facility. This number is from three to five letters and or numbers in length.

Batch Number: Batch number and Transmission number are synonymous. This is a unique number assigned to each batch of dispensing data to be transferred. There are two different methods of creating batch numbers, based on the originating agency. Transmissions sent from Department of Defense pharmacies will have batch numbers composed of two data elements. The first element is the unique Station Number of the originating agency. The second element is a unique number generated by the originating agency for the batch. This number is formatted as a two digit year, the Julian Date, two digit hour, two digit minute (YYDDDHHMM). If two batches are created simultaneously at the originating site this number must be incremented to make the batches unique. These two data elements are joined together with the hyphen character.

Example: the originating agency Station Number is 766, batch number is 013240530. The unique Batch Number would be 766-013240530.

Transmissions sent from VA pharmacies also are made up of two data elements separated by a hyphen. The first data element is the three digit station number for the medical center. The second number is a unique number created by the file system at the medical center. The numbering sequence is sequential with each new transmission increment the number by one.

Rx Index: This is a number that uniquely identifies the prescription from all other prescriptions. The Rx Index is made up of the Station Number dash Rx Number dash Fill Number. Fill numbers start at 1 for the original and increment sequentially for each new fill of the same prescription. Examples: Station Number = 10101, Rx Number = 123456T, Fill Number = 1 for the original. The Rx Index would be 10101-123456T-1. Station Number 10101, Rx Number = 12222A, Fill Number = 2 for the first refill of this prescription, the Rx Index would be 10101-12222A-2.

Duplicate Rx: Duplicate Rx’s are defined as a request to fill the same prescription and fill more than one time. Duplicates are detected by comparing the Rx Index (RXE - 15) [8.2.5e] with the Control ID (MSH – 10) [8.2.1] as received against an index, table or other storage location. If the same Rx Index is received a second (or more) time, it will be rejected as a duplicate unless the original Rx Index has a status of Cancelled or Not Dispensed. If the original Rx Index has a status of Dispensed and mailed to the patient or is still awaiting processing by the dispensing system, all new occurrences will be filed in the production database system and will be immediately and automatically rejected back to the originating medical center with a cancel reason of ‘Duplicate Rx Index’. These rejected Rx’s will be returned in the next release data file or query file.

3 Message Rules XE “Message Rules” \b The HL7 Standard describes the basic rules for the exchange of information between two computer systems. The unit of data transferred is referred to as the message. It is comprised of a group of segments in a defined sequence. Each message has a three-character code called a message type that defines its purpose. The real-world event that initiates an exchange of messages is called a trigger event. There is a one-to-many relationship between message types and trigger event codes. The same trigger event code may not be associated with more than one message type; however a message type may be associated with more than one trigger event. All message type and trigger event codes beginning with Z are reserved for locally defined messages. No such codes will be defined within the HL7 Standard.

Some special characters are used to construct messages. They are the segment terminator, field separator, component separator, sub-component separator, repetition separator, and escape character (listed in Appendix D). The other characters recommended by HL7 are used in this application (See HL7 Standard V. 2.5.1/2.5, Chapter 2 for details).

4 Segment Rules XE “Segment Rules” \b A segment is a logical grouping of data fields. Segments of a message may be required or optional. They may occur only once in a message or they may be allowed to repeat. Each segment is given a name and is identified by a unique three-character code. All segments beginning with Z are reserved for locally defined messages. No such code will be defined within the HL7 Standard. Segment length will not exceed 245 characters.

5 Field Rules XE “Field Rules” \b A field is a string of characters. HL7 does not care how systems actually store data within an application. Except where noted, HL7 data fields may take on the null value. Sending the null value, which is transmitted as two double quotation marks (“”), is different from omitting an optional data field. The difference appears when the contents of a message will be used to update a record in a database rather than create a new one. If no value is sent (i.e., it is omitted) the old value should remain unchanged. If the null value is sent, the old value should be changed to null. In defining a segment, the following information is specified about each field:

a) Position - position of the data field within the segment.

b) Name - unique descriptive name for the field.

c) ID number - integer that uniquely identifies the data field throughout the Standard.

d) Maximum length - maximum number of characters that one occurrence of the data field may occupy.

e) Optional - whether the data field is required ®, optional (O), or conditional © in a segment.

f) Repetition - whether the field may repeat (N=no; Y=yes; (integer)= no. of repeats).

g) Table - a table of values for a field (See HL7 Standard V. 2.5.1, Section 2.4.3.7 for source of tables).

h) Data type - restrictions on the contents of the data field (See HL7 Standard V. 2.5.1, Section 2.4.5).

6 Message Construction Rules

Note: These message construction rules define the standard HL7 encoding rules, creating variable length delimited messages. Although only one set of encoding rules is defined as a standard in HL7 Version 2.3, other encoding rules are possible (but since they are non-standard, they may only be used by a site-specific agreement).

Step 1. Construct the segments in the order defined for the message. Each message is constructed as follows:

a) The first three characters are the segment ID code.

b) Each data field in sequence is inserted in the segment in the following manner:

1) A field separator is placed in the segment.

2) If the value is not present, no further characters are required.

3) If the value is present, but null, the characters “” (two consecutive double quotation marks) are placed in the field.

4) Otherwise, the characters of the value are placed in the segment. The maximum number of characters that can be included is defined for each data field. It is not necessary and is undesirable to pad fields to fixed lengths. Padding to fixed lengths is permitted. The individual data fields are encoded as shown in HL7 Standard V. 2.5.1, Chapter 2, Section 2.8, “DATA TYPES.”

5) If the field definition calls for a field to be broken into components, the following rules are used:

i.

If more than one component is included they are separated by the component separator.

ii.

Components that are present but null are represented by the characters “”.

iii.

Components that are not present are treated by including no characters in the component.

iv.

Components that are not present at the end of a field need not be represented by component separators. For example, the two data fields are equivalent:

|ABC^DEF^^| and |ABC^DEF|.

6) If the component definition calls for a component to be broken into subcomponents, the following rules are used:

i.

If more than one subcomponent is included they are separated by the subcomponent separator.

ii.

Subcomponents that are present but null are represented by the characters “”.

iii.

Subcomponents that are not present are treated by including no characters in the subcomponent.

iv.

Subcomponents that are not present at the end of a component need not be represented by sub-component separators. For example, the two data components are equivalent:

^XXX&YYY&&^ and ^XXX&YYY^.

7) If the field definition permits repetition of a field, the following rules are used, the repetition separator is used only if more than one occurrence is transmitted and is placed between occurrences. (If three occurrences are transmitted, two repetition separators are used.) In the example below, two occurrences of telephone number are being sent:

|234-7120~599-1288B1234| c) Repeat step 1) b) while there are any fields present to be sent. If all the data fields remaining in the segment definition are not present there is no requirement to include any more delimiters.

d) End each segment with a vertical bar and an ASCII carriage return character Step 2. Repeat Step 1 until all segments have been generated.

6.1 The following rules apply to receiving HL7 messages and converting their contents to data values:

a) Ignore segments, fields, components, subcomponents, and extra repetitions of a field that are present but were not expected.

b) Treat segments that were expected but are not present as consisting entirely of fields that are not present.

c) Treat fields and components that are expected but were not included in a segment as not present.

d) Fields containing string

XE “TRANSACTION SPECIFICATIONS” \b 7 Communication Protocol XE “Communication Protocol” \b Connectivity will be established using methods compatible with both the current VHA standards and the capabilities of the systems involved. The method the CMOP program is using to communicate with outside agencies at the time of printing follows. Due to the variability of network communication techniques and policy, the actual hardware currently in use has not been included in this document.

The CMOP system uses a batch data transfer. This method of transferring data between the CMOP central database and all other entities has proved to be the most effective and efficient method of data transfer. It has several advantages that increase the efficiency the overall CMOP production systems.

8 Socket-to-Socket TCP/IP Message Processing All data and administrative communications consist of HL7 formatted Socket to Socket message transmissions (Microsoft MLLP). The data is gathered and batched based on a time. There can be from one to many patients in the batch. Each patient can have from one to many prescriptions. Data is organized by patient order.

The VA National CMOP will send prescription workload to Out Source vendors using an approved HL7 socket-to-socket TCP/IP connection.

The VA National CMOP will send batched workload throughout the day.

The VA CMOP system requires each patient Rx to have a unique processing id assigned. This is defined as the transmission order number and is composed of the unique station number, a dash, and an incrementing sequence number. This sequence number will be reset with each new Control ID.

Communication with Outsource vendors will only receive orders that needed to be fulfilled by the outsource vendor, so the order sequencing will appear to be incomplete with some orders apparently skipped. Care should be taken to make sure complete patient orders are received. This is accomplished by tracking the information in the ORC-4 (8.2.7) and the use of the ZRQ message QRO01 Query Type (8.8 and Appendix B).

8.1.1 Daily Common Segment Messages

Data that applies to all Rx’s will be sent as Master File Update segments, known as “Daily Comment Segment Messages”. All prescriptions received relating to that Control ID will have the Common Segment Message information applied to them. This Daily Common Segment Message will be sent for every Control ID. There should be no assumption that the Common Segment Message is the same for any sequential transmissions where the site number is the same. The message will include the transmission number for the current transmission.

The master file updates will follow the sequence below.

MSH

MFI

ZP1

ZR3

8.1.2 MSH – Message Header Segment – Required segment

[MSH-5] Receiving Application is the name of the dispensing application.

[MSH-10] Message Control ID is the number that uniquely identifies the message. It is returned in MSA-2.

EXAMPLE

MSH|^~\&| VENDOR NAME ||VENDOR NAME||20010925202704||MFN^M01|573-013240530|P|2.5.1|

OR

MSH|^~\&| VENDOR NAME || CMOP - CDB ||20010925202704||MFN^M01|10029-092300501|P|2.5.1|

8.1.3 MFI – Master File Identification - Required segment

This field contains an optional code of up to 180 characters which (if applicable) uniquely identifies the application responsible for maintaining this file at a particular site.

This field contains the time stamp for file-level event on originating system.

This optional field contains the effective date/time, which can be included for file-level action specified.

EXAMPLE:

MFI|ZBM||UPD|20010925202704|20010925202704

8.1.4 MFE – Master File Entry – Required segment

Reference the Message Control ID Field in the MSH Segment.

An optional effective date/time can be included for the record-level action specified.

Reference the Message Control ID Field in the MSH Segment.

MFE|MAD|ControlID|20010925202704|ControlID|CE| From MSH Example

MFE|MAD|573-013240530|20010925202704|573-013240530|CE|

MFE|MAD|10029-092300501|20010925202704|10029-092300501|CE|

8.1.5 ZP1 – Pharmacy Information – Required segment

Reference the Message Control ID Field in the MSH Segment.

This field will contain the pharmacy division number.

This field will contain the pharmacy division name.

This field will contain the pharmacy unique station number.

This field contains the return mailing address for the sending pharmacy division. CDB will always send this element

This is the phone number for the sending pharmacy division.

ZP1|ControlID| 672GA|VA MEDICAL CENTER|672|10 CALLE CASIA^^SAN JUAN^PR^00921-3201|(787) 641-4554| From MSH Example

ZP1|573-013240530|573MA|VA MEDICAL CENTER|573|10 CALLE CASIA^^SAN JUAN^PR^00921-3201|(787) 641-4554| ZP1|10029-092300501|10029|VA MEDICAL CENTER|10029|100 CASTLE BLVD^^PERRY POINT^FL^30921-3001|(323) 441-5009|

8.1.6 ZR3 – Order Instructions Text – Optional segment

Reference the Message Control ID Field in the MSH Segment.

Must be “2” for refill instructions, “3” for non-refill

Instructions, “4” Copayment Narrative

Sequence number in multiple continuation messages.

This is the standard free text refill/non-refill instructions that will print for all refillable prescriptions in the batch. For backwards compatibility, this segment will always be present. If no data for the segment, the segment will be formatted with at least three spaces.

[ZR3] The Type Indicator field will identify the ZR3 segment (2=Refill Instructions; 3=Non-refill Instructions Narrative; 4=Copayment Narrative). The Sequence Number Field will contain the sequence within the group the comment will be printed. The Comment field will contain the respective information.

EXAMPLE OF REFILL:

ZR3|ControlID|2|00|Prescriptions (Rx’s) are NOT automatically | ZR3|ControlID|2|01|refilled. To request refills: | ZR3|ControlID|2|02| | ZR3|ControlID|2|03| (1) Call our TOLL FREE # -> 1-888-820-0230. | ZR3|ControlID|2|04| Have your Social Security & Rx #’s ready | ZR3|ControlID|2|05| OR | ZR3|ControlID|2|06| (2) Sign and mail your refill request(s).|

ZR3|ControlID|2|07| Use the return address label provided.|

ZR3|ControlID|2|08| | ZR3|ControlID|2|09|Order your refills as soon as possible, AT | ZR3|ControlID|2|10|LEAST 14 DAYS before you run out. | ZR3|ControlID|2|11| | ZR3|ControlID|2|12|ALL refills are MAILED. Please do NOT come | ZR3|ControlID|2|13|to the clinic for Rx refills. |

EXAMPLE OF NON-RIFILL:

ZR3|ControlID|3|00| ** If NO REFILLS remain OR your Rx has | ZR3|ControlID|3|01| EXPIRED (too old) ** discuss this with | ZR3|ControlID|3|02| your VA PROVIDER at your next appt. |

ZR3|ControlID|3|03| | ZR3|ControlID|3|04| If you will run out of medicine BEFORE | ZR3|ControlID|3|05| your next appt, call (941) 939-3939 to | ZR3|ControlID|3|06| make or change an appt. |

EXAMPLE CO PAY NARRATIVE:

ZR3|ControlID|4|00| Questions about your bill? Please call |

ZR3|ControlID|4|01| 1-888-820-0230 Ext. 4004 (TOLL FREE) |

8.2 Patient Prescription Messages

Patient prescription information will be transmitted using the standard message formats found in the batch transmission protocol. The sequence and format of the segments will not change. Nor will the data transmitted on the segments. The data segments will follow the sequence below:

{MSH

PID

[ZPD]

[ZA8]

{[ZML]}

{[ZSL]}

ORC

RXE

{[ZS7]}

ZR1

{[ZW1]}

{[ZC1]}

{[ZC2]}}

{MSH

ZRQ}

8.2.1 MSH – Message Header Segment – Required segment

HL7 recommended field separator.

HL7 recommended encoding characters.

The name of the application creating the batch. This will be “VENDOR NAME” or “VENDOR NAME - APPLICATION”.

This is the application receiving the data. This will be “VENDOR NAME” or “VENDOR NAME - APPLICATION”. For CMOP this will be “CMOP - CDB”

Date and time the message was created on the sending

Station system.

This is a number that uniquely identifies this message from all other messages. The format of the message number is station number-transmission number- Sequence Number or station number-Julian date - Sequence Number.

[MSH-5] Receiving Application is the name of the dispensing application.

[MSH-10] Message Control ID is the number that uniquely identifies the message. It is returned in MSA-2.

EXAMPLE:

MSH|^~\&| VENDOR NAME ||VENDOR NAME ||20010925202704||ORM^O01|573-013240530-4|P|2.5.1| Or MSH|^~\&| VENDOR NAME ||CMOP - CDB ||20010925202704||ORM^O01|10029-092300501-7|P|2.5.1|

8.2.2 PID – Patient Identification Segment – Required segment

Patient Identification; This will be the Integration Control Number (ICN) value.

This can be a SSN but this is not guaranteed or that it will be sent to VA partners or Contractors.

The name of the patient. Format will be last name^first name^middle Initial^suffix.

First = 200, Last = 200, Initial = 1, Suffix = 10

When 11.14 (Date) indicates when the address expires. 11.7 indicates Primary or Secondary.

The patient’s contact phone number.

Patient’s primary language field is used to determine the language used to print the patient PMIS. ISO Table 639 defines the language codes. (Appendix A)

This field contains the unique patient account number

[PID-3] This is the patient’s Identification this is the ICN and will always be present

[PID-4] This is the alternate patient’s Identification this can be a SSN but is not guaranteed as well that it will be sent to VA partners or contractors. The VA will be migrating away from the use of the SSN. If the SSN is present it has a very specific reason why with an agreed between the communication partners.

[PID-15] Patient’s primary language field is used to determine the language used to print the patient PMI data, medication information, etc.

EXAMPLE: ONE Address has alternate Patient Identifier PID|||11111111116 |938475647|WATER^UNDER^^||||||DEEP 6 STREET^^CHARLESTON^SC^29405^^ PRIMARY||(843) 745-4124|

Two Addresses has alternate Patient Identifier PID|||11111111116|736529835| BOB^Sponge^^||||||107 OAK RD. ^APT#3 ^LIMA^OH^48132^^PRIMARY^Line 3^^^^^^20180830~1000 UNDER THE SEA^PINEAPPLE WAY^NEW YORK^NY^11003^^ALTERNATE^Atlantic Ocean||(875) 159-7582 Outsource Vendor Example with no alternate Patient Identifier PID|||11111111116 || CLOWN^NEMO^FISH^||||||1000 UNDER THE SEA ^^ NEW YORK ^NY^11003^^ PRIMARY||(110) 622-4994||ENG|

8.2.3 ZSL – Suspense Label Segment – Optional segment

The free text drug name. (VA PRINT NAME)

The date the fill is suspended for processing.

This is the prescription number as assigned by the originating pharmacy.

[ZSL] This segment is repetitive. It repeats for all suspended Rx’s for the patient.

ZSL|FELODIPINE 10MG SA TAB|20011209|200002833

8.2.4 ORC – Common Order Segment – Required segment

This is the prescription number.

This field is the order number associated with the filling application.

<entity identifier (ST)> ^ <namespace ID (IS)> Communication with Cerner, this will be the Cerner DISPENSE HISTORY ID and namespace of “HNAM_DISPENSEID”

This field is two parts. The first part is the number of

Rx’s in the patient order, the second number is the

Sequence number of this Rx in the patient order.

Example: this patient order has five Rx’s in it, this

Rx is the second Rx in the order so this field will be 5^2.

This field contains duration of the fill. Start date of the fill.

End date of the fill = Start date + days supply ^ ^ ^ <Start Date/Time (TS)> ^ <End Date/Time (TS)>

The entering clerks id number.

The name of the ordering provider with the ICN Value. First = 200, Last = 200, Initial = 1

The effective date of the order.

ORC|NW|1010-200002833F|290|1^1|||^^^20010925^20011224|||10111||5486521^STEPHENS^ REBECCA^S|||20001227|

OR

ORC|NW|1010-200002833F|876|2^1|||^^^20010925^20011224|||10111||5486521^STEPHENS^ REBECCA^S|||20001227| ORC|NW|1010-200001139|008|2^2|||^^^20010925^20011224|||10111||5486521^STEPHENS^ REBECCA^S|||20001227|

8.2.5 RXE – Pharmacy/Treatment Encoded Order Segment – Required segment

Quantity Requested. This is the amount to be picked unless a conversion factor needs to be applied. In that particular case This field is the original Quantity on the sending system. The ZR1 Field 22 (Pack Size) is the Conversion factor and ZR1 Field 23 (Qty to Pick) is quantity to be picked.

unique VA product ID^VA Print Name^L

This field contains the units for the Give Amount as encoded by the pharmacy or treatment application. Example: TAB, CAP, GM, OZ etc.

This field will contain the provider’s instructions (SIG)

This field contains the total original number of refills.

This is the pharmacist’s id number on the sending station system. For the VA it will be the pharmacist’s Local ID (DUZ) number.

This is the prescription number as assigned by the originating pharmacy. This number has to match the Placer Order Number field on the preceding ORC Segment.

Number of refills remaining for this prescription.

Date of the most recent fill dispensed.

This field be used to identify the prescription should utilize the Audible Script Talk equipment.

1^SCRIPT_TALK

EXAMPLE: No Script talk indicator RXE|45|L0139^LEVOTHYROXINE NA (SYNTHROID) 0.1MG TAB^L|45||TAB||^TAKE 1 TABLET(S) BY MOUTH EVERY MORNING |||||0||10111|200002833F|0||20010925| Script talk indicator RXE|45|L0139^LEVOTHYROXINE NA (SYNTHROID) 0.1MG TAB^L|45||TAB||^TAKE 1 TABLET(S) BY MOUTH EVERY MORNING |||||0||10111|200002833F|0||20010925|||1^SCRIPT_TALK|

8.2.5.1 ADDITIONAL FIELD NOTES:

[RXE-1] Quantity Requested

[RXE-2] Give Code identifies the substance ordered as encoded by the Pharmacy. The components, in order, are the VA Product ID, VA Product Name.

[RXE-5] Give Units identifies the units for the give amount as encoded by the VA National Drug File.

[RXE-7] Providers Administration Instructions (SIG). This field is limited to 350 characters. Only the second component of this field is used.

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>

Definition: This field contains the ordering provider’s instructions to the patient or the provider administering he drug or…