The use of technology in the healthcare sector is rapidly expanding and continues to play a key role in the evolution of the range of healthcare services provided to patients. The use of robotics in surgical procedures represents one of the fastest growing areas of development in the medical devices industry, and has the potential to improve and transform the delivery of care, as well as the overall outcomes for patients.
One key area of development is the use of surgical robots for minimally invasive surgical procedures, and in this article we consider some of the main legal considerations associated with technology of this kind. There are currently a number of surgical robotic systems on the market, ranging from the da Vinci Surgical System (used for a wide spectrum of surgical procedures, including urology and gynaecology procedures), to Smith & Nephew's Navio Surgical System and Stryker's Mako Robotic-Arm (both used for orthopaedic surgery), and CMR Surgical's Versius surgical robotic system, which is used for laparoscopic procedures.
Key legal issues to be considered
The use of robotics for surgical procedures undoubtedly has a number of potential benefits, such as making clinical care better, faster and safer; however, equally, there are a number of risks that need to be considered by the manufacturer and supplier of the robotics, the purchaser, as well as by the clinicians and patients. We advise medtech companies, NHS Trusts and Foundation Trusts, and private healthcare providers in connection with agreements for the supply and use of robotics. Based on that experience, we have identified the following key legal issues that the parties should consider when negotiating an agreement for the supply and use of robotics.
Components of the robot
The introduction of the use of robots in surgical procedures has multiplied the number of possible "products"; for example, the actual robot itself is likely to fit within the traditional concept of a "product" and be classified as a medical device, but what about the software required to operate the robot? Is the software a component of the product, or is the software itself a medical device?
The manufacturer of the robot will be responsible for deciding whether the robot is a medical device and, if so, the classification of that device. Such classification will depend on the level of risk associated with the device; unsurprisingly, the strictest control is for products which present the greatest risk. Other factors will also be taken into consideration when classifying a device, including the intended purpose of the device, how long it is intended to be in use for and if the device is invasive/surgically invasive. These factors tie into the liability provisions that the parties should consider including in the agreement.
With regard to the software required to operate the robot, the European Commission's Medical Device Coordination Group (MDCG) issued guidance on 11 October 2019 to assist developers of medical software to determine whether their products are medical devices. The MDCG guidance (which is not legally binding) notes that the essential question is whether the developer intends the device to have a medical purpose. According to Regulation (EU) 2017/746 of the European Parliament and of the Council of 5 April 2017 on in vitro diagnostic medical devices, this includes the diagnosis, prevention, monitoring, prognosis, treatment or alleviation of a disease or injury. However, the first question to be considered is whether the software is "independent" of any other medical device, meaning can the software autonomously perform its function? If the answer is yes, then the software must comply with the regulatory regime for medical devices (the MHRA is the regulator of medical devices in the UK). If the answer to the first question is "no", the software is likely to be regarded as a component of the robot.
The parties should ensure that the agreement clearly identifies who is responsible for installing the robot at the customer's premises. Generally, the supplier will be responsible for such installation, as well as testing the robot after installation in order to verify compliance with the manufacturer's installation protocol and user specification.
Once installed, the robot will, in most cases, be used and operated by clinicians (either employed or engaged by the customer) when performing the patient's surgery; however, other customer personnel (e.g. nurses and theatre support staff) may also be required to use/handle the robot. The supplier should therefore ensure that before any customer personnel use/operate the robot, it provides appropriate training to ensure the safe and effective use of the robot. The supplier should assess the level of training required (theatre staff may only require basic product awareness training, whereas the clinicians are likely to require more detailed training), and the frequency of any refresher training.
Although the clinician will be responsible for the selection of the patient parameters (such as conducting a pre-op consultation and seeking the patient's consent for the use of the robot when providing their treatment), the parties may agree that supplier personnel will provide clinical support services. This may include uploading patient images on to the robot, and assisting with the technical settings (such as programming the robot) in preparation for the patient's surgery. The parties should also consider what information they will share in relation to patient outcomes, by way of example, what went well, and areas for development etc.
The parties should also take steps at the outset to clearly identify the surgical team and their respective responsibilities, as this is likely to help the parties assess the parameters of liability in the event that something should go wrong. Potential areas of risk include device malfunctions, device and instrument malfunctions (e.g. burnt/broken pieces of instruments falling into the patient), issues with the software (e.g. corrupted software / having to reboot the software), human error when uploading the software and/or uploading the patient images, and human error in using and/or operating the robot.
Whilst it is frequently difficult to clearly apportion legal responsibility for the harm caused to a patient because a claim occurs as a result of a series of connected events occurring during the course of care, rather than a single, catastrophic failure in the system of care, it is important that the risks and corresponding potential liabilities are fully understood and managed appropriately by each party, as this will assist the parties when determining who is liable if and when a claim is made.
Once the parties have defined their respective roles and responsibilities (including those of their respective personnel), they should consider whether the contractual obligations in the agreement reflect this understanding, including by way of warranties and indemnities, and whether each party's liability should be capped.
In order to ensure compliance with the General Data Protection Regulation (GDPR) and the Data Protection Act 2018, the parties should:
- ensure that data protection safeguards are built into the robot, such as creating an individual profile for each clinician with access to the robot. Each clinician can then protect their profile with a pin and will be responsible for creating a "case" for each patient;
- determine the respective roles of the parties, i.e. will the supplier be acting as a data controller or a data processor for personal data; and
- carry out a data mapping exercise to work out exactly what personal data is being used and in what manner, as well as the legal bases for doing so and the safeguards required to ensure that data protection rights are fully implemented.
The parties will then need to ensure that appropriate provisions are included in the agreement, which will be highly dependent on the data processing relationship between the parties. The most likely scenario is that there will be a controller to processor relationship, as the supplier will typically act on the instructions of the customer. In such circumstances, the GDPR places direct obligations on processors and specifies contractual terms that controllers and processors must include in their agreement. In the event that the parties determine they are each acting as controllers, then it would still be advisable to set out in the agreement their respective responsibilities in respect of the data.
Where the purchaser is a public body, it will need to consider its obligations under the Public Contracts Regulations 2015 (PCR). Where the PCR applies to the purchaser, there will be a presumption that the purchaser needs to undertake a competitive tendering exercise to appoint a supplier. The type of tendering exercise will depend on, amongst other things, whether the agreement is for the supply of robots or a fully managed system. Failure to comply with the PCR can have serious ramifications and therefore its application should be considered at the early stages of any project.
The NHS is currently undertaking market research into the robotic surgery market ahead of a planned national contractual framework due to be rolled out in 2020. The framework is expected to cover robotic surgery systems covering a wide range of medical procedures, including laparoscopic, orthopaedic, and general surgery. We will provide further updates on the proposed contractual framework once the NHS releases details of the outcome of its market research study.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.