Email infrastructure for healthcare organizations under HIPAA and the EU EHDS regime

Our BAA is aligned with the required terms under 45 CFR 164.504(e): we agree to use and disclose PHI only as permitted by the BAA, implement appropriate safeguards under 45 CFR 164.312, report breaches to your organization within the timeframe your BAA specifies (default 24 hours of discovery), make PHI available for the individual's right of access under 164.524, document and report any subcontractor that creates, receives, maintains, or transmits PHI, and return or destroy PHI at termination unless retention is required by law.

Sub-processors: our infrastructure runs on bare-metal servers in our Stockholm and Frankfurt facilities, both of which we operate directly (not on AWS, not on Azure, not on Google Cloud). The sub-processor list is short: DNS, the network providers in each data center, and the trademark-registered VMC issuer (DigiCert) when the bank also runs BIMI. Every sub-processor has a BAA with us. The full register is part of the procurement document we share before signing.

Not currently. HITRUST CSF is a US-centric framework, and while the certification has real value for US healthcare organizations evaluating vendors, our customer base is predominantly European healthcare organizations where HITRUST is not a procurement requirement. We do operate under ISO 27001 and our internal controls are documented at the level a HITRUST audit would require; for US healthcare organizations where HITRUST is a hard requirement, we can either pursue certification or refer to one of the larger HITRUST-certified providers as a complementary option.

The published data on HITRUST is genuinely impressive: less than 1% of HITRUST-certified organizations reported breaches over a two-year span in the most recent industry research. The underlying reason is that the controls HITRUST requires are the controls that actually prevent breaches — encryption, access control, audit logs, incident response. We implement all of them. The certification is the procurement signal; the controls are the actual protection.

HIPAA explicitly allows it under 45 CFR 164.522(b) — the patient has the right to request and receive appointment reminders by email, and the provider must accommodate the request if email is a reasonable alternative. The HHS guidance is clear that the provider can assume email is acceptable when the patient initiates the communication.

What we ship: a per-patient consent flag in the database. When the consent flag is set, our DLP treats that patient's reminders differently — appointment reminders, billing notifications, and similar low-sensitivity communications can flow as plaintext (with a generic subject line that doesn't contain PHI), while clinical communications (lab results, prescription details, diagnosis information) still trigger auto-encryption regardless. The consent flag is auditable: who set it, when, with what evidence (signed authorization form scanned into the EHR, or verbal consent with the staff member's documentation). Revoke is one click and propagates within minutes.

The 24-48 hour window matters most. Detection: our DLP flags multi-recipient messages, unusual recipient domains (consumer Gmail, Hotmail when the patient profile shows an Office 365 account), and recipient email addresses that match staff or vendor accounts on a clinical message. When the flag fires, the message is held in the outbound queue and the sender plus their immediate supervisor are notified within 60 seconds. If the staff member confirms the recipient is correct, the message releases. If not, the message is purged before it leaves our infrastructure.

If a message does leak (because the staff member confirmed before realizing the recipient was wrong, or because the address was typo'd to a real but unintended account), the recovery workflow: immediate notification to your compliance officer, breach assessment template pre-filled with the technical facts, recipient-side request to delete (legally weak but worth doing), and HIPAA Breach Notification Rule clock starts. If the breach affects fewer than 500 individuals it's reported in the annual HHS submission; 500+ requires notification to HHS within 60 days and media notification for incidents affecting more than 500 in a single state. We provide the technical breach data structured for direct inclusion in the OCR submission.

Two integration patterns. SMTP relay pattern: Epic/Cerner/Allscripts (or your European EHR — Compugroup, Doctolib for appointment workflows, Dedalus, Cerner's European deployments) authenticates to our SMTP relay, the EHR continues to be the source of patient communications, our infrastructure handles encryption, DLP, audit, and delivery. The EHR's clinical context isn't exposed to us; we see envelope-level metadata and message structure, not the patient record.

HTTP API pattern: for organizations building newer workflows (telemedicine platforms, patient engagement layers on top of an existing EHR), the EHR or middleware calls our API directly with structured message templates. Patient consent flags travel as API parameters; the DLP runs against the rendered message before SMTP handoff. This pattern is more common in European deployments where the EHDS interoperability standards encourage API-based integration rather than SMTP gateway integration.

EHDS (Regulation EU 2025/327) is principally an interoperability and cross-border-access framework, not an encryption mandate. Most provisions don't apply until 26 March 2027, with the major primary-use functionality (Patient Summaries, ePrescriptions/eDispensations exchanged across borders) operational by 26 March 2029. What's already live: every EU member state had to appoint a National Digital Health Authority by June 2025, and EHR vendors had to certify their systems for interoperability and security compliance by January 2026.

What this means for our infrastructure: we don't replace your EHR (the EHDS certification applies there), but we are part of the security perimeter that the National Digital Health Authority in your member state may inquire about during oversight. The audit trail we maintain is structured to satisfy both HIPAA 45 CFR 164.312(b) and the EHDS Article requirements for security, confidentiality, and integrity controls. For German hospitals specifically, this also aligns with the §22 BDSG-neu special-category processing requirements and the BfArM expectations for ICT in healthcare.

The proposed update reclassifies MFA from an addressable specification (the covered entity decides whether to implement based on risk assessment) to a required specification (the covered entity must implement). As of early 2026 the rule is still proposed — finalized adoption is expected through the regulatory comment process — but the direction is clear, and the prudent operating posture is to treat MFA as required already.

Our infrastructure enforces MFA on every staff account that touches PHI as the default — TOTP (Google Authenticator, Authy, 1Password, etc.), FIDO2/WebAuthn security keys (YubiKey, Apple/Google passkeys), or SMS as fallback for staff who don't have access to other methods. The enforcement is at the authentication layer; staff can't bypass it by accident. The audit log records every authentication event, every MFA challenge, every failure. For an OCR investigation, the question "does the covered entity enforce MFA?" gets a structured "yes" with the audit data to demonstrate it.