The revealing detail in 1upHealth’s story is a letter. In a case study published in May 2024, an unnamed health insurer had invested in a Patient Access API, a service that lets members retrieve their health information through apps. Usage was low. The insurer added website instructions, a video, and physical mailers. During one communications push, monthly utilization rose by more than 3,000% against the average of preceding months. The plumbing had existed. People needed an invitation.
- 1upHealth sells the infrastructure that moves clinical and claims data between healthcare organizations.
- Its current focus is payer operations, from regulatory APIs to continuous clinical data acquisition.
- The useful lesson: budget for connections and adoption alongside the software.
The letter that moved the numbers
There is a temptation to read that percentage as a victory for software. It is more interesting as a lesson in distribution. The insurer explained where members should go, which apps they could use, and how to get help. Letters went out in phases, allowing the campaign to improve. A very modern service acquired an old-fashioned publicist.
The result is company-reported, from an unnamed payer, without raw usage counts. It cannot establish lasting engagement or better health outcomes. Still, the sequence matters: access came first; explanation followed; usage changed. Anyone launching an obscure but useful service can copy that order of operations, preferably with clearer measurement from the start.
A bet on a common language
Founded in 2017 by Ricky Sahu and Gajen Sunthara, 1upHealth chose FHIR, the healthcare data standard pronounced “fire,” as its foundation. FHIR stands for Fast Healthcare Interoperability Resources. Think of it as a shared vocabulary and set of conventions that lets software ask for health information without inventing a separate language for every institution.
The founders brought relevant experience. Sahu had worked at Google and led engineering at CareJourney. Sunthara had spent years working on electronic health records at Boston Children’s Hospital and on federal interoperability initiatives. This was a business built around the awkward distance between possessing a medical record and being able to use it elsewhere.
Regulation gave that distance commercial urgency. Federal rules required certain payers to make data available through standardized APIs. CMS-0057-F extends the requirements to provider access, payer-to-payer exchange, and prior authorization, with API compliance dates generally beginning January 1, 2027. A deadline creates buyers; a useful product must survive the deadline.
“We take on complexity so you don’t have to.”1upHealth’s stated proposition
Why a lakehouse belongs in healthcare
1upHealth’s answer is a managed data platform. It takes in clinical, claims, and financial information, organizes records, applies quality checks, and governs who can access them. Customers can exchange information through APIs or feed it into existing analytics and operational systems. The customer buys a maintained service and implementation expertise, rather than assembling every component independently.
In March 2025, the company introduced a new platform built around lakehouse architecture. The ungainly name describes a practical combination: the querying strengths of a data warehouse with the flexibility to handle less tidy data. The release added detailed audit trails, quality gates, and ingestion recovery from the last successful step. Those features address the expensive, repetitive work of finding where a record went wrong.
The company reported more than 90 customer organizations when announcing that release. Earlier disclosures included health plans, accountable care organizations, clinical researchers, and state Medicaid agencies. The newer website concentrates on payers. Its argument is that the same data foundation can support compliance today and quality, risk adjustment, and care management tomorrow.
Conceptual workflow, not a performance benchmark.
The patient record gets a second opinion
In September 2026, 1upHealth launched Clinical Connect, with Capital Health Plan as its first announced user. The Florida insurer serves more than 135,000 members. The product retrieves clinical information from participating provider systems, including Epic and athenahealth, and joins it with claims in a longitudinal member record.
The distinction matters. A claim records a billing event; clinical information can add the result, measurement, or context needed to interpret care. Clinical Connect is intended to help plans find completed care that claims miss, identify gaps, and support quality measurement. Better visibility is the mechanism. Improved scores remain an outcome to demonstrate, rather than a prize automatically delivered with installation.
Another product took the opposite architectural route. Announced in July 2026, Gateway places a managed API and compliance layer in front of a plan’s existing FHIR-capable endpoints. Organizations that have already invested in infrastructure can retain it. The company sells the operational work around those endpoints: onboarding outside parties, maintaining connections, reporting, and auditing.
Selling the work between the endpoints
This is enterprise SaaS with a substantial service component. The 2025 platform is hosted in AWS; customer teams help implement and maintain data pipelines. Pricing is negotiated. The public financing is easier to count: a $2.4 million seed round, an $8 million Series A, a $25 million Series B, and a $40 million Series C led by Sixth Street Growth in April 2023. Investment capital says little about a particular customer’s bill.
The alternatives include internal development, cloud FHIR services, and interoperability vendors with overlapping capabilities. 1upHealth’s pitch combines a data foundation with payer-specific operating experience. Its partner program adds another route to market: Inovalon, UST, and AXIOM Systems joined in August 2026, bringing client relationships to infrastructure they need not build themselves.
Build the service, then invite people in
There is also a deliberate narrowing. Documentation says Patient Connect, the patient-mediated aggregation product, stopped being sold and was scheduled to sunset on September 30, 2026, with support through existing agreements. Patient Access remains a separate current offering. The stated reason is expansion of payer interoperability solutions. The public record supports a strategic shift, without requiring an invented tale of failure.
The limits are ordinary and consequential. Provider participation, permissions, complete records, and usable workflows still matter. An API cannot persuade a missing counterparty to exchange data. Nor can a quality gate supply a clinical result that never arrives. For buyers, the sensible questions concern live connections, actual retrieval, and sustained use. For everyone else, the letter remains instructive: an elegant piece of infrastructure can wait quietly until somebody explains what to do with it.