In early March 2024, the EU lawmakers reached agreement on the European Health Data Space (EHDS).  For now, we only have a work-in-progress draft version of the text, but a number of interesting points can already be highlighted.  This article focusses on the obligations of data holders; for an overview of the EHDS generally, see our first post in this series.

We expect the final text of the EHDS to be adopted by the European Parliament in April 2024 and by the EU Member States shortly thereafter.

1: Health data holder

The term “health data holder” includes, among others, any natural or legal person developing products or services intended for health, developing or manufacturing wellness applications, or performing research in relation to healthcare, who:

• in relation to personal electronic health data: in its capacity of a data controller has the right or obligation to process the health data, including for research and innovation purposes; or
• in relation to non-personal electronic health data: has the ability to make the data available through control of the technical design of a product and related services.  These terms appear to be taken from the Data Act, but they are not defined under the EHDS.

In practice, this means that, for example, hospitals, as data controllers, are data holders of their electronic health records.  Similarly, pharmaceutical companies are data holders of clinical trial data and biobanks.  Medical device companies may be data holders of non-personal data generated by their devices, if they have access to that data and an ability to produce it.  However, medical device companies would not qualify as a data holder where they merely process personal electronic health data on behalf of a hospital.

Individual researchers and micro enterprises are not data holders, unless EU Member States decide differently for their territory.

2: Data sets covered by EHDS

The EHDS sets out a long list of covered electronic health data that should be made available for secondary use under the EHDS.  It includes, among others:

• electronic health records;
• human genetic data;
• biobanks;
• data from wellness applications;
• clinical trial data – though according to the recitals, this only applies when the trial has ended;
• medical device data;
• data from registries; and
• data from research cohorts and surveys, after the first publication of the results – a qualifier that does not seem to apply for clinical trial data.

Member States may add data categories on national level.  They are also allowed to introduce stricter safeguards (for example an opt-in consent) for certain data categories, such as genetic data, biobanks, and data from wellness applications (oddly, as this data is not more sensitive than other data categories).

The EHDS does not contain a clear limitation in time.  This suggests that it will apply to all electronic health data that data holders have, irrespective of when they obtained or generated it, and will therefore cover data collected before the EHDS came into force.

3: Catalogue of data sets

Irrespective of whether a data holder receives any actual data request, data holders must provide a description of the data sets they hold and that are covered by the EHDS to their respective Health Data Access Body (HDAB).  The European Commission will set out the minimum information required in that description by means of secondary legislation.  Given the broad scope of the EHDS, we expect this will require considerable effort from data holders.

The HDAB will make the information its receives from data holders public in a standardized, machine-readable “dataset catalogue”.  Data holders have to verify every year that their information in the catalogue is accurate and up to date.

4: Data Quality

Data holders may decide to apply a data quality or data utility label to (part of) their data sets.  However, such labels are mandatory for data sets collected and processed with EU or Member State funding.  As a result, most electronic health records will probably require a label because they will often be publicly funded.  Similarly, data sets from clinical trials or biobanks that receive funding through Union or national research programs would require a label.

The EHDS sets out the elements that the labels have to cover, including, for example, information allowing to assess the technical quality of the data, the coverage of the data, the applied data management practices, and how to modify or merge data sets.

5: Obligation to share data

Data holders who receive a request from their HDAB to share data covered by EHDS must provide that data to the HDAB within 3 months – this period can be extended by another 3 months where justified.  The HDAB then makes the data available on its secure processing environment to the health data user in an anonymized form – or in pseudonymized form, if the user can justify that it requires such data in pseudonymized form instead. 

Recitals indicate that the anonymization must occur as soon as possible in the chain of the secondary use.  In practice that would mean that anonymization should be done by the data holder in most cases, since they will be the first entity in the chain.  That said, the recitals to the EHDS also say that the HDAB or data holders can perform this task.  We expect that which entities in this chain do what, when, and in which circumstances, will be clarified through guidance and market practice over time.

6: Trusted health data holders

For access request involving data sets from a single data holder, data holders can choose to be designated as a “trusted health data holder”, in accordance with a procedure to be set up by the Member States. Where a data holder is a “trusted health data holder”, its data can be made available to the data users directly via a secure processing environment, instead of via the platform of the HDAB.

While this is portrayed as a simplified procedure, it is difficult to understand what these simplifications are.  Data users still have to make their access applications to the HDAB and the HDAB will issue the permit, following a (non-binding) assessment of the trusted data holder.  In light of this, and in light of the additional complexity involved in operating a secure processing environment, it is unclear what incentives data holders have to qualify as trusted data holders (also see below in section 8).

7: Fees

HDABs and trusted data holders may charge a fee to data users for making the requested data available, including for assessing the application, for the collection of the data and its consolidation, preparation, anonymization and for the provisioning of the data.  The fees must be in proportion to the cost of making the data available and may include compensation for the cost incurred by the data holders – data holders should provide an estimate of these costs to the HDAB. 

Member States can decide to reduce the fees for certain data users, such as public bodies and universities; it remains to be seen how they will exercise this power in practice.  It is also unclear whether this can have an impact on the share of the fee received by data holders for their part in the costs.

8: Data controllers

The EHDS contains specific language on the GDPR designation of several parties in the process.  Data holders are “controllers” for the sharing of personal health data with the HDAB pursuant to an access request.  The legal basis for this sharing is a “legal obligation” under Art. 6(1)(c) GDPR and the Art. 9(2)(i) or (j) GDPR derogation for health data. 

The HDAB and trusted data holder are also controllers for their processing activities (e.g., collection, preparation and anonymization), despite the fact that the processing would never have occurred without a request from the data user (clinical trial buffs will get the hint).  However, the HDAB and trusted data holder are deemed “processors” of the data user (the data controller), for the provisioning of the data in their secure processing environment.  This processor qualification makes little sense, legally and practically.  The HDABs necessarily co-decide on the purpose of the processing by assessing the access request and granting the permit.  Moreover, they decide alone on the means used for the processing because it is their secure processing platform being used.  Practically, this deemed processor-controller relationship will mean that the HDAB and trusted data holder will require an Art. 28 GDPR agreement with each data user, granting the data user, among others, a right to audit the HDAB and trusted data holder.  At the same time, the EHDS provides that the HDAB is supposed to audit the data user’s use of the secure processing environment, meaning that at least in theory both sides will be required to audit each other.