Every healthcare organization running patient records in Salesforce eventually gets asked one question, and it never arrives at a convenient time: who looked at this patient's record, and when? Sometimes it's a patient exercising their rights. Sometimes it's a compliance officer investigating a complaint, an employee departure, or a suspected case of curiosity-browsing. Out of the box, Salesforce cannot answer it — and most teams don't discover that until the question is already on the table.
At Goldfinch Health, a national surgical-recovery care program and a long-running GAT client, we answered it with one Platform Event, one invisible Lightning Web Component, and one custom object. Six months into production, that trail holds 34,860 access events. This article walks through the architecture, the real numbers, and — because this is a compliance topic — an unusually blunt section on what this build does not prove.
Salesforce logs what changed — not what was seen
Salesforce's native audit surfaces are all write-oriented. Field History Tracking records changes to tracked fields. The Setup Audit Trail records configuration changes. Login History tells you who signed in and from where. All useful; none of them will tell you that a coordinator opened a specific patient's record at 11:42 on a Tuesday and looked at it without changing anything.
For most industries that gap is a shrug. In healthcare it's the whole question. The HIPAA Security Rule's audit-controls standard expects covered entities to implement mechanisms that record activity in systems containing electronic PHI — and "activity" includes reading. Inappropriate viewing of records, not editing, is the classic insider incident.
The options landscape: Shield vs. a targeted build
Salesforce's first-party answer is Shield Event Monitoring. It's genuinely the more complete instrument: it captures Lightning page views, API queries, report exports, and list-view access across the org, with event data that's harder for an insider to quietly alter. If your risk profile demands forensic coverage of every access path, buy it — we'll tell you that in the first call.
The honest tradeoffs run in both directions. Shield is an add-on priced against your Salesforce contract, which is a material line item for a mid-size provider; the raw event data typically needs additional tooling or storage decisions before an auditor can use it; and you're buying coverage for hundreds of event types when the question your compliance team actually fields is narrow: who opened this patient's record page?
For that specific question, a targeted build gives you a first-class, reportable answer inside the org itself — rows you can report on, dashboard, and hand to an auditor without exporting log files. It took us days, not a procurement cycle. The rest of this article is that build.
The build: an invisible LWC that announces record opens
The instrumentation layer is a Lightning Web Component with no UI. It sits on the patient record page like any other component — placed once in Lightning App Builder — and renders nothing. Its only job is lifecycle awareness:
- When the component connects — meaning a user has opened the record page — it publishes a
Record_Access_Event__ePlatform Event carrying the record Id, the running user, an OPEN action, and a timestamp. - When the component disconnects — the user navigated away or closed the tab — it publishes the matching CLOSE event.
The architectural decision that matters here is publishing an event instead of writing a record directly from the component. A read path should never block on a write: record pages open in bursts, users tab through patients quickly, and the last thing you want is page-load latency or DML contention caused by your own audit layer. The Platform Event bus absorbs the burst; persistence happens asynchronously on the other side. It's the same shock-absorber pattern we use for EHR webhooks and voice-AI intake in behavioral health, applied to user behavior instead of vendor traffic.
Persistence and reporting: rows an auditor can actually use
On the subscribing side, a trigger on the Platform Event persists each event as a Record_Access__c row: who, which record, which action, when. Both the publisher and the trigger handler ship with test coverage — in an org where the data is patient records, tests on the audit trail are part of the audit trail.
Because the trail is an ordinary custom object, everything downstream is standard Salesforce reporting — no log parsing, no external SIEM required for the base case:
- Per-patient history: every access to a given record, in order — the exact report a complaint investigation starts with.
- Per-user activity: access counts by user by period, the fastest way to spot an outlier.
- Pattern views: after-hours access, spikes against a user's own baseline, access to records outside a user's usual caseload.
When compliance asks the question, the answer is a filtered report, not an engineering ticket.
What it captures in practice: 34,860 events
Numbers from our own org queries, January through July 2026: the trail has logged 34,860 access events across 51 active users — roughly 190 record-access events every day, captured without anyone thinking about it. That's the point of instrumentation: the evidence accumulates whether or not anyone remembers the compliance requirement that week.
Context makes the number more useful. This is the second Platform-Event architecture we authored in the same org — the first powers the real-time patient chat through which more than 100,000 patient messages have been managed — inside a build that spans 166 authored Apex classes and 59 Lightning Web Components supporting 15,314 surgeries to date. The access-audit trail wasn't a bolt-on; it's one organ in an event-driven system that was already structured this way.
What this does NOT prove for a HIPAA audit
This section exists because compliance content that only sells the upside is how organizations end up with false confidence. Read it before you build or buy anything.
- It only sees the page it's placed on. The component logs opens of the Lightning record pages where it's deployed. It does not see API reads, SOQL from integrations, report exports, list views, Data Loader extractions, or any surface without the component. If your threat model includes those paths, this build alone is not your answer — that's Shield Event Monitoring territory.
- It is not tamper-proof.
Record_Access__cis a custom object; an administrator with sufficient permissions could delete rows. You can narrow that risk — restrict object permissions, alert on deletions, archive externally — but a determined admin is outside this design's protection boundary. - CLOSE events are best-effort. Browsers killed mid-session don't always fire a clean disconnect, so session-duration math derived from OPEN/CLOSE pairs is approximate. Treat durations as signal, not testimony.
- A log is not a compliance program. HIPAA's audit-controls expectation includes procedures to regularly review activity, retention decisions, and a documented response process. A trail nobody reads proves very little in an investigation — and can prove the wrong thing.
This is also why we describe our healthcare work as HIPAA-conscious, never HIPAA-compliant. Compliance belongs to the covered entity: your BAA with Salesforce, your policies, your training, your review cadence. What we control is whether the system produces the evidence your program needs — and whether the limits of that evidence are documented honestly, the way this section just did.
Extending the pattern
Because the trail is ordinary Salesforce data, extensions are incremental rather than architectural:
- Session duration: pair OPEN and CLOSE events per user per record to approximate time-on-record — useful for spotting both drive-by browsing and unusually long dwell times.
- Anomaly flags: a scheduled job comparing each user's access volume against their own baseline, flagging after-hours activity or sudden spikes for human review.
- Review cadence artifacts: a subscribed monthly report to the compliance owner — turning the log into the documented review procedure auditors ask about.
- Retention and archival: a scheduled archive path once volume warrants it, with the retention window set by your policies rather than by storage limits.
- Aggregate-only discipline: the audit rows carry references and counts, never clinical content. Every number in this article is a count, not a patient — the reporting layer should hold itself to the same rule.
Frequently asked questions
Can Salesforce track who viewed a record out of the box?
Not meaningfully. Field History Tracking and the Setup Audit Trail log changes, and Login History logs sessions — but none of them record read access. To know who opened a specific record you need either Shield Event Monitoring or a custom instrumentation layer like the one described here.
Is this approach HIPAA compliant?
No tool or build is HIPAA compliant on its own — compliance is a property of your organization's program: your BAA with Salesforce, your policies, workforce training, and documented review procedures. This build is HIPAA-conscious engineering: it gives your compliance program the access evidence Salesforce doesn't produce natively. Your compliance officer and counsel decide whether the whole program meets the audit-controls requirement.
Should we just buy Shield Event Monitoring instead?
If you need forensic coverage of every access path — API queries, report exports, list views, Data Loader — Shield Event Monitoring is the more complete instrument, and for some risk profiles it's the right spend. It's priced as an add-on tied to your Salesforce contract, which is material for a small or mid-size org. The custom pattern covers the specific question most healthcare teams are actually asked — who opened this patient's record page — for a few days of build effort.
Does publishing an event on every record open slow the page down?
No perceptible impact in production. The component renders nothing and publishes a lightweight Platform Event asynchronously — the record page never waits on a database write. The subscribing trigger does its insert on the event bus side, decoupled from the user's session.
Does this pattern only apply to healthcare?
The same build answers 'who viewed this record' for any regulated or sensitive context: financial accounts, legal matters, HR cases, M&A pipelines. The event and the audit object are generic; only the compliance framing changes.
Get an honest read on your access-audit posture
GAT Solutions builds revenue-generating systems for healthcare, accounting, and SaaS companies — fast, flawlessly, and powered by AI. We're AI-augmented go-to-market consultants who treat compliance evidence as an engineering deliverable, not a checkbox.
If nobody in your org can answer "who viewed this patient record?" today, start with a Salesforce audit — we'll map what your org can and cannot prove, and show you whether the fix is a Shield purchase or a week of engineering. See the rest of our healthcare work on the Salesforce for healthcare page.