EDI 275 – Patient Information / Health Care Claim Attachment (ANSI ASC X12)

What Is the EDI 275?

The EDI 275 Patient Information transaction set is an ANSI ASC X12 healthcare transaction used to exchange supplemental patient information and electronic healthcare claim attachments between healthcare organizations. Rather than replacing the EDI 837 Health Care Claim, the EDI 275 extends it by transmitting documentation that cannot be represented within the structured claim itself, including clinical records, operative reports, laboratory results, imaging reports, certificates of medical necessity (CMNs), discharge summaries, and other supporting medical documentation required for claim adjudication.

Healthcare organizations rely upon the EDI 275 whenever additional documentation must accompany a healthcare claim, authorization request, utilization review, workers' compensation submission, or payer documentation request. By replacing paper attachments with standardized electronic documents, the transaction reduces manual handling, accelerates adjudication, and improves regulatory compliance while protecting Protected Health Information (PHI) through standardized electronic exchange.

Unlike many healthcare transactions that communicate structured business data, the EDI 275 uniquely accommodates binary clinical content using standardized attachment structures. The transaction therefore acts as the bridge between administrative EDI processing and clinical documentation.
 

Transaction Identity Block

What Does the EDI 275 Do?

The EDI 275 provides a standardized mechanism for electronically transmitting patient documentation that supports healthcare business transactions. Instead of mailing paper records, faxing physician notes, or uploading documents through proprietary payer portals, healthcare organizations package supporting documentation inside a standardized ANSI ASC X12 transaction. 

Electronic attachments commonly include:

• Operative reports
• Clinical notes 
• Progress notes 
• Laboratory reports 
• Imaging reports 
• Pathology reports
• Certificates of Medical Necessity (CMNs) 
• Referral documentation 
• Medical histories
• Therapy documentation 
• Discharge summaries 
• Prior authorization documentation 

The transaction may contain either:

• Base64-encoded binary content embedded directly inside the transaction through the BDS segment; or 
• A secure reference to externally stored clinical content, depending upon payer implementation requirements.

Rather than functioning as an isolated transaction, the EDI 275 operates as part of a larger healthcare revenue cycle and authorization workflow.
 

What Is a Healthcare Attachment?

A healthcare attachment is supplemental clinical documentation transmitted electronically to support a healthcare claim, prior authorization, utilization review, or medical review process. The EDI 275 standardizes these electronic attachments by allowing providers to exchange medical records, laboratory reports, imaging studies, operative reports, and other supporting documentation alongside administrative healthcare transactions.

Who Uses the EDI 275?

Organizations exchanging healthcare documentation routinely use the EDI 275 to automate attachment management.

Primary users include:

Healthcare providers generate the majority of EDI 275 transactions, while payers consume them during claim adjudication, medical review, utilization management, fraud investigation, and audit activities.
 

When Is the EDI 275 Required?

The EDI 275 is transmitted whenever supporting documentation is required to complete a healthcare business process.

Common scenarios include:

• Additional documentation requested after claim submission 
• Initial claim submission requiring mandatory attachments 
• Prior authorization documentation 
• Medical necessity validation 
• Utilization review 
• Appeals processing 
• Workers' compensation medical reporting 
• Disability claim support 
• Medical record exchange 
• Government program documentation requirements 

Many payers request an EDI 275 after reviewing an EDI 837 claim when automated edits determine that additional information is necessary before adjudication.

Other companion guides require providers to proactively transmit the EDI 275 immediately following the associated EDI 837.
 

Is the EDI 275 Mandated Under Regulation?

The EDI 275 operates within HIPAA Administrative Simplification standards governing electronic healthcare transactions. Although HIPAA historically standardized numerous healthcare transactions, implementation of healthcare attachments has evolved through CMS rulemaking and payer adoption.

Covered entities exchanging healthcare attachments electronically must comply with:

• HIPAA Privacy Rule 
• HIPAA Security Rule 
• HIPAA Administrative Simplification 
• Applicable CMS attachment implementation requirements 
• Companion guides published by individual payers 
• Workers' Compensation jurisdictional requirements where applicable 

Healthcare organizations should distinguish between:

• HIPAA transaction standardization 

• CMS implementation requirements 

• Individual payer companion guide requirements 

Each layer influences implementation behavior.
 

How Does the EDI 275 Work in the Business Workflow?

The EDI 275 occupies the documentation layer of the healthcare revenue cycle.

Instead of communicating financial or adjudication data, it communicates evidence supporting those financial transactions. 
 

Upstream Transactions

Downstream Transactions

Industry-Specific Workflow Variations

Although the transaction structure remains standardized, operational workflows differ considerably across healthcare segments.
 

Commercial Insurance

Commercial insurers frequently automate attachment requests through integrated claim editing systems. Electronic attachments may be requested immediately following claim receipt or submitted proactively based upon payer companion guides. 

Typical workflow:

270 → 271 → 837 → 275 → 277 → 835
 

Medicare

Medicare implementations generally follow CMS guidance and companion guides with strict attachment validation rules, emphasizing standardized document identification and timely submission.

Typical workflow:

270 → 271 → 837 → 275 → 277 → 835

Medicaid

State Medicaid agencies often publish jurisdiction-specific companion guides defining:

• accepted attachment categories 

• required document formats 

• submission timing 

• allowable attachment codes 

• jurisdiction-specific references 
   

Workers' Compensation

Workers' compensation organizations frequently exchange substantially more clinical documentation than commercial healthcare.

Typical attachments include:

• injury reports 

• operative reports 

• physician narratives 

• disability evaluations 

• rehabilitation documentation 

• independent medical examinations (IMEs) 

Typical workflow:

148 → 837 → 275 → 277 → 835
 

End-to-End Workflow Example

Managed Care Organizations

Managed Care Organizations leverage the EDI 275 extensively during utilization management, authorization review, medical necessity determination, case management, and quality assurance activities. 
 

Cross-Standard Canonical Mapping

Although the EDI 275 is an ANSI ASC X12 healthcare transaction, its business purpose—transmitting supplemental patient documentation—exists across multiple healthcare interoperability standards. The EDI 275 serves as the standardized attachment transaction within the X12 healthcare ecosystem, while other healthcare messaging standards provide comparable capabilities using different message structures.

Unlike HL7 or FHIR, which focus on broad clinical interoperability, the EDI 275 is designed specifically for administrative healthcare workflows involving claims, authorizations, reimbursement, and payer documentation. It provides a standardized mechanism for associating clinical documentation with administrative healthcare transactions while maintaining compatibility with HIPAA-adopted X12 transaction standards.
 

How Does PartnerLinQ Use the EDI 275?

PartnerLinQ uses the EDI 275 to automate the secure exchange of supplemental patient information between providers, payers, clearinghouses, managed care organizations, and workers' compensation entities. The platform transforms clinical documentation into standardized X12 transactions while preserving traceability to associated claims, authorization requests, and healthcare business processes.

Rather than treating healthcare attachments as isolated files, PartnerLinQ incorporates the EDI 275 into an intelligent healthcare integration workflow that coordinates structured business transactions with the supporting clinical documentation required for adjudication.
 

Where Is the EDI 275 Used?

The EDI 275 is most commonly deployed throughout healthcare provider and payer ecosystems.

Typical environments include:

• Hospitals 

• Integrated Delivery Networks (IDNs) 

• Physician Practices 

• Ambulatory Surgery Centers 

• Clinical Laboratories 

• Diagnostic Imaging Centers 

• Commercial Insurance Companies 

• Medicare Administrative Contractors 

• Medicaid Agencies 

• Managed Care Organizations 

• Workers' Compensation Boards 

• Healthcare Clearinghouses 

• Third-Party Administrators 

• Revenue Cycle Management organizations 

Healthcare organizations exchanging clinical documentation electronically frequently implement the EDI 275 alongside the EDI 837, 277, 278, and 835 as part of an integrated revenue cycle management strategy.
 Compliance Reporting

When Is the EDI 275 Required?

Patient information exchanged by way of the EDI 275 may be solicited or unsolicited. Solicited attachments are submitted in response to a payer request for additional information, while unsolicited attachments accompany an initial healthcare claim or authorization request when supporting clinical documentation is expected. The EDI 275 supports both solicited and unsolicited healthcare attachments, requirements for which are generally determined by each trading partner's companion guide and implementation policies.
 

Are There Industry-Specific Responses to the EDI 275?

Yes. Although ANSI ASC X12 standardizes the transaction structure, implementation varies considerably depending upon the healthcare sector, payer, and regulatory environment.

Examples include:

Most implementation differences occur within:

• document types 

• attachment timing 

• required reference identifiers 

• allowable document formats 

• companion guide validation rules 

• security requirements 

The underlying X12 transaction structure remains standardized even when business rules differ.
 

What Is the Purpose, Key Features, and Business Use Cases of the EDI 275?

The EDI 275 provides a standardized method for transmitting supplemental patient information that cannot be represented inside structured healthcare transactions. Rather than exchanging paper records or proprietary electronic files, organizations exchange standardized electronic attachments linked directly to claims, authorizations, or other healthcare business events.

The transaction improves operational efficiency by eliminating manual document handling while providing secure, traceable exchange of clinical information throughout the healthcare ecosystem.
 

Operational Purpose

The primary operational purpose of the EDI 275 is to electronically transmit patient documentation supporting healthcare administrative transactions.
 

Key Features

The EDI 275 includes several capabilities designed specifically for healthcare attachment processing.

Key features include:

• Standardized X12 transaction format 

• Patient demographic information 

• Traceability through TRN references 

• Binary attachment support using the BDS segment 

• Clinical document categorization 

• Multiple participant identification 

• Companion guide extensibility 

• HIPAA-aligned structure 

• Secure document exchange 

• Support for both solicited and unsolicited attachments 

Business Use Cases

The EDI 275 supports numerous healthcare business processes.

Industry Applications

Although most frequently associated with healthcare claims, the EDI 275 supports a broad range of administrative healthcare workflows.

Primary applications include:

• Health Insurance 

• Government Healthcare 

• Revenue Cycle Management 

• Workers' Compensation 

• Behavioral Health 

• Hospital Billing 

• Specialty Care 

• Clinical Documentation Exchange 

• Utilization Management 

• Case Management 

Operational Visibility

The EDI 275 improves operational visibility by integrating documentation exchange directly into automated healthcare workflows.

Organizations gain visibility into:

• Attachment submission status 

• Outstanding documentation requests 

• Pending claim documentation 

• Missing attachments 

• Processing exceptions 

• Workflow bottlenecks 

• Companion guide compliance 

• Transaction acknowledgments 

Rather than managing documentation through email, fax, or paper files, healthcare organizations gain centralized monitoring of documentation throughout the revenue cycle.

Compliance Reporting

Healthcare organizations use the EDI 275 to support compliance with electronic healthcare transaction requirements while maintaining auditability of patient documentation exchanges.

The transaction supports:

• HIPAA Administrative Simplification 

• HIPAA Privacy Rule 

• HIPAA Security Rule 

• CMS attachment initiatives 

• Companion guide compliance 

• Internal audit requirements 

• Healthcare accreditation documentation 

Electronic transmission also improves document traceability by associating attachments with transaction control numbers, trace identifiers, and reference numbers contained within the X12 message.
 

Financial Reconciliation

Although the EDI 275 does not communicate payment information, it directly influences healthcare reimbursement.

Supporting documentation frequently determines whether a claim:

• proceeds to adjudication, 

• remains pending, 

• requires additional review, 

• is denied, 

• or advances toward payment. 

Timely submission of complete attachments reduces reimbursement delays while minimizing manual follow-up.
 

Healthcare Information Exchange (Clinical Information Coordination)

Within healthcare, information functions as a critical operational asset flowing between providers, payers, clearinghouses, laboratories, government agencies, and managed care organizations.

The EDI 275 coordinates this information flow by ensuring that supporting clinical documentation accompanies administrative healthcare transactions throughout the reimbursement lifecycle.
 

Exception Management

The EDI 275 serves as an important exception-management transaction by resolving documentation deficiencies before they delay reimbursement.

Common operational exceptions include:

Healthcare organizations frequently integrate these exception workflows into automated revenue cycle management systems, reducing manual intervention while accelerating claim resolution.
 

What Information Is Required in the EDI 275?

The EDI 275 Patient Information transaction contains the information needed to electronically transmit supplemental patient documentation supporting healthcare claims, prior authorizations, and other clinical workflows. Required information typically includes patient identification, participating organizations, trace references, document categories, service dates, and the clinical attachment itself, allowing payers to associate supporting documentation with the appropriate healthcare transaction. 
 

Quick Segment Reference

The EDI 275 uses a relatively compact transaction structure that combines patient identification, participating organizations, document classification, reference identifiers, trace information, dates, and binary attachment data. Together these segments create a standardized healthcare attachment capable of supporting automated claim adjudication and clinical documentation exchange.
 

Required Segments

The EDI 275 requires core transaction segments that identify the transaction, patient, healthcare participants, attachment references, service dates, document category, and binary attachment content. Required segments establish transaction integrity while ensuring the receiving payer can correctly associate the attachment with the intended healthcare claim or authorization request.
 

Summary Table of Key Segments

The following segments form the core of the EDI 275 Patient Information transaction.

Optional Segments

Optional segments within the EDI 275 provide additional demographic, communication, location, and reference information when required by trading partners or companion guides. Although not mandatory under the base ANSI X12 standard, many healthcare organizations require these segments to improve document matching, routing, and clinical workflow automation. 
 

Required Identifiers

The EDI 275 relies on multiple identifiers to associate attachments with the correct patient and healthcare transaction. Common identifiers include patient identifiers, provider identifiers, payer identifiers, transaction control numbers, trace numbers, and reference numbers that link supplemental documentation to previously submitted claims or authorization requests. 
 

Required Dates

The EDI 275 commonly includes service dates, attachment creation dates, transaction dates, and other clinically significant dates required by companion guides. Accurate date information ensures healthcare attachments are correctly associated with claims, authorization requests, utilization reviews, and reimbursement timelines. 
 

Required Reference Numbers

Reference numbers establish the relationship between the EDI 275 attachment and the healthcare transaction it supports. These references commonly include claim numbers, attachment control numbers, trace numbers, authorization identifiers, or payer-assigned references that enable automated document matching during claim adjudication. 
 

Required Attachment Information

The EDI 275 transmits supplemental clinical documentation using standardized attachment structures. Attachments may contain encoded medical records, laboratory reports, imaging reports, operative notes, certificates of medical necessity, discharge summaries, or other supporting documentation that cannot be represented within the EDI 837 Health Care Claim transaction.
 

What File Formats Can an EDI 275 Contain?

The EDI 275 may transport or reference many types of clinical documentation depending on the trading partner's implementation guide. Common formats include PDF documents, TIFF images, JPEG images, XML documents, plain text reports, and Base64-encoded binary content embedded directly within the transaction using the BDS segment.
 

What Is the BDS Segment?

The BDS (Binary Data Structure) segment contains the electronic clinical attachment associated with the EDI 275 transaction. Most implementations transmit Base64-encoded documents, allowing medical records, laboratory reports, imaging studies, and other clinical files to travel securely within a standardized ANSI ASC X12 transaction.
 

What Status and Reason Codes Are Used with the EDI 275?

The EDI 275 does not use standardized healthcare claim status codes like the EDI 277. Instead, successful processing depends on transaction acknowledgments, companion guide validation, document references, attachment categories, and business rule validation performed by the receiving healthcare organization.
 

Status Codes

The EDI 275 itself does not communicate claim adjudication or reimbursement status. Processing status is typically conveyed through related transactions such as the EDI 277 Health Care Claim Status Response, while the EDI 275 focuses solely on securely transmitting supplemental patient documentation supporting healthcare business processes.
 

Reason Codes

The EDI 275 does not define a standard set of ANSI X12 reason codes. Rejections generally result from missing required information, invalid identifiers, unsupported attachment types, companion guide violations, or document formatting errors identified during payer or clearinghouse validation.
 

Industry-Specific Code Sets

Healthcare payers frequently publish companion guides that define acceptable attachment categories, document identifiers, reference qualifiers, and business validation rules. These implementation guides supplement the ANSI X12 standard and often determine whether an EDI 275 attachment is accepted for processing.
 

What Are the Benefits of the EDI 275?

The EDI 275 improves healthcare documentation exchange by replacing paper attachments with standardized electronic transactions. Automated attachment processing accelerates claim adjudication, reduces manual handling, improves document traceability, and strengthens collaboration between providers, payers, and healthcare clearinghouses.
 

Operational Benefits

The EDI 275 improves operational efficiency by electronically delivering clinical documentation directly into healthcare workflows. Standardized attachments reduce manual document handling, eliminate duplicate submissions, improve tracking, and help providers respond more quickly to payer requests for additional information.
 

Financial Benefits

Timely transmission of complete supporting documentation reduces reimbursement delays by helping payers complete medical reviews more efficiently. Faster attachment processing can shorten claim adjudication cycles, reduce resubmissions, and improve healthcare revenue cycle performance. 
 

Compliance Benefits

The EDI 275 supports HIPAA-aligned electronic document exchange by standardizing how supplemental patient information is transmitted between healthcare organizations. Electronic processing also improves auditability, protects patient information, and helps organizations satisfy payer and regulatory documentation requirements.
 

What Are the Benefits of Automating the EDI 275?

Automating the EDI 275 eliminates manual document preparation, mailing, faxing, and portal uploads by integrating clinical attachments directly into healthcare workflows. Automation improves document accuracy, accelerates attachment delivery, increases operational visibility, and reduces administrative costs throughout the healthcare revenue cycle.
 

Are There Regulatory and Compliance Requirements for the EDI 275?

The EDI 275 operates within the HIPAA Administrative Simplification framework governing electronic healthcare transactions. Healthcare organizations must also comply with HIPAA Privacy and Security Rules, payer companion guides, CMS implementation guidance where applicable, and jurisdiction-specific requirements for government and workers' compensation programs.
 

EDI 275 Technical Structure, Format, and Versions

The EDI 275 follows the ANSI ASC X12 transaction structure for Patient Information and electronic healthcare attachments. It combines standardized header, identification, reference, date, classification, and binary attachment segments to securely exchange supplemental patient documentation between healthcare organizations while maintaining compatibility with HIPAA-compliant healthcare workflows. 
 

Hierarchical Loop Structure

The EDI 275 uses a structured sequence of heading and detail loops to organize patient information, participating organizations, reference identifiers, attachment metadata, and binary clinical content. This hierarchical organization allows receiving healthcare systems to accurately associate supporting documentation with the corresponding patient, provider, and healthcare transaction.
 

What Delimiters Are Used?

The EDI 211 uses standard ANSI X12 delimiters including element separators, segment terminators, and component element separators. Trading partners may vary delimiter characters based on implementation requirements.
 

File Format and Delimiters

Using the following Production Delimiters on all EDI transmissions sent to Vendors, Carriers, Trading and Solution partners will enable consistent EDI parsing across trading partners:

• Segment Separator – hex 15 (NAK) or hex 7E (~) 
• Element separator – hex 7C (|) or hex 2A (*)
• Sub-element Separator – hex 3E (>)
   

Version Differences

The EDI 275 has evolved through multiple ANSI ASC X12 releases while maintaining its core purpose of exchanging supplemental patient information. Later implementations improve attachment support, implementation guidance, and interoperability with HIPAA-adopted healthcare transactions, although individual payers frequently publish companion guides that further refine implementation requirements.
 

What Are the Limitations of the EDI 275?

The EDI 275 standardizes electronic healthcare attachments but does not eliminate payer-specific implementation requirements. Companion guides, supported attachment formats, document size limitations, and business validation rules frequently vary among healthcare organizations, requiring providers to validate trading partner requirements before implementation.
 

Version or Companion Guide Constraints

Companion guides frequently define the practical implementation of the EDI 275 beyond the ANSI ASC X12 base standard. Healthcare organizations commonly specify accepted attachment categories, document formats, reference identifiers, implementation versions, and validation rules that must be satisfied before attachments are accepted for processing.
 

Jurisdiction-Specific Requirements

Government healthcare programs, state Medicaid agencies, Medicare contractors, and workers' compensation jurisdictions often publish additional implementation requirements governing electronic healthcare attachments. These jurisdiction-specific rules may influence document content, attachment timing, required references, and validation procedures while preserving the underlying ANSI ASC X12 transaction structure.
 

Timing and Frequency Limitations

The timing of an EDI 275 submission depends upon the associated healthcare workflow and payer requirements. Attachments may accompany an initial claim, follow a request for additional information, or support prior authorization and utilization review processes, with submission deadlines commonly defined by payer companion guides.
 

Are Implementation Guidelines and Sample Files Available for the EDI 275?

Implementation guidance for the EDI 275 is available through ANSI ASC X12 implementation conventions, payer companion guides, and trading partner specifications. These documents define segment usage, business rules, attachment handling, required identifiers, and validation requirements needed to exchange electronic healthcare attachments successfully.
 

Companion Guides

Companion guides supplement the ANSI ASC X12 standard by defining payer-specific implementation requirements for the EDI 275. These guides commonly specify accepted attachment types, document classifications, implementation versions, required reference identifiers, and validation rules that healthcare providers must follow during electronic document exchange.
 

Trading Partner Requirements

Trading partners frequently establish additional implementation requirements beyond the ANSI ASC X12 standard. Typical requirements include supported attachment formats, maximum document sizes, identifier conventions, security expectations, testing procedures, and companion guide compliance before production deployment. 
 

EDI 275 Example File (X12 Sample)

An EDI 275 example demonstrates how healthcare providers electronically package supplemental patient information using the ANSI ASC X12 Patient Information transaction. A typical example includes transaction control information, patient and provider identification, reference numbers, service dates, document classification, and an encoded clinical attachment that supports a healthcare claim or authorization request.

ISA*00*  *00*  *ZZ*TESTHIH  *ZZ*111222333   *170320*1110*^*00602*000001100*0*T*:~
GS*PI*TESTHIH*111222333*20170320*1528*1*X*006010~
ST*275*0001*006020X314~
BGN*02*112220221*20180514~
NM1*PR*2*CARROL*****XV*1234~
NM1*41*1*SMITH*JENNIFER*T***46*1112229993~
NM1*1P*2*JOHN*MUFFY*M**M.D.*XX*1234567893~
NX1*1P~
N3*PO BOX 123*157 WEST 57TH STREET~
N4*CINCINNATI*OH*43017~
NM1*QC*1*CARROL*JENNIFER*T**PH.D*MI*9012345918341~
REF*X1*3920394930203~
LX*1~
TRN*1*SURA1234451~
DTP*368*D8*20180514~
CAT*AE*HL~
OOI*1*47*ATTACHMENT~
BDS*B64*16*ClinicalDOCinB64~
SE*17*0001~
GE*1*1~
IEA*1*000001100~

Annotated EDI 275 Sample

An annotated EDI 275 sample explains the purpose of each segment and illustrates how patient information, healthcare participants, trace references, attachment metadata, and binary clinical content work together. Segment-by-segment annotation helps implementation teams understand both the technical structure and the underlying healthcare business process supported by the transaction.

What Are the More Common EDI Errors and Rejection Scenarios for the EDI 275?

Most EDI 275 implementation issues result from structural validation failures, missing identifiers, invalid attachment references, unsupported document formats, or companion guide noncompliance. Identifying and correcting these issues before transmission improves attachment acceptance rates and helps prevent delays in healthcare claim adjudication and authorization workflows.
 

Structural Errors (997 / 999) 

Structural errors occur when the EDI 275 does not conform to the ANSI ASC X12 implementation standard. Common issues include missing mandatory segments, incorrect segment sequencing, invalid loop structures, or mismatched control numbers. These errors are typically identified through Functional Acknowledgments (997) or Implementation Acknowledgments (999) before business processing begins.
 

Data Validation Errors

Data validation errors occur when required business information is incomplete, inconsistent, or fails payer validation rules. Examples include incomplete patient demographics, missing reference identifiers, invalid provider identifiers, incorrect service dates, or incomplete attachment classification information required by the receiving healthcare organization.
 

Identifier Mismatch Errors

Identifier mismatches occur when patient identifiers, provider identifiers, claim references, authorization numbers, or trace references do not correspond to previously submitted healthcare transactions. Accurate identifier correlation is essential for linking the EDI 275 attachment to the correct healthcare claim or authorization request during automated processing.
 

Attachment Validation Errors

Attachment validation errors occur when the transmitted document cannot be processed by the receiving system. Common causes include unsupported attachment formats, invalid Base64 encoding, incorrect document classifications, incomplete binary content, or attachment sizes that exceed trading partner limitations defined in companion guides.
 

Version Compliance Errors

Version compliance errors occur when the transmitted EDI 275 does not match the implementation version expected by the trading partner. Healthcare organizations should verify ANSI ASC X12 versions, implementation conventions, and payer companion guide requirements before exchanging production healthcare attachments.
 

Healthcare-Specific Rejection Scenarios

Healthcare organizations may reject an EDI 275 when required clinical documentation is missing, attachment categories are unsupported, document references cannot be matched to an existing healthcare transaction, or payer-specific companion guide requirements have not been satisfied. Early validation significantly reduces manual intervention and reimbursement delays.
 

What Are the Basic Questions for EDI Integration with the EDI 275?

Successful EDI 275 implementations begin by identifying trading partner requirements, supported implementation versions, accepted attachment formats, reference identifier rules, security expectations, and companion guide requirements. Understanding these implementation details reduces onboarding time and improves first-pass transaction acceptance.

1. Are there Samples and Specs available?
2. What is the general direction of the transaction?
3. Are inbound or outbound orders required?
4. Are AS2, VAN, or SFTP connections used?
5. Are more than one trading partner exchanging the EDI 275?
6. Are there other interested parties? 
7. What trading partner requirements apply?
8. What version is required? 
9. What versions are supported?
10. What other transactions might these interested parties be a party to?
11. What response to the EDI 275 is expected or sent?
12. Is a response to EDI 275 a timed event?  Are notifications involved/needed?
13. What system generates the response?
14. What response time is contractually required?
15. Are there samples and specs of the response transaction available?
16. Are change orders supported?
17. What validation rules apply?
18. How are changes to the EDI 275 business message managed today?
19. Is there automation? (an internal system trigger) or are EDI 275 business message transactions triggered manually?
20. How is automation managed (manual vs. system-triggered)?
21. Are responses and changes automatically triggered? (an internal system trigger) 
22. Are alerting systems configured for missed response deadlines?
23. Do transactions require human intervention?
24. What systems generate or consume the transaction?
25. How are changes to the business message managed today?
26. How are one-time addresses handled in ERP?
27. What identifiers are used (SSCC, GTIN)? 
28. Are SKU or UPC identifiers used?
29. What identifiers are required (SKU, UPC, GTIN)?
30. What testing process is required?
31. What validation rules must be applied?
     

What Are the Best Practices for Using the EDI 275?

Organizations achieve the greatest success with the EDI 275 by validating attachments before transmission, maintaining accurate reference identifiers, following payer companion guides, monitoring acknowledgments, securing protected health information, and automating document workflows. These practices improve attachment accuracy while accelerating healthcare claim processing.
 

What Transactions Are Associated with the EDI 275?

The EDI 275 operates within a broader healthcare transaction ecosystem supporting eligibility verification, prior authorization, claim submission, claim status, payment, and technical acknowledgments. Frequently associated transactions include the EDI 270, 271, 278, 837, 277, 824, 835, 997, and 999, creating an integrated electronic healthcare workflow.
 

What Documents Are Commonly Sent Using an EDI 275? (Frequently Attached Documents)

Healthcare providers commonly use the EDI 275 to transmit operative reports, laboratory results, imaging reports, discharge summaries, physician progress notes, pathology reports, certificates of medical necessity, referral documentation, rehabilitation records, and other clinical information supporting healthcare claims and authorization requests.

Why Not Just Email a PDF?

The EDI 275 is designed to support the secure exchange of Protected Health Information (PHI). Organizations typically exchange attachments through secure EDI networks while implementing administrative, physical, and technical safeguards required under the HIPAA Security Rule.
 

How Large Can an Attachment Be?

While ANSI X12 does not prescribe a universal size limit and acceptable attachment sizes are typically determined by each trading partner's companion guide and implementation policies.

Frequently Asked Questions (FAQs)

What is an EDI 275 transaction?

The EDI 275 Patient Information transaction is an ANSI ASC X12 standard used to electronically exchange supplemental patient information and healthcare claim attachments. It enables providers to transmit clinical documentation, medical records, and supporting information that cannot be represented within an EDI 837 Health Care Claim.
 

What is the purpose of the EDI 275?

The primary purpose of the EDI 275 is to electronically transmit supporting patient documentation required for healthcare claims, prior authorizations, utilization reviews, and other administrative healthcare processes. Electronic attachments improve efficiency while reducing paper-based document handling between healthcare organizations.
 

Who uses the EDI 275?

Healthcare providers, hospitals, physician practices, commercial insurers, Medicare, Medicaid, managed care organizations, clearinghouses, and workers' compensation administrators commonly use the EDI 275 to exchange supplemental clinical documentation supporting healthcare transactions.
 

Is the EDI 275 HIPAA compliant?

The EDI 275 operates within the HIPAA Administrative Simplification framework for electronic healthcare transactions. Organizations exchanging healthcare attachments electronically must also comply with HIPAA Privacy and Security Rules, payer companion guides, and applicable CMS implementation guidance.
 

What documents are sent using the EDI 275?

The EDI 275 commonly transmits operative reports, laboratory results, diagnostic imaging reports, discharge summaries, physician notes, certificates of medical necessity, referral documentation, medical records, and other supporting clinical information required during healthcare claim processing.
 

How does the EDI 275 relate to the EDI 837?

The EDI 837 communicates the healthcare claim, while the EDI 275 supplies the supporting documentation that may be required to adjudicate that claim. Together, the transactions provide both the administrative claim information and the clinical evidence supporting reimbursement.
 

Does the EDI 275 contain medical records?

The EDI 275 can transmit electronic medical records or portions of clinical documentation when required by the receiving healthcare organization. Attachments are typically encoded as binary content or transmitted using approved document reference methods defined by trading partner companion guides.
 

What is the BDS segment in an EDI 275?

The BDS (Binary Data Structure) segment contains the encoded electronic attachment included within the EDI 275 transaction. The attachment commonly represents a PDF, image, text report, or other approved clinical document encoded using Base64 or another supported format.
 

Can the EDI 275 support prior authorizations?

Yes. Healthcare organizations frequently use the EDI 275 to transmit supporting clinical documentation for prior authorization requests, utilization review activities, and medical necessity determinations associated with healthcare services.
 

What is the difference between the EDI 275 and EDI 277?

The EDI 275 transmits supplemental patient documentation and healthcare claim attachments, while the EDI 277 communicates the processing status of healthcare claims. The EDI 275 provides supporting clinical evidence, whereas the EDI 277 reports adjudication progress and claim status.
 

Is the EDI 275 used for workers' compensation?

Yes. Workers' compensation organizations commonly use the EDI 275 to exchange injury documentation, physician narratives, operative reports, rehabilitation records, and other medical information supporting workers' compensation claims and medical bill processing.
 

Can an EDI 275 contain multiple attachments?

The EDI 275 supports transmitting supplemental patient information within the structure defined by the applicable ANSI ASC X12 implementation guide and companion guide. Whether multiple attachments are permitted depends upon the trading partner's implementation requirements and document handling policies.
 

What acknowledgments are associated with the EDI 275?

Healthcare organizations typically validate EDI 275 transactions using ANSI ASC X12 Functional Acknowledgments (997) or Implementation Acknowledgments (999). Business-level validation may also be communicated through payer-specific processing responses and companion guide workflows.
 

How are attachments linked to a healthcare claim?

The EDI 275 links attachments to healthcare claims using reference numbers, trace identifiers, patient identifiers, provider identifiers, and other transaction references that allow receiving systems to associate the supplemental documentation with the correct administrative healthcare transaction.
 

What industries use the EDI 275?

The EDI 275 is primarily used throughout the healthcare industry, including hospitals, physician practices, laboratories, imaging centers, commercial health plans, government healthcare programs, managed care organizations, healthcare clearinghouses, and workers' compensation administrators.
 

What implementation challenges are common with the EDI 275?

Organizations most frequently encounter challenges involving companion guide compliance, attachment formatting, identifier matching, document classification, binary encoding, implementation version compatibility, and payer-specific business validation requirements.
 

How does PartnerLinQ support the EDI 275?

PartnerLinQ automates the secure exchange of EDI 275 healthcare attachments by validating transaction structure, integrating companion guide requirements, managing binary clinical documents, orchestrating healthcare workflows, and providing operational visibility across provider, payer, and clearinghouse ecosystems.
 

What transactions commonly work with the EDI 275?

The EDI 275 commonly operates alongside the EDI 270, 271, 278, 837, 277, 824, 835, 997, and 999. Together, these transactions support eligibility verification, authorization, claim submission, attachment processing, claim status, payment, and technical acknowledgment within the healthcare revenue cycle.
 

How EDI 275 Works for Dental Claims?

The EDI 275 works is support of Dental Claims, it is capable of carrying clinical data required to process dental services like crowns, bridges, or oral surgery. The EDI 275 allows sending unsolicited attachments (sent with or right after the 837D dental claim) or solicited attachments (sent in response to a payer's request). Payers often require documentation to support certain procedures or dental claims, eligibility, benefit inquiry and response transactions. The EDI 275  when used with or sent right after the 837D dental claim serves to reduce costs for the payee and the patient.
 

Why is automating the EDI 275 important?

Automating the EDI 275 reduces manual document handling, accelerates attachment delivery, improves claim processing efficiency, enhances document traceability, strengthens HIPAA compliance, and helps healthcare organizations respond more quickly to payer requests for additional clinical documentation.
 

How does the EDI 275 improve healthcare interoperability?

The EDI 275 improves healthcare interoperability by providing a standardized method for exchanging supplemental patient information between disparate healthcare systems. Standardized electronic attachments reduce reliance on paper, fax, and proprietary document exchange methods while improving coordination across providers, payers, and healthcare networks.
 

How Does the EDI 275 Compare to HL7 FHIR?

The EDI 275 and HL7 FHIR both support healthcare information exchange but address different business needs. The EDI 275 standardizes supplemental documentation exchanged during healthcare claims processing, while FHIR focuses on real-time clinical interoperability through APIs and structured healthcare resources. Many healthcare organizations use both standards together within modern interoperability strategies.