Alerts Don’t Fail at Delivery. They Fail at Identity

Alerts Don’t Fail at Delivery. They Fail at Identity.‍

An alert that confirms a discharge but cannot tell you where it happened, who owns it, or where follow-up should go isn’t a corner case. It’s what happens when systems move events, not resolve identity. This is an identity failure, not delivery.‍

The identity problem.‍

Alerts don’t resolve identity. They pass through available information—sometimes an organization, sometimes a facility, sometimes a partial location—with no standardization or context to make them usable.

In practice, identity is fragmented across weak inputs: system names, partial addresses, inconsistent location fields, and variably populated identifiers. One identifier can represent dozens or hundreds of sites. Provider identity follows the same pattern—often missing, inconsistent, or tied to local identifiers that don’t resolve to a single accountable clinician.

Facility detail often degrades or is lost in exchange. What looks like a valid identifier is often a grouping construct, not a physical location or actionable owner.

The result is not just missing data, it is unusable. For example, an alert may say ‘Memorial Health,’ a system with 11 campuses, without specifying which facility discharged the patient. Routing stalls. Or it may list ‘Dr. Smith’ with no NPI—a provider who practices across multiple locations and shares a common name. Ownership is ambiguous and accountability is delayed.

This is measurable. With this enrichment, facility location match rate skyrockets from approximately 20% to over 67%, provider identification fill rate more than doubles from 38% to 83%, and the median number of facilities represented by a single organization identifier is approximately 105. Without it, you're routing blind.

Before a care team can act, they need to know where the event happened and who owns it. When identity cannot answer those two questions, every downstream step—assignment, follow-up, escalation—degrades.

Normalization is not optional.‍

Raw clinical data is structurally inconsistent. Facility and provider identity are encoded in free-text names, partial addresses, variable taxonomies, and sparsely populated identifiers. The same entity can appear dozens of different ways across CCDAs and ADTs.

In practice, identity is not a field. It is inferred. “Memorial Health,” “Memorial Hospital,” and a street address may all refer to the same facility—or not. Without standardization, these cannot be reliably matched or deduplicated.

Normalization resolves this by transforming noisy inputs into canonical entities. Names are standardized, addresses are parsed and geocoded, taxonomies are aligned, and duplicate representations are collapsed. The output is a single, stable representation of a facility or provider.

Without this step, entity resolution fails. Ambiguity persists, and every downstream system inherits it.

Normalization does not make the data complete. It makes it coherent.

Particle Health treats identity as a first-class system, not a cleanup step. We perform deterministic and probabilistic entity resolution across facilities and providers—standardizing names, normalizing and geocoding addresses, reconciling identifiers, and collapsing duplicates into canonical entities. Organization identifiers are decomposed into actual sites of care; provider records are resolved to a single accountable clinician with verified NPIs and affiliations. This produces a stable identity layer that downstream systems can route against, measure, and trust.

Enrichment is what makes it actionable.‍

Normalization makes identity coherent. Enrichment makes it usable at the moment a decision is required.

A care manager does not need an alert. They need to know where the event happened, who owns it, and what needs to happen next. Enrichment attaches that context—resolving the exact facility, identifying the accountable provider or team, and filling missing identifiers required for routing.

Enrichment adds the structure the source data lacks: facility → organization → system hierarchy, provider affiliations, specialties, ownership, and standardized identifiers. External data fills gaps—linking providers to organizations, assigning NPIs, and validating locations. A facility becomes a routable endpoint. A provider becomes attributable and accountable.

This is where alerts become operational.

• A discharge is routed to the correct facility and owner
• A provider is attributable and accountable
• An event is assigned, measured, and followed up

Enrichment also expands the detectable alert. Our Signal products’ cross-source linkage surfaces encounters, relationships, and attributes no single feed contains, collapsing fragmented data into a complete, longitudinal view.

Without enrichment, the alert creates work. With it, the alert is the work.

Context is what makes it usable.‍

Even when identity is resolved, the next question is immediate: what actually happened?

Most alerts don’t answer that. They indicate that an event occurred, but not why. The reason for admission, medication changes, procedures performed, and risk factors that determine urgency are often missing, delayed, or buried in documents that arrive hours or days later.

In practice, this forces the same pattern: the alert is routed correctly, but the care team still has to reconstruct the clinical picture. They open charts, chase documents, and manually interpret what should already be available. The alert is there, but not in a form that supports immediate action.

Context completes the event.

• Identity answers where and who
• Context answers what happened and how urgent it is

Without it, even perfectly routed alerts degrade into investigation. With it, the next step is clear at the moment the alert arrives.

Identity → Context → Action
These are not independent layers. Identity determines whether context can be attached. Context determines whether action is possible.

If identity is ambiguous, context attaches incorrectly or not at all. If context is incomplete, routing degrades into manual work. By the time action is required, the system has already failed.

Alerts do not fail at delivery. They fail upstream—when identity is not resolved and context cannot be constructed.

The alert arrives. The work starts from zero.