Wireframe preview

Best viewed on desktop.

This is a wireframe for review, not the finished site. The responsive (mobile) treatment comes in the design and build phase. Open this page on a screen at least 1200 px wide to see the layout as intended.

Glossary

The transactions, operating rules, identifiers and architecture terms behind healthcare data sharing, defined in plain language and grouped by kind. Search by a term or a word in its definition.

Transactions

837 (X12 837)

The HIPAA-standard transaction for submitting healthcare claims from providers to payers. Three variants: 837P (professional, replacing CMS-1500), 837I (institutional, replacing UB-04), and 837D (dental). Current mandated version is 005010X222A1 (837P) and 005010X223A2 (837I).

Read more: 837 Claims

835 (X12 835)

The HIPAA-standard Electronic Remittance Advice. Sent by payers to explain claim adjudication: what was paid, what was denied, and why, via CARC and RARC codes. Carries the TRN02 reassociation trace number that links the remittance to its corresponding EFT payment.

Read more: 835 ERA Processing

270/271 (X12 270/271)

Eligibility and benefit inquiry (270) and response (271). Version 005010X279A1. The 271 returns active coverage, plan detail, and service-level benefits. Failures return AAA rejection codes rather than coverage.

Read more: 270/271 Eligibility & Benefits Verification

276/277 (X12 276/277)

Claim status inquiry (276) and response (277). Lets a provider check a submitted claim without calling the payer. The 277CA (Claim Acknowledgment) is a distinct transaction reporting front-end acceptance or rejection.

Read more: 276/277 Claim Status

278 (X12 278)

The HIPAA-standard health care services review transaction, used for prior authorization. The 278 Request carries the service being requested; the 278 Response carries the payer's certification decision. Version 005010X217. CMS-0057-F additionally mandates a FHIR-based Prior Authorization API alongside it.

Read more: 278 Prior Authorization

275 (X12 275)

The HIPAA-standard transaction for submitting additional documentation supporting a claim or prior authorization: operative reports, labs, clinical notes. Linked to its parent 837 or 278 by payer control number.

Read more: 275 Claims Attachments

Codes & Identifiers

AAA Error Codes

Rejection codes returned in a 271 when an eligibility inquiry cannot be answered. AAA 72 (invalid/missing subscriber ID) and AAA 41 (authorization/access restrictions) are the two most common. AAA codes indicate the inquiry failed. They are not a statement that coverage is inactive, a distinction that drives a large share of avoidable denials.

Read more: 270/271 Eligibility & Benefits Verification

CARC / RARC

Claim Adjustment Reason Codes and Remittance Advice Remark Codes. CARCs state why a payment differs from the billed amount; RARCs supply supplemental explanation. Both are carried in the 835 and are the raw material of denial management.

Read more: Denial Management

TRN02

The reassociation trace number data element in the 835. Must match the trace number in the CCD+ addenda of the corresponding EFT for automated reassociation to succeed.

Read more: 835 ERA Processing

CCD+ TRN

The addenda record carried on an ACH CCD+ healthcare payment. Contains the reassociation trace number that must match the TRN02 in the corresponding 835, enabling automated payment-to-remittance matching.

Read more: EFT/ERA Reassociation

MBI (Medicare Beneficiary Identifier)

The identifier that replaced the SSN-based HICN for Medicare beneficiaries. MBI lookup services allow a provider to retrieve a current MBI when it is unknown or has changed.

Read more: HETS Attestation

NPPES / PECOS

The National Plan and Provider Enumeration System (source of NPI data) and the Provider Enrollment, Chain and Ownership System (Medicare enrollment). Both are used in provider data validation and screening.

Standards, Rules & Programs

EDI (Electronic Data Interchange)

Computer-to-computer exchange of business documents in standard format. In US healthcare, EDI means the X12 transaction sets mandated by HIPAA.

Read more: Data Engineering

X12 005010X279A1

The mandated implementation guide version for the 270/271 eligibility transaction pair. Conformance to this guide, including its AAA error handling, is required for HIPAA compliance.

Read more: 270/271 Eligibility & Benefits Verification

HL7 v2

The long-established clinical messaging standard: ADT, ORM, ORU and related message types. Still the dominant clinical integration format in production despite FHIR's growth.

Read more: HL7 Integration

FHIR (Fast Healthcare Interoperability Resources)

HL7's modern API standard for healthcare data exchange, using REST and JSON. FHIR R4 is the version referenced by CMS-0057-F.

Read more: FHIR API Integration

CAQH CORE

The Committee on Operating Rules for Information Exchange. Publishes federally mandated operating rules layered on top of X12, including the EFT & ERA Enrollment Data Rule (vPR.2.0) and the CCD+ TRN reassociation requirement.

Read more: Security & Compliance

CMS-0057-F

The CMS Interoperability and Prior Authorization Final Rule. Requires impacted payers to implement FHIR-based Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs. API compliance dates begin January 1, 2027.

Read more: FHIR API Integration

TEFCA / QHIN

The Trusted Exchange Framework and Common Agreement, and the Qualified Health Information Networks that operate under it. A federally facilitated framework for nationwide clinical data exchange.

PHI (Protected Health Information)

Individually identifiable health information created, received, maintained, or transmitted by a covered entity or business associate. Protected under HIPAA.

Read more: Security & Compliance

MSP (Medicare Secondary Payer)

Rules determining when Medicare pays secondary to another payer. MSP reason codes on the 835 indicate why. Misapplied MSP is a common source of improper payment and recovery activity.

Read more: Coordination of Benefits

HETS (HIPAA Eligibility Transaction System)

The CMS system providing real-time Medicare beneficiary eligibility. Access requires an approved trading-partner relationship. A trading-partner attestation requirement took effect May 11, 2026.

Read more: HETS Attestation

Workflows

Clearinghouse

A company that translates non-standard healthcare transactions into HIPAA-standard formats and routes them between trading partners. Traditional clearinghouses use centralized store-and-forward architectures that aggregate and retain PHI. PNT Data Corp. is a clearinghouse alternative that routes without retention.

Read more: Clearinghouse Alternative

Coverage Discovery

The process of identifying active coverage a provider does not already know about, often after a self-pay or unknown-payer encounter. Distinct from eligibility verification, which confirms coverage already on file.

Read more: Coverage Discovery

Coordination of Benefits (COB)

The process of determining payment order when a member has more than one coverage. Errors produce denials, rework, and improper payments. Governed in part by NAIC model rules and, for Medicare, by MSP rules.

Read more: Coordination of Benefits

EFT / ERA Reassociation

Matching an ACH payment (EFT) to its corresponding Electronic Remittance Advice (835). Performed by comparing the CCD+ addenda trace number to the 835 TRN02. Failed reassociation is a leading cause of unposted cash and manual reconciliation cost.

Read more: EFT/ERA Reassociation

Secondary Claim

A claim submitted to a second payer after a primary payer has adjudicated. Requires accurate carry-forward of primary payment and adjustment data from the primary 835 into the secondary 837.

Read more: Secondary Claims

Prior Authorization (ePA)

Payer pre-approval of a service. Electronic prior authorization uses the X12 278 and, under CMS-0057-F, a FHIR Prior Authorization API. Manual PA remains one of the largest administrative burdens in US healthcare.

Read more: Prior Authorization Modernization

Medicaid Reclamation

The process by which a state Medicaid agency recovers payments made where a third party was liable. Depends on accurate coverage identification and COB data.

Read more: Medicaid Reclamation

Architecture

Data Sharing Authority

An organization that facilitates secure exchange of health information between parties without taking ownership of, or permanently storing, the underlying data. PNT Data Corp. operates as a Data Guardian rather than a Data Owner.

Read more: Why a Data Sharing Authority Platform

Federated Architecture

A model in which data remains at its source and is accessed or exchanged on demand rather than aggregated centrally. Eliminates the central data pool while enabling interoperability.

Read more: How It Works

Zero-Residency Architecture

An architecture in which an intermediary authenticates, validates, translates, and routes data in transit but never stores it at rest. Eliminates the centralized PHI pool that makes traditional intermediaries high-value breach targets.

Read more: Security & Compliance

Ready to talk through your use case?

Talk to a Post-n-Track specialist about your data challenges. A direct conversation, starting with what you need.