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.
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.
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 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.
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 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 Claims Adjudication Assistant
First-pass payer-side: catalog edits + reason codes + adjudicator cosign (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud claims-adjudication analog, and a DETERMINISTIC (no-Claude) agent. It runs the FIRST-PASS payer-side adjudication pipeline: for each submitted claim, apply payer-specific catalog edits (NCCI-PTP unbundling, LCD/NCD coverage, benefit-limit exhaustion, prior-auth missing, duplicate submission, out-of-network, timely-filing), classify as clean-pay / pend-clinical-review / pend-adjudicator-review / deny-drafted with a specific catalog reason code (illustrative CO-97 / CO-50 / CO-96 / CO-119 / CO-197 / CO-18 / CO-242 / CO-29 style), and route anything non-clean to a human. It NEVER autonomously finalizes a denial — every denial is DRAFTED for adjudicator cosign, because denial letters are legally consequential under CMS / ERISA / state insurance code. It is distinct from the Prior Authorization agent (pre-service utilization management), the Member Service / Billing agent (member-facing self-service), and the Grievance & Appeals agent (post-denial intake) — this one is the first-pass PAYER-SIDE adjudicator that decides which claims are clean-pay and which need human review. Adjudication is a pure function of the claim + member benefits + edit catalog + caller-provided asOfDate (no randomness, no clock), so the same context always yields the same decision + applied edits + reason code with a documented precedence (deny > pend-clinical > pend-adjudicator > clean-pay) and stable edit-id ordering. THREE load-bearing honesty properties are governance-enforced: every applied edit must trace to CLAIM_EDIT_CATALOG — a fabricated 'you owe us more' edit is blocked (policy.claims.edit-catalog-sourced); every denial requires adjudicator cosign (requiresAdjudicatorCosign:true, cosigned:false) — an autonomous cosign is blocked (policy.claims.no-autonomous-denial); and every non-clean-pay decision cites a specific catalog reason code with a documented rationale — a reasonless denial or pend is blocked (policy.claims.reason-code-integrity), because under Section 1557 / state insurance code / CMS a denial notice must state the specific reason. It also honors the HIPAA-audit policy. The edit catalog, reason-code catalog, and benefit-rule shape are ILLUSTRATIVE synthetics, clearly labeled — NOT CMS X12 837 claim spec, an NCCI PTP edit table, an LCD/NCD medical-necessity registry, or a real payer's benefit configuration.
Agentforce Formulary & Drug Utilization Review
First-pass drug review: tier + step-therapy + quantity + interactions + clinician cosign (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud formulary + DUR analog, and a DETERMINISTIC (no-Claude) agent. For a proposed medication, it looks up the payer's formulary tier, verifies step-therapy sequencing against DOCUMENTED prior-therapy history, applies quantity limits, and screens for drug-drug interactions — classifying as preferred-approved / pend-step-therapy / pend-quantity-limit / pend-interaction-review / pend-non-formulary with a specific catalog reason code (PF-100 preferred / PF-200 step / PF-201 quantity / PF-202 interaction / PF-203 non-formulary), and routing pends to a clinician (or pharmacist for interactions). It NEVER autonomously overrides a formulary exception — every non-preferred decision is DRAFTED for clinician cosign, because formulary exceptions are legally consequential under Medicare Advantage Chapter 6 + Part D (a documented rationale from a prescriber is required). Menopause-relevant because HRT tier placement varies significantly by plan (transdermal estradiol is often Tier 2 or non-formulary despite being clinically preferred for CVD-risk profiles). It is companion to the Prior Authorization agent (broader utilization management), the Medication Adherence agent (nudge-only refill), and the Claims Adjudication Assistant (post-service). Review is a pure function of the request + patient's prior-therapy + current-medication list + payer catalog + caller-provided asOfDate (no randomness, no clock), so the same context always yields the same decision + applied rules + reason code, with a documented decision precedence (pend-non-formulary > pend-step-therapy > pend-interaction-review > pend-quantity-limit > preferred-approved) and stable rule-id ordering. THREE load-bearing honesty properties are governance-enforced: every proposed drug + applied rule + reason code must trace to the defined catalogs (FORMULARY_DRUG_CATALOG, FORMULARY_RULE_CATALOG, FORMULARY_REASON_CODE_CATALOG) — a fabricated drug or 'we-just-said-no' rule is blocked (policy.formulary.catalog-sourced); step therapy must be honored with a DOCUMENTED prior-therapy trial — approving on undocumented / self-reported history is blocked (policy.formulary.step-therapy-honored), a common payer-audit finding; and every non-preferred-approved decision must be clinician-cosign gated (requiresClinicianCosign:true, cosigned:false) — an autonomous override is blocked (policy.formulary.no-autonomous-override), mirroring the Claims Adjudication Agent's no-autonomous-denial, the PA Agent's no-autonomous-submission, and the CCM Agent's no-autonomous-billing posture. It also honors the HIPAA-audit policy. The drug catalog, rule catalog, reason-code catalog, step-therapy chains, and interaction pairs are ILLUSTRATIVE synthetics, clearly labeled — NOT Medi-Span, First Databank, RxNorm, an actual payer's formulary file, or a certified DUR engine.
Agentforce Fraud, Waste & Abuse Detection
Pattern-based SIU screening: flag suspicious claims for human review, never autonomously deny (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud FWA analog, and a DETERMINISTIC (no-Claude) agent. Screens each submitted claim / prior-auth against the FWA pattern catalog (unbundling, upcoding, duplicate billing, quantity outliers, impossible-day billing, phantom services), classifies each hit by severity (low / medium / high), and routes to the SIU (Special Investigations Unit) for HUMAN review — priority queue on high, standard queue on medium. It NEVER autonomously denies a claim, opens an investigation, or freezes payment; every flagged claim goes to human review with due-process protections (Section 1557 / state insurance code / notice + appeal rights). Distinct from the Claims Adjudication Assistant (which AUTO-denies routine mechanical edits like NCCI-PTP unbundling with a specific catalog reason code): FWA is about SUSPICIOUS PATTERNS that need investigation, not mechanical catalog edits. Screening is a pure function of the claim + provider peer-baseline + pattern catalog + caller-provided asOfDate (no randomness, no clock), so the same context always yields the same flags + primary pattern + severity with a documented severity precedence (high > medium > low; lexical tie-break by pattern-id) and stable pattern ordering. THREE load-bearing honesty properties are governance-enforced: every applied flag must trace to FWA_PATTERNS — a fabricated 'we-just-don't-like-this-provider' flag or category-of-one pattern is blocked (policy.fwa.pattern-catalog-sourced); every report is requiresSiuReview:true (when flagged) / investigationOpened:false / paymentFrozen:false — an autonomous denial / investigation / freeze is blocked (policy.fwa.no-autonomous-denial), because denying on suspicion is a due-process failure; and the detection engine may NOT score on protected-class attributes (race, ethnicity, religion, national origin, disability status, gender identity, sexual orientation, marital status) or provider-demographic proxies — a factor list including any of those is blocked (policy.fwa.no-protected-class-factors), a documented compliance failure in real payer FWA systems that has led to consent decrees. Mirrors the Population Health Agent's no-protected-class-factors posture. It also honors the HIPAA-audit policy. The pattern catalog, peer baselines, and severity thresholds are ILLUSTRATIVE synthetics, clearly labeled — NOT SAS Detection and Investigation, LexisNexis Provider Insight, an actual payer SIU rule set, or a certified fraud-detection engine.
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 Utilization Review (MCG/InterQual analog)
Pre-service medical-necessity screen: catalog criteria + clinician-cosign + SLA integrity (care coordination) · Care coordination
The Salesforce 'Agentforce for Health' / Health Cloud utilization-management analog, and a DETERMINISTIC (no-Claude) agent. Runs the PRE-SERVICE medical-necessity screen for a proposed procedure or inpatient admission against catalog medical-necessity criteria sets (MCG-analog / InterQual-analog) — for each service type it reads the caller's per-criterion evidence flags, evaluates a set of catalog rules, and classifies as approves-meets-criteria / pend-for-clinical-review / require-peer-to-peer / blocked-non-covered with a specific reason code from an illustrative UR-100/200/201/300 catalog. Non-approved cases route to a clinical reviewer or peer-to-peer with a catalog-sourced SLA deadline (standard 72h, urgent 24h, concurrent-review 24h). Menopause-relevant: an illustrative service-type catalog with DEXA bone-density (age gate + interval), hysterectomy for abnormal uterine bleeding (bleed pattern + first-line failure + malignancy workup), inpatient medical admission (severity + intensity), sleep-study for OSA workup, and a cosmetic non-covered example. Distinct from the Prior Authorization agent (which ASSEMBLES a clinician-gated PA package for a specific payer) and the Claims Adjudication Assistant (which runs POST-SERVICE mechanical edits): this is the first-pass PRE-SERVICE medical-necessity engine. Review is a pure function of the request + criteria evidence + urgency + catalog + caller-provided asOfDate (no randomness, no clock), so the same context always yields the same decision + criteria-met/missing lists + primary reason + SLA deadline, with a documented decision precedence (blocked-non-covered > require-peer-to-peer > pend-for-clinical-review > approves-meets-criteria) and stable rule-id ordering. THREE load-bearing honesty properties are governance-enforced: every applied criterion + rule + reason code must trace to the catalog — a fabricated 'we-just-decided-you-don't-need-it' criterion or off-catalog service is blocked (policy.ur.criteria-catalog-sourced), mirroring Claims Adjudication's edit-catalog-sourced, Formulary's catalog-sourced, FWA's pattern-catalog-sourced, and Trial Payments' schedule-catalog-sourced posture; the agent NEVER autonomously denies — every non-approved decision is DRAFTED for clinician cosign (policy.ur.no-autonomous-denial), because UR denial letters are legally consequential under Medicare Advantage / state utilization-review-agent codes with notice + due-process rights (denying medical necessity on the agent's own authority is a Section 1557 / state-code violation), mirroring the Claims Adjudication Agent's no-autonomous-denial, the Formulary Agent's no-autonomous-override, the FWA Agent's no-autonomous-denial, and the Trial Payments Agent's no-autonomous-irb-deviation posture; and every case SLA deadline must trace to catalog urgency + received asOfDate — a silently-extended deadline is blocked (policy.ur.sla-integrity), because silently extending a UR deadline breaches Medicare Advantage Chapter 4 / state UR-agent timelines, mirroring the Grievance & Appeals Agent's deadline-integrity posture. It also honors the HIPAA-audit policy. The service-type catalog, criteria sets, rules, reason codes, and SLA windows are ILLUSTRATIVE synthetics, clearly labeled — NOT MCG (Milliman Care Guidelines / Indicia), InterQual, an actual payer's UR rule set, or a certified medical-necessity engine.
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 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.
