This edition centers on four converging forces: clinical data access, regulatory shifts, infrastructure constraints, and agentic workflows.
First-Party Clinical Data: Strategic Asset or Shared Resource?
One of the themes I keep coming back to is the growing constraint around first-party clinical data, specifically ownership and access within health system EMR ecosystems.
This has surfaced repeatedly in conversations with medical device companies and community providers who don’t have access to clinical EMR data.
The result is a bit of a paradox: these organizations are generating clinically meaningful signals, but don’t have the underlying data access needed to validate, iterate, or scale them.
Meanwhile, data owners are moving up the value chain.
CB Insights’ Pharma–Health System Strategy Maps 2026 captures this shift well. As margin pressure builds, health systems are moving from stewards of clinical data to vendors of it. Data infrastructure now delivers value twice: internally through predictive tools and externally through monetization.
Providence (Ahavi) and Mayo Clinic (Platform_Insights) are licensing de-identified datasets to pharma and AI developers.
HCA is leveraging its 43 million annual encounters to power CareIntellect Perinatal for real-time maternal risk prediction.
But health systems aren’t shifting into data vendors in a vacuum; they are doing it within the confines of their EMR vendors. Epic alone controls nearly 57% of all U.S. hospital beds, and dominates the major academic medical centers where the richest clinical data lives, effectively mediating both commercial and architectural boundaries.

Supported by Runtime Revolution, an engineering partner for healthcare teams building clinical platforms and patient-facing products
TEFCA: The Intended Solution Under Strain
TEFCA (The Trusted Exchange Framework and Common Agreement) was supposed to be the unlock—standardized access to patient data under a “treatment purpose.”
In reality, that path is getting narrower.
Recent disputes (Particle Health, Health Gorilla) point to a deeper issue: who actually qualifies as a “provider,” what counts as legitimate treatment use, and whether participants are truly giving something back.
Because at its core, TEFCA is built on reciprocity. You give data, you get value.
I was reminded of this during earlier work with provider networks under TPO (Treatment, Payment, Operations). To gain access to EMR data at the time, we had to build dashboards - something tangible that providers could use in return.
For third parties operating under a covered entity Business Associate Agreement (BAA) such as community organizations, medical device firms, and healthcare app developers, the bar is clearly rising. Beyond restrictive BAA terms, Epic is enforcing a redirect flow, requiring users to actively log into a MyChart portal to authorize what data gets released.
FDA and TEFCA Pull in Different Directions
TEFCA was designed to expand access to health data through standardized exchange. At the same time, the FDA is raising expectations around provenance, traceability, and evidence quality through its evolving Real-World Evidence (RWE) framework.
In theory, those goals should be complementary.
In practice, there is a growing disconnect.
When data flows through TEFCA, it often shows up as summaries, with patient matching challenges and limited granularity—rather than clean, discrete FHIR-level data.
That makes it hard to use for real-time AI or even robust retrospective models.
So there’s a tension building: the FDA is raising the bar on provenance and evidence quality, while the actual data pipelines many teams rely on aren’t designed to meet that bar.
Which raises a harder question: how do you establish FDA-grade provenance when the data itself is third-party, fragmented, and not fully traceable?
Agentic AI Meets Technical Debt
Then there’s what’s happening inside organizations.
Teams are now being asked to build agentic workflows—systems that can reason, act, and deliver ROI in near real time. But many are doing this on top of infrastructure built for a very different era.
I was in a conversation recently where technical debt came up, and the question was simple but uncomfortable: how do you steer teams who’ve spent years building and maintaining systems that no longer match current needs?
Do you rip and replace, or incrementally modernize?
The fundamentals still matter—data models, compute, latency, system design — but the constraints have shifted. What worked in 2015 doesn’t hold in 2026.
Latency, in particular, has become the silent killer. If retrieval takes 20–30 seconds because of middleware or fragmented systems, agentic workflows break down completely.
There are attempts to bridge this. Model Context Protocol (MCP), for example, introduces a new integration layer—essentially a governed interface between AI models and clinical systems that allows structured access to clinical data through permissioned APIs and an auditable layer for how data is retrieved and used.
Look at ambient and predictive AI adoption: nearly two-thirds of Epic-using hospitals have already deployed native ambient AI tools because the infrastructure layer is already optimized for minimal latency. For third-party AI developers, the hurdle isn't just proving their model works; it's proving their agent can reason faster through a third-party API than a native Epic feature running directly in the clinical workflow.
It’s a compelling direction, but likely not sufficient on its own. MCP can unify access, but it doesn’t erase fragmentation, decades of technical debt, or the need for strong governance.
Which is why most organizations are converging on the same reality: this is a build, buy, and partner problem—and the answer is probably a hybrid.
Modernize where you must, layer in AI-native systems where you can, and be deliberate about where integration actually creates leverage.
Till next month,
Clinical to Commercial