The
EDI 278 Health Care Services Review Information transaction is an ANSI ASC X12 standard used by healthcare providers, payers, and utilization management organizations to electronically request, evaluate, and communicate prior authorizations, referrals, certifications, and healthcare review decisions.
What Is the EDI 278?
The EDI 278 Health Care Services Review Information transaction is an ANSI ASC X12 healthcare transaction used to electronically exchange healthcare services review information between providers, payers, health plans, utilization management organizations, and other healthcare participants. The transaction supports requests for review, certification, prior authorization, notification, and reporting of healthcare services review outcomes while standardizing the clinical and administrative information required to process those requests.
Healthcare organizations use the EDI 278 to automate utilization management workflows by replacing manual phone calls, faxed forms, and paper documentation with standardized electronic transactions. The transaction exchanges subscriber, patient, provider, diagnosis, treatment, and service information while maintaining end-to-end traceability throughout the healthcare review process.
Unlike claim transactions that request payment, the EDI 278 manages healthcare review activities before or during care delivery. The transaction enables organizations to request prior authorization, receive certification decisions, communicate review outcomes, and coordinate healthcare services using a standardized electronic workflow.
Transaction Identity Block
Attribute | Description |
Transaction Name | Health Care Services Review Information |
ANSI X12 Transaction Set | 278 |
Functional Group | HI (Health Care Services Review Information) |
Document Classification | Healthcare Services Review Transaction |
Primary Industry | Healthcare |
Business Domain | Utilization Management, Prior Authorization, Care Management |
Primary Purpose | Exchange healthcare services review requests, certifications, notifications, and review outcomes |
Typical Exchange Pattern | Provider ↔ Payer / Health Plan / Utilization Management Organization |
Typical Sender | Healthcare Provider, Hospital, Physician Practice, Utilization Management Organization |
Typical Receiver | Health Plan, Commercial Payer, Government Payer, Utilization Review Organization |
Primary Objective | Automate healthcare services review and prior authorization workflows |
Business Value | Improves review accuracy, reduces manual processing, accelerates authorization decisions, and increases workflow visibility |
Common Preceding Transactions | EDI 270 Eligibility Inquiry, EDI 271 Eligibility Response |
Common Following Transactions | EDI 277 Claim Status Response, EDI 837 Health Care Claim, EDI 835 Health Care Claim Payment/Advice |
Primary Standards Organization | Accredited Standards Committee (ASC) X12 |
Standard Version | ANSI ASC X12 Version 005010 (5010) |
What Does the EDI 278 Do?
The EDI 278 standardizes the electronic exchange of healthcare services review information throughout the utilization management lifecycle. Healthcare organizations use the transaction to submit prior authorization requests, receive certification decisions, exchange clinical review information, and communicate review outcomes using a common ANSI ASC X12 format.
Common business functions include:
- Admission reviews
- Certification requests and Certification responses
- Prior authorization requests
- Utilization review
- Referral reviews
- Medical services reservation
- Review outcome reporting
- Clinical information exchange
- Healthcare workflow orchestration
Who Uses the EDI 278?
Healthcare organizations involved in utilization management, prior authorization, certification, and healthcare services review routinely use the EDI 278 Health Care Services Review Information transaction. The transaction supports electronic communication between providers, payers, health plans, utilization management organizations, and other healthcare entities by standardizing the exchange of clinical, administrative, and review information required to evaluate healthcare services.
Primary Users of the EDI 278
Organization | Typical Purpose |
Healthcare Providers | Submit prior authorization, certification, and healthcare services review requests |
Hospitals | Request inpatient admissions, specialty services, and utilization reviews |
Physician Practices | Obtain authorization for procedures, diagnostics, and specialty care |
Commercial Health Plans | Review, approve, modify, or deny healthcare service requests |
Government Health Plans | Process utilization review and certification requests for covered services |
Utilization Management Organizations | Coordinate and manage healthcare services review activities |
Third-Party Administrators (TPAs) | Process healthcare review requests on behalf of health plans |
Healthcare Clearinghouses | Translate, validate, and route EDI 278 transactions between trading partners |
Healthcare providers generate most EDI 278 transactions when requesting prior authorization or certification for healthcare services. Payers, health plans, and utilization management organizations receive the transaction, evaluate the request, and communicate certification, approval, pending, modified, or other review outcomes electronically.
When Is the EDI 278 Required?
The EDI 278 is exchanged whenever healthcare services require review before, during, or after care delivery. Healthcare organizations use the transaction to request authorization, perform utilization review, communicate certification decisions, and report healthcare services review outcomes using a standardized electronic workflow.
Many healthcare organizations exchange the EDI 278 before services are rendered to determine medical necessity and coverage requirements. The transaction may also be used throughout the healthcare review lifecycle to communicate approvals, pending decisions, modifications, or final certification outcomes.
Common business scenarios include:
Prior authorization requests
Admission review
Emergency admission review
Referral review
Home health care review
Medical services reservation
Utilization review
Certification requests
Certification responses
Review outcome reporting
Is the EDI 278 Mandated Under Regulation?
Yes. The X12 278 remains the HIPAA-adopted transaction standard for electronic referral certification and prior authorization. HHS, however, exercises enforcement discretion for HIPAA-covered entities that implement and use qualifying FHIR-based Prior Authorization APIs and elect not to use X12 278 as part of that electronic FHIR prior authorization process.
Under the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), payers are mandated to implement FHIR-based Prior Authorization APIs however HHS maintains enforcement discretion allowing entities to use either FHIR or legacy X12 278 workflows for electronic prior authorization
Healthcare organizations should distinguish between:
HIPAA transaction standardization
CMS implementation requirements
Individual payer companion guide requirements
What Prior Authorization Requirements Apply in 2026?
CMS-0057-F requires impacted payers, subject to applicable program requirements, to improve prior authorization processing beginning in 2026. Requirements include specific denial reasons and decision timeframes of generally 72 hours for expedited requests and seven calendar days for standard requests, helping improve transparency and reduce authorization delays.
What Changes for Prior Authorization in 2027?
Beginning in 2027, impacted payers generally must implement a FHIR-based Prior Authorization API that identifies covered items and services requiring authorization, communicates documentation requirements, and supports electronic authorization requests and responses. The API must communicate approval, denial with a specific reason, or requests for additional information.
Which Payers Are Impacted by CMS-0057-F?
CMS-0057-F applies Prior Authorization API requirements to specified impacted payers, including Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid and CHIP managed-care entities, and Qualified Health Plan issuers on Federally-facilitated Exchanges. Requirements and compliance dates should be evaluated according to the applicable CMS program.
How Does EDI 278 Interoperate with HL7 FHIR PAS?
The HL7 FHIR Prior Authorization Support (PAS) Implementation Guide is designed to transform FHIR resources into the HIPAA-mandated X12 278 transaction structure. While providers interact with modern FHIR APIs inside EHR systems, integration platforms often translate these payloads into standard X12 278 loops (HL03, UM, HCR) for back-end adjudication by health plans.
Does FHIR Replace the EDI 278 for Prior Authorization?
No, not universally the X12 278 remains as the HIPAA-adopted transaction for electronic referral certification and authorization. HHS currently exercises discretionary enforcement for covered entities using qualifying FHIR-based Prior Authorization APIs. CMS also states that X12 278 alone cannot satisfy every CMS-0057-F (Prior Authorization API requirement).
Can EDI 278 Alone Satisfy CMS-0057-F Prior Authorization API Requirements?
No. The X12 278 can exchange prior authorization requests and responses, but CMS states that the current transaction cannot by itself satisfy all CMS-0057-F Prior Authorization API requirements. Impacted payers must implement the required FHIR-based capabilities for coverage requirements, documentation requirements, authorization requests, and decisions.
Can X12 278 and FHIR Be Used Together?
Yes. CMS permits covered entities subject to the applicable enforcement discretion to use qualifying FHIR-based prior authorization processes, including architectures that combine FHIR and X12. Organizations must still satisfy applicable CMS, HIPAA, implementation-guide, and trading-partner requirements.
How does PartnerLinQ Support both the X12 278 and FHIR?
PartnerLinQ provides an orchestration layer between FHIR-based provider workflows and X12-based healthcare transaction environments. Canonical data models, semantic mapping, validation, routing, exception management, and transaction visibility work together to integrate modern APIs with established EDI infrastructure, helping organizations coordinate prior authorization processes across multi-enterprise healthcare environments.
How Does the EDI 278 Work in the Business Workflow?
The EDI 278 supports the healthcare services review lifecycle by electronically coordinating prior authorization requests, utilization reviews, certification decisions, and review outcomes between providers, payers, and utilization management organizations. Rather than relying on phone calls, faxed forms, or paper documentation, trading partners exchange standardized healthcare review information using a structured ANSI ASC X12 transaction.
Upstream Transactions
EDI Transaction | Purpose | Relationship to EDI 278 |
270 | Health Care Eligibility Benefit Inquiry | Verifies patient eligibility before requesting services |
271 | Health Care Eligibility Benefit Response | Confirms coverage and benefits before authorization |
837 | Health Care Claim | References services that may have required prior authorization |
Downstream Transactions
EDI Transaction | Purpose | Relationship to EDI 278 |
277 | Health Care Claim Status Response | Communicates claim or review status following authorization activities |
835 | Health Care Claim Payment/Advice | Supports reimbursement after approved services are adjudicated |
999 | Implementation Acknowledgment | Confirms the structural validity of the EDI 278 transaction |
997 | Functional Acknowledgment | Confirms receipt of the transaction where applicable |
End-to-End Workflow Example
Commercial Health Plans
Commercial payers commonly use the EDI 278 to automate prior authorization and utilization review before services are rendered.
Typical workflow:
270 → 271 → 278 → 837 → 277 → 835
Medicare
Medicare organizations generally follow CMS implementation guidance and payer companion guides when exchanging EDI 278 transactions for healthcare services review.
Typical workflow:
270 → 271 → 278 → 837 → 277 → 835
Medicaid
State Medicaid agencies frequently supplement the ANSI ASC X12 standard with companion guides that define authorization requirements, business rules, and implementation details.
Managed Care Organizations (MCOs)
Managed care organizations rely extensively on the EDI 278 to coordinate utilization management, specialty referrals, medical necessity reviews, certification decisions, and ongoing care management activities.
Cross-Standard Canonical Mapping
The EDI 278 serves as the standardized ANSI ASC X12 transaction for healthcare services review, while HL7 and FHIR standards exchange many of the same clinical and authorization data using different interoperability models.
Standard | Comparable Message | Business Purpose |
ANSI ASC X12 | EDI 278 | Healthcare services review and prior authorization |
HL7 FHIR | CoverageEligibilityRequest / Claim / Prior Authorization workflows | Coverage and authorization exchange |
HL7 CDA | Clinical Document Architecture | Clinical documentation supporting review |
HL7 v2.x | Referral and clinical messaging | Clinical information exchange |
CMS Prior Authorization APIs | Prior authorization workflow | Regulatory healthcare authorization exchange |
Where Is the EDI 278 Used?
The EDI 278 is commonly implemented across healthcare organizations responsible for utilization management and healthcare services review, including:
- Hospitals
- Physician Practices
- Health Systems
- Commercial Health Plans
- Medicare Organizations
- Medicaid Agencies
- Managed Care Organizations (MCOs)
- Utilization Management Organizations
- Healthcare Clearinghouses
- Third-Party Administrators (TPAs)
Are there Industry-Specific Responses to the EDI 278?
Yes. Although the ANSI ASC X12 EDI 278 standard defines a common transaction structure for healthcare services review, implementation varies across healthcare sectors. Health plans, government programs, and utilization management organizations frequently publish companion guides that define business rules, required data elements, code values, response timing, and certification requirements specific to their organizations. These implementation guidelines supplement—but do not replace—the underlying ANSI ASC X12 standard.
Industry | Typical Implementation |
Commercial Health Insurance | Prior authorization, utilization review, and certification workflows are governed by payer-specific companion guides and medical policy requirements. |
Medicare | Healthcare services reviews follow CMS requirements together with Medicare Administrative Contractor (MAC) implementation guidance. |
Medicaid | State Medicaid agencies publish jurisdiction-specific companion guides defining authorization requirements, covered services, and submission rules. |
Managed Care Organizations (MCOs) | The EDI 278 supports utilization management, referral management, specialty care authorization, and ongoing care coordination. |
Hospitals and Health Systems | Organizations exchange EDI 278 transactions for inpatient admissions, outpatient procedures, specialty referrals, and medical necessity reviews. |
Home Health Agencies | The transaction supports certification and authorization for home health services and continuing care. |
Behavioral Health | Providers use the EDI 278 to request and manage authorizations for behavioral health evaluations, inpatient treatment, and ongoing therapy services. |
Third-Party Administrators (TPAs) | TPAs process healthcare services review requests and certification responses on behalf of health plans and self-funded employer groups. |
How does PartnerLinQ use the 278?
PartnerLinQ uses the EDI 278 to automate and orchestrate healthcare services review processes between providers, payers, health plans, utilization management organizations, and other healthcare trading partners. The platform transforms healthcare services review information into standardized ANSI ASC X12 transactions, enabling organizations to electronically submit review requests, receive certification decisions, and exchange clinical and administrative information through a governed, end-to-end workflow.
Rather than functioning solely as an electronic document exchange, the EDI 278 becomes part of PartnerLinQ's intelligent healthcare integration platform, providing standardized transaction processing, business rule validation, operational visibility, and automated workflow coordination across the healthcare services review lifecycle.
What Is the Purpose, Key Features, and Business Use Cases of the EDI 278?
The EDI 278 provides a standardized method for electronically requesting, reviewing, authorizing, certifying, and reporting healthcare services review information. By replacing manual phone calls, paper forms, and faxed documentation with structured electronic transactions, the EDI 278 improves healthcare workflow efficiency, reduces administrative processing, and accelerates authorization decisions.
Operational Purpose
The primary purpose of the EDI 278 is to electronically exchange healthcare services review information required to evaluate, authorize, certify, or report healthcare services before or during patient care.
Key Features
The EDI 278 includes capabilities designed specifically for healthcare services review.
- Standardized ANSI ASC X12 transaction format
- Hierarchical participant structure (HL loops)
- Prior authorization and certification support
- Utilization review processing
- Review outcome reporting
- Clinical and administrative information exchange
- Transaction traceability through TRN references
- Multiple healthcare participant identification
- Companion guide extensibility
- HIPAA-aligned electronic healthcare messaging
Business Use Cases
Business Use Case | Description | Primary Stakeholders |
Prior Authorization | Request approval before healthcare services are rendered | Providers, Health Plans |
Utilization Review | Evaluate the medical necessity of requested services | Providers, Payers |
Certification | Approve or certify healthcare services | Health Plans, Utilization Management Organizations |
Admission Review | Review inpatient admissions | Hospitals, Payers |
Referral Review | Authorize specialty care referrals | Providers, Health Plans |
Home Health Review | Evaluate home healthcare services | Home Health Agencies, Payers |
Medical Services Reservation | Coordinate scheduled healthcare services | Providers, Health Plans |
Review Outcome Reporting | Communicate approval, pending, denial, or modification decisions | All Trading Partners |
Industry Applications
The EDI 278 supports numerous healthcare business processes across both public and private healthcare organizations.
- Commercial Health Insurance
- Government Healthcare Programs
- Managed Care
- Utilization Management
- Hospital Administration
- Physician Practices
- Home Health Services
- Specialty Care
- Case Management
- Care Coordination
Operational Visibility
The EDI 278 improves operational visibility by integrating healthcare services review into automated workflows. Organizations gain visibility into:
- Authorization request status
- Pending certifications
- Review decisions
- Outstanding healthcare reviews
- Transaction processing exceptions
- Workflow bottlenecks
- Companion guide compliance
- Transaction acknowledgments
Compliance Reporting 
Healthcare organizations use the EDI 278 to support standardized electronic healthcare services review while maintaining auditability throughout the authorization process. The transaction supports:
- HIPAA Administrative Simplification
- HIPAA Privacy Rule
- HIPAA Security Rule
- CMS implementation guidance where applicable
- Health plan companion guide compliance
- Internal healthcare audit requirements
Financial Reconciliation
Although the EDI 278 does not exchange payment information, authorization and certification decisions frequently determine whether healthcare services proceed to claim submission and reimbursement. Timely processing of healthcare services reviews helps reduce treatment delays, minimize claim denials, and improve revenue cycle performance.
Healthcare Workflow Coordination
The EDI 278 coordinates healthcare services review by standardizing the exchange of authorization requests, certification decisions, clinical review information, and supporting administrative data. Integrating these activities into automated workflows enables providers, payers, and utilization management organizations to improve collaboration, reduce manual processing, and accelerate healthcare decision-making.
Exception Management
The EDI 278 supports proactive exception management by identifying incomplete or non-compliant healthcare services review requests before they delay patient care or downstream claims processing.
Exception | Operational Response |
Missing clinical information | Request additional review documentation |
Incomplete authorization request | Correct and resubmit the EDI 278 |
Invalid patient or provider identifiers | Validate identifiers before processing |
Missing certification details | Update and retransmit the transaction |
Companion guide validation failure | Correct implementation-specific requirements and resubmit |
What Information Is Required in the EDI 278?
The EDI 278 Health Care Services Review Information transaction contains the clinical, administrative, and participant information required to request, evaluate, certify, and communicate healthcare services review activities. The transaction organizes healthcare services review information using a hierarchical structure that identifies the information source, information receiver, subscriber, and healthcare services while exchanging the data necessary to support review, certification, notification, and reporting of healthcare services review outcomes.
Quick Segment Reference
The EDI 278 uses a structured hierarchy of heading, detail, and participant loops to organize healthcare services review information. Core segments identify the transaction, establish participant relationships, communicate healthcare services review requests, exchange supporting clinical information, identify participating organizations, and report review outcomes.
Required Segments
The EDI 278 requires core transaction segments that identify the transaction, establish the hierarchical structure, define the healthcare services review request, identify participating healthcare entities, and complete the transaction. Additional segments communicate healthcare services review information, reference numbers, dates, diagnosis information, service details, provider information, and review outcomes as required by the implementation guide.
Summary Table of Key Segments
Segment | Primary Purpose |
ST | Begins the transaction and establishes the transaction control number |
BHT | Identifies the business purpose, transaction type, reference number, date, and time |
HL | Defines the hierarchical relationship between healthcare participants |
TRN | Provides unique transaction traceability |
UM | Identifies the healthcare services review request and certification information |
HCR | Communicates the healthcare services review outcome |
REF | Carries reference identifiers associated with the review |
DTP | Specifies service, review, and processing dates |
HI | Communicates diagnosis and healthcare information codes |
SV1 | Identifies professional healthcare services |
SV2 | Identifies institutional healthcare services |
HSD | Describes healthcare service delivery information |
CRC | Communicates clinical condition indicators |
CL1 | Identifies claim-related information |
CR1 | Provides ambulance certification information when applicable |
CR6 | Provides home health certification information when applicable |
PWK | References supporting documentation |
NM1 | Identifies healthcare organizations and individuals |
N3 | Provides address information |
N4 | Provides geographic location information |
PER | Identifies administrative contacts |
PRV | Identifies provider specialty and classification |
DMG | Provides demographic information |
SE | Ends the transaction and validates segment counts |
Optional Segments
Optional segments provide additional healthcare review, provider, patient, demographic, certification, and supporting documentation information when required by a trading partner or companion guide. Although optional within the base ANSI ASC X12 standard, these segments are frequently used to support healthcare services review workflows and trading partner-specific business requirements.
Required Identifiers
The EDI 278 uses identifiers to uniquely associate healthcare services review requests with the appropriate transaction, participants, and healthcare services. Common identifiers include transaction control numbers, trace numbers, reference identifiers, subscriber information, provider identifiers, and organization identifiers exchanged throughout the hierarchical transaction structure.
Required Dates
The EDI 278 uses DTP segments to communicate dates associated with healthcare services review activities, including transaction, review, and service dates as required by the applicable implementation guide and business process.
Required Healthcare Services Review Information
Healthcare services review information exchanged within the EDI 278 commonly includes:
- Request category
- Certification type
- Service type
- Facility or place of service
- Level of service
- Release of information status
- Healthcare services review outcome
- Reference information
- Diagnosis information
- Professional or institutional service information
- Healthcare service delivery information
- Clinical condition indicators
- Claim information
- Supporting documentation references
Service-Level Detail
The EDI 278 supports both professional and institutional healthcare services. Service-level information may include diagnosis codes, professional services (SV1), institutional services (SV2), healthcare service delivery information (HSD), clinical condition indicators (CRC), claim information (CL1), ambulance certifications (CR1), home health care certifications (CR6), and supporting documentation references (PWK).
What Status and Reason Codes Are Used with the EDI 278?
The EDI 278 communicates healthcare services review requests and review outcomes rather than claim adjudication status. Processing decisions are conveyed through healthcare services review information, certification details, action codes, transaction purpose codes, and implementation-specific business rules defined by trading partner companion guides.
Status Codes
The EDI 278 uses standardized ANSI ASC X12 code values to identify the purpose of the transaction, the type of healthcare services review request, and the outcome of the review. The PartnerLinQ implementation guide specifically identifies status-related values within the BHT, UM, and HCR segments.
Segment | Code | Meaning |
BHT02 | 13 | Request |
BHT02 | 11 | Response |
BHT06 | 18 | Response – No Further Updates to Follow |
BHT06 | 19 | Response – Further Updates to Follow |
BHT06 | RU | Medical Services Reservation |
HCR01 | A1 | Certified in Total |
HCR01 | A4 | Pended |
HCR01 | A6 | Modified |
Reason Codes
The PartnerLinQ EDI 278 specification does not publish a standalone table of standardized reason codes. Instead, the HCR segment allows the sender to communicate an industry code identifying the reason for the healthcare services review outcome associated with the action code. The implementation guide notes that this value is assigned by the information source and references the applicable industry code list.
Industry-Specific Code Sets
The PartnerLinQ implementation guide identifies several standardized code sets used throughout the EDI 278 to classify healthcare services review requests and outcomes. These code values are exchanged within specific transaction segments rather than through a single consolidated code list.
Segment | Purpose | Example Codes |
BHT02 | Transaction Set Purpose | Request, Response |
BHT06 | Transaction Type | Medical Services Reservation, Response Types |
UM01 | Request Category | Admission Review, Health Services Review, Individual, Specialty Care Review |
UM02 | Certification Type | Initial |
UM03 | Service Type | Medical Care, Surgical, Consultation, Medically Related Transportation, Psychiatric |
UM04 | Facility / Place of Service | Place of Service Codes |
UM06 | Level of Service | Emergency |
UM09 | Release of Information | Provider Has Signed Authorization |
HCR01 | Review Action | Certified, Pended, Modified |
What Are the Benefits of the EDI 278?
The EDI 278 improves healthcare services review by standardizing the electronic exchange of review requests, certifications, notifications, and review outcomes between providers, payers, and utilization management organizations. The transaction enables organizations to exchange clinical, administrative, subscriber, patient, diagnosis, treatment, and service information while supporting automated healthcare workflow orchestration and transaction visibility.
Operational Benefits
The EDI 278 streamlines healthcare services review by electronically submitting review requests, receiving certification decisions, routing transactions between trading partners, validating required healthcare information, and tracking requests through unique transaction references and trace numbers. These capabilities improve the efficiency and consistency of healthcare services review workflows.
Financial Benefits
The specification does not identify specific financial or cost-saving benefits for the EDI 278. Instead, it focuses on supporting healthcare services review, certification, authorization, and transaction processing through standardized electronic data exchange.
Compliance Benefits
The EDI 278 provides a standardized ANSI ASC X12 transaction for exchanging healthcare services review information. Standardized transaction structures, validated healthcare data, and consistent routing between trading partners support reliable implementation of healthcare services review processes in accordance with established implementation guidelines.
What are the Benefits of Automating the EDI 278?
Automating the EDI 278 enables healthcare organizations to electronically submit healthcare services review requests, receive certification decisions, exchange clinical and administrative information, validate required healthcare data, and route transactions between trading partners using a standardized ANSI ASC X12 transaction. Automation also improves transaction traceability through unique references and supports healthcare workflow orchestration and transaction visibility.
Automation supports organizations by:
- Submitting prior authorization requests electronically
- Receiving certification and review decisions
- Routing review requests and responses between trading partners
- Validating required healthcare data before processing
- Tracking transactions through unique trace numbers
- Supporting automated healthcare workflow orchestration
- Improving transaction visibility throughout the review process
Are there Regulatory and Compliance Requirements for the EDI 278?
The PartnerLinQ EDI 278 specification does not define regulatory or compliance requirements for the transaction. Instead, it identifies the EDI 278 as an ANSI ASC X12 Health Care Services Review Information transaction used to exchange healthcare services review information within an Electronic Data Interchange (EDI) environment and references implementation guidance developed for trading partner onboarding and technical development.
Which Requirements Govern an EDI 278 Implementation?
EDI 278 implementations can involve several authority layers: HIPAA Administrative Simplification requirements, the adopted X12 implementation specification, CMS program requirements, payer companion guides, and trading-partner business rules. Organizations should distinguish regulatory requirements from X12 syntax requirements and payer-specific implementation requirements when designing and validating EDI 278 workflows.
EDI 278 Technical Structure, Format, and Versions
The EDI 278 uses HL loops to establish dependencies among hierarchically related healthcare information. PartnerLinQ uses HL03 codes to identify the Information Source, Information Receiver, Subscriber, Event, and Services levels, allowing receiving systems to interpret relationships between the healthcare entities and services represented within the transaction.
Hierarchical Loop Structure
HL03 Code | Hierarchical Level | Purpose |
20 | Information Source | Identifies the payer, maintainer, or source of the information |
21 | Information Receiver | Identifies the provider or other recipient of the information |
22 | Subscriber | Identifies the covered subscriber |
EV | Event | Identifies the healthcare event level |
SS | Services | Identifies the healthcare services level |
What Delimiters Are Used?
The EDI 278 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 (>)
What Version of the EDI 278 Is Used for HIPAA Transactions?
HIPAA electronic referral certification and authorization transactions use the adopted X12 278 implementation specifications. Version 5010 implementations distinguish healthcare services review request/response processing from acknowledgment requirements, while individual payers may further define usage through companion guides. Implementers should validate the required implementation convention before exchanging production transactions.
What Are the Limitations of the EDI 278?
The EDI 278 standardizes healthcare services review and prior authorization exchanges, but it does not standardize every payer's authorization policy, or documentation requirement, its medical-necessity rule, or workflows. Implementations therefore depend on the applicable X12 implementation guides, payer companion guides, supported services, business rules, and trading-partner requirements. While the EDI 278 does go a long way in terms of presenting documents as evidence and is effectively HIPAA endorsed by way of enforcement reasoning, it is by no means a panacea. Companies will have to find their own way to success and it will take time.
Version or Companion Guide Constraints
EDI 278 implementations must conform to the applicable X12 implementation convention and trading-partner requirements. Payer companion guides may further define supported authorization scenarios, required identifiers, segment usage, code values, validation rules, response expectations, testing procedures, and other requirements necessary for production exchange.
Jurisdiction-Specific Requirements
EDI 278 specifications do not define jurisdiction-specific requirements for healthcare services review transactions. The specification is designed for technical development, trading partner onboarding, and implementation rather than complete regulatory or compliance guidance. Organizations should therefore validate jurisdiction-specific requirements against the applicable trading partner, payer, or governing implementation guidance.
Timing and Frequency Limitations
The EDI 278 specification does not establish specific timing or transmission-frequency limitations. The transaction supports requests and responses for healthcare services review, including admission, emergency admission, referral, home health care, medical services reservation, and non-emergency transportation workflows. Timing and frequency requirements should therefore be determined by the applicable business process and trading partner implementation requirements.
Are Implementation Guidelines and Sample Files Available for the EDI 278?
Yes. EDI 278 implementation guidance is available through applicable X12 implementation specifications, payer companion guides, and trading-partner documentation. These resources define transaction structure, segment usage, identifiers, code values, validation requirements, authorization scenarios, testing procedures, and request-and-response requirements.
Companion Guides
EDI 278 companion guides supplement the X12 implementation guide with payer- or program-specific requirements. They may define required segments and data elements, supported authorization scenarios, identifiers, code values, validation rules, submission procedures, testing requirements, and response expectations. Implementers should validate each trading partner's companion guide before production 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 278 Example File (X12 Sample)
ST*278*0001*005010X217~
BHT*0007*13*278000001*20260811*1345~
HL*1**20*1~
NM1*X3*2*HEALTH PLAN*****PI*842610001~
HL*2*1*21*1~
NM1*1P*2*SAMPLE MEDICAL CENTER*****MI*1234567890~
HL*3*2*22*1~
TRN*1*278000001*8426100010~
NM1*IL*1*DOE*JANE****MI*ABC123456789~
DMG*D8*19800115*F~
HL*4*3*EV*1~
UM*HS*I**12:B*****Y~
DTP*472*D8*20260820~
HI*BF:1831*BF:2630~
HL*5*4*SS*0~
SV1*HC:275~
SE*17*0001~
Annotated Example
| Segment | Example | Interpretation |
|---|---|---|
| ST | ST*278*0001*005010X217~ | ST01 identifies the transaction as an EDI 278 Health Care Services Review Information transaction. ST02 provides the sender-assigned control number, while ST03 identifies the implementation convention used to interpret and validate the transaction. |
| BHT | BHT*0007*13*278000001*20260811*1345~ | The BHT establishes the transaction's identity, hierarchical structure, business purpose, reference, date, and processing intent. BHT02 distinguishes a request (13) from a response (11), while BHT03 provides the originating application's transaction reference. |
| HL | HL*1**20*1~ | Establishes the Information Source level. 20 identifies the payer, maintainer, or source of the information. |
| NM1 | NM1*X3*2*HEALTH PLAN*****PI*842610001~ | Identifies the organization acting as the information source within this illustrative transaction. |
| HL | HL*2*1*21*1~ | Establishes the Information Receiver level subordinate to HL 1. 21 identifies the provider or other recipient of the information. |
| NM1 | NM1*1P*2*SAMPLE MEDICAL CENTER*****MI*1234567890~ | Identifies the healthcare provider participating in the review workflow. |
| HL | HL*3*2*22*1~ | Establishes the Subscriber level subordinate to the Information Receiver. 22 identifies the covered subscriber. |
| TRN | TRN*1*278000001*8426100010~ | Assigns a trace reference to the transaction. 1 identifies a current transaction trace number; TRN02 provides the unique transaction identification. |
| NM1 | NM1*IL*1*DOE*JANE****MI*ABC123456789~ | Identifies the subscriber represented within the hierarchical transaction. |
| DMG | DMG*D8*19800115*F~ | Communicates demographic information associated with the identified individual. |
| HL | HL*4*3*EV*1~ | Establishes the Event level subordinate to the subscriber. EV identifies the healthcare event being reviewed. |
| UM | UM*HS*I**12:B*****Y~ | Communicates the healthcare services review information. HS identifies Health Services Review, I identifies Initial certification, and 1 identifies Medical Care. The segment can also communicate facility/place of service, level of service, and release-of-information status. |
| DTP | DTP*472*D8*20260820~ | Communicates a date associated with the healthcare service or review. The PDF defines DTP as the segment used to specify a date, time, or period. |
| HI | HI*BF:1831*BF:2630~ | Supplies healthcare information codes, such as diagnosis information, supporting the healthcare services review. |
| HL | HL*5*4*SS*0~ | Establishes the Services level subordinate to the Event. SS identifies healthcare services; 0 indicates that no additional subordinate HL level follows. |
| SV1 | SV1*HC:275~ | Identifies the professional healthcare service associated with the review request. |
| SE | SE*17*0001~ | Ends the transaction set. The control number corresponds to ST02 and the segment count represents the segments contained from ST through SE. |
What Information Does the EDI 278 AAA Segment Contain?
The EDI 278 AAA segment communicates whether a request validation condition exists, the reason the transaction or request failed validation, and the follow-up action required. **AAA03 carries the Reject Reason Code, while AAA04 communicates actions such as correcting and resubmitting the request.
What is the difference between the two samples?
Placement of the AAA Request Validation after the subscriber NM1 makes the rejection read as a patient-specific issue in Sample 1. Where the placement of the AAA Request Validation after the subscriber HL Segment in Sample 2 makes the rejection read as a subscriber specific issue.
What Are the More Common EDI Errors and Rejection Scenarios for the EDI 278?
The EDI 278 may be rejected when required application data is missing, incorrect, structurally invalid, or inconsistent with the healthcare services review being requested.
Common EDI 278 Errors
Error Scenario | Common Cause | Potential Result |
Missing required segments | ST, BHT, HL, NM1, or SE information is absent where required | Transaction cannot be processed |
Invalid hierarchical structure | HL01/HL02 relationships do not correctly identify parent and subordinate loops | Participant or service relationships cannot be interpreted |
Invalid transaction purpose | BHT contains an unsupported or incorrect purpose/type value | Request may be rejected or incorrectly processed |
Missing or invalid trace information | TRN01/TRN02 is missing or incorrectly populated when used | Request cannot be reliably tracked or reconciled |
Unsupported review category | UM01 contains a request category not supported by the receiver | Healthcare services review may be rejected |
Invalid certification information | UM certification or service information conflicts with the review request | Request may fail business validation |
Missing healthcare service information | Required service or procedure information is incomplete | Authorization review cannot be completed |
Invalid diagnosis information | HI contains missing, invalid, or inappropriate healthcare information codes | Clinical review may fail |
Invalid participant information | NM1 or related identification information is incomplete or invalid | Provider, subscriber, payer, or other participant cannot be identified |
Invalid service delivery information | HSD values violate required element relationships | Transaction may fail syntax or business validation |
Missing conditional data | A conditionally required element is omitted when its paired element is present | Transaction may fail X12 validation |
Control number mismatch | ST/SE transaction control information does not reconcile | Transaction fails structural validation |
Generally speaking, specifications provide explicit syntax dependencies for individual segments. The Health Care Services
Delivery segment (HSD) may require the HSD01 and HSD02 together, in other words, If either HSD01 or HSD02 is present, then the other is required. The HSD05 and HSD06 act in the same way. Violating relationships such as these creates an invalid segment that cannot be processed.
Hierarchical Loop Errors
HL errors are particularly important as the EDI 278 relies on hierarchical relationships to organize healthcare participants, events, and services. HL01 must uniquely identify each HL occurrence, HL02 identifies the parent HL, HL03 defines the context of the information that follows, and HL04 indicates whether subordinate levels exist. Incorrect relationships can prevent the receiving system from determining which patient, event, or service the review information belongs to.
Healthcare Services Review Errors
The UM segment is a common point for business-rule validation because it communicates the information needed to initiate or evaluate the healthcare services review. Errors can result from unsupported request categories, incorrect certification information, invalid service types, or other values inconsistent with the receiver's implementation requirements.
The PartnerLinQ specification supports UM01 request categories including:
- AR — Admission Review
- HS — Health Services Review
- IN — Individual
- SC — Specialty Care Review
A request containing an unsupported review category may therefore fail the receiving organization's business validation.
Rejection Responses
The EDI 278 does not provide a consolidated EDI 278 rejection-code table, instead it defines the segments, code values, syntax relationships, and business information against which the transaction can be validated.
The underlying X12 005010X217 implementation guidance goes further and confirms that missing or incorrect application data can cause rejection and that a rejected 278 request is returned as a 278 response containing a AAA Request Validation segment at the appropriate hierarchical level to explain the rejection.
Common Corrective Actions
Organizations can reduce EDI 278 rejection scenarios by validating:
- Required and conditionally required segments
- HL parent-child relationships
- Transaction control numbers
- TRN trace information
- UM request and certification values
- Subscriber and provider identifiers
- Diagnosis and service information
- Segment syntax dependencies
- Trading partner-supported code values
- Companion guide business rules
PartnerLinQ applies these and other validations before routing the transaction, thus helping identify structural, data, and business-rule exceptions before an EDI 278 enters the downstream healthcare services review workflow and if required can be configured to overcome (accept, alert, modify, and track) business-rule exceptions to ensure downstream compliance and business continuity.
How are EDI 278 rejections communicated?
When an EDI 278 prior authorization request fails validation, the payer returns an EDI 278 Response containing a AAA (Request Validation) segment at the appropriate Hierarchical Level (HL). The AAA segment carries specific X12 error reason codes explaining missing data, invalid patient eligibility, or unlisted service codes.
AAA*Y**67*C~
│ │ │ └─ AAA04: Follow-up Action Code ("C" = Please Correct and Resubmit)
│ │ └──── AAA03: Reject Reason Code ("67" = Patient not Found)
│ └────── AAA02: (Not Used in 5010 278)
└──────── AAA01: Valid Request / Response Code ("Y" = Yes, error detected)
What Does “Correct and Resubmit” Mean in an EDI 278 AAA Segment?
When AAA04 contains ‘C’, the requester should correct the data responsible for the validation error and resubmit the healthcare services review request. X12 distinguishes this from a general resubmission request, which asks for the original request to be submitted again rather than specifically correcting erroneous data.
What are the Basic Questions for EDI Integration with the 278?
- Are there Samples and Specs available?
- Are there samples and specs of the response transaction available?
- What is the general direction of the transaction?
- Are AS2, VAN, or SFTP connections used?
- Which X12 278 implementation convention applies?
- What trading partner requirements apply?
- What version is required?
- What versions are supported?
- Will the architecture support X12 278, FHIR Prior Authorization APIs, or both?
- Which payer companion guides must be supported?
- Will the organization send requests, receive responses, or both?
- What system generates the response?
- What response time is required?
- What validation rules apply?
- Which prior authorization and healthcare services review scenarios are required?
- Which provider, subscriber, payer, and trace identifiers are required?
- Which UM, HCR, AAA, HI, SV1/SV2, HSD, and DTP rules must be validated?
- How are supporting clinical documents referenced or exchanged?
- Which acknowledgment and application-error transactions are required?
- How are pending, modified, rejected, and certified requests managed?
- What authorization response-time requirements apply?
- How will eligibility, authorization, clinical documentation, and downstream claims be correlated?
- Is there automation? (an internal system trigger) or are 278 business message transactions triggered manually?
- How is automation managed (manual vs. system-triggered)?
What are the Best Practices for using the 278?
The best practices for using the EDI 278 center on maintaining a valid transaction structure, accurate hierarchical relationships, complete healthcare review information, reliable transaction traceability, and compliance with trading partner implementation guidance. Emphasis therefore should be placed on the correct use of the BHT, HL, TRN, UM, HCR, participant, service, and supporting clinical segments throughout healthcare services review processing.
Use the Correct Hierarchical Structure
The EDI 278 relies on HL loops to organize the Information Source, Information Receiver, Subscriber, Event, and Services levels. HL01 should uniquely identify each level, HL02 should correctly identify the parent level, HL03 should define the proper hierarchy type, and HL04 should accurately indicate whether subordinate levels follow and so on. Mapping should follow a standardized data structure regardless of input type, limiting risk and exposure.
Maintain Reliable Transaction Traceability
Trace (TRN) values should be populated consistently so healthcare services review requests and related responses can be tracked and reconciled. Using the TRN02 as the unique transaction identification and the TRN03 to identify the originating organization when used, helps.
Validate Healthcare Review Information
Health Care Services Review Information (UM) information should accurately represent the healthcare services review being requested or evaluated. Request category, certification type, service type, facility information, level of service, and release-of-information values should conform to the supported implementation requirements.
Communicate Review Outcomes Consistently
Health Care Services Review (HCR) information should accurately communicate the outcome of the healthcare services review. Partner specifications lend support to the review process.
Preserve Supporting Clinical and Service Information
Supporting segments should be included when required by the review scenario. Diagnosis information, professional or institutional services, service delivery patterns, clinical conditions, claim information, ambulance certification, home health certification, and supporting documentation references should remain associated with the appropriate HL level.
Follow Segment Syntax Rules
Conditional element relationships should be validated before transmission. The specification documents segment-level syntax requirements, such as paired Health Care Services Delivery (HSD) elements and conditional Home Health Care Certification (CR6) elements, that must be satisfied when those data are present.
Validate Participant Information
Individual and/or Organization Names (NM1) and related segments should accurately identify providers, facilities, subscribers, utilization management organizations, and other healthcare participants. Associated identifiers, addresses, contacts, provider information, and demographic information should be validated before processing, which might mean accessing, creating, and or validating (NM1) source data.
Pay attention to Implementation Requirements
Partner specifications are intended to support technical development and trading partner onboarding rather than provide complete compliance guidance. Implementations should therefore validate transaction requirements against the applicable specification and trading partner implementation guidance before production documents are exchanged.
What Transactions are associated with the 278?
The EDI 278 operates within a broader healthcare transaction workflow rather than as an isolated exchange which makes the 278 the healthcare services review transaction within the broader Health Care Eligibility and Benefit lifecycle.
EDI Transaction | Transaction Name | Relationship to the EDI 278 |
270 | Health Care Eligibility Benefit Inquiry | Eligibility may be verified before healthcare services are reviewed or authorization is requested. |
271 | Health Care Eligibility Benefit Response | Coverage and benefit information can support the decision to initiate an EDI 278 review request. |
275 | Patient Information / Health Care Claim Attachment | Supporting clinical documentation may accompany healthcare authorization and services review processes. |
277 | Health Care Claim Status Notification | Provides healthcare status information associated with downstream claim processing. |
824 | Application Advice | While not a replacement for the EDI 278 Response it can be used to supplement EDI 278 processing by communicating application-level acceptance, rejection, or data-content errors when supported by the trading partner. |
837 | Health Care Claim | Authorized or reviewed healthcare services may subsequently be submitted for claim processing. |
835 | Health Care Claim Payment/Advice | Communicates payment and remittance information following downstream claim adjudication. |
997 | Functional Acknowledgment | May acknowledge receipt and syntactical acceptance of an X12 functional group. |
999 | Implementation Acknowledgment | Communicates implementation-level acceptance or rejection of an X12 transaction. |
Frequently Asked Questions (FAQs)
What is an EDI 278 prior authorization transaction?
An EDI 278 is the X12 healthcare transaction used to electronically exchange healthcare services review information, including prior authorization, certification, referral, admission review, and utilization review requests and responses. It enables providers and health plans to exchange structured clinical and administrative information before or during healthcare delivery.
Does an EDI 278 request receive an EDI 278 response?
Yes. The EDI 278 supports both healthcare services review requests and responses. A provider can submit review or authorization information and the payer can return a 278 response communicating the review outcome, such as certification, modification, pending status, or other applicable authorization information.
What Is the AAA Segment in an EDI 278?
The AAA Request Validation segment communicates validation errors in an EDI 278 response. When a healthcare services review request cannot be processed because required or valid application data is missing or incorrect, the AAA segment identifies the rejection reason and the authorized follow-up action at the appropriate hierarchical level.
What is the difference between EDI 278 and EDI 275?
EDI 278 manages healthcare services review, referral certification, and prior authorization workflows. EDI 275 is used to exchange supporting patient information or healthcare attachments. The transactions can complement one another when an authorization workflow requires supporting clinical documentation, but they perform different business functions.
What is the difference between EDI 278 and EDI 270/271? 
EDI 270 and 271 determine healthcare eligibility and benefit information, while EDI 278 supports healthcare services review and prior authorization. Eligibility is commonly verified before authorization, making 270 → 271 → 278 a logical transaction sequence within an electronic healthcare workflow.
What information is included in an EDI 278?
An EDI 278 can contain subscriber and patient identifiers, provider information, diagnosis information, requested healthcare services, certification details, service dates, review categories, trace identifiers, clinical indicators, and authorization outcomes. Exact requirements depend on the applicable X12 implementation guide and trading-partner companion guide.
What is the AAA segment in an EDI 278?
The AAA Request Validation segment communicates request validation problems at the applicable hierarchical level of an EDI 278 response. It can identify rejection conditions and follow-up actions when information such as eligibility, identifiers, or requested services prevents the transaction from being processed successfully.
What Does the AAA Segment Mean in an EDI 278 Response?
The AAA segment indicates that an EDI 278 request encountered a validation condition requiring a response. The AAA03 identifies the reject reason code, while AAA04 identifies the follow-up action expected from the requester. The segment can occur at the appropriate hierarchical level to associate the rejection with the affected portion of the request.
Where Does the AAA Segment Appear in an EDI 278?
The AAA segment appears at the hierarchical level where the validation problem applies. X12 allows a rejected EDI 278 response to return AAA at the appropriate level. For example, AAA at Loop 2000A can indicate a problem affecting the information source or routing of the request rather than a lower-level patient or service condition.
Does FHIR Replace the EDI 278?
No, not universally the X12 278 remains as the HIPAA-adopted transaction for electronic referral certification and authorization. HHS currently exercises discretionary enforcement for covered entities using qualifying FHIR-based Prior Authorization APIs. CMS also states that X12 278 alone cannot satisfy every CMS-0057-F (Prior Authorization API requirement).
Can X12 278 and FHIR work together?
Yes the X12 278 and FHIR can work together. Prior authorization architectures can combine FHIR-based provider-facing workflows with X12 278 processing. While organizations must still satisfy CMS API, HIPAA, and trading-partner requirements, modern architectural models with advanced technologies behind the firewall are finding success with canonical data modelling, semantic data models, and purpose build high performance architectures.
Can an EDI 824 Be Used with an EDI 278? 
Yes. The EDI 824 Application Advice can supplement EDI 278 processing by communicating application-level acceptance, rejection, or data-content errors when supported by the trading partner. The 824 does not replace the EDI 278 Response, which communicates the healthcare services review or prior authorization decision.
Is EDI 278 still required under HIPAA?
Yes, the X12 278 remains the adopted HIPAA standard; it has not been repealed or replaced outright by FHIR, an important distinction. While HIPAA-covered entities are still generally required to use the currently adopted X12 278 transaction standard when conducting electronic referral certification and prior authorization transactions, HHS is exercising enforcement discretion for HIPAA-covered entities that implement qualifying FHIR-based Prior Authorization APIs under the CMS Interoperability and Prior Authorization Final Rule.
Related Resources
Explore Our Integration Solutions
PartnerLinQ Integration Solutions
Connect Everything. Integrate Intelligently.
Future-Proof Your Business with Composable, AI Powered Connectivity.