I've been in that room. That specific combination of facts: encrypted fields, scheduled audit, satisfied security team. I've watched it create a kind of shared confidence that is technically correct and practically incomplete at the same time. And when the gap surfaces later, the conversation is never comfortable.
This is about Platform Events and PHI. About a gap in how most healthcare architects think about Shield Platform Encryption. About why it keeps slipping through design reviews that are otherwise thorough and careful.
I'm not writing this as a gotcha. I'm writing this because I've seen the pattern enough times to know it deserves a name and a hard look.
The Mental Model That Gets You In Trouble
Shield Platform Encryption does what it says: encrypts field values at rest. Standard fields, custom fields, files: they sit encrypted on disk, decrypt in-memory for authorized users, re-encrypt on write. This is real protection. It holds up under scrutiny.
The mental model most architects carry is something like: Shield is enabled, so our PHI is encrypted. And for data that lives in standard Salesforce objects (Contacts, Cases, custom objects), this is largely true. The field value hits the disk encrypted, comes back decrypted when you need it, goes down encrypted again.
Here's where the model breaks: it stops being true at a hard architectural boundary. Platform Events sit on the other side of that boundary. And most people don't know where the boundary is until they've already crossed it.
What Platform Events Actually Are
Platform Events are Salesforce's pub/sub layer. You publish, subscribers pick up. In healthcare orgs they show up everywhere: patient status updates, appointment confirmations, lab result notifications, care coordination handoffs between systems. They're genuinely elegant. They integrate cleanly with the Flow Builder and Apex ecosystem and decouple systems in ways that make the architecture cleaner.
The thing that trips people up (and I mean architects who know Salesforce well) is that Platform Events are not records in the traditional sense. They don't live in the object store the way a Contact or a Case does. They live in an event bus. They flow through a serialization and pub/sub delivery mechanism that is architecturally separate from the Shield-encrypted field store.
When you put PHI in a Platform Event field, that data does not go through Shield's encryption boundary. It serializes into the event payload and moves through the event bus unencrypted by Shield.
That's the gap. The encryption you checked the box for is not encrypting this data. Shield is enabled, and this PHI is not encrypted by Shield. Both are true simultaneously.
A Design That Has This Problem
Picture a healthcare organization running Health Cloud, Shield enabled, HIPAA BAA in place. They've encrypted Patient Name, Date of Birth, the MRN field. The security team reviewed it. Everyone is satisfied.
Now: when a patient is admitted, a Flow triggers and publishes a Platform Event. The event carries the patient's name, their room number, their attending physician, an acuity flag. A subscriber Flow picks this up, updates a scheduling object, sends an internal notification.
This design is architecturally correct by Salesforce patterns. But the PHI in that event payload is transiting through the event bus without Shield's protection. It may be surfacing in Event Monitoring logs. If Event Bus Replay is configured, that data is persisting in a replay window Shield is not covering.
The checkbox that made everyone feel safe isn't covering this data path. It never was.
Why Architecture Reviews Miss This
The PHI inventory process in a compliance review: identify objects with PHI, verify Shield encryption, check FLS and sharing rules, verify the BAA. Reasonable. Catches most things.
Platform Events don't look like PHI storage. They're events. Transient. The reviewer's model says they're not in the domain Shield covers, and technically, that's true. That's exactly what creates the exposure. The mental model that is technically accurate is the one that produces the gap.
There's a compounding factor: Platform Events in healthcare Salesforce often arrive late in the architecture. The PHI inventory happened when the core objects were designed. Three months later, someone added a Platform Event to solve an immediate integration problem. Nobody went back to the inventory. Nobody asked whether PHI was now touching a component the original assessment didn't cover.
Three Questions For Any Platform Event Flow
The first: what data fields are on this event, and does any of it map to a HIPAA identifier? Actually map the fields against the 18 Safe Harbor identifiers. Names, dates, geographic data, account numbers, device identifiers. If any are in the payload, keep going.
The second: where does this event go after it's published? Trace every downstream path. The event bus replay window is an exposure point. Debug logs during development are an exposure point. Event Monitoring logs are an exposure point. Trace the full path, not just the happy path.
The third: does this PHI actually need to be in the event payload? In my experience, often no. The event can carry a record ID, a reference to the encrypted record in the Shield-protected object store. The subscriber queries the record directly, FLS enforced, Shield covering the field read. The PHI never enters the event bus.
The Fix Space
The record-ID-as-reference pattern is the cleanest path. Publish only the Salesforce record ID in the event. Subscribers query the record through Shield-protected, FLS-enforced paths. The event bus stays clean. The encryption model you thought you had actually applies.
When the event needs to carry actual data values, you need to be explicit that this data is leaving the Shield boundary. That might mean application-layer encryption of specific field values. It might mean a different integration pattern entirely. It might mean accepting different security requirements for this flow and addressing them directly.
What it can't mean is leaving it as-is because the checkbox was checked.
What Else Shield Doesn't Cover
Platform Events are the most common case of this class of problem. They're not the only one.
Shield has a documented coverage model. Other Salesforce features sit outside it in ways that matter in healthcare. None of this is obscured. Salesforce publishes its encryption considerations. But reading documentation isn't the same as knowing where your architecture crosses a boundary.
Shield protects the field store. Every PHI data flow in your architecture either passes through the field store or around it. The compliance posture you have is only as real as your ability to answer that question for every path, including the paths added six months after the original review.
The interesting work isn't the checklist. It's building the instinct for where the boundaries actually are, so you catch the next Platform Event before it's in production, not after.