Jusletter IT

The decade from 2010 to 2020 saw significant advancements in electronic health and mobile health applications. The emerging concept of the Internet of Things expanded the scope of internet usage in healthcare. Governments, companies, and research institutions recognised that the internet could be utilised for more than just the exchange of electronic records between healthcare providers or online consultations between patients and physicians. It became clear that digitalisation in healthcare entails more than just adopting electronic health records and enhancing digital healthcare communication. The push for digitalisation is now directed towards advanced electronic decision support systems for physicians, tools for patient self-management, and electronic systems for telemonitoring care processes.¹ The concept of Ambient Assisted Living presented a „captivating technology that seamlessly integrates into ‚smart home environments‘ and aids individuals in their everyday lives.“². Within this concept, the monitoring of individual well-being, lifestyle counselling, diagnostics, and even treatment become constantly present and automated aspects of life. This integration is made possible by the interoperation of various household devices and wearable sensors. Some of these are classified as medical devices, while others are considered regular consumer products. AAL technologies merge single-purpose medical devices designed for specialised tasks, such as insulin pumps, glucometers, heart rate sensors, or oximeters, with general multi-purpose devices like personal computers, smartwatches, Wi-Fi routers, and internet networks. Prime examples of these practical applications include diabetes management systems³ or systems designed to monitor the well-being of the elderly. They also assist caregivers in addressing the repetitive behaviours of patients with dementia.⁴ With the rapid evolution of AI and machine learning, the potential for AAL is vast. Future systems might predict potential health challenges before they manifest, offer virtual companionship to the lonely, or even integrate with advanced robotics to offer physical support.

Much like other areas of medical technology, take-home medical devices and wearable sensors bring about concerns of potential malfunctions. Beyond just the mechanical failures of hardware, there‘s the risk of malware attacks or unforeseen software errors and errors caused by malfunctioning interoperability to consider. Another significant concern is the potential threat that the adoption of AAL technology poses to an individual’s privacy. In this context, AAL technology and wearable devices mirror challenges faced by other e-health technologies. After all, security and privacy issues are prevalent across all digital technologies employed in patient care.⁵

The AAL technology has been widely encouraged by governments as they perceived AAL technology as a part of their public health policy. AAL has potential to lead individuals to healthier lifestyle, to reduce negative impacts of diseases on one’s lifestyle⁶ and makes delivery of healthcare more efficient. The AAL technologies have also significant social policy context as it has potential to reduce inequalities in access to healthcare for vulnerable patients, elderly, or individuals living in remote areas and can potentially reduce a social isolation of the aged population⁷.

On the other hand, private sector and technological companies see AAL technologies as an opportunity to extend the functionality of the already existing multi-purpose technological solutions. The e-health and m-health is perceived as a vehicle for adding more users and increase the network effect of the existing eco-systems⁸ (an example, the smart functions of wearable electronics or smart-home devices).

The two different approaches lead to two different designs. The healthcare-centric design focuses on improving the functionality of individual medical device, or efficient treatment of a specific disease. AAL is seen as an extension to the system of healthcare, with the objective of make healthcare system more efficient. The individual devices necessary for functioning of AAL are designed and distributed as medical devices. The end user learns about the functionalities of the technology from his healthcare provider and often cannot purchase the technology without direct prescription/referral of the provider.

The IT-centric design focuses AAL as an extension of technological environment, usually provided by big technology firm. The objective is to offer the broadest possible range of features to the already established “ecosystem” of hardware and software products⁹. The individual devices are designed and marketed mostly as gadgets/consumer goods, which sometimes have certifications of medical devices. For example, „Apple Healthcare”¹⁰ product range includes software, hardware and cloud solutions to deliver personalized medical care without having a single product whose primary function is a function of a medical device. The end user receives the information about the functionalities of the devices from manufacturer and purchases the product on his own via commercial vendors.

The differences of the two designs have significant legal implications, because both frameworks have origins in different regulatory backgrounds. The safety and security standards on medical devices are arguably higher than safety and security standards of consumer products¹¹. The AAL environment blurs the border between regular consumer products and medical devices. It is important to ask, whether we the standards applied on medical devices shall be also applied on all elements of IT ecosystem that offers AAL features. Consumer driven healthcare empowers patient autonomy and provides patients with a choice¹², however the emergence of this trend needs to meet with the response of a regulator. Some states, like US¹³ and India¹⁴ have reflected this trend in their rules governing consumer goods with dual-use¹⁵ and marketing of consumer products for healthcare¹⁶. The European framework remains fragmented and as will be described in the next section, develops in two separate regulatory channels for consumer products and medical devices.

The second Article of the Medical devices regulation¹⁷ (MDR) defines the “medical device”. According to the definition, the main criterion to asses, whether an individual product shall be considered as a medical device is the intention of the manufacturer to design and sell product that can be used for medical purposes.¹⁸ The device, which has multiple possible uses in medical and non-medical areas shall fulfil cumulatively the requirements applicable to devices with an intended medical purpose and those applicable to devices without an intended medical purpose.¹⁹ The intended purpose is assessed by the manufacturer’s statements and promotions of the device on the label, in the instructions for use or in promotional or sales materials.²⁰ The MDR also defines accessory for a medical device, an article which, “whilst not being itself a medical device, is intended by its manufacturer to be used together with one or several particular medical device(s) to specifically enable the medical device(s) to be used in accordance with its/their intended purpose(s) or to specifically and directly assist the medical functionality of the medical device(s) in terms of its/their intended purpose(s)”.²¹

The general rules for medical devices that require interaction with their environment are described in the Art. 14 of the MDR. If the device is intended for use in combination with other devices or equipment the whole combination, including the connection system shall be safe and shall not impair the specified performance of the devices. Medical Devices that require interaction must be manufactured in such a way as to remove or reduce risks connected with reasonably foreseeable external influences or environmental conditions.²²

The Regulation on medical devices (EU) 2017/745 recognises devices that incorporate programmable systems and non-implantable active devices. Manufacturers shall set out requirements concerning and IT security measures, including protection against unauthorised access. Not all devices that are used for home-diagnostics, Active Assisted Living or as “fitness wearables” are marketed as medical devices. The manufacturer or distributor can choose whether he subjects himself to the regulation of the directive or not by marketing strategy. Devices that are not marketed as „medical devices“ are not subject to the Regulation 2017/745.

Software alone can be considered as a medical device.²³ The standards for “Electronic programmable systems” (i.e. devices that are based on software or contain programmable element) are set forth in the Art. 17 of the MDR. The manufacturers have duty to ensure repeatability, reliability and performance in line with their intended use.²⁴ The software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation. Software that is intended to be used in combination with mobile computing platforms shall be designed and manufactured taking into account the specific features of the mobile platform (e.g. size and contrast ratio of the screen) and the external factors related to their use (varying environment as regards level of light or noise).²⁵ Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

General Data Protection Regulation (GDPR)²⁶ is built around the legal principles of lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity, confidentiality and accountability.²⁷ Apart from the main principles, the data controller has to make sure, that the rights of the data subject stated in the third chapter of GDPR are respected. These rights revolve around transparency of the data processing, right to access to the personal data and transfer them to another controller, information on the sources of personal data, rights for objections, rectification and erasure. Biometric data and data concerning health data are considered as special categories of data,²⁸ which means that they need to be processed only under explicit consent that relates to defined purposes.

AAL technologies process special categories of data and often include systematic and extensive evaluation of patients based on automated processing, which means the necessity of data protection impact assessments.²⁹ The responsibility to ensure that all of the rights above are respected lies mainly on the controller of the personal data. The controller is any entity which alone or jointly with others, determines the purposes and means of the processing of personal data.³⁰ The processor³¹ is a provider of service that carries out processing of data on behalf of the controller without using data for other purposes. The efficient operation of a take-home device or a medical device integrated into an AAL (Ambient Assisted Living) system necessitates data processing by various controllers and data processors. In this scenario involving multiple participants, it is crucial to identify which party assumes the role of controller and which assumes the role of processor. This distinction is important to understand their respective liabilities for the security of the personal data involved.

In a healthcare-centric design, the healthcare provider who recommended, prescribed, or distributed the technology to the end-user (patient) is the ultimate controller of personal data. The manufacturers of hardware components, developers of software solutions, and providers of data services act as data processors. They have very limited legal bases for using the data for their own purposes. The end-user (patient) assumes the role of data subject, who has several rights with respect to the data controller, especially those granted by the third chapter of the GDPR. In this context, the healthcare provider bears the primary responsibility for ensuring the security of processing,³² for providing appropriate risk assessments³³ and for allocation of responsibilities. It can be assumed that a healthcare provider licensed in an EU country possesses the technical capability to select reliable processors. These processors should provide sufficient guarantees to implement appropriate technical and organisational measures. This ensures that the processing complies with the requirements of this Regulation and safeguards the rights of the data subject. In this scenario, the primary responsibility for the safety of patient data rests chiefly with the healthcare provider. The liability of other participants is confined to breaches of contractual obligations. For the patient, the liability for his own harm, it is limited to instances of patient’s non-compliance with instructions on how to use the technology properly.

In an IT-centric design, where the healthcare provider is absent or plays a peripheral role, the end user becomes the ultimate controller of the data. However, in this context, it becomes significantly easier for the provider of the technological solution to obtain consent to use the data for their own purposes. Here, the provider of the hardware/software solution assumes primary responsibility for the security of data processing and conducting appropriate risk assessments, whether acting as a data controller or a processor. It‘s noteworthy that the entire ecosystem of exchanging patient data is governed by GDPR in both scenarios. Yet, in the absence of a licensed healthcare provider, key regulatory mechanisms common in the healthcare industry in European countries – such as physician-patient privilege, standardization of medical information, protection of vulnerable subjects, surrogate consent, and decision-making support – are missing. On one hand, this reduces transaction costs, expedites the process of receiving the device for the end-user and makes patient less dependent on the healthcare provider. On the other hand, a scenario where the patient acts as the ultimate data controller assumes that the patient is fully capable of making informed decisions, both legally and in terms of actual understanding of what they are consenting to. The healthcare-centric setting can potentially identify gaps in a patient’s capacity to understand, decide, and consent – gaps that an IT-centric design simply cannot address.

The first Network and Information Security Directive³⁴ (hereinafter called also “NIS 1”) mandates member States to identify and regulate security measures of operators of essential services and providers of digital services. Operator of essential service is an entity that provides a service which is essential for the maintenance of critical societal activities via networked information systems and could be disrupted by a security incident.³⁵ A good example of operator of operator of essential service would be a large regional hospital that would equip its patients with medical devices to monitor their health status during their lives outside the hospital. The security requirements for this system are defined mostly in the chapter IV of the NIS Directive.

However, if the equipment used in AAL setting is provided by the tech-company as an extension of ecosystem of cloud-based solutions, it could be qualified as a digital service and regulated under the standards of the chapter V. Under this framework, itis was also possible that standards of both chapters must be achieved if a medical device provided/prescribed by a healthcare provider but integrated in a network that uses solutions of a commercial consumer platform. The “NIS 2” Directive³⁶ broadens the scope of its predecessor, “NIS 1”, to cover a wider range of sectors and entities and includes also certain pharmaceutical companies and producers of certain medical devices. The factual impact of the “NIS 2” Directive on AAL platforms is yet to be seen, but it can be expected, that most AAL solutions that did not fall under the scope NIS 1 directive will remain outside of the scope of “NIS 2” Directive as well. The improvement might be seen in emphasis on more complex approaches to security of networked solutions that are integrated into formal healthcare provision.

It is plausible to presume that a significant portion of Ambient Assisted Living (AAL) platforms will fall under the purview of the proposed EU AI Act.³⁷ This legislative proposal endeavours to establish a uniformed framework governing the conception, implementation, and utilisation of artificial intelligence (AI) technologies. In the context of AAL solutions, which will very likely tend to incorporate AI in order to improve their functionality related to health, well-being, and routine activities, certain specifications of this proposal become exceedingly pertinent. Depending on their inherent functionalities, AAL systems may be categorised as ‚high risk‘, particularly if they have a direct bearing on health, safety, or foundational human rights. For example, an AAL system that employs AI for the monitoring of vital signs or the dispensation of medication could potentially be classified as ‚high risk‘ due to the consequential ramifications of any operational aberrations. On the other hand, the strict regulatory framework of high risk AI solutions may lead developers to design their platforms without certain high risk functionalities and offering “limited risk” functionalities instead. For example, as chatbots with general advice who fall within the scope of proposed Art. 52 of the AI act, rather than chatbots that can warn about immediate threats to life and health under Art. 6 and following. The economic incentive to incorporate “high risk” functions might be too small in comparison with risks and liability. We can only speculate, that the division between “high risk” solutions that will be incorporated into formal healthcare and “limited risk” consumer solutions will remain even after AI Act comes into force.

The regulation matrix of take home devices incorporated into AAL platforms becomes more complex when we take into the consideration the national rules regarding physician-patient privilege and rules regarding keeping and accessing health records.³⁸ The application of national rules, however, is beyond the scope of this paper.

The form of liability for a product malfunction is different if a device is supplied via commercial channels based on consumers preferences and decisions or if it is supplied via healthcare system or on recommendation of a healthcare provider.

A consumer product that does not function properly or develops a mechanical flaw can be returned during warranty period. The producer is liable for any damage that is caused by the product³⁹ and relates to both material damage on property as well as immaterial damage to life and health. The directive does not however cover other forms of immaterial damage, such as damage to privacy, personal life or family life. The right of redress would be applied to the final seller in a contractual chain.⁴⁰

If a medical device was purchased directly by an individual, his claims towards the final seller for product malfunction and even injury might be similar to any regular consumer products, even if healthcare products and medical devices are explicitly excluded from certain rules regarding the consumer rights.⁴¹ However, significant proportion of medical devices handed out to individuals is procured by public entities, distributed by a healthcare system, handed out on basis of prescription. They often remain in the ownership of healthcare provider and are returned by the patient once they are not needed. In this setting any failure of a product is a potential medical malpractice. The medical malpractice claims may arise also form wrongly indicated use of a product that shows no flaw during the period of its indication. As opposed to liability for malfunction of a consumer product, the liability for medical malpractice includes also liability for all kinds of immaterial damage.

The privacy by design request incorporated in the GDPR means that the manufacturer or provider of any consumer product, including software product, has a broad responsibilities to protect the privacy and integrity of the consumers data. The secondary law of EU does not directly address the liability of an injury that could result from an information security breach. Directive (EU) 2019/770 on certain aspects concerning contracts for the supply of digital content and digital services does not apply on services regarding healthcare and does not cover medical devices. This means clear distinction between consumer and regulatory framework, as Considering the fact, that cloud-based services or software can be classified as a medical device.

Malfunction of medical device as a result of information security breach (regardless of intentional direct attack or unintentional interaction with other software solution) may lead to material and immaterial damage to the patient and will be considered as a medical malpractice in many scenarios. The healthcare provider usually bears objective responsibility⁴² for any equipment he directly or indirectly uses in the process of treatment. It is well documented, that threats to security of information systems used in healthcare consist more of internal factors than external⁴³ but the healthcare provider would be most likely liable for both of them.

It is clear, that take home devices and wearables that can serve dual purpose have two regulatory frameworks which lead to different outcomes in manufacturer’s or service provider’s accountability. It is unsurprising to see that the regulatory framework puts higher standards and more severe liability outcomes on the devices and solutions that are marketed as a medical devices. Unlike regulatory frameworks in the USA and India which reflect the consumer driven demand for IT solutions in healthcare by applying healthcare standards on consumer products, the EU secondary law tries to draw clear distinctions between the two regulatory frameworks. This however allows for a regulatory “forum shopping”. Unless manufacturers market their dual-use products as ‚medical devices‘, they can avoid the strict regulations applicable to medical devices in the European market, even if these products can interact with other medical devices or function de facto as medical devices

Most consumers are not likely to distinguish between a medical device that is certified as such and a regular consumer product. This regulatory environment is favourable for large tech companies which are able to market “health” applications connected to wearable sensors which are marketed as commercial products with relatively low responsibility for its actual functionality. On the other hand, the healthcare providers, who recommend and supply certified products to their patients for home treatment carry objective liability for every security incident, even if such incident was caused by interaction of regular consumer product.

This work of the author during the work on this paper is supported by Ministry of Education, Youth and Sports of the CR / Operational Programme Research, Development and Education, CyberSecurity, CyberCrime and Critical Information Infrastructures Center of Excellence (CZ.02.1.01/0.0/0.0/16_019/0000822) and “Systemic Risk Institute” number LX22NPO5101, funded by the European Union – Next Generation EU (Ministry of Education, Youth and Sports, NPO: EXCELES).