Is TLS required for HL7 connections, or just recommended?

While specific technical requirements can vary by regulation and context, using TLS for HL7 connections carrying PHI reflects current security best practice and is generally expected as part of meeting HIPAA's transmission security requirements.

Does encrypting data at rest mean I don't need access controls too?

No, encryption at rest and access controls serve complementary but distinct purposes — encryption protects against certain storage-level compromise scenarios, while access controls govern who can view data through normal, authorized application access.

Should backup files be encrypted the same way as the live database?

Yes, backup files should meet the same encryption standard as your production database, since an unencrypted or weakly protected backup undermines the security benefit of encrypting your primary, live data store.

How often should encryption keys actually be rotated?

This depends on your organization's specific policies and risk tolerance, but establishing any defined, periodic rotation schedule is better than using the same keys indefinitely without ever rotating them at all.

Does using HTTPS automatically mean my API traffic is adequately secured?

HTTPS is a strong baseline, but confirm the specific TLS version and cipher suites in use reflect current standards, since simply using HTTPS with outdated underlying configuration can still leave meaningful security gaps.

What's the risk of storing encryption keys alongside the data they protect?

If both the keys and the encrypted data are compromised together, the encryption provides little practical protection, since an attacker with both would have everything needed to decrypt the data regardless of the encryption strength used.

Healthcare Data Encryption In Transit and At Rest

Healthcare Data Encryption In Transit and At Rest: The Practical Basics

Healthcare data encryption in transit and at rest covers two genuinely distinct protection scenarios that both need to be addressed for PHI flowing through an integration engine: encryption in transit protects data while it's actively moving between systems over a network, while encryption at rest protects data sitting in storage, like a message database, when it's not actively being transmitted anywhere. Both matter independently, since strong encryption in transit does nothing to protect data once it's landed in an unencrypted database, and vice versa.

Below is how encryption in transit actually applies to HL7 and API-based integration traffic, what encryption at rest looks like for a message database, and the key management basics that make either approach genuinely effective. If you're unsure your current encryption setup is adequate, our free Mirth Health Check can review your configuration directly — part of the Mirth Connect support work we do for US healthcare teams.

How Encryption in Transit Applies to Integration Traffic

Data moving between your integration engine and any connected system, whether over HL7, an HTTP-based API, or another protocol, needs protection specifically while it's in that transit state between endpoints.

TLS for HL7 Connections Over MLLP

Traditional HL7 v2 connections over MLLP can and should be secured using TLS, encrypting the connection between sending and receiving systems rather than transmitting PHI-containing HL7 messages over a plain, unencrypted socket connection.

HTTPS for REST and FHIR API Connections

Any REST or FHIR API-based integration should use HTTPS exclusively, ensuring the underlying TLS encryption protects API requests and responses carrying PHI, the same baseline expectation as any modern web-based data exchange.

Current, Strong TLS Versions and Cipher Suites

Simply using TLS isn't sufficient on its own — the specific TLS version and cipher suites in use should reflect current security standards, since outdated TLS versions and weak ciphers can undermine the protection encryption is meant to provide. See our SSL/TLS hardening guide for the specifics.

Every Hop in a Multi-System Chain Needs Coverage

If a message passes through multiple systems before reaching its final destination, each specific hop in that chain needs its own encryption in transit, since a single unencrypted segment anywhere in the path creates a genuine exposure gap.

What Encryption at Rest Looks Like for a Message Database

Once PHI lands in your integration engine's message database, protecting it in storage requires a different, complementary set of encryption considerations distinct from transit protection.

Database-Level Encryption for Stored Message Content

Whether using the embedded default database or an external platform, message content and metadata stored at rest should be encrypted, protecting that data even if the underlying storage were somehow improperly accessed or physically compromised. See our database configuration guide for the setup details.

Disk-Level Encryption as an Additional Layer

Beyond database-level encryption specifically, disk-level encryption on the underlying server or storage infrastructure adds another protective layer, covering scenarios where physical storage media itself might be accessed outside the database layer.

Backup Files Need the Same Encryption Standard

Backups of your message database should be encrypted to the same standard as the live database itself, since a backup file sitting somewhere less protected than production defeats the purpose of encrypting the primary data store. See our backup and disaster recovery guide for the broader strategy.

Encryption Doesn't Replace Access Controls

Encryption at rest protects against certain physical or storage-level compromise scenarios, but it doesn't replace the need for proper access controls governing who can query and view that data through normal, authorized application access.

Key Management Basics That Make Encryption Effective

Encryption is only as strong as the key management protecting the encryption keys themselves, and weak key management can undermine even technically strong encryption implementation.

Keys Should Be Stored Separately From Encrypted Data

Encryption keys shouldn't be stored alongside the data they protect, since co-locating keys and encrypted data significantly weakens the protection encryption is meant to provide if that storage location is ever compromised together.

Access to Keys Should Be Tightly Restricted

Limit access to encryption keys to the minimum necessary personnel and systems, applying the same least-privilege principle you'd apply to any other highly sensitive credential within your broader security architecture.

Key Rotation Should Happen on a Defined Schedule

Establish a periodic key rotation schedule rather than using the same encryption keys indefinitely, reducing the potential impact if a key were ever compromised without your organization's immediate knowledge.

Document Your Key Management Practices Clearly

Maintain clear documentation of how encryption keys are generated, stored, rotated, and access-controlled, since this documentation becomes essential both for internal governance and for demonstrating due diligence during a compliance review.

Unsure your current encryption setup is adequate?

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