I. Introduction
Internet of Things (IoT) is the terminology used to describe an ecosystem of objects and devices which can gather information on the surrounding environment with sensors. This type of technology can be applied in many sectors as it can adapt to different tools and applications. The easiest example is the case of smart objects installed in a smart house: from the smart fridge to the smart lighting, the devices are all connected to the internet and can gather information from the user and react to specific requests.Footnote 1 Still, the sector where IoT use is flourishing is the health one: wearable or implantable devices gather information about patient’s health conditions, allow doctors (or hospitals) to personalise medical services, and react expeditiously to emergencies.Footnote 2 During the Covid pandemic, the use of such technologies was crucial to avoid direct contact between patients and doctors without reducing the possibility of providing medical care.Footnote 3 Moreover, IoTs in the health sector are also perceived as tools to increase the system’s efficiency: the cost of unnecessary check-ups is reduced, as the patient is constantly monitored.
The Covid pandemic has also confirmed the value of health data for research activities: thanks to the clinical and immunological data gathered from patients who were already affected and survived the disease, it was possible to understand the virus and its structure and to predict which of its components will provoke an immune response.Footnote 4 This was a key step in vaccine design and allowed research teams worldwide to build up the necessary knowledge to eventually produce an effective vaccine.
As a matter of fact, the data gathered by IoT devices can subsequently be used for research activities, both to improve the device itself and to develop new tools or devices. This type of processing is crucial for innovation in the health sector, as it allows researchers and manufacturers to verify the potential avenues for improvements and to test and train new products on real and reliable data. However, when the data needed in this subsequent development are personal data, some limitations apply. In particular, the General Data Protection Regulation allows the “secondary” use of personal data only for specific circumstances, such as for research purposes or public interest in public health.Footnote 5 Yet, two recent European legislations were put forward to enhance the opportunities for the secondary use of personal data: the Data Act (DA) and the European Health Data Space Regulation (EHDS). Although the two legislative acts rely on the framework provided by the General Data Protection Regulation, inconsistencies and lack of coordination among the three legislative interventions emerge. In particular, interrelated issues emerge across the set of legislations, such as incoherent terminology used, the overall complexity of the application, as well as intra-related issues affecting the economic incentives for market actors to exploit the path provided by each piece of legislation. Moreover, the use of IoT in the health sector may imply the application of another piece of legislation: the Medical Device Regulation, depending on the type of purposes of the IoT devices considered.
This contribution will address the overlaps and the coordination issues applicable in the case of medical IoT investigating what will happen when IoT-generated data are shared to create new products or services according to the framework now depicted by the Data Act and the European Health Data Space. Given that the EHDS and the Data Act are both aimed at facilitating the secondary use of (health) data, the contribution will compare the two processes set up to establish a roadmap to solve health-data sharing theoretical and practical queries.
The article will first identify the current legislation applicable to IoT in the medical sector, looking to the General Data Protection Regulation and the Medical Device Regulation. Then, the specific case of secondary use of data will be presented, comparing the rules in the DA (Section 3) and the ones in the EHDS (Section 4). An evaluation of the most suitable solutions from the manufacturer’s perspective will be presented in the conclusions.
II. The data processing in Medical IOT
1 The general data protection regulation framework
The personal data collection carried out by any connected product or IoT is subject to the rules provided by the General Data Protection Regulation (GDPR), which identifies a horizontal framework applicable to data processing with special attention to health data.Footnote 6
The GDPR applies to any operation or set of operations performed manually or by automated means on personal data (Article 4 (2) GDPR). According to the definition provided by GDPR, personal data includes any information related to an identified or identifiable natural person. Thus, personal data can be objective information, such as the features of the individual, which rarely change (eg, the colour of the eyes or the place of birth), and subjective information, such as opinions or assessments. The GDPR does not distinguish between objective and subjective data but rather between generic data and special categories of personal data. The second category includes personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data, data concerning health, etc. (Article 9 GDPR). In this latter case, stricter rules apply to data processing. Although Article 4(15) GDR provides a definition of health data, the terminology used is not clear, as health data are “personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his or her health status.” This almost tautological definitionFootnote 7 may lead to an extremely wide interpretation that can also cover other personal data that indirectly hint at the health conditions of the data subject.Footnote 8
IoT processing of personal data that concerns health is therefore subject to the stricter requirements imposed by Article 9 GDPR.Footnote 9 Health data processing is prohibited except for a set of specific legal cases, such as upon the special consent by the data subject, data manifestly made public by the data subject, data processing aimed at preventive or occupational medicine and also data processing for reasons of public interest in the area of public health.Footnote 10 These exceptions are crucial for the secondary use of health data, as will be clarified in the section dedicated to the EHDS.
Looking in general at the actors involved in the data collection carried out by a connected product, we may distinguish between three types of actors that can collect and process the personal data of the data subject, namely the data controller, the data processor and the data recipient.
Article 4(7) GDPR describes the data controller as “the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data.” Given the crucial role played by the data controller in the processing, the GDPR adopts an objective approach to identifying who oversees this role, looking at the factual elements or circumstances of a case, regardless of any formal declaration.Footnote 11 The controller is the body that decides the purpose of the processing and means to carry it out: the type of data collected, the duration of the process, the recipients of data, and the technical means to process the data. It should be underlined that the data controller is not obliged to control the means physically or directly; it is possible that the hardware or software collecting personal data is entrusted to a third party. This is relevant in the case of IoT in the medical sector; for instance, the company manufacturing the software that is embedded in a device that monitors blood sugar levels for patient subjects with diabetes can be qualified as a data controller as it processes the health data to provide an alert if the level of sugar in the blood rises. Still, data collection can be done thanks to sensors collecting raw data from the data subject’s body; such sensors can be part of a multi-purpose (smart) device that runs more than one software.
The data processor, pursuant to Article 4(8) GDPR is the natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller. The processors involved in data processing may be more than one and oversee different processing stages. Also, in this case, the factual circumstances and the concrete activities are crucial to identify whether the qualification as a data processor is correct. For instance, the provided service may not be targeted at processing personal data or does not constitute a key element of the service. In these cases, the service provider cannot qualify as a processor but as a data controller. A different situation may emerge when the data processor decides to carry out additional processing for its own purpose with the data collected; in this case, the qualification is correct as the data processor was under the direct control or authority of the data controller, but the additional processing may lead to an infringement of Article 28(10) GDPR.
The role of the data controller and the data processor can be clearly identified in the processor agreement, where the services offered by the data processor are presented, and the final approval of the data controller allows for their adoption in the data processing. For instance, in case the IoT is a smart device with limited internal memory, it may use the services of a cloud storage provider. Although the cloud service can be completely standardised, with limited to no power to change the contractual clauses, the IoT developer will play the role of the controller, given its decision to use this particular cloud service provider to process personal data for its purposes. In contrast, the cloud service provider will qualify as a data processor.Footnote 12
Article 4(9) GDPR adds another actor who may play an important role in the data processing, namely the data recipient, who is defined as “a natural or legal person, public authority, agency or another body, to which the personal data are disclosed, whether a third party or not.” In principle, the data recipient has no obligations or responsibilities vis-à-vis the existing data processing. However, it can become a new controller or processor once the data are received. For example, when a controller sends personal data to another entity, the latter is qualified as a recipient. This disclosure may be justified for data sharing, transmission or dissemination. For instance, the IoT manufacturer may disclose the data processed to parent companies for advertising purposes.
2. The specific rules emerging from the Medical Device Regulation
Another regulation that may apply to the IoT in the health sector is the Medical Devices Regulation 2017/745 (MDR).Footnote 13 The MDR replaced two previous medical device directives (Council Directive 90/385/EEC on Active Implantable Medical Devices (the AIMD) and Council Directive 93/42/EEC on Medical Devices (the MDD) on 26 May 2021).Footnote 14 The new legal framework also brought some novelties regarding the definition of medical devices.Footnote 15
IoT devices can be qualified as medical devices. According to Art. 2(1) MDR, a medical device is “any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings” for one of the specific objectives listed in the subsequent lines of the same article.Footnote 16 The important update is the inclusion of “software” among the types of medical devices, both stand-alone software and software connected to other software, and also software offered as a service to another medical device.Footnote 17 It is important to note that when the software qualifies as an accessory, ie, it can steer the performance of a device, but as a stand-alone component does not perform medical actions, it does not qualify as a medical device.Footnote 18 However, the definition of medical device (MD) software is ambiguous: if MD software is downloaded on an IoT, does this new connected product with a related service constitute a new IoMT? In the least problematic scenario, the reply is negative: the IoT object can be considered an accessory to the MD software.Footnote 19 However, it is possible that the IoT is already a medical device whose functioning is enhanced by MD software. Thus, the reply to the previous question can be positive: it is a new medical device, a generic device groupFootnote 20 or a system.Footnote 21
Moreover, the definition in Article 2 (1) MDR provides the criteria distinguishing medical and wellness devices/software.Footnote 22 If the purpose is among the ones listed, the device/software qualifies as a medical device. Article 2 (12) MDR states that the purpose is indicated by the manufacturer. Therefore, it is up to the manufacturer to provide information about the device’s purpose on the label, in the instructions for use or in promotional or sales materials or statements.
The MDR refers to the GDPR in terms of protecting personal data, according to Article 110 MDR. Thus, the roles of the data controller and/or processor can be found in the data processing carried out by the medical device. As a result of the previous description, it is possible to identify and distinguish different hypotheses depending on the technical features of the IoMT. The most common one is the case of an IoMT as a standalone device: here, the role of the data controller can be allocated to the device’s manufacturer. However, depending on the possibility for a medical expert to verify the results of the device applied to a patient, a joint controllership with the medical expert may occur. This is the case with HomeKit Lite,Footnote 23 which is a standalone certified medical device designed for the rehabilitation of cognitive patients both at the hospital and at home. The device includes a set of components and sensors that allow the patient to perform several exercises: cognitive exercises, but also speech therapy, postural, facial, respiratory, motor and neuromotor skills exercises. The system can be used offline, collecting information about the activities of the patient and in connection with the therapist, who can monitor the previous results collected by the device and adapt to the needs of the patient. In this case, although the medical device is a standalone device that does not exploit any external service for storage and processing (such as cloud computing service), health data regarding the patient are also shared directly with the therapist.
So far, the legislation applicable to data processing by medical IoT has been limited to the aforementioned provisions of the GDPR and MDR. Suppose manufacturers are interested in developing novel IoT in the medical sector, such as applications and devices that complement existing devices. In that case, they cannot exploit the data structures already available in the existing devices. For instance, developing an AI-based medical software that allows the recognition of tumoral formations may be better trained and tested with the data and patterns detected by existing medical devices. In this case, the manufacturer may be unable to access such data, except for applying the specific exceptions provided in Articles 6 and 9 GDPR.Footnote 24 Moreover, the conditions upon which the data are shared are not defined in GDPR, and, for instance, where specific interoperability standards are relevant for the interpretation and use of the data, the lack of coordination and coherence may reduce the advantages of the data sharing. These limitations are addressed and tentatively solved by the Data Act and the EHDS legislation recently adopted.
III. The impact of the data act on the development of new medical IoT
Medical IoT fall into the scope application of the Data Act (DA).Footnote 25 To clarify how the DA will affect the choices of manufacturers, it is necessary to understand the rationale of this piece of legislation by comparing it with the structure and functioning of a medical IoT (3.1). Second, the DA’s functioning will be described, focusing on the data-sharing contract schemes and their applicability to IoMT (3.2). Finally, overlaps, clashes, and possible harmonisation of the DA data sharing involved subjects with the GDPR ones will be addressed (3.3).Footnote 26
1. The origin and the rationales of the DA and why it applies to the IoMT
The DA must be considered when discussing IoMT objects’ data-sharing practices for two reasons. First, it is the most general (ie, horizontal) regulation concerning data sharing and concerns both personal (health) data and non-personal data, as stated by Art. 1(1) and (2) DA. The DA aims to build up on the GDPR and Free Flow of Data InitiativeFootnote 27 data sharing principles and to apply them to data-reliant new technologies such as the IoT but also, in perspective, some kinds of AI. In the absence of a sectorial intervention, the DA will be applicable to business-to-business (B2B) – more likely – and business-to-consumer (B2C) – less likely – health data-sharing scenarios among a set of subjects. It is also noteworthy to point out that this data-sharing will be regulated through contractual agreements.Footnote 28 Second, one of the objectives of the DA is to make available “[…] product data and related service data to the user of the connected product or related service” (Art. 1(a) DA). Product data is generated by a connected product, which is none other than an IoT object.Footnote 29 In fact, Article 2(5) DA describes the “connected product as ‘[…] an item that obtains, generates or collects data concerning its use or environment and that is able to communicate the 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.”Footnote 30 The DA definition is more detailed concerning how the IoMT works while connected to other IoTs, sockets or the human body and the choices for it to be accessed. Because of the generality of this definition, an IoMT as well, such as a wearable heart monitor device, is a kind of connected product.
Regarding the technologies considered, the DA considers the AI, especially when it deals with related service data, which are generated by “related services.” The definition considers three aspects: first, the service is integrated in some way into the product (eg, by being downloaded); and second, “its absence would prevent the connected product from performing one or more of its functions”; and third, “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.”Footnote 31
2. The DA framework
To explain the DA’s application, it is necessary first to describe the subjects involved in the data sharing and, secondly, to analyse the structure of the future data-sharing contracts based on the DA itself.
(a) Who is who? The data-sharing subjects
The subjects involved in the data-sharing contracts are mainly three.
The first is the user, who can be a consumer or a professional. Article 2(12) DA states that the user is either a natural or legal person “that owns a connected product or to whom temporary rights to use that connected product have been contractually transferred, or that receives related services.”Footnote 32 However, in the framework of IoMT, it is unlikely that the patient/consumer using an IoMT or MD software has the knowledge, resources and initiative to enter into a data-sharing contract. It will be more likely that the data-sharing contract will be negotiated by a professional, such as a doctor, or a health facility that purchased or rents an IoMT object (such as a smart IoMT for a distance heart monitoring object) or related service-MD software (such as an AI-based image diagnostic application for tumours).
The second is the data holder. Article 2(13) DA describes it as “a natural or legal person that has the right or obligation […] to use and make available data, including, where contractually agreed, product data or related service data which it has retrieved or generated during the provision of a related service.” Following the previous examples, the data holder could be the manufacturer of the connected product, meaning the company marketing the distance health monitoring IoMT, or the developer of the related service developed, such as the AI-based image diagnostic application for tumours.
The last subject is the data recipient. According to Article 2(14) DA the data recipient is “a 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 a legal obligation under Union law or national legislation adopted in accordance with Union law.” Thus, the data recipient differs from the user and must act for professional (lato sensu) reasons. Besides, the data recipient cannot be a data holder, as it is specified that it must receive data from the data holder itself. It can be, though a third party who received authorisation from the user to ask for access to data to the data holder. This data recipient/third party can also act autonomously, but only if there is a legal obligation under EU or national law implementing the EU law. This last possibility seems to fit with the hypothesis of mandatory data sharing with EU institutions and bodies whenever an emergency arises.Footnote 33 Keeping the previous examples, the third party can be an MD or a software company that wants to develop new software applications that can be compatible with the heart-monitoring IoMT, such as e-wellness apps. As far as the second example, a medical devices company developing IoMT, such as radio or chemotherapy medical devices, might be interested in having access to the AI-based diagnostic program data to understand which kind of tumour is more frequent and how it is distributed among a target population, such as the hospital patients for which this software has been used for diagnostic purposes.
(b) The data-sharing contract schemes
Two kinds of data-sharing contracts are set in Articles 4 and 5 of the DA. The first one is characterised by the absence of any intermediary between the user and the data holder; the second one, instead, is multifaceted, as it requires a triangulation of contracts involving the user, the data holder and the data recipient/third party.
(i) The user and data holder. A relationship without intermediaries
In this scenario, there are two parties: the user and the data holder. The user who wants to access the connected product or related service data to develop another connected product or related service. This new connected product or related service must not be in competition with the original connected product or related service, according to Article 4 (10) DA.
In principle, the data holder should build the product or service to grant a sort of “accessibility by default and by design” principle, which is analogue to the “privacy by design and by default” principle in Article 25 GDPR. The data holder needs to grant access to the product data and related service data so that the user can access it freely, according to Article 3(1) DA. Furthermore, the data holder must, as a set of pre-contractual duties, inform clearly and comprehensibly about the qualities of data and data-cycle investing product generated data (Article 3(2) DA) and related services data (Article 3(3) DA).
If direct access to product and related service data is not possible, the user must send an electronic request form to the data holder. However, according to Article 4(1) DA, the data holder is obliged to make data available, including the metadata. According to the same article, there is a parallel between how a data holder and a data controller must give access to data according to Articles 12–15 of GDPR. In the DA context, Article 4(1) obliges the data holder to provide data to the user “without undue delay, of the same quality as is available to the data holder, easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format and, where relevant and technically feasible, continuously and in real-time.”
In line with the proposal, according to Article 4(5) DA, the data holder cannot ask for a disproportionately high amount of information to identify the user and also take advantage of it to infer information about its economic situation, according to paragraph 13 of the same article.
DA includes an extended list of mutual duties and obligations of the parties, to rules concerning intellectual property protection and the right to lodge a complaint. The contract between the data holder and the user is the tool through which reciprocal duties and obligations are listed. Both users and data holders may contractually restrict or prohibit accessing or further the sharing of data if, in this way, one can undermine the security requirements of the object, according to Article 4(2) DA. Further, a data holder’s duty is not to make the exercise of users’ rights difficult by using certain designs while suggesting options, according to Article 4(4) DA. Conversely, the user can’t take advantage of gaps in the data-holder technical infrastructure, designed to protect data from being accessed.Footnote 34 By setting duties of de facto good faith between the parties,Footnote 35 Articles 3 and 4 DA seem to imply that both the user and the data holder have the same contractual and negotiation power, especially as far as intellectual property, such as trade secrets, are concerned. This is confirmed by Article 13 DA, which sets the non-binding character of a contract as the clause if “its use grossly deviates from good commercial practice in data access and use, contrary to good faith and fair dealing.” Regarding intellectual assets protection, it is highly likely that by giving access to data and metadata, one might expose intellectual property rights such as trade secrets.
The last set of obligations concerns the right to lodge a complaint, defined in paras 3 and 9 of Article 4 DA. The paragraphs are similar in content, but the first refers to disagreements concerning the security restrictions mentioned in Article 4(2), while the second concerns the protection of trade secrets. In both cases, the right to lodge the complaint can be done by following the procedure in Article 37(5)(b) DA or by agreeing with the data holder to solve the issue with a dispute settlement body described in Article 10(1) DA.
The last relevant element is Article 4 DA’s explicit connection with data protection concerning the legal basis when the personal data collected are not the user’s.Footnote 36 The paragraph limits itself to pointing out that Articles 6 and 9 GDPR are left unprejudiced, as well as Article 5(3) of the E-privacy directive.Footnote 37 In connection with practical scenarios involving IoMT stakeholders, this aspect will be dealt with in-depth in Section 3.3 (Fig. 1).
Figure 1. The first data-sharing contract scheme. User – Data holder
(ii) Data holders, data recipients, user(s) and third parties. Triangular relationships
The second data-sharing scheme is more complex. According to Article 5 DA, the user can “share data with third parties.” Footnote 38 Article 5 DA describes two different sub-sets of data-sharing contracts corresponding to the dual definition of the term data recipient analysed in (a).
Article 5(1) DA describes the first subset of data-sharing contracts. In this first hypothesis, the user can ask the data holder to make data available to a third party/data recipient of their choice.Footnote 39 The alternative, instead, is that a data recipient/third party asks to get access to product/service-related data on behalf of the user to the data holder.Footnote 40 According to the definition of data recipient, there might also be another hypothesis, ie when the third party asks the data holder to get access to the data based on a national or EU law obligation. This last hypothesis seems to be connected to Chapter V, which mandates making data available to public sector bodies, the EU Commission, the ECB and the Union bodies in case of an exceptional need.Footnote 41
One of the differences between the articles concerns a subjective prohibition. Article 5(3) DA makes it impossible for the user to designate a gatekeeper within the meaning of the Digital Markets Act (DMA).Footnote 42 This is because whatever platform, cloud service provider, or another one from the list of stakeholders responds to the criteria of Art. 3 DMA, holds such an economic and technological power that it would take advantage to become a leader in secondary markets for connected products or related services while already being de facto dominant concerning certain connected products or related services.
Apart from these sub-sets of other contracts, Article 5 DA is similar to Article 4 DA regarding the mutual sets of “good faith” obligations between the data holder and the third party/data recipients. These are, for instance, the third party’s duty to respect the intellectual property assets (trade secrets) of the data holder.Footnote 43 But the third-party/data recipient also has a set of obligations towards the user set in Article 6 DA. Moreover, only if there is a data recipient can the data holder ask the data recipient to pay a fee, which will need to be calculated according to the fair, reasonable and non-discriminatory (FAIR) principles and exclusively in B2B contracts.Footnote 44
The remaining question concerns the contracts between the user and the third party/data recipient. In the first part of Article 5 DA, it is implicit the conclusion of a contract concerning the fair use of the data holder’s data between the user and data recipient for the creation of the new IoMT pre-exists the contract/agreement between the data holder and the data recipient. The content of this latter contract, described supra, includes mutual fairness clauses in the execution of the contract, clauses concerning IP and eventual restrictions of data sharing and dispute resolution clauses. However, one can also imagine the contract’s content that must exist between the user and the data recipient, even though it is not explicitly described in the DA. It might be similar to the data-sharing contract in some ways, but there are at least two different elements. The first set of these specific clauses is the project of the new IoMT or related service characteristics. Almost certainly, there might be clauses concerning IP rights management (eg, whether to try to patent a solution or not to keep it as a trade secret or to make a hypothetical AI-based medical software solution open-source). Moreover, if needed, there could be clauses concerning dispute resolution involving international private law rules. The second set of clauses pertains only to the second kind of contract described by Article 5, where the data recipient directly contacts the data holder for the data-sharing operation. Nevertheless, not only a previous contract on the realisation of the new IoMT or service might already exist between the user and the data recipient/third party, but also a mandate/representation contract. This can also exist in a separate document, but it will contain the formal authorisation of the user to the data recipient to ask the data holder to access the relevant data. It will be up to the national law to govern the rules of this contract of mandate/representation.
To sum up, these subsets of contracts hint at a triangular relationship (data holder, data recipient and user), but they all involve at least two separate contracts in which only two of the parties are directly involved. In the first hypothesis, there is a contract/request by the user to make data available to a data recipient/third party and a contract/set of mutual duties between the data recipient and the data holder as well as, most probably, a contract between the user and the data recipient. In the second hypothesis, the user delegates (through a contract) the third party/data recipient to ask a data holder for access to data. Even in this case, there should be a contract existing between the data holder and the data recipient acting on behalf of the user of which the user is not formally part (Figs. 2 and 3).
Figure 2. The second data-sharing contract scheme. User’s request – Data holder
Figure 3. The second data-sharing contract scheme. User’s request to the Data Recipient/Third party
3. Overlaps and clashes with data protection framework
After presenting the data-sharing contracts, it is important to verify how the different actors can be qualified according to the GDPR framework.Footnote 45 Despite the DA affirming that it safeguards the application of the GDPR,Footnote 46 also sharing some of its definitions,Footnote 47 there are doubts about the coordination between the GDPR and the DA. The EDPB and EDPS already characterised this relationship as potentially problematic in their joint opinion of 2022.Footnote 48
For IoMT device manufacturers, it is more useful to understand whether there is an overlap (even a partial one) between the GDPR’s and DA’s subjects not only for compliance reasons but also to understand better how to coordinate these two legislations and, if possible, to simplify the compliance process.
The DA’s user definition can partly overlap with GDPR’s data subject one. This is because the user can ask to access data that the product or the related service has collected and processed about themselves and other people. Starting from the data-sharing contract between the user and the data holder without an intermediary, in this case the user is generally the one who purchased, rented, leased or, in any case, has an immediate availability of the connected product or the related service and uses it (eg for therapeutic purposes). If the user is a (tech-savvy) consumer and a patient using the IoMT, they can ask the data holder to make the data of their connected product or related service available. The kinds of data the consumer/patient/user can get access to are personal data (such as data related to health or biometric data), non-personal data (such as the logs connected to the functioning and activity of the product or related service), and the connected metadata. If the consumer/patient/user is the only one using the connected product or the related service, the personal data they get access to would be their own, and there are no data protection issues provided that the legal basis they have agreed on to have their connected product/ or related service process their data is lawful. An example is a patient who purchased a rehabilitative connected prosthetic limb (connected product) or who needs to use some exergames based on augmented reality for rehabilitation. In this case, there would be no need to worry about Article 4(12) DA concerning the GDPR legal basis as the user is the only data subject involved. Article 4(12) DA needs to be applied in the case of the user/patient/consumer only if someone else used the device.Footnote 49
There is a significant difference, instead, for the application of Article 4(12) DA if the user is a professional. The case could be of a doctor or a university hospital using a medical device, which could be a connected product (IoMT) or a related service. Let us take the example of a CAT-SCAN operating in a hospital on multiple people every day per year. In this case, both the data holder and the user are already joint controllers under Article 26 GDPR for the data processing linked to the healthcare service.Footnote 50
When looking at the data processing envisaged in the DA, the role of the data controller could be shared among different subjects. The first data controller in chronological order is the data holder. The data holder can be the manufacturer of the connected product,Footnote 51 as well as the provider of the related service.Footnote 52 Then, as far as Article 4 DA is concerned, the user can become a data controller for this further processing operation. If the user is a professional, to ask for the re-use of personal data, they will need a legal basis according to Articles 6 and 9 GDPR. Depending on the contractual strength of the user and the context of the data sharing contract, it is not to be excluded that the user can become a joint controller of data according to Article 26 GDPR. Following the previous example, the data gathered from the CAT-SCAN can help the university hospital researchers to develop a new and more performing software for IoMT software to recognise specific kinds of cancer.
In the case of Article 5, things are more complex as the third party/data recipient is added as a new data controller for further data processing activity. The data holder coincides with the original data controller according to the GDPR. Regardless of whether the data-sharing request comes either from the user or the data recipient/third party with the user’s authorisation, the data holder needs to alert all their data subjects (including the user) of the further processing of their personal data, which can be lawful only if based on Articles 6 and 9 GDPR and on the national implementation laws concerning the lawfulness of secondary use of health data. More nuanced is the position of the data recipient/third party. In Article 5 first part, the data recipient/third party comes into play after the formal request that the user has made. Nevertheless, the only contract regulated by the DA will be a data-sharing contract between the data holder and the data-recipient/third party. The data-sharing contract will give the data recipient the role of data controller. Then, the third party and the user can become joint controllers depending on the contract that will be set up to develop a new IoMT or related service and how much the user will be involved in the creation of the new product or service. This is even more likely when thinking about Article 5 second part. In this case, the data recipient contracts with the data holder after receiving the user’s mandate/representation contract. What could be the factors for a user to opt for Article 5 first or second part to represent their interests best, if not the technological capabilities and economic strength of the data recipient/third party? In both cases, the user will not directly control the data collected by the data recipient/third party.
If the user is also a data subject (eg a patient), there will be two coordinated activities regained the data processing. First, the user/data subject includes in the mandate contract to the data recipient/third party their consent to the processing of their personal data. Second, the data holder will also have to ask the user/data subject for their consent for the further processing of their data based on Articles 6 and 9 of GDPR and the national authorities’ interpretation of the secondary use of health data.
Another aspect to clarify is the position of the professional user (the university hospital to continue with the same example) towards the data subjects, which will need to decide whether to consent or not to further data processing. In case the privacy policy of the professional user does not encompass this specific kind of secondary use, the professional user might use the legitimate interest basis.Footnote 53 Otherwise, if it is a private entity, it will have to contact again the data subjects which might be using the IoT. This further data processing coincides with the data sharing contract in DA’s terms, which the user will not be part of, according to Article 5 DA. According to Article 4 DA, qualifying the professional user in GDPR terms might be easy. Keeping the examples of a contract between a university hospital and a manufacturer. In this case, the hospital is already the data controller of at least some categories of personal data of the data subjects/patients. In this case, it might need to update its privacy policy and clarify which kinds of secondary uses can carry on with patients’ data. For this reason, it might include personal data extracted from IoT devices that are lent to patients for rehabilitation purposes (Table 1).
Table 1. Translating the DA framework according to the GDPR interactions.
IV. The data-sharing through the European Health Data Space framework
The constellation of actors presented above is not completed, as some additions should be made based on the recent proposal for a European Health Data Space (EHDS).Footnote 54 The regulation aims to provide “a common space where natural persons can easily control their electronic health data. It will also make it possible for researchers, innovators and policymakers to use this electronic health data in a trusted and secure way that preserves privacy.”Footnote 55
As mentioned above, the EHDS regulation does not aim at amending and substituting the GDPR legal framework for health data. In the project of the European Commission, the EHDS aims at adapting and interpreting the GDPR to the specific needs and challenges of health data. In particular, the EHDS regulation seeks to complement the rights provided by the GDPR, addressing two main perspectives: first, the primary use of health data, where the provisions seek to facilitate the reuse of health data by consumers, ensuring portability across health service providers and increasing competition among service providers. The proposal introduces several improvements regarding health data management, such as the design and development of electronic health registries and the interoperability of electronic health record systems across the EU. Moreover, the EHDS Regulation envisages a set of rights for the data subject concerning their personal electronic health data, particularly the right to access “immediately […] free of charge and in an easily readable, consolidated and accessible form.”Footnote 56 To enhance the possibility of achieving the primary use of data and, in the case of cross-border services, the regulation mandates the European Commission to establish a central platform for digital health to provide services and facilitate the exchange of electronic health data.Footnote 57 This approach would overcome the difficulties that emerge in the provision of cross-border healthcare and the fragmented digital standards applicable to health services granting the possibility to data subjects to access their own electronic health data.Footnote 58
Second, the EHDS regulation establishes the legal framework for the secondary use of health data in the EU. It should be underlined that Article 71 EHDS allows the possibility for natural persons to opt out of the secondary use of health data, thus potentially reducing the relevance of the data set made available from data holders. Still, the possibility to access the available data is an added value provided by the procedure set up by the EHDS. Moreover, the secondary use of electronic health data is linked to different purposes, ranging from scientific research to the innovation of new products or services. Article 53 EHDS lists six potential justifications for processing health data for secondary purposes, though not all are uncontroversial. In line with the main focus of this article, the following sections will focus on the rules the EHDS lays down for the secondary use of health data.
One of the first discrepancies emerging when looking at the definitions provided by the EHDS and the GDPR is the one of health data. The type of data covered by the EHDS proposal is wider than the definition of health data given in Article 9 GDPR.Footnote 59 The data covered include both data that squarely fall into the category, such as electronic health records, genomic data and data on patient’s clinical records, but also include other categories of data that only indirectly can be qualified as data that only indirectly refer to health,Footnote 60 such as the “data on factors impacting on health, including socio-economic, environmental and behavioural determinants of health” as well as “healthcare-related administrative data, including dispensation, claims and reimbursement data” and also “data from wellness applications” as well as “aggregated data on healthcare needs, resources allocated to healthcare, the provision of and access to healthcare, healthcare expenditure and financing”.Footnote 61 For instance, regarding data generated by wellness devices, it may be possible that these data can become health data if they are processed to identify specific health conditions or if they are processed together with other data concerning health.Footnote 62 An example would be the data collected by a wellness device regarding the physical activity of an individual that may become health data if they are connected with the medical prescriptions of a doctor regarding strategies to reduce the level of cholesterol. As is underlined by an evaluation of the proposal by the EDPB and EDPS,Footnote 63 the quality requirements and characteristics of the health-related data generated by wellness applications are lower than those generated by medical devices.
This wide concept of health data is crucial for the secondary use of data,Footnote 64 which should follow a specific process. A preliminary step is the creation of the national dataset catalogueFootnote 65 that includes the source and the nature of the electronic health data hosted by entities that offer services or perform research in the health or care sector and qualified as health data holders in the regulation. In this case, the definition covers both public bodies, such as hospitals, research centres, and agencies, as well as developers and manufacturers of IoMT and wellness applications.Footnote 66 The body in charge of receiving this information and setting up the national dataset catalogue is the newly created Health Data Access Body (DAB). The DAB is an independent authority set up at the national levelFootnote 67 to moderate access to such datasets for health data users.Footnote 68 Health data holders must inform the DAB at the national level, following the rules regarding the minimum information elements describing their datasets.Footnote 69 This first part of the procedure also considers the intellectual property rights and trade secrets that may apply to the datasets: Article 52 EHDS Regulation requires that DAB shall take measures to protect the rights of the health data holders. The legal basis for the data processing carried out by the data holder to share the data with the DAB is Article 6 (1)(c) GDPR, namely the fact that the “processing is necessary for compliance with a legal obligation to which the controller is subject.” At the same time, the EHDS also fulfils the requirements set for health data processing, namely Articles 9 (2) (i) and (j), as the processing is necessary for archiving purposes in public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) based on Union or Member State law.Footnote 70
The second step in the procedure is the data request by the health data users. It must be underlined that the health data user definition does not converge with the user definition in the Data Act, as the EHDS defines health data users as any natural or legal person who can justify access to electronic health data for secondary use. They can submit two types of requests: a data request or a data access application, which should be based on the purposes listed in Article 53 EHDS Regulation.Footnote 71 The difference between the two types of requests lies in the type of data that can be accessed. After a health data request, the health data user will receive from the health data holder the anonymised and statistical version of the data,Footnote 72 without providing access to the data that have been used to answer the request.Footnote 73 In the second case, the data access application will be reviewed by the DAB, which will be in charge of deciding whether or not to grant access to the data and issue – in the affirmative case – a so-called data permit.Footnote 74 Here, the data user should also justify its request upon a legal basis among the ones in Article 6 (1)(e) and (f) GDPR, namely, the data processing is carried out in the public interest or for the purpose of the legitimate interests of the controller. In the first case, the EHDS indicates that the health data user should reference another EU or national law mandating the data user to process personal health data to comply with its tasks.Footnote 75 In the case of a data access application, it will be the data permit issued by the DAB that will define the conditions for the access, namely the types and format of electronic health data accessed, the purpose for which data are made available, the duration of the data permit, the technical conditions for the secure processing environment, as well as the fees to be paid by the health data user.Footnote 76
When the data permit is issued, the data user will coordinate with the DAB to access the data through a secure processing environment without data leaving that repository.Footnote 77 The health data user will become the controller, while the DAB will act as a data processor for the data made available under a particular data permit.Footnote 78
As a result, the process for managing health data in case of secondary use follows the steps presented in Fig. 4.
Figure 4. The data-sharing on the basis of EHDS
If we translate this process in the context of the IoMT, we need to clarify if and how manufacturers of the medical devices (or software) fall in the category of data holders and eventually can also qualify as potential health data users. As mentioned above, the definition of health data holders is broad enough to cover not only medical device manufacturers but also many other health applications that do not squarely fall into the “entities performing research” yet collect health data that can potentially support such research.Footnote 79 Thus, in principle, manufacturers of medical devices will be qualified as data holders and required to share their datasets with the DAB.
Looking at the side of the data user, the definition is even wider, as it only requires that the natural or legal person can fulfil one or more of the purposes listed in the aforementioned art. 53 EHDS proposal, without requiring that the data user belong to the sphere of healthcare. It is clear that the manufacturers of IoMT will be able to justify the purposes described in Article 53 (1) (e) (i) and (ii) EHDS. For instance, the purpose of training, testing and evaluating algorithms already refers to the application in medical devices, AI systems and digital health applications, contributing to public health or social security.
According to the definitions, a manufacturer seeking to develop an IoMT can fill a data access request to use the data previously collected by a different data holder, for instance, to train the algorithm used in the IoMT.Footnote 80 Thus, the data access request could avoid the need for the manufacturer to ask the consent of each data subject, as well as the need to identify a specific project to fit the conditions defined for the application of the “research exemption” already provided in Article 9 (2) (j) GDPR as legal basis.Footnote 81
Given the risks that may be associated with the secondary use of data,Footnote 82 the safeguards included in the EHDS should be strictly applied. In particular, the monitoring role of the DAB will be crucial. The evaluation of the data access application will require not only a mere formal check of the purpose of the secondary use among the ones listed in Article 34 EHDS, but also a substantial analysis of the documentation required in Article 45(2) EHDS.
Unlike the DA’s previous analysis, the EHDS does not envisage specific contractual agreements between the health data holder and the health data user.Footnote 83 The relationships among the actors involved are defined by the regulation itself, relying in any case on the GDPR framework. If we focus on the processing activities, Table 2 clarifies the role of each actor.
Table 2. Translating the EDHS framework according to the GDPR interactions.
V. Conclusions
This article aims to map the options available to manufacturers and researchers to develop new IoMT thanks to the new legislative framework provided by the Data Act and the European Health Data Space Regulation. These legislations start from the shareable assumption that the new medical and health devices can be designed, trained and developed by analysing and processing existing datasets. These activities imply that data will be accessed and transferred from the initial data controller to a data user. In order to protect personal data within this framework, additional rules and processes are envisaged by the DA and the EHDS.
Although data-sharing opportunities were not excluded from the pre-existing legal framework, provided by the GDPR and the MDR, the rules applicable were deemed by the European bodies as hampering innovation. Therefore, the DA and the EHDS were put forward providing alternative options that could enhance the possibilities for research and innovation.Footnote 84
Before detailing the pros and cons of the DA and the EHDS sharing processes, it is worthwhile to point out some similarities. The first one is ratione materiae: the EHDS and the DA can apply to the same sets of objects. IoMT devices are bound to become increasingly used in hospital and home environments. Another similarity is the centrality of the data holder, which is the first data controller according to the GDPR. This role affects the tasks and obligations of the data holder both in the EHDS and the DA. Under the DA, the data holder is the addressee of the request of the user and, at a later stage, the data recipient/third party.Footnote 85 In the EHDS, the data holder is obliged to make its dataset to the Data access body. Then the data user’s request to the data access body prompts the latter to transfer or allow access to the data requested to the data user. In both legislations, the data holder the point of reference for the secondary use of data.
When it comes to differences, they relate to the purposes for which an actor asks to have access to data and the means through which the transfer operation occurs.
According to the EHDS, the primary purpose of secondary use of data is research and, eventually, the development of medical and non-medical devices (ie, wellness apps not certified as MD). This justifies access to a much larger amount of data that can be made available to corroborate scientific research. This quantity of data is essential to design IoMT because the MDR requires medical devices to have clinical evidence that they are safe and do not harm patients through clinical data.Footnote 86 Another characteristic is that the EHDS provides for a more centralised procedure subject to administrative control. The administrative bodies in charge of exercising the tasks of the DAB require implementation by the states and coordination that will probably be slowed down in the early stages of application. The EHDS will likely require more years than the ones specified in the act for the transition to its full implementation. Once implemented, it will give easier access to more data than the DA.
Conversely, the DA has the function of horizontal regulation and has the purpose of creating IoT devices in general but also IoMT devices, given that there is no specific legislation on IoMT yet, and there will, probably, not be one in the future. Among the positive features of this legislation is the decentralised approach, stemming from the autonomous initiative of private actors or even public actors whenever acting with a private actor’s logic (eg, a university hospital which wants to develop a new IoMT or related service through its research teams). The main characteristic of the DA is the regulation through contracts. This is, in principle, a more flexible process than the administrative based one, ie, the EHDS one. However, the fact that everything is regulated through contracts might also add some difficulties in making the market truly competitive and enacting the principle of the free flow of data. Despite Article 13 DA affirms the invalidity of the unfair clauses, the drafting and the management of all these (almost) triangular relationships will be a hidden cost that not many users or third parties might be able to sustain, especially if the IoMT device is produced by an important medical device manufacturer. This unbalance could also emerge in the IP rights obligations that the user or third party/data recipient must abide by. Moreover, the user or third party must have access to several IoMTs or have the availability of an IoMT, which creates a considerable amount of data, to gather a sufficient amount of data to identify patterns and train an algorithm. Another variable which might negatively impact the success of the DA depends on the market strength, respectively, of the data holder, user and third party. The combination of the DA rules and GDPR’s principles concerning data portability are the only rules that can be applied directly also by IoMT manufacturers that are not dominant on a market and by medical researchers who want to market the result of their studies. Hence, as far as the time of writing, the Data Act is the most complete discipline, together with the GDPR, to be used to bring innovation to the IoMT sector.
Acknowledgments
The authors wish to thank Irene Aprile, Tommaso Crepax, Simona Demkova, Enea Parimbelli, Silvana Quaglini, Arianna Rossi, and Giuseppina Sgandurra for suggestions, comments and access to the repository on medical devices within the Fit4MedRob project. The research was carried out in the framework of the PNRR project “SoBigData.it: Strengthening the Italian RI for Social Mining and Big Data Analytics” (CUP B53C22001760006) (F. Casarosa) and "Biorobotics Research and Innovation Engineering Facilities" (IR0000036” –CUP J13C22000400007) (F. Gennari).
Competing interests
The authors confirm there are no conflicts of interest to declare.
Open access
