Pool 1
Conditions
Clinical conditions the patient has been diagnosed with — t1d, t2d, hypertension, cardiac_event_history, cancer_diagnosis, etc. Sourced from the buyer's clinical data. Used to gate disease-specific message variants.
Audience safety
Filter, never flag.
Seven audience tags keep every cue in-bounds. Ineligible members are filtered silently — never warned, never shamed.
Display mode never touches PHI — no BAA required. Start in 5 minutes.
One filtered cue
- template
- relapse-prevention
- audience_inclusion
- substance_use_optin
delivered to 41 312 enrolled
271 filtered silently
Audience safety
Filter, not flag.
Every message in every template carries two audience tag sets: includes (must match the patient for the message to be eligible) and excludes (any match blocks the message). Tags are organized into four pools so a buyer's roster mapping does not get tangled with their condition coding. The cue endpoint runs the filter before it returns; messages that fail are dropped, never sent, never flagged for review.
What "filter, not flag" means in practice
A message that fails its audience check is not returned from the cue endpoint, not enqueued for review, not surfaced in any partner dashboard. The next eligible message in the template is selected and returned instead. Failure is silent, durable, and logged in the safety audit trail — never user-facing.
The contrast with "flag" is intentional. Health-content products that flag messages for human review add latency, a queue, and a person looking at PHI. Signal does none of that. The template authors decide what is appropriate at authoring-time; the cue endpoint enforces those decisions at call-time; humans never see the filtered candidates.
Try it · synthetic patient
Toggle a patient's tags below. The 6 message variants light up eligible or filtered live — the same logic that runs inside the cue endpoint.
Conditions
Topics
Family
Population
2
eligible ·
4
filtered
Pool 2
Topics
Patient-opted-in topic categories — mental_health_optin, sex_repro_optin, substance_use_optin, lgbtq_optin, etc. Sourced from explicit consent. Used to gate sensitive content classes.
Pool 3
Family
Relationship and life-stage context — caregiver_role, parent_pediatric, postpartum_optin, partner_disclosure. Used by relapse-prevention and family-system templates to address the right person.
Pool 4
Population
Demographic and population-health stratification — veteran_optin, occupation_class, language_pref. Used for population-tailored messages without mixing demographic data into condition records.
§2 · Display vs Deliver
Filtering runs in both modes. PHI handling does not.
Every cue is gated against the audience filter regardless of mode. What differs between Display and Deliver is whether real PHI crosses Uphealth's boundary, whether a BAA is required, and who actually sends the resulting message.
Display
Buyer renders · default
Deliver
Uphealth sends · opt-in
Who sends the message
Your application
Uphealth (email + push)
PHI permitted
No — mock patient_ref only
Yes — real PHI under BAA
BAA required
Not required
Required before keys activate
Tier
Discovery and above
PMPM and above
API scopes granted
create · cue · read · metadata
+ stream:deliver
Onboarding speed
20 minutes (self-serve)
Same-day (manual review + BAA)
Webhook required
Optional (your channel reports its own engagement)
Required (engagement reported back to you)
Receptivity score
Returned — your routing logic uses it
Returned + composed with Reach for routing
§3 · Governance roles
Four roles. One audit trail.
Audience-safety decisions are not a single team's call. The split below is the canonical role-based separation — one person at the partner can hold multiple roles, but the audit trail records the role exercised on each change, not just the user.
-
1
At authoring time
Template authors
Uphealth's content team. Decide which include/exclude audience tags gate each message at authoring time. Cannot read partner roster data; their decisions are per-message, not per-patient. Changes write a content audit entry — message_id, tag set, author, effective_at.
-
2
At roster-config time
Partner admins
Buyer-side. Configure roster ingestion — which fields in the clinical record map to which audience-tag pools (Conditions, Topics, Family, Population). Roster changes write a partner audit entry; the data itself stays on the partner's side in Display mode or under BAA in Deliver mode.
-
3
At opt-in time
Patients
Opt in or out of sensitive Topics-pool tags via the partner's settings UI (mental_health_optin, sex_repro_optin, substance_use_optin, lgbtq_optin). Conditions-pool tags are clinical-data-derived, not patient-toggled. Patient changes propagate to Signal within the next cue cycle.
-
4
At review time
Uphealth compliance
Quarterly review of the safety audit trail under BAA-bound access. Reads aggregate filter rates per tag pool — not per-patient data. Reviewers can flag template-level patterns (a tag fires more than expected) but cannot see which patients matched which tags.
§4 · Crisis pathway
Crisis content never just sends.
Messages tagged with mental_health_optin and any suicide-related sub-tag carry a separate routing contract from the rest of the catalog. They never reach a patient without a paired resource. The pathway differs slightly by mode but the destination is the same: 988 (Suicide & Crisis Lifeline) plus the buyer's configured EAP where one exists.
Display mode
You render the resource
Deliver mode
Uphealth routes through EAP first
What the cue returns
The cue carries the per-cue audience-safety verdict (the safety field) — not footer markup. The 988 / Crisis Text Line / SAMHSA crisis-resource footer is a per-template contract: the template catalog flags it as crisis_footer_rendered_on: every_cue, and your application surfaces it on every rendered cue. Your configured EAP details are applied at partner provisioning time, not returned per cue.
For a crisis-tagged cue, Uphealth routes through the partner's configured EAP first (if one exists in the partner record), with 988 as a universal fallback. The patient receives the message plus the routing resources inline.
Who sends
Your application renders the cue body plus the crisis-resource footer. Signal does not enforce the render; the per-cue safety verdict and the cue's audience tags are persisted on the event, so the audit trail shows the cue was issued under the every-cue footer contract.
Uphealth — the routing-choice + send-time is logged to the safety audit trail. EAP-configured partners get the EAP route; the rest get the 988 universal fallback.
Audit captures
The per-cue safety verdict + the cue's audience tags. Your render-side telemetry stays with you.
Full routing trail — EAP attempted, EAP success/failure, 988 fallback fired, message send-time.
What's not in the pathway
Signal is not a crisis-intervention product. The pathway routes content + resources; it does not detect crises, does not screen patient replies for risk, and does not page on-call clinicians. Buyers building crisis-detection products on top of Signal should layer their own detection + escalation on the response stream.
Buyers that have not configured an EAP see only the 988 universal fallback. Configuring an EAP is part of Deliver-mode onboarding; Discovery-tier buyers in Display mode can configure one at any time via /talk-to-sales.
Filter as care
Sensitive topics carry the highest stakes. Filtering — not flagging — keeps care private.