Configure Sentry Without Leaking PHI

Sentry is valuable because it collects context around a failure. In a healthcare application, that same context can include patient identity, appointment details, clinical responses, access tokens, or screen content. The goal is not to remove so much data that errors become impossible to debug. It is to make diagnostic context intentional.

For healthcare software development teams, the engineering target is a useful observability system that does not depend on raw patient identity, clinical text, appointment details, or production payloads to debug routine failures.

The right sequence is: confirm contractual coverage, define an allowed telemetry schema, prevent unsafe data from leaving the application, scrub again before storage, and test the complete route through alerts and integrations.

Confirm the BAA before PHI

Sentry publicly references BAA commitments, but the executed agreement controls. Confirm the legal entity, account, plan, service, region, subprocessors, retention, support, and incident terms. Verify whether errors, tracing, logs, profiling, replay, user feedback, attachments, AI features, and integrations are included.

If the BAA does not cover the intended data path, configure Sentry as a no-PHI service or do not deploy it in that workflow. A compliance page or HIPAA attestation is not a substitute for the agreement.

Inventory every capture surface

Do not rely on memory or SDK defaults. Trigger representative frontend, backend, mobile, API, and integration failures and inspect the stored event field by field.

Filter before transmission

Keep default PII collection disabled unless a documented requirement and agreement support it. Use the SDK's event and breadcrumb hooks to remove unsafe fields, normalize URLs, replace exception text with controlled error codes, and drop events that cannot be made safe.

Sentry.init({
  dsn: SENTRY_DSN,
  sendDefaultPii: false,
  beforeBreadcrumb: sanitizeBreadcrumb,
  beforeSend(event) {
    return sanitizeAndValidate(event);
  }
});

This is an architectural sketch, not a complete sanitizer. The implementation should use explicit allowlists for tags, contexts, request fields, and extra data. A recursive list of suspicious field names is useful as a backstop, but it cannot understand every clinical value or free-text message.

Normalize before you capture

Enable server-side scrubbing

Sentry provides organization and project controls for server-side data scrubbing, default sensitive-field rules, custom sensitive fields, advanced scrubbing rules, and IP-address removal. Configure these as a second layer so a missed SDK path is less likely to be stored.

Prefer removal over masking when the field has no diagnostic value. Add application-specific names such as patient, member, appointment, encounter, medical record, date of birth, phone, email, token, and authorization fields. Test nested objects and alternative naming conventions.

Scrubbing usually applies to new incoming events. It does not retroactively clean data already stored, so define a deletion and incident process for accidental collection.

Keep replay off until proven safe

Replay can expose rendered text, user input, DOM structure, network details, and interactions across a patient workflow. Default masking is helpful, but a healthcare review should not assume that every custom component, canvas, native view, third-party widget, or future screen is covered.

Start without replay. If the product case justifies it, confirm BAA scope, block sensitive routes and elements, mask text and inputs, block media, restrict network payload capture, lower sampling, restrict replay access, and test every patient-facing state. Repeat that review when the UI changes.

Observability features share the same risk

Logs can capture formatted objects, prompts, responses, SQL parameters, and support details. Traces can record URLs, operation names, database statements, and service metadata. Profiles and local-variable capture may expose memory values that were never intended as telemetry.

Use structured, categorical fields. Disable input and output recording for AI integrations unless the exact workflow has been reviewed. Avoid raw database statements and dynamic transaction names containing identifiers. Apply the same allowlist across errors, logs, traces, and alerts.

Review alerts, support, and integrations

A clean event can become an unsafe disclosure when an alert template includes the wrong field or an integration copies event data into email, chat, issue tracking, source control, or an AI assistant. Map each destination and confirm its agreement, access, retention, and purpose.

Keep notification content minimal. Link authorized staff back to Sentry instead of copying complete payloads into broader collaboration channels. Disable anonymous issue sharing and restrict who can view, export, delete, or administer production data.

Test the failure path, not just the happy path

1. Create synthetic test values resembling names, emails, phone numbers, record numbers, dates, tokens, and clinical free text.
2. Place them in URLs, headers, bodies, exception messages, breadcrumbs, logs, local variables, and replayed screens.
3. Trigger frontend, backend, mobile, network, validation, and unhandled failures.
4. Inspect the event received by Sentry, not only the application payload before sending.
5. Inspect alerts, exports, replays, issue-tracker entries, and chat notifications.
6. Verify deletion, access logs, retention, and incident escalation.
7. Repeat the suite when SDKs, integrations, schemas, or product features change.

Complete the review

Official references: Sentry SDK options, Sentry replay privacy, and Sentry organization privacy and scrubbing controls.