Everything that touches a patient or a clinical decision — acquisition, qualification, intake, routing, and post-conversion engagement. PHI lives here and is governed by the HIPAA audit policy.
Agentforce Inbound Lead Generation
Inbound acquisition (site & chat) · Patient acquisition
The inbound complement to outbound prospecting. Captures interest from the marketing site, Agentforce web chat, and symptom-check forms; qualifies each visitor against the menopause-care ICP and scores readiness; creates an opt-in-consented lead in Data 360 with source attribution, resolved against existing patients/prospects so nothing duplicates. Routes a ready lead straight to intake and a not-yet-ready lead into the Prospecting & Nurture cadence — both over A2A.
Agentforce Prospecting & Nurture Agent
Outbound acquisition + lead nurture (top of funnel) · Patient acquisition
Turns Data 360 population segments (e.g., the 40-60 vasomotor-burden cohort) into consented prospect audiences, then scores and warms leads across a multi-touch nurture cadence — drafting each outreach and nurture touch via Marketing Cloud for human review, never auto-sent. Suppresses anyone lacking contact consent, drops a prospect from every sequence the instant they convert or opt out, and hands a sufficiently-warmed prospect to the intake agent over A2A.
Agentforce Qualification
Lead qualification (the gate before intake) · Lead qualification
The authoritative qualifier both acquisition paths hand off to. Applies one consistent rubric (menopause-care fit + eligibility + expressed intent/readiness) to inbound and outbound leads alike, and returns a qualified/disqualified decision with human-readable rationale on every lead. Routes qualified-and-ready leads to intake and qualified-but-warming ones back into nurture. Protected-class attributes are excluded from the criteria, and every disqualification is logged for human review.
Agentforce Service Agent
Patient-facing intake (front door) · Patient-facing
Captures the structured intake record, performs red-flag screening, and produces an Open-mHealth-shaped artifact. Speaks Google A2A outbound.
Agentforce Assessment Agent
Validated-instrument scoring (patient-facing) · Patient-facing
The Salesforce 'Agentforce for Health — Assessments' analog. Administers and DETERMINISTICALLY scores an allow-listed set of validated instruments — the Menopause Rating Scale, Greene Climacteric Scale, PHQ-9, and Insomnia Severity Index — with real cutoff-based math, no LLM: per-instrument subscores, a total, and a severity band normalized onto intake's mild/moderate/severe vocabulary. It screens red-flag items (e.g. PHQ-9 item 9 self-harm ideation) and escalates them explicitly, and it refuses any instrument outside the validated allow-list. The scored severity feeds IntakeRecord.severity, so the Care Router's decision is backed by a validated instrument rather than a self-report.
Agentforce Benefits & Coverage Verification (EBV)
Eligibility & benefit verification (patient access) · Benefits verification
The Salesforce 'Agentforce for Health — Eligibility & Benefit Verification' analog. Verifies a patient's insurance coverage for a menopause specialist (MSCP) visit and returns a structured eligibility result — plan status (active/inactive), in/out-of-network, deductible + amount met, coinsurance/copay, and an estimated visit cost + patient out-of-pocket — with the (mock) payer/clearinghouse EBV source the result traces to. In the prototype the EBV round-trip is a DETERMINISTIC synthetic (deductible $1,500–$6,000, coinsurance 10–30%, visit $180–$420), clearly labeled synthetic — not a real 270/271 EDI transaction or FHIR CoverageEligibilityResponse. Governance requires every returned result to trace to a payer/clearinghouse response, so the agent can't fabricate coverage without a source; the eligibility summary threads into the intake → Care Router spine so a coverage check can precede routing.
Agentforce Patient Financial Assistance & Charity Care
501(r) charity-care screening: FPL-tiered eligibility + no-collections-before-screening + human-review-gated denial (patient access) · Benefits verification
The Salesforce 'Agentforce for Health' / Health Cloud patient-financial-experience analog, and a DETERMINISTIC (no-Claude) agent, a sibling to the Benefits & Coverage Verification (EBV) agent on the patient-access tier. Given a household size + annual income (plus the FPL guideline year, an optional presumptive-eligibility signal, whether the FAP application is complete, and whether an extraordinary collection action is being requested), it computes the household's income as a percentage of the Federal Poverty Level (from the household size's FPL base), cites the governing FAP tier from an illustrative FAP_SCHEDULE (≤200% FPL → full charity 100% discount, 201–300% → 75%, 301–400% → 50%, >400% → not eligible), and classifies the patient as full-charity / partial-charity / not-eligible under an IRS 501(r) Financial Assistance Policy; a recorded presumptive-eligibility reason (Medicaid-eligible, homelessness, SNAP-enrolled, deceased-no-estate) grants full charity regardless of documented income. It COMPLEMENTS, not duplicates, the EBV agent (which verifies plan eligibility + estimates the covered visit cost): this screens the patient-responsibility remainder for CHARITY CARE, and is distinct from the SDOH Screening agent (health-related social needs). The determination is a pure function of the household size + income + FPL year + the request's own flags (no randomness, no clock), so the same household always yields the same tier + discount + eligibility. THREE load-bearing honesty properties are governance-enforced: an extraordinary collection action (ECA — collections, credit reporting, a lien) may NEVER proceed before financial-assistance screening is complete — an ECA asserted before screening is blocked (policy.finassist.no-eca-before-screening), because IRS 501(r)(6) requires reasonable efforts to determine FAP eligibility before any ECA, mirroring the Data Retention Agent's legal-hold-overrides-purge and the Overpayment & Recovery Agent's within-lookback-window posture (a legal precondition bounds the action); every determination must cite a recorded FAP tier or presumptive reason — an ad-hoc / un-sourced eligibility decision is blocked (policy.finassist.fap-schedule-sourced), mirroring the Data Retention Agent's schedule-sourced and the Overpayment & Recovery Agent's reason-catalog-sourced posture; and a denial of charity care is NEVER autonomous — a not-eligible determination is a RECOMMENDATION requiring human review with written notice + appeal rights under 501(r)(4) (requiresHumanReview:true), and an autonomous denial is blocked (policy.finassist.no-autonomous-denial), mirroring the Overpayment & Recovery Agent's no-autonomous-clawback, the Utilization Review Agent's no-autonomous-denial, and the Claims Adjudication Agent's no-autonomous-denial posture — granting full/partial charity is a benefit but denying it is legally consequential. It also honors the HIPAA-audit policy. Menopause-relevant: a 45-64 self-pay or high-deductible patient facing the patient-responsibility remainder of an MSCP visit is exactly the cohort a hospital FAP screen serves. Runs against an ILLUSTRATIVE synthetic FAP tier schedule + discount percentages + FPL table + presumptive-eligibility reasons — clearly labeled; NOT a certified financial-assistance system (real hospital FAPs are governed by IRS 501(r) / 26 CFR 1.501(r), the HHS Federal Poverty Guidelines, and each hospital's Board-approved FAP + state charity-care law).
Agentforce Good Faith Estimate (No Surprises Act)
Itemized self-pay estimate before care: charge-master-sourced + complete + an estimate never a binding bill (patient access) · Benefits verification
The Salesforce 'Agentforce for Health' / Health Cloud price-transparency analog, and a DETERMINISTIC (no-Claude) agent, the THIRD leg of the patient-access triad with the Benefits & Coverage Verification (EBV) and Patient Financial Assistance & Charity Care agents. Given a scheduled primary service + the expected line items (each a charge-master service id + quantity), it prices each line item from an illustrative CHARGE_MASTER (established visit $220, comprehensive menopause consult $400, hormone panel $180, DEXA $250, pelvic ultrasound $450, HRT admin $90), verifies the estimate includes the primary service AND every reasonably-expected co-item (a comprehensive consult expects a hormone panel; a DEXA / pelvic ultrasound expects an ordering office visit), sums the total expected charge, and returns a Good Faith Estimate that is an ESTIMATE (binding:false) requiring patient confirmation, with the No Surprises Act $400 dispute threshold recorded. It COMPLEMENTS, not duplicates, its patient-access siblings: the EBV agent verifies what the PLAN covers (eligibility + estimated COVERED cost) and the Financial Assistance agent screens the patient-responsibility remainder for CHARITY CARE — this assembles the itemized SELF-PAY / uninsured estimate required BEFORE care. The estimate is a pure function of the request's line items + the charge master (no randomness, no clock), so the same request always yields the same total + completeness + sourcing flags. THREE load-bearing honesty properties are governance-enforced: every priced line item must be charge-master-sourced — an off-catalog service id or an amount that doesn't match the charge master is blocked (policy.gfe.charge-master-sourced), mirroring the Overpayment & Recovery Agent's reason-catalog-sourced and the Lab Result Agent's reference-range-sourced posture; the estimate must be COMPLETE — an estimate missing the primary or a reasonably-expected co-item is blocked (policy.gfe.expected-items-complete), because the No Surprises Act (45 CFR 149.610) requires the convening provider to include items/services reasonably expected to be furnished and an incomplete estimate understates the total and misleads the patient (the load-bearing gate, mirroring the Care Coordination Handoff Agent's SBAR-completeness and the Lab Result Agent's critical-value-notified); and a GFE is an ESTIMATE, NEVER a binding / final bill — a determination presented as a binding bill is blocked (policy.gfe.estimate-not-binding), mirroring the Lab Result Agent's no-autonomous-clinical-action and the Financial Assistance Agent's no-autonomous-denial posture (the agent recommends, a human confirms). It also honors the HIPAA-audit policy. Menopause-relevant: a 45-64 self-pay or uninsured patient scheduling a comprehensive menopause consult + hormone panel is exactly the cohort a GFE serves. Runs against an ILLUSTRATIVE synthetic charge master + categories + amounts + expected-co-item rules — clearly labeled; NOT a certified hospital chargemaster, machine-readable price-transparency file, or a real provider's charges (a real GFE is governed by the No Surprises Act / 45 CFR 149.610, the provider's actual charges, and HHS guidance).
Agentforce Advance Beneficiary Notice (Medicare ABN)
Pre-service Medicare liability: coverage-rule-sourced + ABN-required-when-non-covered + no autonomous patient bill (patient access) · Benefits verification
The Salesforce 'Agentforce for Health' / Health Cloud Medicare price-transparency analog, and a DETERMINISTIC (no-Claude) agent, a patient-access sibling to the Good Faith Estimate, Benefits & Coverage Verification (EBV), and Financial Assistance agents. Given a proposed service (the cited Medicare coverage rule, whether the service meets its coverage criteria or exceeds a frequency limit, and whether an ABN was issued and signed BEFORE the service), it DETERMINISTICALLY assesses coverage against an illustrative MEDICARE_COVERAGE_RULES catalog (a reasonable-necessary vitamin-D lab, a frequency-limited DEXA bone-density scan, a statutorily-excluded cosmetic procedure) as likely-covered / likely-non-covered / statutorily-excluded, decides whether a signed pre-service ABN (Form CMS-R-131) is required, computes whether a valid pre-service ABN is on file (issued AND signed before the service), decides whether the beneficiary may be billed, assigns the CMS liability modifier (none / GA waiver-on-file / GZ expected-denial-no-ABN / GY statutorily-excluded), and decides the disposition (proceed-covered / issue-abn-before-service / bill-beneficiary-with-abn / notify-statutory-exclusion). It COMPLEMENTS, not duplicates, its patient-access siblings: the Good Faith Estimate agent assembles the No Surprises Act SELF-PAY estimate and the Balance Billing agent enforces the No Surprises Act CLAIM-time surprise-bill prohibition — this decides the narrow Medicare question of whether a signed pre-service ABN is required before a likely-denied service and whether the beneficiary may be billed. The determination is a pure function of the request's own fields + the cited rule (no randomness, no clock), so the same service always yields the same coverage assessment + ABN requirement + modifier + disposition. THREE load-bearing honesty properties are governance-enforced: every non-coverage decision must cite a recorded Medicare coverage rule — an ad-hoc / un-sourced rule is blocked (policy.abn.coverage-rule-sourced), mirroring the Good Faith Estimate Agent's charge-master-sourced and the Timely Filing Agent's filing-limit-sourced posture; a likely-non-covered service must require a signed pre-service ABN — a determination that marks it as needing no ABN is blocked (policy.abn.abn-required-when-noncovered), because understating this is how a surprise Medicare denial lands on the patient (the load-bearing completeness gate, mirroring the Good Faith Estimate Agent's expected-items-complete); and patient financial liability is NEVER assigned autonomously — the beneficiary may be billed for a non-covered service ONLY with a valid pre-service ABN (the GA modifier), otherwise the PROVIDER is liable (the GZ modifier), and every liability decision requires human review, so a determination that bills the beneficiary without a valid ABN or auto-assigns liability is blocked (policy.abn.no-autonomous-beneficiary-liability), mirroring the Balance Billing Agent's no-autonomous-balance-bill and the Timely Filing Agent's no-autonomous-write-off posture — the harmful action is enforced-off. It also honors the HIPAA-audit policy. Menopause-relevant: a 45-64 Medicare-eligible patient scheduling a DEXA bone-density scan or a vitamin-D screen is exactly the cohort an ABN protects from a surprise denial. Runs against an ILLUSTRATIVE synthetic coverage catalog + categories + modifier logic — clearly labeled; NOT a certified Medicare coverage engine (real ABN decisions are governed by the Medicare National / Local Coverage Determinations, the Social Security Act §1862(a), the CMS Medicare Claims Processing Manual Ch. 30, and Form CMS-R-131).
Pause Care Router (Anthropic Claude Sonnet 4.5)
Clinical-decision agent · Clinical decision
Takes the structured intake over A2A, reasons over symptoms + cycle + safety screen + age band, and returns one of six care pathways with rationale and red-flag flags. Falls back to a deterministic Pause policy engine when ANTHROPIC_API_KEY is unset or the API call fails.
Agentforce Lab Result & Critical-Value Notification
Clinical-decision agent · Clinical decision
A DETERMINISTIC clinical-decision sibling of the Care Router. Classifies a discrete diagnostic lab result (analyte + value) against the analyte's reference range + critical thresholds as normal / abnormal-high / abnormal-low / critical-high / critical-low, flags mandatory clinician notification for a critical (panic) value, and flags clinician review for any abnormal result — a pure function of the value + the catalog range (no randomness, no clock). A CRITICAL value can NEVER be suppressed or auto-closed (governance genuinely blocks a critical result flagged as not requiring notification via policy.lab.critical-value-notified — CLIA §493.1291), every classification must cite a recorded reference range (policy.lab.reference-range-sourced), and the agent NEVER autonomously acts on a result — a non-normal result is escalated for clinician review (policy.lab.no-autonomous-clinical-action). Distinct from Remote Patient Monitoring (RPM streams), Clinical Summary (chart summarization), and Care Gap Closure (preventive measures). The analyte catalog + reference ranges are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified laboratory information system (real ranges are method-/instrument-/population-specific and set by the laboratory's medical director under CLIA / 42 CFR 493).
Agentforce Immunization Forecasting (ACIP)
Clinical-decision agent · Clinical decision
A DETERMINISTIC (no-Claude) clinical-decision agent that forecasts a patient's vaccines against an ACIP-style schedule. Given a patient (a synthetic reference, a birth date, an immunization history, and any recorded contraindications) evaluated against a provided asOfDate, it computes the patient's age and forecasts each vaccine — up-to-date / due / overdue / contraindicated / not-indicated — against the schedule catalog (influenza annual, Td/Tdap booster every 10 years, recombinant zoster/RZV 2-dose series at 50+, pneumococcal at 65+, updated COVID-19), applying age-eligibility, dose-series / booster-interval logic, and any recorded contraindications, citing the governing schedule rule + the next-due date. The forecast is a pure function of the request + its own asOfDate + the schedule catalog (no randomness, no clock), so the same patient always yields the same forecast + cited rules + next-due dates. Every forecast entry must cite a recorded ACIP schedule rule (governance genuinely blocks an ad-hoc / un-sourced recommendation via policy.immunization.schedule-sourced), a vaccine the patient is contraindicated for is NEVER recommended — it is withheld and flagged (policy.immunization.contraindication-honored, the load-bearing safety gate), and a due / overdue vaccine is a RECOMMENDATION requiring a clinician order — the agent never administers, orders, or records a vaccine autonomously (policy.immunization.no-autonomous-administration). Distinct from Care Gap Closure (broad missing preventive measures), Lab Result (discrete diagnostic results), Care Plan (the longitudinal plan), and the Care Router (triage). The ACIP-style schedule, age-eligibility, dose series, and booster intervals are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified immunization forecaster (a real forecast uses the current ACIP recommendations, the CDC immunization schedules, and the patient's full clinical context).
Agentforce Controlled Substance / PDMP Safety Check
Clinical-decision agent · Clinical decision
A DETERMINISTIC (no-Claude) clinical-decision agent that screens a proposed controlled-substance prescription against the patient's PDMP (Prescription Drug Monitoring Program) history. Given a proposed prescription (a drug, its class, its dose in MME/day, days supply, prescriber, pharmacy) and the patient's active PDMP history, it DETERMINISTICALLY sums the total opioid MME/day (morphine milligram equivalents; proposed + concurrent), flags a concurrent opioid+benzodiazepine combination (a respiratory-depression risk) and multi-prescriber / multi-pharmacy patterns, compares the total against the cited guideline's caution (50 MME/day) and high-risk (90 MME/day) thresholds, and classifies the risk (low / elevated / high). The finding is a pure function of the request's data + the cited guideline (no randomness, no clock), so the same request always yields the same total + risk + disposition. THREE load-bearing honesty properties are governance-enforced: every risk threshold must cite a recorded guideline — an ad-hoc / un-sourced threshold is blocked (policy.controlledsubstance.guideline-sourced), mirroring the Immunization Agent's schedule-sourced and the Lab Result Agent's reference-range-sourced posture; the total MME/day must equal the computed proposed opioid contribution + concurrent opioid MME/day — a guessed / hidden dose (how an over-threshold prescription is wrongly called safe) is blocked (policy.controlledsubstance.mme-computed), the load-bearing correctness gate, mirroring the Timely Filing Agent's deadline-computed and the Good Faith Estimate Agent's math-consistent posture; and a risk finding is NEVER an autonomous prescribing decision — the agent never approves, denies, dispenses, or writes the prescription, an elevated / high finding is a RECOMMENDATION requiring prescriber review, and an auto-decided / unreviewed finding is blocked (policy.controlledsubstance.no-autonomous-prescribing-decision), mirroring the Immunization Agent's no-autonomous-administration and the Lab Result Agent's no-autonomous-clinical-action posture. It also honors the HIPAA-audit policy. It COMPLEMENTS, not duplicates, the other clinical / medication agents: distinct from the Formulary & DUR Review agent (plan-level coverage, step therapy, and drug-utilization-review alerts), the Medication Adherence agent (taking an already-prescribed drug), the Prior Authorization agent (assembling a payer PA package), and the Immunization Forecasting agent (vaccine schedule) — this screens the TOTAL controlled-substance burden across ALL prescribers per the PDMP. Menopause-relevant: a 45-64 patient managed for chronic pain plus an anxiety-indicated benzodiazepine is exactly the concurrent opioid+benzo cohort the CDC guidance flags. The MME thresholds + drug classes + MME/day figures are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified PDMP or clinical decision support (real monitoring uses the state PDMP, the CDC MME conversion factors, the CDC 2022 Clinical Practice Guideline for Prescribing Opioids, and the prescriber's clinical judgment).
Agentforce Drug–Drug Interaction (DDI) Safety Check
Clinical-decision agent · Clinical decision
A DETERMINISTIC (no-Claude) clinical-decision agent that screens a PROPOSED medication against the patient's ACTIVE medication list for drug–drug interactions. UNLIKE the recent platform agents there is NO date math, NO dollar waterfall, and NO single-record exception classifier — the heart of the service is a PAIRWISE KNOWLEDGE-BASE LOOKUP + a SEVERITY RANKING. Given a proposed / new drug and the patient's active medication list, it DETERMINISTICALLY pairs the proposed drug with each active medication, looks up every recorded interaction in the knowledge base, ranks them by severity (contraindicated > major > moderate > minor), reports the overall severity + mechanism + management, and decides the disposition (no-interaction-detected / monitor / review-recommended / review-required / do-not-coadminister-needs-review). The finding is a pure function of the request's own fields (no randomness, no clock), so the same proposed drug + active list always yields the same interactions + overall severity + disposition. THREE load-bearing honesty properties are governance-enforced: every reported interaction must trace to the recorded knowledge base with a matching pair + severity — a fabricated / off-catalog interaction (which erodes clinician trust and drives alert fatigue) is blocked (policy.ddi.interaction-sourced), mirroring the Controlled Substance Agent's guideline-sourced and the Immunization Agent's schedule-sourced posture; the overall severity must equal the highest cataloged severity among the detected interactions — an INFLATED severity (wrongful order cancellation, alert fatigue) or a SUPPRESSED severity (a hidden contraindication) is blocked (policy.ddi.severity-consistent), the load-bearing correctness gate mirroring the Member Cost-Share Agent's math-consistent and the OIG Exclusion Agent's match-not-overstated posture; and the order is NEVER autonomously held / cancelled (which could deny needed therapy) or the alert overridden (which could push through a contraindicated combination) — the agent SCREENS, every finding is a RECOMMENDATION requiring a pharmacist / prescriber to act on or review, and an auto-held / auto-overridden / unreviewed finding is blocked (policy.ddi.no-autonomous-hold-or-override), mirroring the Controlled Substance Agent's no-autonomous-prescribing-decision and the Lab Result Agent's no-autonomous-clinical-action posture. It also honors the HIPAA-audit policy (PHI-bearing — the screen references the patient's active medication list). It COMPLEMENTS, not duplicates, the other clinical / medication agents: distinct from the Controlled Substance / PDMP agent (the TOTAL controlled-substance MME burden across prescribers), the Formulary & DUR Review agent (plan-level coverage / step therapy), the Medication Adherence agent (taking an already-prescribed drug), the Prior Authorization agent (assembling a PA package), and the Immunization agent (the vaccine schedule) — this screens whether a NEW drug INTERACTS with what the patient already takes. Menopause-relevant: a 45-64 patient on tamoxifen for breast-cancer risk reduction who is newly prescribed paroxetine for hot flashes is exactly the major CYP2D6 interaction this screen catches before it reaches the pharmacy. The interaction knowledge base + severity assignments are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified clinical decision support system (real interaction checking uses a maintained compendium, normalized drug vocabularies like RxNorm, dose / route / timing context, patient-specific factors, and the pharmacist's / prescriber's clinical judgment).
Agentforce Medication Name Safety (LASA)
Flag look-alike / sound-alike drug-name confusion by edit distance: every candidate sourced + distances exact + never an autonomous substitution (patient & clinical) · Clinical decision
The Salesforce 'Agentforce for Health' / Health Cloud medication-name-safety analog, and a DETERMINISTIC (no-Claude) clinical-decision agent that takes a PRESCRIBED / TYPED drug name plus a formulary CATALOG and, using EDIT DISTANCE, finds the nearest catalog name and flags a LOOK-ALIKE / SOUND-ALIKE (LASA) confusion — a name dangerously close to a DIFFERENT drug, or a near-miss misspelling — for a pharmacist. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: UNLIKE the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the DDI agent's PAIRWISE KNOWLEDGE-BASE LOOKUP, the OIG Exclusion agent's EXACT identity MATCHING (which explicitly does NO fuzzy / phonetic matching), or the Audit Log Integrity agent's HASH CHAIN — and UNLIKE the date-deadline agents that add N days to a single date — the heart is STRING EDIT DISTANCE (the classic Levenshtein dynamic-programming algorithm: the minimum single-character insertions, deletions, and substitutions to turn one name into another). Look-alike / sound-alike medication-name confusion (premarin vs primaxin, hydroxyzine vs hydralazine) is one of the most persistent sources of medication error — the ISMP maintains a LASA list and the Joint Commission requires organizations to manage it. Given the name, it DETERMINISTICALLY normalizes it, computes the edit distance to every catalog drug, finds the nearest match, collects the look-alikes within the confusability threshold (0 < distance ≤ threshold), and derives the disposition — recognized-clear (an exact match with no look-alike), lasa-warning (a look-alike within the threshold — a possible wrong-drug confusion or near-miss misspelling), or unrecognized (no exact match and nothing within the threshold). The finding is a pure function of the name + catalog + threshold (no randomness, no clock), so the same input always yields the same finding. It COMPLEMENTS — it does not duplicate — the other medication agents: distinct from the Drug–Drug Interaction agent (whether two drugs INTERACT), the Formulary & DUR agent (whether a drug is COVERED / appropriate), the Controlled-Substance / PDMP agent (opioid MME safety), and the Medication Adherence agent (refill nudges), this catches a name CONFUSABLE with a different drug before it becomes a wrong-drug error. It is a clinical-decision agent on the PATIENT / CLINICAL plane, PHI-bearing (on the HIPAA-audit policy — the prescribed name is for a patient's medication order), not a live-Claude agent. A finding — recognized-clear, lasa-warning, or unrecognized — is a SAFE, honest output (not a block); every finding requires pharmacist review — which is how a legitimate finding is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: every candidate (the nearest match and every confusable look-alike) must trace to a real catalog drug (drugId in the catalog, echoed name matching) — a fabricated or mislabeled candidate is blocked (policy.lasa.candidates-sourced), the sourced gate mirroring the DDI Agent's interaction-sourced; the distances must be exact — recomputing the Levenshtein distance to the catalog must reproduce the reported nearest match, every distance, the exact-match flag, the confusable set (exactly those within the threshold), and the disposition, and a miscomputed distance / wrong nearest match / omitted look-alike / bad disposition is blocked (policy.lasa.distances-consistent), the load-bearing correctness gate mirroring the Schedule Conflict Agent's conflict-free and the Access Anomaly Agent's window-count-consistent; and no drug is autonomously substituted — the agent FLAGS, and a finding that substitutes the drug, silently corrects the order, or dispenses (autoSubstituted:true) or skips pharmacist review is blocked (policy.lasa.no-autonomous-substitution), mirroring the DDI Agent's no-autonomous-hold-or-override. Menopause-relevant: a hurried order for 'premarin' (conjugated estrogens for menopausal symptoms) that is one or two keystrokes from 'primaxin' (an IV antibiotic) is exactly the wrong-drug confusion this edit-distance check surfaces for a pharmacist — without ever autonomously changing the order. The catalog + names are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified medication-safety system; real LASA safety uses the ISMP / FDA LASA lists, tall-man lettering, RxNorm / First Databank vocabularies, indication / dose context, and barcode scanning.
Agentforce Care Pathway Sequencing
Order a clinical pathway's steps to respect prerequisites: every step sourced + a valid order (no prerequisite violated) + never an autonomous execution (patient & clinical) · Clinical decision
The Salesforce 'Agentforce for Health' / Health Cloud care-pathway analog, and a DETERMINISTIC (no-Claude) agent. A clinical pathway — a staged, evidence-based plan such as a menopause work-up-to-treatment pathway — is a set of steps with prerequisite dependencies; sequencing puts them in a safe order. UNLIKE the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the OIG Exclusion agent's identity MATCHING, the Drug Interaction agent's pairwise LOOKUP, or the MLR Rebate agent's RATIO + apportionment, the heart of this service is a TOPOLOGICAL ORDERING (Kahn's algorithm) over a dependency graph + CYCLE DETECTION — a genuinely new kind of computation for the fabric. Given a pathway (a pathway reference, a patient reference, and the steps, each declaring the prerequisite step ids that must precede it), it DETERMINISTICALLY runs Kahn's algorithm (ties broken by step id), reporting the disposition — sequenced (the ordered steps, with each step's stage = longest-prerequisite-chain depth), cannot-sequence-cycle-detected (the steps in a circular dependency, where no valid order exists), or cannot-sequence-missing-prerequisite (the steps whose prerequisites reference ids absent from the pathway). It COMPLEMENTS, not duplicates, the other clinical agents: distinct from the Care Plan agent (which AUTHORS a plan's goals / interventions / cadence from a template), the Transitions of Care and Care Coordination Handoff agents (moving a patient between settings / teams), the Prior Authorization agent (assembling a PA package), and the Drug Interaction / Controlled Substance agents (medication safety) — this ORDERS the steps of a pathway so no step is scheduled before its prerequisites. The determination is a pure function of the pathway's steps (no randomness, no clock), so the same pathway always yields the same order. THREE load-bearing honesty properties are governance-enforced: every step id appearing anywhere in the output (the ordered sequence, the stage map, the reported cycle members, the missing-prerequisite holders) must reference a submitted pathway step — a fabricated / dangling step id that would order or flag care that doesn't exist is blocked (policy.pathway.steps-sourced), mirroring the Drug Interaction Agent's interaction-sourced and the Enrollment Reconciliation Agent's actions-sourced posture; the sequence must be valid — when reported SEQUENCED, the ordered steps must be a complete permutation of the pathway (none dropped or duplicated) and every step must appear AFTER all of its prerequisites (ordering a treatment step before its safety-screening prerequisite is the worst failure mode), and when un-sequenceable no order may be asserted; a sequence that violates a prerequisite, drops a step, or asserts an impossible order is blocked (policy.pathway.sequence-valid), the load-bearing correctness gate mirroring the Member Cost-Share Agent's math-consistent and the Enrollment Reconciliation Agent's reconciliation-complete posture; and a step is NEVER autonomously executed — ordering a lab, a screening, or a therapy is a clinical action that must be authorized, and a determination that auto-executes or is not review-gated is blocked (policy.pathway.no-autonomous-execution), mirroring the Drug Interaction Agent's no-autonomous-hold-or-override and the Lab Result Agent's no-autonomous-clinical-action posture. It also honors the HIPAA-audit policy (PHI-bearing — the pathway references the patient). Menopause-relevant: a menopause work-up pathway — baseline labs, then confirm-diagnosis + cardiovascular/breast-cancer risk screening in parallel, then a shared decision-making visit, then initiate MHT or non-hormonal therapy, then a 3-month follow-up — is exactly the kind of dependency-ordered pathway this sequences so the risk screening always precedes the treatment decision. Runs against ILLUSTRATIVE synthetic pathways + steps — clearly labeled; NOT a certified clinical pathway engine (real pathway management uses evidence-based order sets, the patient's clinical context, scheduling / timing constraints, and the care team's judgment).
Pause Care Plan (Anthropic Claude Sonnet 4.5)
Post-visit care plan + progress summary (clinical decision) · Clinical decision
The Salesforce 'Agentforce for Health' / Health Cloud CarePlan analog, a clinical-plane sibling of the Care Router and the SECOND live-Claude agent on the fabric. Post-visit, it DETERMINISTICALLY instantiates a menopause care plan (goals, interventions, follow-up cadence) from a defined template — HRT-management, vasomotor/lifestyle, bone-health, or mood/behavioral — selected by the Care Router's pathway/severity + intake, so the same context always yields the same plan and every plan references a defined template id (never fabricated; governance genuinely blocks any off-template plan via policy.careplan.template-sourced). It then generates a patient/clinician progress summary with live Anthropic Claude — the same model + allow-list as the Care Router — falling back to a DETERMINISTIC scripted summary (with a recorded fallbackReason) when ANTHROPIC_API_KEY is unset or the API call fails, exactly like the Care Router. Summaries are NON-PRESCRIPTIVE (they never add or change a medication, dose, order, or prescription). The templates are ILLUSTRATIVE synthetics, clearly labeled — not a certified care-plan engine.
Agentforce Appointment Scheduling
Book / reschedule the MSCP visit (care coordination) · Care coordination
The Salesforce 'Agentforce for Health — Book/Reschedule/Update Appointment' analog, and the step that closes the loop: it books (and can reschedule) the MSCP menopause-specialist visit the Care Router recommends, honoring the requested modality (telehealth / in-person) against a provider availability calendar, and returns a structured booking — a Salesforce ServiceAppointment id, the confirmed slot start/end, modality, provider, and status. In the prototype the calendar is a DETERMINISTIC synthetic (hashed provider + date → stable 30-minute business-hours slots, ~a third pre-booked), clearly labeled synthetic — not a real Salesforce Scheduler / ServiceAppointment write. Governance genuinely enforces the two invariants that matter: it never double-books an already-taken slot and only books within the provider's published availability. It then hands the booked appointment to the Engagement Agent for visit reminders — closing acquisition → intake → routing → booking → engagement.
Agentforce Referral Management
Triage + draft outbound specialist referrals (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' Referrals ('Create Referral') analog, and the full-referral GENERALIZATION of the Care Router's behavioral-health handoff: rather than expressing a single handoff pathway, it triages a patient's intake + Care Router routing signals into referrals across the adjacent specialists menopause commonly touches — cardiology / CVD risk, endocrinology, bone health, pelvic-floor PT, and behavioral health — and drafts a referral request per recommendation. Triage is DETERMINISTIC (a pure function of the age/cycle/symptom/severity/red-flag context + risk flags — no randomness, no clock), so the same context always yields the same referral(s), and every recommended referral references a defined specialty-catalog id AND carries a documented reason (never fabricated, never reasonless). The load-bearing honesty property is that it can only DRAFT: an outbound referral requires a clinician's sign-off before it is sent — a referral is a clinical action that needs a human-in-the-loop, and governance genuinely blocks any send-without-cosign (policy.referral.clinician-cosign), alongside the reused rationale-required and HIPAA-audit policies. The specialties + triage rules are ILLUSTRATIVE synthetics, clearly labeled — not a certified clinical referral engine.
Agentforce Engagement Agent
Care continuity (post-routing) · Patient engagement
Picks up the Care Router's pathway output and the booked appointment, and schedules the follow-up cadence — visit reminders, symptom check-ins, and adherence nudges — honoring quiet-hours, channel preference, and frequency caps sourced from Data 360, and escalating disengagement or emerging-risk signals back to the router.
Agentforce Care Gap Closure
Proactive preventive care (care gap closure) · Care gap closure
The Salesforce 'Agentforce for Health' / Health Cloud care-gap-closure analog, and the fabric's PROACTIVE agent: rather than reacting to an intake, it grounds on the patient's Data 360 context + age/cycle/symptom signals and DETERMINISTICALLY detects menopause-relevant preventive-care gaps — bone-density/DEXA (osteoporosis risk), lipid panel, screening mammogram, and overdue HRT follow-up — then drafts consent- and quiet-hours-aware outreach for each and hands it to the Engagement Agent for delivery. Detection is a pure function of an explicit as-of date + per-measure history (no randomness, no clock), so the same context always yields the same gaps. The load-bearing property is integrity, not clinical authority: every detected gap references a defined clinical-measure catalog id — never a fabricated one — and governance genuinely blocks any off-catalog gap (policy.caregap.clinical-measure-sourced). The clinical measures + intervals are ILLUSTRATIVE synthetics, clearly labeled — not a certified guideline engine. Outreach reuses the engagement guards: contact consent required, human approval before any send, and quiet-hours + channel preference honored.
Agentforce Medication Adherence
Nudge-only HRT/SSRI refill & adherence (patient engagement) · Patient engagement
The Salesforce 'Agentforce for Health' / Health Cloud MedicationRequest + MedicationTherapyReview analog, and a second PROACTIVE patient-care agent alongside Care Gap Closure: it tracks whether a patient is staying on their menopause medications — transdermal/oral HRT (estradiol, oral progesterone) and an SSRI/SNRI for vasomotor symptoms or mood (paroxetine, venlafaxine) — and whether a refill is coming due, then drafts consent- and quiet-hours-aware refill/adherence nudges it hands to the Engagement Agent and flags adherence drop-off to the care team. Detection is DETERMINISTIC (a pure function of an explicit as-of date + each medication's days-supply and last-fill — no randomness, no clock), producing a good / at-risk / lapsed status and a refill-due call. The load-bearing honesty property is that it can only NUDGE: it may draft a refill reminder for human review but must NEVER autonomously submit or order a refill — a refill is a clinical action that requires a human-in-the-loop, and governance genuinely blocks any autonomous refill (policy.medication.no-autonomous-refill), reusing the no-prescribing and engagement outreach guards (contact consent, human approval before send, quiet-hours + channel preference). The medications + refill intervals are ILLUSTRATIVE synthetics, clearly labeled — not a certified pharmacy / e-prescribing system.
Agentforce Member Service / Billing
Billing & coverage self-service (patient service) · Patient-facing
The Salesforce 'Agentforce for Health' Claims & Coverage / patient-service analog: it answers a member's BILLING & COVERAGE self-service questions — claim status, copay / patient responsibility, outstanding balance, and EOB explanation — grounded on the member's synthetic claim/EOB records, and routes anything out of scope (a clinical, prescription, or scheduling request) to a human member-services specialist with a PII-safe billing context bundle, keeping it scoped to billing/coverage self-service and distinct from the Engagement Agent. Generation is DETERMINISTIC (member/claim keys hashed into realistic billed / allowed / plan-paid / patient-responsibility figures across submitted / adjudicated / paid / denied statuses — no randomness, no clock), so the same member always yields the same claims and the same question always answers identically. The load-bearing honesty property is that every billing/claim answer must trace to a specific claim/EOB record — the agent may not fabricate claim data — and governance genuinely blocks any billing answer that cites no claim (policy.billing.claim-data-sourced), alongside the reused no-free-text-pii and HIPAA-audit policies. The claim/EOB records are ILLUSTRATIVE synthetics, clearly labeled — not a real claims / 835-ERA remittance or FHIR ExplanationOfBenefit.
Agentforce Prior Authorization
Assemble a clinician-gated PA (clinical decision · utilization management) · Clinical decision
The Salesforce 'Agentforce for Health' / Health Cloud CareRequest + Utilization Management analog — the HEAVIEST agent on the fabric and, deliberately, the LEAST demo-honest of the set. For a PA-requiring menopause item (systemic HRT / compounded estradiol, a bone-density DEXA scan, or a specialized hormone lab panel) it pulls the (synthetic) clinical context, DETERMINISTICALLY matches the payer's medical-necessity criteria, assembles the required supporting-documentation checklist (present vs missing), and returns a clinician-gated PA package with a synthetic Health Cloud CareRequest / authorization id and a status (draft / ready-for-clinician / submitted). Real prior authorization is a genuinely multi-system workflow — an X12 278 (or FHIR PAS / Da Vinci) EDI exchange against a payer's utilization-management system — so this is a clearly-labeled MOCK, NOT a real 278/EDI or payer PA portal submission, and the payer criteria + document checklists are ILLUSTRATIVE synthetics, not a certified utilization-management engine (Salesforce's own guidance is to do PA last, and we did). TWO load-bearing honesty properties are governance-enforced: it must NOT autonomously submit a PA — a clinician must approve first, so it only ever assembles a clinician-gated draft (requiresClinicianApproval:true, submitted:false) and governance blocks any submit-without-approval (policy.pa.no-autonomous-submission); and a PA submission must include the required supporting documentation — a submission missing a required document is blocked (policy.pa.documentation-integrity). It reuses the no-prescribing, consent-before-grounding, and HIPAA-audit policies.
Agentforce Clinical Summary
After-visit summary + clinician handoff (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' After-Visit Summary / clinical-documentation analog, and the THIRD live-Claude agent after the Care Router and the Care Plan agent. It COMPOSES the outputs the other agents already produced — intake severity/symptoms, the Care Router pathway, and any optional validated-instrument assessment, instantiated care plan, or detected care gaps — into two artifacts: a patient-friendly after-visit summary and a clinician handoff note. Assembly is DETERMINISTIC and gathers ONLY facts present in the provided lifecycle inputs (no randomness, no clock), so it never invents a clinical fact or a source; the phrasing is generated with live Anthropic Claude — the same model + allow-list as the Care Router and Care Plan agents — falling back to a DETERMINISTIC scripted composition (with a recorded fallbackReason) when ANTHROPIC_API_KEY is unset or the API call fails, mirroring the Care Router / Care Plan agents. The load-bearing honesty property is governance-enforced: every summary must trace to the defined source records the context was assembled from — a fabricated / off-context assertion is blocked (policy.clinical-summary.source-record-sourced). It is NON-PRESCRIPTIVE and commits no clinical action (it re-states existing records for two audiences and requires clinician review), and it also honors the model allow-list and the HIPAA-audit policy. The artifacts are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified clinical-documentation engine.
Agentforce SDOH Screening
Whole-person care · social-needs screening + community referral · Whole-person care
The Salesforce 'Agentforce for Health' whole-person-care analog: it screens a patient for health-related social needs / social determinants of health with a validated, public-domain instrument (the CMS Accountable Health Communities HRSN core-domain tool: housing instability, food insecurity, transportation needs, utility needs, interpersonal safety), DETERMINISTICALLY flags the positive social-need domains (real rule-based scoring — the Hunger Vital Sign food screen, the HITS interpersonal-safety cutoff — no LLM), and drafts CONSENT-GATED community-resource referrals (211, food bank, housing/utility assistance, a domestic-violence hotline). Two load-bearing honesty properties are governance-enforced: it may only administer a screener on the validated allow-list (policy.sdoh.validated-screener-only), and it may only draft a community referral with the patient's explicit consent — never an autonomous enrollment (policy.sdoh.consent-before-referral). A positive interpersonal-safety screen is a mandatory escalation to a human social worker (mirroring the Assessment Agent's PHQ-9 item 9 handling). SDOH is SEPARATE from clinical severity — a positive social need raises a care-coordination flag, not an intake severity — so it complements the clinical agents. The community-resource catalog is an ILLUSTRATIVE synthetic, NOT a live directory of real programs.
Agentforce Patient Education & Health Coaching
Personalized menopause education + lifestyle coaching (patient engagement) · Patient engagement
The Salesforce 'Agentforce for Health' patient-education / health-coaching analog, and the FOURTH live-Claude agent: it turns already-produced signals (intake symptoms/severity, an optional validated-instrument assessment, Care Plan focus areas, and detected care gaps) into a personalized, evidence-sourced menopause/midlife education curriculum (bone health, cardiovascular risk, sleep hygiene, vasomotor self-management, mood/stress, nutrition, physical activity) and a warm, motivational coaching message. It is distinct from the clinician-authored Care Plan agent and the refill-focused Medication Adherence agent — it only EDUCATES and COACHES. Module SELECTION is DETERMINISTIC (a pure function of the inputs against a defined evidence-sourced catalog — no randomness, no clock), and the coaching message is generated with live Anthropic Claude, falling back to a deterministic scripted message (with a recorded fallbackReason) on a missing key or any SDK error, mirroring the Care Plan / Clinical Summary agents. THREE load-bearing honesty properties are governance-enforced: every module must trace to a defined evidence source (policy.education.evidence-sourced), the content must stay strictly within general education — never a diagnosis, medication dose, or individualized medical advice (policy.education.no-medical-advice), and any coaching outreach is consent-gated + human-approval-gated (policy.education.consent-before-outreach). It also honors the model allow-list and the HIPAA-audit policy. The education modules + source labels (The Menopause Society, USPSTF, NAMS/ACOG-style) are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified patient-education engine.
Agentforce Remote Patient Monitoring & Symptom-Trend Tracking
Longitudinal symptom/vital trend detection + clinician-routed escalation (care coordination) · Care coordination
The remote-patient-monitoring (RPM) analog, and a DETERMINISTIC (no-Claude) agent modeled on Care Gap Closure and Medication Adherence: it ingests longitudinal (time-series) symptom/vital readings — self-reported or from wearables/devices — for a menopause/midlife patient (hot-flash frequency, sleep hours, mood score, resting heart rate, weight), DETERMINISTICALLY detects a per-metric trend (improving / stable / worsening) by comparing a recent window against a baseline window against a defined monitored-metrics catalog, and routes worsening or red-flag trends to a clinician for review. Trend detection is a pure function of the reading series (timestamps are accepted as data — no randomness, no clock dependence), so the same series always yields the same trend + escalation decision, and every escalation cites the metric + the threshold rule that triggered it. It is distinct from the preventive-measure Care Gap agent, the refill-focused Medication Adherence agent, and the coaching Patient Education agent — this one is about longitudinal monitoring, trend detection, and clinician-routed escalation. THREE load-bearing honesty properties are governance-enforced: every reading must trace to a recognized device/self-report source and a defined monitored metric — fabricated / off-catalog readings are blocked (policy.rpm.reading-source-integrity); it may NEVER take an autonomous clinical action — every escalation must be routed to a human clinician (routedTo:'clinician-review'), and any autonomous escalation is blocked (policy.rpm.no-autonomous-escalation); and longitudinal monitoring is consent-gated — monitoring without the patient's consent is blocked (policy.rpm.consent-to-monitor). It also honors the HIPAA-audit policy. The monitored-metric catalog, thresholds, and red-flag cutoffs are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified remote-monitoring or clinical-alerting engine.
Agentforce Population Health & Risk Stratification
Panel/cohort-level risk stratification + prioritized outreach worklist (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud population-health / risk-stratification analog, and a DETERMINISTIC (no-Claude) agent. Unlike every other patient-plane agent (which reasons over a SINGLE patient), this one reasons over a whole PANEL/COHORT at once — a new granularity. It ingests already-produced per-patient signals (intake severity, validated-assessment band, open care gaps, positive SDOH domains, medication-adherence status, monitored-symptom trend) and DETERMINISTICALLY stratifies each patient into a risk tier (low / rising / high) with a TRANSPARENT additive/weighted risk model — a pure function of the signals (no randomness, no clock), so the same panel always yields the same tiers + worklist ordering with a stable, documented tie-break — then emits a prioritized outreach worklist for a human care manager. It is distinct from the single-patient Care Gap Closure, Remote Patient Monitoring, and Clinical Summary agents: this one is population-level prioritization / care-management triage. THREE load-bearing honesty properties are governance-enforced: every patient's tier must trace to the documented risk-factor spec — an opaque / off-spec / black-box score is blocked (policy.pophealth.transparent-risk-model); the risk model may NOT score on a protected-class attribute (race, ethnicity, gender identity, religion, etc.) — a fairness / responsible-AI requirement (policy.pophealth.no-protected-class-factors); and a risk tier is a prioritization signal only — it may NEVER trigger an autonomous care action, every tier→action requires human / care-manager review (policy.pophealth.no-autonomous-care-decision). It also honors the HIPAA-audit policy. The risk factors, weights, cutoffs, and patient references are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified risk-stratification model.
Agentforce Clinical Trials & Research Matching
Structured trial-eligibility matching + consent-gated outreach (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud clinical-trials / research-matching analog, and a DETERMINISTIC (no-Claude) agent. It matches a SINGLE menopause/midlife patient against a SYNTHETIC study catalog using STRUCTURED eligibility criteria (age band, symptom profile, comorbidities, geography, prior therapy, HRT status, postmenopausal status), returns the matching studies ranked with per-criterion match explanations, and drafts a CONSENT-GATED outreach — it NEVER auto-enrolls a patient. Eligibility is a pure function of the patient context against each study's DEFINED criteria (dates, if any, are accepted as data — no randomness, no clock), so the same context always yields the same matches + ranking with a stable, documented tie-break (eligible first, then match score, then studyId). It ties thematically to the Consent & Preferences Management agent's `research` consent scope — deferring to that authoritative research-consent state before any outreach — but does its own eligibility logic, and is distinct from the single-patient Care Gap Closure and the panel-level Population Health agents: this one is trial / research eligibility matching. THREE load-bearing honesty properties are governance-enforced: every eligibility determination must trace to a defined study criterion — a fabricated / ad-hoc / off-catalog eligibility is blocked (policy.trials.eligibility-criteria-sourced); trial outreach is research-consent-gated — an active outreach without the patient's research consent is blocked, and when consent is absent the agent WITHHOLDS outreach (policy.trials.research-consent-required); and the agent may NEVER enroll a patient autonomously — enrollment requires informed consent + a human (policy.trials.no-autonomous-enrollment). It also honors the HIPAA-audit policy. The study catalog, sponsors, criteria, and patient references are ILLUSTRATIVE synthetics, clearly labeled — NOT real studies, real sponsors, or a certified trial-eligibility engine.
Agentforce Language Access & Health Equity
LEP language access: qualified interpreter + approved materials + equity gaps (whole-person care) · Whole-person care
A patient-care EQUITY agent, and a DETERMINISTIC (no-Claude) agent, that ensures limited-English-proficiency (LEP) patients can actually understand their care. It DETERMINISTICALLY determines the patient's PREFERRED LANGUAGE (deferring in copy to the Consent & Preferences Management agent's preferred-language preference), decides whether a QUALIFIED MEDICAL INTERPRETER is required and of which modality (in-person / video / phone), checks whether the needed PATIENT MATERIALS exist in that language (from an approved translated-materials catalog, each with a translation-provenance label), and FLAGS EQUITY / ACCESS GAPS (no qualified interpreter available for a language, a consent form only in English). The assessment is a pure function of the patient's structured context against the supported-language + approved-materials catalogs (no randomness, no clock), so the same context always yields the same assessment with a stable, documented equity-gap ordering. It reuses the existing whole-person-care tier (the SDOH / equity tier — a health-equity / access activity), not a new tier, and is distinct from the SDOH, consent, and clinical agents. THREE load-bearing honesty properties are governance-enforced: clinical interpretation must use a QUALIFIED medical interpreter — an untrained / ad-hoc / family interpreter (or machine translation) for clinical communication is blocked (policy.langaccess.qualified-interpreter-only), and when no qualified interpreter is available the agent ESCALATES to a human language-access coordinator (a safe answer, not a block) rather than substituting an unqualified option; every in-language material presented as official must trace to the approved translated-materials catalog — an unverified / ad-hoc translation is blocked (policy.langaccess.translated-material-source-integrity); and machine / auto translation may NEVER be used for clinical consent or clinical decision communication (policy.langaccess.no-machine-translation-for-consent). It also honors the HIPAA-audit policy. The supported-language list, interpreter availability, translated-materials catalog, and translation-provenance labels are ILLUSTRATIVE synthetics, clearly labeled — NOT a real interpreter roster, a real translated-document library, or a certified language-access system.
Interpreter Assignment / Optimal Assignment (Hungarian Algorithm)
Assign interpreters to concurrent appointments at minimum total cost via the Hungarian algorithm: every assignment a sourced self-consistent one-to-one matching + a re-optimizing cost + never an autonomous dispatch (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud language-access scheduling analog, and a DETERMINISTIC (no-Claude) care-coordination agent — the interpreter-assignment layer of the care plane, and the operational sibling of the Language Access & Health Equity agent (which decides WHETHER a qualified interpreter is required; this decides WHICH interpreter covers WHICH appointment at least total cost). Given a set of qualified INTERPRETERS, a set of concurrent APPOINTMENTS, and a COST matrix (each interpreter↔appointment pairing carrying a cost — travel + wait + skill-mismatch, or an 'unavailable' sentinel when an interpreter can't cover an appointment), it computes the MINIMUM-TOTAL-COST one-to-one ASSIGNMENT — reporting the pairings, the total cost, and any uncoverable appointments (disposition assignable / infeasible). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of this service is the HUNGARIAN ALGORITHM (Kuhn–Munkres): the O(n³) combinatorial method that finds a minimum-cost perfect matching in a bipartite graph by maintaining dual potentials and augmenting along tight-edge alternating paths until every row is matched. It is EMPHATICALLY DISTINCT from the two matching agents it sits near: NOT the PCP Matching agent's GALE–SHAPLEY STABLE MATCHING (which produces a STABLE matching from two-sided PREFERENCE lists — no costs, no global optimum, and stability, not minimum total cost, is its property) and NOT the Caseload Balancing agent's WORST-FIT-DECREASING BIN-PACKING (an unordered greedy capacity fill, not a one-to-one optimal matching). It is also NOT the Referral Throughput agent's MAX-FLOW, NOT the Network Build-Out agent's MINIMUM SPANNING TREE, NOT the Batch Partition agent's LINEAR PARTITION, NOT the Outreach agent's 0/1 KNAPSACK, and NOT the Care Routing agent's DIJKSTRA'S SHORTEST PATH — it is the ASSIGNMENT PROBLEM, solved to the provable minimum. The minimum total assignment cost is the invariant this service reports and defends (a pure function of the cost matrix — no clock, no randomness — so the same request always yields the same assignment). It COMPLEMENTS — it does not duplicate — the PCP Matching agent (stable member↔PCP matching) and the Caseload Balancing agent (panel capacity fill): this is the optimal one-to-one assignment. It is a care-coordination agent on the CARE plane, PHI-adjacent (on the HIPAA-audit policy — appointment encounters), not a live-Claude agent. An assignment — assignable or infeasible — is a SAFE, honest output (not a block); an infeasible disposition is a LEGITIMATE FINDING (some appointment has no qualified interpreter — a coverage gap), and every assignment requires coordinator review — which is how a legitimate assignment is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: the assignment must be sourced + self-consistent — a real one-to-one matching over the submitted sets (no interpreter or appointment used twice, no fabricated pairing, no unavailable cell), the totalCost equal to the sum of the chosen cells, the unmatched list exactly the uncovered appointments, the disposition following — a fabricated pairing, a reused interpreter, or an overstated cost is blocked (policy.interpasg.assignment-sourced), the sourced + self-consistency gate mirroring the Benefit Accumulator Agent's ledger-sourced and the Network Build-Out Agent's tree-sourced; the assignment must be cost-optimal — re-running the Hungarian algorithm over the submitted cost matrix must reproduce the reported totalCost — a sub-optimal assignment that wastes interpreter time is blocked (policy.interpasg.cost-optimal), the load-bearing correctness gate that recomputes the minimum total cost INDEPENDENT of the reported pairings (so a fabricated assignment that still reports the optimal cost fails sourced only and a real-but-sub-optimal assignment fails optimal only — the two gates are isolable), mirroring the Benefit Accumulator Agent's accumulator-exact and the Network Build-Out Agent's cost-optimal; and no interpreter is autonomously dispatched — the agent ASSIGNS and RECOMMENDS, and an assignment that books / dispatches / notifies an interpreter (autoDispatched:true) or skips coordinator review is blocked (policy.interpasg.no-autonomous-dispatch), mirroring the Benefit Accumulator Agent's no-autonomous-adjust and the Referral Throughput Agent's no-autonomous-route. Menopause-relevant: staffing a morning of concurrent menopause-clinic visits — a Spanish telehealth consult, a Mandarin in-person visit, an Arabic follow-up — with the on-call interpreters at the least total travel + wait cost, and surfacing the appointment that has no qualified interpreter, is exactly the optimal assignment this Hungarian solver computes, without ever booking an interpreter on its own. The costs are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified interpreter-scheduling / workforce system (real interpreter scheduling weighs certification & specialty, modality, union & labor rules, travel logistics, and member language preference — not a bare cost matrix).
Coverage Heatmap / Difference-Array Range Accumulation
Compute per-slot concurrent staffing coverage from overlapping shift intervals and flag under-staffed slots via a difference array: every heatmap a sourced self-consistent count + a re-materializing exact accumulation + never an autonomous staffing action (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud capacity-visibility analog, and a DETERMINISTIC (no-Claude) care-coordination agent — the coverage-heatmap layer of the care plane. Given a set of staffing COVERAGE INTERVALS (each adding some number of staff over a contiguous window of time slots) and a REQUIRED MINIMUM staffing level, it computes the CONCURRENT coverage at every slot and flags the UNDER-STAFFED slots (those below the minimum) — reporting the per-slot coverage array, the under-staffed slots, the min/max, and the disposition (fully-covered / understaffed). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of this service is the DIFFERENCE ARRAY (the imos / range-update technique): to add `staff` to every slot in [start, end), increment diff[start] and decrement diff[end] — an O(1) range update — then a single PREFIX-SUM pass materializes the concurrent coverage at every slot in O(T), so applying m overlapping intervals costs O(m + T), not O(m·T). It is NOT the Fenwick / Benefit Accumulator agent's POINT-UPDATE + PREFIX-QUERY tree (the dual problem — this is RANGE-UPDATE + full MATERIALIZE), NOT the Schedule Conflict agent's GREEDY INTERVAL SELECTION (which picks a max non-overlapping subset — this COUNTS overlaps per slot), NOT the Peak-Window agent's KADANE MAXIMUM-SUBARRAY (a max contiguous sum — this is per-slot occupancy), NOT the Caseload Balancing agent's BIN-PACKING, and NOT the Batch Partition agent's LINEAR PARTITION — it is difference-array range accumulation. The per-slot concurrent coverage is the invariant this service reports and defends (a pure function of the intervals + slot count — no clock, no randomness — so the same request always yields the same heatmap). It COMPLEMENTS — it does not duplicate — the Schedule Conflict agent (double-booking guard) and the Caseload Balancing agent (panel capacity fill): this visualizes concurrent coverage across a schedule. It is a care-coordination agent on the CARE plane, PHI-adjacent (on the HIPAA-audit policy — care-unit staffing), not a live-Claude agent. A heatmap — fully-covered or understaffed — is a SAFE, honest output (not a block); an understaffed disposition is a LEGITIMATE FINDING (a coverage gap), and every heatmap requires manager review — which is how a legitimate heatmap is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: the coverage must be sourced + self-consistent — each coverage[t] equal to the true count of staff covering slot t (cross-checked by DIRECT interval counting, INDEPENDENT of the difference-array method), the under-staffed slots exactly the below-min slots, honest min/max — a fabricated coverage value, a mis-listed slot, or a dishonest min/max is blocked (policy.coverageheat.coverage-sourced), the sourced + self-consistency gate mirroring the Benefit Accumulator Agent's ledger-sourced and the Interpreter Assignment Agent's assignment-sourced; the accumulation must be exact — re-applying the intervals to a fresh difference array must reproduce the coverage array — a mis-materialized heatmap is blocked (policy.coverageheat.accumulation-exact), the load-bearing correctness gate that re-runs the difference-array accumulation INDEPENDENT of the reported coverage, so the two gates cross-check the same per-slot truth by two different methods (a fabricated coverage that still reports the right under-staffed slots fails accumulation only and a genuine-but-mislabeled disposition fails sourced only — the two are isolable), mirroring the Benefit Accumulator Agent's accumulator-exact and the Interpreter Assignment Agent's cost-optimal; and no staff is autonomously scheduled — the agent VISUALIZES and RECOMMENDS, and a heatmap that schedules / adjusts / dispatches staff (autoStaffed:true) or skips manager review is blocked (policy.coverageheat.no-autonomous-staff), mirroring the Interpreter Assignment Agent's no-autonomous-dispatch and the Benefit Accumulator Agent's no-autonomous-adjust. Menopause-relevant: seeing, across a menopause-clinic day, exactly which hours dip below the required nurse / MA coverage as morning and afternoon shifts overlap and hand off — so a manager can plug the gap before it becomes a wait-time or safety problem — is exactly the per-slot concurrency this difference-array heatmap computes, without ever moving a staff member on its own. The intervals are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified workforce-management / staffing system (real staffing weighs skill mix, acuity-adjusted ratios, licensure, breaks & meal relief, union rules, and float pools — not a bare count of overlapping intervals).
Rolling Census Peak / Sliding-Window Maximum (Monotonic Deque)
Compute the peak census in every trailing window of a unit's occupancy readings and flag over-capacity windows via a monotonic deque: every report a sourced self-consistent per-window peak + a re-deriving exact deque + never an autonomous diversion (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud capacity-monitoring analog, and a DETERMINISTIC (no-Claude) care-coordination agent — the rolling-peak layer of the care plane. Given a series of per-slot CENSUS readings (occupancy counts over time) and a trailing WINDOW width k, it computes the PEAK census in every trailing window and flags the windows whose peak exceeds a CAPACITY threshold — reporting the per-window maxima, the over-capacity windows, the overall peak, and the disposition (within-capacity / over-capacity). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of this service is the MONOTONIC DEQUE sliding-window maximum: maintain a double-ended queue of candidate indices whose readings are decreasing, pop from the back every index whose reading is ≤ the incoming reading (they can never again be a maximum), push the new index, and drop the front once it falls out of the window — the front is always the window's maximum, giving O(1) amortized per window and O(n) overall. It is NOT the Access Anomaly agent's SLIDING-WINDOW COUNTING (a fixed-window EVENT COUNT — this is the sliding-window EXTREMUM via a monotonic deque), NOT the Coverage Heatmap agent's DIFFERENCE-ARRAY RANGE ACCUMULATION (per-slot occupancy from range-adds — this is the rolling MAX over a window of an existing series), NOT the Peak-Window agent's KADANE MAXIMUM-SUBARRAY (a max contiguous SUM — this is a max VALUE per fixed-width window), NOT the Fenwick / Benefit Accumulator agent's PREFIX SUMS, and NOT the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING — it is the sliding-window maximum. The per-window peak is the invariant this service reports and defends (a pure function of the readings + window size — no clock, no randomness — so the same request always yields the same report). It COMPLEMENTS — it does not duplicate — the Coverage Heatmap agent (per-slot concurrent coverage) and the Access Anomaly agent (windowed event counts): this reports the rolling peak occupancy. It is a care-coordination agent on the CARE plane, PHI-adjacent (on the HIPAA-audit policy — care-unit occupancy), not a live-Claude agent. A report — within-capacity or over-capacity — is a SAFE, honest output (not a block); an over-capacity disposition is a LEGITIMATE FINDING (a capacity breach), and every report requires supervisor review — which is how a legitimate report is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: the windows must be sourced + self-consistent — each window max equal to the true max of that window (cross-checked by DIRECT per-window scanning, INDEPENDENT of the deque method), the over-capacity windows exactly the breaching windows, honest peak/counts — a fabricated window max, a mis-listed window, or a dishonest peak is blocked (policy.rollingcensus.windows-sourced), the sourced + self-consistency gate mirroring the Coverage Heatmap Agent's coverage-sourced and the Benefit Accumulator Agent's ledger-sourced; the deque must be exact — re-running the monotonic deque must reproduce the maxima array — a mis-derived maxima array is blocked (policy.rollingcensus.deque-exact), the load-bearing correctness gate that re-runs the monotonic deque INDEPENDENT of the reported maxima, so the two gates cross-check the same per-window truth by two different methods (a fabricated maxima array that still reports the right over-capacity windows fails deque only and a genuine-but-mislabeled disposition fails sourced only — the two are isolable), mirroring the Coverage Heatmap Agent's accumulation-exact and the Benefit Accumulator Agent's accumulator-exact; and no admissions are autonomously diverted — the agent MONITORS and RECOMMENDS, and a report that diverts admissions, triggers surge staffing, or acts on a peak (autoDiverted:true) or skips supervisor review is blocked (policy.rollingcensus.no-autonomous-divert), mirroring the Coverage Heatmap Agent's no-autonomous-staff and the Interpreter Assignment Agent's no-autonomous-dispatch. Menopause-relevant: watching a menopause-clinic's rolling occupancy across a busy clinic day — seeing which 3-hour windows peak above the safe capacity as walk-ins and scheduled visits stack up — so a supervisor can flex capacity before wait times or safety suffer, is exactly the rolling peak this monotonic-deque sliding-window maximum computes, without ever diverting a patient on its own. The readings are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified capacity-management / patient-flow system (real census management weighs acuity, staffed vs licensed beds, isolation & telemetry needs, anticipated discharges, and boarding — not a bare rolling max over illustrative counts).
Agentforce HEDIS & Quality Reporting
Panel-level HEDIS / Star measure rollup + human-approved submission (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud quality-reporting analog, and a DETERMINISTIC (no-Claude) agent. Unlike the single-patient Care Gap Closure agent (which drafts outreach for one patient's gaps) and the panel-level Population Health & Risk Stratification agent (which prioritizes patients), this one reports a whole PANEL against a defined set of HEDIS quality measures — numerator, denominator, catalog-sourced exclusions, and compliance RATE per measure — the artifact provider organizations owe payers under value-based-care contracts. The illustrative measure catalog covers menopause-relevant preventive-and-screening (Osteoporosis Screening in Women / OSW, Breast Cancer Screening / BCS), cardiovascular (Controlling High Blood Pressure / CBP, Statin Therapy for CVD / SPC), and behavioral (Tobacco Cessation Counseling / TCC) domains. The roll-up is a pure function of the panel signals + the caller-provided `asOfPeriod` accepted as data (no randomness, no clock), so the same panel + period always yields the same rates and gap lists, with a stable, documented per-measure denominator narrowing. THREE load-bearing honesty properties are governance-enforced: every scored measure must trace to the defined HEDIS measure catalog — an off-catalog / fabricated measure is blocked (policy.hedis.measure-catalog-sourced); every applied denominator exclusion must trace to a defined catalog exclusion on that measure — an ad-hoc / unlisted exclusion is blocked (policy.hedis.exclusion-integrity), the load-bearing rate-integrity guard against inflating a rate by shrinking the denominator; and the agent may NEVER autonomously submit a package to a payer / CMS / a quality registry — every submission requires a human quality-team approval (policy.hedis.no-autonomous-submission). It also honors the HIPAA-audit policy. The measure catalog, thresholds, and exclusion lists are ILLUSTRATIVE synthetics, clearly labeled — NOT NCQA-certified HEDIS specifications, real value sets, or a certified HEDIS engine.
Agentforce Advance Care Planning
Midlife ACP touchpoint: catalog-sourced directives + human-signoff + LEP-safe conversation (whole-person care) · Whole-person care
A whole-person-care ACP TOUCHPOINT agent for the midlife/menopause patient, and a DETERMINISTIC (no-Claude) agent. It uses perimenopause / menopause as a natural midlife moment to surface which advance directives are on file (living will, DPOA-HC; POLST only when a serious-illness flag is on), flags missing / stale / language-access gaps against an illustrative directive catalog + approved-source list (verbal / ad-hoc sources deliberately excluded), and drafts a consent-gated conversation prompt for the care team to deliver. It is distinct from the Consent & Preferences Management agent (data-use consent) and the Care Plan agent (active treatment planning) — this one is about preserving the patient's voice if they lose decisional capacity, held at a midlife touchpoint rather than during acute illness. The assessment is a pure function of the caller-provided asOfDate + directives-on-file (no randomness, no clock), so the same context always yields the same assessment. THREE load-bearing honesty properties are governance-enforced: every claimed directive on file must trace to the defined ACP directive catalog AND an approved directive-source label with a recorded execution date — an off-catalog directive, an unapproved / verbal / ad-hoc source, or a missing execution date is blocked (policy.acp.directive-source-integrity), so the agent cannot fabricate a directive on file to inflate ACP completeness; the agent may NEVER autonomously create, update, or override a directive — every change is a clinician + patient sign-off gated proposal (policy.acp.no-autonomous-directive-change); and for a limited-English-proficiency (LEP) patient the active conversation prompt is gated on a documented qualified-interpreter plan — a plan claiming an active drafted prompt for an LEP patient with no interpreter is blocked (policy.acp.language-access-integrity), and when no plan is documented the agent WITHHOLDS the active prompt (a safe completed answer, not a block), deferring to the Language Access & Health Equity agent. It also honors the HIPAA-audit policy. The directive catalog, approved-source labels, and staleness threshold are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified advance-directives registry, a POLST/MOLST program, or a legal instrument.
Agentforce Care Team & Case Management
Multi-disciplinary team assembly + case-manager assignment (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud care-team / case-management analog, and a DETERMINISTIC (no-Claude) agent. It reasons over a SINGLE high-need menopause/midlife patient (distinct from the panel-level Population Health & Risk Stratification agent, which prioritizes people across a whole panel) and COORDINATES clinicians around that patient: it resolves which roles are needed from the patient's active clinical needs against an illustrative care-role catalog + condition→role trigger map (PCP + MSCP universally required; cardiology / endocrinology / bone-health / pelvic-floor PT / behavioral health triggered by cardiovascular / bone-health / pelvic-floor / behavioral needs), assembles the roster of assigned members in role catalog order, assigns a case manager by a stable, documented hash on the patient ref, and emits a shared team snapshot the whole team reads from. The assembly is a pure function of the context + asOfDate (no randomness, no clock), so the same context always yields the same team + case manager + snapshot with a stable, documented gap ordering. THREE load-bearing honesty properties are governance-enforced: every team role — on the roster and in the needed-roles set — must trace to the defined care-role catalog, so an off-catalog / fabricated discipline label is blocked (policy.careteam.role-catalog-sourced), preventing an assembly from padding the roster with an invented role or claiming coverage for a needed role that doesn't exist; the agent may NEVER autonomously add or remove a team member (or reassign the case manager) — every roster change is a case-manager sign-off gated proposal, mirroring the ACP Agent's directive-change and the HEDIS Agent's submission posture (policy.careteam.no-autonomous-assignment); and a legitimate multi-disciplinary team must include a PCP anchor — a specialist-only roster shipping without an accountable primary-care owner is blocked (policy.careteam.pcp-required), a load-bearing continuity-of-care invariant. It also honors the HIPAA-audit policy. The care-role catalog, condition→role triggers, case-manager pool, member refs, and responsibility labels are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified care-team schema, a real provider directory, or a case-management workflow engine.
Agentforce Caseload Balancing (Care-Manager Panel Assignment)
Allocate a panel of members across care managers within capacity (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud panel-assignment analog, and a DETERMINISTIC (no-Claude) agent — a care-coordination service that takes a PANEL of members (each with an acuity weight) and a set of CARE MANAGERS (each with a weighted-slot CAPACITY) and ALLOCATES the members across the managers WITHOUT exceeding any manager's capacity — balancing the load and WAITLISTING the overflow. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: UNLIKE the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING + GAP DETECTION, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the OIG Exclusion agent's identity MATCHING, or the Audit Log Integrity agent's HASH CHAIN — and UNLIKE the date-deadline agents that add N days to a single date — the heart is GREEDY ALLOCATION UNDER A CAPACITY CONSTRAINT (a bin-packing / worst-fit-decreasing assignment of weighted items into capacity-limited bins: it processes members in descending acuity and places each into the manager with the greatest remaining capacity that can fit it, tie-broken by id, waitlisting any that do not fit). The allocation is a pure function of the members + managers (no randomness, no clock), so the same panel always yields the same assignment. It COMPLEMENTS — it does not duplicate — the other care-coordination agents: distinct from the Care Team & Case Management agent (which assembles the multi-disciplinary team around ONE patient and picks that patient's case manager), the Complex Care Management agent (CCM time-tracking for ONE patient), the Transitions of Care agent (moving ONE patient between settings), and the Population Health agent (which PRIORITIZES / stratifies a panel), this ALLOCATES a whole panel across the managers' finite capacity — the balancing of caseloads, not the coordination of one patient's care. It is a care-coordination service on the PATIENT / CLINICAL plane, PHI-bearing (on the HIPAA-audit policy — the members reference the patients on the panel), not a live-Claude agent. An allocation — fully assigned OR partially assigned with a waitlist — is a SAFE, honest output (not a block); every allocation requires care-management-lead review — which is how a legitimate allocation is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: every member is accounted for exactly once — the assigned set and the waitlisted set must be disjoint and cover every member (no dropped member falling through the cracks, no double-assignment), and a determination that drops or double-counts a member is blocked (policy.caseload.assignment-complete), the completeness gate mirroring the Enrollment Reconciliation Agent's reconciliation-complete; capacity is respected — each manager's assigned acuity must equal the sum of their members' acuities, must not exceed capacity, and every waitlist must be justified (the member's acuity exceeds every manager's final remaining capacity), and an over-loaded manager, a miscounted load, or a member waitlisted while a manager had room is blocked (policy.caseload.capacity-respected), the load-bearing correctness gate mirroring the Access Anomaly Agent's window-count-consistent and the Member Cost-Share Agent's math-consistent; and no assignment is autonomously committed — the agent RECOMMENDS, and a determination that commits an assignment, reassigns a patient, or overrides a manager's caseload (autoAssigned:true) or skips care-lead review is blocked (policy.caseload.no-autonomous-assignment), mirroring the Care Team Agent's no-autonomous-assignment posture. The members + managers + acuity + capacity are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified caseload / staffing system; real panel assignment uses validated acuity instruments, care-manager licensure / specialty / language fit, geographic match, and continuity of an existing relationship.
Agentforce PCP Assignment / Member–Provider Matching
Assign members to primary care providers via a stable two-sided matching: every assignment sourced + a stable recompute (no blocking pair) + never an autonomous commit (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud PCP-assignment analog, and a DETERMINISTIC (no-Claude) care-coordination agent that takes a PANEL of unassigned MEMBERS (each with a ranked list of preferred primary care providers) plus a set of PROVIDERS (each with a panel CAPACITY and a ranked list of the members it would accept) and produces a STABLE assignment of members to providers — a matching in which no member and provider who both prefer each other over their current assignment are left apart (no BLOCKING pair) and no provider is over capacity. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: UNLIKE the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the Master-Patient-Index agent's WEIGHTED identity MATCHING, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN — and, CRUCIALLY, UNLIKE the Caseload Balancing agent's GREEDY BIN-PACKING (which allocates a panel across managers' capacity by acuity, with NO preferences and NO stability guarantee) — the heart of this service is TWO-SIDED STABLE MATCHING: the Gale–Shapley DEFERRED-ACCEPTANCE algorithm (the member-proposing, many-to-one 'hospitals/residents' variant) that, from both sides' preference lists + provider capacities, produces the member-optimal STABLE matching — the unique assignment with no blocking pair. An assignment that leaves a member and a provider who each prefer the other over their current lot (a blocking pair) is UNSTABLE — it unravels as the pair defects, leaving a patient without a real PCP; so the agent computes a provably stable matching DETERMINISTICALLY (a pure function of the preferences + capacities — no clock, no randomness — so the same panel always yields the same matching, with the free members proposing in a deterministic id order) and derives the disposition: all-matched (every member matched to a preferred provider) or partial-match (some members unmatched — capacity exhausted or short preference lists). It COMPLEMENTS — it does not duplicate — the other care-coordination agents: distinct from the Caseload Balancing agent (which BIN-PACKS a panel across managers' capacity to balance load, no preferences), the Care Team & Case Management agent (the multi-disciplinary team around ONE patient), the Transitions of Care agent (moving ONE patient), and the Population Health agent (prioritizing a panel) — this produces a STABLE two-sided matching of members to primary care providers. It is a care-coordination agent on the PATIENT / CLINICAL plane, PHI-bearing (on the HIPAA-audit policy — the members are patients), not a live-Claude agent. A matching — all-matched or partial-match — is a SAFE, honest output (not a block); every matching requires coordinator review — which is how a legitimate matching is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: every assignment must be built from the submitted panel — one assignment per submitted member (all present, none dropped or invented), every assigned provider a submitted one, and the provider loads echoing the submitted capacities + actual counts — and a phantom member / provider that corrupts the panel is blocked (policy.pcp.matching-sourced), the sourced + completeness gate mirroring the Network Adequacy Agent's providers-sourced and the Caseload Balancing Agent's assignment-complete; the matching must be stable — recomputing the Gale–Shapley deferred acceptance from the preferences + capacities must reproduce the assignment + each member's preference rank, no provider may be over capacity, and there must be NO blocking pair — and an unstable / mis-recomputed matching is blocked (policy.pcp.matching-stable), the load-bearing correctness gate mirroring the Network Adequacy Agent's distances-consistent and the Household Composition Agent's partition-consistent; and no assignment is autonomously committed — the agent PROPOSES, and a determination that commits an assignment, reassigns a patient, or overrides a provider's panel (autoAssigned:true) or skips coordinator review is blocked (policy.pcp.no-autonomous-assignment), mirroring the Caseload Balancing Agent's and the Care Team Agent's no-autonomous-assignment posture. Menopause-relevant: a 45-64 woman newly enrolling who ranks the in-network gynecologists and internists she'd accept as her PCP, matched against those providers' panel capacities, is exactly the stable assignment this Gale–Shapley matching produces — without ever committing her to a panel on its own. The members + providers + preferences + capacities are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified panel-management system; real PCP assignment also weighs geography, language, continuity of care, plan-network rules, and member choice, and runs against a live attribution system.
Agentforce Reportable / Notifiable Condition Case Classification
Classify a patient case against a nested public-health case definition via recursive boolean tree evaluation: every criterion sourced + a recomputing classification + never an autonomous report (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud reportable-condition analog, and a DETERMINISTIC (no-Claude) care-coordination / public-health-compliance agent that takes a patient CASE's structured facts plus a public-health CASE DEFINITION — an ordered list of classifications (confirmed / probable / suspect), each expressed as a nested boolean CRITERIA TREE of all-of (AND) / any-of (OR) / not (NOT) over leaf predicates ('confirmed = lab-positive OR (clinically-compatible AND epi-linked)') — and DETERMINISTICALLY classifies the case by evaluating each classification's tree and taking the highest-precedence one that holds (else not-a-case). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: UNLIKE the PCP Matching agent's TWO-SIDED STABLE MATCHING (Gale–Shapley), the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the Master-Patient-Index agent's WEIGHTED identity MATCHING, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN — the heart of this service is RECURSIVE BOOLEAN EXPRESSION-TREE EVALUATION: the recursive walk of a nested all-of / any-of / not tree whose leaves are predicates over the case's facts, the exact shape a public-health case definition takes, plus a documented classification precedence (the highest-precedence met tree wins). A mis-evaluated tree over-reports a notifiable condition (a false alarm to public health) or under-reports it (a missed case), so the agent evaluates the tree DETERMINISTICALLY (a pure function of the facts + definition — no clock, no randomness — so the same case always yields the same classification) and hands the classification to a human. It COMPLEMENTS — it does not duplicate — the other compliance / clinical agents: distinct from the Adverse-Event Reporting agent (which DRAFTS a MedWatch / VAERS report for a drug / vaccine event), the Utilization Review agent (medical-necessity criteria for a service), and the Lab Result agent (a single analyte vs a reference range) — this classifies a case against a nested public-health CASE DEFINITION. It is a care-coordination agent on the PATIENT / CLINICAL plane, PHI-bearing (on the HIPAA-audit policy — the case is a patient's clinical data), not a live-Claude agent. A classification — confirmed / probable / suspect / not-a-case — is a SAFE, honest output (not a block); every classification requires epidemiologist review — which is how a legitimate classification is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: every criterion must be sourced — each leaf predicate must reference a submitted fact (no fabricated criterion inventing a requirement the definition never stated), the reported classification results must be exactly the definition's classifications in order, and the referenced-fact set must match the definition's actual leaves — and a fabricated criterion / mis-enumerated definition is blocked (policy.reportable.facts-sourced), the sourced + completeness gate mirroring the PCP Matching Agent's matching-sourced and the Network Adequacy Agent's providers-sourced; the classification must recompute — re-running the recursive boolean evaluation of each criteria tree from the facts must reproduce each met flag, the selected classification, and the reportable flag — and a mis-evaluated tree (an over- or under-reported condition) is blocked (policy.reportable.classification-consistent), the load-bearing correctness gate mirroring the PCP Matching Agent's matching-stable and the Care Pathway Agent's sequence-valid; and no case is autonomously reported — the agent CLASSIFIES, and a determination that reports the case to a public-health authority (autoReported:true) or skips epi review is blocked (policy.reportable.no-autonomous-report), mirroring the Adverse-Event Reporting Agent's human-review posture and the HEDIS Agent's no-autonomous-submission. Menopause-relevant: a 45-64 woman presenting with an acute illness during a menopause-care encounter whose labs + clinical picture must be evaluated against a jurisdiction's notifiable-condition case definition is exactly the classification this recursive boolean tree produces — without ever filing a public-health report on its own. The condition + definition + facts are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified surveillance / case-reporting system; real notifiable-condition reporting uses the jurisdiction's official CSTE / CDC case definitions, eCR / eICR electronic case reporting, and an epidemiologist's judgment.
Agentforce Clinical Quality-Measure Shift Detection (Statistical Process Control)
Watch a clinical quality-measure series for a sustained shift via a two-sided tabular CUSUM: every point sourced + a recomputing CUSUM + never an autonomous intervention (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud quality-analytics analog, and a DETERMINISTIC (no-Claude) care-coordination / quality-analytics agent that watches a time-ordered series of a clinical QUALITY MEASURE (a weekly mammography-screening rate, a monthly HbA1c-control rate, a daily lab-QC value) and detects whether the measure has drifted into a SUSTAINED SHIFT away from its established TARGET — reporting the charted CUSUM points, the signal (in-control / shift-up-detected / shift-down-detected), the first-alarm index + direction, and the peak sums. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: UNLIKE the Timeline Merge agent's K-WAY MERGE OF SORTED STREAMS, the Reportable Condition agent's RECURSIVE BOOLEAN EXPRESSION-TREE EVALUATION, the PCP Matching agent's TWO-SIDED STABLE MATCHING (Gale–Shapley), the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN — and, CRUCIALLY, UNLIKE the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS (which ranks one value against a static peer distribution; this watches ONE series evolve over time) and the Access Anomaly agent's SLIDING-WINDOW COUNTING (which counts events in a fixed recent window to catch a spike; this accumulates a running deviation to catch a SUSTAINED small shift a window would miss) — the heart of this service is CHANGE-POINT DETECTION via a two-sided TABULAR CUSUM (cumulative-sum) control chart: it accumulates an upper sum SH_i = max(0, SH_{i-1} + (x_i − target) − k) and a lower sum SL_i = max(0, SL_{i-1} + (target − x_i) − k), where k is the slack, and signals the first observation whose SH or SL exceeds the decision threshold h. A missed shift lets a quality measure decay unnoticed; a false alarm sends a team chasing noise, so the agent charts DETERMINISTICALLY (a pure function of the observations' own values + the parameters — no clock, no randomness — so the same series always yields the same signal) and hands the finding to a human. It COMPLEMENTS — it does not duplicate — the other quality / clinical agents: distinct from the HEDIS agent (which COMPUTES a measure rate), the Population Health agent (which PRIORITIZES a panel by risk), the Provider Benchmarking agent (which RANKS a value against peers), and the Remote Monitoring agent (which checks ONE patient's vitals against a threshold) — this watches a quality-measure series for a sustained shift over time. It is a care-coordination agent on the PATIENT / CLINICAL plane; it charts de-identified aggregate rate series, but because the measures are derived from patient clinical data it is PHI-bearing (on the HIPAA-audit policy), not a live-Claude agent. A signal — in-control / shift-up-detected / shift-down-detected — is a SAFE, honest output (not a block); every signal requires quality review — which is how a legitimate signal is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: every charted point must be sourced — each must trace to a submitted observation (same index + value; no fabricated point), every submitted observation must appear exactly once (none dropped, none double-charted), and the chart parameters must be present — and a fabricated or dropped point is blocked (policy.quality.observations-sourced), the sourced + completeness gate mirroring the Timeline Merge Agent's events-sourced and the Enrollment Reconciliation Agent's reconciliation-complete; the CUSUM must recompute — re-running the two-sided tabular CUSUM from the observations must reproduce every charted SH_i / SL_i, the first-alarm index, the direction, and the signal — and a mis-charted CUSUM (a faked or hidden shift) is blocked (policy.quality.cusum-consistent), the load-bearing correctness gate mirroring the Timeline Merge Agent's merge-consistent and the Provider Benchmarking Agent's stats-consistent; and no corrective action is launched autonomously — the agent DETECTS, and a determination that launches a corrective action, a recall / outreach campaign, or a process change (autoActioned:true) or skips quality review is blocked (policy.quality.no-autonomous-intervention), mirroring the HEDIS Agent's no-autonomous-submission and the Care Gap Agent's human-review posture. Menopause-relevant: a menopause-care program tracking its bone-density-screening or mammography-completion rate week over week, whose sustained downward drift is exactly the sustained shift this CUSUM chart catches before the care gap widens — without ever launching an outreach campaign on its own. The measures are ILLUSTRATIVE de-identified aggregate rate series, clearly labeled — NOT a certified SPC / quality-surveillance platform; real statistical process control tunes k and h to a target ARL, combines CUSUM with Shewhart / EWMA charts, and accounts for autocorrelation and measure specifications.
Agentforce Care-Management Capacity Allocation / Outreach Prioritization
Select the max-benefit subset of proactive interventions under a capacity budget via 0/1 knapsack DP: every selection sourced + an optimal + feasible allocation + never an autonomous schedule (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud care-management capacity-planning analog, and a DETERMINISTIC (no-Claude) care-coordination agent that, given a care team's fixed CAPACITY for the cycle (its available outreach HOURS this week) and a set of candidate proactive INTERVENTIONS (each with an hours COST and a projected clinical BENEFIT), selects the subset that MAXIMIZES total projected benefit while fitting the capacity budget — deferring (never denying) the rest to the next cycle — reporting the selected + deferred sets, the total cost / benefit, the remaining capacity, and the disposition (all-scheduled / some-deferred). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: UNLIKE the Quality Shift agent's CUSUM CHANGE-POINT DETECTION, the Timeline Merge agent's K-WAY MERGE OF SORTED STREAMS, the Reportable Condition agent's RECURSIVE BOOLEAN EXPRESSION-TREE EVALUATION, the PCP Matching agent's TWO-SIDED STABLE MATCHING (Gale–Shapley), the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN — and, CRUCIALLY, UNLIKE the Caseload Balancing agent's GREEDY BIN-PACKING (which distributes EVERY member across managers' capacities by acuity — a partition) and the Population Health agent's RISK RANKING (which orders a panel; it selects no subset under a budget) — the heart of this service is the 0/1 KNAPSACK via DYNAMIC PROGRAMMING: the capacity-constrained maximum-value-subset optimization, filling a DP table dp[i][c] = max(dp[i-1][c], dp[i-1][c-cost_i] + benefit_i) and reconstructing the optimal set by walking the table back. A greedy or hand-picked allocation leaves benefit on the table — patients who could have been reached this cycle are not — so the agent optimizes DETERMINISTICALLY (a pure function of the candidates' costs + benefits + the capacity — no clock, no randomness — so the same request always yields the same plan) and hands the plan to a human. It COMPLEMENTS — it does not duplicate — the other care-coordination agents: distinct from the Caseload Balancing agent (which bin-packs a whole panel across managers), the Population Health agent (which ranks a panel by risk), and the Care Gap agent (which acts on a measure gap) — this selects a max-benefit subset of interventions under a capacity budget. It is a care-coordination agent on the PATIENT / CLINICAL plane, PHI-bearing (on the HIPAA-audit policy — the interventions reference patients), not a live-Claude agent. An allocation — all-scheduled / some-deferred — is a SAFE, honest output (not a block); every allocation requires care-lead review, and a deferred intervention is deferred to a later cycle, never denied — which is how a legitimate allocation is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: every selection must be sourced — each selected AND deferred intervention must trace to a submitted candidate (same id + cost + benefit; no fabricated intervention), every candidate must appear exactly once across selected ∪ deferred, and the tallies must add up — and a fabricated or dropped intervention is blocked (policy.outreach.selections-sourced), the sourced + completeness gate mirroring the Caseload Balancing Agent's assignment-complete and the Timeline Merge Agent's events-sourced; the allocation must be optimal + feasible — recomputing the knapsack DP over the candidates + capacity must reproduce the reported maximum benefit, and the selection must fit the capacity and equal the DP optimum — and a sub-optimal or over-capacity allocation is blocked (policy.outreach.allocation-optimal), the load-bearing correctness gate mirroring the Caseload Balancing Agent's capacity-respected and the Quality Shift Agent's cusum-consistent; and no outreach is launched autonomously — the agent PRIORITIZES, and a determination that launches the outreach, commits the plan, or books the interventions (autoScheduled:true) or skips care-lead review is blocked (policy.outreach.no-autonomous-schedule), mirroring the Caseload Balancing Agent's no-autonomous-assignment and the Care Gap Agent's human-review posture. Menopause-relevant: a menopause-care team with a fixed number of outreach hours this week and more high-value proactive touches (HRT titration calls, DEXA screening reminders, SDOH check-ins, education) than it can complete is exactly the max-benefit-within-capacity selection this knapsack produces — deferring, never denying, the rest to next cycle, and never dialing a patient on its own. The interventions are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified care-management / capacity-planning system; real capacity planning weighs clinical urgency, member consent, staffing mix, regulatory timeliness, and equity — not a single benefit score under one hours budget.
Agentforce Care-Transition Routing (Least-Burden Path)
Find the minimum-total-burden route through a weighted graph of care settings via Dijkstra's shortest path: path sourced + an optimal route + never an autonomous transition (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud care-transition-planning analog, and a DETERMINISTIC (no-Claude) care-coordination agent that, given a patient's current care SETTING (a start node), a goal setting, and a directed graph of PERMITTED transitions between settings each carrying a non-negative BURDEN weight (wait days + travel + cost proxy + risk), finds the MINIMUM-TOTAL-BURDEN path from start to goal — or reports the goal unreachable — reporting the path, the total burden, the hop count, and the disposition (route-found / no-route). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: UNLIKE the KPI Trend agent's LEAST-SQUARES LINEAR REGRESSION, the Outreach Prioritization agent's 0/1 KNAPSACK DYNAMIC PROGRAMMING, the Quality Shift agent's CUSUM CHANGE-POINT DETECTION, the Timeline Merge agent's K-WAY MERGE OF SORTED STREAMS, the Reportable Condition agent's RECURSIVE BOOLEAN EXPRESSION-TREE EVALUATION, the PCP Matching agent's TWO-SIDED STABLE MATCHING (Gale–Shapley), the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN — and, CRUCIALLY, UNLIKE the Care Pathway agent's TOPOLOGICAL ORDERING (which sequences ALL the required steps of ONE protocol into a dependency order — no weights, no source/target, no choosing among alternative routes), the Claim Lifecycle agent's BFS REACHABILITY (which finds the fewest-HOPS path across an UNWEIGHTED status state machine — edge count, not edge weight), and the Transitions of Care agent's MEDICATION RECONCILIATION (which reconciles meds across ONE encounter — it routes nothing) — the heart of this service is DIJKSTRA'S WEIGHTED SHORTEST PATH: the classic single-source shortest-path over a graph with non-negative edge weights, settling the nearest unsettled node and relaxing its out-edges (dist[v] = min(dist[v], dist[u] + w(u,v))) then reconstructing the minimum-total-weight path by walking predecessors back. A greedy or hand-picked route sends a patient the long way round — more waiting, more travel, more cost — so the agent optimizes DETERMINISTICALLY (a pure function of the graph's own edges + weights — no clock, no randomness — so the same graph always yields the same route) and hands the route to a human. It COMPLEMENTS — it does not duplicate — the other care-coordination agents: distinct from the Care Pathway agent (which topologically orders one protocol's steps), the Transitions of Care agent (medication reconciliation), and the Schedule Conflict agent (double-booking guard) — this finds the least-burden path through a weighted graph of care settings. It is a care-coordination agent on the PATIENT / CLINICAL plane, PHI-bearing (on the HIPAA-audit policy — the route is a patient's care plan), not a live-Claude agent. A route — route-found / no-route — is a SAFE, honest output (not a block); every route requires care-lead review, which is how a legitimate route is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: the reported path must be sourced — it must start at the start, end at the goal, every consecutive pair must be a submitted edge (no fabricated transition), and the totalCost must equal the sum of those edges' weights (an honest no-route carries an empty path) — and a fabricated edge or malformed path is blocked (policy.route.path-sourced), the sourced + well-formedness gate mirroring the Claim Lifecycle Agent's states-sourced and the Care Pathway Agent's steps-sourced; the route must be optimal — recomputing Dijkstra over the edges must reproduce the reported minimum total burden, the reachable flag, and the disposition — and a sub-optimal route or a false 'unreachable' is blocked (policy.route.route-optimal), the load-bearing correctness gate mirroring the Claim Lifecycle Agent's transition-consistent and the Outreach Agent's allocation-optimal; and no transition is initiated autonomously — the agent ROUTES on paper, and a determination that initiates the transition, books the setting, or moves the patient (autoRouted:true) or skips care-lead review is blocked (policy.route.no-autonomous-routing), mirroring the Care Gap Agent's human-review posture and the Outreach Agent's no-autonomous-schedule. Menopause-relevant: a midlife woman being discharged from a hospital stay who could go home directly, via a skilled-nursing stay, or through home-health — each transition carrying its own wait, travel, and cost burden — is exactly the least-total-burden routing this Dijkstra path produces for her care team, without ever booking a bed or moving her on its own. The settings + transitions are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified care-transition / discharge-planning system; real transition planning weighs clinical appropriateness, bed availability, payer authorization, patient preference, and caregiver capacity — not a single scalar burden per edge.
Agentforce Scheduling Conflict / Double-Booking Guard
Compute a resource's maximum conflict-free schedule + waitlist the collisions (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud scheduling-integrity analog, and a DETERMINISTIC (no-Claude) agent — a care-coordination service that takes a RESOURCE (a provider's clinic day, an infusion chair, an imaging machine) and a BATCH of requested appointment INTERVALS (each a start/end time for a patient) and computes the MAXIMUM CONFLICT-FREE SCHEDULE that fits without double-booking, WAITLISTING the requests that collide. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: UNLIKE the Caseload Balancing agent's GREEDY BIN-PACKING under a capacity constraint, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING + GAP DETECTION (that one MERGES overlapping intervals into continuous spans; THIS one SELECTS a maximum NON-overlapping subset), the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the OIG Exclusion agent's identity MATCHING, or the Audit Log Integrity agent's HASH CHAIN — and UNLIKE the date-deadline agents that add N days to a single date — the heart is GREEDY INTERVAL SELECTION (the classic activity-selection algorithm: sort the intervals by EARLIEST FINISH time and admit each one that doesn't overlap the last admitted, provably maximizing the count of non-overlapping appointments). Time is data: the schedule is a pure function of the requested intervals (ISO strings or epoch-ms, no real clock), so the same batch always yields the same schedule, and the greedy MAXIMIZES the number scheduled (two short appointments beat one long one) rather than 'first request wins'. It COMPLEMENTS — it does not duplicate — the Appointment Scheduling agent (which BOOKS a SINGLE slot against a provider calendar and never double-books THAT slot): this validates a WHOLE BATCH for a resource, computes the conflict-free schedule + the waitlist, and hands it to a scheduler — the double-booking guard for a day, not the booker of one appointment. It is a care-coordination service on the PATIENT / CLINICAL plane, PHI-bearing (on the HIPAA-audit policy — the requests reference the patients being scheduled), not a live-Claude agent. A schedule — fully conflict-free OR partial with a waitlist — is a SAFE, honest output (not a block); every schedule requires scheduler review — which is how a legitimate schedule is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: every scheduled / waitlisted appointment traces to a submitted request (same id, member, start, end) and every request is accounted for exactly once — a fabricated appointment, a dropped patient, or a double-count is blocked (policy.schedule.intervals-sourced), the sourced + completeness gate mirroring the Caseload Balancing Agent's assignment-complete; the scheduled set is conflict-free — the appointments are pairwise NON-overlapping, every waitlisted appointment genuinely overlaps the scheduled one it names, and the counts add up, and a double-booked resource or a request waitlisted while it actually fit is blocked (policy.schedule.conflict-free), the load-bearing correctness gate mirroring the Caseload Balancing Agent's capacity-respected and the Access Anomaly Agent's window-count-consistent; and no appointment is autonomously booked — the agent RECOMMENDS, and a schedule that books, cancels, or bumps an appointment (autoBooked:true) or skips scheduler review is blocked (policy.schedule.no-autonomous-booking), mirroring the Caseload Balancing Agent's no-autonomous-assignment and the Appointment Scheduling Agent's governance posture. The resource + intervals are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified scheduling system; real scheduling uses provider availability calendars, appointment-type durations, buffer / turnover times, and room / equipment constraints.
Agentforce Resource-Block Scheduling (Max-Value Non-Overlapping Selection)
Select the max-value non-overlapping set of competing requests for one contended resource (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud capacity-optimization analog, and a DETERMINISTIC (no-Claude) agent — a care-coordination service that takes a single SHARED SCARCE RESOURCE (an infusion chair, an OR block, a specialist's slot ladder, an imaging machine) and a batch of competing REQUESTS for it — each a time WINDOW with a priority WEIGHT (clinical value / acuity) — and selects the MAXIMUM-TOTAL-WEIGHT set of NON-OVERLAPPING requests the resource can honor, reporting the rest as CONTENDED (disposition all-scheduled / contended). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY it is NOT the sibling Scheduling Conflict agent's GREEDY INTERVAL SELECTION (which maximizes the COUNT of double-booking-free appointments, WEIGHTLESS) and NOT the Caseload Balancing agent's GREEDY BIN-PACKING under a capacity constraint or the Outreach Prioritization agent's 0/1 KNAPSACK DYNAMIC PROGRAMMING (items with a value + a cost packed under a single capacity budget, no time / overlap structure). It is also UNLIKE the Care Routing agent's DIJKSTRA'S WEIGHTED SHORTEST PATH, the Source Consensus agent's BOYER–MOORE MAJORITY VOTE, the Code Taxonomy agent's TRIE LONGEST-PREFIX MATCH, the KPI Trend agent's LEAST-SQUARES REGRESSION, the Quality Shift agent's CUSUM CHANGE-POINT DETECTION, the Timeline Merge agent's K-WAY MERGE, the PCP Matching agent's STABLE MATCHING, the Network Adequacy agent's GREAT-CIRCLE DISTANCE, the Household Composition agent's UNION-FIND, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, or the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM — the heart of this service is WEIGHTED INTERVAL SCHEDULING via DYNAMIC PROGRAMMING: sort the requests by end time, compute for each request i the latest earlier request p(i) that does NOT overlap it, fill dp[i] = max(dp[i-1], weight_i + dp[p(i)]), and backtrack to recover the max-weight compatible subset. Time is data: the windows are plain numbers and the selection is a pure function of the requests (no real clock, no randomness), so the same request always yields the same determination, and a greedy earliest-finish rule maximizes the COUNT of appointments but can leave clinical VALUE on the table (two short low-acuity blocks beat one long high-acuity block by count, but not by weight); the DP maximizes the total weight the resource actually delivers. It COMPLEMENTS — it does not duplicate — the Scheduling Conflict agent (which maximizes the number of double-booking-free appointments) and the Caseload Balancing agent (which bin-packs patients across care managers): this picks the max-VALUE non-overlapping set for one contended resource. It is a care-coordination service on the PATIENT / CLINICAL plane, PHI-bearing (on the HIPAA-audit policy — each request references the patient being scheduled), not a live-Claude agent. A schedule — all-scheduled or contended — is a SAFE, honest output (not a block); every schedule requires scheduler review — which is how a legitimate schedule is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: the selection must be sourced + feasible — every selected id a submitted request (no fabricated block, none double-counted), the selected windows pairwise NON-overlapping (the resource is never double-booked), the reported totalWeight equal to the selected sum, the counts adding up, and the disposition following — a fabricated block or a double-booked resource is blocked (policy.block-schedule.selection-sourced), the sourced + feasibility gate mirroring the Scheduling Conflict Agent's intervals-sourced + conflict-free and the Care Routing Agent's path-sourced; the selection must be optimal — re-running the weighted-interval DP over the requests must reproduce the reported totalWeight + disposition — and a sub-optimal schedule that leaves clinical value unbooked is blocked (policy.block-schedule.schedule-optimal), the load-bearing correctness gate mirroring the Care Routing Agent's route-optimal and the Outreach Prioritization Agent's selection-optimal; and no block is autonomously booked — the agent SELECTS and RECOMMENDS, and a schedule that books, bumps, or confirms a block (autoBooked:true) or skips scheduler review is blocked (policy.block-schedule.no-autonomous-booking), mirroring the Scheduling Conflict Agent's no-autonomous-booking and the Caseload Balancing Agent's no-autonomous-assignment. Menopause-relevant: a menopause-care program competing for a scarce infusion chair, an imaging slot, or a specialist block against higher- and lower-acuity requests is exactly the contention this DP resolves by delivered clinical value — without ever booking the block on its own. The resource + requests are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified scheduling / capacity system; real resource scheduling uses provider availability calendars, appointment-type durations, buffer / turnover times, room / equipment constraints, and staffing ratios.
Agentforce Discharge & Transitions of Care
Close-the-loop after a hospitalization / ED visit — medication reconciliation + scheduled follow-up + PCP handoff (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud transitions-of-care analog, and a DETERMINISTIC (no-Claude) agent. It runs the CLOSE-THE-LOOP workflow after a hospitalization / ED / observation encounter for a menopause/midlife patient — RECONCILING the discharge medication list against the pre-admit list (added / removed / dose-changed / unchanged, each tracing to an approved source), BOOKING the follow-up appointment (or drafting an appointment-request handoff to the Appointment Scheduling agent — never a text recommendation), pulling encounter-reason RED-FLAG warning signs from an illustrative catalog (vasomotor, cardiovascular, behavioral, musculoskeletal, general), emitting a TEACH-BACK checklist, and assembling the PCP HANDOFF summary. It is distinct from the Care Plan agent (active treatment planning), the Medication Adherence agent (nudge-only refill / adherence prompts), and the Referral Management agent (specialist triage) — this one closes the loop back to primary care after an acute event. The package is a pure function of the context + discharge date + provided lists (no randomness, no clock; timestamps are accepted as data), so the same context always yields the same reconciliation + red-flag list + teach-back checklist + PCP summary with a stable, documented ordering (sorted by medication id). THREE load-bearing honesty properties are governance-enforced: every medication on the reconciliation (pre-admit or discharge) must cite an approved medication source (pre-admit-verified, discharge-order, patient-verified, ehr-scanned-with-provenance) — a verbal / ad-hoc / undocumented source is blocked (policy.toc.reconciliation-source-integrity), the load-bearing safety guard against a fabricated medication slipping in; the agent may NEVER autonomously commit a medication change — every add / remove / dose-change is a clinician sign-off gated proposal, and an autonomous change is blocked (policy.toc.no-autonomous-medication-change); and the follow-up must be a SCHEDULED slot (slotStart + providerRef + modality) or explicitly awaiting-schedule (state:'awaiting-schedule', a safe interim answer with a handoff to Scheduling) — a package claiming a 'scheduled' or 'complete' follow-up without a real slot is blocked (policy.toc.follow-up-scheduled-not-recommended), the load-bearing 30-day-readmission guard against 'recommended' follow-ups masquerading as complete. It also honors the HIPAA-audit policy. The encounter categories, red-flag catalog, follow-up window (14 days), approved-source labels, and teach-back items are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified TOC schema, a real ADT / discharge system, or a clinical-guideline registry.
Agentforce Grievance & Appeals
Regulated intake: classify + route to a human queue + stamp a regulatory deadline (patient-facing) · Patient-facing
The Salesforce 'Agentforce for Health' / Health Cloud grievance-and-appeals analog, and a DETERMINISTIC (no-Claude) agent. It runs the INTAKE half of the regulated grievance-and-appeals process — classifying a member complaint or coverage-denial appeal (grievance-quality-of-service / grievance-billing-dispute / appeal-coverage-denial / appeal-expedited-coverage-denial), routing it to the correct human queue (member-services / clinical-review / compliance), and stamping a regulatory deadline that traces to the case-type catalog + received date (3d expedited, 30d standard is the illustrative shape). It is distinct from the Member Service / Billing agent (billing self-service, one-shot answers) and the Prior Authorization agent (pre-service utilization management) — this one runs the regulated grievance/appeal intake and routing workflow. The classification, routing, and deadline are pure functions of the intake keywords + coverage/service flags + received date (no randomness, no clock), so the same intake always yields the same case. THREE load-bearing honesty properties are governance-enforced: the agent may NEVER autonomously resolve, approve, or deny a case — every case is queued for human review, and every resolution is human-queue-action gated (policy.grievance.no-autonomous-resolution), a denial-appeal decision in particular needing a clinician-plus-compliance review; every case deadline must trace to the case-type catalog + received date and may NOT exceed the regulatory maximum — a silently-extended deadline is blocked (policy.grievance.deadline-integrity), the load-bearing regulatory-compliance guard against breaching Medicare Advantage Chapter 13 / state-insurance-code timelines; and the routing summary handed to the receiving human queue must be PHI-SAFE (structured only — memberRef + caseType + urgency + queue + deadlineDate, never free-text PHI) — a summary containing free-text PHI or an extra free-text key is blocked (policy.grievance.no-phi-in-routing-summary), so the routing payload can be delivered via lower-trust channels (Slack, email, ticketing) without leaking PHI. It also honors the HIPAA-audit policy. The case-type catalog, deadline windows, expedited-eligibility rules, and queue mapping are ILLUSTRATIVE synthetics, clearly labeled — NOT Medicare Advantage Chapter 13, a certified state-insurance-code process, or a real appeal-adjudication engine.
Agentforce Quality-Measure Attribution
Who counts on whose panel: attribute each patient to a provider + VBC contract for HEDIS scoring (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud attribution analog, and a DETERMINISTIC (no-Claude) agent. It PAIRS with the HEDIS & Quality Reporting agent — HEDIS computes the RATES (numerator / denominator / catalog-sourced exclusions per measure), THIS agent decides WHOSE PANEL each patient counts on. Getting attribution wrong is how value-based-care contracts get argued over: a provider gets credit (or blame) for a patient they never actually saw, or a contract's specifically-excluded population still shows up on the scorecard. It attributes each patient to a provider / clinic / VBC contract under a defined methodology from the catalog (plurality-of-visits, PCP-of-record, prospective Medicare Advantage, contract-defined window), honors the VBC contract's explicit exclusion terms (age band, network status, exclusion codes) so an excluded patient doesn't pollute the contract's scorecard, and applies a documented tie-break chain (most-recent-visit-wins → provider-ref-lexical-ascending) when the primary metric ties — no coin-flip, no gameable non-determinism. Rolls up per-provider counts (attributed / excluded / tie-broken) so downstream HEDIS scoring lands on the correct denominator. Attribution is a pure function of the visit history + contract terms + caller-provided asOfDate (no randomness, no clock; timestamps and windows are accepted as data), so the same context always yields the same attribution + rollup. It is distinct from the HEDIS Quality agent (rates), the Care Team agent (multi-disciplinary team assembly around a patient), and the Provider Credentialing agent (network integrity) — this one is quality ACCOUNTABILITY. THREE load-bearing honesty properties are governance-enforced: every attribution must trace to a defined methodology on the ATTRIBUTION_METHODOLOGIES catalog AND a defined contract on the VBC_CONTRACTS catalog — a bespoke / off-catalog rule is blocked (policy.attribution.methodology-catalog-sourced); every attribution must honor the VBC contract's explicit exclusion terms — a caller asserting excludedByContract:false on a patient the contract actually excludes is blocked (policy.attribution.no-conflicting-contract-terms), the guard against a contract's scorecard getting polluted; and every tie-break must be on the documented list (most-recent-visit-wins, provider-ref-lexical-ascending) — an undocumented / opaque / coin-flip tie-break is blocked (policy.attribution.tie-break-documented), turning tie-break resolution from gameable non-determinism into a fabric-verifiable invariant. It also honors the HIPAA-audit policy. The methodology catalog, contract catalog, tie-break rules, and refs are ILLUSTRATIVE synthetics, clearly labeled — NOT CMS Shared Savings Program attribution, an ACO REACH prospective assignment, an NCQA HEDIS attribution appendix, or a real payer's VBC contract terms.
Agentforce Complex Care Management (CCM)
Reimbursable time-tracking: CCM eligibility + monthly minutes + CPT-coded billing package (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud CCM analog, and a DETERMINISTIC (no-Claude) agent. Medicare pays a monthly per-beneficiary fee under CPT 99490 / 99491 (non-complex, 20-59min) and CPT 99487 / 99489 (complex, ≥60min with moderate/high complexity decision-making) — but only if the patient is ELIGIBLE (2+ chronic conditions from a catalog, Medicare-eligible age, coverage flag, consent on file), the TIME is documented per care-coordination activity type, and the BILLING PACKAGE is assembled and reviewed by a human quality team. This agent runs all three: it confirms eligibility (catalog-sourced conditions + age + coverage + consent), tracks per-activity monthly minutes against the CCM activity catalog (medication reconciliation, care-plan update, patient communication, referral follow-up, care-team coordination, patient education, resource navigation), maps the total to the CPT ladder, and assembles a billing package for HUMAN QUALITY-TEAM REVIEW — never autonomously submits a CMS claim. It is distinct from the Care Team & Case Management agent (multi-disciplinary team assembly around a patient) and the Care Plan agent (treatment content) — this one is the REIMBURSABLE TIME-TRACKING piece paired with them. Eligibility, time totals, and CPT selection are pure functions of the caller-provided context (no randomness, no clock), so the same context always yields the same eligibility + time summary + CPT selection + billing package. THREE load-bearing honesty properties are governance-enforced: every CCM eligibility claim must cite chronic conditions on the defined catalog — an off-catalog / fabricated condition is blocked (policy.ccm.eligibility-catalog-sourced); the agent NEVER autonomously submits a CMS claim — every package is human-quality-team-approval gated (policy.ccm.no-autonomous-billing), mirroring the HEDIS Agent's no-autonomous-submission and Prior Authorization Agent's no-autonomous-submission posture; and every logged minute must trace to a catalog activity AND the reported total must equal the sum of the entries — phantom-minute inflation (the classic CCM audit finding) or an off-catalog activity is blocked (policy.ccm.time-integrity). It also honors the HIPAA-audit policy. The chronic-condition catalog, CCM activity catalog, CPT thresholds (99490 non-complex 20-39min → 99491 non-complex 40-59min → 99487 complex 60-89min → 99489 complex ≥90min), and Medicare-eligibility flags are ILLUSTRATIVE synthetics, clearly labeled — NOT CMS Chapter 12 / MLN Booklet 909188 CCM billing, an actual CPT coding manual, or a live Medicare claim-submission system.
Agentforce Clinical Trial Payments & Stipends
IRB-schedule payment engine: participant stipends + travel + coordinator cosign (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud clinical-trial payments analog, and a DETERMINISTIC (no-Claude) agent. Pairs with the Clinical Trials Matching agent (which selects candidates) — this one handles the reimbursable/regulated PAYMENTS side. For each participant visit, it looks up the IRB-approved compensation schedule (trial + visit type + IRB approval ref), verifies research-payment informed consent is on file (Common Rule / 45 CFR 46 requirement), computes the stipend + travel reimbursement (per-mile rate capped at IRB max), and classifies as schedule-approved / pend-coordinator-review / blocked-no-consent. Non-standard payments (missed visit, out-of-range travel, extra procedure comp) route to the study coordinator for cosign. Menopause-relevant: an illustrative catalog with three menopause trials — vasomotor fezolinetant Phase 3, HRT transdermal Phase 4 observational, and bone-density bisphosphonate Phase 3. Payment computation is a pure function of the request + patient consent + schedule catalog + caller-provided asOfDate (no randomness, no clock), so the same context always yields the same decision + amounts + reason code, with a documented precedence (blocked-no-consent > pend-coordinator-review > schedule-approved) and stable rule ordering. THREE load-bearing honesty properties are governance-enforced: every payment must trace to the catalog (trial + visit type + rule + reason code) — an off-catalog ad-hoc payment is blocked (policy.trial-payments.schedule-catalog-sourced); the agent NEVER autonomously deviates from an IRB-approved schedule — every non-schedule-approved decision is DRAFTED for study-coordinator cosign (policy.trial-payments.no-autonomous-irb-deviation), because IRB deviations are a research-ethics failure that could invalidate the study (mirroring the Claims Adjudication Agent's no-autonomous-denial and Formulary Agent's no-autonomous-override); and no payment may be issued to a participant without research-payment informed consent — the safe answer is decision:'blocked-no-consent' with zero payment (policy.trial-payments.participant-consented), a 45 CFR 46 requirement. It also honors the HIPAA-audit policy. The trial catalog, IRB payment schedules, visit types, rules, and travel rate are ILLUSTRATIVE synthetics, clearly labeled — NOT IRBNet, WCG IRB, Advarra IRB, or an actual sponsor's payment protocol.
Agentforce Clinical List Reconciliation (Longest-Common-Subsequence Diff)
Reconcile two ordered clinical lists via the longest common subsequence: diff sourced + self-consistent + a recomputing LCS optimum + never an autonomous update (patient & clinical) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud list-reconciliation analog, and a DETERMINISTIC (no-Claude) agent — a care-coordination service that takes TWO ordered clinical lists for one record — a PRIOR list (the medication list at admission, the problem list at last visit, the care-plan steps as last agreed) and a CURRENT list (the same list now) — reconciles them by finding the LONGEST COMMON SUBSEQUENCE (the items PRESERVED in both, in order) and derives what was RETAINED, ADDED, and REMOVED (disposition lists-match / changes-present). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY it is NOT the Medication Name Safety agent's LEVENSHTEIN EDIT DISTANCE (which measures CHARACTER-level edit distance between two drug-name STRINGS to catch look-alike/sound-alike confusability) and NOT the Enrollment Reconciliation agent's KEYED SET RECONCILIATION (which joins two record sets on a key to find adds/drops/mismatches, order-independent). It is also UNLIKE the Timeline Merge agent's K-WAY MERGE (which interleaves already-sorted streams), the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING, the Peak-Window agent's KADANE MAXIMUM-SUBARRAY, the Care Routing agent's DIJKSTRA'S SHORTEST PATH, the Outreach agent's 0/1 KNAPSACK, the Source Consensus agent's BOYER–MOORE MAJORITY VOTE, the Code Taxonomy agent's TRIE LONGEST-PREFIX MATCH, the Household Composition agent's UNION-FIND, the Care Pathway agent's TOPOLOGICAL ORDERING, or the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM — the heart of this service is the LONGEST COMMON SUBSEQUENCE: a dynamic-programming table over the two ORDERED lists finds the longest subsequence common to both (the items kept, in their shared order), and its complement in each list is what was removed (prior only) and added (current only). Order matters — LCS respects the sequence — which is exactly what set reconciliation throws away. Time is data: the two lists are plain ordered tokens and the diff is a pure function of them (no real clock, no randomness), so the same request always yields the same diff. It COMPLEMENTS — it does not duplicate — the Medication Name Safety agent (which measures character-level edit distance between two drug-name strings) and the Enrollment Reconciliation agent (which joins two record sets on a key, order-independent): this DIFFS two ORDERED lists respecting sequence. It is a care-coordination service on the PATIENT / CLINICAL plane, PHI-bearing (on the HIPAA-audit policy — the lists are one patient's clinical record), not a live-Claude agent. A reconciliation — lists-match or changes-present — is a SAFE, honest output (not a block); every reconciliation requires clinician review — which is how a legitimate diff is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: the diff must be sourced + self-consistent — the reported retained list a genuine common subsequence of both lists (it appears in order within prior AND within current, nothing fabricated / reordered), the removed list exactly the prior items left unmatched (in order), the added list exactly the current items left unmatched (in order), the reported lcsLength matching the retained length, and the disposition following — a fabricated / reordered retained item or a mis-stated add/remove is blocked (policy.listdiff.diff-sourced), the sourced + self-consistency gate mirroring the SLA Worklist Agent's schedule-sourced and the Peak-Window Agent's window-sourced; the common subsequence must be the longest — re-running the LCS dynamic program must reproduce the reported lcsLength — and a shorter-than-optimal subsequence that over-reports change is blocked (policy.listdiff.lcs-optimal), the load-bearing correctness gate that recomputes the LCS length INDEPENDENT of the reported retained list (so a fabricated retained list that still reports the optimal length fails sourced only and a real-but-sub-optimal subsequence fails optimal only — the two gates are isolable), mirroring the SLA Worklist Agent's edf-ordered and the Care Routing Agent's route-optimal; and no reconciled list is autonomously written — the agent RECONCILES and RECOMMENDS, and a reconciliation that writes the list back, updates the chart, or starts/stops a medication (autoApplied:true) or skips clinician review is blocked (policy.listdiff.no-autonomous-update), mirroring the SLA Worklist Agent's no-autonomous-dispatch and the Resource Scheduling Agent's no-autonomous-booking. Menopause-relevant: reconciling a menopause patient's medication list between admission and discharge — surfacing that lisinopril was stopped and estradiol started while metformin, atorvastatin, and aspirin were preserved — is exactly the retained/added/removed diff this LCS reconciler produces for a clinician to confirm, without ever writing the chart on its own. The lists are an ILLUSTRATIVE synthetic, clearly labeled — NOT a certified medication-reconciliation system; real medication / problem-list reconciliation normalizes to RxNorm / SNOMED and accounts for dose, route, frequency, therapeutic equivalence, and clinical intent.
Agentforce Data-Sharing / TEFCA Interoperability
Cross-org PHI exchange: HIPAA §164.506 TPO gate + TEFCA participant verification + consent scopes (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud interoperability analog, and a DETERMINISTIC (no-Claude) agent. For each cross-organization PHI exchange request over TEFCA QHIN / Carequality / CommonWell / Direct Secure Messaging, it classifies the exchange purpose against a defined EXCHANGE_PURPOSES catalog (treatment / payment / operations / patient-request / public-health / research — with TPO purposes flagged for HIPAA §164.506's consent-not-required exception), verifies the counterparty is a Trusted Exchange Framework participant, applies the patient's data-sharing consent scopes from the Consent agent, and classifies as release-authorized / pend-purpose-verification / blocked-non-catalog-purpose / blocked-participant-unverified / blocked-consent-required-non-tpo with a specific reason code from an illustrative DS-100/101/200/300/400 catalog. Menopause-relevant: illustrative demo requests include a TPO treatment exchange over TEFCA, a research exchange over Carequality with an active research consent scope, an ONC-compliant patient right-of-access request over Direct Secure Messaging, and a hospice referral that requires transfer consent. Classification is a pure function of the request + catalog + caller-provided asOfDate (no randomness, no clock), so the same context always yields the same decision + primary reason, with a documented decision precedence (blocked-participant-unverified > blocked-non-catalog-purpose > blocked-consent-required-non-tpo > pend-purpose-verification > release-authorized) and stable rule-id ordering. THREE load-bearing honesty properties are governance-enforced: every exchange must trace to the EXCHANGE_PURPOSES + EXCHANGE_NETWORKS + DATA_SHARING_RULES + DATA_SHARING_REASON_CODES catalog — an off-catalog / bespoke exchange purpose is blocked (policy.data-sharing.purpose-catalog-sourced), because a bespoke purpose doesn't map to a HIPAA disclosure permission and would open the network to unauthorized aggregation (mirroring the Claims Adjudication Agent's edit-catalog-sourced, the FWA Agent's pattern-catalog-sourced, the Trial Payments Agent's schedule-catalog-sourced, the UR Agent's criteria-catalog-sourced, the Handoff Agent's SBAR-completeness, and the Adverse Event Reporting Agent's event-catalog-sourced posture); the agent NEVER autonomously releases PHI for a non-TPO purpose without an active consent scope — every non-TPO release without consent is DRAFTED for consent capture (policy.data-sharing.no-autonomous-non-tpo-release), because unauthorized non-TPO disclosures are the documented breach pattern behind the majority of OCR HIPAA enforcement actions (mirroring the Consent & Preferences Management Agent's no-scope-override, the Grievance & Appeals Agent's no-phi-in-routing-summary, and the Handoff Agent's transfer-consent posture); and the requester participant must be identity-attested — an unverified counterparty is blocked (policy.data-sharing.participant-verified), because under 45 CFR 171 + the TEFCA Common Agreement a QHIN / participant / sub-participant must be identity-attested before a cross-org exchange is authorized (mirroring the Provider Credentialing Agent's source-integrity, the Adverse Event Reporting Agent's reporter-verified, and the Handoff Agent's receiving-clinician-credentialed posture). Every non-release decision is requiresPrivacyOfficerCosign:true / cosigned:false. It also honors the HIPAA-audit policy. The exchange-network catalog, exchange-purpose catalog, rules, and reason codes are ILLUSTRATIVE synthetics, clearly labeled — NOT an actual TEFCA QHIN implementation, the Carequality Interoperability Framework, the CommonWell Health Alliance node stack, an ONC-certified data-sharing gateway, or a certified 45 CFR 171 information-blocking-safe release engine.
Agentforce Risk Adjustment & HCC Coding
Value-based-care documentation integrity: evidence-supported HCCs + RAF-style score + clinician-validated, never autonomously submitted (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud risk-adjustment analog, and a DETERMINISTIC (no-Claude) agent. It reviews a SINGLE patient's clinical context and identifies suspected / confirmed HIERARCHICAL CONDITION CATEGORIES (HCCs) for value-based-care risk adjustment — for each HCC in a synthetic HCC_CATALOG it reads the documented supporting-evidence signals, classifies as confirmed (a diagnosis code is on the claim AND every catalog evidence signal is documented) / suspected (evidence documented but no code — a coding gap) / unsupported (a code on the claim but the evidence not documented — over-coded), computes a RAF-style risk score as the sum of the confirmed HCCs' illustrative RAF weights, and flags the coding gaps + unsupported entries. It COMPLEMENTS, not duplicates, the HEDIS & Quality Reporting and Quality-Measure Attribution agents: those score quality MEASURES; this is risk-adjustment CONDITION coding. Menopause-relevant: the illustrative catalog spans the chronic-condition neighborhood a midlife panel carries (diabetes with / without complication, morbid obesity, CKD stage 3, major depression, COPD, CHF) including an osteoporosis-with-fragility-fracture category, and the demo patient surfaces two confirmed HCCs (RAF 0.739) plus a suspected major-depression coding gap. Assessment is a pure function of the clinical context (no randomness, no clock; any dates are data), so the same context always yields the same HCCs + RAF + gaps + flags, with stable catalog ordering. THREE load-bearing honesty properties are governance-enforced: every confirmed / suspected HCC must trace to the documented clinical evidence the catalog defines — a fabricated / unsupported code PRESENTED AS supported (an off-catalog HCC, or one whose evidence doesn't cover the catalog's required set) is blocked as upcoding (policy.riskadj.evidence-supported-coding), while a coding gap and an unsupported / over-coded flag are SAFE, honest OUTPUTS surfaced for a clinician to validate / correct (NOT blocks), mirroring the Care Gap Closure Agent's clinical-measure-sourced and the HEDIS Agent's measure-catalog-sourced integrity posture; every suspected code is a RECOMMENDATION requiring clinician validation before use — a suspected code finalized without it is blocked (policy.riskadj.clinician-validation-required); and the agent NEVER autonomously submits codes or adjusts a claim / RAF for reimbursement — an autonomous submission is blocked (policy.riskadj.no-autonomous-submission), mirroring the Prior Authorization Agent's clinician-approval + no-autonomous-submission and the HEDIS Agent's no-autonomous-submission posture. Every assessment is requiresClinicianValidation:true / submitted:false. It also honors the HIPAA-audit policy (it reviews patient clinical context). The HCC catalog, RAF weights, and supporting-evidence catalog are ILLUSTRATIVE synthetics, clearly labeled — NOT the certified CMS-HCC model, real RAF coefficients, an ICD-10 → HCC crosswalk, or a certified risk-adjustment / coding engine.
Agentforce Adverse Event Reporting (FDA MedWatch / VAERS analog)
Pharmacovigilance / device-safety reporting: MedWatch or VAERS drafts + regulatory-team cosign (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud pharmacovigilance / device-safety-reporting analog, and a DETERMINISTIC (no-Claude) agent. For each reported event (drug ADR, vaccine reaction, device malfunction, medication error, therapeutic failure) it classifies the event into the FDA MedWatch (3500 / 3500A) or VAERS channel, computes the 21-CFR-314.80 seriousness tier (non-serious / serious / life-threatening / death) from caller-provided outcome flags (resultedInDeath / isLifeThreatening / requiredHospitalization / causedDisability / causedBirthDefect / medicallyImportant), verifies reporter identity attestation (name / credentials / contact), and classifies as draft-medwatch / draft-vaers / blocked-non-catalog-event / blocked-reporter-unverified with a specific reason code from an illustrative AE-100/101/300/400 catalog. All drafts route to a regulatory-team queue for cosign. Menopause-relevant: illustrative demo events include a fezolinetant ADR (hospitalization → serious), an estradiol patch life-threatening reaction, a paroxetine non-serious side effect, and a seasonal-flu vaccine adverse reaction (routes to VAERS). Classification is a pure function of the request + catalog + caller-provided asOfDate (no randomness, no clock), so the same context always yields the same decision + channel + seriousness + primary reason, with a documented decision precedence (blocked-reporter-unverified > blocked-non-catalog-event > draft-medwatch / draft-vaers) and stable rule-id ordering. THREE load-bearing honesty properties are governance-enforced: every draft must trace to the ADVERSE_EVENT_TYPES + SERIOUSNESS_TIERS + ADVERSE_EVENT_RULES + ADVERSE_EVENT_REASON_CODES catalog — an off-catalog event or made-up severity is blocked (policy.adverse-event.event-catalog-sourced), because a bespoke event doesn't map to an FDA channel and poisons the pharmacovigilance signal, mirroring the Claims Adjudication Agent's edit-catalog-sourced, the FWA Agent's pattern-catalog-sourced, the Trial Payments Agent's schedule-catalog-sourced, the UR Agent's criteria-catalog-sourced, and the Handoff Agent's SBAR-completeness posture; the agent NEVER autonomously submits a MedWatch or VAERS report to the FDA — every draft is DRAFTED for regulatory-team cosign (policy.adverse-event.no-autonomous-submission), because FDA submissions are legally consequential under 21 CFR 314.80 with sponsor / manufacturer / clinician liability, mirroring the Claims Adjudication Agent's no-autonomous-denial, the UR Agent's no-autonomous-denial, the Formulary Agent's no-autonomous-override, the FWA Agent's no-autonomous-denial, the Trial Payments Agent's no-autonomous-irb-deviation, and the HEDIS Agent's no-autonomous-submission posture; and reporter identity must be attested — an anonymous or unverified reporter is not admissible under FDA reporting requirements and is blocked (policy.adverse-event.reporter-verified), because unverified reports poison the surveillance signal. Every draft decision is requiresRegulatoryTeamCosign:true / cosigned:false. It also honors the HIPAA-audit policy. The event-type catalog, seriousness tiers, rules, and reason codes are ILLUSTRATIVE synthetics, clearly labeled — NOT FDA MedWatch, VAERS, EudraVigilance, an actual sponsor's pharmacovigilance database, or a certified 21 CFR 314.80 submission pipeline.
Agentforce Care Coordination Handoff (Cross-Setting)
Joint-Commission-NPSG-2 SBAR for any cross-setting transition (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud cross-setting care-coordination analog, and a DETERMINISTIC (no-Claude) agent. Handles ANY cross-setting patient transition — hospital → SNF, SNF → home, home → hospice, ED → PCP, PCP → specialist, PCP → behavioral health — deterministically assembling the Joint-Commission-NPSG-2 SBAR (situation, background, assessment, recommendation), verifying the receiving clinician's credentialing status, confirming transfer consent is on file for transitions that share PHI with a new setting, and classifying as handoff-accepted / pend-sbar-incomplete / blocked-clinician-not-credentialed / blocked-no-consent with a specific reason code from an illustrative HO-100/200/300/400 catalog. Non-accepted cases route to sending-clinician-completion / credentialing-remediation / consent-capture. Distinct from the Discharge & Transitions of Care agent (which is POST-DISCHARGE hospital→home only, and owns the medication reconciliation) and the Referral Management agent (which drafts an outbound specialist referral): this is any CROSS-SETTING handoff — the SBAR assembly a receiving clinician needs to accept the patient. Menopause-relevant: an illustrative catalog of eight care settings (hospital inpatient, ED, SNF, home health, hospice, PCP clinic, specialist clinic, behavioral health clinic) and six transition types, each flagged for whether it typically requires documented transfer consent. Handoff evaluation is a pure function of the request + catalog + caller-provided asOfDate (no randomness, no clock), so the same context always yields the same decision + missing-sections list + primary reason, with a documented decision precedence (blocked-no-consent > blocked-clinician-not-credentialed > pend-sbar-incomplete > handoff-accepted) and stable rule-id ordering. THREE load-bearing honesty properties are governance-enforced: every accepted handoff must have all four SBAR sections populated — a handoff-accepted decision missing a section is blocked (policy.handoff.sbar-completeness), because the Joint Commission NPSG-2 requires standardized handoff communication and incomplete SBAR is a well-documented patient-safety failure; the receiving clinician must be current + unsanctioned — a handoff to an expired / incomplete / sanctioned clinician is blocked (policy.handoff.receiving-clinician-credentialed), because this is a ghost-network variant and a Section 1557 / due-process failure (mirroring the Provider Credentialing Agent's no-referral-to-expired-or-sanctioned posture); and transitions that share PHI with a new setting require documented transfer consent — a handoff without it is blocked (policy.handoff.consent-on-file), because sharing clinical information with a receiving setting without patient consent is a HIPAA disclosure failure (mirroring the Consent & Preferences Management Agent's consent-scope posture). Every accepted handoff is requiresReceivingClinicianCosign:true / cosigned:false — the agent NEVER autonomously accepts on behalf of the receiving clinician. It also honors the HIPAA-audit policy. The care-setting catalog, transition-type catalog, SBAR rule set, and reason codes are ILLUSTRATIVE synthetics, clearly labeled — NOT Epic Care Everywhere, Cerner CareAware, an actual health system's handoff protocol, or a certified Joint Commission / ONC-approved handoff module.
Chart Review Batch Partitioning / Linear Partition (Binary-Search-on-Answer)
Split an ordered clinical review worklist into k contiguous batches minimizing the busiest reviewer's load via linear partition: every partition sourced + self-consistent + a recomputing minimal-peak-load optimum + never an autonomous assignment (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud workload-partitioning analog, and a DETERMINISTIC (no-Claude) care-coordination agent — the worklist-partitioning layer of the care plane. Given a CHRONOLOGICALLY / PRIORITY-ORDERED clinical review worklist — each item carrying an effort WEIGHT (estimated review minutes / complexity points) — and a reviewer count k, it splits the worklist into k CONTIGUOUS batches (order preserved: no item jumps its neighbours) that MINIMIZE the busiest reviewer's load (the maximum batch weight), so a chart-review backlog can be balanced across reviewers as evenly as possible — reporting the batch boundaries, each batch's load, the minimal achievable peak load, the heaviest single item, the total weight, and the disposition (divisible / item-bound). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY it is NOT the Caseload Balancing agent's WORST-FIT-DECREASING BIN-PACKING (which reorders members by descending acuity and greedily drops each into the emptiest bin — an UNORDERED heuristic assignment) and NOT the Peak-Window agent's KADANE MAXIMUM-SUBARRAY (which finds one best contiguous window, not a k-way split). It is also UNLIKE the Huffman agent's OPTIMAL PREFIX CODING, the List Reconciliation agent's LONGEST COMMON SUBSEQUENCE, the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING, the Care Routing agent's DIJKSTRA'S SHORTEST PATH, the Outreach agent's 0/1 KNAPSACK, the PCP Matching agent's GALE–SHAPLEY STABLE MATCHING, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, or the Household Composition agent's UNION-FIND — the heart of this service is the LINEAR PARTITION PROBLEM solved by BINARY SEARCH ON THE ANSWER: the minimal feasible peak load lies between the single heaviest item and the total weight; a greedy feasibility test (how many contiguous batches does a candidate cap require?) is monotonic in the cap, so binary search converges on the exact minimal maximum, and an order-preserving DP reconstructs the split. Order matters — the split is CONTIGUOUS — which is exactly what unordered bin-packing throws away. The linear partition minimum is provably optimal — no contiguous k-way split achieves a smaller maximum — and the minimal peak load is the invariant this service reports and defends (a pure function of the weights + reviewer count — no clock, no randomness — so the same request always yields the same partition). It COMPLEMENTS — it does not duplicate — the Caseload Balancing agent (which greedily bin-packs unordered members into capacity-bounded panels): this splits an ORDERED worklist into contiguous batches, provably minimizing the peak. It is a care-coordination agent on the CARE plane, PHI-adjacent (on the HIPAA-audit policy — the item labels reference charts / encounters), not a live-Claude agent. A partition — divisible or item-bound — is a SAFE, honest output (not a block); every partition requires supervisor review — which is how a legitimate partition is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: the partition must be sourced + self-consistent — the batches, concatenated IN ORDER, reproducing EXACTLY the submitted items (same labels, weights, and sequence — nothing dropped / added / reordered / split), exactly batchCount non-empty contiguous batches, each batch's load equal to the sum of its items' weights, the reported maxBatchLoad the largest batch load, maxItemWeight and totalWeight honest, and the disposition following — a fabricated batch, a reordered cover, or an overstated load is blocked (policy.batchpartition.partition-sourced), the sourced + self-consistency gate mirroring the Huffman Agent's code-sourced and the List Reconciliation Agent's diff-sourced; the partition must be optimal — re-running the linear-partition solver (binary search on the answer) over the submitted weights + batchCount must reproduce the reported maxBatchLoad — and a sub-optimal split that overloads one reviewer is blocked (policy.batchpartition.load-optimal), the load-bearing correctness gate that recomputes the minimal peak load INDEPENDENT of the reported batches (so a fabricated cover that still reports the optimal peak load fails sourced only and a real-but-sub-optimal split fails optimal only — the two gates are isolable), mirroring the Huffman Agent's code-optimal and the Care Routing Agent's route-optimal; and no reviewer is autonomously assigned — the agent PARTITIONS and RECOMMENDS, and a partition that assigns a named reviewer to a batch or dispatches the worklist (autoAssigned:true) or skips supervisor review is blocked (policy.batchpartition.no-autonomous-assign), mirroring the Huffman Agent's no-autonomous-deploy and the SLA Worklist Agent's no-autonomous-dispatch. Menopause-relevant: a menopause-clinic chart-review backlog — annual visit notes, HRT titration reviews, lab-result reconciliations — priority-ordered and split evenly across the reviewing clinicians so no one reviewer is overloaded, is exactly the ordered worklist this linear partition balances, without ever assigning a named reviewer on its own. The weights are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified staffing / workforce-management system (real reviewer scheduling weighs skills, certifications, shift rules, breaks, and fatigue — not a bare contiguous split by an effort number).
Provider Network Build-Out / Minimum Spanning Tree (Kruskal's Algorithm)
Connect a set of care sites into one network at minimum total build cost via minimum spanning tree: every plan sourced + self-consistent + a recomputing minimal-cost optimum + never an autonomous provisioning (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud network-planning analog, and a DETERMINISTIC (no-Claude) care-coordination agent — the network build-out layer of the care plane. Given a set of care SITES (clinics / facilities / exchange endpoints) and candidate LINKS between them — each carrying a build COST (data-exchange setup cost, referral-corridor distance, integration effort) — it selects the MINIMUM-TOTAL-COST set of links that connects every site into ONE network (a minimum spanning tree), or reports that the candidate links cannot connect everything (a spanning FOREST) — reporting the chosen links, the minimum total build cost, the connected-component count, and the disposition (connected / partitioned). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of this service is MINIMUM SPANNING TREE construction via KRUSKAL'S ALGORITHM: sort the candidate links by ascending cost, then walk them cheapest-first, adding a link IFF it JOINS TWO DISTINCT COMPONENTS (a union-find cycle check rejects a link whose endpoints are already connected). Union-find here is a SUBROUTINE — the cycle test inside the greedy edge selection — NOT the computation itself: this is emphatically NOT the Household Composition agent's UNION-FIND CONNECTED-COMPONENT LABELING (which groups records into families by transitively merging match edges — it has NO edge weights, chooses NO minimum-cost subset, and reports components, not a tree). It is also DIFFERENT from the Care Routing agent's DIJKSTRA'S SHORTEST PATH (which minimizes the cost of ONE path between TWO nodes; MST minimizes the total cost to connect ALL nodes), the Batch Partition agent's LINEAR PARTITION, the Care Pathway agent's TOPOLOGICAL ORDERING, the Outreach agent's 0/1 KNAPSACK, the PCP Matching agent's GALE–SHAPLEY STABLE MATCHING, the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING, the Huffman agent's OPTIMAL PREFIX CODING, the List Reconciliation agent's LONGEST COMMON SUBSEQUENCE, the Timeline Merge agent's K-WAY MERGE, and the Peak-Window agent's KADANE MAXIMUM-SUBARRAY. Kruskal's tree is provably optimal — no spanning tree of the candidate links has a smaller total cost — and the minimum total build cost is the invariant this service reports and defends (a pure function of the sites + links — no clock, no randomness, ties broken by a stable link ordering — so the same request always yields the same plan). It COMPLEMENTS — it does not duplicate — the Care Routing agent (which finds the cheapest single path between two nodes): this finds the cheapest way to connect ALL the sites. It is a care-coordination agent on the CARE plane, PHI-adjacent (on the HIPAA-audit policy — the site labels reference clinics / facilities), not a live-Claude agent. A build plan — connected or partitioned — is a SAFE, honest output (not a block); a partitioned disposition is a LEGITIMATE FINDING (the candidate links really can't connect every site), and every plan requires architect review — which is how a legitimate plan is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: the tree must be sourced + self-consistent — each chosen link a SUBMITTED candidate (same endpoints, same cost — no fabricated link, no altered cost), the chosen links forming a FOREST (no cycle, verified by union-find), the reported totalCost equal to the sum of the chosen links' costs, the reported componentCount equal to the components the chosen links induce, siteCount and linkCount honest, and the disposition following — a fabricated link, an altered cost, or a cycle is blocked (policy.netbuildout.tree-sourced), the sourced + self-consistency gate mirroring the Batch Partition Agent's partition-sourced and the Huffman Agent's code-sourced; the tree must be cost-optimal — re-running Kruskal's algorithm over the submitted sites + links must reproduce the reported totalCost — and a sub-optimal tree that wastes build budget is blocked (policy.netbuildout.cost-optimal), the load-bearing correctness gate that recomputes the minimum total cost INDEPENDENT of the reported tree (so a fabricated tree that still reports the optimal total cost fails sourced only and a real-but-sub-optimal tree fails optimal only — the two gates are isolable), mirroring the Batch Partition Agent's load-optimal and the Care Routing Agent's route-optimal; and no link is autonomously provisioned — the agent PLANS and RECOMMENDS, and a plan that provisions, activates, or orders a link (autoProvisioned:true) or skips architect review is blocked (policy.netbuildout.no-autonomous-provision), mirroring the Batch Partition Agent's no-autonomous-assign and the Huffman Agent's no-autonomous-deploy. Menopause-relevant: standing up a connected menopause-care network — linking a hub clinic, satellite offices, a lab, and a telehealth endpoint at the least total integration cost so records and referrals flow across all of them — is exactly the connect-everything-cheaply problem this minimum spanning tree solves, without ever provisioning a link on its own. The costs are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified network-design system (real provider-network design weighs adequacy standards, contracted rates, capacity, redundancy, and regulatory requirements — not a bare minimum spanning tree over illustrative costs).
Referral Throughput / Maximum-Flow Network Capacity (Edmonds–Karp)
Compute the maximum referrals routable through a capacity network + the min-cut bottleneck via max-flow: every plan a sourced, conservation-consistent feasible flow + a recomputing maximum + never an autonomous routing (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud referral-capacity analog, and a DETERMINISTIC (no-Claude) care-coordination agent — the network-capacity layer of the care plane. Given a referral-routing NETWORK (a source feeding intake pools through capacity-limited specialty CHANNELS to a sink of appointment slots, each edge carrying a CAPACITY — referrals per period), it computes the MAXIMUM number of referrals routable end-to-end (the maximum flow) and identifies the BOTTLENECK (the minimum cut: the saturated edges whose total capacity caps throughput) — reporting the per-edge flows, the max-flow value, the total demand, the min-cut edges, and the disposition (unconstrained / bottlenecked). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of this service is the MAXIMUM-FLOW / MINIMUM-CUT computation via EDMONDS–KARP (the BFS-augmenting-path refinement of FORD–FULKERSON): repeatedly find a shortest augmenting path from source to sink in the residual graph, push the path's bottleneck residual capacity, and update residual capacities (including back-edges) until no augmenting path remains; the total pushed is the maximum flow, and the source-reachable side of the final residual graph induces the minimum cut. By the max-flow min-cut theorem the maximum flow EQUALS the minimum cut capacity — that equality is the invariant this service reports and defends (a pure function of the network — no clock, no randomness, augmenting paths chosen by a deterministic BFS — so the same request always yields the same plan). It is DIFFERENT from every other fabric pattern: NOT the Network Build-Out agent's MINIMUM SPANNING TREE (Kruskal's — connect all nodes at least cost; this pushes as much flow as possible through capacities), NOT the Care Routing agent's DIJKSTRA'S SHORTEST PATH (one cheapest path between two nodes; this saturates the whole network), NOT the PCP Matching agent's GALE–SHAPLEY STABLE MATCHING, NOT the Batch Partition agent's LINEAR PARTITION, NOT the Outreach agent's 0/1 KNAPSACK, NOT the Caseload Balancing agent's BIN-PACKING, NOT the Household Composition agent's UNION-FIND, NOT the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING, and NOT the Timeline Merge agent's K-WAY MERGE. It COMPLEMENTS — it does not duplicate — the Care Routing agent (cheapest single path) and the Network Build-Out agent (connect sites at least cost): this pushes maximum flow through the capacities. It is a care-coordination agent on the CARE plane, PHI-adjacent (on the HIPAA-audit policy — the node labels reference intake pools / specialties / slots), not a live-Claude agent. A throughput plan — unconstrained or bottlenecked — is a SAFE, honest output (not a block); a bottlenecked disposition is a LEGITIMATE FINDING (a min-cut really caps throughput below demand), and every plan requires coordinator review — which is how a legitimate plan is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: the flow must be sourced + conservation-consistent — every edge's flow between 0 and its SUBMITTED capacity (no fabricated edge, no over-capacity flow), flow CONSERVED at every node other than source and sink (in === out), the reported maxFlow equal to the net out of source AND net into sink, nodeCount and edgeCount honest — a fabricated edge, an over-capacity flow, or a conservation violation is blocked (policy.referralflow.flow-sourced), the sourced + self-consistency gate mirroring the Network Build-Out Agent's tree-sourced and the Batch Partition Agent's partition-sourced; the throughput must be optimal — re-running Edmonds–Karp over the submitted network must reproduce the reported maxFlow, with the min-cut capacity equal to it (max-flow min-cut theorem) — a sub-maximal or overstated throughput is blocked (policy.referralflow.throughput-optimal), the load-bearing correctness gate that recomputes the maximum flow INDEPENDENT of the reported flows (so a fabricated flow that still reports the optimal value fails sourced only and a real-but-sub-maximal flow fails optimal only — the two gates are isolable), mirroring the Network Build-Out Agent's cost-optimal and the Care Routing Agent's route-optimal; and no referral is autonomously routed — the agent PLANS and RECOMMENDS, and a plan that books, dispatches, or routes a referral (autoRouted:true) or skips coordinator review is blocked (policy.referralflow.no-autonomous-route), mirroring the Network Build-Out Agent's no-autonomous-provision and the Batch Partition Agent's no-autonomous-assign. Menopause-relevant: sizing a menopause-clinic referral network — how many intake referrals can actually reach a gynecology or endocrinology appointment slot given each channel's weekly capacity, and which saturated edge is the bottleneck to add capacity to — is exactly the maximum-flow / min-cut question this agent answers, without ever booking a referral on its own. The capacities are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified capacity-planning / scheduling system (real referral capacity planning weighs clinical urgency, specialty match, geography, payer networks, and provider preference — not a bare max-flow over illustrative capacities).
Member Contact Rate Limiting / Token-Bucket Throttle
Throttle a member's outbound contact attempts under a token-bucket frequency cap: every plan a sourced order-preserving replay + a re-simulating exact throttle + never an autonomous send (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud contact-governance analog, and a DETERMINISTIC (no-Claude) care-coordination agent — the contact-frequency layer of the care plane. Given a CHRONOLOGICALLY-ORDERED sequence of outbound contact ATTEMPTS to a member (calls / texts / emails from the various agents) and a token-bucket CONFIG (a burst CAPACITY of tokens and a continuous REFILL rate per hour), it replays the attempts through a TOKEN BUCKET to decide which contacts are PERMITTED and which are THROTTLED — so a member is never over-contacted past the configured frequency cap — reporting the per-attempt decisions, the permitted / throttled tallies, the final token level, and the disposition (within-limits / throttled). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of this service is the TOKEN-BUCKET RATE-LIMITING algorithm: the bucket holds up to `capacity` tokens and refills continuously at `refillPerHour` tokens/hour (never above capacity); each attempt, processed in time order, first accrues the refill earned since the previous attempt, then — if at least one whole token is available — consumes one token and is PERMITTED, otherwise is THROTTLED (no token consumed). It is NOT the Outreach Prioritization agent's 0/1 KNAPSACK (which selects WHICH members to contact under a capacity budget — this governs HOW OFTEN one member may be contacted over time), NOT the Access Anomaly agent's SLIDING-WINDOW COUNTING (a fixed-window event count with no continuous refill or token reservoir), NOT the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING, the Referral Throughput agent's MAX-FLOW, the Network Build-Out agent's MINIMUM SPANNING TREE, the Care Routing agent's DIJKSTRA'S SHORTEST PATH, or the Schedule Conflict agent's GREEDY INTERVAL SELECTION — it is token-bucket throttling, a continuously-refilling token reservoir with a burst cap. The per-attempt permit/throttle decision is provably determined by the bucket state, and the exact throttle decision is the invariant this service reports and defends (a pure function of the config + timestamps — no clock, no randomness — so the same request always yields the same plan). It COMPLEMENTS — it does not duplicate — the Outreach Prioritization agent (which selects whom to reach): this caps how often one member may be reached. It is a care-coordination agent on the CARE plane, PHI-adjacent (on the HIPAA-audit policy — the attempts reference member contacts), not a live-Claude agent. A throttle plan — within-limits or throttled — is a SAFE, honest output (not a block); a throttled disposition is a LEGITIMATE FINDING (some attempts really exceed the cap), and every plan requires coordinator review — which is how a legitimate plan is distinguished from a governance block. THREE load-bearing honesty properties are governance-enforced: the replay must be sourced + self-consistent — the decisions covering EXACTLY the submitted attempts (same ids + timestamps, in non-decreasing time order — none dropped / added / reordered / with a fabricated timestamp), the permitted / throttled tallies matching, attemptCount honest, and the disposition following — a fabricated attempt, a reordered replay, or a miscounted tally is blocked (policy.contactrate.replay-sourced), the sourced + self-consistency gate mirroring the Referral Throughput Agent's flow-sourced and the Batch Partition Agent's partition-sourced; the throttle must be policy-exact — re-running the token-bucket simulation over the submitted attempts + config must reproduce the exact permit / throttle decision for every attempt and the final token level — an over-throttled (denying a contact the bucket would allow) or under-throttled (permitting past the cap) decision is blocked (policy.contactrate.throttle-exact), the load-bearing correctness gate that re-simulates the bucket INDEPENDENT of the reported decisions (so a fabricated replay that still reports the right tally fails sourced only and a real-but-mis-simulated throttle fails exact only — the two gates are isolable), mirroring the Referral Throughput Agent's throughput-optimal and the Care Routing Agent's route-optimal; and no contact is autonomously sent or suppressed — the agent PLANS and RECOMMENDS, and a plan that sends a permitted contact or suppresses a throttled one (autoSent:true) or skips coordinator review is blocked (policy.contactrate.no-autonomous-send), mirroring the Referral Throughput Agent's no-autonomous-route and the Batch Partition Agent's no-autonomous-assign. Menopause-relevant: a newly-enrolled member getting simultaneous nudges from the intake, care-gap, adherence, and education agents in the same afternoon is exactly the over-contact risk this token bucket caps — permitting a healthy cadence and throttling the rest — without ever sending or suppressing a message on its own. The attempts are ILLUSTRATIVE synthetics, clearly labeled — NOT a certified communications-compliance system (real member-contact governance weighs TCPA / CAN-SPAM consent, quiet hours, channel-specific caps, member preferences, and campaign suppression lists — not a bare token bucket over illustrative timestamps).
