Core insight
Compliance in healthcare software is an architectural problem before it is a legal one. The real gaps tend to live in trust architecture: devices without unique cryptographic identities, mobile apps treated as trusted relays, and backend systems that accept data without verifying its origin.
Where HIPAA and GDPR conflict, the answer is to implement to the stricter standard and use architectural separation – pseudonymization, jurisdictional data routing, conditional consent workflows – to satisfy both frameworks simultaneously. Every third-party vendor, API, and cloud service is a potential weak link, and a BAA with AWS only protects what falls within a correctly configured, HIPAA-eligible scope. Compliance maintained at scale is a continuous property of a system, not a state achieved once and periodically reviewed.
Compliance as an architectural problem
Every enterprise healthcare software team understands, at least in theory, what HIPAA and GDPR require. The regulations are well-documented, the penalties are well-publicized, and most organizations have a compliance officer on staff. And yet, data breaches in healthcare keep happening – not because teams are ignorant of the rules, but because they treat compliance as a legal problem rather than an architectural one.
At enterprise scale, the challenge rarely lies in understanding what the regulations say. The real difficulty is ensuring that compliance is baked into the architecture itself – something that doesn't break with every new integration, vendor swap, or onboarded device. A single misconfigured cloud bucket, an untrusted mobile relay, or a missing Business Associate Agreement with a third-party API provider can undo years of diligent compliance work.
HIPAA vs GDPR. Key differences that impact system design
HIPAA and GDPR share a common goal – protecting sensitive personal data – but they operate in fundamentally different ways, and the gap between them creates real operational complexity for organizations serving both US and EU markets.
Sources:
* https://www.govinfo.gov/content/pkg/FR-2024-08-08/pdf/2024-17466.pdf
** https://gdpr.eu/article-83-conditions-for-imposing-administrative-fines/
For enterprise healthcare software teams, the practical implication is this: if your system serves US healthcare providers and processes data from EU residents, you're subject to both frameworks simultaneously. And the two don't always agree.
Organizations building or integrating medical devices add a third layer: Medical Device Regulations (MDR) in the EU and FDA regulations in the US. When HIPAA and GDPR compliance work intersects with medical device software, it typically also triggers alignment with ISO 13485 (quality management for medical devices) or ISO 27001 (information security management). ISO 27001 is often the most practical starting point – it provides a structured security framework that creates substantial overlap with both HIPAA's Security Rule requirements and GDPR technical safeguard obligations, reducing duplication of compliance effort.
Where healthcare compliance fails at scale. Compliance as a transport problem
As Sebastian Zarzycki, CTO in Apzumi points out, the most common and most costly technical mistake is treating data transmission as a transport problem rather than a trust problem.
What does it mean? Most teams, once they've implemented HTTPS or BLE secure pairing, consider the transmission layer addressed. From a narrow technical standpoint, the data is "protected." But in a real-world healthcare context – where data correctness and traceability are as important as data privacy – this is merely the beginning.
The typical gaps at the enterprise level aren't in the transport layer. They're in the trust architecture:
Weak device identity.
Devices in production environments frequently share generic credentials or rely on identifiers that can be spoofed. There's no robust mechanism to verify which exact device is transmitting a given payload. At scale – with hundreds or thousands of devices in the field – this becomes a critical audit and liability problem.
Blind trust between layers.
Mobile applications often trust incoming device data implicitly after initial pairing. Backend systems trust the mobile app without validating the originating device. This creates a chain of assumed trust with no cryptographic verification at any link.
The mobile app as a "trusted bridge."
This is perhaps the most prevalent architectural error in healthcare software. The mobile app is treated as a secure relay between device and backend, when in reality it runs in an untrusted, user-controlled environment. Any data passing through an unverified intermediary is vulnerable to tampering – and tampered clinical data is not just a security issue, it's a patient safety issue.
Insufficient data integrity controls.
Data may be encrypted in transit but remain vulnerable to modification before or after transmission. Without cryptographic signing at the device level, there's no reliable way to verify that a payload arrived exactly as it was produced.
HIPAA and GDPR both require the ability to demonstrate data integrity and traceability. If you cannot guarantee which device produced a given data point, whether it was altered in transit, and whether it belongs to the correct patient record, you're facing an active regulatory non-compliance, not a hypothetical one.
The architectural answer is to design for end-to-end trust from the beginning, not just secure transport. In practice, this means:
- Unique device certificates provisioned at manufacturing or onboarding
- Mutual authentication between device, mobile app, and backend at every layer
- Cryptographic signing of each payload at the device level
- Treating the mobile app as a potentially compromised intermediary, not a trusted relay
- Ensuring every data point can be linked back to a verified device and timestamp
Managing compliance when HIPAA and GDPR collide
The two frameworks sometimes require opposite things. Teams operating across both jurisdictions need explicit architectural decisions for each point of conflict.
Right to erasure vs. retention requirements.
GDPR's "right to be forgotten" requires organizations to delete a data subject's personal data upon request. HIPAA, on the other hand, mandates retention of medical records – typically 6 years from creation or last use. These requirements directly contradict each other for patient health data. The most defensible technical solution is pseudonymization: separating identifying attributes from clinical data such that GDPR deletion requests can be honored at the identity layer without destroying the clinical record required by HIPAA.
Consent models.
HIPAA permits certain disclosures of PHI without explicit patient consent – for example, sharing data between providers for treatment purposes. GDPR is stricter, but Article 9(2) allows health data processing without consent for purposes such as preventive medicine, health care management, public health, and scientific research. However, for most commercial health applications, explicit consent is the only available legal basis, as the other exceptions are tied to specific legal obligations, public interest, or institutional context. As a result, systems serving both markets need conditional consent workflows that apply the appropriate standard based on the data subject's jurisdiction.
Breach notification timelines. GDPR requires notification to the relevant supervisory authority within 72 hours of discovering a breach. HIPAA allows 60 days. An enterprise organization cannot operate two separate incident response processes. The practical solution is to build to the stricter standard: design your detection, investigation, and notification workflows to meet the 72-hour GDPR requirement, which automatically satisfies HIPAA's longer window.
The general principle: when the two frameworks conflict, implement the higher standard. When they require incompatible approaches, use architectural separation (pseudonymization, jurisdictional data routing, conditional logic) to satisfy both simultaneously.
Vendor and integration risk: The blind spot
For healthcare organizations, first-party code is one part of the compliance picture, but the ecosystem around it often introduces risks that are harder to see and control. Cloud providers, third-party APIs, analytics tools, and device manufacturers – any of them can introduce a gap in the compliance chain.
Under HIPAA, every vendor that creates, receives, maintains, or transmits PHI on your behalf must sign a Business Associate Agreement (BAA). AWS, Azure, and GCP all offer BAAs for their HIPAA-eligible services – but the BAA only covers those specific services, and only when configured correctly. Using a service outside its HIPAA-eligible configuration while a BAA is in place does not provide compliance protection. Configuration is the organization's responsibility, not the cloud provider's.
Under GDPR, vendors processing personal data of EU residents must sign a Data Processing Agreement (DPA) that specifies the scope of processing, security requirements, procedures for cross-border transfers, and data deletion protocols.
At enterprise scale, the vendor risk surface can be extensive: EMR integrations, telehealth platforms, analytics pipelines, IoT device manufacturers, payment processors. Each is a potential weak link. A comprehensive compliance posture requires a structured vendor assessment process – not just at onboarding, but on a regular cadence, since vendor security postures and subprocessor relationships change over time.
Compliance as an architectural discipline
The organizations that consistently maintain compliance at enterprise scale share one characteristic: they treat compliance as a continuous property of their systems, not a state to be achieved and periodically verified.
Privacy by Design requires architectural constraints. Data minimization, access control, and audit logging should be enforced at the infrastructure level, not added as features. If your data model makes it technically easy to store more PHI than necessary, compliance depends on developer discipline rather than system constraints. That's a fragile posture at scale.
Compliance belongs in the CI/CD pipeline. Manaul audits catch problems after the fact. Automated checks – for encryption configuration, access control policies, audit log coverage, and dependency vulnerabilities – catch problems before deployment. This is especially important in organizations with multiple development teams contributing to shared infrastructure.
The right infrastructure choices reduce ongoing compliance burden. Cloud services with built-in HIPAA eligibility, encryption-by-default storage, structured audit logging, and granular IAM policies create a compliance-friendly baseline. Retrofitting these capabilities onto an existing system is significantly more expensive – in engineering time, risk, and potential regulatory exposure – than building on them from the start. The practical default stack: AWS or Azure with HIPAA-eligible service configurations, backend audit logging from day one, encryption at rest and in transit throughout, and a secrets management solution for credentials and device certificates.
Regulations change, and that’s why compliance is ongoing, not periodic. In early 2025, HHS published a notice of proposed rulemaking introducing the most significant updates to the HIPAA Security Rule in over a decade – with the final rule expected in 2026. GDPR enforcement patterns evolve with new European Data Protection Board guidance. New integrations, new device models, and new vendors each introduce potential gaps. Enterprise compliance programs need a continuous monitoring function, not just an annual audit.
Frequently Asked Questions
What is the most common technical mistake when transmitting sensitive medical data from a device to an app or cloud?
The most common mistake is treating transmission as a transport problem – assuming that encryption in transit (HTTPS, BLE secure pairing) is sufficient. In practice, the more dangerous gaps are in the trust architecture: devices without unique cryptographic identities, mobile apps treated as trusted relays when they run in uncontrolled environments, and backend systems that trust the app layer without validating the originating device. If a data payload cannot be verified as originating from a specific, authenticated device and arriving unmodified, the system lacks the integrity guarantees that both HIPAA and GDPR implicitly require.
How often does HIPAA/GDPR compliance work need to align with Medical Device Regulations (MDR), and which ISO standard is typically the right foundation?
For software teams working with connected medical devices, MDR alignment is required whenever the software meets the definition of a medical device or is integral to one – which covers a broader range of healthcare software than many teams initially assume. ISO 27001 is typically the most practical foundation: it establishes an information security management framework with substantial overlap with HIPAA's Security Rule and GDPR's technical safeguard requirements, reducing duplication across compliance programs – though overlap is not the same as full coverage, and each framework still needs to be addressed on its own terms. For software teams specifically, IEC 62304 is often the more immediate requirement, governing the software development lifecycle directly. ISO 13485 becomes relevant when quality management for the device itself – not just the software – is in scope.
What is the most effective way to handle HIPAA and GDPR conflicts in a system serving both US and EU patients?
The most conflicts – right to erasure vs.The most conflicts – right to erasure vs. retention, consent models, breach timelines – can be resolved through two approaches used together. First, implement to the higher standard wherever possible: GDPR's explicit consent requirements and data minimization principles are stricter than HIPAA's equivalents, and satisfying them typically satisfies HIPAA as well. Breach notification timelines are converging – the proposed 2025 HIPAA updates would bring the HHS notification window down to 72 hours, matching GDPR – but until that rule is finalized, GDPR's timeline remains the stricter default to build against. Second, use architectural separation for genuine conflicts: pseudonymization to handle erasure requests without destroying clinical records, jurisdictional data routing to apply appropriate consent logic, and clearly documented legal bases for each processing activity in each jurisdiction.
