The HIPAA Claims Attachment Standard

HIPAA's administrative simplification provisions told the Secretary to adopt standards for the transactions the statute lists, and attachments were on the list from the start. The Affordable Care Act then set a deadline: the Secretary was to adopt a standard and operating rules for attachments by 1 January 2014, effective no later than 1 January 2016. The rule recites that deadline itself. It was missed by more than a decade, and the practical consequence is the thing every billing office already knows — the attachment is the one part of the claim where each plan gets to invent its own process.

That gap is why an attachment is disproportionately expensive to handle. A standardized transaction can be built once and reused across every payer; an unstandardized one is a per-payer integration, or, more often, no integration at all. The absence is also why the operational discipline around attachments — verifying what is actually required before sending anything, and keeping the material linked to the exact claim version — has had to carry weight that a standard would otherwise carry.

Two new sections do the work. 45 CFR 162.2001 defines the transaction, and it is deliberately two-directional. It covers attachment information sent from a health care provider to a health plan in support of a claim or equivalent encounter transaction, and it separately covers a request from a health plan to a provider for that information. The request is a transaction in its own right, which is the part most likely to change day-to-day work: the payer's ask becomes a standard message rather than a letter.

45 CFR 162.2002 then names the standards. The structure pairs an X12 transaction, which carries the envelope and the claim linkage, with an HL7 clinical document, which carries the content:

The provider's transmission — X12N 275

For attachment information going from provider to plan, the rule adopts the ASC X12N 006020X314 transaction, identified in the regulation as additional information to support a health care claim or encounter (45 CFR 162.2002(c)).

The plan's request — X12N 277

For a plan's request to a provider for attachment information, the rule adopts the ASC X12N 006020X313 transaction, identified as a health care claim request for additional information (45 CFR 162.2002(d)). Note the version: this is a 6020 request transaction, and it is a different thing from the 277 claim acknowledgment a practice already sees in submission workflows.

The content — CDA-based documents

For both directions, the rule adopts an HL7 CDA Release 2 attachment implementation guide for the exchange of C-CDA based documents (45 CFR 162.2002(a)). For the provider-to-plan direction it additionally adopts the two volumes of the HL7 Consolidated CDA templates for clinical notes (45 CFR 162.2002(b)).

The signature — where one is used

Where a provider uses an electronic signature on a claims attachment, the rule adopts an HL7 CDA Release 2 implementation guide for digital signatures and delegation of rights (45 CFR 162.2002(e)). This is the first electronic signature standard adopted under the statutory instruction to specify procedures for the electronic transmission and authentication of signatures, and its scope is narrow: it applies to claims attachments, and nowhere else.

One design decision is worth flagging because it forecloses a shortcut. A commenter asked HHS to let a plan comply by supporting either structured or unstructured documents, adding the other later. HHS declined: covered entities will have to support both document types. A plan cannot satisfy the standard by accepting only tidy structured data, and a practice cannot assume its unstructured records will be refused.

So the correct near-term posture is not migration. Nothing about how a plan may request records, or how a practice may send them, changes before May 2028. What changes now is planning: the format of the eventual transaction is knowable, the direction of travel is fixed, and a clearinghouse or practice management contract signed in 2026 or 2027 will still be running when the requirement lands. The question to put to a vendor is whether the roadmap reaches the standard, not whether the product supports it today.

This is the part most likely to be got wrong, because the natural assumption in 2026 is the opposite. Attachments and prior authorization are entangled in practice — the documentation a plan wants before it approves a service looks a lot like the documentation it wants before it pays a claim — and CMS has been actively rulemaking on electronic prior authorization. A reader could reasonably expect an attachments standard to cover both.

It does not. HHS proposed exactly that, and withdrew it. The proposed rule would have defined attachment information to reach both claims and prior authorization transactions, and would have adopted a version of the X12N 278 request-for-review transaction to carry prior authorization attachments. Commenters opposed it, and the final rule declines: HHS states that it is not finalizing adoption of a standard for prior authorization attachments transactions, and that the definitions and standards it does adopt neither reference nor extend to prior authorization attachments. The X12N 278 version it had proposed was not adopted. Even the conforming change it had proposed to the definition of "transaction" was dropped — the definition was finalized as health care claims attachments rather than the broader health care attachments it had floated.

1. 01

   Keep running the current workflow

   Nothing is required before May 2028. The existing discipline — confirm the requirement before sending, send the minimum necessary, keep the material linked to the exact claim version, reconcile receipt — is still the whole job, and it will remain the job after the standard lands, because a standard changes the channel and not the judgement.
2. 02

   Put the date into vendor conversations

   Clearinghouse, practice management, and document management contracts running into 2028 will meet this requirement inside their term. Ask what the roadmap is rather than what the product does today, and get the answer before renewal rather than after.
3. 03

   Separate the two rules when planning

   Attachment standardization and electronic prior authorization are different programs with different dockets, different CFR parts, and different dates. Treating them as one initiative is the most likely planning error, and this rule went out of its way to keep them apart.
4. 04

   Expect the request to become a message

   The two-directional design means the payer's request for records is itself a standard transaction. That is the piece with the most operational upside for a practice, because a standardized request can be routed and tracked automatically in a way a fax or a portal notice cannot — and it is worth knowing which of today's manual payer records requests would land in that channel.