VA770-17-R-0423-00002000.docx

Appendix B **DRAFT**

5. PROJECT NUMBER (if applicable)

CODE

7. ADMINISTERED BY

2.

AMENDMENT/MODIFICATION NUMBER

CODE

6. ISSUED BY

8. NAME AND ADDRESS OF CONTRACTOR

4. REQUISITION/PURCHASE REQ. NUMBER

3. EFFECTIVE DATE

9A. AMENDMENT OF SOLICITATION NUMBER

9B. DATED

PAGE

OF PAGES

10A. MODIFICATION OF

CONTRACT/ORDER NUMBER

10B. DATED

BPA NO.

1. CONTRACT ID CODE

FACILITY CODE

CODE

Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods:

The above numbered solicitation is amended as set forth in Item 14. The hour and date specified for receipt of Offers

E. IMPORTANT:

is extended,

(a) By completing Items 8 and 15, and returning __________ copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or electronic communication which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY is not extended.

12. ACCOUNTING AND APPROPRIATION DATA

(REV.

11/2016) is required to sign this document and return ___________ copies to the issuing office.

is not, A. THIS CHANGE ORDER IS ISSUED PURSUANT TO: (Specify authority) THE CHANGES SET FORTH IN ITEM 14 ARE MADE IN THE CONTRACT ORDER NO. IN ITE M 10A.

15C. DATE SIGNED

B. THE ABOVE NUMBERED CONTRACT/ORDER IS MODIFIED TO REFLECT THE ADMINISTRATIVE CHANGES

SET FORTH IN ITEM 14, PURSUANT TO THE AUTHORITY OF FAR

43.103(b).

RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by letter or electronic communication, provided each letter or electronic communication makes r eference to the solicitation and this amendment, and is received prior to the opening hour and date specified.

C. THIS SUPPLEMENTAL AGREEMENT IS ENTERED INTO PURSUANT TO AUTHORITY OF:

D. OTHER

BY

Contractor

16C. DATE SIGNED

14.

DESCRIPTION OF AMENDMENT/MODIFICATION

16B. UNITED STATES OF AMERICA

Except as provided herein, all terms and conditions of the document referenced in Item 9A or 10A, as heretofore changed, remains unchanged and in full force and effect.

15A. NAME

AND TITLE OF SIGNER

16A. NAME AND TITLE OF CONTRACTING OFFICER

15B. CONTRACTOR/OFFEROR

STANDARD FORM 30

PREVIOUS EDITION NOT USABLE

Prescribed by GSA - FAR (48 CFR) 53.243 (Type or print) (Type or print) (Organized by UCF section headings, including solicitation/contract subject matter where feasible.)

(Number, street, county, State and ZIP Code) (If other than Item 6) (Specify type of modification and authority) (such as changes in paying office, appropriation date, etc.)

(If required)

(SEE ITEM 11)

(SEE ITEM 13)

(X)

CHECK

ONE

13. THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACTS/ORDERS,

IT MODIFIES THE CONTRACT/ORDER NO. AS DESCRIBED IN ITEM 14.

11. THIS ITEM ONLY APPLIES TO AMENDMENTS

OF SOLICITATIONS

AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT

(Signature of person authorized to sign) (Signature of Contracting Officer) National CMOP 00002 11-28-2017 None 36C770 Department of Veterans Affairs National CMOP 3450 S. 4th St. Trafficway Leavenworth KS 66048-5581 36C770 Department of Veterans Affairs National CMOP 3450 S. 4th St. Trafficway Leavenworth KS 66048-5581 To all Offerors/Bidders

VA770-17-R-0423

11-20-2017

X X X X The purpose of this amendment is to post questions and answers and update the solicitation.

A. See Attachment 1 for questions and answers.

B. Update solicitation, see questions 7, 8, 9, 10, 11, 12.

Leah Thurman Contracting Officer

VA770-17-R-0423

A00002 Questions and Answers

Question: How many past performance references are required for this response?

Answer: At least one.

Question: Do vendors with a GSA/GSS Schedule receive any type of credit in the evaluation process?

Answer: Per the solicitation evaluation criteria no.

Question: What is the set aside participation goal for this contract? Does it matter whether the participation is SDVOB or M/WBE?

Answer: See page 57 Factor 4 Socio-Economic Consideration Participation in the solicitation.

Question: Does the amount of time a vendor has been in business factor into the past performance evaluation?

Answer: Per the solicitation evaluation criteria no.

Question: Paragraph B.4.1 includes the following statement: This requirement is needed for the duration of time the MID-SOUTH CMOP is located at 5171 Sam Jared Drive, Murfreesboro, TN 37130 and during the transition period to the new facility located at 3209 Elam Farms Parkway, Murfreesboro, TN 37127.

The equipment being installed at the Elam Farms location appears to have the capability of performing the requirements of this solicitation. Will there be a continuing requirement after completion of the transition period and what is the best estimate as to when the transition should be completed? This information is needed to effectively calculate an amortization period for capitalized assets and the development of new software.

Answer: The estimated transition completion date is January 2020. However, this is just an estimated date and can change at any time. Future use of this service is not expected after transition is completed.

Questions: The CMOP hours of operation have shifted to a single shift operation as opposed to the table shown in Paragraph B.4.5. While this may be temporary, is this change expected to last through the transition period?

Answer: We do not anticipate any changes at this time.

Questions: The Average Number of Paperwork Pages Required per Parcel is dated and should be revised. The average number of paperwork pages experienced for 2016 were as follows:

Average pages per PMI: 4.15 Average pages per Med Guide: 2.25 Average total pages per parcel: 5.04 Note: not all parcels require Med Guides.

Answer: It is unclear as to why the pages are concerned since the service is not paid per page but by piece which is the number of PMI’s/Medguides that are printed and inserted. To provide the most up to date information the number of PILs for the first quarter of FY17 is 3,641,557 and the number of Medguides for the first quarter of FY17 is 1,448,202, the solicitation is updated with this amendment..

Questions: Paragraph B.4.8.1.2 specifies an opaque sleeve. This should be a clear sleeve.

Answer: Clear is the current practice, the solicitation is updated with this amendment.

Questions: Paragraph B.4.8.1.8 shows a pickup schedule that is dated. The current schedule is 1:00 and 5:00 pm daily at Sam Jared and 3:00 pm at Elam Farms.

Answer: Correct, this is the current pick up schedule, the solicitation is updated with this amendment.

Questions: Paragraph B.4.8.2.8 specifies 8 1/2 X 14 inch, 24lb paper. During the visit at Elam Farms it was noted that the CMOP is using 8 ½ by 11 inch, 20lb paper for PMI’s and Med Guide’s produced there. For consistency between the two operations and a seamless experience for recipients we propose the use of 8 ½ x 11 inch, 20lb, paper for this requirement. Please see additional question below regarding postconsumer content paper.

Answer: For consistency 20lb paper as well as the size of 8.5x11 will be used at both Elam Farms and Sam Jared, the solicitation is updated with this amendment.

Question: Paragraph B.4.8.2.9 2 specifies an opaque sleeve. This should be a clear sleeve. This is the current practice.

Answer: Clear is the current practice, the solicitation is updated with this amendment.

Questions: Paragraph B.4.8.4.6 states “The contractor shall print and insert all paperwork into parcels and tender completed parcels to the MID-SOUTH CMOP specified government designated transportation contractor within twelve (12) hours of pickup from the MID-SOUTH CMOP ninety-five (95%) of the time.” The contractor has no control over the timing of pickup by the MID-SOUTH CMOP specified government designated transportation contractor. We suggest the following wording for clarity: The contractor shall print and insert all paperwork into parcels and have completed parcels available for pickup by the MID-SOUTH CMOP specified government designated transportation contractor within twelve (12) hours of pickup from the MID-SOUTH CMOP ninety-five (95%) of the time.

Answer: For clarification wording in B.4. 8.4.6 shall read “The contractor shall print and insert all paperwork into parcels and have completed parcels available for pickup by the MID-SOUTH CMOP specified government designated transportation contractor within twelve (12) hours of pickup from the MID-SOUTH CMOP ninety-five (95%) of the time.” The solicitation is updated with this amendment.

Questions: Paragraph C.1 52.252-2 Clauses Incorporated by Reference (FEB 1998) includes FAR Number 52.204-4, PRINTED or COPIED DOUBLE-SIDED ON RECYCLED PAPER. Does this incorporation require the use of 30 percent postconsumer fiber paper and/or printing on both sides of the paper?

Answer: There is EPA guidance that we must utilize 30% post-consumer fiber paper to the maximum extent possible.

Questions: Packaging Insert Printing Interface Control Document page 8, Data Transfer, references the “VA Security and Privacy” documents. This document was not included in the solicitation.

Answer: This document will be provided to the awardee.

Questions: Packaging Insert Printing Interface Control Document page 38, references “CMOP Outsource Interface EDI Document” and states see attached. This document is not attached.

Answer: This document is added, see below, to the solicitation with this amendment.

Attachment 1

Consolidated Mail Outpatient Pharmacy (CMOP) Electronic Data Interface (EDI) Guidelines Version 2

March 2009

1 Table of Contents

ATTACHMENT 2

Table of Contents Table of Contents

Page i of 5 ii

Page 1 of

April 2007 CMOP Electronic Data Interface (EDI) Guidelines Page v of 9 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 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.

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

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:

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

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

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:

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.

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.

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

HL7 recommended field separator.

HL7 recommended encoding characters.

The name of the application creating the batch.

This is the application receiving the data.

Date and time the message was created on the sending station’s system.

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.

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

MUP.

This field will be the station number and the transmission date/time.

Date/Time of Request

Medical Center Station Number

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

9.1.3 ZLF – Master File Update Segment – Required segment

See Request Type table below.

Name of person requesting or approving the action. Format^LAST NAME^FIRST NAME^MI^SUFFIX

Agency Type. See Agency Table below. This table can be added to as necessary.

This is a free text rejection reason. This will only be present if the request was denied or rejected.

ZLF|1|Armstead, Percy|2|

ZLF Request Type

ZLF Agency Table

9.2 Activation Acknowledgement Message (Flat Files: .SAC)

MSH

MFE

ZLF

9.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 is the application receiving the data.

Date and time the message was created on the sending station’s system.

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.

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

MUP.

This field will be the station number and the transmission date/time.

Date/Time of Request

Medical Center Station Number

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

9.2.3 ZLF – Master File Update Segment – Required segment

See Request Type table below.

Name of person requesting or approving the action. Format^LAST NAME^FIRST NAME^MI^SUFFIX

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

9.3 Inactivation Acknowledgement Message (Flat Files: .SAC)

MSH

MSA

9.3.1 MSH – Message Header Segment – Required segment

HL7 recommended field separator.

HL7 recommended encoding characters.

The name of the application creating the batch.

This is the application receiving the data.

Date and time the message was created on the sending station’s system.

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.

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

Message Control ID. This will be same as on the preceding MSH segment.

This will be null.

MSA|CA|0111-011214|

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

HL7 recommended field separator.

HL7 recommended encoding characters.

The name of the application creating the batch. In the VA this will always be VistA. For DoD- “DOD”.

This is the application receiving the data.

Date and time the message was created on the sending station’s system.

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.

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 9.4.2 ARQ – Appointment Request Segment – Required segment

This is the Station ID.

This is the code for the type of scheduling event. See table below.

This is the Date/Time the transmission schedule will begin. MLLP: Time to process Rx’s received.

Repeating Interval. See Chapter 4, Section 4.4.2

Name of the Point of Contact from the Medical Center. Format

^LAST NAME^FIRST NAME^MI^SUFFIX

Phone Number of the point of contact in sequence 15.

The person who initiated the request. Format

^LAST NAME^FIRST NAME^MI^SUFFIX

The phone number of the person initiating the request.

Request Event Reason

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

9.5 Schedule Acknowledgement (Flat Files: .HAC)

MSH

MSA

9.5.1 MSH – Message Header Segment – Required segment

HL7 recommended field separator.

HL7 recommended encoding characters.

The name of the application creating the batch. In the VA this will always be VistA. For DoD- “DOD”.

This is the application receiving the data.

Date and time the message was created on the sending station’s system.

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.

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

Message Control ID. This will be same as on the preceding MSH segment.

This will be null.

MSA|CA|10111-011214|

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

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

)[NTE|8]

{[ZML]}

{[ZSL]}

ORC

RXE

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

){[NTE|7]}

ZR1

[NTE|11]}

BTS

FTS

9.6.1 FHS – File Header Segment – Required segment

HL7 recommended field separator.

HL7 recommended encoding characters.

The name of the application creating the batch.

The name of the sending medical center.

The name of the receiving station.

The date and time the batch was created on the sending station system.

This field will be the file name. The file name is the batch number concatenated with the file extension.

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

9.6.2 BHS – Batch Header Segment – Required segment

HL7 recommended field separator.

HL7 recommended encoding characters.

The name of the application creating the batch.

The name of the sending medical center.

The date and time the batch was created on the sending station system.

RAR^RAR

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.

This is the transmission number.

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

9.6.3 ORC – Common Order Segment – Required segment

This field will contain the pharmacy division name and unique pharmacy division number.

This field contains the return mailing address for the sending pharmacy division.

This is the phone number for the sending pharmacy division.

ORC|NW||…