Flagship / Authority brief

The Healthcare AI Control Plane: Designing the Whole System

A 500-foot operating architecture for the future of healthcare across people, payers, providers, pharmacy, claims, data, agents, human authority, and the learning loop that turns activity into accountable value.

Return to insights

Healthcare founders, CEOs, CFOs, payer and provider executives, pharmacy leaders, product teams, and operating partners / Reviewed 2026-09-01

By Healthcare AI operator

Decision use

Define the health system before choosing the technology.

Public factsOperator interpretationBuyer implicationsFounder actions

This is an independent operator synthesis of current public regulation, interoperability policy, and peer-reviewed research. It describes a category-level architecture and does not imply that any cited institution endorses Azis Dabas or that every future state is already deployed.

Executive thesis

The Healthcare AI Control Plane: Designing the Whole System

A 500-foot operating architecture for the future of healthcare across people, payers, providers, pharmacy, claims, data, agents, human authority, and the learning loop that turns activity into accountable value.

Public facts

  1. CMS-0057-F makes payer-provider interoperability operational: impacted payers face process requirements generally beginning in 2026 and API requirements generally beginning in 2027 for patient, provider, payer-to-payer, and prior-authorization exchange.

  2. ASTP/ONC reported in February 2026 that nearly 500 million health records had been exchanged through TEFCA, evidence that nationwide exchange is becoming a practical substrate rather than a policy abstraction.

  3. A 2026 Nature Health framework argues that longitudinal health agents require coherence, continuity, adaptation, and agency across repeated interactions, not isolated prompt-response encounters.

  4. A 2026 npj Digital Medicine framework says meaningful oversight depends on epistemic capacity, cognitive space, decisional authority, and intervention effectiveness. A human's presence alone is not an operating control.

  5. A 2026 scoping review of agentic AI in healthcare found only seven eligible studies; most were exploratory, few had real-world deployment, and only one involved patients. The capability narrative remains ahead of clinical validation.

  6. FDA guidance increasingly treats AI as a total-product-lifecycle concern, including planned modifications, monitoring, real-world performance, and controls that continue after deployment.

Operator read

  1. The future health system will not be run by one model. It will be coordinated by a control plane that carries context, policy, identity, action rights, human authority, and evidence across many specialized systems.

  2. The unit of design is moving from an encounter or task to a longitudinal trajectory. That changes the product requirement from producing a good answer to maintaining continuity, ownership, follow-through, and safe adaptation over time.

  3. Healthcare's core architecture is economic as well as clinical. Coverage, benefit design, provider capacity, pharmacy access, claims, and patient burden determine whether an apparently intelligent workflow can actually operate.

  4. Agentic capability should be classified by consequence, reversibility, and action scope. Retrieving context, drafting a message, changing a queue, initiating an authorization, and influencing care are not the same autonomy tier.

  5. The durable moat is not access to a foundation model. It is trusted context, workflow position, integration depth, operating rights, distribution, and an evidence loop that becomes more useful with responsible use.

  6. Value must be reconciled across the system. Labor removed from one organization can become rework, access friction, patient burden, or financial risk somewhere else.

Architecture artifact / whole-system crosswalk

Where the system lives. How control operates. How a decision travels.

The control plane is the connective architecture across the health system, not another destination or autonomous model.

Persistent threadPersonEpisodeContext travels across every domain, control plane, and decision chapter.
WHERE

Ten health-system domains

The boundary of the system being designed.

  1. 01
    Person and caregiver

    The durable subject of the system.

  2. 02
    Care delivery

    Encounters, plans, escalation, and follow-through.

  3. 03
    Provider network

    Capacity, referral corridors, and operating fit.

  4. 04
    Payer and coverage

    Benefits, authorization, eligibility, and risk.

  5. 05
    Pharmacy and therapeutics

    Access, adherence, fulfillment, and outcomes.

  6. 06
    Diagnostics and labs

    Signals that change the clinical or operating path.

  7. 07
    Claims and revenue cycle

    Transactions, denials, payment, and burden.

  8. 08
    Data and interoperability

    Portable context with provenance and freshness.

  9. 09
    Agents and workflow

    Specialized intelligence placed in the work.

  10. 10
    Authority and learning

    Human ownership, economics, and adaptation.

HOW

Five control planes

The governing capabilities that make the system coherent.

  1. 01
    Context

    Assemble the person, episode, evidence, history, and current state.

  2. 02
    Policy

    Translate rules, benefits, clinical boundaries, and incentives into constraints.

  3. 03
    Action

    Choose the smallest useful next step, with explicit permissions and rollback.

  4. 04
    Authority

    Give the right person the time, information, and power to decide or interrupt.

  5. 05
    Evaluation

    Measure outcomes, exceptions, burden, equity, value, and drift.

HOW A DECISION TRAVELS

Six decision chapters

The sequence that turns a need into accountable evidence.

  1. 01
    Need

    A signal, friction, risk, or unmet goal makes the next decision necessary.

  2. 02
    Context

    The control plane carries a coherent person-and-episode state into the work.

  3. 03
    Policy

    Rules and incentives narrow what is permitted, advisable, or out of bounds.

  4. 04
    Action

    An agent drafts, recommends, routes, or initiates a bounded move.

  5. 05
    Authority

    A named human or accountable service accepts, changes, stops, or reverses it.

  6. 06
    Evaluation

    The result becomes evidence for value, safety, burden, and the next need.

Closed feedback loopOutcome evidenceNext decisionNeed / signal

Every evaluated outcome re-enters the system as the context for the next decision.

WHERE names the system boundary.HOW names the control capabilities.TRAVEL names the decision sequence.THREAD keeps person and episode continuity intact.

Operating response

Translate the signal into a governed decision.

The architecture is a forward-looking operator framework grounded in cited public sources. It separates published facts from interpretation and makes no claim that Azis personally built the public systems discussed.

Buyer implications

  1. Health-system leaders need an enterprise architecture that distinguishes the data plane, decision plane, action plane, authority plane, and evidence plane before scaling AI use cases.

  2. Payers and providers should design electronic authorization and data exchange as shared workflows with exception ownership, not simply compliant endpoints.

  3. Pharmacy, medical benefit, diagnostics, and care delivery should be modeled as one therapy-access-and-outcomes loop when the patient experience crosses those boundaries.

  4. Founders should define the longitudinal outcome and operating owner before choosing an agent framework or model stack.

  5. CFOs and investors should evaluate transferred burden, implementation cost, exception growth, and evidence durability alongside gross automation or productivity claims.

Founder actions

  1. 01

    Map the whole system around one patient, member, provider, or transaction journey, including every handoff, incentive, data boundary, and exception owner.

  2. 02

    Define one longitudinal unit of value and state how it affects access, quality, operating burden, total cost, and trust.

  3. 03

    Separate context, decision, action, authority, and evidence into explicit architecture layers with named owners and interfaces.

  4. 04

    Create an autonomy matrix that sets permissions, required evidence, human review, escalation, rollback, and stop rules by risk tier.

  5. 05

    Instrument provenance, freshness, overrides, exceptions, subgroup performance, drift, workflow impact, and finance-validated value from the first pilot.

  6. 06

    Design for interoperability and portable evidence so the operating model can survive a new payer, provider, pharmacy partner, EHR, or model vendor.

Metrics that matter

  1. Time from qualified signal to closed-loop action

  2. Continuity and completion across care, coverage, and therapy handoffs

  3. Percentage of consequential outputs with traceable source, freshness, and reviewer action

  4. Exception, override, escalation, reversal, and unresolved-queue behavior

  5. Access, quality, equity, patient burden, and operating impact by population

  6. Finance-validated net value after implementation, human review, rework, and transferred cost

  7. Real-world performance, calibration, drift, and incident response over time

Red flags

  1. The AI strategy starts with a model or vendor rather than a system problem and accountable owner.

  2. Medical, pharmacy, claims, and care workflows are optimized independently even though the patient journey crosses all four.

  3. Human-in-the-loop means a person is present, but that person lacks time, context, authority, or a reversible control.

  4. An agent can invoke tools or change workflow state without explicit action rights, provenance, and escalation rules.

  5. The pilot reports accuracy or automation while ignoring continuity, exceptions, downstream burden, and real-world outcomes.

  6. Scaling volume increases hidden manual work faster than the operating system can resolve it.

Executive questions

  1. 01

    What is the full system boundary, and which important actor or incentive is currently outside it?

  2. 02

    Whose goal is the system optimizing, and what happens when patient, payer, provider, pharmacy, and financial goals conflict?

  3. 03

    What longitudinal context must travel with the person, decision, and workflow for the system to remain coherent?

  4. 04

    What can the AI observe, recommend, initiate, change, and complete without approval?

  5. 05

    Who has the time, information, authority, and practical control to interrupt or reverse a consequential action?

  6. 06

    Which outcome proves the system created value rather than moving cost or work to another part of healthcare?

  7. 07

    What does the architecture learn after deployment, and who is accountable for changing it?

Primary and attributed sources

The cited agencies, publishers, and authors inform the analysis and do not endorse this framework or its recommendations.

Related operating work

Use this mandate to define the system boundary, longitudinal value unit, operating owner, action rights, evidence loop, and first implementation wedge.

Architect the operating mandate

Start a serious conversation

Turn the evidence into an operating decision.

Discuss an operating mandate