Where PHI Actually Tends to Leak Into Logs
Understanding the specific, common places PHI ends up in logs unintentionally is the first step toward actually preventing it, since most exposure happens through predictable, avoidable patterns rather than deliberate logging of sensitive data.
Error Messages That Include Full Message Content
When a transformer script throws an exception, many default error-handling patterns log the entire message content alongside the error for debugging convenience, inadvertently writing PHI directly into the log file every time that error occurs.
Debug-Level Logging Left Enabled in Production
Debug-level logging often captures far more detail than standard operational logging, including raw message content during normal processing, and leaving this enabled in production significantly increases how much PHI ends up logged unnecessarily.
Stack Traces That Embed Variable Values
Stack traces from custom script errors can include the actual variable values in play at the time of failure, which may directly contain patient names, identifiers, or clinical data depending on what the failing script was processing.
Third-Party Library Logging You Don't Directly Control
Libraries or extensions used within custom transformer code may have their own logging behavior that captures data you didn't explicitly choose to log, requiring awareness of what those dependencies actually write to logs by default.
Practical Scrubbing and Masking Strategies
Once you understand where PHI tends to leak, specific scrubbing and masking techniques can prevent it from reaching log files in the first place, without sacrificing the diagnostic value logs provide.
Redacting Specific Fields Before Logging Errors
Build error-handling logic that explicitly redacts or omits known PHI fields, like patient name or medical record number, before writing any error context to the log, rather than logging the raw message unfiltered. See our error handling patterns guide for the broader pattern.
Logging Message Metadata Instead of Full Content
Where possible, log identifying metadata like message control ID and channel name rather than full message content, giving you enough context to investigate an issue without directly exposing the underlying PHI in the log itself.
Using Pattern-Based Masking for Known PHI Formats
For cases where full redaction isn't practical, pattern-based masking that obscures likely PHI formats, like partially masking what appears to be a Social Security number, reduces exposure while still preserving some diagnostic value.
Reviewing Custom Scripts Specifically for Logging Behavior
Audit custom transformer and filter scripts specifically for any logging statements they contain, since a well-intentioned developer debugging statement can easily become a permanent, overlooked source of PHI exposure in production logs.
Log-Level Discipline That Prevents This From Recurring
Beyond one-time scrubbing fixes, establishing genuine ongoing discipline around log levels and review prevents PHI exposure from creeping back into your logs over time as channels are modified.
Keeping Production Log Levels at an Appropriate Baseline
Set production log levels to capture what's genuinely needed for operational monitoring without the excessive detail debug-level logging provides, reserving that more verbose level specifically for temporary, deliberate troubleshooting sessions.
Returning Debug Logging to Normal After Troubleshooting
If you temporarily raise log verbosity to diagnose a specific issue, treat returning it to normal afterward as a required step, not an optional cleanup task that might get forgotten once the immediate problem is resolved.
Reviewing Logging Configuration During Code Review
Include logging behavior as part of your regular code review process for new or modified transformer scripts, catching PHI-exposing logging statements before they ever reach a production deployment in the first place.
Auditing Existing Logs Periodically for PHI Exposure
Periodically sample existing log files to check for unintended PHI exposure, since this catches gaps in logging discipline that may have developed gradually rather than waiting to discover them during an actual compliance audit.
Suspect PHI is currently sitting in your logs?
Start with a free Mirth Health Check to review your logging configuration, send us the exact error if you're troubleshooting something specific, or check pricing for our support plans.