Back to Pilotfish Home

EDI 278 Format Example

EDI 278 Healthcare Services Review – Request for Review

What is the EDI 278 Transaction Set?

The EDI 278 Healthcare Services Review Information transaction set and format have been specified by HIPAA 5010 standards for the electronic exchange for transmission of claims status review information. Users of this transaction set include payors, plan sponsors, providers, utilization management, and other entities involved in healthcare services review. The EDI 278 transaction set and format can be a one-way transaction or a two-way “inquiry/response” transaction.  It can be used to transmit healthcare service information, such as subscriber, patient, demographic, diagnosis or treatment data for the purpose of a request for review, certification, notification, or reporting the outcome of a healthcare services review.

Note that a single EDI 278 is commonly used for one patient and one patient event. This is in contrast to other EDI HIPAA 5010 healthcare transactions where multiple plan subscribers or patients may be processed.

The EDI 278 A1 transaction set can be used to transmit healthcare service information, such as subscriber, patient, demographic, diagnosis or treatment data.  The purpose of the transaction can be a request for review, certification, notification or reporting the outcome of a healthcare services review.

EDI 278 A1 Transaction Loaded Into Claims Processing Software

EDI 278 Services Review Request in Data Mapper
(Click to enlarge)

EDI 278 A1 may relate to services to be administered by the healthcare service provider, or for referring an individual to another provider. A single 278 is commonly used for one patient and one patient event. The Healthcare Services Review document was chosen by HIPAA as the standard format for EDI transmission of authorizations and referrals. This is an important issue of patient privacy, as 278 documents typically contain healthcare-related data, such as patient, diagnosis or treatment information.


EDI 278 Frequently Asked Questions


The PilotFish integration platform seamlessly supports the EDI 278 transaction by enabling users to connect various healthcare systems and data formats. Our platform simplifies the mapping, validation and routing of EDI 278 messages, ensuring accurate and timely exchanges between providers and payers. Check out our X12 EDI case studies showcasing successful integrations.


Yes, the PilotFish integration platform can automate EDI 278 transactions by implementing predefined workflows that manage the submission and processing of service requests. Automation features include scheduled transmissions, error handling, and notification systems, which enhance efficiency and reduce manual intervention.


Yes, PilotFish supports integration with various third-party applications, allowing users to connect EDI 278 transactions with CRM systems, analytics tools, and other healthcare applications. This integration fosters a more cohesive ecosystem, enhancing data flow and operational efficiency.


PilotFish includes comprehensive error handling capabilities for EDI 278 transactions. When errors are detected, the platform provides detailed logs and alerts, allowing users to quickly identify and rectify issues. This proactive approach minimizes disruptions in the authorization process and enhances overall reliability.


The EDI 278 transaction enhances interoperability by standardizing the format for service requests across different healthcare IT systems. PilotFish facilitates this interoperability by connecting disparate systems, allowing seamless data exchange between electronic health records (EHRs), billing systems and payer platforms. This capability reduces integration challenges and promotes efficient workflows.


Pharmacies use the EDI 278 for eligibility verification to check if medications are covered, for refill authorizations to request approvals for prescription refills and for billing to facilitate claims submission. This transaction works alongside the NCPDP D.0 transaction.


Check out our EDI FAQ pages for more.


 

EDI 278 A1 Format Example

Referral – Request for Review

ASC X12 Version: 005010 | Transaction Set: 278 | TR3 ID: 005010X217

The following example represents the Request for Review (Specialty Care Referral) from Dr. Gardener to Maryland Capital Insurance.

Transmission Explanation

Table 1

ST*278*0001*005010X217~Begin transaction set 278, control #0001, and implementation convention reference is 005010X217.
BHT*0007*13*A12345*20050502*1101~This transaction is a request using hierarchical structure 0007 (information source, information receiver, subscriber, dependent, event, services). The originating system has assigned the Submitter Transaction Identifier “A12345″ along with the transaction set creation date and time.

 

Loop 2000A hierarchical level identifies the Insurance Company.

HL*1**20*1~HL count is 1. There is no higher, or parent, HL. This HL code is 20, identifying the information source or the insurance company. This HL has subordinate levels or children.
NM1*X3*2*MARYLAND CAPITAL INSURANCE COMPANY*****46*789312~The request for a referral is being made to Maryland Capital Insurance Company. Their electronic transmitter identification number is 789312.

 

Loop 2000B hierarchical level identifies the submitting provider.

HL*2*1*21*1~HL count is 2. This HL is subordinate to HL*1, the parent HL. This HL code is 21, identifying the information receiver or the referring provider. This HL has subordinate levels or children.
NM1*1P*1*GARDENER*JAMES****46*8189991234~The request is being made by James Gardener whose Electronic Transmitter Identification Number is 8189991234.

 

Loop 2000C hierarchical level identifies the subscriber, who in this case is also the patient.

HL*3*2*22*1~HL count is 3. This HL is subordinate to HL*2, the parent HL. This HL code is 22, identifying the subscriber. This HL has subordinate levels or children.
NM1*IL*1*SMITH*JOE****MI*12345678901~The patient’s name is Joe Smith; his Member Identification Number is 12345678901.

 

Loop 2000D hierarchical level identifies the dependent as a patient.

Because there is no dependent in this example, there is no Loop 2000D.

 

Loop 2000E hierarchical level identifies the patient event.

HL*4*3*EV*0~HL count is 4. This HL is subordinate to HL*3, the parent HL. This HL code is EV, identifying the patient event. This HL has no subordinate levels or children.
TRN*1*111099*9012345678~The provider assigned trace number 111099 to this service request. The requester has included the user-assigned identifier of 012345678 in this trace number.
UM*SC*I*3*11:B*****Y~Dr. Gardener is requesting an initial consultation for the patient.
HI*BF:41090:D8:20050430~The patient has been diagnosed with acute myocardial infarction; unspecified site.
HSD*VS*1~Dr. Gardener is requesting a single visit.
NM1*SJ*1*WATSON*SUSAN****34*987654321~The patient event provider is identified as Susan Watson. Her Social Security Number is 987654321.
PER*IC**TE*4029993456~Dr. Watson can be contacted by telephone at (402)999-3456.
SE*16*0001~Number of segments, control number.

 

Source

Accredited Standards Committee X12. ASC X12 Standard [Table Data]. Data Interchange Standards Association, Inc., McLean, VA. ASC X12 Examples

X12, chartered by the American National Standards Institute for more than 35 years, develops and maintains EDI standards and XML schemas.

This is a unique website which will require a more modern browser to work! Please upgrade today!