X12, 270/271, 278 and HL7 Q22/K22 Explained

At the registration desk, checking insurance can feel as simple as clicking a button. Within seconds, the system may report coverage dates, copays, deductibles, or an error. But that information did not appear by magic. Behind the scenes, healthcare systems exchanged standardized electronic messages.

You do not have to read programming code to work in Patient Access. Knowing what those messages are supposed to accomplish, however, can make it much easier to understand why a verification failed, why an authorization is still pending, or why two patient records appear to match.

First, what is X12?

X12 is an organization that develops standards for electronic business information exchange. In healthcare, its transaction formats give hospitals, insurers, clearinghouses, and other organizations a shared way to send common administrative information. Think of X12 as an agreed-upon format for a conversation—not the software system and not the insurance company itself.

You may also hear the term EDI, short for electronic data interchange. EDI means exchanging structured business information electronically. X12 provides standards used for many healthcare EDI transactions.

What is HL7, and how is it different from X12?

HL7 (Health Level Seven) is another organization that develops standards for exchanging healthcare information. While X12 is widely used for insurance-related administrative transactions, HL7 standards help clinical and administrative systems share patient information. For example, HL7 messages can help registration and electronic health record systems exchange demographics, report admissions or discharges, and find possible matches to existing patient records. Both matter to Patient Access: X12 supports insurance-related exchanges; HL7 helps healthcare systems exchange and coordinate patient information. A practical example is the HL7 Q22/K22 patient-matching exchange discussed later in this article. This is a high-level distinction; the specific messages and workflows depend on the systems involved.

270 and 271: Is this patient covered?

These two numbers work together. A 270 is an eligibility and benefits inquiry: the provider or its technology partner asks a payer about a patient and plan. A 271 is the payer’s eligibility and benefits response.

270 — The question: Is this person on file, and what coverage or benefits are reported for the requested date and service?
271 — The answer: The payer may return eligibility status, effective dates, benefit categories, copays, coinsurance, deductibles, limitations, or a response explaining why the inquiry could not be completed.

At the front desk: A registrar checks insurance for an upcoming visit. The registration system sends or initiates a 270, often through a clearinghouse. A 271 comes back, and the software turns its contents into a screen a staff member can use.

A positive eligibility response is important, but it does not guarantee that a specific service will be covered or paid. Network participation, authorizations, exclusions, medical necessity, billing details, and payer rules may still matter.

Service Type Codes: why one eligibility check may not answer everything

A 270/271 exchange can identify the kind of care involved using Service Type Codes (STCs). For example, a general health benefit inquiry and an inpatient hospital inquiry are not necessarily asking the same question. The difference helps explain why a payer might return active plan coverage but limited details for the actual appointment.

278: Does this service need review or authorization?

The 278 transaction supports healthcare services review, including requests and responses related to prior authorization, referrals, and certain admission or service review workflows. Unlike the eligibility pair, the request and response both use the 278 transaction family.

At Patient Access: A scheduled service may require an authorization check or request. An electronic 278 exchange is one way the organization and payer can communicate about that review. The response may indicate a decision or that additional action is needed, depending on the use case and payer workflow.

Remember the distinction: a 271 eligibility response helps answer coverage and benefits questions; a 278 service-review response relates to a different question—whether the proposed care has been reviewed under relevant payer requirements. Neither guarantees final payment.

Q22 and K22: Is this the right patient?

Not every healthcare message is an X12 transaction. Q22 and K22 belong to HL7 messaging, another set of standards used by healthcare systems. A QBP^Q22 message can ask a patient-identification or master patient index system to find possible matches using demographic information. Its RSP^K22 response can return candidate records for review.

At registration: Imagine someone arrives with a familiar name and a different phone number or address. A patient-matching workflow can help find likely existing records so staff do not accidentally create a duplicate chart or select the wrong person. A possible match still needs to be confirmed under the organization’s identity-verification policy.

Where does propensity to pay fit?

Propensity to pay is a financial-assessment concept some revenue cycle teams and vendors use to estimate the likelihood that a patient will pay an outstanding or estimated balance. It is not the same thing as identifying the correct patient, checking insurance, or issuing a 278 authorization response.

A propensity-to-pay tool might use permitted account and financial information to guide outreach or financial counseling. Patient Access should treat any score as a decision-support signal—not proof of someone’s circumstances or a reason to withhold appropriate care, financial assistance screening, or respectful communication.

The messages in one simple patient journey

Find the right patient: An HL7 Q22/K22 patient-matching exchange may help identify candidate records.
Verify coverage: A 270 eligibility inquiry and 271 response exchange insurance eligibility and benefit details.
Review proposed care: A 278 transaction may support prior authorization or related healthcare services review.
Address financial questions: Financial counseling and approved propensity-to-pay tools, when used, are separate from these standard messaging functions.

Many systems hide the underlying messaging and display only the relevant results. Understanding what each type of exchange does—and does not do—helps you ask better questions when something looks wrong.

Why this matters to Patient Access

Better troubleshooting: A failed 271 response is different from a payer reporting inactive eligibility; the next step depends on what actually happened.
Clearer patient conversations: You can explain that a coverage check is not the same as authorization or a payment guarantee.
Fewer avoidable errors: Accurate member, subscriber, service-date and encounter details improve the quality of the electronic question being asked.
More useful escalations: You can tell a support team whether the issue concerns patient matching, eligibility, prior authorization, or a separate financial workflow.
Career development: Understanding these terms helps Patient Access representatives work with identity management, eligibility, authorization, financial counseling, and technology teams.

Frequently asked questions

Do Patient Access staff need to read raw X12 messages?

Usually not. Most patient-facing systems translate the transaction into fields, labels, and status messages. Understanding the purpose of each transaction is more important than memorizing its syntax.

Is 271 the same as an authorization approval?

No. A 271 communicates eligibility and benefit information; a separate service review or authorization process may be required.

Why can a patient show active coverage but still receive an unexpected bill?

Eligibility is only one part of coverage determination and claim processing. The actual services, providers, network, benefits, authorization, and claim adjudication can change the amount owed.

Is 278 used for every prior authorization?

No. Payers and providers use different operational channels. A 278 is a standardized electronic healthcare services review transaction, but it is not the only way organizations handle prior authorization.

Sources and further reading

Information checked October 27, 2026. This is a practical introduction, not a transaction implementation guide. Always follow current payer instructions, official standards and your organization’s policies. Eligibility and authorization information do not guarantee payment.

Eligibility Service Type Codes (STC): The Patient Access Reference Guide