How Health-Data Privacy Rules Work: A Plain Guide to GDPR and HIPAA

Two of the world's most influential health-data privacy frameworks solve the same problem from opposite directions. The EU's General Data Protection Regulation (GDPR) starts with the person and treats all personal data as protected, with health information singled out for extra care. The US Health Insurance Portability and Accountability Act (HIPAA) starts with the setting and protects health information held by specific players in the healthcare system. If you understand that difference in starting point, most of the rest falls into place. This piece is general education, not legal advice, and if you are making decisions about a real product or a real medical record you should talk to a qualified professional.

Two different starting points

GDPR is a comprehensive privacy law. It governs how organizations handle personal data about people in the EU, whatever the sector or the technology. Health data is not a separate island; it sits inside the general regime as one of several "special categories" that deserve heightened protection.

HIPAA is narrower by design. It regulates health information, but only when that information is held by defined actors in the US healthcare system. A hospital falls under HIPAA. A general fitness app that a consumer downloads often does not, because it is not a covered entity and is not acting on behalf of one. The same heart-rate number can be tightly regulated in one hand and loosely regulated in another, depending on who holds it and why.

I came to this topic through medical-device regulation rather than privacy law. My certificate work at KTH covered EU MDR, IVDR, FDA pathways, and Software as a Medical Device, and that vantage point makes one thing clear: privacy rules and device rules run on parallel tracks, and a serious product satisfies both.

What GDPR asks of you

GDPR treats health data as a special category under Article 9. The default rule is that you may not process it at all unless a specific exception applies, which is a strong signal about how the framework views this information.

To process ordinary personal data lawfully, an organization needs a lawful basis under Article 6. There are six: consent, performance of a contract, a legal obligation, protection of vital interests, a task carried out in the public interest, and legitimate interests. For health data you need more than that. You need one of those Article 6 bases and, on top of it, a separate condition under Article 9. The two layers are cumulative. Explicit consent is one Article 9 route. Others cover care and treatment, public health, and scientific research, each with its own guardrails. Legitimate interests, which does a lot of work for ordinary data, rarely carries special-category data on its own.

GDPR also gives people rights over their data: to be informed, to access a copy, to correct errors, to have data erased in some circumstances, to restrict or object to processing, and to move data elsewhere. These rights are not absolute. Erasure, for instance, can collide with laws that require medical records to be kept for a set period, and the retention obligation usually wins for the records it covers.

Two roles matter for anyone building a product. A controller decides why and how data is processed. A processor acts on the controller's instructions, such as a cloud vendor running infrastructure on a clinic's behalf. The distinction is not cosmetic. It determines who owes which duties, and it has to be set out in a written contract before data changes hands.

What HIPAA asks of you

HIPAA's scope is defined by who you are. Covered entities are health plans, healthcare clearinghouses, and healthcare providers that transmit certain information electronically. Business associates are the vendors and partners that handle protected health information on a covered entity's behalf, bound through a business associate agreement. If you sit in one of those buckets, HIPAA applies. If you do not, it generally does not, though other laws still might.

The information HIPAA protects is protected health information, or PHI: individually identifiable health information held or transmitted by a covered entity or business associate. In electronic form it is often called ePHI.

HIPAA works through a few connected rules. The Privacy Rule sets limits on how PHI can be used and disclosed and gives patients rights, including the right to get a copy of their records and to request corrections. The Security Rule sets standards for safeguarding electronic PHI through administrative, physical, and technical measures. A Breach Notification Rule then requires notice when unsecured PHI is exposed. A defining feature is that HIPAA permits many uses of PHI for treatment, payment, and healthcare operations without asking the patient to sign off each time, which is what lets care function.

The Security Rule is an area of active movement. US regulators have proposed strengthening its cybersecurity requirements, with measures such as broader use of encryption and multi-factor authentication under discussion. That proposal is not final, so the general direction is clearer than any specific deadline or clause, and you should check the current text before relying on it.

What a patient should take from this

Your rights depend on where your data lives. Under GDPR you can generally ask an organization what it holds about you, request a copy, and ask for corrections, and health data carries extra protection by default. Under HIPAA you can get a copy of your records from a covered provider or plan, ask for amendments, and receive notice if your information is breached.

The gap worth remembering is the consumer app. A wellness tracker you install yourself may sit outside HIPAA entirely, which means the app privacy policy you scroll past, not a federal medical-privacy rule, is doing the work. Reading it is time well spent.

What a builder should take from this

Decide early which frameworks touch your product, because that answer shapes the architecture as much as the paperwork. If you serve EU users, map your Article 6 basis and your Article 9 condition before you write a line of storage code, and know whether you are a controller or a processor. If you touch the US healthcare system as a covered entity or business associate, the Privacy and Security Rules and a business associate agreement are not optional add-ons.

Privacy law and device law overlap but do not substitute for each other. A clinical algorithm can be a well-regulated medical device and still mishandle personal data, and a privacy-clean app can still make a clinical claim it has no clearance to make. Serious teams treat both as design constraints from the start.