Securing HIPAA EDI Transactions with AS2 | JSCAPE

Overview

One of the main goals of the Health Insurance Portability and Accontability Act (HIPAA) is to improve efficiency in the US health care industry. To achieve this, HIPAA mandates the use of electronic data interchange (EDI) in health care transactions and requires HIPAA covered entities to adopt national standards when implementing EDI.

The use of EDI alone can boost the speed, data quality, and cost-effectiveness of health care information exchanges - a vital ingredient for improving processes and services in health care.

In addition, HIPAA is aimed at preserving the confidentiality of certain patient data known as protected health information (PHI) during such information exchanges.

In this post, we'll:

✔ Talk about the benefits of using EDI;

✔ Introduce you to the HIPAA EDI Rule;

✔ Acquaint you with the vulnerabilities in EDI; and

✔ Discuss how you can secure HIPAA EDI transactions using AS2.

For a more lengthy discussion on HIPAA-compliant data/file transfers in general, please read: Guide to HIPAA Compliant File Transfers - Part 1. Part 2 and 3 of that article talks about the Technical Safeguards of the HIPAA Security Rule as they apply to data/file transfers.

Benefits of using standardized EDI in health care transactions

Whenever people are introduced to a regulation, they usually don't see the benefits right away. What they see are mostly additional costs, work, and disruptions. But regulations do have benefits. And in the case of the HIPAA EDI provisions, the benefits far outweigh the initial inconveniences.

I'd like to start by sharing them with you first.

Imagine a health care provider who needs to submit a health claim to an insurance company or health plan. If, as they often do, the business systems of the two parties differ from one another, the data format (e.g. structure and content) generated by the provider's system would likely be different from what the insurer's system is programmed for. In cases like this, the receiving party, i.e., the health plan, would be forced to manually enter the information needed for claims processing.

The basic steps for this transaction would be as follows:

1. Staff at health care provider processes the health claim information through its IT system and then prints out the resulting paper documents;

2. Staff at health care provider mails paper documents to the health plan;

3. Staff at health plan sorts paper forms received from various health care providers; and

4. Staff at health plan keys in all relevant claim information into its system.

This process can be tedious, causes too much delay, and can be very prone to human error.

We're just talking about one claim. A single patient can actually have more than one health plan and a single health care provider can have hundreds of patients. In fact, there are thousands of health plans and millions of health care providers all over the country, many of whom can be running different IT software, supporting different data formats, and requiring different form entries. Although these organizations have been transacting with each other for decades, they've been doing things in a very inefficient and costly manner.

That's why EDI can help. When two parties transact via EDI, they exchange information using a common data format. In other words, both sender and receiver know exactly how many data elements there should be, what content each element holds, and in what order those elements are arranged.

Once a common data format is used, it would be much easier to process transactions. It would even be possible to connect these two parties' IT systems/business applications and set them up to perform fully automated transactions. Here's an example showing how EDI can be used in a health claim transaction similar to the one we just discussed.

In our example, each transacting party deploys an in-house EDI system that can transform application data (i.e., data generated by the internal business applications) into data in standard format (in the form of EDI messages) and vice versa. The file transfer server is assumed to be capable of transmitting EDI messages. The basic flow would be as follows:

1. Health care provider's business applications generate health claim information in non-standard format and forwards it to the provider's EDI system;

2. EDI system translates non-standard format to standard format and then forwards the health claim EDI files to the provider's file transfer service;

3. Provider's file transfer service transmits the EDI files to the health plan's file transfer service;

4. File transfer service forwards the EDI files to the health plan's EDI system;

5. EDI system translates the EDI files to a non-standard format that's suitable for the health plan's business applications;

6. EDI system forwards the non-standard format data to the health plan's business applications to continue claims processing.

Note: It's also possible to hire the services of a clearinghouse, who can transform non-standard data format to standard (and vice versa) in behalf of other covered entities, but that's for another post.

Unlike the previous method, which required lots of human intervention, this one's fully automated. Hence, it's many times faster.

Thus, by carrying out HIPAA transactions through EDI, covered entities can:

✔ Automate the transactions in question;

✔ Avoid manual data entries;

✔ Reduce the use of various paper forms;

✔ Avoid the risk of losing pertinent paper documents;

✔ Bring down delivery time from days (or weeks) to seconds;

✔ Eliminate human errors;

✔ Improve data quality;

✔ Do away with maintaining inventories of transaction forms; and

✔ Cut costs associated with paper-based transactions, i.e. document storage, mailing, and manpower for processing;

Still, simply employing EDI is not enough. Various organizations in the health care industry already started transacting through EDI in the 1990's. But as the number of EDI solutions grew, so did the number of proprietary EDI formats. This led to incompatibility issues. For instance, a health care provider could only carry out EDI transactions with health plans who used the same EDI format that it was also using. To perform an EDI transaction with other health plans, the provider had to add an EDI system compatible with theirs.

That's why the government decided to standardize. By forcing all HIPAA-covered transactions to implement a national standard, the government has made it possible for every covered entity to carry out seamless EDI transactions with just about any other covered entity in the country.

That is the essence of the HIPAA EDI Rule.

HIPAA Electronic Transactions Rule

The provisions that govern EDI transactions is found in the HIPAA Electronic Transactions Rule a.k.a. the HIPAA EDI Rule. The HIPAA Electronic Data Interchange Rule promotes the use of EDI and requires all HIPAA covered entities to adopt the same standard format and content when using EDI for any of the transactions we'll soon be enumerating below.

It applies to all health plans and health care clearinghouses, as well as those health care providers who transmit electronic health information through the said transactions.

These transactions include the following: health care claims or equivalent encounter information, health claims attachments, health plan enrollments and disenrollments, health plan eligibility, health care payment and remittance advice, health plan premium payments, first report of injury, health care claim status, and referral certification and authorization.

As of this writing, HIPAA covered entities who conduct HIPAA transactions are required to apply these two standards: NCPDP version D.0 (for pharmacy-related transactions) and X12 version 5010. The standards specify the format, data elements, and content of each transaction.

Here are the electronic transactions as they are formally known under HIPAA, along with their designated numbers:

• 1. EDI Health Care Claim Transaction set (837),
• 2. EDI Retail Pharmacy Claim Transaction (NCPDP Telecommunications Standard version 5.1)
• 3. EDI Health Care Claim Payment/Advice Transaction Set (835)
• 4. EDI Benefit Enrollment and Maintenance Set (834)
• 5. EDI Payroll Deducted and other group Premium Payment for Insurance Products (820)
• 6. EDI Health Care Eligibility/Benefit Inquiry (270)
• 7. EDI Health Care Eligibility/Benefit Response (271)
• 8. EDI Health Care Claim Status Request (276)
• 9. EDI Health Care Claim Status Notification (277)
• 10. EDI Health Care Service Review Information (278)
• 11. EDI Functional Acknowledgment Transaction Set (997)

There are special documents called Implementation Guides, which provide technical details regarding each transaction. These guides include information on how data should be moved electronically as well as how health care software can be programmed to meet HIPAA electronic standards requirements. The guides are mostly used by health plans, payers, and clearinghouses.

Health plans may in turn furnish health care providers with a Companion Guide, which contains instructions and other pertinent information about the electronic transactions the two parties will be engaging in.

In the event of non-compliance, the Secretary of the Department of Health and Human Services (HHS) can impose civil monetary penalties on any covered entity caught violating HIPAA transaction standards. Depending on the conditions surrounding the violation, penalties can go up to as high as $25,000 per person per violation.

The penalties for non-compliance combined with the benefits of complying have proven to be strong motivational factors.

In fact, although health care providers are allowed to submit claims in paper form, the number of providers who still submit in paper form has dwindled. According to the latest survey conducted by America's Health Insurance Plans (AHIP), a national trade association representing the health insurance industry, the percentage of claims received electronically was already at 94% in 2011 (up from 82% in 2009). Meaning, only 6% still use paper.

Technological advancements like EDI have revolutionized the way companies do business. Unfortunately, they also expose those companies to a new breed of risks and vulnerabilities. In the next section, we'll talk about the vulnerabilities inherent in EDI transmissions.

Vulnerabilities in HIPAA EDI messages

The EDI X12 messages used in HIPAA transactions are actually just text files. Meaning, their contents can be viewed even through regular text editors like Microsoft's NotePad. Now, although you can certainly view the contents of an EDI message, reading and interpreting what the contents mean is an entirely different story altogether.

To the average person, the contents of an EDI file - with all the data elements, segment separators, identifiers, clinical and non-clinical codes, and a host of other symbols - will only appear gibberish. But they aren't.

People familiar with EDI structure and HIPAA code sets, can actually "read" an EDI file. Some of them can work with developers to build customized software that can parse EDI messages. They just need to get hold of the relevant implementation guides. Besides, some of the content (e.g. names) is human-readable.

This means, if you transmit EDI messages in the clear, they can be vulnerable to man-in-the-middle attackers who can eavesdrop on your connection. The blog post Countering Packet Sniffers Using Encrypted FTP can give you an overview of the kind of threats you're bound to face.

Individually identifiable health information (or information that can be used to identify an individual) stolen from health care EDI transactions can be sold in the black market where they can be bought by identity thieves. Medical identity theft is a growing threat whose incidence (according to federal statistics) has jumped by 61.5% last year.

How to secure EDI transactions

Having recognized the threats to individually identifiable health information, which in HIPAA terms is known as PHI (protected health information), the government also issued the HIPAA Privacy and Security Rules. These rules specify the responsibilities of covered entities in protecting PHI. You can read more about the Security Rule and how it affects file transfers like EDI transactions in the article Guide to HIPAA Compliant File Transfers - Part 2

The best way of securing EDI transactions is by carrying them out over an AS2 connection. AS2 is built exactly for EDI files and provides the following security:

✔ SSL encryption - for keeping EDI contents confidential;

✔ Digital signatures - for authentication and non-repudiation; and

✔ MDN messages - for issuing electronic acknowledgment receipts

SSL encryption, in particular, can prevent crooks from eavesdropping on your EDI connection.

You can find detailed discussions on AS2 and its secure file transfer mechanisms in the articles:

AS2 Simplified and What is AS2 MDN?

Recommended Download

AS2 is one of the secure data transfer protocols supported by JSCAPE MFT Server, a platform independent managed file transfer server that supports a wide range of security mechanisms for meeting various laws and regulations like HIPAA. Aside from AS2, JSCAPE MFT Server also supports SFTP, FTPS, WebDAV, and others.

JSCAPE MFT Server comes with a FREE fully-functional evaluation edition which you can download today.