Investor brief · Salesforce Data 360
Pause-Health.ai grounds its Care Router agent in a Salesforce Data 360 federated patient view — calculated insights, longitudinal observations, cohort comparisons, and identity resolution computed continuously across JupyterHealth, DBDP, and the customer's EHR-of-record without ever moving PHI.
Why Data 360
Data 360 queries the customer's existing data plane in place — JupyterHealth FHIR, Snowflake / Databricks warehouses, DBDP feature stores, and the Epic Health Cloud — via the Federation + Iceberg connectors. No PHI bulk-ingestion into Salesforce; nothing for the customer's data team to migrate.
Identity Resolution reconciles the same patient across wearable signups, EHR records, prior intake sessions, and claims. The Care Router decides over a single unified patient, not whichever fragment happened to be in the current API response.
Materialized features computed continuously across the federated sources: 30-day HRV z-score, vasomotor burden index, sleep disruption fraction, days since last MSCP-credentialed contact. These become routing inputs without us writing a feature pipeline.
Population segments (e.g. 'late perimenopause with rising HRV variability', 'postmenopausal bleeding cohort') activate to Agentforce, the Agent Fabric, and Health Cloud. Pause can reach the right patients before they ever open an intake session.
How it composes with the rest of the stack
MuleSoft remains the integration plane (system-to-system, writes, transforms). Data 360 is the unified read plane on top: 'what do we know about this patient, right now, across every source we federate into?' The two compose cleanly.
Data 360 appears in the Agent Fabric registry alongside Agentforce, the Care Router, the Pause MCP server, and MuleSoft. Its grounding queries emit trace spans. Its identity resolution emits trace spans. Every call is auditable in the same pane.
Three Data 360-specific policies enforced today: zero-copy-federation-only (no PHI bulk-ingest), consent-required-before-grounding (the Care Router cannot read without an active 'ai-decision-support' consent), segment-activation-allowlist (downstream channels must be approved). Standard HIPAA audit policy applies to every grounding call.
When Agentforce captures the intake, the handoff endpoint asks Data 360 to resolve the partial identity to a unified patient id. That unified id flows through the rest of the trace — the Care Router, the MCP server, every downstream span carries it.
The four-span trace
Every multi-agent task now produces this trace shape. Open /demo/agent-fabric, run a test case, and watch the four spans appear with parent/child correlation intact.
Agentforce intake.completePatient finishes the intake. Captured fields, red-flag screen, and severity are recorded as the parent span.
Data 360 identity.resolveThe handoff endpoint asks Data 360 to resolve the partial identity. Returns the unified patient id and the IR confidence score.
Data 360 grounding.federated-queryFederated read against the Data 360 unified patient view: calculated insights, longitudinal observations, cohort comparison, last MSCP contact. The full grounding payload attaches to the A2A handoff.
Care Router a2a.tasks/sendThe Care Router receives BOTH the intake AND the Data 360 grounding as data parts of one A2A message. Decision rationale cites which insights it used; span attributes record cohort name and insights cited.
Touch the architecture
Every Data 360 mock is reachable as a real HTTP endpoint right now. The Care Router reads grounding from one of them on every intake.
Prototype vs production
| Aspect | Prototype today | Customer deployment |
|---|---|---|
| Federated query target | In-memory mocked patient store (frontend/lib/data-360.ts) returning a clinically realistic shape. | Real Salesforce Data 360 Federated Query API against the customer's JupyterHealth FHIR store, DBDP feature warehouse, and EHR-of-record. |
| Identity Resolution | Stub that always returns the demo unified id with high confidence. | Configurable Data 360 IR ruleset across federated sources, returning ranked match candidates with confidence scores. |
| Calculated insights | Deterministic fixtures (30-day HRV z-score, vasomotor burden index, sleep disruption, days since MSCP contact). | Calculated Insights jobs on Data 360, recomputed nightly (or streaming) over federated sources. |
| Segments | Four hand-curated segments returned by /api/data-360/segments. | Population segments authored in the Data 360 console by the customer's clinical-data team, with activation routes configured per segment. |
| Consent enforcement | Consent ledger included on the federated record; policy advertised but not blocking the prototype. | Hard-enforced by the Data 360 consent service. Care Router grounding calls without an active 'ai-decision-support' consent are rejected with a redaction notice. |
Phased plan
Today
Data 360 registered on the Agent Fabric. Mocked federated grounding + IR + segments endpoints. Care Router reads grounding from the A2A message and cites insights in its rationale. Trace shows the full four-span flow.
2–3 weeks
Stand up a Salesforce Data 360 trial org. Federate one real source (JupyterHealth FHIR test instance) via the Iceberg connector. Author the four calculated insights as real Data 360 jobs. Wire Pause's handoff endpoint to the real Federated Query API; flip a single env var to switch the prototype off the mocks.
4–6 weeks with customer
Federate the customer's EHR-of-record (Epic / Cerner / Athena) and their DBDP feature warehouse. Author the customer's IR ruleset. Wire consent enforcement to the customer's existing consent ledger. Roll the Care Router onto real-customer grounding.
Ongoing
Population segments activate to Agentforce for proactive outreach ("women in your cohort who saw an MSCP within 14 days had 71% symptom resolution"). Health Cloud cards on the patient timeline. Marketing Cloud for educational journeys.
Why investors should care
Read deeper