VA770-17-R-0409-025.pdf

ATTACHMENT A

CONSOLIDATED MAIL

OUTPATIENT PHARMACY

(CMOP)

Electronic Data Interface (EDI) Guidelines

Version 2

March 2009

Table of Contents

ATTACHMENT A APRIL 2007 CMOP ELECTRONIC DATA INTERFACE (EDI) GUIDELINES

ii

1 Table of Contents Version 2 ..................................................................................................................................... i

1 Table of Contents ................................................................................................................. ii

GENERAL HL7 INFORMATION

1. Introduction

2 Key Terms

2.1 File Extensions:

3 Message Rules

4 Segment Rules

5 Field Rules

6 Message Construction Rules

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

7 Communication Protocol

8 Concept of Operation

8.1 Overview

8.2 Activation/Inactivation

8.3 Transmission Schedule

8.4 Prescription Order Transmissions

9 HL7 Segments Used in CMOP Transactions

9.1 Activate/Inactivate (Flat Files: .SIT)

9.1.1 MSH – Message Header Segment – Required segment

9.1.2 MFE – Master File Entry Segment – Required segment

9.1.3 ZLF – Master File Update Segment – Required segment

9.2 Activation Acknowledgement Message (Flat Files: .SAC)

9.2.1 MSH – Message Header Segment – Required segment

9.2.2 MFE – Master File Entry Segment – Required segment

9.2.3 ZLF – Master File Update Segment – Required segment

9.3 Inactivation Acknowledgement Message (Flat Files: .SAC)

9.3.1 MSH – Message Header Segment – Required segment

9.3.2 MSA – Message Acknowledgment Segment – Required segment

9.4 Transmission Scheduling (Flat Files: .SCH)

9.4.1 MSH – Message Header Segment – Required segment

9.4.2 ARQ – Appointment Request Segment – Required segment

iii

9.5 Schedule Acknowledgement (Flat Files: .HAC)

9.5.1 MSH – Message Header Segment – Required segment

9.5.2 MSA – Message Acknowledgment Segment – Required segment

9.6 Batch Transmission Segments (.TRN)

9.6.1 FHS – File Header Segment – Required segment

9.6.2 BHS – Batch Header Segment – Required segment

9.6.3 ORC – Common Order Segment – Required segment

9.6.4 NTE|2 – Refill Instructions Text – Required segment

9.6.5 NTE|3 – Non Refill Instructions Text Segment– Required segment

9.6.6 NTE|4 – Copay Instructions Text Segment – Required segment

9.6.7 MSH – Message Header Segment – Required segment

9.6.8 PID – Patient Identification Segment – Required segment

9.6.9 NTE|8 – Additional Patient Street Address Information Segment – Optional segment 21

9.6.10 ZML – Multi-Rx Label Segment – Optional segment

9.6.11 ZSL – Suspense Label Segment – Optional segment

9.6.12 ORC – Common Order Segment – Required segment (HL7 2.3.1)

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

9.6.14 NTE|7 – Additional Medication Instructions Segment – Optional segment

9.6.15 ZR1 – Rx Order Additional Information Segment – Required segment

9.6.16 NTE|11– Special Medication Instructions Segment – Optional segment

9.6.17 BTS – Batch Trailer Segment – Required segment

9.6.18 FTS – File Trailer Segment – Required segment

9.7 Batch Transmission Acknowledgement/Non-Acknowledgement (.TAC)

9.7.1 MSH – Message Header Segment – Required segment

9.7.2 MSA – Message Acknowledgement Segment – Required segment

9.8 CMOP Production Transmission Acknowledgment/Non Acknowledgement (.TAC) 32

9.8.1 MSH – Message Header Segment – Required segment

9.8.1 MSA – Message Acknowledgement Segment – Required segment

9.9 Batch Prescription Fulfillment (.QRY)

9.9.1 FHS – File Header Segment – Required segment

9.9.2 BHS – Batch Header Segment – Required segment

9.9.3 MSH – Message Header Segment – Required segment

9.9.4 PID – Patient Identification Segment – Required segment

9.9.5 ORC – Common Order Segment – Required segment

9.9.6 RXD – Pharmacy/Treatment Dispense Segment – Required segment iv

9.9.7 ZR2 – Release Data Additional Information Segment – Required segment

9.9.8 BTS – Batch Trailer Segment – Required segment

9.9.9 FTS – File Trailer Segment – Required segment

9.10 Batch Prescription Fulfillment Acknowledgement (.QAC)

9.10.1 FHS – File Header Segment – Required segment

9.10.2 BHS – Batch Header Segment – Required segment

9.10.3 MSH – Message Header Segment – Required segment

9.10.4 MSA – Message Acknowledgement Segment – Required segment

9.10.5 BTS – Batch Trailer Segment – Required segment

9.10.6 FTS – File Trailer Segment – Required segment

9.11 Socket-to-Socket TCP/IP Message Processing

9.11.1 Daily Common Segment Messages

9.11.2 MSH – Message Header Segment – Required segment

9.11.3 MFI – Master File Identification - Required segment

9.11.4 MFE – Master File Entry – Required segment

9.11.5 ZP1 – Sending Pharmacy Information – Required segment

9.11.6 ZR3 – Order Instructions Text – Optional segment

9.12 Patient Prescription Messages

9.12.1 MSH – Message Header Segment – Required segment

9.12.2 PID – Patient Identification Segment – Required segment

9.12.3 NTE|8 – Additional Patient Street Address Information Segment – Optional

9.12.4 ZML – Multi-Rx Label Segment – Optional segment

9.12.5 ZSL – Suspense Label Segment – Optional segment

9.12.6 ORC – Common Order Segment – Required segment (HL7 2.3.1)

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

9.12.8 NTE|7 – Additional Medication Instructions Segment – Optional segment

9.12.9 ZR1 – Rx Order Additional Information Segment – Required segment

9.12.10 NTE|11– Special Medication Instructions Segment – Optional segment

9.13 CMOP Message Acknowledgment/Non Acknowledgement

9.13.1 MSH – Message Header Segment – Required segment

9.13.2 MSA – Message Acknowledgement Segment – Required segment

9.14 Prescription Fulfillment Messages

9.14.1 MSH – Message Header Segment – Required segment

9.14.2 PID – Patient Identification Segment – Required segment

9.14.3 ORC – Common Order Segment – Required segment

v

9.14.4 RXD – Pharmacy/Treatment Dispense Segment – Required segment

9.14.5 ZR2 – Release Data Additional Information Segment – Required segment

9.15 Prescription Fulfillment Acknowledgement

9.15.1 MSH – Message Header Segment – Required segment

9.15.2 MSA – Message Acknowledgement Segment – Required segment

9.16 National Drug file Update (.NDF)

9.16.1 MSH – Message Header Segment – Required segment

9.16.2 MFE – Master File Entry Segment – Required segment

9.16.3 ZND – NDF Data Segment - Required segment

10 NDF Update Acknowledgement (.NAC)

10.1.1 MSH – Message Header Segment - Required segment

10.1.2 MSA – Message Acknowledgement Segment – Required segment

Appendix A: VA Drug Warnings

Appendix B: CMOP Host Site Directory

Appendix C: ISO Table 639 Language Codes:

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 1

CMOP HL7 Interface Specification

GENERAL HL7 INFORMATION

1. Introduction This document defines the standard electronic data interface (EDI) used by DVA Consolidated Mail Outpatient Pharmacy (CMOP) system. This specification is based upon the Health Level 7 Standard (HL7) Version Batch: 2.3.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. VA Medical Center and the CMOP VistA system

b. Other Federal Agency Medical Center systems and the CMOP VistA or CMOP Central

Database (CDB) system

c. Contract Vendors and the CMOP CDB system

d. CMOP VistA system and CMOP CDB system

e. CMOP CDB and CMOP production database systems

f. CMOP production database and dispensing systems

2 Key Terms Outside Agency: Outside agencies are defined as any non-VA entity.

Originating Agency (OA): The agency that ‘owns’ the prescription (Rx). The originating agency may be an entity sending data to a VA CMOP facility. The originating agency may also be a VA CMOP facility sending the Rx data to an outside agency to fill under the ‘home delivery’ contract.

Dispensing Agency (DA): The agency that fulfills the prescription order.

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 agency to the originating agency to show that the Rx was either dispensed and mailed or returned as not-dispensed.

Station Number: A unique number assigned to the originating facility. This number is from three to five numbers in length. VA Medical Centers will use the Station ID numbers. DoD MTFs will use the DMIS ID numbers. The data type is integer.

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 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

General HL7 Informat ion

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 2 incremented to make the batches unique. These two data elements are joined together with the underscore 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 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.

2.1 File Extensions:

The following file extensions will be used for the transaction specified.

.TRN - transmission of dispense request from OA to DA.

766_013240530.trn .TAC - acknowledgement of dispense requests DA to OA.

766_013240530.tac .QRY – prescription fulfillment data from DA to OA.

0111141230.qry .QAC – acknowledgement of receipt of fulfillment data from OA to DA.

0111141230.qac

.SIT - activation/deactivation request from OA to DA.

Filename Format - OA station number_DateTime stamp (yymmddhhmm).sit 766_0111151300.sit .SAC – acknowledgement of activation/deactivation 766_0111151300.sac

.SCH – auto transmission schedule/unschedule message 766_0111151300.sch

.HAC – acknowledgement of auto transmission schedule/unschedule message.

766_0111151300.hac

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 3

.NDF – National Drug File data update ndf update pxxx.ndf where xxx is the NDF patch number.

.NAC – National Drug File data update acknowledgement ndf update pxxx.nac

NOTE: The ‘.TAC’, ‘.QAC’, ‘.SAC’, and ‘HAC’ acknowledgement files content will indicate the acceptance or rejection (nak) of the corresponding message. The message body will indicate which response is accurate.

3 Message Rules 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.

The segment terminator is always a carriage return (CR in ASCII or hex OD). The other characters recommended by HL7 are used in this application (See HL7 Standard V. 2.3.1/2.5, Chapter 2 for details).

4 Segment Rules 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 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.

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 4

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.3.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.3.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.3.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

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 5 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

7 Communication Protocol 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 Concept of Operation

8.1 Overview

The method of data transfer described herein is commonly referred to as the “fetch” method. A storage device such as a hard drive located on a network server is shared between the OA and the DA. All data and administrative communications consist of either HL7 formatted flat ASCII files or Socket to Socket message transmissions (Microsoft MLLP). Flat ASCII files are transferred to and from subdirectories or folders named INBOX and OUTBOX located on the shared drive. The OA will put all files it creates in the INBOX. The DA will put all files it creates in the OUTBOX. The OA will ‘batch’ together all data required to fill the prescriptions into one file.

The data is gathered and batched based on an agreed upon time interval and frequency between the DA and the OA. 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 in the file.

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 6

8.2 Activation/Inactivation

a. To request approval to send the DA prescription data, Flat Files: the OA places an activation request in the INBOX . File extension “.sit”. MLLP: An activation message will be transmitted using the socket to socket connections.

b. Flat Files: The DA fetches the data from the INBOX and places an approval/disapproval in the OUTBOX. File extension “.sac”. MLLP: An approval/disapproval message will be transmitted using the socket to socket connections.

8.3 Transmission Schedule

a. If approved for activation, Flat Files: the OA places a transmission schedule in the INBOX. This transmission schedule would have previously been coordinated with the DA. File extension “.sch”. MLLP: OA transmits a schedule message via the socket to socket connection.

b. Flat Files: The DA fetches the transmission schedule and places a message acknowledgement file in the OUTBOX. File extension “.hac”. MLLP: The DA transmits a message acknowledge via the socket to socket connection.

8.4 Prescription Order Transmissions

a. Flat Files: The OA batches the prescriptions and places the prescription order batch file in the

INBOX. File extension “.trn”. MLLP: The prescriptions are sent individually via the socket to socket connection.

b. Flat Files: The DA fetches the prescription order batch file and begins processing. The DA places an acknowledgement file in the OUTBOX. File extension “.tac”. If the file contains errors the DA places a negative acknowledgement in the OUTBOX. Where possible, as many of the problems detected will be identified. The entire batch will be rejected if ANY bad data within that batch is detected. MLLP: The prescription is validated for required field types and data existence. If the prescription is valid, an acknowledgement is returned. If not, a negative acknowledgement is returned. Only the prescription is rejected. All communications is via the socket to socket connection.

c. Flat Files: After fulfilling the prescription orders, DA places the prescription fulfillment data in a folder in the OUTBOX. File extension “.qry”. MLLP: The prescription fulfillment message is sent via the socket to socket connection.

d. Flat Files: The OA fetches the fulfillment data from the OUTBOX and places an acknowledgement that it has received the data in the INBOX. File extension “.qac”. MLLP:

The OA receives the fulfillment message and returns and acknowledgement of data received via the socket to socket connection.

e. Flat Files: The DA places a final acknowledgement in the OUTBOX upon receipt of the fulfillment acknowledgement from the OA in the inbox. File extension “.qac”. MLLP: The DA receives the fulfillment acknowledgement via the socket to socket connection. This completes the cycle for a prescription order.

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 7

9 HL7 Segments Used in CMOP Transactions

This section contains the definitions of the segments used in CMOP transactions. It is divided into parts according to functionality, i.e., activation/inactivation, etc. Following each section heading is a list of the segments used for that transaction. Segment notation follows standard HL7 encoding rules.

a. Each message is defined in special notation that lists the segment IDs in the order they would appear in the message. Message segments without the braces or brackets indicate the segment is required within the message.

b. Braces, { . . . }, indicate one or more repetitions of the enclosed group of segments. (Of course, the group may contain only a single segment.)

c. Brackets, [ . . . ], show that the enclosed group of segments is optional. If a group of segments is optional and may repeat it should be enclosed in brackets and braces, { [ . . . ]

Note: [{...}] and {[...]} are equivalent.

9.1 Activate/Inactivate (Flat Files: .SIT)

The Activate and Inactivate messages are used by the medical center to request permission from the CMOP to subscribe to the CMOP services. By acknowledging the request, the CMOP grants permission to the medical center to begin using the CMOP services.

MSH

MFE

ZLF

9.1.1 MSH – Message Header Segment – Required segment

Field Name Seq# Len DT R/O Rep Qty Tbl Desc Field Separator 1 1 ST R N HL7 recommended field separator.

Encoding Characters 2 4 ST R N HL7 recommended encoding characters.

Sending Application 3 15 ST R N The name of the application creating the batch.

Receiving Application 5 30 ST R N This is the application receiving the data.

Message Creation Date/Time 7 26 TS R N Date and time the message was created on the sending station’s system.

Message Type 9 7 C R N 0076 The type of message being sent. This will always be

MFN^M01.

Message Control ID 10 20 ST R N This is a number that uniquely identifies this message from all other messages. The format of the message number is station number-transmission date/time.

Processing ID 11 1 ID R N 0103 This will always be a P.

Version ID 12 8 ID R N 0104 This will always be Batch: 2.3.1, MLLP: 2.5

Accept Ack Type 15 2 ID O N 0155 Batch: This will always be AL for this MSH segment. MLLP: No Entry

Application Ack Type 16 2 ID O N 0155 Batch: This will always be AL for this MSH segment. MLLP: No Entry

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 8

EXAMPLE:

Batch: MSH|^~\&|CHCS||VistA||20020412163500||MFN^M01|0617-021021635|P|2.3.1|||AL|AL MLLP: MSH|^~\&|CHCS||VistA||20020412163500||MFN^M01|0617-021021635|P|2.5

9.1.2 MFE – Master File Entry Segment – Required segment

Record-Level Event Code 1 3 ID R 0180 Record-Level Event Code. This will always be

MUP.

MFN Control ID 2 20 ST C This field will be the station number and the transmission date/time.

Effective Date/Time 3 26 TS O Date/Time of Request Primary Key Value – MFE 4 200 NM R Y Medical Center Station Number Primary Key Value Type 5 3 ID R Y 0355 The field will be CE for all segments

MFE|MUP|766-011214|200110021345|766|CE

9.1.3 ZLF – Master File Update Segment – Required segment

Field Name Seq

Le n

DT R/

O

Re p

Qt y

Tb l

Desc

Request Type 1 3 NM R See Request Type table below.

Requesting/Approving Official

2 45 ST R Name of person requesting or approving the action. Format^LAST NAME^FIRST

NAME^MI^SUFFIX

Agency 3 4 ST R Agency Type. See Agency Table below. This table can be added to as necessary.

Reject Reason 4 80 ST This is a free text rejection reason. This will only be present if the request was denied or rejected.

EXAMPLE:

ZLF|1|Armstead, Percy|2|

ZLF Request Type

1 Request to Activate Non Controlled Substance Transmissions 2 Request to Activate Controlled Substance Transmissions 3 Activation Approval 4 Activation Disapproval 5 Inactivation for Non Control Substances Transmissions 6 Inactivation for Control Substances Transmissions

ZLF Agency Table

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 9

1 VA Medical Center 2 US Army 3 US Air Force 4 US Navy 5 US Marine Corp 6 US Coast Guard 7 Indian Health Service 8 Public Health Service

9 CHAMPVA

10 CHAMPUS

11 OTHER/Not Applicable

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 10

9.2 Activation Acknowledgement Message (Flat Files: .SAC)

MSH

MFE

ZLF

9.2.1 MSH – Message Header Segment – Required segment

Field Separator 1 1 ST R N HL7 recommended field separator.

Encoding Characters 2 4 ST R N HL7 recommended encoding characters.

Sending Application 3 15 ST R N The name of the application creating the batch.

Receiving Application 5 30 ST R N This is the application receiving the data.

Message Creation Date/Time 7 26 TS R N Date and time the message was created on the sending station’s system.

Message Type 9 7 C R N 0076 The type of message being sent. This will always be

MFR^M02.

Message Control ID 10 20 ST R N This is a number that uniquely identifies this message from all other messages. The format of the message number is station number-transmission date/time.

Processing ID 11 1 ID R N 0103 This will always be a P.

Version ID 12 8 ID R N 0104 This will always be Batch: 2.3.1, MLLP: 2.5

Accept Ack Type 15 2 ID O N 0155 Batch: This will always be NE for this MSH segment.

MLLP: No Entry.

Application Ack Type 16 2 ID O N 0155 Batch: This will always be NE for this MSH segment.

MLLP: No Entry.

EXAMPLE:

Batch: MSH|^~\&|VistA||CHCS||20010925202704||MFR^M02|766-011214|P|2.3.1||NE|NE MLLP: MSH|^~\&|VistA||CHCS||20010925202704||MFR^M02|766-011214|P|2.5

9.2.2 MFE – Master File Entry Segment – Required segment

Field Name Seq# Len DT R/O Rep Qty Tbl Desc

Record-Level Event Code 1 3 ID R 0180 Record-Level Event Code. This will always be

MUP.

MFN Control ID 2 20 ST C This field will be the station number and the transmission date/time.

Effective Date/Time 3 26 TS O Date/Time of Request Primary Key Value – MFE 4 200 NM R Y Medical Center Station Number Primary Key Value Type 5 3 ID R Y 0355 The field will be CE for all segments

MFE|MUP|766-011214|200110021345|766|CE

9.2.3 ZLF – Master File Update Segment – Required segment

Field Name Seq

Le n

D T

R/ O

Re p

Qt y

Tb l

Desc

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 11

Request Type 1 3 NM R See Request Type table below.

Requesting/Approving Official

2 45 ST R Name of person requesting or approving the action.

Format^LAST NAME^FIRST NAME^MI^SUFFIX

Reject Reason 4 80 ST This is a free text rejection reason. This will only be present if the request was denied or rejected.

ZLF|2|Armstead, Percy

ZLF Request Type

1 Request to Activate Non Controlled Substance Transmissions 2 Request to Activate Controlled Substance Transmissions 3 Activation Approval 4 Activation Disapproval 5 Inactivation for Non Control Substances Transmissions 6 Inactivation for Control Substances Transmissions

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 12

9.3 Inactivation Acknowledgement Message (Flat Files: .SAC)

MSH

MSA

9.3.1 MSH – Message Header Segment – Required segment

Field Name Seq# Len DT R/O Rep Qty Tbl Desc Field Separator 1 1 ST R N HL7 recommended field separator.

Encoding Characters 2 4 ST R N HL7 recommended encoding characters.

Sending Application 3 15 ST R N The name of the application creating the batch.

Receiving Application 5 30 ST R N This is the application receiving the data.

Message Creation Date/Time 7 26 TS R N Date and time the message was created on the sending station’s system.

Message Type 9 7 C R N 0076 The type of message being sent. This will always be

MFR^M02.

Message Control ID 10 20 ST R N This is a number that uniquely identifies this message from all other messages. The format of the message number is station number-transmission date/time.

Processing ID 11 1 ID R N 0103 This will always be a P.

Version ID 12 8 ID R N 0104 This will always be Batch: 2.3.1, MLLP: 2.5

Accept Ack Type 15 2 ID O N 0155 Batch: This will always be NE for this MSH segment.

MLLP: No Entry.

Application Ack Type 16 2 ID O N 0155 Batch: This will always be NE for this MSH segment.

MLLP: No Entry.

EXAMPLE:

Batch: MSH|^~\&|VistA||CHCS||20010925202704||MFR^M02|0111-011214|P|2.3.1||NE|NE MLLP: MSH|^~\&|VistA||CHCS||20010925202704||MFR^M02|0111-011214|P|2.5

9.3.2 MSA – Message Acknowledgment Segment – Required segment Field Name Seq# Len DT R/O Rep Qty Tbl Item# Desc Acknowledgement Code 1 2 ID R 0008 00018 Acknowledgement Code This will be CA.

Message Control ID 2 20 ST R Message Control ID. This will be same as on the preceding MSH segment.

Text Message 3 80 ST O This will be null.

MSA|CA|0111-011214|

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 13

9.4 Transmission Scheduling (Flat Files: .SCH)

The transmission scheduling message is used by the medical center to notify the CMOP of their schedule for transmitting batches of prescription data.

MSH

ARQ

9.4.1 MSH – Message Header Segment – Required segment

Field Name Seq# Len DT R/O Rep Qty Tbl Desc Field Separator 1 1 ST R N HL7 recommended field separator.

Encoding Characters 2 4 ST R N HL7 recommended encoding characters.

Sending Application 3 15 ST R N The name of the application creating the batch. In the VA this will always be VistA. For DoD- “DOD”.

Receiving Application 5 30 ST R N This is the application receiving the data.

Message Creation Date/Time 7 26 TS R N Date and time the message was created on the sending station’s system.

Message Type 9 7 C R N 0076 The type of message being sent. This will always be ‘SIU^SO7’. Cancel SIU^S20

Message Control ID 10 20 ST R N This is a number that uniquely identifies this message from all other messages. The format of the message number is station number-transmission date/time.

Processing ID 11 1 ID R N 0103 This will always be a P.

Version ID 12 8 ID R N 0104 This will always be Batch: 2.3.1, MLLP: 2.5

Accept Ack Type 15 2 ID O N 0155 Batch: This will always be NE for this MSH segment.

MLLP: No Entry.

Application Ack Type 16 2 ID O N 0155 Batch: This will always be NE for this MSH segment.

MLLP: No Entry.

EXAMPLE:

Batch: MSH|^~\&|CHCS||VistA||2001121401000||SIU^SO7|0111-011214|P|2.3.1||AL|AL MLLP: MSH|^~\&|CHCS||VistA||2001121401000||SIU^SO7|0111-011214|P|2.5

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 14

9.4.2 ARQ – Appointment Request Segment – Required segment

Field Name Seq# Len DT R/O Rep Qty Tbl Desc Placer Appointment ID 1 75 EI R This is the Station ID.

Request Event Reason 6 200 CE O This is the code for the type of scheduling event. See table below.

Requested Start Date/Time Range 11 53 DR O Y This is the Date/Time the transmission schedule will begin. MLLP: Time to process Rx’s received.

Repeating Interval 13 100 RI O Repeating Interval. See Chapter 4, Section 4.4.2

Placer Contact Person 15 48 XCN R Y Name of the Point of Contact from the Medical Center. Format

^LAST NAME^FIRST NAME^MI^SUFFIX

Placer Contact Phone Number 16 40 XTN O Y Phone Number of the point of contact in sequence 15.

Entered By Person 19 48 XCN R Y The person who initiated the request. Format

^LAST NAME^FIRST NAME^MI^SUFFIX

Entered By Phone Number 20 40 XTN O Y The phone number of the person initiating the request.

Request Event Reason

1 Non Controlled Substance Transmission Auto Schedule 2 Controlled Substance Transmission Auto Schedule 3 Non Controlled Substance Transmission Cancel Auto Schedule 4 Controlled Substance Transmission Cancel Auto Schedule

EXAMPLE:

ARQ|10111|||||1|||||200112141000||Q24H||^JONES^DEBRA^J|(555) 555-

1212|||^JONES^DEBRA^J|(555) 555-1212

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 15

9.5 Schedule Acknowledgement (Flat Files: .HAC)

MSA

9.5.1 MSH – Message Header Segment – Required segment

Field Name Seq# Len DT R/O Rep Qty Tbl Desc Field Separator 1 1 ST R N HL7 recommended field separator.

Encoding Characters 2 4 ST R N HL7 recommended encoding characters.

Sending Application 3 15 ST R N The name of the application creating the batch. In the VA this will always be VistA. For DoD- “DOD”.

Receiving Application 5 30 ST R N This is the application receiving the data.

Message Creation Date/Time 7 26 TS R N Date and time the message was created on the sending station’s system.

Message Type 9 7 C R N 0076 The type of message being sent. This will always be ‘SRR^SO7’ for the schedule, SRR^S20 for a schedule cancellation.

Message Control ID 10 20 ST R N This is a number that uniquely identifies this message from all other messages. The format of the message number is station number-transmission date/time.

Processing ID 11 1 ID R N 0103 This will always be a P.

Version ID 12 8 ID R N 0104 This will always be Batch: 2.3.1, MLLP: 2.5

Accept Ack Type 15 2 ID O N 0155 Batch: This will always be NE for this MSH segment.

MLLP: No Entry.

Application Ack Type 16 2 ID O N 0155 Batch: This will always be NE for this MSH segment.

MLLP: No Entry.

EXAMPLE:

Batch: MSH|^~\&|VistA||CHCS||2001121401100||SRR^SO7|0111-011214|P|2.3.1||NE|NE MLLP: MSH|^~\&|VistA||CHCS||2001121401100||SRR^SO7|0111-011214|P|2.5

9.5.2 MSA – Message Acknowledgment Segment – Required segment Field Name Seq# Len DT R/O Rep Qty Tbl Item# Desc Acknowledgement Code 1 2 ID R 0008 00018 Acknowledgement Code This will be CA.

Message Control ID 2 20 ST R Message Control ID. This will be same as on the preceding MSH segment.

Text Message 3 80 ST O This will be null.

MSA|CA|10111-011214|

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 16

9.6 Batch Transmission Segments (.TRN)

At the sending medical center, prescription orders are held in a queue until the scheduled transmission time. Typically a medical center will transmit prescriptions once a day to the CMOP. At the scheduled time, all prescriptions waiting transmission to the CMOP are grouped first by pharmacy division and then by patient and then grouped together into one batch of data to send to the CMOP using the batch file transmission protocol. Each batch contains up to 9,999 individual patient orders for the sending pharmacy division. (A VA medical center can have multiple pharmacy divisions.) Each patient order within the batch contains from one to many prescriptions to be dispensed for the patient. Each batch is a separate transmission of data.

At the medical center, a unique number is assigned to the batch to distinguish it from all other batches.

See the definition of a batch number in the definitions section for how the batch numbers are created.

This batch number is used to identify and track all patient orders and prescriptions sent to the CMOP.

This number is combined with the message number of the order within the transmission to uniquely identify the patient order within all CMOP database systems.

Data sent in the Batch Transmission file are part of the permanent prescription dispensing record. The data elements will not be modified edit or deleted by the receiving station. The data may be supplemented with new data as necessary by the processing system. Only data that has been archived to permanent storage may be deleted by the processing system.

Data is sent from the CMOP VistA system to the CMOP CDB and then on to the CMOP production systems are sent in batches just as they are received from the pharmacy. The same batch transmission protocols are used for these data transmissions. Batch integrity maintained as the data is received and then forwarded by the CMOP VistA and CMOP CDB systems.

Braces, { . . . }, indicate one or more repetitions of the enclosed group of segments. (Of course, the group may contain only a single segment.)

Brackets, [ . . . ], show that the enclosed group of segments is optional. If a group of segments is optional and may repeat it should be enclosed in brackets and braces, { [ . . . ] }.

Note: [{...}] and {[...]} are equivalent.

FHS

BHS

ORC

{NTE|2}

{NTE|3}

{NTE|4}

{MSH

PID

[NTE|8]

{[ZML]}

{[ZSL]}

This group of segments can be repeated between the first ORC and BTS segments

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 17

ORC

RXE

{[NTE|7]}

ZR1

[NTE|11]}

BTS

FTS

9.6.1 FHS – File Header Segment – Required segment

Field Name Seq# Len DT R/O Rep Tbl Desc File Field Separator 1 1 ST R N HL7 recommended field separator.

File Encoding Characters 2 4 ST R N HL7 recommended encoding characters.

File Sending Application 3 15 ST R N The name of the application creating the batch.

File Sending Facility 4 20 ST R N The name of the sending medical center.

File Receiving Facility 6 20 ST R N The name of the receiving station.

File Creation Date/Time 7 26 TS R N The date and time the batch was created on the sending station system.

File Control ID 11 20 ST R N This field will be the file name. The file name is the batch number concatenated with the file extension.

EXAMPLE:

FHS|^~\&|CHCS|MEDICAL CENTER NAME||CMOP CHARLESTON|20010928120135||||573-

013240530.TRN

9.6.2 BHS – Batch Header Segment – Required segment

Field Name Seq# Len DT R/O Rep Tbl Desc Batch Field Separator 1 1 ST R N HL7 recommended field separator.

Batch Encoding Characters 2 3 ST R N HL7 recommended encoding characters.

Batch Sending Application 3 15 ST R N The name of the application creating the batch.

Batch Receiving Application 5 15 ST R N The name of the sending medical center.

Batch Creation Date/Time 7 26 TS R N The date and time the batch was created on the sending station system.

Batch Name/ID/Type 9 20 ST O N RAR^RAR

Batch Comment 10 80 ST O N Controlled Substance Flag. This field will be set to CS for a Controlled substance transmission. It will be null if not a Controlled substance transmission.

Batch Control ID 11 20 ST R N This is the transmission number.

EXAMPLE:

Non Controlled Substance Transmission BHS|^~\&|Outside Agency Application Name||VistA||20011109144013||RAR^RAR||573-013240530

Controlled Substance Transmission BHS|^~\&|Outside Agency Application Name||VistA||20011109144013||RAR^RAR|CS|573-013240530

This group of segments can be repeated between the first ORC and NTE|11

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 18

9.6.3 ORC – Common Order Segment – Required segment

Field Name Seq# Len DT R/O Rep Qty Tbl Desc Order Control 1 2 ID R N 0119 This will always be a new order, NW

Order Facility Name 21 60 XON O Y This field will contain the pharmacy division name and unique pharmacy division number.

Ordering Facility Address 22 106 XAD O Y This field contains the return mailing address for the sending pharmacy division.

Ordering Facility Phone Number 23 48 XTN O Y This is the phone number for the sending pharmacy division.

EXAMPLE:

ORC|NW||||||||||||||||||||^^^^^^^573GG&INVERNESS CBOC&573|PO BOX

147038^^GAINESVILLE^FL^32614-7038|(800) 349-9457

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 19

9.6.4 NTE|2 – Refill Instructions Text – Required segment

Field Name Seq# Len DT R/O Rep Tbl Desc Set ID = 2 1 1 ST R N Set id for the segment

Refill Instructions Text 2 100 FT R

This is the standard free text refill instructions that will print for all refillable prescriptions in the patch. 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.

[NTE] The Set ID field will identify the NTE segment (2=Refill Instructions; 3=Non-refill Instructions Narrative; 4=Copayment Narrative). The Comment field will contain the respective information.

EXAMPLE:

NTE|2|Prescriptions (Rx’s) are NOT automatically NTE|2|refilled. To request refills:

NTE|2|

NTE|2|(1) Call our TOLL FREE # -> 1-888-820-0230.

NTE|2| Have your Social Security & Rx #’s ready

NTE|2| OR

NTE|2|(2) Sign and mail your refill request(s).

NTE|2| Use the return address label provided.

NTE|2|

NTE|2|Order your refills as soon as possible, AT NTE|2|LEAST 14 DAYS before you run out.

NTE|2|

NTE|2|ALL refills are MAILED. Please do NOT come NTE|2|to the clinic for Rx refills.

9.6.5 NTE|3 – Non Refill Instructions Text Segment– Required segment Field Name Seq# Len DT R/O Rep Tbl Desc Set ID = 3 1 1 ST R N Set id for the segment

Refill Instructions Text 2 100 FT R

This is the standard free text non-refillable instructions that will print for all non-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.

EXAMPLE:

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

NTE|3|

NTE|3| If you will run out of medicine BEFORE NTE|3| your next appt, call (941) 939-3939 to NTE|3| make or change an appt.

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 20

9.6.6 NTE|4 – Copay Instructions Text Segment – Required segment Field Name Seq# Len DT R/O Rep Qty Tbl Desc Set ID = 4 1 1 ST R N Set id for the segment

Refill Instructions Text 2 100 FT R

This is the standard free text copay instructions that will print for all prescriptions in the batch that have a copay charge. 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.

EXAMPLE:

NTE|4| Questions about your bill? Please call NTE|4| 1-888-820-0230 Ext. 4004 (TOLL FREE)

9.6.7 MSH – Message Header Segment – Required segment

Field Name Seq# Len DT R/O Rep Tbl Desc Field Separator 1 1 ST R N HL7 recommended field separator.

Encoding Characters 2 4 ST R N HL7 recommended encoding characters.

Sending Application 3 15 ST R N The name of the application creating the batch. In the VA this will always be ‘VistA’.

Receiving Application 5 30 ST R N This is the application receiving the data. Where VA is the Dispensing Agency it will be ‘VistA’.

Message Creation Date/Time 7 26 TS R N Date and time the message was created on the sending Station system.

Message Type 9 7 C R N 0076 The type of message being sent. This will always be

‘ORM^O01’.

Message Control ID 10 20 ST R N This is a number that uniquely identifies this message from all other messages. The format of the message number is station number-transmission number-order number.

Processing ID 11 1 ID R N 0103 This will always be a P.

Version ID 12 8 ID R N 0104 This will always be 2.3.1 Accept Ack Type 15 2 ID R N 0155 This will always be NE Application Ack Type 16 2 ID R N 0155 This will always be NE

[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|^~\&|SENDING AGENCY NAME||VistA||20010925202704||ORM^O01|573-013240530-

1794|P|2.3.1|||AL|AL

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 21

9.6.8 PID – Patient Identification Segment – Required segment Field Name Seq# Len DT R/O Rep Qty Desc

Patient ID 3 20 C R N Patient SSN^Check Digit^Check Digit Scheme. Check digit scheme will be M11. HL7 P 2-15

Patient Name 5 48 PN R N The name of the patient. Format will be ^LAST

NAME^FIRST NAME^MIDDLE INITIAL^SUFFIX.

Patient Address 11 106 AD R Y 3 The patient’s mailing address. See HL7 specification,

3.3.2.11 for format.

Patient Phone Number 13 40 TN O N The patient’s contact phone number.

Primary Language 15 60 CE O N 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 C)

Patient Account Number 18 250 CX O N

This field contains the unique VA Internal Control Number (ICN) and checksum value. Format will be ICN^checksum. The Checksum is provided by the VistA system. Receiving station is not required to compute the checksum for validating the data.

[PID-3] This is the patient’s SSN, check digit and check digit scheme. Refer to HL7 Version 2.3.1 page 2-15.

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

[PID-18] Patient Account Number field is used to uniquely identify the patient. The number is guaranteed to be unique across the VA system. A checksum value is provided with the field, the receiving station is not required to compute checksums on this data element. Nor will the checksum be stored with in the receiving stations database.

EXAMPLE:

PID|||11111111111^1^M11||^MOUSE^MICKEY^^||||||100 MOUSE LANE^APT

#3^CHARLESTON^SC^29405||(843) 745-4124||ENG|||1234567^345

9.6.9 NTE|8 – Additional Patient Street Address Information Segment – Optional segment

This segment is multi- functional. It is used to carry additional street lines for the patient address if there are more than two street lines in the address. It is also used to indicate that the patient address is a temporary address. When used as a temporary address indicator, the expiration date will indicate when the address is due to expire. If the patient’s mailing label is scheduled to print after the expiration date, the entire patient order will be automatically cancelled back to the medical center with a cancel reason of ‘Temp Address Expired’. The check for address expiration is to be made before the patient order is released to the system for processing. If the patient address will expire prior to the package being mailed, the entire patient order will be automatically cancelled back to the medical center. The cancel reason will be ‘ADD – Expired address correct & resubmit” Field Name Seq# Len DT R/O Rep Qty Tbl Desc Set Id = 8 1 4 ST R N Temporary Address 2 1 NM R N 1 means this is a temporary addrss

April 2007 CMO P Electronic Data Interface (EDI) Guidelines 22

Temporary Until 3 8 DT R N Expiration Date. Format: YYYYMMDD

Additional Street Address 4 35 ST R 2 Additional Street Address. This field may Repeat twice.

Example of Patient Data with Temporary Address Information:

PID|||999999999^1^M11||STEELE^JAMES E.||||||107 OAK RD.^APT#3^LIMA^OH^48132 (or 48132- 9999) NTE|8|1\F\20041015\F\Street Address line 3\R\Street Address line 4\R\Street Address line 5

Example of Patient Data with NO Temporary Address Information:

PID|||999999999^1^M11||STEELE^JAMES E.||||||107 OAK RD.^APT#3^LIMA^OH^48132

NTE|8||\F\\F\Street Address line 3\R\Street Address line 4\R\Street Address line 5

9.6.10 ZML – Multi-Rx Label Segment – Optional segment

Field Name Seq# Len DT R/O Rep Tbl Desc Drug Name 1 40 ST R N The free text drug name. (VA PRINT NAME) Number of Refills 2 3 NM R N Total number of remaining refills Expiration Date 3 26 TS R N Prescription…