EU Data Act for US Medical Device Makers: The Access-by-Design Duty After 12 September 2026

A US manufacturer of a connected infusion pump, a remotely monitored implant or a home-use glucose sensor faces two distinct FDA questions. For covered cyber-device submissions, section 524B of the Federal Food, Drug, and Cosmetic Act addresses cybersecurity. For devices on the 510(k) pathway, 21 C.F.R. § 807.81(a)(3) asks whether a change could significantly affect safety or effectiveness, subject to the exceptions in 21 C.F.R. § 807.81(b).1Federal Food, Drug, and Cosmetic Act § 524B, 21 U.S.C. § 360n-2, added by Pub. L. No. 117-328, div. FF, title III, § 3305(a), 136 Stat. 5832 (2022) (Consolidated Appropriations Act, 2023): 21 U.S.C. § 360n-2(a) (specified premarket submissions for cyber devices), 21 U.S.C. § 360n-2(b)(1) to (3) (postmarket vulnerability plan, processes and procedures providing reasonable assurance of cybersecurity, updates and patches, and a software bill of materials), and 21 U.S.C. § 360n-2(c) and (d) (the three-part cyber-device definition and authority to exempt categories by published list). 21 C.F.R. § 807.81(a)(3) (changes that could significantly affect safety or effectiveness, or a major change in intended use), subject to 21 C.F.R. § 807.81(b), including 21 C.F.R. § 807.81(b)(1)(ii) (no new premarket notification where the change is consistent with a predetermined change control plan cleared under section 515C of the Act). Neither asks who is entitled to the data the device generates. The EU Data Act does. Subject to the enterprise exclusions and transitional periods in Art. 7(1) Data Act, a connected product first placed on the Union market after 12 September 2026 must have user access designed in. Placement is counted unit by unit. A previously cleared and CE-marked model can therefore face the duty for its next unit first supplied in the Union, even though the model itself is unchanged. For a medical device, the change that answers the Data Act is also a change the MDR regulates, and much of the data it releases is health data.

1. Which Connected Medical Devices, Which Data, Which Units

The Data Act is a horizontal instrument rather than a medical device law, and it does not leave medical devices out. A connected product is an item that obtains, generates or collects data concerning its use or environment and can communicate product data via an electronic communications service, a physical connection or on-device access, unless its primary function is storing, processing or transmitting data for a party other than the user. Recital 14 Data Act names "medical and health devices" among its examples. Art. 3(1) Data Act requires connected products and related services to be designed so that product data and related service data, with the metadata needed to use them, are by default accessible to the user easily, securely, free of charge and in a comprehensive, structured, commonly used and machine-readable format and, where relevant and technically feasible, directly. Art. 50 Data Act applies that obligation to connected products, and the services related to them, placed on the market after 12 September 2026.2Regulation (EU) 2023/2854 of 13 December 2023 on harmonised rules on fair access to and use of data (Data Act), [2023] OJ L 2023/2854, Art. 2(5), (15) to (17), (21) and (22), Art. 3(1), Art. 7(1), Art. 50 and recital 14. The design duty applies to in-scope connected products and their related services placed on the market after 12 September 2026, subject to the enterprise exclusions and transitional periods.

That date is counted against units, not models. Placing on the market is the first making available of a connected product on the Union market under Art. 2(22) Data Act, and the Commission's FAQ on the Data Act reads the concept, as the Commission's Blue Guide on product rules does, as referring to each individual product, not to a type. The Blue Guide adds that individual units of a model supplied before new requirements applied must comply with them if they are placed on the market afterwards.3European Commission, Frequently Asked Questions: Data Act, version 1.4 (22 January 2026), questions 7, 8 and 12; Commission Notice, The “Blue Guide” on the implementation of EU product rules 2022, 2022/C 247/01, [2022] OJ C 247/1, section 2.3. Both are non-binding guidance. Placement concerns each individual product, not its model; physical delivery is not required for the first supply. A monitor model first sold in the Union in 2019 is therefore subject to Art. 3(1) Data Act for each in-scope unit first supplied there after 12 September 2026, subject to Art. 7(1) Data Act. Neither document binds, but the per-unit reading follows from the Regulation's own definition.

The September 2026 date adds a design layer; it does not open the access right. The Regulation has applied since 12 September 2025, and since then a data holder whose product does not offer direct access has had to make readily available data accessible on a simple request under Art. 4(1) Data Act, a reading the FAQ confirms for products already on the market. The later date adds a design duty for in-scope units first placed on the Union market after 12 September 2026. Art. 7(1) Data Act excludes data from products manufactured or designed, or related services provided, by a micro or small enterprise only if its partner/linked-enterprise and subcontracting conditions are met. The same conditions govern the transition for an enterprise that has qualified as medium-sized for less than one year and the one-year period for products placed on the market by a medium-sized enterprise.4Data Act (n 2), Art. 4(1), Art. 7(1), Art. 50 and recital 41; Commission Recommendation 2003/361/EC of 6 May 2003 concerning the definition of micro, small and medium-sized enterprises, [2003] OJ L 124/36, Annex, Art. 2 to Art. 6 Recommendation 2003/361/EC; FAQ (n 3), question 22. The enterprise exclusions and medium-enterprise transition retain the partner/linked-enterprise and subcontracting conditions; size is not assessed by headcount alone. Whether a venture-backed US device company qualifies turns on its headcount and financial figures and on which of its investors and affiliates the Commission's SME definition counts as partner or linked enterprises.

Which data are caught is where a medical device departs most from a smart appliance. Product data are data generated by the use of a connected product that the manufacturer designed to be retrievable, and related service data represent user actions or events during the provision of a related service. Recital 15 Data Act places raw and pre-processed data within scope, including readings from a single sensor or a connected group of sensors that determine a physical quantity, and places outside it information inferred or derived from such data through additional investment, in particular by means of proprietary, complex algorithms. For a device whose clinical value lies in its algorithm, that line runs through the middle of the product. A raw electrocardiogram trace or infusion log can fall within the raw or pre-processed category; an arrhythmia classification or dosing recommendation may be inferred or derived information if it results from the additional investment described in recital 15 Data Act. The classification depends on the actual processing, not the clinical label alone. The exclusion of content from Chapter II of the Data Act adds a second uncertainty. The FAQ reads content as something akin to copyrightable material, typically destined for human appreciation, and treats certain non-creative sensor imagery not destined for human consumption as within scope.5Data Act (n 2), Art. 1(2)(a), Art. 2(15) to (17) and recital 15; FAQ (n 3), questions 4 to 6. Raw and pre-processed data are distinguished from information inferred or derived through additional investment. Whether a particular clinical output falls on either side depends on how it is produced; the FAQ does not classify diagnostic images as a category. A diagnostic image can be destined for a clinician without being the result of a creative process. The FAQ does not decide that category, so neither human readership nor the label “image” settles the classification.

The definitions also let the design set its own perimeter. Recital 14 Data Act lets the manufacturer's design choices, and sector-specific law, determine which data a product can make available. Recital 20 Data Act excludes from readily available data those the design does not provide for storing or transmitting outside their generating component or the product as a whole, while preserving data minimization under Art. 5(1)(c) GDPR. The non-binding FAQ treats exclusively local processing without external transmission as outside Chapter II Data Act in principle, but retains the obligations where raw or pre-processed data was at any point accessible or externally transmittable.6Data Act (n 2), Art. 2(15) Data Act (product data designed to be retrievable), recital 14 Data Act (design choices and applicable sectoral law), and recital 20 Data Act (data not designed to be stored or transmitted outside their generating component or the product as a whole; no obligation to store them on the central computing unit; data minimization preserved; later restrictions of accessible data to be communicated). Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) [2016] OJ L 119/1 (GDPR), Art. 5(1)(c) GDPR. European Commission, FAQ on the Data Act (n 3), version 1.4, 22 January 2026, question 5a: exclusively local processing without external transmission in principle does not trigger Chapter II, but obligations apply where raw or pre-processed data was at any point accessible or externally transmittable. This is non-binding guidance, not a general exemption for data described as local. Whether a decision to keep a data stream on the device in new units, or to stop logging it, is data minimization, engineering or a way around Art. 3(1) Data Act requires an assessment of the actual design and its effects, and Recital 20 Data Act expects a software update that restricts previously accessible data to be communicated to the user.

The user is the second variable. Art. 2(12) Data Act defines the user as the person who owns a connected product, holds contractually transferred temporary rights to use it, or receives related services, and the FAQ describes a stable right in the object for the ownership or temporary-use route. A hospital that buys or leases a monitor is its user, and Recital 18 Data Act counts public sector bodies among users. The patient is a data subject but does not become a user merely by being connected to that monitor. A patient who buys a home-use device is both. Ownership after implantation is one route by which a patient may qualify as a user of an implanted device, and the FAQ builds the Data Act on civil-law relations of ownership and lease, which national law supplies. The related service is the third variable. The FAQ treats a digital service as a related service only where data flow in both directions and the service affects the product's functions, so a remote-monitoring platform that reprograms an implant qualifies and a dashboard that only receives telemetry may not.7Data Act (n 2), Art. 2(6), (12) and (13), recitals 17 and 18; FAQ (n 3), questions 9, 10, 14 and 21. A patient does not acquire user status merely by being connected to a hospital device, but may separately hold qualifying rights or receive a related service. Each answer moves the identity of the party entitled to the data, and of the data holder who must supply it.

For units within its scope, the Data Act asks when each unit is first supplied on the Union market, not whether the model is new to Europe. The design duty applies after 12 September 2026 subject to the enterprise exclusions and transitional periods in Art. 7(1) Data Act, whatever the model's regulatory history.

None of this depends on where the manufacturer sits. Art. 1(3)(a) Data Act reaches manufacturers of connected products placed on the market in the Union irrespective of their place of establishment, and Art. 1(3)(b) Data Act requires only that the user be in the Union. The US comparison draws a different boundary. The HIPAA right of access runs against covered entities, the health plans, clearinghouses and qualifying providers to which 45 C.F.R. Part 164 applies. Manufacturing a device alone does not make a company a covered entity, but a manufacturer performing covered or business-associate functions may have HIPAA responsibilities. Section 524B FD&C Act asks about security, not access.845 C.F.R. § 164.104(a) and (b) (covered health plans, clearinghouses and providers conducting covered electronic transactions; business associates where provided); 45 C.F.R. § 164.524(a)(1) (individual access to protected health information in a designated record set, subject to the stated exclusions and grounds for denial); 45 C.F.R. § 164.504(e)(2)(ii)(E) (business-associate contract to require making protected health information available in accordance with 45 C.F.R. § 164.524). Manufacturing a device alone does not establish covered-entity status; the organization may nevertheless perform covered or business-associate functions. 21 U.S.C. § 360n-2 (n 1). Art. 1(3)(a) and (b) Data Act (n 2) (manufacturers and related-service providers irrespective of establishment, and users in the Union). European Commission, FAQ on the Data Act (n 3), version 1.4, 22 January 2026, questions 15 and 28. The broader Data Act access right and its implications for US contract terms provide the background to these device-specific questions.

2. Direct or Indirect Access: What Art. 3(1) Data Act Leaves to the Manufacturer

The words that decide the engineering are "where relevant and technically feasible". Read with Art. 4(1) Data Act, which obliges the data holder to make readily available data accessible on request where the user cannot access them directly, they leave the manufacturer a choice between direct access, without the data holder's intervention, indirect access requiring the data holder to respond to a request, or both. A portal can provide direct access if it requires no such intervention. The FAQ reads Art. 3(1) Data Act as not obliging manufacturers to design or redesign for direct access in every case and names what a manufacturer may weigh: technical possibility, the cost of modifications, the difficulty of protecting trade secrets or intellectual property, and the security of the product. That list is the FAQ's, not the Regulation's, and it binds no competent authority.

The choice carries consequences the FAQ also spells out. On the FAQ's non-binding reading, the specific Data Act protections in Art. 4 to Art. 6 Data Act operate through the request route; Art. 3(1) Data Act does not give the manufacturer those same mechanisms for direct access. Contractual conditions remain subject to Art. 7(2) Data Act and cannot undermine the user's rights. Other applicable law, including trade-secret and data-protection law, remains relevant.9Data Act (n 2), Art. 1(8), Art. 3(1), Art. 4(1), Art. 7(2) and recital 31; FAQ (n 3), questions 17, 22 and 24. The FAQ distinguishes direct access without data-holder intervention from access on request and discusses the specific Data Act protections on that basis. It does not disapply trade-secret or other applicable law. An on-device export can reduce requests to process, but on that reading the manufacturer cannot rely on the request-route mechanisms to control each direct disclosure.

The first brake matters most for a medical device. Under Art. 4(2) Data Act, users and data holders may contractually restrict or prohibit access, use or further sharing where that processing could undermine security requirements of the connected product laid down by Union or national law, resulting in a serious adverse effect on the health, safety or security of natural persons. The provision lets sectoral authorities lend technical expertise, but names none and gives none a power. A data holder that refuses on that ground must notify the competent authority, and the user may complain or agree with the data holder to refer the dispute to a dispute settlement body under Art. 4(3) Data Act. The MDR supplies security requirements of that provenance. Annex I, Section 17.2 MDR requires device software to be developed in accordance with the state of the art, taking into account risk management, including information security, and Annex I, Section 17.4 MDR requires manufacturers to set out the IT security measures, including protection against unauthorized access, needed to run it as intended.10Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC [2017] OJ L117/1 (MDR), consolidated version of 19 July 2026, Annex I, sections 17.2 and 17.4 MDR; Data Act (n 2), Art. 4(2) and (3); FAQ (n 3), question 25 (security requirements and the qualified refusal route). Whether general requirements of that kind are specific enough to carry a restriction, whether "contractually" confines the brake to what the user has agreed, and whether a given export channel "could undermine" them are questions the text leaves open.

The second brake protects the manufacturer's commercial position. Art. 4(6) Data Act preserves trade secrets but requires the data holder to identify them and agree confidentiality measures with the user. Under Art. 4(7) Data Act it may withhold or suspend sharing where no measures are agreed or they are not honored, and under Art. 4(8) Data Act a data holder that holds the trade secret may, in exceptional circumstances, refuse a specific request where it shows on objective elements, among them the enforceability of trade secret protection in third countries and the uniqueness and novelty of the product, that serious economic damage is highly likely despite the safeguards taken by the user under Art. 4(6) Data Act. Each such decision is notified to the competent authority. Art. 5(9) to Art. 5(12) Data Act provide the corresponding third-party scheme, including the same residual-harm requirement despite that third party’s safeguards. The FAQ adds that calling data trade secrets does not by itself defeat the access right. The Commission's Digital Omnibus proposal of 19 November 2025 would add a third-country trade-secret risk ground within the same exceptional, case-by-case mechanism. It concerns a high risk, despite the user’s or third party’s safeguards, of unlawful acquisition, use or disclosure to third-country entities, or Union entities they control, subject to weaker or non-equivalent protection. This is a proposed change, not the operative refusal rule applied here.11Data Act (n 2), Art. 4(6) to (9) and Art. 5(9) to (12); FAQ (n 3), question 23. Exceptional refusal requires highly likely serious economic damage despite the user’s or third party’s safeguards. European Commission, Proposal for a Regulation as regards the simplification of the digital legislative framework (Digital Omnibus), COM(2025) 837 final (19 November 2025), Art. 1, points (3) and (4), of COM(2025) 837 proposes an additional third-country trade-secret risk ground within that exceptional mechanism; it is not enacted law.

What the Regulation does not supply is a documentation standard. Nothing in Art. 3(1) Data Act requires the manufacturer to record why direct access was not relevant or technically feasible for a given data stream, yet that choice is a likely focus of scrutiny, because in Germany a connected product that is not properly designed is itself a fineable offense. A feasibility assessment written after a complaint reads differently from one written when the design was frozen, and whether it sits in the MDR technical documentation, where a notified body will read it, is itself a choice with consequences.

The access route also has to be described before anyone buys the device. Under Art. 3(2) Data Act the seller, rentor or lessor, which may be the manufacturer, must tell the user before contracting what type, format and estimated volume of product data the device can generate, whether it does so continuously and in real time, where and for how long it stores them, and how the user may access, retrieve or, where relevant, erase them. Under Art. 3(3) Data Act the provider of a related service owes a longer list, from the prospective data holder's identity and intended use of the data to the user's right to complain.12Data Act (n 2), Art. 3(2)(a) to (d), Art. 3(3)(a) to (i) and recital 24. Sellers, rentors or lessors and related-service providers owe distinct pre-contract information. The product information includes access, retrieval and, where relevant, erasure; the recital addresses later changes and stable web links or QR codes. Recital 24 Data Act expects later changes to be communicated too. Many medical devices reach hospitals through distributors and public tenders, so the party that owes this information is often one whose documents the manufacturer does not control, and a software release that adds a data stream changes information a distributor gave months earlier.

3. A Data Export Under the MDR: Significant Change, Legacy Status and the Notified Body

For devices still sold under the MDR's transitional provisions, the Data Act arrives at an awkward moment. A legacy device, one covered by a certificate under the old directives or self-declared under them before the MDR brought it under a notified body, may be placed on the market until 31 December 2027 or 31 December 2028, depending on its class, and Art. 120(3c)(b) MDR makes that conditional, among other things, on there being no significant changes in the design and intended purpose.13MDR (n 10), Art. 120(2) and (3)–(3c), as amended by Regulation (EU) 2023/607 of the European Parliament and of the Council of 15 March 2023 amending Regulations (EU) 2017/745 and (EU) 2017/746 as regards the transitional provisions for certain medical devices and in vitro diagnostic medical devices [2023] OJ L 80/24 (2027/2028 endpoints depend on the device route and all the transition conditions, including no significant changes in design and intended purpose). Legacy units first placed on the Union market after 12 September 2026 are subject to Art. 3(1) Data Act on the same terms, including Art. 7(1) Data Act. The MDR and IVDR transition analysis maps the dates themselves; the question here is what a change made for the Data Act does to them.

The Medical Device Coordination Group's guidance on significant changes, MDCG 2020-3 Rev.1 of May 2023, treats a significant change as two cumulative elements, a change in design or intended purpose and its significance, and places one category outside the test altogether. Changes made to comply with other Union legislation are out of scope even if they relate to the design, but only if the risk/benefit ratio of the device is not negatively affected. The manufacturer carries the burden of evidence and justification, and a notified body may confirm in writing that a change is not significant without amending the certificate.14Medical Device Coordination Group, Guidance on significant changes regarding the transitional provision under Article 120 of the MDR with regard to devices covered by certificates according to MDD or AIMDD, MDCG 2020-3 Rev.1 (May 2023), sections 3, 4.1 and 4.3.2.1–4.3.2.3, Chart C (non-binding; the other-legislation exclusion requires no negative risk/benefit effect; its application to an elective Data Act implementation is not expressly resolved). That gives the Data Act a possible route through the exclusion. It does not establish that every implementation chosen in its name falls outside Art. 120(3c)(b) MDR.

Whether the exclusion covers a discretionary design change chosen to achieve the required access is unresolved. The guidance does not say that the selected engineering method must itself be legally compelled. Art. 3(1) Data Act, as the FAQ reads it, requires access but leaves room over its implementation, including indirect access through the data holder where direct access is not relevant or technically feasible. A manufacturer adding wireless export or an open interface when a server-side route could satisfy the duty may face an argument that the additional design change goes beyond what compliance calls for. That is a possible interpretation, not an express test in the guidance. The risk/benefit condition cuts the same way, because a new external interface carries security consequences that belong in that assessment. If the change is not covered by the other-legislation exclusion, the ordinary software examples point in two directions. Subject to no negative effect on the risk/benefit ratio, the guidance lists as non-significant new non-medical features such as printing, reporting formats and additional languages, the display of data already present in the device and part of the original conformity assessment, and security updates. As significant it lists a new or major modification of architecture, a new user interface presenting medical data in a new format, and a new channel of interoperability, such as wireless communication with compatible continuous blood glucose monitors. An export of data the device already records may resemble the first list; a new wireless path may resemble the second. Neither example determines the result for a particular export mechanism. The guidance does not expressly classify Data Act export files, and the manufacturer must assess the actual functions, interface and risks.

What the Guidance Cannot Settle

The guidance is not binding, says so on its cover and, adopted before the Data Act, does not mention it. Labeling is the easier half. The guidance treats updates to the label or instructions for use required by EU legislation other than the MDR as non-significant where they are mere clarifications and do not adversely affect safety and performance, a category into which information supplied under Art. 3(2) Data Act could fall if those conditions are met. The software is the harder half. A significant change does not end a legacy device's life in Europe, since the changed device may be placed on the market under the MDR. It ends its life under the directives, and a unit can then ship only under an MDR certificate its manufacturer may not yet hold.

Devices already certified under the MDR face change control of a different kind with the same timing problem. Where the notified body assesses the technical documentation device by device, as the Annex IX MDR route requires for class III devices and, under Art. 52(4) MDR, for class IIb implantable devices outside a listed set, Section 4.10 of Annex IX MDR requires its approval of changes that could affect safety and performance or the conditions prescribed for use, and it decides whether they call for a new conformity assessment or a supplement to the certificate. Where it has approved the quality management system, Section 2.4 of Annex IX MDR requires notice and assessment of planned substantial changes to that system or the device range, with approval taking the form of a supplement to the QMS certificate. The FAQ's position that a connected product may be placed on the market only if it complies with the Data Act and has passed the conformity assessment its own rules require leaves no gap between the two.15MDR (n 10), Art. 52(3) and (4), Annex IX, sections 2.4 and 4.10 MDR (separate thresholds for substantial QMS/device-range changes and changes to an approved device); FAQ (n 3), question 12. An in-scope unit first placed on the Union market after 12 September 2026 without the required access design is exposed under the Data Act. A unit that ships with a new interface requiring notified-body approval is exposed under the MDR if that approval has not been obtained. The notified body's calendar is not set by the Data Act.

US readers will recognize the structure from the other side. For devices on the 510(k) pathway, 21 C.F.R. § 807.81(a)(3) requires a new notification for a change that could significantly affect safety or effectiveness, subject to 21 C.F.R. § 807.81(b). That includes an exception for a change consistent with a cleared predetermined change control plan under 21 C.F.R. § 807.81(b)(1)(ii). The FDA's 2017 software-change guidance addresses the 510(k) assessment; it does not cover PMA or 510(k)-exempt devices.16FDA, Deciding When to Submit a 510(k) for a Software Change to an Existing Device (Guidance for Industry and Food and Drug Administration Staff, issued 25 October 2017, docket FDA-2016-D-2021), section III, pp. 3–4 (scope: relevant 510(k), preamendments and De Novo devices; not PMA or 510(k)-exempt devices), and section V, pp. 9–11 (flowchart and explanation: cybersecurity-only changes with no other impact, restoration of the most recently cleared specifications, and the remaining risk assessment). The guidance is non-binding and does not provide an exemption merely because another law prompted the change. 21 C.F.R. § 807.81(a)(3) and (b) (n 1) govern the notification requirement, including the exception for a change consistent with a cleared predetermined change control plan in 21 C.F.R. § 807.81(b)(1)(ii). The FDA download retains the 2017 guidance text and adds a cover notice about the Quality Management System Regulation effective 2 February 2026. The FDA asks about effect on safety and effectiveness; the MDCG guidance asks whether design or intended purpose changes significantly, with a carve-out for changes made to comply with other legislation that the FDA's guidance does not contain. Where one global software build serves both markets, an EU-driven change also needs assessment under the applicable US pathway. The Data Act is not a substitute for that assessment. The Commission's December 2025 proposal to simplify the MDR keeps the condition of no significant changes in design and intended purpose in the transitional route it would add for orphan legacy devices, says nothing about the Data Act, and as of publication awaited a committee decision in the European Parliament.17European Commission, Proposal for a Regulation of the European Parliament and of the Council amending Regulations (EU) 2017/745 and (EU) 2017/746 as regards simplifying and reducing the burden of the rules on medical devices and in vitro diagnostic medical devices, and amending Regulation (EU) 2022/123 as regards the support of the European Medicines Agency for the expert panels on medical devices and Regulation (EU) 2024/1689 as regards the list of Union harmonisation legislation referred to in its Annex I, COM(2025) 1023 final (16 December 2025), Art. 1(95) of COM(2025) 1023 final, proposed Art. 120(14) MDR (conditional orphan-device transition; proposal, not law in force).

4. Health Data and National Enforcement: GDPR Requirements and German Law

Much of what a connected medical device generates is personal data, and much of that is data concerning health. The Data Act does not displace the GDPR. Under Art. 1(5) Data Act the Regulation is without prejudice to Union data protection law, its Chapter II rights complement the rights of access and portability under Art. 15 and Art. 20 GDPR where users are data subjects, and data protection law prevails in any conflict. For a home-use device bought by a patient that complement is the simple case, because the patient is user and data subject at once.

The hospital is the difficult case. Where the user is not the data subject, Art. 4(12) Data Act lets the data holder make personal data available to the user only where there is a valid legal basis under Art. 6 GDPR and, where relevant, the conditions of Art. 9 GDPR are met, and Art. 5(7) Data Act says the same of sharing with a third party. Recital 7 Data Act states that the Regulation creates no legal basis of its own in that situation and mentions anonymization as one way to comply, and the FAQ leaves the data holder to assess the basis or provide anonymized data. Health data engage the prohibition in Art. 9(1) GDPR. Processing for hospital care may satisfy Art. 9(2)(h) GDPR, which covers processing necessary for medical diagnosis, treatment or the management of health care on the basis of Union or Member State law or under contract with a health professional, subject to the professional-secrecy safeguards of Art. 9(3) GDPR, or Art. 9(2)(i) GDPR, which covers reasons of public interest in public health, including the quality and safety of medical devices, on the basis of Union or Member State law with suitable and specific safeguards. Explicit consent under Art. 9(2)(a) GDPR is another possible condition, subject to that provision’s limits. Other Art. 9(2) GDPR conditions may apply to particular purposes; these examples are not exhaustive.18GDPR (n 6), Art. 4(7) and (8) GDPR (controller and processor), Art. 6(1) GDPR (lawful basis), Art. 9(1) and (2) GDPR (health-data prohibition and conditions), and Art. 9(3) GDPR (professional-secrecy safeguards for Art. 9(2)(h) GDPR). Art. 9(2)(a) GDPR permits explicit consent subject to its stated Union or Member State law limitation; Art. 9(2)(h) and (i) GDPR address specified health-care and public-health purposes with their respective conditions. These are not the only conditions in Art. 9(2) GDPR. Art. 15 and Art. 20 GDPR govern access and portability; Art. 28(10) GDPR treats a processor that determines purposes and means in infringement of the GDPR as controller for that processing. Data Act (n 2), Art. 1(5) Data Act (data-protection law preserved and prevailing in a conflict), Art. 4(12) and Art. 5(7) Data Act (where the user is not the data subject, a valid Art. 6 GDPR basis and, where relevant, the conditions of Art. 9 GDPR and Art. 5(3) of Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications) [2002] OJ L 201/37), recital 7 Data Act (no new disclosure basis in that situation; anonymization as one route), and recital 22 Data Act (processors are not data holders but may be tasked by the controller with making data available). European Commission, FAQ on the Data Act (n 3), version 1.4, 22 January 2026, questions 25a and 25b (assess the disclosure basis or anonymize; each of two controllers must demonstrate its own compliance). The manufacturer's disclosure must itself have an Art. 6 GDPR basis and an applicable Art. 9(2) GDPR condition; the hospital's treatment basis does not automatically supply them. A request within Art. 4(1) Data Act can therefore be one the manufacturer cannot lawfully answer in full.

The characterization of the manufacturer compounds the difficulty. Recital 22 Data Act provides that processors within the meaning of the GDPR are not considered to act as data holders, although a controller may task them with making data available. A manufacturer operating a remote-monitoring platform on the hospital's behalf may be a processor for that operation, while acting as controller for separate product-improvement processing whose purposes and means it determines. The roles follow the actual allocation of purposes and means for each operation under Art. 4(7) and (8) GDPR. Contracts and operating arrangements help establish that allocation, but contractual labels alone do not decide it.

Two neighboring regimes frame the problem without resolving it. The Data Act does not apply as Swiss domestic law, although Swiss manufacturers placing connected products on the EU market fall within its territorial scope. The Swiss right that comes closest, Art. 28 DSG (the Swiss Federal Act on Data Protection), lets a person obtain the personal data he or she has disclosed to a controller in a common electronic format where the controller processes them automatically, with consent or in direct connection with concluding or performing a contract between that controller and the data subject, and have them transferred to another controller where the same conditions are met and this requires no disproportionate effort, subject to the statutory restrictions. Health data are particularly sensitive personal data under Art. 5 lit. c DSG, a category examined in the analysis of Swiss health-data duties for US software providers.19Bundesgesetz über den Datenschutz (Datenschutzgesetz, DSG) vom 25. September 2020 (SR 235.1), Stand am 7. Juli 2025, the version in force on 15 September 2026: Art. 5 lit. c Ziff. 2 DSG (health data are particularly sensitive personal data); Art. 28 Abs. 1 DSG (personal data disclosed by the person to the controller, processed automatically with consent or in direct connection with concluding or performing a contract between that controller and the data subject), Art. 28 Abs. 2 DSG (transfer to another controller under the same conditions without disproportionate effort), and Art. 29 DSG (statutory restrictions). The right does not cover non-personal data or impose the Data Act’s product-data-access design obligation; the separate data-protection-by-design and default duties in Art. 7 DSG remain applicable. That right covers no non-personal data and creates no comparable product-data-access design duty. The separate Swiss data-protection-by-design duties remain applicable. Under Art. 27(1) of the European Health Data Space Regulation (EHDS), a device manufacturer that claims interoperability with the harmonized software components of electronic health record systems must prove compliance with the EHDS essential requirements, from 26 March 2029 for the first priority categories of health data, and the EHDS is without prejudice to the Data Act.20Regulation (EU) 2025/327 of the European Parliament and of the Council of 11 February 2025 on the European Health Data Space and amending Directive 2011/24/EU and Regulation (EU) 2024/2847 [2025] OJ L2025/327 (EHDS), Art. 1(3), Art. 27(1) and Art. 105 EHDS (interoperability claims trigger the stated requirements; relevant application is phased from 2029/2031). A device that meets the access duty in 2026 may face a different interoperability standard in 2029.

Who Enforces the Design Duty

Enforcement is national, and it is split. Each Member State designates competent authorities under Art. 37(1) Data Act and lays down penalties under Art. 40(1) Data Act, while the data protection supervisory authorities remain responsible insofar as personal data are concerned under Art. 37(3) Data Act and may, within their competence, impose fines up to the ceiling of Art. 83(5) GDPR for infringements of Chapter II of the Data Act under Art. 40(4) Data Act. A manufacturer within the Data Act’s scope that makes connected products available in the Union but is not established there must designate a legal representative in a Member State under Art. 37(11) Data Act. Until it does, Art. 37(13) Data Act gives all Member States competence where applicable, subject to its safeguard against concurrent enforcement concerning the same facts.21Data Act (n 2), Art. 37(1), (3), (11) and (13), Art. 40(1) to (4); MDR (n 10), Art. 11(1); FAQ (n 3), questions 67, 70 and 71. A non-EU entity within the Data Act’s scope that makes connected products available or offers services in the Union must designate a legal representative. An MDR appointment does not automatically satisfy that separate mandate. That is a separate mandate from the authorized representation required by Art. 11(1) MDR. An existing MDR appointment does not itself designate a Data Act representative, even if the same person is appointed separately to both roles.

Germany shows what national enforcement looks like. Its implementing statute, the DADG, was signed on 26 May 2026, promulgated on 29 May 2026 and entered into force the following day. It makes the Bundesnetzagentur, the federal regulator for electricity, gas, telecommunications, post and railways, the competent authority and central point of contact, and assigns the Federal Commissioner for Data Protection and Freedom of Information (BfDI) the supervision of private bodies’ compliance with the Data Act insofar as personal data are concerned. That displaces the state authorities for this Data Act role, not for all GDPR supervision. The Bundesnetzagentur reports refusals notified under Art. 4(2) and Art. 4(8) Data Act to the Commission every year under § 2 Abs. 2 Nr. 2 DADG, and under § 4 Abs. 2 DADG it normally consults the affected higher federal authorities before the specified final decisions on sectoral data-access or use matters. The statute permits exceptions where their views are already known. Under § 9 DADG it may require a remedy and, if the recipient does not comply within the specified period, order measures enforceable with a coercive penalty of up to EUR 500,000. Under § 15 Abs. 2 Nr. 1 DADG, designing or manufacturing a connected product, or designing or providing a related service, contrary to Art. 3(1) Data Act is an administrative offense, fineable under § 15 Abs. 4 DADG up to EUR 500,000; failing to designate a legal representative is fineable up to EUR 50,000. The information duties of Art. 3(2) and Art. 3(3) Data Act are not listed as direct offenses in § 15 Abs. 2 DADG. They remain subject to remedy requests and orders; breach of an enforceable order is fineable under § 15 Abs. 1 Nr. 2 DADG. Decisions addressed to a party abroad go to its agent in the Union or, absent one, are published in the agency's gazette or served abroad under § 12 Abs. 1 DADG.22Gesetz zur Anwendung und Durchsetzung der Datenverordnung (Datenverordnung-Anwendungs-und-Durchsetzungs-Gesetz – DADG) vom 26. Mai 2026 (BGBl. 2026 I Nr. 157), §§ 2–4, 9, 12, 15 and 16 DADG (in force 30 May 2026; the federal privacy-supervision allocation concerns the Data Act, and coercive penalties are distinct from administrative fines). A German hospital’s Data Act complaint about access by design may therefore involve the Bundesnetzagentur, with the BfDI responsible for the personal-data supervision assigned by that Act. The separate MDR change-control process still has to be addressed with the relevant notified body and competent authorities.

5. For US Device Makers Supplying the EU

The starting point is the device and its route to market: whether it is a connected product, which platforms are related services, what data its design makes retrievable and who qualifies as the user. For each in-scope unit, first placement on the Union market after 12 September 2026 triggers the design duty, subject to Art. 7(1) Data Act. A distributor's shipment date alone does not establish that first placement.

The design record can usefully explain why direct or indirect access fits each data stream and how the selected mechanism affects device safety and performance. For a legacy device, the manufacturer must assess Art. 120(3c)(b) MDR and any reliance on the guidance's other-legislation exclusion. The guidance does not settle every optional implementation. Where a notified body is involved, discussing that uncertainty and seeking written confirmation may be useful; neither replaces the manufacturer's assessment. For an MDR-certified device, the applicable certificate and change-control route determine whether notified-body notice or approval is required. The same change in a US build also needs assessment under its US pathway, including any applicable cleared change control plan.

The allocation between manufacturer, importer and distributor matters too. Art. 3(2) Data Act places pre-contract information duties on the party selling, renting or leasing the device. Their agreements can identify who prepares that information, updates it after a software release and responds to errors. The manufacturer's use of non-personal device data for product improvement or new services rests, under Art. 4(13) Data Act, on a contract with the user. For a hospital, the relevant agreement may have been negotiated through a distributor.23Data Act (n 2), Art. 4(13) and (14), recital 25; FAQ (n 3), question 29. A data holder’s non-personal-data use requires a contract with the user and must respect the restrictions on undermining the user’s commercial position and on sharing with third parties. The parties need to identify the data holder for each stream and distinguish that contractual permission from the legal basis needed to disclose personal data.

A manufacturer established outside the Union also needs to address the Data Act's separate legal-representative mandate. Its response to a security or trade-secret concern must meet the applicable grounds, safeguards and notification duties, rather than treating the concern as an automatic refusal right. Germany illustrates how product-access enforcement and personal-data supervision can involve different authorities while MDR change control remains a separate process. A common global build then raises the US change-control and Swiss privacy questions discussed above. These assessments turn on the device, the processing and the commercial arrangements; a single statement that the product is “Data Act compliant” cannot establish all of them.