European Health Data Space – Is the Proposed Certification System Effective against Cyber Threats?

Abstract

The proposal for a European Health Data Space aims at creating a common space where individuals may control their health data in a trusted and secure way. The objective is not only improving healthcare delivery, but also enhancing the opportunities to use health data for research and innovation. To achieve these results, the proposal implements a mandatory self-certification scheme for European health records systems as well as for wellness devices and applications, setting up essential requirements related to interoperability and security. Although this is the first intervention that sets a horizontal framework that is mandatory for all Member States, the security requirements that are included in the legislative proposal are not sufficiently detailed and comprehensive. Given that cyberthreats are increasing and security incidents affecting health data may potentially have an impact on the lives of patients, it is important that cybersecurity measures are adopted and implemented in the most effective way. The paper will analyse the European Health Data Space proposal pointing to the open issues and doubts that may be emerging and it will compare them with the proposed Cyber Resilience Act, identifying the issues that may be solved thanks to this horizontal regulation and the ones that instead remain open.

I. Introduction

The COVID-19 pandemic provided the worst-case scenario, clearly showing the difficulties emerging in achieving meaningful and effective health data sharing to facilitate biomedical research in Europe. However, practitioners and academic communities have already acknowledged this situation as problematic. The pandemic provided a more substantial justification to push forward the EU Commission’s plan to create a common European Health Data Space. The initial plan was presented in early 2020 as one of the pillars of the European Data Strategy, ¹ along with the Data Governance Act ² and the recently adopted Data Act. ³ The overall strategy aimed at providing new avenues for the use of data and developing a common data space where data can be accessed and shared safely and securely. ⁴

According to the view of the Commission, the data space would provide a framework where health data would be stored, managed and operationalised to contribute to research developments, overcoming the challenges of limited data interoperability, fragmented rules for access to data for research, and barriers on individuals to exercise access to and control over their health data. ⁵

The European Health Data Space Regulation (EHDS) proposal was then presented in May 2022 to set a benchmark for other areas of law and jurisdictions. ⁶ The EHDS proposal addresses two challenges: on the one hand, the need to expand the use of electronic health data to deliver healthcare to the individual from whom those data were collected, and on the other hand, the need to improve research, innovation, policy making, patient safety, personalised medicine, official statistics or regulatory activities. The first set of purposes are qualified as primary use of health data, while the others are secondary use of data.

Although the number of contributions addressing the risks and issues associated with the secondary use of health data has steadily increased since the first presentation of the EHDS proposal, ⁷ less attention has been devoted to the analysis of the rules applicable to the primary use of data, ⁸ and in particular to the cybersecurity requirements defined in the EDHS proposal. ⁹ This contribution aims to fill this gap by focusing on the rules applicable to electronic health records systems and those applicable to wellness devices and applications that, according to the definition in the EHDS proposal, guarantee interoperability with electronic health records systems. ¹⁰ Although relevant, the security requirements envisaged by the legislative proposal are insufficient to safeguard the cybersecurity of electronic health data collected and stored in the Electronic Health Records systems. This is due to the narrow perspective adopted by the EHDS proposal only towards the confidentiality perspective, disregarding the integrity and availability of networks and data. Moreover, not only no ex-ante assessment of compliance with the essential requirements is envisaged, but in the case of strict interpretation, wellness devices and applications may not be subject to monitoring and corrective obligations in the case of potential risks and incidents that may affect the health and safety of patients. This negative evaluation can still be tempered, but coordination is crucial.

The contribution will initially address the rules applicable to Electronic Health Records systems, Section II, and to wellness devices and applications, Section III, highlighting the main critical issues emerging from the cybersecurity perspective. Section IV will then provide some tentative solutions thanks to the coordination between the EHDS proposal and the co-eve Proposal for a Regulation on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act – CRA proposal), showing that the latter may have the opportunity to solve at least part of the mentioned critical issues. ¹¹ Conclusions will follow.

II. The evolution of Electronic Health Records Systems

The Electronic Health Records (EHR) system was put in place in 2008 to enhance the shift of patient documentation from paper to digital format, with the final objective of making the EHR accessible throughout Europe and strengthening the protection of citizens’ health. ¹² EHR systems have several benefits, including reducing errors, improving patient safety, better communication, and potentially reducing costs. ¹³ Truthfully, the EHR system has passed through an initial cumbersome process of transcribing the existing medical data until it is collected and managed on paper and entered into an electronic format. This first step required quite an adaptation effort, not only regarding adopting new legal rules and provisions applicable to medical data collection and storage but also an investment in the training and education of all medical practitioners. ¹⁴ The second step was setting up a technical and legal framework that would allow the sharing of the gathered medical data by the different actors (ie patients, healthcare providers and health insurance companies) for processing and communication. The EHR is qualified as a comprehensive medical record, or similar documentation, of the past and present physical and mental state of health of an individual in electronic form and provides for ready availability of these data for medical treatment and other closely related purposes. ¹⁵ Given the sensitivity of this broad set of information, it must be safeguarded from the data protection perspective. ¹⁶

The European intervention in this area was initially carried out using Recommendations, which set the common principles to be implemented at the national level. ¹⁷ The last recommendation issued by the Commission was then devoted to identifying a standard exchange format ¹⁸ and aimed at facilitating the cross-border exchange of EHR by indirectly supporting the introduction of interoperable EHR at the national level. Although a system of voluntary cooperation among Member States exists, thanks to the eHealth network and the eHealth Digital Service Infrastructure, ¹⁹ the information systems used at the national level for recording, retrieving and managing health records were deemed incompatible due to varying formats and technical standards. The lack of interoperable standards was considered one of the significant barriers to accessing health personal data. ²⁰ The 2019 Recommendation was another effort to solve this problem, providing a set of principles governing the access and exchange of EHRs, baseline technical specifications and a coordinated process to elaborate the format further. Among the principles, data security is also included to safeguard data transmission across different national infrastructures. In particular, to protect the integrity and confidentiality of personal data, EHR systems should incorporate security measures, such as auditing and archiving of access and backup mechanisms. ²¹

The baseline for the European EHR exchange format described in the Recommendation is then developed in the EHDS proposal, where Article 6 allocates explicitly the power to the Commission “to lay down the technical specifications for the priority categories of personal electronic health data […], setting out the European electronic health record exchange format.” ²² Then, according to Article 14 of the EHDS Proposal, the EHR systems intended for the primary use of electronic health data should comply with a mandatory certification scheme based on the set of requirements identified in Article 17 of the EDHS Proposal and subsequently specified in the Annexes.

The essential requirements listed in Annex II of the EHDS proposal are the baseline for the manufacturers of EHR systems. Among them, a specific section is dedicated to (cyber)security issues. The security perspective adopted in the EHDS proposal follows the principles defined in Recommendation 2019 on the standard exchange format for EHR. The security requirements mainly focus on preventing unauthorised access to electronic health data, requiring the adoption of reliable mechanisms for identification and authentication of health professionals, allowing different access rights depending on the specific role and supported by digital signature. ²³ Interestingly, the EHR system should enable patients (ie data subjects) to restrict access to electronic health data, except for emergencies. These measures align with the security-by-design perspective envisaged in the General Data Protection Regulation, which requires that any data processing activity be adequately secured against unauthorised access or unlawful processing, accidental loss, disclosure, destruction or damage, and identity theft or fraud. ²⁴

Although relevant, these essential requirements are insufficient to safeguard the cybersecurity of electronic health data collected and stored in the EHR systems. For instance, these measures cannot provide any solution in case of denial-of-service attacks, malware attacks, or social engineering threats. ²⁵ For example, in case of a denial-of-service attack, users of an EHR system may not be able to access relevant data, services or other resources. This can be accomplished by exhausting the service and its resources or overloading the components of the network infrastructure. Such an attack, then, may affect the possibility of the patient or the healthcare provider (a doctor or a hospital) to provide the needed service, ranging from slowness in patient admission to risks to patient safety due to unavailability of IT services in emergencies. The abovementioned cases are all threats listed in the recent ENISA Health threat landscape as the most relevant threats after ransomware attacks and data threats. ²⁶ Such concerns were also confirmed by the evaluations of the Italian Data Protection Authority as regards the vis-à-vis the draft decree adapting the national EHR system. ²⁷ Remarkably, the Italian DPA affirmed that the legislation, to be acceptable from the data protection perspective, should (1) ensure minimum levels of security, (2) identify criteria for encryption and for the separation of data capable of revealing health status and sexual life from other personal data, (3) indicate the entity responsible for carrying out authorisation activities, management of privileges, and profiling of authorised subjects, (4) envisage technical measures to be adopted concerning sensible data subject. Moreover, the Italian DPA suggested that legislation should require manufacturers (a) to apply the principles of privacy by default/design in the design and development phases of EHR, (b) to adopt policies and procedures aimed at ensuring that the development of EHR takes place in compliance with secure coding guidelines conforming to best practices and there is constant monitoring, identification and replacement of third-party libraries presenting vulnerabilities that malicious attacks may exploit, (c) to adopt and maintain procedures to test, verify and regularly evaluate the effectiveness of technical and organisational measures to ensure the security of processing (including risks of homonymy resulting from software bugs, transcoding errors, or metadata association with documents, in the interactions between the various components of the systems with particular attention to integration tests of components and services).

Considering the risks identified by ENISA and the Italian DPA, the cybersecurity baseline of the EDHS proposal is insufficient. The EDHS proposal is focused only on the confidentiality perspective, bearing less if no attention to the other two dimensions associated with cybersecurity, namely availability and integrity. ²⁸

An additional element to consider is that the proposal envisages the need for further specifications of the requirements set in Annex II, and it leaves the task of defining “Common specifications” to the Commission under Article 23 of the EHDS Proposal. However, as affirmed elsewhere, ²⁹ the process for drafting Common specifications is neither transparent nor inclusive of the relevant stakeholders. Additionally, the EHDS proposal does not envisage the possibility of referring to standards, European or international, which may provide coherent, updated and comprehensive requirements. ³⁰

The security requirements are then subject to a certification process based on the self-assessment of the EHR system manufacturer. The latter will ensure that the product complies with all the obligations in Article 17 of the EHDS Proposal. The market surveillance authorities then oversee the process set up at the national level. ³¹ The authorities shall be able to exercise their powers of investigation and enforcement, ³² requiring the EHR system manufacturer to take preventive or corrective measures in case of risks or incidents. Although the self-assessment procedure is a way of enhancing the autonomy and responsibility of the manufacturer in complying with the essential requirements, such procedure has a degree of risk as regards the reliability of the evaluation. Given the potential impact of a misevaluation of cybersecurity compliance, it may be more reasonable to have a third-party assessment that could verify the compliance in advance.

III. Wellness devices and applications

The EHDS Proposal also extends its scope of application to the so-called wellness devices and applications (wellness D&A). The latter is defined as “any appliance or software intended by the manufacturer to be used by a natural person to process electronic health data for purposes other than healthcare, such as well-being and pursuing healthy lifestyles.” ³³ According to recital 35 of the proposal, wellness D&A become relevant as they can collect several types of data that can become health data if they are processed to identify specific health conditions or if they are processed together with other data concerning health. For instance, the data collected by a wellness D&A regarding an individual’s physical activity may become health data if they relate to 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, ³⁵ it is clear that the quality requirements and characteristics of the health-related data generated by wellness applications are lower than those generated by those qualified as medical devices. ³⁶

The purpose of including such wellness D&A within the scope of the EHDS proposal is to enhance their interoperability with the existing EHR system and allow the possibility of collecting and using the data produced by such devices and applications for healthcare purposes. However, given that not all wellness D&A gather data that may be relevant for healthcare purposes, the EHDS proposal does not impose a mandatory certification system. Instead, it leaves the manufacturers to decide whether to start the certification process. This will depend on the manufacturers’ interest in including their devices and applications in the infrastructure for the primary use of electronic health data. ³⁷

According to Article 31 of the EHDS Proposal, the wellness D&A that claims interoperability with the EHR systems should comply with the essential requirements laid down in Annex II, namely the abovementioned mechanisms to ensure the safe and secure processing of data and the prevention of unauthorised access; the identification and authentication mechanisms (including role-based control); the log records; the tools to allow natural persons to restrict access to personal data; the digital signature mechanisms; and the control over data retention periods. ³⁸ As mentioned above, these requirements are insufficient to safeguard security. Moreover, in this case, the certification system is based on a self-assessment conformity test, which is left entirely to the manufacturer of the wellness device, following the same rules that apply to EHR systems. ³⁹ The market surveillance authorities then oversee the system with investigation and enforcement powers. However, no ex-ante third-party assessment is envisaged in the certification process.

It is important to note that Article 31 (7) of the EHDS only mentions that the market surveillance authorities will check compliance with the essential requirements provided in Annex II. No mention of the extension of obligations related to handling risks and serious incidents, defined in Article 29 of the EHDS, is included. Will the manufacturer of wellness D&A have to inform the market surveillance authority about a serious incident that affects the device? Serious incidents are defined as any malfunction or deterioration in the characteristics or performance that directly or indirectly leads, might have led or might lead to the death of a natural person or serious damage to a natural person’s health; a serious disruption of the management and operation of critical infrastructure in the health sector. ⁴⁰ In this case, if applicable, the manufacturer of wellness D&A would be required to notify no later than 15 days after becoming aware or immediately after they have established a causal link between the application and the event (or the reasonable likelihood of such link). ⁴¹ If interpreted strictly, Art. 31 of the EHDS does not extend any obligation applicable to the EHR or wellness D&A apart from the need to ensure interoperability between the two; however, it would be an incomplete and, potentially, an inefficient system of control if, after having imposed the obligation to comply with the same standards of security, the wellness D&A will not have any subsequent monitoring and correction obligations in case of risks, or even incidents, affecting the health and safety of patients.

From the cybersecurity perspective, the current framework applicable to EHR and wellness D&A does not guarantee a sufficient level of protection: (1) essential requirements dedicated to security are focused only on the confidentiality perspective, disregarding the issues of integrity and availability of networks and data; (2) the monitoring activity of market authorities can only be exercised after the products are put on the market, with no ex-ante assessment of the compliance with the essential requirements; (3) in case of a strict interpretation of Article 31 of the EHDS, wellness D&A may not be subject to monitoring and corrective obligations in case of potential risks and incidents that may affect the health and safety of patients. This negative evaluation can still be tempered, thanks to the interplay between the EHDS proposal and another legislative document explicitly addressing the cybersecurity dimension, namely the Proposal for a Cyber Resilience Act. Thanks to the coordination between the two documents, some of the issues emerging in the EHDS proposal may be solved, while others remain open.

IV. The gap-filling role of the Cyber Resilience Act

EHR systems and wellness D&A must comply with the requirements in the proposed Cyber Resilience Act (CRA Proposal) regarding cybersecurity, defining pre-market and post-market obligations. This Regulation was first proposed in 2022 to address the risks and challenges of cybersecurity, which were already identified in the EU’s Cybersecurity Strategy for the Digital Decade presented in 2020. ⁴² The intervention was justified by the increasing awareness that malicious attacks can exploit vulnerabilities of any product connected online, eventually leading to negative consequences that spread across devices regardless of country borders.

The CRA aims to lay down horizontal rules for any “product with digital elements” available on the European market. Article 3(1) CRA Proposal defines the latter as “any software or hardware product and its remote data processing solutions, including software or hardware components to be placed on the market separately.” ⁴³ In the case of software, the CRA specifies that it qualifies as remote processing, ie “any data processing at a distance for which the software is designed and developed by the manufacturer […], and the absence of which would prevent the product […] from performing one of its functions.” ⁴⁴ Although the scope of application does not cover the products with digital elements that fall in the definition of medical devices, both EHR systems and wellness D&A can squarely fall in the definition of products with digital elements.

EHR systems and wellness D&A, thus, must comply with the requirements set out in the CRA Proposal regarding cybersecurity, defining both pre-market and post-market obligations. Before they are put on the market, all products with digital elements must be designed, developed and manufactured in such a way as to ensure an appropriate level of cybersecurity. ⁴⁵ Products must be delivered without known exploitable vulnerabilities and deployed in a secure default configuration. The basic requirements are set in Annex II and include, on the one hand, the security aspects and, on the other hand, the vulnerability handling aspects. Under the first category, the list consists of security by default measures, confidentiality protection, integrity and availability of the data and the networks, data minimisation measures, resilience measures (particularly against DoS attacks), safeguards against network effects, records on internal activity, and data portability. Additionally, products shall ensure protection from unauthorised access by appropriate control mechanisms and protect the confidentiality considering methods such as encryption.

Differently from the EHDS proposal, Article 18 (2) CRA Proposal acknowledges two possible standardisation techniques: on the one hand, to request by the Commission to the European Standardisation organisations to draft harmonised standards, and on the other, the adoption of common specifications, such as in EHDS proposal. However, this second option is only a fallback situation if the first one is not accepted. The first option is more reliable and transparent, as the process envisaged for adopting European Standards is based on consensus, openness, transparency, national commitment and technical coherence principles. Moreover, it also includes the possibility to involve stakeholders and experts from industry, associations, public administrations, academia and societal organisations. ⁴⁶

The technical documentation that manufacturers should prepare before the products are put on the market should contain an assessment of cybersecurity risks and describe the means used by the manufacturer to meet the essential cybersecurity requirements and mitigate the risks. ⁴⁷

To receive the declaration of conformity, manufacturers should follow conformity assessment procedures, ⁴⁸ proving that their products comply with the abovementioned requirements. Depending on the class of risk of the product, the type of conformity assessment may vary, ranging from an internal control procedure to a conformity assessment based on full quality assurance. Internal control conformity assessment is only available for those products with digital elements that do not perform any of the functions listed in Article 6 (2). In particular, Article 6 (2)(b) of the CRA Proposal provides as one of the criteria the fact that “the product with digital elements performs a function which carries a significant risk of adverse effects in terms of its intensity and ability to disrupt, control or cause damage to a large number of other products or the health and safety of a large number of individuals through direct manipulation, such as a central system function, including network management, configuration control, virtualisation, processing of personal data.” Although wellness D&A will not fall under this category, EHR systems may fall under this category and be subject to the third-party conformity assessment procedure.

After this process, manufacturers may receive a declaration of conformity following the template in Annex IV and will be able to obtain the CE marking. The product is then subject to post-market surveillance controls by specifically defined authorities, which can take all appropriate corrective actions to bring it into compliance, withdraw it from the market, or recall it within a reasonable period. ⁴⁹

It is important to note that in the case of becoming aware of exploited vulnerabilities or incidents having an impact on the security of the product with digital elements, the manufacturer is obliged to notify the event within 24 hours to the national Computer Security Response Team (CSIRT), ⁵⁰ providing the most relevant information about the event, as well as the corrective and mitigating measures taken. ⁵¹ The information about the incident should also reach the product user to request the latter’s collaboration in the deployment of corrective measures; however, in this case, no specific timeline is set up. ⁵² According to Article 11 (2dd) of the CRA Proposal, ENISA has the role of setting up (and maintaining) a single reporting platform to collect notifications regarding vulnerability cases and incidents.

It must be highlighted that the interplay between the CRA and the EHDS proposals was already envisaged by the legislator, as in its Article 24 (4), the CRA proposal acknowledges that manufacturers of EHR systems and wellness applications and devices must comply with both acts. Therefore, the Article affirms there is no need to duplicate the technical documentation as the one drafted by the manufacturer will suffice to meet the obligations defined in the two acts. ⁵³ However, this coordination is only limited to the supply of technical information, but it does not extend to any other element in the procedure. Therefore, the conformity assessment will follow the rules defined in the relevant legislative act and will be carried out independently.

As a result of this analysis, it is possible to affirm that the CRA Proposal may solve some of the problems highlighted in the EHDS regarding cybersecurity issues. First, the CRA Proposal is more detailed and precise regarding the security requirements, the essential requirements to be adopted, and the vulnerability handling measures. EHR and wellness D&A also fall into the definition of products with digital elements so that such provisions will be applicable and complement the fewer present in the EHDS proposal, strengthening the level of protection. Additionally, it envisages the possibility of adopting European standards that are transparent and based on the participation of relevant stakeholders and experts. Second, the CRA proposal identifies a well-defined procedure in the case of security incidents or vulnerability exploitation, which will again apply to EHR systems and wellness D&A. However, it must be noted that the interplay between the two proposals may solve the risk of under efficient monitoring and control over wellness D&A. Still, it may duplicate the obligations for EHR system manufacturers. According to Article 28 of the EHDS Proposal, the manufacturer must notify two different authorities with different timelines and documentation required if the security incidents also qualify as serious ones.

One of the issues the CRA Proposal does not solve is the ex-ante control of the compliance with the security requirements. Although, in principle, the EHR systems may fall in the category of products with digital elements that are subject to third-party assessment, according to Article 6 (2) (b) of the CRA Proposal, the same Act relieves the manufacturers from this obligation, as Article 24 (4) provides that the conformity assessment will follow the rule defined in the EHDS, namely the self-assessment procedure.

V. Conclusion

According to ENISA, the healthcare sector is one of the prime victims of cyber attackers, and this was even exacerbated by the COVID-19 pandemic when patient data were subject to several ransomware attacks. ⁵⁴ Securing patient data becomes crucial when looking at the long-term strategy of the EU to set up a European Health data Space that will allow healthcare providers and wellness applications to share health data that will be accessed across the EU. The envisaged data space will be based on the health data collected in the EHR systems and the (interoperable) wellness D&A. Each includes several components allowing health records to be created, stored and retrieved. All the rules and procedures, processing and storage devices, and communication and support facilities must ensure that the data are protected from cyber-attacks that may hamper data confidentiality, availability and integrity.

Cybersecurity measures should then be adopted, following the design and development of both EHR systems and (interoperable) wellness D&A. The current EHDS proposal has the merit of addressing security, including requirements for EHR systems and wellness D&A. However, the current text of the EHDS proposal does not guarantee a sufficient level of protection in terms of security: the essential security requirements are focused only on the confidentiality perspective, disregarding the issues of integrity and availability of networks and data; the monitoring activity of market authorities can only be exercised after the products are put on the market, with no ex-ante assessment of the compliance with the essential requirements; and in case of a strict interpretation of Article 31, wellness D&A may not be subject to monitoring and corrective obligations in case of potential risks and incidents that may affect the health and safety of patients.

Analysed in an isolated manner, the current text of the EHDS proposal is insufficient to safeguard the security of the health data collected by EHR systems and wellness devices. However, this negative evaluation can be tempered when a more comprehensive perspective is adopted, and the coordination between the EHDS proposal and the CRA proposal is considered. This coordination effort is crucial to ensure that the detailed cybersecurity and vulnerability handling requirements defined in the CRA proposal will be applicable and, most importantly, complement the fewer ones included in the EHDS proposal. Still, the interplay between these two legislative proposals may increase complexity as in the case of security incidents that are also serious incidents, the manufacturer will have to notify two different authorities with different timelines and documentation required.

Both Acts are still in the legislative process, but some changes are still feasible. It will be crucial that the European legislator considers the interplay between the two Acts and evaluates if any modification in one of the two affects, negatively or positively, the overall level of cybersecurity for the envisaged European health data space.