Is Mirth Connect's default logging sufficient for HIPAA audit control requirements?

Default operational logging is designed for technical troubleshooting and may not fully satisfy audit control requirements on its own, so review your specific configuration against what genuine audit logging needs to capture for compliance purposes.

What's the difference between operational logs and audit logs?

Operational logs focus on technical troubleshooting, like error diagnosis, while audit logs specifically need to answer who accessed PHI, when, and what they did, serving a distinct compliance rather than technical purpose.

How long should audit logs be retained?

This depends on your organization's specific compliance requirements and any applicable state regulations, so define a documented retention period rather than leaving it undefined, and confirm your specific obligations don't exceed a generic industry assumption.

Should failed access attempts be logged along with successful ones?

Yes, failed attempts, particularly repeated ones, can indicate an attempted unauthorized access, so capturing both successful and failed attempts gives a more complete picture than tracking only confirmed, successful system access.

Can audit logs be stored in the same location as operational logs?

They can be, but consider whether your specific compliance needs warrant separate access controls or retention policies for audit logs specifically, given their distinct sensitivity and purpose compared to general operational logging.

Who should have access to review audit logs?

Access should be restricted to those with a genuine compliance or security oversight responsibility, since audit logs themselves reveal sensitive access patterns and shouldn't be broadly accessible to the same audience as general system logs.

Audit Logging for HL7 Interfaces: What's Required

Audit Logging for HL7 Interfaces: What's Actually Required

Audit logging for HL7 interfaces exists to satisfy HIPAA's Security Rule audit control requirement, which expects covered entities to implement mechanisms recording and examining activity in systems containing PHI, and an integration engine processing HL7 messages is squarely within that scope given how much PHI flows through it. This isn't the same as Mirth's general operational logging aimed at troubleshooting technical failures — audit logging specifically needs to answer who accessed what PHI, when, and what they did with it, in a way that holds up during a compliance review.

Below is what audit logging actually needs to capture, how it differs from standard operational logs, and what tamper-evidence and retention expectations look like in practice. If you're unsure your current logging meets audit requirements, our free Mirth Health Check can review your setup directly — part of the Mirth Connect support work we do for US healthcare teams.

What Audit Logging Actually Needs to Capture

The Security Rule's audit control requirement is intentionally broad on specifics, but a few core elements consistently need to be captured for audit logging to genuinely serve its intended compliance purpose.

Who Accessed the System and When

Audit logs need to record which specific user accessed the integration engine, and when, giving you a genuine record of who was interacting with the system at any given point rather than only tracking system-level events.

What Specific Action Was Taken

Beyond simply recording access, audit logs should capture what action was actually taken, whether viewing a message, modifying a channel configuration, or exporting data, distinguishing between meaningfully different levels of system interaction.

Which Specific Data or Resource Was Involved

Where feasible, audit logs should identify which specific message, channel, or resource was accessed or modified, giving investigators enough specificity to trace a particular incident back to the exact data involved.

Successful and Failed Access Attempts Both

Audit logging should capture both successful and failed access attempts, since failed attempts, particularly repeated ones, can be an important indicator of an attempted unauthorized access that succeeded logging alone wouldn't reveal.

How Audit Logging Differs From Standard Operational Logs

Conflating audit logging with Mirth's general operational logging is a common mistake, since the two serve genuinely different purposes and often need to be configured and protected differently.

Operational Logs Focus on Technical Troubleshooting

Standard operational logs, like mirth.log, are designed to help diagnose technical failures in message processing, capturing error details and processing flow rather than specifically tracking user access to PHI for compliance purposes. See our log file locations guide for what these actually contain.

Audit Logs Focus on Who Did What to PHI

Audit logs specifically need to answer compliance-relevant questions about user access and actions, which may require configuration beyond Mirth's default operational logging to genuinely satisfy audit control requirements.

The Two Log Types May Need Separate Retention Policies

Since audit logs serve a distinct compliance purpose, they may warrant a different, often longer, retention policy than operational logs kept primarily for short-term technical troubleshooting needs.

Access to Audit Logs Themselves Needs Its Own Controls

Audit logs are themselves sensitive, since they can reveal patterns of PHI access, so access to the audit logs specifically needs its own access controls, separate from general operational log access within your team.

Tamper-Evidence and Retention in Practice

Beyond simply capturing the right information, audit logs need specific protections ensuring their integrity and appropriate retention over time to genuinely serve their compliance function.

Protecting Audit Logs From Unauthorized Modification

Audit logs should be protected against unauthorized modification or deletion, since a log that can be quietly altered after the fact provides little genuine assurance during an investigation or compliance review of past activity.

Considering Write-Once or Append-Only Storage

Where feasible, storing audit logs in a write-once or append-only format adds a meaningful layer of tamper-evidence, making it considerably harder for anyone, including a malicious insider, to quietly alter historical audit records.

Retaining Audit Logs for a Defined, Documented Period

Define and document a specific retention period for audit logs that satisfies your organization's compliance requirements, rather than leaving retention as an undefined, inconsistent practice that varies unpredictably over time.

Reviewing Audit Logs Periodically, Not Just Reactively

Audit logs provide the most value when reviewed periodically as a proactive practice, not only pulled up reactively after an incident is already suspected, since periodic review can actually catch a developing problem earlier.

Unsure your current logging meets audit requirements?

Start with a free Mirth Health Check to review your setup, send us the exact error if you're troubleshooting something specific, or check pricing for our support plans.