HealthTech, MedTech & AI Diagnostics
HealthTech and MedTech companies build products that process health, genomic and imaging data continuously: a cardiac imaging algorithm, a genomic analysis platform, an epigenetic test, a stroke detection model. Each product is a data processing activity in its own right, often with the company acting as processor for hospital customers and as controller for its own users, and increasingly as a provider of an AI system under Regulation (EU) 2024/1689.
The compliance stack is layered: GDPR and UK GDPR for personal data, the MDR and IVDR for device software and its technical documentation, the EU AI Act for AI systems classified as high risk under Annex I or Annex III, NIS2 and ISO 27001 expectations from hospital procurement, and HIPAA when the product is sold in the United States.
iliomad works with product, engineering and regulatory teams to implement one framework across these regimes: a DPO who understands software, an AI Officer for the AI Act, and a data protection file that survives a hospital security questionnaire.
What a HealthTech company has to get right
Hospital customers, notified bodies and investors ask the same questions in a different order. The obligations below are the ones that decide whether a procurement, a CE marking or a financing round goes through.
A platform sold to hospitals usually processes patient data as a processor under Art. 28 GDPR, while processing its own users' data as a controller. Getting this qualification wrong invalidates the contracts and the privacy notices. iliomad documents the role per product and per customer type and builds the DPA templates your sales team can sign.
An AI system that is a medical device or a safety component of one is high risk under Annex I of the AI Act; certain other health uses fall under Annex III. Providers must implement a risk management system (Art. 9), data governance (Art. 10), technical documentation (Art. 11), logging, transparency, human oversight and a quality management system (Art. 17). iliomad classifies each system and builds the documentation alongside your MDR/IVDR file. See AI compliance services.
Art. 25 GDPR requires privacy by design and by default; the MDR and IVDR require cybersecurity in the technical documentation; hospital procurement requires evidence of both. This means data flow maps, pseudonymisation strategies, access controls, retention rules and a DPIA per product before launch, not after. See DPIA.
Training and validating models on patient data requires a lawful basis (Art. 9(2)(j) GDPR for scientific research with appropriate safeguards, or consent) and a documented anonymisation or pseudonymisation position. Art. 10(5) of the AI Act allows processing of special category data for bias detection under strict conditions. iliomad documents the position for each dataset and each model.
Selling to hospitals means answering ISO 27001, NIS2 and national health data hosting requirements (such as HDS certification in France) in every tender. A DPO and an information security framework that speak the hospital's language shorten the sales cycle. iliomad prepares the compliance pack once and keeps it current.
A product used by US covered entities makes the company a business associate under HIPAA, with a Business Associate Agreement, the Security Rule safeguards and breach notification duties. State laws such as the CCPA/CPRA add obligations towards consumers. iliomad aligns the GDPR framework with HIPAA and CPRA so that one programme covers both markets.
How iliomad Health Data can help you
iliomad Health Data supports HealthTech, MedTech and AI companies from seed stage to growth stage: cardiac imaging, genomic platforms, epigenetic testing, AI stroke detection, digital therapeutics. Our consultants combine data protection and AI regulation, and work directly with product and engineering teams. The engagement is structured as a DPO or AI Officer mandate plus scoped deliverables, so that you pay for a framework, not for hourly firefighting.
HealthTech company led by its founders? See how a single fixed fee mandate works for founders and executives.
FAQs
Our frequently questions
No, but most diagnostic AI is. Under Art. 6(1) of Regulation (EU) 2024/1689, an AI system is high risk when it is a medical device, or a safety component of one, and that device must undergo a third party conformity assessment by a notified body. This covers MDR devices in class IIa and above and IVDR devices in classes B, C and D. Because Rule 11 of the MDR places most software that informs diagnostic or therapeutic decisions in class IIa or higher, the majority of AI diagnostic tools fall in scope. Wellness apps and administrative tools fall outside Annex I, but they must still be checked against Annex III and the transparency rules of Art. 50.
Following the Digital Omnibus amendment, Regulation (EU) 2026/1744, the high risk requirements apply from 2 August 2028 for AI systems covered by product legislation such as the MDR and IVDR (Art. 6(1) and Annex I), and from 2 December 2027 for standalone high risk systems listed in Annex III. Other provisions already apply: the prohibited practices of Art. 5 since February 2025, and most transparency obligations of Art. 50 from August 2026. The postponement gives time to prepare, not an exemption: risk management, data governance and technical documentation have to be built into the product and aligned with the MDR or IVDR file well before the deadline.
Yes. The MDR and IVDR govern safety and performance; they do not provide a lawful basis for processing patient data, nor do they cover transparency towards users, data subject rights or transfer mechanisms, which remain governed by the GDPR. Art. 2(7) of the AI Act confirms that it applies without prejudice to the GDPR. The AI Act does, however, allow providers to integrate its requirements into existing product procedures: Art. 8(2) and Art. 11(2) let a manufacturer keep a single set of technical documentation for the MDR or IVDR and the AI Act. iliomad builds the GDPR file and the AI Act documentation on the same risk analysis and data flow maps as your regulatory file.
In most cases, yes. Art. 37(1)(c) GDPR makes a DPO mandatory where the core activities of a controller or processor consist of processing special category data, including health data, on a large scale. A platform, app or diagnostic service whose product is the processing of patient data usually meets this test, whether it acts as controller for its own users or as processor for hospitals. The DPO can be external, must have expert knowledge and must report to the highest management level under Art. 38. iliomad provides outsourced DPOs who work directly with product and engineering teams.
Only on a clear legal and contractual basis. When you process patient data as a processor under Art. 28 GDPR, you may act only on the hospital's documented instructions; using the data for your own purposes, such as retraining a model, makes you a controller for that processing under Art. 28(10), with your own legal basis and transparency duties. The usual routes are effective anonymisation before reuse, a research framework under Art. 9(2)(j) with the hospital as partner, or an agreement in which the hospital, as controller, authorises a defined reuse that it can justify to its patients. The chosen route must be documented before the data is touched, because it is what a hospital audit or a notified body will ask to see.
AI Governance is the internal framework that lets a company use and build AI responsibly: an inventory of AI systems and tools, an acceptable use policy, defined roles including an AI Officer, an onboarding process for third party AI tools and the AI literacy measures required by Art. 4 of the AI Act. AI Compliance is system specific: it qualifies each AI system and your role as provider or deployer, classifies it under Art. 5, Art. 6 and the Annexes, and delivers the obligations that follow, such as risk management, data governance, technical documentation and conformity assessment. iliomad offers both as distinct services; HealthTech companies usually need governance first, and compliance as soon as a product qualifies as high risk.
Any Questions ?
