🎧 Part I Podcast free on Apple Podcasts and Spotify.
🎧 Part II Podcast episode also for free subscribers.
To listen to paid episodes in Apple or Spotify, link your Substack subscription via the show settings on those platforms (instructions inside the Substack app under Subscriptions → Podcast).
Table of Contents
What the employer pledge actually changes
The existing market is already busy
Make the employer’s plan executable
Measure the delays that disappear from the dashboard
Build the evidence for retiring authorization
Keep treatment intact when benefits change
Make an approval mean something at payment
The business model has to survive the pilot
Abstract
The expansion of electronic prior authorization into self-funded employer plans creates opportunities for venture-backed companies that help employers control how their benefits actually operate. The strongest candidates connect plan documents to executable administrative rules, measure delays from the original clinical order through treatment, identify authorization requirements worth removing, preserve treatment continuity through benefit changes, and reconcile approvals with payment. Existing vendors already automate substantial parts of this process, so a credible startup needs a narrower claim than faster authorization through artificial intelligence. The investment case rests on obtaining usable data and contractual authority, producing measurable value for a specific buyer, and distributing through administrators or benefits advisers without becoming a custom integration shop. The employer pledge creates a reason to buy these capabilities. It does not supply the operating model.
What the employer pledge actually changes
The interesting part of the October twenty-first announcement is who is asking for change. Amazon, Axon Enterprise, Google, Meta, and Oracle signed a statement supporting the extension of prior authorization reforms to self-funded health plans. The Centers for Medicare and Medicaid Services and the Department of Labor are encouraging that expansion. These employers finance benefits while relying on administrators and other vendors to run much of the machinery. That arrangement creates a straightforward business question: can the organization paying for healthcare verify that its vendors are administering the coverage it actually purchased?
Read the employer statement carefully and the commercial opening becomes clearer. It distinguishes technical improvements that could become available through administrators’ platforms from changes to authorization requirements that employers could consider adopting individually. The statement asks third-party administrators to make technical improvements immediately available to self-funded plan sponsors; employers did not themselves commit to reducing prior authorization and said such changes would be considered against their fiduciary duties. That leaves work to do at the plan level. Somebody has to identify which rules apply, decide which changes make sense, configure them, and verify that they work after deployment. The twenty twenty-four interoperability rule requires electronic prior authorization capabilities from specified Medicare Advantage, Medicaid, Children’s Health Insurance Program, and federal exchange payers, with most application programming interface requirements beginning in twenty twenty-seven. It does not impose those requirements across all self-funded employer plans. Employer purchasing decisions and administrative contracts therefore matter enormously.
Even the market sizing deserves a little housekeeping. The announcement associates millions of people with self-funded coverage, but the Census figure it links to describes employer coverage generally. KFF’s twenty twenty-five employer survey reports that sixty-seven percent of covered workers were enrolled in self-funded plans. Those figures describe different populations and cannot be swapped into the same market model. A startup needs reachable covered lives, participating administrators, and an actual purchasing mechanism. Multiplying everyone with employer coverage by a hypothetical software fee is easy. Getting permission to receive the authorization event feed is where the business starts.
For founders, the useful consequence is a new procurement conversation. An employer can ask its administrator to prove that electronic authorization works for its particular benefits, including delegated services and exceptions. A benefits consultant can make that proof part of an administrator selection process. A startup can provide the measurement and testing machinery. The fax machine is irritating, but it has been taking an impressive amount of blame for contract design.
The existing market is already busy
Authorization automation is an established category. Availity supports standards-based discovery, documentation, and submission workflows. Cohere markets clinical policy management, automated review, selective reductions in provider requirements, and authorization-to-claim matching. Surescripts operates electronic medication authorization workflows, while SamaCare focuses on medical-benefit drug access. A startup claiming to have discovered automated submissions, policy interpretation, or gold carding will have a short meeting with an informed investor. Those capabilities already have vendors, distribution, and customer references.
The opportunities worth examining sit in the specific arrangements those products might support but do not automatically establish. An employer could retain its own independently testable record of agreed authorization rules across administrators. It could purchase measurement of the entire patient journey rather than rely solely on vendor turnaround reports. Multiple employers could evaluate whether removing a particular review requirement actually changes utilization, administrative expense, and access. These are proposed businesses whose novelty needs customer diligence. Public product descriptions cannot establish that nobody is building them, and being less visible than a large incumbent is hardly proof of an empty market.
The customer also needs to be chosen early. A hospital values fewer staff touches and fewer preventable denials. An employer values appropriate access, dependable administration, and reasonable total spending. A manufacturer values treatment initiation and persistence. Those interests overlap, but they produce different product requirements and compensation arrangements. A company paid for increasing drug starts should not quietly present itself as an independent evaluator of employer benefit spending. The party writing the check influences which problems get solved, which metrics look attractive, and which uncomfortable findings survive the quarterly business review.
Make the employer’s plan executable
Consider a hypothetical administrator serving several employers through one recognizable insurance brand. One employer removes authorization for a defined outpatient imaging category. Another keeps it. A third uses a delegated vendor with different documentation requirements. The provider’s electronic system has to reach the correct answer for the individual member, service date, and benefit arrangement. Successfully connecting to the administrator does not establish that the employer’s selected rules are being applied.
A company could sell a plan configuration and verification service that turns agreed benefit terms into a versioned, testable specification. Its input would include the governing plan documents, administrative agreement, adopted medical policies, and documented exceptions. Its output would identify the applicable rule, the entity authorized to decide, the evidence required, and the effective period. Every rule would remain traceable to its approved source. Conflicts would go to the responsible human reviewer. A language model could extract candidate provisions and flag inconsistent language, but it should not resolve a contractual ambiguity by producing a particularly confident sentence.
The existing technical standards provide useful places to connect. Coverage Requirements Discovery addresses what information and authorization may be required. Documentation Templates and Rules supports collecting the needed clinical information. Prior Authorization Support handles submission and responses. A new company’s contribution could be verifying that an employer’s approved configuration survives that entire workflow. For example, a test could check whether an imaging exemption appears during ordering, whether the documentation workflow unnecessarily opens anyway, and whether a downstream system still expects an authorization identifier when the claim arrives.
That testing should cover far more than whether a message conforms to a technical schema. It should examine benefit effective dates, rendering providers, service locations, delegated reviewers, and the treatment of amended requests. Authorized test environments could run synthetic cases before a benefit change takes effect. Production monitoring could compare actual transactions against the approved configuration without inventing patient encounters. Changes would have an owner and a recorded approval. When an administrator updates a shared policy, the product would identify employer configurations affected by the update and rerun the relevant tests.
The buyer could be an employer coalition or benefits adviser that wants the specification to survive an administrator replacement. An independent administrator could also buy it to onboard groups more reliably. The difficult dependencies are access to configuration details, rights to use clinical criteria, and an agreement that someone will fix identified discrepancies. Proprietary medical policies do not become freely reusable because software can read them. Without these arrangements, the product risks becoming an excellent report on mistakes nobody has agreed to correct. With them, annual renewals and benefit changes create recurring work that a reusable software system could handle.
Measure the delays that disappear from the dashboard
The industry’s voluntary pledge includes a target of answering at least eighty percent of electronic authorization approvals in real time by twenty twenty-seven, with the necessary clinical documentation supplied. The denominator deserves attention. An approval metric does not describe every attempted request, and a completed submission clock does not measure everything that happened before the payer accepted the case. This creates room for independent measurement that follows care from the original order through a resolved administrative outcome.
Take an illustrative thousand orders expected to require authorization. Suppose six hundred produce complete submissions, five hundred are eventually approved, and four hundred of those approvals arrive immediately. The real-time approval rate is eighty percent. Immediate approvals account for forty percent of the original orders. Neither calculation has to be wrong. They answer different questions. The remaining orders might involve missing information, routing problems, clinical cancellations, or patients choosing not to proceed. A useful product would investigate those categories instead of treating every missing claim as proof that authorization caused abandonment.
Technically, this requires a persistent case history across systems that create different identifiers for the same episode. The company would connect the clinical order to submission attempts, requests for additional information, revised submissions, decisions, scheduled services, and eventual claims where available. It would preserve unresolved cases in the denominator and distinguish an amended request from a genuinely new treatment decision. The provider’s clock and the administrator’s clock would both remain visible. Missing upstream data would be reported as a coverage limitation, not silently converted into a better turnaround statistic.
The employer could then negotiate service commitments against observable events. An administrator might respond quickly after receiving complete documentation while a delegated vendor takes days to identify what documentation is required. A provider may repeatedly submit an obsolete form. The system should identify both. Commercial value comes from locating a correctable failure, routing it to the party responsible, and verifying the repair. A prettier monthly chart adds little if the next employee encounters exactly the same problem.
Privacy has to be part of the product architecture. HIPAA restricts how identifiable health information may pass to an employer acting as a plan sponsor and requires separation from employment functions. Appropriate plan administration access does not give ordinary managers a view into employees’ treatment. The platform should support controlled access for authorized administrators and carefully designed aggregate reporting for purchasing decisions. Small groups need particular care because apparently anonymous categories can identify a person surprisingly quickly. The appeal of measuring access does not justify turning the benefits department into a clinical surveillance operation.
Build the evidence for retiring authorization
An employer that can observe the workflow can ask a more valuable question: which authorization requirements should disappear? Existing vendors already support selective exemptions and provider programs. The more specific entrepreneurial opportunity is an employer-controlled evaluation service that helps purchasers decide what to remove, negotiates implementation with administrators, and measures the consequences using a consistent method across participating plans.
A high approval rate is a useful screening signal, but it does not establish that the requirement has no effect. Clinicians may have changed their ordering behavior because review exists. Staff may have learned which cases never get through and stopped submitting them. Requests with complete documentation may represent an unusually selected population. Removing the requirement could leave utilization unchanged, increase appropriate access, or increase low-value services. Historical approvals alone cannot distinguish those possibilities.
The product would need clinical governance and credible comparison groups. Participating plans might use a staggered rollout of an approved exemption across comparable provider groups, with adjustment for changes in membership, clinical mix, and benefit design. Where feasible and appropriate, randomized rollout could strengthen the evidence. The evaluation would track service volume and substitution into other services, along with administrative effort and relevant clinical outcomes. It would also identify changes in coding or referral behavior that could make a nominal savings result misleading. Rare harms would require longer follow-up or larger pooled samples than a short pilot can provide.
The economics need equally careful boundaries. Suppose a participating plan spends fifty dollars in avoidable administrative expense per review across ten thousand reviews annually. That is five hundred thousand dollars under those assumptions. If removing the requirement creates four hundred fifty thousand dollars in additional paid claims, only fifty thousand dollars remains before the evaluation vendor’s fee and other effects. Additional care could still be worthwhile. It simply cannot be sold as a large medical savings result. Provider labor savings belong in a separate account unless the buyer can capture them through a commercial arrangement.
A venture-backed company could charge for policy evaluation and ongoing monitoring, with expansion through employer coalitions and administrator partnerships. Payment per submission would create an awkward incentive for a product meant to reduce submissions. Subscription revenue is easier to reconcile with successful removal. Defensibility would come from well-characterized policy changes, trustworthy comparisons, and permission to reuse suitable aggregate findings. The important dataset would record what happened after a rule changed, including cases where removal disappointed. A database containing only favorable case studies is a marketing department with storage costs.
Keep treatment intact when benefits change
Specialty care creates another potential business because a treatment episode can outlast the administrative arrangement that originally approved it. An employer replaces its administrator or pharmacy benefit manager. An employee changes plans. A therapy’s delivery route or site changes. Clinical history remains relevant, but the operational workflow may start over. That is an expensive place to keep rediscovering facts already established.
The regulatory work is moving toward broader drug coverage, but founders need to distinguish proposals from obligations. The twenty twenty-four rule excluded drugs from its authorization requirements. The April twenty twenty-six proposal would extend requirements to drugs, with medical-benefit workflows using the relevant interoperability interfaces and pharmacy-benefit workflows using prescription drug standards for specified payers. As of October twenty-second, that proposal remains a proposal and should not be treated as a finalized universal deadline. A company serving employers still needs workable connections and contractual participation from the medical administrator, pharmacy benefit manager, and other relevant parties.
A focused startup could build a portable treatment record for use during an administrator transition. For an ongoing biologic treatment, that record might include the diagnosis, previously tried therapies, documented reasons for discontinuation, relevant clinical evidence, and the existing authorization’s conditions. Each fact would carry its source and date. Historical treatment failures would be distinguishable from information requiring refresh. The system would identify what the receiving administrator accepts, which requirements remain unmet, and whether the next scheduled treatment falls inside an unresolved coverage period.
There is already a continuity commitment in the industry pledge, but its boundaries matter. It describes a minimum ninety-day transition for the same service under the same benefit type, in network, after treatment has begun. That language does not promise universal portability across a medical-to-pharmacy benefit change, a different network, or every self-funded arrangement. The receiving party has to recognize the applicable obligation or explicitly accept the transition arrangement. Moving an authorization document is technically useful. Getting a receiving administrator to acknowledge what it will honor is the commercial work.
The hardest cases involve benefit coordination rather than missing paperwork. A specialty therapy might require alignment between the drug authorization, administration services, the treatment site, and the supplying pharmacy. Drug identifiers and medical billing units need clinically correct interpretation; a simple code crosswalk cannot establish equivalence across all products and dosing arrangements. An approval for the product may leave the infusion service unresolved. The proposed software should maintain those separate dependencies and detect conflicts before the appointment, without choosing a treatment or changing the clinician’s order.
A sensible starting customer could be a benefits adviser managing large administrator transitions, supported by a defined specialty provider network. That creates a bounded implementation event and a measurable outcome: fewer treatment interruptions attributable to administrative transition, with acknowledged responsibility for resolving exceptions. A manufacturer might also value the service, but manufacturer sponsorship would need transparent limits if the company simultaneously claims independence for employer purchasing decisions. The company would have to show why its transition workflow complements existing specialty access platforms and earns incremental payment. General enthusiasm about continuity is not a purchase order.
Make an approval mean something at payment
An authorization can be approved while the eventual claim still fails. Payer materials explicitly warn that authorization does not guarantee benefits or payment. Eligibility, the actual service delivered, contractual terms, and other conditions still matter. That limitation gives founders a tempting opening, but basic authorization-to-claim matching already exists. A differentiated business would need to take the next step into agreed responsibility for preventable administrative discrepancies.
Imagine a provider obtains an approval covering a particular service and site, performs the service within the approved period, and submits a conforming claim. The claim then encounters an authorization-related denial because the adjudication system did not receive the approval or associated it with the wrong identifier. A product could preserve the original authorization response, connect it to the relevant claim lines, identify the discrepancy, and present the administrator with the evidence needed to resolve it. It would distinguish that situation from a claim that exceeds the approved units or describes a different service.
Useful reconciliation requires more than a denial label. It needs the submitted claim, adjudication results, adjustments, and the authorization history, together with the applicable contractual rules. A remittance reason can indicate where to investigate without establishing the full cause. The software also has to track corrected claims and reversals so it does not declare victory on a payment subsequently recouped. Shared identifiers help, but systems will still need careful matching when a treatment episode produces multiple claims or a claim contains several authorized services.
The ambitious commercial extension would be a narrow contractual assurance. An administrator could agree to a defined remedy when its own processing contradicts a qualifying approval, subject to explicit conditions and exclusions. The startup would supply the verification machinery and manage the dispute workflow. That is meaningfully different from promising that every approved service will be paid. If the startup begins absorbing uncertain losses itself, it needs separate analysis of capital requirements and whether the arrangement constitutes regulated risk transfer. An insurer partner might become relevant later. A seed-stage company should not discover its underwriting business through a surprisingly expensive customer support ticket.
The employer’s incentive here also needs explanation. Paying valid claims reliably does not automatically reduce near-term medical spending. The value may be fewer disputes, lower administrative expense, better provider relationships, and less employee exposure to avoidable billing problems. Providers may therefore be the more natural initial buyer, while administrators participate because they can reduce reconciliation costs. The product’s commercial structure should reflect who actually receives the benefit.
The business model has to survive the pilot
The strongest initial thesis is probably the combination of employer plan verification and independent workflow measurement. They address a purchaser’s need to know whether selected reforms were implemented and whether access improved. Authorization retirement could become an expansion product once the company has adequate event history and evaluation expertise. Specialty continuity offers a different starting point for a team with pharmacy and infusion distribution. Payment assurances belong later, after the company understands the error patterns and has negotiated responsibility for them. These opportunities do not need to be stuffed into one seed-stage roadmap.
The revenue arithmetic should be explicit. At an assumed one dollar per covered member per month, two hundred thousand covered lives produce two million four hundred thousand dollars in annual revenue. Five million lives produce sixty million dollars. Those are illustrations, not established market prices or proof of willingness to pay. They show why distribution matters. A company pursuing large outcomes needs repeatable access through administrators, coalitions, or advisers, and it must account for channel fees and customer concentration. Hundreds of bespoke employer implementations would make that arithmetic much less appealing.
Gross margin should include the people who resolve mapping problems, review policy conflicts, maintain connections, and support customers. Calling those people implementation resources does not make their cost temporary. The company needs evidence that each additional employer requires less incremental work because the underlying administrators and rule structures are already supported. A useful technical advantage would be reusable tests and reliable data normalization. A useful commercial advantage would be a contract that keeps the service in place when the employer changes its administrator.
Early diligence should establish that the buyer can obtain the required data and secure cooperation from the parties expected to act on findings. A pilot needs a defined scope, agreed baseline, and a payable success condition. For configuration testing, that might mean detecting and correcting discrepancies before a benefit change goes live. For continuity, it might mean receiving documented acceptance of active treatment arrangements before the transition date. For workflow measurement, it might mean reducing a specific source of delay while reporting unresolved cases honestly. Counting connected interfaces would prove very little about any of these outcomes.
Investors should be prepared to walk away when the administrator will not provide usable events, the employer lacks practical authority to change the process, or the proposed savings depend entirely on unverified assumptions. A buyer who enjoys the findings but has no budget or contractual remedy is another warning. The first valuable commercial proof would be an employer paying for an independently verified correction, an administrator accepting responsibility for maintaining it, and the same software reproducing that result for another group. That would be a much stronger foundation than a faster authorization demo.
