The Clearinghouse Is Not the Payer Platform

Cloud Health Office is the claims operating system a health plan actually runs. Stedi is one of the networks it can speak.

The question investors actually ask

Healthcare investors do not diligence a clearinghouse the way they diligence a payer platform. A pipe that can post an 837 is necessary and nowhere near sufficient. The strict criteria usually sound like this:

• Can you determine eligibility in real time?
• Can you accept professional, institutional, and dental claims?
• Can you tell a provider the claim was accepted into processing without pretending it was paid?
• Can you ask where it is, attach documentation, and receive an ERA?
• Can you keep tenants apart and keep PHI out of logs?
• Can you speak FHIR for CMS-0057-F without abandoning X12?
• If the clearinghouse changes, does the product die?

That last question is the trap. Wrap Stedi too tightly and you have rented a network, not built a platform. Rebuild QNXT and you have a ten-year migration. Cloud Health Office is the third shape: a source-available claims platform with a replaceable network adapter.

Ninety seconds on what CHO is

Cloud Health Office is a Kubernetes-native, multi-tenant claims administration platform. It does the work a health plan actually has to do after the EDI file arrives: interpret eligibility, ingest the claim, adjudicate against a versioned benefit plan, price against fee schedules, apply NCCI and COB, persist a lifecycle, and expose FHIR APIs for CMS-0057-F.

It is source-available under BSL 1.1. It deploys in the plan’s cloud. It is designed to sit beside QNXT, Facets, or HealthEdge as a compliance and modernization layer, or to run as a full claims stack for a new entrant.

The Million Claim Challenge already showed the adjudication core can carry a million mixed claims through Azure Service Bus on a local Kubernetes cluster, with inspectable evidence. This field note is the other half of the same argument: the platform can also talk to the industry without becoming the industry’s clearinghouse.

The boundary that makes the platform valuable

Every Stedi PR in this sequence obeyed one architectural rule: CHO owns the healthcare business. The gateway owns transport and translation. Canonical request and response models never contain a vendor name. A guard test fails the build if they do.

That sounds academic until you price vendor lock-in. A health plan that embeds Stedi DTOs in its claim aggregate cannot change networks without rewriting adjudication. A health plan that talks to IClaimSubmissionGateway can add Availity later the way CHO added Stedi: an adapter, not a product rewrite.

One claim life, six transactions

A real claim is not one API call. It is a life:

1. 270/271 — is the member covered?
2. 837 — submit professional, institutional, or dental.
3. 277CA — accepted or rejected into processing. Not paid.
4. 276/277 — where is it now? Status is not remittance.
5. 275 — outbound documents, and inbound receive when CHO is the payer.
6. 835 — what was allowed, paid, and left to the patient. Stored, not posted.

Most “EDI platforms” collapse those into a single status field. CHO keeps them distinct on purpose. That is how you avoid the lie that kills trust with providers: calling a clearinghouse acceptance a payment.

Claim intelligence is the product surface

A dental practice, a provider portal, and a payer operations queue should not have to understand CLP02. They need a sentence: processing, pending information, paid, denied. They need a timeline. They need to know whether documentation arrived. They need patient responsibility when an ERA exists, and “unknown” when it does not.

GET /api/claims/{claimId}/intelligence is that sentence. It rebuilds from the transaction stores. It is not a second database of truth. Duplicate 277CA or 835 deliveries do not duplicate the timeline, because event ids are the source record ids — status lives on the payload, not in the identity.

Two rules from that PR are the ones to say out loud in a diligence room:

• 277CA Accepted is not Paid.
• 276/277 Paid does not create an 835.

Those are not slogans. They are tests. They are why a healthcare investor can believe the rest of the lifecycle.

What we refused to fake

The Million Claim Challenge series is useful here as a method, not just a number. We publish limitations in the same breath as results. For Stedi:

• CI never calls live Stedi. Contract tests use documented JSON and stubbed HTTP.
• Stedi test keys are not supported for 276/277. Live inquiry needs production/test capability.
• Live 835 retrieve needs ERA enrollment and a real transaction id. Sandbox accounts do not produce that ERA.
• Inbound payer-side 275 through Stedi is adapter-ready. The CHO receiver is real; Stedi’s public inbound 275 path is not claimed.
• Payment posting, EFT reconciliation, and accumulator writes from 835s are explicitly later work.
• The provider portal UI is not this PR. The API is the reusable layer CDO will consume.

That list is how you tell a serious healthcare investor you are not selling a demo that collapses in underwriting.

Why this is the valuable platform

The value is not “we integrated Stedi.” Plenty of teams can post an 837. The value is the combination:

1. A complete claim life — eligibility through remittance — as distinct facts.
2. A healthcare business layer that already adjudicates, prices, and scores at million-claim evidence scale.
3. A replaceable network so the plan is not married to one clearinghouse.
4. A workflow API that CloudDentalOffice and a provider portal can use without becoming EDI companies.
5. CMS-0057-F FHIR on the same platform, so compliance is an on-ramp rather than a side project.
6. Source you can read. The PRs, the evidence docs, and the Million Claim Challenge packets are public.

For a capital-markets conversation, that is the underwriting story. The clearinghouse is a cost of doing business. The platform is the asset: tenant-safe claims operations that a health plan, a TPA, or a dental network can run, inspect, and extend.

Stedi made the wire real this month. Cloud Health Office is what the wire is for.