Data-protection and Health-information Regulations — GDPR, UK GDPR, FADP and HIPAA

Privacy regulation follows data, purpose, people and relationships

A connected medical device may collect identifiers, measurements, symptoms, medication events, diagnostic results, location, device telemetry and account information. The applicable law depends on where people are located, what information is processed, why it is processed, which organisation determines the purpose, and the relationships between manufacturers, healthcare providers, employers, insurers, cloud suppliers and users.

Privacy is not a legal notice added after development. Data choices affect intended purpose, architecture, interfaces, cybersecurity, usability, clinical work, service, post-market surveillance and commercial models.

Start with an end-to-end data map

A useful data map follows information from collection to final deletion, including copies, derived information, logs, backups and support access. It should distinguish information needed for care or device operation from information used for analytics, improvement, research, marketing or another secondary purpose.

Use MTL-121 — Data, Connectivity and Interoperability to define information meaning and interface behaviour, and MTL-129 — Privacy and Data Protection by Design to turn the map into design controls.

The four regimes overlap but are not equivalent

Maintain an applicability rationale per data flow and jurisdiction. A single label such as “GDPR compliant” or “HIPAA data” is too coarse to guide design or demonstrate accountability.

Personal health data and HIPAA PHI are different concepts

Under GDPR and UK GDPR, information concerning health is a special category of personal data. It includes information revealing an individual's physical or mental health status, including data arising from healthcare services. Identifiers and device data may become health data through their content, context or combination.

The Swiss FADP treats data concerning health as sensitive personal data. HIPAA protects individually identifiable health information as PHI only when it is held or transmitted by a covered entity or business associate, subject to defined inclusions and exclusions.

• Do not assume pseudonymised data is anonymous; the organisation may still be able to reconnect it to a person.
• Do not assume device telemetry is non-personal when it can be linked to an account, patient or unique device.
• Do not call all US health information PHI; HIPAA status depends on both the information and the regulated relationship.
• Define de-identification or anonymisation criteria and validate the result against the applicable regime and intended use.

EU GDPR combines principles, lawful bases and accountability

The GDPR applies to processing of personal data in the context of an EU establishment and can also apply outside the EU when organisations offer goods or services to, or monitor the behaviour of, people in the Union. Its principles include lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability.

Processing needs a lawful basis under Article 6. Processing special-category health data also needs an applicable condition under Article 9. These are separate questions. Depending on the activity, relevant conditions may concern healthcare, public health, research, legal claims or explicit consent, but the organisation must select and document the actual basis rather than list every possibility.

High-risk processing can require a data-protection impact assessment. Controller–processor arrangements, records of processing, privacy information, individual rights, international transfers and breach response must align with the real system and operating model.

UK GDPR requires a separate jurisdictional assessment

The UK GDPR sits alongside the Data Protection Act 2018 and subsequent UK amendments. It retains the familiar framework of principles, lawful bases, special-category conditions, controller and processor responsibilities, rights, security, impact assessment and accountability, but it is a distinct legal regime.

An organisation operating in both the EEA and the UK should not assume that one governance decision automatically satisfies both. Confirm territorial scope, representation, supervisory authority, transfer mechanism, national conditions and current ICO guidance. Maintain coordinated documentation where the same product and controls support both regimes, while preserving jurisdiction-specific decisions.

Swiss FADP has its own scope and terminology

The revised Federal Act on Data Protection entered into force on 1 September 2023. It applies to processing personal data by private persons and federal bodies, protects natural persons, and identifies health data and certain other categories as sensitive personal data.

Important themes include transparency, proportionality, purpose, data accuracy, privacy by design and by default, processor control, records in defined circumstances, data-protection impact assessments for processing likely to result in high risk, security, overseas disclosures and notification of qualifying data-security breaches.

Swiss organisations should use the official FADP and its implementing ordinance rather than treating GDPR documentation as automatic evidence of Swiss compliance. Similar controls can be reused, but differences in scope, terminology, thresholds, rights and notification must be mapped deliberately.

HIPAA is relationship- and sector-specific

HIPAA's Privacy Rule governs uses and disclosures of PHI by covered entities—health plans, healthcare clearinghouses and healthcare providers conducting specified electronic transactions—and by business associates performing defined functions or services involving PHI. Business associates and relevant subcontractors have direct obligations as well as contractual duties.

The Security Rule protects electronic PHI through administrative, physical and technical safeguards designed to preserve confidentiality, integrity and availability. The Breach Notification Rule establishes notification duties for breaches of unsecured PHI.

A manufacturer can be a business associate for one customer service while processing different product, research or consumer data outside that role. Separate those activities, permissions and records.

Determine legal roles for each processing activity

Contract labels do not override reality. Product architecture, customer instructions, analytics decisions, support access and reuse of data can change the role. Record the conclusion per activity and revisit it when the business model or system changes.

Every use needs a defined and permitted purpose

Separate the purposes needed to deliver the device or service from optional analytics, product improvement, scientific research, safety reporting and marketing. “Improving our services” is rarely precise enough to guide users, engineers or reviewers.

• Describe the purpose and expected benefit in plain language.
• Identify the necessary data and avoid collecting information merely because it may be useful later.
• Record the legal basis and any special-category condition under GDPR or UK GDPR.
• Confirm the FADP purpose, transparency and proportionality position.
• For HIPAA, identify whether the use or disclosure is required, permitted or needs an authorisation.
• Prevent secondary use unless its compatibility, permission and safeguards have been established.
• Align product behaviour, customer contracts, privacy information and internal procedures.

Consent is important, but it is not a universal solution

Under GDPR and UK GDPR, consent must be freely given, specific, informed and unambiguous, and explicit consent is one possible Article 9 condition for health data. It may be unsuitable where there is an imbalance of power or where the service cannot genuinely accommodate refusal and withdrawal.

HIPAA authorisation is a defined mechanism for uses and disclosures not otherwise permitted or required by the Privacy Rule; it is not equivalent to GDPR consent. Clinical-investigation consent, consent to treatment, device terms and privacy consent also serve different purposes.

Design withdrawal and preference behaviour before collecting information. Define which processing stops, which records must be retained, what happens to derived data and how downstream parties are informed.

Translate legal obligations into protection by design

Privacy by design requires early decisions about data minimisation, separation, identity, access, retention, user control, interfaces and default settings. A DPIA or equivalent assessment should influence architecture and product requirements rather than merely describe a completed system.

Use MTL-103 — User Needs and Design Inputs and MTL-104 — Design Controls and Technical Documentation to make these decisions controlled and verifiable.

Individual rights need product and operational support

GDPR, UK GDPR and FADP provide rights concerning personal data, although scope, conditions and exceptions differ. HIPAA provides rights over PHI, including access and amendment within its regulated context. A useful response process must be able to find the relevant data, verify identity, explain decisions and act across systems and suppliers.

• Maintain an inventory showing where a person's information and copies reside.
• Provide usable export, correction, restriction or deletion functions where applicable.
• Separate legal retention from avoidable technical inability to delete.
• Propagate approved changes to processors and relevant downstream recipients.
• Protect the requester and other people during identity verification and disclosure.
• Record requests, decisions, fulfilment and any lawful refusal.

Privacy security and product cybersecurity must connect

GDPR and UK GDPR require security appropriate to risk. FADP requires appropriate technical and organisational measures. HIPAA's Security Rule applies administrative, physical and technical safeguards to ePHI. The terminology differs, but each requires a defensible relationship between information risk and implemented controls.

Privacy harm can include discrimination, loss of confidentiality, loss of control, financial harm, distress or exposure of sensitive circumstances. Product cybersecurity risk also considers patient safety and device performance. One security event may affect both; the analyses must exchange assets, threats, controls, verification results and monitoring information without collapsing privacy harm into safety harm.

Use MTL-108 — Medical-device Cybersecurity for secure product lifecycle controls.

Cloud and service suppliers remain part of the responsibility chain

GDPR and UK GDPR require controllers to use processors providing sufficient guarantees and to put required contractual terms in place; subprocessors require controlled authorisation and equivalent protections. FADP likewise requires appropriate processor selection, instruction and control.

HIPAA covered entities and business associates need business associate agreements where the relationship meets the definition. A cloud service provider that stores encrypted ePHI without viewing it can still be a business associate. Relevant subcontractors must also be covered.

• Define data, purpose, role, instructions and prohibited uses.
• Identify locations, subprocessors, support access and international transfers.
• Specify security, incident reporting, audit evidence and cooperation with rights requests.
• Control retention, return, deletion, backups and exit arrangements.
• Assess supplier changes and vulnerabilities throughout the service lifecycle.
• Confirm that technical architecture matches the promises in the contract.

International data movement needs its own control

GDPR, UK GDPR and FADP restrict disclosures or transfers to countries without an accepted level of protection unless a valid mechanism and required safeguards are used. Decisions may depend on adequacy findings, contractual clauses, binding rules, derogations and transfer-risk assessments.

A supplier's registered address is not a complete location map. Consider production hosting, replicas, backups, disaster recovery, content-delivery services, support, remote administration, logging and subprocessors. Control transfer mechanisms as living dependencies: legal developments, supplier architecture and onward transfers can change the conclusion.

Breach response must support several clocks and thresholds

GDPR and UK GDPR generally require notification to the relevant supervisory authority within 72 hours after awareness when a personal-data breach is likely to result in a risk to people's rights and freedoms, with communication to affected people in defined high-risk cases.

Under FADP, the controller must notify the FDPIC as soon as possible when a data-security breach is likely to result in a high risk to personality or fundamental rights. Under HIPAA, breaches of unsecured PHI trigger notification duties to affected individuals, HHS and sometimes the media; detailed timing and process depend on the circumstances, and business associates notify the covered entity.

Privacy controls must survive the product lifecycle

Privacy impact assessment should be revisited when new data, algorithms, users, interfaces, jurisdictions, suppliers or purposes are introduced.

Privacy obligations interact with medical-device regulation

Medical-device law can require complaint, vigilance, traceability, clinical, quality and post-market records. Privacy law does not automatically prohibit those records; it requires a documented basis, proportionate content, suitable access, security, retention and transparency.

In the US, HIPAA permits specified disclosures to organisations subject to FDA jurisdiction for purposes including adverse-event reporting, product tracking, recalls and post-market surveillance. The precise parties, data and purpose still need assessment. Use MTL-320 — US FDA Medical-device Regulations: 21 CFR Overview for the FDA lifecycle and MTL-307 — EU MDR and IVDR General Safety and Performance Requirements for the European product-safety framework.

Preserve traceability between privacy requirements, cybersecurity controls and product evidence, while keeping legal analyses distinct. A cybersecurity control can protect both safety and privacy without making the two regulatory arguments identical.

Common misconceptions

Practical privacy-regulation checklist

• Map personal and health information across the complete system and lifecycle.
• Identify individuals, locations, purposes, recipients and legal entities.
• Determine applicability and organisational role for every regime and processing activity.
• Record lawful bases, special-category conditions or HIPAA permissions and authorisations.
• Minimise data, access, precision, frequency and retention.
• Complete and maintain impact or risk assessments where required.
• Translate obligations into approved requirements, architecture and verification evidence.
• Provide accurate privacy information and workable individual-rights processes.
• Control processors, business associates, subprocessors, cloud services and transfers.
• Integrate privacy incidents with cybersecurity, safety, quality and regulatory escalation.
• Review the assessment whenever product, data, purpose, supplier or jurisdiction changes.