1. Introduction

Problem statement and purpose of the paper

The advent of healthcare open collaborative platforms has given individuals the possibility to share knowledge to design, create and reproduce Open Source Hardware (OSHW)1 projects worldwide. Those involved in the design and creation of OSHW healthcare projects – such as makers and designers, often lack an outline of possible legal challenges that could arise during the development of these projects. Hence, the purpose of this paper is to map the common legal challenges of OSHW healthcare projects.

The paper first provides the background, defining and describing open collaborative platforms by giving three examples of healthcare-related platforms. A second chapter lists the common legal challenges of OSHW healthcare projects. Therein, key findings touch upon privacy and data protection, intellectual property, medical devices and tort law. The conclusion summarises the main findings and gives key recommendations. Finally, the Annex of this paper includes a Questionnaire containing key questions that ascertain the applicability of medical devices law for OSHW healthcare projects (Table 1), and an Infographic showing key recommendations for OSHW healthcare projects (Figure 3).

Table 1

Questions to evaluate MDL scope and applicability.

Questions to evaluate MDL scope and applicability

Personal Scope

(0) Manufacturer Are you providing goods in a business-related context?
The following elements may be taken into account:
  • How often are goods supplied? Frequently?
  • What are the characteristics of the product?
  • What are your intentions as a supplier?

* In principle, occasional supplies by charities or hobbyists should not be considered as to operate in a business-related context.
* If you or your entity operates in a business-related context ➔ answer to the questions (1), (2) and (3)
Material Scope

(1) Nature of the device Is the object in one of the following categories?
  • Is it an instrument?
  • Is it an apparatus or an appliance?
  • Is it a software?
  • Is it an implant, a reagent, or a material?
(2) Usage by human beings Is the item intended to be used by human beings?
(3) Principal intended action Is its principal intended action achieved not by pharmacological, immunological or metabolic means?
* If the answer is YES to questions (1), (2) and (3) ➔ answer to the question (4)
Core question

(4) Purpose of the device Is the item intended to be principally used for specific medical purposes?
[disease]
  • – Is it intended to make a diagnosis or a prognosis of a disease?
  • – Is it intended to prevent or predict a disease?
  • – Is it intended for monitoring, treat or alleviate a disease?
[disability]
  • – Is it intended to make a diagnosis or to monitor a disability?
  • – Is it intended to treat, alleviate or compensate a disability?
[injury]
  • – Is it intended to make a diagnosis or to monitor a disability?
  • – Is it intended to treat, alleviate of, or compensate an injury?
[anatomy]
  • – Is it intended to investigate the anatomy?
  • – Is it intended to replace or modify the anatomy?
[physiological or pathological process or state]
  • – Is it intended to investigate, replace or modify a physiological or pathological process or state?
* If the answer is YES to any of the questions under (4) ➔ consider applying the MDL requirements.

Methodologically, the paper aims at distilling overarching legal principles for the identified legal challenges, by drawing upon EU legislation. The objective of this paper is the mapping of legal challenges, hence the analysis is directed at establishing the common grounds thereof, rather than offering a matter-specific or case-specific study. Finally, to limit the paper’s scope to key legal aspects, medical ethics requirements or research ethics requirements will not be addressed. These are nonetheless worthy of being considered throughout the development process of OSHW solutions.2

2. Background

What are open collaborative platforms?

Increasing connectivity, combined with the democratisation of design and fabrication tools, has opened the possibility for individuals to collaborate in new digital environments. Collaborative innovation3 and digital social innovation4 are phenomena that have rapidly diffused around the world: multiple stakeholders progressively engage in sharing open innovation and create new projects, technologies and solutions through open collaborative platforms (Biasin & Kamenjašević 2020). These platforms are becoming a means to empower individuals to share projects and ideas online, and even co-create new products with other users around the world. There, a consortium of stakeholders may meet to work collaboratively, including individuals with healthcare needs and their caregivers, healthcare professionals, designers, engineers, developers, and makers (see Figure 1).

Figure 1 

The key stakeholders in open collaborative platforms in healthcare (Biasin & Kamenjašević 2020).

The objective of these platforms is fostering collaborative innovation online. Community and society as a whole benefit from this kind of novel interaction as these collaborations enhance and empower individuals to access healthcare solutions regardless of their physical location. This objective, therefore, supports the advancement of the United Nations (UN) Sustainable Development Goals (SDG) (United Nations 2015), namely the SDG n. 3 “Good Health and Well Being” – with particular focus on the Target 3.4: “By 2030, reduce by one-third premature mortality from non-communicable diseases through prevention and treatment and promote mental health and well-being”, and Target 3.8: “Achieve universal health coverage, including financial risk protection, access to quality essential healthcare services and access to safe, effective, quality and affordable essential medicines and vaccines for all”.

Examples of collaborative healthcare platforms

Many collaborative platforms have been initiated in the past few years, such as Thingiverse, Github, Hackaday, Wevolver, to name a few. They are places of digital social innovation (Bria et al. 2015), an example of how users can collaboratively work online. These platforms contain sections, topics or threads dedicated to healthcare solutions (Zahid et al. 2019). Interestingly, there has been a significant growth of health- and care- focused collaborative platforms, such as Careables.org5, Patient Innovation6, Makers Making Change7.

Careables.org is a collaborative platform launched in 2018 and funded by the EU H2020 Made4You project. It aims at fostering the participatory design of healthcare solutions through co-creation. It proposes an open and inclusive approach to healthcare based on digital fabrication, distributed manufacturing and collaborative making (Careables.org2020). In this platform, a user may upload documentation for customised healthcare projects in its ‘design for care collection’ which include projects ranging from mobility to self-care and indoor and outdoor installations.

Makers Making Change started in 2014 by the Canadian non-profit organisation Neil Squire Society. The platform’s objective is to connect makers to people with disabilities who need assistive technologies. The platform aims to enable everyone to publish and share open source assistive technology designs. Makers Making Change has a library containing an Open Source collection of Assistive Technology Solutions. It also provides for the possibility to build a given solution upon request via their network of ‘Volunteer Makers’ (Makers Making Change 2020).

Patient Innovation was launched in 2014, as a result of a multidisciplinary research project led by Catolica-Lisbon School of Business & Economics, in partnership with MIT, Sloan School of Management and the Carnegie Mellon University. Its objective is the design and sharing of user innovation in healthcare. Patient Innovation presents itself ‘as a platform and a social network that allows patients and caregivers to share their health solutions with other people’ (Patent Innovation 2020).

A common denominator across all these platforms is that designers, makers, healthcare professionals, and users share their knowledge to create healthcare projects for an individual’s healthcare need. Users and communities are enabled to collaborate online by using the advantages of new digital technologies. Knowledge is shared openly to maximise the spread of designs and project ideas worldwide.

3. Common legal challenges for OSHW healthcare projects

Context

Since the phenomenon of collaborative platforms and OSHW are relatively novel subjects in law and given the global reach of the platforms, it has become burdensome for the stakeholders to grasp the legal challenges they may face. Could makers and designers be held accountable for the misuse of an object that has been manufactured according to the information and instructions they provided on a collaborative platform? Or, what if someone gets injured from the use of the object shared on the platform? What if someone is injured by the object that has been manufactured following the indications provided on the platform? The following sections will try to illustrate those challenges with the objective of providing a set of considerations and legal principles that – although not providing definitive answers to these questions – may help OSHW stakeholders in navigating the relevant laws.

Privacy and data protection

The development of an OSHW project may entail the processing of personal (and also health) data of an individual.8 This may happen at different stages of design and co-creation of a project:

  • From an abstract idea to prototyping: when an individual (patient, or person with a special need) meets with a team of designers, engineers, makers with the support of a healthcare professional to explain his or her need, an amount of information relating to his or her health will likely be shared. This kind of information has to be processed according to the requirements foreseen by the law (such as the General Data Protection Regulations (GDPR - European Union 2016)). Similarly, when ‘FabLabs’ or a Makerspace organise thematic events to prototype specific objects in the presence of persons with specific needs, it is important to be aware that the processing of personal data may occur, and the requirements prescribed by the GDPR have to be respected.
  • Design of the OSHW healthcare project: While it is uncommon that a given OSHW project processes personal data, this might occur. To give an example, a healthcare solution that monitors heart rates or insulin rates (see Figure 2 – example of OSHW glucose monitor connected to a mobile app – NightScout9) is subject to data protection requirements as the heart rate or insulin level are health data (WP29, 2015).
  • Uploading the design documentation of an OSHW project: an open collaborative platform also serves as a hub to share ideas and documentation. When uploading a CAD file or instructions which contain information about the patient or the individual for which the solution is created, only the necessary information should be disclosed on the platform.
Figure 2 

NightScout Drip (GNU 3.0).

Privacy and data protection have to be considered for the development of OSHW healthcare projects. Each stakeholder should question his or her role10 and the legal basis11 for the processing of personal data. All operations, from prototyping to designing and uploading documentation on the platform, should take into account privacy and data protection laws. Personal data should be processed only if strictly necessary for achieving the purpose for which they are being collected, and only as relevant to such purpose.

Data should be processed in a lawful, transparent, and fair manner.12 The key stakeholders must put in place the technical and organisational measures that are necessary to ensure the security of the processing of personal data.13 Such technical and organisational measures must be aimed at ensuring the security of processing. Measures to ensure a level of security (for instance, the pseudonymisation or encryption of personal data) shall be appropriate to the risk and must be evaluated with regard to the characteristics of the solution to be developed.

Patients and individuals should always be informed14 of any processing of their personal data, deriving from an initiative, a prototyping session, or the upload of any personal information about him or her on the collaborative platform. Every stakeholder involved in the material development of a healthcare project should be aware that privacy must be taken care of from the first design steps of the OSHW project (data protection by design principle).15

Intellectual property rights

While developing a specific OSHW project, IPR-related questions will arise. Therefore, during the design phase, designers and makers should agree on the ownership rights, exclusivity, and licensing terms applicable to (1) the documentation that reflects the design of the hardware product, and (2) of the product that is manufactured by following that documentation.16

What concerns the documentation, designers and makers should often be aware of the international, EU, and national copyright laws likely applicable to such documentation released together with the specific hardware, their implications, and the duration of the protection in order to be able to adequately assess and choose licensing terms.17. To meet openness and the free-use goals, designers and makers should consider the use of copyright licences, such as Creative Commons (CC).18

Moreover, designers and makers should evaluate whether they meet the requirements to obtain patent protection to a hardware component manufactured on the basis of the mentioned documentation, as well as the desirability, implications, rights, duration, limitations, and fees of having patents applied to their OSHW healthcare project. If the patent protection is granted, they may, as a second step, license the hardware under terms that retain OSHW permissions.19 If they do not obtain patent protection, designers and makers do not strictly need to apply a hardware license to it, and everyone may use such hardware freely, as long as they respect any underlying third party patents, copyright, or other intellectual property rights.20

Liability

Some of the most pressing unanswered questions in the OSHW makers’ community are ‘Will I be liable if any damage occurs to a person’?, or, ‘What are the risks for a maker, a designer, a healthcare professional or a caregiver if something goes wrong’? This section lists and describes general issues to consider around liability for OSHW projects but specific answers would require legal advice on a case-by-case basis.

In the frame of OSHW co-design and co-creation through collaborative platforms, many stakeholders are involved – such as the categories illustrated in Table 1.21 They have different roles and responsibilities in the design and development of OSHW.22 Given the different contexts (i.e., commercial, non-commercial, household) from which they are operating, different liability frameworks may be applicable (DiDIY 2017).

An individual or a legal entity may be held liable under product liability law when a product is defective and when it causes personal injury to an individual. If the product is defective, the manufacturer23 might be held liable even if he or she has not been negligent in manufacturing that defective product (also known as ‘strict liability doctrine’).

However, the interpretation and application of product liability law may become challenging when makers and designers are involved. That is because, in theory, strict liability applies to products that have been industrially produced, when products were manufactured for sale or economic purposes or in the course of the producer’s business.24 This rule is therefore challenged by the novel role of makers and designers not entirely fitting in these traditional scenarios. In a do-it-yourself (DIY) environment, makers and designers may not be classed as regular sellers, instead (or also) they may be classed as hobbyists performing household activities (Daly 2016: 69; Kamenjašević & Biasin 2018: 62–64).25

At the moment, there are no clear rules for makers and designers nor significant EU case law in this regard (DiDIY 2017: 23). Nonetheless, as a general rule, strict liability rules should always be evaluated on a case-by-case basis, and these rules could reasonably be applied when an entity is a regular seller, rather than an occasional one (Kamenjašević & Biasin 2019: 24; see also Figure 3). Further on, tort law liability follows when a duty of care is breached, and damage or injury occurs. In order not to breach this duty of care,26 makers and designers should apply adequate standards of diligence, meaning that they shall not have a negligent behaviour27 in co-designing and co-developing their projects. Warranties and liability clauses may help as a mitigation tool to counterbalance responsibility of makers vis-à-vis the need of protection of users that want to try new OSHW projects which have been openly shared through a collaborative platform (Wang 2016). While it is true that usually OSHW licenses already include a section on warranty and liabilities (see Ackermann on TAPR OHL in 2009: 216), writing specific and proper warranties is recommended as a best practice (DiDIY 2017: 49; Kamenjašević & Biasin 2019: 23).

Figure 3 

Recommendations for makers developing OSHW healthcare projects.

Finally, collaboration via online platforms with a global reach adds another level of complexity to the common legal challenges on liability. Often, the aforementioned stakeholders (Figure 1) are located in different geographical areas. Sharing an OSHW project in various states may imply the applicability of the different liability laws foreseen at respective national levels, even if the person providing the OSHW project resides in a different state. Ultimately, depending on the facts and circumstances, the applicable law will be determined following the principles and rules of international private law.28 Criteria such as the place where the damage occurs, or where the intellectual property rights are protected may play a role in this evaluation.

Law on medical devices

Does the medical devices legislation apply to an OSHW project that has been shared on a collaborative platform? What should a maker do when he or she wants to reproduce an OSHW project from the design files shared on a platform?

To reply to these questions, we will bring the example of EU medical devices legislation (MDL) (European Union 1993; European Union 2017)29. A medical device is any device (or instrument, software, implant or any article) intended to be used for medical purposes. Medical devices can be of various kinds. They may range, for instance, from non-invasive devices (e.g. cervical collars, walking aids, wheelchairs) to invasive devices (e.g. tracheal tubes, long term corrective contact lenses) to surgically invasive devices (e.g. breast implants, prosthetic health valves). Medical devices may also be ‘connected-to-network’, such as insulin pumps, heart defibrillators and pacemakers.

The EU law classifies medical devices depending on the risks they may pose to patients and foresees specific technical requirements aimed at ensuring the safety of patients.30 The full application of MDL relies on the occurrence of a variety of factors. In the following are some key recommendations to preliminarily guide makers and designers in assessing the legal context of a device they are operating:

  • Identify the personal scope: makers and designers, when designing and producing a device, should question whether they fall under a definition of a ‘manufacturer’31 within the meaning of the EU MDL and in what kind of business-related context they operate.
  • Evaluate the material scope: before establishing applicable MDL requirements, it is necessary to evaluate whether the OSHW project falls under the definition of a medical device within the meaning of MDL. Not every item used within the healthcare context will qualify as a medical device; hence, it is important to assess (1) the nature of the device, (2) its intended usage and, (3) its principal intended action.
  • Establish the purpose of the device (core question): makers and designers should evaluate whether the item is intended to be principally used for a specific medical purpose or not, as determined by the law. As an example, a medical purpose may be the treatment or the compensation of a disability or an injury, or the replacement or modification of a part of human anatomy.32

A list of questions in Table 1 may help makers and designers in the evaluation of the points above.

4. Conclusions and Recommendations

The grey areas concerning the applicability of laws and regulations in the OSHW field may result in uncertainty for the stakeholders involved. In order to start filling this gap, this paper provided an overview of the common legal challenges that makers and designers usually face while creating OSHW healthcare projects. The main points outlined in the above chapters may be summarised in the form of the following findings (Figure 3):

  • Privacy and data protection. Developing an OSHW project entails the processing of personal and health data of individuals. This may happen at different stages of design and co-creation of a project, namely while designing or prototyping, or while uploading the related documentation to a collaborative platform. During all these stages, each stakeholder involved should take into account its respective role in the processing, the legal basis, and the purposes of the data processing activities. Moreover, data should be processed in a lawful, transparent, and fair manner while technical and organisational measures necessary to ensure the security of the processing need to be in place. Individuals should always be informed of any processing of their personal data, and data protection by design approach should be applied from the early design stage of the OSHW project.
  • Intellectual property rights. Designers and makers of an OSHW project should consult the international and national copyright laws applicable to the documentation that reflects the design of the OSHW, their implications, given rights, and duration of the protection in order to be able to assess adequately and chose licensing terms. Moreover, they should evaluate whether the patent protection could be granted for the hardware part of their OSHW project, its implications, rights, and licensing possibilities.
  • Liability. Co-design and co-creation of OSHW projects often involve many stakeholders likely to lead to an overlap of liability responsibilities. As stakeholders are often located in different geographical areas, different national liability frameworks may become applicable, following the principles and rules of international private law. Applicability of rules depends on concrete situations. As a tool to mitigate risks for other users OSHW projects, it is recommended to provide specific warranties, disclaimers or warning clauses to OSHW projects.
  • Law on medical devices. To assess whether a project has to comply with the EU medical devices legislation, makers and designers should take into account the notion of ‘manufacturer’, the definition of a ‘medical device’, and the purpose they want to attribute to the OSHW project.