Medical devices, data protection, and cybercrime: the three challenges of new software

Software embedded in medical devices or stand-alone software qualified as MDs are among the products that, more than others, will be affected by the new MDR. Not only - as mentioned in the article "Apps and telemedicine in view of the new MDR" - many software that are currently not classified as medical devices will fall under the scope of the new Regulation, but the risk class of many software that are already MDs will increase. 

Great challenges of the future

But the challenge for software is much greater today. In fact, the general objectives to which MDs must respond have always been "performance efficiency" and "medical devices safety", taking into account the risk/benefit ratio. Aspects reiterated in point 1 of Annex I of the MDR, which states that: “Devices shall achieve the performance intended by their manufacturer and shall be designed and manufactured in such a way that, during normal conditions of use, they are suitable for their intended purpose. They shall be safe and effective and shall not compromise the clinical condition or the safety of patients, or the safety and health of users or, where applicable, other persons, provided that any risks which may be associated with their use constitute acceptable risks when weighed against the benefits to the patient and are compatible with a high level of protection of health and safety, taking into account the generally acknowledged state of the art.”

For software that falls under the notion of medical devices, these two objectives have a broader scope: security and effectiveness must intertwine with cybersecurity and data security aspects. Let's start with the first.

Cybersecurity

In recent years, in fact, the increase in processing capacity and the diffusion of software, supported by the availability of increasingly performing communication networks (Internet and mobile), have led to the definition of "cyberspace" understood as the virtual perimeter within which data and information generated by objects, people and systems circulate. It follows that today all software, being part of the virtual space, can be subject to violations from the outside. This is strongly relevant for medical devices for which an undetected or unmanaged external violation can compromise the effectiveness of the medical device and therefore the safety of the patient. There is no doubt, therefore, that it is no longer sufficient to guarantee the "inherent" safety of the software, but it is necessary to pose the problem of its safety in relation to the external environment.

Since virtual space has no borders, the issue is certainly not only national or European, but also global. Suffice it to say that in September 2018 the Fda published the latest guidelines on the subject entitled "Fda should further integrate its review of cybersecurity into the premarket review process for medical devices" in which additional requirements were specified for the premarket phase to increase security from external attacks. In light of this, medical apps and data exchanges are at particular risk.

Data protection aspects

As far as personal data is concerned, it is certainly necessary to comply with the General Regulation (EU) 2016/679 (Gdpr). The software is in fact a medical device that - most probably - processes personal data. The designer and manufacturer of the DM will therefore not be able to ignore the requirements established by the GDPR. In fact, the Public Administration that purchases the software becomes the controller of one (or more) data processing activities and must therefore act in accordance with the principle of accountability (art. 5 Gdpr), also by only buying devices that comply with GDPR requirements.

Consequently, the subjects who design and market the software must include, early in the design process of the MD, privacy by design security measures in order to give an assurance to the buyer that the features of the software purchased allow compliance with the Gdpr. In particular, the software must allow:

1) Authentication of the user who uses the device and accesses the data.

2) Protection of transmitted/exchanged data (according to the most recent evidence).

3) The impermeability to vulnerability scanners.

4) The possibility to install antivirus.

5) The obligation of complementary measures for the organizational structure that utilizes the software.

Therefore, these elements are now increasingly requested in tenders, where the manufacturer is called upon to declare that its software, in addition to being compliant with the Mdr, also complies with the Gdpr and the principles of privacy by design and by default.

What does the MDR say

Analyzing the new Mdr, its provisions seem to go in the direction of the aspects highlighted above. In particular in point 17 of Annex I, Chapter II (entitled Requirements regarding design and manufacture), where the specifications for the software are outlined. In fact, after having established the obligation to ensure repeatability, reliability and performance in line with the intended use of the software (point 17.1), it is stated that: “For devices that incorporate software or for software that are devices in themselves, 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.”

The following point goes further by establishing that: “software referred to in this Section 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).”

MDR and GDPR go hand in hand

More specifically, in point 17.4, the manufacturer is asked to consider the place where the software will be used, and also to indicate to the user (health facility) the characteristics that the context in which the software is installed must have in order to maintain its security. Point 17.4 states that "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." The issues to be considered, therefore, are not only those directly linked to the MDR, since it is necessary to look beyond, towards the GDPR and the even more challenging issue of cybercrime.