Lesson 0001
A first mental model for EMR and healthcare SaaS claim workflows: what gets sent, who touches it, and which product state changes when the payer responds.
After this lesson, you should be able to look at a revenue-cycle workflow event and name the likely transaction family: eligibility, claim submission, claim status, or remittance.
Primary source to read after the lesson: CMS Transactions Overview.
In a claim workflow, the EMR or billing system is not merely sending an API call called "submit claim." It is participating in a standardized administrative transaction network. CMS defines a transaction as an electronic exchange of information between two parties for health care financial or administrative activity, such as a provider sending a claim to a health plan to request payment (CMS Transactions Overview).
For the first pass, keep four transaction families in working memory:
270/271Eligibility inquiry and response. Use before the claim to check coverage and benefits. CMS describes 270/271 eligibility data as useful for preparing accurate claims and determining beneficiary liability (CMS Eligibility Inquiry).
837Health care claim. Use after the encounter is coded and ready to bill. CMS lists health claims as ASC X12N 837 Version 5010 transactions for institutional, professional, and dental claims (CMS Adopted Standards).
276/277Claim status request and response. Use after submission when the product needs to know where the claim stands. CMS notes that 277 responses can support automatic posting of status information (CMS Claim Status).
The payment document is different from the claim. After adjudication, the payer sends payment and explanation data through an electronic remittance advice, usually 835. CMS explains that ERA reports adjudication decisions, adjustment reasons, group codes, CARCs, and RARCs (CMS Remittance Advice).
A clearinghouse sits between the provider-side software and payers. In product terms, it often handles connectivity, payer routing, validation, enrollment-related friction, acknowledgments, status, and remittance delivery. It is not the payer and does not make the final coverage/payment decision.
CMS explicitly names clearinghouses as an option for providers that need software or programming support for claims submission (CMS Professional Paper Claim Form). CMS also states that HIPAA standards apply to health plans, health care clearinghouses, and electronic-transaction providers, not only Medicare and Medicaid participants (CMS Adopted Standards).
CAQH CORE operating rules matter because raw transaction standards do not define every business rule. CMS describes operating rules as the necessary business rules and guidelines not defined by a standard or implementation specification, and CAQH CORE is the current authoring entity (CMS Operating Rules; CAQH CORE Operating Rules).
The most common beginner mistake is collapsing every negative outcome into "denied." Do not do that.
| Outcome | Meaning | Product Response |
|---|---|---|
| Rejected | The claim or batch failed validation before normal adjudication. | Fix data, regenerate claim, resubmit. Track source: app, clearinghouse, payer front-end. |
| Denied | The payer adjudicated the claim and decided not to pay all or part of it. | Route to denial management, appeal, correction, write-off, or patient billing logic. |
| Adjusted | The payer paid or assigned responsibility with explanation codes on the remittance. | Post payment, contractual adjustment, patient responsibility, or provider-level balance. |
CMS describes a layered claims process: basic HIPAA standard edits can reject an entire batch, implementation-guide edits can reject individual claims, and coverage/payment policy edits can reject or deny individual claims (CMS Electronic Health Care Claims).
Answer from memory. Use the transaction code or the lifecycle word requested. Examples: 837, 270/271, rejection.
Ask follow-up questions whenever a term is fuzzy. Good next questions: "What fields are required for an 837P?", "What exactly does a clearinghouse return after submission?", or "How would I model claim statuses in a database?"
For review, keep the claim transaction map nearby.