Legal aspects of digital health: some practical considerations

Digital health is expanding rapidly and will continue to do so in the coming years, albeit at different speeds in different sectors and areas in Italy. But what are the legal aspects to consider? What are the caveats to be aware of?

We talked to a real expert, lawyer Silvia Stefanelli, co-owner of the eponymous law firm, with whom we discussed many practical aspects that can provide interesting food for thought for those approaching these issues, whether they are doctors, patients, pharmaceutical or healthcare companies.

We are witnessing a great development in the field of digital health: what are the main issues that your firm is dealing with?

Our work in this area is definitely growing. In particular, we support the development of new digital healthcare products and processes: what is commonly called "innovation in healthcare".

More specifically, these are situations where healthcare processes - whether organisational or for service delivery - are changed through the introduction of digital systems in the doctor-patient relationship, or in the doctor-doctor and doctor-healthcare provider relationship.

The most common cases today are systems that enable telemedicine or telemonitoring through platforms connected to applications or devices that can be remotely controlled by physicians. These systems allow physicians to provide the service, monitor the patient remotely or otherwise assist them in their therapeutic decisions.

Then there are the so-called digital therapeutics, where a direct therapeutic action is performed on the patient, and apps that simply support the doctor's organisational activity (so-called digital support). These new models are now being introduced both in the public sector (often in collaboration with private providers) and in the purely private or insurance sector.

How do you approach an innovative healthcare project?

Almost everyone starts with an idea, usually for a system or software, and then calls our law firm to get the related documentation (contracts, website terms and conditions, data protection documents etc).

But in reality, this approach almost never works, and many projects run aground halfway through because of a lack of clarity about the route: it is like trying to build the outer walls of a house without having designed the layout and dug the foundations.

Instead, the correct course is to design the new process and then carry out a feasibility study analysing all the possible legal solutions (there are often more than one), as well as the economic, reimbursement and fiscal profiles of the service.

All these elements must be analysed together, not separately. Here is an example.

Suppose we want to offer a service through a platform that collects patient monitoring data through a device and that this data can then be analysed by the doctor through an application on his/her computer. The first thing we need to consider is whether this new service will operate in the public sector or in the private and/or insurance sector. Obviously, in all three cases, the legal and economic profiles of reimbursement will be different. For the sake of simplicity, let us assume that the system will operate in a purely private market.

At this point, it will be necessary to understand whether the entity operating the platform is acting as a direct provider of the digital health service (thus billing the patient directly), or whether it is instead offering a service to doctors who pay the platform and then bill the patient.

These are two completely different business models: in the first, you act as a healthcare entrepreneur; in the second, you provide a service to third parties who provide healthcare.

This choice has different legal consequences. For example, in the first case it is necessary to obtain a health authorisation (which raises different sets of issues in each Italian region – for example, only Emilia Romagna has regulated the authorisation of digital platforms in healthcare), while in the second case there are no specific administrative measures to be obtained.

And what are the other legal aspects to be taken into account?

Returning to the example above, with regard to the health requirements to be met by the platform, reference can be made to the Ministerial Decree of 22 September 2022 on telemedicine, which was issued for the public sector but can also be applied by analogy in the private sector.

Then there is the whole issue of protecting the data that will have to be processed in compliance with the GDPR. In this respect, it will be necessary to establish exactly what the purpose of the processing is (obviously diagnosis and treatment, but there could be other purposes such as research or marketing) and at the same time who is the data controller, who is legally responsible for the security of the data. It will also be necessary to draw up the contracts with the physicians, which may be different depending on the business model chosen.

Then there is an issue that has always been underestimated: the general terms and conditions attached to the digital service being offered. This aspect is highly relevant, because these conditions are in fact the contract between the provider and the doctor or between the provider and the patient. For example, the terms of service of an app used by the patient must also comply with the Consumer Code.

How is all this software being used today regulated?

This is a very complex issue.

Software used in healthcare will have to be qualified as a medical device if it performs a data processing function and if that processing has a healthcare purpose. In this case it must comply with the new EU Reg. 2017/745 on medical devices or EU Reg. 2027/746 on in vitro diagnostics.

On the other hand, if the software is not a medical device, it must comply with the General Product Safety Regulation: currently Directive 2001/95/EEC, which will be completely replaced by EU Regulation 2023/988 in December 2024.

There are also new regulations on the horizon: the Regulation on Artificial Intelligence, which will apply to all software that fall under the definition of AI according to Art. 6 of the draft Regulation, and the future Regulation on health data space.

The latter will not only expand the secondary use of data, but will also establish a very detailed regulation for medical records, aimed at ensuring the interoperability of data.

Last but not least: medical liability.

Yes, I know this is the aspect that everyone fears the most. Actually, the legal framework does not change: Law 24/2017, which regulates medical liability in our system, also applies to digital health.

However, it is important to remember that this is a law based on the analysis of health risks and the measures taken to manage them. It follows that in the field of digital health, what may change are the types of risks that must take into account the digital aspects in the provision of the service.

Can you give us examples of mistakes that can be made in digital health?

To give practical examples, one could imagine the scenario in which a doctor decides to provide a service via telemedicine when the patient's clinical situation would require a face-to-face visit instead, or the case where the service can be provided clinically via digital tools, but the patient is unable to use these tools correctly, thus invalidating the outcome of the clinical process.

Under this last aspect, it is important to emphasise that a new element appears here: the so-called patient eligibility. In other words, the doctor in charge of the patient who decides to provide the service with digital tools must ensure that the patient or caregiver is able to use the digital tools correctly. In this respect, new forms of patient 'education' will also need to be considered.

In general, liability profiles are closely linked to the subject who performed the act that caused the damage. For example, if a doctor instructs a person to use a digital instrument and the patient is unable to use it, the doctor will be liable. On the other hand, if the patient is able to use the digital instrument and has been properly trained, but uses it negligently, the patient may be liable.

Finally, if the damage is caused by a defect in the software, the software manufacturer will be liable.