What you will learn
By the end of this topic, you should be able to define the privacy professional’s product contribution; map data and legal roles; establish purpose, legal basis, minimisation and retention; influence architecture and requirements; lead impact assessments; control processors and international transfers; enable transparency and rights; and coordinate breaches, changes and end-of-life obligations.
The privacy and data-protection role
Privacy professionals help the organisation use personal and health data lawfully, fairly and transparently while supporting a viable medical product. Their value is architectural: challenging unnecessary collection, unclear purpose, excessive access, uncontrolled sharing and indefinite retention before these become embedded in the product.
Legal interpreter
Identify applicable regimes, roles, obligations and jurisdictional differences.
Design adviser
Turn privacy principles into product and operational requirements.
Assessment lead
Evaluate risks to people and document proportionate safeguards.
Lifecycle coordinator
Maintain transparency, rights, incidents, retention and supplier controls.
Map the complete data lifecycle
Identify data collected, inferred, generated, combined, displayed, transferred, logged, backed up, retained and deleted across the device, app, cloud, portals, service tools, analytics and support processes. Include identifiers, pseudonymous data, telemetry, location, voice, images, free text and metadata. Record purpose, source, recipient, location, retention and security classification.
Clarify legal and operational roles
Determine who decides the purposes and means of processing, who acts on instructions, and whether parties are independent or joint controllers under the applicable law. Distinguish healthcare-provider, manufacturer, research, employer and consumer contexts. Under US law, determine whether and how HIPAA applies rather than assuming all health-related data is protected health information.
Use MTL-303 — Data-protection and Health-information Regulations — GDPR, UK GDPR, FADP and HIPAA.
Make purpose, legal basis and minimisation explicit
- Describe each processing purpose in specific, understandable terms.
- Identify the lawful basis and any condition for sensitive or health data.
- Collect only data necessary for the defined purpose.
- Separate care, safety, support, research, analytics and marketing purposes.
- Avoid making essential product use conditional on unnecessary processing.
- Define retention and deletion from legal, clinical and technical needs.
- Reassess compatibility before reusing data for a new purpose.
Translate privacy into system requirements
Apply separation, pseudonymisation, least privilege, local processing, aggregation and privacy-preserving defaults where appropriate. Coordinate with MTL-109 — Medical-device Cybersecurity; security protects data, while privacy also governs whether and why processing should occur.
Use privacy impact assessment to change the design
Describe processing, necessity, proportionality and risks to people, including discrimination, surveillance, loss of control, exclusion, distress and physical consequences. Consider vulnerable users, power imbalance, large-scale health data, systematic monitoring and automated decisions. Define safeguards, owners and residual risk, and revisit the assessment when purpose, technology, population or data flow changes.
Control processors, services and international transfers
Identify cloud, analytics, support, identity, communications and development services that receive or can access personal data. Establish documented instructions, confidentiality, security, subprocessor, breach, deletion, audit and assistance obligations. Assess transfer mechanisms and destination-country risks where required. Product teams remain accountable for architecture choices even when processing is outsourced.
Design transparency and rights into operations
Provide concise and layered information that matches actual processing. Establish routes for access, correction, deletion, restriction, portability, objection and automated-decision safeguards where applicable. Verify identity without collecting disproportionate additional data. Ensure rights requests can be fulfilled across live systems, backups, processors and linked records within required timescales.
Coordinate incidents, changes and end of life
Define how privacy incidents are detected, contained, assessed, documented and notified. Connect product-security, safety, legal and communications teams. Assess new features, data sources, AI uses, suppliers, markets and research programmes before implementation. At retirement, address exports, migration, account closure, legal retention, deletion, installed products and continuing patient access.
Common misconceptions
“Consent makes any processing acceptable.”
Consent must be valid and does not remove purpose, minimisation, fairness or security obligations.
“Pseudonymous data is anonymous.”
If re-identification remains reasonably possible, data-protection obligations generally continue.
“Privacy belongs in the notice.”
A notice cannot repair unnecessary collection, excessive access or an architecture that cannot honour rights.
Authoritative starting points
Privacy must shape the product before data starts to flow
Define purpose, minimise processing and make access, retention, rights and accountability technically achievable.