Part D Transaction Facilitator

Form / Attachment / Pricing Sheet

This document, "Appendix E_020226.pdf", appears to be a technical specification or data dictionary related to transaction formats for Medicare Part D. It details the structure and content of various transaction segments, including header, patient, insurance, response, and status segments, for different transaction types (e.g., vD.0 E1, Batch N, F1, F2, F3).

• Transaction Segments: Defines mandatory and optional segments for requests and responses, such as Request Header, Patient Segment, Insurance Segment, Response Header, Response Status, and Response Claim Segment.
• Field Definitions: Provides detailed information on individual fields within each segment, including Field Name, Type, Length, Start/End positions, Use (Mandatory, Required, Optional), Value, and Comments.
• Transaction Codes: Specifies transaction codes like 'E1' for Eligibility Verification, and various codes for Financial Information Reporting (F1, F2, F3).
• Data Formats: Outlines expected data formats for fields like dates (CCYYMMDD), and numeric values.
• Reject Codes and Messages: Details specific reject codes and their corresponding descriptions and messages for various error conditions encountered during transaction processing.

This document is highly relevant for vendors developing systems that need to interface with Medicare Part D or other payers using these NCPDP (National Council for Prescription Drug Programs) standards. It provides the technical specifications required for constructing compliant transaction requests and interpreting responses, particularly for eligibility verification and financial information reporting. Understanding these specifications is crucial for accurate data submission and processing, ensuring successful integration with payer systems and avoiding rejections due to formatting or data errors.

Other / Unclassified

This document is a flowchart illustrating the "Real-time Supplemental Payment N Transaction Process." It outlines the steps involved when a pharmacy submits a claim to a Part D Plan, and how supplemental payments are handled.

This document is relevant to bidders as it visually explains a specific process related to pharmacy claims and payments within the Part D program. Understanding this process can be crucial for vendors involved in healthcare IT, pharmacy benefit management, or claims processing systems, as it details the flow of information and transactions between pharmacies, Part D plans, supplemental payers, and transaction facilitators. It highlights decision points and potential outcomes, such as claim acceptance, rejection, or the need for further follow-up, which could impact system design, integration, or operational procedures for any related government contract.

Form / Attachment / Pricing Sheet

This document, "Beneficiary Information on the Cloud (BIC) Transaction Facilitator Interface Specification Version 7.0", details the technical specifications for the daily data exchange between the Medicare Enrollment and Premium Billing Systems (MEPBS) and the TRF Contractor. It outlines the format and structure of the Transaction Facilitation (TRF) batch file, which is generated in JavaScript Object Notation (JSON) format.

• TRF Batch File Structure: Defines three types of records: Header, Detail (update or delete), and Trailer.
• Data Elements: Specifies attributes for beneficiary information, including enrollment status (Part A, B, C, D), mailing address, other insurance, low-income subsidy, and historical MBI data.
• Record Formats: Details the structure of each record type, including required fields, data types, lengths, and descriptions.
• Appendices: Includes a topological interconnect diagram (Appendix A), a record of changes (Appendix B), and a list of acronyms (Appendix C).

This specification is crucial for any bidder or contractor involved in the processing or integration of Medicare beneficiary data. It provides the technical blueprint for the data exchange, enabling systems to correctly interpret and utilize the beneficiary information transmitted daily. Understanding this interface is essential for ensuring accurate data handling and system compatibility with CMS's modernized cloud platform.

Form / Attachment / Pricing Sheet

This document outlines the "Transaction Facilitator E1 Medicare Eligibility Matching Logic" which details the requirements and logic for pharmacies submitting eligibility inquiries. It specifies the required fields and the matching process used to determine Medicare eligibility.

• Pharmacy Submission Requirements: Requires Cardholder ID (MBI, full SSN, or last 4 SSN) along with Patient Last Name, at least the first character of Patient First Name, Patient Date of Birth (DOB), and Patient Zip Code. Failure to submit all 5 required fields results in a reject.
• Matching Logic: Details how the system matches submitted information against its database. This includes scenarios for partial SSN submissions (last 4 digits) and full SSN/MBI submissions, considering exact matches, name matches, DOB, and Zip Code.
• Rejection Codes: Lists specific rejection codes (e.g., "NO PATIENT MATCH FOUND", "MISSING REQUIRED FIELD") that pharmacies may receive based on submission errors or lack of a match.

This document is crucial for any bidder involved in pharmacy services or systems that interact with Medicare eligibility. It clarifies the exact data points required for successful eligibility checks and the logic the system uses, which can impact system design, data validation, and operational workflows for pharmacies.

Form / Attachment / Pricing Sheet

This document, "Appendix D_020226.pdf", appears to be an appendix containing detailed information related to specific transactions and processes within the Medicare Part D program. It outlines the procedures and data requirements for various transactions, including:

• Medicare Part D Eligibility Verification Transaction (E1): Details the purpose, required demographic information, and scenarios for submitting an E1 transaction to verify a beneficiary's Part D eligibility and coverage.

• Financial Information Reporting Transactions (FIR): Explains the purpose of FIR transactions in transferring beneficiary information and spending data between Part D plans. It describes three types of FIR transactions (F1, F2, F3), the process for triggering and sending them, and the timing of FIR sequences.

• Supplemental Payment Information Transaction (Nx): Describes the process for Part D plans to coordinate benefits with supplemental payers (e.g., SPAPs, commercial insurance) to ensure accurate TrOOP accumulation and cost sharing. It also introduces the Hospice Part D pilot program, which uses the Nx transaction to transmit hospice election information.

• E1 Transaction: Requires Cardholder ID, Full Last Name, Full First Name (optional), First Initial of First Name, Date of Birth, and ZIP/Postal Code.

• FIR Transactions: Involve Inquiry (F1), Update (F2), and Exchange (F3) types, triggered by changes in beneficiary plans, contract IDs, or other demographic information.

• Nx Transaction: Facilitates coordination of benefits between Part D plans and supplemental payers, and transmits hospice election status.

This document is highly relevant for any bidder involved in the Medicare Part D program, particularly those providing pharmacy services or managing Part D plans. It provides critical technical details on how eligibility, financial information, and supplemental payments are processed and communicated electronically. Understanding these transactions is essential for accurate claims processing, benefit coordination, and compliance with Medicare Part D requirements.

Form / Attachment / Pricing Sheet

This document, Appendix B: Schedule of Deliverables, outlines the specific tasks and their corresponding due dates for the contract. It serves as a critical reference for understanding the expected timeline and deliverables throughout the contract period.

• Tasks: A numbered list of specific actions and responsibilities required under the contract.
• Descriptions: Detailed explanations of each task.
• Due Dates: Specifies when each task is expected to be completed, ranging from 'Ongoing' and 'Daily' to 'Monthly', 'As Needed', and specific dates (e.g., 'Within 15 days of contract award or by December 31, 2022').

This appendix is crucial for bidders to understand the scope of work and the performance expectations. It directly impacts proposal development by highlighting the timing and nature of deliverables, which are key components in assessing a bidder's capability and resource allocation. Bidders should carefully review these deliverables to ensure they can meet the specified requirements and timelines.

Form / Attachment / Pricing Sheet

This document provides specifications for the RelayHealth Message Header, which acts as a wrapper for Switch Composite Transactions for Supplemental Claims. It details the structure and content required for messages submitted to and returned by RelayHealth.

• STX (Start-of-Text): Hex 02.
• Message Length: Total message length excluding STX and the 4 bytes for Message Length itself.
• Header Length: Specifies the total characters for Version, Claim Length, Response Length, and Reference Number fields.
• Version: Must be "01".
• Claim Length: Length of the NCPDP formatted claim.
• Response Length: Length of the NCPDP formatted response.
• Reference Number: Optional field for Switch use, up to 22 ASCII characters (0-9, A-Z).
• Claim: NCPDP formatted claim data.
• Response: NCPDP formatted response data.
• ETX (End-of-Text): Hex 03.
• Response Messages: Details standard captured responses and reject responses (e.g., 'Too Many Threads'), including specific field values and status codes.

This document is crucial for bidders developing systems that will interface with RelayHealth for supplemental claims processing. Understanding the message header specifications, including data field lengths, formats, and response codes, is essential for successful data transmission and integration. It outlines the technical requirements for claim submission and the expected response formats from RelayHealth.

Form / Attachment / Pricing Sheet

This document appears to be a schedule or list of dates, labeled 'BatchDate' and 'TBTYear'. It is likely an attachment providing specific dates relevant to the opportunity, possibly for task orders, deliveries, or reporting periods.

• A list of dates under the 'BatchDate' column.
• Corresponding years under the 'TBTYear' column, indicating the year associated with each 'BatchDate'.

Bidders should review this schedule to understand the timing of potential work, deliverables, or milestones associated with this opportunity. The 'TBTYear' column may indicate the fiscal year or calendar year for specific contract actions or requirements.

Form / Attachment / Pricing Sheet

This document is a Contractor Non-Disclosure Agreement (NDA) that must be completed by each employee of the contractor and any subcontractors who will have access to non-public government information under the contract. It outlines the requirements for protecting sensitive information.

• Agreement to Comply: Bidders must agree to comply with HHS information security and privacy program policies, procedures, practices, and related contract requirements. This includes adherence to HHS privacy and confidentiality laws, HIPAA, the Privacy Act of 1974, the E-Government Act of 2002, NIST SP 800-53, and Executive Order 13556.
• Training Requirements: Employees must complete annual HHS Privacy and security awareness training. If access to protected health information is granted, HIPAA training is also required annually.
• Use of Information: Information provided by HHS or collected by the contractor is to be used solely for the purpose of carrying out the contract provisions. Disclosure to any other person is prohibited unless necessary for contract performance.
• Protection of Information: Bidders must protect the confidentiality, integrity, and availability of information in accordance with HHS policies.
• Consequences of Disclosure: Unauthorized disclosure of information is subject to HHS sanction policies and relevant laws, including potential criminal and civil penalties.
• Definition of HHS Sensitive Information: The document defines HHS sensitive information broadly, including proprietary information, records requiring protection under various laws, information exempt from FOIA, and other data that could cause harm if disclosed.

This document is critical for any bidder whose personnel will access non-public or sensitive HHS information. It mandates specific training and strict adherence to security and privacy protocols. The completed NDA must be submitted to the Contracting Officer prior to the commencement of work. Failure to comply can result in significant penalties.

Request for Information (RFI)

This RFI is issued by the Centers for Medicare & Medicaid Services (CMS) to conduct market research regarding the accurate, timely, and compliant processing of Part D Coordination of Benefits (COB) related transactions between Medicare Part D plans and other payers. The goal is to determine the availability and technical ability of GSA MAS vendors and to inform future procurement methods.

• Document Provided: A draft Statement of Objectives (SOO) including Transition-In and Part D Transaction Facilitation tasks is included.
• Vendor Action Required: Vendors are asked to review the SOO and address specific questions based on their experience. Feedback may be used to refine the SOO and a future Request for Quotation (RFQ).
• Not a Solicitation: This RFI is for information and planning purposes only and does not constitute an RFP or RFQ. The Government will not pay for any costs incurred in responding to this RFI.
• Submission Deadline: Responses are due by May 7, 2026.
• Submission Format: Responses must be submitted via the GSA eBuy portal in Microsoft Word or Adobe PDF format. Hard-copy responses or other formats will not be accepted.

Responses should include three sections:

• Section I: General Vendor Information (Organization Name, UEI, mailing address, POC contact, licenses, expertise, GSA credentials).
• Section II: Contact information for the organization's views (if different from Section I).
• Section III: Concise responses to the listed questions, referencing specific SOO sections where applicable. A table format is provided for questions and responses.

Vendors are asked to provide feedback on:

• Sufficiency of technical detail in the SOO.
• Potential issues with the SOO that would prevent submitting a quote.
• Recommendations for contract type (FFP vs. T&M) for specific tasks.
• Suitable contract vehicles (e.g., GSA MAS, GSA Alliant).
• Labor categories to meet requirements.
• Project management methods.
• Recommended CLIN structure for the payment schedule.
• Need for teaming arrangements.
• Likelihood of responding to a future RFQ and whether they would submit as a prime.

Statement of Objectives (SOO)

This document outlines the high-level outcomes and objectives for a Part D Transaction Facilitator contract. The Centers for Medicare & Medicaid Services (CMS) requires a contractor to support accurate tracking of True Out-of-Pocket (TrOOP) costs, facilitate eligibility queries, and ensure secure and compliant exchange of protected health information (PHI) related to Medicare Part D prescription drug benefit program coordination of benefits (COB).

• Part D Transaction Facilitation: Maintain Medicare Part D Eligibility Index, respond to eligibility queries, build a database of payer BIN/PCNs, accept and route Part D transactions, identify and accept supplemental claims, create and route TrOOP balance transfer transactions, and create and route coordination of benefits information. Requires a 24/7 real-time network.

• HIPAA-Compliant BAA Execution: Ensure full compliance with HIPAA Privacy Rule for PHI exchange, execute BAAs with Part D plan sponsors, and publish standard BAA language.

• Pharmacy Eligibility Query (E1) Support: Provide timely and accurate responses to E1 eligibility queries using NCPDP standard E1 transaction, utilize Medicare Eligibility Index, apply matching criteria, and maintain the E1 environment.

• Disaster Recovery (DR) and System Architecture Compliance: Design and re-architect the DR environment to meet federal continuity and security requirements, maintaining system availability at a Moderate risk level.

• Information Security and Privacy Compliance: Ensure compliance with federal information security and privacy requirements, safeguard PII, handle CUI, and provide immediate notification of threats.

• Program and Technical Management: Provide transparent, accurate, and timely project management, including developing a PMP, maintaining a project schedule, participating in reviews, and submitting status reports.

• Transition-In Support (Optional): Ensure a seamless transition from the incumbent contractor.

• Section 508 Compliance: Ensure all Information and Communication Technology (ICT) developed or delivered complies with Section 508 of the Rehabilitation Act.

• Contract Type: Firm-Fixed-Price (FFP) with Time-and-Materials (T&M) Order-level materials (OLMs) CLINs.

• Offerors must submit a Performance Work Statement (PWS) and a Quality Assurance Surveillance Plan (QASP) as part of their technical proposal.

• The PWS must incorporate all technical requirements from Appendices A through I.

• The QASP must address performance objectives, standards, Acceptable Quality Levels (AQLs), surveillance methods, and remedies.

• Not specified in this document.

• Appendices A through I define binding technical specifications, data formats, matching criteria, and transaction standards that are non-negotiable and must be incorporated into the PWS.

• The overall information system risk level is Moderate.

• The contract involves Personally Identifiable Information (PII) at a Moderate confidentiality impact level.