The Data Act: Six Months to Go — But What To Do?

The Financial Times recently published a special report on the future of digital healthcare, comprising articles on ‘smart’ hospitals, the use of networked devices, remote care and, inevitably, AI.

Our clients are at the forefront of many of the developments covered by the report. That said, I couldn’t help thinking that the report overlooked a law that takes effect in less than six months’ time and which will have significant ramifications for organisations operating in this space: the European Union’s Data Act.

The Data Act, which takes effect from 12 September 2025, applies to data — both personal and non-personal — generated by connected products that are placed on the EU market and related services, and seeks to enhance the EU’s data economy by (i) giving users of Internet-enabled products greater access to their data, and (ii) legally requiring businesses to share data with other businesses. A very wide range of Internet of Things products and services will be caught by the Act — consumer-facing (e.g., connected cars, smart home devices) and industrial (e.g., robots and machinery) alike. 

The Act also includes measures to increase competition in the European cloud market and establishes a mechanism through which public sector bodies can request data from businesses where there is an exceptional need (such as in public emergencies). For the purposes of this article, however, we will look solely at the B2C and B2B data sharing provisions in Chapters II, III and IV of the Act as they apply to Internet-enabled medical and health devices.

Roles and Responsibilities

Recital 14 of the Act makes clear that the manufacturers of “medical and health devices” are in scope — both the devices themselves and their associated software, and irrespective of whether the device is subject to an approval requirement or conformity assessment regime (e.g., a fitness tracker that does not constitute a medical device for the purposes of EU law but is a connected product under the Act).

• Connected Product. An item that obtains, generates or collects data concerning its use or environment and that is able to communicate product data via an electronic communications service, physical connection or on-device access, and whose primary function is not the storing, processing or transmission of data on behalf of any party other than the user.
• Related Service. A digital service, other than an electronic communications service, including software, that is connected with the product at the time of the purchase, rent or lease in such a way that its absence would prevent the connected product from performing one or more of its functions, or which is subsequently connected to the product by the manufacturer or a third party to add to, update or adapt the functions of the connected product.

The Act applies primarily to data holders and data users. However, given that certain of the data produced, requested and shared by these parties will constitute personal data for the purposes of the GDPR, in-scope entities will need to assess their roles under both the Act (data holder, data user, data recipient) as well as the GDPR (controller, processor, data subject). Importantly, these roles do not always overlap neatly.

• Data Holder. The natural or legal person that has the right or obligation to make data available. In the healthcare context, the manufacturer of the medical device will typically act as a data holder. 
  • GDPR Overlay. In most cases, the data holder will also act as a controller for the purposes of the GDPR. However, it is possible that a data holder which provides a SaaS product could be the processor and the hospital (i.e., the data user) would be the controller.
• Data User. The natural or legal person that owns or has a right to use the connected product. In the healthcare context, patients, consumers and HCPs can all potentially act as a data user. Notably, the type of connected products that are used in commercial healthcare settings can — indeed, often will — have more than one user. 
  • GDPR Overlay. In some cases, the data user will also be the data subject for the purposes of the GDPR (e.g., an individual that uses a consumer health device). But that is not always the case. For example, a hospital that purchases a device for use on its patients will be the data user — and will typically process the patients’ personal data as a controller for GDPR purposes — and its patients will be the data subjects. Indeed, where a data user that is not a data subject obtains data from a connected product, it will become a controller for the purposes of the GDPR.
• Data Recipient. The natural or legal person, acting for purposes which are related to that person’s trade, business, craft or profession, other than the user of a connected product or related service, to whom the data holder makes data available, including a third party following a request by the user to the data holder or in accordance with an EU legal obligation.
  • GDPR Overlay. In some cases, the data recipient will act as a controller for the purposes of the GDPR (e.g., another related to the provision of healthcare). However, and depending on the context, recipients could also process personal data as a processor. Here, as with each of the above roles, the devil will be in the detail.

Data Access and Sharing Requirements

Chapters II, III and IV of the Act set out the provisions on B2B and B2C sharing, B2B sharing where required by law, and unfair contractual terms, respectively.

• Article 3. Connected products and related services must be designed and manufactured or provided in way that allows product data and related service data (and relevant metadata) to be accessible easily and securely, free of charge and by default to the data user — including, where relevant and technically feasible, directly to the user. This obligation is essentially an ongoing Article 15 GDPR access right — and compliance will pose significant technical and operational challenges for device manufacturers and related parties. 

• Article 3(1). Before concluding a contract for the purchase, rent or lease of a connected product, the data holder must provide to the data user information on (i) the type, volume and scope of product data, (ii) whether the product is capable of generating data continuously and in real-time, as well as its retention capabilities, and (iii) how the user may access, retrieve or erase the data.
• Article 3(2). Before concluding a contract for the provision of a related service, the provider must provide to the data user clear and comprehensible information on (among other things) (i) the nature, estimated volume and collection frequency of product and generated data, (ii) the identity of the prospective data holder, and (iii) how the data user can request that data are shared with a third party. 

• Article 4. Where data cannot be directed access by the data user, the data holder must give users the right to access the usage data (including relevant metadata), where technically feasible. Such access and onward sharing may be contractually restricted or prohibited where doing so could undermine the security of the connected product and result in a serious adverse effect on individuals’ health, safety or security. Importantly, the data holder does not have to disclose trade secrets where the parties cannot agree on the measures needed to preserve their confidentiality or, in exceptional cases, where the data holder can demonstrate that it is highly likely to suffer serious economic damage from the disclosure of its trade secrets. 
• Article 5. Upon request by a data user, the data holder must make data easily available and free of charge (and, where technically feasible, continuously and in real-time) to third parties, which are referred to by the Act as “data recipients”. The GDPR’s right to data portability is the inspiration here — but as above, the obligations under the Data Act will have significant technical and operational effects for organisations that are being asked to share data.    
• Article 8. Where, in a B2B relationship, a data holder is required to make data available to a data recipient (e.g., under Article 5 of the Act), it must agree arrangements with the data recipient under fair, reasonable and non-discriminatory (a/k/a FRAND) terms. Although the parties can agree on compensation for making data available, it must be non-discriminatory, reasonable and may include a margin.  

Next Steps

With less than six months to go until the majority of its provisions take effect, manufacturers of medical devices and developers of related software should be taking a three-pronged approach to meeting their obligations under the Act. 

• Technical. Connected products and related services should be designed to ensure that they can fulfil the data access and sharing obligations under the Act. This will in practice impose a heavy burden on most organisations and so should be started as soon as possible.
• Organisational. Internal policies and procedures should be revised to reflect how the organisation will handle access and portability requests. Addressing requests that relate to personal data under the GDPR and non-personal data (as well as personal data) under the Data Act will be particularly challenging, such that applying existing processes is unlikely to be an effective solution.   
• Contractual. Terms and conditions, master service agreements and other data sharing terms should be updated to reflect the information required by Article 3 of the Act. Readers that lived through the Article 28 GDPR papering exercise in the run up to May 2018 can expect a similarly time-consuming process, meaning that time is of the essence. 

Subscribe to Ropes & Gray Viewpoints by topic here.