Hubble

Healthcare data has a discovery problem. Not just in the sense of finding the right record, but in the sense of reaching the systems where that record actually lives. Most patient-data APIs stop at the EHR — Epic, Cerner, athenahealth — and call it a day. Hubble, a Y Combinator-backed startup (YC Summer 2026), is making a different bet: that the future of healthcare data access is patient-mediated, and that the patient, not the vendor, is the true integration point.

The company's pitch is blunt: "Retrieve medical records other APIs can't." It's a claim that hinges on a specific architectural choice — one that treats the patient's right of access as the legal foundation for data retrieval, and then layers on browser and voice automation to reach sources that have no public API at all.

The missing layer in healthcare's API story

For years, the healthcare API narrative has been dominated by FHIR — the standard for exchanging electronic health records. But FHIR has a ceiling. It works when the data is in a system that exposes a FHIR endpoint, and when the requesting party has the right credentials. In practice, that leaves out a vast amount of patient data: payer claims, eligibility details, coverage information, and records stored in systems that predate modern interoperability standards.

Hubble positions itself as "the intelligence layer for patient information" — a layer that sits above the fragmented infrastructure of EHRs and payers, and normalizes data from multiple sources into a single, traceable record. The website lists Epic, Oracle Health (Cerner), athenahealth, UnitedHealthcare, and Aetna as connected systems, with "+ more" suggesting a broader footprint. The claim is not that Hubble replaces these systems, but that it reaches them through whatever interface is available: API, browser, or voice.

This is a meaningful distinction. Most API companies build connectors to well-documented endpoints. Hubble's approach implies a more aggressive strategy: using browser automation to interact with systems that lack public APIs, and voice to handle phone-based workflows. That's not just a technical difference — it's a philosophical one about how far a company will go to retrieve a patient's data.

Patient-mediated access: the legal spine that makes Hubble possible

Hubble's model rests on a legal concept that predates the API era: the patient's right of access. Under HIPAA and, more recently, TEFCA's Individual Access Services, patients have the right to obtain their own medical records and direct them to a third party. Hubble's blog posts explicitly frame this as the "legal spine" of patient-mediated access.

The workflow is simple from the user's perspective: a patient verifies their identity once, and Hubble returns their medical records through a single API. But behind that simplicity is a complex orchestration. The patient authorizes access, Hubble reaches into the relevant systems, retrieves the data, and normalizes it into a structured format. The company emphasizes that this is "patient-mediated" — meaning the patient is an active participant in the data flow, not just a passive subject.

This is a clever regulatory hack, but it's also a genuine product insight. By making the patient the integration point, Hubble sidesteps the need for direct vendor partnerships or complex business associate agreements with every EHR. The patient's consent becomes the key that unlocks the data.

Why FHIR-only APIs hit a ceiling

The limitations of FHIR are well-known to anyone who has tried to build a health app. FHIR is a standard, but it's not a universal one. Many systems don't expose FHIR endpoints, and those that do often have inconsistent data models. Payers, in particular, are notorious for their legacy systems and lack of modern APIs.

Hubble's differentiation is that it doesn't rely on FHIR alone. The website lists "APIs, browser, and voice" as the three channels it uses to reach data sources. This multi-pronged approach is what allows Hubble to claim it can retrieve records "other APIs can't." It's not just a FHIR wrapper; it's a data retrieval engine that adapts to the source.

The tradeoff is complexity. Browser automation is fragile, and voice interactions are even more so. But if Hubble can make this work reliably, it has a moat that FHIR-only competitors can't easily replicate.

One record, four sources: how Hubble's assembly model works

The website includes a compelling illustration: a single patient record assembled from four sources — Epic, athenahealth, UnitedHealthcare, and Aetna. Each field is tagged with its source: name and DOB from Epic, last encounter from athena, coverage from UHC, and eligibility from Aetna. This is Hubble's core value proposition: not just retrieving data, but assembling it into a coherent whole.

The emphasis on "every field traceable to its source" is a governance feature. In healthcare, knowing where a piece of data came from is critical for clinical decision-making and compliance. Hubble's audit trail is not an afterthought; it's a core part of the product.

This assembly model also enables the "Workflows" product — a no-code studio for ops teams. The idea is that non-technical users can compose workflows in plain language and run them on Hubble's data infrastructure. This extends the platform beyond developers to the operations teams that are often the ones actually dealing with data retrieval.

The name as a promise: Hubble and the expanding view of patient data

The name "Hubble" evokes the space telescope, which expanded humanity's view of the universe. The implication is that this company expands the view of patient data — pulling in information from sources that were previously invisible. It's a strong name for a data aggregation platform, and it fits the "intelligence layer" positioning.

The domain, hubble.ai, is clean and memorable. The .ai extension reinforces the AI angle, though the product is more about data infrastructure than AI per se. The name is distinctive enough to avoid confusion with the Hubble Space Telescope, though there is a slight risk of trademark overlap in the future.

Overall, the naming is a plus: it's short, evocative, and hints at the product's core function of seeing the whole picture.

What Hubble doesn't say: the open questions

The website is light on specifics about security architecture, uptime, and pricing. It claims HIPAA compliance and an audit trail, but doesn't detail the technical measures in place. For a healthcare product, these are critical considerations.

There's also the question of how Hubble handles the fragility of browser and voice automation. If a source system changes its UI, does the integration break? The company doesn't address this directly, but it's a risk that potential customers should probe.

Finally, the YC Summer 2026 batch is a signal of early-stage validation, but it's not a guarantee of long-term viability. Hubble will need to prove that its patient-mediated model can scale beyond the early adopters.

For digital health companies and ops teams tired of wrestling with fragmented data, Hubble offers a compelling alternative. It's a bet on the patient as the ultimate integration point — and if it works, it could indeed retrieve the records other APIs can't.