Payments, Insurance, and Claims

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Billing is where a telemedicine product either makes money or quietly loses it, and it is the part founders most often underestimate because "take a payment" sounds like a solved problem. This article is for the founder, product manager, or hospital IT lead who needs to scope the money layer honestly: which parts are PCI, which parts are HIPAA, what a clearinghouse actually does, and why a single line of metadata can turn a clean card charge into a reportable breach. Get the boundaries right and the payment path is small, cheap to certify, and out of HIPAA scope; get them wrong and you put patient health data on a system with no contract to hold it, or you build a claims pipeline that silently rejects a third of your revenue. This is the deep dive behind the billing node on the telemedicine integration map.

Two money flows, two different worlds

Before any standard or API, get the shape of the problem. Money enters a telemedicine product through two separate pipes that look similar and are governed by entirely different rulebooks.

The first pipe is the patient payment — the copay, the self-pay visit fee, the no-show charge — paid by credit or debit card. This flow lives on the card-industry rails, and its rulebook is PCI DSS (the Payment Card Industry Data Security Standard), a contract the card brands impose on anyone who handles card numbers. PCI is not a government law; it is enforced by the banks and card networks through your payment contract.

The second pipe is the insurance claim — the bill you send to the patient's health plan for the visit, and the payment that comes back. This flow lives on healthcare's own electronic-data-interchange rails, a family of standardized message formats called X12 transactions, and its rulebook is HIPAA — specifically the HIPAA Administrative Simplification rules at 45 CFR Part 162, which make these formats mandatory for electronic billing [1].

The whole article is about keeping these two worlds separate, because the data they carry has a different risk level, and the cheapest, safest architecture treats them differently from the first day.

Figure 1. The two money flows. The patient's card payment runs on PCI rails and can stay outside the HIPAA boundary; the insurance claim runs on X12 rails and lives inside it. Keeping them separate is the central design decision.

Keep the card out: Stripe and the PCI boundary

Start with the patient payment, because it has the cleanest answer. The goal is to never let a raw card number touch your own servers. The technique is tokenization — the card number is captured by the payment processor's own code running in the browser or app, sent straight to the processor, and replaced with a meaningless token you can safely store and reuse. Your system charges the token; it never sees the card.

This is exactly what tools like Stripe Elements or Stripe Checkout do: the card fields are hosted by Stripe, so the number goes from the patient's browser to Stripe without passing through your backend [2]. The payoff is measured in compliance paperwork. PCI DSS lets a merchant prove compliance with a Self-Assessment Questionnaire (SAQ) sized to how much card data they touch. A merchant that handles card data directly fills out SAQ A-EP, which carries roughly 140 security requirements; a merchant that tokenizes through a hosted field fills out SAQ A, which carries about 24 [3]. Walk that difference:

SAQ A-EP (you touch card data):   ~140 controls
SAQ A    (tokenized, hosted):     ~24 controls
Avoided by tokenizing:            ~116 controls

Those ~116 controls you avoid include vulnerability scanning, penetration testing, and change-management processes on your own card-handling code [3]. For a small telemedicine team, the difference between SAQ A and SAQ A-EP is the difference between a checkbox and a quarter of an engineer's year. One note on dates: the current standard is PCI DSS v4.0.1, and the older v3.2.1 was retired on March 31, 2025, so any new build certifies against v4 [3].

The Stripe BAA trap: a card charge is not PHI — until you make it one

Here is the mistake that surprises teams, because it feels like good hygiene to keep records tidy. You take the payment through Stripe, and to keep your books straight you add a description to the charge: "Telehealth visit — anxiety follow-up, Jane Doe." You have just created a problem.

Stripe does not sign a Business Associate Agreement (BAA) — the contract HIPAA requires before an outside vendor may handle Protected Health Information (PHI), meaning any health data tied to an identifiable person [4]. Stripe's own position is that you should keep PHI out of Stripe entirely [4]. That is fine, and even elegant, as long as you actually keep PHI out. A bare payment — an amount, a card token, a date — is a financial transaction, not PHI; HIPAA's rules specifically leave ordinary payment processing alone. But the instant you attach the patient's name together with a clinical reason, the charge record becomes PHI, and it is now sitting on a system with no BAA. Encryption does not save you here: "encrypted" and "compliant" are different claims, and a vendor with no signed BAA is non-compliant for PHI no matter how strong its encryption is.

Common mistake — PHI in the payment metadata. Charge descriptions, statement descriptors, customer-record fields, and webhook payloads are all places teams quietly leak a diagnosis into the payment processor. The rule is simple: the payment system gets an opaque visit ID and an amount, nothing clinical. The mapping from that ID back to "who and why" stays inside your HIPAA-covered platform. If you genuinely need PHI on the payment rail — say, for a healthcare-specific billing workflow — use a processor that will sign a BAA (InstaMed, Rectangle Health, and Sphere/TrustCommerce are common choices) rather than bending a general-purpose processor that won't [4].

The contract behind all of this is covered in Business Associate Agreements; the boundary it protects is the same one described in the compliance architecture pattern.

Figure 2. The two boundaries. The PCI boundary keeps card numbers out of your servers; the HIPAA boundary keeps PHI out of the payment processor. The leak is attaching a clinical reason to the charge — it pulls a no-BAA system into PHI scope.

Eligibility: know what the patient owes before the visit

Now switch to the insurance side, and start before the visit even happens. The worst time to discover that a patient's plan does not cover telehealth, or that their deductible is unmet and they owe the full visit cost, is after you have delivered care and the patient has logged off. The fix is an eligibility check — an automated question to the health plan that returns the patient's coverage and what they will owe.

This runs on a standardized message pair: the X12 270 is the inquiry your system sends ("is this member covered, and for what?"), and the X12 271 is the plan's response, which returns coverage status plus the financial details — the copay (a fixed per-visit amount), the coinsurance (a percentage the patient pays), and the deductible (what they must pay out of pocket before coverage kicks in), including how much of the deductible remains [1][5]. Because the Affordable Care Act's Section 1104 directed HHS to adopt operating rules for these transactions, plans are required to support real-time eligibility — the 271 comes back in seconds, not overnight, so you can check coverage while the patient is booking [5].

That real-time answer is what lets you collect the right copay at booking instead of mailing a surprise bill weeks later. Walk a simple example for a single visit:

Visit allowed amount:          $150
Patient deductible: met        → deductible portion = $0
Plan coinsurance: 20%          → patient owes 20% × $150 = $30
Copay (from the 271):          $25 flat for telehealth visits
Collect at booking:            $25 copay   (plan pays the rest)

The eligibility response tells you it is a flat \$25 copay, not the \$30 coinsurance, so you collect \$25 up front through the card path described above and bill the plan for the remainder. Get this wrong and you either under-collect (and chase the patient later, at a fraction of recovery) or over-charge (and issue refunds and erode trust). The eligibility check is cheap insurance against both.

Figure 3. From eligibility to copay. A real-time 270/271 exchange returns the patient's copay, coinsurance, and remaining deductible, so the right amount is collected at booking — not chased after the visit.

The claim: the 837, the clearinghouse, and the 835 loop

After the visit, you bill the plan. The bill is an X12 837 — the standard electronic health-care claim, mandated under 45 CFR § 162.1102 [1]. It comes in three flavors: 837P for professional services (the kind most telemedicine visits are), 837I for institutional, and 837D for dental [1]. The 837P carries the same information as the familiar paper CMS-1500 claim form maintained by the National Uniform Claim Committee — same data, electronic envelope [6].

You almost never send the 837 straight to the insurer. You send it to a clearinghouse — a service that connects to thousands of health plans, checks your claim's format, translates between variations, and routes it to the right payer. This is where a load-bearing compliance fact lives: under HIPAA, a health care clearinghouse is itself a covered entity that handles PHI on your behalf, so it must sign a BAA before it touches a single claim [7]. A claim is full of PHI — name, diagnosis codes, procedure codes — so the clearinghouse relationship is a PHI relationship, not a plumbing detail.

The claim then travels a defined loop, and each step has its own message:

The 835 — the Electronic Remittance Advice, or ERA — is the one that closes the loop: it tells you, claim line by claim line, what the plan paid, what it adjusted, and what it denied and why [1][8]. The actual money usually moves separately by electronic funds transfer (EFT) through the banking system, with the 835 as the explanation that lets your system auto-post the payment and reconcile. The sequence in practice is: 837 out → 999 confirms format → 277CA confirms acceptance → 835 brings the money and the math [8].

Figure 4. The claim lifecycle. The 837 claim flows out through a BAA-covered clearinghouse to the payer; the 999, 277CA, and 835 flow back. The clearinghouse is a HIPAA covered entity that handles your PHI.

Common mistake — one clearinghouse, no fallback. In February 2024, a ransomware attack on Change Healthcare — the largest US claims clearinghouse, touching roughly one in three patient records — froze claims nationwide for weeks and exposed data on an estimated 192.7 million people, after attackers entered through a remote-access portal that lacked multi-factor authentication [9]. Providers who routed every claim through that one path simply stopped getting paid. The lesson for a build: treat the clearinghouse as critical infrastructure, hold a BAA, and design so you can fail over to a second clearinghouse rather than betting your entire revenue cycle on one vendor.

Telehealth-specific billing: codes, modifiers, and the 2027 cliff

A telemedicine claim is a normal claim with two extra fields that say "this happened over video," and getting them wrong is the most common reason a clean visit gets denied. The first is the place-of-service (POS) code, which tells the payer where the visit occurred. For telehealth, Medicare uses POS 10 when the patient is at home and POS 02 when the patient is somewhere other than home; POS 10 generally pays at the higher non-facility rate [10]. The second is the modifier, a two-character code appended to the procedure: modifier 95 marks a synchronous audio-video visit (used mainly by commercial payers), and modifier 93 marks an audio-only visit, which Medicare requires for telephone-based care [10]. You cannot use modifier 95 for an audio-only call — that is a 93 — and mixing them up triggers denials [10].

Then comes the rule that humbles every roadmap: telehealth reimbursement is jurisdictional and dated, and it changes constantly. Medicare's pandemic-era telehealth flexibilities — letting patients be seen at home, anywhere in the country, rather than only in rural clinic sites — have been extended repeatedly by short-term legislation. After a lapse on February 1, 2026, Congress extended them again, and as of this writing they run through December 31, 2027 [11]. Commercial-payer and state-Medicaid rules differ from Medicare and from each other, and many ride on state "parity" laws that change yearly. The product implication: never hard-code a reimbursement rule. Treat coverage, POS codes, modifiers, and effective dates as configuration that a billing specialist can update, because the one certainty is that they will move. The broader picture of how these rules shape what you can build is in reimbursement and the rules that shape the product.

Choosing the money stack: who signs a BAA, and which PCI path

Two questions decide most of the architecture: does the vendor sign a BAA, and how much PCI scope does it leave you? The table below frames the common patient-payment processors against both. Insurance-claim connectivity (eligibility and the 837/835 loop) is a separate decision — a clearinghouse or a billing API such as Availity, Office Ally, or a modern EDI platform — and every option there must sign a BAA because the data is PHI by definition.

The pattern that works for most telemedicine builds: tokenize patient card payments through a general processor and keep that path PHI-free, and run all insurance-side traffic through a BAA-covered clearinghouse. You only need a BAA-signing payment processor if your billing workflow genuinely requires PHI on the card rail — which, for the common copay-and-self-pay case, it does not.

Where Fora Soft fits in

Fora Soft has built real-time video and clinical software since 2005, and in telemedicine the money layer is where two boundaries have to be drawn precisely: the PCI boundary that keeps card numbers off your servers, and the HIPAA boundary that keeps patient health data off your payment processor. We design the payment path to stay out of PHI scope by default — tokenized card capture, an opaque visit ID on every charge, and no clinical detail in any payment field — so the part of the system that touches cards stays small and cheap to certify. On the insurance side we wire eligibility (270/271) and the claim loop (837 out, 277CA and 835 back) through a BAA-covered clearinghouse, with the telehealth place-of-service and modifier logic kept as updatable configuration rather than buried in code, because reimbursement rules move every year.

What to read next

• The telemedicine integration map: what connects to what
• HL7 v2, FHIR, and the EHR integration reality
• Reimbursement and the rules that shape the product

Download the Telemedicine Payments & Claims Checklist (PDF)

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your telemedicine billing and payments plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Telemedicine Payments & Claims Checklist — One page to scope the money layer of a telemedicine product: the two money flows (PCI card path vs HIPAA claim path), the tokenization rule that keeps you in PCI SAQ A, the PHI-in-payment-metadata trap and the Stripe BAA stance, the….

References

1. 45 CFR Part 162 — Administrative Requirements (HIPAA Administrative Simplification: Transactions and Code Sets) — HHS / Code of Federal Regulations (eCFR). Mandates the standard electronic transactions: the health care claim (837) at subpart K (§ 162.1102), eligibility (270/271) at subpart L, claim status (276/277) at subpart N, referral/authorization (278) at subpart M, and the claim payment/remittance advice (835) at subpart P (§ 162.1602), all on ASC X12 Version 5010. The controlling source for healthcare EDI. Tier 1. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162
2. PCI DSS Compliance & tokenization (Stripe documentation) — Stripe. Describes how hosted fields (Stripe Elements / Checkout) tokenize card data so it never reaches the merchant's servers, reducing PCI scope. Vendor documentation, used for integration mechanics; re-verify before publish. Tier 4. https://stripe.com/guides/pci-compliance
3. PCI DSS v4.0.1 and the SAQ A / SAQ A-EP self-assessment questionnaires — PCI Security Standards Council. Defines the merchant self-assessment levels (SAQ A ≈ 24 requirements for fully outsourced/tokenized acceptance; SAQ A-EP ≈ 140 for merchants whose site affects card data) and the retirement of v3.2.1 on 2025-03-31. The card-industry standard (contractual, not statutory). Tier 3 (standards body). https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4-0-SAQ-A.pdf
4. Stripe and HIPAA — no Business Associate Agreement; keep PHI out of the payment rail — Stripe policy as reported across compliance guidance. Stripe does not sign a BAA and instructs customers not to send PHI; a bare payment (amount + token) is a financial transaction, not PHI, but attaching clinical detail creates PHI on a no-BAA system. For PHI-on-rail workflows, use BAA-signing healthcare processors (InstaMed, Rectangle Health, Sphere/TrustCommerce). Vendor-policy reporting; re-verify Stripe's current BAA stance before publish. Tier 4. https://www.accountablehq.com/post/is-stripe-hipaa-compliant-a-guide-with-best-practices-and-compliance-tips
5. CAQH CORE Eligibility & Benefits (270/271) Operating Rules and ACA Section 1104 — CAQH CORE (HHS-designated operating-rule authoring entity). Section 1104 of the Affordable Care Act directed HHS to adopt operating rules requiring real-time processing of the X12 270/271 eligibility and 276/277 claim-status transactions; the 271 returns copay, coinsurance, and base/remaining deductible. Tier 1 (statutory mandate) / Tier 3 (operating-rule text). https://www.caqh.org/core/operating-rules
6. Medicare Billing: Form CMS-1500 and the 837P — Centers for Medicare & Medicaid Services (MLN006976). The 837P is the electronic professional claim carrying the same data as the NUCC-maintained CMS-1500 form, in ASC X12N 5010A1. Tier 2 (agency guidance). https://www.cms.gov/files/document/mln006976-medicare-billing-cms-1500-837p.pdf
7. 45 CFR § 160.103 — Definition of "health care clearinghouse" — HHS / Code of Federal Regulations. A clearinghouse is a HIPAA covered entity that processes health information (e.g., standard claim transactions) on behalf of others; handling claims on your behalf requires a Business Associate Agreement. Tier 1. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103
8. The electronic claim lifecycle: 837 → 999 → 277CA → 835 (ERA) — CMS / ASC X12 standard workflow (via CMS EDI companion guidance). The 999 confirms file syntax, the 277CA acknowledges claim acceptance/rejection, and the 835 remittance advice reports paid/adjusted/denied amounts, with money typically moving by EFT. Tier 2 (agency/standard guidance). https://www.cms.gov/files/document/837p-cms-1500pdf
9. Change Healthcare ransomware attack (February 2024) — HHS OCR breach reporting and contemporaneous coverage. A ransomware attack on the largest US claims clearinghouse, entered via a Citrix portal lacking multi-factor authentication, froze claims nationwide and exposed data on an estimated 192.7 million individuals. Illustrates single-clearinghouse dependency risk. Tier 5 (incident reporting; underlying OCR investigation tier 1). https://www.hipaajournal.com/change-healthcare-responding-to-cyberattack/
10. Telehealth place-of-service codes and modifiers (POS 02/10, modifier 95/93) — CMS telehealth billing guidance. POS 10 (patient at home) vs POS 02 (patient not at home); modifier 95 for synchronous audio-video, modifier 93 for audio-only (Medicare). Jurisdictional and revised annually; re-verify the current year before publish. Tier 2 (agency guidance). https://www.cms.gov/medicare/coverage/telehealth
11. Medicare telehealth flexibilities extended through December 31, 2027 (Continuing Appropriations Act, 2026) — Congressional appropriations as reported by health-law analysts. After a lapse on 2026-02-01, the home/geographic/originating-site flexibilities were extended through 2027-12-31. Time-sensitive — re-verify the current expiry before publish. Tier 5 (legal analysis; underlying statute tier 1). https://natlawreview.com/article/continuing-appropriations-act-2026-another-lifeline-medicare-telehealth

Per the source hierarchy, the mandated EDI transactions and the clearinghouse definition are cited to the CFR (refs 1, 7, tier 1); the real-time eligibility mandate to the ACA Section 1104 statute and CAQH CORE operating rules (ref 5, tier 1/3); the claim form and lifecycle to CMS guidance and the X12 standard (refs 6, 8, tier 2); the telehealth codes and the 2027 reimbursement window to CMS guidance and appropriations analysis (refs 10–11, tier 2/5, both flagged for re-verification); and PCI scope, the Stripe BAA stance, and the Change Healthcare incident to the PCI SSC standard, vendor policy, and breach reporting (refs 2–4, 9, tier 3–5). Of 11 sources, 4 are tier-1 primary regulatory/statutory documents (36%), and every binding compliance claim — the EDI mandate, the clearinghouse-as-covered-entity rule, the eligibility mandate, and the PHI boundary — traces to a primary regulatory or statutory source.