Free EDI Training Guide
Careers | Contact | About | Home
 
Amosoft EDI Services Call (800) 761-4269 Login
hipaa-edi-banner.jpg
EDI for the Health Insurance (HIPAA)
The Health Insurance Portability and Accountability Act (HIPAA) was enacted by the U.S. Congress in 1996. According to the Centers for Medicare and Medicaid Services (CMS) website, Title I of HIPAA protects health insurance coverage for workers and their families when they change or lose their jobs. Title II of HIPAA, known as the Administrative Simplification (AS) provisions, requires the establishment of national standards for electronic health care transactions and national identifiers for providers, health insurance plans, and employers.

The Administration Simplification provisions also address the security and privacy of health data. The standards are meant to improve the efficiency and effectiveness of the nation's health care system by encouraging the widespread use of electronic data interchange (EDI) in the U.S. health care system.

HIPAA covered entities such as providers completing electronic transactions, healthcare clearinghouses, and large health plans, must use only the National Provider Identifier (NPI) to identify covered healthcare providers in standard transactions by May 23, 2007. Small health plans must use only the NPI by May 23, 2008.

Amosoft provide everything you need to create and exchange HIPAA EDI documents with your Payer or Provider.
We give you the tools to communicate with your trading partners using secure communication methods such as AS2.
Our HIPAA EDI solution consists of full EDI integration with your ERP system.
Common Health Insurance (HIPAA) EDI transactions are listed here:

Healthcare Insurance Industry - HIPAA
HIPAA 270 Eligibility, Coverage or Benefit Inquiry
HIPAA 270 Eligibility, Coverage or Benefit Inquiry
Prior to HIPAA, providers of medical services submitted health care eligibility and benefits inquiries by a variety of methods, either on paper, by phone, or electronically.
The information requirements varied depending on
  • Type of insurance plan
  • Specific insurer's requirements
  • Type of service performed
  • Where the service is performed
  • Where the inquiry is initiated
  • Where the inquiry is sent
A provider uses the benefit inquiry transaction to ask about the benefits, deductibles, and co-pays of the patient�s health plan and if the patient is on file and currently is covered by the plan.
The inquiry can ask whether a specific benefit Is covered by the plan.
The transaction has the capability to inquire if a specific benefit will be covered for the patient on a given day, but the payer is not required to answer in this level of detail.
The response is conditional.
That is, it is not a guarantee of payment.

This transaction will be used by agents of all lines of insurance; Health, Life, Property and Casualty to inquire about the eligibility, coverage, and benefits accorded a prospective subscriber by a health benefit plan.
The inquiry is designed so the submitter can determine if a subscriber or dependent is enrolled in a health benefit plan and whether projected services for the subscriber or dependent are covered by the plan.

The Healthcare eligibility request is designed so that the inquiry submitter can determine
  • Whether an information source organization, for example, a payer, employer, or HMO has a particular subscriber or dependent on file
  • The healthcare eligibility and/or benefit information about that subscriber and/or dependents.
This transaction is used to inquire about a number of different general and specific eligibility, coverage, and benefit attributes or conditions, for example:
  • General Requests
    • Eligibility status, for example, active or not active in the plan
    • Maximum benefits
    • Exclusions
    • In-plan/out-of-plan benefits
    • C.O.B. information
    • Deductible
    • Co-pays
  • Specific Requests
    • Procedure coverage dates
    • Procedure coverage maximum amount allowed
    • Deductible amount
    • Remaining deductible amount
    • Co-insurance amount
    • Co-pay amount
    • Coverage limitation percentage
    • Patient responsibility amount
    • Non-covered amount
EDI-270 was designed to be flexible enough to encompass all the information requirements of various entities.
These entities include, but are not limited to
  • Insurance companies
  • HMO's
  • PPO's
  • Healthcare purchasers and employees
  • Professional Review Organizations
  • Social worker organizations
  • Healthcare providers, physicians, hospitals and laboratories
  • Third party administrators
  • Healthcare vendors, practice management vendors and billing services
  • Service bureaus
  • Governments agencies such as Medicare, Medicaid, and civilian Health and medical program of the uniformed services
Some submitters do not have ready access to all the information needed to generate an inquiry to a payer.
An outside lab or pharmacy that furnishes services to a healthcare provider might need to ask that provider which payer a healthcare eligibility inquiry or benefit inquiry should be routed to.
In this scenario, an EDI 270 might originate from a provider and be sent to another provider if the receiving provider supports the inquiry.

This transaction is more flexible than most EDI X12 transactions, allowing a requestor to enter a very small amount of patient information to indentify them to a payer.
This approach is not without limitations, and the more information that you provide, the more likely the payer will find a match in their systems.
If the patient is the subscriber, the minimum information includes
  • Patient's member ID or the HIPAA unique patient identifier once mandated for use
  • Patient's first name
  • Patient's last name
  • Patient's date of birth
If the patient is a dependent of a subscriber, the minimum information includes
  • Subscriber�s member ID or the HIPAA unique identifier once mandated for use Patient�s first name
  • Patient�s last name
  • Patient�s date of birth
If a provider submits all four of the required elements, the payer source must generate a response if the patient is in their database.

In the absence of the required data elements, for example in an emergency situation or if the patient has forgotten to bring his insurance card, this transaction may be transmitted with as many of the required pieces of data that are available along with any of other items indentified in the transaction, for example a Social Security Number.
The payer should attempt to look up the patient when a reasonable number of data elements are submitted.
HIPAA 271 Eligibility, Coverage or Benefit Information
HIPAA 271 Eligibility, Coverage or Benefit Information
HIPAA EDI 271 is an Eligibility, Coverage, or Benefit Information
The eligibility or benefit reply information from the source organization, payer or employer is contained in 271 in an Eligibility or benefit information data segment.
The information source can also return other information about eligibility and benefits based on its business agreement with the inquiry submitter and available information that it might be able to provide.

The content of the eligibility, coverage and benefits information transaction set varies depending on the level of data information source organization makes available as well as the type request.

EDI 271 transaction is the reply vehicle for the EDI 270 transaction.
When a provider submits an eligibility, coverage, or benefit inquiry, the receiver will
  • Initiate the eligibility, coverage, or benefit information transaction form explaining the conditions of the health coverage pertaining the principal, subscriber or dependent.
  • Forward the request to the most appropriate next destination
The transaction form is designed to respond to general and specific requests.
General requests include information pertinent to eligibility status, policy limits, exclusions, benefits, deductibles, and co-pays.
Specific requests relate to issues such as procedure coverage dates, procedure coverage limits, and deductibles for procedures.
The details of these requests and replies will, in many cases, involve significant complexity, as intermediaries are used throughout the health care service industry.
HIPAA 276 Health Care Claim Status Request
HIPAA 276 Health Care Claim Status Request
HIPAA EDI 276 is Healthcare Claim Status Request
EDI 276 Transaction is used to inquire into the status of a claim.
It�s response tool is the EDI 277 Healthcare claim status response.
The form is usually submitted by healthcare service providing agencies such as hospitals, physicians, dentists, employers, billing agencies, and other agencies with vested interest in the progress of a chain.
EDI 276 transaction cannot be submitted unless it has been preceded by an 837 Healthcare Claim.

Thus, the 276 is used to request the current status of a specified claim.
The business partners affiliated with the EDI 276 transaction include:
  • Billing services
  • Consulting services
  • Vendors of systems
  • EDI network intermediaries such as automated clearinghouses, value-added networks, and telecommunications services.
Payers or certain intermediaries involved with processing any given claim need to track the claim�s current status through the adjudication process.
The purpose of submitting this transaction is to obtain the current status of the claim within the adjudication process.
An authorized entity can request status information at the claim and line level.
A valid healthcare claim status request includes data necessary for the payer to identify the specific claim in question.
The transaction trace number is an important key to match the response to a specific request transaction.

Supplying the primary, or unique, identifying elements should allow the requestor to obtain an exact match.
Conditions, through, are not always ideal; and when the requester does not know the unique elements, the claim should be located by supplying several parameters, including the provider number, patient identifier, dates of service, and submitted charges from original claim.

The following are sample primary elements:
  • Information source; the decision maker in the business transaction; for example, the payer
  • Information receiver who expects the response from the information source; for example a provider group, a clearinghouse, a service bureau, an employer, and so on
  • Service provider who delivered the healthcare service
  • Subscriber, known by the insurance carrier
  • Requested claims identification
HIPAA 277 Health Care Claim Status Notification
HIPAA 276 Health Care Claim Status Request
HIPAA EDI 277 is Healthcare Claim Status Response
EDI 277 transaction is being used in three ways:
  1. Reply to an EDI 276 Healthcare Claim Status Request
  2. Unsolicited notification of a healthcare claim status
  3. Request for additional information about a healthcare claim
Organizations sending an EDI 277 Healthcare Claim Status Response include payers such as:
  • Insurance companies
  • Third party Administration
  • Service corporations
  • State and federal agencies and their contractors
  • Plan purchasers
  • Any other entity that processes healthcare claims
Other business partners affiliated with the EDI 277 include
  • Billing services
  • Consulting services
  • Vendors of payments
  • EDI network intermediaries such as automated clearinghouse, values-added networks, and telecommunications services.
A provider uses the claim status inquiry to ask about the status of processing for a particular claim or claims that remain outstanding within its accounts receivable system.

EDI 277 response might include
  • Accepted or rejected claims
  • Claim pending, incorrect or incomplete claims, or suspended claims
  • Final: rejected claims
  • Final: denied claims
  • Final: approved claims pre-payment
  • Final: approved claims post-payment
Insurance companies, intermediaries, government agencies and auditors, or billing agents services usually submit the form.
The form is not to be used in place of EDI 835 Healthcare Claim Payment Advice transaction set and should not be used for posting of account payments.

The EDI Acknowledgement is usually performed by the ANSI 997 Functional Acknowledgement transaction.
This transaction is not a HIPAA standard. However, if commerce and efficiency are best served by using it, trading partners are free to do so.
The EDI 997 transaction set may not be used for a function otherwise supported by a standard transaction like the EDI 277
HIPAA 278 Health Care Services Review -- Request for Review
HIPAA 278 Health Care Services Review -- Request for Review
HIPAA EDI 278 is Healthcare Services Review: Request for Review
The Request for Review and the Response to that Request Transaction Set cover the following business events:
  • Admission certification review request and response
  • Referral review request and response
  • Health care services certification review request and response
  • Extend certification review request and response
Terms used in the services review transactions include
  • Long-term care
  • Patient event
  • Requester
  • Service provider
  • Utilization Management Organization
Review requests are submitted using the 278 EDI Healthcare Services Review:
"Request for Review".
Issues addressed by the EDI 278 differ from those for the EDI 276 in that the Request for Review triggers an audit of a healthcare encounter and the forms, certifications, and adjudication arising from it.
The requester is a provider who seeks authorization or certification for a patient to receive healthcare services.

Transaction EDI 278 can be used to send unsolicited information to trading partners.
This data can take form of health service review copies, or notification of the beginning or end of treatment.
This transaction should be routinely used in the following events: � Patient arrival notice � Patient discharge notice � Certification change notice � Notification of certification to primary providers, other providers, and Utilization Management Organization
EDI 278 is used to transmit information pertinent to subscriber or patient identification, demographics, treatment diagnostics, or certification of provided or proposed services in response to transaction set EDI 278 Healthcare services request for review.
HIPAA 278 Health Care Services Review -- Response to Request for Review
HIPAA 278 Health Care Services Review -- Response to Request for Review
HIPAA EDI 278 is Healthcare Services Review: Request for Review
The Request for Review and the Response to that Request Transaction Set cover the following business events:
  • Admission certification review request and response
  • Referral review request and response
  • Health care services certification review request and response
  • Extend certification review request and response
Terms used in the services review transactions include
  • Long-term care
  • Patient event
  • Requester
  • Service provider
  • Utilization Management Organization
Review requests are submitted using the 278 EDI Healthcare Services Review:
"Request for Review".
Issues addressed by the EDI 278 differ from those for the EDI 276 in that the Request for Review triggers an audit of a healthcare encounter and the forms, certifications, and adjudication arising from it.
The requester is a provider who seeks authorization or certification for a patient to receive healthcare services.

Transaction EDI 278 can be used to send unsolicited information to trading partners.
This data can take form of health service review copies, or notification of the beginning or end of treatment.
This transaction should be routinely used in the following events: � Patient arrival notice � Patient discharge notice � Certification change notice � Notification of certification to primary providers, other providers, and Utilization Management Organization
EDI 278 is used to transmit information pertinent to subscriber or patient identification, demographics, treatment diagnostics, or certification of provided or proposed services in response to transaction set EDI 278 Healthcare services request for review.
HIPAA 820 Payment Order/Remittance Advice
HIPAA 820 Payment Order/Remittance Advice
HIPAA EDI 820 is Payment Order/Remittance Advice

Transaction 820 is also known as the transaction supporting "Payroll Deducted and Other Group Premium Payment for Insurance Products."
It is used to pay for insurance products, individual and group premiums, to forward remittance advice, or both.
Payment is often in the form of a transaction order to a financial institution or directions to a payee�s accounts receivable system.
It is also used when sending premium payments to an insurance carrier.
Electronic Funds Transfer transactions are fully supported through submission of the 820.

Transaction 820 is applicable when sending premium payments to an insurance company, health care organization, or government agency.
Business functions applicable under HIPAA compliance fall into two categories:

The first is the use of an Electronic Fund Transfer with remittance information carried through the Automated Clearinghouse system.
The choice of which type of detail depends on the contract type.
Detail may include
  • Organization summary remittance detail
  • Individual remittance detail
Individual remittance detail may only be sent for those contractors who require individual remittance information to properly apply the premium payments.

The second function applicable under HIPAA is the use of an Electronic Fund Transfer or a check to make the payment, with separate remittance advice containing information for either :
  • Organization summary remittance detail
  • Individual remittance detail
The movement of the remittance advice is through the 820 transaction communicated outside of the banking networks, where the choice of which type of detail again depends on contract type.

The 820 transaction can perform multiple functions:
  • An 820 can be sent to a bank to move money only
  • An 820 can be sent to a bank to move money as well as detailed or summary remittance information.
  • An 820 can be sent directly to a payee to move detailed or summary remittance information.
Each function changes the actual content of the transaction slightly.
The X12N payroll deducted and other group premium payment for insurance products implementation guide provides standardized data requirements and content to all users of the ANSI X12 premium payment order remittance advice transaction set for the purpose of reporting payroll deducted and other group premiums.
For HIPAA, only portions of the complete 820 implementation guide are applicable.

To summarize, the payment and remittance advice transaction is frequently used in separate functions.
In the payment role, it is a payment order directing a bank to effect payment to a health plan; in this role, the remittance advice is primarily payment reference information to enable the health plan�s system to match up the payment with coverage kept in force.
Payments are frequently made in aggregate to cover several subscribers in a group policy.
In the electronic remittance advice role, it explains payment and partial payment for subscriber involved.

The remittance advice is intended to support automatic reconciliation of premium in a health plan�s accounts receivable systems and is one of the most attractive transactions from a health plan�s viewpoint.
HIPAA 834 Benefit Enrollment and Maintenance
HIPAA 834 Benefit Enrollment and Maintenance
HIPAA EDI 834 is Benefit Enrollment and Maintenance

EDI 834 is used to transfer enrollment information from a sponsor to a healthcare insurance or benefit provider.
The sponsor is the employer, association, or other agency that ultimately pays for the insurance coverage.
The sponsor may also elect to designate a Third Party Administrator to submit the information.
Thus, EDI 834 is to transfer enrollment information from the sponsor of the healthcare insurance coverage, benefits, or policy to a health plan.

This transaction is used to enroll, update, or dis-enroll employees and dependents in a health plan.
The transaction is typically used in two modes: update and full replacement.
In update mode, the employer, union, or other sponsor sends transactions to add, charge, or terminate subscriber and dependent records.

In the full replacement mode, the sponsor periodically sends a complete file of all subscribers and dependents, and the payer does a comparison and reconciliation with its files.
The enrolment transaction is expected to be popular with small and medium size accounts.

The parties that engage in the enrolment process include the following:
  • Sponsor
  • Payer/Insurer
  • Third Party Administrator
  • Subscriber
  • Dependent
  • Insured or Member
These parties interact in a number of ways during the delivery of healthcare.
HIPAA 835 Health Care Claim Payment/Advice
HIPAA 835 Health Care Claim Payment/Advice
HIPAA EDI 835 is Healthcare Claim Payment/Advice

EDI 835 is used to send a payment and Explanation of benefits remittance advice, or both only from a healthcare insurer to a healthcare provider.
Payment can be issued directly or through a financial institution.
As with the 820 transaction, the payment portion of this function may be done with a paper check.

EDI 835 is used to send and receive electronic remittance advice and payments.
Healthcare providers receiving the 835 include:
  • Hospitals
  • Nursing homes
  • Laboratories
  • Physicians
  • Dentists
  • Allied professional groups
Organizations sending EDI 835 include:
  • Insurance companies
  • Third party administrators
  • Service corporations
  • State and federal agencies and their contractors
  • Plan purchasers
  • Any other entities that process healthcare reimbursements
Other business partners affiliated with EDI 835 include:
  • Depository financial institutions
  • Billing services
  • Consulting services
  • Vendors of systems
  • EDI network intermediaries such as automated clearinghouse, values added networks, and telecommunications services.
Depending on the number of entities involved, healthcare claims payment and advice communications can become relatively complex.

Amosoft will manage all the communication with Depository Financial Institutions,
Perform Electronic funds transfer, electronic remittance advice and send funds deposit notifications.
HIPAA 837 Health Care Claim: Professional, Institutional and Dental
HIPAA 837 Health Care Claim: Professional, Institutional and Dental
HIPAA EDI 837 is Healthcare Claim Professional, Institutional and Dental

The healthcare claim transaction, EDI 837, is intended to originate with the healthcare provider or the healthcare provider�s designated agent.
It also may originate with payers in an encounter-reporting situations.
EDI Transaction 837 provides all necessary information to allow the destination payer to at least begin to adjudicate the claim.
All the following transactions are generated by healthcare providers and transmitted to payers either directly or through intermediary billing services.
Payers are such organizations as insurance companies, HMO�s and Medicare/Medicaid.
All of these claims are intended to provide information that will allow the payer to begin to adjudicate the claim.

The healthcare claim Professional transaction set is used to submit healthcare encounter and billing information generated by healthcare providers, such as physicians, surgeons, radiologists, and mental health professionals.

The healthcare claim, Dental originates with a dental healthcare service provider or designated agent.
This transaction set is used to submit dental healthcare encounter and billing information.
The healthcare claim, Institutional transaction set is used to submit healthcare encounter and billing information generated by healthcare facilities such as hospitals, acute care clinics, and so on.

Healthcare claims for pharmaceuticals use the NCPDP standard.
All other claims use EDI 837 format.
EDI 837 format replaces electronic versions of the uniform billing claim UB-92 and the HCFA 1500.
It can carry HMO medical encounter accounting information as well as billing claims.
A key consideration for coordination with payer claim systems is a requirement for systems to retain all of the information received on the claim.

Payers must be able to electronically accept an EDI 837 transaction with all the data for a given type of claim.
The payer cannot summarily reject such a claim.
That does not mean, however, that the payer is required to bring that data into their adjudication system.
The payer, acting in accordance with his business partner policies and contractual agreements, can ignore information within EDI 837 transaction set.
Therefore, it is permissible for trading partners to specify a subset of an EDI 837 transaction set they are able to process or act upon most efficiently.

Amosoft is familiar with the Health Insurance EDI documents, and our EDI services and solutions support all of them. Our EDI integration solutions provides full integration of EDI and your ERP system. Amosoft can help with EDI integration and implementation, beginning to and End solution full custom tailored to your specific needs. For companies who have low volume of EDI documents every month we developed our Web-EDI solution. The web solution is very easy to use and has the fill and look of using an email.

EDI Software & Services   EDI Industries EDI Resources
EDI Software EDI Integration EDI for Retailers EDI Articles
Web Based EDI Solution EDI Outsourcing EDI for Suppliers EDI Documents
AS2 Software EDI Consulting EDI for Manufacturers Partners
ASN Software VAN Services EDI for Grocery Success Stories
QuickBooks EDI Software   EDI for Food Brokers EDI Overview
Microsoft Dynamics AX EDI Software   EDI for Logistics The Future of EDI
Microsoft Dynamics GP EDI Software   EDI Healthcare Supply Why should I use EDI?
Microsoft Dynamics SL EDI Software   EDI HIPAA More about EDI
Microsoft Dynamics NAV EDI Software     ASC-X12
SAP Business One EDI Software     DISA
SAP R/3 EDI Software     HIPAA
Oracle JD Edwards EDI Software     EDI Standards
Epicor Retail EDI Software     Employment Opportunities
Sage MAS 90 EDI Software      
Sage MAS 200 EDI Software      
Sage MAS 500 EDI Software      
Sage PFW ERP EDI Software      
Sage Accpac ERP EDI Software      
Sage Pro ERP EDI Software      
 

Get more business with EDI Outsourcing quote-blue.png
 
or call us (310) 862-4259
 

From our News


EDI Outsourcing: Outsource EDI Project
There are many benefits of EDI, and one of the most conspicuous benefits of EDI is that it is the safest way of transferring data and information to the recipients. Now, the web based EDI service is used comprehensively by the business companies across the world. However,
Read more...

11601 Wilshire Blvd. Suite 500

Los Angeles, CA 90025

Sales Inquiries: +1 800-761-4268

sales@amosoft.com

Contact Us arrow-yellow.gif


twitter-follow-us.png


map.png