- Commercial payer tailwind: GLP-1 cost and utilization have broken the old formulary model, forcing employers, carriers, and PBMs to rebuild benefit design around eligibility, adherence, and outcomes logic rather than yes/no coverage.

- Cost anchor: KFF 2025 data shows 43% of firms with 5,000+ workers cover GLP-1s for weight loss (up from 28% in 2024), 59% report usage higher than expected, and 66% say the spend impact is significant. Mercer shows 77% of large employers say managing GLP-1 cost is extremely or very important for 2026.

- Employer-as-payer: 34% of firms covering GLP-1s now require dietitian, case mgmt, therapy, or lifestyle participation (up from 10% the year prior). Business Group on Health reports 79% of large employers have seen GLP-1 uptick with flat obesity-indication coverage and more utilization mgmt.

- Indication fragmentation: Wegovy added CV risk reduction (2024) and noncirrhotic MASH with F2-F3 fibrosis (2025); Zepbound got moderate-to-severe OSA in adults w/ obesity (Dec 2024). Each indication carries a different medical-necessity narrative and cost-offset story.

- Incumbent infrastructure already exists: Evernorth EncircleRx has 9M enrolled lives, offers a 15% cost cap or 3:1 savings guarantee, has saved plans ~$200M since 2024; Evernorth also added a $200 patient-copay cap on Wegovy and Zepbound in 2025. Optum Rx’s Weight Engage pairs GLP-1 access with obesity specialist navigation, coaching, and lifestyle programs. UHC Total Weight Support requires coaching engagement (Real Appeal Rx or WeightWatchers for Business) as a coverage gate.

- Manufacturer channel-war: Lilly Employer Connect (Mar 5, 2026) goes direct-to-employer at $449/dose Zepbound KwikPen with 15+ program administrators including GoodRx, Cost Plus Drugs, Teladoc, Calibrate, Form Health, 9amHealth, Waltz. Novo Nordisk is running a parallel DTE play with Waltz Health and 9amHealth (launched Jan 1, 2026 model).

- Persistence problem: Meta-regression data shows ~50% GLP-1 discontinuation within 1yr and ~60% of lost weight regained within 12 mo of cessation. Prime Therapeutics’ 3yr data cited by Mercer shows only 1-in-12 still on therapy after three years. That is the entire ROI problem in one stat.

- Build opportunity: utilization mgmt infra, outcomes-based contracting rails, indication-specific cardiometabolic programs (CV, OSA, MASH, perimenopause, prediabetes), adherence/tapering/discontinuation systems, and employer-side financing or subsidy products.

Table of contents

Why the old pharmacy benefit model cannot hold

What the KFF and Business Group data actually shows

How self-insured employers became micro-payers

The indication map: obesity, CV, OSA, MASH

Incumbent payer and PBM playbooks: EncircleRx, Weight Engage, Total Weight Support

Manufacturer counter-moves: Lilly Employer Connect and the Novo/Waltz direct channel

The persistence and discontinuation problem

Where the infrastructure and platform opportunities actually sit

Risks, skepticism, and things that could blow up the thesis

Closing take

Why the old pharmacy benefit model cannot hold

The thing worth saying up front is that GLP-1 economics are not just “expensive drug, same playbook.” They break the playbook. Pharmacy benefit managers were built to manage formularies of drugs where the eligible population is bounded, utilization is fairly predictable, and the plan sponsor mostly just needs a tier, a prior auth, and a rebate story. GLP-1s blow up every assumption in that stack. The eligible population is enormous (KFF estimates 36.2 million commercially insured adults have a BMI that would medically qualify them), the cost is recurring at roughly $1,000 to $1,200+ per month list, persistence is uncertain, and the indications keep expanding into territory that is harder to refuse (cardiovascular risk reduction, obstructive sleep apnea, noncirrhotic MASH). Put that all together and the plan sponsor cannot realistically answer a simple yes/no question about coverage anymore. What they have to answer is: which population, under what diagnostic threshold, through which channel, with what behavioral gate, at what subsidy level, for how long, and with what stop rule. That is a different product than a formulary. It is an operating model.

The KFF 2025 Employer Health Benefits Survey made the shape of the problem very concrete. Among firms with 5,000 or more workers, 43% cover GLP-1 agonists primarily for weight loss, up from 28% the prior year. Among the firms that do cover, 59% say use has been higher than expected and 66% say the impact on prescription spending has been significant. One employer told KFF the class went from its 32nd biggest drug spend line to its single biggest in one year. That is not a trend curve; that is a cliff. The behavioral reaction is exactly what anyone watching benefits design for a decade would predict: sponsors are not so much de-covering as re-covering with more logic bolted on.

What the KFF and Business Group data actually shows

Read more

For decades, the United States healthcare system has operated without a single authoritative, machine-readable directory of its providers. Hospitals, insurers, health systems, and technology companies each maintained their own proprietary provider databases - expensive to build, difficult to maintain, and impossible to reconcile with one another. A physician might appear in dozens of databases simultaneously, each with slightly different information about their specialty, location, affiliations, and contact details. This fragmentation imposed enormous costs on the system: prior authorization delays, misdirected referrals, failed care coordination, and billions of dollars spent annually on provider data management by organizations that would rather spend that money on care.

On April 9, 2026, the Centers for Medicare and Medicaid Services (CMS) released the National Provider Directory (NPD) - a single, public, FHIR-formatted dataset containing every Medicare-enrolled provider in the United States. The release, available at https://directory.cms.gov is the most comprehensive public healthcare provider dataset ever assembled. It contains 27,204,567 records across six FHIR resource types, compressed to 2.8 gigabytes and freely downloadable by anyone.

This essay presents the results of a complete analysis of every record in the dataset - not a sample, not an approximation, but a full population analysis of all 27.2 million records. The analysis was conducted using Python streaming scripts, with the most computationally intensive cross-resource graph linkage analysis run on GitHub Actions cloud infrastructure to avoid local compute constraints. The findings reveal both the extraordinary power of what CMS has released and the significant gaps that remain - gaps that represent direct entrepreneurial opportunities for health technology builders.

Alongside this analysis, a working prototype was built to make the data tangible and interactive: the CMS NPD Explorer, available at onhealthcare.manus.space. The application is a six-page React 19 web application built with TypeScript, Tailwind CSS 4, and Recharts, deployed on Manus cloud infrastructure. It was designed with a Federal Data Observatory aesthetic - a deep navy sidebar, Source Serif 4 display typography paired with DM Sans for body text, and a dark-on-light color system that evokes institutional precision rather than consumer-product softness. The site includes an Overview Dashboard displaying all 27.2 million records across the six resource types with live summary statistics; a Practitioners Explorer with searchable and filterable tables across specialty, qualification, gender, and enrollment status; an Organizations Directory with state distribution charts and organizational size breakdowns; a FHIR Endpoints Directory showing EHR vendor market share, endpoint status, and FHIR version distributions; an Analytics Dashboard with six interactive visualizations covering the full dataset; and a Data Model Reference documenting the complete FHIR schema and cross-resource relationship structure. The prototype was built entirely from the raw NPD data - no third-party data enrichment, no commercial provider database - demonstrating that a functional, production-quality provider intelligence application can be built on this public foundation alone.

II. What Was Released: The Six FHIR Resources

The NPD is structured around six FHIR R4 resource types, each capturing a different dimension of the provider ecosystem. Understanding what each resource contains - and what it deliberately omits - is essential for anyone seeking to build on this data.

The format is NDJSON (newline-delimited JSON) compressed with Zstandard at level 12 - a modern, high-ratio compression algorithm that achieves roughly 14:1 compression on these files. Each line in each file is a complete, self-contained FHIR resource. The data was released under a public domain license with no restrictions on use.

III. The Practitioner File: 7.4 Million Individual Providers

The Practitioner file is the backbone of the dataset. With 7,441,212 records, it represents the most comprehensive enumeration of US healthcare providers ever made publicly available. Each record contains a National Provider Identifier (NPI), name, qualifications, specialties, and a set of CMS-specific extensions that reveal the provider's enrollment status.

The Workforce Demographics

The gender distribution is striking: 67.42% of practitioners are female (5,016,631 women) versus 32.14% male (2,389,498 men), with 0.44% unknown. This is not a sample artifact - it was confirmed across all 7.44 million records. It reflects the well-documented feminization of the healthcare workforce, particularly in nursing, behavioral health, and allied health professions, which together constitute the majority of Medicare-enrolled providers.

The qualification landscape reveals the true shape of the modern US healthcare workforce. Nurse Practitioners (NPs) are the single largest specialty category at 8.8% of all practitioners, reflecting two decades of scope-of-practice expansion and the growing reliance on NPs for primary care delivery. The second-largest qualification type, at 8.53%, is Behavior Technician - a finding that would surprise most healthcare observers. This reflects the explosive growth of Applied Behavior Analysis (ABA) therapy for autism spectrum disorder, which became a covered benefit under most state Medicaid programs and commercial insurance plans during the 2010s. The presence of nearly 635,000 behavior technicians in the Medicare enrollment database is a direct artifact of that policy shift.

NPI enrollment peaked in 2006, the year after the NPI mandate took effect under HIPAA, with 1,009,174 new enrollments. The distribution of enrollment years provides a natural audit trail: practitioners enrolled before 2004 are almost certainly physicians or other long-established provider types, while the post-2010 surge reflects the expansion of covered provider categories.

The CMS Enrollment Quality Extensions

Every Practitioner record carries four CMS-specific boolean extensions that have no equivalent in any prior public dataset:

The enrollment-in-good-standing rate of 39.75% is the most consequential finding in the entire dataset. It means that 60.25% of Medicare-enrolled providers — more than 4.4 million practitioners — have some form of enrollment issue. This could mean lapsed enrollment, pending revalidation, excluded status, or simply administrative backlog. For any application that needs to distinguish active, billable providers from historical records, this field is essential.

The IAL2 verification rate of 0% is a statement about the current state of healthcare identity infrastructure. NIST Identity Assurance Level 2 requires in-person or supervised remote identity proofing with document verification. The fact that no provider in the entire dataset has been verified to this standard reflects both the scale of the challenge and the opportunity for identity verification services in healthcare.

What Is Missing from Practitioner Records

The Practitioner file is notable for what it does not contain. Birth dates are absent from all 7.44 million records - a complete absence, not a gap. Languages spoken are present on only 2.8% of records. Photos are absent entirely. Accepting-new-patients status is absent. These omissions are not accidental; they reflect the deliberate scope of the initial release, which prioritized enrollment data over clinical or operational data.

IV. The PractitionerRole File: 7.2 Million Relationships and Their Surprising Fragility

The PractitionerRole resource is where the dataset's most surprising structural finding lives. With 7,180,732 records, it contains one relationship record for each practitioner-organization pairing in the Medicare enrollment system. But 44.85% of all PractitionerRole records are inactive - 3,220,444 records describe historical relationships that no longer exist.

This is not a data quality problem. It is a deliberate design choice: the NPD preserves the full historical record of provider affiliations, not just current relationships. For longitudinal research, this is invaluable. For applications that need to know where a provider works today, it requires careful filtering on the `active` field.

The Linkage Structure

The cross-resource graph analysis, run on GitHub Actions across all 7.18 million PractitionerRole records, reveals the connectivity structure of the dataset:

Every PractitionerRole record has a practitioner reference. 97.99% have an organization reference. 77.21% have a location reference. This means that for 77.21% of all provider-organization relationships, there is a complete three-way link connecting a specific person to a specific organization at a specific location.

The Practitioner Connectivity Gap

When the analysis is inverted - asking how many of the 7.44 million practitioners have any organizational linkage - the picture becomes more complex:

Only 28.70% of practitioners in the dataset are linked to any organization through PractitionerRole records. The remaining 71.30% - more than 5.3 million practitioners - appear in the Practitioner file but have no corresponding PractitionerRole record linking them to an organization or location. This is the single most important structural finding in the dataset: the majority of practitioners are "orphaned" - present in the directory but not connected to any organizational context.

This gap is partly explained by the enrollment history: many of these practitioners may have enrolled in Medicare but never established an active organizational affiliation, or their affiliations may have lapsed. It is also partly a data completeness issue - the NPD is a first release, and the linkage infrastructure between CMS enrollment systems and organizational data is still being built.

For entrepreneurs, this gap is an opportunity. Any application that can accurately link orphaned practitioners to their current organizations - through claims data, state licensing databases, or other sources - would be providing a service that the NPD itself cannot yet deliver.

Multi-Organization Practitioners

Among the 2.1 million practitioners who are linked to organizations, the distribution of organizational affiliations is revealing:

More than half of linked practitioners work across multiple organizations. This reflects the reality of modern medical practice: hospitalists who work at multiple hospitals, specialists who split time between academic medical centers and private practices, and behavioral health providers who contract with multiple group practices simultaneously.

V. The Organization File: 3.6 Million Entities - and a Taxonomy Problem

The Organization file contains 3,605,261 records representing every organizational entity in the Medicare enrollment system. The file is notable for both its coverage and its taxonomic limitations.

55.45% of organizations are typed as "Healthcare Provider" - a FHIR type code that is accurate but unhelpful. It does not distinguish between a solo practitioner's practice, a 500-bed hospital, and a national health system. The remaining 44.55% are typed only as "ein" - meaning they are identified by their tax ID number but have no FHIR organizational type assigned at all.

This taxonomy gap is significant for any application that needs to distinguish between different types of healthcare organizations. A hospital network, a physician group, a pharmacy chain, and a home health agency all appear in the same file with the same type code. Differentiating them requires either enrichment from external sources (like the CMS Provider of Services file or the AHA Annual Survey) or inference from the organization's name and NPI taxonomy codes.

The Health System Hierarchy

The cross-resource graph analysis identified the top organizations by practitioner count - a proxy for organizational scale that has never before been available in a public dataset:

Kaiser Permanente's two medical groups together account for 34,097 practitioners - the largest single health system presence in the dataset. The appearance of Teladoc Health at #16 with 5,472 practitioners is a signal of how dramatically telehealth has scaled: a company that did not exist as a significant healthcare entity a decade ago now employs more Medicare-enrolled providers than most major academic medical centers.

The organization size distribution reveals the extreme fragmentation of US healthcare delivery:

143,491 organizations - 37.1% of all organizations with practitioners - are solo practices. The US healthcare system is dominated by small organizations: 84.2% of all organizations with practitioners have fewer than 11 practitioners. The 599 enterprise organizations with more than 1,000 practitioners collectively represent the major health systems, but they are a tiny fraction of the total organizational landscape.

VI. The Location File: 3.5 Million Addresses - With a Critical Gap

The Location file contains 3,494,239 records representing physical service locations. 46.64% have GPS coordinates - 1,630,294 locations with latitude and longitude at 5+ decimal places (sub-meter accuracy). The geographic distribution mirrors the US population: California leads with 176,913 locations, followed by Florida (134,240) and Texas (126,627).

The critical gap in the Location file is operational data. Hours of operation are absent from 100% of records. Accepting-new-patients status is absent from 100% of records. Available time slots, telehealth availability, and accessibility information are all absent. The Location file tells you where a provider can be found but nothing about when they are available or whether they are accepting new patients.

This gap is the single most important limitation for consumer-facing applications. A patient searching for a primary care physician needs to know not just that a provider exists at a given address, but whether that provider is accepting new patients and when they have availability. The NPD cannot answer either question.

VII. The Endpoint File: 5.0 Million FHIR Connections - and the EHR Market Revealed

The Endpoint file is perhaps the most technically significant resource in the dataset. With 5,043,524 records, it is the largest public enumeration of healthcare interoperability infrastructure ever assembled. Every record represents a machine-readable connection point to a healthcare organization's data systems.

74.21% of endpoints are active (3,742,777 records). 25.79% are in an error or inactive state (1,300,747 records). The inactive endpoints are not random noise - they are a signal about the state of healthcare IT infrastructure. Organizations that have migrated EHR systems, gone out of business, or failed to maintain their FHIR endpoints appear in this file as inactive records.

The EHR Market Share Revelation

The endpoint domain distribution is the first public, population-level view of EHR market share in US healthcare:

These figures require careful interpretation. Cerner's apparent lead over Epic reflects Cerner's historical dominance in hospital and government markets (including the VA and DoD), while Epic's true market share — particularly in large academic medical centers and integrated delivery networks — is substantially understated by the hosted domain count alone. Epic installations at Kaiser, Mayo, Cleveland Clinic, and dozens of major health systems appear under those institutions' own domains, not under epichosted.com.

25.81% of all endpoints - 1,301,977 records - are Direct Project endpoints, not FHIR REST APIs. The Direct Project is a pre-FHIR secure messaging standard developed in 2010 as part of the Meaningful Use program. Its continued presence at this scale reveals that a quarter of healthcare interoperability infrastructure is still running on technology that predates the FHIR standard by nearly a decade. This is both a data quality issue and a market opportunity: any service that can help organizations migrate from Direct to FHIR would be addressing a real and quantifiable need.

100% of endpoints use HTTPS - a baseline security requirement that is universally met. FHIR R4 is the dominant version at 70.6% of all endpoints, with FHIR STU3 accounting for most of the remainder.

VIII. The OrganizationAffiliation File: The Healthcare Network Graph

The OrganizationAffiliation file, at 439,599 records, is the smallest resource in the dataset but arguably the most strategically significant. It is the first public enumeration of the relationships between healthcare organizations - who is affiliated with whom, and in what capacity.

The affiliation code distribution reveals the structure of these relationships:

- 57.10% are Member affiliations: organizations that are members of a network, association, or health system

- 3.33% are HIE/HIO affiliations: 14,622 records documenting participation in Health Information Exchanges

The HIE/HIO records are particularly significant. Health Information Exchanges are the organizations responsible for sharing patient data across provider organizations within a region. Before the NPD, there was no public, machine-readable list of which organizations participated in which HIEs. These 14,622 records are the first such enumeration - a foundation for understanding the actual connectivity of the US health information infrastructure.

The network analysis reveals 98,179 unique organizational hubs with at least one affiliation relationship. The largest network hub has 12,086 member organizations - likely a major national health network or payer-sponsored network. The distribution is highly skewed: 69,429 hubs (70.7%) have only a single affiliation relationship, while a small number of large hubs account for the majority of the network's connectivity.

IX. The Cross-Resource Graph: Connectivity, Gaps, and What They Mean

The most important analytical question about the NPD is not what each individual resource contains, but how well the six resources connect to each other. A healthcare provider directory is only as useful as the completeness of its linkage graph: does each practitioner connect to their organization, their location, and their FHIR endpoint?

The full cross-resource analysis, run on GitHub Actions across all 27.2 million records, produces a definitive answer:

The finding that 0% of practitioners have a complete chain connecting them to an organization, a location, AND an endpoint is the most important structural insight in the entire dataset. The endpoint references in the Practitioner file use a different reference format than expected by the cross-resource join — the Endpoint file's records are linked through PractitionerRole and Organization, not directly through Practitioner extension references. This means the full five-resource chain (Practitioner → PractitionerRole → Organization → Location → Endpoint) exists for the 27.74% of practitioners who have both organizational and location linkage, but the endpoint leg of the chain runs through the organization, not the practitioner directly.

The 71.30% of practitioners with no organizational linkage at all represents the dataset's most significant completeness gap. These are practitioners who are enrolled in Medicare but whose organizational affiliations are either not captured in the NPD or have lapsed. Closing this gap - connecting orphaned practitioners to their current organizations - is one of the most valuable enrichment tasks that can be performed on this dataset.

X. The Entrepreneur's Guide: Eight Ventures the NPD Makes Possible

The NPD is not just a dataset. It is infrastructure - the kind of infrastructure that enables an entire generation of applications that were previously impossible or prohibitively expensive to build. The following eight venture categories represent the most direct and defensible opportunities.

1. The Provider Search Engine

The most obvious application is also the most valuable: a consumer-facing provider search engine that is actually comprehensive. Existing provider directories - Zocdoc, Healthgrades, WebMD - are built on proprietary data that is expensive to acquire and difficult to maintain. The NPD provides a free, comprehensive foundation. The value-add is enrichment: layering in accepting-new-patients status (from payer directories or direct provider outreach), appointment availability (from scheduling APIs), patient reviews (from CMS's existing review data), and telehealth availability.

The NPD's 3.49 million location records with 46.64% GPS coverage provide the geographic foundation. The 7.44 million practitioner records with specialty data provide the clinical foundation. The 5.04 million endpoint records provide the interoperability foundation. A search engine built on this data would have coverage that no proprietary directory can match.

2. EHR Connectivity Intelligence

The endpoint file is a real-time map of which EHR systems are deployed where. For health IT vendors, this is a sales intelligence tool of extraordinary value. A company selling a clinical decision support module, a revenue cycle management tool, or a patient engagement platform can use the endpoint data to identify every organization running a specific EHR, segment them by geography and size, and prioritize outreach accordingly.

The 12.97% Cerner market share, 8.40% athenahealth share, and 7.38% Epic hosted share are the first population-level EHR market data ever made publicly available. For any company that sells into healthcare, this data is more valuable than any analyst report.

3. Prior Authorization Automation

Prior authorization - the process by which insurers require providers to obtain approval before delivering certain services - is one of the most expensive and time-consuming administrative burdens in US healthcare. The NPD's endpoint data makes it possible to route prior authorization requests directly to the right FHIR API endpoint for any organization in the country.

A prior authorization automation platform built on the NPD could identify the FHIR endpoint for any ordering provider's organization, submit the authorization request programmatically, and receive a response without any manual fax or phone call. The 5.04 million endpoint records represent the infrastructure for this automation. The 25.81% of endpoints that are still Direct Project (legacy fax-equivalent) represent the market for migration services.

4. Healthcare CRM and Sales Intelligence

Every company that sells to healthcare providers - pharmaceutical companies, medical device manufacturers, health IT vendors, staffing agencies - maintains expensive proprietary databases of provider information. The NPD makes it possible to build a comprehensive, free-to-use foundation layer that these companies can enrich with their own data.

The top-50 organizations by practitioner count, the org size distribution, the specialty breakdown, and the geographic distribution are all now public. A healthcare CRM built on the NPD would have structural advantages over any proprietary competitor: lower data acquisition costs, more comprehensive coverage, and a foundation that updates with each NPD release.

5. HIE Participation Analytics

The 14,622 HIE/HIO affiliation records are the first public enumeration of Health Information Exchange participation in the United States. Before the NPD, there was no way to know, from public data, which organizations participated in which HIEs. This information is now available.

A platform that maps HIE participation - showing which regions have strong HIE coverage, which organizations are connected to which exchanges, and where the connectivity gaps are - would be valuable to state health departments, ACOs, and any organization trying to understand the actual state of health information sharing in their market.

6. Workforce Analytics and Staffing Intelligence

The NPD's practitioner data - 7.44 million records with specialty, qualification, gender, enrollment year, and geographic distribution - is the most comprehensive public dataset on the US healthcare workforce ever assembled. A workforce analytics platform built on this data could answer questions that no existing tool can: What is the ratio of NPs to physicians in rural counties? How has the behavioral health workforce grown since 2015? Which specialties are most concentrated in specific metropolitan areas?

For healthcare staffing agencies, this data is a prospecting tool. For health systems doing workforce planning, it is a benchmarking resource. For policymakers, it is a foundation for evidence-based workforce policy.

7. Care Gap and Desert Identification

The combination of location data (with GPS coordinates) and specialty data makes it possible to identify healthcare deserts - geographic areas with insufficient access to specific types of care. The NPD's 3.49 million location records, combined with census population data, enable the first comprehensive, population-level mapping of care access at the ZIP code or census tract level.

A care gap analytics platform could identify every county in the United States where the ratio of behavioral health providers to population falls below a threshold, or where there are no oncologists within 50 miles, or where the nearest FHIR-connected provider is more than an hour's drive away. This is the kind of analysis that health plans, ACOs, and state Medicaid programs need for network adequacy compliance.

8. Provider Data Enrichment and Verification

The NPD's CMS enrollment quality extensions — particularly the 39.75% enrollment-in-good-standing rate — create a new market for provider data enrichment and verification services. Any organization that needs to know whether a specific provider is currently in good standing with Medicare now has a free, authoritative source. But the 60.25% of providers who are not in good standing need to be investigated further: are they excluded, lapsed, or simply pending revalidation?

A verification service that combines the NPD's enrollment quality flags with the OIG exclusion list, state licensing board data, and DEA registration data would provide a comprehensive provider credentialing foundation. This is the core function of CAQH, which charges health plans and providers significant fees for this service. The NPD makes it possible to build a competitive alternative on a free foundation.

XI. The Prototype: CMS NPD Explorer

To demonstrate the practical utility of the NPD, a working prototype application was built: the CMS NPD Explorer, available live at onhealthcare.manus.space. The application is a six-page React application with a Federal Data Observatory design aesthetic - deep navy sidebar, Source Serif 4 and DM Sans typography, and recharts-powered visualizations.

The prototype includes:

Overview Dashboard - A hero statistics panel showing all 27.2 million records across the six resource types, with a summary of key findings from the complete population analysis.

Practitioners Explorer - A searchable, filterable table of practitioner records with specialty, qualification, gender, and enrollment status filters. The table demonstrates how the NPD can be used as a foundation for provider search.

Organizations Directory - An organizational directory with state distribution charts and size distribution visualizations, demonstrating the extreme fragmentation of US healthcare delivery.

FHIR Endpoints Directory - An endpoint directory with EHR vendor breakdown, status distribution, and FHIR version analysis, demonstrating the interoperability intelligence available in the dataset.

Analytics Dashboard - Six interactive recharts visualizations covering specialty distribution, qualification breakdown, gender distribution, EHR market share, geographic distribution, and data quality scoring.

Data Model Reference - A complete FHIR schema reference for all six resource types, with field-level documentation and cross-resource relationship diagrams.

The prototype is intentionally a demonstration, not a production application. It uses embedded sample data rather than live API calls to the full dataset, which would require a backend server capable of streaming and indexing the 2.8 GB compressed files. A production implementation would require either a DuckDB-based query layer, an Elasticsearch index, or a purpose-built FHIR server.

XII. Data Quality Assessment

A complete data quality assessment across all six resources, based on the full population analysis, produces the following scorecard:

The overall picture is of a dataset that is excellent on identity (NPI, name, organization name) but incomplete on operational data (hours, availability, accepting patients) and connectivity (only 28.70% of practitioners are linked to organizations). This is consistent with a first release that prioritizes enrollment data over operational data.

XIII. The Regulatory Foundation: Why This Data Will Improve

The NPD was released under the authority of the 21st Century Cures Act (2016) and the CMS Interoperability and Patient Access Final Rule (2020). These regulations require CMS to make provider directory data available in a standardized, machine-readable format and require payers to maintain accurate provider directories as a condition of participation in Medicare Advantage and Medicaid managed care.

The regulatory pressure on data quality will increase over time. The No Surprises Act (2022) created new requirements for provider directory accuracy, with financial penalties for plans that maintain inaccurate directories. As CMS links NPD data to claims data, quality reporting data, and enrollment data, the completeness and accuracy of the directory will improve.

The current gaps - particularly the 71.30% of practitioners with no organizational linkage and the 0% hours-of-operation coverage - are not permanent features of the dataset. They reflect the current state of CMS's data integration infrastructure. Future releases will incorporate data from payer directories (required to be submitted to CMS under the Interoperability Rule), state licensing boards, and direct provider attestation systems.

For entrepreneurs, this trajectory matters. The NPD is not a static dataset - it is a living infrastructure that will become more complete and more accurate with each release. Applications built on the NPD today will benefit from those improvements automatically.

XIV. Conclusion: The Infrastructure Moment

The release of the CMS National Provider Directory is an infrastructure moment for US healthcare technology - comparable to the release of the NPI registry in 2005 or the publication of Medicare claims data in 2012. It does not solve every problem in healthcare data, but it creates a foundation that makes a new generation of applications possible.

The complete analysis of all 27,204,567 records reveals a dataset that is simultaneously more powerful and more incomplete than its surface description suggests. It is more powerful because it contains the first public EHR market share data, the first public HIE participation enumeration, the first public enrollment quality flags, and the first public enumeration of the organizational structure of US healthcare at population scale. It is more incomplete because 71.30% of practitioners have no organizational linkage, 0% of locations have hours of operation, and 25.81% of endpoints are still running on pre-FHIR legacy technology.

These gaps are not obstacles. They are the market. Every gap in the NPD is a problem that a health technology entrepreneur can solve — by enriching the data, by building the missing linkages, by migrating the legacy endpoints, by adding the operational data that CMS has not yet captured. The NPD provides the foundation; the entrepreneurs provide the structure.

The 27.2 million records in this dataset represent every Medicare-enrolled provider in the United States. They represent the infrastructure of American healthcare - the people, organizations, locations, and technology systems through which care is delivered. That infrastructure is now public, free, and machine-readable for the first time. What gets built on it will define the next decade of health technology.

---

References

[1] CMS National Provider Directory. Centers for Medicare and Medicaid Services. https://directory.cms.gov/

[2] Health Tech Ecosystem Data Release Specifications. GitHub. https://github.com/ftrotter-gov/HTE_data_release_specifications

[3] 21st Century Cures Act, Pub. L. No. 114-255 (2016). https://www.congress.gov/bill/114th-congress/house-bill/34

[4] CMS Interoperability and Patient Access Final Rule (CMS-9115-F). Federal Register, 85 FR 25510 (2020). https://www.federalregister.gov/documents/2020/05/01/2020-05050/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-interoperability-and

[5] HL7 FHIR R4 Specification. HL7 International. https://hl7.org/fhir/R4/

[6] National Plan and Provider Enumeration System (NPPES). CMS. https://npiregistry.cms.hhs.gov/

[7] No Surprises Act, Consolidated Appropriations Act of 2021, Pub. L. No. 116-260 (2020). https://www.congress.gov/bill/116th-congress/house-bill/133

[8] NIST Special Publication 800-63A: Digital Identity Guidelines — Enrollment and Identity Proofing. NIST. https://pages.nist.gov/800-63-3/sp800-63a.html

[9] Direct Project Overview. HealthIT.gov. https://www.healthit.gov/topic/standards-technology/direct-project

[10] CMS Provider of Services File. CMS. https://data.cms.gov/provider-characteristics/hospitals-and-other-facilities/provider-of-services-file-hospital-non-hospital-facilities

Background: The Regulatory Arc from 2020 to 2026

What FHIR Endpoints Actually Are and Why They Matter Here

The Drug PA Extension: Scope, Timeline, and Technical Requirements

HIPAA Administrative Simplification: The Big Structural Shift

API Endpoint Reporting: The Infrastructure Registry Play

Decision Timeframes and Denial Transparency

Prior Authorization Metrics: The Public Accountability Layer

RFIs Worth Watching: ADT, Cybersecurity, Step Therapy

Investment Themes and Build Opportunities

Conclusion: The Regulatory Arbitrage Case

Abstract

CMS released CMS-0062-P on April 10, 2026, a proposed rule that extends prior authorization interoperability requirements to drugs for the first time, mandates FHIR-based API endpoint reporting, proposes FHIR as the HIPAA standard for PA-related transactions, and tightens decision timeframes across MA, Medicaid, CHIP, and QHP programs. Key dates and numbers:

- Comment deadline: June 15, 2026

- Compliance target for most proposals: October 1, 2027

- Drug PA timeframes proposed: 24 hours (Medicaid/CHIP drugs), 72 hours standard / 24 hours expedited (QHPs)

- Required IGs include CARIN Blue Button 2.2.0, Da Vinci PDex 2.1.0, CRD 2.2.1, DTR 2.2.0, PAS 2.2.1

- Old IG versions (STU 2 era) proposed to expire January 1, 2028

- Builds on 2020 interoperability final rule and 2024 PA final rule

- New coverage: small group market QHP issuers on FF-SHOPs added as impacted payers

Background: The Regulatory Arc from 2020 to 2026

To understand why CMS-0062-P matters, you have to understand where it sits in a multi-year regulatory campaign that started in earnest in 2020. The 2020 CMS Interoperability and Patient Access Final Rule (CMS-9115-F) was the opening salvo. It told Medicare Advantage plans, Medicaid, CHIP, and qualified health plan issuers that they had to build and maintain FHIR-based APIs for patient access, provider directories, payer-to-payer data exchange, and eventually prior authorization. The mandate was a structural shock to an industry that had grown comfortable with X12 EDI transactions, fax-based PA workflows, and the general opacity of payer administrative systems.

Then came the 2024 CMS Interoperability and Prior Authorization Final Rule, which went further and required actual electronic prior authorization support for non-drug items and services, with decision timeframe mandates and public reporting obligations for PA metrics. That rule gave the industry a taste of what FHIR-native PA workflows look like in practice, at least for the medical side of the house. Drugs were conspicuously left out, which everyone in the industry noticed and fully expected would be addressed in subsequent rulemaking.

CMS-0062-P is that subsequent rulemaking. It closes the drug PA gap, extends the IG requirement stack, adds an entirely new mandatory FHIR endpoint registry, and layers HIPAA administrative simplification proposals on top of all of it. The cumulative effect is a regulatory architecture that, when fully implemented, would make FHIR-based interoperability the legal floor for how prior authorization works in America rather than just a best practice or a pilot.

For health tech founders and early-stage investors, this is not just regulatory background noise. This is the demand signal. Every compliance obligation in this rule is a vendor opportunity somewhere in the stack. The question is where the real money is and who is positioned to capture it.

What FHIR Endpoints Actually Are and Why They Matter Here

Read more

1. Abstract

2. The Great Prior Auth and Denials Paradox

3. Fraud by the Numbers: Government Programs vs. Commercial Plans

4. How Prior Auth and Denials Actually Work as Fraud Prevention

5. The Medicare and Medicaid Fraud Landscape: A Quick Tour of the Wreckage

6. Why Private Payers Don’t Have This Problem (Or At Least Not Nearly as Bad)

7. The Uncomfortable Tradeoff Nobody Wants to Talk About

8. Where the Opportunities Are

9. The Bottom Line

Abstract

- Prior authorization and claims denials are universally despised across the healthcare ecosystem, with bipartisan legislative efforts aimed at curtailing their use in commercial insurance.

- Meanwhile, Medicare and Medicaid lose an estimated $100-300B+ annually to improper payments and outright fraud, numbers that dwarf fraud losses in commercial plans.

- Commercial payers deploy prior auth, claims denials, utilization management, and sophisticated analytics that function as a de facto fraud and abuse prevention layer, one that government programs largely lack.

- The thesis here: the very mechanisms providers and patients hate most in commercial insurance may be the primary reason private plans don’t hemorrhage money to fraud at anything close to the rate of public programs.

- Prior auth blocks fraud prospectively by forcing review before payment. Denials block fraud retrospectively by catching suspicious claims after submission but before or shortly after payment. Together they create a two-layer defense that government programs have historically lacked.

- For health tech entrepreneurs and operators, this creates a massive opportunity space around fraud prevention, payment integrity, and automation tools targeting government programs, while also raising hard questions about the real cost of dismantling prior auth and denial controls in commercial plans.

- Key opportunity themes include AI-driven prior auth automation, intelligent denial management, predictive fraud analytics for government payers, payment integrity platforms, and provider workflow tools that balance access with accountability.

The Great Prior Auth and Denials Paradox

There is a strange disconnect happening in healthcare policy right now, and it is worth pausing on because it has real implications for anyone building, operating, or investing in health tech. On one side of the conversation, you have providers, patients, advocacy groups, and frankly most of Congress united in their desire to gut prior authorization requirements and rein in claims denials in commercial insurance. The complaints are legitimate and well-documented. Prior auth delays care. Denials force appeals processes that consume enormous provider resources and sometimes result in patients simply going without needed treatment. Together, these mechanisms create administrative burden that costs the system billions, burns out physicians, and occasionally kills people. The horror stories are real, and nobody is arguing otherwise.

But on the other side of the ledger, something far less discussed is happening. Government insurance programs, specifically Medicare and Medicaid, are bleeding money at a rate that should make anyone with a finance background physically uncomfortable. We are talking about improper payment rates that, depending on whose numbers you trust, run somewhere between $100 billion and $300 billion per year. Some estimates go higher. A meaningful chunk of that is straight-up fraud. Not billing errors. Not coding mistakes. Fraud. Fake patients, phantom clinics, organized crime rings, the whole nine yards.

And here is the part that nobody seems to want to connect: Medicare and Medicaid have historically operated with far less rigorous prior authorization and far lower denial rates than commercial plans. When government programs do deny claims, it is often retrospective, meaning the money already moved and recovering it becomes a lengthy, expensive process that frequently fails. The correlation between “fewer prospective controls and less aggressive denial practices” and “dramatically more fraud” is not subtle. It is staring everyone in the face. Yet the policy conversation treats these as two completely separate issues, as if the people screaming about prior auth and denials in commercial insurance and the people screaming about fraud in government programs are living on different planets.

They are not. They are describing two sides of the same coin.

Fraud by the Numbers: Government Programs vs. Commercial Plans

Let’s get into the actual numbers because this is where the argument gets hard to ignore. CMS publishes improper payment rates annually, and while the methodology has shifted over the years, the directional story is consistent and grim. Medicare fee-for-service has run improper payment rates in the 6-8% range in recent years, which on a base of roughly $450 billion in annual FFS spending translates to somewhere around $30-40 billion per year just in traditional Medicare FFS. Medicare Advantage adds another layer of complexity with risk adjustment coding issues that GAO and OIG have estimated cost taxpayers tens of billions more annually. HHS OIG has put the MA overpayment figure in the range of $12-25 billion depending on the year and methodology.

Medicaid is arguably worse on a percentage basis. The most recent CMS data pegged the Medicaid improper payment rate above 20% in some years, though that number bounced around due to measurement changes. On a program that spends over $700 billion annually including both federal and state share, even a conservative 10% improper payment rate means $70 billion walking out the door incorrectly. And that 20%+ figure, when it showed up, implied something north of $140 billion.

Now compare that to commercial insurance. The National Health Care Anti-Fraud Association has historically estimated that fraud accounts for roughly 3-10% of total health spending, but that is an aggregate number across all payers. When you isolate commercial plans specifically, the fraud and improper payment rates tend to run dramatically lower than government programs. The big commercial payers, your UnitedHealthcare, Anthem, Aetna, Cigna, Humana on the commercial side, typically report fraud loss ratios well under 3%, and most internal estimates from payer executives suggest the real number is closer to 1-2% for well-managed commercial books of business.

So you have got government programs losing somewhere in the range of 8-20% to improper payments and fraud, and commercial plans losing maybe 1-3%. That is not a rounding error. That is an order of magnitude difference. And the single biggest structural distinction between these two payer types, besides the obvious scale and population differences, is the intensity of prospective utilization management and the willingness to deny claims that do not meet clinical or billing criteria. Which is a fancy way of saying prior auth and the associated denial machinery.

How Prior Auth and Denials Actually Work as Fraud Prevention

Most of the public conversation about prior auth and denials focuses on their role in clinical gatekeeping. Does the patient really need that MRI? Is that brand-name drug medically necessary when a generic exists? Should this surgery happen at an outpatient center instead of an inpatient facility? These are the utilization management questions that drive providers crazy, and rightfully so in many cases where the clinical answer is obvious and the auth process just adds friction and delay. Similarly, the denials conversation tends to focus on legitimate claims getting rejected for technicalities or documentation gaps, forcing providers into costly appeal cycles.

But there is a second function of both prior auth and denials that gets almost zero airtime: fraud prevention. These two mechanisms work as complementary layers of defense. Prior auth works as a prospective fraud deterrent because it forces review of the service before it happens. Denials work as a concurrent and retrospective fraud barrier because they catch suspicious claims that make it past the front door, rejecting payment before or shortly after the money moves. Together, they create a two-layer system that is fundamentally different from the pay-and-chase model that Medicare has historically relied on, where claims get paid first and audited later, sometimes much later, sometimes never.

Think about it from the perspective of someone running a fraudulent billing operation. If you are billing a commercial plan for, say, a series of expensive genetic tests on patients who never actually received them, you have a problem at two levels. First, the plan is likely going to require prior authorization for those tests. Someone is going to review the clinical documentation before approving the service. The patient’s primary care physician may get a notification. The plan may require the test to be performed at a credentialed lab. Second, even if you somehow get past prior auth, the claims adjudication system is going to run those claims through editing logic, medical policy rules, and increasingly sophisticated analytics before payment. Claims that trigger flags get denied, and the denial creates a paper trail that feeds into the plan’s special investigations unit. There are multiple checkpoints that a fraudulent claim has to clear before money changes hands, and each checkpoint generates data that makes the next fraudulent claim harder to push through.

Now try the same scheme against Medicare FFS. Submit the claim. Get paid in 14-30 days. Maybe get audited in two years. Maybe not. If a claim does get denied in Medicare, it is usually for a coding or documentation technicality, not because someone prospectively reviewed the clinical scenario. The structural vulnerability is enormous, and organized fraud rings know it. The DOJ has prosecuted cases involving hundreds of millions of dollars in Medicare fraud perpetrated by operations that ran for years before anyone caught on. Some of the most notorious cases, like the $1.3 billion home health fraud takedown in 2022 or the $1.4 billion telemedicine fraud schemes that DOJ rolled up during and after COVID, specifically exploited the absence of prospective controls and the low denial rates in Medicare.

Commercial prior auth and denials are not perfect. They are often clunky, slow, and applied in situations where they add cost without clinical value. But as structural anti-fraud mechanisms, they work remarkably well. Prior auth as the front gate and denials as the back gate create a system where it is genuinely difficult for fraudsters to operate at scale.

The Medicare and Medicaid Fraud Landscape: A Quick Tour of the Wreckage

For anyone not tracking the government program fraud space closely, a brief tour of recent enforcement actions is instructive. DOJ’s Health Care Fraud Strike Force, which operates in major metro areas across the country, has been running coordinated takedowns for over fifteen years. The annual totals are staggering. In June 2023, DOJ announced charges against 78 defendants across the country for approximately $2.5 billion in alleged fraud. The 2022 action tagged $1.7 billion. These are annual events now, recurring like clockwork, and the amounts keep growing.

The schemes are diverse and increasingly sophisticated. Durable medical equipment fraud remains a perennial favorite, with operations billing for wheelchairs, braces, and orthotics that patients never received. Home health fraud is massive, particularly in states like Texas and Florida, where fake home health agencies have been caught billing for services on patients who were either dead, not homebound, or never visited. Compounding pharmacy fraud exploded a few years back, with pharmacies billing government programs for expensive custom compounds that were either never dispensed or therapeutically unnecessary.

And then there is the telemedicine fraud wave that came out of COVID. When CMS loosened telehealth restrictions during the public health emergency, including dropping prior auth requirements, expanding the types of services eligible for telehealth billing, and effectively lowering the bar for claim denials, fraud operators moved in almost immediately. The DOJ has since prosecuted telemedicine fraud cases totaling multiple billions, with schemes typically involving call centers that would cold-call Medicare beneficiaries, conduct sham telehealth visits, and then bill for expensive genetic tests, durable medical equipment, or pain creams. The beneficiaries often had no idea their Medicare numbers were being used.

The common thread in almost all of these schemes is the absence of prospective review and the low rate of claim denial. The fraudsters specifically target Medicare and Medicaid because these programs pay first and investigate later, and because the odds of any given fraudulent claim being denied before payment are relatively low compared to commercial plans. The pay-and-chase model combined with low denial rates is not just inefficient. It is an invitation.

Medicaid fraud has its own special flavor, often involving providers in long-term care, behavioral health, personal care services, and substance abuse treatment. The behavioral health and substance abuse categories have been particularly problematic, with “Florida shuffle” style operations cycling patients through sham treatment programs and billing Medicaid for services that were either not rendered or grossly substandard. California’s Medicaid program alone has estimated fraud losses in the billions annually.

Compare any of this to what happens in commercial insurance and the contrast is sharp. Commercial fraud certainly exists, but it tends to be smaller in scale, detected faster, and harder to sustain because the prospective controls and more aggressive denial practices catch anomalies before large sums move.

Why Private Payers Don’t Have This Problem (Or At Least Not Nearly as Bad)

The question worth asking is: what exactly are commercial plans doing differently? The answer is not one thing but a layered system of controls, and prior auth and denials sit near the top of that stack.

First, commercial plans maintain provider credentialing processes that are more rigorous than Medicare’s enrollment system. To bill a commercial plan, a provider typically needs to be credentialed through a process that verifies licensure, malpractice history, practice location, and specialty qualifications. Medicare has its own enrollment process, obviously, but it has historically been more permissive and slower to remove bad actors. CMS has made improvements here, particularly through the Affordable Care Act’s enhanced screening provisions, but the commercial credentialing process remains tighter in practice.

Second, commercial plans use prior authorization as a prospective control on high-cost services. This means that before expensive imaging, surgeries, specialty drugs, genetic tests, and durable medical equipment are authorized, someone at the plan or its utilization management vendor reviews the request. This review serves a dual purpose. It assesses medical necessity, which is the clinical gatekeeping function everyone complains about, and it validates that the requesting provider, the patient, and the proposed service all check out. It is very hard to bill a commercial plan for a service on a patient who does not exist or from a facility that is not real when someone is reviewing the request prospectively.

Third, commercial plans deploy denial logic as a second line of defense. Claims that make it past prior auth still run through automated editing systems, medical policy engines, and payment integrity algorithms at the point of adjudication. Claims that do not match the authorization, that come from non-credentialed providers, that contain coding anomalies, or that trigger fraud indicators get denied. These denials serve a different function than the prior auth layer. Where prior auth prevents fraud from entering the system, denials catch it at the point of payment and stop the money from moving. The combination of prospective and concurrent controls is what makes the commercial system so much harder for fraudsters to exploit than government programs, which tend to rely more heavily on post-payment audits.

Fourth, commercial plans invest heavily in analytics and special investigation units. The big payers run sophisticated data science operations that flag billing anomalies, provider outliers, and suspicious patterns in near-real time. When these analytics generate flags, the response is often a targeted increase in prior auth requirements for the flagged provider or an increase in the denial rate for specific claim types, creating a feedback loop that tightens controls around suspicious actors. Medicare has its own analytics capabilities through CMS’s Center for Program Integrity and contractors, but the commercial payer analytics infrastructure is generally more advanced and more aggressively deployed.

Fifth, commercial plans have a direct financial incentive to prevent fraud and deny improper claims. Every dollar lost to fraud comes directly off the bottom line. Medical loss ratio regulations under the ACA mean that plans need to keep admin costs within bounds, but fraud losses hit the medical cost side of the equation and directly impact profitability. This creates a strong alignment between the payer’s economic interest and aggressive use of prior auth and denials. Medicare and Medicaid, by contrast, are spending taxpayer money, and while CMS certainly has fraud prevention programs, the institutional urgency is different. Bureaucratic processes, interagency coordination challenges, and political dynamics all slow the government’s response relative to what a commercial plan with direct profit exposure can do.

Sixth, commercial plans benefit from smaller, more defined networks. A commercial plan knows its providers. It has contracts with them. It knows their billing patterns, their patient panels, their historical utilization. When something looks off, the signal is easier to spot against a known baseline, and the plan can respond by increasing prior auth requirements or denial rates for that specific provider. Medicare, which is essentially an open network where any enrolled provider can bill the program, has a much harder signal-to-noise problem. The sheer scale and openness of the Medicare provider base makes it structurally more vulnerable to bad actors blending in.

The Uncomfortable Tradeoff Nobody Wants to Talk About

Here is where this gets politically uncomfortable, which is probably why the conversation rarely happens in mixed company. The prior auth and denials machinery that everyone hates in commercial insurance is performing a fraud prevention function that is saving enormous amounts of money. The government programs that lack equivalent controls are hemorrhaging cash to fraudsters at a rate that, if it were happening in any other sector, would be considered a national scandal.

This does not mean that prior auth and denials as currently implemented are optimal. They are not. Prior auth is too slow, too manual, too often applied to routine services that do not need prospective review. Denials are too often applied to legitimate claims for technical reasons, creating enormous appeal volumes and delaying payment to honest providers. The Gold Card programs that some states have implemented, where high-performing providers get exempted from prior auth requirements, are a smart step in the right direction. So are the CMS interoperability rules requiring electronic prior auth by 2027, and the various health tech solutions automating both the prior auth and denial management workflows.

But the conversation about reforming these mechanisms needs to happen with clear eyes about what happens when you remove prospective controls and reduce denial rates entirely. The Medicare and Medicaid experience provides a natural experiment, and the results are not encouraging. When you pay first and chase later, you lose a lot of money. When you do not require prospective justification for services, fraud scales easily. When your denial rates are low and your provider enrollment and credentialing processes are permissive, bad actors get in and stay in.

The advocacy community, and frankly a lot of the health policy commentariat, talks about prior auth and denial reform as if the only variable is access to care. And access matters enormously, nobody is disputing that. But the fraud prevention function matters too, and pretending it does not exist leads to policy proposals that could have very expensive unintended consequences.

Consider what would happen if commercial plans were required to eliminate prior auth and dramatically reduce denial rates, as some legislative proposals have suggested. Based on the differential fraud rates between commercial and government programs, you would expect a meaningful increase in fraudulent billing. How much? Hard to say precisely, but even a 2-3 percentage point increase in the commercial fraud rate would represent tens of billions of dollars annually, costs that would ultimately flow through to employers and consumers in the form of higher premiums. The actuaries at the big plans have modeled these scenarios, and the numbers are not pretty.

Where the Opportunities Are

For anyone building or operating in health tech, this tension between prior auth and denial reform on one hand and fraud prevention on the other creates several massive opportunity areas.

The most obvious is prior auth automation. The market for solutions that make prior auth faster, less burdensome, and more clinically intelligent is large and growing. Platforms that can automate the prior auth submission process, use clinical data to pre-populate authorization requests, and reduce turnaround times from days to minutes are addressing a real pain point without eliminating the prospective review function. The value proposition is straightforward: keep the fraud prevention benefit of prior auth while removing the administrative friction that delays care and burns out clinicians.

Denial management and optimization is equally compelling, and it cuts both ways. On the provider side, tools that help practices and health systems manage denials more efficiently, automate appeals, and reduce denial rates for legitimate claims have a massive addressable market. On the payer side, solutions helping plans deploy smarter denial logic that catches fraud and coding errors without generating the massive false positive rates that plague current systems are equally valuable. The ideal outcome is a denial system that is more accurate in both directions: fewer denials of legitimate claims and more denials of fraudulent ones.

Government program fraud prevention is arguably the biggest greenfield opportunity in the bunch. Given the scale of improper payments in Medicare and Medicaid, there is an enormous market for solutions that bring commercial-grade prior auth, denial logic, and fraud analytics to government programs. CMS has been investing in this area, and the Fraud Prevention System that CMS operates has identified and prevented billions in improper payments. But the gap between government and commercial capabilities remains wide. Predictive models, provider risk scoring platforms, and real-time claims surveillance tools specifically built for the Medicare and Medicaid context address a gap that costs taxpayers hundreds of billions annually.

Payment integrity platforms represent a related but distinct opportunity. Payment integrity goes beyond fraud to include coding accuracy, clinical validation, and billing compliance. The payment integrity market for commercial payers is already well-established with large incumbents. But the government program payment integrity space is less mature and arguably more impactful given the higher improper payment rates.

Provider-side workflow tools that help legitimate providers navigate the prior auth and denials landscape while ensuring compliance represent another substantial market. Think of this as the provider workflow layer that sits between the clinical decision and the payer authorization or claim adjudication. Tools that can predict whether a prior auth will be required, pre-check the likely approval criteria, assemble the necessary documentation automatically, submit electronically, and proactively address the most common denial triggers before submission are valuable to providers and do not threaten the fraud prevention function that payers rely on.

And then there is intelligent utilization management, which is more speculative but potentially very large. This means moving beyond binary approve/deny logic to more nuanced, risk-stratified approaches. A system that applies intensive prospective review and higher denial thresholds to high-risk providers, new-to-network entities, and unusual service patterns, while fast-tracking authorizations and reducing denial friction for established providers with clean billing histories. This is essentially what Gold Card programs do at a coarse level, but there is room for much more granular, data-driven approaches that could dramatically reduce administrative burden for the vast majority of legitimate providers while actually increasing scrutiny on the small percentage of actors who account for most of the fraud.

The Bottom Line

The prior auth and denials debate in healthcare is one of those situations where the loudest voices in the room are not necessarily wrong, but they are definitely incomplete. Yes, prior auth as currently implemented is often terrible. Yes, denials of legitimate claims waste enormous resources and delay necessary care. Yes, both need to be reformed, automated, and made more intelligent.

But the argument that prior auth should simply be eliminated and denial rates slashed across the board, that these mechanisms serve no useful purpose, that they are purely tools for payers to deny care and boost profits, that argument does not survive contact with the data. The differential fraud rates between commercial plans (which use prior auth and denials aggressively) and government programs (which historically have not) tell a clear story. These mechanisms, for all their flaws, are functioning as critical fraud prevention layers. And the scale of fraud in programs that lack them is genuinely breathtaking.

For health tech entrepreneurs and operators, this creates a rare situation where both sides of the equation present opportunity. The reform side needs better technology to make prior auth less painful and denials more accurate. The fraud prevention side needs better technology to bring government programs up to something approaching commercial-grade integrity. And the sweet spot is solutions that can do both simultaneously, reducing the burden on legitimate providers while increasing the detection of fraudulent actors.

The regulatory trajectory supports this view. CMS is moving toward electronic prior auth requirements. Multiple states are passing Gold Card laws. Congress continues to advance bipartisan prior auth and denial reform legislation. And at the same time, CMS is investing in enhanced program integrity tools and the DOJ continues to ramp up healthcare fraud enforcement. These parallel tracks are not contradictory. They are complementary. The future of utilization management is not “fewer controls.” It is “smarter controls.” And that is a technology problem, which means it is exactly the kind of problem that health tech companies can solve.

The fraud numbers in government programs are not going down on their own. The political pressure to reform prior auth and denials in commercial plans is not going away. Both problems need technology solutions. Both represent enormous markets. And both are underfunded relative to their scale.​​​​​​​​​​​​​​​​

CMS launched the BALANCE Model in December 2025, a 1115A Innovation Center voluntary model that for the first time waives the Part D statutory exclusion on weight loss drugs, negotiating net prices of $245/month for Zepbound and model drugs from Novo Nordisk (Ozempic, Rybelsus, Wegovy) and Eli Lilly (Mounjaro, Zepbound, and pending FDA approval, orforglipron)

The Part D application deadline is April 20, 2026, with an 80% beneficiary participation threshold that CMS will evaluate by April 30, 2026 to determine whether the model launches in Medicare in January 2027

A Medicare GLP-1 Bridge demonstration launches July 2026 at $50/month copay, operating entirely outside the Part D benefit structure, meaning plans carry zero risk

Medicaid states can join on a rolling basis from May 2026 through January 2027, executing supplemental rebate agreements that reflect CMS-negotiated key terms

Simultaneously, FDA peptide regulation is in upheaval: semaglutide and tirzepatide were removed from the drug shortage list in early 2025, HHS Secretary Kennedy announced in February 2026 that ~14 of 19 restricted Category 2 peptides would return to Category 1 compounding status, and the formal reclassification publication remains pending

The convergence of BALANCE’s government-negotiated GLP-1 pricing with FDA’s peptide compounding crackdown and subsequent partial reversal creates a complex opportunity map for providers, pharmacies, manufacturers, wellness companies, d2c telehealth, payers, entrepreneurs, and investors

Table of Contents

What BALANCE Actually Is (and What It Isnt)

The Mechanics: Pricing, Rebates, and the Facilitated DIR Field

Part D Plan Sponsors: The 80% Threshold Problem

Medicaid: The Rolling On-Ramp

The Bridge Demo: Why July 2026 Matters More Than January 2027

Provider Strategy: PA Criteria, Auto-Lookback, and Patient Volume

Pharmacy and PBM Implications

Pharma Manufacturers: Lilly and Novo in a Negotiated Cage

Wellness Companies and Lifestyle Support: The Mandated Wraparound

D2C Telehealth: The Compounding Cliff Meets Government Pricing

FDA Peptide Activity: The Category 2 to Category 1 Reversal

Payer Strategy: Risk Corridors, Adverse Selection, and Bid Uncertainty

The Entrepreneur and Investor Lens

What BALANCE Actually Is (and What It Isnt)

The BALANCE Model (Better Approaches to Lifestyle and Nutrition for Comprehensive hEalth, because government acronyms gonna government acronym) is a CMMI 1115A demonstration. That statutory authority matters. It means CMS can waive provisions of the Social Security Act to test payment and delivery models. In this case the single most consequential waiver is of Section 1860D-2(e), which has historically excluded drugs used for weight loss from Part D coverage. That exclusion has been the law since 2003. Twenty-plus years of Part D and weight loss drugs have never been covered. BALANCE changes that for participating plans.

But it is voluntary. Manufacturers, states, and Part D sponsors all opt in. The model runs January 2027 through December 2031 for Part D, with Medicaid states joining on a rolling window from May 2026 through January 2027. CMS negotiated directly with Eli Lilly and Novo Nordisk during a pre-implementation period from January 12 through February 5, 2026, and those manufacturers executed Participation Agreements by February 28, 2026. The negotiated drugs include all formulations of Mounjaro, Ozempic, Rybelsus, and Wegovy, the KwikPen formulation of Zepbound, and orforglipron tablets if FDA approves them. The net price for Zepbound is $245 per month supply. Novo’s pricing for its portfolio is listed in the RFA appendix but follows similar negotiated terms.

What BALANCE is not: it is not a permanent statutory change. It is not the IRA’s Medicare Drug Price Negotiation Program, although it interacts with it in weird ways (more on that below). It is not a guarantee of coverage for any individual patient. And it absolutely is not universal, because if fewer than 80% of Part D beneficiaries are enrolled in participating plans, the whole Medicare side does not launch.

The Mechanics: Pricing, Rebates, and the Facilitated DIR Field

The payment plumbing here is genuinely interesting and worth understanding because it tells you where the money flows. CMS negotiated a net price with manufacturers. That net price includes all discounts, rebates, and price concessions. For drugs that are also selected under the IRA’s Negotiation Program (which applies to some of these products), CMS is waiving the Maximum Fair Price requirement. Instead, plans will use WAC as the base for gross drug cost calculations, and manufacturers will pay rebates through a new PDE field called Facilitated DIR (FAD).

The FAD field calculates the difference between the ingredient cost the plan reports on the PDE and the sum of the GLP-1 Discounted Price plus the Manufacturer Discount Program amount. Manufacturers get invoiced quarterly through the existing MDP portal with separate model-specific invoices. Plans do not report the FAD amount on the DIR Report for Payment Reconciliation, but CMS incorporates it into annual reconciliation.

Why does this matter? Because it means plans are not chasing manufacturers for rebates. CMS is intermediating the rebate flow, which dramatically reduces administrative friction for plans. It also means CMS has real-time visibility into whether plans are complying with price guidance, and it protects beneficiary and physician data by keeping the invoicing process clean on the CMS side rather than requiring plans to share utilization data directly with manufacturers.

There is a 340B adjustment baked in too. Rebates get reduced by up to 5% to account for the fact that manufacturers will be paying model rebates on units purchased by 340B covered entities at already-discounted prices. This is a small but important detail for health systems running 340B programs who are evaluating the model.

Part D Plan Sponsors: The 80% Threshold Problem

This is the single most important near-term question in the entire model. CMS requires that plans representing at least 80% of NAMBA-eligible beneficiaries apply to participate. If they do not hit that number, BALANCE does not launch in Medicare in 2027. Period. CMS calculates the threshold based on February 2026 enrollment data, projected forward. The denominator includes all NAMBA-eligible plan types plus Defined Standard plans (even though DS plans cannot actually participate). The numerator is beneficiaries in plans that applied. SNPs and EGWPs are excluded from the calculation even though they can participate.

The application deadline was April 20, 2026. CMS targets April 30, 2026 to notify plans whether the threshold was met. As of this writing, that notification should be imminent or already out. If it cleared, the next milestone is June 1, 2026, when plans indicate participation in HPMS and submit bids reflecting BALANCE. Contract addendums execute in September 2026.

Participation is at the parent organization level, which is a big deal. A parent org must include all of its Enhanced Alternative plans. It must also include 90% of beneficiary enrollment in its basic plans (excluding ineligible types and DS plans). DS plans cannot participate because they cannot offer the reduced cost sharing while maintaining DS status, but parent orgs can convert DS plans to BA or AE benefit types for 2027. EGWPs can participate but are not required to.

For plans, the decision tree is: if enough of the market applies, you are probably going to have to participate because not participating means your competitors offer $50 or $125 copay GLP-1s and you do not. The adverse selection concern is real (people who want GLP-1s will shop for plans that cover them) and that is exactly why CMS set the 80% threshold so high. If basically everyone is in, adverse selection washes out.

Medicaid: The Rolling On-Ramp

The Medicaid side works differently. States apply through a Qualtrics link by July 31, 2026, execute State Agreements with CMS by January 1, 2027, and enter supplemental rebate agreements with each participating manufacturer. States that need SPAs or new state legislation can work with CMCS to get those in place. States can start as early as May 2026 with just FFS populations and bring managed care populations in later, as long as everything is live by January 1, 2027.

The coverage criteria are identical to the Part D criteria (same BMI thresholds, same comorbidity requirements), and the Medicaid Key Terms are standardized. States can vary terms with CMS approval but cannot disadvantage one model drug relative to another. Managed care plans within participating states must apply the same access policy as FFS.

For investors watching the Medicaid managed care space, this matters because MCOs in participating states will need to cover these drugs at negotiated prices with standardized PA criteria. That is new cost exposure but also new opportunity if the drugs reduce downstream utilization of hospitalizations, ER visits, and specialty care. The question of whether GLP-1s are net savings or net cost for Medicaid populations is going to be the subject of the model evaluation, but anyone who has been following the cardiovascular outcomes data from SELECT and STEP-HFpEF trials knows the clinical signal is strong.

The Bridge Demo: Why July 2026 Matters More Than January 2027

Before BALANCE even launches, CMS is running a separate Medicare GLP-1 payment demonstration starting July 2026. This is often overlooked but it is arguably the bigger near-term catalyst. The bridge demo operates entirely outside the Part D benefit’s coverage and payment flow. Part D sponsors carry zero risk. CMS uses a single central processor to manage prior authorization, claims adjudication, and payment to pharmacies. Eligible beneficiaries pay $50 per month for Wegovy or Zepbound.

This means that starting mid-2026, millions of Medicare Part D beneficiaries can access GLP-1s for weight management at $50/month regardless of what their plan does. The catch: it ends December 31, 2026. So beneficiaries who start on the bridge need to enroll in a BALANCE-participating plan for 2027 to maintain access. CMS has said they will do beneficiary outreach and education around this transition.

From a market dynamics perspective, the bridge demo is going to create a massive cohort of Medicare patients on GLP-1s before BALANCE launches. That is demand that gets locked in. Plans that do not participate in BALANCE will lose those members during open enrollment. This is the stick that makes the 80% threshold achievable.

Provider Strategy: PA Criteria, Auto-Lookback, and Patient Volume

The prior authorization criteria under BALANCE are more generous than many expected. The three tiers are: (1) BMI 35 or above with lifestyle modification, (2) BMI 30 or above with specific comorbidities like HFpEF, uncontrolled hypertension, CKD stage 3a+, moderate/severe OSA, or noncirrhotic MASH F2-F3, and (3) BMI 27 or above with pre-diabetes, previous MI, previous stroke, or symptomatic PAD. Patients with type 2 diabetes, MASH with F2-F3 fibrosis, or OSA do not even need to meet a BMI threshold for the lifestyle modification pathway.

The Auto-Lookback provision is really interesting for health IT companies. Plans are directed to try to confirm PA through automated review of patient health records via ICD-10 code matching before requiring provider attestation. If the automated check fails, then provider attestation is sufficient. This creates an opportunity for companies building prior authorization automation, clinical data matching, and interoperability tooling. The plans that execute Auto-Lookback well will have lower administrative costs and faster patient access.

For provider organizations, the volume implications are significant. CMS is essentially telling every primary care doc in America that their Medicare patients with BMI 30+ and common comorbidities can now get GLP-1s covered. The prescribing volume is going to be enormous. Practices need to think about PA workflow capacity, patient education at scale, and monitoring protocols. Obesity medicine as a specialty is about to see a massive demand surge.

Pharmacy and PBM Implications

Participating plans must reimburse in-network pharmacies at no less than WAC plus sales tax plus a dispensing fee. That WAC-plus floor is a real win for pharmacies that were worried about being squeezed. Mail order and specialty pharmacy are both eligible channels. The cost sharing maximums ($50 for EA/EGWP plans, $125 for AE/BA plans) apply at all in-network pharmacy types, preferred and non-preferred, retail and mail.

For PBMs, the FAD field changes rebate economics. PBMs typically negotiate and retain a share of DIR rebates. Under BALANCE, the manufacturer rebates flow through CMS’s invoicing system, not through PBM-negotiated contracts. PBMs will need to figure out how model drugs interact with their existing rebate structures for non-model indications and non-model plans. This is a structural change to the PBM value proposition for this drug class.

Community pharmacies should be paying close attention to the bridge demo’s central processor model. If CMS builds an effective centralized claims processing system for the bridge, that infrastructure could influence future payment models beyond GLP-1s.

Pharma Manufacturers: Lilly and Novo in a Negotiated Cage

Eli Lilly and Novo Nordisk both signed Participation Agreements. They accepted $245/month net pricing (for Zepbound at least, and comparable pricing for Novo products). That is roughly 75-80% off WAC depending on the specific product. In exchange they get access to the entire Medicare and Medicaid population at negotiated volume with standardized coverage criteria.

The manufacturers are also required to fund lifestyle support programs at no cost to plans or beneficiaries. These programs must cover diet and nutrition counseling, physical activity support, medication adherence tools, and must be delivered on a recurring basis with accessibility accommodations for patients with limited digital access. The safe harbor at 42 CFR 1001.952(ii) protects manufacturers from anti-kickback exposure on these programs, but only within the model.

For Lilly specifically, orforglipron is the sleeper hit. If FDA approves the oral GIP/GLP-1 receptor agonist, it enters the model immediately. An oral formulation at $245/month with Medicare and Medicaid coverage would be enormously disruptive to the injectable-dominated market. Lilly filed the NDCs in the RFA appendix, which suggests they are confident on approval timing.

Wellness Companies and Lifestyle Support: The Mandated Wraparound

The lifestyle support mandate is where wellness, digital health, and coaching companies should be paying very close attention. Manufacturers are on the hook to provide these programs, but the RFA language around program requirements reads like a digital health company’s product spec sheet: diet and nutrition with GI side effect management, physical activity promotion, medication adherence with reminders and injection site guidance, recurrent engagement with weight logging and goal review, and scalable delivery including offline options for patients without digital access.

Lilly and Novo are going to need partners to deliver this at the scale of the Medicare and Medicaid population. They are not going to build this in-house. That means contracts for digital health platforms, health coaching companies, nutrition counseling services, and patient engagement technology. If you are building in the GLP-1 support ecosystem (think Noom, Calibrate-style models, clinical coaching platforms, remote patient monitoring for metabolic health), the manufacturer lifestyle support mandate just created a guaranteed buyer.

CMS has also said it expects to revisit lifestyle support requirements annually and may shift responsibility to states and MA-PD plans in future years. That is a signal that this could evolve from a manufacturer-funded mandate to a plan-funded benefit, which would further expand the addressable market for wellness and coaching companies.

D2C Telehealth: The Compounding Cliff Meets Government Pricing

This is where things get really spicy. The d2c telehealth GLP-1 market has been built on two pillars: compounded semaglutide at $200-400/month, and the ability to prescribe without the friction of traditional insurance PA. BALANCE and the FDA’s regulatory actions are attacking both pillars simultaneously.

On the compounding side, FDA removed semaglutide from the drug shortage list in February 2025 and tirzepatide in October 2024. The legal basis for shortage-based 503B compounding effectively evaporated, though ongoing litigation and 503A patient-specific compounding have kept some supply flowing. As of April 2026, the landscape is messy: 503A compounding continues under physician prescription, many 503B facilities are operating under court injunctions or enforcement uncertainty, and the gray market is still active.

Meanwhile, BALANCE introduces branded GLP-1s at $50/month copay for Medicare EA/EGWP plans and through the bridge demo. Even the $125/month AE/BA copay is competitive with compounded pricing. For Medicaid populations, cost sharing will be even lower. This fundamentally changes the value proposition for d2c telehealth companies selling compounded GLP-1s to commercially insured or cash-pay patients, because the comparison anchor just dropped from $1,000+/month brand name to $50-245/month government-negotiated.

Companies like Hims and Hers, Ro, and the dozens of smaller d2c GLP-1 telehealth plays need to be thinking about what their business looks like when the government is offering branded Wegovy at $50/month. The cash-pay compounded model only works if it is cheaper or more accessible than the covered option. For Medicare and Medicaid patients, that calculus just shifted dramatically. For commercially insured patients, the BALANCE pricing will create employer and plan pressure to match.

FDA Peptide Activity: The Category 2 to Category 1 Reversal

Running in parallel with BALANCE is a wild chapter in FDA peptide regulation. In September 2023, FDA placed 19 commonly used peptides on the Category 2 restricted list, effectively banning compounding pharmacies from preparing them. This included BPC-157, Thymosin Alpha-1, TB-500, CJC-1295/Ipamorelin, AOD-9604, and others widely used in wellness and longevity medicine.

Then in February 2026, HHS Secretary Kennedy announced on the Joe Rogan podcast (yes, really) that approximately 14 of the 19 would be reclassified back to Category 1, restoring legal compounding access under physician prescription. The five expected to stay restricted include Melanotan II, GHRP-2, GHRP-6, LL-37, and PEG-MGF. As of early April 2026, the formal FDA publication has not been released, so compounding pharmacies technically cannot resume production yet.

The connection to BALANCE is not immediately obvious but it matters for understanding the broader regulatory picture around peptide therapeutics in government health programs. GLP-1 receptor agonists like semaglutide and tirzepatide are themselves peptides. They are fully FDA-approved peptide drugs. The compounding crackdown on GLP-1s (shortage list removal, enforcement actions against compounders, Lilly and Novo litigation against clinics) and the partial reversal on non-GLP-1 peptides reflect two different regulatory postures for two different categories of peptide products.

For the investment thesis, the regulatory bifurcation creates distinct lanes. FDA-approved GLP-1 peptides are moving toward government-negotiated pricing and broad coverage through BALANCE. Non-approved peptides used in wellness and longevity are moving toward restored compounding access under physician supervision, but without insurance coverage and with ongoing quality concerns. These are fundamentally different market structures and business models, and conflating them is a mistake a lot of generalist investors make.

Payer Strategy: Risk Corridors, Adverse Selection, and Bid Uncertainty

The risk corridor modification is a clever incentive that deserves more attention. Under standard Part D, the first risk corridor threshold is plus or minus 5% of the target amount, with plans bearing 100% of the variance within that band. BALANCE offers an optional narrowed first threshold of plus or minus 2.5% for plans that opt in and subsequently experience model drug utilization more than one standard deviation above the mean for their plan type.

The mechanics are retrospective: CMS calculates utilization rates after the plan year, compares them to the mean and standard deviation across all eligible participating plans of the same type, and narrows the corridor for plans that got hit hardest. This is essentially CMS saying “if you get adverse selection, we will share the risk.” It is available for the first two years of the model, with potential extension based on results.

For payer actuaries, the bid uncertainty is the real challenge. Plans need to submit CY 2027 bids in June 2026 reflecting BALANCE participation. They are pricing a new drug class that has never been in the Part D benefit. They do not know what utilization will look like. They do not know how many of their members will meet the PA criteria. The narrowed risk corridor helps, but the first year is going to be a massive exercise in actuarial estimation with limited data. Plans with better analytics capabilities, especially those that can model the intersection of their current membership demographics, chronic condition prevalence, and the specific PA criteria, will have a meaningful advantage in bid accuracy.

The Entrepreneur and Investor Lens

So where does all of this leave entrepreneurs building companies and investors deploying capital in health tech?

First, the obvious: anything that reduces friction in the GLP-1 prescribing and monitoring workflow for participating plans and providers is going to see demand. PA automation that can handle the BALANCE-specific criteria and auto-lookback ICD-10 matching. Clinical decision support that helps PCPs identify eligible patients in their panel. Remote monitoring and coaching platforms that can serve the lifestyle support mandate. Lab ordering and metabolic health monitoring tooling. All of these are immediate build opportunities.

Second, the less obvious: BALANCE creates a data exhaust that will be extremely valuable. CMS is going to collect PDE data, utilization data, clinical outcomes data, and patient-reported measures across the entire model population over five years. Companies that position to help CMS, plans, states, or manufacturers analyze this data, reconcile rebates, monitor quality metrics, or support evaluation activities will find willing buyers. The FAD field alone creates a new data infrastructure requirement for every participating plan.

Third, the competitive dynamics in d2c telehealth are about to shift hard. Companies built on compounded GLP-1 margin are going to need to pivot toward branded drug access facilitation, comprehensive metabolic health management, or differentiated clinical services that justify their existence in a world where Medicare patients can get Wegovy for $50. The companies that survive this transition will be the ones that were always more than a pharmacy arbitrage play.

Fourth, the wellness and lifestyle support space just got a government-mandated TAM expansion. Manufacturers need to procure these services at scale. Plans may need to procure them in future model years. The specification in the RFA (diet/nutrition, physical activity, medication adherence, recurrence, scale/accessibility) reads like a product requirements doc. Companies that can deliver evidence-based lifestyle interventions at Medicare-and-Medicaid scale, including offline delivery for digitally underserved populations, have a clear path to contracted revenue.

Fifth, and this is the longer-term play, watch what happens with orforglipron. If Lilly gets FDA approval for an oral GLP-1 that enters the model at $245/month, the entire delivery model changes. No more cold chain. No more injection training. No more specialty pharmacy gatekeeping. Oral administration at government-negotiated prices is a completely different product from injectable semaglutide at $1,300/month. The downstream effects on patient adherence, prescriber behavior, pharmacy logistics, and competitive positioning are going to be massive.

On the peptide side, the Category 2 to Category 1 reversal creates a separate but parallel opportunity in wellness and longevity medicine. BPC-157, Thymosin Alpha-1, and the other returning peptides will flow through compounding pharmacies under physician prescription, serving a cash-pay, wellness-oriented population that is largely distinct from the BALANCE population. Companies building peptide therapy platforms, compounding pharmacy networks, or clinical protocols for non-GLP-1 peptides should be scaling their physician networks and pharmacy relationships now, ahead of the formal FDA reclassification publication.

The macro picture is that the federal government just decided to become the single largest purchaser of GLP-1s in the world, at prices 75-80% below list, with mandatory lifestyle support and standardized coverage criteria, across both Medicare and Medicaid. At the same time, FDA is unwinding its most aggressive compounding restrictions on non-GLP-1 peptides while maintaining pressure on compounded GLP-1s. These two regulatory vectors create very different market structures for very different patient populations, and the companies and investors that understand the distinction clearly will be positioned to capture the most value. The ones who treat “peptides” as a monolithic category or who assume the compounding arbitrage window stays open forever are going to get caught.

The next 90 days are going to tell the story. The 80% participation threshold decision. The bridge demo operational guidance. The FDA formal peptide reclassification publication. State Medicaid applications rolling in. Any one of these could reshape assumptions. Keep close to the primary source documents, read the RFAs yourself, and do not rely on secondary coverage that smooths over the details. The details are where the alpha is.​​​​​​​​​​​​​​​​

- Abstract

- How This Leak Happened and Why It Matters Beyond the Drama

- The Memory Architecture Problem: Context Entropy and What It Means for Clinical AI

- Multi-Agent Coordination: The Pattern Healthcare Has Been Waiting For

- KAIROS and the Shift from Reactive to Proactive AI in Care Settings

- AutoDream: Persistent Memory as a Clinical Infrastructure Problem

- Permission Architecture and Why Healthcare Builders Should Steal This Pattern

- Feature Gating, Dead Code Elimination, and Staged Rollouts for Regulated Environments

- What the Roadmap Signals for Health Tech Investment Theses

- The So-What: Practical Takeaways for Builders and Investors

Abstract

On March 31, 2026, a 59.8 MB JavaScript source map file was accidentally bundled into a public npm package release of Claude Code, Anthropic’s flagship agentic coding CLI, exposing its entire ~512,000-line TypeScript codebase. A researcher at Solayer Labs spotted it within hours. By nightfall the repo had thousands of forks. Anthropic confirmed no customer data was involved and attributed the incident to a packaging error. That said, what got exposed is a rare unobstructed view into how the most commercially successful AI agent in production actually works under the hood.

Key findings relevant to healthcare builders and investors:

- Three-layer skeptical memory architecture directly applicable to clinical AI context management

- Coordinator mode (multi-agent orchestration) is a production-validated pattern for parallel clinical workflows like prior auth, coding, and documentation

- AutoDream background consolidation offers a model for persistent, contradiction-resolving clinical knowledge stores

- KAIROS proactive daemon mode is the architectural predecessor to ambient clinical AI that surfaces insights before the clinician asks

- Permission and risk classification system is a template for HIPAA-compliant agentic tool governance

- Compile-time feature gating via dead code elimination is a viable pattern for staged rollouts in regulated environments

- The unreleased feature roadmap (1M context windows, task budgets, effort control) signals where health tech AI investment should be concentrating over the next 18 months

How This Leak Happened and Why It Matters Beyond the Drama

The mechanics of the leak are almost embarrassingly simple. When you build a JavaScript or TypeScript project, the toolchain typically generates source map files with the .map extension. These files exist purely to help developers debug production code – they map compressed, minified output back to the original readable source. The structure embeds the actual raw source code as strings inside a JSON file. Normally you strip these before shipping to production. In this case, nobody did. The .map file went out with the npm package, and anyone who pulled the package could grab 512,000 lines of unobfuscated TypeScript from Anthropic’s own R2 cloud storage bucket. The ironic twist that every developer on X immediately noted: the leaked source contains an entire subsystem called Undercover Mode, built specifically to prevent internal Anthropic information from accidentally leaking into public repos. They built a whole concealment architecture for the AI, then shipped the source code of the entire thing in a JSON file. Probably via Claude.

For healthcare builders, the drama of the leak itself is mostly noise. What matters is that this is one of the only detailed, verified looks at how a production-grade AI agent actually works at scale in a commercially mature product. Anthropic is reportedly running around $19B in annualized revenue as of early 2026, with enterprise contracts accounting for roughly 80% of that. This is not a research prototype. The patterns in this codebase are the patterns of a system that works at scale, survives enterprise procurement, and retains users. That makes it a genuinely useful reference architecture for anyone building agentic software in healthcare, which is a sector that desperately needs proven patterns for how to manage agent memory, orchestrate parallel tasks, handle permissions, and roll out features safely in regulated environments.

There are approximately 40 tools exposed in the leaked source, covering everything from bash execution to file operations to web fetching to sub-agent spawning. The query engine alone is ~46,000 lines. The base tool definition is ~29,000 lines. This is not wrapper code. And the healthcare sector, which is simultaneously drowning in workflow complexity and terrified of AI liability, has a lot to learn from how this architecture was assembled.

The Memory Architecture Problem: Context Entropy and What It Means for Clinical AI

The single most important technical insight in the leaked source for healthcare builders is how context entropy was solved. Context entropy is the tendency of AI agents to become progressively confused, hallucinatory, or inconsistent as sessions grow long and complex. It is the core unsolved problem for any AI agent that needs to operate across extended workflows – and in healthcare, virtually every meaningful workflow is extended. Prior auth spans days. Chronic disease management spans years. Complex coding reviews touch dozens of data points across multiple systems.

The leaked architecture addresses this through what VentureBeat described as a three-layer memory system that moves away from the store-everything retrieval approach. The foundational insight is that the agent is explicitly instructed to treat its own memory as a hint, not a fact. Before acting on something it believes it knows, the agent verifies against the actual source material. This is a skeptical memory architecture, and it is a genuinely important design philosophy for clinical AI. In clinical settings, the consequences of acting on stale or contradicted memory are not just wrong answers in a coding session – they can be adverse patient outcomes, billing fraud exposure, or regulatory violations.

The autoDream consolidation engine, which runs as a forked background subagent, executes a four-phase memory pass: it orients itself by reviewing existing memory structure, gathers recent signal from logs and transcripts, consolidates by writing or updating memory files while converting relative timestamps to absolute ones and deleting contradicted facts, and then prunes the memory index to stay under defined size limits. The three-gate trigger (24 hours since last consolidation, at least 5 sessions since last run, acquisition of a consolidation lock to prevent concurrent passes) ensures the system neither over-consolidates nor lets memory drift stale for too long.

For healthcare builders, this is a directly applicable pattern. Consider a prior authorization agent managing 50 concurrent cases. Each case has a history of clinical notes, payer criteria, submission attempts, and denial reasons. Storing all of that naively in context kills token budgets and introduces entropy. Running a background consolidation pass that strips contradictions, converts relative to absolute facts, and maintains a pruned index under defined size thresholds is exactly how you keep that agent performant over a weeks-long workflow. The dream system even runs read-only bash to verify facts against the actual project state before writing memory – translate that to an agent that verifies clinical facts against the EHR before committing them to its working memory and you have a pattern that could genuinely reduce the hallucination rate in clinical documentation workflows. The healthcare AI companies that figure this out first will have a durable moat. The ones still using naive RAG with no consolidation architecture will be embarrassed by the quality delta within 18 months.

Multi-Agent Coordination: The Pattern Healthcare Has Been Waiting For

The coordinator mode in the leaked source is a full multi-agent orchestration system, activated via a single environment flag. When enabled, the tool transforms from a single agent into a coordinator that manages multiple parallel worker agents. The orchestration follows four phases: parallel research workers investigate the problem and gather data, the coordinator synthesizes findings and writes specs, worker agents implement changes per spec, and verification workers test results. The system prompt for the coordinator mode explicitly teaches parallelism as a core design value, with the directive that workers are async and independent work should never be serialized when it can run simultaneously.

There is also a shared scratchpad directory for cross-worker durable knowledge sharing, and the coordinator is explicitly prohibited from lazy delegation – it reads worker findings directly and specifies exact next actions, rather than passing the ambiguity downstream. Worker communication happens via structured XML message passing with typed task notification schemas.

The healthcare workflow implications here are significant enough to spend some real time on. Take the prior authorization workflow as a concrete example because it is the canonical case where the industry keeps trying and failing to automate at scale. A coordinator agent receives a prior auth request. It simultaneously spawns one worker to pull and summarize the relevant clinical notes from the EHR, another to retrieve and parse the payer’s clinical criteria for the requested procedure, a third to check for any prior submissions or denials on the same patient and case, and a fourth to verify member eligibility and benefit limits. All four run in parallel. The coordinator synthesizes findings into a structured submission spec. An implementation worker drafts the prior auth submission. A verification worker checks it against payer format requirements and flags issues before submission. This is not science fiction – this is directly the architecture in the leaked source, applied to a healthcare workflow.

The same pattern maps to concurrent clinical coding review (parallel workers checking ICD codes, CPT codes, modifier applicability, and payer-specific edits), ambient documentation (workers pulling from different encounter data sources simultaneously while a coordinator synthesizes into a note), and population health monitoring (parallel workers checking patient panels against multiple protocol criteria while a coordinator surfaces actionable gaps). The companies building this coordination layer for specific healthcare verticals are the ones worth betting on right now. The leaked source is essentially a validated reference implementation that removes years of trial-and-error from the architecture decision.

KAIROS and the Shift from Reactive to Proactive AI in Care Settings

KAIROS is referenced over 150 times in the leaked source and represents the most forward-looking design pattern in the entire codebase for healthcare applications. It is a persistent, always-running daemon mode – an agent that does not wait to be prompted. It watches activity, writes observations to append-only daily logs, and receives periodic tick prompts that allow it to decide whether to surface something proactively or stay quiet. It has a 15-second blocking budget for proactive actions, meaning it self-limits how much it will interrupt the user’s workflow before deferring.

The name comes from ancient Greek. Chronos is clock time. Kairos is the right moment – the opportune instant when action is meaningful. That framing is deliberate. This is not an agent that floods you with notifications. It is an agent designed to intervene at the moment when intervention has the highest expected value.

Healthcare builders should pay close attention to this architecture because it is the technical predecessor to something the industry has been trying to describe but not quite build: AI that surfaces clinical insights before the clinician asks. The closest current analog is ambient clinical documentation, where AI listens to an encounter passively and drafts notes without requiring a prompt. But ambient documentation is still fundamentally reactive – it waits for the encounter to end and then generates output. KAIROS-style architecture goes further: a persistent background agent that monitors patient data streams, flags emerging deterioration patterns, surfaces drug interaction risks when a new order is placed, or alerts a care manager when a high-risk patient’s activity data shows anomalous patterns – all without waiting for a query.

The 15-second blocking budget is actually a really smart design constraint for clinical settings. A persistent agent that fires high-priority alerts constantly would induce alert fatigue, which is already one of the most documented patient safety problems in hospital medicine – studies have shown that more than 90% of clinical alerts in some hospital systems get overridden by clinicians who have been desensitized by volume. A proactive agent with a built-in self-limiting behavioral constraint that defers low-confidence or low-urgency interventions is a pattern that could genuinely reduce alert fatigue rather than exacerbate it. For health tech investors, companies that build this proactive-but-self-limiting architecture into their clinical AI products are solving a problem that pure reactive AI cannot solve. The market for clinical decision support that actually gets used (as opposed to clicked through and ignored) is enormous. The architecture to build it is now documented in a public GitHub repo with thousands of forks.

AutoDream: Persistent Memory as a Clinical Infrastructure Problem

The autoDream system deserves its own section separate from the broader memory architecture discussion because of what it reveals about how to think about persistent memory as an infrastructure problem rather than a feature. The leaked source treats memory consolidation as a background service with defined triggering conditions, explicit phase structure, size constraints, and a locking mechanism to prevent race conditions. This is not bolted-on memory. It is a first-class infrastructure component with the same design rigor as any stateful backend service.

The four phases (orient, gather signal, consolidate, prune and index) map remarkably well to how clinical knowledge management should work in a longitudinal patient care context. Orient means the agent reads its current memory structure before doing anything, establishing baseline understanding of what it already knows and how that knowledge is organized. Gather signal means it identifies what has changed since the last consolidation pass – new labs, new notes, new orders, new encounter records. Consolidate means it updates its durable knowledge store, specifically converting relative temporal references (three days ago, last visit) to absolute ones (March 28, 2026, encounter 447291), which is critical for clinical reasoning that depends on accurate timelines. Prune and index means it removes stale information, resolves contradictions, and keeps the index size manageable for future session efficiency.

The contradiction resolution step is particularly important for healthcare. Clinical records are full of contradictions – a patient who is listed as a non-smoker in their problem list but has documented tobacco use in encounter notes, a medication list that includes a drug the patient reported stopping six months ago, an allergy list that conflicts with a prescribed medication. An agent that just stores everything naively will eventually try to act on contradictory information and produce unreliable outputs. An agent with active contradiction resolution in its consolidation cycle surfaces these conflicts explicitly rather than silently working around them, which is the behavior you need in a HIPAA-regulated environment where auditability of AI reasoning is increasingly a compliance requirement.

The size constraints in the autoDream implementation (memory index under 200 lines and approximately 25KB) also offer a useful design forcing function. Healthcare builders tend to assume that more context is always better, but long context windows do not solve context entropy – they just defer it. The discipline of maintaining a pruned, well-organized memory index under defined size constraints forces the agent to make explicit decisions about what information is durable versus transient, which is exactly the kind of structured knowledge management clinical AI needs.

Permission Architecture and Why Healthcare Builders Should Steal This Pattern

The permission system in the leaked source is probably the most directly transferable component for healthcare builders, and also the most underappreciated in most of the general tech coverage of the leak. The system classifies every tool action as low, medium, or high risk. It gates protected files from automatic modification. It includes path traversal prevention that handles URL-encoded attacks, Unicode normalization exploits, backslash injection, and case-insensitive path manipulation. It has four distinct permission modes: default (interactive user prompts), auto (ML-based auto-approval via a transcript classifier), bypass (skip checks), and a mode called yolo that ironically denies everything.

There is also a permission explainer component that generates a natural language explanation of what a tool action will do and why it carries risk, before the user approves it. That explanation is itself generated by the model – meaning the AI is explaining its own actions in plain language as a precondition for execution. For healthcare, this is an extremely relevant pattern. The core HIPAA and emerging AI governance requirement for clinical AI is explainability – the ability to show what an agent did, why it did it, and what access it exercised in the process. An architecture where every high-risk action generates a human-readable explanation before execution, and where that explanation is logged, is a compliance architecture as much as a product architecture.

The specific protected file list in the source (git configuration, shell profiles, MCP configuration files) maps directly to a concept healthcare builders should formalize: protected data objects. In clinical AI, that list would include patient records, consent flags, medication orders, and anything touching billing or coding. The principle is the same – certain objects are too consequential to allow automatic modification, regardless of how confident the agent is. The leaked codebase draws that line explicitly in code. Healthcare builders should draw equivalent lines explicitly in their tool governance frameworks, not leave it to the model’s judgment.

The YOLO classifier, despite the irreverent name, is a genuinely interesting component: it is a fast ML-based permission decision system that uses session transcripts to decide automatically whether a pending action should be approved without interrupting the user. In healthcare settings, the equivalent would be an agent that auto-approves routine, low-risk documentation actions while escalating anything touching orders, prescriptions, or billing to human review. This is a much more sophisticated approach than blanket human-in-the-loop requirements, which add friction without always adding safety. The leaked source shows that this kind of tiered permission system is buildable with current ML capabilities and that the major lab developing the most widely-used coding agent in production has shipped it.

Feature Gating, Dead Code Elimination, and Staged Rollouts for Regulated Environments

One of the less-discussed but highly practical architectural decisions in the leaked source is the compile-time feature gating system. Features are controlled via compile-time flags that the Bun bundler constant-folds and then dead-code-eliminates in external builds. Branches behind inactive feature flags are not just inactive at runtime – they are physically absent from the compiled output. This means the external production build has a smaller attack surface, no accidental exposure of internal feature surfaces, and no runtime flag-checking overhead. The internal build has the full feature set. The two builds share source but produce fundamentally different artifacts.

For healthcare software teams, this is a compelling pattern for managing staged rollouts in a regulated environment. The FDA’s guidance on AI/ML-based software as a medical device (SaMD), and the associated predetermined change control plan requirements, create real compliance headaches for teams trying to iterate quickly on AI features. A compile-time gating system that produces provably different builds for different deployment contexts (say, a research use only build versus a clinical decision support build versus a diagnostic aid build) offers a cleaner story for validation and regulatory submission than a runtime flag system where features could theoretically be toggled in a production environment. Regulators like hard boundaries. Dead code elimination creates hard boundaries. This is worth stealing.

The GrowthBook-based runtime gating layer running alongside the compile-time system also reveals a mature dual-track approach: compile-time elimination for structural features that differ across deployment types, runtime flags for incremental behavioral tuning within a deployment type. Healthcare builders operating in multi-site deployment environments (which is most of them at any meaningful scale) should think carefully about which of their feature variations belong to each layer. The leaked source shows that even a company with the engineering depth of the organization that built this system found both layers necessary for production operation.

What the Roadmap Signals for Health Tech Investment Theses

The leaked source contains a list of undisclosed API beta headers representing features not yet public, and for investors, this list is essentially a forward-looking product roadmap for the most widely deployed AI agent platform. A few are particularly relevant for healthcare investment theses.

The context-1m beta header points to a 1M token context window, dated August 2025 in the source. For healthcare, this is significant because the workflows that most need AI assistance – complex case management, multi-encounter longitudinal analysis, comprehensive chart review – are exactly the ones where current context limits force fragmentation, which introduces errors. A 1M context window changes the architecture of what is possible for longitudinal clinical AI. The companies building on the assumption that 200K context is the ceiling may need to revisit their architecture assumptions sooner than they think.

Task budgets (task-budgets-2026-03-13) and effort control (effort-2025-11-24) are both in the unreleased beta headers. For healthcare, these translate directly to cost governance and workflow time management, both of which are top-tier procurement objections for clinical AI. An agent that can be given an explicit task budget – spend no more than $X in compute to complete this prior auth review – and an explicit effort level – do a quick check versus an exhaustive review – is far more deployable in a healthcare operations context than an agent with unbounded resource consumption. These are the kinds of controls that make AI palatable to CFOs and CMOs simultaneously.

Redacted thinking (redact-thinking-2026-02-12) is interesting from a liability and compliance angle. The ability to expose or suppress the agent’s reasoning chain based on deployment context matters a lot for healthcare companies navigating the dual pressures of explainability requirements (show your work) and IP protection (but not all of your work). An AI that drafts prior auth appeals might be required to explain its clinical reasoning to the payer, but a health system might not want to expose its internal decision logic. Configurable reasoning chain visibility is a feature that resolves a genuine compliance tension.

AFK mode (afk-mode-2026-01-31) and the associated transcript classifier for auto-approval map directly to the unattended agent use cases that are increasingly the target of healthcare AI investment – autonomous claim scrubbing, overnight coding review, background eligibility verification. These are tasks where human-in-the-loop approval at the action level is neither practical nor necessary, but where you still need audit trails and anomaly detection. The auto-approval classifier architecture in the leaked source is a validated approach to that problem.

The So-What: Practical Takeaways for Builders and Investors

The leaked source is not a gift to competitors in the narrow sense that they can copy Anthropic’s UI or business model. It is more valuable than that – it is a validated reference architecture for building production-grade AI agents, written by a team that had to solve the same problems healthcare builders are fighting with right now. Context entropy. Parallel workflow orchestration. Persistent memory. Tiered permissions. Proactive versus reactive UX modes. Staged rollouts in regulated environments.

Healthcare has a tendency to try to reinvent every pattern from scratch because the domain is specialized enough that practitioners distrust general solutions. Sometimes that instinct is right. HIPAA is real. Clinical liability is real. The regulatory environment for AI in clinical settings is genuinely more complex than general enterprise software. But the core agent architecture problems – how do you manage context over long workflows, how do you parallelize task execution safely, how do you build permissions that balance automation with human oversight, how do you roll out features in a validated way – are not healthcare-specific problems. They are software engineering problems. And the leaked source shows how a very good engineering team solved them.

For investors evaluating health tech AI companies right now, the leaked source is a useful benchmark. Any company pitching a clinical AI agent should be able to articulate how it handles context entropy over multi-session workflows. If the answer is basically just storing everything in a long context window and hoping the model handles it, that is a red flag. Any company building autonomous clinical workflow agents should be able to describe its permission and risk classification system. If the answer is human approval on every action or conversely no governance layer at all, both are architectural immaturity signals. Any company targeting the unattended agent market in healthcare should have a story for how its auto-approval logic works and how it maintains audit trails.

The companies that will win in clinical AI over the next three to five years are the ones treating agent infrastructure with the same rigor that the leaked source reveals – as a set of deeply considered, production-hardened engineering problems, not as a thin wrapper around a foundation model API. The bar is now visible. It is high. And as of March 31, 2026, anyone who wants to read the specs is about 1,900 GitHub forks away from having the full picture.​​​​​​​​​​​​​​​​

Introduction: The Un-AI Company

What b.well Actually Built

The Partnership Sequence That Changes the Story

The Technical Architecture Nobody Talks About

The Data Refinery as a Real Moat

Health Skills and the Product Roadmap Signal

The Competitive Risks Worth Taking Seriously

The Investment Thesis

Abstract

b.well Connected Health is a Baltimore-based health data infrastructure company founded in 2015 by Kristen Valdes and Bryan Jones. Total disclosed funding is approximately $116M across 10+ rounds, with the most recent being a $40M Series C in February 2024 followed by $20M in Trinity Capital growth debt in July 2025. The company has not publicly disclosed a valuation but is trading on Nasdaq Private Market.

Key facts: 2.4 million provider connections, 350+ health plan and lab connections, FHIR-native canonical data model, 13-step proprietary Data Refinery, four SDK surfaces (Web TypeScript, Android Kotlin, iOS Swift in progress, AI via MCP), white-label AI assistant called bailey, and a compliance product line tied to NCQA-certified digital quality measures.

Partnership sequence Oct 2025 through Mar 2026: Google (Oct 2025), SDK launch (Dec 2025), OpenAI/ChatGPT Health (Jan 2026), bailey white-label (Feb 2026), athenahealth point-of-care workflow (Feb 2026), Samsung/Kill the Clipboard (Mar 2026), Perplexity Health (Mar 2026).

Confirmed tech stack via sub-processor disclosure (effective Jan 5, 2026): AWS (infrastructure), Databricks (data processing), MongoDB (database), Redis (caching), Fivetran (ETL), Sigma Computing (analytics/BI), Groundcover (observability), Sentry (errors), Wiz (cloud security), Descope (identity), CLEAR (identity verification), CloudBees (feature flags), Mixpanel (app analytics), Iterable/Twilio (communications), [Tonic.ai](http://Tonic.ai) (synthetic data/de-identification).

Additional confirmed from GitHub and 2021 tech blog: Apache Kafka (event streaming), Elasticsearch (search), ClickHouse (OLAP analytics), GraphQL (query layer), CQL (clinical quality logic), Kubernetes/Helm (deployment), Python (data engineering), Node.js (FHIR API server).

Open investment questions: current valuation unknown, no disclosed revenue or customer metrics, iOS SDK still listed as coming soon, Torch acquisition by OpenAI creates internalization risk, Microsoft chose HealthEx over b.well for Copilot Health.

Introduction: The Un-AI Company

There is a company sitting at the center of the most important AI health launches of the past six months that has not raised a mega-round, has not been on the cover of anything, and most people in health tech have never heard of. That company is b.well Connected Health, and the reason it does not get written about is exactly the reason it is worth understanding. It is not building AI. It is building the thing AI needs before it can work in healthcare at all.

To get the full picture, back up to January 7, 2026. OpenAI announced ChatGPT Health, its dedicated health AI product that allows users to connect their actual medical records to their conversations with the model. The announcement was huge. The coverage was everywhere. The thing most of that coverage missed, buried in the press release, was that the health data connectivity infrastructure powering the whole thing was b.well. Not OpenAI’s in-house data team. Not a bespoke API integration built by some well-funded startup. A Baltimore company with under $120M in disclosed capital that had spent the better part of a decade building the plumbing nobody else wanted to build.

That is not a lucky break. By the time the OpenAI deal landed, b.well had already signed Google (October 2025), launched the first SDK designed specifically for health AI assistants (December 2025), introduced a white-label AI assistant called bailey (February 2026), partnered with athenahealth on bidirectional point-of-care data sharing (February 2026), expanded a two-year Samsung partnership into a full Kill the Clipboard implementation at HIMSS (March 2026), and signed Perplexity for its new health product (March 2026). That is five major platform partnerships in five months, each one with one of the most prominent technology companies on earth, all funneling through the same data layer.

The framing that matters here is infrastructure versus application. Applications get acquired, disrupted, or commoditized. Infrastructure, if it becomes the standard, gets buried into the foundation and stays. The question for investors and founders watching this space is whether b.well has actually become infrastructure, or whether it just looks that way from the press release cadence.

What b.well Actually Built

The company’s official description calls it a FHIR-native digital health platform with a connected health data network. That is technically accurate and almost completely useless for understanding what it does. Here is the more useful version.

b.well spent roughly a decade quietly onboarding as a trusted third party to every major payer and provider in the country, leveraging the information blocking rules and patient access API mandates created by the 21st Century Cures Act and CMS interoperability regulations. By the time those regulations had teeth, b.well already had two million provider connections and three hundred payer connections. That network is the foundation. Everything else, all the AI products, all the SDK surfaces, all the enterprise software, runs on top of that foundation.

The network connects through multiple interoperability rails simultaneously. Patient Access APIs mandated under ONC (g)(10), which are the richest data pathway because they require USCDIv3 content including unstructured clinical notes. TEFCA QHINs for the national exchange layer, though TEFCA only operates at USCDIv1, meaning it is less data-rich than the direct API connections. Regional HIEs and HINs. CMS Blue Button for Medicare. The VA. Proprietary pharmacy and lab networks. Payer claims APIs. The March 2026 technical blog post by Yelena Balin on the resource hub makes the competitive argument plainly: companies that claim 90% coverage by counting EHR vendor logos are using a meaningless metric because a single physician can document care across four different EHR systems at four different organizations, and if you are only counting vendor relationships you are missing three of those four. Real completeness requires NPI-level onboarding at individual clinic locations, not just system-level agreements.

On top of the network sits the Data Refinery. b.well describes it as a 13-step proprietary process that has been in development for a decade. What that means in practice is a pipeline that ingests data in every format healthcare has ever produced, including X12 claims, HL7 v2 messages, C-CDA documents, CSV files, and JSON APIs, converts everything into standardized FHIR R4 resources, and then runs a sequence of cleansing, validation, deduplication, normalization, enrichment, and compression steps before the data touches any downstream application or AI system. The CTO Imran Qureshi published a detailed technical walkthrough of this in January 2026 on the resource hub, including a worked example of a single prescription generating six separate records across EMR, HIE, pharmacy, insurance, patient app, and refill systems, each with overlapping but incomplete information, and how the refinery reconciles those into one clean current-state record. That is not a marketing story. That is the actual problem, and it is actually hard.

The refinery’s commercial importance for AI is the 10x LLM token reduction claim. Raw FHIR bundles are verbose, redundant, and expensive to process. A patient’s complete medication history as raw FHIR JSON might cost several hundred tokens per medication entry. The refinery compresses, reconciles, and structures that into a dense, AI-optimized representation. The compressed-fhir repository on GitHub is the technical implementation of that. Multiply the cost difference across every ChatGPT Health user who connects their records and runs health conversations, and the economic case for b.well sitting between the patient’s data and the language model becomes obvious.

The Partnership Sequence That Changes the Story

Read more

- YC W26 Demo Day: March 24, 2026, approx. 196 companies total

- Healthcare/Biotech companies in batch: 22 (roughly 11% of batch)

- Batch-wide context: 64% B2B, sub-1% acceptance rate, Rebel Fund estimates 35% of W26 companies score in top 20% of all YC companies ever evaluated

- Healthcare median seed: ~$4.6M vs. $3.1M batch-wide median

- Beacon Health notable outlier: Accel + Sequoia scout backing, Stanford/Harvard physician co-founder + ex-Amazon Alexa engineer co-founder

- Synthetic Sciences: $1.4M pre-YC + $500K standard deal

- Categories observed across the 22 companies: clinical operations/admin automation, primary care AI, drug discovery/computational bio, surgical planning, practice-specific verticals (dental, medspa, infusion), revenue cycle/billing, life sciences infrastructure, language/translation access, wearables, and medico-legal

- Key structural thesis: the batch signals a move from “AI in healthcare” as a concept to AI as the operational substrate of specific care workflows and discovery pipelines

- Three investability tiers proposed: high conviction (Beacon Health, CellType, Ditto Biosciences, Strand AI, Mango Medical), watch list (Origin, Overdrive Health, MochaCare, Eos AI, Prana, Scheduling Wizard, Rhizome AI, 10x Science), and early/niche (Ruma Care, [Patientdesk.ai](http://Patientdesk.ai), Tepali, Mantis, Opalite Health, Synthetic Sciences, Fort, OctaPulse, Docura Health, Wayco)

Table of Contents

Setting the Context: This Batch Is Different

The Cluster Map: How to Read 22 Companies

Clinical Operations and the Admin Automation Wave

Primary Care as Platform: The Most Crowded and Most Important Bet

Drug Discovery Goes Computational: The Science-Heavy End of the Batch

Surgical AI and the Procedural Frontier

Practice Verticals: Dental, Medspa, and Infusion

Revenue Cycle and Billing AI: Boring Name, Massive Market

Life Sciences Infrastructure and Research Tooling

The Sleepers and the Long Shots

How to Think About This as an Angel

Setting the Context: This Batch Is Different

Every YC batch gets called the strongest one yet. Usually that’s marketing. For W26, the data is slightly harder to dismiss. Rebel Fund, which has been running a machine learning model against every YC batch since 2013, published something before a single company presented: 35% of W26 startups scored in the top 20% of all YC companies ever evaluated. No prior batch has gotten close to that number. The distribution curve didn’t just shift at the top end – it shifted across the board.

About 196 companies showed up to Demo Day on March 24th. Of those, 22 tagged themselves under Healthcare / Biotech in the YC system. That’s roughly 11% of the batch, which is a meaningful concentration for an accelerator that historically skews B2B SaaS and developer tooling. For context, the batch overall was 64% B2B. Consumer barely registered at around 5%. Healthcare was one of the few categories punching above its historical weight.

That matters for a few reasons. YC acceptance is sub-1% from the application pool. The healthcare companies that make it through the filter are not random. They’ve been pressure-tested by partners who have now seen hundreds of health tech pitches across a decade-plus of batches. When YC starts concentrating health deals at 10%+ of a batch, they’re making a statement about where they think defensible businesses are being built.

What’s also worth noting before getting into the individual companies: the median seed round for YC healthcare startups sits around $4.6M, compared to $3.1M batch-wide. That gap is structural. Healthcare takes longer to build, costs more to distribute, and requires regulatory navigation that most other software categories don’t. When evaluating these 22 companies, keep that capital intensity reality in mind. A medspa operating system and a drug discovery company are not the same business, even if both are checking the Healthcare / Biotech box on the YC website.

The Cluster Map: How to Read 22 Companies

Read more

GE HealthCare closed a $2.3B all-cash acquisition of Intelerad on March 21, 2025, the largest enterprise imaging transaction in recent memory and arguably the most strategically significant OEM software bet in a generation. This piece unpacks what actually happened, what the capital stack tells us about healthcare IT value creation, and what downstream effects the deal is likely to produce across the imaging software ecosystem.

Key facts at a glance:

- Deal size: $2.3B all-cash

- Intelerad stats: 1,500 healthcare orgs, 230M exams/year, 8B images under management

- Projected Year 1 revenue: ~$270M, ~90% recurring

- Hg entry (2020): ~$650M valuation; exit (2025): $2.3B = roughly 3.5x in five years

- Intelerad founding: 1999, Rick Rubin and Christopher Henri, largely bootstrapped until ~2016

- First institutional capital: Novacap (~2016), followed by Hg (2020), TA Associates minority stake (2022)

- Key figure: Morris Panner (ex-Ambra Health CEO, then Intelerad President), Jordan Bazinsky (CEO)

Topics covered: deal mechanics and valuation math, Intelerad’s atypical cap table and what it signals, the Ambra acquisition as strategic linchpin, outpatient and ambulatory imaging as the structural thesis, competitive displacement dynamics, and what this means for health IT investors and operators.

GE Just Bought the Connective Tissue of Radiology

Most acquisition headlines in health IT are noise. A PE firm flipping an aging EHR, a strategist bolting on a point solution to shore up a product gap, a SPAC-era darling getting quietly absorbed at a write-down. This one is different.

GE HealthCare’s $2.3 billion acquisition of Intelerad, closed in March 2025, represents something genuinely structural: a legacy hardware OEM buying its way into the software and interoperability layer of imaging at a moment when that layer is, arguably for the first time, more valuable than the iron underneath it. The deal is worth understanding in detail because it is not just a corporate event. It is a signal about where enterprise imaging value will live for the next decade, and it carries direct implications for anyone investing in or building in the radiology IT space.

Start with the asset itself. Intelerad is not a startup and was never really positioned as one. Founded in Montreal in 1999 by Rick Rubin and Christopher Henri, it spent its first decade and a half doing something increasingly rare in enterprise software: growing organically, without significant external capital, into a genuinely global PACS business. By the time private equity showed up, the company had already built a real footprint across Canada, Australia, New Zealand, the UK, and the United States, with an enterprise sales motion and a customer base that actually renewed. For a software vendor in a notoriously sticky and slow-moving market like radiology IT, that matters more than it might seem.

The numbers GE is inheriting are not promotional math. One thousand five hundred healthcare organizations on the platform. Two hundred and thirty million exams processed annually. Eight billion images under management. And a revenue profile that would make most SaaS investors do a double-take: approximately $270 million in projected first-year revenue with roughly 90 percent of it recurring. That is not a software company that sells and churns. That is infrastructure. The kind of platform that gets embedded in hospital and imaging center workflows so completely that switching costs become existential, and the renewal conversation is less “should we continue” and more “who handles the paperwork.”

The Cap Table as Diagnosis

The capitalization history here is worth spending real time on because it is genuinely instructive and meaningfully different from the typical digital health narrative that this audience is used to hearing. Intelerad did not do a seed round. It did not take Series A money in the early 2000s when healthcare IT venture was just getting interesting. It did not optimize for a rapid exit or pursue growth-at-all-costs. For approximately the first fifteen years of its existence, the company was founder-funded and operationally self-sustaining, scaling through long enterprise sales cycles and compounding product quality rather than headline metrics.

The first major institutional capital came from Novacap, a Canadian PE firm, around 2016. This is the moment that matters from a structural standpoint: it marks the transition from a founder-led product vendor to a PE-backed platform company. Novacap entered during a period of what was reportedly 20 to 25 percent annual growth, which for a 17-year-old enterprise software company in a low-churn market is a genuinely impressive signal. They were not fixing a broken business. They were professionalizing a good one and setting it up for the more aggressive platform expansion that would come next.

Hg, the London-based software-focused PE firm with a strong track record in healthcare IT, took a majority stake in 2020 at a reported valuation of somewhere in the $650 to $700 million range. This is the number that makes the $2.3 billion exit so interesting. In five years, under Hg’s ownership, Intelerad went from a well-run mid-market enterprise imaging vendor to a platform asset worth 3.5 times more. That kind of return in healthcare IT, in a relatively boring software category, is not the result of hype or multiple expansion. It is the result of disciplined buy-and-build execution combined with a macro tailwind that Hg correctly identified early: the structural shift in imaging volume from inpatient hospital settings to outpatient and ambulatory environments.

TA Associates came in with a minority growth investment in 2022, which in retrospect looks like clean late-stage capital to fund continued M&A and enterprise expansion without diluting the equity structure heading into exit. Ardan Equity also co-invested alongside Hg. None of these are early investors in the classic venture sense. The “early” money was the founders themselves, and arguably Novacap as the first institutional check. That is the archetype worth paying attention to for capital formation purposes: bootstrapped-to-PE, not VC-backed-to-strategic. It is a path that health IT’s infrastructure layer has taken more often than the headlines suggest, and it tends to produce stickier businesses even if the timeline is less glamorous.

Ambra Was the Actual Move

If there is a single transaction that explains why GE paid $2.3 billion rather than something closer to one and a half, it is Intelerad’s 2021 acquisition of Ambra Health. This one deserves more attention than it got at the time.

Ambra Health was a cloud-native medical image management and sharing platform. Its core value proposition was interoperability: making it possible for imaging studies to move between hospitals, imaging centers, referring physicians, and teleradiology groups without the friction that has historically defined radiology IT. The company was led by Morris Panner, a Harvard Law graduate who came to health IT through an unusual path and turned out to be exactly the kind of operator that a platform-stage company needs. After the acquisition, Panner became President of Intelerad, which is a fairly reliable signal that Ambra was not just a feature acquisition but a foundational bet on where the market was going.

What Ambra brought to Intelerad was not incremental. It was one of the largest medical image sharing networks on the planet, connecting imaging environments that had spent two decades refusing to talk to each other. The interoperability layer in radiology is genuinely hard to build, not primarily for technical reasons, though those are real, but because of the organizational and contractual complexity of getting health systems, independent imaging centers, teleradiology networks, and referring physician groups to agree on how images should travel. Ambra had done the work. Intelerad absorbed that network and made it the connective tissue of the combined platform.

This changes the nature of what GE bought. A traditional OEM imaging acquisition would be a device company buying workflow software to differentiate the hardware sale, a classic defensive move to create switching costs around the modality install base. That is not what happened here. GE acquired an end-to-end imaging ecosystem: hospital PACS, ambulatory workflow, teleradiology connectivity, image sharing, and a cloud architecture that was genuinely cloud-first before cloud-first was a marketing claim rather than an actual infrastructure decision. The Ambra layer means that GE can now offer something to health system CIOs and imaging directors that it has never been able to offer before: not a device, not a viewer, not a departmental solution, but a single connected platform that spans every imaging environment in their network, with the hardware relationships already established and an AI development layer being built on top of it.

The Ambulatory Thesis

The structural reason this deal makes sense is not complicated once you understand where imaging volume is actually going. For most of the last 30 years, the economic logic of radiology IT followed hospital capital. Big systems bought big PACS from Philips, Fuji, GE, Agfa, and a handful of others. The vendors sold hardware first and bundled software as the incentive to close. The sales cycles were long, the procurement committees were large, and the switching costs were enormous. It was a market optimized for incumbent advantage and hardware margin.

That model is under pressure from a structural shift that has been building for a decade and accelerated meaningfully in the post-COVID period: imaging volume is migrating to outpatient and ambulatory settings at a pace that is changing the economics of the entire sector. According to industry analysis, outpatient imaging now accounts for somewhere between 65 and 70 percent of total imaging volume in the United States, a figure that has increased steadily as reimbursement policy, patient preference, and health system economics all point in the same direction. Imaging centers, urgent care facilities, orthopedic surgery centers, and multi-specialty outpatient groups are capturing procedures that used to require a hospital admission or at minimum a hospital outpatient department.

The problem for traditional OEM vendors in this environment is that the ambulatory market does not buy hardware and software the same way a hospital does. Ambulatory imaging customers are more cost-sensitive, more likely to make software decisions independently of hardware decisions, and more likely to care about workflow interoperability because they are, by definition, part of a referral network that runs through multiple organizations. They need to send images to hospital radiologists, receive reports from teleradiology groups, and make studies accessible to referring physicians who may be working across five different EHR environments. The traditional PACS vendor model, which assumed the imaging department was a closed system within a single institution, does not fit this customer well.

Intelerad was built for this. Its cloud-first architecture, its image sharing network, and its workflow tools were explicitly designed for environments where imaging does not stay inside institutional walls. The company’s growth under Hg was not accidental; it reflected a thesis that the ambulatory segment was underserved by existing solutions and would consolidate around vendors who could provide genuinely interoperable infrastructure rather than departmental tools dressed up as platforms. GE, which had strong hardware relationships in the ambulatory market but no credible software story, could not compete for the platform conversation. Now it can.

Competitive Displacement Is Not Hypothetical

For anyone in this audience who is either invested in or building imaging IT software, the second-order effects of this deal are worth thinking through carefully because the competitive dynamics are going to move faster than most mid-market players are positioned for.

The imaging software market below the top tier has been surprisingly fragmented given the consolidation pressure that has characterized most of health IT over the last decade. There are a meaningful number of vendors competing for radiology IT contracts in the community hospital, regional health system, and ambulatory imaging segments: companies that have built real products, real customer bases, and real revenue, but whose platform ambitions have been constrained by capital and distribution. Those vendors are now facing a fully integrated competitor with GE’s balance sheet, global device distribution network, existing relationships inside imaging departments at thousands of institutions, and an Intelerad platform that is already operating at scale in their target markets.

The question for the leadership teams of those companies is not whether they would prefer to remain independent. Most of them would, and some of them have the product quality and customer loyalty to make a credible argument for why their customers should stick around. The real question is whether the market will give them the time and space to make that argument before the integrated GE-Intelerad stack becomes the default procurement answer for imaging IT in ambulatory and mid-market enterprise settings. Based on historical precedent in health IT, when a large strategic combines a strong distribution engine with a credible platform product, the consolidation pressure on the second and third tier of the market tends to arrive faster and with less warning than anyone planned for.

There is a specific dynamic in radiology IT that makes this particularly acute: the imaging director or CIO who is managing a best-of-breed stack with multiple point solutions across PACS, image sharing, workflow, and AI faces a real argument from GE that consolidation onto a single platform reduces administrative complexity, simplifies vendor management, and potentially reduces total cost of ownership even if the per-seat pricing is not the lowest in the market. That argument has always existed in enterprise software. It is more compelling when the platform vendor can also service the hardware in the imaging suite and has pre-existing relationships with the radiology group. The consolidation thesis just got a very large distribution engine behind it.

What the Hg Return Actually Tells Investors

The 3.5x return on a five-year hold in enterprise imaging software is worth parsing carefully because the lesson is more specific than “healthcare IT PE works.” The lesson is about what kind of healthcare IT PE works, and under what conditions, and with what kind of operating discipline.

Hg did not buy a high-growth SaaS startup and ride multiple expansion to an exit. They bought a mature, profitable, recurring-revenue business in a market segment that was undergoing structural change, and they applied a disciplined platform construction strategy: identify the right infrastructure asset, acquire complementary capabilities that accelerate the interoperability story, build out the enterprise go-to-market, and wait for the strategic acquirer who needs what you have built to show up. The Ambra acquisition was not a growth bet. It was an infrastructure bet. The thesis was that the interoperability layer in imaging would become the most valuable part of the stack, and that whoever controlled it going into the consolidation cycle would exit at a premium to anything that could be justified by revenue multiples alone.

That thesis proved correct, and it produced a return that most healthcare IT venture investments would envy. For investors in this audience thinking about where similar dynamics might exist, the pattern is worth generalizing: mature software businesses in infrastructure-adjacent healthcare IT categories, where interoperability is underbuilt and the market is undergoing structural volume shifts, have historically been undervalued relative to their strategic worth. The Intelerad case is a clean example of a PE firm correctly identifying that gap, having the patience to build through it, and timing the exit well.

The TA Associates minority investment in 2022 is a small but instructive data point in this regard. Coming in three years before the exit at a valuation that implied meaningful upside, it suggests that sophisticated late-stage growth investors were validating the Hg thesis without needing the OEM acquisition to materialize immediately. The platform was valuable on its own terms, and the strategic exit was a bonus rather than the only path to return.

The AI Layer Question

Any piece on enterprise imaging in 2025 that does not address AI is incomplete, so here it is, stated plainly: the AI layer in radiology is real, it is growing, and GE’s acquisition of Intelerad changes the AI conversation in this market in a way that is not fully appreciated in most of the coverage this deal has received.

The challenge for AI in radiology has never been algorithmic. The models for detecting pulmonary nodules, pneumothorax, incidental findings, and a growing list of other pathologies are good and getting better. The challenge has always been integration: getting AI inference into the actual reading workflow, in the right clinical context, with the right routing logic, at the scale of a functioning imaging operation. That problem is fundamentally a platform problem, not a model problem. And it is the reason that the most sophisticated AI deployment strategies in radiology have consistently required either deep EHR integration, deep PACS integration, or both.

Intelerad’s platform, combined with GE’s existing AI development efforts under the Edison platform, gives the combined entity something that most AI vendors in radiology do not have: a native integration path into the imaging workflow at scale, across hospital and ambulatory environments, with the device relationships that provide ground truth training data at volume. That is not an incremental advantage. It is a structural moat that will take competitors years to replicate, if they can replicate it at all. For the stand-alone radiology AI vendors who have built strong models and are competing for enterprise deployment contracts, the question of whether to build toward Intelerad or to position as an alternative to the GE stack is now more consequential than it was six months ago.

What Morris Panner and Jordan Bazinsky Actually Built

It is worth ending on the people, because the asset that GE acquired did not happen by accident and it did not happen because of favorable market conditions alone.

Morris Panner took Ambra Health from a promising cloud imaging startup to the kind of scaled interoperability platform that a company like Intelerad would pay a meaningful premium to absorb. The Ambra story is, in some ways, the more instructive entrepreneurial case study in this deal: a founder who identified that the real problem in radiology was not storage or computation but connectivity, built a product that solved for that specifically, and navigated the organizational complexity of convincing health systems to change their image sharing behavior in a market notorious for resistance to workflow change. That Panner then stepped into the Intelerad president role and helped steer the combined platform to a $2.3 billion strategic exit is a clean example of what happens when a founder’s thesis is validated by an acquirer who is building toward the same vision from a different direction.

Jordan Bazinsky, as CEO of Intelerad through the Hg era and into the exit, oversaw the platform construction phase that turned a good PACS business into the kind of integrated imaging infrastructure asset that commands a strategic premium. The consistency of execution over five years, across multiple acquisitions, in a market that does not reward shortcuts, is the kind of operational discipline that PE-backed scaling in healthcare IT requires and rarely gets.

The deal sets a template. Not just for valuation or for exit mechanics, but for what healthcare IT platform construction can look like when the fundamentals are right from the beginning: long-term thinking on capital structure, genuine infrastructure positioning rather than point-solution optimization, interoperability as a first-order product priority rather than an afterthought, and the patience to build toward a strategic moment that may take years to arrive. Two point three billion dollars, all cash, closed in March 2025. The math is instructive. The story behind the math is the part worth studying.​​​​​​​​​​​​​​​​

Section 1: How a 30-Year-Old HIPAA Mandate Finally Became a Rule

Section 2: What the Rule Actually Does (and What It Punted On)

Section 3: The Math: $782M in Annual Savings and $478M in Costs

Section 4: The Infrastructure Stack This Creates

Section 5: Investment Implications and the Market That Just Opened Up

Abstract

- Rule: CMS-0053-F, “Administrative Simplification; Adoption of Standards for Health Care Claims Attachments Transactions and Electronic Signatures,” published March 24, 2026

- Effective date: May 26, 2026. Compliance deadline: May 26, 2028

- Core action: First-ever HIPAA-adopted standards for health care claims attachments, mandating electronic exchange of clinical documentation (medical records, lab results, imaging, clinical notes, telemedicine visit documentation) in support of claims

- Standards adopted: X12N 275 (v6020), X12N 277 (v6020), HL7 C-CDA IG Volumes 1 and 2, HL7 Attachments IG (March 2022), and a digital signatures framework

- What got dropped: Prior authorization attachment standards, which were pulled from the final rule after industry pushback on misalignment with FHIR-based prior auth mandates

- Estimated annual savings: $781.98M. Estimated annual compliance cost: $478.23M. Net annualized cost (7% discount rate): $303.75M

- Applies to all HIPAA-covered entities: health plans, clearinghouses, and providers that conduct electronic transactions

- Why it matters to this audience: The rule is a hard regulatory forcing function creating a 24-month sprint for compliance infrastructure buildout, and a multi-hundred-million dollar market signal for vendors in the clinical data exchange, administrative AI, and health IT middleware spaces

Section 1: How a 30-Year-Old HIPAA Mandate Finally Became a Rule

Here is a fact that should make every health tech investor feel something between despair and opportunity: HIPAA was signed in 1996. It included a mandate for the Secretary of HHS to adopt standards for health care claims attachments. Thirty years later, on March 24, 2026, CMS finally published that rule. This is not a nuance of regulatory process. This is a structural market signal about how long it takes for a regulatory gap to close in healthcare, and what happens on the other side when it does.

To be fair to the people who tried before, this is not the first attempt. CMS published a proposed rule on claims attachment standards way back in September 2005 (70 FR 55990), targeting specific service categories like ambulance, laboratory, and emergency department documentation. The industry shot it down, citing technical immaturity. The standards weren’t ready, the vendors weren’t ready, and the EHR ecosystem that would need to generate these structured documents essentially didn’t exist yet. So CMS shelved it. Then the Affordable Care Act in 2010 reiterated the mandate and set a deadline of January 1, 2016 for adoption. That also didn’t happen. A second proposed rule landed in December 2022 (87 FR 78438), and after years of comment periods, SSO consultations, and the prior auth wars described below, the final rule landed in early 2026. You really can’t accuse the feds of rushing this one.

What changed between 2005 and now is actually a pretty interesting story for builders. The CDA standard (Clinical Document Architecture, an HL7 XML-based markup for clinical documents) matured dramatically. C-CDA, the Consolidated CDA, became the de facto structured clinical document format across EHR vendors through Meaningful Use mandates. By the time CMS got serious about this rule, there was a functioning, if imperfect, ecosystem of C-CDA generation across most major EHR platforms. That’s not a coincidence. The HIPAA attachments standard being adopted here is X12N 275/277 paired with HL7’s C-CDA, which means the plumbing that EHRs already built for other interoperability mandates is now being pressed into service for claims workflows. That’s the foundational technical logic of the rule, and it explains why the compliance timeline is 24 months rather than something longer.

The other piece of context worth understanding is the CAQH CORE environmental scan from 2019, which CMS cites in the rule. CAQH found that the industry broadly lacked direction for attachment automation, that vendors and payers weren’t converging on even a small number of electronic solutions, and that paper-based and fax-based workflows remained dominant for claims attachment requests. By some estimates, the U.S. healthcare system was still processing tens of millions of attachment requests annually via fax or portal upload as recently as 2024. That’s the market baseline this rule is attacking.

Section 2: What the Rule Actually Does (and What It Punted On)

Read more

What MCP Actually Is (and Why Everyone Keeps Explaining It Badly)

The Healthcare Interoperability Problem MCP Was Born to Solve

Athena’s Big Bet: First Mover in the EHR Space

The Real Risk Surface: HIPAA, PHI, and the Confused Deputy

Where MCP Belongs in Healthcare (and Where It Doesn’t)

Investment Thesis: What This Means for Founders and Angels

Abstract

- MCP, open-sourced by Anthropic in late 2024 and donated to the Linux Foundation in Dec 2025, solves the classic M x N integration problem for AI agents connecting to enterprise systems

- Athenahealth announced Aug 2025 an industry-first MCP server on athenaOne APIs, framing it as the connective tissue for their AI-native platform serving 160,000+ providers

- The protocol dramatically lowers the cost of building agentic health tech, but introduces serious HIPAA/PHI risk surface that founders and investors cannot ignore

- FHIR + MCP is the architectural stack that will define the next generation of clinical workflow tools

- Investment implications span ambient documentation, prior auth automation, clinical decision support, and interop infrastructure

What MCP Actually Is (and Why Everyone Keeps Explaining It Badly)

There’s a particular flavor of tech explanation that shows up in healthcare conferences where someone puts up a slide with a bunch of boxes and arrows and calls it “interoperability.” MCP has started getting that treatment. So let’s skip the slide deck version.

MCP, or Model Context Protocol, was originally released by Anthropic in late 2024 as an open standard, and then donated to the Linux Foundation’s Agentic AI Foundation in December 2025. The spec has since attracted formal backing from OpenAI, Google DeepMind, Microsoft, and AWS, which is about as close as you get to a consensus standard in AI infrastructure. As of mid-2025, there were reportedly over 5,000 active MCP servers listed in the Glama MCP Server Directory, with more than 115 production-grade vendor implementations.

The core problem MCP solves is what computer scientists call the M x N integration problem. If you have five AI models and five enterprise systems, you don’t have ten integrations, you have twenty-five. Each model needs custom glue code for each system. Every time the model updates or the API version changes, something breaks. Multiply that across a health system’s tech stack, which might include a primary EHR, a PACS system, a lab information system, a scheduling platform, and several revenue cycle tools, and the engineering cost of connecting AI agents to real clinical data is enormous. MCP flattens that matrix. Instead of point-to-point custom integrations, every model plugs into MCP and every system plugs into MCP. The analogy that has stuck, because it’s genuinely accurate, is USB-C. One port, multiple devices, standardized handshake.

Technically, MCP operates over a lightweight JSON-RPC layer and defines three core building blocks for how AI agents interact with external systems: action tools (things the agent can do), read-only resources (data the agent can pull), and reusable prompt templates. The agent doesn’t need to know the underlying schema of your EHR or your billing system. It expresses a need, the MCP server handles the translation, applies access controls, and returns a structured response. The host layer can be built to encrypt in transit, log every call, and enforce least-privilege access. Done right, it’s actually a more auditable architecture than a lot of the bespoke integrations currently running in production across health systems.

The reason this matters specifically in healthcare is that health data is probably the most structurally complex regulated data domain that exists. FHIR, HL7, DICOM, LOINC, SNOMED, RxNorm, ICD-10, prior auth formats, payer-specific EDI, state-level HIE feeds, the list goes on. Before MCP, connecting an LLM to even a subset of this required domain-specific engineering that only a handful of teams really got right. What MCP does is provide the standardized discovery and communication layer that makes it possible for a well-built agent to navigate that complexity without custom hardcoding. When paired with FHIR R4, which is the current gold standard for structured clinical data exchange, you start to get a stack that can actually express the full context of a patient encounter to an AI model in a controlled, auditable way.

The Healthcare Interoperability Problem MCP Was Born to Solve

Read more

- Abstract

- The Staffing Crisis Nobody Wanted to Talk About

- What Sequoia Got Right (and What They Left Out)

- Revenue Cycle Is Just the Warm-Up

- The Physical Layer: Why Robots Are the Real Endgame

- What This Means for Investors and Founders Right Now

- The Uncomfortable Math

Key data points and framing:

- US hospital labor costs = ~60% of total operating expenses, up from ~55% pre-pandemic

- Nursing shortage projected at 450,000 RNs by 2025 per McKinsey; actual shortfalls worse post-COVID

- Travel nurse spend alone hit ~$11.6B in 2022 (Kaufman Hall); some systems spent 40% of nursing budget on agency

- Healthcare revenue cycle outsourcing = $50-80B TAM per Sequoia’s own mapping

- Physical/robotic automation in hospitals still under 5% penetration by most estimates

- Hospital systems operate on 1-3% net margins even in good years; labor is the single largest lever

- Sequoia’s core thesis: for every $1 spent on software, $6 goes to services; in healthcare the ratio is probably closer to 1:10 or worse

- The robot market in healthcare logistics/clinical support expected to reach $12B+ by 2030 (various analyst estimates)

- AI agent software replacing services = the first wave; humanoid and task-specific robots = the second wave; convergence of both = where the real wealth gets built

The Staffing Crisis Nobody Wanted to Talk About

The hospital staffing crisis did not sneak up on anyone. Workforce consultants, hospital CFOs, and healthcare economists were all saying the same things throughout the 2010s: the nurse pipeline was narrowing, physicians were burning out at alarming rates, and the demographics of the clinical workforce skewed old enough that retirement waves were inevitable. Everyone nodded along at conferences, published white papers, and then went back to optimizing charge capture and EHR implementations. The crisis arrived anyway, on schedule, and COVID poured accelerant on a slow fire and turned it into something unmanageable almost overnight.

What happened between 2020 and 2023 in hospital labor markets was not just a staffing disruption, it was a fundamental repricing of clinical labor. Travel nurses who were earning $35 an hour pre-pandemic were suddenly commanding $100, $120, even $150 per hour on short-term contracts. Kaufman Hall tracked aggregate travel nurse spend reaching $11.6 billion in 2022 across major health systems, a number that would have seemed implausible in 2019. Some large regional systems were allocating 35 to 40 percent of their total nursing budget to agency and travel contracts just to keep units staffed. The economics were ruinous, and the margin compression was immediate. For context, most nonprofit hospital systems operate on net margins between one and three percent in a good year. A 15-point swing in nursing labor cost is not an inconvenience, it is an existential event.

The systems that survived relatively intact were the ones that had invested in workforce management infrastructure, or that happened to be located in markets with stronger pipeline programs. The ones that struggled most were community hospitals and rural systems with no pricing power over labor markets and no institutional reserves to absorb the shock. A number of them did not survive at all. Rural hospital closures accelerated, and the M&A activity in nonprofit healthcare during 2022 and 2023 was largely driven by distressed assets being absorbed by larger systems that could spread fixed costs across more volume.

All of this matters for the investor and entrepreneur thesis because it created something rare in healthcare: genuine urgency around the cost structure. Hospital executives who had resisted labor substitution for years, partly for patient safety reasons and partly because of union dynamics, suddenly found themselves in board conversations where the alternative to automation was insolvency. That kind of urgency is the conditions under which technology adoption actually accelerates in an industry that otherwise moves at a geological pace. The window opened, and it stayed open because the structural drivers did not go away when the acute crisis eased. The nursing shortage projected by McKinsey at roughly 450,000 RNs by the mid-2020s was not a post-pandemic artifact, it was a pipeline and demographic problem that was going to show up regardless. Post-pandemic stabilization just masked the underlying deficit for a few years while systems burned cash on agency contracts.

What Sequoia Got Right (and What They Left Out)

Sequoia’s March 2026 framework on services as the new software is genuinely useful and worth reading seriously. The core observation is clean: for every dollar spent on software, six go to services. Autopilot companies that sell the work rather than the tool capture the services budget from day one rather than hoping to expand from a tool contract later. The framing of intelligence versus judgement as a way to identify which service categories are ripe for automation first is also solid. High intelligence ratio, already outsourced, outcome-based purchasing, clear ROI: those are the four conditions that make a category ready for an autopilot to walk in and replace a vendor contract.

Sequoia’s opportunity map places healthcare revenue cycle at 50 to 80 billion dollars in outsourced spend, calls it almost pure intelligence work, notes the outsourcing is already mature and outcome-based, and names Anterior as the furthest along. That is all directionally correct. Medical coding is genuinely the translation of clinical documentation into roughly 70,000 standardized ICD-10 codes. The rules are Byzantine, but they are still rules. A well-trained model with the right clinical context handles this better than offshore coders working under productivity quotas, and it scales in a way human coding teams cannot. Authorization management is a similar story. The average prior auth workflow involves querying payer portals, matching clinical criteria against coverage policies, drafting appeal letters when denials come back, and tracking everything through resolution. There is almost no judgement in that workflow, just rules running against rules, which is exactly where AI agents operate best.

What the Sequoia piece does not fully develop, for understandable reasons since it is a generalist framework, is that revenue cycle is really just the anteroom in healthcare. The bigger rooms are clinical operations, supply chain, environmental services, patient transport, and the physical coordination work that makes a hospital function as a physical plant. These categories represent labor spend that dwarfs revenue cycle, and they sit on the other side of a wall that software alone cannot cross. Revenue cycle workers sit at computers. They push data. Replacing them with software agents is a distribution and integration problem, hard but tractable. The nurses, the surgical techs, the phlebotomists, the patient transport staff, the people doing medication delivery and environmental services rounds: they move through physical space, they touch patients, they carry things, they respond to unpredictable real-world conditions. Software cannot help you there. Robots can.

The other thing the framework undersells, not incorrectly but incompletely, is compounding. The autopilot companies that win in healthcare will not win because they automated one revenue cycle function. They will win because every claim they touch, every auth they process, every coding decision they make feeds a model that gets better at the next decision. The data moat in healthcare AI is not metadata or clickstream data, it is actual clinical and financial transaction data flowing through real workflows. The companies that get into the workflow early, even on the narrow intelligence tasks, are the ones that will have the proprietary data stack to eventually handle more judgement-adjacent work. The wedge is always about data accumulation as much as it is about revenue.

Revenue Cycle Is Just the Warm-Up

Being concrete about where the AI agent opportunity in healthcare revenue cycle actually sits is useful because it tends to get oversimplified in both directions. Some people treat it as solved because a few well-funded companies exist. Others dismiss it as too complex given payer variability and clinical documentation quality. The honest answer is that it is neither solved nor impossibly complex. It is a large, fragmented market where the structural conditions for disruption exist but where execution is genuinely hard.

The revenue cycle technology market, inclusive of outsourced services, software, and hybrid arrangements, is probably somewhere between 100 and 150 billion dollars in aggregate annual spend in the US. That number includes the big outsourcing players like Optum360, Conifer, Ensemble Health, and nThrive, but also the technology vendors selling into the insourced revenue cycle functions at large health systems. The pure outsourced services slice that Sequoia sizes at 50 to 80 billion is the more immediately actionable target for autopilot-style companies, because those contracts already price on outcomes rather than seats.

The specific functions where AI agents are making real traction right now are prior authorization, denial management, coding, and patient financial clearance. Prior auth is a particularly good example because the workflow is well-defined, the downstream financial impact is enormous, and the human workforce doing this work is almost entirely keyboard-based. A single academic medical center might have 60 or 80 full-time employees doing nothing but prior authorization management. At fully loaded labor costs of 70 to 90 thousand dollars per head, that is six to seven million dollars annually in a single department, at a single hospital, for one function. The national aggregate is several billion dollars. Replacing even half of that with agents is a meaningful business.

Denial management is the downstream version of the same problem. When authorizations fail or claims get denied, someone has to identify the root cause, determine whether an appeal is worthwhile, draft the appeal, route it correctly, and track it through resolution. The denial rate across the industry averages somewhere between 5 and 10 percent of submitted claims, with enormous variation by payer and by specialty. At a health system doing two billion in net revenue, a 7 percent denial rate with 40 percent recovery through appeals represents hundreds of millions of dollars in at-risk revenue annually. The people managing that process are not doing complex clinical reasoning. They are running decision trees against payer policies. Agents do that work well, often better than humans on pure accuracy, and without the attrition and training costs that plague large revenue cycle departments.

The next wave inside revenue cycle is going to be more interesting than what exists now, because it will start to touch functions that currently require some coordination between revenue cycle and clinical operations. CDI, clinical documentation improvement, is a good example. CDI specialists are typically nurses or experienced coders who read physician documentation and identify gaps or ambiguities that could affect coding accuracy and therefore reimbursement. That work sits at the boundary of intelligence and judgement, because it requires reading clinical context, not just applying rules to structured data. Models that are good enough to do CDI work at scale would unlock a much larger revenue impact than pure coding automation, and a few companies are starting to make credible moves in that direction.

The Physical Layer: Why Robots Are the Real Endgame

Sequoia’s autopilot framework is mostly a software frame. Sell the work, not the tool, capture the services budget, let model improvements compound your margins. That thesis is correct and there will be multiple large businesses built on it in healthcare. But it stops at the edge of physical space, and that is where the genuinely large healthcare labor story lives.

Hospital labor economics are brutal in ways that software cannot fully address, because a significant portion of hospital labor is irreducibly physical. The Bureau of Labor Statistics data on hospital labor composition is instructive here. Registered nurses represent roughly 25 to 30 percent of hospital FTEs. Allied health professionals, including surgical techs, respiratory therapists, imaging techs, and physical therapists, account for another 15 to 20 percent. Environmental services, patient transport, dietary, and facilities together account for somewhere between 10 and 15 percent of FTEs at most large systems. Physicians and advanced practice providers are another 15 to 20 percent. Administrative and revenue cycle staff, the people software agents can most directly replace, are maybe 20 to 25 percent of the total.

So even a perfect outcome in software-based automation of administrative work might address 20 to 25 percent of hospital FTE spend. The other 75 to 80 percent involves physical presence, clinical assessment, hands-on care, or some combination of those things. That does not mean it is immune to automation. It means the automation vector is robots, not software. And the transition from software automation to robotic automation in healthcare is not a far-future scenario anymore. Several distinct robot categories are already in deployment, and the investment activity in the space reflects genuine conviction that the trajectory is real.

The most mature category is surgical robotics. Intuitive Surgical has been a durable large cap for years, and the robotic-assisted surgery market is now large enough that multiple platforms are in serious clinical use. The argument for robotic surgery from a labor economics standpoint is not primarily about replacing surgeons, though over a very long time horizon that conversation will happen. The near-term argument is about extending surgical capacity, reducing fatigue-related variability, and allowing procedures to happen in settings that do not currently have access to subspecialty surgeons. That last point matters enormously for health system strategy, because surgical volume drives hospital margin in ways that few other service lines do.

The more interesting near-term investment category from a pure labor substitution angle is hospital logistics and environmental services. These are high-volume, repetitive, physical tasks that do not require clinical judgment, just reliable navigation, object manipulation, and task sequencing. Autonomous mobile robots for medication delivery, lab specimen transport, linen and supply distribution, and waste management are already deployed in a meaningful number of hospitals. Aethon TUG robots have been around long enough that they are now on their second generation of deployment at large academic medical centers. Moxi, developed by Diligent Robotics, handles room stocking and delivery tasks and has accumulated enough real-world hospital hours to generate actual operational data on labor impact. The early results from systems using these platforms are credible: somewhere between 30 and 60 percent reduction in staff time on the specific transport and logistics tasks the robots handle, which translates to either headcount reduction or redeployment to higher-acuity patient care work.

The next frontier, and the place where the investment community is writing the most speculative but also potentially most consequential checks, is humanoid robots in clinical settings. This is not yet a deployed product category in any meaningful sense. Boston Dynamics, Figure, 1X, and Apptronik are all building general-purpose humanoid platforms, and several of them have announced partnerships or pilot conversations with healthcare systems. The theoretical value proposition is significant. A humanoid robot that can reliably perform patient transport, ambulation assistance, vital sign collection, medication delivery, and environmental services rounds would address a substantial fraction of total nursing assistant and tech labor in a hospital. The current cost of a humanoid platform is still too high for the unit economics to work cleanly, but the trajectory on both cost and capability is steep. The analogies to industrial robotics adoption curves, and to early autonomous vehicle timelines corrected for hindsight, suggest a realistic deployment window of five to ten years for limited clinical tasks at scale.

The clinical judgment layer is where the timeline gets harder to specify. Replacing a nurse doing medication administration is not just a manipulation problem, it is a clinical assessment problem. The nurse administering a medication is also watching the patient’s color, noticing respiratory changes, asking questions, and making implicit assessments that are not documented anywhere but that matter enormously for patient safety. That layer requires multimodal sensing, natural language, and real-time clinical reasoning in a way that current robotic systems are not close to handling reliably. But the sub-tasks that do not require that level of clinical judgment, and there are more of them than most people acknowledge, are accessible to current and near-future robotic systems. The bet the smart investors are making is not that robots replace nurses entirely, it is that robots handle the intelligence-ratio tasks within nursing workflows and free clinical staff to concentrate on the judgment-intensive work. That is exactly the same framing Sequoia applies to software services, just translated to physical space.

What This Means for Investors and Founders Right Now

The investment thesis in healthcare labor automation is not one bet, it is a stack. The bottom of the stack is software agents automating revenue cycle and administrative functions, a market that is large, accessible today, and where the distribution mechanisms are relatively clear. The middle of the stack is logistics and environmental services robots, a category where the technology is proven enough to deploy but adoption is still in early innings and the sales cycle into hospital operations is long and relationship-dependent. The top of the stack is humanoid clinical robots, a category where the technology is still developing but where the value proposition is enormous enough that patient capital makes sense now even without near-term revenue.

For angel investors and seed-stage funds specifically, the most interesting check-writing zone right now is probably the intersection of AI agents and revenue cycle, because the time-to-revenue is shortest and the validation mechanisms are clearest. Health systems will tell you in a procurement conversation whether your automation is outperforming their current vendor. Denial management and prior auth are numerically scorable in ways that make the ROI conversation relatively clean compared to most healthcare sales. Companies in this space that are reaching meaningful revenue scale are also the most interesting acquisition targets for the large RCM outsourcing players, which creates a near-term exit path that is not dependent on public market conditions.

The more interesting but harder bet for investors who have longer time horizons is the robotic layer. The companies building clinical logistics robots are past the concept stage and into the scaling problem. The cost per robot is still high enough that the ROI math only works well at large systems, but that is the same early adoption pattern that every capital equipment category goes through. The systems that are adopting now are doing so partly because the economics are marginal but improving, and partly because they are positioning for a future where the labor shortage makes any alternative look attractive. The founders building in this space need to understand hospital operations deeply, not just robotics, and the best teams are typically coming out of clinical engineering backgrounds or long careers in health system operations rather than pure robotics labs.

The humanoid clinical robot bet is for the patient and technically sophisticated. There are real companies with real engineering progress, and several of the general-purpose humanoid platforms will eventually be deployed in clinical settings whether they are purpose-built for healthcare or not. The question is timing and which clinical tasks get unlocked first. Founders building specifically for healthcare deployment of humanoid platforms need a clear view on the regulatory path, which will be significant, and a realistic model for liability in clinical settings. Those are not insurmountable problems but they are real ones that add years to deployment timelines.

The common thread across all three layers is data. The AI agent companies that win in revenue cycle will win partly on their model quality and partly on the proprietary transaction data they accumulate. The robot companies that win in hospital logistics will win partly on hardware reliability and partly on the operational data they collect about hospital movement patterns, task completion rates, and failure modes. The future humanoid clinical platforms will win partly on general capability and partly on the clinical context data that makes them trustworthy in patient-facing settings. Healthcare is a domain where proprietary data is extraordinarily hard to acquire at scale, which means the companies that get into workflows early have structural advantages that compound. The wedge is always about more than the first dollar of revenue.

The Uncomfortable Math

It is worth being direct about something that tends to get softened in polite healthcare technology conversations. The ultimate value proposition of AI agents and clinical robots in hospitals is replacing human labor with software and hardware. That is not a side effect of the technology thesis, it is the thesis. The financial case for health systems is predicated on labor cost reduction. The investment case for the companies building these tools is predicated on labor being the dominant cost category in their target customer’s operating budget. Dressing this up as workforce augmentation or care quality enhancement is not wrong, those things are also true, but the unit economics work because labor gets replaced or reduced, not just augmented.

For a health system running a billion dollars in annual operating expense, with roughly 600 million of that being labor, a 15 percent reduction in total labor through a combination of agent-based administrative automation and robotic logistics would represent 90 million dollars in annual savings. At even a conservative three to four times multiple on savings, that is a business case that supports substantial capital investment. The hospital gets margin improvement, the technology vendor gets a large contract, and the investors backing the technology vendor get a return. The workers who lose jobs get, in the best case, redeployment to higher-acuity work and, in the less good case, displacement.

The healthcare investor and entrepreneur community tends not to dwell on that last part, and there are legitimate reasons for that beyond simple discomfort. Health systems genuinely are operating under financial conditions that threaten community access to care. Rural hospital closures hurt patients, not just shareholders. If robotics and AI can stabilize the cost structure enough to keep hospitals operating in underserved markets, there is a real public health argument alongside the financial one. That does not make the displacement question disappear, but it does mean the tradeoffs are genuinely complicated in healthcare in ways they might not be in, say, insurance brokerage.

What is not complicated is the direction of travel. Every major health system in the country has a workforce transformation initiative running right now. The language varies, some call it care team redesign, others call it operational efficiency, a few are honest enough to call it labor optimization, but the destination is the same. More work done by technology, fewer humans required per unit of care delivered. The companies that help health systems get there faster and with better outcomes will build large businesses. The investors who identify those companies early will generate strong returns. The timing on the robotic layer is the main uncertainty, not the direction.

The Sequoia thesis that services are the new software is right, and healthcare is the largest single services market in the domestic economy. The software automation wave is already breaking. The robotic wave is the one that will define the next decade of health system economics. Founders and investors who are thinking about this as a single market rather than two sequential waves are the ones who will position themselves correctly for both.​​​​​​​​​​​​​​​​The Labor Problem Healthcare Won’t Solve With Recruiting

The Conference in One Sentence

Epic Builds the Agent Factory

athenahealth Opens the Data Layer

RCM Is Getting Automated Whether Finance Teams Are Ready or Not

Google Goes All In With Health System Partners

Stryker Enters the Digital Hospital OS Race

Physical Automation Arrives on the Floor

Governance Finally Gets Its Moment

What the Pattern Actually Means

Abstract

Key HIMSS26 announcements across major themes:

- Epic previewed Agent Factory, a no-code visual builder letting health systems create, configure, and deploy custom AI agents within the Epic environment; revenue cycle AI tool Penny cut prior auth submission time 42% at Summit Health; coding-related denials down 20%+ at high-usage systems

- athenahealth launched athenaConnect, an intelligent interoperability layer covering 170,000 providers and 20% of the US population, and previewed a first-of-kind MCP server enabling authorized AI agents including Claude to access structured patient data directly inside athenaOne

- Google Cloud announced partnerships with Humana, CVS Health, Highmark Health, Waystar, and Quest Diagnostics all running Gemini-powered agentic AI; CVS launched Health100, a standalone health tech subsidiary built entirely on the stack; Waystar cited 15B+ in prevented denials since launching its AI

- FinThrive framed agentic AI as an operating model, not a feature, with autonomous workflows across 50+ use cases recovering 1.1% on underpayments for early adopters; XiFin debuted an autonomous Appeals Agent handling the full denials workflow end to end

- Stryker launched SmartHospital Platform via a new Smart Care business unit, combining ambient sensors, the Engage alarm-filtering middleware engine, voice-activated Sync Badge devices, and virtual nursing workflows

- Singulr AI launched Agent Pulse, a real-time AI agent governance platform; Sword Health launched Dawn, an always-on AI mental health product built on a proprietary clinical model with MindGuard safety classifiers

- Wolters Kluwer integrated UpToDate Expert AI into Microsoft Dragon Copilot and Teams; ModMed Scribe 2.0 hit 240,000 visits in under 100 days

- The through-line: HIMSS26 was not about what AI might do. It was about what AI is already doing, and the governance, infrastructure, and interoperability plumbing required to let it scale

The Conference in One Sentence

If HIMSS25 was the year everyone arrived with a generative AI slide deck, HIMSS26 was the year people started showing receipts.

That is the honest one-sentence summary of what happened in Las Vegas this week. The demos shifted. The conversations shifted. Health system buyers are not asking whether AI can help anymore. They are asking which vendors have actually deployed it, how many claims it touched, how many hours it returned, and what happens when it goes sideways. That last question finally has a vendor category of its own, which tells you something about how far this market has moved in twelve months.

The overarching theme, and it was not subtle, was agentic AI: systems that do not just surface recommendations but actually execute workflows without a human rubber-stamping every step. Revenue cycle, clinical documentation, physical logistics, patient data access, mental health, population health contracting. Agents everywhere. The vendors showing up with pure summarization tools looked like they brought a flip phone to a 5G conference.

Here is what actually mattered.

Epic Builds the Agent Factory

Epic came to HIMSS26 with outcomes data and a platform play, which is a more dangerous combination than most people give them credit for. The headlining announcement was Agent Factory, a no-code visual builder embedded inside the Epic environment that lets health systems configure, deploy, and monitor their own AI agents. The framing matters here. Epic is not shipping a pre-built agent and calling it innovation. They are handing health systems a development environment for building custom automation inside the EHR, which is a structurally different move.

The outcomes data they brought to the floor was hard to ignore. At Summit Health, Epic’s revenue cycle AI tool Penny cut medication prior authorization submission time by 42%, with 92% of AI-generated responses accepted without edits. At systems with the heaviest Penny usage, coding-related denials dropped more than 20%. For context, prior auth is one of the most expensive and despised administrative drags in ambulatory care. A 42% time reduction in that specific workflow is not a demo metric, it is a CFO conversation.

On the clinical side, Epic highlighted Chart with Art, its AI charting tool for bedside nursing, which Houston Methodist became the first system to deploy. Home care workflows are slated for April. The clinical AI story at Epic is quietly expanding from ambient documentation into workflows that touch actual care delivery, not just the administrative wrapper around it.

The strategic implication is the one worth sitting with. Epic is building a platform moat around agentic AI that competitors will find nearly impossible to replicate inside the health system enterprise. If Agent Factory gets real adoption, the health system AI stack becomes even more tightly coupled to Epic than it already was. Good news for Epic retention. Sobering signal for any company selling workflow automation into an Epic shop and hoping to survive the next three years.

athenahealth Opens the Data Layer

The single most technically interesting announcement at the conference, for anyone thinking seriously about the AI agent infrastructure layer in healthcare, was athenahealth’s MCP server. Model Context Protocol is the open standard that lets AI agents communicate with external systems in a structured, permissioned way. athenahealth previewed what it describes as an industry-first patient MCP server, enabling authorized AI agents, including Claude specifically, to access structured patient data directly inside athenaOne.

This sounds like a plumbing announcement. It is actually a strategic one. The core bottleneck for deploying AI agents in clinical environments is not the model quality. It is secure, structured data access. Getting an AI agent to actually do something useful in a healthcare context requires it to read and understand patient records, not just summarize free text it has been handed. athenahealth just built a formal, permissioned pathway for that to happen inside their EHR. The fact that they called out Claude by name in their press materials is notable and speaks to where enterprise AI partnerships are heading.

Beyond the MCP server, athenahealth also launched athenaConnect, an intelligent interoperability layer designed to serve as a single access point connecting 170,000 athenahealth providers, representing roughly 20% of the US population, to health systems, pharmacies, labs, and external partners. The framing was interoperability beyond compliance, meaning not just meeting the minimum FHIR requirements but actually making data actionable in real time at the point of care. They also hosted a panel at the conference asking whether LLMs can finally replace HL7 standards for interoperability, which is a genuinely interesting question that the industry is going to be arguing about for the next few years.

RCM Is Getting Automated Whether Finance Teams Are Ready or Not

Revenue cycle was the busiest category on the floor this year and for good reason. Administrative waste in US healthcare runs somewhere north of 400 billion dollars annually, and RCM is the single most tractable part of that problem for AI to attack. Several vendors showed up with autonomous agent deployments, not pilots.

FinThrive made the most aggressive positioning play, framing agentic AI not as a feature but as an operating model. Their Fusion data architecture runs autonomous workflows across more than 50 use cases, with early adopters reporting a 1.1% recovery rate on underpayments, translating to nearly a million dollars in recovered cash within three months of deployment. That is the kind of number that gets a CFO to pick up the phone.

XiFin debuted its Empower AI ecosystem with a specific focus on denials, which is where the real money is. Their autonomous Appeals Agent reviews denied claims, retrieves medical necessity documentation, drafts patient-specific appeal letters, and submits the full package to payors, all within defined compliance guardrails and without a human touching it. The end-to-end automation of the appeals workflow is significant because appeals management is one of the most labor-intensive parts of hospital billing, and one of the areas with the clearest ROI for automation.

Waystar expanded its partnership with Google Cloud to accelerate its agentic AI capabilities across complex revenue cycle workflows. Since launching its AI platform, Waystar has helped providers prevent more than 15 billion in denied claims, and clients have reported cutting time spent on appeal and documentation workflows by 90%. These are large numbers from a vendor with real scale, and they are being cited in the context of expanded capability deployment, not initial pilots.

Google Goes All In With Health System Partners

Google Cloud had one of the more consequential booth presences at HIMSS26, not because of anything Google itself announced, but because of who they brought with them. The list of organizations publicly committing to Gemini-powered agentic AI deployments included Humana, CVS Health, Highmark Health, Waystar, and Quest Diagnostics. That is a cross-section of payers, providers, diagnostics, and health tech companies that represents a significant portion of US healthcare transaction volume.

The CVS announcement deserves particular attention. The company launched Health100, a standalone health technology services subsidiary with agentic AI built into its foundation. The pitch is a unified healthcare engagement platform for consumers regardless of which pharmacy, care provider, insurer, PBM, or digital health solution they use. That is a very ambitious interoperability play from a company with the distribution to actually execute it, and it signals that CVS is making a serious bet on being a technology company in addition to a healthcare services company.

Quest Diagnostics launched Quest AI Companion, a HIPAA-compliant AI chat feature embedded in the MyQuest app that helps patients understand their lab results in plain language. It sounds simple. It is actually one of the more patient-facing deployments of AI in diagnostics and addresses a real problem: most patients cannot interpret a lab panel without calling their doctor, which creates unnecessary downstream utilization. Helping patients understand their own results at the moment of access is genuinely valuable.

Stryker Enters the Digital Hospital OS Race

Stryker made a move that most people in the health tech investment community probably underestimated, launching the SmartHospital Platform through a newly formed internal business unit called Smart Care. The platform is designed to do something deceptively ambitious: serve as a connective layer between all the hardware, software, and people inside a hospital, essentially positioning itself as an operating system for the physical hospital environment.

The technical components are worth understanding individually. Engage is the middleware engine at the core of the platform, designed to filter and prioritize alarms and notifications so that nurses are not buried in irrelevant alerts. Alarm fatigue is a real and well-documented clinical problem. Nurses in some settings receive hundreds of alerts per patient per day, the overwhelming majority of which are non-actionable. A middleware layer that intelligently triages that noise is clinically meaningful, not just operationally convenient. The Sync Badge is a voice-activated, hands-free communication device that delivers prioritized alarms and clinical information to individual staff members. Virtual nursing and ambient monitoring workflows are also built into the platform.

What makes this announcement strategically interesting is the context. Stryker acquired AI-assisted virtual care company [Care.ai](http://Care.ai) in 2024 and communication platform Vocera in 2022. SmartHospital is the first major public signal that Stryker is integrating those acquisitions into a unified platform play, rather than running them as standalone product lines. A medtech company of Stryker’s scale and hospital distribution moving into digital hospital infrastructure is a different competitive threat than a startup attempting the same thing.

Physical Automation Arrives on the Floor

Robots were on the HIMSS show floor this year in a way that felt less like a novelty and more like a product category. Two announcements stood out for different reasons.

VSee launched what it described as the world’s first fully autonomous telehealth AI robot, purpose-built for hospital deployment. The device uses LiDAR navigation and 30x optical and infrared night vision to navigate hospital corridors independently, reaching patient bedsides without requiring staff escorts for virtual rounding, telestroke response, and specialist coverage in emergency departments and ICUs. It also includes programmable drawers for medication and supply delivery, meaning a single autonomous pass can handle both the clinical encounter and the logistics of delivering what was prescribed in it. The underlying AI Workflow Engine is a no-code/low-code layer that lets hospitals configure and scale clinical AI modules without rebuilding existing IT infrastructure. VSee claims common customizations can be completed in as little as one day.

On the logistics side, Diligent Robotics continues to expand Moxi, the autonomous hospital delivery robot that has now completed over one million picks in healthcare settings. Moxi handles the non-patient-facing tasks that consume an outsized portion of nursing time: running lab samples, fetching medications, moving supplies between units, distributing PPE. The documented outcomes from existing deployments are meaningful. One nursing system reported getting back the equivalent of 595 full nursing days over the deployment period. A hospital pharmacy saved 6,350 staff hours. At one system, nurses were performing routine item movements over 300 times per day before Moxi. The robot handles that without complaint, without overtime, and without calling in sick.

The pattern across both announcements points to something the investment community should take seriously. Physical automation in hospitals is no longer a futuristic aspiration. It is an operational product category with real deployments, real outcomes data, and real unit economics. The question for investors is not whether this market exists. It is which companies have the integration depth, the hospital relationships, and the operational support model to scale it.

Governance Finally Gets Its Moment

One of the most telling signals at HIMSS26 was not any single product announcement. It was the emergence of AI governance as a standalone vendor category. Singulr AI launched Agent Pulse, a platform specifically designed to monitor and control AI agent behavior in real time. The technical framing is runtime governance: the system provides context discovery, risk intelligence, and policy enforcement to ensure that AI agents only execute authorized actions within defined parameters.

This matters because autonomous AI agents operating on PHI inside a hospital create a risk surface that the industry has not had to manage before. An AI agent that can access patient records, draft clinical documentation, submit prior auth requests, and initiate appeals is enormously useful. It is also a compliance and liability exposure if it behaves outside its intended scope. The fact that a dedicated governance vendor showed up at HIMSS with a real product, and generated serious interest, tells you that health system CIOs are thinking hard about this problem.

Wolters Kluwer addressed the hallucination problem from a different angle, integrating its UpToDate Expert AI directly into Microsoft Dragon Copilot and Teams. The logic is sound: if clinicians are going to use AI-assisted documentation and communication tools, embedding curated, evidence-based clinical intelligence directly into those tools creates a guardrail against the model generating confident but incorrect clinical content. UpToDate is one of the most trusted clinical reference databases in the world. Putting it inside Dragon Copilot is a meaningful safety layer, not just a partnership announcement.

What the Pattern Actually Means

Step back from the individual announcements and a coherent architecture starts to emerge. At the infrastructure layer, the MCP server movement, led by athenahealth and picked up by multiple ecosystem vendors, is establishing a standard for how AI agents access EHR data. That is the equivalent of agreeing on an API specification before building the applications on top of it. It is foundational and will determine which AI vendors can play inside health system workflows versus which ones get locked out.

At the application layer, the agentic AI deployments in RCM, clinical documentation, and patient engagement are moving from pilot to production. The outcomes data being cited at HIMSS26 is real and measurable. Prior auth time cut by 42%. Denials reduced by 20%. Fifteen billion in prevented claim losses. These are not aspirational projections. They are retrospective results from live deployments at named health systems.

At the physical layer, autonomous robots are now a product category with commercial traction, documented ROI, and serious institutional capital behind the leading companies. The hospital operations automation story is not a ten-year thesis anymore. It is a three-to-five year scaling story for companies already in the market.

And threading through all of it is the governance question, which is the most underappreciated investment theme coming out of this conference. Every autonomous system that operates on PHI, executes financial transactions, or influences clinical decisions creates regulatory surface area that health systems are not fully equipped to manage on their own. The vendors who can credibly answer “how do we know the agent is doing what it is supposed to do” are going to have very short sales cycles with any health system CIO who just watched a week of agentic AI demos in Las Vegas and is now quietly terrified about what happens when one of them goes wrong.

HIMSS26 was the conference where the hype settled and the infrastructure work became visible. That is usually when the interesting investing starts.​​​​​​​​​​​​​​​​

Section 1: What Epic Actually Announced (And Why It Matters More Than the Headline)

Section 2: The Market Position Problem – Epic’s Gravity Has Become Structural

Section 3: What Gets Killed, What Gets Squeezed, and What Gets Accelerated

Section 4: The Embedded Competitor Problem for Portfolio Companies

Section 5: Where the Real Opportunity Lives Post-Agent Factory

Section 6: Investment Theses That Need Recalibration

Abstract

This essay analyzes Epic’s HIMSS26 announcements – specifically Agent Factory, its no-code agentic AI builder – and the downstream implications for health tech entrepreneurs and investors. Key data points and themes:

- Epic holds 42.3% of the acute care EHR market by hospital count and 54.9% by bed count as of 2024

- Epic revenue grew from $4.9B (2023) to $5.7B (2024), with R&D spend historically running at ~50% of operating expense

- Agent Factory enables drag-and-drop, no-code AI agent orchestration for health systems – clinical, administrative, patient-facing

- The HIMSS26 lineup includes Art (clinical AI), Emmie (patient chatbot), Penny (rev cycle), and Forward (clinical trials management)

- Over 1,000 apps listed on Epic’s Showroom; 2,400+ called a live API in the last year

- The no-code capability compresses the technical moat previously held by AI middleware, workflow automation, and point-solution startups

- Viable investment zones post-Agent Factory: data layers Epic can’t own, cross-EHR interoperability plays, specialty-specific clinical decision support, and infrastructure bets upstream of Epic

- Several digital health categories warrant portfolio review – especially ambient documentation, administrative automation, and rev cycle AI in Epic-heavy customer bases

What Epic Actually Announced (And Why It Matters More Than the Headline)

Before getting into the so-what, it helps to be precise about what Epic showed up to HIMSS26 with, because the framing in most of the coverage undersells it. The headline is “Agent Factory” – a no-code, drag-and-drop environment that lets Epic customers build and orchestrate AI agents that can reason, decide, and execute steps autonomously across clinical and operational workflows. Phil Lindemann, Epic’s VP of data and research, described it plainly: their customers have ideas for where AI can help, and Agent Factory is how they bring those ideas to life without needing to call a vendor or write a line of code.

That one sentence should be circled by every health tech investor who has a portfolio company selling workflow automation to Epic-installed health systems. The historical pitch of many digital health startups has been some version of “we know what your Epic data means and we can do something useful with it.” Agent Factory is Epic’s answer that maybe the health system itself can do that now, on their own, with a visual builder, without writing a check to a startup. That may be an overstatement of what no-code actually delivers in year one – no-code tools have been around in other verticals for years and have not eliminated custom software – but the direction of travel is unmistakable.

Alongside Agent Factory, Epic rolled out a suite of named AI products at HIMSS26 that investors need to track individually. Art is Epic’s clinical AI assistant, with AI Charting already deployed across multiple outpatient specialties in Wisconsin. The pattern here follows Epic’s prior playbook: launch in-state first, prove it, scale it. Emmie is the patient-facing chatbot built into MyChart. Penny is the revenue cycle co-pilot. Forward is a clinical trials management system integrated directly with the rest of Epic’s platform, including its research discovery tools, covering end-to-end study management. First phases are available in 2026, full rollout in 2027.

Put these together and what you have is a company that has essentially announced it is building a full operating stack for health systems – not just the EHR, but clinical AI, patient engagement AI, revenue cycle AI, research management, and now a citizen developer environment for custom AI agents. For a company that reportedly invests up to 50% of operating expenses back into R&D, HIMSS26 represents the point where the outputs of that compounding investment are becoming visible all at once.

The Market Position Problem – Epic’s Gravity Has Become Structural

Read more

What CMS Actually Announced (And Why Everyone Glossed Over It)

The Identity Problem in Healthcare Is Way Bigger Than a Login Screen

CLEAR, ID.me, and Login.gov: Not Just Gatekeepers, But Infrastructure

The Kill the Clipboard Play: What This Signals for the Market

Creative Use Cases Nobody Is Building Yet (But Should Be)

What This Means for Investors and Founders

Abstract

Topic: CMS’s March 2026 announcement adding CLEAR, ID.me, and Login.gov to Medicare.gov is being read as a pedestrian security upgrade. It’s actually a signal that verified digital identity is becoming foundational infrastructure across the healthcare system, with massive downstream implications for startups, health system partnerships, and fraud prevention.

Key data points:

- Healthcare identity fraud costs over $5B annually; synthetic ID fraud up 311% from Q1 2024 to Q1 2025

- DOJ’s June 2025 healthcare fraud takedown charged 324 defendants tied to $14.6B in fraudulent claims

- ID.me: 157M total users, 80M verified to federal IAL2, 70+ healthcare orgs, $275M credit facility from Ares Management in Jan 2025

- CLEAR projected $2M in savings per 25,000 verified patients at Wellstar; digital check-in adoption jumped from 2% to 10%

- CLEAR1 integrates with Epic/MyChart out of the box; deployed at Wellstar, Tampa General, Hackensack Meridian, Ochsner, and others

- ID.me 2024: 409M authenticated logins, up 44% YoY; 20.4M new wallets added

- The real play isn’t better logins. It’s a reusable, portable, IAL2-compliant identity layer that can power prior auth, claims adjudication, prescription access, clinical trial enrollment, and cross-entity data sharing

- The smart money isn’t reading this as a cybersecurity announcement. It’s a platform moment. The winners will be the companies that figure out how to build workflows on top of verified identity as infrastructure rather than treating it as a security checkbox.

What CMS Actually Announced (And Why Everyone Glossed Over It)

On March 3, 2026, CMS dropped a fact sheet announcing that Medicare.gov would now support three external login options for beneficiaries: ID.me, CLEAR, and Login.gov. The announcement reads like a press release written by someone whose primary goal was to put healthcare journalists to sleep. The language is exactly what you’d expect from a federal agency trying to explain something mildly complicated to an audience it assumes has very low technical tolerance. Phrases like “enhanced security,” “protect your Medicare information,” and “strict federal security standards” are doing a lot of heavy lifting. There’s no mention of NIST 800-63-3 IAL2 compliance, no acknowledgment of what a reusable verified credential actually enables downstream, and zero framing of why this matters beyond the obvious “fraud bad, security good” narrative.

So it’s no surprise that most people in health tech saw this, nodded, and moved on. When the average digital health startup founder is heads down on product-market fit and the average health system CIO is still trying to get their EHR to stop crashing on Monday mornings, a Medicare login upgrade is not the thing that lights up the group chats. It competes for attention against AI clinical documentation tools, the latest MA rate notice, and whatever CMS proposed rule dropped that week.

But pay attention, because this announcement is the visible tip of something much more interesting. It’s the formal codification of what has been building quietly over the past two years: a federated, government-backed identity verification layer is being installed across the largest healthcare payer in the country, and it’s being built on the same commercial rails that already exist in the private sector. That’s not a login upgrade. That’s infrastructure.

To understand why that matters, go back to December 2025. CLEAR announced its CMS contract first, framed explicitly under CMS Strategic Advisor Amy Gleason’s Kill the Clipboard initiative, which is one of three named modernization priorities CMS has set for Medicare. That framing is deliberate. Kill the Clipboard is not a metaphor for reducing paperwork. It is a specific, named initiative to make patient intake digital, portable, and interoperable. Gleason’s quote at the CMS-CLEAR co-hosted event in Washington was blunt: checking in at a doctor’s office should feel as simple as boarding a flight. That’s a CLEAR airport lane reference from the CMS strategic advisor. She knows exactly who she’s partnering with and why.

ID.me announced its own CMS contract two weeks later. ID.me had been operating under a broader HHS contract since 2022, but the explicit Medicare.gov expansion is new. Login.gov was already in the mix as the government-run alternative. So as of early 2026, all three major government-grade identity verification providers are officially plugged into Medicare, covering 67 million-plus beneficiaries who will increasingly authenticate through commercial identity wallets they can also use at the VA, SSA, and IRS.

Founders and investors who read this only as CMS worrying about fraud are missing the more interesting read, which is that CMS just created a standardized identity handshake that private-sector health companies can now build on top of. That’s the real story here.

The Identity Problem in Healthcare Is Way Bigger Than a Login Screen

Read more

Health systems are operationally underwater and analytically blind across dozens of high-value domains simultaneously. The gap between what exists commercially and what these organizations actually need is enormous, and the window for building category-defining companies inside this gap is open right now for a specific set of structural reasons. This essay maps the opportunity stack, explains why now is the right moment, and gives builders and investors a prioritized view of where the returns are and why.

Key themes:

- The biggest health system software gaps are in financial operations, not clinical AI

- Data network effects compound faster in health system contexts than in any other enterprise vertical

- The entry point to most of these markets is a CFO conversation about quantifiable revenue loss, not a clinical champion selling upward

- Several of these opportunities have natural exit buyers already circling the category

- Sequencing matters enormously, starting with the cheapest and fastest builds funds the harder ones

Table of Contents

Why health systems are the most compelling enterprise software opportunity in the market right now

The financial operations layer that nobody has built

Workforce intelligence and what $29 billion in agency spend looks like when it’s solvable

The operating room problem and why 65% block utilization is basically embezzlement

Prior authorization as a regulatory forcing function

Clinical variation and what two surgeons doing the same knee replacement tells you about margin

The data monetization play hiding in plain sight

Where to start and why sequencing is the whole game

Why health systems are the most compelling enterprise software opportunity in the market right now

Health systems are, by almost any analytical measure, the most complex operating organizations in the American economy. A single large health system manages tens of thousands of employees across dozens of employee classifications with wildly different compensation structures, benefits, union contracts, and scheduling requirements. It negotiates multi-year contracts with dozens of commercial payers where 60-70% of net patient revenue depends on the outcome. It runs an OR generating 40-60% of its margin in a physical space that represents maybe 3-5% of its square footage. It processes hundreds of millions of dollars in accounts payable annually, manages pension obligations that would terrify a mid-size manufacturer, operates clinical research programs, employs thousands of physicians with their own productivity compensation models, and does all of this while trying to keep people alive.

The software that exists to support most of these operations was not built for health systems. It was built for hospitals in the 1990s and 2000s, adapted for health systems as they consolidated, and patched together in ways that leave stunning amounts of operational intelligence on the floor. The CFO of a billion-dollar health system negotiates payer contracts using anecdote and historical rate data while United sits across the table with actuarial teams, claims data on millions of patients, and benchmarks across every market they operate. The OR director gets utilization reports on what happened last month, not predictions of what is going to happen next week. The nursing director finds out about a staffing gap when a shift starts, not 30 days before when something could have been done about it.

This is not a problem of ambition or intelligence inside health systems. These are sophisticated organizations run by capable people. It is a problem of tools. The commercial software ecosystem that serves health systems has prioritized EHR depth, billing compliance, and clinical documentation over operational intelligence, financial analytics, and the kind of real-time decision support that actually changes outcomes. Epic is extraordinary at what it does. What it does is not run a business.

The timing argument for building in this space right now has a few components that stack on each other. The financial pressure on health systems is at levels not seen since the post-ACA adjustment period, which means CFO conversations about quantifiable cost reduction and revenue recovery are shorter than they have ever been. The AI infrastructure available to builders today makes products feasible that would have required armies of data scientists three years ago – the extraction logic that used to take a team of managed care attorneys can now run through an API call. And the regulatory environment, particularly around prior authorization and data interoperability, is creating forcing functions that compress enterprise sales cycles from 18 months to something actually manageable. When a mandate says you have to do something by January 2027, the procurement process gets motivated.

The counterintuitive insight is that the biggest opportunities are not in clinical AI. Clinical AI is genuinely important and the market for it is enormous, but the competitive intensity is also extraordinary and the sales cycles are brutal because clinical validation requirements are appropriately high. The most compelling near-term opportunities are in financial operations, workforce intelligence, and data infrastructure – categories where the ROI is quantifiable, the buyer is a CFO or COO rather than a clinical committee, and the competitive landscape is weak because everyone with a healthcare AI thesis has been chasing clinical documentation and diagnostic support.

The financial operations layer that nobody has built

Read more

Health systems are operationally underwater and analytically blind across dozens of high-value domains simultaneously. The gap between what exists commercially and what these organizations actually need is enormous, and the window for building category-defining companies inside this gap is open right now for a specific set of structural reasons. This essay maps the opportunity stack, explains why now is the right moment, and gives builders and investors a prioritized view of where the returns are and why.

Key themes:

- The biggest health system software gaps are in financial operations, not clinical AI

- Data network effects compound faster in health system contexts than in any other enterprise vertical

- The entry point to most of these markets is a CFO conversation about quantifiable revenue loss, not a clinical champion selling upward

- Several of these opportunities have natural exit buyers already circling the category

- Sequencing matters enormously, starting with the cheapest and fastest builds funds the harder ones

Table of Contents

Why health systems are the most compelling enterprise software opportunity in the market right now

The financial operations layer that nobody has built

Workforce intelligence and what $29 billion in agency spend looks like when it’s solvable

The operating room problem and why 65% block utilization is basically embezzlement

Prior authorization as a regulatory forcing function

Clinical variation and what two surgeons doing the same knee replacement tells you about margin

The data monetization play hiding in plain sight

Where to start and why sequencing is the whole game

Why health systems are the most compelling enterprise software opportunity in the market right now

Health systems are, by almost any analytical measure, the most complex operating organizations in the American economy. A single large health system manages tens of thousands of employees across dozens of employee classifications with wildly different compensation structures, benefits, union contracts, and scheduling requirements. It negotiates multi-year contracts with dozens of commercial payers where 60-70% of net patient revenue depends on the outcome. It runs an OR generating 40-60% of its margin in a physical space that represents maybe 3-5% of its square footage. It processes hundreds of millions of dollars in accounts payable annually, manages pension obligations that would terrify a mid-size manufacturer, operates clinical research programs, employs thousands of physicians with their own productivity compensation models, and does all of this while trying to keep people alive.

The software that exists to support most of these operations was not built for health systems. It was built for hospitals in the 1990s and 2000s, adapted for health systems as they consolidated, and patched together in ways that leave stunning amounts of operational intelligence on the floor. The CFO of a billion-dollar health system negotiates payer contracts using anecdote and historical rate data while United sits across the table with actuarial teams, claims data on millions of patients, and benchmarks across every market they operate. The OR director gets utilization reports on what happened last month, not predictions of what is going to happen next week. The nursing director finds out about a staffing gap when a shift starts, not 30 days before when something could have been done about it.

This is not a problem of ambition or intelligence inside health systems. These are sophisticated organizations run by capable people. It is a problem of tools. The commercial software ecosystem that serves health systems has prioritized EHR depth, billing compliance, and clinical documentation over operational intelligence, financial analytics, and the kind of real-time decision support that actually changes outcomes. Epic is extraordinary at what it does. What it does is not run a business.

The timing argument for building in this space right now has a few components that stack on each other. The financial pressure on health systems is at levels not seen since the post-ACA adjustment period, which means CFO conversations about quantifiable cost reduction and revenue recovery are shorter than they have ever been. The AI infrastructure available to builders today makes products feasible that would have required armies of data scientists three years ago – the extraction logic that used to take a team of managed care attorneys can now run through an API call. And the regulatory environment, particularly around prior authorization and data interoperability, is creating forcing functions that compress enterprise sales cycles from 18 months to something actually manageable. When a mandate says you have to do something by January 2027, the procurement process gets motivated.

The counterintuitive insight is that the biggest opportunities are not in clinical AI. Clinical AI is genuinely important and the market for it is enormous, but the competitive intensity is also extraordinary and the sales cycles are brutal because clinical validation requirements are appropriately high. The most compelling near-term opportunities are in financial operations, workforce intelligence, and data infrastructure – categories where the ROI is quantifiable, the buyer is a CFO or COO rather than a clinical committee, and the competitive landscape is weak because everyone with a healthcare AI thesis has been chasing clinical documentation and diagnostic support.

The financial operations layer that nobody has built

Start with the most egregious gap, which is payer contract intelligence. Health systems negotiate multi-year agreements with commercial payers that determine the majority of their revenue, and they go into those negotiations almost entirely blind. The information asymmetry is total and structural. United Healthcare has actuarial teams modeling claims across every market they operate in. Aetna knows exactly what every competing health system in a given geography is accepting for DRG 470. The health system managed care team has their current rates and maybe some consultant anecdotes from similar markets.

The benchmarking database that would fix this has never existed because no single health system has data across markets. The opportunity is to build it collectively using anonymized rate data from a network of participating systems. The product itself is not particularly technically complex once you have the data – contract term extraction using modern LLMs, a rate benchmarking layer that answers questions like what does United pay for a knee replacement in Dallas versus Denver, and an underpayment monitoring dashboard that flags where actual remittances are running below contracted rates. That last feature alone is worth the price of admission for most health systems, because underpayment rates of 2-4% of net revenue are essentially universal and most systems lack the tooling to detect them systematically.

The business case closes itself. A billion-dollar health system that is being underpaid at 3% of net revenue is leaving $30 million on the table annually. A platform that finds half of that and charges $1 million per year is a no-brainer conversation. The negotiation intelligence feature is additive – showing a managed care team that peer systems in similar markets are receiving rates 15% higher for a specific DRG is worth far more than a million dollars in the next contract cycle. The strategic acquirers in this category are obvious: Kaufman Hall, Vizient, Premier, any major consulting firm that wants to own the data layer of managed care advisory, or private equity building a healthcare analytics platform. Five to eight times ARR multiple at meaningful ARR is a very credible exit.

AP automation is a different kind of financial operations play but equally underbuilt. A large health system processes $500 million to $2 billion in accounts payable to vendors annually – medical supplies, pharma, staffing agencies, software, facilities contractors – and almost all of it moves by check or ACH. The interchange revenue that could be generated by converting those payments to virtual card, typically 1-2.5% per transaction, goes entirely to banks who have done almost nothing to earn it. A virtual card program that shares the majority of interchange back to the health system as a cash rebate and wraps it in an AP automation layer generates what is essentially found money for a CFO who is looking everywhere for non-clinical revenue.

The reason this has not been done well is vendor enrollment. Getting vendors to accept card payment requires outreach at scale, and most fintechs doing vendor enrollment have no leverage with healthcare suppliers. The leverage comes from representing enough combined purchasing volume that vendors have a genuine incentive to change their payment acceptance infrastructure. Represent a network of health systems paying a specific medical supply company $100 million annually and you have an entirely different conversation than a generic AP fintech that can offer access to maybe $10 million in volume. The business model generates interchange revenue from the first transaction and scales with every additional vendor that converts, which means the economics compound without proportional cost increases.

Treasury management is adjacent and similarly underdeveloped. A large health system has dozens of bank accounts across multiple entities – operating accounts, restricted funds, foundation accounts, bond proceeds, self-insurance reserves, pension assets – managed by a small treasury team using bank portals and spreadsheets. Cash visibility across the enterprise is minimal. Idle cash optimization is essentially nonexistent. The interest income left on the table through poor cash positioning is millions annually at current rates. The product that Kyriba or Broadridge provides for large corporations does not map cleanly to health system needs because the nonprofit status, bond covenants, and restricted fund rules create compliance requirements that general treasury platforms handle poorly. Purpose-built means native handling of those constraints, which means the product actually works rather than requiring a treasury analyst to manage the edge cases manually.

Workforce intelligence and what $29 billion in agency spend looks like when it is solvable

Health systems spent $29 billion on contract and agency nursing labor in 2023. At the pandemic peak it was $49 billion. Even at normalized rates, this is an extraordinary cost that is largely preventable, and the prevention mechanism does not require eliminating agency nurses – it requires predicting demand accurately enough to staff proactively rather than reactively. The gap between those two things is the product.

The core insight that sells this category is the distinction between preventable and structural agency spend. Every CFO knows their agency nursing line item. Almost none of them know how much of it was genuinely unavoidable versus the result of poor demand visibility, inadequate float pool management, or scheduling decisions made on the basis of last month’s patterns rather than a forward-looking forecast. Show a CFO that $20 million in agency spend contains $7 million that was structurally unavoidable and $13 million that a 30-day demand forecast would have allowed them to cover with internal resources, and you have created urgency that no vendor pitch deck could manufacture.

The technical build for this is not exotic. Historical census data by unit, scheduling system exports, and agency invoice files are the inputs. Time series demand prediction at the unit-shift level is a solved problem technically. The complexity is in the institutional data aggregation – getting clean, consistent data out of health system scheduling systems requires integration work that is not glamorous but is very real. The output is a 30-90 day staffing demand forecast by unit and shift, a float pool optimization recommendation layer that matches predicted gaps with available internal resources before the gap becomes a crisis, and a CFO dashboard that shows preventable versus structural agency spend with enough granularity to act on it.

The commercial model can include performance pricing – a share of documented agency spend reduction above a baseline – which turns the product into an essentially self-justifying investment. A health system spending $20 million on agency labor that the platform reduces by 20% has saved $4 million. A $750 thousand annual contract against that outcome is an easy conversation, and the performance fee on top of that aligns incentives in a way that makes renewal automatic rather than a negotiation.

Physician workforce intelligence is a related but distinct problem. Health systems spent the last decade acquiring physician practices at extraordinary valuations and then destroying value during integration. The failure mode is consistent: compensation model misalignment, productivity drops, physician attrition, cultural friction, and a general absence of systematic integration infrastructure. Every acquisition is essentially a bespoke consulting project that ends when the consultants leave, taking the institutional knowledge with them and leaving behind unhappy physicians and data that does not flow coherently between the acquired practice and the health system.

The platform that manages the full lifecycle of an employed physician enterprise – compensation benchmarking, productivity analytics, satisfaction monitoring, credential management, cultural integration workflows – does not exist as a coherent product. The pieces exist in various EHR modules and point solutions but the integrated system of record for the physician enterprise is a gap. And the data network effect is real: compensation benchmarking requires peer data, which means the product gets better for every participant as the network grows. Workday and Oracle are the logical acquirers, alongside PE platforms building physician management infrastructure.

The operating room problem and why 65% block utilization is basically embezzlement

The OR is where health system finances live. Forty to sixty percent of margin, three to five percent of physical space. And it is run with tools that were designed for documentation and scheduling, not optimization. Block utilization nationally averages 65-70%. First case on-time start rates average below 60%. Implant costs vary by 40% between surgeons doing identical procedures with equivalent outcomes. The average health system leaves $10-30 million in OR margin on the table annually through inefficiency that is predictable and therefore preventable.

The intelligence layer that would actually drive OR performance is a prediction problem. If you can accurately forecast which blocks are going to be underutilized before the day, which cases are likely to run long, and which implant choices are adding cost without improving outcomes, you can intervene proactively rather than generating reports about what went wrong. The difference between an analytics product and an operations product is that timing – analytics tells you what happened, operations changes what is going to happen.

OR data is also the most structured and accessible clinical data in any health system. Case times, block schedules, surgeon preference cards, and supply utilization are all clean exports from OR management systems. An MVP does not require EHR integration. Historical case data from multiple systems trains prediction models in weeks, not months. The business case is immediate: a 400-bed hospital that improves block utilization from 67% to 75% adds roughly $8-12 million in OR margin annually on cases that were already scheduled. The product pays for itself in weeks at almost any reasonable pricing.

The strategic acquirers in perioperative intelligence are interesting – Vizient, GE Healthcare, Intuitive Surgical expanding beyond robotics, Epic rounding out perioperative workflow. What makes this category particularly attractive is that the data moat compounds quickly. Training prediction models across multiple OR environments simultaneously generates accuracy that a cold-start competitor would need years to replicate, because surgical preference patterns and case time variance are highly specific to the combination of surgeon, procedure type, facility, and patient population in ways that synthetic data cannot approximate.

Prior authorization as a regulatory forcing function

CMS has mandated prior authorization API compliance from payers by January 2027. This is one of those rare regulatory moments where the forcing function is real enough to compress enterprise sales cycles dramatically. You do not need to convince a health system leader that prior authorization is a problem – the AMA estimates it costs health systems $13 billion annually in administrative burden, physicians spend 16 hours per week per physician on PA, and denial rates have increased 56% over the last decade. The problem is universally understood. The question is whether the deadline is real enough to change procurement behavior, and it is.

The product architecture for prior auth automation has two sides. The provider-facing product automates submission, predicts denial probability before submission, generates supporting clinical documentation automatically, and manages appeals with minimal human involvement. The denial probability scoring feature deserves particular emphasis because it changes the workflow in a way that nothing else does – if a physician can see before submission that a specific request has a 73% predicted denial probability and here is the additional clinical documentation that would reduce that to 18%, you have intervened at the point where intervention actually matters rather than managing appeals after the fact. That feature requires training data good enough to build a reliable prediction model, which is why health system partnerships are the moat.

The payer-facing product is where the business gets dramatically larger, but it requires the provider-side credibility first. Payers pay for AI-driven clinical review that applies evidence-based criteria consistently rather than relying on offshore reviewers following rigid scripts. The strategic acquirers are Availity, Optum, Epic, and major payers that want to own the PA infrastructure rather than buy access to it. Cohere Health raised $50 million and sold for $400 million. Build this with better training data, built-in distribution through founding health system relationships, and a regulatory tailwind they did not have.

Clinical variation and what two surgeons doing the same knee replacement tells you about margin

Clinical variation intelligence is one of the most politically sensitive and financially significant opportunities in the health system stack. Two orthopedic surgeons doing the same knee replacement might use implants that cost $3,000 versus $8,000 with identical outcomes. One hospitalist discharges pneumonia patients in 3 days on average, another in 5 days, with the same readmission rates. These variations are known anecdotally inside health systems and almost never addressed systematically because the data is not organized in a way that enables productive conversations with physicians.

The product design insight here is that punitive dashboards do not work. Physicians are not hourly workers who respond to performance management pressure in predictable ways – they are highly trained professionals with significant institutional leverage who will disengage from, work around, or actively resist tools that feel like surveillance. What works is peer comparison with outcome context in a format designed for physician-to-physician conversation. The department chair who can show a colleague that the top quartile of orthopedic surgeons in the group achieves equivalent outcomes at 22% lower supply cost, and here is specifically what is different about their preference cards, is having a productive clinical conversation. The administrator who publishes a cost ranking is creating a grievance.

Building this correctly requires understanding physician psychology as well as data architecture, which means the design partners have to be physician leaders rather than IT or revenue cycle leadership. The data network effect compounds with every health system that participates because compensation benchmarking and outcome comparison require peer data at scale to be statistically meaningful. Vizient and Premier are the natural acquirers, alongside healthcare analytics platforms that want outcome-contextualized variation data as a differentiator.

Referral leakage is adjacent and equally under-addressed. Health systems lose 20-30% of their referral revenue to out-of-network providers – patients referred to specialists who are not in the employed or affiliated network. For a billion-dollar health system, that is $50-100 million in lost downstream revenue annually. Every health system has this problem. Almost none of them have software to solve it.

The data to solve it already exists in the EHR and in claims data – referral orders, specialist scheduling, downstream claims. The gap is that nobody has organized it into an actionable layer. The MVP is a leakage attribution dashboard and a PCP-level risk score that answers two questions: where is referral revenue going and which primary care physicians are the highest leakage drivers. The intervention that actually changes behavior – surfacing the right in-network specialist at the moment of referral, with wait times, outcomes data, and patient satisfaction scores, so that the in-network choice is the easiest choice rather than requiring directory navigation – is the second version. You need the attribution intelligence first to create urgency for the intervention.

The data monetization play hiding in plain sight

Real-world clinical data – structured EHR data, imaging, pathology, genomics – is the most valuable commodity in life sciences and the least efficiently monetized asset most health systems own. Pharma companies spend billions on synthetic data, claims proxies, and limited real-world datasets because the actual clinical data is fragmented across thousands of institutions with no consistent access model. AI foundation model developers need high-quality clinical data at scale and are paying for it wherever they can access it.

The business model for clinical data monetization is licensing – structured access to de-identified longitudinal clinical records for pharma research, clinical trial recruitment, pharmacovigilance, and AI model training. The governance complexity is real: patient consent frameworks, de-identification validation, BAA structures, and IRB considerations all require legal infrastructure that takes time to build correctly. But the revenue potential is extraordinary. Data licensing revenue from pharma for a large enough dataset runs into the hundreds of millions annually, and AI model training contracts add to that.

The execution insight is that the data catalog and access portal are the actual product, not the data itself. Pharma companies and AI developers need to understand what is available before they can structure a research contract – patient volume, condition mix, data completeness by field, longitudinal depth, geographic diversity. Building that catalog with enough specificity that a research team at a pharma company can structure a meaningful dataset request, and then handling the de-identification and delivery pipeline in a standardized way that passes data governance scrutiny, is where most of the technical work lives. The first revenue comes from direct research contracts, probably $2-5 million each, before anything resembling a self-service platform exists.

The federated compute model is an interesting alternative structure that avoids some of the regulatory friction around raw data commercialization. Rather than exporting datasets, you build secure enclaves where external entities bring algorithms to the data rather than the reverse. Pharma companies and AI developers run approved analytics inside the compute environment and pay for the results, not the underlying data. This positions the platform as a neutral governance-backed compute utility rather than a data seller, which changes the political dynamics inside health systems significantly and may be the right architecture for the long term even if direct licensing generates faster initial revenue.

Patient financial navigation deserves mention in the context of data-driven operations because the moat is similar – proprietary training data from billing and collections history that produces propensity-to-pay models more accurate than anything built on purchased credit data. A patient who just received a cancer diagnosis has completely different payment behavior than their FICO score would suggest. A patient who has been coming to the same health system for 15 years has a payment history that is far more predictive than generic credit bureau data. The product is a segmentation layer that routes each patient to the appropriate pathway – charity care, payment plan, financing, or collections – automatically rather than running everyone through the same process. The commercial model on percentage of incremental collections makes this an extremely easy internal sale because the alternative is leaving money on the floor.

Where to start and why sequencing is the whole game

The sequencing logic for building in the health system stack is governed by two variables: how quickly does the product generate revenue, and how much does it strengthen the data foundation for the companies that come after it. These are not always the same product.

The fastest path to cash is the cheapest technical builds with the most quantifiable ROI and the shortest sales cycles. Payer contract intelligence and purchased services benchmarking are the canonical examples. The MVP for payer contract intelligence is a contract term extraction engine, a rate benchmarking database, and an underpayment monitoring dashboard. The technical build is 10-12 weeks at $140-180 thousand. The pilot pricing is $500 thousand to $1 million per health system annually. The product at launch says here is the $8-15 million you are currently leaving on the table, and here is the negotiation intelligence that will help you recover it at your next renewal. That conversation is extremely short.

Purchased services benchmarking is even simpler technically. Hospitals spend 30-45% of non-labor costs on purchased services – food service, equipment leases, IT consulting, facilities contractors – with almost no visibility into whether they are paying market rates. The product is a spend audit tool that ingests AP data, categorizes it against a purchased services taxonomy, and benchmarks each category against peer spend. The first deliverable to each participating health system is a report showing the categories where they are paying above median and the estimated savings opportunity. That report is the sales motion. It often closes before a dashboard has been built. Cost to MVP is $80-120 thousand, timeline 6-8 weeks, and it is genuinely the fastest path to studio cash flow and proof of concept for a broader portfolio.

Workforce intelligence and perioperative intelligence are the next wave – slightly more complex data collection requirements but equally quantifiable ROI and accessible data. OR data is already structured and available as clean exports. Historical census and scheduling data requires 24 months of exports from each health system, which is an operational ask but not a technical one. These build to $10 million plus ARR businesses within 12 months if execution is clean.

Virtual card AP automation is the highest-revenue Wave 1 opportunity by a significant margin if vendor enrollment executes. The economics are straightforward: at $500 million in converted AP spend per health system at 1.5% interchange with a 25% revenue share, a network of health systems generates tens of millions in annual revenue from interchange alone before adding a single outside customer. The vendor enrollment operation – convincing suppliers to convert from check or ACH to card acceptance – is the real product, not the technology. The leverage comes from representing enough combined purchasing volume that the conversation with any given vendor is categorically different from what a generic fintech can have.

Prior auth, clinical documentation improvement, referral intelligence, and patient financial navigation come next because they require EHR integration that adds 60-90 days to timelines regardless of technical readiness – health system IT review cycles are what they are. Starting those IT relationship conversations during the first wave while the technical builds run in parallel is how you compress the overall timeline.

Data monetization, cybersecurity, and marketplace businesses come last because they require legal infrastructure, institutional credibility, or operational scale that the earlier companies build. Data monetization specifically needs BAA structures and de-identification validation across multiple health systems that are expensive and time-consuming to build correctly but not technically complex. The institutional credibility that comes from having deployed multiple products inside a health system network makes those legal conversations significantly easier than approaching them cold.

The aggregate math on this sequencing is compelling. The cheapest Wave 1 builds – payer contract intelligence, purchased services, workforce intelligence, perioperative intelligence, and the AP automation business development operation – can be capitalized for under a million dollars and generate $60-100 million in ARR across the portfolio within 18 months if execution is disciplined. The Wave 2 builds add cost but also add ceiling, particularly prior auth and data monetization, which are the businesses most likely to generate eight- and nine-figure exits.

The common thread across all of these is that the entry point is a CFO conversation about quantifiable revenue loss or cost reduction, not a clinical champion selling upward through a committee. Health systems are under enough financial pressure right now that a product demonstrating $10 million in recoverable revenue gets an audience quickly. The data network effects that make these businesses defensible compound faster than in most enterprise verticals because health system data is both scarce and extraordinarily valuable, meaning the benchmarking advantage of a multi-system network is very difficult for a single-system point solution to replicate. Build the network first, then build the products on top of it. The sequencing is the strategy.​​​​​​​​​​​​​​​​

Digital health investment hit roughly $29B globally in 2023 after the correction from the 2021 peak of $57B. Most of the capital that got torched in the downturn chased applications -- the shiny clinical tools, the consumer apps, the point solutions. What survived and what will win the next cycle is infrastructure. This essay makes the case that the durable alpha in digital health sits one layer below the applications most investors are looking at, in the unglamorous but defensible plumbing that every health tech builder will need. Key themes:

 - Data interoperability and the persistence of fragmentation as a forcing function for middleware

 - Identity and patient matching as an underappreciated category with moat characteristics

 - Clinical AI infrastructure vs. AI applications -- why the former is the better bet

 - Provider revenue cycle as infrastructure, not software

 - Compliance and regulatory infrastructure as a structural tailwind

 - Market sizing: the infrastructure TAM that nobody talks about is north of $80B by 2030

 Table of Contents

1. The Application Graveyard and What It Teaches Us

2. Data Infrastructure: The Fragmentation Dividend

3. Identity Is Infrastructure

4. The AI Stack Problem in Healthcare

5. Revenue Cycle as Structural Infrastructure

6. Compliance Infrastructure Is Having Its Moment

7. Where the Money Should Go

The Application Graveyard and What It Teaches Us

There is a reason that the 2020-2021 digital health bubble produced so many companies with impressive press releases and mediocre outcomes. The investment thesis for most of that capital was essentially: healthcare is broken, technology fixes broken things, therefore health tech. That logic is not wrong exactly, but it skips the part where healthcare is not just broken, it is structurally different from every other industry that has been disrupted by software. The regulatory environment is uniquely hostile, the sales cycles are brutal, the procurement committees are designed to move slowly, and the data that any application needs to work is scattered across thousands of siloed systems in formats that were standardized in 1987. You can build a beautiful chronic care management product and spend three years failing to get EHR integration before you run out of runway. The graveyard is full of companies that solved the clinical problem and could not solve the plumbing problem.

What this tells the sophisticated investor is something that should feel obvious in retrospect: the constraint in health tech is almost never the application layer. There are plenty of smart clinician-founders who understand the workflow problem. The constraint is everything underneath. The data access problem. The identity problem. The compliance problem. The billing and remittance problem. The AI model evaluation problem. These are unsexy, technically hard, and -- crucially -- shared across every application that anyone is trying to build. That combination of characteristics is exactly what makes them good businesses. Picks and shovels during a gold rush tend to be better investments than individual miners, and healthcare is in the early innings of a multi-decade software transformation that is going to require a lot of shovels.

The market correction that ran from late 2021 through 2023 was healthy. It rationalized valuations, it killed zombie point solutions that were never going to achieve the unit economics required for standalone success, and it concentrated capital toward companies that had real infrastructure value. What has emerged from that correction is a cleaner view of where durable value lives. The companies that held their valuations through the downturn were disproportionately infrastructure plays. The companies that got torched were disproportionately application-layer point solutions dependent on grant funding, employer pilots, or consumer acquisition economics that never penciled.

The forward thesis, then, is not complicated: the next cohort of successful digital health applications is going to be built on a layer of infrastructure that mostly does not exist yet in mature form. The entrepreneurs building that infrastructure are going to have better unit economics, stronger moats, and cleaner exit paths than the application builders they serve. The investors who figure this out early are going to make a lot of money. The ones who keep chasing the clinical application story are going to keep getting frustrated by the same structural problems that killed the last cycle's darlings.

Data Infrastructure: The Fragmentation Dividend

Read more

On Feb 25, 2026, the Trump administration announced a sweeping set of Medicare/Medicaid fraud enforcement actions including a 6-month nationwide DMEPOS enrollment moratorium, a $259.5M federal Medicaid funding deferral in Minnesota, and the launch of the CRUSH (Comprehensive Regulations to Uncover Suspicious Healthcare) RFI. This essay unpacks the policy mechanics, data, and second-order implications for founders and investors in health tech.

Key facts up front:

- 80k+ DMEPOS suppliers enrolled; 6,000+ are medical supply cos (7.5% of total)

- 17% revocation rate for medical supply cos vs ~6% for other DMEPOS types

- CMS suspended $5.7B in suspected fraudulent Medicare payments in 2025

- $1.5B in suspected fraudulent DMEPOS billing stopped in 2025 alone

- CRUSH RFI comment deadline: March 20, 2026 (file code CMS-6098-NC)

- Minnesota deferral: $259.5M with possible $1B+ exposure over next year

- 7 specific medical supply company types covered by moratorium

- Moratorium applies nationwide, all states, territories, DC

- No judicial review of the moratorium decision itself

Table of Contents

What actually happened and why it matters

The DMEPOS moratorium mechanics

The data CMS used to justify this

The CRUSH RFI and what CMS is fishing for

Minnesota as a canary

What this means for founders

What this means for investors

The AI angle

How to think about the comment period

What actually happened and why it matters

Feb 25, 2026 was a busy day at CMS. VP Vance, RFK Jr., and Dr. Oz held a White House press event to announce what amounts to the most aggressive coordinated Medicare/Medicaid fraud enforcement posture in a decade. Three actions dropped simultaneously: a nationwide moratorium blocking new Medicare enrollment for seven categories of medical supply company DMEPOS suppliers, a $259.5M federal Medicaid funding deferral in Minnesota, and the CRUSH RFI soliciting public input on a potential future rulemaking. These aren’t isolated policy moves. They’re a coordinated signal about where this administration wants to take program integrity enforcement, and the downstream effects on health tech companies, from compliance infrastructure to AI vendors to DME-adjacent platforms, are significant.

The headline framing from CMS Administrator Oz was theatrical but directionally accurate: “CMS is done trying to catch fraudsters with their hands in the cookie jar – instead, we’re padlocking the jar and letting them starve.” Secretary Kennedy framed it as replacing “pay and chase” with “detect and deploy.” Whether or not you buy the political branding, the underlying operational shift is real. CMS suspended $5.7 billion in suspected fraudulent Medicare payments in 2025, stopped $1.5 billion in DMEPOS billing alone, revoked billing privileges from 5,586 providers, and sent 372 fraud referrals covering $3.7 billion in billing to law enforcement. That’s not rhetoric, that’s a functioning enforcement apparatus that got materially more aggressive over the past year.

The moratorium itself is the most immediately impactful piece for health tech operators. DMEPOS fraud has been on CMS and OIG radar for literally decades, with OIG reports flagging it since 1998. What’s new is the bluntness of the tool being used: not additional screening requirements, not payment suspensions post-billing, but a hard stop on enrollment for an entire category of supplier. No new medical supply companies get in for at least 6 months, possibly longer if CMS extends. For the companies and investors playing in the DME supply chain, distribution, or adjacently in software supporting these suppliers, this is a material market structure event.

The DMEPOS moratorium mechanics

Read more

This essay examines the tension between standardized AI agent infrastructure and the custom workflow engineering required to actually make AI agents useful in clinical and administrative healthcare settings. The core argument is that roughly 60-70% of a healthcare AI agent tech stack can be standardized (LLM APIs, vector databases, orchestration layers, auth/compliance scaffolding), but the remaining 30-40% demands something closer to Palantir’s forward deployed engineering (FDE) model, where engineers and domain experts are embedded on-site to understand, map, and programmatically encode workflows that are often undocumented, inconsistent, and deeply human. Key topics covered include the anatomy of a healthcare AI agent stack, what makes healthcare workflows uniquely resistant to generic automation, the economics and tradeoffs of the FDE model, and what this means for startups, health systems, and investors deploying or funding agent-based solutions.

Key data points referenced include:

- 2024 Rock Health report noting 70% of health AI pilots fail to scale beyond proof of concept

- McKinsey estimate that healthcare administrative costs exceed $350B annually in the US

- Palantir’s FDE model origins at DoD/CIA deployments and translation to commercial healthcare

- LangChain, LlamaIndex, CrewAI as examples of standardized orchestration layers

- FHIR R4 adoption rates and interoperability gap data from ONC

- Time-to-value benchmarks from enterprise AI deployments across health systems

Table of Contents

The agent hype problem

What actually lives in a healthcare AI agent stack

The standardizable 60-70%: what you can commoditize

The custom 30-40%: where health systems actually differ

The Palantir FDE model and why it translates

Economics of the FDE approach for startups and health systems

What this means for investors

Where this is all going

The agent hype problem

Everyone in health tech right now is either deploying AI agents, claiming to deploy them, or on a panel about why they’re going to deploy them soon. The vendor landscape has gotten comically overcrowded. There are “AI agents for prior auth,” “AI agents for clinical documentation,” “AI agents for revenue cycle,” and several dozen companies all pitching the same slide showing a robot completing tasks a human used to do. Most of it is noise. Some of it is genuinely interesting. The challenge for operators and investors is figuring out which is which, and the best way to do that is to get very precise about what these systems actually require to work.

The thing that distinguishes healthcare from most other verticals deploying agent tech is that the workflows are a mess, the data is a mess, the regulatory environment is punishing, and the end users are either clinicians who will not tolerate friction or administrative staff who have been burned by technology promises before. You can’t just drop a general-purpose agent into a hospital billing department and expect it to work. The agent needs to understand that this particular health system uses a 15-year-old Epic instance with a custom charge description master, that their coders follow a hybrid ICD-10/internal taxonomy, and that there’s one person in the Medicaid team who manually overrides the system every Tuesday because of a payer contract quirk nobody has fully documented.

This is the core tension in healthcare AI agent deployment: the infrastructure layer is becoming commoditized fast, but the workflow layer remains stubbornly bespoke. Getting that balance right is the difference between a pilot that works and a product that scales.

What actually lives in a healthcare AI agent stack

Before getting into what can and can’t be standardized, it helps to be explicit about what a full-stack healthcare AI agent actually consists of. Most people collapse this into “the model plus some integrations” which is too simple and leads to bad architectural decisions.

A reasonably complete healthcare AI agent stack has about six layers. At the foundation you have the LLM or model layer, which is the reasoning engine. Above that sits the memory and retrieval layer, which handles how the agent accesses relevant context, whether from a vector database, structured SQL, or document stores. The orchestration layer sits on top of that and manages multi-step task execution, tool use, and agent-to-agent coordination. Then there’s the integration layer, which handles connections to EHRs, payer portals, lab systems, and other health IT endpoints. Above that is the workflow and rules layer, which encodes the actual decision logic and process flows specific to the use case and organization. And at the top is the interface and trust layer, which includes the user-facing surface, audit logging, explainability outputs, and human-in-the-loop mechanisms that regulators and risk-averse health system CTOs care deeply about.

The interesting question is not “what are these layers” but “which of them can you buy off the shelf versus what do you have to build yourself.” The answer varies significantly by layer, and understanding where the customization burden falls is essential for anyone making a build/buy/partner decision.

The standardizable 60-70%: what you can commoditize

Let’s start with the good news, which is that a substantial portion of a healthcare AI agent stack is now genuinely commoditized or close to it. Foundational model access is a solved problem. Whether it’s GPT-4o, Claude Sonnet, Gemini 1.5 Pro, or one of the open-weight alternatives like Llama 3.1 or Mistral, the raw reasoning capability you need to power most administrative and certain clinical agent tasks is accessible via API with pricing that has dropped precipitously in the last 18 months. Token costs for input have fallen something like 90% since GPT-4 launched in 2023. That’s not a rounding error, that’s a structural shift in the economics of building on top of foundation models.

The orchestration layer is also largely commoditized at this point. LangChain, LlamaIndex, LangGraph, CrewAI, AutoGen from Microsoft, and a handful of others provide solid frameworks for building multi-step, tool-using agents. None of them are perfect. LangChain in particular has a reputation for over-engineering simple use cases. But the core capability, managing an agent loop that can call tools, route between sub-agents, maintain state across steps, and handle errors, is well-covered by open-source or low-cost commercial tooling. You don’t need to build an orchestration layer from scratch in 2024 unless you have a very specific reason.

Vector databases and retrieval infrastructure are similarly commoditized. Pinecone, Weaviate, Qdrant, pgvector inside Postgres, Chroma for lightweight applications. The market has standardized reasonably well here and the cost per query is trivial at most healthcare administrative use case scales. Healthcare does add complexity in terms of data volumes (large imaging datasets being the obvious exception) but for text-heavy workflows like clinical documentation, prior auth, and coding, standard retrieval infrastructure works fine.

Authentication, RBAC, and audit logging infrastructure is increasingly well-served by vendors who have built specifically for regulated industries. The SOC 2, HIPAA BAA, and increasingly FedRAMP compliance layers are not easy to build but they are well-understood, and there are platforms that abstract most of this away. Similarly, basic integration tooling for health data, FHIR APIs, HL7 v2 parsing, CCD/CCDA document handling, has matured substantially. The ONC’s interoperability rules under the 21st Century Cures Act pushed health systems and EHR vendors to build FHIR R4 APIs, and while adoption is uneven (somewhere around 60-70% of large health systems have functional FHIR endpoints as of late 2024 per ONC tracking data), you have real programmatic access to clinical data at a scale that wasn’t possible three years ago.

So the standardizable portion of the stack covers the model layer, orchestration, vector infrastructure, compliance scaffolding, and a decent chunk of the integration layer. Call it 60-70% of the technical surface area. This is the commodity layer, and it is getting commoditized faster than most vendors in the space want to admit. If your pitch deck says “we built a proprietary LLM” or “our secret sauce is our vector database,” those claims are increasingly unpersuasive to sophisticated investors who understand what’s available off the shelf.

The custom 30-40%: where health systems actually differ

Here’s where things get complicated and interesting. The remaining 30-40% of the stack, concentrated primarily in the workflow and rules layer and in the integration specifics, is where healthcare organizations are fundamentally different from each other in ways that matter enormously for agent performance.

Start with EHR variability. Epic, Oracle Health (formerly Cerner), Meditech, and a few others are the dominant EHR vendors, but “running Epic” doesn’t mean two health systems have anything close to the same data model. Epic is famously configurable, which is both its commercial strength and a deployment nightmare for anyone building on top of it. Two large academic medical centers running Epic Cogito can have CDMs (clinical data models) so divergent that a model trained or configured on one system will fail in meaningful ways on the other. Custom build types, non-standard flowsheet rows, local formularies, home-grown order sets, legacy data migration artifacts, none of this is standardized. This is not a solvable problem through better APIs alone. It requires human investigation.

Beyond EHR variability, the actual clinical and administrative workflows at any given health system are a product of years of organizational history, regulatory responses, payer contract specifics, and individual human workarounds that never got cleaned up. The McKinsey number on US healthcare administrative costs, roughly $350B annually, isn’t just a market opportunity number, it’s also a signal of how many people are currently doing work that could theoretically be automated, but only if you understand exactly what they’re doing and why. A prior authorization workflow at a large integrated delivery network might involve eight different handoff points, two different payer portals that use incompatible authentication methods, an internal approval queue that runs on a SharePoint list from 2017, and a set of clinical criteria that the CMO updated last quarter but that nobody has fully communicated to the coding team. An agent built on generic prior auth logic will get about 60% of the way there. The last 40% requires encoding the specific logic that applies at that organization.

Clinical variation adds another layer. Even within standardized workflows like sepsis protocols or medication reconciliation, there is legitimate clinical judgment variation that agents must handle correctly or defer appropriately. The difference between a safe AI agent in a clinical workflow and an unsafe one is not primarily model capability, it’s whether the workflow layer correctly encodes when to act versus when to escalate, and that boundary is different at different organizations, different care settings, and different patient populations. Getting this wrong has real consequences. The FDA’s evolving framework for AI/ML-based software as a medical device (SaMD) and the recent executive order guidance on clinical AI make clear that regulatory scrutiny on exactly this question is increasing.

There’s also the integration-specific custom layer that goes beyond what FHIR standardizes. Lab information systems, pharmacy systems, scheduling systems, billing and RCM platforms, payer portals, state Medicaid management information systems (MMIS), prior auth portals that use screen scraping because they have no APIs, document management systems running on file shares. The full technology landscape inside a typical health system involves dozens of these point solutions, many of which have no standard API, some of which are actively hostile to programmatic access, and all of which need to talk to each other through an AI agent that is supposed to complete a coherent multi-step task. This cannot be solved generically. Someone has to map it, and that someone needs to be on-site.

The Palantir FDE model and why it translates

Palantir Technologies built its business on a model that was, at the time, considered strange and possibly unscalable: instead of selling software and letting customers implement it, they embedded engineers inside client organizations for months or years to understand the data environment, map the workflows, and build the integrations and logic layers that made the platform actually useful. They called these people Forward Deployed Engineers, and the approach originated at places like the CIA and DoD where the stakes were high enough that failing to understand the operational context would mean the software just didn’t work.

The FDE model got a lot of criticism from traditional SaaS investors because it looks expensive and it doesn’t scale the way a pure software business does. Revenue per employee metrics suffer. The argument in favor of it was always that in sufficiently complex environments with sufficiently high stakes, you cannot separate the software from the domain knowledge required to configure it correctly, and trying to do so via documentation, onboarding calls, and customer success handholding is how you end up with shelfware.

This translates to healthcare AI agent deployment with remarkable fidelity. The complexity argument applies directly. Health systems are not going to figure out how to correctly configure an AI agent for complex clinical workflows from a 200-page implementation guide and a Slack channel with a CSM. The stakes argument also applies, because errors in clinical or even administrative workflows have real consequences, regulatory, financial, and patient safety. And the data environment argument applies most directly of all, because the workflow and data complexity described in the previous section is precisely the kind of thing that only becomes visible when someone is in the room.

What forward deployed engineering looks like in a healthcare AI agent deployment is roughly this: a team of two to four engineers and at least one clinical or operational domain expert is embedded at the health system for anywhere from six weeks to six months. Their job in the first phase is not to build anything. It’s to observe and document. They sit with coders, with billing staff, with care coordinators, with prior auth specialists. They pull actual workflow data from the EHR and the ticketing systems and the shared drives. They find the SharePoint lists and the Excel macros and the email threads that are doing load-bearing work in processes that the org chart says are automated. They map the decision trees that experienced staff use implicitly without ever having written them down.

In the second phase, they translate that knowledge into the workflow and rules layer of the agent stack. This is where the custom 30-40% gets built. Integration adapters for non-standard endpoints. Decision logic trees that encode the real approval criteria, not the theoretical ones. Escalation rules that match how the organization actually wants to handle exceptions. Validation checks that catch the kinds of errors specific to that health system’s data quality issues. This is slow, skilled work. It is also the work that determines whether the agent actually performs or whether it sits at 60% accuracy and never gets used in production.

Companies doing this well in 2024 include some of the better-known clinical AI platforms that have been around long enough to have built real deployment infrastructure, and a newer cohort of agent-focused startups that have explicitly adopted the FDE model. The ones that haven’t are often the ones with the better press coverage and the worse enterprise deployment track records.

Economics of the FDE approach for startups and health systems

The honest conversation about the FDE model is that it’s expensive and the economics are genuinely hard to make work at early stages. A forward deployed engineer team for a six-month health system engagement might cost $600K to $900K in fully-loaded costs before you’ve closed a software contract. For a Series A startup, that’s a painful burn rate on a single customer. This is why so many companies try to skip it, and why so many pilots fail to convert to enterprise deployments.

The way the math works for the FDE model to be viable is through a combination of higher ACV (annual contract values), reusability of deployment artifacts, and time compression as the team builds institutional knowledge about the health system type. On ACV, healthcare AI agent deployments that include real workflow customization and integration work should command $500K to $2M+ annually from large health systems, not the $50K to $150K SaaS pricing that gets thrown around for lighter-weight tools. The organizations that have the most complex problems and the most to gain from agent automation also have the budget and the willingness to pay for a high-quality deployment. The pitch shifts from “here’s our software” to “here’s what our team will accomplish for your organization in the first 12 months,” which is a services-plus-software model that most pure SaaS investors still misunderstand.

On reusability, this is where the FDE model starts to get more economically interesting over time. Every EHR configuration, every payer portal integration, every workflow mapping effort produces artifacts that are partially reusable at the next similar customer. An FDE team that has deployed inside five health systems running Epic in the northeast US has built up a library of Epic configuration patterns, common workflow variations, integration adapters, and tested decision logic that meaningfully reduces the time required to deploy at the sixth similar health system. The marginal cost of deployment decreases over time even as the quality of deployment stays high or improves. This is how Palantir’s unit economics eventually improved despite the high upfront cost model.

For health systems as buyers, the FDE model is actually better aligned with how they want to procure technology even if they don’t always articulate it that way. CIOs and CMIOs at large health systems are deeply skeptical of point solution vendors who promise self-serve deployment. They’ve been burned too many times. The offer of an embedded expert team that will spend real time understanding their specific environment before building anything is a more credible pitch than a demo showing a generic prior auth workflow that looks nothing like how they actually process prior auths. The total cost of a well-executed FDE-model deployment is often lower than a failed self-serve deployment followed by a year of remediation work and eventual contract termination.

The investor tension around this model is worth naming directly. SaaS multiples are driven by revenue growth and gross margin. Services revenue gets punished in public market valuations and often in venture valuation conversations too. Companies that have built real FDE capability often try to hide it behind “professional services” line items or undercharge for it in order to keep their software revenue metrics clean. This is strategically wrong and often leads to the FDE capability being underfunded relative to what it needs to be. The better frame for investors is that FDE is a moat-building activity, not a services business. The workflow knowledge and deployment artifacts built through FDE engagements are proprietary data assets that competitors cannot easily replicate, and they compound over time in ways that pure software does not.

What this means for investors

For anyone allocating capital to healthcare AI agent companies, the standardization/customization framework has some direct implications for due diligence and portfolio construction.

First, be suspicious of companies whose entire technical differentiation story lives in the commodity layer. If the pitch is “we have the best LLM fine-tuned for healthcare” or “our vector database is optimized for clinical notes,” those are real technical achievements but they are not durable moats. The foundation model providers and infrastructure vendors will eat most of that differentiation within 12-24 months. The durable moat in healthcare AI agents lives in the workflow layer, in the proprietary knowledge of how specific care settings and organizations actually operate, in the integration adapters and decision logic that have been built and tested and refined over hundreds of real deployments.

Second, look for evidence of real deployment at real health systems at real scale. This sounds obvious but in an environment where demo-stage companies are raising at Series B valuations based on pilot announcements and press releases, it requires active effort. Ask for production deployment metrics, not pilot metrics. Ask how many patients or encounters the agent has processed in a non-sandboxed environment. Ask what the false positive or escalation rate is. Ask how many full-time people from the vendor are embedded at each customer. Ask what the P1 incident rate is. These questions separate companies with working deployments from companies with impressive demos.

Third, the FDE model is a positive signal, not a negative one, even if it makes the unit economics look worse in a model. A company that has built real FDE capability and is using it to generate proprietary workflow knowledge at enterprise customers is building something that is genuinely hard to replicate. The cost structure is real, but so is the moat. A company that has grown to $20M ARR through FDE-model deployments at 15 health systems has a data and knowledge asset that a competitor with a cleaner SaaS model and $30M ARR through 200 small customers probably does not.

Fourth, think carefully about the category structure of healthcare AI agent companies. There are horizontal players trying to build general-purpose agent infrastructure for healthcare, and there are vertical players building for specific workflows like prior auth, clinical documentation, coding, or care coordination. The standardization/customization tradeoff argues somewhat in favor of vertical focus, at least at early stages, because deep workflow knowledge in a specific domain is more achievable and more defensible than trying to map workflows across every healthcare use case simultaneously. The horizontal players that win will probably be the ones that built very deep vertical expertise first and then expanded, not the ones that started with generic infrastructure and tried to add vertical depth later.

Fifth, the companies most at risk in this landscape are the mid-tier: too expensive to deploy rapidly at SMB health systems, not deep enough in workflow expertise to win enterprise deployments against vendors who have been doing FDE-style work for years. The dumbbell structure of the market (lightweight self-serve tools for small practices and deeply embedded solutions for large health systems) is going to squeeze the middle.

Where this is all going

The trajectory here is not that FDE goes away as agents get smarter. The trajectory is that the cognitive burden of the FDE engagement shifts. Two years ago, the forward deployed engineer was spending most of their time on raw integration work, writing Python scripts to parse HL7 feeds and building one-off adapters for payer portals. That work is getting easier faster than almost anything else in the stack, as the ecosystem of health IT integrations, FHIR compliance, and managed API platforms matures. A non-trivial portion of the integration layer will be handled by commodity tooling within 24 months.

What won’t get commoditized is the workflow observation and encoding work. You cannot send a model to watch someone work and capture the implicit decision logic that experienced healthcare workers carry in their heads. That knowledge elicitation work is fundamentally a human process, requiring trust, domain vocabulary, patience, and the ability to ask the right follow-up questions when a nurse says “oh we just know when to flag it.” The value of the FDE team is shifting from integration engineering toward something closer to workflow anthropology plus rapid prototyping, and the profiles of the best people to do this work are also shifting accordingly.

The interesting longer-term question is whether the workflow knowledge accumulated through FDE deployments can itself become training data for models that eventually reduce the customization burden. There are early signs of this: companies that have done enough deployments to have a large corpus of labeled healthcare workflow examples are starting to fine-tune models on that data in ways that reduce the time required to onboard a new similar organization. This is a legitimate form of compounding moat, workflow knowledge encoded in deployment artifacts, used to train better models, which reduce deployment cost, which allows more deployments, which generates more workflow knowledge. It’s a flywheel, and the companies that are already executing on it are probably further along in building durable competitive advantages than their current revenue figures suggest.

The final point worth making is about timing. The window where a company can acquire deep workflow knowledge in a specific healthcare AI agent category without facing well-resourced competition is probably two to three years, not five to ten. The big EHR vendors, the large RCM companies, and a few well-capitalized health AI incumbents are all moving toward agent-based products. They have existing health system relationships and embedded sales motion advantages that new entrants don’t. The moat that a focused, FDE-model startup can build before those players are fully in the market is real but it has a time limit. The companies that will still be relevant in ten years are the ones deploying real agents into real workflows right now, not the ones waiting for the infrastructure to mature further or for the regulatory environment to clarify. That clarity is coming, but it rewards those who have already done the deployment work, not those who are watching from the sidelines.​​​​​​​​​​​​​​​​