How US Healthcare Claims Processing Works: From Patient Visit to Payment 

A patient visits a doctor. The physician provides the service, completes the documentation, and eventually the healthcare organization gets paid. 

From the outside, that sounds like a fairly simple process. In reality, healthcare claims processing in the US connects a series of clinical, administrative, and financial workflows before a patient visit becomes a payment. That visit can trigger a sequence of electronic transactions involving the scheduling system, eligibility verification, the electronic health record, clinical documentation, medical coding, claim validation, a clearinghouse, the payer, remittance information, and potentially the patient's financial account. 

Understanding this process matters for digital health companies because claims processing is closely connected to the clinical workflows their products support. If a platform schedules reimbursable services, supports clinical documentation, integrates with an EHR, or helps providers deliver care, decisions made inside the product can eventually affect whether a service can be billed and whether a claim is paid. 

About This Article 

This article is based on work delivered by the Touch4IT team at BigHeart and MyOwnDoctor, organizations we have worked alongside for several years while developing healthcare technology in the United States. 

Claims Processing Starts Before the Patient Sees the Doctor 

It is tempting to think that a healthcare claim begins when a physician finishes treating a patient. 

Operationally, the process can begin much earlier. 

Imagine that a patient calls a clinic to schedule a therapy appointment. Before delivering the service, the organization needs to know whether the patient has active insurance coverage and what that coverage means for this particular service. 

Take the front desk workflow in practical terms. A staff member collects the patient's insurance information, and the system sends an eligibility inquiry. In standardized electronic healthcare transactions, this is commonly represented by a 270 eligibility inquiry and a 271 eligibility response. 

The response can provide information immediately relevant to the appointment, including whether coverage is active and the patient's financial responsibility. CMS describes the 270/271 transaction in similar terms and notes that eligibility operating rules support information such as deductibles, copayments, coinsurance, and coverage for specific service types. 

This creates an important connection between administrative infrastructure and the patient experience. 

The patient might simply see an appointment appear in an application. Behind that appointment, the healthcare system may already be communicating with the payer to determine whether the service is covered and what the patient may owe. 

Scheduling an appointment could trigger an eligibility request, with the result eventually appearing alongside the appointment so staff knows whether the patient is covered and whether to collect a copayment. 

For healthcare product teams, this is the first important lesson: scheduling, insurance eligibility, and billing are often connected workflows. 

The Clinical Encounter Creates the Information Needed for the Claim 

Once the patient actually receives care, the process moves from insurance eligibility into clinical documentation. 

The physician or other healthcare professional documents what happened during the encounter. Depending on the service and the EHR, this can include the patient's complaint, medical history, assessment, diagnosis, procedures performed, treatment decisions, prescriptions, and other information required for the clinical record. 

That documentation has another purpose as well. 

It provides information that can ultimately support the claim. 

In modern EHR workflows, documentation templates can help capture relevant diagnosis and service codes while the clinician completes the note, with validation before the note is signed and the possibility of coding suggestions being generated from the clinical documentation. 

This is where two coding systems become particularly important. 

ICD-10-CM codes generally communicate the diagnosis or reason for the service. CPT and HCPCS codes describe the professional services, procedures, or other billable items being reported. CMS lists ICD-10-CM as the adopted diagnosis code set, CPT for physician and outpatient procedures, and HCPCS for supplies and services not included in CPT. 

Here’s a simple way of thinking about the information contained in a claim: 

• Why was the service provided? The diagnosis. 
• What service was provided? The procedure or service code. 
• Who provided it? The provider identifier. 
• Who received it? The patient and insurance information. 
• When did it happen? The date of service. 

That simplified model is useful because it shows why claims functionality cannot be completely separated from clinical software. The information required for reimbursement originates in what actually happened during care. 

A Signed Clinical Note Can Become an 837 Claim 

Once the encounter is complete and the required documentation is available, the organization can prepare the healthcare claim. 

For electronic healthcare claims covered by the HIPAA transaction standards, the core transaction is the ASC X12N 837. CMS defines the 837 as the adopted electronic standard for healthcare claims or equivalent encounter information. 

The 837 is the electronic claim containing the essential information needed to tell the insurer what happened. It includes the patient's insurance information, diagnosis, service information, provider identifier, and date of service. 

The provider identifier is typically the National Provider Identifier, or NPI, while the diagnosis and service information are represented using the appropriate healthcare code sets. 

In a sophisticated EHR, much of this process can happen behind the scenes. 

The clinician signs the note. The system has access to the patient, provider, and encounter information. Relevant codes have been entered or captured. The claim can then be constructed from the data already associated with the encounter. 

This automated workflow means signing the note can eventually trigger the claim process, subject to validation before submission. 

That validation is important. 

A healthcare organization cannot simply send whatever information exists in the clinical record. The claim needs the required information in the right structure, and the codes and other claim elements must satisfy applicable rules. 

This is why claims processing software often includes validation or claim-scrubbing functionality before a claim reaches the payer. 

The Claim May Pass Through a Clearinghouse 

The path from the healthcare provider to the insurance company does not always consist of a direct connection between two systems. 

Healthcare organizations frequently work with billing companies and healthcare clearinghouses that help prepare, validate, and transmit claims. 

Information can originate in the healthcare platform, move through the billing operation, and then be transformed into the standardized claim submitted to the payer. 

For a digital health company building billing functionality, this creates an important architectural decision. 

The product does not necessarily need to reproduce the entire revenue cycle infrastructure internally. Depending on the business model, the platform may need to generate the right clinical and administrative information, integrate with a billing partner or clearinghouse, receive responses, and make the resulting status visible to the appropriate users. 

The important question is therefore not simply, “Can our software generate a claim?” 

It is, “Where does our software sit in the complete workflow between care delivery and payment?” 

The Payer Adjudicates the Claim 

Submitting the 837 does not mean the provider has been paid. 

The payer must now process the claim. 

This stage is called adjudication. The insurer evaluates the submitted claim and determines what it will pay based on the patient's coverage and applicable contractual and payment rules. The resulting amount may not be the same as the amount originally billed. 

Several outcomes are possible. A claim may be paid as submitted, adjusted, partially paid or denied. Depending on the patient's plan, the patient may also have some financial responsibility. 

For a healthcare platform, this means the claim cannot simply disappear after submission. 

The system may need to understand what happened after adjudication and connect that information back to the original patient, encounter, and claim. 

And that leads to another important electronic transaction. 

The 835 Tells the Provider What Happened to the Claim 

After adjudication, payment and remittance information can return electronically through the 835 transaction, commonly used for electronic remittance advice. 

The 835 is the information coming back from the payer explaining how the claim was processed, including what was paid, what was denied, adjustments, and potentially amounts attributable to the patient. 

CMS similarly explains that an electronic remittance advice provides final claim adjudication and payment information. It can identify payment amounts and adjustments at the claim or service line level and communicate the reasons for those adjustments using standardized codes. 

This closes an important part of the electronic cycle. 

• 270 → Is this patient eligible and what benefits apply? 
• 271 → Here is the eligibility and benefit information. 
• 837 → Here is the healthcare claim. 
• 835 → Here is how the claim was adjudicated and the associated remittance information. 

Other transactions exist within the broader administrative ecosystem, including the 276/277 claim status inquiry and response. CMS confirms that 270/271, 837, 276/277 and 835 are all standardized HIPAA electronic transactions. 

And from a software engineering perspective, this is where the workflow becomes particularly interesting. 

The 835 needs to reconnect with information that originated much earlier in the process: the patient, appointment, clinical encounter, provider, codes, and submitted claim. 

That's where claims processing becomes as much a data architecture problem as a billing problem. 

When the Claim Comes Back, the Financial Workflow Continues 

Receiving an 835 does not necessarily mean that the entire amount originally billed has been paid. 

The payer may approve the claim in full, pay only part of it, apply a contractual adjustment, or deny the claim. Depending on the patient's insurance coverage, some of the remaining amount may also become the patient's responsibility. 

This information must eventually flow back into the healthcare organization's financial records. The remittance information can update a ledger, and if a patient balance remains, it may need to appear in the system and eventually on a patient statement. 

This means that a claims workflow is circular. Information begins with the patient and their coverage, moves through the clinical encounter and claim, reaches the payer, and then returns as financial information that must be connected to the correct patient and service. 

For healthcare software teams, maintaining those relationships is critical. A payment or denial has little value as an isolated record. The system needs to know which claim it belongs to, which encounter generated it, which patient received the service, and what financial responsibility remains. 

Claims Can Be Adjusted or Denied 

A submitted claim does not automatically result in payment. 

The payer response can show what was approved, what was denied, how much the insurer paid and whether an adjustment was made. It can also communicate a reason when a claim is denied. 

This matters because claims processing requires more than a simple status such as “submitted” or “paid.” 

Healthcare organizations need visibility into what happened after submission. If something is denied or adjusted, the information must reach the people or systems responsible for deciding what happens next. 

Some problems can originate much earlier in the workflow. Insurance information may be incorrect. Required information may be missing. The documentation may not support the submitted service. A code may be inconsistent with other information on the claim. This is one reason why validation is crucial before submission. 

Modern systems can automate some of this work, such as claim scrubbing and payer rule validation before a claim is transmitted, to identify coding or claim data issues before they reach the payer. 

Preventing an avoidable problem before submission is generally much easier than discovering it after adjudication. 

Clinical Documentation and Claims Processing Are Closely Connected 

Clinical and financial workflows are closely connected within an EHR. 

The clinician is primarily documenting care. Yet information entered during that process can later contribute to coding and claim generation. 

Documentation templates can capture structured information, generate coding suggestions from the completed note, validate before sign-off, and build claims by assembling the information required for reimbursement.  

This creates a chain of dependencies: 

Clinical encounter → Documentation → Coding → Validation → Claim → Adjudication → Remittance 

A problem early in that chain can create problems later. 

If required information was never captured during the encounter, the billing workflow may have to recover it later. If clinical documentation and submitted codes don't align, the claim may require additional review. If information is stored only as unstructured text, downstream systems may have a harder time using it automatically. 

This is why clinical documentation design has consequences beyond the physician interface. 

The data model underneath that interface can eventually affect billing, reporting, and other healthcare operations. 

Claims Processing Is Part of EHR Architecture 

A scheduler may see patient demographics, insurance information, and the result of an eligibility request. Staff may collect a copayment before or during the appointment. A clinician completes the encounter and signs the note. The system can then validate the information and initiate the claim process. Later, financial information can return and update the patient's account. 

Different users interact with different parts of this process. 

A scheduler does not need the same clinical access as a physician. A physician should not have to manually manage every administrative transaction generated by a visit. Billing staff needs visibility into claims and payment information. Administrative users may need organization-wide reporting. 

The EHR is a collection of connected workflows with permissions and interfaces adapted to different roles rather than a single patient database. 

This is one reason healthcare software becomes complex quickly. A relatively simple action, such as scheduling a reimbursable appointment, can affect eligibility, patient payments, clinical documentation, claims, and reporting. 

Automation Depends on Structured Data 

Here’s a highly automated version of this process. 

A patient is scheduled. Eligibility can be checked electronically. The clinician completes the visit. The note contains the information needed for coding. The claim is built and validated. The system sends it to the payer, potentially through a clearinghouse. The payer processes it, and the resulting financial information returns to the healthcare organization's systems. 

The physician does not manually construct an 837 transaction after every visit. In the workflow, the claim can be generated after the clinical note is signed and validated. 

But automation only works when the underlying information is structured correctly. 

The system needs to know which patient received the service, which insurance coverage applies, which provider delivered it, what happened during the encounter, what diagnosis was documented, what service was performed, and when it occurred. 

That information also needs to remain connected as it passes between systems. 

For engineering teams, this is a useful way to think about claims infrastructure. The visible claim is only one output of a much larger healthcare data workflow. 

What Digital Health Companies Should Consider Before Building Claims Functionality 

A digital health company does not necessarily need to build a complete billing system. 

The more useful question is how far its product participates in the reimbursement workflow. 

A wellness application that never supports reimbursable healthcare services may have little reason to interact with claims infrastructure. A telehealth platform, virtual clinic, remote care platform, or software product embedded in provider workflows may have very different requirements. 

If the product participates in reimbursable care, the team should understand where insurance eligibility is checked, where clinical documentation occurs, where diagnosis and service codes originate, who validates the claim, whether a billing company or clearinghouse is involved, how claims are transmitted, and how remittance information returns. 

The product does not have to own every component. It does need reliable interfaces between the components it owns and the systems responsible for the rest. 

Claims Data Can Become Useful Beyond Billing 

Claims exist primarily because healthcare organizations need to get paid, but the information generated through claim workflows can also become valuable for understanding healthcare activity. 

Diagnosis codes show why care was delivered. Procedure and service codes describe what was delivered. Provider identifiers show who delivered it. Dates connect those activities over time. Adjudication and remittance information add a financial dimension. 

When this information is connected with clinical and operational data, healthcare organizations can begin answering broader questions about service utilization, patient populations, and financial performance. 

This becomes particularly important as organizations move beyond traditional fee-for-service reimbursement. 

In value-based arrangements, the organization may need to understand what happened across an entire population, what services patients received, how much their care cost, and whether healthcare utilization changed over time. 

That is where claims processing connects with another major part of US healthcare technology: value-based care infrastructure. 

We will explore that separately in our article on how technology supports value-based care. 

From Patient Visit to Payment 

A healthcare claim may look like an administrative document, but it represents the output of a much larger operational process. 

The patient must first be identified and their insurance information captured. Eligibility may be checked before the appointment. A healthcare professional then delivers and documents the service. Diagnosis and service information is translated into standardized codes. The claim is assembled and validated before being transmitted to the payer. The payer adjudicates it, and payment and adjustment information returns to the healthcare organization. 

At a simplified level, the journey looks like this: 

Appointment → Eligibility → Encounter → Documentation → Coding → 837 Claim → Payer Adjudication → 835 Remittance → Payment or Patient Balance 

Understanding this journey is valuable even for engineers who will never work directly in medical billing. The clinical, administrative, and financial systems are connected. Decisions about scheduling, documentation, data structures, and integrations can eventually affect what happens much further downstream. 

For digital health companies building products for the US market, understanding those connections early can prevent claims infrastructure from becoming an expensive afterthought. 

Final Thoughts 

Claims processing is one of the clearest examples of why building healthcare software requires knowledge of the healthcare system around the product. 

A patient sees an appointment. A clinician sees an encounter and a clinical note. A billing team sees codes and claims. A payer sees standardized transactions that it must adjudicate. A finance team eventually sees payments, adjustments, and outstanding balances. 

The software must connect those perspectives while preserving the relationships in the underlying data. 

That is why claims processing should not be treated only as a billing integration when it is central to the product's business model. For many digital health companies, it is part of the architecture connecting clinical care with the economics of delivering that care. 

Building Healthcare Software for the US Market? 

Touch4IT has spent more than six years working with BigHeart on healthcare technology supporting care delivery and operations in the United States. Our work has included EHR functionality, telehealth, patient engagement, healthcare integrations, care management and healthcare data infrastructure. 

We work with digital health companies that need to turn complex healthcare workflows into software that can operate reliably in real clinical environments. 

If you are building or expanding a healthcare platform for the US market, talk to Jan, our healthcare lead. 

FAQs 

1. What is healthcare claims processing? 

Healthcare claims processing is the process of submitting information about a healthcare service to a payer for reimbursement. It typically connects patient insurance information, clinical documentation, diagnosis and procedure codes, provider information, claim submission, payer adjudication, and remittance. 

2. What is an 837 healthcare claim? 

The 837 is the standard electronic transaction used to submit healthcare claim information. It communicates information such as who received the service, who provided it, why the service was provided, what service was performed and when it occurred. 

3. What are 270 and 271 transactions in healthcare? 

The 270 transaction requests information about a patient's insurance eligibility and benefits. The 271 is the corresponding response. These transactions help healthcare organizations determine whether coverage is active and provide information about benefits and patient financial responsibility before delivering a service. 

4. What is an 835 transaction in healthcare? 

The 835 is an electronic remittance transaction that communicates how a payer processed a healthcare claim. It can contain information about payments, adjustments, denials, and patient responsibility, allowing the healthcare organization to reconcile the payer's response with the original claim. 

5. What is the role of ICD-10, CPT, and HCPCS codes in healthcare claims? 

ICD-10-CM codes generally describe the patient's diagnosis or reason for receiving care. CPT and HCPCS codes describe healthcare services, procedures, and other billable items. Together with patient, provider, and service information, these codes help communicate what happened during an encounter to the payer. 

6. Why should digital health companies understand healthcare claims processing? 

Digital health products that support reimbursable care may interact with scheduling, insurance eligibility, clinical documentation, coding, billing partners, clearinghouses, and payer systems. Understanding the claims workflow helps product and engineering teams determine which information their software must capture, where integrations are required, and how clinical activity eventually connects with payment.