X12 HIPAA is the common name for the set of specifications businesses use to transmit healthcare transactions in the United States. A transaction is an electronic exchange of information between two parties to carry out financial or administrative activities related to healthcare. For example, a healthcare provider like a hospital may send a claim to a health plan to request payment for medical services. X12 HIPAA is a narrower subset of the X12 standard. The name refers to the detailed specifications that the X12N Insurance subcommittee have defined. The official term for these specifications is a Technical Report Type 3 (TR3). More commonly, they are called X12 HIPAA implementation guides, though regulators call them federally-mandated operating rules.

​
Where can I find X12 HIPAA specifications?

The Stedi Network has Stedi guides for every X12 HIPAA transaction set. Stedi guides are interactive, machine-readable EDI specifications that let you instantly validate EDI test files. You can import any HIPAA guide into your Stedi account and use it to validate and generate EDI. Visit our Trust Center to learn more about HIPAA compliance at Stedi.

​
Is my trading partner’s companion guide the same as an X12 HIPAA specification?

No. A companion guide such as Anthem’s 270/271 companion guide is only an addendum and does not contain the complete information required to understand the specification. To create a valid transaction, you also need the information contained in the X12 HIPAA implementation guide. Generally, you start with the X12 HIPAA implementation guide and then customize it further using the information in the companion guide. Companion guides are allowed to be more restrictive than the X12 HIPAA implementation guides, but they cannot be less restrictive. For example, if the X12 HIPAA implementation guide says that a given field is required, a companion guide provided by a healthcare plan operator cannot say that the field is optional. By the same token, the X12 HIPAA implementation guides are always more restrictive than the base X12 Release 5010 specification, and they can never be less restrictive.

​
Does every healthcare company use the same specification?

No. There are two reasons why healthcare companies don’t share the exact same specifications. First, HHS so far has only mandated the strict use of X12 HIPAA implementation guides (also called operating rules) for a subset of transactions. Refer to the Operating Rules Mandate for complete details. So, while many companies may choose to adopt the X12 HIPAA implementation guides as a restriction above and beyond the base X12 Release 5010 standard, X12 HIPAA is not strictly required for all transaction sets.
Transaction NameX12 Transaction SetFederally Mandated Operating Rules
Eligibility and benefit verification270/271Yes
Claim status inquiry and response276/277Yes
Claim payment (EFT) / Electronic remittance advice (ERA)835Yes
Prior Authorization and referrals / Referral certification278No
Premium payment/explanation (employer)820No
Enrollment/disenrollment in a health plan834No
Health claims (institutional, professional, and dental) / coordination of benefits837No
Second, even for transaction sets that have federally mandated operating rules, like the 270 and 271, companies are permitted to implement further constraints. These additional constraints are provided in a companion guide, such as the one Anthem provides for its 270/271.

​
Why does healthcare use X12 HIPAA?

The United States Department of Health and Human Services (HHS) originally chose X12 as the mandated standard. Standardizing on X12 meant that all parties would use a common transaction structure, which would serve to minimize the industry’s proliferation of multiple formats.

​
X12 allowed too much flexibility

While HHS found that adopting X12 decreased administrative burden for parties by creating greater uniformity, the flexibility of the X12 standard meant that each health plan used the transaction set standards in different ways. Although the X12 standard constrained the data elements that could be used, an organization was free to impose additional constraints required by their business flow and operations, both in terms of technical constraints and business semantics. For example, different health plan operators may have allowed for a different number of transactions to be submitted in a single file. They may also have had different opinions about which specific data elements are required for each transaction. This led each health plan operator to create a companion guide, typically a PDF, that described their unique implementation of the X12 transaction sets. This required trading partners (the providers) to adhere to different transaction implementation rules for each plan operator, subverting the original goal of administrative simplification.

​
X12 HIPAA reduces ambiguity

Congress passed laws in 2010 (Public Law 111-148 | Public Law 111-152) requiring HHS to “adopt a single set of operating rules for each transaction[…]with the goal of creating as much uniformity in the implementation of the electronic standards as possible.” The laws mandate that these operating rules “describe all data elements (including reason and remark codes) in unambiguous terms, require that such data elements be required or conditioned upon set values in other fields, and prohibit additional conditions (except where necessary to implement State or Federal law, or to protect against fraud and abuse).” Essentially, Congress mandated that not only would the healthcare industry needed to use a very specific subset and configuration of the values allowed by X12 in order to “reduce ambiguities currently permitted by the standard.” (Rule by Health and Human Services Department). As a result, the healthcare industry worked with X12 to form the X12N Insurance committee, which created a detailed specification for each transaction set. These specifications are formally called a Technical Report Type 3 (TR3). The series of TR3s produced by the X12N Insurance committee is what’s commonly known as X12 HIPAA.